Is "nodelist" (corosync.conf) represented better as an object instead of a list?

[scmschmidt]

I had a discussion with @pirat013 about the representation of "nodelist" by the corosync.conf gatherer. Here an example:

...
  "Name": "nodelist.node",
  "CheckID": "",
  "Value": {
    "Value": [
      {
        "Value": {
          "nodeid": {
            "Value": 2
          },
          "ring0_addr": {
            "Value": "192.168.122.22"
          }
        }
      },
      {
        "Value": {
          "nodeid": {
            "Value": 1
          },
          "ring0_addr": {
            "Value": "192.168.122.11"
          }
        }
      }
    ]
  },
...

The nodes are represented as a list of objects. Fetching a specific node would mean iterate over the list until you have found the correct "nodeid".
Would it not make more sense to have an object (in Python I would call it a dictionary) with "noteid" as key?

Example: "nodelist.node": { "1": { "ring0_addr": "192.168.122.11" }, "2": { "ring0_addr": "192.168.122.22} }

[pirat013]

Thanks @scmschmidt for the details written down.
FMPOV looking at bigger cluster like 31 nodes in a scaleout setup, it would be helpful to get the result back much more readable. And btw if someone didn't know that an index is starting with 0 , the missing value for the --argument 'nodelist.node.<node_index>.nodeid' is quite hard to catch from the output.

[dottorblaster]

Hi @scmschmidt, thanks for the feedback! Would you kindly provide a working implementation using what we have at the moment and a concurrent potential implementation using a dictionary-shaped return value?

Keep in mind anyway that gatherer return values are anemic in logic by design, because it's easier to embed some additional logic in a check in a second moment than tying gatherer results to specific implementations.

[scmschmidt]

Hi @dottorblaster, sorry, but I'm not a golang programmer. Dive into the code, understand and modify it would take me a few days at least.

I wasn't aware that the current anemic logic is by design. Seeing that e.g. corosync.conf does cutting after a space and trimming strings made me think, that some sort of cleaning/evaluation takes place, which is a relief for test writers.
Maybe we should make clear and formulate what a gatherer does with the values and what doesn't.

Other question/idea. Would it be possible to add self-written libraries to the check engine? We could leave the gatherer like it is, but add functions available in the DSL/Rhai to processing facts. In our case translating the node list into a dictionary. That keeps the gatherer lean but eases the life of test writers.

(Unlike others, I haven't found time yet to dig into the DSL or Rhai, so forgive me if I missed an already documented way.)

[dottorblaster]

sorry, but I'm not a golang programmer. Dive into the code, understand and modify it would take me a few days at least.

Sorry, maybe I explained myself in a very poor way. I just meant an implementation of a working check using what we have. Anyway, I think @fabriziosestito's answer is more authoritative than mine.

[scmschmidt]

No worries. Yep, I guess your request is obsolete now.

[fabriziosestito]

@scmschmidt thanks for the feedback. At this moment we prefer not to alter the corosync configuration structure by adding custom parsing only for certain fields.
This could lead to confusion, as some fields could return inconsistent values.

The "nodelist" is in fact a list. This is expected and also underlined by the field name.

By using the rhai expression language, it is very easy to get an element by a property (in this case nodeid), which is basically the same as getting a value by knowing the key.
See index_of and get here: https://rhai.rs/book/language/arrays.html?highlight=array#arrays

For instance:

nodelist[nodelist.index_of(|x| x.nodeid == 1)]

Other question/idea. Would it be possible to add self-written libraries to the check engine? We could leave the gatherer like it is, but add functions available in the DSL/Rhai to processing facts.

Yes it's possible. We are thinking to add a find function to arrays so that you could write the above in one step instead using the combination of get and index_of.

Not sure about converting this to a dict though.

[scmschmidt]

@fabriziosestito Thanks. Learning Rhai first seems to be in order. ;-) I guess a find function is good too. Just an easy way to get an element of a list by its attribute value. Don't know if we'll run into problems if such lists get longer. Currently I don't see a problem, but if we gather devices from hosts in the future to evaluate them, we can end up with dozens or more entries.

[fabriziosestito]

I guess a find function is good too

Yes I am talking to the rhai mantainer and he's up to accept a PR in that regards, so I will be working on it in the next days.

we can end up with dozens or more entries

Even thousands shouldn't be worrying in terms of performances.
Also, by doing the conversion in the gatherer itself we would cycle the list anyways, so it will not change much.

[fabriziosestito]

@scmschmidt i've just corrected the snippet

[scmschmidt]

Even thousands shouldn't be worrying in terms of performances.
Good.

Also, by doing the conversion in the gatherer itself we would cycle the list anyways, so it will not change much.
Right. If really long lists cause performance issues, it doesn't matter how processing them.

[fabriziosestito]

@scmschmidt @pirat013 we've added Array.find to the expectation language. See here: https://rhai.rs/book/language/arrays.html?highlight=array#built-in-functions

nodelist[nodelist.index_of(|x| x.nodeid == 1)]

becomes

nodelist.find(|x| x.nodeid == 1)