| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-11-02 | |||
| 16:54:02 | EugenMayer | doesnt host-passthrough also harm the security / encapsulation? | |
| 16:54:02 | sean-k-mooney[m] | you could group them in an az | |
| 16:54:30 | EugenMayer | yes, az planned for the big ones, the smaller ones are internal CI servers only (azure agents or concourse CI workers) | |
| 16:56:33 | sean-k-mooney[m] | no it just allows the vm to use all the cpu features | |
| 16:56:56 | sean-k-mooney[m] | host-model still allows the vm to know what model of cpu is used | |
| 16:57:08 | EugenMayer | hmm, all VMs are our VMs, no customers or such. so i know what runs on each of them | |
| 16:57:10 | sean-k-mooney[m] | so form a security point of view more or less the same | |
| 16:57:50 | EugenMayer | i guess passthrough and hosting freebsd could be an issue. What about running windows? | |
| 16:59:13 | EugenMayer | Thank you so much! | |
| 17:00:11 | EugenMayer | the only thing i disklike is that i would need to fix every compute and i'am not sure this configuration file is controlled by kolla, but they have overrides and in the end, i have chef, so this will do it in any case | |
| 17:01:31 | sean-k-mooney[m] | it is | |
| 17:02:11 | sean-k-mooney[m] | you can drop an override in /etc/kolla/config/nova.conf or in /etc/kolla/nova/nova-compute.conf i belvie | |
| 17:03:39 | sean-k-mooney[m] | https://docs.openstack.org/kolla-ansible/latest/admin/deployment-philosophy.html#kolla-s-solution-to-customization | |
| 17:03:53 | sean-k-mooney[m] | its basically the example they use | |
| 17:04:37 | sean-k-mooney[m] | its one of the reasons i like kolla | |
| 17:04:44 | sean-k-mooney[m] | it makes this type of config simple | |
| 17:04:48 | yuriys | there are way too many reasons to like kolla | |
| 17:24:26 | EugenMayer | sean-k-mooney[m] thanks. Did that with globa_pysical_mtu already | |
| 17:24:38 | EugenMayer | yuriys there also some to not do so. As with everything | |
| 17:33:42 | EugenMayer | sean-k-mooney[m] your right, nova.conf would work https://gist.github.com/EugenMayer/d74ffdc0b15db9c9c1af344bd27accd1 | |
| 17:49:45 | Zer0Byte | hey @lyarwood are you there? | |
| 17:52:14 | lyarwood | \o evening, yeah | |
| 17:52:20 | Zer0Byte | hey | |
| 17:52:43 | Zer0Byte | https://bugs.launchpad.net/bugs/1949224 | |
| 17:52:47 | Zer0Byte | is regarding about this bug | |
| 17:53:17 | lyarwood | Yeah apologies I just saw your update | |
| 17:53:28 | lyarwood | and I missed this QoS spec on the cinder side was per GB | |
| 17:53:47 | Zer0Byte | what i mean is performing the resize only should update the iops on the kvm configuration isn't it? | |
| 17:53:49 | lyarwood | I guess this is valid in that case but I'm not sure how we can fix this between Nova and Cinder | |
| 17:54:35 | lyarwood | if it's a size related QoS spec then yeah I guess it should | |
| 17:54:41 | lyarwood | tbh I didn't even know these existed | |
| 17:54:59 | Zer0Byte | yeah im using on my backend storage and work well | |
| 17:55:13 | Zer0Byte | the problem is with nfs this is why in moving to the frontend | |
| 17:56:23 | Zer0Byte | and if i create a new instance with the same volume resized take the new iops specs | |
| 17:56:29 | lyarwood | https://github.com/openstack/nova/blob/82be4652e2c840bd69ec354fd734a2d3f83f395b/nova/virt/libvirt/volume/volume.py#L63-L77 is where Nova is told about the cinder side QoS FWIW | |
| 17:57:53 | Zer0Byte | but this is only during volume attach ? | |
| 17:58:20 | lyarwood | Yeah there's a missing piece during a resize | |
| 17:58:36 | lyarwood | A workaround would be shelve and unshelve the instance | |
| 17:58:46 | Zer0Byte | let me try it | |
| 17:58:48 | lyarwood | That should regenerate the connection_info in cinder and have that passed to Nova | |
| 18:04:57 | Zer0Byte | you are right @lyarwood works if i perform shelve and unshelve | |
| 18:05:19 | Zer0Byte | quesiton but shelveand unshelve change mac address or any machine configuration? | |
| 18:05:59 | Zer0Byte | like uuid or serial | |
| 18:06:22 | lyarwood | Overall things should remain the same but I'm not entirely sure if we persist the MAC addresses, sean-k-mooney ^ any idea? | |
| 18:07:05 | Zer0Byte | yeah is running cloud init again | |
| 18:07:09 | Zer0Byte | changing the ssh key | |
| 18:08:48 | lyarwood | cloud-init shouldn't regenerate ssh keys if they already exist right? | |
| 18:09:05 | Zer0Byte | mhmm if the machine id change | |
| 18:09:10 | Zer0Byte | trigger execute cloud init agai | |
| 18:09:11 | Zer0Byte | n | |
| 18:09:38 | Zer0Byte | and cloudinit perform ssh-keygen | |
| 18:10:56 | sean-k-mooney[m] | lyarwood: the mac adress comes from the neutron port so it wont change | |
| 18:11:06 | sean-k-mooney[m] | the machine id i guess you mean the one shown in dmidecoe | |
| 18:11:22 | sean-k-mooney[m] | i think that depends on your config but i think its the vms uuid by default | |
| 18:11:51 | sean-k-mooney[m] | https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.sysinfo_serial | |
| 18:14:00 | sean-k-mooney[m] | Zer0Byte: so it would only change if you had set the sysinfo_serial to OS which uses the host /etc/machine-id file , hardware which uses the host uuid form libvirt or auto whcih choses between those | |
| 18:14:50 | sean-k-mooney[m] | Zer0Byte: so with our default config of unique unshleving should not change the guest serial and cloud-init should not run | |
| 18:15:23 | sean-k-mooney[m] | the mac adress should not change either unless you changed it manually in neutron while i was sheleved | |
| 18:17:11 | lyarwood | anyway there's some additional tooling in Xena to refresh connection_info for shutdown instances without the need to shelve and unshelve etc | |
| 18:17:32 | lyarwood | https://docs.openstack.org/nova/latest/cli/nova-manage.html#volume-attachment-commands | |
| 18:17:59 | lyarwood | that's another way to workaround it while we try to work something out in-tree | |
| 18:18:34 | lyarwood | tbh I can't think of a way with the current cinder APIs | |
| 18:19:13 | Zer0Byte | i got to go thanks anyway i will check the option of @sean-k-mooney[m] | |
| 18:20:26 | sean-k-mooney[m] | no worries im offically on pto until tomorrow anyway so not really here today just saw you question while i was checking over my car insurance | |
| 19:01:23 | EugenMayer | Anybody in here uses freezer (successfully?) | |
| 19:16:00 | dansmith | bauzas: when you return: https://blueprints.launchpad.net/nova/+spec/nova-change-default-overcommit-values | |
| 20:10:42 | hyang[m] | Can anyone help to take a look this patch https://review.opendev.org/c/openstack/nova/+/811521 thanks in advance! | |
| 22:31:55 | opendevreview | Merged openstack/nova stable/stein: [stable-only] Pin virtualenv and setuptools https://review.opendev.org/c/openstack/nova/+/813451 | |
| #openstack-nova - 2021-11-04 | |||
| 00:47:12 | opendevreview | Ghanshyam proposed openstack/nova stable/train: DNM: test tempest train-last tag https://review.opendev.org/c/openstack/nova/+/816598 | |
| 08:01:33 | gibi | good morning | |
| 08:03:10 | opendevreview | Balazs Gibizer proposed openstack/nova stable/victoria: Parse alias from domain hostdev https://review.opendev.org/c/openstack/nova/+/816486 | |
| 08:07:39 | opendevreview | Balazs Gibizer proposed openstack/nova stable/xena: Prevent leaked eventlets to send notifications https://review.opendev.org/c/openstack/nova/+/816487 | |
| 08:08:47 | opendevreview | Balazs Gibizer proposed openstack/nova stable/xena: Avoid unbound instance_uuid var during delete https://review.opendev.org/c/openstack/nova/+/816488 | |
| 08:09:33 | gibi | bauzas: the reno for the pps work has landed so you can marke the | |
| 08:09:39 | gibi | https://blueprints.launchpad.net/nova/+spec/qos-minimum-guaranteed-packet-rate | |
| 08:09:43 | gibi | bp as implemented | |
| 08:09:46 | gibi | \o/ | |
| 08:11:02 | opendevreview | Balazs Gibizer proposed openstack/nova master: Enable min pps tempest testing in nova-next https://review.opendev.org/c/openstack/nova/+/811748 | |
| 08:15:45 | lyarwood | gibi++ | |
| 08:16:03 | gibi | lyarwood: thanks for the reviews yestarday | |
| 08:16:15 | lyarwood | np, still catching up | |
| 08:20:46 | gibi | I hope you enjoyed the explanation of the fix for https://launchpad.net/bugs/1946339 . It was a real adventure for me in eventlet/greenlet land. | |
| 08:21:53 | jpodivin | Hi everyone. Has anyone ever encountered: "The placement service for 192.168.24.100:regionOne exists but does not have any supported versions." ? | |
| 08:22:27 | jpodivin | It's hitting master in rdo, but wallaby somehow avoids it. | |
| 08:26:08 | gibi | jpodivin: hi, could you try to simply send a GET request to the root of you placement service? | |
| 08:26:47 | gibi | you should see something like https://paste.opendev.org/show/810375/ | |
| 08:27:00 | jpodivin | gibi: hm, sadly it's a proposed CI job, so the nodes are already down. | |
| 08:27:07 | jpodivin | althought I do have the logs stored | |
| 08:27:25 | gibi | then it would be good to check the placement service logs | |
| 08:28:08 | jpodivin | gibi: anything specific I should look for? | |
| 08:28:28 | gibi | jpodivin: do you see requests resulting in 404 there? | |
| 08:28:38 | EugenMayer | when running nova backup on an image, i see pending operations in the UI. Is there any way to show this tasks and their detailed operations on the cli? glance taks-list and glance image-tasks do not show any pending tasks | |
| 08:29:13 | gibi | we had an issue with apache config not long ago resulted in wrong proxy config for placement https://review.opendev.org/c/openstack/devstack/+/811389 | |
| 08:29:31 | jpodivin | gibi: no, it looks fairly clean, couple of warnings but those seem related to deprecation. https://logserver.rdoproject.org/99/36499/6/check/periodic-tripleo-ci-centos-8-containers-multinode-compute-master-validation/91262ed/logs/subnode-1/var/log/containers/placement/placement.log.txt.gz | |
| 08:31:31 | jpodivin | gibi: found another log, that might be what you meant. Lists a bunch of requests but 404 https://logserver.rdoproject.org/99/36499/6/check/periodic-tripleo-ci-centos-8-containers-multinode-compute-master-validation/91262ed/logs/subnode-1/var/log/containers/httpd/placement/placement_wsgi_access.log.txt.gz | |
| 08:32:33 | jpodivin | Interesting thing is: it starts *after* the error occurs, not before. | |
| 08:32:40 | gibi | yeah, these logs seems to indicate your placement service works correctly and some clients (probably nova) was able to communicate with it | |
| 08:33:23 | gibi | if the error happens after the logs ends then it can be that your placement service was simply stopped / crashed | |
| 08:34:10 | jpodivin | gibi: looking at the time stamps, it looks like the error occurs a approximately one minute before the placement requests log starts . | |
| 08:34:50 | jpodivin | gibi: scrap that. It's actually about 3 seconds before | |