[OpenStack-DefCore] How to Deal With Overlapping Capabilities

Rob Hirschfeld rob at zehicle.com
Thu Mar 26 15:35:01 UTC 2015


On 03/26/2015 09:17 AM, Mark Voelker wrote:
>>> the Platform as requiring Nova-Net or Neutron.
> And the same OR concept would apply to the Component License Programs?  E.g. if I want to apply for the “OpenStack Powered Compute” designation I still need networking, so we’d have an OR there as well presumably?
It's up to the Foundation in how they would allow naming.  I suspect 
they could accommodate.

>>> That type of "or" can be accommodated at the Component/Platform level without any new language (but may need some tweaking in the JSON schema where we define required components).
>
> Just to flesh this out a bit, I think you’re proposing that we could have a 2015.someday DefCore spec that says something like:
>
> Platform Components
> ==============================
> Required: Compute and Object, nova-networking OR Neutron
>
> Correct?  I would assume that we’d also want a similar construct for designated sections, right?  Otherwise we’d be allowing a case where it’s ok to replace the networking in your cloud with something that’s not OpenStack (maybe that’s a use case we want to allow, but let’s assume for purposes of discussion that it isn't).  So we’d need something like:
Yes
> Designated Sections
> ==============================
>
> The following designated sections apply to the same releases as
> this specification.
>
> * Nova is by default designated except scheduler, filter, drivers, API
>    extensions and networking.  If the applicant selects the nova-networking
>    component, nova networking is designated as well.
> * If the applicant selects the Neutron component, Neutron is designated
>    except drivers blahblahblah.
>
> So far so good, except that section D3 of the process doc states that we can’t have designated sections without also requiring capabilities for those projects.  What would you envision the capabilities sections looking like for the OR case?
>
> I would agree that the JSON schema is going to need changes in order to express an OR as well.  When we design that, we should probably keep in mind that it’s conceivable (though perhaps unlikely in reality as we might have a hard time with the “widely deployed” criteria) that we might have more than two components in an OR.  As a strawman: imagine a world where Ceilometer, Monasca, and StackTach were all in the OpenStack namespace and had overlapping functionality that we wanted included in DefCore.
Sections can be squishy - I'm less worried about trying to be exact here 
because it's subjective at the end of the day.  IMHO We are trying to 
express intent more than police code use.



More information about the Defcore-committee mailing list