The only current mechanism for renaming a resource agent is to add a symlink at the old name pointing to the new one. This works, but is not very flexible or easily maintained.
A first thought might be to put alias information in resource agent meta-data. However, this is not practical, as resource managers and tools would have to read all meta-data of all installed agents to check alias information.
Another possibility would be an aliases file at a well-known location. For example, "aliases" inside the provider directory would be simple, as well as obvious when browsing the directories (as system administrators frequently do). That would prevent the use of "aliases" as an actual agent name; using a more obscure name such as "ALIASES", "aliases.txt" or even a separate "/usr/lib/ocf/alias.d/" hierarchy would get around that, but I doubt it's worth it -- banning "aliases" as an agent name shouldn't cause any problems in practice, and higher-level tools could explicitly warn about it.
Each provider would provide its own aliases, rather than have a single, shared aliases file, which would be difficult to maintain with entries from multiple providers; also, this would be considered under the control of the provider, not user-configurable (users could of course configure aliases for any custom providers of their own).
# Provide an alias within same provider
IPaddr: IPaddr2
# Provide an alias after changing a provider (in original provider's aliases file)
widget: acme:widget
# Provide an alias for an entire provider (in old provider name's aliases file)
*: clusterlabs:*
For ease of implementation, it would be a good idea to prevent alias recursion, i.e. an alias pointing to another alias. This could pose theoretical problems if an alias points to a different provider, but that is unlikely to be a practical issue, as aliasing one provider to another is likely to be done when both providers are under the same administrative control (e.g. a single organization renaming its provider, or separating a single provider into multiple providers).
Also for ease of implementation, I would recommend the first match wins (if there are multiple), and "*" (meaning "all agents not already matched") as the only wildcard. I.e. I would recommend against supporting regular expressions or file glob patterns, because first, it is a solution in search of a problem, and second, it is a quantum jump in the complexity of parsing the file.
It would be simple to support a requirement that blank lines and some simple comment format (e.g. lines starting with '#' and '#' plus everything following it at the end of a line) should be ignored.
There have been past suggestions that it might be useful to mark whether an alias is considered deprecated, which could trigger a warning or automatic upgrade by higher-level tools. For example, someone might want fully supported aliases for "apache", "Apache", and "httpd", but want to deprecate another name entirely. I am not sure the added complexity is worthwhile, but if so, a "deprecated" keyword could be added to the end of the alias line (e.g. "IPaddr2: IP deprecated").
The only current mechanism for renaming a resource agent is to add a symlink at the old name pointing to the new one. This works, but is not very flexible or easily maintained.
A first thought might be to put alias information in resource agent meta-data. However, this is not practical, as resource managers and tools would have to read all meta-data of all installed agents to check alias information.
Another possibility would be an aliases file at a well-known location. For example, "aliases" inside the provider directory would be simple, as well as obvious when browsing the directories (as system administrators frequently do). That would prevent the use of "aliases" as an actual agent name; using a more obscure name such as "ALIASES", "aliases.txt" or even a separate "/usr/lib/ocf/alias.d/" hierarchy would get around that, but I doubt it's worth it -- banning "aliases" as an agent name shouldn't cause any problems in practice, and higher-level tools could explicitly warn about it.
Each provider would provide its own aliases, rather than have a single, shared aliases file, which would be difficult to maintain with entries from multiple providers; also, this would be considered under the control of the provider, not user-configurable (users could of course configure aliases for any custom providers of their own).
Possible file format:
Examples:
For ease of implementation, it would be a good idea to prevent alias recursion, i.e. an alias pointing to another alias. This could pose theoretical problems if an alias points to a different provider, but that is unlikely to be a practical issue, as aliasing one provider to another is likely to be done when both providers are under the same administrative control (e.g. a single organization renaming its provider, or separating a single provider into multiple providers).
Also for ease of implementation, I would recommend the first match wins (if there are multiple), and "*" (meaning "all agents not already matched") as the only wildcard. I.e. I would recommend against supporting regular expressions or file glob patterns, because first, it is a solution in search of a problem, and second, it is a quantum jump in the complexity of parsing the file.
It would be simple to support a requirement that blank lines and some simple comment format (e.g. lines starting with '#' and '#' plus everything following it at the end of a line) should be ignored.
There have been past suggestions that it might be useful to mark whether an alias is considered deprecated, which could trigger a warning or automatic upgrade by higher-level tools. For example, someone might want fully supported aliases for "apache", "Apache", and "httpd", but want to deprecate another name entirely. I am not sure the added complexity is worthwhile, but if so, a "deprecated" keyword could be added to the end of the alias line (e.g. "IPaddr2: IP deprecated").