Open Stack

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.otto at rackspace.com> wrote on 09/05/2015 07:55:47 PM:
>
>  > From: Adrian Otto <adrian.otto at rackspace.com>
>  > To: "OpenStack Development Mailing List (not for usage questions)"
>  > <openstack-dev at 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 <john at johngarbutt.com> wrote:
>  >
>  > > On 1 May 2015 at 16:14, Davanum Srinivas <davanum at 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-request at 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