[OpenStack-DefCore] Ideas to speed up DefCore's fight for interoperability

Chris Hoge chris at openstack.org
Thu Feb 11 16:49:04 UTC 2016


Top posting, because 
> On Feb 10, 2016, at 10:25 AM, John Garbutt <john at johngarbutt.com> wrote:
> 
> <snip>
> 
> 2: Validating Optional Capabilities
> 
> While its important to define "things that should work everywhere" I
> think its important to define "if available, it should work the same
> way everywhere". This requires that the project APIs work on policy
> discovery, so you can tell if an API is available in a particular
> deployment or not. Its possible we end up defining the minimum
> standard as having one of n choices available (assuming there is a
> workflow that lets you pick between them, ideally an abstract API
> would hide that complexity, but thats not always possible).

This is something that I’ve encouraged, and is being explored in the
RefStack project. We have a format with our guidelines that specifies
capabilities that can be checked by an external program. I’ve been
advocating a way for RefsStack to optionally load third party guidelines
(most likely via passing a URL as a parameter), so that other
capability sets (EC2 is a popular request from some corners of our
community) can be verified.

We already have a fairly difficult task of working out what the
interoperable capability set should be, and I’m not sure we’re in a
place to spread our already limited resources in having the
DefCore committee figure out what optional capability sets should
be (yet). And that’s ok, because we can still have a way to let
members of our community decide what is important to them, which
itself can become a valuable feedback tool for us.

Chris (hogepodge)

> <snip>

> Thanks,
> johnthetubaguy




More information about the Defcore-committee mailing list