Re: [openstack-dev] [magnum] Managing cluster drivers as individual distro packages
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 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
Re: [openstack-dev] [magnum] Managing cluster drivers as individual distro packages
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] 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?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [magnum] Managing cluster drivers as individual distro packages
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 wrote: > If we were to go with (2), what should happen to the common code? > > From: Spyros Trigazis > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > > Date: Friday, November 18, 2016 at 8:34 AM > 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?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
Re: [openstack-dev] [magnum] Managing cluster drivers as individual distro packages
If we were to go with (2), what should happen to the common code? From: Spyros Trigazis mailto:strig...@gmail.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Friday, November 18, 2016 at 8:34 AM To: "OpenStack Development Mailing List (not for usage questions)" mailto: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-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
