| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-02-02 | |||
| 12:14:47 | ralonsoh | I'll push a patch today | |
| 12:14:53 | gibi | ralonsoh: this sounds incorrect that I can boot with a qos rule but the rule type list does not show it | |
| 12:14:59 | gibi | ralonsoh: thank you! | |
| 12:15:01 | ralonsoh | sean-k-mooney, that was supported since wallaby | |
| 12:15:05 | ralonsoh | and in D/S in OSP16 | |
| 12:15:32 | sean-k-mooney | oh ok | |
| 12:16:33 | sean-k-mooney | ralonsoh: this is not the first time this api design choice has come up | |
| 12:16:49 | ralonsoh | sean-k-mooney, yeah... I think the current implementation is wrong | |
| 12:16:58 | sean-k-mooney | well i ment in general | |
| 12:17:11 | sean-k-mooney | neutron also has the same problem with vlan transparncy | |
| 12:17:34 | sean-k-mooney | to work around that vlan transpace was set to yes for sriov | |
| 12:17:44 | sean-k-mooney | event though it really done not support it properly | |
| 12:18:04 | ralonsoh | the aim of the API is to return only what is supported by all drivers | |
| 12:18:06 | sean-k-mooney | i think in general neutron need to list the capyablity per ml2/driver | |
| 12:18:19 | ralonsoh | for example: https://review.opendev.org/q/3299cdffae5cd7196a1676da103da5e2e413ec21 | |
| 12:18:23 | sean-k-mooney | ralonsoh: ya i know but that has never felt useful to me | |
| 12:18:33 | ralonsoh | it was changed before and then reverted | |
| 12:18:57 | sean-k-mooney | the api shoudl idally list the qos polices per driver | |
| 12:18:59 | ralonsoh | sean-k-mooney, then what we can do is to create another API call | |
| 12:19:11 | ralonsoh | return all_supported_qos_types | |
| 12:19:15 | ralonsoh | or something similar | |
| 12:19:52 | sean-k-mooney | perhaps | |
| 12:20:10 | ralonsoh | I'll propose a new API | |
| 12:22:14 | sean-k-mooney | i still think having the new api return a dictonaly keyd by either the driver or vnic-type with the support qos polices as the values would be the way to organsie that api but just add a property to the exising one to list all is less work | |
| 12:23:00 | ralonsoh | I think we can do this with the current API, just adding a new parameter to the CLI call | |
| 12:23:04 | sean-k-mooney | the issue i have with all_supported_qos_types is that you cant tell if a port you create will work with any specific policy | |
| 12:23:30 | sean-k-mooney | ralonsoh: actully at the end of the day what we really need is schduler support | |
| 12:23:37 | ralonsoh | yes | |
| 12:24:06 | gibi | minimum pps / bw has scheduler support :) | |
| 12:24:12 | sean-k-mooney | neutron need to use traits to model which host support which polcies and nova need to shcdule the prot to such a host based on the requst | |
| 12:24:24 | sean-k-mooney | gibi: it does but im thinking for dscp ectra | |
| 12:24:35 | gibi | yeah for dhcp it is a different game | |
| 12:24:40 | sean-k-mooney | e.g. the non quntitive qos | |
| 12:24:50 | sean-k-mooney | its a fair point about min* | |
| 12:25:01 | sean-k-mooney | those are ahead of the game | |
| 12:25:28 | stephenfin | sean-k-mooney: Care to finally get these in? It's only been 16 months :) https://review.opendev.org/c/openstack/nova/+/705792/ https://review.opendev.org/c/openstack/nova/+/754448/ | |
| 12:25:29 | gibi | and supporting the non quantitative is problematic by the resourceless request group problem in placement | |
| 12:26:02 | sean-k-mooney | stephenfin: im looking at https://review.opendev.org/c/openstack/nova/+/814562 now but i can look at them after | |
| 12:26:16 | stephenfin | Okay, sweet. ty :) | |
| 12:26:45 | sean-k-mooney | stephenfin: o nnueton refactoring ya ill review those too | |
| 12:35:45 | sean-k-mooney | ah you have a follow up for the cells doc cool i was going to ask if you were doing a new reviesion | |
| 13:12:10 | gibi | ralonsoh: I'm not sure I understand the reason of the wontfix on https://bugs.launchpad.net/neutron/+bug/1959749 | |
| 13:16:06 | gibi | ralonsoh: you #1) point is what I would need to work. So that the rule type list returns all rule types not just rule types that are supported by every configured driver | |
| 13:32:09 | ralonsoh | gibi, sorry, I don't know why I set this flag | |
| 13:32:25 | ralonsoh | confirmed, this is the correct value | |
| 13:32:37 | gibi | ralonsoh: that is better, thanks :) | |
| 13:48:09 | admin1 | hi guys .. is there a way to "transfer ownership" of an instance from one project to another ? | |
| 14:04:57 | opendevreview | yuval proposed openstack/nova master: Lightbits LightOS driver https://review.opendev.org/c/openstack/nova/+/821606 | |
| 14:58:51 | opendevreview | Dmitrii Shcherbakov proposed openstack/nova master: Document remote-managed port usage considerations https://review.opendev.org/c/openstack/nova/+/827513 | |
| 16:45:59 | gibi | if somebody wants a change of (code) scenery then I can suggest looking at the placement code review series to support any-traits queries in microvarsion 1.39. The series starts here https://review.opendev.org/c/openstack/placement/+/825846/3 :) | |
| 17:01:15 | opendevreview | Merged openstack/nova master: docs: Add a new cells v2 document https://review.opendev.org/c/openstack/nova/+/814562 | |
| 17:15:10 | melwitt | gibi: I will look at some new code scenery :) | |
| 17:27:53 | dmitriis | gibi, sean-k-mooney: mostly been getting unrelated gate failures so I am waiting for some rechecks to complete. I made a functional change to the patch that introduces the remote_managed tag here https://review.opendev.org/c/openstack/nova/+/824834/8/nova/pci/devspec.py#322 to include a check for the presence of a serial number when a device is | |
| 17:27:53 | dmitriis | tagged as remote_managed which is something I overlooked in the previous iteration and updated testing to reflect that. | |
| 17:28:38 | dmitriis | I started working on the docs and started a doc review but most of the docs will be in Neutron under the OVN driver guide similar to how it's done today with OVS hardware offload. | |
| 17:42:44 | gibi | melwitt: thanks! :) | |
| 17:43:12 | gibi | dmitriis: I will read back tomorrow I have to go now | |
| 17:43:32 | dmitriis | gibi: np, thanks a lot for the help so far | |
| 18:13:35 | sean-k-mooney | dmitriis: ack | |
| 18:14:07 | sean-k-mooney | dmitriis: im looking at some downstream stuff currently but ill try to take a look proably tomorow at this point | |
| 18:14:48 | sean-k-mooney | dmitriis: most of the doc make sense for the neutorn guide but we shoudl detail how to use the remote managed flag ectra in nova | |
| 18:16:56 | dmitriis | sean-k-mooney: ack, ta. | |
| 18:16:57 | dmitriis | sean-k-mooney: I currently describe some of it in the latest doc change and reference the option docstring but I can expand the description in the docs themselves too. | |
| 18:18:36 | opendevreview | Ilya Popov proposed openstack/nova master: Fix to implement 'pack' or 'spread' VM's NUMA cells https://review.opendev.org/c/openstack/nova/+/805649 | |
| 18:34:13 | opendevreview | melanie witt proposed openstack/nova master: Raise InstanceNotFound on fkey constraint fail saving info cache https://review.opendev.org/c/openstack/nova/+/826942 | |
| 18:51:41 | sean-k-mooney | o/ are we tracking the failure of tempest.api.compute.servers.test_device_tagging.TaggedAttachmentsTest.test_tagged_attachment | |
| 18:51:49 | sean-k-mooney | as a potential gate issue anywhere | |
| 18:52:05 | sean-k-mooney | im seeing that fail more and more on reviews over the last 2 weeks | |
| 18:52:32 | sean-k-mooney | its like it knew lyarwood was starting on kubvirt this week :) | |
| 18:54:03 | sean-k-mooney | so this could be q35 related | |
| 18:54:11 | artom | Yeah, repeating what I said downstream... it's not even a Tempest race or whatever, it's the guest itself. Is this the q35 problem again? Surely we'd see other tests fail in that job, unless nova-next doesn't do any other device attachment tests, which would be... weird | |
| 18:54:12 | sean-k-mooney | but im not sure about that | |
| 18:54:30 | sean-k-mooney | it could be that the volume is not attched fully yet | |
| 18:54:48 | sean-k-mooney | i.e. the series from lee to wait fothe vm to be pingable might help | |
| 18:54:57 | sean-k-mooney | but in this case the test is sshing into the vm | |
| 18:55:04 | sean-k-mooney | to check the tag is there right | |
| 18:55:34 | sean-k-mooney | the failure message at the top level is Details: Timeout while verifying metadata on server. | |
| 18:55:55 | artom | No, there are definitely other tests that attach stuff that pass | |
| 18:56:29 | sean-k-mooney | so the test is doing Remote command: set -eu -o pipefail; PATH=$PATH:/sbin:/usr/sbin; curl http://169.254.169.254/openstack/latest/meta_data.json | |
| 18:56:29 | artom | Mind you, they may not be SSH'ing into the guest? | |
| 18:56:42 | sean-k-mooney | by sshing into the guest | |
| 18:56:54 | sean-k-mooney | and that ssh connection is well connecting | |
| 18:57:13 | artom | So it's curl that's timing out? | |
| 18:57:17 | sean-k-mooney | im looking at https://zuul.opendev.org/t/openstack/build/d836724c364843e98bf893ac71574828 | |
| 18:57:27 | sean-k-mooney | no i think the curl command is working | |
| 18:57:33 | sean-k-mooney | its doing it in a loop | |
| 18:57:49 | sean-k-mooney | but by the time the test complete the data is not in the metadata servie | |
| 18:58:00 | sean-k-mooney | but that could be related to the attach taking a long time | |
| 19:00:37 | artom | It's not 100% though, so whatever we try will have to be rechecked at least a few times | |
| 19:01:42 | sean-k-mooney | ya i dont know it just gotten flaky recently | |
| 19:01:52 | sean-k-mooney | not clear reason why | |
| 19:02:09 | sean-k-mooney | and as you say its no 100% so its hard to tell why | |
| 19:11:21 | artom | I wonder if we should wait for volume and interface attach before carrying on | |
| 19:11:37 | artom | Like, we're somehow "confusing" the guest by issuing two device attach commands in quick succession | |
| 19:11:46 | artom | I realize how non-engineery that sounds | |
| 19:22:32 | opendevreview | Artom Lifshitz proposed openstack/nova master: DNM: Testing change to test_tagged_attachment in tempest https://review.opendev.org/c/openstack/nova/+/827549 | |
| 19:22:38 | artom | ^^ we'll see | |
| 19:51:28 | sean-k-mooney | artom: we proably should although i think we have an instace level lock at the comptue manager so only one attachment can happen at a time | |
| 19:51:51 | sean-k-mooney | we do for 2 interfaces or volumes but not sure about one of each | |
| 19:52:33 | sean-k-mooney | so ya lets see if that helps | |