<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office">
<head>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<!--[if gte mso 9]>
<xml>
<o:OfficeDocumentSettings>
<o:AllowPNG/>
<o:PixelsPerInch>96</o:PixelsPerInch>
</o:OfficeDocumentSettings>
</xml>
<![endif]-->
<style type="text/css">* a:hover{cursor:pointer;}</style>
<style>body {-webkit-animation:bugfix infinite 1s;}@-webkit-keyframes bugfix {from {position:relative;}to {position:relative;}}</style>
</head>
<body style="word-wrap:normal; word-break:break-word;">
<style>a {word-wrap:normal;word-break:break-word;}.background-contain {background-size:contain;}@media only screen and (max-width:600px) {.container {-webkit-text-size-adjust:none !important;}.container,.palm-one-whole {width:100% !important;min-width:100% !important;}.palm-one-half {width:50% !important;min-width:50% !important;box-sizing:border-box;}blockquote .container,blockquote .container div,blockquote .container table {width:auto !important;min-width:0 !important;position:relative !important;}img {max-width:100%;}.border-outer,.border-middle,.border-inner,.inner,[title="separator"] {width:100% !important;}.innercell {padding:8px !important;}.palm-block {display:block !important;}td.palm-one-whole {display:inline-block !important;padding:0;}td.palm-one-whole:first-child:not(:only-child) {margin-bottom:16px;}td.hostname {padding-top:3px !important;}}@media only screen and (min-width:601px) {.preview-card {max-width:600px !important;}}@media only screen and (min-device-width :320px) and (max-device-width :568px),only screen and (min-device-width :768px) and (max-device-width :1024px),only screen and (max-device-width:640px),only screen and (max-device-width:667px),only screen and (max-width:480px){.container {width:100% !important;min-width:100% !important;}.p,.small,li,font[size="2"],font[size="3"] {font-size:1em !important;}}@media only screen and (min-device-width :320px) and (max-device-width :568px),only screen and (min-device-width :768px) and (max-device-width :1024px),only screen and (min-device-width :1224px) {.message-wrapper {padding-top:6px;}.apple-only[style] {display:block !important;max-height:none !important;line-height:normal !important;overflow:visible !important;height:auto !important;width:100% !important;position:relative !important;}.no-apple {display:none !important;}form {font-size:inherit;}input[type="text"] {height:43px;padding-left:4px !important;}button:hover {cursor:pointer;}}@media only screen and (min-device-width :1224px) {.apple-mail-form {display:block !important;background-color:white !important;}}* [office365] .outlook-com-hidden {display:none !important;}* [office365] .outlook-com-button {display:block;}* [office365] .outlook-com-only {display:block !important;max-height:none !important;line-height:normal !important;overflow:visible !important;height:auto !important;width:100% !important;position:relative !important;}</style>
<!--[if (gte mso 9)|(IE)]>
<style>a,body {font-family:'Calibri',Arial,sans-serif;}img {border:none !important;-ms-interpolation-mode:bicubic;}td {mso-line-height-rule:exactly !important;}.mso-card-inner table {border-collapse:collapse !important;mso-table-lspace:0pt;mso-table-rspace:0pt;vertical-align:top;}.outlook-com-only {display:none !important;font-size:0 !important;}#mso-one-whole {width:100% !important;}.border-outer,.border-middle,.border-inner {border:none !important;}.border-middle,.border-inner {width:100% !important;}.mso-border-outer,.mso-border-middle,.mso-border-inner {padding:1px;}.mso-border-outer {background-color:rgb(245,255,255);}.mso-border-middle {background-color:rgb(223,246,255);}.mso-border-inner {background-color:rgb(153,176,225);}</style>
<![endif]-->
<table class="container" lang="container" border="0" cellpadding="0" cellspacing="0" valign="top" style="width:100%; margin-top:6px;">
<tr>
<td valign="top" class="message-wrapper" style="line-height: 1.31; color: #222; font-family: arial, sans-serif;">
<!--[if mso]><table width="590" border="0" cellpadding="0" cellspacing="0" valign="top" style="width:590px;border-collapse:separate;"><tr><td valign="top"><![endif]-->
<div style="max-width: 590px;">I'd take the idea further. Imagine a typical Heat template, what you need to do is:</div><div style="max-width: 590px;"><br></div><div style="max-width: 590px;">- replace the VM id with Docker image id</div><div style="max-width: 590px;">- nothing else</div><div style="max-width: 590px;">- run the script with a normal heat engine</div><div style="max-width: 590px;">- the entire stack gets deployed in seconds</div><div style="max-width: 590px;"><br></div><div style="max-width: 590px;">Done!</div><div style="max-width: 590px;"><br></div><div style="max-width: 590px;">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.</div><div style="max-width: 590px;"><br></div><div style="max-width: 590px;">Summary: minimal changes to interface and upper systems, much smaller image and much better developer workflow.</div><div style="max-width: 590px;"><br></div><div style="max-width: 590px;">Peng</div><div style="max-width: 590px;"><br></div><div class="mixmax_signature" style="max-width: 590px;"><div class="gmail_signature"><div dir="ltr"><div>-----------------------------------------------------</div><div> Hyper_ Secure Container Cloud</div><div><br></div></div></div></div><img align="left" width="0" height="0" style="border:0; width:0px; height:0px;" src="https://app.mixmax.com/api/track/v2/oBSulqZ1wZwnO5XWU/ig2cuIXZwlHaAdmblBnI/IyZy9mLrNWY0NnblB3buMHdzlGbAZXZk1yajFGdz5WZw9mI/ISKz52bpR3clVXcgU2ZhNXdgI3bmBCdv5GKgQ3cpxEIn5WaslWYNBCduVWbw9GblZXZEByajFGdT5WZw9kI?sc=false" alt="">
<!--[if mso]></td></tr></table><![endif]-->
</td>
</tr>
</table>
<div style="max-width:590px;">
<div style="max-width:590px;">
<br>
<div class="gmail_extra">
<br>
<div class="gmail_quote">
On Wed, Apr 13, 2016 5:23 AM, Joshua Harlow <span dir="ltr"> <a href="mailto:harlowja@fastmail.com" target="_blank">harlowja@fastmail.com</a></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<u></u>
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
</blockquote>
</div>
</div>
</div>
</div>
</body>
</html>