On 5/17/2015 1:22 PM, Adrian Otto wrote:
Good questions Matt and Alex. Currently Magnum creates Bays (places that can
run containers, or pods of containers, and other high level resources such as
service, replication controllers, etc.) composed of one or more Nova instances
(Nodes). This way, we can potentially allow the creation and management for
containers on any compute form factor (bare metal, VM, container, etc.). The
Nova instances Magnum uses to form the Bays come from Heat.
NOTE: There is no such thing as a nova-magnum virt driver today. The following
discussion is theoretical.
Understanding that, it would be possible to make a nova-magnum virt driver that
talks to Magnum to ask for an instance of type container from an *existing*
Bay, but then Magnum would need to have access to Nova instances that are NOT
produced by the nova-magnum driver in order to scale out the Bay by adding more
nodes to it. If we do this, and the cloud operator does not realize the
circular dependency when setting Nova to use a nova-magnum virt driver, it
would be possible to create a loop where nova-magnum provides containers to
Magnum that come from the same bay we are attempting to scale out. This would
prevent the Bay from actually scaling out because it will be sourcing capacity
from itself. We could allow this to work by requiring anyone who uses
nova-magnum to also have another Nova host aggregate that uses an alternate
virt driver (Ironic, libvirt, etc.), and having some way for Magnum’s Heat
template to ask only for instances produced without the Magnum virt driv!
er when
forming or scaling Bays. I suppose a scheduling hint might be adequate for this.
Adrian
On May 17, 2015, at 11:48 AM, Matt Riedemann <mrie...@linux.vnet.ibm.com> wrote:
On 5/16/2015 10:52 PM, Alex Glikson wrote:
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).
We have recently started exploring this direction, and would be glad to
collaborate with folks if this makes sense.
Regards,
Alex
Adrian Otto <adrian.o...@rackspace.com> wrote on 09/05/2015 07:55:47 PM:
From: Adrian Otto <adrian.o...@rackspace.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date: 09/05/2015 07:57 PM
Subject: Re: [openstack-dev] [nova-docker] Status update
John,
Good questions. Remarks in-line from the Magnum perspective.
On May 9, 2015, at 2:51 AM, John Garbutt <j...@johngarbutt.com> wrote:
On 1 May 2015 at 16:14, Davanum Srinivas <dava...@gmail.com> wrote:
Anyone still interested in this work? :)
* there's a stable/kilo branch now (see
http://git.openstack.org/cgit/stackforge/nova-docker/).
* CI jobs are running fine against both nova trunk and nova's
stable/kilo branch.
* there's an updated nova-spec to get code back into nova tree (see
https://review.openstack.org/#/c/128753/)
To proxy the discussion from the etherpad onto the ML, we need to work
out why this lives in nova, given Magnum is the place to do container
specific things.
To the extent that users want to control Docker containers through
the Nova API (without elaborate extensions), I think a stable in-
tree nova-docker driver makes complete sense for that.
[...]
Now whats the reason for adding the Docker driver, given Nova is
considering "container specific" APIs out of scope, and expecting
Magnum to own that kind of thing.
I do think nova-docker should find it’s way into the Nova tree. This
makes containers more accessible in OpenStack, and appropriate for
use cases where users want to treat containers like they treat
virtual machines. On the subject of extending the Nova API to
accommodate special use cases of containers that are beyond the
scope of the Nova API, I think we should resist that, and focus
those container-specific efforts in Magnum. That way, cloud
operators can choose whether to use Nova or Magnum for their
container use cases depending on the range of features they desire
from the API. This approach should also result in less overlap of
efforts.
[...]
To sum up, I strongly support merging in nova-docker, with the
caveat that it operates within the existing Nova API (with few minor
exceptions). For features that require API features that are truly
container specific, we should land those in Magnum, and keep the
Nova API scoped to operations that are appropriate for “all" instance
types.
Adrian
Thanks,
John
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
I was wondering the exact same thing, why not work on a nova virt driver that
talks to the magnum API?
--
Thanks,
Matt Riedemann
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
OK, ignorance on my part, I didn't realize Magnum was using Nova. I'd
like to avoid any circular dependencies anywhere at all times. :)
--
Thanks,
Matt Riedemann
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
