> -----Original Message----- > From: Emilien Macchi [mailto:emil...@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 <vandit...@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- > requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev