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

Reply via email to