<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 24, 2023 at 8:12 AM Alexander Zubkov <<a href="mailto:green@qrator.net">green@qrator.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 24, 2023 at 7:59 AM Ondrej Zajicek <<a href="mailto:santiago@crfreenet.org" target="_blank">santiago@crfreenet.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Jan 24, 2023 at 07:44:47AM +0100, Maria Matejka wrote:<br>
> >Hello<br>
> ><br>
> >I thing that the most elegant way how to handle renaming of objects<br>
> >during reconfiguration is to allow multiple names / aliases. There could<br>
> >be be more symbols pointing to given object (but the object points back<br>
> >to its primary name).<br>
> ><br>
> >Reconfiguration to rename objects could be done in two steps - in the<br>
> >first step, the user would add alias for the new name.  In the second step,<br>
> >the old name would be removed.<br>
> <br>
> I think this keeps the problem with protocol restart when the renaming<br>
> of "base name" is done.<br>
<br>
The primary problem of renaming is matching existing objects with<br>
definitions from the new config. If that can be done (by finding<br>
existing objects through aliases), it is just a reconfiguration of<br>
object property, like any other. I.e. implementation problem instead<br>
of conceptual problem.<br>
<br></blockquote><div><br></div>Adding aliases is an interesting option. But for example now in protos_commit() it uses WALK_LIST(oc, old->protos), so it walks around old protos first and then searches for a new ones. So it is not enough to add another name pointing to the protocol, you need to search for protocol name and also its aliases in the new protocols, or "invert" walking the lists in all such places.</div><div class="gmail_quote">Probably might work if it is done in several steps:<br></div><div class="gmail_quote">1) name1</div><div class="gmail_quote">2) name1 + alias name2</div><div class="gmail_quote">3) name2 + alias name1</div><div class="gmail_quote">4) name2<br></div></div></blockquote><div><br></div><div>I've checked such modifications (in attached patch), and it seems to work too. The transition with those several steps goes without protocol interruption for changing the names of protocols and tables. The patch adds the config statement:</div><div>link <alias> to <symbol></div><div>It makes "alias" to reference the same entity as "symbol".</div><div><br></div><div>In this case the transition process is longer, but less intervention in the code is required and it may be less ugly. As a plus, the transition can be done without additional CLI commands, only with a series of configs. On the other hand you can not do aliases CLI-only for the transition, you need them to be present in the new config while it is loading. You can do it in CLI for step 1->2, but for 2->3 it will not work. Renaming, though, needed intervention in the config too, to extend the symbol buffers.<br></div><div><br></div><div>I also tried to also do a CLI command for aliasing. But it does not work in this variant, the new symbol does not appear in the table. Probably it is cleaned up after the command finishes. It is strange, because when I tried the same for "rename" version like that:</div><div>CF_CLI(RENAME, CF_SYM_KNOWN CF_SYM_UNDEFINED, <sym> <new>, [[Rename symbol]])</div><div>Then I just copied the name from the undefined symbol to the known symbol. And after that I saw multiple occurence of the name in "show symbols". So I thought the undefined one was left in the table. But now when I run "link" in the cli, I do not see the new symbol in the table afterwards.<br></div></div></div>