On Fri, May 13, 2016 at 9:42 AM, Michal Adamczyk <vandit...@gmail.com> wrote:
> > > 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 :) >> > 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- >>> > 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 > -- 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
