Open Stack

On 04/11/2016 02:51 PM, Fox, Kevin M wrote:
> Yeah, I think there are two places where it may make sense.
> 
> 1. Ironic's nova plugin is a lowst common denominator for treating a
> physical host like a vm. Ironic's api is much more rich, but sometimes
> all you need is the lowest common denominator and don't want to rewrite
> a bunch of code. In this case, it may make sense to have a nova plugin
> that talks to magnum to launch a heavy weight container to make the use
> case easy.
> 
> 2. Basic abstraction of Orchestration systems. Most (all?) docker
> orchestration systems work with a yaml file. What's in it differs, but
> shipping it from point A to point B using an authenticated channel can
> probably be nicely abstracted. I think this would be a big usability
> gain as well. Things like the applications catalog could much more
> easily hook into it then. The catalog would provide the yaml, and a tag
> to know which orchestrator type it is, and just pass that info along to
> magnum.

The typical conundrum here is making "the easy things easy, and the hard
things possible". It doesn't have to be a choice between a) providing a
rich API with access to all the features of each individual compute
paradigm, and b) providing a simple API that allows users to request a
compute resource of any type that's available in the public/private
cloud they're interacting with. OpenStack can have both.

The simple lowest common denominator interface would be very limited
(both by necessity and by design), but easy to understand and get
started on, making some smart assumptions on common usage patterns. The
richer APIs are there for users who need more power and flexibility, and
are ready to go beyond the easy on-ramp.

Again, nothing new here, it seems to be the direction we're already
heading. I'm just articulating why.

Allison