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 <[email protected]> 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 <[email protected]> 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: >> [email protected]?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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
