[OpenStack-DefCore] How to Deal With Overlapping Capabilities
Chris Hoge
chris at openstack.org
Thu Mar 26 13:17:56 UTC 2015
This also overlaps a bit with versioned apis. Right now in Keystone we’re in the transition
from v2 to v3, and being able to have a decision on the required version or allowing
an ‘or’ on the versions will need to be addressed.
-Chris
> 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
More information about the Defcore-committee
mailing list