Three prototypes
Luke Kanies
Those of you two track my puppet fork on github already know this, but I produced a few potentially interesting prototypes while I was at EclipseCon a couple of weeks ago. None of them are something we could merge in, but they're at least interesting and might be something worth at least investing in.
These are provided as an FYI, so there's at least some record of what these prototypes are and why they exist. Feel free to follow up with questions, fork them and add tests and send a pull request, or just ignore completely.
--------
Interactive transactions: https://github.com/lak/puppet/tree/prototype/master/interactive_transactions
This provides a simple prompt before changing any resource in a transaction, with the idea being that you could give people like developers some control over how Puppet ran on their system without just giving them carte blanche. You have a few options:
Change: Make the change
Noop: Run it in noop mode
Fail: Throw an exception, thus skipping it and all of its dependencies
Hold: Run this in noop mode in this and any later transactions
That last option involved me building a simple system for storing the list of held resources. You could use it to hold and release resources independent of this interactive transaction (I unfortunately could not use the 'resource' face for this, because it's already used for indirector stuff):
$ puppet held_resources hold 'File[/tmp/foo]'
$ puppet held_resources list
$ puppet held_resources release 'File[/tmp/foo]'
For this to make it into the system, we'd need a new event type, so that the reports retained the difference between a held resource and a resource in noop mode, and we'd need to think a bit about things like whether a held resource should hold its dependencies, too.
---------
Locally audited resources: https://github.com/lak/puppet/tree/prototype/master/locally_audited_files
On a similar note, this branch provides the ability for a local admin to include resource s/he is managing in an audit report being centralized. This is only useful if you're using 'puppet inspect', but it's useful if you're going to make local changes to a system outside of Puppet's control, but you want Puppet to track the change without actually managing anything.
This is, I think, a really common pattern, especially for developers, and this should make it much easier for those devs to at least do part of the right thing, which makes the admins better able to track and manage what the dev is doing.
It's a very small thing, but devs might find it especially useful, and especially so if you're using the Compliance tool in PE.
----------
An interactive puppet shell: https://github.com/lak/puppet/tree/prototype/master/puppet_shell
The best tool I ever had for managing ldap directories was a simple, stupid tool I wrote called ldapsh: http://search.cpan.org/dist/ldapsh/ . It wasn't much of a shell (e.g., no autocomplete), but it was still 100x better than the tools at the time. I've always wanted something similar in Puppet, so I figured I'd give it a shot.
The basic idea is that you'd treat the resource types as the top-level directories, and you could cd around, look at resources, edit them, clone them, or remove them. The reality isn't that nice, because not all resource types play well with this -- e.g., you can't list file instances at all. It's also just really obvious how much work it is to make an ok shell, and you'd still just rather have bash or whatever.
I think a FUSE filesystem would be fantastic for this, especially if it supported connecting to other hosts, or even parallelizing across mcollective, but this is more interesting experiment to make a point than anything I'd recommend actually supporting.
--
Luke Kanies | http://about.me/lak | http://puppetlabs.com/ | +1-615-594-8199
Ken Barber
>
> The best tool I ever had for managing ldap directories was a simple, stupid tool I wrote called ldapsh: http://search.cpan.org/dist/ldapsh/ . It wasn't much of a shell (e.g., no autocomplete), but it was still 100x better than the tools at the time. I've always wanted something similar in Puppet, so I figured I'd give it a shot.
>
> The basic idea is that you'd treat the resource types as the top-level directories, and you could cd around, look at resources, edit them, clone them, or remove them. The reality isn't that nice, because not all resource types play well with this -- e.g., you can't list file instances at all. It's also just really obvious how much work it is to make an ok shell, and you'd still just rather have bash or whatever.
>
> I think a FUSE filesystem would be fantastic for this, especially if it supported connecting to other hosts, or even parallelizing across mcollective, but this is more interesting experiment to make a point than anything I'd recommend actually supporting.
This tool seems interesting - are we able to plugin-sync faces
properly yet? Would be good to get this out into a module. At the very
least it would be awesome for training purposes to teach people the
power of the RAL, but beyond that it starts to get into the discussion
we were having with Paul Anderson about his lcfg tooling that drives
his components. I'm fascinated by the idea that not only should Puppet
be useful for setting policy, but perhaps for providing cross-platform
real time control on the CLI and this certainly asserts that some
more.
ken.
Michael Stahnke
>> An interactive puppet shell: https://github.com/lak/puppet/tree/prototype/master/puppet_shell
>>
>> The best tool I ever had for managing ldap directories was a simple, stupid tool I wrote called ldapsh: http://search.cpan.org/dist/ldapsh/ . It wasn't much of a shell (e.g., no autocomplete), but it was still 100x better than the tools at the time. I've always wanted something similar in Puppet, so I figured I'd give it a shot.
>>
>> The basic idea is that you'd treat the resource types as the top-level directories, and you could cd around, look at resources, edit them, clone them, or remove them. The reality isn't that nice, because not all resource types play well with this -- e.g., you can't list file instances at all. It's also just really obvious how much work it is to make an ok shell, and you'd still just rather have bash or whatever.
>>
>> I think a FUSE filesystem would be fantastic for this, especially if it supported connecting to other hosts, or even parallelizing across mcollective, but this is more interesting experiment to make a point than anything I'd recommend actually supporting.
>
> This tool seems interesting - are we able to plugin-sync faces
> properly yet?
> Would be good to get this out into a module. At the very
> least it would be awesome for training purposes to teach people the
> power of the RAL, but beyond that it starts to get into the discussion
> we were having with Paul Anderson about his lcfg tooling that drives
> his components. I'm fascinated by the idea that not only should Puppet
> be useful for setting policy, but perhaps for providing cross-platform
> real time control on the CLI and this certainly asserts that some
> more.
>
> ken.
>
> --
> 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.
>
Ken Barber
>
> This provides a simple prompt before changing any resource in a transaction, with the idea being that you could give people like developers some control over how Puppet ran on their system without just giving them carte blanche. You have a few options:
>
> Change: Make the change
> Noop: Run it in noop mode
> Fail: Throw an exception, thus skipping it and all of its dependencies
> Hold: Run this in noop mode in this and any later transactions
>
> That last option involved me building a simple system for storing the list of held resources. You could use it to hold and release resources independent of this interactive transaction (I unfortunately could not use the 'resource' face for this, because it's already used for indirector stuff):
>
> $ puppet held_resources hold 'File[/tmp/foo]'
> $ puppet held_resources list
> $ puppet held_resources release 'File[/tmp/foo]'
>
> For this to make it into the system, we'd need a new event type, so that the reports retained the difference between a held resource and a resource in noop mode, and we'd need to think a bit about things like whether a held resource should hold its dependencies, too.
I like this one as well Luke ... I could see this kind of thing going
into core - its worth keeping our ears and eyes open for real-world
case that this would solve I think. I believe its something that once
it was in there, people would use it.
ken.
Luke Kanies
I'd be happy to see someone pull this into a module.
Ken Barber
scaffolding for this new shell tool here:
https://github.com/puppetlabs/puppetlabs-shell
But its very much pre-release at this point (so its not on the forge
and doesn't have a formal release number) - so buyer beware!
I've added the most basic of tests, but it needs lots more love.
Patches accepted - especially rspec test related ones :-).
ken.