Open Stack

On Thu, May 12, 2016 at 2:14 PM, Michal Adamczyk <vanditboy at gmail.com>
wrote:

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

Bug created: https://bugs.launchpad.net/puppet-magnum/+bug/1581372


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



-- 
Kind regards,

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