[OpenStack-DefCore] COMMERCIAL:Re: How to Deal With Overlapping Capabilities
Adrian Otto
adrian.otto at rackspace.com
Thu Mar 26 20:30:42 UTC 2015
Rob,
I’m a little foggy on how we actually test capabilities. The tests for capabilities would need to be standard, right? I think that we are using the Refstack tests for this. Does that mean that someone has a cloud that has a previous version of service XYZ that exhibits all the required capabilities, but they would need to run a nonstandard test to demonstrate it, right? How would that work? Do we just trust participants to create and run their own tests, and just publish results with links to what they used? Would we allow patches to tools like Tempest to allow interoperability with the variants?
Thanks,
Adrian
On Mar 26, 2015, at 1:00 PM, Rob Hirschfeld <rob at rackn.com> wrote:
>
> On 03/26/2015 12:15 PM, Adrian Otto wrote:
>> We can adjust that expected compliance value to a higher one when we have confidence that OpenStack Cloud operators can actually meet the desired requirement value. Using a simple OR is less attractive because every requirement wold need to be re-evaluated every time there is a new version of a capability. Using a lower boundary is a common solution to this problem. Adrian
>
> I agree OR is very expensive to users. For something like API versions, the DefCore work is likely to drive that new API versions to support previous versions to the extent that we've required parts of the API. The point would be that required Capabilities are testable so we can make sure that APIs endure as much as possible.
>
> I think we are all in agreement - when we require APIs by making them required Capabilities, they should become long term stable. That means new versions should preserve old calls so they can pass the Capabilities tests.
>
> --
>
> Rob
> ____________________________
> Rob Hirschfeld, 512-773-7522
> RackN CEO, Founder
>
> I am in CENTRAL (-6) time
> http://robhirschfeld.com
> twitter: @zehicle, github: cloudedge & ravolt
>
More information about the Defcore-committee
mailing list