implementation of faces

[Corey Osman]

Hi,

I remember when the puppet 2.7 release came out with support for faces was all the rage. The faces API seemed pretty slick as its a pluggable system that allows the plugin to implement options as well. I am curious if there is any design notes or blog that someone followed in order to create this system as I am looking to implement a similar pluggable feature for a project I have.


Corey

[Luke Kanies]

On Sep 21, 2015, at 7:52 PM, Corey Osman <co...@logicminds.biz> wrote:
>
> Hi,
>
> I remember when the puppet 2.7 release came out with support for faces was all the rage. The faces API seemed pretty slick as its a pluggable system that allows the plugin to implement options as well. I am curious if there is any design notes or blog that someone followed in order to create this system as I am looking to implement a similar pluggable feature for a project I have.

Hi Corey,

I was half of the design team for Faces (and a dev who left years ago was the other half).

There aren’t any design notes that I know of - we weren’t quite so mature as that then. My goal was to build an internal API that could be used directly in ruby or reflected directly onto the CLI, and I couldn’t find anything that could do it.

FWIW, most of the current dev considers Faces to be a miserable failure. I’m not clear on all the details, but I think it mostly comes down to a high degree of complexity, low relative value, and unnecessarily complicated implementation.

Not very helpful, but there you go.

[Reid Vandewiele]

On Tuesday, September 22, 2015 at 9:17:22 AM UTC-7, Luke Kanies wrote:

On Sep 21, 2015, at 7:52 PM, Corey Osman <co...@logicminds.biz> wrote:
>
> Hi,
>
> I remember when the puppet 2.7 release came out with support for faces was all the rage.  The faces API seemed pretty slick as its a pluggable system that allows the plugin to implement options as well.  I am curious if there is any design notes or blog that someone followed in order to create this system as I am looking to implement a similar pluggable feature for a project I have.  

As an end-user of Faces I don't have insight into how they work or the design process, but I can share a little bit of what makes them awesome and what doesn't work at all. I'm a very light user and I'm sure I don't use the full suite of functionality but I've found writing and using them to be easy and enjoyable (except for the lack of documentation).

What I know about faces comes from tinkering with them on and off, and writing one or two over the last couple of years (only one of which I can find/remember now). I've tinkered with the `puppet node` face, the `puppet node_aws`, `puppet node_gce` faces, and written https://forge.puppetlabs.com/tse/nimbus.

What I like as an end-user:

• CLI and API equivalence. This is AWESOME. This is the #1 reason I'm a fan of Faces.
• Relatively easy API for setting up my UI - subcommands and arguments.
• Direct access to Puppet. Especially other faces! But settings and utility methods are a boon as well.

What I don't like / Doesn't work:

• Versions. I don't use them. Nobody uses them. I'm also pretty sure they don't work. They don't contribute to the usability or draw of Faces.
• I want to be able to specify more than one subcommand. E.g. I want to write `puppet nimbus modules install`, but since that's the "nimbus" face and two sub-commands it doesn't work well. I have to make do with `puppet nimbus install_modules`.
• Many faces are Terminus faces (`puppet certificate`, `puppet ca`, etc). Basically, a kind of generalized wrapper for interacting with terminii. Those seem overgeneralized and often don't hold up well. Faces with more intentional and specific design seem to work much better, generally.

People with more experience around the full suite of Face functionality may be able to infer by omission other things that either don't excite people or need documentation to expose.

~Reid 

[Reid Vandewiele]

On Tuesday, September 22, 2015 at 11:43:30 AM UTC-7, Reid Vandewiele wrote:

What I know about faces comes from tinkering with them on and off, and writing one or two over the last couple of years (only one of which I can find/remember now). I've tinkered with the `puppet node` face, the `puppet node_aws`, `puppet node_gce` faces, and written https://forge.puppetlabs.com/tse/nimbus.

Ah ha! Remembered and found another one: https://github.com/reidmv/puppet-module-puppet_certificate/blob/master/lib/puppet/provider/puppet_certificate/ruby.rb#L22.

Finding that one re-emphasized for me why CLI and API equivalence is the big win of Faces. The other half of the Face user experience is not just writing them, but being able to use them when writing other Puppet components. It's great to have that feeling of (probably false) knowledgeability you get from knowing things on the Puppet CLI, and being able to leverage it when you branch out and start trying to write more automated extensions of it. E.g. types and providers, as shown in this example.

~Reid

[Erik Dalén]

On Tue, 22 Sep 2015 at 20:43 Reid Vandewiele <re...@puppetlabs.com> wrote:

On Tuesday, September 22, 2015 at 9:17:22 AM UTC-7, Luke Kanies wrote:

On Sep 21, 2015, at 7:52 PM, Corey Osman <co...@logicminds.biz> wrote:
>
> Hi,
>
> I remember when the puppet 2.7 release came out with support for faces was all the rage.  The faces API seemed pretty slick as its a pluggable system that allows the plugin to implement options as well.  I am curious if there is any design notes or blog that someone followed in order to create this system as I am looking to implement a similar pluggable feature for a project I have.  

As an end-user of Faces I don't have insight into how they work or the design process, but I can share a little bit of what makes them awesome and what doesn't work at all. I'm a very light user and I'm sure I don't use the full suite of functionality but I've found writing and using them to be easy and enjoyable (except for the lack of documentation).

