1. Backups

Well, having a backup of /etc/openstack_deploy and mysql databases are
indeed most crucial parts you need to have in order to restore cluster
functionality if smth goes wrong.

2. All manual changes made to conf files, without being reflected in
/etc/openstack_deploy will be overwritten

3. a) I'm not sure I got this question... If you're asking about
service order - best way to check is open setup-openstack.yml playbook
- it consists of includes that shows the order of services in which
they will be upgraded.
I guess, I would be extra cautious just with the neutron, as service
restart might lead to some networking disruptions, as namespaces could
get re-created or failover - there were couple of bugs both in neutron
and ovs for instance, that could lead to weird things. Not sure all of
them were backported to Ussuri and to the distro you're using.
b) Well. We had quite some improvements in this field lately. Back in
the days, not all services were upgraded in a serial manner. But most
of the core ones were, meaning that in general the 1st container is
being brought down for upgrade, and once it's back - other 2 are
processed. But Ussuri is relatively old, so I can assume that for some
services it could still be upgraded in parallel.

4. Actually, there's no super trivial answer to this question. One way
of thinking of that, could be checking out openstack-ansible to
previous tag and re-running things. Another way, could be to manually
adjusting path to services in systemd unit files to old venv and
restarting them (since we leave all prior venvs on host systems, and
they're all versioned as well). Though, this will not recover versions
of config files, in case any manual changes were made to them. As it's
assumed, that all config changes should be reflected in
/etc/openstack_deploy

5. Usually minor upgrades are really jsut fine, given that you haven't
messed up with anything manually... If you did - I guess I'd backup
/etc/<service> directories just for the history as well....

пт, 15 мар. 2024 г. в 11:34, keshav bareja <keshav.bareja@gmail.com>:
>
> Hi Dmitriy
>
> Thanks for the responses.
> I am further checking the preparation steps for the minor update from 21.2.6 to Ussuri- EOL and have further queries on it.
>
> 1. Backup Plan:
>
> I am referring these two guides for the same .
> Do you think it is sufficient?
>
> https://docs.openstack.org/openstack-ansible/latest/admin/backup-restore.html
>
> https://docs.openstack.org/operations-guide/ops-backup-recovery.html
>
> 2. Existing configuration changes which are done directly on the .conf files or using adhoc ansible command and not using openstack-ansible variable files.
> can you please confirm if those configurational changes will stay or all will be overwritten to the defaults.
>
> 3. Impact during the minor update.
> can you please confirm what will be the impact during the update.
> a) what will be the sequence of restart of the service containers if we update all services options
>
> Update all OpenStack services:
>
> # openstack-ansible setup-openstack.yml
>
> b) at a given time all containers of one service will be down or 1 at a time.
>
> 4. Fallback plan:
> How can we rollback to the previous version?
>
> 5. Any other prerequisite, we need to perform before performing the minor update following below procedure:
> https://docs.openstack.org/openstack-ansible/ussuri/admin/upgrades/minor-upgrades.html
>
> Regards
> Keshav
>
>
> On Fri, Mar 1, 2024 at 7:39 PM Dmitriy Rabotyagov <noonedeadpunk@gmail.com> wrote:
>>
>> Hey,
>>
>> 1. You can check installed version through:
>> 1.a On the deploy host check for installed binary in PIP:
>> /opt/ansible-runtime/bin/pip show openstack-ansible
>> 1.b On any host check /etc/openstack-release file
>> 2. So, Ussuri has already reached its End Of Life. So latest "version"
>> would be `ussuri-eol`. I would highly recommend performing Major
>> upgrade instead...
>> 3. We are not always great in issuing a release note for each bugfix
>> landed. Moreover, we do not track bugfixes in other upstream projects
>> by design. So that is not a trivial task to achieve. Basically you'd
>> need to "compare" changes made for each project based on their SHA
>> change... So there's no good and easy way to get full picture of
>> bugfixes.
>> But eventually, each OpenStack-Ansible release is just a
>> representation of SHAs for roles and services, so you can relatively
>> easily see changes in git made for each.
>> 4. Usually minor upgrades don't have many prerequisites. But here the
>> problem is, that the version you're running was EOLed some time ago.
>> So no CI was run for quite some time and the current state of the
>> branch is really unknown. But you should totally check this doc for
>> minor upgrades [1]
>>
>> [1] https://docs.openstack.org/openstack-ansible/latest/admin/upgrades/minor-upgrades.html
>>
>> пт, 1 мар. 2024 г. в 18:46, keshav bareja <keshav.bareja@gmail.com>:
>> >
>> > Hi Team
>> >
>> > I am planning to update my environment from the current ussuri minor version to the latest minor version available for the Ussuri.
>> >
>> > I found the procedure below.
>> > https://docs.openstack.org/openstack-ansible/ussuri/admin/upgrades/minor-upgrades.html
>> >
>> > I have some queries on this:
>> > 1. How to find the current minor release version of the Ussuri deployed on my environment? Is there any command or way that can help?
>> > 2. What is the latest minor version available for Ussuri?
>> > In the Ussuri release notes page I could see 2.10, can someone please confirm if 2.10 is the latest version?
>> > 3. Also I need to know the bug fixes between my current release to the latest minor ussuri release.
>> > 4. Can someone confirm what all pre-requisite I need to take care of before going with the update.
>> > 5. Anyone having experience with such minor updates , Please share precaution and recommendations,
>> >
>> > Ussuri Series Release Notes
>> >
>> >
>> >
>> > 21.2.10
>> >
>> > Security Issues
>> >
>> > This release eliminates following security issues:
>> >
>> > OSSA-2021-005: https://security.openstack.org/ossa/OSSA-2021-005.html
>> >
>> > OSSA-2021-006: https://security.openstack.org/ossa/OSSA-2021-006.html