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

Rochelle Grober rochelle.grober at huawei.com
Thu Feb 11 00:13:54 UTC 2016


Hey guys!  This sounds like this crosses into our wheelhouse, too.  We should discuss at the midcycle.

John, the Product WG midcycle is at Rackspace London, out near Heathrow, 2/17 and 2/18.  Any chance we can coax you to visit?

--Rocky

-----Original Message-----
From: John Garbutt , Wednesday, February 10, 2016 10:26 AM

Hi,

DefCore, in its current form, is doing a great job of defining things
that should work on all OpenStack deployments. Stopping the divergence
of OpenStack APIs is super important, and this is working.

But I think we are hitting issues with getting projects engaged on
driving forward the cause of interoperability, and its proving tricky
to expand beyond the base set of required operations.

If we look a few years ahead, I would love to see a broad ecosystem of
applications written to run against any certified OpenStack Compute
cloud. In addition, some applications may need some additional
capabilities (configure network routers, needs object storage, etc). I
am thinking about the next generation of this:
http://apps.openstack.org/

I think DefCore can help make that dream become a reality.

To reach that goal more quickly, I think should change direction
slight, and consider these three ideas:

1: Focus on Uses cases

Lets define the use cases application developers need for the above
vision to become reality. Thats helps projects engage with the
problems that need solving. Sometimes the API exists, sometimes there
is a possible workflow to do this in an interoperable way, other times
a new API or APIs might be needed. These patterns can then be used to
create applications that work across all OpenStack certified clouds. I
think the product working group may be able to help.

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).

3. Working with App Developers to test this

One idea to make this all real is to look at the existing apps in the
marketplace app store, and look at ways to make them work with all
certified OpenStack deployments/products. I think this is likely to
involve working out how to bootstrap their images from an existing
base image in that deployment, and then maybe then share that image
with other users of that clouds. (FWIW, I feel importing a full image
avoids any work each cloud has done to optimise their particular
environment, and many other issues). It might be certain apps are
supported on particular certified products, but thats not the aim. The
aim is to get apps that users can run on all certified products.

What do you all think? Does this look like the seeds of a good idea?
Or is there something I am totally missing here?

Thanks,
johnthetubaguy

_______________________________________________
Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee



More information about the Product-wg mailing list