Open Stack

I pushed a patch for Congress dependent on your patch.

https://review.openstack.org/#/c/217765/

Tim


On Thu, Aug 27, 2015 at 8:05 AM Sergey Lukjanov <slukjanov at mirantis.com>
wrote:

> Hi,
>
> I think filing the cross-project bug is ok. I've already uploaded patch
> for sahara jobs - https://review.openstack.org/217751
>
> Thanks.
>
> On Wed, Aug 26, 2015 at 6:46 PM, Chris Dent <chdent at redhat.com> wrote:
>
>>
>> [If any of this is wrong I hope someone from infra or qa will
>> correct me. Thanks. This feels a bit cumbersome so perhaps there is
>> a way to do it in a more automagic fashion[1].]
>>
>> In the near future ceilometer will be removing itself from the core
>> of devstack and using a plugin instead. This is to allow more
>> independent control and flexibility.
>>
>> These are the related reviews:
>>
>> * remove from devstack: https://review.openstack.org/196383
>> * updated jenkins jobs: https://review.openstack.org/196446
>>
>> If a project is using ceilometer in its gate jobs then before the
>> above can merge adjustments need to be made to make sure that the
>> ceilometer plugin is enabled. The usual change for this would be a
>> form of:
>>
>>   DEVSTACK_LOCAL_CONFIG+=$'\n'"enable_plugin ceilometer git://
>> git.openstack.org/openstack/ceilometer"
>>
>> I'm not entirely clear on what we will need to do coordinate this,
>> but it is clear some coordination will need to be done such that
>> ceilometer remains in devstack until everything that is using
>> ceilometer in devstack is ready to use the plugin.
>>
>> A grep through the jenkins jobs suggests that the projects in
>> $SUBJECT (rally, sahara, heat, congress, tripleo) will need some
>> changes.
>>
>> How shall we proceed with this?
>>
>> One option is for project team members[2] to make a stack of dependent
>> patches that are dependent on 196446 above (which itself is dependent
>> on 196383) so that it all happens in one fell swoop.
>>
>> What are the other options?
>>
>> Thanks for your input.
>>
>> [1] That is, is it worth considering adding functionality to
>> devstack's sense of "enabled" such that if a service is enabled
>> devstack knows how to look for a plugin if it doesn't find local
>> support. With the destruction of the stackforge namespace we can
>> perhaps guess the git URL for plugins?
>>
>> [2] Or me if that's better.
>>
>> --
>> Chris Dent tw:@anticdent freenode:cdent
>> https://tank.peermore.com/tanks/cdent
>>
>> __________________________________________________________________________
>> 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
>>
>
>
>
> --
> Sincerely yours,
> Sergey Lukjanov
> Sahara Technical Lead
> (OpenStack Data Processing)
> Principal Software Engineer
> Mirantis Inc.
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150827/5a7d5070/attachment-0001.html>