<div dir="ltr">Hi,<div><br></div><div>I think filing the cross-project bug is ok. I've already uploaded patch for sahara jobs - <a href="https://review.openstack.org/217751">https://review.openstack.org/217751</a></div><div><br></div><div>Thanks.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 26, 2015 at 6:46 PM, Chris Dent <span dir="ltr"><<a href="mailto:chdent@redhat.com" target="_blank">chdent@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
[If any of this is wrong I hope someone from infra or qa will<br>
correct me. Thanks. This feels a bit cumbersome so perhaps there is<br>
a way to do it in a more automagic fashion[1].]<br>
<br>
In the near future ceilometer will be removing itself from the core<br>
of devstack and using a plugin instead. This is to allow more<br>
independent control and flexibility.<br>
<br>
These are the related reviews:<br>
<br>
* remove from devstack: <a href="https://review.openstack.org/196383" rel="noreferrer" target="_blank">https://review.openstack.org/196383</a><br>
* updated jenkins jobs: <a href="https://review.openstack.org/196446" rel="noreferrer" target="_blank">https://review.openstack.org/196446</a><br>
<br>
If a project is using ceilometer in its gate jobs then before the<br>
above can merge adjustments need to be made to make sure that the<br>
ceilometer plugin is enabled. The usual change for this would be a<br>
form of:<br>
<br>
  DEVSTACK_LOCAL_CONFIG+=$'\n'"enable_plugin ceilometer git://<a href="http://git.openstack.org/openstack/ceilometer" rel="noreferrer" target="_blank">git.openstack.org/openstack/ceilometer</a>"<br>
<br>
I'm not entirely clear on what we will need to do coordinate this,<br>
but it is clear some coordination will need to be done such that<br>
ceilometer remains in devstack until everything that is using<br>
ceilometer in devstack is ready to use the plugin.<br>
<br>
A grep through the jenkins jobs suggests that the projects in<br>
$SUBJECT (rally, sahara, heat, congress, tripleo) will need some<br>
changes.<br>
<br>
How shall we proceed with this?<br>
<br>
One option is for project team members[2] to make a stack of dependent<br>
patches that are dependent on 196446 above (which itself is dependent<br>
on 196383) so that it all happens in one fell swoop.<br>
<br>
What are the other options?<br>
<br>
Thanks for your input.<br>
<br>
[1] That is, is it worth considering adding functionality to<br>
devstack's sense of "enabled" such that if a service is enabled<br>
devstack knows how to look for a plugin if it doesn't find local<br>
support. With the destruction of the stackforge namespace we can<br>
perhaps guess the git URL for plugins?<br>
<br>
[2] Or me if that's better.<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Chris Dent tw:@anticdent freenode:cdent<br>
<a href="https://tank.peermore.com/tanks/cdent" rel="noreferrer" target="_blank">https://tank.peermore.com/tanks/cdent</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Sincerely yours,<br>Sergey Lukjanov<br>Sahara Technical Lead<br>(OpenStack Data Processing)<br>Principal Software Engineer<br>Mirantis Inc.</div>
</div>