[openstack-dev] [puppet] Running Debian packages on top of Trusty
Sofer Athlan-Guyot
sathlang at redhat.com
Wed Oct 7 10:22:28 UTC 2015
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.
>
> Also, I'l bring up this topic on weekly puppet-openstack irc meeting.
>
> [0] -
> https://github.com/openstack/puppet-ceilometer/blob/master/manifests/params.
> pp
> [1] -
> https://github.com/puppetlabs/puppetlabs-mongodb/blob/master/manifests/globals.
> pp
> [2] -
> https://github.com/puppetlabs/puppetlabs-mongodb/blob/master/manifests/params.
> pp
> [3] - https://review.openstack.org/#/c/229918/
>
> 2015-10-02 15:43 GMT+03:00 Ivan Udovichenko
> <iudovichenko at mirantis.com>:
>
> Hello,
>
> On 10/02/2015 03:15 PM, Emilien Macchi wrote:
>> Hey Thomas,
>>
>> On 10/02/2015 04:33 AM, Thomas Goirand wrote:
>> [...]
>>> We also may need, at some point, to add the type mosdebian and
> moscentos
>>> to the list of supported package suite, as there still will be
> some
>>> differences between the upstream Debian or CentOS packages.
> What is the
>>> best way to add this variable values?
>>>
>>> Could you Puppet experts explain to me and my Mirantis
> colleagues again?
>>
>> So we partially discussed about that during our last weekly
> meeting [1]
>> and it come out the best way to support both Debian & Ubuntu are
> Puppet
>> conditionals, like we already have in place.
>>
>> [1]
>>
> http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_
> openstack.2015-09-29-15.00.html
>
> It does not solve the original problem. Let's say you want to
> install
> Debian packages on-top of Ubuntu, it will fail and you will have
> to use
> workarounds, for example in the params.pp [1] you have specified.
>
> [1]
> https://github.com/openstack/puppet-nova/blob/master/manifests/params.
> pp#L100-L107
>
>>
>> See the example with puppet-nova |2] where we use
> $::operatingsystem
>> fact [3] to detect if we're running Ubuntu or Debian.
>> If we're running Ubuntu, we take reference from UCA packaging.
> If
>> Debian, we take your work as reference.
>>
>> [2]
>>
> https://github.com/openstack/puppet-nova/blob/master/manifests/params.
> pp#L100-L107
>> [3] https://puppetlabs.com/facter
>>
>
> What we need is some variable which can override the decision
> which
> Operating System is used and thereby required packages will be
> installed. At least for Debian, that is what we really need.
> I'd be grateful if you look into it. Thank you.
>
>>
>>> Sorry that I didn't take notes about it and couldn't explain,
>>> Cheers,
>>>
>>> Thomas Goirand (zigo)
>>>
>>> P.S: Where may I find the best tutorial to get up-to-speed
> about puppet,
>>> so that I know what I'm talking about next time?
>>>
>>
>> I personally learnt (and am still learning) by using official
>> documentation [4], that I suggest you to start with.
>>
>> [4] http://docs.puppetlabs.com/puppet/
>>
>> Hope it helps,
>>
>>
>>
>
>
>> _
> ___________________________________________________________________
> ______
>> 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
>>
>
> ___________________________________________________________________
> _______
> 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