Dynamic Collection?

[Rajul Vora]

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 '}'

[jcbollinger]

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

[Rajul Vora]

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

[jcbollinger]

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

[Rajul Vora]

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

[Rajul Vora]

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: }

[raju...@gmail.com]

From official documentation:

User <| (group == dba or group == sysadmin) or title == luke |>

On Sun, Nov 18, 2012 at 8:55 AM, Nick Osborn <ni...@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...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

--
Rajul Vora

[jcbollinger]

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

[raju...@gmail.com]

Ok, got it. Thanks for that clarification. I totally missed that distinction.

Rajul

--
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...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

--
Rajul Vora