[openstack-dev] [puppet] magnum module - fixes/improvements for Mitaka release

Hongbin Lu hongbin.lu at huawei.com
Wed May 11 18:47:53 UTC 2016



> -----Original Message-----
> From: Emilien Macchi [mailto:emilien at redhat.com]
> Sent: May-11-16 9:44 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [puppet] magnum module -
> fixes/improvements for Mitaka release
> 
> On Wed, May 11, 2016 at 9:22 AM, Michal Adamczyk <vanditboy at gmail.com>
> wrote:
> > Hi,
> >
> > I am working on some fixes/improvements to puppet magnum module:
> > https://review.openstack.org/#/c/313293/
> 
> reviewed & commented. Almost good, excellent work here!
> 
> > I have found some issues while creating a bays with magnum
> > (https://bugs.launchpad.net/magnum/+bug/1575524) and I still need to
> > address few things:
> >
> >  - getting ID of the domain and user used to create trust (see my
> > patch set
> > 10 commit info). I have added domain class like in heat
> >
> https://review.openstack.org/#/c/313293/10/manifests/keystone/domain.p
> > p but the requirements is to get domain and user id, not a name.
> >    With names module fails to create trust...
> >
> >   Do you know if there is simple way to get user/domain ID via
> > existing keystone module?
> 
> We already had this issue in the paste, with neutron.conf that needed
> the tenant id from nova service, to manage notifications.
> It was a bug and it was fixed very early.
> Using ID in production deployments is:
> * hard to deploy, you need some magic that deploy the resource and get
> the id to write it somewhere
> * not flexible: everytime the resource change, the ID change and you
> need to update conf
> 
> So please fix Magnum to allow to use names (or maybe it's in Keystone,
> I haven't looked).
> Otherwise, you'll need to write a provider that will get the ID for you,
> look this example:
> https://github.com/openstack/puppet-
> tempest/blob/master/lib/puppet/provider/tempest_glance_id_setter/openst
> ack.rb

No problem from me. Please file a bug for that.

> 
> >  - as magnum requires lbaas and in Mitaka v2 is supported according
> to
> > the docs
> > http://docs.openstack.org/mitaka/networking-guide/adv-config-
> lbaas.htm
> > l we should add to neutron module or integration class directly the
> > following
> > changes:
> >
> >  class { '::neutron::agents::lbaas':
> >     interface_driver => $driver,
> >     debug            => true,
> >     enable_v1        => false,
> >     enable_v2        => true,
> >   }
> >
> >   neutron_config { 'service_providers/service_provider':
> >     value =>
> >
> 'LOADBALANCERV2:Haproxy:neutron_lbaas.drivers.haproxy.plugin_driver.Hap
> roxyOnHostPluginDriver:default';
> >   }
> >
> 
> Good to know, we recently did some work to stabilize puppet-neutron so
> we can deploy LBaaS v2, mjblack worked on it, maybe we can have a
> status about it here.

FYI, Magnum is using LBaaS v1. There is a blueprint [1] to migrate to v2, but the blueprint is not finished yet.

[1] https://blueprints.launchpad.net/magnum/+spec/magnum-lbaasv2-support

> 
> > - add a parameter to api.pp or creates a new class with this
> parameter
> > to manage certificate manager entry inside [certificates] section of
> > magnum.conf. Any preferences here?
> 
> Is it some entries for enabling SSL? Or related to Barbican?
> If related to barbican, I suggest we take the puppet-oslo approach, and
> create a Define resource with the common parameters that we'll have in
> our puppet modules for barbican section.
> And consume this class/define or write this code in api.pp makes sense
> to me, now.

It is related to Barbican.

> 
> >
> > - should we extend glance_image resource type to contains --os-distro
> > properties so we can add the fedora-atomic or core-os image via
> > glance_image resource type?
> 
> Definitely yes. Once we have all of this, we might want to create a 4th
> scenario in our integration CI with magnum + containers + barbican
> + neutron lbaas v2, so we test the full stack.
> 
> Question: how do you test Magnum, do you have Tempest tests?
> I see
> https://github.com/openstack/magnum/tree/master/magnum/tests/functional
> /tempest_tests
> kind of empty.
> Our CI is running Tempest, it would be very useful for us to have
> Magnum tests.
> 
> Thanks for your work here,
> --
> Emilien Macchi
> 
> _______________________________________________________________________
> ___
> 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



More information about the OpenStack-dev mailing list