New feature: Show data in modules

[tuxmea]

Discussed in #243

^{Originally posted by tuxmea December 22, 2023}

Request

As a Puppet admin I want to be able to see the module data in case that I select a key with a module name

Solution

Within HDM -> environments -> node -> Key

Check if the selected key first part of the name is a module name by:

• reading the environment.conf modulepath setting (use modules as default, multiple entries are separated by colon :, can also be absolute path)
  • Example:

    modulepath = site-modules:modules:/etc/puppetlabs/puppet/modules:../global
    

  • Default:

    modulepath = modules:$basemodulepath
    

    Basemodulepath: Puppet.settings('basemodulepath')
    Default:

    basemodulepath = /etc/puppetlabs/code/modules:/opt/puppetlabs/puppet/modules
    

• parse the modulepath directories in order for a directory with the same name
• if the directory exists
  • check for hiera.yaml inside the directory
  • if the hiera.yaml file exists
    • show the module button
  • if not
    • dont show the module button
• if not
  • dont show the module button

If module data exist, a button module will show up next to the key.

Now HDM switches into module data view.
There should be a button environment which leads back to the environment data (ideally the one where we switched to module data view).

Within the key list, only module data are shown.
The hiera data directory/file structured is build in the same way as we do it now with environment data.
When selecting a key, one sees the same view as in environment data.

[oneiros]

Basemodulepath: Puppet.settings('basemodulepath')

Up until now we have avoided parsing or otherwise accessing puppet's configuration directly. This is great as it allows to run hdm without a running puppet installation, which is handy not just for development purposes imo.

So I would propose we handle this as we have done with other comparable settings in the past: We assume the same default as puppet, but allow to override it in hdm.yml.

From #351 (comment):

I have not looked into the module layer thing much, but the basis is already here, so I guess it is more a matter of figuring out when to access which module. Should not be too hard (i know, i know, "famous last words" 🙂 ).

Of course it is more complicated than I had anticipated 😂

The new structure that emerged as part of #330 adds a concept of layers, but those layers are quite static: Once you have chosen an environment (which is always the first step in hdm), the global and environment layers are set and will not change.

The module layer is a lot more dynamic, though. It depends on the key that is being queried. But not only that, the most important use case of hdm is displaying all keys for a given node. I tend towards the first option in #243 (comment): At least to begin with it will probably make sense to only show keys that have been overridden in the environment or global layer, not every single key available in all modules.

This means, the module layer is something different, depending on context. Here is a (possibly incomplete) list:

• Show all keys:
  • No module layer
• Search for or lookup of a key:
  • Top-level key?
    • No module layer
  • Namespaced key:
    • Module with the name of the namespace exists?
      • Module layer for the given module
    • No module with the name of the namespace exists?
      • No module layer

The code currently pushes most of these operations (or parts there of) to the lowest code layer (basically a single hierarchy as defined in one of the hiera.yaml files). This leaves us with no obvious place to make these decisions. I will have to think about this some more.

(Sorry for the noise. There is no question in here, I mainly write this down because there is a weekend ahead and I do not want to forget all of this. But if anyone has any remarks anyway, they are very welcome.)