Hi Tim,
Tim Bell <tim.b...@cern.ch> wrote:
Adam,
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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
