<tt><font size=2>Indeed, very interesting use-case. I guess it is similar
to any situation where you might want to dynamically scale your undercloud
via Heat + Nova, and use same or different Nova for the 'overcloud'. You
can do something like this today with Ironic and KVM, I think (we experimented
with such an 'integrated undercloud+overcloud management' environment for
a while, and it seemed to be working - up to few minor glitches).</font></tt>
<br><tt><font size=2>Of course, the system would need to be carefully configured
(maybe requiring some tweaking) if same Nova is used for both - but should
be feasible, IMO. The differentiation between the two types of Nova instances
should be rather straightforward to implement with, for example, image
properties or flavor extra spec (or maybe both).</font></tt>
<br>
<br><tt><font size=2>Regards,</font></tt>
<br><tt><font size=2>Alex</font></tt>
<br>
<br><tt><font size=2>Adrian Otto <adrian.otto@rackspace.com> wrote
on 17/05/2015 11:22:51 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: 17/05/2015 11:28 PM</font></tt>
<br><tt><font size=2>> Subject: Re: [openstack-dev] [nova-docker] Status
update</font></tt>
<br><tt><font size=2>> <br>
> Good questions Matt and Alex. Currently Magnum creates Bays (places
<br>
> that can run containers, or pods of containers, and other high level<br>
> resources such as service, replication controllers, etc.) composed
<br>
> of one or more Nova instances (Nodes). This way, we can potentially
<br>
> allow the creation and management for containers on any compute form<br>
> factor (bare metal, VM, container, etc.). The Nova instances Magnum
<br>
> uses to form the Bays come from Heat.<br>
> <br>
> NOTE: There is no such thing as a nova-magnum virt driver today. The<br>
> following discussion is theoretical.<br>
> <br>
> Understanding that, it would be possible to make a nova-magnum virt
<br>
> driver that talks to Magnum to ask for an instance of type container<br>
> from an *existing* Bay, but then Magnum would need to have access
to<br>
> Nova instances that are NOT produced by the nova-magnum driver in
<br>
> order to scale out the Bay by adding more nodes to it. If we do <br>
> this, and the cloud operator does not realize the circular <br>
> dependency when setting Nova to use a nova-magnum virt driver, it
<br>
> would be possible to create a loop where nova-magnum provides <br>
> containers to Magnum that come from the same bay we are attempting
<br>
> to scale out. This would prevent the Bay from actually scaling out
<br>
> because it will be sourcing capacity from itself. We could allow <br>
> this to work by requiring anyone who uses nova-magnum to also have
<br>
> another Nova host aggregate that uses an alternate virt driver <br>
> (Ironic, libvirt, etc.), and having some way for Magnum’s Heat <br>
> template to ask only for instances produced without the Magnum virt
<br>
> driver when forming or scaling Bays. I suppose a scheduling hint <br>
> might be adequate for this.<br>
> <br>
> Adrian<br>
> <br>
> > On May 17, 2015, at 11:48 AM, Matt Riedemann <br>
> <mriedem@linux.vnet.ibm.com> wrote:<br>
> > <br>
> > <br>
> > <br>
> > On 5/16/2015 10:52 PM, Alex Glikson wrote:<br>
> >> If system containers is a viable use-case for Nova, and if
Magnum is<br>
> >> aiming at both application containers and system containers,
would it<br>
> >> make sense to have a new virt driver in nova that would invoke
Magnum<br>
> >> API for container provisioning and life cycle? This would
avoid (some of<br>
> >> the) code duplication between Magnum and whatever nova virt
driver would<br>
> >> support system containers (such as nova-docker). Such an
approach would<br>
> >> be conceptually similar to nova virt driver invoking Ironic
API,<br>
> >> replacing nova-baremetal (here again, Ironic surfaces various<br>
> >> capabilities which don't make sense in Nova).<br>
> >> We have recently started exploring this direction, and would
be glad to<br>
> >> collaborate with folks if this makes sense.<br>
> >> <br>
> >> Regards,<br>
> >> Alex<br>
> >> <br>
> >> <br>
> >> Adrian Otto <adrian.otto@rackspace.com> wrote on 09/05/2015
07:55:47 PM:<br>
> >> <br>
> >> > From: Adrian Otto <adrian.otto@rackspace.com><br>
> >> > To: "OpenStack Development Mailing List (not for
usage questions)"<br>
> >> > <openstack-dev@lists.openstack.org><br>
> >> > Date: 09/05/2015 07:57 PM<br>
> >> > Subject: Re: [openstack-dev] [nova-docker] Status update<br>
> >> ><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>
> >> [...]<br>
> >> ><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<br>
> >> efforts.<br>
> >> ><br>
> >> [...]<br>
> >> > 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<br>
> >> types.<br>
> >> ><br>
> >> > Adrian<br>
> >> ><br>
> >> > ><br>
> >> > > Thanks,<br>
> >> > > John<br>
> >> > ><br>
> >> <br>
> >> <br>
> >> __________________________________________________________________________<br>
> >> OpenStack Development Mailing List (not for usage questions)<br>
> >> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
> >> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
> >> <br>
> > <br>
> > I was wondering the exact same thing, why not work on a nova
virt <br>
> driver that talks to the magnum API?<br>
> > <br>
> > -- <br>
> > <br>
> > Thanks,<br>
> > <br>
> > Matt Riedemann<br>
> > <br>
> > <br>
> > __________________________________________________________________________<br>
> > OpenStack Development Mailing List (not for usage questions)<br>
> > Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
> > </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
> <br>
> <br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
> <br>
</font></tt>