Puppet users - May 2012 - modifying declared user/group types without resorting to inheritance?

Hello,

I have number of classes that deal with user management and I''ve run
into a
snag with needing to extend/modify either the user or group types.  I''m
using theforeman as an ENC. 

The class structure I have is something like the following.

users::common
users::dev
users::prod
etc...

users::{dev, prod} do not use inheritance.  Almost all node include 
users::common.  Some include users::common and user::dev, while others 
include users::common and users::prod.  No node presently includes all 
three classes but it''s desirable for that to be possible.  The class 
users::common contains user and group types (actually virtual resources but 
that detail shouldn''t matter...) and is machine generated. 
users::{dev,
prod} define additional users and groups.  The difficulty is that I have 
users in  ::common that need to be added a group a group in ::dev but not 
be a member of that group in prod.  This is complicated by the fact that 
this group is declared in ::common.   Am I left with having to do class 
inheritence here?  I''d like to avoid that if possible as that would 
preclude ::dev and ::prod being included on the same node.  I understand 
that heira is good at dealing with this sort of situation.  Is there some 
magic way of looking up data in heira without dumping foreman as an enc?

Cheers,

-Josh

--

-- 
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/-/D8P7pqBY948J.
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 Wed, May 16, 2012 at 9:51 PM, Joshua Hoblitt <jhoblitt@cpan.org>
wrote:
> Hello,
>
> I have number of classes that deal with user management and I''ve
run into a
> snag with needing to extend/modify either the user or group types. 
I''m
> using theforeman as an ENC.
>
> The class structure I have is something like the following.
>
> users::common
> users::dev
> users::prod
> etc...
>
> users::{dev, prod} do not use inheritance.  Almost all node include
> users::common.  Some include users::common and user::dev, while others
> include users::common and users::prod.  No node presently includes all
three
> classes but it''s desirable for that to be possible.  The class
users::common
> contains user and group types (actually virtual resources but that detail
> shouldn''t matter...) and is machine generated.  users::{dev, prod}
define
> additional users and groups.  The difficulty is that I have users in
> ::common that need to be added a group a group in ::dev but not be a member
> of that group in prod.  This is complicated by the fact that this group is
> declared in ::common.   Am I left with having to do class inheritence here?
> I''d like to avoid that if possible as that would preclude ::dev
and ::prod
> being included on the same node.  I understand that heira is good at
dealing
> with this sort of situation.  Is there some magic way of looking up data in
> heira without dumping foreman as an enc?
Check out: https://github.com/torrancew/hiera-foreman

As I understand it lets you map heira variables to foreman params.

Cheers,
Brian

-- 
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 May 16, 8:51 pm, Joshua Hoblitt <jhobl...@cpan.org>
wrote:
> The class structure I have is something like the following.
>
> users::common
> users::dev
> users::prod
> etc...
>
> users::{dev, prod} do not use inheritance.  Almost all node include
> users::common.  Some include users::common and user::dev, while others
> include users::common and users::prod.  No node presently includes all
> three classes but it''s desirable for that to be possible.  The
class
> users::common contains user and group types (actually virtual resources but
> that detail shouldn''t matter...) and is machine generated.
 users::{dev,
> prod} define additional users and groups.  The difficulty is that I have
> users in  ::common that need to be added a group a group in ::dev but not
> be a member of that group in prod.  This is complicated by the fact that
> this group is declared in ::common.   Am I left with having to do class
> inheritence here?

No.

> I''d like to avoid that if possible

Very reasonable, but

> as that would
> preclude ::dev and ::prod being included on the same node.

why do you say that?  That might become the case if you discovered
other, similar requirements, especially going the other direction, but
you could do what you describe with inheritance without
preventing ::dev and ::prod from both being included.  Example:

class users::common {
  user {
    ''alice'': uid => 501, gid => 501;
    ''bob'': uid => 502, gid => 502;
  }

  group { ''special-access'': gid => 99 }
}

class users::dev inherits users::common {
  user { ''charlie'': uid => 601 }
  Group[''special-access''] {
    members => ''bob''
  }
}

class users::prod {
  user { ''dave'': uid => 701 }
}

node dev1 {
  # nothing wrong with including both these:
  include ''users::common''
  include ''users::dev''
}

node prod1 {
  include ''users::common''
  include ''users::prod''
}

# shouldn''t be a problem:
node hybrid {
  include ''users::common''
  include ''users::dev''
  include ''users::prod''
}
>  I understand
> that heira is good at dealing with this sort of situation.  Is there some
> magic way of looking up data in heira without dumping foreman as an enc?

No magic is required just for that.  Hiera and Foreman themselves are
pretty much orthogonal.  A bit of magic might be needed if you want to
use Foreman to set values that Hiera will provide, but that''s what
hiera-foreman claims to do.


John

