Open Stack

Fox, Kevin M wrote:
> I think my head just exploded. :)
>
> That idea's similar to neutron sfc stuff, where you just say what needs to connect to what, and it figures out the plumbing.
>
> Ideally, it would map somehow to heat & docker COE & neutron sfc to produce a final set of deployment scripts and then just runs it through the meat grinder. :)
>
> It would be awesome to use. It may be very difficult to implement.
>
> If you ignore the non container use case, I think it might be fairly easily mappable to all three COE's though.

This feels like Heat with a more readable descriptive language. I don't 
really like this approach, because you end up with the lowest common 
denominator between COE's functionality. They are all different. And 
they are at the peak of the differentiation phase. The LCD is bound to 
be pretty basic.

This approach may be attractive for us as infrastructure providers, but 
I also know this is not attractive to users who used Kubernetes before 
and wants to continue to use Kubernetes (and don't really want to care 
about whether OpenStack is running under the hood). They don't want to 
learn another descriptor language or API, they just want to learn the 
Kubernetes description model and API and take advantage of its unique 
capabilities.

In summary, this may be a good solution for *existing* OpenStack users 
to start playing with containerized workloads. But it is not a good 
solution to attract the container cool kids to using OpenStack as their 
base infrastructure provider. For those we need to make it as 
transparent and simple to use their usual tools to deploy on top of 
OpenStack clouds. The more they can ignore we are there, the better.

-- 
Thierry Carrez (ttx)