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

[Sofer Athlan-Guyot]

Thomas Goirand  writes:

> On 10/07/2015 12:22 PM, Sofer Athlan-Guyot wrote:
>> 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_"
>> 
>> 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-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

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

[Sofer Athlan-Guyot]

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_"

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
> :
>
> 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)
>> 

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

[Thomas Goirand]

On 10/07/2015 12:22 PM, Sofer Athlan-Guyot wrote:
> 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_"
> 
> 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?

Cheers,

Thomas Goirand (zigo)


__
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

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

[Alex Schultz]

On Fri, Oct 2, 2015 at 7:43 AM, Ivan Udovichenko
 wrote:
> 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.
>

There are a few alternatives for this issue.  The first one is that
the package names, etc can be overwritten in the code that pulls in
the OpenStack Puppet modules. We are already doing this today in our
openstack::nova::controler[0] code.  There is another alternative to
leverage a globals class that would allow for overriding params. I
know Ivan Berezovskiy is working on something[1] and I think he was
going to bring this up in the next irc meeting. His method would allow
for the overriding of the params where the current package & service
name calculations are being done.  Another alternative would be to
rework the params class to query hiera and default to the existing
params settings if not defined or something to that effect.

Basically I think the ask for OpenStack Puppet is allowing for
additional configuration options if a user does not want to leverage
the RDO or UCA packages or needs to specific alternative package &
service names.


Thanks,
-Alex


[0] 
https://github.com/stackforge/fuel-library/blob/deb63f09df23170207310f06ca4e12785d018dc2/deployment/puppet/openstack/manifests/nova/controller.pp#L399
[1] https://review.openstack.org/#/c/229918/


>>
>>> 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

__
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

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

[Ivan Berezovskiy]

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?

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 :

> 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
>



-- 
Thanks, Ivan Berezovskiy
MOS Puppet Team Lead
at Mirantis 

slack: iberezovskiy
skype: bouhforever
phone: + 7-960-343-42-46
__
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

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

[Ivan Udovichenko]

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

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

[Thomas Goirand]

Hi!

I've already discussed the topic on IRC with Emilien, however, it came
back within Mirantis, and as I don't have puppet skills, I was not able
to answer my colleagues correctly. Opening this thread is an attempt to
solve the issue once and for all. Hopefully, Emilien (and other puppet
guys) will be able to help.

Puppet currently takes decision based on the type of OS. For example,
"am I running under Debian?" will lead to install "nova-consoleproxy"
instead of nova-novncproxy or nova-spicehtml5proxy. However, when
rebuilding the Debian package, rebuilt and install over on Trusty, the
code path shouldn't depend on the operating system, but on the package type.

As MOS is becoming closer to the Debian packages (Mirantis is slowly
taking the path of contributing to Debian first, before integrating
packages into MOS), and as we would like to contribute in the upstream
puppet project as much as possible (as opposed to maintaining patches on
top), I'd like to know what's the best way to address this issue.

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?

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?

__
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

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

[Emilien Macchi]

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

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


> 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,
-- 
Emilien Macchi



signature.asc
Description: OpenPGP digital signature
__
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