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.ka...@nectechnologies.in<mailto:yatin.ka...@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 [strig...@gmail.com<mailto:strig...@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-requ...@lists.openstack.org<mailto: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