| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-03 | |||
| 17:47:24 | bauzas | well, I'm pretty sure ops size the DB write performance on the nova database | |
| 17:47:33 | sean-k-mooney | to remove the volumn attaments right? | |
| 17:47:54 | sean-k-mooney | and it should be calling neutron to unbind the neutron ports | |
| 17:48:06 | sean-k-mooney | so im wonderign wny cyborg is special in this case | |
| 17:48:26 | bauzas | actually, you're making a point | |
| 17:48:57 | bauzas | but that doesn't infirm my theory | |
| 17:49:16 | bauzas | which is that this periodic task can harm our dependent projects | |
| 17:49:31 | sean-k-mooney | well im not disagreeing that it could cause issue if you misconfigred things | |
| 17:49:37 | sean-k-mooney | yep | |
| 17:49:58 | sean-k-mooney | i think we just have differnet levels of concners as to the effect | |
| 17:50:10 | bauzas | anyway, I don't wanna hold this | |
| 17:50:34 | bauzas | but I was just taking my operator hat, being afraid of my internal APIs | |
| 17:50:51 | sean-k-mooney | moving the client out of the loop will at least stop the load on keystone | |
| 17:50:58 | sean-k-mooney | so that proably shoudl be done in anycase | |
| 17:51:05 | bauzas | and while I trust cinder and neutron in terms of sizing, I'd certainly take much attention to cyborg API if I know this | |
| 17:51:32 | sean-k-mooney | ya there is less op experince with cyborg for sure | |
| 17:51:51 | bauzas | anyway, this is nearly 7pm for me and I really worked late yesterday night, so I'll bail out | |
| 17:52:02 | sean-k-mooney | that said at least with osp donwstream we tend to use one db server for all the dbs | |
| 17:52:15 | sean-k-mooney | enjoy your evnening o/ | |
| 17:52:47 | bauzas | like, hello keystone | |
| 17:53:17 | bauzas | bear with me | |
| 17:53:32 | bauzas | and give me a token that you'll store for a long period of time | |
| 17:53:56 | bauzas | glance ? be quiet and just give me the images | |
| 17:54:21 | bauzas | but meh, I'm diverging | |
| 17:54:22 | bauzas | \o | |
| 17:55:13 | sean-k-mooney | im sure cern use different dbs and rabbitmq instance for different services but many smaller clouds wont | |
| 20:56:22 | openstackgerrit | Merged openstack/nova master: requirements.txt: Bump os-brick to 4.2.0 https://review.opendev.org/c/openstack/nova/+/778177 | |
| 21:01:22 | openstackgerrit | Merged openstack/nova master: Remove unused Instance method https://review.opendev.org/c/openstack/nova/+/757615 | |
| 21:38:14 | openstackgerrit | Merged openstack/nova master: hyper-v rbd volume support https://review.opendev.org/c/openstack/nova/+/763550 | |
| #openstack-nova - 2021-03-04 | |||
| 02:51:09 | openstackgerrit | YuehuiLei proposed openstack/nova-specs master: Add xena directory for specs https://review.opendev.org/c/openstack/nova-specs/+/778604 | |
| 03:23:19 | openstackgerrit | Brin Zhang proposed openstack/nova master: Add missed accel_uuids for _poll_shelved_instances https://review.opendev.org/c/openstack/nova/+/778440 | |
| 07:41:14 | openstackgerrit | Yongli He proposed openstack/nova master: Smartnic support - cyborg drive https://review.opendev.org/c/openstack/nova/+/771362 | |
| 07:41:15 | openstackgerrit | Yongli He proposed openstack/nova master: smartnic support https://review.opendev.org/c/openstack/nova/+/758944 | |
| 08:31:17 | yonglihe | gibi: hope you have some bandwidth.. | |
| 09:20:17 | bauzas | lyarwood: morning | |
| 09:20:48 | openstack | Launchpad bug 1820007 in os-brick "Failed to attach encrypted volumes after detach: volume device not found at /dev/disk/by-id" [Undecided,Fix released] - Assigned to Lee Yarwood (lyarwood) | |
| 09:21:27 | bauzas | I'll recheck my change, but given the bug was fixed, I wonder whether it was related | |
| 09:33:14 | lyarwood | morning | |
| 09:34:58 | gibi | morning folks | |
| 09:35:13 | gibi | stephenfin: do we need https://review.opendev.org/c/openstack/nova/+/765798 for the hypervisor api bp? | |
| 09:36:02 | stephenfin | I think it's a nice-to-have rather than a necessity. gmann did say yesterday that he was going to take over that patch though, | |
| 09:37:00 | openstackgerrit | Lee Yarwood proposed openstack/nova master: WIP: nova-next: Start testing the 'q35' machine type https://review.opendev.org/c/openstack/nova/+/708701 | |
| 09:37:20 | lyarwood | weird, just had `error: remote unpack failed: error Missing blob 08f698bbe36d414eca19d0760a5acc3a714c404e` errors trying to push that ^ | |
| 09:37:34 | lyarwood | appears the git gc actually did something for a change and it's fixed after a git fetch -va | |
| 09:37:48 | lyarwood | bauzas: looking at that issue now sorry | |
| 09:38:11 | bauzas | lyarwood: no worries at all, rechecked meanwhile | |
| 09:38:20 | bauzas | just an open question | |
| 09:38:37 | bauzas | and I thought you could be interested in since you worked on the fix | |
| 09:41:17 | lyarwood | bauzas: yeah this is slightly different | |
| 09:41:19 | lyarwood | 43684 Mar 03 20:53:14.002343 ubuntu-focal-limestone-regionone-0023285105 nova-compute[53948]: ERROR oslo_messaging.rpc.server libvirt.libvirtError: internal error: unable to execute QEMU command 'blockdev-add': Could not open '/dev/disk/by-id/scsi-360000000000000000e00000 000010001': Operation not permitted | |
| 09:41:30 | lyarwood | we find the device but can't attach it | |
| 09:42:39 | lyarwood | weird, we even encrypt it | |
| 09:42:58 | lyarwood | ah but through /dev/sda | |
| 09:43:03 | lyarwood | I hope that's the same device | |
| 09:43:28 | gibi | stephenfin: ack, then I will not push hard on that policy patch | |
| 09:46:27 | bauzas | lyarwood: that looks to me a race finding the device, right? | |
| 09:50:14 | lyarwood | bauzas: no we've found the device fine, /dev/disk/by-id/scsi-360000000000000000e00000000010001 is connected correctly and we even format/encrypt it with LUKSv1 | |
| 09:50:29 | lyarwood | bauzas: QEMU just isn't happy with the passphrase we've provided AFAICT | |
| 09:50:34 | bauzas | ah | |
| 09:50:46 | lyarwood | bauzas: the only odd thing is that we format/encrypt /dev/sda | |
| 09:51:37 | lyarwood | https://github.com/openstack/os-brick/blame/bd629a3a4105f7f3f9f35b71350ea3c66f3690e9/os_brick/encryptors/cryptsetup.py#L80-L81 and https://github.com/openstack/os-brick/blob/bd629a3a4105f7f3f9f35b71350ea3c66f3690e9/os_brick/encryptors/luks.py#L97 cause that | |
| 09:51:47 | lyarwood | but I've never seen that be a problem before, it should be the same underlying block device | |
| 09:52:35 | lyarwood | unless theres some weirdness in the block layers and /dev/disk/by-id/scsi-360000000000000000e00000000010001 still doesn't look like it's encrypted by the time QEMU attempts to attach it | |
| 09:56:29 | stephenfin | gibi: lyarwood: bauzas: Finishing off the microversion to allow e.g. 'openstack server create --hostname $HOSTNAME ...'. Do we want to allow users to update the hostname? | |
| 09:56:56 | bauzas | stephenfin: spec ? | |
| 09:57:00 | stephenfin | I said in the spec that we would, but all that will change is what's stored on the metadata service unless someone re-runs e.g. cloud-init | |
| 09:57:03 | stephenfin | https://specs.openstack.org/openstack/nova-specs/specs/wallaby/approved/configurable-instance-hostnames.html | |
| 09:57:24 | stephenfin | So I'm concerned it might be misleading | |
| 09:57:50 | bauzas | I missed that one or I'm old | |
| 09:58:04 | stephenfin | Well you are old... | |
| 09:58:13 | stephenfin | but I guess you just missed it :P | |
| 09:58:44 | bauzas | it's coming from the display name issue when users were dumb enough to think that ubuntu20.04 was a valid hostname ? | |
| 09:58:50 | stephenfin | yes | |
| 09:58:52 | bauzas | seriously | |
| 09:59:07 | stephenfin | well, sort of | |
| 09:59:26 | stephenfin | we said the idea of tying a display name and hostname together wasn't necessarily that clever | |
| 09:59:37 | bauzas | stephenfin: users can change their instance hostnames without asking nova, right? | |
| 09:59:59 | bauzas | it's just that nova metadata will give you one | |
| 10:00:03 | bauzas | but you can change it | |
| 10:00:19 | stephenfin | of course, but they'd have to disable cloud-init (or part thereof) | |
| 10:00:40 | bauzas | I'm pretty sure they don't need to do it | |
| 10:00:48 | bauzas | at least in 2013, this wasn't required | |
| 10:01:06 | bauzas | but now quantum, err neutron, does exist | |
| 10:02:56 | bauzas | but OK | |
| 10:03:26 | bauzas | stephenfin: let's assume the user wants to change their hostnames on the nova CLI, what's your concern ? | |
| 10:03:34 | stephenfin | I'm trying to find the relevant cloud-init docs. Best I've got is https://cloudinit.readthedocs.io/en/21.1/topics/instancedata.html but that's EC2-specific | |
| 10:03:52 | stephenfin | My concern is that AFAICT cloud-init only runs once when setting up the instance | |
| 10:04:26 | stephenfin | so providing a way to change the hostname in the metadata service could be misleading, since one would need a service to propagate that change to the instance and I don't know if such a service exists | |
| 10:04:44 | bauzas | stephenfin: https://cloudinit.readthedocs.io/en/latest/topics/modules.html#set-hostname | |
| 10:05:14 | bauzas | now I remember | |
| 10:05:30 | bauzas | man, I turned 40 but I forgot I reviewed this one | |
| 10:06:46 | bauzas | and now I see my vote on the change, I remember I approved it by fatigue | |
| 10:08:54 | lyarwood | bauzas: found it, there's another request to attach a volume that also ends up with that WWN somehow | |
| 10:09:14 | bauzas | lyarwood: hah | |
| 10:09:23 | bauzas | good catch, hence the conflict | |
| 10:10:09 | bauzas | stephenfin: so, IIRC, you can turn off the hostname management with cloud-init and set it thru any management tool like ansible or puppet | |
| 10:10:39 | lyarwood | yeah I'm not sure if this is an os-brick or cinder bug tbh | |
| 10:11:44 | bauzas | stephenfin: so, preserve_hostname be True in cloud.cfg and then you can play with /etc/hosts like you want | |
| 10:11:57 | gibi | stephenfin: on use case I can imagine for the changing of the hostname is that the instance is do managed by ansible, and the user changed the hostname with that and want to keep the nova view in sync with what is in the instance | |
| 10:12:19 | bauzas | gibi: yeah, honestly I feel bad with my review of the spec | |