Open Stack

>> 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?

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

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.

At Your Service,

Mark T. Voelker
OpenStack Architect

On Mar 25, 2015, at 5:29 PM, Mark Collier <mark at openstack.org> wrote:

> Yeah i think that would address it. 
> 
> 
> 
> 
> 
>> On Mar 25, 2015, at 4:21 PM, Rob Hirschfeld <rob at zehicle.com> wrote:
>> 
>>> On 03/25/2015 03:54 PM, Mark Voelker wrote:
>>> Both are widely enough deployed that it wouldn’t make sense for us to list one and not the other (thus restricting several long-time clouds from being able to use the trademark) but we also don’t have an “either/or” concept as of now and it wouldn’t be practical to expect clouds/products to supply both capabilities either.
>> I'd suggest that we have the Components concept for this. It's perfectly reasonable to have the Nova-Net and Neutron as Components. Components have distinct lists of capabilities that could overlap (e.g.: they should all require Keystone capabilities). From that perspective, we also do have the flexibility to define the Platform as requiring Nova-Net or Neutron.
>> 
>> 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).
>> 
>> _______________________________________________
>> Defcore-committee mailing list
>> Defcore-committee at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
> 
> _______________________________________________
> Defcore-committee mailing list
> Defcore-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee