Hi!
I have a couple of issues with puppet class import with foreman(-proxy)
1.5.1, with both Puppet 2.7.25 and 3.6.x, OS is Debian 7.
I feel this has worked better (if not perfectly) before, with 1.4.x - with
1.5.0 these issues started to appear, but I did not have time to
investigate until now, this is more of an "am I alone in this/what am I
doing wrong?" post, since the bugtracker did not have anything actually
matching.
- Setting the loglevel to "DEBUG" in foreman-proxy settings does not seem
to acutally do/change anything (for Foreman-Proxy Puppet) - at least there
are no additional log entries after setting to DEBUG, restarting and
re-running the class importer for example. That a known thing, or did I
just fail repeatedly when trying to write the word "debug"?
I would have expected that during class import the proxy would log which
env and which class it is parsing at any given time, or something like that?
Can anyone confirm/ Does anyone have a workaround?
- Classes get a) exclusively associated to b) the "wrong" puppet env, if
the modulepath setting contains multiple directories.
We have a huge number of puppetenvs (150+, don't ask), and our module-paths
always look like this:
[common] #I'm special
modulepath= "/etc/puppet/common/modules"
[env1]
modulepath= "/etc/puppet/env1/modules/:/etc/puppet/common/modules"
[env2]
modulepath= "/etc/puppet/env2/modules/:/etc/puppet/common/modules"
So all environments contain their own module dirs, as well as a (actually
two) commonly shared one(s).
When I let foreman import classes through the smartproxy, it seems as if
(and this feels new, as compared to 1.4 and maybe even 1.5.0) a module
"foo" found first in env "env2" via the "common/modules/" modulepath part,
will only be found once and be directly associated to "env2" ONLY, even
though it should pop up in ALL envs, since all envs include that module dir.
Previously I had all modules from "common/modules/" show up in foreman as
associated to ALLLL the envs, now they are asscoiated to exactly one,
probably the first env that was parsed.
This goes so far that the environment "common" does not (according to
foreman) contain any modules - likely since there is some condition
preventing multiple imports of the same module or the like?
This is true when importing from a puppet 2.7 master and when importing
from a 3.6 master - the configs are the same for both though, we have not
yet configured environment directories for 3.6 yet, so that may change
things?
Can anyone confirm/ Does anyone have a workaround?
- Changes to puppet classes do not seem to get found reliably.
I do 3 puppet class imports one directly after another - first one finds 20
changes, next one finds 40 more changes (which have not been performed
inbetween run 1 and 2) and the third one finds nothing, but the issue from
2 is still present - namely that the environemnt "common" does not seem to
contain any classes, so it's not actually "done".
Can anyone confirm/ Does anyone have a workaround?
- Hammer does not seem to honour the "–environment-id" setting.
hammer -dc proxy import-classes --environment-id 102 --id 3
imports all the stuff from all the configured puppet environments on that
smart proxy, providing --environmnet-id does not seem to do anything.
Can anyone confirm/ Does anyone have a workaround?
I will open bugs once/if confirmations are in, thank you!
Cheers,
Simon