show unused environments

[rwaffen]

get all environments from puppetdb even if no node is running against it

[tuxmea]

Show unused envs

The actual state of HDM works as follows:
HDM reads from PuppetDB which environments are in use (by at least one node which did a complete puppet agent run).
Only after a complete Puppet agent run, the PuppetDB has all data for that node (environment, facts, reports).
Once we select an environment, we read the nodes facts which use the selected environment.

Now we want to also show unused Puppet environments.
Unused environments are located on the filesystem, but don't show up in PuppetDB.
Within HDM we should mark the unused environment (e.g. by prefixing the string 'unused')
When selecting an unused environment, we want the user to select ANY node from the node list.
On unused environments no data changes should be possible (read-only mode).

2nd use case:

Which hiera data does the node retrieve if the node switches its environment?

Solution:

As we want to achieve different results for different use cases we came up with the following proposal:

1. Environments:

• read all environments from file system
• read environments from PuppetDB
• mark unused environments

1. Nodes

• we need a toogle switch which defaults to "show nodes from env only" and which can be set to "all nodes"
• Node list then shows nodes depending on toggle.

API endpoints to use: https://www.puppet.com/docs/puppetdb/7/api/query/v4/nodes.html#pdbqueryv4nodesnodefacts

[oneiros]

I am currently struggling with our test data here as we reuse node names between environments. So just to confirm: In an actual production environment a node can only belong to one environment, correct?

[oneiros]

I am currently struggling with our test data here as we reuse node names between environments. So just to confirm: In an actual production environment a node can only belong to one environment, correct?

The trouble with the test data goes even deeper than I feared. With this change, we would need to query for a node's facts without specifying an environment. We already talked about how that is possible. But in our test data we have node facts in yaml files per environment. This would make it impossible (or at least ugly) to access the correct node data in tests.

I would proprose that we move out the node fact yaml files from the individual environments and into a single folder, e.g. test/fixtures/files/puppet/nodes/.

Each file should contain the current environment of the node. This means we will no longer have all nodes in all environments that they were previously in. I would try to see which ones are actually used in tests and thus important to be in a specific environment and try to divide the remaining ones up equally between those environments where it makes sense to have many nodes.

@tuxmea, since you created most of this test data, do you see any problem with this approach?

[oneiros]

I believe my assumption above is OK, so I went ahead and moved test data around a lot, but with a different approach as outlined above: I put all existing nodes in the development environment, created 25 new nodes in all other environments that had the full set formerly and 5 nodes in the one case where it only had a handfull before.

Tests work fine so far, so I created #146.