The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com
https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:
faces silently fail against master
|Assignee:||Jeff Weiss||% Done:|
|Affected Puppet version:||development||Branch:||https://github.com/puppetlabs/puppet/pull/679|
Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com
when I check out master for puppet, some of my face commands no longer work.
Below is the output when I invoke a face:
no output against master
puppet stack destroy --name nova_single_fedora
it works against 2.7.x
puppet stack destroy --name nova_single_fedora notice: Destroying nodes ec2-46-51-157-246.eu-west-1.compute.amazonaws.com foo notice: Destroying i-9ab1afd3 (ec2-46-51-157-246.eu-west-1.compute.amazonaws.com) ... notice: Destroying i-9ab1afd3 (ec2-46-51-157-246.eu-west-1.compute.amazonaws.com) ... Done
I can print the docs for this face against both branches using puppet stack help
The faces in question can be found here:
#7 Updated by Chris Price about 4 years ago
So basically, what is going on here is that we’ve changed the order that we deal with settings. The global puppet settings handling code now gets first crack at the settings, and it already defines a setting called “name”. Your “name” setting is being confused with that one and some stupid things are happening.
Also, the non-existent error handling here is unacceptable.
I’ll explore this a bit further and see if I can come up with any suggestions for fixing this, along with estimated difficulty…
#9 Updated by Chris Price about 4 years ago
- Status changed from Investigating to Accepted
- Assignee changed from Patrick Carlisle to Chris Price
I’m going to send an email to puppet-dev to solicit input on this issue.
The basic premise is this:
Faces should probably not be allowed to define command-line options that have the same name as built-in puppet settings.
However, it is not an ideal situation that puppet’s built-in settings include a “name” setting.
So, I think there are two things that should come out of this ticket:
- Get rid of (or rename) the “name” setting in puppet’s built-ins, and
- Add validation logic to the faces API so that it errors out if the face attempts to define an option that is already defined by puppet’s built-ins.
#13 Updated by Jeff Weiss about 4 years ago
It would appear the at least in the
certificate case, the meaning of
dns_alt_names is slightly different between the Puppet.settings and the command line argument.
Puppet[:dns_alt_names] is a list of my alternate names whereas
certificate are the alternate names for the host for which I’m generating the certificate.
#16 Updated by Jeff Weiss about 4 years ago
Ok, so it appears that the options included in
--dns-alt-names, whereas the existing puppet setting is
puppet cert, an application not a face, you can do
puppet cert <command> --dns_alt_names <names> <host> and it will do the right thing.
For the faces
certificate you can do something awesome like
puppet ca generate --dns_alt_names alt1 --dns-alt-names alt2 host and it will use
I’m betting that the face options of
--dns-alt-names were added to include the documentation from
--dns_alt_names, and that the
s/_/-/g was in this commit.
#17 Updated by Jeff Weiss about 4 years ago
- Status changed from Investigating to In Topic Branch Pending Review
- Branch set to https://github.com/puppetlabs/puppet/pull/679
I still have to check with Randall about what our path forward should be on the module face’s “documentation only” options of
:environment. The pull request currently remove the explicit declaration of those options, and therefore the documentation; however, the functionality remains (because they were existing Puppet settings that can be passed to any Face to begin with).