Jeff McCune
2010-Jul-29 17:48 UTC
[Puppet Users] Reconciling resource defaults, dynamic scope, and the singleton nature of classes
Hello, I''ve been thinking about how best to handle the situation where a single class is included multiple times from multiple classes who themselves set resource defaults. This situation poses an interesting problem in Puppet because of dynamic scoping rather than lexical scoping and appears to come up frequently as I travel and work with the puppet community. It''s also come up quite a bit in my own work and development of modules for the forge. I''m looking for feedback from the community as to how best to handle the unique situation in a maintainable and elegant manner. This is pretty long, but it''s a rather complex problem and fairly common in my experience, so thanks in advance for taking the time to read through if you do. I believe an use case will illustrate the point. Consider a module, perhaps publicly available in the Forge, which is extremely common and many other modules require. A good example is the configuration of the packaging system for the node to use a local repository. # /etc/puppet/modules/localpackagerepository/manifests/init.pp class localpackagerepository { $module = "localpackagerepository" file { "/etc/yum/yum.repos.d/local.repo": source => "puppet:///modules/${module}/local.repo"; } } Other classes will likely establish a relationship in the graph to this localpackagerepository class to ensure custom packages are available before trying to manage their state. For example: # /etc/puppet/modules/apache/manifests/init.pp class apache { $module = "apache" include localpackagerepository File { owner => "apache", group => "apache", require => Package["apache"], notify => Service["apache"], } ### package { "apache": ensure => installed, require => Class["localpackagerepository"]; } service { "apache": ensure => running } file { "/etc/httpd/httpd.conf": source => "puppet:///modules/${module}/apache.conf"; } } # /etc/puppet/modules/postfix/manifests/init.pp class postfix { $module = "postfix" include localpackagerepository File { owner => "mail", group => "mail", require => Package["postfix"], notify => Service["postfix"], } package { "postfix": ensure => installed, require => Class["localpackagerepository"]; } service { "postfix": ensure => running; } file { "/etc/postfix/main.cf": source => "puppet:///modules/${module}/main.cf"; } } Now, with these three modules we may include them in the node classification like so: include apache include postfix However, this will behave very differently than the classes included in a different order: include postfix include apache In the first ordering the localpackagerepository class will take on the resource defaults of the apache class, while in the second ordering the localpackagerepository class will take on the resource defaults of the postfix class. In both cases there will be a circular dependency (local.repo will require a package, and the package will require local.repo), which is clearly an issue. In either case, local.repo will take on defaults for owner and group which are invalid. How are you handling this situation? How do you think this situation *should* be handled by puppet? I can think of a number of work arounds, but they''re not ideal and they don''t feel to me like they''ll play well with public modules posted to the forge. I make the recommendation that classes should include the classes they depend on, but this appears to be problematic if the class doing the include sets resource defaults, particularity when setting a relationship in a default like require, before, subscribe and notify. This opens up the door for resource cycles. Perhaps it might be useful to set resource defaults only for the local scope, and not for any classes which get included into this scope. How do you feel about this change to the language? Is there some other organization of the class structure I''m overlooking? Thanks for your feedback, -- Jeff McCune 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.
R.I.Pienaar
2010-Jul-29 18:07 UTC
Re: [Puppet Users] Reconciling resource defaults, dynamic scope, and the singleton nature of classes
----- "Jeff McCune" <jeff@puppetlabs.com> wrote:> I make the recommendation that classes should include the classes > they depend on, but this appears to be problematic if the class doing the > include sets resource defaults, particularity when setting a > relationship in a default like require, before, subscribe and notify. > This opens up the door for resource cycles.recommendations are fine, but that is a lot of convention and best practice something that is very hard to pass on to new people, its hard to audit and its hard to predict. And ones established as a best practise that causes problems when ignored also lulls one into a false sense of safety. best avoided, it should do the right thing by default.> Perhaps it might be useful to set resource defaults only for the > local scope, and not for any classes which get included into this scope. > How do you feel about this change to the language?I''ve thought about this problem before and thought the fact that puppet did not behave in this way was a bug, so my vote is with this :) -- 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
2010-Jul-29 18:37 UTC
Re: [Puppet Users] Reconciling resource defaults, dynamic scope, and the singleton nature of classes
On Thu, Jul 29, 2010 at 10:48 AM, Jeff McCune <jeff@puppetlabs.com> wrote:> Perhaps it might be useful to set resource defaults only for the local > scope, and not for any classes which get included into this scope. > How do you feel about this change to the language?So this would mean that you''d only be able to set truly global resource defaults with an import in site.pp? and no longer inside a base class that includes all your other classes? We make use of the current behavior of defaults being applied to included classes quite a lot, and I find it useful just to provide a counterpoint to RIP :)> > Is there some other organization of the class structure I''m overlooking? > > Thanks for your feedback, > -- > Jeff McCune > 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. > >-- 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.
Jeff McCune
2010-Jul-29 18:45 UTC
Re: [Puppet Users] Reconciling resource defaults, dynamic scope, and the singleton nature of classes
On Thu, Jul 29, 2010 at 12:07 PM, R.I.Pienaar <rip@devco.net> wro>> ----- "Jeff McCune" <jeff@puppetlabs.com> wrote: > >> I make the recommendation that classes should include the classes >> they depend on, but this appears to be problematic if the class doing the >> include sets resource defaults, particularity when setting a >> relationship in a default like require, before, subscribe and notify. >> This opens up the door for resource cycles. > > recommendations are fine, but that is a lot of convention and best > practice something that is very hard to pass on to new people, its hard > to audit and its hard to predict. And ones established as a best practise > that causes problems when ignored also lulls one into a false sense of > safety.Agreed. As you mentioned this has been on my mind for quite a while now. The unpredictability of scope when a class is included multiple times has been pushed to front of my mind since it''s been such a common point of confusion when talking with many people, both new and experienced.> best avoided, it should do the right thing by default.Agreed. This begs the question; what is the "right thing" puppet should be doing by default?>> Perhaps it might be useful to set resource defaults only for the >> local scope, and not for any classes which get included into this scope. >> How do you feel about this change to the language? > > I''ve thought about this problem before and thought the fact that puppet > did not behave in this way was a bug, so my vote is with this :)Do you think resource defaults should default to the local scope if the default isn''t declared in the top or node scope? Perhaps it would be sufficient to prevent "include" from granting access to the local scope and instead limit scope to namespaces and class inheritance? I''m not too familiar with the code inside of puppet at this level, so it may be far more sensible to just introduce a "local" keyword to declare resource defaults in the local scope only, but I''m not sure this wouldn''t satisfy the "behave by default" goal we have. -- Jeff McCune 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.
Jeff McCune
2010-Jul-29 18:51 UTC
Re: [Puppet Users] Reconciling resource defaults, dynamic scope, and the singleton nature of classes
On Thu, Jul 29, 2010 at 12:37 PM, Nigel Kersten <nigelk@google.com> wrote:> On Thu, Jul 29, 2010 at 10:48 AM, Jeff McCune <jeff@puppetlabs.com> wrote: > >> Perhaps it might be useful to set resource defaults only for the local >> scope, and not for any classes which get included into this scope. >> How do you feel about this change to the language? > > So this would mean that you''d only be able to set truly global > resource defaults with an import in site.pp? and no longer inside a > base class that includes all your other classes? > > We make use of the current behavior of defaults being applied to > included classes quite a lot, and I find it useful just to provide a > counterpoint to RIP :)How do you "know" what the scope is of those included classes will end up as? Are you not including the "edge" classes multiple times? -- Jeff McCune 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.
Nigel Kersten
2010-Jul-29 18:58 UTC
Re: [Puppet Users] Reconciling resource defaults, dynamic scope, and the singleton nature of classes
On Thu, Jul 29, 2010 at 11:51 AM, Jeff McCune <jeff@puppetlabs.com> wrote:> On Thu, Jul 29, 2010 at 12:37 PM, Nigel Kersten <nigelk@google.com> wrote: >> On Thu, Jul 29, 2010 at 10:48 AM, Jeff McCune <jeff@puppetlabs.com> wrote: >> >>> Perhaps it might be useful to set resource defaults only for the local >>> scope, and not for any classes which get included into this scope. >>> How do you feel about this change to the language? >> >> So this would mean that you''d only be able to set truly global >> resource defaults with an import in site.pp? and no longer inside a >> base class that includes all your other classes? >> >> We make use of the current behavior of defaults being applied to >> included classes quite a lot, and I find it useful just to provide a >> counterpoint to RIP :) > > How do you "know" what the scope is of those included classes will end > up as? Are you not including the "edge" classes multiple times?Nope. That would be insane due to what sparked this thread off :) -- 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.
R.I.Pienaar
2010-Jul-29 19:11 UTC
Re: [Puppet Users] Reconciling resource defaults, dynamic scope, and the singleton nature of classes
----- "Jeff McCune" <jeff@puppetlabs.com> wrote:> On Thu, Jul 29, 2010 at 12:07 PM, R.I.Pienaar <rip@devco.net> wro> > > ----- "Jeff McCune" <jeff@puppetlabs.com> wrote: > > > >> I make the recommendation that classes should include the classes > >> they depend on, but this appears to be problematic if the class > doing the > >> include sets resource defaults, particularity when setting a > >> relationship in a default like require, before, subscribe and > notify. > >> This opens up the door for resource cycles. > > > > recommendations are fine, but that is a lot of convention and best > > practice something that is very hard to pass on to new people, its > hard > > to audit and its hard to predict. And ones established as a best > practise > > that causes problems when ignored also lulls one into a false sense > of > > safety. > > Agreed. As you mentioned this has been on my mind for quite a while > now. The unpredictability of scope when a class is included multiple > times has been pushed to front of my mind since it''s been such a > common point of confusion when talking with many people, both new and > experienced. > > > best avoided, it should do the right thing by default. > > Agreed. This begs the question; what is the "right thing" puppet > should be doing by default? > > >> Perhaps it might be useful to set resource defaults only for the > >> local scope, and not for any classes which get included into this > scope. > >> How do you feel about this change to the language? > > > > I''ve thought about this problem before and thought the fact that > puppet > > did not behave in this way was a bug, so my vote is with this :) > > Do you think resource defaults should default to the local scope if > the default isn''t declared in the top or node scope?I had not considered the global scope defaults, I dont use them cos I like the side effect of a manifest to be clear when looking at a single pp file. I''d only ever set a default that I expect to be localized to the class its in. but thats just me as Nigel points out :)> Perhaps it would be sufficient to prevent "include" from granting > access to the local scope and instead limit scope to namespaces and > class inheritance? > > I''m not too familiar with the code inside of puppet at this level, so > it may be far more sensible to just introduce a "local" keyword to > declare resource defaults in the local scope only, but I''m not sure > this wouldn''t satisfy the "behave by default" goal we have. >I guess so, it sounds all a bit magic really. If this doable then kewl, otherwise some new syntax for indicating global scoped defaults. -- 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
2010-Jul-29 19:22 UTC
Re: [Puppet Users] Reconciling resource defaults, dynamic scope, and the singleton nature of classes
On Thu, Jul 29, 2010 at 12:11 PM, R.I.Pienaar <rip@devco.net> wrote:> > ----- "Jeff McCune" <jeff@puppetlabs.com> wrote: > >> On Thu, Jul 29, 2010 at 12:07 PM, R.I.Pienaar <rip@devco.net> wro> >> > ----- "Jeff McCune" <jeff@puppetlabs.com> wrote: >> > >> >> I make the recommendation that classes should include the classes >> >> they depend on, but this appears to be problematic if the class >> doing the >> >> include sets resource defaults, particularity when setting a >> >> relationship in a default like require, before, subscribe and >> notify. >> >> This opens up the door for resource cycles. >> > >> > recommendations are fine, but that is a lot of convention and best >> > practice something that is very hard to pass on to new people, its >> hard >> > to audit and its hard to predict. And ones established as a best >> practise >> > that causes problems when ignored also lulls one into a false sense >> of >> > safety. >> >> Agreed. As you mentioned this has been on my mind for quite a while >> now. The unpredictability of scope when a class is included multiple >> times has been pushed to front of my mind since it''s been such a >> common point of confusion when talking with many people, both new and >> experienced. >> >> > best avoided, it should do the right thing by default. >> >> Agreed. This begs the question; what is the "right thing" puppet >> should be doing by default? >> >> >> Perhaps it might be useful to set resource defaults only for the >> >> local scope, and not for any classes which get included into this >> scope. >> >> How do you feel about this change to the language? >> > >> > I''ve thought about this problem before and thought the fact that >> puppet >> > did not behave in this way was a bug, so my vote is with this :) >> >> Do you think resource defaults should default to the local scope if >> the default isn''t declared in the top or node scope? > > I had not considered the global scope defaults, I dont use them cos I > like the side effect of a manifest to be clear when looking at a single > pp file. I''d only ever set a default that I expect to be localized > to the class its in. but thats just me as Nigel points out :)So we only do it for quite specific cases, turning off file backups and forcing application, ensuring our desired provider is explicit (we''ve had the odd issue where the automatic provider selection didn''t behave the way we wanted) and ensuring that our apt packages all require our "update-apt-stuff" class. File { force => true, backup => false, } Package { provider => "apt", require => Class["package::apt::update"] } We basically have provider defaults explicitly set as global resource defaults for package and service for each of our platforms. I have had the odd situation where I couldn''t use a resource default due to the scope inheritance, but that''s it. The vast majority of our defaults are either global, or in a class that doesn''t include any other classes. The latter case we do for readability and to reduce fat-fingering.> > >> Perhaps it would be sufficient to prevent "include" from granting >> access to the local scope and instead limit scope to namespaces and >> class inheritance? >> >> I''m not too familiar with the code inside of puppet at this level, so >> it may be far more sensible to just introduce a "local" keyword to >> declare resource defaults in the local scope only, but I''m not sure >> this wouldn''t satisfy the "behave by default" goal we have. >> > > I guess so, it sounds all a bit magic really. If this doable then kewl, > otherwise some new syntax for indicating global scoped defaults. > > -- > 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 -- 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
2010-Jul-29 19:28 UTC
Re: [Puppet Users] Reconciling resource defaults, dynamic scope, and the singleton nature of classes
----- "Nigel Kersten" <nigelk@google.com> wrote:> On Thu, Jul 29, 2010 at 12:11 PM, R.I.Pienaar <rip@devco.net> wrote: > > > > ----- "Jeff McCune" <jeff@puppetlabs.com> wrote: > > > >> On Thu, Jul 29, 2010 at 12:07 PM, R.I.Pienaar <rip@devco.net> wro> > >> > ----- "Jeff McCune" <jeff@puppetlabs.com> wrote: > >> > > >> >> I make the recommendation that classes should include the > classes > >> >> they depend on, but this appears to be problematic if the class > >> doing the > >> >> include sets resource defaults, particularity when setting a > >> >> relationship in a default like require, before, subscribe and > >> notify. > >> >> This opens up the door for resource cycles. > >> > > >> > recommendations are fine, but that is a lot of convention and > best > >> > practice something that is very hard to pass on to new people, > its > >> hard > >> > to audit and its hard to predict. And ones established as a > best > >> practise > >> > that causes problems when ignored also lulls one into a false > sense > >> of > >> > safety. > >> > >> Agreed. As you mentioned this has been on my mind for quite a > while > >> now. The unpredictability of scope when a class is included > multiple > >> times has been pushed to front of my mind since it''s been such a > >> common point of confusion when talking with many people, both new > and > >> experienced. > >> > >> > best avoided, it should do the right thing by default. > >> > >> Agreed. This begs the question; what is the "right thing" puppet > >> should be doing by default? > >> > >> >> Perhaps it might be useful to set resource defaults only for > the > >> >> local scope, and not for any classes which get included into > this > >> scope. > >> >> How do you feel about this change to the language? > >> > > >> > I''ve thought about this problem before and thought the fact that > >> puppet > >> > did not behave in this way was a bug, so my vote is with this :) > >> > >> Do you think resource defaults should default to the local scope > if > >> the default isn''t declared in the top or node scope? > > > > I had not considered the global scope defaults, I dont use them cos > I > > like the side effect of a manifest to be clear when looking at a > single > > pp file. I''d only ever set a default that I expect to be localized > > to the class its in. but thats just me as Nigel points out :) > > So we only do it for quite specific cases, turning off file backups > and forcing application, ensuring our desired provider is explicit > (we''ve had the odd issue where the automatic provider selection > didn''t > behave the way we wanted) and ensuring that our apt packages all > require our "update-apt-stuff" class. > > File { force => true, backup => false, }I think this should be a configuration option tbh - to disable backups, not force :)> Package { > provider => "apt", > require => Class["package::apt::update"] > } > > We basically have provider defaults explicitly set as global resource > defaults for package and service for each of our platforms.I''ve wrapped all my package access in a define that does this kind of thing among others, but it just means i can control all the specific behavior in one place and if i get a new site or new needs its one update. I do this with quite a lot of things, all about explicit behavior and not side effects of something not visible in diff''s being mailed by post commit hooks. -- 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
2010-Jul-29 19:47 UTC
Re: [Puppet Users] Reconciling resource defaults, dynamic scope, and the singleton nature of classes
On Thu, Jul 29, 2010 at 12:28 PM, R.I.Pienaar <rip@devco.net> wrote:> > ----- "Nigel Kersten" <nigelk@google.com> wrote: > >> On Thu, Jul 29, 2010 at 12:11 PM, R.I.Pienaar <rip@devco.net> wrote: >> > >> > ----- "Jeff McCune" <jeff@puppetlabs.com> wrote: >> > >> >> On Thu, Jul 29, 2010 at 12:07 PM, R.I.Pienaar <rip@devco.net> wro> >> >> > ----- "Jeff McCune" <jeff@puppetlabs.com> wrote: >> >> > >> >> >> I make the recommendation that classes should include the >> classes >> >> >> they depend on, but this appears to be problematic if the class >> >> doing the >> >> >> include sets resource defaults, particularity when setting a >> >> >> relationship in a default like require, before, subscribe and >> >> notify. >> >> >> This opens up the door for resource cycles. >> >> > >> >> > recommendations are fine, but that is a lot of convention and >> best >> >> > practice something that is very hard to pass on to new people, >> its >> >> hard >> >> > to audit and its hard to predict. And ones established as a >> best >> >> practise >> >> > that causes problems when ignored also lulls one into a false >> sense >> >> of >> >> > safety. >> >> >> >> Agreed. As you mentioned this has been on my mind for quite a >> while >> >> now. The unpredictability of scope when a class is included >> multiple >> >> times has been pushed to front of my mind since it''s been such a >> >> common point of confusion when talking with many people, both new >> and >> >> experienced. >> >> >> >> > best avoided, it should do the right thing by default. >> >> >> >> Agreed. This begs the question; what is the "right thing" puppet >> >> should be doing by default? >> >> >> >> >> Perhaps it might be useful to set resource defaults only for >> the >> >> >> local scope, and not for any classes which get included into >> this >> >> scope. >> >> >> How do you feel about this change to the language? >> >> > >> >> > I''ve thought about this problem before and thought the fact that >> >> puppet >> >> > did not behave in this way was a bug, so my vote is with this :) >> >> >> >> Do you think resource defaults should default to the local scope >> if >> >> the default isn''t declared in the top or node scope? >> > >> > I had not considered the global scope defaults, I dont use them cos >> I >> > like the side effect of a manifest to be clear when looking at a >> single >> > pp file. I''d only ever set a default that I expect to be localized >> > to the class its in. but thats just me as Nigel points out :) >> >> So we only do it for quite specific cases, turning off file backups >> and forcing application, ensuring our desired provider is explicit >> (we''ve had the odd issue where the automatic provider selection >> didn''t >> behave the way we wanted) and ensuring that our apt packages all >> require our "update-apt-stuff" class. >> >> File { force => true, backup => false, } > > I think this should be a configuration option tbh - to disable backups, not force :)Ah, but we have the odd little file that we do choose to backup :) so a default makes sense here.> >> Package { >> provider => "apt", >> require => Class["package::apt::update"] >> } >> >> We basically have provider defaults explicitly set as global resource >> defaults for package and service for each of our platforms. > > I''ve wrapped all my package access in a define that does this kind of thing > among others, but it just means i can control all the specific behavior in > one place and if i get a new site or new needs its one update. > > I do this with quite a lot of things, all about explicit behavior and not > side effects of something not visible in diff''s being mailed by post commit > hooks.I''m also moving things to defines rather than resource defaults, primarily because you can append to the relationships rather than replacing them, but I''m not sure it''s any more explicit to have to go look at the definition rather than resource default? I guess if you''re using defaults in a non-sane manner it might be :)> > -- > 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 -- 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.
Jeff McCune
2010-Jul-29 20:00 UTC
Re: [Puppet Users] Reconciling resource defaults, dynamic scope, and the singleton nature of classes
On Thu, Jul 29, 2010 at 12:58 PM, Nigel Kersten <nigelk@google.com> wrote:> > How do you "know" what the scope is of those included classes will end > > up as? Are you not including the "edge" classes multiple times? > > Nope. That would be insane due to what sparked this thread off :)I think this is something that is really becoming an issue with the increasing number of modules published to the Forge. Modules need some way to satisfy their dependencies on other modules, and the current behavior of include just doesn''t seem to cut it. What about include ::localyumrepository ? It''s valid syntax in 0.24.9, 0.25.5, and 2.6.0 And... Believe it or not, it actually already does almost exactly what I want it to do in 2.6, except I think I found a bug in 2.6. Here''s my test manifest: # class leaf { notify { "leaf": } } class baseone { Notify { message => "baseone" } notify { "baseone": } include ::leaf } class basetwo { Notify { message => "basetwo" } notify { "basetwo": } include ::leaf } include baseone, basetwo # include basetwo, baseone Here''s the result in 0.25.5 and 0.24.9: notice: baseone notice: //baseone/Notify[baseone]/message: defined ''message'' as ''baseone'' notice: baseone notice: //baseone/leaf/Notify[leaf]/message: defined ''message'' as ''baseone'' notice: basetwo notice: //basetwo/Notify[basetwo]/message: defined ''message'' as ''basetwo'' Notice how Notify[leaf]''s scope is within baseone, which was the first class to include it. Now, for the pleasant surprise: (in 2.6.0) notice: basetwo notice: /Stage[main]/Basetwo/Notify[basetwo]/message: defined ''message'' as ''basetwo'' notice: baseone notice: /Stage[main]/Leaf/Notify[leaf]/message: defined ''message'' as ''baseone'' notice: baseone notice: /Stage[main]/Baseone/Notify[baseone]/message: defined ''message'' as ''baseone'' It *appears* Notify[leaf] is not within the scope of Baseone or Basetwo, however it''s still getting the default value of the message parameter from the baseone class... Flipping in the order around to include basetwo, baseone we get: notice: /Stage[main]/Leaf/Notify[leaf]/message: defined ''message'' as ''basetwo'' Again, it looks like the class is included into top scope, but the behavior is that we''re still getting resource defaults from basetwo''s scope. Thoughts? Am I insane for wanting include ::leaf to place Leaf at top scope? -- Jeff McCune 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.
R.I.Pienaar
2010-Jul-29 20:04 UTC
Re: [Puppet Users] Reconciling resource defaults, dynamic scope, and the singleton nature of classes
----- "Jeff McCune" <jeff@puppetlabs.com> wrote:> > I think this is something that is really becoming an issue with the > increasing number of modules published to the Forge. Modules need some > way to satisfy their dependencies on other modules, and the current > behavior of include just doesn''t seem to cut it. > > > What about include ::localyumrepository ? > > > It''s valid syntax in 0.24.9, 0.25.5, and 2.6.0 > > > And... Believe it or not, it actually already does almost exactly what > I want it to do in 2.6, except I think I found a bug in 2.6. > > > Here''s my test manifest: > # > > class leaf { notify { "leaf": } } > class baseone { > Notify { message => "baseone" } > notify { "baseone": } > include ::leaf > } > class basetwo { > Notify { message => "basetwo" } > notify { "basetwo": } > include ::leaf > } > include baseone, basetwo > # include basetwo, baseone > > > Here''s the result in 0.25.5 and 0.24.9: > > notice: baseone > notice: //baseone/Notify[baseone]/message: defined ''message'' as > ''baseone'' > notice: baseone > notice: //baseone/leaf/Notify[leaf]/message: defined ''message'' as > ''baseone'' > notice: basetwo > notice: //basetwo/Notify[basetwo]/message: defined ''message'' as > ''basetwo'' > > > Notice how Notify[leaf]''s scope is within baseone, which was the first > class to include it. > > > Now, for the pleasant surprise: (in 2.6.0) > > notice: basetwo > notice: /Stage[main]/Basetwo/Notify[basetwo]/message: defined > ''message'' as ''basetwo'' > notice: baseone > notice: /Stage[main]/Leaf/Notify[leaf]/message: defined ''message'' as > ''baseone'' > notice: baseone > notice: /Stage[main]/Baseone/Notify[baseone]/message: defined > ''message'' as ''baseone'' > > > It *appears* Notify[leaf] is not within the scope of Baseone or > Basetwo, however it''s still getting the default value of the message > parameter from the baseone class... Flipping in the order around to > include basetwo, baseone we get: > > notice: /Stage[main]/Leaf/Notify[leaf]/message: defined ''message'' as > ''basetwo'' > > > Again, it looks like the class is included into top scope, but the > behavior is that we''re still getting resource defaults from basetwo''s > scope. > > > Thoughts? Am I insane for wanting include ::leaf to place Leaf at top > scope?I think so :) ::topclass isnt about scope its about resolution? I never considered it would have scope implications. Only time you tend to see it is in: class monitor { } class foo::monitor { } class foo::bar { include ::monitor } to include class monitor and not foo::monitor, you wouldnt want that to do weird scope things -- 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.
Jeff McCune
2010-Jul-29 20:05 UTC
Re: [Puppet Users] Reconciling resource defaults, dynamic scope, and the singleton nature of classes
On Thu, Jul 29, 2010 at 2:00 PM, Jeff McCune <jeff@puppetlabs.com> wrote:> And... Believe it or not, it actually already does almost exactly what I > want it to do in 2.6, except I think I found a bug in 2.6. > >Hrm, it appears to be just a tweak to the display... include leaf and include ::leaf both result in the same display of: notice: /Stage[main]/Leaf/Notify[leaf]/message: defined ''message'' as ''baseone'' So it''s still nesting the scope of leaf, however it''s just no longer clearly displaying it. Rats. -- Jeff McCune 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.
Jeff McCune
2010-Jul-29 20:09 UTC
Re: [Puppet Users] Reconciling resource defaults, dynamic scope, and the singleton nature of classes
On Thu, Jul 29, 2010 at 2:04 PM, R.I.Pienaar <rip@devco.net> wrote:> > I think so :) ::topclass isnt about scope its about resolution? I never considered it would have scope implications.Right, forgot about that case. So what about another keyword in addition to require and include (feels like we''re running out...) that adds a class to the catalog at top scope? Something like "addclass" perhaps. Modules would then avoid using "include mydependency" and prefer "addclass mydependency" -- Jeff McCune 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.
David Schmitt
2010-Jul-30 09:32 UTC
Re: [Puppet Users] Reconciling resource defaults, dynamic scope, and the singleton nature of classes
On 7/29/2010 8:07 PM, R.I.Pienaar wrote:> > ----- "Jeff McCune"<jeff@puppetlabs.com> wrote:>> Perhaps it might be useful to set resource defaults only for the >> local scope, and not for any classes which get included into this scope. >> How do you feel about this change to the language? > > I''ve thought about this problem before and thought the fact that puppet > did not behave in this way was a bug, so my vote is with this :)+1. I was not aware of the current behaviour and it''s definitely not the way I''d expect a sensible language to work. Best Regards, David -- dasz.at OG Tel: +43 (0)664 2602670 Web: http://dasz.at Klosterneuburg UID: ATU64260999 FB-Nr.: FN 309285 g FB-Gericht: LG Korneuburg -- 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.