Open Stack

On May 23, 2014, at 7:09 PM, Bhandaru, Malini K <malini.k.bhandaru at intel.com> wrote:

> Would just like to point out .. assigning a machine to a single tenant – with Docker, would not be very different from assigning bare metal to a tenant who does not want the overhead of virtualization and that is an use case we would like to support in the cloud too.

In either of these cases, the bare metal or container issue is not necessarily the point. If this is all done under the same API calls that are determined to represent core, then the implementation isn’t necessarily a concern. If you require special extensions or unique API calls to access containers or bare-metal options, then those would have to go through the same evaluation process.

Eventually, this points to where DefCore and Tempest testing evolve so that we include some of the emerging ‘scenario testing’ vs. just the current API validation. Moving down this path would be a necessity to get the interoperability we seek in the long term IMHO. But, that won’t be incorporated in the initial versions based on current course and speed.

Troy

> Regards
> Malini
>  
> From: Rob_Hirschfeld at Dell.com [mailto:Rob_Hirschfeld at Dell.com] 
> Sent: Friday, May 23, 2014 5:02 PM
> To: Auld, Will; aclark at suse.com; Defcore-committee at lists.openstack.org
> Subject: Re: [OpenStack-DefCore] Seeking DefCore Feedback from Summit (you can just +1 if you think community supports DefCore)
>  
> Will,
>  
> I want to make sure I understand.  You agree that the issue does not change DefCore approach?   We’re going to wait and see what happens with Docker.
>  
> From: Auld, Will [mailto:will.auld at intel.com] 
> Sent: Friday, May 23, 2014 11:19 AM
> To: Hirschfeld, Rob; aclark at suse.com; Defcore-committee at lists.openstack.org
> Cc: Auld, Will
> Subject: RE: [OpenStack-DefCore] Seeking DefCore Feedback from Summit (you can just +1 if you think community supports DefCore)
>  
> The issue here is as much paradigm as much as function. Docker with OpenStack is kinda like a PaaS and kinda like a IaaS. We would like to be able to deliver it in the cloud as an option alongside our various hypervisors as well as bare metal.  Delivered on a Nova compute host means the host should be restricted to a single tenant which is unusual. Docker is just a different beast for our environment and will need to evolve before it could be a part of core.
>  
> Thanks,
>  
> Will
>  
> From: Rob_Hirschfeld at Dell.com [mailto:Rob_Hirschfeld at Dell.com] 
> Sent: Tuesday, May 20, 2014 1:52 PM
> To: aclark at suse.com; Defcore-committee at lists.openstack.org
> Subject: Re: [OpenStack-DefCore] Seeking DefCore Feedback from Summit (you can just +1 if you think community supports DefCore)
>  
> > > 2. Nova Docker is an interesting use case because Docker does not use
> > > Glance or Cinder in the same way as libvirt Nova does. This means 
> > > that a Docker cloud would not pass the core tests for Glance or 
> > > Cinder as currently structured.
> > 
> > 
> > ok a naive question on my part. Is this a question for the first 
> > release or something to address for Juno? I ask the question because 
> > I'm not sure what the stated Docker support was for Havana and Icehouse.
> >
> 
> I don’t think we have to make changes in response, but it does raise questions that we should consider.
> 
> If someone wanted a “Docker Only” OpenStack then there would be compatibly issues with Glance and Cinder because they don’t work the same way for Docker as other approaches.  We could fake the responses to pass the tests but that would cause other issues.  At some point, we may have to resolve if Nova+Docker is a new type of IaaS and thus a different set of capabilities.  There’s no simple answer.
> 
> Since our goal is interop, I suspect there’s little room for APIs that behave in different ways.   Consequently, the Docker question is an excellent test of DefCore.
> 
> I hope that helps.
> 
> _______________________________________________
> Defcore-committee mailing list
> Defcore-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20140527/1e17a620/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20140527/1e17a620/attachment.pgp>