On Thu, May 12, 2016 at 2:14 PM, Michal Adamczyk <vandit...@gmail.com> wrote:
> > 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? > 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- >> > 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 > -- 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
