seeking feedback on face: puppet-minicat
Eric Sorenson
- is the face structured correctly and am I using the helpers the way they're intended?
- are these '.indirection.find' calls are the right way to make use of the Puppet API?
https://github.com/ahpook/puppet-minicat/blob/master/lib/puppet/face/minicat.rb#L33-38
Any comments appreciated (no matter how harsh :)
[1] https://github.com/ahpook/puppet-minicat
[2] http://www.masterzen.fr/2012/03/17/puppet-internals-the-compiler/
[3] http://puppetlabs.com/blog/about-faces-until-we-go-in-the-right-direction/ (The teaser for the next installment has me on tenterhooks!)
- Eric Sorenson - N37 17.255 W121 55.738 - http://twitter.com/ahpook -
Luke Kanies
> Hi, I got approval from $WORK to post up a little face I wrote called puppet-minicat[1], and I'd like to solicit feedback on it -- it was my first foray into Faces and I'm not sure whether I'm doing things right. (That I was able to get this far at all is thanks to Brice's awesome compiler blogpost[2] and Daniel's post on the PL blog[3].) Specifically I'm wondering:
>
> - is the face structured correctly and am I using the helpers the way they're intended?
>
> - are these '.indirection.find' calls are the right way to make use of the Puppet API?
> https://github.com/ahpook/puppet-minicat/blob/master/lib/puppet/face/minicat.rb#L33-38
>
> Any comments appreciated (no matter how harsh :)
I think this is pretty cool. I've done a ton of testing out of ~/.puppet, and this style of usage works well. The puppet.conf in my ~ is:
modulepath = /Users/luke/etc/puppet/modules
certname = localhost
trace = true
manifest = /Users/luke/bin/test.pp
daemonize = false
vardir = /Users/luke/var/puppet
confdir = /Users/luke/etc/puppet
server = localhost
rest_authconfig = /Users/luke/etc/puppet/auth.conf
This makes it so I can do almost everything without having to specify arguments, which might simplify your usage.
My first thought on reading the doc briefly was that it's a kind of subgraph - I assumed you were compiling the whole catalog and then only looking at a bit of it. I realize now you're just modifying the class list, rather than modifying the output, and I *think* you're pretty-printing the resulting catalog in json, although it's a bit hard to tell from the docs.
This seems like a useful tool, especially for the use case in question, but you could maybe provide a more general tool by building some graph selection capabilities. E.g., something like:
$ puppet subgraph 'Class[foo::bar]'
That would (according to how I'm thinking of it) compile a normal catalog but only print the parts of it that are below the mentioned resource. Thus, you'd get all of the resources in that class, or required by that class. You could add support for things like:
$ puppet subgraph --no-deps 'Class[foo]'
if you didn't want dependencies, or, of course:
$ puppet subgraph --no-containers 'Class[foo]'
if you only wanted them.
There are about a billion graph operations you could do, but most are pretty useless for us. I have been thinking of something like this as a replacement for --tags: Build a more powerful selection tool that could just print a catalog, apply it, etc.
In terms of the indirection syntax, um, unfortunately, yes, that's largely what you do. I think Daniel has finally reverted the code that required the Catalog.indirection.find call, so in the latest versions you can again just do Catalog.find, but you should also be able to just use a face from now on:
Puppet::Face[:catalog, "current"].find(…)
I'm not totally thrilled with that UI, either, but we're working on it.
--
Luke Kanies | http://about.me/lak | http://puppetlabs.com/ | +1-615-594-8199
Eric Sorenson
On Apr 17, 2012, at 9:55 PM, Luke Kanies wrote:
> My first thought on reading the doc briefly was that it's a kind of subgraph - I assumed you were compiling the whole catalog and then only looking at a bit of it. I realize now you're just modifying the class list, rather than modifying the output, and I *think* you're pretty-printing the resulting catalog in json, although it's a bit hard to tell from the docs.
It's not as pretty as I'd like, but yep that's the idea.
> This seems like a useful tool, especially for the use case in question, but you could maybe provide a more general tool by building some graph selection capabilities. E.g., something like:
>
> $ puppet subgraph 'Class[foo::bar]'
> [ snip ]
> There are about a billion graph operations you could do, but most are pretty useless for us. I have been thinking of something like this as a replacement for --tags: Build a more powerful selection tool that could just print a catalog, apply it, etc.
The specific use case I wanted to address was viewing template output when the data come from an external data source and the result of template/controller logic is complicated enough that you can't just look at it and derive what will happen. But yes it would be really nice to be able to do more complete, graph-oriented operations on the catalog, because the broader idea is that people should be able to test how their code will behave on production systems without having to physically be on the system in question, by convincing the data store that your client ought to get the value resolution that the real box would.
> In terms of the indirection syntax, um, unfortunately, yes, that's largely what you do. I think Daniel has finally reverted the code that required the Catalog.indirection.find call, so in the latest versions you can again just do Catalog.find, but you should also be able to just use a face from now on:
>
> Puppet::Face[:catalog, "current"].find(…)
>
> I'm not totally thrilled with that UI, either, but we're working on it.
OK, good to know. Thanks again.
Luke Kanies
> Luke, thanks for taking the time to reply. This is very helpful - a couple of comments inline...
>
> On Apr 17, 2012, at 9:55 PM, Luke Kanies wrote:
>
>> My first thought on reading the doc briefly was that it's a kind of subgraph - I assumed you were compiling the whole catalog and then only looking at a bit of it. I realize now you're just modifying the class list, rather than modifying the output, and I *think* you're pretty-printing the resulting catalog in json, although it's a bit hard to tell from the docs.
>
> It's not as pretty as I'd like, but yep that's the idea.
>
>> This seems like a useful tool, especially for the use case in question, but you could maybe provide a more general tool by building some graph selection capabilities. E.g., something like:
>>
>> $ puppet subgraph 'Class[foo::bar]'
>> [ snip ]
>> There are about a billion graph operations you could do, but most are pretty useless for us. I have been thinking of something like this as a replacement for --tags: Build a more powerful selection tool that could just print a catalog, apply it, etc.
>
> The specific use case I wanted to address was viewing template output when the data come from an external data source and the result of template/controller logic is complicated enough that you can't just look at it and derive what will happen. But yes it would be really nice to be able to do more complete, graph-oriented operations on the catalog, because the broader idea is that people should be able to test how their code will behave on production systems without having to physically be on the system in question, by convincing the data store that your client ought to get the value resolution that the real box would.
general tool with that purpose? I'd love to help.
>> In terms of the indirection syntax, um, unfortunately, yes, that's largely what you do. I think Daniel has finally reverted the code that required the Catalog.indirection.find call, so in the latest versions you can again just do Catalog.find, but you should also be able to just use a face from now on:
>>
>> Puppet::Face[:catalog, "current"].find(…)
>>
>> I'm not totally thrilled with that UI, either, but we're working on it.
>
>
> OK, good to know. Thanks again.
>
> - Eric Sorenson - N37 17.255 W121 55.738 - http://twitter.com/ahpook -
>
> You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
> To post to this group, send email to puppe...@googlegroups.com.
> To unsubscribe from this group, send email to puppet-dev+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
>
Eric Sorenson
>> because the broader idea is that people should be able to test how their code will behave on production systems without having to physically be on the system in question, by convincing the data store that your client ought to get the value resolution that the real box would.
>
> I definitely agree. At interest on your part in turning this into a
> general tool with that purpose? I'd love to help.
Any tips on where to start digging in the code to explore the graph constraints?
Luke Kanies
> On Apr 25, 2012, at 12:12 PM, Luke Kanies wrote:
>
>>> because the broader idea is that people should be able to test how their code will behave on production systems without having to physically be on the system in question, by convincing the data store that your client ought to get the value resolution that the real box would.
>>
>> I definitely agree. At interest on your part in turning this into a
>> general tool with that purpose? I'd love to help.
>
> Yes absolutely.
>
> Any tips on where to start digging in the code to explore the graph constraints?