| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-04-12 | |||
| 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 | |
| 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) | |
| 16:50:48 | elod | (and sorry for pinging you only now :X) | |
| 16:51:52 | lyarwood | elod: I *think* we are carrying this downstream so both bug #1879878 and making any future backports easier upstream in stable/train | |
| 16:51:54 | 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) | |
| 16:55:04 | elod | lyarwood: I see. As I was not fond of backporting that amount of test refactors... I waited to approve these test refactors until the bugfix part is reviewed by more eyes, to reduce the risk of introducing regressions | |
| 16:58:00 | lyarwood | elod: I understand but we are actually reducing the amount of code churn in backports by pulling back something like this | |
| 16:58:34 | elod | yes, for train, but for stein, we have to do the churn anyway o:) | |
| 16:58:46 | elod | but I understand that you only support train | |
| 16:59:02 | lyarwood | well we support Queens still but only really target Train at the moment | |
| 16:59:32 | lyarwood | but yeah eventually we will have to avoid the backport and just do the hard work but I'd prefer to defer that as long as possible | |
| 16:59:45 | lyarwood | we already suffer on stable/train without _create_server etc in the func tests | |
| 17:00:01 | lyarwood | but anyway, I don't see the harm when it's this self contained tbh | |
| 17:00:20 | lyarwood | let me hit the tip of the series | |
| 17:00:27 | lyarwood | and we can go from there | |
| 17:01:09 | elod | so as a standalone patch I wouldn't really merge it. but I understand the need... :S | |
| 17:02:17 | elod | also train-em transition is closer and closer. if it's not a risk, then it's okay to be part of the last release, otherwise I would consider waiting until the transition is done | |
| 18:01:18 | sean-k-mooney | elod: so add them after its EM or just not at all | |
| 18:01:53 | sean-k-mooney | elod: context is we need to support train for 3 more years so it would be nice to have them as we backport regression tests | |
| 18:02:01 | sean-k-mooney | * downstream | |
| 18:03:52 | openstackgerrit | Rodrigo Barbieri proposed openstack/nova master: Error anti-affinity violation on migrations https://review.opendev.org/c/openstack/nova/+/784166 | |
| 18:14:08 | elod | sean-k-mooney: yes, I understand that and accept the reason. I just wanted to avoid regression (especially now when train will trainsition to extended maintenance). that's why I wanted more eyes on the bugfix part. | |
| 18:15:12 | sean-k-mooney | sure i was just asking if you were ok with it going in after it was EM or if you wanted to not backport the _create_server and start_compute functions | |
| 18:18:22 | elod | well, as I said, I'm not fond of backporting such test refactors, but if stable cores are fine with it then we can merge it | |