[cross-posting to openstack-dev]

Oyvind Albrigtsen <oalbr...@redhat.com> wrote:
ClusterLabs is happy to announce resource-agents v4.2.0.
Source code is available at:

The most significant enhancements in this release are:
- new resource agents:


- openstack-cinder-volume
- openstack-floating-ip
- openstack-info

That's an interesting development.

By popular demand from the community, in Oct 2015 the canonical
location for OpenStack-specific resource agents became:


as announced here:


However I have to admit I have done a terrible job of maintaining it
since then.  Since OpenStack RAs are now beginning to creep into
ClusterLabs/resource-agents, now seems a good time to revisit this and
decide a coherent strategy.  I'm not religious either way, although I
do have a fairly strong preference for picking one strategy which both
ClusterLabs and OpenStack communities can align on, so that all
OpenStack RAs are in a single place.

I'll kick the bikeshedding off:

Pros of hosting OpenStack RAs on ClusterLabs

- ClusterLabs developers get the GitHub code review and Travis CI
 experience they expect.

- Receive all the same maintenance attention as other RAs - any
 changes to coding style, utility libraries, Pacemaker APIs,
 refactorings etc. which apply to all RAs would automatically
 get applied to the OpenStack RAs too.

- Documentation gets built in the same way as other RAs.

- Unit tests get run in the same way as other RAs (although does
 ocf-tester even get run by the CI currently?)

- Doesn't get maintained by me ;-)

Pros of hosting OpenStack RAs on OpenStack infrastructure

- OpenStack developers get the Gerrit code review and Zuul CI
 experience they expect.

- Releases and stable/foo branches could be made to align with
 OpenStack releases (..., Queens, Rocky, Stein, T(rains?)...)

- Automated testing could in the future spin up a full cloud
 and do integration tests by simulating failure scenarios,
 as discussed here:


 That said, that is still very much work in progress, so
 it remains to be seen when that could come to fruition.

No doubt I've missed some pros and cons here.  At this point
personally I'm slightly leaning towards keeping them in the
openstack-resource-agents - but that's assuming I can either hand off
maintainership to someone with more time, or somehow find the time
myself to do a better job.

What does everyone else think?  All opinions are very welcome,

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to