<font size=2 face="sans-serif">If system containers is a viable use-case
for Nova, and if Magnum is aiming at both application containers and system
containers, would it make sense to have a new virt driver in nova that
would invoke Magnum API for container provisioning and life cycle? This
would avoid (some of the) code duplication between Magnum and whatever
nova virt driver would support system containers (such as nova-docker).
Such an approach would be conceptually similar to nova virt driver invoking
Ironic API, replacing nova-baremetal (here again, Ironic surfaces various
capabilities which don't make sense in Nova).</font>
<br><font size=2 face="sans-serif">We have recently started exploring this
direction, and would be glad to collaborate with folks if this makes sense.</font>
<br>
<br><font size=2 face="sans-serif">Regards,</font>
<br><font size=2 face="sans-serif">Alex<br>
</font>
<br>
<br><tt><font size=2>Adrian Otto <adrian.otto@rackspace.com> wrote
on 09/05/2015 07:55:47 PM:<br>
<br>
> From: Adrian Otto <adrian.otto@rackspace.com></font></tt>
<br><tt><font size=2>> To: "OpenStack Development Mailing List
(not for usage questions)" <br>
> <openstack-dev@lists.openstack.org></font></tt>
<br><tt><font size=2>> Date: 09/05/2015 07:57 PM</font></tt>
<br><tt><font size=2>> Subject: Re: [openstack-dev] [nova-docker] Status
update</font></tt>
<br><tt><font size=2>> <br>
> John,<br>
> <br>
> Good questions. Remarks in-line from the Magnum perspective.<br>
> <br>
> On May 9, 2015, at 2:51 AM, John Garbutt <john@johngarbutt.com>
wrote:<br>
> <br>
> > On 1 May 2015 at 16:14, Davanum Srinivas <davanum@gmail.com>
wrote:<br>
> >> Anyone still interested in this work? :)<br>
> >> <br>
> >> * there's a stable/kilo branch now (see<br>
> >> </font></tt><a href="http://git.openstack.org/cgit/stackforge/nova-docker/"><tt><font size=2>http://git.openstack.org/cgit/stackforge/nova-docker/</font></tt></a><tt><font size=2>).<br>
> >> * CI jobs are running fine against both nova trunk and nova's<br>
> >> stable/kilo branch.<br>
> >> * there's an updated nova-spec to get code back into nova
tree (see<br>
> >> </font></tt><a href=https://review.openstack.org/#/c/128753/><tt><font size=2>https://review.openstack.org/#/c/128753/</font></tt></a><tt><font size=2>)<br>
> > <br>
> > To proxy the discussion from the etherpad onto the ML, we need
to work<br>
> > out why this lives in nova, given Magnum is the place to do container<br>
> > specific things.<br>
> <br>
> To the extent that users want to control Docker containers through
<br>
> the Nova API (without elaborate extensions), I think a stable in-<br>
> tree nova-docker driver makes complete sense for that.<br>
> <br>
[...]</font></tt>
<br><tt><font size=2>> <br>
> > Now whats the reason for adding the Docker driver, given Nova
is<br>
> > considering "container specific" APIs out of scope,
and expecting<br>
> > Magnum to own that kind of thing.<br>
> <br>
> I do think nova-docker should find it’s way into the Nova tree. This<br>
> makes containers more accessible in OpenStack, and appropriate for
<br>
> use cases where users want to treat containers like they treat <br>
> virtual machines. On the subject of extending the Nova API to <br>
> accommodate special use cases of containers that are beyond the <br>
> scope of the Nova API, I think we should resist that, and focus <br>
> those container-specific efforts in Magnum. That way, cloud <br>
> operators can choose whether to use Nova or Magnum for their <br>
> container use cases depending on the range of features they desire
<br>
> from the API. This approach should also result in less overlap of
efforts.<br>
> <br>
[...]</font></tt>
<br><tt><font size=2>> To sum up, I strongly support merging in nova-docker,
with the <br>
> caveat that it operates within the existing Nova API (with few minor<br>
> exceptions). For features that require API features that are truly
<br>
> container specific, we should land those in Magnum, and keep the <br>
> Nova API scoped to operations that are appropriate for “all"
instance types.<br>
> <br>
> Adrian<br>
> <br>
> > <br>
> > Thanks,<br>
> > John<br>
> > <br>
</font></tt>