Hi, On 2 Oct 2015, iberezovs...@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 > <iudoviche...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sofer Athlan-Guyot __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev