Open Stack

Well, it is a myth that Docker is not linux container specific. It is born with
cgroup/namespace, but the image is an app-centric way to package, nothing
particular to linux container.
For openstack, given the virtualization root, it is an easy win in places where
requires strong isolation, multi-tenancy. And that creates new patterns to
consume technologies.
Peng
----------------------------------------------------- Hyper_ Secure Container Cloud


On Wed, Apr 13, 2016 9:49 PM, Fox, Kevin M Kevin.Fox at pnnl.gov 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 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   > 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 >  
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160414/b521a41b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: attachment-1.gif
Type: image/gif
Size: 43 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160414/b521a41b/attachment.gif>