What I know about faces comes from tinkering with them on and off, and writing one or two over the last couple of years (only one of which I can find/remember now). I've tinkered with the `puppet node` face, the `puppet node_aws`, `puppet node_gce` faces, and written https://forge.puppetlabs.com/tse/nimbus.

What I like as an end-user:

• CLI and API equivalence. This is AWESOME. This is the #1 reason I'm a fan of Faces.
• Relatively easy API for setting up my UI - subcommands and arguments.
• Direct access to Puppet. Especially other faces! But settings and utility methods are a boon as well.

What I don't like / Doesn't work:

• Versions. I don't use them. Nobody uses them. I'm also pretty sure they don't work. They don't contribute to the usability or draw of Faces. 

+1 on this.

• I want to be able to specify more than one subcommand. E.g. I want to write `puppet nimbus modules install`, but since that's the "nimbus" face and two sub-commands it doesn't work well. I have to make do with `puppet nimbus install_modules`.
• Many faces are Terminus faces (`puppet certificate`, `puppet ca`, etc). Basically, a kind of generalized wrapper for interacting with terminii. Those seem overgeneralized and often don't hold up well. Faces with more intentional and specific design seem to work much better, generally.

I contributed some improvements to the terminus faces that have been merged into Puppet 4.x which I think improves their usability quite a bit. They are the following:

•  --help support, no need to use the help face to get help
  
• removed unsupported subcommands instead of just documenting them as unsupported
  
• made `find` the default action for terminus faces
• made `find` default to the host certname if no host argument is supplied

So now stuff like `puppet facts` gives you the facts directly, no need to write `puppet facts find localhost`.

 

People with more experience around the full suite of Face functionality may be able to infer by omission other things that either don't excite people or need documentation to expose.

~Reid 

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/11fba4ec-eb3b-42c3-908f-eb38a961249e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Luke Kanies]

On Sep 23, 2015, at 1:30 AM, Erik Dalén <erik.gus...@gmail.com> wrote:

On Tue, 22 Sep 2015 at 20:43 Reid Vandewiele <re...@puppetlabs.com> wrote:

On Tuesday, September 22, 2015 at 9:17:22 AM UTC-7, Luke Kanies wrote:

On Sep 21, 2015, at 7:52 PM, Corey Osman <co...@logicminds.biz> wrote: 
> 
> Hi, 
> 
> I remember when the puppet 2.7 release came out with support for faces was all the rage.  The faces API seemed pretty slick as its a pluggable system that allows the plugin to implement options as well.  I am curious if there is any design notes or blog that someone followed in order to create this system as I am looking to implement a similar pluggable feature for a project I have.   

As an end-user of Faces I don't have insight into how they work or the design process, but I can share a little bit of what makes them awesome and what doesn't work at all. I'm a very light user and I'm sure I don't use the full suite of functionality but I've found writing and using them to be easy and enjoyable (except for the lack of documentation).

What I know about faces comes from tinkering with them on and off, and writing one or two over the last couple of years (only one of which I can find/remember now). I've tinkered with the `puppet node` face, the `puppet node_aws`, `puppet node_gce` faces, and written https://forge.puppetlabs.com/tse/nimbus.

What I like as an end-user:

• CLI and API equivalence. This is AWESOME. This is the #1 reason I'm a fan of Faces.
• Relatively easy API for setting up my UI - subcommands and arguments.
• Direct access to Puppet. Especially other faces! But settings and utility methods are a boon as well.

What I don't like / Doesn't work:

• Versions. I don't use them. Nobody uses them. I'm also pretty sure they don't work. They don't contribute to the usability or draw of Faces. 

+1 on this.

Interesting. We sure fought a lot over this one internally. 

• I want to be able to specify more than one subcommand. E.g. I want to write `puppet nimbus modules install`, but since that's the "nimbus" face and two sub-commands it doesn't work well. I have to make do with `puppet nimbus install_modules`.
• Many faces are Terminus faces (`puppet certificate`, `puppet ca`, etc). Basically, a kind of generalized wrapper for interacting with terminii. Those seem overgeneralized and often don't hold up well. Faces with more intentional and specific design seem to work much better, generally.

I contributed some improvements to the terminus faces that have been merged into Puppet 4.x which I think improves their usability quite a bit. They are the following:

•  --help support, no need to use the help face to get help
  
• removed unsupported subcommands instead of just documenting them as unsupported
  
• made `find` the default action for terminus faces
• made `find` default to the host certname if no host argument is supplied

So now stuff like `puppet facts` gives you the facts directly, no need to write `puppet facts find localhost`.

Nice.

One of the primary goals of Faces was to directly expose on the CLI APIs that already existed (i.e., those Indirector interfaces).  We didn’t work hard to do much more than expose them, so it’s great to hear you were able to make the reflection more usable.

People with more experience around the full suite of Face functionality may be able to infer by omission other things that either don't excite people or need documentation to expose.

~Reid 

-- 
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/11fba4ec-eb3b-42c3-908f-eb38a961249e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAAAzDLdeUhUuL1215jYUx7vJticvy7dLNsjiWc1oJ8%3Dutk5gOg%40mail.gmail.com.