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@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@fastmail.com] > Sent: Tuesday, April 12, 2016 12:16 PM > > To: Flavio Percoco; OpenStack Development Mailing List (not for > usage questions) > Cc: foundation@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@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@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@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@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@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev