[openstack-dev] [puppet] Running Debian packages on top of Trusty

Sofer Athlan-Guyot sathlang at redhat.com
Tue Oct 20 12:50:58 UTC 2015


Thomas Goirand <zigo at debian.org> writes:

> On 10/07/2015 12:22 PM, Sofer Athlan-Guyot wrote:
>> Hi,
>> 
>> On 2 Oct 2015, iberezovskiy at mirantis.com wrote:
>> 
>>> Hello,
>>>
>>> thanks for bringing up this topic, that's what I wanted to discuss on
>>> next puppet-openstack irc meeting.
>>>
>>> So, user case is following: users may want to install Debian packages
>>> on Ubuntu host or vice versa,
>>> the same problem can probably happen with CentOS, RHEL, Fedora; or
>>> users may use non-official
>>> package repositories with their own package (service) naming strategy
>>> and so on.
>>> Current situation in puppet modules is following that package and
>>> service names are (let's say)
>>> hardcoded in 'params' class (e.g. [0]). But in situation that I've
>>> described it won't work.
>>> Puppet will try to use Ubuntu names on Ubuntu host and it won't allow
>>> to install and work with
>>> Debian packages.
>>>
>>> I've researched puppet modules and found an interesting example which
>>> can help to solve
>>> this issue. It's implemented in puppetlabs mongodb module:
>>> they have 'globals' class [1] that allows to override most part of
>>> parameters from 'params' class [2].
>>>
>>> So, I've decided to rework this soltuion and use it in OpenStack
>>> modules. As result I got draft patch
>>> for ceilometer module [3]. By default we use parameters from 'params'
>>> class, but every parameter
>>> can be now overridden using 'globals' class.
>>>
>>> OpenStack Puppet team, what do you think about this solution?
>> 
>> Here is another track that you may follow.  For instance, to have access
>> to the code variables there
>> https://github.com/openstack/puppet-nova/blob/master/manifests/params.pp#L100-L107
>> on an Ubuntu system you could just do this :
>> 
>> env FACTER_operatingsystem=Debian puppet agent -t 
>> 
>> You can override any facts on a system using the environment variable
>> "FACTER_<fact_name>"
>> 
>> For instance on my system:
>> 
>>   $ facter -p 2>/dev/null | grep osfamily
>>   osfamily => RedHat
>> 
>>   $ env FACTER_osfamily=Ubuntu facter -p 2>/dev/null | grep osfamily                                                                                    
>>   osfamily => Ubuntu
>> 
>> Is this method wouldn't be enough for your purpose ?
>>
>> Check https://puppetlabs.com/blog/facter-part-1-facter-101 for more
>> information.
>
> I'm not sure, as I'm not a puppet specialist...
>
> We don't want to overwrite the parameter about the distribution, because
> some are really dependent of the distro. For example, the libvirt unix
> group is libvirt in Debian, but libvirtd in Ubuntu. This difference has
> to stay depending on the OS type, which we absolutely do not want to
> overwrite. So we do want variables for the *OpenStack package type*
> which is running on top of the operating system.
>
> Will what you wrote above help in this regard?

Well, it seems it would do.  I check the package provider and it doesn't
really care if it's debian or ubuntu, as it checks osfamily.
Furthermore, In your example the user should be set by the package and
not by puppet.  Actually all parameters regarding puppet activity should
be encapsulated in the params file.

So my bet is that running the above would give you what you need.  Let
me know if it worked or if there are limitations in this solution that
makes the case for more code. 

[sorry for the very late reply]

>
> Cheers,
>
> Thomas Goirand (zigo)
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Sofer Athlan-Guyot



More information about the OpenStack-dev mailing list