Open Stack

I think that we should absolutely not do this. We are not a good 
framework for providing individual lightweight containers. Nobody 
_wants_ us to delivery individual lightweight containers. Like, 
literally no humans are saying "kubernetes sucks, it would be so much 
better if we could use our containers via the OpenStack APIs"

OpenStack is a great system for getting computers. It has excellent 
driver support for interfacing with storage, networking and baremetal 
hardware provided by all of our vendors. As such, it makes for a GREAT 
infrastructure abstraction layer on top of which someone can run mesos, 
kube or swarm, should those things be thing they desire.

This is one of the reasons magnum is useful and nova-docker is not. 
Magnum is a thing that allows one to create a k8s cluster on top of your 
openstack with good integration. Add in things like kuryr and you've got 
a really cool thing that adds value to both OpenStack and to kubernetes.

Saying:

  nova boot --flavor=docker --image=ubuntu-trusty

Sounds like the world's worst way to get a docker container - especially 
when:

   docker run -it ubutnu:trusty /bin/bash

is the easiest thing to run in the world.

How about we focus on delivering computer like VMs, and actual bare 
metal computers - and providing excellent integration point for things 
like k8s, swarm, mesos, cloudfoundry and openshift? Doesn't that sound 
like something we can excel at?

On 04/13/2016 08:49 AM, Fox, Kevin M wrote:
> It partially depends on if your following lightweight container
> methodology. Can nova api support unix sockets or bind mounts between
> containers in the same pod? Would it be reasonable to add that
> functionality? Its pretty different to novas usual use cases.
>
> Thanks,
> Kevin
>
> *
> *
> ------------------------------------------------------------------------
> *From:* Peng Zhao
> *Sent:* Tuesday, April 12, 2016 11:33:21 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Cc:* foundation at lists.openstack.org
> *Subject:* Re: [openstack-dev] [OpenStack Foundation] [board][tc][all]
> One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)
>
> Agreed.
>
> IMO, OpenStack is an open framework to different technologies and use
> cases. Different architectures for different things make sense. Some may
> say that using nova to launch docker images with hypervisor is weird,
> but it can be seen as “Immutable IaaS”.
>
>
> -----------------------------------------------------
>      Hyper_ Secure Container Cloud
>
>
>
> On Wed, Apr 13, 2016 1:43 PM, Joshua Harlow harlowja at fastmail.com
> <mailto:harlowja at fastmail.com> wrote:
>
>     __Sure, so that helps, except it still has the issue of bumping up
>     against the mismatch of the API(s) of nova. This is why I'd rather
>     have a template kind of format (as say the input API) that allows
>     for (optionally) expressing such container specific
>     capabilities/constraints. Then some project that can understand that
>     template /format can if needed talk to a COE (or similar project) to
>     translate that template 'segment' into a realized entity using the
>     capabilities/constraints that the template specified. Overall it
>     starts to feel like maybe it is time to change the upper and lower
>     systems and shake things up a little ;) Peng Zhao wrote: > I'd take
>     the idea further. Imagine a typical Heat template, what you > need
>     to do is: > > - replace the VM id with Docker image id > - nothing
>     else > - run the script with a normal heat engine > - the entire
>     stack gets deployed in seconds > > Done! > > Well, that sounds like
>     nova-docker. What about cinder and neutron? They > don't work well
>     with Linux container! The answer is Hypernova >
>     (https://github.com/hyperhq/hypernova) or Intel ClearContainer,
>     seamless > integration with most OpenStack components. > > Summary:
>     minimal changes to interface and upper systems, much smaller > image
>     and much better developer workflow. > > Peng > >
>     ----------------------------------------------------- > Hyper_
>     Secure Container Cloud > > > > On Wed, Apr 13, 2016 5:23 AM, Joshua
>     Harlow harlowja at fastmail.com > wrote: > > __ Fox, Kevin M wrote: > I
>     think part of the problem is containers > are mostly orthogonal to
>     vms/bare metal. Containers are a package > for a single service.
>     Multiple can run on a single vm/bare metal > host. Orchestration
>     like Kubernetes comes in to turn a pool of > vm's/bare metal into a
>     system that can easily run multiple > containers. > Is the
>     orthogonal part a problem because we have made > it so or is it just
>     how it really is? Brainstorming starts here: > Imagine a descriptor
>     language like (which I stole from >
>     https://review.openstack.org/#/c/210549 and modified): --- >
>     components: - label: frontend count: 5 image: ubuntu_vanilla >
>     requirements: high memory, low disk stateless: true - label: >
>     database count: 3 image: ubuntu_vanilla requirements: high memory, >
>     high disk stateless: false - label: memcache count: 3 image: >
>     debian-squeeze requirements: high memory, no disk stateless: true -
>      > label: zookeeper count: 3 image: debian-squeeze requirements:
>     high > memory, medium disk stateless: false backend: VM networks: -
>     label: > frontend_net flavor: "public network" associated_with: -
>     frontend - > label: database_net flavor: high bandwidth
>     associated_with: - > database - label: backend_net flavor: high
>     bandwidth and low latency > associated_with: - zookeeper - memchache
>     constraints: - ref: > container_only params: - frontend - ref:
>     no_colocated params: - > database - frontend - ref: spread params: -
>     database - ref: > no_colocated params: - database - frontend - ref:
>     spread params: - > memcache - ref: spread params: - zookeeper - ref:
>     isolated_network > params: - frontend_net - database_net -
>     backend_net ... Now nothing > in the above is about container, or
>     baremetal or vms, (although a > 'advanced' constraint can be that a
>     component must be on a > container, and it must say be deployed via
>     docker image XYZ...); > instead it's just about the constraints that
>     a user has on there > deployment and the components associated with
>     it. It can be left up > to some consuming project of that format to
>     decide how to turn that > desired description into an actual
>     description (aka a full expanding > of that format into an actual
>     deployment plan), possibly say by > optimizing for density (packing
>     as many things container) or > optimizing for security (by using
>     VMs) or optimizing for performance > (by using bare-metal). > So,
>     rather then concern itself with > supporting launching through a COE
>     and through Nova, which are two > totally different code paths,
>     OpenStack advanced services like Trove > could just use a Magnum COE
>     and have a UI that asks which existing > Magnum COE to launch in, or
>     alternately kick off the "Launch new > Magnum COE" workflow in
>     horizon, then follow up with the Trove > launch workflow. Trove then
>     would support being able to use > containers, users could
>     potentially pack more containers onto their > vm's then just Trove,
>     and it still would work with both Bare Metal > and VM's the same way
>     since Magnum can launch on either. I'm afraid > supporting both
>     containers and non container deployment with Trove > will be a large
>     effort with very little code sharing. It may be > easiest to have a
>     flag version where non container deployments are > upgraded to
>     containers then non container support is dropped. > Sure > trove
>     seems like it would be a consumer of whatever interprets that >
>     format, just like many other consumers could be (with the special >
>     case that trove creates such a format on-behalf of some other >
>     consumer, aka the trove user). > As for the app-catalog use case, >
>     the app-catalog project (http://apps.openstack.org) is working on >
>     some of that. > > Thanks, > Kevin > >
>     ________________________________________ > From: Joshua Harlow >
>     [harlowja at fastmail.com] > Sent: Tuesday, April 12, 2016 12:16 PM > >
>     To: Flavio Percoco; OpenStack Development Mailing List (not for >
>     usage questions) > Cc: foundation at lists.openstack.org > Subject: Re:
>      > [openstack-dev] [OpenStack Foundation] [board][tc][all] One
>     Platform > – Containers/Bare Metal? (Re: Board of Directors Meeting)
>      > > Flavio > Percoco wrote: >> On 11/04/16 18:05 +0000, Amrith
>     Kumar wrote: >>> > Adrian, thx for your detailed mail. >>> >>> >>>
>      >>> Yes, I was > hopeful of a silver bullet and as we’ve discussed
>     before (I >>> > think it >>> was Vancouver), there’s likely no
>     silver bullet in this > area. After that >>> conversation, and some
>     further experimentation, > I found that even if >>> Trove had >>>
>     access to a single Compute > API, there were other significant >>>
>     complications >>> further down > the road, and I didn’t pursue the
>     project further at the >>> time. > >>> >> Adrian, Amrith, >> >> I've
>     spent enough time researching on > this area during the last month
>      >> and my >> conclusion is pretty > much the above. There's no
>     silver bullet in this >> area and >> I'd > argue there shouldn't be
>     one. Containers, bare metal and VMs differ > >> in such >> a way
>     (feature-wise) that it'd not be good, as far as > deploying >>
>     databases goes, >> for there to be one compute API. > Containers
>     allow for a different >> deployment >> architecture than > VMs and
>     so does bare metal. > > Just some thoughts from me, but why > focus
>     on the > compute/container/baremetal API at all? > > I'd > almost
>     like a way that just describes how my app should be > >
>     interconnected, what is required to get it going, and the features >
>      > and/or scheduling requirements for different parts of those app.
>      > > > To me it feels like this isn't a compute API or really a heat
>     API > but > something else. Maybe it's closer to the docker compose
>      > API/template > format or something like it. > > Perhaps such a
>     thing > needs a new project. I'm not sure, but it does feel > like
>     that as > developers we should be able to make such a thing that >
>     still > exposes the more advanced functionality of the underlying
>     API so > > that it can be used if really needed... > > Maybe this is
>     similar to > an app-catalog, but that doesn't quite feel > like it's
>     the right > thing either so maybe somewhere in between... > > IMHO
>     I'd be nice > to have a unified story around what this thing is, so
>      > that we as a > community can drive (as a single group) toward
>     that, maybe > this is > where the product working group can help and
>     we as a developer > > community can also try to unify behind... > >
>     P.S. name for project > should be 'silver' related, ha. > > -Josh >
>      > >
>     __________________________________________________________________________
>      > > OpenStack Development Mailing List (not for usage questions) >
>      > Unsubscribe: >
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > >
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
>      > > >
>     __________________________________________________________________________
>      > > OpenStack Development Mailing List (not for usage questions) >
>      > Unsubscribe: >
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > >
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
>     __________________________________________________________________________
>      > OpenStack Development Mailing List (not for usage questions) >
>     Unsubscribe: >
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe >
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
>      >
>     __________________________________________________________________________
>      > OpenStack Development Mailing List (not for usage questions) >
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe >
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> Foundation mailing list
> Foundation at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
>