FAQ
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.

Search Discussions

  • Jcbollinger at Nov 16, 2012 at 2:38 pm

    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.
  • Rajul Vora at Nov 16, 2012 at 5:07 pm
    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.
  • Jcbollinger at Nov 16, 2012 at 7:16 pm

    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.
  • Rajul Vora at Nov 16, 2012 at 7:25 pm
    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.
  • Rajul Vora at Nov 16, 2012 at 9:04 pm
    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.
  • Nick Osborn at Nov 18, 2012 at 5:32 pm

    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.
  • Rajulvora at Nov 18, 2012 at 6:13 pm
    From official documentation:

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


    On Sun, Nov 18, 2012 at 8:55 AM, Nick Osborn 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.
  • Jcbollinger at Nov 19, 2012 at 2:34 pm

    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.
  • Rajulvora at Nov 19, 2012 at 5:31 pm
    Ok, got it. Thanks for that clarification. I totally missed that
    distinction.

    Rajul

    On Mon, Nov 19, 2012 at 6:34 AM, jcbollinger 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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedNov 16, '12 at 12:01a
activeNov 19, '12 at 5:31p
posts10
users3
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase