[openstack-dev] [magnum] Managing cluster drivers as individual distro packages

Drago Rosson drago.rosson at RACKSPACE.COM
Fri Nov 18 17:04:58 UTC 2016


If we were to go with (2), what should happen to the common code?

From: Spyros Trigazis <strigazi at gmail.com<mailto:strigazi at gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Friday, November 18, 2016 at 8:34 AM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: [openstack-dev] [magnum] Managing cluster drivers as individual distro packages

Hi all,

In magnum, we implement cluster drivers for the different combinations
of COEs (Container Orchestration Engines) and Operating Systems. The
reasoning behind it is to better encapsulate driver-specific logic and to allow
operators deploy custom drivers with their deployment specific changes.

For example, operators might want to:
* have only custom drivers and not install the upstream ones at all
* offer user only some of the available drivers
* create different combinations of  COE + os_distro
* create new experimental/staging drivers

It would be reasonable to manage magnum's cluster drivers as different
packages, since they are designed to be treated as individual entities. To do
so, we have two options:

1. in-tree:  remove the entrypoints from magnum/setup.cfg to not install them
by default. This will require some plumbing to manage them like separate python
packages, but allows magnum's development team to manage the official drivers
inside the service repo.

2. separate repo: This option sounds cleaner, but requires more refactoring and
will separate more the drivers from service, having significant impact in the
development process.

Thoughts?

Spyros
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161118/da091362/attachment.html>


More information about the OpenStack-dev mailing list