Querying is awesome, particularly with the new relationship syntax, and as a more comprehensible alternative to class inheritance. Package <| |> The part I find frustrating is that it also *realizes* all the virtual resources that match the query. It would be immensely useful in my opinion if you could collect without realizing. How could we get there? Proposal here is that Package <| |> would realize, but Package <| |> { } wouldn''t. Luke from a previous conversation: I''m thinking that a collection with no {} on it should default to realizing> resources but could throw a warning, and a collection with a {} on it should > not realize. We would probably also want to make a collection a valid > rvalue, and have it resolve to an array of resources in that case. This > would probably cause some ordering issues, because collections are run many > times, but functions are only called once.Proposal here is that we add the ability to filter based upon whether resources have been realized or not: Me from a previous conversation: Could we add the ability to query whether a given resource has> been realized or not? How much of an ordering problem is this? > Package <| state == virtual |> > Package <| state == real |>I''d like to keep this thread on this particular topic. In the course of discussing this somewhere else we covered areas such as filtering on provider where providers weren''t explicitly set in the manifests, issues around the defined() function, etc. Lets start new threads if we want to discuss those peripheral issues. -- 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.
Dan Bode
2011-Feb-13 03:40 UTC
[Puppet Users] Re: [Puppet-dev] Collections and Realizing Resources
On Sat, Feb 12, 2011 at 2:00 PM, Nigel Kersten <nigel@puppetlabs.com> wrote:> Querying is awesome, particularly with the new relationship syntax, and as > a more comprehensible alternative to class inheritance. > > Package <| |> > > The part I find frustrating is that it also *realizes* all the virtual > resources that match the query. > > It would be immensely useful in my opinion if you could collect without > realizing. How could we get there? > > > Proposal here is that Package <| |> would realize, but Package <| |> { } > wouldn''t. > > Luke from a previous conversation: > > I''m thinking that a collection with no {} on it should default to realizing >> resources but could throw a warning, and a collection with a {} on it should >> not realize. We would probably also want to make a collection a valid >> rvalue, and have it resolve to an array of resources in that case. This >> would probably cause some ordering issues, because collections are run many >> times, but functions are only called once. > > > > Proposal here is that we add the ability to filter based upon whether > resources have been realized or not: > > Me from a previous conversation: > > Could we add the ability to query whether a given resource has >> been realized or not? How much of an ordering problem is this? >> Package <| state == virtual |> >> Package <| state == real |> >> >>Sounds reasonable, I have actually tried something like this before hoping it would work. (the use case was that I wanted to specify some dependency for all resources of a given type that I was realizing)> > I''d like to keep this thread on this particular topic. In the course of > discussing this somewhere else we covered areas such as filtering on > provider where providers weren''t explicitly set in the manifests, issues > around the defined() function, etc. Lets start new threads if we want to > discuss those peripheral issues. > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To post to this group, send email to puppet-dev@googlegroups.com. > To unsubscribe from this group, send email to > puppet-dev+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-dev?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 Sat, Feb 12, 2011 at 7:40 PM, Dan Bode <dan@puppetlabs.com> wrote:> >> Could we add the ability to query whether a given resource has >>> been realized or not? How much of an ordering problem is this? >>> Package <| state == virtual |> >>> Package <| state == real |> >>> >> > Sounds reasonable, I have actually tried something like this before hoping > it would work. (the use case was that I wanted to specify some dependency > for all resources of a given type that I was realizing) >I''m curious how many people are actually using this syntax for resource realization rather than the realize() function? Generally when I realize resources, I''m doing so for very specific resources, not large collections of resources. Should we be conflating querying/collecting and realizing like this at all? -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
Daniel Pittman
2011-Feb-14 04:25 UTC
Re: [Puppet Users] Re: [Puppet-dev] Collections and Realizing Resources
On Sun, Feb 13, 2011 at 19:21, Nigel Kersten <nigel@puppetlabs.com> wrote:> On Sat, Feb 12, 2011 at 7:40 PM, Dan Bode <dan@puppetlabs.com> wrote: >>> >>>> Could we add the ability to query whether a given resource has >>>> been realized or not? How much of an ordering problem is this? >>>> Package <| state == virtual |> >>>> Package <| state == real |> >> >> Sounds reasonable, I have actually tried something like this before hoping >> it would work. (the use case was that I wanted to specify some dependency >> for all resources of a given type that I was realizing) > > I''m curious how many people are actually using this syntax for resource > realization rather than the realize() function? > Generally when I realize resources, I''m doing so for very specific > resources, not large collections of resources. > Should we be conflating querying/collecting and realizing like this at all?I would very, very strongly like to see this separated, because one of my longer term goals is to see better support for doing things with information about collections, not just including random resources with them. So, separating out the two concepts and having a mechanism for realise() to meet a collection? Great. I fully support this. Daniel My trivial use case for doing things with collections is: give me the fqdn of every machine tagged "application server for X" on my load balancer. Storeconfigs, or mcollective, or something more dynamic is an implementation detail under that use case. -- ⎋ Puppet Labs Developer – http://puppetlabs.com ✉ Daniel Pittman <daniel@puppetlabs.com> ✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775 ♲ 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.
Dan Bode
2011-Feb-14 05:59 UTC
Re: [Puppet Users] Re: [Puppet-dev] Collections and Realizing Resources
On Sun, Feb 13, 2011 at 7:21 PM, Nigel Kersten <nigel@puppetlabs.com> wrote:> > > On Sat, Feb 12, 2011 at 7:40 PM, Dan Bode <dan@puppetlabs.com> wrote: > >> >>> Could we add the ability to query whether a given resource has >>>> been realized or not? How much of an ordering problem is this? >>>> Package <| state == virtual |> >>>> Package <| state == real |> >>>> >>> >> Sounds reasonable, I have actually tried something like this before hoping >> it would work. (the use case was that I wanted to specify some dependency >> for all resources of a given type that I was realizing) >> > > I''m curious how many people are actually using this syntax for resource > realization rather than the realize() function? > > Generally when I realize resources, I''m doing so for very specific > resources, not large collections of resources. > > Should we be conflating querying/collecting and realizing like this at > all? > >We have only been teaching <| |> in the puppetmaster training as a way to realize virtual resources. We do not teach that it is possible to override attributes with this syntax as well: <| |> {} (at least in part b/c the implications/non-determinism terrify me) , and do not teach that it actually effects all resources. The common example from class is something like: class db::users { user { [''alice'', ''bob'']: ensure => present, gid => ''dbadmin'', } } class app::users { user { [''charlie'', ''bob'']: ensure => present, gid => ''webadmin'', } } class app { User<| gid == ''webadmin'' |> ... } class db { User<| gid == ''dbadmin'' |> ... } so that a machine can safely be a webserver and db server without conflict.> > -- > 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
2011-Feb-14 14:49 UTC
Re: [Puppet Users] Re: [Puppet-dev] Collections and Realizing Resources
On Sun, Feb 13, 2011 at 9:59 PM, Dan Bode <dan@puppetlabs.com> wrote:> > We have only been teaching <| |> in the puppetmaster training as a way to > realize virtual resources. We do not teach that it is possible to override > attributes with this syntax as well: <| |> {} (at least in part b/c the > implications/non-determinism terrify me) , and do not teach that it actually > effects all resources. >Why is using collections to override attributes non-deterministic compared to class inheritance doing the same thing? The common example from class is something like:> > class db::users { > user { [''alice'', ''bob'']: > ensure => present, > gid => ''dbadmin'', > } > } > > class app::users { > user { [''charlie'', ''bob'']: > ensure => present, > gid => ''webadmin'', > } > } > > > class app { > User<| gid == ''webadmin'' |> > ... > } > > class db { > User<| gid == ''dbadmin'' |> > ... > } > > so that a machine can safely be a webserver and db server without conflict. >Why is this preferred over the realize() function? I consider the realize function much simpler to teach and understand for this class of problem. -- 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.
Dan Bode
2011-Feb-14 16:56 UTC
Re: [Puppet Users] Re: [Puppet-dev] Collections and Realizing Resources
On Mon, Feb 14, 2011 at 6:49 AM, Nigel Kersten <nigel@puppetlabs.com> wrote:> On Sun, Feb 13, 2011 at 9:59 PM, Dan Bode <dan@puppetlabs.com> wrote: > >> >> We have only been teaching <| |> in the puppetmaster training as a way to >> realize virtual resources. We do not teach that it is possible to override >> attributes with this syntax as well: <| |> {} (at least in part b/c the >> implications/non-determinism terrify me) , and do not teach that it actually >> effects all resources. >> > > Why is using collections to override attributes non-deterministic compared > to class inheritance doing the same thing? >With the below example, the evaluation order of the overrides determines the final value. notify { ''foo'': message => ''bar'', } Notify<| |> { message => ''bazz'' } Notify<| |> { message => ''baz'' } # try this example and swap the overrides With class inheritance, any attempt to override the same attribute twice fails: class a { notify { ''foo'': message => ''a'', } } class c inherits a { Notify[''foo''] {message => ''c''} } class b inherits a { Notify[''foo''] {message => ''b''} } include a,c,b :!puppet apply /tmp/foo2.pp Parameter ''message'' is already set on Notify[foo] by #<Puppet::Resource::Type:0xb7a430c8> at /tmp/foo2.pp:9; cannot redefine at /tmp/foo2.pp:12 on node mypuppetmaster.localdomain The common example from class is something like:>> >> class db::users { >> user { [''alice'', ''bob'']: >> ensure => present, >> gid => ''dbadmin'', >> } >> } >> >> class app::users { >> user { [''charlie'', ''bob'']: >> ensure => present, >> gid => ''webadmin'', >> } >> } >> >> >> class app { >> User<| gid == ''webadmin'' |> >> ... >> } >> >> class db { >> User<| gid == ''dbadmin'' |> >> ... >> } >> >> so that a machine can safely be a webserver and db server without >> conflict. >> > > > Why is this preferred over the realize() function? I consider the realize > function much simpler to teach and understand for this class of problem. >The realize function requires that we have to know all of the names of the resources that we are realizing. Consider the example where each group of users has 10 members, the above syntax is way easier to manage than: realize(User[1], User[2], .... User[10])> > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To post to this group, send email to puppet-dev@googlegroups.com. > To unsubscribe from this group, send email to > puppet-dev+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-dev?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
2011-Feb-14 17:26 UTC
Re: [Puppet Users] Re: [Puppet-dev] Collections and Realizing Resources
On Mon, Feb 14, 2011 at 8:56 AM, Dan Bode <dan@puppetlabs.com> wrote:> > > On Mon, Feb 14, 2011 at 6:49 AM, Nigel Kersten <nigel@puppetlabs.com>wrote: > >> On Sun, Feb 13, 2011 at 9:59 PM, Dan Bode <dan@puppetlabs.com> wrote: >> >>> >>> We have only been teaching <| |> in the puppetmaster training as a way to >>> realize virtual resources. We do not teach that it is possible to override >>> attributes with this syntax as well: <| |> {} (at least in part b/c the >>> implications/non-determinism terrify me) , and do not teach that it actually >>> effects all resources. >>> >> >> Why is using collections to override attributes non-deterministic compared >> to class inheritance doing the same thing? >> > > With the below example, the evaluation order of the overrides determines > the final value. > > notify { ''foo'': > message => ''bar'', > } > > Notify<| |> { > message => ''bazz'' > } > Notify<| |> { > message => ''baz'' > } > > # try this example and swap the overrides > > With class inheritance, any attempt to override the same attribute twice > fails: > > class a { > notify { ''foo'': > message => ''a'', > } > } > class c inherits a { > Notify[''foo''] {message => ''c''} > } > class b inherits a { > Notify[''foo''] {message => ''b''} > } > include a,c,b > > :!puppet apply /tmp/foo2.pp > Parameter ''message'' is already set on Notify[foo] by > #<Puppet::Resource::Type:0xb7a430c8> at /tmp/foo2.pp:9; cannot redefine at > /tmp/foo2.pp:12 on node mypuppetmaster.localdomain >Hmm. So it''s order-dependent because you can do it more than once, unlike class inheritance. Overriding the same attribute more than once via collection feels like a code smell to me. The common example from class is something like:>>> >>> class db::users { >>> user { [''alice'', ''bob'']: >>> ensure => present, >>> gid => ''dbadmin'', >>> } >>> } >>> >>> class app::users { >>> user { [''charlie'', ''bob'']: >>> ensure => present, >>> gid => ''webadmin'', >>> } >>> } >>> >>> >>> class app { >>> User<| gid == ''webadmin'' |> >>> ... >>> } >>> >>> class db { >>> User<| gid == ''dbadmin'' |> >>> ... >>> } >>> >>> so that a machine can safely be a webserver and db server without >>> conflict. >>> >> >> >> Why is this preferred over the realize() function? I consider the realize >> function much simpler to teach and understand for this class of problem. >> > > The realize function requires that we have to know all of the names of the > resources that we are realizing. Consider the example where each group of > users has 10 members, the above syntax is way easier to manage than: > > realize(User[1], User[2], .... User[10]) > >ah, but your collection syntax requires that you have to know the gid of the resources you are realizing :) There are certainly cases where the collection syntax is easier, but I feel that the vast majority of virtual resource realizations I see in the wild are for one or two resources where the name is known. -- 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.
Felix Frank
2011-Feb-15 08:03 UTC
Re: [Puppet Users] Re: [Puppet-dev] Collections and Realizing Resources
> realize(User[1], User[2], .... User[10]) > > > ah, but your collection syntax requires that you have to know the gid of > the resources you are realizing :) > > There are certainly cases where the collection syntax is easier, but I > feel that the vast majority of virtual resource realizations I see in > the wild are for one or two resources where the name is known.Not to mention "realize(User[1,2,...,10])". It would be nice if multiple overrides failed from this syntax just the way it fails for inheritance. But that''s probably hard to implement? Regards, Felix -- 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.