Hi All,
On Fri, May 13, 2016 at 12:28 PM, Michal Adamczyk <[email protected]> wrote: > On Fri, May 13, 2016 at 9:42 AM, Michal Adamczyk <[email protected]> > wrote: > >> >> >> On Thu, May 12, 2016 at 2:14 PM, Michal Adamczyk <[email protected]> >> wrote: >> >>> >>> On Wed, May 11, 2016 at 7:47 PM, Hongbin Lu <[email protected]> >>> wrote: >>> >>>> >>>> >>>> > -----Original Message----- >>>> > From: Emilien Macchi [mailto:[email protected]] >>>> > 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 <[email protected] >>>> > >>>> > 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 >> >> > Hi, As the above bug has been fixed how we can merge it to Mitaka and RDO/Ubuntu? Or we don't do it for Mitaka and leave it as it is now... > >>>> > >>>> > > - 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. >>> >>> Any update from mjblack or does this topic of lbaasv2 died? I have created a bug for it https://bugs.launchpad.net/bugs/1583024 but appears that it was closed without any explanation. >>>> > >>>> > > - 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 :) >>> >> Quest here is done - glance client shows it a separate property for > "os_distro" but in fact the image in glance_image resource type is added > via openstack client so all we need here is > > glance_image { 'fedora23-atomic': > ensure => present, > container_format => 'bare', > disk_format => 'qcow2', > is_public => 'yes', > source => "${repourl}/Fedora-Cloud- > Atomic-23-20160420.x86_64.qcow2", > properties => "os_distro='fedora-atomic'" > } > > So at the end glance image-show <id>: > +------------------+--------------------------------------+ > | Property | Value | > +------------------+--------------------------------------+ > | checksum | 7466b305e32ae83e438c592e347d59fb | > | container_format | bare | > | created_at | 2016-05-13T10:55:59Z | > | disk_format | qcow2 | > | id | a759c9e3-ae35-4b39-b24d-d887f12ec305 | > | min_disk | 0 | > | min_ram | 0 | > | name | fedora23-atomic | > | os_distro | fedora-atomic | > | owner | 0360f4288e834ab0afd3bac0f88123e4 | > | protected | False | > | s_distro | fedora-atomic | > | size | 497786368 | > | status | active | > | tags | [] | > | updated_at | 2016-05-13T11:06:12Z | > | virtual_size | None | > | visibility | public | > +------------------+--------------------------------------+ > No extra work to be done here. > >> >>> >>>> > 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- >>>> > [email protected]?subject:unsubscribe >>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> ____________________________________________________________ >>>> ______________ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: [email protected]?subject: >>>> unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>> >>> >>> >>> -- >>> Kind regards, >>> >>> Michal Adamczyk >>> >> >> >> >> -- >> Kind regards, >> >> Michal Adamczyk >> > > > > -- > Kind regards, > > Michal Adamczyk > -- Kind regards, Michal Adamczyk
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
