Hi Experts, I define two classes, each of them has the same service defined in it, if I include both classes for a node it will fail complaining "Duplicated definition: Service[xxx]". Just wondering is there a way to work around this? Thank you ! -Yushu -- 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.
Richard Crowley
2010-Nov-15 23:22 UTC
Re: [Puppet Users] Same Service in Different Classes
> I define two classes, each of them has the same service defined in it, if I > include both classes for a node it will fail complaining "Duplicated > definition: Service[xxx]". > > Just wondering is there a way to work around this?Define the service in a third class and include that third class in each of the first two. class a { include c } class b { include c } class c { service { "foobar": } } Classes can be included multiple times without trying to create duplicates of the resources they contain. Richard -- 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, Nov 15, 2010 at 3:08 PM, Yushu Yao <yyao@lbl.gov> wrote:> Hi Experts, > > I define two classes, each of them has the same service defined in it, if I > include both classes for a node it will fail complaining "Duplicated > definition: Service[xxx]".Why do both classes need to have the same service defined?> > Just wondering is there a way to work around this? > > Thank you ! > > -Yushu > > > -- > 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. >-- Nigel Kersten - Puppet Labs - http://www.puppetlabs.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.
> Why do both classes need to have the same service defined? > > Simple use case:Want to define two apache based web services on the same server. (e.g. passenger + turbogears) I think module-based definitions are the key concept behind puppet (no?), so we use one module for turbogears, another module for passenger. They both need to have control over the Service["httpd"] What is the best way to implement this? -Yushu> > > > > Just wondering is there a way to work around this? > > > > Thank you ! > > > > -Yushu > > > > > > -- > > 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<puppet-users%2Bunsubscribe@googlegroups.com> > . > > For more options, visit this group at > > http://groups.google.com/group/puppet-users?hl=en. > > > > > > -- > Nigel Kersten - Puppet Labs - http://www.puppetlabs.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<puppet-users%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > >-- 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.
> > Just wondering is there a way to work around this? > > Define the service in a third class and include that third class in > each of the first two. > > class a { > include c > } > class b { > include c > } > class c { > service { "foobar": } > } > > Classes can be included multiple times without trying to create > duplicates of the resources they contain. >What if class a and class b are in two different modules that are developed by different developer? They will not necessarily know where class c is. Thanks -Yushu> > Richard > > -- > 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<puppet-users%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > >-- 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, Nov 15, 2010 at 9:16 PM, Yushu Yao <yyao@lbl.gov> wrote:> > > >> >> Why do both classes need to have the same service defined? >> > Simple use case: > > Want to define two apache based web services on the same server. (e.g. > passenger + turbogears) > > I think module-based definitions are the key concept behind puppet (no?), so > we use one module for turbogears, another module for passenger. > > They both need to have control over the Service["httpd"]You should have an apache/httpd module for the webserver itself. It will contain the Service definition. Then your modules for turbogears and passenger should only need to notify Service["httpd"], not actually define the service again.> > What is the best way to implement this? > > -Yushu > > > >> >> > >> > Just wondering is there a way to work around this? >> > >> > Thank you ! >> > >> > -Yushu >> > >> > >> > -- >> > 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. >> > >> >> >> >> -- >> Nigel Kersten - Puppet Labs - http://www.puppetlabs.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. >> > > -- > 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. >-- Nigel Kersten - Puppet Labs - http://www.puppetlabs.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.
Yushu Yao <yyao@lbl.gov> writes:>> > Just wondering is there a way to work around this? >> >> Define the service in a third class and include that third class in each of >> the first two. >> >> class a { include c } class b { include c } class c { service { >> "foobar": } } >> >> Classes can be included multiple times without trying to create duplicates >> of the resources they contain. > > What if class a and class b are in two different modules that are developed > by different developer? They will not necessarily know where class c is.We use the puppetdoc tools to help with that communication: http://projects.puppetlabs.com/projects/1/wiki/Puppet_Manifest_Documentation That makes it easier for your two developers to see the existence of class c and all. (Good naming makes it easier, of course. :) Otherwise, we use code review before committing to the central repository to help reduce the risk of issues - now *two* operations people need to be ignorant of class C for the issue to pop up. If that also fails we eventually live with the risk: when the manifest deploys with the duplication service definition we get a failure report because of it. Then we identify which manifest (A or B) is wrong, fix it to use manifest C, and go on from there. While that failure is in place we can''t make operational changes to the machine using the combination of bad classes, but that isn''t too much of a problem. Historically we would have been worse off because B would have broken A without any warning. ;) Daniel -- ✣ Daniel Pittman ✉ daniel@rimspace.net ☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons -- 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 Nov 15, 2010, at 9:53 PM, Daniel Pittman wrote:> Otherwise, we use code review before committing to the central repository to > help reduce the risk of issues - now *two* operations people need to be > ignorant of class C for the issue to pop up.Hi Daniel - it''s a bit off-topic from the original question but would you mind explaining how your code review works in more detail? I''m curious about both the technology and people process involved. To me, supporting many authors is one of the most difficult problems scaling puppet. It''s really hard to strike a balance between, on one hand, safeguarding the stability of production puppet config and, on the other hand, enabling people to get work done without a big, slow, complicated process. - 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 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.
Eric Sorenson <eric.sorenson@me.com> writes:> On Nov 15, 2010, at 9:53 PM, Daniel Pittman wrote: > >> Otherwise, we use code review before committing to the central repository >> to help reduce the risk of issues - now *two* operations people need to be >> ignorant of class C for the issue to pop up. > > Hi Daniel - it''s a bit off-topic from the original question but would you > mind explaining how your code review works in more detail? I''m curious > about both the technology and people process involved.Ah. Um, pretty light-weight: we all work within about ten feet of each other, so the process is simple and "social" rather than technical: We use Subversion as our central repository. When someone is ready to commit we grab another member of the team and ask them to review the code. If that brings up issues that need to be addressed then they get reworked and someone else (often the same reviewed) does another review. We do have a ''testing-modules'' path and use multiple environments so that we can have code in "testing" on live systems without having to do it all offline. Anyway, once something is committed to that SVN repo it pushes on up to the central service and rolls out to production. No further review is needed. However, since the *only* way to get code into production[1] we have the absolute knowledge that every change made to the puppet code has the user id attached to it. So, if someone skips out on review and commits something we can know who it was, and fix the problem, whatever that is, that meant they didn''t follow process.> To me, supporting many authors is one of the most difficult problems scaling > puppet. It''s really hard to strike a balance between, on one hand, > safeguarding the stability of production puppet config and, on the other > hand, enabling people to get work done without a big, slow, complicated > process.Yup. That works for us because we have a small, collocated team in the same time zone. If I had to scale that to multiple sites and especially multiple time zones I would do it a bit differently: At the moment we use the honour system to manage code review; in a larger scale system I would require that the commit message document the reviewer and use a repository hook to verify that.[2] (If necessary I would also put a smaller team of folks between the production checkout and the place that anyone can check in, and use them to vet changes, but that adds a huge amount of cost.) Once you have the social control of your team knowing, without a shadow of a doubt, that if something they commit to puppet will be identified back to them, most of the problems go away. People generally want to play nice, and knowing they will be caught if they cowboy things and it blows up stops most of the abuses. We still get the occasional problem, but they are pretty self-correcting. Finally, if you really want to get scary-big I would reach out for the tools that support good development practices: something like Gerrit, plus some sort of CI toolchain[3], so that changes get a real review and approval history. Daniel Footnotes: [1] Technically someone could directly edit the files on the puppetmaster, but that usually breaks the next "proper" commit and our audit logs show who accessed the system and all. [2] Check it has a userid, check that userid is known to the system, check they are in the list of approved reviews. (...and this can scale up, later, to allow reviewers to "own" part of the puppet codebase.) [3] ...at least for syntax checking on Puppet manifests and ERB files. -- ✣ Daniel Pittman ✉ daniel@rimspace.net ☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons -- 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, Nov 15, 2010 at 10:00 PM, Eric Sorenson <eric.sorenson@me.com> wrote:> > On Nov 15, 2010, at 9:53 PM, Daniel Pittman wrote: > > Otherwise, we use code review before committing to the central repository to > help reduce the risk of issues - now *two* operations people need to be > ignorant of class C for the issue to pop up. > > Hi Daniel - it''s a bit off-topic from the original question but would you > mind explaining how your code review works in more detail? I''m curious > about both the technology and people process involved. To me, supporting > many authors is one of the most difficult problems scaling puppet. It''s > really hard to strike a balance between, on one hand, safeguarding the > stability of production puppet config and, on the other hand, enabling > people to get work done without a big, slow, complicated process.After spending a couple of years working on this in my last job, I came to the conclusion that you need a rich library of pre-commit hooks to stop code review being slow and manual. If you automate away all the minor niggles like whether a manifest actually parses or not, people get to actually review code at an interesting level, which means they''ll do it faster, and they have less to check for. We set up some tooling that also made checking commits easier, where you could launch ad hoc puppetmasters out of your VCS repository and set them to serve code other people had sent out for review. This made a big difference. It meant that if someone sent out a commit that was meant to achieve certain functionality, other people on the team could actually test that it did what it was meant to do. As Daniel said, once you''ve set things up so that all code changes can be traced back to a reviewer and an author, a lot of problems will simply go away, as people will do the right thing. You only need to get named and shamed in a couple of service outage postmortems for behavior to change :)> > - 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 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. >-- Nigel Kersten - Puppet Labs - http://www.puppetlabs.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.