run mode in faces?
Peter Meier
Hash: SHA1
Hi
I tried to port the clean application (#1886) with help of Nick to
faces. So far it looks good (POC pushed to my github account), except
that faces seem to run in user mode (by default). This is for example
likely a problem when we try to figure out, whether the master is
configured as CA or not.
So currently my POC can't delete any certs as it thinks it is not a CA.
We weren't able to figure out how we can set it on a face action side.
Also we were asking us how the certificate face is then actually be able
to sign certificates, as imho it should know whether it is a CA or not,
before trying to sign any certs.
Any hints?
Thanks!
~pete
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk261iwACgkQbwltcAfKi39iqACfZGyTxXUy67Fu+V6Yv9H3RKud
uLkAn2O+oOrVEnWSm40rctMdwvFFPz/w
=/O/P
-----END PGP SIGNATURE-----
Daniel Pittman
G'day.
> I tried to port the clean application (#1886) with help of Nick to
> faces. So far it looks good (POC pushed to my github account), except
> that faces seem to run in user mode (by default). This is for example
> likely a problem when we try to figure out, whether the master is
> configured as CA or not.
>
> So currently my POC can't delete any certs as it thinks it is not a CA.
>
> We weren't able to figure out how we can set it on a face action side.
> Also we were asking us how the certificate face is then actually be able
> to sign certificates, as imho it should know whether it is a CA or not,
> before trying to sign any certs.
>
> Any hints?
The only way to specify the run mode is at the very start of the
application; this is one of the limitations of the older Puppet
architecture that we didn't completely excise during the initial move
to faces. Specifically, you need to pass it on the command line:
] puppet --mode {user,agent,master} node clean # or whatever...
That will set the run mode before it does the rest of the command line
parsing, invokes your face and action, or anything like that.
To make the certificate face work as expected you have to do the same
thing: set the run mode globally, for all faces, before any face is
invoked.
Regards,
Daniel
--
⎋ Puppet Labs Developer – http://puppetlabs.com
✉ Daniel Pittman <dan...@puppetlabs.com>
✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775
♲ Made with 100 percent post-consumer electrons
Peter Meier
Hash: SHA1
Hi Daniel,
thanks for your answer.
> The only way to specify the run mode is at the very start of the
> application; this is one of the limitations of the older Puppet
> architecture that we didn't completely excise during the initial move
> to faces. Specifically, you need to pass it on the command line:
>
> ] puppet --mode {user,agent,master} node clean # or whatever...
>
> That will set the run mode before it does the rest of the command line
> parsing, invokes your face and action, or anything like that.
>
> To make the certificate face work as expected you have to do the same
> thing: set the run mode globally, for all faces, before any face is
> invoked.
hmm, this makes faces not so useable for certain cases. So for example
the clean face: Setting the mode on the cli is quite cumbersome, and I'm
not really happy to propose a face, that only works with an additional
cli flag, to be included in the core.
However, the certificate face will be included, which, I fear, will lead
to a lot of confusion and imho regarding Randall's UX talk, the current
behavior should actually be a no go.
So as far as I see we have to options:
* fix setting mode before 2.7. Is this feasible?
* Ship things that require an ugly face/cli-options chain. Could we then
at least say that certain actions require master mode and abort
otherwise? One option is to manually test it on our own in the action,.
The other way would be to have a more declarative way, where we can
require run modes for an action and abort execution in a more generic
and clean way. (With a nice error message and so on...)
It would be nice to have the first option, otherwise various faces will
look quite half baken. However, I don't know all the internals and
further plans to decide and say whether it's actually feasible. So #2
would also be fine, although rather hacky and smelly.
Other options?
~pete
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk2+9OcACgkQbwltcAfKi3/GqwCcCIlulcJ9HioXvzqKg13LG12g
gSMAn2GvaksQyQh0162GmDGpaTYpjU2k
=4BZG
-----END PGP SIGNATURE-----
Daniel Pittman
> thanks for your answer.
I only wish I had a better answer to give you at this stage.
>> The only way to specify the run mode is at the very start of the
>> application; this is one of the limitations of the older Puppet
>> architecture that we didn't completely excise during the initial move
>> to faces. Specifically, you need to pass it on the command line:
>>
>> ] puppet --mode {user,agent,master} node clean # or whatever...
>>
>> That will set the run mode before it does the rest of the command line
>> parsing, invokes your face and action, or anything like that.
>>
>> To make the certificate face work as expected you have to do the same
>> thing: set the run mode globally, for all faces, before any face is
>> invoked.
>
> hmm, this makes faces not so useable for certain cases. So for example
> the clean face: Setting the mode on the cli is quite cumbersome, and I'm
> not really happy to propose a face, that only works with an additional
> cli flag, to be included in the core.
I agree. Part of the problem is that faces are young, and we can't
rearchitect the entire Puppet system before 2.7.0 is due out; this
assumption that run-mode is fixed at startup time is pretty darn core
in the entire set of assumptions the code used to make.
That said? You /can/ change run-mode dynamically. We don't make
promises about that always working, but it is reasonably stable as far
as I can tell. (Essentially, if it tests stable it probably is, but
we don't universally test for code that makes assumptions that it is
static.)
> * fix setting mode before 2.7. Is this feasible?
Nope. There is basically no chance you could do that.
> * Ship things that require an ugly face/cli-options chain. Could we then
> at least say that certain actions require master mode and abort
> otherwise? One option is to manually test it on our own in the action,.
> The other way would be to have a more declarative way, where we can
> require run modes for an action and abort execution in a more generic
> and clean way. (With a nice error message and so on...)
So, you can declare your run-mode in your face application shell, if
you want. If you only require 'master' mode then declaring it in
there will work for now, and we can sort of the rest later.
> It would be nice to have the first option, otherwise various faces will
> look quite half baken. However, I don't know all the internals and
> further plans to decide and say whether it's actually feasible. So #2
> would also be fine, although rather hacky and smelly.
Yah. Sadly, there is no chance we can fix that before release. Sorry.
> Other options?
I think you covered it.