Right, I wouldn't either. The problem has to do with being able to clearly define the difference between bootstrapping and upgrading in Kubernetes. Bootstrapping has a series of steps it needs to run. Upgrades have a different series of steps. How can kolla-kubernetes be able to perform one or the other based on whether the operator is boostrapping or upgrading the same pod? And how will those steps be ordered?
Maybe a combination of Kubernetes hooks and health checks could solve this? I'm not entirely sure. However, you can still get bootstrapping and upgrades using outside orchestration. For now, I think kolla-kubernetes will focus on outside orchestration until Kubernetes reaches a point where the community can do this in a pod. Thanks, Ryan ----- Original Message ----- From: "Britt Houser (bhouser)" <bhou...@cisco.com> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Sent: Monday, May 23, 2016 8:49:43 AM Subject: Re: [openstack-dev] [kolla][kolla-kubernetes][kubernetes] I wouldn't expect new users to be created on upgrade, so is the problem with bootstrap and upgrade that we do the database migration during bootstrap too? Thx, britt On 5/22/16, 3:50 PM, "Ryan Hallisey" <rhall...@redhat.com> wrote: >Hi all, > >At the Kolla meeting last week, I brought up some of the challenges around the >bootstrapping >process in Kubernetes. The main highlight revolved around how the >bootstrapping process will >work. > >Currently, in the kolla-kubernetes spec [1], the process for bootstrapping >involves >outside orchestration running Kubernetes 'Jobs' that will handle the database >initialization, >creating users, etc... One of the flaws in this approach, is that >kolla-kubernetes can't use >native Kubernetes upgrade tooling. Kubernetes does upgrades as a single action >that scales >down running containers and replaces them with the upgraded containers. So >instead of having >Kubernetes manage the upgrade, it would be guided by an external engine. Not >saying this is >a bad thing, but it does loosen the control Kubernetes would have over stack >management. > >Kubernetes does have some incoming new features that are a step in the right >direction to >allow for kolla-kubernetes to make complete use of Kubernetes tooling like >init containers [2]. >There is also the introduction to wait.for conditions in the kubectl [3]. > > kubectl get pod my-pod --wait --wait-for="pod-running" > >Upgrades will be in the distant future for kolla-kubernetes, but I want to >make sure the >community maintains an open mind about bootstrap/upgrades since there are >potentially many >options that could come down the road. > >I encourage everyone to add your input to the spec! > >Thanks, >Ryan > >[1] SPEC - https://review.openstack.org/#/c/304182/ >[2] Init containers - https://github.com/kubernetes/kubernetes/pull/23567 >[3] wait.for kubectl - https://github.com/kubernetes/kubernetes/issues/1899 > >__________________________________________________________________________ >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 __________________________________________________________________________ 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
