| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-02-02 | |||
| 12:12:19 | opendevreview | Dmitrii Shcherbakov proposed openstack/nova master: [yoga] Add support for VNIC_TYPE_SMARTNIC https://review.opendev.org/c/openstack/nova/+/824835 | |
| 12:12:19 | opendevreview | Dmitrii Shcherbakov proposed openstack/nova master: Bump os-traits to 2.7.0 https://review.opendev.org/c/openstack/nova/+/826675 | |
| 12:12:20 | opendevreview | Dmitrii Shcherbakov proposed openstack/nova master: Filter computes without remote-managed ports early https://review.opendev.org/c/openstack/nova/+/812111 | |
| 12:12:27 | gibi | ovs support the min packet rate rule | |
| 12:12:38 | ralonsoh | gibi, yes, right, as I weas guessing | |
| 12:12:52 | ralonsoh | the problem is how we build the rule type set, as I commented in the bug | |
| 12:13:04 | gibi | looking... | |
| 12:13:13 | ralonsoh | we return the intersection of all mech driver supported types | |
| 12:13:18 | ralonsoh | instead of returning the union | |
| 12:13:30 | sean-k-mooney | gibi: ovn does not support qos fully yes i think | |
| 12:13:42 | gibi | sean-k-mooney: yes, I uses ovs :) | |
| 12:13:49 | sean-k-mooney | so if you are using the new default it might not work unless you reverted to ml2/ovs | |
| 12:13:51 | sean-k-mooney | ok | |
| 12:13:57 | gibi | sean-k-mooney: I reverted, yes :) | |
| 12:14:08 | ralonsoh | sean-k-mooney, we do support qos in OVN | |
| 12:14:10 | ralonsoh | fully | |
| 12:14:12 | gibi | ralonsoh: ohh so because I have sriov I cannot see the min pps | |
| 12:14:18 | ralonsoh | gibi, right | |
| 12:14:23 | gibi | ralonsoh: let me check that in another devstack that only hase ovs but not sriov | |
| 12:14:27 | ralonsoh | I think this should be reconsidered in the API | |
| 12:14:32 | sean-k-mooney | ralonsoh: that new this cycle right | |
| 12:14:33 | gibi | ralonsoh: I agree | |
| 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 | tagged as remote_managed which is something I overlooked in the previous iteration and updated testing to reflect that. | |
| 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: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 | |