[ClusterLabs Developers] [questionnaire] Do you overload pacemaker's meta-attributes to track your own data?
jpokorny at redhat.com
Thu Jun 28 14:23:29 EDT 2018
Hello, and since it is a month since the preceding attempt to gather
some feedback, welcome to yet another simple set of questions that
I will be glad to have answered by as many of you as possible,
as an auxiliary indicator what's generally acceptable and what's not
within the userbase.
This time, I need to introduce context of the questions, since that's
important, and I am sorry it's rather long (feel free to skip lower
to the same original indentation level if you are in a time press):
As you've surely heard when in touch with pacemaker, there's
a level of declarative annotations for resources (whether primitive
or otherwise), their operations and few other entities. You'll
find which ones (which identifiers in variable assignments emulated
with identifier + value pairs) can be effectively applied in which
context in the documentation -- these are comprehended with
pacemaker and put into resource allocation equations.
Perhaps less known is the fact that these sets are open to possibly
foreign, user-defined assignments that may effectively overload the
the primary role of meta-attributes, dragging user-defined semantics
there. There may be warnings about doing so at the high-level
management tools, but pacemaker won't protest by design, as this
is also what allows for smooth configuration reuse with various
point releases possibly acquiring new meanings for new identifiers.
This possibility of a free-form consumer extensibility doesn't appear
to be advertised anywhere (perhaps to prevent people confusing CIB,
the configuration hierarchy, with generic key-value store, which it
is rather not), and within the pacemaker configuration realms, it
wasn't useful until it started to be an optional point of interest
in location constraints thanks to ability to refer meta-attributes
in the respective rules based on "value-source" indirection,
which arrived with pacemaker 1.1.17.
More experienced users/developers (intentionally sent to both lists)
may already start suspecting potential namespace collisions between
a narrow but possibly growing set identifiers claimed by pacemaker
for its own (and here original) purpose, and those that are added
by users, either so as to pose in the mentioned constraint rules
or for some other, possibly external automation related purpose.
So, I've figured out that with upcoming 2.0 release, we have a nice
opportunity to start doing something about that, and the least
effort, fully backward + tooling compatible, that would start
getting us to a conflict-less situation is, in my opinion, to start
actively pushing for a lexical cut, asking for a special
prefix/naming convention for the mentioned custom additions.
This initiative is meant to consist of two steps:
a. modify the documentation to expressly detail said lexical
- you can read draft of my change as a pull request for pacemaker:
(warning: the respective discussion was somewhat heated,
and is not a subject of examination nor of a special interest
here), basically I suggest "x-*" naming, with full recommended
convention being "x-appname_identifier"
b. add a warning to the logs/standard error output (daemons/CLI)
when not recognized as pacemaker's claimed identifier nor
starting with dedicated prefix(es), possibly referring to
the documentation stanza per a., in a similar way the user
gets notified that no fencing devices were configured
- this would need to be coded
- note that this way, you would get actually warned about
your own typos in the meta-attribute identifiers even
if you are not using any high-level tooling
This may be the final status quo, or the eventual separation
of the identifiers makes it really easy to perform other schema
upgrade related steps with future major schema version bumps
_safely_. Nobody is immediately forced to anything, although
the above points should make it clear it's prudent to get ready
(e.g. also regarding the custom tooling around that) in respect
to future major pacemaker/schema version bumps and respective
auto-upgrades of the configuration (say it will be declared
it's valid to upgrade to pacemaker 3.0 only from as old pacemaker
as 2.0 -- that's the justification for acting _now_ with preparing
sane grounds slowly).
* * *
So now the promised questions; just send a reply where you [x] tick
your selections for the questions below, possibly with some more
commentary on the topic, and preferrably on-list (single of your
choice is enough):
1. In your cluster configurations, do you carry meta-attributes
other than those recognized by pacemaker?
[ ] no
[ ] yes (if so, can you specify whether for said constraints
rules, as a way to permanently attach some kind of
administrative piece of information, whether you
have the whole custom tooling around this, etc.?)
2. How do you feel about said meta-attributes' namespace separation
proposal (as summarized in documentation edit per above link)?
[ ] no feelings/not related to my use cases (e.g., haven't used
custom meta-attributes possibility before, no inclination to
use that in the future)
[ ] too cumbersome, better to live with the risk of the future
clashes now (and with the risk of distant future automatic
upgrade doing accidentally a wrong thing)
[ ] acceptable, but only as an interim solution
[ ] acceptable without complaints
* * *
I am also keen to hear if this rather non-intrusive change alone could
be a show-stopper for some.
Thanks for your feedback!
 e.g. for primitive resources:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: not available
More information about the Developers