-- 
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 Thursday, May 17, 2012 7:11:18 AM UTC-7, jcbollinger
wrote:
>
>
>
> On May 16, 8:51 pm, Joshua Hoblitt <jhobl...@cpan.org> wrote: 
>
> > as that would 
> > preclude ::dev and ::prod being included on the same node. 
>
>
> why do you say that?  That might become the case if you discovered 
> other, similar requirements, especially going the other direction, but 
> you could do what you describe with inheritance without 
> preventing ::dev and ::prod from both being included.  Example: 
>
> class users::common { 
>   user { 
>     ''alice'': uid => 501, gid => 501; 
>     ''bob'': uid => 502, gid => 502; 
>   } 
>
>   group { ''special-access'': gid => 99 } 
> } 
>
> class users::dev inherits users::common { 
>   user { ''charlie'': uid => 601 } 
>   Group[''special-access''] { 
>     members => ''bob'' 
>   } 
> } 
>
> class users::prod { 
>   user { ''dave'': uid => 701 } 
> } 
>
> [snip] 
> # shouldn''t be a problem: 
> node hybrid { 
>   include ''users::common'' 
>   include ''users::dev'' 
>   include ''users::prod'' 
> } 
>
> In order for this to work for me both ::dev & ::prod would need to
inherit
from ::common and extend the same group definition.  Without some sort of 
multiple inheritance support that would end up with a Group type declared 
twice or am I missing something?
>  I understand 
> > that heira is good at dealing with this sort of situation.  Is there 
> some 
> > magic way of looking up data in heira without dumping foreman as an
enc?
>
>
> No magic is required just for that.  Hiera and Foreman themselves are 
> pretty much orthogonal.  A bit of magic might be needed if you want to 
> use Foreman to set values that Hiera will provide, but that''s what
> hiera-foreman claims to do. 
>
> It sounds like I need to look further into Hiera...
-Josh

--

-- 
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/-/9Bo_IP28_sUJ.
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 Thu, May 17, 2012 at 8:44 PM, Joshua Hoblitt <jhoblitt@cpan.org> wrote:
>
>
> On Thursday, May 17, 2012 7:11:18 AM UTC-7, jcbollinger wrote:
>
>>
>>
>> On May 16, 8:51 pm, Joshua Hoblitt <jhobl...@cpan.org> wrote:
>>
>> > as that would
>> > preclude ::dev and ::prod being included on the same node.
>>
>>
>> why do you say that?  That might become the case if you discovered
>> other, similar requirements, especially going the other direction, but
>> you could do what you describe with inheritance without
>> preventing ::dev and ::prod from both being included.  Example:
>>
>> class users::common {
>>   user {
>>     ''alice'': uid => 501, gid => 501;
>>     ''bob'': uid => 502, gid => 502;
>>   }
>>
>>   group { ''special-access'': gid => 99 }
>> }
>>
>> class users::dev inherits users::common {
>>   user { ''charlie'': uid => 601 }
>>   Group[''special-access''] {
>>     members => ''bob''
>>   }
>> }
>>
>> class users::prod {
>>   user { ''dave'': uid => 701 }
>> }
>>
>> [snip]
>
>> # shouldn''t be a problem:
>> node hybrid {
>>   include ''users::common''
>>   include ''users::dev''
>>   include ''users::prod''
>> }
>>
>> In order for this to work for me both ::dev & ::prod would need to
> inherit from ::common and extend the same group definition.  Without some
> sort of multiple inheritance support that would end up with a Group type
> declared twice or am I missing something?
>
> >  I understand
>> > that heira is good at dealing with this sort of situation.  Is
there
>> some
>> > magic way of looking up data in heira without dumping foreman as
an
>> enc?
>>
>>
>> No magic is required just for that.  Hiera and Foreman themselves are
>> pretty much orthogonal.  A bit of magic might be needed if you want to
>> use Foreman to set values that Hiera will provide, but that''s
what
>> hiera-foreman claims to do.
>>
>> It sounds like I need to look further into Hiera...
>
another option would be to consider foreman smart variables.

Ohad
>
> -Josh
>
> --
>
> --
> 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/-/9Bo_IP28_sUJ.
>
> 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.

On May 17, 12:44 pm, Joshua Hoblitt <jhobl...@cpan.org>
wrote:
> In order for this to work for me both ::dev & ::prod would need to
inherit
> from ::common and extend the same group definition.  Without some sort of
> multiple inheritance support that would end up with a Group type declared
> twice or am I missing something?
Yes.  Look at my example again: only ::dev inherits from ::common.  As
I said, if you come up with requirements for ::prod to also
override ::common then it gets dicey and maybe breaks altogether, but
for what you actually described, there is no need for that.

As for "multiple inheritance", I guess you mean declaring more than
one subclass of the same class on one node (whereas the term more
conventionally refers to refers to a class having more than one direct
superclass).  I think I remember Puppet allowing multiple subclasses
when last I tested, so long as they do not override the same
resources.  It certainly permitted subclasses of subclasses.

With that said, inheritance is probably not the best solution to this
problem.  Personally, I would not even consider it unless I expected
the override to be a one-off, or unless I needed a quick, temporary
solution.


John

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