modifying declared user/group types without resorting to inheritance?

51 views
Skip to first unread message

Joshua Hoblitt

unread,
May 16, 2012, 9:51:16 PM5/16/12
to puppet...@googlegroups.com
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

--

Brian Gupta

unread,
May 17, 2012, 12:07:12 AM5/17/12
to puppet...@googlegroups.com
Check out: https://github.com/torrancew/hiera-foreman

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

Cheers,
Brian

jcbollinger

unread,
May 17, 2012, 10:11:18 AM5/17/12
to Puppet Users


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

Joshua Hoblitt

unread,
May 17, 2012, 1:44:27 PM5/17/12
to puppet...@googlegroups.com


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

--

Ohad Levy

unread,
May 17, 2012, 2:03:58 PM5/17/12
to puppet...@googlegroups.com
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...@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.

jcbollinger

unread,
May 18, 2012, 9:07:19 AM5/18/12
to Puppet Users


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
Reply all
Reply to author
Forward
0 new messages