Hi Tim,

Tim Bell <tim.b...@cern.ch> wrote:

Personally, I would prefer the approach where the OpenStack resource agents are part of the repository in which they are used.

Thanks for chipping in. Just checking - by this you mean the resource-agents rather than openstack-resource-agents, right? Obviously the agents aren't usable as standalone components in either context, without a cloud's worth of dependencies including Pacemaker.
This is also the approach taken in other open source projects such as Kubernetes and avoids the inconsistency where, for example, Azure resource agents are in the Cluster Labs repository but OpenStack ones are not.

Right. I suspect there's no clearly defined scope for the resource-agents repository at the moment, so it's probably hard to say "agent X belongs here but agent Y doesn't". Although has been alluded to elsewhere in this thread, that in itself could be problematic in terms of the repository constantly growing.
This can mean that people miss there is OpenStack integration available.

Yes, discoverability is important, although I think we can make more impact on that via better documentation (another area I am struggling to make time for ...)
This does not reflect, in any way, the excellent efforts and results made so far. I don't think it would negate the possibility to include testing in the OpenStack gate since there are other examples where code is pulled in from other sources.

There are a number of technical barriers, or at very least inconveniences, here - because the resource-agents repository is hosted on GitHub, therefore none of the normal processes based around Gerrit apply. I guess it's feasible that since Zuul v3 gained GitHub support, it could orchestrate running OpenStack CI on GitHub pull requests, although it would have to make sure to only run on PRs which affect the OpenStack RAs, and none of the others. Additionally, we'd probably need tags / releases corresponding to each OpenStack release, which means polluting a fundamentally non-OpenStack-specific repository with OpenStack-specific metadata. I think either way we go, there is ugliness. Personally I'm still leaning towards continued use of openstack-resource-agents, but I'm happy to go with the majority consensus if we can get a semi-respectable number of respondees :-)
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to