Open Stack

Team,

We discussed this in today’s team meeting:

http://eavesdrop.openstack.org/meetings/containers/2017/containers.2017-01-03-16.00.html

Our consensus was to start iterating on this in-tree and break it out later into a separate repo once we have reasonably mature drivers, and/or further guidance form the TC about handling drivers.

Adrian

On Nov 26, 2016, at 11:31 PM, Yatin Karel <yatin.karel at nectechnologies.in<mailto:yatin.karel at nectechnologies.in>> wrote:

Hi,

As it will helpful in adoption of Magnum so it's good to seperate drivers somehow and make addition/management of new/current cluster drivers easier.

>From Developer's(refering just Myself) point of view i think current approach is Ok as we can manage everything at one place and from Operator perspective i think it should be easier to add/disable drivers.
Keeping above points in mind i think for now we should consider more on current contrib drivers development process, as this will lead to how other drivers would be developed/added in magnum later on. Currently we have three contrib drivers under development:- k8s_opensuse_v1/dcos_centos_v1/dcos_centos_ironic_v1. So we can target atleast finalizing process for their addition to some extent in this cycle.

Should we focus more on adding new contrib drivers now.  I think Adding new cluster drivers should be made more easier and independent whether by documenting or by other means. As i believe disabling can just be done by updating setup.cfg or manum.conf. May be we can provide some option for disabling drivers without manully updating config/setup files.


<< 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.


For this approach, what if we add drivers automatically as it is right now. And update doc for operators who want to disable some/all automatically installed drivers and on how they can add their custom drivers. I think Murali was working on this(process for adding new contrib drivers) so he might have some idea on this.


<< 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.

Yes, This sounds more cleaner but seems not necessary now.
Agree with Ricardo for not moving to this approach now as Drago's concern is also valid and it would be difficult to handle that along with other high priorities tasks in the Ocata Cycle. So it can be revisited later when we have defined process for new drivers and we have more drivers in-tree.


Regards
Yatin Karel
________________________________
From: Spyros Trigazis [strigazi at gmail.com<mailto:strigazi at gmail.com>]
Sent: Friday, November 18, 2016 8:04 PM
To: OpenStack Development Mailing List (not for usage questions)
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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org<mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170103/4418c04f/attachment.html>