On Thu, 2018-10-25 at 18:09 +0100, Adam Spiers wrote: > 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 :-)
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 <kgail...@redhat.com> _______________________________________________ Developers mailing list Developers@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/developers
