[openstack-dev] [ceilometer] [rally] [sahara] [heat] [congress] [tripleo] ceilometer in gate jobs
Chris Dent
chdent at redhat.com
Wed Aug 26 15:46:30 UTC 2015
[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
More information about the OpenStack-dev
mailing list