On Wed, May 11, 2016 at 7:47 PM, Hongbin Lu <hongbin...@huawei.com> wrote:
> > > > -----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! > > > 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- > > 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 > -- Kind regards, Michal Adamczyk
__________________________________________________________________________ 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