Hi, what plans are in place to deal with bug #8040: http://projects.puppetlabs.com/issues/8040 I have some Puppet experience but I''m also looking at Chef and Ansible right now in order to determine which configuration management to commit to and being able to build and re-use components is a major issue. Right now this bug seems to make it almost impossible to build non-trivial components and the workaround mentioned isn''t really useful as a) it means you have to lace each and every class with dependencies just to anchor them to their parents an b) you will not be able to use components from e.g. puppet-forge because they will most likely miss this anchoring as well. So what is the story here? Is this being worked on in some concrete way or is re-usability not something that is considered important in the Puppet ecosystem? Regards, Dennis -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
On 2013-06-05 18:57, Dennis Jacobfeuerborn wrote:> Hi, > what plans are in place to deal with bug #8040: > http://projects.puppetlabs.com/issues/8040 > > I have some Puppet experience but I''m also looking at Chef and Ansible > right now in order to determine which configuration management to commit > to and being able to build and re-use components is a major issue. > Right now this bug seems to make it almost impossible to build > non-trivial components and the workaround mentioned isn''t really useful > as a) it means you have to lace each and every class with dependencies > just to anchor them to their parents an b) you will not be able to use > components from e.g. puppet-forge because they will most likely miss > this anchoring as well. > > So what is the story here? Is this being worked on in some concrete way > or is re-usability not something that is considered important in the > Puppet ecosystem?In my experience of systems with up to 70 modules, this is not a problem for re-usability. Regards, David -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Using anchors happens alot less than you think if you write minimal functionality into your subclasses. You don''t put anchors in subclasses to anchor them to the parents. You may need anchors in subclasses if they include other classes whose resources need to be ordered, but this really shouldn''t happen much and can usually be handled in the parent class as part of the main anchoring (i.e. put apache2 in foo instead of foo::web) While it''s true that many modules on the forge do not appropriately use anchoring, many of the most popular ones do and this situation improves constantly. On Wednesday, June 5, 2013 10:57:54 AM UTC-6, Dennis Jacobfeuerborn wrote:> > Hi, > what plans are in place to deal with bug #8040: > http://projects.puppetlabs.com/issues/8040 > > I have some Puppet experience but I''m also looking at Chef and Ansible > right now in order to determine which configuration management to commit to > and being able to build and re-use components is a major issue. > Right now this bug seems to make it almost impossible to build non-trivial > components and the workaround mentioned isn''t really useful as a) it means > you have to lace each and every class with dependencies just to anchor them > to their parents an b) you will not be able to use components from e.g. > puppet-forge because they will most likely miss this anchoring as well. > > So what is the story here? Is this being worked on in some concrete way or > is re-usability not something that is considered important in the Puppet > ecosystem? > > Regards, > Dennis >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
On Wednesday, June 5, 2013 11:57:54 AM UTC-5, Dennis Jacobfeuerborn wrote:> > Hi, > what plans are in place to deal with bug #8040: > http://projects.puppetlabs.com/issues/8040 > > I have some Puppet experience but I''m also looking at Chef and Ansible > right now in order to determine which configuration management to commit to > and being able to build and re-use components is a major issue. > Right now this bug seems to make it almost impossible to build non-trivial > components and the workaround mentioned isn''t really useful as a) it means > you have to lace each and every class with dependencies just to anchor them > to their parents an b) you will not be able to use components from e.g. > puppet-forge because they will most likely miss this anchoring as well. > > So what is the story here? Is this being worked on in some concrete way or > is re-usability not something that is considered important in the Puppet > ecosystem? > >It''s simply not the problem you seem to think it is. As a practical matter, there is a thriving ecosystem of reusable third-party modules, so experience shows that your concerns are ill-founded. Really, it''s outrageous that you attribute a technical problem to essentially every available community module, without actually demonstrating it in even a single one. To be sure, it is likely that a few available modules do suffer from containment problems -- bugs are a fact of life -- but there is no evidence of a pervasive problem. The few issues I am aware of in the area of inter-module compatibility are not related to issue 8040. And again, empirical evidence demonstrates that these are not actual blockers for reusable modules. From a technical perspective, 1. One does not need any particular relative ordering between most pairs of classes, and the cases where you do need it are more often between classes of the same module (where you can assume that the author will set up relationships as needed) than between classes of different modules (where considerations of modularity may preclude declaring relationships that would work around the containment issue by means other than anchors). 2. Classes already do fully contain all the resources that they declare directly. Issue 8040 relates only to the situation wherein classes assign *other classes* to the target node. 3. It is by no means always the case that when one class assigns another to the target node, the latter should be considered logically contained in the former. Indeed, there are many common cases where the latter class *most not* be contained in the former. There are other cases where containment is neither needful nor harmful. Places where containment is actually needed are comparatively rare. 4. When you do want classes to be logically contained in other classes, that is achieved strictly by declarations in the container class, not in the contained ones, so it is not particularly difficult or intrusive to implement. 5. The anchor pattern is simple, addresses the issue well, and is fairly well known, so it is unreasonable to suppose that the norm is for community modules to fail to apply it where needed. 6. In fact, because a resource of any type can serve as an anchor, anchoring occasionally even falls out naturally from the structure of a container class. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
On 06/05/2013 06:57 PM, Dennis Jacobfeuerborn wrote:> Hi, > what plans are in place to deal with bug #8040: > http://projects.puppetlabs.com/issues/8040I don''t know why this seems so much of a problem for you. Managing ~200 nodes, some of wich are quite complex beasts and I haven''t run into this issue yet... -- Jakov Sosic www.srce.unizg.hr -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
I can say I have over 12,000 nodes managed with puppet and have not had any issues with this bug. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.