Open Stack

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