Open Stack

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
>
>
>>
>>> >
>>> > >  - 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-
>>> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160513/8bc3244c/attachment.html>