Open Stack

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 :-)