I want to do something like this:
class foo ( $collection ) {
User <| $collection |>
}
where $collection would be a string like "group == admin or group ==
powerusers"
Doesn''t work. Is there an alternative way to do this?
Syntax error at ''|>''; expected ''}''
--
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/-/lx88_I9wS24J.
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, November 15, 2012 6:01:24 PM UTC-6, Rajul Vora wrote:> > > I want to do something like this: > > class foo ( $collection ) { > > User <| $collection |> > > } > > where $collection would be a string like "group == admin or group == > powerusers" > > Doesn''t work. Is there an alternative way to do this? > > Syntax error at ''|>''; expected ''}'' >It depends on what you mean by "this". As far as I know, there is no way to implement so dynamic a collection predicate as you want, though you can do this: define mymodule::usergroup() { User<| group == $name |> } (Or you could do the something similar with a class, but a defined type is probably better for modeling this sort of thing.) You can augment that in various ways, but I think a perceived need to be as generic as you wanted reflects a modeling problem. Consider also whether you need to wrap that collection at all. Would it be a problem to just write User<| group == ''admin'' |> instead of mymodule::usergroup { ''admin'': } (or a comparable class declaration)? I suppose you''re actually working on something more complex, of which the collection is just one part. I''m inclined to think there is a deeper problem with your design if you perceive a need for such a generic collection, but unless you explain the real problem you''re trying to solve, there''s not much more I can do for you. 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/-/r6cP6vML_00J. 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.
Thanks for the effort in explaining these alternatives. I apologize I
didn''t do justice to explaining the bigger picture in the first place.
So here it goes:
Goal: Use hiera to provision different groups of users in different
environments.
Approach: First create virtual users from hiera that lists all possible
users and then realizing "collection" of users that are also defined
in
hiera using the <| expression |> to combine various groups. I like this
approach because I can list every possible user in a single hiera file so I
can keep the UIDs sequential as I add new users, etc.
So the main problem here is that the thing that goes between the spaceship
operators is dynamic.
I am using erwbgy/puppet-system module which has been extended to support
virtual users.
E.g. My hieradata would look like this:
- common.yaml:
- system::virt_users:
- ''user1'':
- uid: 1001
- groups: ["A", "B", "C"]
- ''user2'':
- uid: 1002
- groups: [ "A" ]
- ''user3'':
- uid: 1003
- groups: [ "C" ]
- and so on....
- production.yaml:
- system::realize_users: group == "A"
- qa.yaml:
- system::realize_users: group == "A" or group == "B"
- dev.yaml:
- system::realize_users: # empty value that should mean all
matching virtual users like <| |>
So the "foo" class in my original post would really be something like
this:
# system module does hiera lookup in init.pp but I am simplifying below to
make code concise for this discussion
class system::realize_users (
$collection=hiera("system::realize_users") {
User <| $collection |>
}
I am not married to this approach or module. So any other approach to
achieve my goal listed above would do.
Thanks,
Rajul
On Friday, November 16, 2012 6:38:13 AM UTC-8, jcbollinger wrote:
>
>
> On Thursday, November 15, 2012 6:01:24 PM UTC-6, Rajul Vora wrote:
>>
>>
>> I want to do something like this:
>>
>> class foo ( $collection ) {
>>
>> User <| $collection |>
>>
>> }
>>
>> where $collection would be a string like "group == admin or group
==
>> powerusers"
>>
>> Doesn''t work. Is there an alternative way to do this?
>>
>> Syntax error at ''|>''; expected
''}''
>>
>
>
> It depends on what you mean by "this". As far as I know, there
is no way
> to implement so dynamic a collection predicate as you want, though you can
> do this:
>
> define mymodule::usergroup() {
> User<| group == $name |>
> }
>
> (Or you could do the something similar with a class, but a defined type is
> probably better for modeling this sort of thing.) You can augment that in
> various ways, but I think a perceived need to be as generic as you wanted
> reflects a modeling problem.
>
> Consider also whether you need to wrap that collection at all. Would it
> be a problem to just write
>
> User<| group == ''admin'' |>
>
> instead of
>
> mymodule::usergroup { ''admin'': }
>
> (or a comparable class declaration)?
>
> I suppose you''re actually working on something more complex, of
which the
> collection is just one part. I''m inclined to think there is a
deeper
> problem with your design if you perceive a need for such a generic
> collection, but unless you explain the real problem you''re trying
to solve,
> there''s not much more I can do for you.
>
>
> 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/-/-ufmqi2Q2gEJ.
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 Friday, November 16, 2012 11:07:18 AM UTC-6, Rajul Vora wrote:> > > Thanks for the effort in explaining these alternatives. I apologize I > didn''t do justice to explaining the bigger picture in the first place. > > So here it goes: > > Goal: Use hiera to provision different groups of users in different > environments. > > Approach: First create virtual users from hiera that lists all possible > users and then realizing "collection" of users that are also defined in > hiera using the <| expression |> to combine various groups. I like this > approach because I can list every possible user in a single hiera file so I > can keep the UIDs sequential as I add new users, etc. > > So the main problem here is that the thing that goes between the spaceship > operators is dynamic. >Yes, but to support only what you describe, it doesn''t need to be nearly as dynamic as you''re trying to make it. Inasmuch as you are choosing which users to realize based on their groups, the defined type example in my previous message should get you most of the way to where you want to go. The key to making it work for you would be to change from using the ''system::realize_users'' collection predicate to using a plain array of the user groups you want. For example, production.yaml: mymodule::usergroups: - A qa.yaml: mymodule::usergroups: - A - B dev.yaml: mymodule::usergroups: ALL Then you realize them with a class such as this one: class mymodule::systemusers { $usergroups = hiera(''mymodule::usergroups'') if $usergroups == ''ALL'' { User <| |> } else { mymodule::usergroup { $usergroups: } } } If $usergroups is an array then that calls for one mymodule::usergroup instance per element; if it is a scalar then you will get just one. Also, be aware that it is not a problem to realize / collect the same virtual User multiple times so long as you do not override any properties when you collect. On the other hand, users have only one primary group, so you''re not going to have collisions selecting only on group. There are, of course, many other ways to do it, including some involving playing various clever tricks with your data. If all you need is to select users based on values of one property (at a time), however, then the above is a pretty good way. 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/-/TZydaf0thNIJ. 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.
Yes, I was actually thinking of doing that after I sent my reply to you - based on your mymodule::usergroup defined resource idea. Thanks for confirming that idea. I''ll implement it and it will work for what I am trying to do. Simple is better. Rajul On Friday, November 16, 2012 11:16:36 AM UTC-8, jcbollinger wrote:> > > > On Friday, November 16, 2012 11:07:18 AM UTC-6, Rajul Vora wrote: >> >> >> Thanks for the effort in explaining these alternatives. I apologize I >> didn''t do justice to explaining the bigger picture in the first place. >> >> So here it goes: >> >> Goal: Use hiera to provision different groups of users in different >> environments. >> >> Approach: First create virtual users from hiera that lists all possible >> users and then realizing "collection" of users that are also defined in >> hiera using the <| expression |> to combine various groups. I like this >> approach because I can list every possible user in a single hiera file so I >> can keep the UIDs sequential as I add new users, etc. >> >> So the main problem here is that the thing that goes between the >> spaceship operators is dynamic. >> > > > Yes, but to support only what you describe, it doesn''t need to be nearly > as dynamic as you''re trying to make it. Inasmuch as you are choosing which > users to realize based on their groups, the defined type example in my > previous message should get you most of the way to where you want to go. > The key to making it work for you would be to change from using the > ''system::realize_users'' collection predicate to using a plain array of the > user groups you want. For example, > > production.yaml: > mymodule::usergroups: > - A > > qa.yaml: > mymodule::usergroups: > - A > - B > > dev.yaml: > mymodule::usergroups: ALL > > Then you realize them with a class such as this one: > > class mymodule::systemusers { > $usergroups = hiera(''mymodule::usergroups'') > > if $usergroups == ''ALL'' { > User <| |> > } else { > mymodule::usergroup { $usergroups: } > } > } > > If $usergroups is an array then that calls for one mymodule::usergroup > instance per element; if it is a scalar then you will get just one. Also, > be aware that it is not a problem to realize / collect the same virtual > User multiple times so long as you do not override any properties when you > collect. On the other hand, users have only one primary group, so you''re > not going to have collisions selecting only on group. > > There are, of course, many other ways to do it, including some involving > playing various clever tricks with your data. If all you need is to select > users based on values of one property (at a time), however, then the above > is a pretty good way. > > > 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/-/gwydGuVhR3wJ. 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.
Unfortunately, this does not work either. Here''s a complete standalone
puppet manifest you can do "puppet apply" on. No users are actually
being
realized.
I don''t believe "User <| group == $name |>" works.
:(
Rajul
node default {
class { ''usergroups'':
}
}
class virtusers {
group { ''A'': ensure => present }
group { ''B'': ensure => present }
group { ''C'': ensure => present }
@user { ''one'':
ensure => present,
uid => 5001,
groups => [ ''A'' ]
}
@user { ''two'':
ensure => present,
uid => 5002,
groups => [ ''B'' ]
}
@user { ''three'':
ensure => present,
uid => 5003,
groups => [ ''C'' ]
}
}
class usergroups {
include virtusers
define realize_helper( ) {
User <| group == $name |>
}
### none of these work
#$group_list = [ ''A'', ''B'' ]
$group_list = ''A''
realize_helper { $group_list: }
}
On Friday, November 16, 2012 11:25:15 AM UTC-8, Rajul Vora
wrote:>
> Yes, I was actually thinking of doing that after I sent my reply to you -
> based on your mymodule::usergroup defined resource idea. Thanks for
> confirming that idea. I''ll implement it and it will work for what
I am
> trying to do.
>
> Simple is better.
>
> Rajul
>
> On Friday, November 16, 2012 11:16:36 AM UTC-8, jcbollinger wrote:
>>
>>
>>
>> On Friday, November 16, 2012 11:07:18 AM UTC-6, Rajul Vora wrote:
>>>
>>>
>>> Thanks for the effort in explaining these alternatives. I apologize
I
>>> didn''t do justice to explaining the bigger picture in the
first place.
>>>
>>> So here it goes:
>>>
>>> Goal: Use hiera to provision different groups of users in different
>>> environments.
>>>
>>> Approach: First create virtual users from hiera that lists all
possible
>>> users and then realizing "collection" of users that are
also defined in
>>> hiera using the <| expression |> to combine various groups. I
like this
>>> approach because I can list every possible user in a single hiera
file so I
>>> can keep the UIDs sequential as I add new users, etc.
>>>
>>> So the main problem here is that the thing that goes between the
>>> spaceship operators is dynamic.
>>>
>>
>>
>> Yes, but to support only what you describe, it doesn''t need to
be nearly
>> as dynamic as you''re trying to make it. Inasmuch as you are
choosing which
>> users to realize based on their groups, the defined type example in my
>> previous message should get you most of the way to where you want to
go.
>> The key to making it work for you would be to change from using the
>> ''system::realize_users'' collection predicate to using
a plain array of the
>> user groups you want. For example,
>>
>> production.yaml:
>> mymodule::usergroups:
>> - A
>>
>> qa.yaml:
>> mymodule::usergroups:
>> - A
>> - B
>>
>> dev.yaml:
>> mymodule::usergroups: ALL
>>
>> Then you realize them with a class such as this one:
>>
>> class mymodule::systemusers {
>> $usergroups = hiera(''mymodule::usergroups'')
>>
>> if $usergroups == ''ALL'' {
>> User <| |>
>> } else {
>> mymodule::usergroup { $usergroups: }
>> }
>> }
>>
>> If $usergroups is an array then that calls for one mymodule::usergroup
>> instance per element; if it is a scalar then you will get just one.
Also,
>> be aware that it is not a problem to realize / collect the same virtual
>> User multiple times so long as you do not override any properties when
you
>> collect. On the other hand, users have only one primary group, so
you''re
>> not going to have collisions selecting only on group.
>>
>> There are, of course, many other ways to do it, including some
involving
>> playing various clever tricks with your data. If all you need is to
select
>> users based on values of one property (at a time), however, then the
above
>> is a pretty good way.
>>
>>
>> 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/-/lEpYYdoxXO4J.
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 Friday, November 16, 2012 9:04:44 PM UTC, Rajul Vora wrote:> > define realize_helper( ) { > User <| group == $name |> > } >ITYM ''groups'' not ''group''. -- Nick -- 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/-/IzxzAKePgY4J. 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.
From official documentation: User <| (group == dba or group == sysadmin) or title == luke |> On Sun, Nov 18, 2012 at 8:55 AM, Nick Osborn <nick@osborn.ws> wrote:> On Friday, November 16, 2012 9:04:44 PM UTC, Rajul Vora wrote: >> >> define realize_helper( ) { >> User <| group == $name |> >> } >> > > ITYM ''groups'' not ''group''. > > -- > Nick > > -- > 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/-/IzxzAKePgY4J. > > 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. >-- Rajul Vora -- 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 Sunday, November 18, 2012 12:13:20 PM UTC-6, Rajul Vora wrote:> > > From official documentation: > > User <| (group == dba or group == sysadmin) or title == luke |> > >You are missing Nick''s point. In your example, you declare *secondary*groups for your users via their ''groups'' properties, then you try to collect them based on a predicate testing the *primary* group (the ''group'' property). These are separate, uncorrelated properties. 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/-/Wmd0Z4rhkOUJ. 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.
Ok, got it. Thanks for that clarification. I totally missed that distinction. Rajul On Mon, Nov 19, 2012 at 6:34 AM, jcbollinger <John.Bollinger@stjude.org>wrote:> > > On Sunday, November 18, 2012 12:13:20 PM UTC-6, Rajul Vora wrote: >> >> >> From official documentation: >> >> User <| (group == dba or group == sysadmin) or title == luke |> >> >> > You are missing Nick''s point. In your example, you declare *secondary*groups for your users via their ''groups'' properties, then you try to > collect them based on a predicate testing the *primary* group (the > ''group'' property). These are separate, uncorrelated properties. > > > 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/-/Wmd0Z4rhkOUJ. > > 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. >-- Rajul Vora -- 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.