Ok, I''ve had this weekend to create some recipes and here''s what I''ve think are missing from Puppet... 1. The obvious one is power if statements.. I assume this is being improved in future versions. I have seen the wiki workaround/hack. 2. classes and puppet itself is missing multiple states of an application? Meaning you can easily define how to get Puppet to install and configure an application to a specific state, but what about uninstalling it or other states? It almost appears you need a constructor/destructor statements in the ''class'' statement. I assume this goes along with planned transactions into puppet. Maybe some of this can be done by using tags? Luke, I know you mentioned you don''t have a timeline listed and when you did only a few people visited it. :-) What is planned to get to 1.0 status that you mentioned would be this year? Just curious what''s at least on the 3-6 month horizon.. Thanks.. -L -- Larry Ludwig Empowering Media 1-866-792-0489 x600 Managed and Unmanaged Xen VPSes http://www.hostcube.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Apr 13, 2008, at 3:03 PM, Larry Ludwig wrote:> > Ok, I''ve had this weekend to create some recipes and here''s what I''ve > think are missing from Puppet... > > 1. The obvious one is power if statements.. I assume this is being > improved in future versions. I have seen the wiki workaround/hack.These would be relatively easy to add for anyone willing to make an effort with the parser. I''ve got much bigger fish to fry.> > 2. classes and puppet itself is missing multiple states of an > application? Meaning you can easily define how to get Puppet to > install and configure an application to a specific state, but what > about uninstalling it or other states? It almost appears you need a > constructor/destructor statements in the ''class'' statement. I assume > this goes along with planned transactions into puppet. Maybe some of > this can be done by using tags?This is something I''ve thought about but haven''t had any time to actually implement. We could probably copy the SmartFrog model, since I think it has this ability. I''m not planning on this making it into 1.0; really, it''s unlikely that this will get done by anyone at Reductive Labs unless we suddenly have many more full time developers or a customer pays for it. I do want this kind of feature, I just don''t have the time to implement it for free.> > Luke, I know you mentioned you don''t have a timeline listed and when > you did only a few people visited it. :-) What is planned to get to > 1.0 status that you mentioned would be this year? Just curious what''s > at least on the 3-6 month horizon..I did create a ''RoadMap'' wiki page, and it explains the major work I think needs to be done to release 1.0. It''s mostly refactoring, rather than new features, since 1.0 implies stable interfaces. -- I do not feel obliged to believe that the same God who has endowed us with sense, reason, and intellect has intended us to forgo their use. -- Galileo Galilei --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Apr 13, 10:14 pm, Luke Kanies <l...@madstop.com> wrote:> I''m not planning on this making it into 1.0; really, it''s unlikely > that this will get done by anyone at Reductive Labs unless we suddenly > have many more full time developers or a customer pays for it. I do > want this kind of feature, I just don''t have the time to implement it > for free. >These two are at least the most obvious I''ve seen. Before I can even think about adding features myself to Puppet I really need to become more of an ''expert'' with the automation/Puppet domain. Most of this means using Puppet more and more in our production environment and how Puppet fit with ours and our customer''s needs. I also too have bigger fish to fry ;-) For now Puppet is an much needed advancement compared to other tools (or custom hack/scripts) out there. Obviously as computing services are becoming more ''grid'' and ''on demand'' tools like Puppet are not an option but a necessity. With the 100+ VPS/servers we manage we see how this can help tremendously. Our previous methods to manage the configs was ok at best. One thing I see is OSS projects, commercial products and even outsourced sysadmins having each their own puppetmaster which you subscribe your server to and makes the setup ''just happen''. Obviously with the current state of Puppet''s one-to-one relationship, this makes it kinda hard. Either this or some other method to automate the download of the latest vendor recipe. Cheers! -L -- Larry Ludwig Empowering Media 1-866-792-0489 x600 Managed and Unmanaged Xen VPSes http://www.hostcube.com/> > > Luke, I know you mentioned you don''t have a timeline listed and when > > you did only a few people visited it. :-) What is planned to get to > > 1.0 status that you mentioned would be this year? Just curious what''s > > at least on the 3-6 month horizon..Ah found it... thanks.. :-)> I did create a ''RoadMap'' wiki page, and it explains the major work I > think needs to be done to release 1.0. It''s mostly refactoring, > rather than new features, since 1.0 implies stable interfaces. > > -- > I do not feel obliged to believe that the same God who has endowed us > with sense, reason, and intellect has intended us to forgo their use. > -- Galileo Galilei > --------------------------------------------------------------------- > Luke Kanies |http://reductivelabs.com|http://madstop.com--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Larry-> One thing I see is OSS projects, commercial products and even > outsourced sysadmins having each their own puppetmaster which you > subscribe your server to and makes the setup ''just happen''. Obviously > with the current state of Puppet''s one-to-one relationship, this makes > it kinda hard. Either this or some other method to automate the > download of the latest vendor recipe. >Have you taken a look at modules? there is a page on teh wiki about using modules for just this type of thing.Comparing it to the current RPM/YUM or DPG/APT setups the puppet mpdules will take the role of RPM/DPG and something else (not yet build) will take on the role of YUM/APT. So it looks like we are about half way there. Evan --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Sun, Apr 13, 2008 at 1:03 PM, Larry Ludwig <larrylud@gmail.com> wrote:> > Ok, I''ve had this weekend to create some recipes and here''s what I''ve > think are missing from Puppet... > > 1. The obvious one is power if statements.. I assume this is being > improved in future versions. I have seen the wiki workaround/hack.I used to consider this a problem until I spent more time working on puppet. I''ve come to the conclusion that if you really need complex if statements, you should really try to do your abstraction at a different level and model a type instead. The fact that the community hasn''t been clamoring for this backs this up in my opinion. I would like to work on a few simple additions like "if x and y" and "if x or y" and maybe even a ''if x =="foo"'' to replace simple case statements but apart from that, I really don''t think we need particularly powerful if statements. my 2c. -- Nigel Kersten Systems Administrator MacOps --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
--On Sunday, April 13, 2008 1:03 PM -0700 Larry Ludwig <larrylud@gmail.com> wrote:> 2. classes and puppet itself is missing multiple states of an > application? Meaning you can easily define how to get Puppet to > install and configure an application to a specific state, but what > about uninstalling it or other states? It almost appears you need a > constructor/destructor statements in the ''class'' statement. I assume > this goes along with planned transactions into puppet. Maybe some of > this can be done by using tags?We generally just have a subclass overrides the class that configures the application or service. For instance, we have an ssh::disabled class that overrides the ssh class and ensures the service is stopped and the port closed in iptables. I think this approach is more sensible as Puppet is not intended to be a programming language but a configuration management system. I generally find that situations that seem to require super advanced features can actually be solved with the existing abilities if approached a little differently. That''s been my experience, for the most part. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Can you give an example of this? I assume it''s just class ssh::disabled inherits ssh, and then some differences, and then in an node you can just include ssh::disabled, which would overwrite say, ''include ssh'' in baseclass? On Wed, Apr 16, 2008 at 12:09 PM, Digant C Kasundra <digant@stanford.edu> wrote:> > --On Sunday, April 13, 2008 1:03 PM -0700 Larry Ludwig <larrylud@gmail.com > > > wrote: > > > 2. classes and puppet itself is missing multiple states of an > > application? Meaning you can easily define how to get Puppet to > > install and configure an application to a specific state, but what > > about uninstalling it or other states? It almost appears you need a > > constructor/destructor statements in the ''class'' statement. I assume > > this goes along with planned transactions into puppet. Maybe some of > > this can be done by using tags? > > We generally just have a subclass overrides the class that configures the > application or service. For instance, we have an ssh::disabled class that > overrides the ssh class and ensures the service is stopped and the port > closed in iptables. I think this approach is more sensible as Puppet is > not intended to be a programming language but a configuration management > system. I generally find that situations that seem to require super > advanced features can actually be solved with the existing abilities if > approached a little differently. That''s been my experience, for the most > part. > > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
The more I''m seeing this the more I am also thinking KISS (Keep It Simple Silly/Stupid) The less complex the options the less one gets into trouble and hard to test, validate is true. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Wed, Apr 16, 2008 at 11:10 AM, Ashley Penney <apenney@gmail.com> wrote:> Can you give an example of this? I assume it''s just class ssh::disabled > inherits ssh, and then some differences, and then in an node you can just > include ssh::disabled, which would overwrite say, ''include ssh'' in > baseclass?We don''t do this, but here is the general idea: class ssh { package { ["openssh", "openssh-clients", "openssh- server"]: ensure => present, } service { sshd: ensure => running, subscribe => File["/etc/ssh/sshd_config"], } } class ssh::disable inherits ssh { Package["openssh", "openssh-clients", "openssh-server"] { ensure => absent, } Service["sshd"] { ensure => stopped, } } The important part is that the resources in the child class are specified with a capital letter to indicate overriding the resource from the parent class. Apologies for any syntax errors :-). --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---