how to avoid duplicate types (i.e. users)

[Jason Edgecombe]

I have a defined type buildbot::slave::instance, which has a username as
a parameter. The instance type has a "user" instance to create the
specified user. This works fine, but each buildbot::slave::instance must
use a different user. Passing the same user gives an error that the user
is defined twice.

How do I automatically create a user (including home directory and cp of
/etc/skel) as triggered by buildbot::slave::instance, and avoid the
duplicate user errors?

The source of the problem files is at:
https://github.com/edgester/puppet-buildbot/blob/master/manifests/user_homedir.pp
https://github.com/edgester/puppet-buildbot/blob/master/manifests/slave/instance.pp

Thanks,
Jason

[Schofield]

How do I automatically create a user (including home directory and cp of
/etc/skel) as triggered by buildbot::slave::instance, and avoid the
duplicate user errors?

If I understand right you want all buildbot::slave::instance types to have the same user.  The special little flowers section of the defined types documentation addresses this.
http://docs.puppetlabs.com/learning/definedtypes.html#special-little-flowers

If I did not understand correctly please clarify what you want the final state to look like.

[Jason Edgecombe]

correct, I want the option of having multiple buildbot::slave::instance
types to use the same user by defining the buildbot::user_homedir {
'username': } type.

Either I don't understand, or the 'special little flowers' document
doesn't cover what I want.

in essence, I want something like the following:
======
define buildbot::slave::instance {
...
require => Buildbot::User_homedir['foo']

if !defined buildbot::user_homedir{ 'foo': } then
userdir_homedir{ 'foo': }
fi

} # end buildbot::slave::instance
======

[col_s]

You may find virtual resources useful for this. Define the user home directory resources as virtual resources (within a separate class), and then" realize" them in your buildbot::slave::instance type.

http://docs.puppetlabs.com/guides/virtual_resources.html

[jcbollinger]

On Monday, December 31, 2012 7:51:37 PM UTC-6, Jason Edgecombe wrote:

On 12/31/2012 07:20 PM, Schofield wrote:
>
>> How do I automatically create a user (including home directory and cp of
>> /etc/skel) as triggered by buildbot::slave::instance, and avoid the
>> duplicate user errors?
>>
> If I understand right you want all buildbot::slave::instance types to have
> the same user.  The special little flowers section of the defined types
> documentation addresses this.
> http://docs.puppetlabs.com/learning/definedtypes.html#special-little-flowers
>
> If I did not understand correctly please clarify what you want the final
> state to look like.
correct, I want the option of having multiple buildbot::slave::instance
types to use the same user by defining the buildbot::user_homedir {
'username': } type.

If multiple Buildbot::Slave::Instance resources may rely on the same buildbot::user_homedir resource, then it follows that the slave instances do not own the user resource.  Therefore, they should rely on the user being declared for them (once, centrally) instead of declaring the user themselves.

 

in essence, I want something like the following:
======
define buildbot::slave::instance {
...
   require => Buildbot::User_homedir['foo']

if !defined buildbot::user_homedir{ 'foo': } then
   userdir_homedir{ 'foo': }
fi

} # end buildbot::slave::instance
======

That's a bit confusing, but it looks like you want to declare slave instances like this:

buildbot::slave::instance { 'instance1':
  # ...

  require => Buildbot::User_homedir['foo']
}

where Buildbot::User_homedir['foo'] is to be declared by the definition body if it is not already declared.  That cannot work, because when it parses that declaration, the parser will reject the resource reference Buildbot::User_homedir['foo'] if no declaration for that resource has yet been parsed.

Also, your proposed use of defined() is considered harmful (along with almost every other use of that function).

There are various robust ways that you might approach the situation, but you have presented too narrow a view of the problem for me really to advise you on which way to go.

This feels like a problem looking for a data-driven solution, but that might be overkill.

On the other hand, if all the Buildbot::User_homedir instances that might be needed can be enumerated, then perhaps it would be best to declare the all virtually, first, and realize the one needed at the point where you declare each buildbot::slave::instance.

There are other possibilities and variations.


John