| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-01-11 | |||
| 17:19:46 | opendevreview | Merged openstack/nova master: Make the CellDatabases fixture work with fasteners >= 0.15 https://review.opendev.org/c/openstack/nova/+/813114 | |
| 17:30:05 | spatel | sean-k-mooney Hi and happy new year | |
| 17:30:29 | spatel | I am getting stranger error in nova-scheduler logs - numatopologyfilter returned 0 hosts | |
| 17:31:13 | spatel | Question can i check resource provider inventory of host to see why my numa not getting filter? | |
| 17:33:02 | spatel | all i can see this but how do i check my NUMA related resources in placement? - https://paste.opendev.org/show/812039/ | |
| 17:34:08 | opendevreview | Merged openstack/nova master: Fill the exception msg https://review.opendev.org/c/openstack/nova/+/821385 | |
| 17:37:26 | bauzas | spatel: there are no NUMA resources in placement | |
| 17:37:42 | spatel | hmm | |
| 17:37:48 | bauzas | if the filter returns 0 hosts, then look at it | |
| 17:37:56 | bauzas | add a DEBUG if you can | |
| 17:38:06 | bauzas | for the nova-scheduler service log level | |
| 17:38:49 | spatel | ok so there is no way to see my host NUMA inventory in DB. anyway if that is the case then only option i have which is debug | |
| 17:39:09 | spatel | I was reading this - https://specs.openstack.org/openstack/nova-specs/specs/ussuri/approved/numa-topology-with-rps.html | |
| 17:40:14 | spatel | https://specs.openstack.org/openstack/nova-specs/specs/ussuri/approved/numa-topology-with-rps.html#optionally-configured-numa-resources | |
| 17:40:46 | bauzas | spatel: yeah but as you can see, the spec was only approved, not implemented | |
| 17:41:14 | spatel | +1 copy that | |
| 17:41:42 | spatel | Thank you so much! let me play with debug and see | |
| 17:45:15 | bauzas | spatel: ack, I'll leave by now | |
| 18:04:36 | ade_lee | gmann, sorry - just to confirm -- as we're not going to add ecdsa key generation to nova api, we can leave the key generation code in create_keypair() in https://review.opendev.org/c/openstack/tempest/+/807465/23/tempest/lib/services/compute/keypairs_client.py#84 for ecdsa , right? | |
| 18:07:04 | ade_lee | gmann, so that basically the only changes needed in that patch is adding more detail to the release note | |
| 18:13:36 | gmann | ade_lee: for nova api, yes we do not need to add and we will remove the existing ssh key generation part too with microversion. | |
| 18:15:24 | gmann | ade_lee: for tempest, let me re-review it now. I think it make sense to me now to add in create_keypair() so that complete set of test can be tested with configured key. I will leave comment in review today | |
| 18:15:50 | ade_lee | gmann, great thanks | |
| 18:16:24 | gmann | ade_lee: I will be able to review in my evening, need to prepare lunch now :) | |
| 18:17:03 | ade_lee | gmann, ok - enjoy -- I have to do the same .. | |
| 18:27:09 | yuval | Hey regarding running third party ci on the nova repo | |
| 18:27:16 | yuval | which tempest test should I run? | |
| 18:30:43 | gmann | yuval: you can run compute integrated test which is what we run in upstream ci (or less depends on what you want to test). this file is used to prepare the integrated compute tests https://github.com/openstack/tempest/blob/master/tools/tempest-integrated-gate-compute-exclude-list.txt | |
| 18:31:31 | gmann | this file exclude all other tests and in tempest run you can pass this file with --exclude-list , example: https://github.com/openstack/tempest/blob/master/tox.ini#L161 | |
| 18:34:05 | yuval | I see thank you | |
| 18:47:40 | opendevreview | Jonathan Race proposed openstack/nova-specs master: Adds Pick guest CPU architecture based on host arch in libvirt driver support https://review.opendev.org/c/openstack/nova-specs/+/824044 | |
| 19:04:05 | chateaulav | sean-k-mooney: I think that covers what was identified. | |
| 19:11:19 | opendevreview | Jonathan Race proposed openstack/os-traits master: Adds Pick guest CPU architecture based on host arch in libvirt driver support https://review.opendev.org/c/openstack/os-traits/+/824050 | |
| 19:15:23 | opendevreview | Jonathan Race proposed openstack/nova master: Adds Pick guest CPU architecture based on host arch in libvirt driver support https://review.opendev.org/c/openstack/nova/+/822053 | |
| 19:16:17 | opendevreview | Jonathan Race proposed openstack/os-traits master: Adds Pick guest CPU architecture based on host arch in libvirt driver support https://review.opendev.org/c/openstack/os-traits/+/824050 | |
| 21:02:39 | opendevreview | Merged openstack/placement master: Spec: support any trait in allocation candidates https://review.opendev.org/c/openstack/placement/+/649992 | |
| 21:05:37 | opendevreview | Merged openstack/placement master: Spec: support mixing required traits with any traits https://review.opendev.org/c/openstack/placement/+/649368 | |
| 22:47:15 | opendevreview | yuval proposed openstack/nova master: NO MERGE - activate lightbits third party ci on nova repo https://review.opendev.org/c/openstack/nova/+/824255 | |
| 23:02:26 | yuval | if someone is still awake - I have enabled the third party ci | |
| #openstack-nova - 2022-01-12 | |||
| 00:36:11 | gmann | yuval: cool. | |
| 04:16:05 | opendevreview | melanie witt proposed openstack/nova master: Add wrapper for oslo.concurrency lockutils.ReaderWriterLock() https://review.opendev.org/c/openstack/nova/+/824280 | |
| 08:47:43 | EugenMayer | How do you all handle nat reflection issues. so a vm/server connecting to an other service via the public IP, which happens to be hosted in the same openstack and is also the IP of the gateway for the commucation. So usualy nat reflection - any hints? | |
| 08:52:22 | opendevreview | yuval proposed openstack/nova-specs master: lightos volume driver spec https://review.opendev.org/c/openstack/nova-specs/+/824191 | |
| 08:53:13 | yuval | dear core reviewer - I have update the nova spec for lightos driver, can you please review? | |
| 08:53:30 | gibi | yuval: hi! I will take a look | |
| 08:54:38 | opendevreview | Lior Friedman proposed openstack/nova master: support use_multipath for nvme driver https://review.opendev.org/c/openstack/nova/+/824353 | |
| 09:02:56 | opendevreview | Ghanshyam proposed openstack/nova master: Server actions APIs scoped to project scope https://review.opendev.org/c/openstack/nova/+/824358 | |
| 09:04:30 | opendevreview | Lior Friedman proposed openstack/nova master: support use_multipath for nvme driver https://review.opendev.org/c/openstack/nova/+/823941 | |
| 09:51:45 | EugenMayer | considering this older commit to fix nat-reflextion issues https://github.com/openstack/nova/commit/b61e1ea12cd41ea507b1f6496ec1413c93bd679b .. is this even working/used with OVN networking? | |
| 10:02:42 | sean-k-mooney1 | EugenMayer: nat reflection is not something done by nova | |
| 10:03:09 | sean-k-mooney1 | EugenMayer: the neutron routers i think will do that | |
| 10:03:11 | EugenMayer | sean-k-mooney1 i assume it is a neutron topic, but that commit is somehow in the nova namespace | |
| 10:03:34 | sean-k-mooney1 | EugenMayer: nova used to have nova networks to use instead of neutron | |
| 10:03:37 | EugenMayer | sean-k-mooney1 asking there too - i cannot pin down the right project right now. Thank you for the hint | |
| 10:03:57 | EugenMayer | ah - i see. so it was 'nova back then'. Sorry i was not here back then | |
| 10:04:13 | EugenMayer | understood. The nova here is the 'old network nova nowdays replaced by neutron' | |
| 10:04:34 | sean-k-mooney1 | it was nova when nova did networking | |
| 10:04:39 | EugenMayer | This also means that particular patch has no affect/sense today. Could be entirely oncovereed | |
| 10:04:45 | sean-k-mooney1 | but today its in neutron | |
| 10:05:02 | EugenMayer | i see. As so often, thank you for clearing the fog out for me! | |
| 10:05:17 | sean-k-mooney1 | EugenMayer: i think that code has been entirly deleted a release or two ago | |
| 10:05:54 | sean-k-mooney1 | https://github.com/openstack/nova/tree/master/nova/network | |
| 10:06:10 | EugenMayer | I see. Do you know of any position right now if people basically are at 'use split DNS or deal with the consequences?' | |
| 10:07:12 | sean-k-mooney1 | well its kind of an odd issue | |
| 10:07:26 | sean-k-mooney1 | in that you seam to be tryign to use the same ip for two things | |
| 10:07:39 | sean-k-mooney1 | using it as the default gateway and as a vm | |
| 10:09:01 | sean-k-mooney1 | like you would normally reserve the default gateway ip so it could not be used for floating ips | |
| 10:38:46 | opendevreview | Merged openstack/nova master: Enable min pps tempest testing in nova-next https://review.opendev.org/c/openstack/nova/+/811748 | |
| 11:26:42 | opendevreview | Lee Yarwood proposed openstack/nova master: WIP manage: Add image_property commands https://review.opendev.org/c/openstack/nova/+/824392 | |
| 11:26:42 | opendevreview | Lee Yarwood proposed openstack/nova master: WIP libvirt: Register defaults for undefined hw image properties https://review.opendev.org/c/openstack/nova/+/800708 | |
| 12:24:58 | opendevreview | yuval proposed openstack/nova-specs master: lightos volume driver spec https://review.opendev.org/c/openstack/nova-specs/+/824191 | |
| 12:58:33 | sean-k-mooney | gibi: bauzas im ok with the latest version of ^ by the way. given the scope fo the nova change is small i think this is more then enough detail for now | |
| 12:58:57 | sean-k-mooney | more detail can be included in the documentation and or cidner driver | |
| 13:00:39 | gibi | sean-k-mooney: ack, I will check back to that today | |
| 13:02:37 | sean-k-mooney | gibi while i have you regarding teh ttl for healthcheck | |
| 13:02:50 | gibi | yes | |
| 13:03:10 | sean-k-mooney | so you think i shoudl keep the ttl, remove the stale_multipleer and intoduce a new state unkonwn | |
| 13:03:28 | sean-k-mooney | and if the ttl is expired for a reading report it as unknown or pass? | |
| 13:03:52 | sean-k-mooney | or perhaps warn? | |
| 13:03:53 | gibi | keep the ttl, remove the stale_multiplier, do not introduce unknow state | |
| 13:04:00 | sean-k-mooney | ok | |
| 13:04:02 | gibi | move from fail -> pass if ttl expires | |
| 13:04:16 | gibi | basicaly if it is unknown the report pass | |
| 13:04:22 | gibi | that will attract trafic | |
| 13:04:38 | gibi | so if it is still faulty we will detect it | |
| 13:04:56 | sean-k-mooney | ok that works for nova-api certenly | |
| 13:05:20 | sean-k-mooney | not sure about other services | |
| 13:06:00 | sean-k-mooney | i think it shoudl be workable | |
| 13:06:14 | sean-k-mooney | ill incoperate that into the next version | |
| 13:06:40 | sean-k-mooney | i kind of feel like if all are expired the state shoudl be warn but we can debate that in the implemetion | |
| 13:06:49 | sean-k-mooney | unless you feel that shoudl be stated in the spec | |
| 13:07:24 | sean-k-mooney | for now i think im going to follow dansmith's advise of sepcify that warn is a viald value but in initally do not use it in the implemenation | |
| 13:07:46 | gibi | you view also make sense, we don't know the state so we warn that it might be faulty. | |
| 13:08:03 | sean-k-mooney | i.e. only start usign warn after we have the basic pass fail stuff workign | |
| 13:08:42 | sean-k-mooney | gibi ya so the IETF draft recommend treating warn as still "passing" but that somethign might be wrong | |
| 13:09:10 | gibi | I'm OK to define warn, but not use it in the first implementation | |
| 13:09:40 | gibi | maybe we can gather some feedback from the field what operators want to see when the service don't know the state of it dpes | |
| 13:09:43 | gibi | *deps | |
| 13:10:15 | sean-k-mooney | ya that sounds resonabl that we shoudl ask there input | |
| 13:10:43 | gibi | so I won't block on having warn | |