rhallise at redhat.com
Mon May 23 14:13:55 UTC 2016
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.
----- Original Message -----
From: "Britt Houser (bhouser)" <bhouser at cisco.com>
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at 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?
On 5/22/16, 3:50 PM, "Ryan Hallisey" <rhallise at redhat.com> wrote:
>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
>Currently, in the kolla-kubernetes spec , 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 .
>There is also the introduction to wait.for conditions in the kubectl .
> 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!
> SPEC - https://review.openstack.org/#/c/304182/
> Init containers - https://github.com/kubernetes/kubernetes/pull/23567
> wait.for kubectl - https://github.com/kubernetes/kubernetes/issues/1899
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev