Hi. As I think I mentioned (here or in IRC, dont know), I''m doing a kind of "grant" to investigate Puppet for my company. So far I''ve been learning the language and trying to model some of our infrastructure on a small test server I''ve set up. This is going fine, I''m learning a lot... but. This doesnt give me a picture of how is Puppet used on a real enviroment. So, I was kind of hoping if some sucessfull Puppet users on this list could have some time to chat about how they are using Puppet. How are your machines and services life-cycles managed - all with Puppet, from install to decommision? How do you deal with dynamic changes or process (been a theme of discussion lately here) and having Puppet enforcing a "state"? Do you work always inside Puppet or some task have you "shut down" it till you get it done correctly and then model it on Puppet? How many people work with your Puppet configuration and how do you manage access - basically how you use Puppet and distribute task to junior members or other teams or... What kind of benefits have you got from using Puppet? What kind of drawbacks? Have any taks you tried it and decided it was not suited? Are you using tools like Capistrano/MCollective/Func/etc with Puppet? Why? How do you coordinate that? ... yep, tons of things I know is generic stuff that is in part on the "Who is using Puppet" page, but I want to see if I can get some more detailed approximation of how do you live with Puppet as your system configuration management tool, instead of the common "lets log in via SSH and do stuff" admin model we all know by default. If you want to answer here for anybody to see, great, but I would really like to get in touch with, say, 2 or 3 "advocates" that could spend, say, 1 h or so, talking about how do they do their work with Puppet, so if you want to help, please send me a mail at this address. Best regards, ------------------------------ Jesús Couto F. -- 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.
Jesús Couto wrote:> Hi. > > As I think I mentioned (here or in IRC, dont know), I''m doing a kind > of "grant" to investigate Puppet for my company. So far I''ve been > learning the language and trying to model some of our infrastructure > on a small test server I''ve set up. > > This is going fine, I''m learning a lot... but. This doesnt give me a > picture of how is Puppet used on a real enviroment. > > So, I was kind of hoping if some sucessfull Puppet users on this list > could have some time to chat about how they are using Puppet. How are > your machines and services life-cycles managed - all with Puppet, from > install to decommision? How do you deal with dynamic changes or > process (been a theme of discussion lately here) and having Puppet > enforcing a "state"? Do you work always inside Puppet or some task > have you "shut down" it till you get it done correctly and then model > it on Puppet? How many people work with your Puppet configuration and > how do you manage access - basically how you use Puppet and distribute > task to junior members or other teams or...Provisioning is sort of outside the scope of the server lifecycle that puppet manages. I use preseed to provision, lots of people use kickstart. From there, puppet takes over and brings it to state X. Dynamic changes in processes are rare and can either be handled outside of puppet or be dynamically generated in other ways such as database queries. In very rare cases, like troubleshooting problems, I will stop puppet and make certain changes, then restart puppet when I am done, however it will be brought back to state X. Any permanent changes to state *always* go in puppet for too many reasons to list here. Three people have access to make puppet changes, and this is all handled by subversion and one unix group. With subversion you can easily manage write access to less important modules with a unix group something like junior_admins to only edit a certain module, and possibly not even deploy- just commit.> > What kind of benefits have you got from using Puppet? What kind of > drawbacks? Have any taks you tried it and decided it was not suited? > Are you using tools like Capistrano/MCollective/Func/etc with Puppet? > Why? How do you coordinate that?I don''t think I would be able to do my job in a 40 hour work week without puppet. The only drawback is the slight overheard of writing a module to configure something new. I use capistrano to deploy the corporate website, to deploy openbsd configurations, and to deploy puppet. I also have a Capfile that loads up its roles from the puppet stored config db so that I can run arbitrary commands across nodes of a particular type/class. This is better suites to mcollective however because of all the ssh threading problems with capistrano (it''s not very scalable.)> > ... yep, tons of things > > I know is generic stuff that is in part on the "Who is using Puppet" > page, but I want to see if I can get some more detailed approximation > of how do you live with Puppet as your system configuration management > tool, instead of the common "lets log in via SSH and do stuff" admin > model we all know by default. > > If you want to answer here for anybody to see, great, but I would > really like to get in touch with, say, 2 or 3 "advocates" that could > spend, say, 1 h or so, talking about how do they do their work with > Puppet, so if you want to help, please send me a mail at this address.Most people will charge for that sort of thing but if you go on IRC and just chat you might find yourself in a better position.> > Best regards, > > ------------------------------ > > Jesús Couto F. > -- > 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.-- Joe McDonagh AIM: YoosingYoonickz IRC: joe-mac on freenode L''ennui est contre-révolutionnaire -- 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 Mon, Feb 8, 2010 at 10:50 PM, Jesús Couto <jesus.couto@gmail.com> wrote:> So, I was kind of hoping if some sucessfull Puppet users on this list could > have some time to chat about how they are using Puppet. How are your > machines and services life-cycles managed - all with Puppet, from install to > decommision?The way I see it, you have 3 phases in a life cycle of a server 1. Pre Operation (e.g. DNS) and OS installation. 2. Initial configuration 3. Never ending story of patching, changing configuration etc. Puppet handle 2 and most of 3, with the exceptions of one time activities (e.g. reboot this server now). You may want to view a presentation which address this part here: http://www.slideshare.net/ohadlevy/a-presentation-about-puppet-that-ive-made-at-the-osspac-conference I''ve written an application, which aims to solve all of the missing peaces around puppet - http://theforeman.org How do you deal with dynamic changes or process (been a theme of discussion> lately here) and having Puppet enforcing a "state"?One time activities are usually not done via puppet, and most people use ssh for this kind of things. Puppet goal is to enforce a state, so that''s the default behavior.> Do you work always inside Puppet or some task have you "shut down" it till > you get it done correctly and then model it on Puppet? How many people work > with your Puppet configuration and how do you manage access - basically how > you use Puppet and distribute task to junior members or other teams or... >I currently have 31 people who have some sort of write access to the puppet manifests. nevertheless, a lot of the simple configuration changes, happen at the web interface level, reducing the risk that some one breaks something.> What kind of benefits have you got from using Puppet? What kind of > drawbacks? Have any taks you tried it and decided it was not suited? Are you > using tools like Capistrano/MCollective/Func/etc with Puppet? Why? How do > you coordinate that? > > I think that you need to be aware of what is the scope of puppet, what itcan do, and what it cant do, puppet will not fix all of your problems over night, but there is a good chance that by using it, you will get there sooner.> If you want to answer here for anybody to see, great, but I would really > like to get in touch with, say, 2 or 3 "advocates" that could spend, say, 1 > h or so, talking about how do they do their work with Puppet, so if you want > to help, please send me a mail at this address. >I guess IRC is the best place to hang around for this kind of discussions - or maybe attend the next puppet camp :) cheers, Ohad -- 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.
Thanks you both for the answers, I''m going to spend some time parsing them :-P Let me clarify - I''m not looking for help or consulting in implementing Puppet on a particular site right now. The objective of my work now is just to make the company aware this exist and see if it is something useful to have in our arsenal, so to say. So my request is not for somebody to help me migrate to Puppet - is to just have a chat (30 minutes or less) with somebody that is actually using it and get the feeling of the tool being used as part of your workflow, not just learning the syntax of the language and things like that. I''m suso on IRC so probably you will see me there pestering you :-P How do you deal with dynamic changes or process (been a theme of discussion>> lately here) and having Puppet enforcing a "state"? > > One time activities are usually not done via puppet, and most people use > ssh for this kind of things. > Puppet goal is to enforce a state, so that''s the default behavior. > >Yes, but with this kind of automation tools there is always the worry that whatever manual work you are doing now is going to be obliterated later or interfered during your work. So I guess if you have are a "Puppet shop", you have a different way to go about things that if you just have N servers around handconfigured and go SSH for everything. When you get a request or find the need to do a change, you try to see if its something to change on a manifest,or just a one time task to run in between puppetd runs, or to have an schedule defining a maintenance window, or... Do changes get to the "Puppet admins" first to check that? I guess having your infrastructure managed by Puppet makes you have to think more about what is that "state" that you are mantaining and what are the deviations for that state that can happen and how to manage them... -- ------------------------------ Jesús Couto F. -- 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.
> I''ve written an application, which aims to solve all of the missing peaces > around puppet - http://theforeman.orgOhad, as you''ve said "I''ve written an application, which aims to solve all of the missing peaces around puppet". Obviously you''ve done a lot of work here, but I need to communicate something from a community perspective -- the proper place to fix missing pieces in Puppet is by contributing to Puppet -- our vision is to have no such "missing pieces". Hence things done outside of core tend to fragment the userbase and make things harder to install/use/manage/maintain. The future of this workflow tool is going to be Puppet''s Dashboard. Where there are barriers to doing this, we will remove them. If folks have feature requests, please send them along, and let''s work on making Puppet core (and dashboard) strong so there are less external dependencies to manage -- so they can install all easily in the box, that we have linked bug tracking, linked releases, and a united community. That''s one of my goals over the coming year -- to make Puppet even easier to contribute to, and make it clear to folks how they may do so. External integrations are of course very important to us -- but the out of the box Puppet experience will be as complete as we can make it rather than fragmenting workarounds between various external tools. --Michael -- 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.
hello, ----- "Michael DeHaan" <michael@reductivelabs.com> wrote:> > I''ve written an application, which aims to solve all of the missing > peaces > > around puppet - http://theforeman.org > > Ohad, as you''ve said "I''ve written an application, which aims to > solve all of the missing peaces around puppet". Obviously you''ve done a > lot of work here, but I need to communicate something from a > community perspective -- the proper place to fix missing pieces in Puppet is by > contributing to Puppet -- our vision is to have no such "missing > pieces". Hence things done outside of core tend to fragment the > userbase and make things harder to install/use/manage/maintain. The > future of this workflow tool is going to be Puppet''s Dashboard. > Where there are barriers to doing this, we will remove them.As a non affiliated community member who spend a lot of my time on Puppet I think this is a particularly unfriendly and in fact alarming statement for someone from RL to make. -- 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 Tue, Feb 9, 2010 at 9:39 AM, R.I.Pienaar <rip@devco.net> wrote:> hello, > > ----- "Michael DeHaan" <michael@reductivelabs.com> wrote: > > > > I''ve written an application, which aims to solve all of the missing > > peaces > > > around puppet - http://theforeman.org > > > > Ohad, as you''ve said "I''ve written an application, which aims to > > solve all of the missing peaces around puppet". Obviously you''ve done a > > lot of work here, but I need to communicate something from a > > community perspective -- the proper place to fix missing pieces in Puppet > is by > > contributing to Puppet -- our vision is to have no such "missing > > pieces". Hence things done outside of core tend to fragment the > > userbase and make things harder to install/use/manage/maintain. The > > future of this workflow tool is going to be Puppet''s Dashboard. > > Where there are barriers to doing this, we will remove them. > > As a non affiliated community member who spend a lot of my time on Puppet I > think this is a particularly unfriendly and in fact alarming statement for > someone from RL to make. > >It also goes against what I saw as a rather wonderful development at Puppet Camp this year, namely puppet evolving to become a viable component of in-house software stacks. I understand the situation with Foreman and Puppet Dashboard is a little complicated, but it''s a good thing to have competition in the Puppet ecosystem. I''m not sure you communicated this "from a community perspective" at all Michael. -- nigel -- 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 9 February 2010 17:39, R.I.Pienaar <rip@devco.net> wrote:> hello, > > ----- "Michael DeHaan" <michael@reductivelabs.com> wrote: > >> > I''ve written an application, which aims to solve all of the missing >> peaces >> > around puppet - http://theforeman.org >> >> Ohad, as you''ve said "I''ve written an application, which aims to >> solve all of the missing peaces around puppet". Obviously you''ve done a >> lot of work here, but I need to communicate something from a >> community perspective -- the proper place to fix missing pieces in Puppet is by >> contributing to Puppet -- our vision is to have no such "missing >> pieces". Hence things done outside of core tend to fragment the >> userbase and make things harder to install/use/manage/maintain. The >> future of this workflow tool is going to be Puppet''s Dashboard. >> Where there are barriers to doing this, we will remove them. > > As a non affiliated community member who spend a lot of my time on Puppet I think this is a particularly unfriendly and in fact alarming statement for someone from RL to make. >I agree, I''m sure Michael didn''t mean to be offensive hear, but it comes off as arrogant. The community exists around puppet and there should be room for innovation within it. We want to encourage tool writing systems administration, not a centralized single company based environment. Obviously Reductive needs to make money and keep going but dismissing the work of active and contributing members of the community and stating it''s from "a community perspective" feels disingenuous. I personally don''t think it''s a good statement of the community perspective. Paul -- 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 Tue, Feb 9, 2010 at 12:39 PM, R.I.Pienaar <rip@devco.net> wrote:> hello, > > ----- "Michael DeHaan" <michael@reductivelabs.com> wrote: > >> > I''ve written an application, which aims to solve all of the missing >> peaces >> > around puppet - http://theforeman.org >> >> Ohad, as you''ve said "I''ve written an application, which aims to >> solve all of the missing peaces around puppet". Obviously you''ve done a >> lot of work here, but I need to communicate something from a >> community perspective -- the proper place to fix missing pieces in Puppet is by >> contributing to Puppet -- our vision is to have no such "missing >> pieces". Hence things done outside of core tend to fragment the >> userbase and make things harder to install/use/manage/maintain. The >> future of this workflow tool is going to be Puppet''s Dashboard. >> Where there are barriers to doing this, we will remove them. > > As a non affiliated community member who spend a lot of my time on Puppet I think this is a particularly unfriendly and in fact alarming statement for someone from RL to make.Not in the least; we welcome all contributions... and we want to encourage folks here to contribute to the core. The statement "this is broken, go use my tool" is less interesting than "let''s all come together and work and build better software". This is how OSS really works best ... joining together as one. If you take a look at my experience with Cobbler and Func, enabling external integration (see OpenSymbolic for a fine example) was something I am very much in favor of doing. However, I''m also very much interested in raising contributions to Puppet proper -- which we can do much better at. We do that by encouraging everyone to work together. We don''t do this by saying "Puppet is broke, go use this"... that is a mindset we need to shift. This is where OSS really shines. Right now we have about 80 or so committers to the core. For a project of this size, I''d like it to be much larger. This is one of the things we want to enable. We also want to make it clear that Dashboard is our future, and we welcome contributions there and will be better positioned to help keep that and Puppet working better in sync. --Michael -- 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 Tue, Feb 9, 2010 at 12:39 PM, R.I.Pienaar <rip@devco.net> wrote:> hello, > > ----- "Michael DeHaan" <michael@reductivelabs.com> wrote: > >> >> Ohad, as you''ve said "I''ve written an application, which aims to >> solve all of the missing peaces around puppet". Obviously you''ve done a >> lot of work here, but I need to communicate something from a >> community perspective -- the proper place to fix missing pieces in Puppet is by >> contributing to Puppet -- our vision is to have no such "missing >> pieces". Hence things done outside of core tend to fragment the >> userbase and make things harder to install/use/manage/maintain. The >> future of this workflow tool is going to be Puppet''s Dashboard. >> Where there are barriers to doing this, we will remove them. > > As a non affiliated community member who spend a lot of my time on Puppet I think this is a particularly unfriendly and in fact alarming statement for someone from RL to make.Soliciting contributions of code for improvements to an open source project isn''t what I''d classify as unfriendly and I''d expect RL people to take a leadership role when it comes to maintaining a solid foundation for the project. It is very difficult to infer tone from a mailing list posting, perhaps you''ve misread here? Or maybe I am but I''m willing to give Michael the benefit of the doubt. -- 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.
hello,> Not in the least; we welcome all contributions... and we want to > encourage folks here to contribute to the core.. .> We also want to make it clear that Dashboard is our future, and we > welcome contributions there and will be better positioned to help > keep that and Puppet working better in sync.I think you''re in desperate need of a history lesson in what happened in the cases where people tried to contribute or suggest improvements wrt dashboard. -- R.I.Pienaar -- 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 Tue, Feb 9, 2010 at 12:47 PM, Paul Nasrat <pnasrat@googlemail.com> wrote:> On 9 February 2010 17:39, R.I.Pienaar <rip@devco.net> wrote: >> hello, >> >> ----- "Michael DeHaan" <michael@reductivelabs.com> wrote: >> >>> > I''ve written an application, which aims to solve all of the missing >>> peaces >>> > around puppet - http://theforeman.org >>> >>> Ohad, as you''ve said "I''ve written an application, which aims to >>> solve all of the missing peaces around puppet". Obviously you''ve done a >>> lot of work here, but I need to communicate something from a >>> community perspective -- the proper place to fix missing pieces in Puppet is by >>> contributing to Puppet -- our vision is to have no such "missing >>> pieces". Hence things done outside of core tend to fragment the >>> userbase and make things harder to install/use/manage/maintain. The >>> future of this workflow tool is going to be Puppet''s Dashboard. >>> Where there are barriers to doing this, we will remove them. >> >> As a non affiliated community member who spend a lot of my time on Puppet I think this is a particularly unfriendly and in fact alarming statement for someone from RL to make. >> > > I agree, I''m sure Michael didn''t mean to be offensive hear, but it > comes off as arrogant. The community exists around puppet and there > should be room for innovation within it. We want to encourage tool > writing systems administration, not a centralized single company based > environment. Obviously Reductive needs to make money and keep going > but dismissing the work of active and contributing members of the > community and stating it''s from "a community perspective" feels > disingenuous. I personally don''t think it''s a good statement of the > community perspective. > > Paul >Paul -- I''m as community oriented as you''ll get. Moving forward, our efforts should be in contributing around one common tool that everyone in our community can contribute to. Unfortunately due to some IP issues we can''t do this around Foreman -- and /we/ can''t contribute to it. Similarly, since we are looking at doing some very powerful and tightly coupled features in Dashboard, it is non-strategic to be avertising that users should be investing in Foreman. Features that go into Foreman are lost to Puppet... Rather than look at this as dismissive, I think we need to look at this as a chance to rally our efforts. Ohad is enormously helpful here and I don''t want to take away from his contributions. ---Michael -- 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.
> I think you''re in desperate need of a history lesson in what happened in the cases where people tried to contribute or suggest improvements wrt dashboard.If there is such a percieved lack of interest, this is something I would like to rectify. (Also don''t miscontrue an inability to implement RFEs with a lack of interest... the phrase "patches accepted" is often thrown around but exists for a reason, right?) That all being said, the past is just that. A seperate list for dashboard discussion and development probably makes sense so we can get this going in higher gear. While it mainly serves external nodes now, there are a lot of interesting places it can go -- and we would definitely like everyone''s ideas on that. --Michael -- 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 9 February 2010 17:53, Michael DeHaan <michael@reductivelabs.com> wrote:> On Tue, Feb 9, 2010 at 12:47 PM, Paul Nasrat <pnasrat@googlemail.com> wrote: >> On 9 February 2010 17:39, R.I.Pienaar <rip@devco.net> wrote: >>> hello, >>> >>> ----- "Michael DeHaan" <michael@reductivelabs.com> wrote: >>> >>>> > I''ve written an application, which aims to solve all of the missing >>>> peaces >>>> > around puppet - http://theforeman.org >>>> >>>> Ohad, as you''ve said "I''ve written an application, which aims to >>>> solve all of the missing peaces around puppet". Obviously you''ve done a >>>> lot of work here, but I need to communicate something from a >>>> community perspective -- the proper place to fix missing pieces in Puppet is by >>>> contributing to Puppet -- our vision is to have no such "missing >>>> pieces". Hence things done outside of core tend to fragment the >>>> userbase and make things harder to install/use/manage/maintain. The >>>> future of this workflow tool is going to be Puppet''s Dashboard. >>>> Where there are barriers to doing this, we will remove them. >>> >>> As a non affiliated community member who spend a lot of my time on Puppet I think this is a particularly unfriendly and in fact alarming statement for someone from RL to make. >>> >> >> I agree, I''m sure Michael didn''t mean to be offensive hear, but it >> comes off as arrogant. The community exists around puppet and there >> should be room for innovation within it. We want to encourage tool >> writing systems administration, not a centralized single company based >> environment. Obviously Reductive needs to make money and keep going >> but dismissing the work of active and contributing members of the >> community and stating it''s from "a community perspective" feels >> disingenuous. I personally don''t think it''s a good statement of the >> community perspective. >> >> Paul >> > > Paul -- I''m as community oriented as you''ll get.Show don''t tell, I''m aware of your work on other projects. But being part of the community around puppet is earned not transitioned with a role. Whilst I think you''re background and skills make you> Moving forward, our efforts should be in contributing around one > common tool that everyone in our community can contribute to.So you don''t believe an ecosystem of tools can exist around puppet and facter? You believe that one solution fits all? This really is coming across in a light I don''t think you intend.> Unfortunately due to some IP issues we can''t do this around Foreman -- > and /we/ can''t contribute to it.I''m aware of that. What I''m objecting to is a myopic vision that there can''t be an ecosystem. Paul -- 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 Tue, Feb 9, 2010 at 1:04 PM, Paul Nasrat <pnasrat@googlemail.com> wrote:> On 9 February 2010 17:53, Michael DeHaan <michael@reductivelabs.com> wrote: >> On Tue, Feb 9, 2010 at 12:47 PM, Paul Nasrat <pnasrat@googlemail.com> wrote: >>> On 9 February 2010 17:39, R.I.Pienaar <rip@devco.net> wrote: >>>> hello, >>>> >>>> ----- "Michael DeHaan" <michael@reductivelabs.com> wrote: >>>> >>>>> > I''ve written an application, which aims to solve all of the missing >>>>> peaces >>>>> > around puppet - http://theforeman.org >>>>> >>>>> Ohad, as you''ve said "I''ve written an application, which aims to >>>>> solve all of the missing peaces around puppet". Obviously you''ve done a >>>>> lot of work here, but I need to communicate something from a >>>>> community perspective -- the proper place to fix missing pieces in Puppet is by >>>>> contributing to Puppet -- our vision is to have no such "missing >>>>> pieces". Hence things done outside of core tend to fragment the >>>>> userbase and make things harder to install/use/manage/maintain. The >>>>> future of this workflow tool is going to be Puppet''s Dashboard. >>>>> Where there are barriers to doing this, we will remove them. >>>> >>>> As a non affiliated community member who spend a lot of my time on Puppet I think this is a particularly unfriendly and in fact alarming statement for someone from RL to make. >>>> >>> >>> I agree, I''m sure Michael didn''t mean to be offensive hear, but it >>> comes off as arrogant. The community exists around puppet and there >>> should be room for innovation within it. We want to encourage tool >>> writing systems administration, not a centralized single company based >>> environment. Obviously Reductive needs to make money and keep going >>> but dismissing the work of active and contributing members of the >>> community and stating it''s from "a community perspective" feels >>> disingenuous. I personally don''t think it''s a good statement of the >>> community perspective. >>> >>> Paul >>> >> >> Paul -- I''m as community oriented as you''ll get. > > Show don''t tell, I''m aware of your work on other projects. But being > part of the community around puppet is earned not transitioned with a > role. Whilst I think you''re background and skills make you > >> Moving forward, our efforts should be in contributing around one >> common tool that everyone in our community can contribute to. > > So you don''t believe an ecosystem of tools can exist around puppet and > facter? You believe that one solution fits all? > > This really is coming across in a light I don''t think you intend.Sounds like it. So imagine my intent.> >> Unfortunately due to some IP issues we can''t do this around Foreman -- >> and /we/ can''t contribute to it. > > I''m aware of that. What I''m objecting to is a myopic vision that there > can''t be an ecosystem. > > PaulThere can and must be an ecosystem. We want to encourage as many integration points and projects as possible. -- 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.
R.I.Pienaar wrote:> hello, > > ----- "Michael DeHaan" <michael@reductivelabs.com> wrote: > > >>> I''ve written an application, which aims to solve all of the missing >>> >> peaces >> >>> around puppet - http://theforeman.org >>> >> Ohad, as you''ve said "I''ve written an application, which aims to >> solve all of the missing peaces around puppet". Obviously you''ve done a >> lot of work here, but I need to communicate something from a >> community perspective -- the proper place to fix missing pieces in Puppet is by >> contributing to Puppet -- our vision is to have no such "missing >> pieces". Hence things done outside of core tend to fragment the >> userbase and make things harder to install/use/manage/maintain. The >> future of this workflow tool is going to be Puppet''s Dashboard. >> Where there are barriers to doing this, we will remove them. >> > > As a non affiliated community member who spend a lot of my time on Puppet I think this is a particularly unfriendly and in fact alarming statement for someone from RL to make. > >Though I have nowhere near the contributor-status that Nigel or R.I have, I basically agree with Michael here. Foreman is a great tool in wide-use as I understand it, but I''m not sure the best action for the future of both Foreman AND puppet is to continue development on two separate tracks. This could have possibly been better elucidated by Michael, but I don''t think many of us are experts in communications. Let''s not forget that Luke''s original vision was to create a tool to bring us all together (hopefully that didn''t sound too hippie like) because there was such a huge amount of fragmentation in the infrastructure management community. -- Joe McDonagh AIM: YoosingYoonickz IRC: joe-mac on freenode L''ennui est contre-révolutionnaire -- 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 Feb 9, 2010, at 9:25 AM, Michael DeHaan wrote:>> I''ve written an application, which aims to solve all of the missing >> peaces >> around puppet - http://theforeman.org > > Ohad, as you''ve said "I''ve written an application, which aims to solve > all of the missing peaces around puppet". Obviously you''ve done a > lot of work here, but I need to communicate something from a community > perspective -- the proper place to fix missing pieces in Puppet is by > contributing to Puppet -- our vision is to have no such "missing > pieces". Hence things done outside of core tend to fragment the > userbase and make things harder to install/use/manage/maintain. The > future of this workflow tool is going to be Puppet''s Dashboard. > Where there are barriers to doing this, we will remove them. > > If folks have feature requests, please send them along, and let''s work > on making Puppet core (and dashboard) strong so there are less > external dependencies to manage -- so they can install all easily in > the box, that we have linked bug tracking, linked releases, and a > united community.Just to clarify this a bit: Puppet never has been and never will be a complete solution, and it will always require other tools. There are areas that Puppet should do but doesn''t, and we intend to expand it in those areas, but in general, our goal is to make Puppet a focused tool with a specific purview. I don''t believe there can ever be a single tool that fills all of the gaps, but clearly at least one person disagrees. When it comes to those other tools, some of them are things that we''ve been promising to implement for ages, and now that we have the resources we''re finally working on them. You can go back to 2006 and find threads, started by me, about creating external node tools (e.g., nodify), and I added general support for them so anyone could create and use one. However, I always maintained that I''d be building one at the company, and I''ve discussed the conceptual tools with lots of people, including Ohad, individually. Probably my biggest disappointment in the last few years is that I didn''t have the bandwidth to develop the tools around Puppet that I wanted to create and discussed at such length, such as a node tool (of which there are many, including iClassify (abandoned), Foreman, and our Dashboard) and a message bus (of which mcollective is a good example). Even in discussing those, I always wanted our tools to stand on their own. If our node tool isn''t the best node tool for you, then don''t use it - find something better, and we''ll try to catch you on the next upgrade. If Puppet isn''t the best config mgmt tool but our node tool is, then hey, that''s great, too. So, having tools like Foreman is great, especially since Ohad is spending so much time maintaining it, and his development mentality really gels well with a lot of other sysadmins. However, it''s quite a stretch to say that any tool solves all of the missing pieces around Puppet. There are lots of things I want our dashboard to do that neither it nor Foreman does, and there are things Foreman does that I wouldn''t recommend to my customers. Foreman is a great tool for some set of people, and it''s a great example of the power of an open ecosystem. I *never* want to shut that ecosystem down, and in fact, we''re moving as quickly and thoroughly as possible to a *more* open ecosystem. As Michael said, there are also IP issues with our relying on Foreman. There is a significant difference between a lone developer producing an open source project and a commercial enterprise making promises to customers about a project. One of the big drivers for my creation of Puppet is that I found I couldn''t keep promises I made to customers because my goals didn''t mesh with the goals of Cfengine''s maintainer. Since the day I started Puppet, I have had a commercial company backing it and funding its development. It''s been my full time job since March of 2005, and one of my prerequisites for it has always been that I be able to make and keep promises to customers. The problem with Foreman, for us, is that its IP is in a sufficient state for Ohad''s purposes but not for ours. That doesn''t by any means invalidate Ohad''s effort, it just means that we can''t build a business on it. We''re planning on producing commercial extensions to our Dashboard, which requires very clear IP control, at least for GPL''d software, but more importantly for me, I don''t think it''s a wise business decision for my company to base its future plans on a tool that someone else controls. Beyond the IP issues, though, there are just plain differences in what we want to build. It''s quite possible that Ohad''s vision of what this tool should look like is more correct than my own, but I''m here to build my own vision. I have a clear idea of what our dashboard should look like, and that''s what I intend to build, because I think that''s where the greatest opportunity is. The differences between the tools is healthy and gives us both the opportunity to steal ideas from each other, which is healthy and good for everyone. Our telling Ohad not to work on Foreman would be just as bad as the community telling us not to produce the Dashboard - there''s not only room for competition, it''s very good.> That''s one of my goals over the coming year -- to make Puppet even > easier to contribute to, and make it clear to folks how they may do > so. > > External integrations are of course very important to us -- but the > out of the box Puppet experience will be as complete as we can make it > rather than fragmenting workarounds between various external tools.This is a bit of a conflation - the Dashboard will be part of the out of the box Puppet experience for our customers, but it won''t be part of everyone''s ecosystem. Obviously, for us to provide the best story to our customers and users, we''re going to do what we can to do as much as possible as cleanly and consistently as possible, but doing so will never preclude anyone else telling the story their way, and each individual piece - Puppet, Facter, Dashboard, and everything else -- will always be stand-alone entities. -- You can''t wait for inspiration. You have to go after it with a club. -- Jack London --------------------------------------------------------------------- Luke Kanies -|- http://reductivelabs.com -|- +1(615)594-8199 -- 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 2/9/10 9:57 AM, Michael DeHaan wrote:> If there is such a percieved lack of interest, this is something I would like to rectify. (Also > don''t miscontrue an inability to implement RFEs with a lack of interest... the phrase "patches > accepted" is often thrown around but exists for a reason, right?) >I have submitted a pull request for a feature, and have at least two tickets to the dashboard''s redmine project. Currently there are something like 8 open bugs, none of which have even been reviewed. :(> That all being said, the past is just that. A seperate list for dashboard discussion and > development probably makes sense so we can get this going in higher gear. >OK by me, if the demand is there. Although given the volume of traffic in Redmine for it, I don''t know that there is just yet...? Have no idea how many people use it.> While it mainly serves external nodes now, there are a lot of interesting places it can go -- and > we would definitely like everyone''s ideas on that. > > --Michael >...so in the mean time I have forked the project on Github and fix what I can. I''ve added a handful of Rake tasks to add/modify nodes, prune reports, etc. Very useful stuff if you''re maintaining a decent number of hosts, IMO! (I currently have ~400, but that will grow by 10x or more in a couple months.) BTW, I''m working on setting up partitions for the reports table to make it way more scalable (doing a select * on 30k rows just sucks, and I plan to have ~7M at any given time). Also will be changing the schema to add indexes where necessary. So right now if anyone wants to use my fixes/changes they have to clone my repo. Bummer! -scott -- 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.