I''ve been trying to wrap my head around ENCs. Kelsey Hightower gave me some very useful info in IRC the other day, but there are still some things I can''t quite get my head around. From what I can tell, an ENC allows you to assign classes and parameters (top scope variables) to a given node or group of nodes. They cannot declare/define relationships (chain classes together to order them) or declare individual resources. The purpose is to help separate data and configuration. From reading what documentation I could find on the puppet site (some of which is potentially inaccurate / outdated from the wiki), the only way to get around these limits is to build your modules, then define a series of wrapper classes and super classes and assign these to the nodes. We''ve got 2 dozen or so systems that we manage with puppet, and so far have done it all just using node defs. What benefits would there be in using an ENC, from an admin side of things? Is it something that would be worth my time in setting up? I''m trying to understand this, and my long term goal is to maximize the benefit we get from puppet. Thanks. Lee -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/Lr4lgnpVWcwJ. 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 Thursday, July 12, 2012 8:27:16 AM UTC-5, llo...@oreillyauto.com wrote:> > I''ve been trying to wrap my head around ENCs. > > Kelsey Hightower gave me some very useful info in IRC the other day, but > there are still some things I can''t quite get my head around. > > From what I can tell, an ENC allows you to assign classes and parameters > (top scope variables) to a given node or group of nodes. > > They cannot declare/define relationships (chain classes together to order > them) or declare individual resources. > > The purpose is to help separate data and configuration. > > From reading what documentation I could find on the puppet site (some of > which is potentially inaccurate / outdated from the wiki), the only way to > get around these limits is to build your modules, then define a series of > wrapper classes and super classes and assign these to the nodes. > > We''ve got 2 dozen or so systems that we manage with puppet, and so far > have done it all just using node defs. > > What benefits would there be in using an ENC, from an admin side of > things? Is it something that would be worth my time in setting up? > > I''m trying to understand this, and my long term goal is to maximize the > benefit we get from puppet. >If your node definitions contain only class and maybe variable declarations -- a good practice -- then you would not have much trouble doing the same thing with an ENC. With that said, I don''t think there are very many sites that would benefit from *writing their own* ENCs. If you are using Foreman or the Puppet Dashboard, however, then you already have an ENC available to you, with a spiffy UI and everything. Overall, as long as you''re satisfied with writing node definitions in Puppet DSL, I don''t think it''s worth the time and effort to change. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/Yg9jlmWjkEkJ. 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 Jul 12, 2012, at 2:42 PM, jcbollinger wrote:> > > On Thursday, July 12, 2012 8:27:16 AM UTC-5, llo...@oreillyauto.com wrote: > I''ve been trying to wrap my head around ENCs. > > Kelsey Hightower gave me some very useful info in IRC the other day, but there are still some things I can''t quite get my head around. > > From what I can tell, an ENC allows you to assign classes and parameters (top scope variables) to a given node or group of nodes. > > They cannot declare/define relationships (chain classes together to order them) or declare individual resources. > > The purpose is to help separate data and configuration. > > From reading what documentation I could find on the puppet site (some of which is potentially inaccurate / outdated from the wiki), the only way to get around these limits is to build your modules, then define a series of wrapper classes and super classes and assign these to the nodes. > > We''ve got 2 dozen or so systems that we manage with puppet, and so far have done it all just using node defs. > > What benefits would there be in using an ENC, from an admin side of things? Is it something that would be worth my time in setting up? > > I''m trying to understand this, and my long term goal is to maximize the benefit we get from puppet. > > If your node definitions contain only class and maybe variable declarations -- a good practice -- then you would not have much trouble doing the same thing with an ENC. With that said, I don''t think there are very many sites that would benefit from writing their own ENCs. If you are using Foreman or the Puppet Dashboard, however, then you already have an ENC available to you, with a spiffy UI and everything. > > Overall, as long as you''re satisfied with writing node definitions in Puppet DSL, I don''t think it''s worth the time and effort to change.---- Just to further this discussion, I would recommend that the OP take a good look at Foreman since it not only provides an funcational ENC but also provides a listing of puppet classes that can be observed/inspected (another thread). There are a few instances where I have found Foreman''s ENC useful to designate a top scoped variable on specific nodes which is then deduced by manifests to provide alternate configurations, create ''hostgroups'' of grouping of classes so I can assign a node to a hostgroup to configure the node and also note that these ''hostgroups'' are nestable. Lastly, the WebUI of Foreman provides the opportunity for others to participate in the configuration of specific nodes (or at least view the configuration). Craig -- 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 Thursday, July 12, 2012 4:42:12 PM UTC-5, jcbollinger wrote:> > > > On Thursday, July 12, 2012 8:27:16 AM UTC-5, llo...@oreillyauto.com wrote: >> >> I''ve been trying to wrap my head around ENCs. >> >> Kelsey Hightower gave me some very useful info in IRC the other day, but >> there are still some things I can''t quite get my head around. >> >> From what I can tell, an ENC allows you to assign classes and parameters >> (top scope variables) to a given node or group of nodes. >> >> They cannot declare/define relationships (chain classes together to order >> them) or declare individual resources. >> >> The purpose is to help separate data and configuration. >> >> From reading what documentation I could find on the puppet site (some of >> which is potentially inaccurate / outdated from the wiki), the only way to >> get around these limits is to build your modules, then define a series of >> wrapper classes and super classes and assign these to the nodes. >> >> We''ve got 2 dozen or so systems that we manage with puppet, and so far >> have done it all just using node defs. >> >> What benefits would there be in using an ENC, from an admin side of >> things? Is it something that would be worth my time in setting up? >> >> I''m trying to understand this, and my long term goal is to maximize the >> benefit we get from puppet. >> > > If your node definitions contain only class and maybe variable > declarations -- a good practice -- then you would not have much trouble > doing the same thing with an ENC. With that said, I don''t think there are > very many sites that would benefit from *writing their own* ENCs. If you > are using Foreman or the Puppet Dashboard, however, then you already have > an ENC available to you, with a spiffy UI and everything. > > Overall, as long as you''re satisfied with writing node definitions in > Puppet DSL, I don''t think it''s worth the time and effort to change. > >Our node defs are mostly classes and variables, but they also do some ordering using chaining syntax, because, for an web app server, for example, you need to make sure that Java is installed before Tomcat. We don''t currently make use of Stages, and while I see their benefit, I don''t know that we need them with how we are using puppet currently. I''m not sure that we need an ENC either, as using the node defs is working well for us, and we typically only have one person working on a given module or node at any given time, but I want to maximize the benefit we get from puppet while making it easy to maintain and, as needed, reuse bits and pieces.> > John > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/Iw2AYnjcc6EJ. 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 Thursday, July 12, 2012 4:59:51 PM UTC-5, llo...@oreillyauto.com wrote:> > > Our node defs are mostly classes and variables, but they also do some > ordering using chaining syntax, because, for an web app server, for > example, you need to make sure that Java is installed before Tomcat. >I''d generally recommend that you express dependencies directly in your resources or classes, rather than using the chain operators at a higher level. As much as possible, classes and especially modules should be self-contained. A need to express dependencies outside a module (e.g. in a node definition) constitutes a failure of encapsulation, and it makes your classes and modules harder to use.> > We don''t currently make use of Stages, and while I see their benefit, I > don''t know that we need them with how we are using puppet currently. >I don''t much care for stages, actually, and I don''t see much benefit to them myself, at least as they are currently implemented. There is nothing you can do with them that you cannot do with conventional resource relationships. At best they are syntactic sugar, but in practice they are prone to problems, such as creating dependency cycles and forcing parameterized class declaration syntax even on unparametrized classes. I''d recommend that you avoid them.> > I''m not sure that we need an ENC either, as using the node defs is working > well for us, and we typically only have one person working on a given > module or node at any given time, but I want to maximize the benefit we get > from puppet while making it easy to maintain and, as needed, reuse bits and > pieces. >It''s very unlikely that you need an ENC for an installation your size. You might nevertheless find Dashboard''s or Foreman''s ENC features convenient, especially as your site grows. I''m not using either at the moment myself, but I keep flirting with the idea of installing one or the other. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/_taXaw6yQzYJ. 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.