<div>                1. Of course you should upgrade every 6 months. I've never seen or heard of anyone doing that, but if you have the resources, I agree, that would be great. And yes, if you're upgrading a few versions, you may need to do one or more operating system upgrades along the way.<br><br>2. I've never seen an easy, smooth process. That being said, I've never done a single-version upgrade. If you upgrade every 6 months, then maybe it would be smooth and easy. The standard situation I saw during my contracting years is that a company has got themselves into a bind because they have a small team (or maybe 1 guy) running Openstack, and they haven't upgraded for a long time, so they hire me to clean up the mess.<br><br>4 (I think you meant 5 here?). I've never lost resources during an upgrade, but I would never promise customers that there is 0 percentage chance of loss. I always recommend that the customer be resilient against loss, for example by duplicating their application in multiple clusters and by maintaining backups of important data, and I strengthen that recommendation during upgrades.<br>            </div>            <div class="yahoo_quoted" style="margin:10px 0px 0px 0.8ex;border-left:1px solid #ccc;padding-left:1ex;">                        <div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">                                <div>                    On Thursday, March 2, 2023, 10:56:47 AM EST, Dmitriy Rabotyagov <noonedeadpunk@gmail.com> wrote:                </div>                <div><br></div>                <div><br></div>                <div><div dir="ltr">These are very weird statements and I can not agree with most of them.<br></div><div dir="ltr"><br></div><div dir="ltr">1. You should upgrade in time. All problems come if you try to avoid<br></div><div dir="ltr">upgrades at any costs - then you're indeed in a situation when<br></div><div dir="ltr">upgrades are painful as you're running obsolete stuff that is not<br></div><div dir="ltr">supported anymore and not provided by your distro (or distro also is<br></div><div dir="ltr">not supported as well).<br></div><div dir="ltr">With SLURP releases you will be able to do upgrades yearly starting<br></div><div dir="ltr">with Antelope. Before that upgrades should be done each 6 month<br></div><div dir="ltr">basically. Jumping through 1 release was not supported before but is<br></div><div dir="ltr">doable given some preparation and small hacks. Jumping through more<br></div><div dir="ltr">than 1 release will almost certainly guarantee you pain. Upgrades to<br></div><div dir="ltr">next releases are well tested both by individual projects and by<br></div><div dir="ltr">OpenStack-Ansible, so given you've looked through release notes and<br></div><div dir="ltr">adjusted configuration - it should be just fine.<br></div><div dir="ltr"><br></div><div dir="ltr">2. It's quite an easy and relatively smooth process as of today. Yes,<br></div><div dir="ltr">you will have small API interruptions during the upgrade and when<br></div><div dir="ltr">services do restart they drop connections. But we control HAproxy<br></div><div dir="ltr">backends to minimize the effect of this. In many cases upgrade can be<br></div><div dir="ltr">performed just running scripts/run_upgrade.sh - it will work given<br></div><div dir="ltr">it's ran against healthy cluster (meaning that you don't have dead<br></div><div dir="ltr">galera or rabbit node in your cluster). At the moment we spend around<br></div><div dir="ltr">a working day for upgrading a region, but planning to automate this<br></div><div dir="ltr">process soonish to perform upgrades of production environments using<br></div><div dir="ltr">Zuul. We also never had to rollback, as rollback is indeed painful<br></div><div dir="ltr">process that you can hard process. So I won't sugggest rolling back<br></div><div dir="ltr">production environment unless it's absolutely needed.<br></div><div dir="ltr"><br></div><div dir="ltr">3. This is smth I will agree with. You can take a look at our MNAIO<br></div><div dir="ltr">[1] that can help you to spawn a virtual sandbox with multiple nodes<br></div><div dir="ltr">in it, where you can play with upgrades. Also I'd suggest running<br></div><div dir="ltr">tempest or rally tests regularly. They are helpful indeed.<br></div><div dir="ltr"><br></div><div dir="ltr">4. I'm not sure what's meant here at all. I can hardly imagine how you<br></div><div dir="ltr">can fail an OpenStack upgrade in a way that you will lose customer<br></div><div dir="ltr">data. I can recall such failures with Ceph though, but it was<br></div><div dir="ltr">somewhere around Hammer release (0.84 or smth) which is not the case<br></div><div dir="ltr">for quite a while as well.<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">[1] <a href="https://opendev.org/openstack/openstack-ansible-ops/src/branch/master/multi-node-aio" target="_blank">https://opendev.org/openstack/openstack-ansible-ops/src/branch/master/multi-node-aio</a><br></div><div dir="ltr"><br></div><div dir="ltr">чт, 2 мар. 2023 г. в 15:15, Albert Braden <<a ymailto="mailto:ozzzo@yahoo.com" href="mailto:ozzzo@yahoo.com">ozzzo@yahoo.com</a>>:<br></div><div dir="ltr">><br></div><div dir="ltr">> Having done a few upgrades, I can give you some general advice:<br></div><div dir="ltr">><br></div><div dir="ltr">> 1. If you can avoid upgrading, do it! If you are lucky enough to have customers who are willing (or can be forced) to accept a "refresh" strategy whereby you build a new cluster and move them to it, that is substantially easier and safer.<br></div><div dir="ltr">><br></div><div dir="ltr">> 2. If you must upgrade, go into it with the understanding that it is a difficult and dangerous process, and that avoiding failure will require meticulous preparation. Try to duplicate all of the weird things that your customers are doing, in your lab environment, then upgrade and roll it back repeatedly, documenting the steps in great detail (ideally automating them as much as possible) until you can roll forward and back in your sleep.<br></div><div dir="ltr">><br></div><div dir="ltr">> 3. Develop a comprehensive test procedure (ideally automated) that tests standard, edge and corner cases before and after the upgrade/rollback.<br></div><div dir="ltr">><br></div><div dir="ltr">> 4. Expect different clusters to behave differently during the upgrade, and to present unique problems, even though as far as you know they are setup identically. Expect to see issues in your prod clusters that you didn't see in lab/dev/QA, and budget extra downtime to solve those issues.<br></div><div dir="ltr">><br></div><div dir="ltr">> 5. Recommend to your customers that they backup their data and configurations, so that they can recover if an upgrade fails and their resources are lost. Set the expectation that there is a non-zero probability of failure.<br></div><div dir="ltr">> On Wednesday, March 1, 2023, 07:54:30 AM EST, Dmitriy Rabotyagov <<a ymailto="mailto:noonedeadpunk@gmail.com" href="mailto:noonedeadpunk@gmail.com">noonedeadpunk@gmail.com</a>> wrote:<br></div><div dir="ltr">><br></div><div dir="ltr">><br></div><div dir="ltr">> Hey,<br></div><div dir="ltr">><br></div><div dir="ltr">> Regarding rollaback of upgrade in OSA we indeed don't have any good<br></div><div dir="ltr">> established/documented process for that. At the same time it should be<br></div><div dir="ltr">> completely possible with some "BUT". It also depends on what exactly<br></div><div dir="ltr">> you want to rollback - roles, openstack services or both. As OSA roles<br></div><div dir="ltr">> can actually install any openstack service version.<br></div><div dir="ltr">><br></div><div dir="ltr">> We keep all virtualenvs from the previous version, so during upgrade<br></div><div dir="ltr">> we build just new virtualenvs and reconfigure systemd units to point<br></div><div dir="ltr">> there. So fastest way likely would be to just edit systemd unit files<br></div><div dir="ltr">> and point them to old venv version and reload systemd daemon and<br></div><div dir="ltr">> service and restore DB from backup of course.<br></div><div dir="ltr">> You can also define  <service>_venv_tag (ie `glance_venv_tag`) to the<br></div><div dir="ltr">> old OSA version you was running and execute openstack-ansible<br></div><div dir="ltr">> os-<service>-install.yml --tags  systemd-service,uwsgi - that in most<br></div><div dir="ltr">> cases will be enough to just edit systemd units for the service and<br></div><div dir="ltr">> start old version of it. BUT running without tags will result in<br></div><div dir="ltr">> having new packages in old venv which is smth you totally want to<br></div><div dir="ltr">> avoid.<br></div><div dir="ltr">> To prevent that you can also define <service>_git_install_branch and<br></div><div dir="ltr">> requirements_git_install_branch in /etc/openstack_deploy/group_vars<br></div><div dir="ltr">> (it's important to use group vars if you want to rollback only one<br></div><div dir="ltr">> service) and take value from<br></div><div dir="ltr">> <a href="https://opendev.org/openstack/openstack-ansible/src/tag/26.0.1/playbooks/defaults/repo_packages/openstack_services.yml" target="_blank">https://opendev.org/openstack/openstack-ansible/src/tag/26.0.1/playbooks/defaults/repo_packages/openstack_services.yml</a><br></div><div dir="ltr">> (ofc pick your old version!)<br></div><div dir="ltr">><br></div><div dir="ltr">> For a full rollback and not in-place workarounds, I think it should be like that<br></div><div dir="ltr">> * checkout to previous osa version<br></div><div dir="ltr">> * re-execute scripts/bootstrap-ansible.sh<br></div><div dir="ltr">> * you should still take current versions of mariadb and rabbitmq and<br></div><div dir="ltr">> define them in user_variables (galera_major_version,<br></div><div dir="ltr">> galera_minor_version, rabbitmq_package_version,<br></div><div dir="ltr">> rabbitmq_erlang_version_spec) - it's close to never ends well<br></div><div dir="ltr">> downgrading these.<br></div><div dir="ltr">> * Restore DB backup<br></div><div dir="ltr">> * Re-run setup-openstack.yml<br></div><div dir="ltr">><br></div><div dir="ltr">> It's quite a rough summary of how I do see this process, but to be<br></div><div dir="ltr">> frank I never had to execute full downgrade - I was limited mostly by<br></div><div dir="ltr">> downgrading 1 service tops after the upgrade.<br></div><div dir="ltr">><br></div><div dir="ltr">> Hope that helps!<br></div><div dir="ltr">><br></div><div dir="ltr">> ср, 1 мар. 2023 г. в 12:06, Adivya Singh <<a ymailto="mailto:adivya1.singh@gmail.com" href="mailto:adivya1.singh@gmail.com">adivya1.singh@gmail.com</a>>:<br></div><div dir="ltr">><br></div><div dir="ltr">> ><br></div><div dir="ltr">> > hi Alvaro,<br></div><div dir="ltr">> ><br></div><div dir="ltr">> > i have installed using Openstack-ansible, The upgrade procedure is consistent<br></div><div dir="ltr">> ><br></div><div dir="ltr">> > but what is the roll back procedure , i m looking for<br></div><div dir="ltr">> ><br></div><div dir="ltr">> > Regards<br></div><div dir="ltr">> > Adivya Singh<br></div><div dir="ltr">> ><br></div><div dir="ltr">> > On Wed, Mar 1, 2023 at 12:46 PM Alvaro Soto <<a ymailto="mailto:alsotoes@gmail.com" href="mailto:alsotoes@gmail.com">alsotoes@gmail.com</a>> wrote:<br></div><div dir="ltr">> >><br></div><div dir="ltr">> >> That will depend on how did you installed your environment: OSA, TripleO, etc.<br></div><div dir="ltr">> >><br></div><div dir="ltr">> >> Can you provide more information?<br></div><div dir="ltr">> >><br></div><div dir="ltr">> >> ---<br></div><div dir="ltr">> >> Alvaro Soto.<br></div><div dir="ltr">> >><br></div><div dir="ltr">> >> Note: My work hours may not be your work hours. Please do not feel the need to respond during a time that is not convenient for you.<br></div><div dir="ltr">> >> ----------------------------------------------------------<br></div><div dir="ltr">> >> Great people talk about ideas,<br></div><div dir="ltr">> >> ordinary people talk about things,<br></div><div dir="ltr">> >> small people talk... about other people.<br></div><div dir="ltr">> >><br></div><div dir="ltr">> >> On Tue, Feb 28, 2023, 11:46 PM Adivya Singh <<a ymailto="mailto:adivya1.singh@gmail.com" href="mailto:adivya1.singh@gmail.com">adivya1.singh@gmail.com</a>> wrote:<br></div><div dir="ltr">> >>><br></div><div dir="ltr">> >>> Hi Team,<br></div><div dir="ltr">> >>><br></div><div dir="ltr">> >>> I am planning to upgrade my Current Environment, The Upgrade procedure is available in OpenStack Site and Forums.<br></div><div dir="ltr">> >>><br></div><div dir="ltr">> >>> But i am looking fwd to roll back Plan , Other then have a Local backup copy of galera Database<br></div><div dir="ltr">> >>><br></div><div dir="ltr">> >>> Regards<br></div><div dir="ltr">> >>> Adivya Singh<br></div><div dir="ltr">><br></div><div dir="ltr"><br></div></div>            </div>                </div>