<div dir="ltr">Jay's approach is really neat and that how it done in big productions, sadly there is a problem with implementation of it in Kolla. I'd consider to dig into it, maybe there is nice way to do so. If not, original approach is ok too.</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 7, 2015 at 10:06 AM, Steven Dake (stdake) <span dir="ltr"><<a href="mailto:stdake@cisco.com" target="_blank">stdake@cisco.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
On 12/6/15, 9:47 PM, "Jay Pipes" <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>> wrote:<br>
<br>
>On 12/07/2015 04:28 AM, Michał Jastrzębski wrote:<br>
>> On 6 December 2015 at 09:33, Jay Pipes <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>> wrote:<br>
>>><br>
>>> On 12/04/2015 11:50 PM, Michał Jastrzębski wrote:<br>
>>>><br>
>>>> Hey guys,<br>
>>>><br>
>>>> Orchiestrated upgrades is one of our highest priorities for M in<br>
>>>> kolla, so following up after discussion on summit I'd like to<br>
>>>> suggest an approach:<br>
>>>><br>
>>>> Instead of creating playbook called "upgrade my openstack" we<br>
>>>> will create "upgrade my nova" instead and approach to each<br>
>>>> service case by case (since all of our running services are in<br>
>>>> dockers, this is possible). We will also make use of image tags<br>
>>>> as version carriers, so ansible will deploy new container only if<br>
>>>> version tag differs from what we ask it to deploy. This will help<br>
>>>> with idempotency of upgrade process.<br>
>>>><br>
>>>> So let's start with nova. Upgrade-my-nova playbook will do<br>
>>>> something like this:<br>
>>>><br>
>>>> 0. We create snapshot of our mariadb-data container. This will<br>
>>>> affect every service, but it's always good to have backup and<br>
>>>> rollback of db will be manual action<br>
>>>><br>
>>>> 1. Nova bootstrap will be called and it will perform<br>
>>>> db-migration. Since current approach to nova code is add-only we<br>
>>>> shouldn't need to stop services and old services should keep<br>
>>>> working on newer database. Also for minor version upgrades there<br>
>>>> will be no action here unless there is migration. 2. We upgrade<br>
>>>> all conductor at the same time. This should take mere seconds<br>
>>>> since we'll have prebuilt containers 3. We will upgrade rest of<br>
>>>> controller services with using "series: 1" in ansible to ensure<br>
>>>> rolling upgrades. 4. We will upgrade all of nova-compute services<br>
>>>> on it's own pace.<br>
>>>><br>
>>>> This workflow should be pretty robust (I think it is) and it<br>
>>>> should also provide idempotency.<br>
>>><br>
>>><br>
>>> From Nova's perspective, most of the above looks OK to me, however,<br>
>>> I am in more in favor of an upgrade strategy that builds a "new"<br>
>>> set of conductor or controller service containers all at once and<br>
>>> then flips the VIP or managed IP from the current controller pod<br>
>>> containers to the newly-updated controller pod containers.<br>
>><br>
>> Well, we can't really do that because that would affect all other<br>
>> services on controller host, and we want to minimize impact on rest<br>
>> of cluster during upgrade. Containers gives us option to upgrade<br>
>> "just nova", or even "just nova conductors" without affecting<br>
>> anything else. On the bright side, redeploying pre-built container is<br>
>> a matter of seconds (or even less). Whole process from turning off<br>
>> last conductor to spawn first new conductor should take less than<br>
>> 10s, and that's only downtime we should get there.<br>
><br>
>Sorry, I guess I wasn't clear. I was not proposing to put all controller<br>
>services in a single container. I was proposing simply to build the<br>
>various container sets (nova-conductor, nova-api, etc) with the updated<br>
>code for that service and then "flip the target IP or port" for that<br>
>particular service from the existing container set's VIP to the<br>
>new/updated container set's VIP.<br>
><br>
>In Kubernetes-speak, you would create a new Pod with containers having<br>
>the updated Nova conductor code, and would set the new Pod's selector to<br>
>something different than the existing Pod's selector -- using the Git<br>
>SHA1 hash for the selector would be perfect... You would then update the<br>
>Service object's selector to target the new Pod instead of the old one.<br>
><br>
>Or, alternately, you could use Kubernetes' support for rolling updates<br>
>[1] of a service using a ReplicationController that essentially does the<br>
>Pod and Service orchestration for you.<br>
><br>
>Hope that is a little more clear what I was referring to...<br>
><br>
>Best,<br>
>-jay<br>
<br>
</div></div>Jay,<br>
<br>
Forgive me if this is a little incoherent - I have a root canal scheduled<br>
for tomorrow with the fun-filled day that comes  comes with :(<br>
<br>
We don't use docker-proxy in kolla.  Instead we use net=host mode.  I<br>
think what you propose would require an extra global VIP for upgrades (or<br>
using docker-proxy, which we don't want to do). I am not really hot on<br>
this approach for that reason.<br>
<br>
Regards<br>
-stee<br>
<br>
><br>
>[1]<br>
><a href="https://github.com/kubernetes/kubernetes/blob/master/docs/user-guide/repli" rel="noreferrer" target="_blank">https://github.com/kubernetes/kubernetes/blob/master/docs/user-guide/repli</a><br>
<div class="HOEnZb"><div class="h5">><a href="http://cation-controller.md#rolling-updates" rel="noreferrer" target="_blank">cation-controller.md#rolling-updates</a><br>
><br>
>>> This seems to me to be the most efficient (in terms of minimal<br>
>>> overall downtime) and most robust (because a "rollback" is simply<br>
>>> flipping the VIP back to the original controller/conductor service<br>
>>> pod containers) solution for upgrading Nova.<br>
>><br>
>><br>
>>><br>
>>> Dan Smith, can you comment on this since you are the God of<br>
>>> Upgrades?<br>
>>><br>
>>> Best, -jay<br>
>>><br>
>>><br>
>>><br>
>>>________________________________________________________________________<br>
>>>__<br>
>>><br>
>>><br>
>OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe:<br>
>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>><br>
>>_________________________________________________________________________<br>
>>_<br>
>><br>
>><br>
>OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe:<br>
>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
>__________________________________________________________________________<br>
>OpenStack Development Mailing List (not for usage questions)<br>
>Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div style="color:rgb(136,136,136);font-size:12.8px"><div dir="ltr">Best regards,<br>Proskurin Kirill</div></div></div></div></div></div>
</div>