|
This ticket is to explore how we could cease supporting plugin facts on a per-environment basis.
Currently per-environment plugin facts can be used as an input to node classification, which means a node may end up issuing multiple plugin downloads and catalog requests during a single run as it attempts to reconcile its environment with the one specified in its catalog.
This goes something like this:
1) agent with 'production' environment requests catalog
2) catalog specifies 'dev' environment
3) agent plugin-syncs from 'dev' environment
4) 'dev' environment plugins include new facts
5) agent submits catalog request with new facts, resulting in different classification
6) new catalog specifies 'test' environment
7) agent plugin-syncs from 'tests' environment
...
and so on up to 4 times.
The net effect on performance is non-trivial, as a worst-case agent run can generate 4x the load and nearly as many network calls. The logic in Puppet::Configurer is overly complex to accommodate.
Eliminating per-environment facts could dramatically simplify the agent run lifecycle by reducing the number of requests and environment switching logic in the configurer. This is a backwards-incompatible change that would require some sort of workflow replacement for users relying on per-environment facts. Many modules deliver facts (this is a standard mechanism for distribution of custom facts) - making them per-environment by default.
From a workflow perspective, we should investigate
-
what are the use-cases for plugin-facts that are dependent on their environment?
-
are there other ways we could achieve these without using facts?
-
how would we support distributing facts without placing them in modules, or is there another way?
-
is this even worth it?
|
