| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-04-12 | |||
| 10:34:25 | stephenfin | sean-k-mooney: sure | |
| 10:34:31 | dtantsur | maybe we did something wrong when migrating to zuul v3? | |
| 10:34:52 | sean-k-mooney | dtantsur: perhaps only the plugins seam to be listed | |
| 10:37:33 | elod | just for the record I've looked into the last successful run of ironic-grenade on stable/victoria and it also upgraded to oslo.messaging===12.5.2 | |
| 10:37:56 | sean-k-mooney | elod: did it upgrade the other serivces? | |
| 10:38:32 | sean-k-mooney | its likely not oslo.messaging by the way | |
| 10:38:44 | sean-k-mooney | i think the reraise decorator comes form oslo.utils | |
| 10:38:48 | elod | sean-k-mooney: yes: Upgrade projects: keystone placement swift glance neutron nova ironic | |
| 10:39:20 | sean-k-mooney | https://github.com/openstack/oslo.utils/blob/master/oslo_utils/excutils.py#L145 | |
| 10:39:29 | sean-k-mooney | elod: ya so thats what has changed | |
| 10:39:37 | elod | sean-k-mooney: it seems | |
| 10:39:38 | sean-k-mooney | now its just ironic | |
| 10:39:46 | elod | yes | |
| 10:40:05 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/train: Add regression test for bug #1908075 https://review.opendev.org/c/openstack/nova/+/785847 | |
| 10:40:09 | openstack | bug 1908075 in OpenStack Compute (nova) "Nova allows a non-multiattach volume to be attached to multiple instances *if* its volume state is reset by an admin" [Low,In progress] https://launchpad.net/bugs/1908075 - Assigned to Lee Yarwood (lyarwood) | |
| 10:40:10 | sean-k-mooney | do we use the victoria or ussuri version of grenade | |
| 10:40:10 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/train: api: Reject volume attach requests when an active bdm exists https://review.opendev.org/c/openstack/nova/+/785848 | |
| 10:40:28 | sean-k-mooney | e.g. is it the source or target version that does the upgrade | |
| 10:41:15 | elod | it should be victoria | |
| 10:41:26 | elod | in my understanding | |
| 10:41:46 | sean-k-mooney | ok then i should be looking at stable/victoria grenade so | |
| 10:49:55 | sean-k-mooney | i suspect the issue is with the grenaderc generation | |
| 10:50:05 | sean-k-mooney | UPGRADE_PROJECTS is empty by default | |
| 10:50:12 | sean-k-mooney | plugins are auto added to it | |
| 10:50:21 | sean-k-mooney | which is why ironic is there | |
| 10:51:06 | sean-k-mooney | there are added by register_project_for_upgrade | |
| 10:51:14 | sean-k-mooney | https://opendev.org/openstack/grenade/src/branch/master/inc/upgrade#L101-L111 | |
| 10:54:26 | sean-k-mooney | each of the in tree services should register them selves https://opendev.org/openstack/grenade/src/commit/15e02fec78cdcce00d302fc2c6c29afea91f6f14/projects/10_keystone/settings#L1 | |
| 10:54:55 | sean-k-mooney | but i am wondering if that setting file is correctly loaded | |
| 11:08:15 | yoctozepto | ok, so still no consensus on what has failed? | |
| 11:08:43 | yoctozepto | oh, I see the missing projects were confirmed | |
| 11:09:08 | yoctozepto | so then it's "only" a matter of tracking what introduced the breaking change in behaviour | |
| 11:11:23 | sean-k-mooney | yoctozepto: something cause the list of project to be changed ya im not seeing what that was at first glance | |
| 11:11:44 | yoctozepto | sean-k-mooney: ack | |
| 11:59:49 | openstackgerrit | Qiu Fossen proposed openstack/nova-specs master: Support live migrate vtpm server https://review.opendev.org/c/openstack/nova-specs/+/785860 | |
| 12:12:12 | openstackgerrit | Qiu Fossen proposed openstack/nova-specs master: Allow migrating PMEM's data https://review.opendev.org/c/openstack/nova-specs/+/785563 | |
| 12:15:13 | sean-k-mooney | stephenfin: didnt you support vtpm live migration already ^ | |
| 12:17:10 | openstackgerrit | Qiu Fossen proposed openstack/nova-specs master: Support live migrate vtpm server https://review.opendev.org/c/openstack/nova-specs/+/785860 | |
| 13:14:07 | Habib-A | i have a running production environment of Openstack with the following architecture | |
| 13:14:07 | Habib-A | Hello | |
| 13:14:08 | Habib-A | 1 controller node | |
| 13:14:08 | Habib-A | it was installed manually | |
| 13:14:09 | Habib-A | 3 physical compute nodes | |
| 13:14:09 | Habib-A | 1 network node | |
| 13:14:10 | Habib-A | is it possible to add HA to environment ? is it easy ? will cause data loss ? | |
| 13:14:10 | Habib-A | 1 cinder node | |
| 13:15:33 | yoctozepto | Habib-A: it's probably not the right channel to ask this question; it really depends on the deployment method you used (kolla/osa/tripleo/charms/helm...) | |
| 13:15:56 | yoctozepto | I assume you mean controller HA | |
| 13:16:06 | Habib-A | i did say i installed it manually | |
| 13:16:15 | Habib-A | im sorry if its the wrong place | |
| 13:16:21 | yoctozepto | it is usually quite straightforward and does not cause any data loss | |
| 13:16:31 | yoctozepto | ah, I missed that, sorry | |
| 13:16:44 | yoctozepto | I am into misreading today it seems | |
| 13:17:09 | Habib-A | is it fine even though its currently in production and the network node is not on the controller | |
| 13:17:28 | Habib-A | no problem my friend thank you very much for your help | |
| 13:17:41 | yoctozepto | yes, the network node can be separate | |
| 13:17:52 | yoctozepto | you can have different numbers of each of these | |
| 13:18:08 | sean-k-mooney | Habib-A: i would proably make the netwo contol and cinder nodes all contollers | |
| 13:18:42 | yoctozepto | ^ yeah, depending on your needs you might find yourselves happy setting these as your HA backups | |
| 13:19:02 | sean-k-mooney | you would do that by installing rabbit mq on all 3 nodes and making it a cluster behind a ha proxy instance | |
| 13:19:23 | sean-k-mooney | then do the same with the db add 2 more instance and use galera with haproxy in front | |
| 13:19:50 | sean-k-mooney | then deploy 2 more instance of each of the contoelr/network/cinder services | |
| 13:20:12 | sean-k-mooney | again using haproxy to loadbalance between them | |
| 13:20:23 | sean-k-mooney | that would be the most simple ha setup | |
| 13:20:39 | Habib-A | thats very cool many thanks | |
| 13:20:47 | sean-k-mooney | Habib-A: even if you are doing a manual install i would recommend looking at kolla-ansible as a reference | |
| 13:20:57 | sean-k-mooney | or consider moving to it :) | |
| 13:21:03 | Habib-A | hmmm i get you | |
| 13:21:39 | Habib-A | ? | |
| 13:21:39 | Habib-A | can i pm for more details > | |
| 13:22:05 | sean-k-mooney | i have never actully adopted an existing manual install into one of the deployment tools | |
| 13:22:20 | sean-k-mooney | and i generally use them to provide ha so i dont think i can help direclty | |
| 13:22:46 | sean-k-mooney | Habib-A: https://docs.openstack.org/ha-guide/ should help | |
| 13:23:23 | Habib-A | my question is how can i move the cinder and network to the controller | |
| 13:23:28 | Habib-A | without losing data | |
| 13:23:35 | sean-k-mooney | if you were interested in using kolla-ansible #openstack-kolla would proably be the best place to ask if you consier one of the other tool there channles too would be where you would ask | |
| 13:24:26 | sean-k-mooney | Habib-A: basically by doing a db backup and restore to the second and thrid db instance then froming a galare cluster making your current db the primary/leader | |
| 13:25:04 | Habib-A | i want to move to kolla but is it possible to migrate my currnet environment to the new environment | |
| 13:25:28 | sean-k-mooney | Habib-A: yes i know people have done it in the past im not sure if its documented | |
| 13:25:43 | sean-k-mooney | Habib-A: kolla support external dbs | |
| 13:25:44 | Habib-A | i understand the DB part but for the network node and cinder | |
| 13:25:59 | sean-k-mooney | well the network nodes dont store data locally | |
| 13:26:15 | Habib-A | ok that makes sense | |
| 13:26:22 | Habib-A | what about cinder | |
| 13:26:26 | sean-k-mooney | so really you just install more api/l3/dhcp/l2 agents on the cinder and contler node | |
| 13:26:34 | sean-k-mooney | cinder depneds on the backend | |
| 13:26:44 | Habib-A | lvm2 | |
| 13:26:45 | sean-k-mooney | are you using ceph? lvm? | |
| 13:26:52 | sean-k-mooney | ok so that is harder | |
| 13:26:56 | Habib-A | and its in a VM (vmware ) | |
| 13:27:00 | sean-k-mooney | you can make the api/db ha | |
| 13:27:11 | Habib-A | i get you | |
| 13:27:19 | sean-k-mooney | the lvm dirver itslef does not support ha | |
| 13:27:29 | Habib-A | got it | |
| 13:27:40 | Habib-A | thank you very much sean :D | |
| 13:27:43 | sean-k-mooney | as in you cant have 2 cinder volume agent managne the same set of lvm volumes | |
| 13:27:51 | sean-k-mooney | you can however have many seperate backend | |
| 13:28:12 | sean-k-mooney | Habib-A: the path forwad for cinder would be to deploy ceph or another ha backend | |
| 13:28:21 | sean-k-mooney | then do a volume migration form the lvm backend to the new one | |
| 13:29:24 | sean-k-mooney | if you were using a backend that supported ha volumes like ceph you would have jsut installed addtion cinder volume agents and pointed them all at the same ceph cluster with the same config | |