[ClusterLabs Developers] [questionnaire] Do you overload pacemaker's meta-attributes to track your own data?

[Jan Pokorný]

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[1] -- 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[2],
  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
     requirement
     - you can read draft of my change as a pull request for pacemaker:
       https://github.com/ClusterLabs/pacemaker/pull/1523/files
       (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!


[1] e.g. for primitive resources:
    https://clusterlabs.org/pacemaker/doc/en-US/Pacemaker/1.1/html-single/Pacemaker_Explained/index.html#_resource_meta_attributes
[2] https://clusterlabs.org/pacemaker/doc/en-US/Pacemaker/1.1/html-single/Pacemaker_Explained/index.html#_node_attribute_expressions

-- 
Jan (Poki)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/developers/attachments/20180628/ab1d6422/attachment.sig>