Re: [Openstack-operators] Openstack release compatibility
Hello, OpenStack-Ansible Mitaka deploys Linux Bridge by default. This would still happen, but as said, it's not too big of a deal too. Best regards, Jean-Philippe (evrardjp) On 6 November 2017 at 08:10, Kevin Bentonwrote: > The Neutron OVS agent should not cause interrupts on restart in the later > versions (Liberty+ https://review.openstack.org/#/c/215596/) of OpenStack > since they don't destroy old flows until the new ones are setup so you > should be able to safely do that. > > On Fri, Nov 3, 2017 at 9:22 AM, Jean-Philippe Evrard > wrote: >> >> Hello, >> >> I think you'll face end user downtime anyway, due to _at least_ >> neutron agents flapping. But yes it can be fairly limited. >> I can't say for restart or no restart. I think it's possible to do >> without restarting, but I also think you should have plan for the >> restarts, else how do you do your critical security updates for things >> like kernel? >> >> Just my 2 cents, it's probably good to have other opinions out there. >> >> Best regards, >> Jean-Philippe Evrard (evrardjp) >> >> On 3 November 2017 at 13:19, haad wrote: >> > Hi, >> > >> > I have one additional question. What is your experience with updating >> > OpenStack in place on compute nodes with out rebooting them. Can we >> > update >> > e.g. mitaka to newton and leave machines running on compute node running >> > ? >> > (if libvirt/kvm/os update is necessary we can do it after.) >> > >> > On Fri, Nov 3, 2017 at 8:22 AM, Jean-Philippe Evrard >> > wrote: >> >> >> >> On 2 November 2017 at 18:17, Chris Friesen >> >> >> >> wrote: >> >> > On 10/31/2017 01:13 AM, haad wrote: >> >> >> >> >> >> Hi, >> >> >> >> >> >> We have an OSA installation with 10-12 compute nodes running Mitaka >> >> >> on >> >> >> Ubuntu >> >> >> 16.04. As initially we have not prepared any long term update >> >> >> strategy >> >> >> we >> >> >> would >> >> >> like to create one now. Plan would be to upgrade it to new OSA >> >> >> release(Ocata/Pike/Queens) in near future. >> >> >> >> >> >> Our original plan was to update management/networking/backend at >> >> >> once >> >> >> by >> >> >> using >> >> >> rolling updates to newer release and then upgrade compute nodes one >> >> >> by >> >> >> one >> >> >> to >> >> >> new release.. I think that [2] provides a general upgrade manual. Is >> >> >> there >> >> >> any >> >> >> document describing how are different OSA releases compatible ? Is >> >> >> there >> >> >> any >> >> >> policy in place about backward compatibility ? >> >> > >> >> > >> >> > As a general rule, OpenStack only supports an online upgrade of one >> >> > version >> >> > at a time. That is, controller nodes running version N can talk to >> >> > compute >> >> > nodes running version N-1. >> >> > >> >> > If you can tolerate downtime of the API layer, there has been some >> >> > discussion around "skip-level" upgrades. >> >> > >> >> > Chris >> >> > >> >> > >> >> > >> >> > ___ >> >> > OpenStack-operators mailing list >> >> > OpenStack-operators@lists.openstack.org >> >> > >> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >> >> >> >> Hello, >> >> >> >> Having worked on "skip level" upgrades, I can tell you that it's >> >> simpler to do the upgrades in a row, because it's a more tested path. >> >> >> >> Best regards, >> >> Jean-Philippe Evrard (evrardjp) >> >> >> >> ___ >> >> OpenStack-operators mailing list >> >> OpenStack-operators@lists.openstack.org >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >> > >> > >> > >> > >> > -- >> > >> > >> > Regards. >> > >> > Adam >> >> ___ >> OpenStack-operators mailing list >> OpenStack-operators@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Openstack release compatibility
Hello, I think you'll face end user downtime anyway, due to _at least_ neutron agents flapping. But yes it can be fairly limited. I can't say for restart or no restart. I think it's possible to do without restarting, but I also think you should have plan for the restarts, else how do you do your critical security updates for things like kernel? Just my 2 cents, it's probably good to have other opinions out there. Best regards, Jean-Philippe Evrard (evrardjp) On 3 November 2017 at 13:19, haadwrote: > Hi, > > I have one additional question. What is your experience with updating > OpenStack in place on compute nodes with out rebooting them. Can we update > e.g. mitaka to newton and leave machines running on compute node running ? > (if libvirt/kvm/os update is necessary we can do it after.) > > On Fri, Nov 3, 2017 at 8:22 AM, Jean-Philippe Evrard > wrote: >> >> On 2 November 2017 at 18:17, Chris Friesen >> wrote: >> > On 10/31/2017 01:13 AM, haad wrote: >> >> >> >> Hi, >> >> >> >> We have an OSA installation with 10-12 compute nodes running Mitaka on >> >> Ubuntu >> >> 16.04. As initially we have not prepared any long term update strategy >> >> we >> >> would >> >> like to create one now. Plan would be to upgrade it to new OSA >> >> release(Ocata/Pike/Queens) in near future. >> >> >> >> Our original plan was to update management/networking/backend at once >> >> by >> >> using >> >> rolling updates to newer release and then upgrade compute nodes one by >> >> one >> >> to >> >> new release.. I think that [2] provides a general upgrade manual. Is >> >> there >> >> any >> >> document describing how are different OSA releases compatible ? Is >> >> there >> >> any >> >> policy in place about backward compatibility ? >> > >> > >> > As a general rule, OpenStack only supports an online upgrade of one >> > version >> > at a time. That is, controller nodes running version N can talk to >> > compute >> > nodes running version N-1. >> > >> > If you can tolerate downtime of the API layer, there has been some >> > discussion around "skip-level" upgrades. >> > >> > Chris >> > >> > >> > >> > ___ >> > OpenStack-operators mailing list >> > OpenStack-operators@lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >> >> Hello, >> >> Having worked on "skip level" upgrades, I can tell you that it's >> simpler to do the upgrades in a row, because it's a more tested path. >> >> Best regards, >> Jean-Philippe Evrard (evrardjp) >> >> ___ >> OpenStack-operators mailing list >> OpenStack-operators@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > > > > -- > > > Regards. > > Adam ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Openstack release compatibility
Hi, I have one additional question. What is your experience with updating OpenStack in place on compute nodes with out rebooting them. Can we update e.g. mitaka to newton and leave machines running on compute node running ? (if libvirt/kvm/os update is necessary we can do it after.) On Fri, Nov 3, 2017 at 8:22 AM, Jean-Philippe Evrard < jean-phili...@evrard.me> wrote: > On 2 November 2017 at 18:17, Chris Friesen> wrote: > > On 10/31/2017 01:13 AM, haad wrote: > >> > >> Hi, > >> > >> We have an OSA installation with 10-12 compute nodes running Mitaka on > >> Ubuntu > >> 16.04. As initially we have not prepared any long term update strategy > we > >> would > >> like to create one now. Plan would be to upgrade it to new OSA > >> release(Ocata/Pike/Queens) in near future. > >> > >> Our original plan was to update management/networking/backend at once by > >> using > >> rolling updates to newer release and then upgrade compute nodes one by > one > >> to > >> new release.. I think that [2] provides a general upgrade manual. Is > there > >> any > >> document describing how are different OSA releases compatible ? Is there > >> any > >> policy in place about backward compatibility ? > > > > > > As a general rule, OpenStack only supports an online upgrade of one > version > > at a time. That is, controller nodes running version N can talk to > compute > > nodes running version N-1. > > > > If you can tolerate downtime of the API layer, there has been some > > discussion around "skip-level" upgrades. > > > > Chris > > > > > > > > ___ > > OpenStack-operators mailing list > > OpenStack-operators@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > Hello, > > Having worked on "skip level" upgrades, I can tell you that it's > simpler to do the upgrades in a row, because it's a more tested path. > > Best regards, > Jean-Philippe Evrard (evrardjp) > > ___ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > -- Regards. Adam ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Openstack release compatibility
On 2 November 2017 at 18:17, Chris Friesenwrote: > On 10/31/2017 01:13 AM, haad wrote: >> >> Hi, >> >> We have an OSA installation with 10-12 compute nodes running Mitaka on >> Ubuntu >> 16.04. As initially we have not prepared any long term update strategy we >> would >> like to create one now. Plan would be to upgrade it to new OSA >> release(Ocata/Pike/Queens) in near future. >> >> Our original plan was to update management/networking/backend at once by >> using >> rolling updates to newer release and then upgrade compute nodes one by one >> to >> new release.. I think that [2] provides a general upgrade manual. Is there >> any >> document describing how are different OSA releases compatible ? Is there >> any >> policy in place about backward compatibility ? > > > As a general rule, OpenStack only supports an online upgrade of one version > at a time. That is, controller nodes running version N can talk to compute > nodes running version N-1. > > If you can tolerate downtime of the API layer, there has been some > discussion around "skip-level" upgrades. > > Chris > > > > ___ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators Hello, Having worked on "skip level" upgrades, I can tell you that it's simpler to do the upgrades in a row, because it's a more tested path. Best regards, Jean-Philippe Evrard (evrardjp) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Openstack release compatibility
On 10/31/2017 01:13 AM, haad wrote: Hi, We have an OSA installation with 10-12 compute nodes running Mitaka on Ubuntu 16.04. As initially we have not prepared any long term update strategy we would like to create one now. Plan would be to upgrade it to new OSA release(Ocata/Pike/Queens) in near future. Our original plan was to update management/networking/backend at once by using rolling updates to newer release and then upgrade compute nodes one by one to new release.. I think that [2] provides a general upgrade manual. Is there any document describing how are different OSA releases compatible ? Is there any policy in place about backward compatibility ? As a general rule, OpenStack only supports an online upgrade of one version at a time. That is, controller nodes running version N can talk to compute nodes running version N-1. If you can tolerate downtime of the API layer, there has been some discussion around "skip-level" upgrades. Chris ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Openstack release compatibility
On 31 October 2017 at 07:13, haadwrote: > Hi, > > We have an OSA installation with 10-12 compute nodes running Mitaka on > Ubuntu 16.04. As initially we have not prepared any long term update > strategy we would like to create one now. Plan would be to upgrade it to new > OSA release(Ocata/Pike/Queens) in near future. > > Our original plan was to update management/networking/backend at once by > using rolling updates to newer release and then upgrade compute nodes one by > one to new release.. I think that [2] provides a general upgrade manual. Is > there any document describing how are different OSA releases compatible ? Is > there any policy in place about backward compatibility ? > > > > [1] https://etherpad.openstack.org/p/osa-newton-xenial-upgrade > [2] https://wiki.openstack.org/wiki/Upgrade-with-minimal-downtime > > -- > > > Regards. > > Adam > > ___ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > Hello, I'd advise you to follow the standard OpenStack-Ansible path, which is upgrading from Mitaka to Newton, then do your ubuntu upgrade to xenial. From Newton onwards, we have code taking care of the rolling part of the upgrade, which should help you getting to Pike, after a series of upgrades (N->O->P) under ubuntu 16.04. Best regards, Jean-Philippe Evrard (evrardjp) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] Openstack release compatibility
Hi, We have an OSA installation with 10-12 compute nodes running Mitaka on Ubuntu 16.04. As initially we have not prepared any long term update strategy we would like to create one now. Plan would be to upgrade it to new OSA release(Ocata/Pike/Queens) in near future. Our original plan was to update management/networking/backend at once by using rolling updates to newer release and then upgrade compute nodes one by one to new release.. I think that [2] provides a general upgrade manual. Is there any document describing how are different OSA releases compatible ? Is there any policy in place about backward compatibility ? [1] https://etherpad.openstack.org/p/osa-newton-xenial-upgrade [2] https://wiki.openstack.org/wiki/Upgrade-with-minimal-downtime -- Regards. Adam ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators