Re: [openstack-dev] [kolla][kolla-kubernetes][kubernetes]

[Ryan Hallisey]

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

Re: [openstack-dev] [kolla][kolla-kubernetes][kubernetes]

[Britt Houser (bhouser)]

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"  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-dev] [kolla][kolla-kubernetes][kubernetes]

[Ryan Hallisey]

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