[ClusterLabs Developers] [openstack-dev] [HA] future of OpenStack OCF resource agents (was: resource-agents v4.2.0)

[Ken Gaillot]

On Thu, 2018-10-25 at 18:09 +0100, Adam Spiers wrote:
> Hi Tim,
> 
> Tim Bell <Tim.Bell at 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 :-) 

FYI there is further discussion happening on the PR:

https://github.com/ClusterLabs/resource-agents/pull/1147

I think we have multiple issues we're trying to solve:

1. Discoverability in terms of users knowing what agents may be
available for any given purpose

2. Organization of installed agents into categories for display by
tools (especially GUIs)

3. Packaging of agents in a way that avoids dragging in unnecessary
dependencies

4. Then the original problem that the provider field solved, which was
to allow unrelated organizations to create their own sets of resource
agents, whether for internal use or public distribution. This has
become less of a problem since the consolidation of the cluster stack,
but is still useful, especially for local customizations of stock
agents.

#1 and #4 conflict to some extent. I think the whole point of a
standard (OCF in this case) is to not require a central authority, so
we should allow for independent providers who may not be closely tied
into the ClusterLabs community. But we don't want users to be lost in a
sea of unconnected repos, either.

I don't see an obvious solution for #1 (discoverability). We could
document known other repos in the resource-agents README as some have
suggested, or some other common location such as clusterlabs.org, but
will users know to look there?

For #2 (organization), some possibilities are:

- add a category field in the RA meta-data
- extend the RA naming to include a category, e.g.
ocf:clusterlabs:networking/IPaddr2
- repurpose the provider field as a category name

The first is cleaner and works unchanged with existing tools, but it
requires any tool that wants to use it to read all agents' meta-data at
start-up. I'm not sure if that's reasonable or not. The second allows
more efficient listing (just regular old subdirectories) but may
require changes to the standard as well existing tools. I'm not fond of
the third, because it then loses the ability to solve #4. Of course I'm
open to other possibilities too :-)

I'm not sure how much a problem #3 (packaging) is. Just because an
agent manipulates service X doesn't mean it needs to depend on the X
package; we could limit dependencies to the interpreters used. On the
other hand, using application-specific Python libraries, for example,
would reasonably be a package dependency that we wouldn't want to
require for all installations. So, maybe the resource-agents package
could separate into resource-agents-core (for all agents with minimal
dependencies), and separate resource-agents-X packages for those with
highly specific library dependencies. This would all be within the
ClusterLabs resource-agents project.

I like keeping the provider field for #4 (independent distributors),
though I'm open to changing it.
-- 
Ken Gaillot <kgaillot at redhat.com>