[qa][zun][kuryr][k8s]
Hi all, Right now, we have a devstack plugin [1] to install container engine (i.e. docker, cri-o). The plugin is currently used by Zun and Kuryr and under the governance of QA team. I am working on a patch [2] to enable k8s installation via devstack. Zun needs this feature to setup the CI for the virtual kubelet provider, and I heard Kuryr also interest to leverage it. The original idea is to incorporate k8s installation into devstack-plugin-container, so that we can avoid the overhead to bootstrap and maintain a separated plugin. However, the feedback I received so far gave preference to a separated plugin for k8s, so I sent out this email to collect more opinions. Do you prefer a dedicated devstack plugin for k8s, or is fine to reuse the existing container plugin for this purpose? [1] https://github.com/openstack/devstack-plugin-container [2] https://review.openstack.org/#/c/646018/ Best regards, Hongbin
On Thu, 2019-04-18 at 23:54 -0400, Hongbin Lu wrote:
Hi all,
Right now, we have a devstack plugin [1] to install container engine (i.e. docker, cri-o). The plugin is currently used by Zun and Kuryr and under the governance of QA team.
I am working on a patch [2] to enable k8s installation via devstack. Zun needs this feature to setup the CI for the virtual kubelet provider, and I heard Kuryr also interest to leverage it.
The original idea is to incorporate k8s installation into devstack-plugin-container, so that we can avoid the overhead to bootstrap and maintain a separated plugin. However, the feedback I received so far gave preference to a separated plugin for k8s, so I sent out this email to collect more opinions.
Do you prefer a dedicated devstack plugin for k8s, or is fine to reuse the existing container plugin for this purpose?
I looked through the proposed code again and I think I'll soften my stance here. If we'll keep the code in a separated file and do not mix the settings of two too much (note that some dependency is necessary - we do that in kuryr-kubernetes DevStack plugin in regards to e.g. CONTAINER_ENGINE), then we should be easily able to extract it in the future if needed. My only concern is that if any future OpenStack project wanted to deploy K8s on its DevStack, devstack-plugin-container would certainly not be first place they would look at. Anyway let's just start with something and see where it carries us. It'll definitely need a lot of work to develop the plugin to the point it could be used by kuryr-kubernetes, so it's just a start.
On Fri, Apr 19, 2019 at 6:59 AM Michał Dulko <mdulko@redhat.com> wrote:
On Thu, 2019-04-18 at 23:54 -0400, Hongbin Lu wrote:
Hi all,
Right now, we have a devstack plugin [1] to install container engine (i.e. docker, cri-o). The plugin is currently used by Zun and Kuryr and under the governance of QA team.
I am working on a patch [2] to enable k8s installation via devstack. Zun needs this feature to setup the CI for the virtual kubelet provider, and I heard Kuryr also interest to leverage it.
The original idea is to incorporate k8s installation into devstack-plugin-container, so that we can avoid the overhead to bootstrap and maintain a separated plugin. However, the feedback I received so far gave preference to a separated plugin for k8s, so I sent out this email to
collect more opinions. > > Do you prefer a dedicated devstack plugin for k8s, or is fine to reuse the existing container plugin for this purpose?
I looked through the proposed code again and I think I'll soften my stance here. If we'll keep the code in a separated file and do not mix the settings of two too much (note that some dependency is necessary - we do that in kuryr-kubernetes DevStack plugin in regards to e.g. CONTAINER_ENGINE), then we should be easily able to extract it in the future if needed. My only concern is that if any future OpenStack project wanted to deploy K8s on its DevStack, devstack-plugin-container would certainly not be first place they would look at.
Anyway let's just start with something and see where it carries us. It'll definitely need a lot of work to develop the plugin to the point it could be used by kuryr-kubernetes, so it's just a start.
Sure.
---- On Thu, 18 Apr 2019 22:54:14 -0500 Hongbin Lu <hongbin034@gmail.com> wrote ----
Hi all, Right now, we have a devstack plugin [1] to install container engine (i.e. docker, cri-o). The plugin is currently used by Zun and Kuryr and under the governance of QA team. I am working on a patch [2] to enable k8s installation via devstack. Zun needs this feature to setup the CI for the virtual kubelet provider, and I heard Kuryr also interest to leverage it. The original idea is to incorporate k8s installation into devstack-plugin-container, so that we can avoid the overhead to bootstrap and maintain a separated plugin. However, the feedback I received so far gave preference to a separated plugin for k8s, so I sent out this email to collect more opinions. Do you prefer a dedicated devstack plugin for k8s, or is fine to reuse the existing container plugin for this purpose? [1] https://github.com/openstack/devstack-plugin-container[2] https://review.openstack.org/#/c/646018/
I agree on this, it makes more sense to keep it in existing 'devstack-plugin-container' plugin. As you mentioned clearly in your patch about 'how to enable the k8s' and what is default is enough for the user to use it in either way. -gmann
Best regards,Hongbin
participants (3)
-
Ghanshyam Mann
-
Hongbin Lu
-
Michał Dulko