Open Stack

Hi All,



On Fri, May 13, 2016 at 12:28 PM, Michal Adamczyk <vanditboy at gmail.com>
wrote:

> On Fri, May 13, 2016 at 9:42 AM, Michal Adamczyk <vanditboy at gmail.com>
> wrote:
>
>>
>>
>> On Thu, May 12, 2016 at 2:14 PM, Michal Adamczyk <vanditboy at gmail.com>
>> wrote:
>>
>>>
>>> On Wed, May 11, 2016 at 7:47 PM, Hongbin Lu <hongbin.lu at huawei.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> > -----Original Message-----
>>>> > From: Emilien Macchi [mailto:emilien at 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 <vanditboy at 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
>>
>>
> 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-
>>>> > request at 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-request at 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
>



-- 
Kind regards,

Michal Adamczyk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160822/12243a47/attachment-0001.html>