[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