Open Stack

On Wed, May 11, 2016 at 7:47 PM, Hongbin Lu <hongbin.lu at huawei.com> wrote:

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

Thanks, another patch-set has been committed today.


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


Should I rise a bug for that or it's already done?


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


This indicates that we have to wait till this is finished for magnum and my
error:
ERROR: HEAT-E99001 Service neutron is not available for resource type
OS::Neutron::HealthMonitor, reason: Service endpoint not in service
catalog.\n']
might be related to the fact I have lbaasv2 enabled, correct? Magnum won't
work with Mitaka release as we don't have lbaasv1 there :/

So we wait for mjblack status about lbaasv2 switch for puppet-neutron.


> >
> > > - 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.
>
>
I am adding the class "certificates" with cert_manager_type parameter for
the moment and we can think about barbican resource.

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

Yes, good idea, this will be my next quest :)


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

Hmm, well, I don't have Tempest tests. I am testing it on some old
laptops/vms, wherever I can. I am just lunching baker/lint tests now to
check if no errors.
I will think about creating them when I finish all tasks in the patch I am
doing atm.

> Thanks for your work here,
>
No - thank you for the guidance and support here, I am very happy to work
on such great project!



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



-- 
Kind regards,

Michal Adamczyk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160512/c7cbd3ee/attachment.html>