Hi. I think option 1. is the best one right now, mostly to reduce the impact on the ongoing developments.
Upgrades, flattening, template versioning and node groups are supposed to land a lot of patches in the next couple months, moving the drivers into separate repos now could be a distraction. We can revisit this later... and maybe improve at the same time the user experience of adding custom drivers, which is not yet great (we're using the glance image metadata for this as there's no explicit --driver option yet). Cheers, Ricardo On Fri, Nov 18, 2016 at 6:04 PM, Drago Rosson <drago.ros...@rackspace.com> wrote: > If we were to go with (2), what should happen to the common code? > > From: Spyros Trigazis <strig...@gmail.com> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Date: Friday, November 18, 2016 at 8:34 AM > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@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 > > __________________________________________________________________________ > 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
