Hi all, Some weird idea. I'm not sure it needs to be in the mainstream version, but somebody might find it helpful. For example I may want to refactor the naming scheme for protocols/tables in my bird config. But when I apply the new config with the new names, such renamed protocols will be recreated or restarted, which may be undesired. So if I could rename protocols/tables in advance and then load the new config, I can hope than no changes would be found and the there would be no interruptions. The attached patch solves the problem, by introducing such changes: To rename some symbol one can use cli command: rename <old_symbol> "<new_name>" The new name is in the form of the string, because symbol form requires symbol to be created. I tried to use CF_SYM_UNDEFINED for the second parameter. It works somehow, but leaves duplicate symbols in the table. If there is some way to clean them after it, it could be more visually pleasing option. The other problem is that a symbol has the fixed buffer for the name bound by its length. And one would not be able to rename it to a new name that is longer. But to overcome that, I add a field to a symbol to remember the length of the allocated buffer and allow the buffer to be bigger. This can be controlled by config option: symbols min <len> Which sets minum length that will fit the buffer. But as symbols are allocated while reading the config, you need to place this configuration option to the top of your config, i.e. before all the symbols you want to rename. So you can load the old config with the old names and this option added, it will allocate bigger buffers for the symbols. Then you can rename your symbols to the new ones. And finally load the new config with the new names. Of course you need the bird version with this patch applied in advace to do the trick. :)
Hello!
For example I may want to refactor the naming scheme for protocols/tables in my bird config. But when I apply the new config with the new names, such renamed protocols will be recreated or restarted, which may be undesired. So if I could rename protocols/tables in advance and then load the new config, I can hope than no changes would be found and the there would be no interruptions.
What I was thinking about some time ago, was not this kind of "renaming from CLI" but a special clause "renamed XYZ to ABC" which could be put at the end (!) of the new config. This would solve the problem with rewriting the symbol in-place which is ugly. Yet there are problems (mostly in v3) where e.g. the protocol name is pre-formatted into other strings, effectively forcing us to walk through the code and find all these cases while renaming. We don't want BIRD to errorneously log about a protocol with its old name. All in all, I'd not opposed to this idea, yet from my current POV, the changes needed are too high for now to have it a single patch or so. Thank you for your suggestion! Maria
On Tue, Jan 24, 2023 at 06:57:01AM +0100, Maria Matejka via Bird-users wrote:
Hello!
For example I may want to refactor the naming scheme for protocols/tables in my bird config. But when I apply the new config with the new names, such renamed protocols will be recreated or restarted, which may be undesired. So if I could rename protocols/tables in advance and then load the new config, I can hope than no changes would be found and the there would be no interruptions.
What I was thinking about some time ago, was not this kind of "renaming from CLI" but a special clause "renamed XYZ to ABC" which could be put at the end (!) of the new config. This would solve the problem with rewriting the symbol in-place which is ugly.
Hello I thing that the most elegant way how to handle renaming of objects during reconfiguration is to allow multiple names / aliases. There could be be more symbols pointing to given object (but the object points back to its primary name). Reconfiguration to rename objects could be done in two steps - in the first step, the user would add alias for the new name. In the second step, the old name would be removed. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On 24 January 2023 07:33:24 CET, Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Tue, Jan 24, 2023 at 06:57:01AM +0100, Maria Matejka via Bird-users wrote:
Hello!
For example I may want to refactor the naming scheme for protocols/tables in my bird config. But when I apply the new config with the new names, such renamed protocols will be recreated or restarted, which may be undesired. So if I could rename protocols/tables in advance and then load the new config, I can hope than no changes would be found and the there would be no interruptions.
What I was thinking about some time ago, was not this kind of "renaming from CLI" but a special clause "renamed XYZ to ABC" which could be put at the end (!) of the new config. This would solve the problem with rewriting the symbol in-place which is ugly.
Hello
I thing that the most elegant way how to handle renaming of objects during reconfiguration is to allow multiple names / aliases. There could be be more symbols pointing to given object (but the object points back to its primary name).
Reconfiguration to rename objects could be done in two steps - in the first step, the user would add alias for the new name. In the second step, the old name would be removed.
I think this keeps the problem with protocol restart when the renaming of "base name" is done. Yet you can do something like having base symbols like gdjdhcixsnrviowdh and use aliases for everything… which would make your logs and "show route" unreadable and you'd have to apply some additional machinery to address this. Maria
On Tue, Jan 24, 2023 at 07:44:47AM +0100, Maria Matejka wrote:
Hello
I thing that the most elegant way how to handle renaming of objects during reconfiguration is to allow multiple names / aliases. There could be be more symbols pointing to given object (but the object points back to its primary name).
Reconfiguration to rename objects could be done in two steps - in the first step, the user would add alias for the new name. In the second step, the old name would be removed.
I think this keeps the problem with protocol restart when the renaming of "base name" is done.
The primary problem of renaming is matching existing objects with definitions from the new config. If that can be done (by finding existing objects through aliases), it is just a reconfiguration of object property, like any other. I.e. implementation problem instead of conceptual problem. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On Tue, Jan 24, 2023 at 7:59 AM Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Tue, Jan 24, 2023 at 07:44:47AM +0100, Maria Matejka wrote:
Hello
I thing that the most elegant way how to handle renaming of objects during reconfiguration is to allow multiple names / aliases. There could be be more symbols pointing to given object (but the object points back to its primary name).
Reconfiguration to rename objects could be done in two steps - in the first step, the user would add alias for the new name. In the second step, the old name would be removed.
I think this keeps the problem with protocol restart when the renaming of "base name" is done.
The primary problem of renaming is matching existing objects with definitions from the new config. If that can be done (by finding existing objects through aliases), it is just a reconfiguration of object property, like any other. I.e. implementation problem instead of conceptual problem.
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. Probably might work if it is done in several steps: 1) name1 2) name1 + alias name2 3) name2 + alias name1 4) name2
On Tue, Jan 24, 2023 at 8:12 AM Alexander Zubkov <green@qrator.net> wrote:
On Tue, Jan 24, 2023 at 7:59 AM Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Tue, Jan 24, 2023 at 07:44:47AM +0100, Maria Matejka wrote:
Hello
I thing that the most elegant way how to handle renaming of objects during reconfiguration is to allow multiple names / aliases. There could be be more symbols pointing to given object (but the object points back to its primary name).
Reconfiguration to rename objects could be done in two steps - in the first step, the user would add alias for the new name. In the second step, the old name would be removed.
I think this keeps the problem with protocol restart when the renaming of "base name" is done.
The primary problem of renaming is matching existing objects with definitions from the new config. If that can be done (by finding existing objects through aliases), it is just a reconfiguration of object property, like any other. I.e. implementation problem instead of conceptual problem.
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. Probably might work if it is done in several steps: 1) name1 2) name1 + alias name2 3) name2 + alias name1 4) name2
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: link <alias> to <symbol> It makes "alias" to reference the same entity as "symbol". 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. 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: CF_CLI(RENAME, CF_SYM_KNOWN CF_SYM_UNDEFINED, <sym> <new>, [[Rename symbol]]) 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.
Hi, I did some more experimenting with making aliases from cli. As I understand, cli has its own "config" structure and memory pool, where its symbols are allocated. So I need to copy it to the current config, but I did not find suitable functions for doing that. And I make a copy for cf_new_symbol. Not sure though, that I did everything right. It would be great if someone looked at it and gave me some advice. I split the modifications into two parts: creating aliases in the config and then creating it in the cli. I think this idea with aliases is not that ugly. The solution is quite minimal and does not affect anybody who do not touch aliases. So if somebody wants to be able to do renaming in their setup - feel free to use/test the patches. And maybe in such form it would be meaningful to include it into the upstream version, as it is not that ugly anymore (at least from my point of view). :) I also not sure wether I need to copy the "scope" field from the reference symbol or keep it from aliased. I originally kept if from alias symbol and it worked too, at least with "config"-aliases. Now I'm copying it from the reference symbol and it also works. On Tue, Jan 24, 2023 at 9:42 AM Alexander Zubkov <green@qrator.net> wrote:
On Tue, Jan 24, 2023 at 8:12 AM Alexander Zubkov <green@qrator.net> wrote:
On Tue, Jan 24, 2023 at 7:59 AM Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Tue, Jan 24, 2023 at 07:44:47AM +0100, Maria Matejka wrote:
Hello
I thing that the most elegant way how to handle renaming of objects during reconfiguration is to allow multiple names / aliases. There could be be more symbols pointing to given object (but the object points back to its primary name).
Reconfiguration to rename objects could be done in two steps - in the first step, the user would add alias for the new name. In the second step, the old name would be removed.
I think this keeps the problem with protocol restart when the renaming of "base name" is done.
The primary problem of renaming is matching existing objects with definitions from the new config. If that can be done (by finding existing objects through aliases), it is just a reconfiguration of object property, like any other. I.e. implementation problem instead of conceptual problem.
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. Probably might work if it is done in several steps: 1) name1 2) name1 + alias name2 3) name2 + alias name1 4) name2
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: link <alias> to <symbol> It makes "alias" to reference the same entity as "symbol".
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.
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: CF_CLI(RENAME, CF_SYM_KNOWN CF_SYM_UNDEFINED, <sym> <new>, [[Rename symbol]]) 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.
On 24 January 2023 07:54:23 CET, Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Tue, Jan 24, 2023 at 07:44:47AM +0100, Maria Matejka wrote:
Hello
I thing that the most elegant way how to handle renaming of objects during reconfiguration is to allow multiple names / aliases. There could be be more symbols pointing to given object (but the object points back to its primary name).
Reconfiguration to rename objects could be done in two steps - in the first step, the user would add alias for the new name. In the second step, the old name would be removed.
I think this keeps the problem with protocol restart when the renaming of "base name" is done.
The primary problem of renaming is matching existing objects with definitions from the new config. If that can be done (by finding existing objects through aliases), it is just a reconfiguration of object property, like any other. I.e. implementation problem instead of conceptual problem.
Well… yes, it is more of an implementation problem, yet in v3 I considered this more of an invariant. It can be done, though, I'm just kind of lazy to check all the places where I put the protocol / table name like memory pool names or IO loop names… and implement renaming of these. Maria
On Tue, Jan 24, 2023 at 7:05 AM Maria Matejka via Bird-users < bird-users@network.cz> wrote:
Hello!
For example I may want to refactor the naming scheme for protocols/tables in my bird config. But when I apply the new config with the new names, such renamed protocols will be recreated or restarted, which may be undesired. So if I could rename protocols/tables in advance and then load the new config, I can hope than no changes would be found and the there would be no interruptions.
What I was thinking about some time ago, was not this kind of "renaming from CLI" but a special clause "renamed XYZ to ABC" which could be put at the end (!) of the new config. This would solve the problem with rewriting the symbol in-place which is ugly.
Yes, that is ugly and I would not run the "renamed" configuration long, just for the transition. But it is the minimal intervention I figured out. I was thinking about adding new symbols instead of changing the name in-place, but there are too many places where you need to update the pointers to the new names. And still you need to do something with the old symbol. When I rename them in place, it updates the names automatically, as they all point to the buffer inside symbol, as far as I understand.
Yet there are problems (mostly in v3) where e.g. the protocol name is pre-formatted into other strings, effectively forcing us to walk through the code and find all these cases while renaming. We don't want BIRD to errorneously log about a protocol with its old name.
Could you explain it more, when will you need to change something more in the code in my or your variant (with renamed statement)? As I udnerstand, in my variant, it should not be possible to log the old name, because I replace the string in-place. Only if it was copied somewhere. Anyway after loading the new config it should go away. In your variant too, if you do the second step and load the final config without "renamed" than there also should not be the old names. I don't think we should care much about logging during the transition.
All in all, I'd not opposed to this idea, yet from my current POV, the changes needed are too high for now to have it a single patch or so.
Thank you for your suggestion!
Maria
participants (3)
-
Alexander Zubkov -
Maria Matejka -
Ondrej Zajicek