Earlier  
Posted Nick Remark
#openstack-nova - 2022-02-02
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
19:54:14 sean-k-mooney o/ all chat to ye tomrrow
19:54:20 artom It's a shot in the dark to serve as a data poin
19:54:21 artom t
21:19:49 admin1 hi .. is there a nova command to see all ongoing migrations ?
21:23:09 mloza hello, need help figure out what would cause nova to delete a port on an instance

Earlier   Later