| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-04-12 | |||
| 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 | Hello | |
| 13:14:07 | Habib-A | i have a running production environment of Openstack with the following architecture | |
| 13:14:08 | Habib-A | it was installed manually | |
| 13:14:08 | Habib-A | 1 controller node | |
| 13:14:09 | Habib-A | 1 network node | |
| 13:14:09 | Habib-A | 3 physical compute nodes | |
| 13:14:10 | Habib-A | 1 cinder node | |
| 13:14:10 | Habib-A | is it possible to add HA to environment ? is it easy ? will cause data loss ? | |
| 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 | can i pm for more details > | |
| 13:21:39 | Habib-A | ? | |
| 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 | |
| 13:30:20 | Habib-A | hmmm makes sense | |
| 13:34:14 | sean-k-mooney | Habib-A: the simplest way to move an exsiting deployment to kolla ansibel is to use external dbs by the way | |
| 13:34:16 | sean-k-mooney | https://github.com/openstack/kolla-ansible/blob/master/doc/source/reference/databases/external-mariadb-guide.rst | |
| 13:35:29 | 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 | |
| 14:45:01 | dansmith | sean-k-mooney: gibi: stephenfin: Can you think of any reason this is still defaulted to false? https://github.com/openstack/nova/blob/master/nova/conf/scheduler.py#L152 | |
| 14:45:18 | sean-k-mooney | i think i have a patch to change that | |
| 14:45:26 | sean-k-mooney | i was looking at removign the filter | |
| 14:45:28 | dansmith | IIRC we introduced it as false because we had to wait a cycle for mirroring of the aggregates, but at this point I would think we'd want that on | |
| 14:45:50 | dansmith | sean-k-mooney: right okay, I was surprised to find it still =False and thought the filter would have been deprecated by now | |
| 14:45:51 | dansmith | owalsh: ^ | |
| 14:46:25 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/745605 | |
| 14:46:58 | sean-k-mooney | i need to repopose the blueprint but i can do that | |
| 14:48:24 | dansmith | cool | |
| 16:21:43 | openstackgerrit | Merged openstack/python-novaclient master: Add unit tests for client logger https://review.opendev.org/c/openstack/python-novaclient/+/785741 | |
| 16:39:02 | 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 | |
| 16:50:16 | elod | lyarwood: out of curiosity, do you want this patch because of the fix of bug #1879878 or because other patch? >>> https://review.opendev.org/c/openstack/nova/+/751364/5 | |
| 16:50:19 | openstack | bug 1879878 in OpenStack Compute (nova) train "VM become Error after confirming resize with Error info CPUUnpinningInvalid on source node " [Undecided,In progress] https://launchpad.net/bugs/1879878 - Assigned to Stephen Finucane (stephenfinucane) | |