| *** amoralej|off is now known as amoralej | 07:02 | |
| opendevreview | Attila Fazekas proposed openstack/nova master: Note the deleyad address view https://review.opendev.org/c/openstack/nova/+/827856 | 07:20 |
|---|---|---|
| *** hemna3 is now known as hemna | 07:37 | |
| yuval | Hey is there any special keyword I can reply to my patch to make zuul re-test my patch? | 08:34 |
| gibi | yuval: say: recheck <reason, e.g. the bug number your patch hit> | 08:36 |
| yuval | gibi: in this chat or on the gerrit gui? | 08:42 |
| gibi | yuval: in gerrit as a reply | 08:42 |
| yuval | thanks | 08:42 |
| opendevreview | Merged openstack/nova master: docs: Follow-ups for cells v2, architecture docs https://review.opendev.org/c/openstack/nova/+/827336 | 10:27 |
| *** ralonsoh_ is now known as ralonsoh | 10:51 | |
| opendevreview | Tobias Urdin proposed openstack/nova master: Update announce self workaround opt description https://review.opendev.org/c/openstack/nova/+/826829 | 11:25 |
| gibi | sean-k-mooney: hi! I'm +2 on the off-path networking series now | 11:34 |
| sean-k-mooney | ack that is nice to hear | 11:35 |
| gibi | sean-k-mooney: also looked at your healthcheck wip patch and left some notes | 11:39 |
| sean-k-mooney | thanks i need to spend more time on that in general but once i have the basic infra working adding the checks should be fairly quick | 11:51 |
| gibi | yepp | 12:00 |
| sean-k-mooney | im currenly thinking about what to keep and what to factor out into the resoucetracker class or whatever i end up calling it | 12:03 |
| sean-k-mooney | but looking a the current manager ther eare clearly 2 types of functiosn and data | 12:04 |
| gibi | yes | 12:04 |
| gibi | that run method makes it an active component, but also it encapsulates some response data | 12:04 |
| sean-k-mooney | ya so run sleep and generating the responce feel like tehy should all be on one class | 12:05 |
| sean-k-mooney | and the data storage and querying its state shoudl be in anohter | 12:05 |
| sean-k-mooney | gibi: i did not quite understand what you ment by https://review.opendev.org/c/openstack/nova/+/825015/3/nova/healthcheck/manager.py#31 | 12:06 |
| sean-k-mooney | i always split imports into 8 groups , standar lib, external lib, openstack libs, nova and in each of those 4 i split into imports then from x import | 12:08 |
| sean-k-mooney | were you saying that i have split it into more groups then you were expecting or something else? | 12:09 |
| gibi | sean-k-mooney: I meant that in nova I see 3 groups: stdlib, 3pp lib, repo local import | 12:10 |
| gibi | sean-k-mooney: but I have no real problem with more groups | 12:10 |
| gibi | so feel free to ignore that command | 12:11 |
| gibi | *comment | 12:11 |
| sean-k-mooney | gibi: i use the same groups in nova for my other work | 12:20 |
| sean-k-mooney | hacking allows both i really hate when we mix from and import in the same group | 12:21 |
| gibi | OK, I can adapt to it per file :) | 12:21 |
| sean-k-mooney | i used to go fix that but now i more or less deal with the impoort confution | 12:21 |
| sean-k-mooney | i find it really diffuct to parse how i should order things when you mix the import and from together | 12:22 |
| sean-k-mooney | i have considered proposing we us automatic import sorting at one point but there are more importnat hills to die on | 12:22 |
| sean-k-mooney | gibi: but effectivly you were suggestign treating openstack libs and third party python libs the same | 12:24 |
| gibi | sean-k-mooney: our current nova style do so. I have no hard feelings either way | 12:25 |
| sean-k-mooney | we are not super consitent with that | 12:25 |
| sean-k-mooney | sometimes we include evently in the standardlib section :) | 12:25 |
| sean-k-mooney | if people want me to change it i can but ill leave it for now until i have it working end to end | 12:27 |
| gibi | leave it :) | 12:29 |
| opendevreview | Stephen Finucane proposed openstack/placement master: db: Update 'select()' calls https://review.opendev.org/c/openstack/placement/+/801103 | 12:30 |
| opendevreview | Stephen Finucane proposed openstack/placement master: db: Remove use of non-integer/slice indices https://review.opendev.org/c/openstack/placement/+/801104 | 12:30 |
| opendevreview | Stephen Finucane proposed openstack/placement master: db: Replace deprecated 'FromClause.select().whereclause' parameter https://review.opendev.org/c/openstack/placement/+/801105 | 12:30 |
| opendevreview | Stephen Finucane proposed openstack/placement master: db: Use explicit transactions https://review.opendev.org/c/openstack/placement/+/801106 | 12:30 |
| opendevreview | Stephen Finucane proposed openstack/placement master: db: Remove unnecessary use of '_mapping' https://review.opendev.org/c/openstack/placement/+/801107 | 12:30 |
| opendevreview | Stephen Finucane proposed openstack/placement master: tox: Enable SQLAlchemy 2.0 warnings https://review.opendev.org/c/openstack/placement/+/801108 | 12:30 |
| opendevreview | Stephen Finucane proposed openstack/placement master: tests: Restore - don't reset - warning filters https://review.opendev.org/c/openstack/placement/+/828119 | 12:30 |
| sean-k-mooney | hehe speaking of placement ^ gibi how is you any trait series coming | 12:31 |
| stephenfin | sean-k-mooney: I'd appreciate reviews on that, btw :) It's all very simple stuff but preps us for sqla 2.0 | 12:32 |
| stephenfin | Need to find time to finish the equivalent nova series /o\ | 12:32 |
| sean-k-mooney | stephenfin: ack i can take a look. im going to try an go thorugh the off path seires this morning maybe this afternoon | 12:33 |
| *** amoralej is now known as amoralej|lunch | 12:56 | |
| gibi | sean-k-mooney: melwitt gave +2 on the next patch in the any-traits series | 13:01 |
| gibi | sean-k-mooney: you your eyese are appreciated there too :) | 13:01 |
| * gibi go and look at the placement sqla series now | 13:02 | |
| bauzas | folks, I'm a bit on and off today, I think I'm impacted by the COVID | 13:05 |
| * bauzas still awaits for the PCR test result | 13:06 | |
| elodilles | ohh, bauzas get well soon :S | 13:07 |
| elodilles | (i just wanted to ask for a stable review, but then i won't disturb you with that :S) | 13:08 |
| gibi | bauzas: take care! | 13:08 |
| gibi | bauzas: if you need I can cover you tomorrow on the weekly meeting | 13:09 |
| bauzas | gibi: no, unfortunately in France if you're impacted but you WFH, they don't give you some offtime | 13:09 |
| gibi | that sounds bad | 13:10 |
| gibi | anyhow I'm not bound by the french law so I can still cover you if you want :) | 13:10 |
| opendevreview | Tobias Urdin proposed openstack/nova master: Cleanup old resize instances dir before resize https://review.opendev.org/c/openstack/nova/+/827865 | 13:16 |
| bauzas | for the moment, I don't have a lot of issues, just some cough, a sore throat and nose blowing | 13:16 |
| bauzas | like if it was a small rhinitis | 13:18 |
| bauzas | fwiw, my daughter got the same on Tuesday and we saw the positif test on Wed so I tested myself too on Wed morning with a selftest, then an antigenic test on Wed evening, and then a PCR test on Thursday | 13:19 |
| bauzas | eventually a last selftest on Friday | 13:19 |
| bauzas | all of them were negative | 13:19 |
| bauzas | but yesterday evening, I selftested again (ie. after 5 days of being negative) and eventually it was positive :( | 13:20 |
| bauzas | hence the PCR test today | 13:20 |
| *** dasm|off is now known as dasm | 13:20 | |
| bauzas | so, see, maybe testing yourself up to J+4 doesn't work | 13:20 |
| bauzas | D+4 I mean | 13:21 |
| gibi | yeah | 13:22 |
| gibi | I heard similar stories | 13:22 |
| bauzas | from what I read, this is specific to Omicron | 13:25 |
| bauzas | for Delta, this worked | 13:25 |
| bauzas | but now, symptoms arrive before the viral charge | 13:25 |
| bauzas | or at the same time | 13:26 |
| bauzas | so, previously, testing yourself at D+3 was verifying your viral charge | 13:26 |
| bauzas | while now, your viral charge would only arrive around D+5 | 13:28 |
| bauzas | the more people know, the better it will be | 13:28 |
| sean-k-mooney | dmitriis: -1 for https://review.opendev.org/c/openstack/nova/+/824833/7/nova/network/neutron.py#1527 | 13:40 |
| dmitriis | sean-k-mooney: looking | 13:40 |
| sean-k-mooney | tl;dr we cant assume a PF has a netdev | 13:41 |
| sean-k-mooney | so you cant assume it has a mac | 13:41 |
| sean-k-mooney | your new fucntion will be called for all VFs not just remote managed ones | 13:42 |
| sean-k-mooney | so you need to not raise | 13:42 |
| sean-k-mooney | just dont include the info if it cant be recived | 13:42 |
| sean-k-mooney | *retrived | 13:42 |
| dmitriis | sean-k-mooney: yeah, a PF can be something else, much like a PF with a netdev can have non-netdev VFs | 13:43 |
| dmitriis | good point | 13:43 |
| sean-k-mooney | we broke this in the past | 13:44 |
| sean-k-mooney | by always trying to get the netdev name for bandwith qos and i broke it differently in a different bugfix | 13:44 |
| sean-k-mooney | so we have been bitten by it twice | 13:45 |
| sean-k-mooney | dmitriis: actully just to reinforce that you cant assume all VFs are nics | 13:46 |
| gibi | ohh, I knew that we cannot assume that netdev exists but I did not realized that to get the MAC we need the netdev | 13:46 |
| sean-k-mooney | that is what we broke with the init qos support we broke vf for qat | 13:47 |
| dmitriis | sean-k-mooney: yeah, Bluefield2 devs have a management VF, for example, which is not a netdev | 13:47 |
| sean-k-mooney | i can triple check how we do the lookup but in general the mac wont be in /sys if the netdev is not created | 13:47 |
| sean-k-mooney | gibi: we do the lookup like this https://github.com/openstack/nova/blob/master/nova/pci/utils.py#L173-L191 | 13:50 |
| sean-k-mooney | which i woudl expect to fail sicne we are geting the netdev path | 13:50 |
| gibi | yeah you are correct | 13:50 |
| sean-k-mooney | dmitriis: anyway hopefully that will be a minor change jsut dont populate the filed if the data is not available | 13:51 |
| sean-k-mooney | im going to continue reviewing the rest of the series in the mean time | 13:51 |
| dmitriis | sean-k-mooney: Thinking about it now, I assumed that since we are in the neutron-related code path and got a PCI device allocated which is a netdev VF, I am safe to assume the PF is also a netdev. However, this may not be true all the time. | 13:51 |
| dmitriis | sean-k-mooney: ack | 13:51 |
| sean-k-mooney | dmitriis: ya that was the assumtion that bit us for the calvim thunderx | 13:52 |
| sean-k-mooney | i even hat that in a comment | 13:52 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/777679/3/nova/virt/libvirt/host.py | 13:52 |
| sean-k-mooney | so no we cant assume that | 13:52 |
| dmitriis | sean-k-mooney: yes, I recall fixing something for that comment but I definitely missed this part | 13:53 |
| *** amoralej|lunch is now known as amoralej | 13:53 | |
| 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 | 13:54 |
| gibi | melwitt: fyi the placement perfload job (non voting) probably broken since the consumer types feature https://zuul.opendev.org/t/openstack/build/0d0e850ea9de47e8bf30ad1dbd1d3b91/log/job-output.txt#1163 | 14:05 |
| gibi | melwitt: I think we don't really look at that job so I'm not sure we want to fix it | 14:05 |
| chateaulav | gibi: for the hanging comment about the tempest testing, you mean in addition to an additional ci job, correct? | 14:08 |
| chateaulav | for https://review.opendev.org/c/openstack/nova/+/822053, and thanks for the continued reviews! | 14:08 |
| gibi | chateaulav: yeah so I think a separate job that test some emulation (maybe aarch64) with tempest. But I guess some of the existing tempest test will not work with emulation so we need a trimmed down test list | 14:08 |
| chateaulav | ok, makes sense for the most part. first time messing with tempest, but ill get something together | 14:11 |
| gibi | chateaulav: thanks | 14:13 |
| sean-k-mooney | gibi: chateaulav by the way have either of you got a working vm image for this testing. i think the centos9s cloud image will booth properly on arm (it did on my mac nativly) but i could not get cirros to work | 14:17 |
| sean-k-mooney | the centos image is huge in comparison at almost 700mb | 14:17 |
| gibi | sean-k-mooney: I did not tired | 14:18 |
| sean-k-mooney | ok well that might be one of the chanllages with doing the arm testing via emulation but it is likely fine | 14:18 |
| sean-k-mooney | we can have devstack download addtional images | 14:19 |
| sean-k-mooney | but i was having trouble geting cirrus to boot with uefi in genreal and that is required for aarch64 | 14:19 |
| sean-k-mooney | so uefi on x86 and aarch64 did not seam to work with cirros | 14:19 |
| sean-k-mooney | i got an error with the alingment or either the filesystme or uefi firmware in the console and then no output | 14:20 |
| sean-k-mooney | chateaulav: what have you been using to test with qemu directly? | 14:20 |
| chateaulav | sean-k-mooney: yeah havent tried the cirros on aarch hardware, but on x86 works fine. | 14:20 |
| chateaulav | have code running in a deployment ostack env | 14:20 |
| sean-k-mooney | did you do an install form iso or something else | 14:21 |
| sean-k-mooney | chateaulav: ok so you did arch64 via qemu on x86 with the aarch64 cirros image | 14:21 |
| chateaulav | http://download.cirros-cloud.net/0.5.2/cirros-0.5.2-aarch64-disk.img | 14:21 |
| chateaulav | sean-k-mooney: qcow | 14:21 |
| chateaulav | yes | 14:21 |
| sean-k-mooney | ya i tried that and it woudl not boot on may ubuntu aarch64 vm on my macbook air | 14:22 |
| sean-k-mooney | i was trying to see if i could use that as a arm dev env | 14:22 |
| sean-k-mooney | chateaulav: did you put anything special in the glacne metadtaa | 14:23 |
| chateaulav | hw_emulation_architecture='aarch64', hw_firmware_type='uefi', hw_machine_type='virt' | 14:23 |
| sean-k-mooney | ya ok that is what i was expecting | 14:23 |
| sean-k-mooney | thanks | 14:23 |
| sean-k-mooney | i can give it a try again i pulled the image form github so maybe there is a delta | 14:24 |
| sean-k-mooney | from here https://github.com/cirros-dev/cirros/releases/tag/0.5.2 | 14:24 |
| chateaulav | the ubuntu one is kinda weird because of how they setup the video aspect but i havent had issues with other vendors. it still builds but i only ever have ssh | 14:24 |
| dmitriis | sean-k-mooney: RE https://review.opendev.org/c/openstack/nova/+/824833/7/nova/network/neutron.py#1536 shouldn't we always be able to get a VF num for a valid VF PCI address? This would only raise if a device somehow got unbound just before this code ran and a symlink to physfn of a VF is not present to retrieve the VF num OR if the PCI address is | 14:25 |
| dmitriis | not valid in the first place. Happy to remove this check and let operators to figure it out in case it happens but just curious. | 14:25 |
| sean-k-mooney | dmitriis: im not sure if all vendors always export the symilink to work that out | 14:25 |
| sean-k-mooney | i would expect that the vf number should generally be avaialble but rather then raise in this funciton i think we shoudl just not include the info if not avaiable | 14:26 |
| sean-k-mooney | as a general pattern | 14:26 |
| opendevreview | Elod Illes proposed openstack/nova stable/wallaby: workarounds: Add libvirt_disable_apic https://review.opendev.org/c/openstack/nova/+/805628 | 14:28 |
| sean-k-mooney | dmitriis: i say perfer as im open to being conviced otherwise but in general i woudl prefer not to reate retiving info as an error. its true it might mean that device cannot be remote managed but in that case the operator has incorrectly tagged it. on the neutron side the ml2/driver can check the profile and fail the binding if the info is not present tha it needs | 14:28 |
| dmitriis | sean-k-mooney: I think it's the generic SR-IOV handling code in the kernel that creates the sysfs entry | 14:32 |
| dmitriis | https://github.com/torvalds/linux/blob/v5.16/drivers/pci/iov.c#L144-L147 | 14:32 |
| dmitriis | https://github.com/torvalds/linux/blob/v5.16/drivers/pci/iov.c#L295 | 14:32 |
| dmitriis | In this case, the case where the info won't be retrievable will likely never happen so I have no issue in making it optional. Just trying to reason about what to put into a comment there. | 14:32 |
| sean-k-mooney | just say somthign like. this should be created by default on all modeern kernels but we make it optional to cater for expotic hardware or older kernel where this may not be ture | 14:34 |
| dmitriis | sean-k-mooney: ack, will do | 14:34 |
| sean-k-mooney | dmitriis looking at 4.14 for example im not sure it does the same https://github.com/torvalds/linux/blob/v4.14/drivers/pci/iov.c#L165-L176 | 14:35 |
| sean-k-mooney | well | 14:35 |
| sean-k-mooney | it has the physfn symlink | 14:36 |
| sean-k-mooney | i guess it has the virtfn symlink too | 14:36 |
| sean-k-mooney | so i guess it would not break on centos 8 | 14:36 |
| sean-k-mooney | dmitriis: i know mellonox/nvida changed where the representor netdevs were create for example in a relitivly recent kernel | 14:37 |
| sean-k-mooney | https://github.com/openstack/os-vif/commit/b37de19c58c877f5174d76d0a4ba5ab519f464e8#diff-087288ddacb7516a4762ef38c4361754c2d6bb07a52952b06aa6f607dc3811fe | 14:37 |
| sean-k-mooney | 5.8 https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=123f0f53dd64b67e34142485fe866a8a581f12f1 | 14:38 |
| sean-k-mooney | dmitriis: im trying to avoid failure in nova when thing like that ar changed | 14:39 |
| dmitriis | sean-k-mooney: yeah, probably worth one VM failing to boot than the whole daemon dying because of the exception | 14:39 |
| dmitriis | totally agree | 14:39 |
| sean-k-mooney | yep plus as i said in the neutron ml2 driver you can fail the port binding an log an explit error message if the required info is not present | 14:40 |
| dmitriis | sean-k-mooney: also very true | 14:41 |
| sean-k-mooney | you could proably also add a check in nova at a differnt point if you wanted before that but i woudl just log the error form neutron personlaly | 14:41 |
| dmitriis | sean-k-mooney: I'll log a warning in Nova in this case and simply return no data in the profile and let Neutron fail to bind | 14:42 |
| sean-k-mooney | well you shoudl not return an empty profile | 14:42 |
| sean-k-mooney | this code will be used for other VFs that may not be remote managed | 14:42 |
| sean-k-mooney | and tehy do not need the vf number | 14:43 |
| sean-k-mooney | we pass the vf pci adress | 14:43 |
| sean-k-mooney | that is all they need in the general case | 14:43 |
| dmitriis | rephrasing: 1. if PF MAC cannot be retrieved, do not include vf_num or card_serial_number either | 14:43 |
| dmitriis | 2. if vf_num cannot be retrieved, do not include pf_mac and card_serial_number | 14:43 |
| sean-k-mooney | ah well ya perhaps | 14:44 |
| sean-k-mooney | i was thinking just include all the info you can always but i guess that works too | 14:44 |
| dmitriis | ok, just need to fix the tests a little and I'll re-upload | 14:45 |
| sean-k-mooney | ack | 14:45 |
| sean-k-mooney | dmitriis: by the way have you tested this feature with a second ovs on the compute host | 14:46 |
| *** Guest1862 is now known as dansmith | 14:47 | |
| sean-k-mooney | we had some internal question regarding can we have both offpath port and on path port on the same host | 14:47 |
| sean-k-mooney | the reason for that was to use vm management port with vnic_type=normal and datapalne prots with vnic_type=smartnic | 14:48 |
| dmitriis | sean-k-mooney: i.e. having a DPU and a regular SR-IOV card | 14:48 |
| sean-k-mooney | well dpu and another nic that can be used with ovs or linux bridge | 14:48 |
| dmitriis | right | 14:48 |
| dmitriis | I haven't tested that explicitly but just trying to think what would that entail | 14:49 |
| sean-k-mooney | basically it was raised that by using the dpu you are limiting the numer or port that can be created to the number of vfs | 14:49 |
| sean-k-mooney | dmitriis: i think it should just work honestly | 14:49 |
| sean-k-mooney | i was just wondering if you had considerd it | 14:49 |
| dmitriis | sean-k-mooney: yes, the limitation on the number of ports have definitely come up in our conversations | 14:49 |
| sean-k-mooney | dmitriis: all it really requires is the ml2 dirver changes to not require you to designate a host as only dpu enabled | 14:50 |
| dmitriis | and nothing immediately jumps into mind regarding OVS on the host being a problem | 14:50 |
| sean-k-mooney | e.g. make the binding desiion per port based on vnic_type | 14:50 |
| sean-k-mooney | ack that is what my assement was too | 14:50 |
| dmitriis | sean-k-mooney: yeah and IIRC it's just based on the vnic_type, we just added handling for vnic_type smartnic to the OVN mechanism driver | 14:51 |
| dmitriis | so it should just bind a normal port regularly | 14:51 |
| sean-k-mooney | yep | 14:51 |
| sean-k-mooney | cool | 14:51 |
| sean-k-mooney | we are still trying to assess what woudl be requried to eventually support this in our product | 14:51 |
| dmitriis | sean-k-mooney: yeah, plus hardware is hard to come by | 14:52 |
| sean-k-mooney | that too | 14:52 |
| dmitriis | I think this feature will be useful for FPGA-based SmartNICs as well. I've seen the ones with a separate CPU but with an FPGA instead of an ASIC | 14:52 |
| dmitriis | considering the DPDK dataplane usage at the SmartNIC's CPU side for that with rte_flow for offload | 14:53 |
| sean-k-mooney | i do potentially have access to a BF2 that i coudl use but only 1 so i obviouly cant test multi node and in general an all in one deployment while useful is not fully reflective of how it would be deployed in a datacenter | 14:53 |
| dmitriis | the Nova and Neutron bits would work the same though | 14:53 |
| sean-k-mooney | dmitriis: yes in princial it could be | 14:53 |
| dmitriis | sean-k-mooney: I have an idea on how to test multi-node with just one BF2 | 14:53 |
| sean-k-mooney | the only fpga based smartnic i have use used armstong os with only 2 arm cores and i think 4GB of ram | 14:54 |
| sean-k-mooney | dmitriis: run two copies of nova-compute with difernt host values in teh conf on the same host | 14:54 |
| sean-k-mooney | and use differnt ports on the BF2? | 14:54 |
| dmitriis | sean-k-mooney: 2 VMs with nested virt a the hypervisor, plus 2 VMs at the DPU side. Each VM uses 1 PF. VPD can be faked by bind mounting a file in the right sysfs location | 14:54 |
| dmitriis | BF2's ARM CPU is virt-capable btw xD | 14:55 |
| sean-k-mooney | dmitriis: that proably wotn work becaue wehn the PF is passed to the qemu instacle the pcie capablityies are not in the pci config space in teh guest | 14:55 |
| sean-k-mooney | lspci in the guest will only print the pci capablities not the extened pcie cabalities like sriov | 14:56 |
| sean-k-mooney | in my previous experince | 14:56 |
| sean-k-mooney | even when using q35 | 14:56 |
| dmitriis | sean-k-mooney: I was about to ask about q35 :^) | 14:56 |
| sean-k-mooney | if it does work let me know :) | 14:56 |
| dmitriis | sean-k-mooney: there's another option | 14:56 |
| dmitriis | BF2 on one host + ConnectX on another | 14:56 |
| dmitriis | just use the remote_managed feature with ovs/ovn-controller running locally on the connectx node | 14:57 |
| sean-k-mooney | ya i tought about that | 14:57 |
| sean-k-mooney | jsut addign the serial to the chasis table for the hosts ovn | 14:58 |
| dmitriis | yes | 14:58 |
| sean-k-mooney | in prinicapal that would owrk without BF2 | 14:58 |
| dmitriis | yes, technically, we just made Nova and Neutron realize that networking agents may run remotely but the trivial case is running locally | 14:58 |
| sean-k-mooney | i did not really want to say that to our qe however :) | 14:58 |
| dmitriis | yeah, fair enough :^) | 14:59 |
| sean-k-mooney | but ya in principal we can test most of the integration that way for any nic that supprot vpd | 14:59 |
| dmitriis | or even bind mount a file to the right sysfs location | 15:00 |
| sean-k-mooney | i.e. if we can get the serial,mac and vf number we can test the end to end integration | 15:00 |
| dmitriis | I got used to crafting VPD blobs since I needed to unit test the libvirt change | 15:00 |
| dmitriis | basically, I crafted them byte-by-byte | 15:00 |
| dmitriis | sean-k-mooney: ^ yes | 15:00 |
| sean-k-mooney | ya thats doable | 15:01 |
| sean-k-mooney | although i dont think it woudl be hard to have a python class that modeled it and just serialise it as a byte string | 15:01 |
| sean-k-mooney | rather then do it by hand | 15:01 |
| sean-k-mooney | unfortunetly i dont think we can use that to test in the upstream ci | 15:01 |
| dmitriis | sean-k-mooney: yeah, it's not too hard. The only tricky part there is checksum calculation but it's a simple algorithm | 15:02 |
| sean-k-mooney | crc32 or similar i assume | 15:02 |
| sean-k-mooney | it would not be hard to look at the c code and ectra | 15:02 |
| dmitriis | sean-k-mooney: just one's complement | 15:02 |
| sean-k-mooney | that said im not sure libvirt cares about the crc | 15:02 |
| sean-k-mooney | ack | 15:03 |
| dmitriis | sean-k-mooney: IIRC I validate the checksum for the read-only portion there | 15:03 |
| sean-k-mooney | oh in the nova code? | 15:03 |
| sean-k-mooney | i dont think i recall seeing that | 15:03 |
| dmitriis | sean-k-mooney: no-no, in the Libvirt code that parses VPD | 15:04 |
| sean-k-mooney | ah | 15:04 |
| sean-k-mooney | ok | 15:04 |
| dmitriis | sean-k-mooney: there is a chance that something may be added to the mellanox CI. I know CX5 hw is there based on the logs but no BF2 (yet) | 15:04 |
| dmitriis | maybe I'll have some info later this week about that | 15:04 |
| dmitriis | there are automation challenges: i.e. we need to bring up devstack + also program the DPU | 15:05 |
| dmitriis | but devices availability first I guess | 15:05 |
| sean-k-mooney | i actully have been doing some experiment on the side lately and as part of my test infra i have a fake copy of part of /sys | 15:05 |
| sean-k-mooney | https://github.com/SeanMooney/arbiterd/tree/master/arbiterd_tests/test_data/sys | 15:05 |
| sean-k-mooney | the idea being that in my func test it would use the fake copy of the file system | 15:05 |
| sean-k-mooney | its too bad we cant create fake pf devices using kernel modules for testing | 15:06 |
| sean-k-mooney | i have looked into it in the past and we can create the fake netdevs for sriov | 15:06 |
| dmitriis | sean-k-mooney: there's netdevsim but it doesn't create PCI devices | 15:06 |
| sean-k-mooney | but not the pci toploty | 15:06 |
| sean-k-mooney | yep | 15:07 |
| sean-k-mooney | exactly | 15:07 |
| dmitriis | can't pass them to a VM, yep | 15:07 |
| sean-k-mooney | i tried to use that for sriov testing in the upstream ci in the past | 15:07 |
| sean-k-mooney | i also was lookign at the mdev equivlent | 15:07 |
| dmitriis | we utilize netdevsim for ovn-vif testing | 15:07 |
| sean-k-mooney | same issue no pci endpoints | 15:07 |
| dmitriis | and Frode is working on some code to extend it in the kernel but it's only usable for the ovn-vif testing part | 15:08 |
| sean-k-mooney | ya that kind fo makes sense since it woudl not need the pci adress just the netdevs | 15:08 |
| sean-k-mooney | if it ever gets extened to implement pci vfs/pfs | 15:09 |
| sean-k-mooney | we would be able to use it for basic pci pasthorugh testing | 15:09 |
| sean-k-mooney | we woudl not need the networking to actully work | 15:09 |
| sean-k-mooney | just enough to pass it to qemu | 15:09 |
| sean-k-mooney | that is a lot of work but would be super useful for us | 15:09 |
| dmitriis | sean-k-mooney: I also looked at a possibility of using the rocker switch in QEMU but it's useful for switchdev testing but doesn't have SR-IOV emulation | 15:09 |
| sean-k-mooney | ya | 15:10 |
| dmitriis | sean-k-mooney: yes, also Libvirt's testing of VF-related stuff is quite minimal. They have the same problem with emulating VFs presumably | 15:10 |
| sean-k-mooney | so at some point we likely will want to supprot vdpa with subfunction rather then vfs as the parent | 15:10 |
| sean-k-mooney | the rocker switch might be useful to test that eventually | 15:10 |
| dmitriis | yeah, SFs are something we also started looking into but there's more work to do at the ovn-vif side. Even for VFs we ran into a race at the BF2 side https://github.com/ovn-org/ovn-vif/pull/1 and SFs are even more dynamic | 15:12 |
| dmitriis | TL;DR: SR-IOV is enabled at the hypervisor and then BF2 realizes that it needs to create representors and the DPU kernel starts creating udev events for them and rename them | 15:13 |
| sean-k-mooney | ack in a similar vain i was hoping to eventualy start using https://github.com/torvalds/linux/blob/d4ec3d5535c784c3adbc41c2bbc5d17a00a4a898/samples/vfio-mdev/mtty.c and https://github.com/torvalds/linux/blob/d4ec3d5535c784c3adbc41c2bbc5d17a00a4a898/samples/vfio-mdev/mdpy.c or | 15:13 |
| sean-k-mooney | https://github.com/torvalds/linux/blob/d4ec3d5535c784c3adbc41c2bbc5d17a00a4a898/samples/vfio-mdev/mbochs.c to test our generic mdev support | 15:13 |
| dmitriis | mtty, interesting | 15:14 |
| sean-k-mooney | i belive it just echos back what you send to it | 15:14 |
| sean-k-mooney | but that woudl be super simple to test in tempest | 15:15 |
| dmitriis | yes, quite useful | 15:15 |
| sean-k-mooney | our current mdev code i belive assumes each mdev has a pci device as a parent | 15:15 |
| sean-k-mooney | so we would need to relax that | 15:15 |
| sean-k-mooney | to use the driver but if we did we could get full ci coverage for it | 15:15 |
| sean-k-mooney | when people start using mdev for subfuction or non VF usecase we might need to do that anyway | 15:16 |
| sean-k-mooney | at which point we can test it properly in ci | 15:16 |
| dmitriis | I heard that SFs were introduced to support container use-cases because of scalability issues, less so for VMs. Doesn't mean VMs cannot use them but still. | 15:17 |
| dmitriis | scalability ~ small number of ports | 15:17 |
| sean-k-mooney | depend on who you ask. i know intel were interestin in there version for contaienr but also saw it as a way to adress the vm case in terms of number of ports | 15:18 |
| sean-k-mooney | dmitriis: really the use case is the same allow more then max_vf ports | 15:18 |
| sean-k-mooney | that said i think recent connectx/bf2 cards have started to get into the 1000+ vf range | 15:19 |
| dmitriis | sean-k-mooney: yeah, there are some parts of the SR-IOV spec that can be used to overcome the 256 limit | 15:19 |
| dmitriis | some neat tricks with PCI address allocation | 15:19 |
| sean-k-mooney | yes you multiple buses to card to work around that | 15:20 |
| dmitriis | yep | 15:20 |
| sean-k-mooney | contaienr and vm cloud system really prefer to pertend that the port limit is infinity | 15:21 |
| sean-k-mooney | like k8s and opnestack really dont treat ports as a finite reqouce outside fo sriov | 15:21 |
| dmitriis | sean-k-mooney: there's another problem: accounting and quotas on certain hw limits. There's a finite number of flows that can be programmed and not a lot of data on hw limits per VF/SF | 15:22 |
| dmitriis | likewise, no APIs to query that AFAIK | 15:22 |
| sean-k-mooney | in reality most customer proably wont hit that limit but they are woried fi they layer things like openshift running on top of openstack they might | 15:22 |
| dmitriis | sean-k-mooney: yes, plus with layers on top of OpenStack people start running overlays on top of overlays | 15:23 |
| sean-k-mooney | ya there are both limits on the number of tables and the table row count and then seperat lmits on but the hardwar flows offload | 15:23 |
| dmitriis | and doing that using guest CPU | 15:23 |
| sean-k-mooney | ok i better get back to reviewing your changes before my next meeting :) | 15:24 |
| dmitriis | sean-k-mooney: right, I'll get to re-submitting too :^) | 15:24 |
| *** dansmith is now known as Guest2102 | 15:29 | |
| *** Guest2102 is now known as dansmith | 15:37 | |
| sean-k-mooney | dmitriis: is there anyting in the port beyond the vnic_type that tells nova that we need a vf | 15:49 |
| sean-k-mooney | dmitriis: gibi be might not be able to reuse vnic_type smartnic | 15:49 |
| opendevreview | Tobias Urdin proposed openstack/nova master: Cleanup old resize instances dir before resize https://review.opendev.org/c/openstack/nova/+/827865 | 15:50 |
| sean-k-mooney | if we assume that all port that have vnic_type smartnic require a vf that would break ironics use of it yes? | 15:50 |
| opendevreview | Balazs Gibizer proposed openstack/placement master: Fix perfload jobs after consumer_types https://review.opendev.org/c/openstack/placement/+/828167 | 15:50 |
| gibi | sean-k-mooney: I don't know how ironic uses the smartnic vnic_type | 15:51 |
| gibi | melwitt: I think the perfload job is easy to fix https://review.opendev.org/c/openstack/placement/+/828167 | 15:51 |
| dmitriis | sean-k-mooney: (thinking) | 15:51 |
| sean-k-mooney | https://specs.openstack.org/openstack/ironic-specs/specs/12.1/support-smart-nic.html | 15:51 |
| sean-k-mooney | gibi: they bascially wanted to supprot ovs running on the smartnic also | 15:54 |
| sean-k-mooney | but using ml2/ovs | 15:54 |
| sean-k-mooney | with the neutron agetn deployed on the smartnic | 15:55 |
| dmitriis | sean-k-mooney: they have a special config option for the neutron-openvswitch-agent as well | 15:55 |
| sean-k-mooney | yes | 15:55 |
| sean-k-mooney | dmitriis: the possible problem i am seing is when we go to scedule the vm we have not bound the port | 15:55 |
| sean-k-mooney | since we have not selected a host yet | 15:56 |
| sean-k-mooney | so i dont think we will be able to tell the difference between the ironic usage and the new usage | 15:56 |
| sean-k-mooney | and we wont know if we shoudl request a VF or not | 15:56 |
| sean-k-mooney | so we might need to use a differnt off-path vnic type | 15:57 |
| sean-k-mooney | instead | 15:57 |
| dmitriis | sean-k-mooney: in Nova we decide if we want to request a remote_managed port or not | 15:57 |
| dmitriis | and add that to a InstancePCIRequest | 15:57 |
| sean-k-mooney | dmitriis: yes based on the vnic_type right | 15:57 |
| dmitriis | yes | 15:57 |
| sean-k-mooney | right so if we only look at that we need a new vnic type | 15:58 |
| dmitriis | but that's in Nova, trying to figure out how that affects ironic | 15:58 |
| sean-k-mooney | since that decision need to be made before we schdule and therefor cannot depend on the host or driver | 15:58 |
| sean-k-mooney | booting ironic service via nova api | 15:58 |
| sean-k-mooney | *servers | 15:58 |
| sean-k-mooney | in both cases the vnic_type would be the same | 15:59 |
| sean-k-mooney | the falvor woudl be differnt but we would not know its an ironic flavor | 15:59 |
| sean-k-mooney | dmitriis: so i think we need to quickly add a new vnic in neutron-lib and update the nova and neutron code to use that | 16:00 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Allow authorization by user_id for server resume action https://review.opendev.org/c/openstack/nova/+/828168 | 16:01 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Allow authorization by user_id for server resume action https://review.opendev.org/c/openstack/nova/+/828168 | 16:01 |
| dmitriis | sean-k-mooney: we could, trying to think if there's anything we've missed that could allow us to avoid that. We originally wanted to add a new VNIC type but then decided to reuse VNIC_TYPE_SMARTNIC after some reviews. | 16:03 |
| sean-k-mooney | yep i proably suggested the reuse :) but i think its proably required | 16:03 |
| sean-k-mooney | *the new vnic | 16:03 |
| sean-k-mooney | i dont think there is anything else on the port we can use to differenciate | 16:03 |
| * gibi needs to jump on a call but will read back | 16:04 | |
| sean-k-mooney | oh same | 16:05 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Allow authorization by user_id for server resume action https://review.opendev.org/c/openstack/nova/+/828168 | 16:10 |
| *** amoralej is now known as amoralej|off | 16:22 | |
| gibi | so if we always translate the smartnic vnic_type to InstancePCIRequest but ironic support smartnic with ml2/ovs then we might have a problem | 16:38 |
| gibi | do we require ironic to use some custom resource in the flavor or it is just an option? | 16:38 |
| sean-k-mooney | am we require cpu, ram and disk to be overriden to resources:cpu=0 | 16:42 |
| *** dansmith is now known as Guest2108 | 16:45 | |
| *** Guest2108 is now known as dansmith | 16:46 | |
| gibi | that could be a clue | 16:46 |
| sean-k-mooney | im not sure if we want to rely on that | 16:46 |
| sean-k-mooney | we could | 16:46 |
| gibi | yeah it is hackins | 16:46 |
| gibi | hackis | 16:46 |
| gibi | when we have the lib freeze? | 16:47 |
| sean-k-mooney | i belive in a week or two | 16:47 |
| sean-k-mooney | ill check | 16:47 |
| gibi | feb 18 | 16:47 |
| sean-k-mooney | ya | 16:47 |
| sean-k-mooney | actully proably 17th | 16:48 |
| gibi | yeah | 16:48 |
| sean-k-mooney | so we still have time to add the value | 16:48 |
| gibi | lets try the new vnic_type way then | 16:48 |
| gibi | that would be clean | 16:48 |
| sean-k-mooney | so vnic_type=off-path | 16:49 |
| sean-k-mooney | actully maybe vnic_type=off-path-direct | 16:49 |
| sean-k-mooney | so that we can have vnic_type=off-path-vdpa or off-path-mev or whaterver later if needed | 16:49 |
| sean-k-mooney | but keep the pattern | 16:49 |
| gibi | yes, off-path or remote-managed whathever floats the neturon team's boat | 16:50 |
| sean-k-mooney | remote-managed might be better ya | 16:51 |
| sean-k-mooney | keep the continuity with the config option | 16:51 |
| dmitriis | sean-k-mooney, gibi: been trying to find something to use as a clue (such as image or flavor metadata) | 16:56 |
| dmitriis | but, yes, it's tricky to rely on that | 16:56 |
| sean-k-mooney | dmitriis: i dont think there is really anything and really it shoudl be soemthing on the port anyway | 17:01 |
| sean-k-mooney | we could look at the flaovr but that is messy | 17:01 |
| dmitriis | sean-k-mooney: ovs hardware offload uses binding:profile to differentiate between legacy SR-IOV and offload cases https://docs.openstack.org/neutron/latest/admin/config-ovs-offload.html#validate-open-vswitch-hardware-offloading | 17:02 |
| dmitriis | been considering utilizing something like that as well | 17:02 |
| sean-k-mooney | dmitriis: the port is not bound at this point | 17:02 |
| sean-k-mooney | we cant use anything that depend on the host/neutron backend | 17:03 |
| sean-k-mooney | since the host is only selected after the scheduling | 17:03 |
| sean-k-mooney | dmitriis also --binding-profile '{"capabilities": ["switchdev"]}' i dot think was ever actully implemented | 17:03 |
| dmitriis | sean-k-mooney: yeah, that's the unfortunate thing - I don't know the driver before scheduling happens | 17:03 |
| dmitriis | sean-k-mooney: ah, right we discussed that way back | 17:04 |
| sean-k-mooney | it also would be admin only since binind-profile is admin only | 17:04 |
| sean-k-mooney | yep | 17:04 |
| dmitriis | sean-k-mooney: yes, that would be a shame if it was admin-only | 17:04 |
| dmitriis | sean-k-mooney: ok, I am convinced we need a new VNIC type then | 17:04 |
| dmitriis | sean-k-mooney: I'll propose a change and, I suppose, spec changes too | 17:05 |
| dmitriis | hopefully I'll get quick turnaround from the Neutron team | 17:05 |
| dmitriis | fnordahl ^ FYI | 17:05 |
| sean-k-mooney | yep im happy to review the spec change and approve once neutron agree | 17:05 |
| dmitriis | sean-k-mooney: proposed a spec change for Neutron: https://review.opendev.org/c/openstack/neutron-specs/+/828173. Will upload a neutron-lib change and also raise a Nova spec update. | 17:22 |
| sean-k-mooney | dmitriis: ack. | 17:26 |
| chateaulav | sean-k-mooney: i think i found it, essentially have to tell nova to set `cpu = None` so that no topology is identified. https://usercontent.irccloud-cdn.com/file/EAK0qvLu/riscv | 17:38 |
| sean-k-mooney | topology | 17:39 |
| sean-k-mooney | oh pci topology | 17:39 |
| sean-k-mooney | hum i dont know if None is a supported value or if that is stable | 17:39 |
| chateaulav | https://usercontent.irccloud-cdn.com/file/5U9wBUXt/image.png | 17:39 |
| sean-k-mooney | e.g. does that just mean "qemu you decide" | 17:39 |
| sean-k-mooney | is that new code your addign to nova | 17:40 |
| sean-k-mooney | settign the cpu element to None | 17:40 |
| sean-k-mooney | for risxv64 | 17:40 |
| sean-k-mooney | ]hum that might break other features | 17:41 |
| sean-k-mooney | it will disable the topology but also numa affinity | 17:41 |
| sean-k-mooney | have you tried settign the sockets and thread to 1 | 17:41 |
| chateaulav | gonna do more testing, but that is locally currently. | 17:42 |
| sean-k-mooney | ack. try hw:cpu_sockets=1 hw:cpu_threads=1 | 17:42 |
| chateaulav | yeah i did no 'cpu.model = None' first and it did not like that | 17:42 |
| sean-k-mooney | i think your current code is just not generatign the cpu element entirly | 17:43 |
| sean-k-mooney | but if its just a toplocy issue perhaps you can generate a toplogy it will like | 17:43 |
| chateaulav | yeah, i believe so. | 17:43 |
| sean-k-mooney | when you dont set the falvor extra specs technially the toplogy is driver defined | 17:44 |
| sean-k-mooney | so you can modify it to work based on the requirments | 17:44 |
| sean-k-mooney | for legacy reason the libvirt driver genearte a toplogy of 1 socket per vcpu requested | 17:45 |
| sean-k-mooney | which is bad for a number of reasons | 17:45 |
| sean-k-mooney | it used to improve perfromance but i stongly doubt it does and it cause issue for windows for example | 17:45 |
| sean-k-mooney | chateaulav: so if you need to change the default toplogy for the emulation usecase i think that is ok | 17:46 |
| chateaulav | definetly, now that ive isolated the area, gonna tweak the topology settings | 17:46 |
| opendevreview | Tobias Urdin proposed openstack/nova master: Cleanup old resize instances dir before resize https://review.opendev.org/c/openstack/nova/+/827865 | 18:14 |
| opendevreview | Dmitrii Shcherbakov proposed openstack/nova-specs master: Late Amendments to the Off-path Backends Spec https://review.opendev.org/c/openstack/nova-specs/+/828177 | 18:22 |
| dmitriis | sean-k-mooney: https://review.opendev.org/c/openstack/nova-specs/+/828177 - uploaded | 18:27 |
| sean-k-mooney | dmitriis: ack am im not really happy with adding allow_remote_managed_ports to the whitelist | 18:33 |
| sean-k-mooney | that feels semanticly incorrect to me | 18:33 |
| *** Uggla is now known as Uggla|afk | 18:33 | |
| sean-k-mooney | dmitriis: the docs issue on the spec repo is not related to your patch by the way | 18:36 |
| dmitriis | sean-k-mooney: the alternative approach I considered was to expose a property on the whitelist which would tell us about whether remote_managed is used or not | 18:36 |
| sean-k-mooney | dmitriis: that i think i coudl accpet yes | 18:36 |
| sean-k-mooney | really the whitelist shoudl not really have awareness of the off-path feature | 18:37 |
| dmitriis | sean-k-mooney: hmm, I felt it was slightly backwards because I am exposing state for somebody else to check but maybe I am wrong | 18:37 |
| sean-k-mooney | a porperty i think woudl be ok | 18:37 |
| dmitriis | I'd have to pass it through both on the whitelist and PciDeviceSpec though | 18:37 |
| dmitriis | because I only know about the use of those tags in the spec object | 18:37 |
| sean-k-mooney | the whitelist shoudl not be doign any validation of those tags | 18:38 |
| sean-k-mooney | only the pci tracker should | 18:38 |
| sean-k-mooney | the whitelist is a POD object | 18:39 |
| sean-k-mooney | it does some basic validation fo the imports | 18:39 |
| sean-k-mooney | but it should not be doing any filtering | 18:39 |
| dmitriis | sean-k-mooney: there's some validation done here https://github.com/openstack/nova/blob/b6fe7521afa8d42febc68f5f79782f7bcc3b568f/nova/compute/manager.py#L1430 | 18:41 |
| dmitriis | which is also very early | 18:41 |
| dmitriis | and I have access to the whitelist here | 18:41 |
| sean-k-mooney | that is in the compute manager | 18:41 |
| sean-k-mooney | so its oke to do it there | 18:41 |
| sean-k-mooney | but really it shoudl not be there either | 18:42 |
| sean-k-mooney | it shoudl be in the resouce tracker or pci manager | 18:42 |
| sean-k-mooney | in https://github.com/openstack/nova/blob/master/nova/pci/manager.py#L38 | 18:42 |
| dmitriis | sean-k-mooney: yeah, this should be set up relatively early as well | 18:43 |
| sean-k-mooney | you shoudl do any validation you need here https://github.com/openstack/nova/blob/master/nova/pci/manager.py#L78-L83 | 18:43 |
| sean-k-mooney | its called as part of _setup_pci_tracker in teh resouce traceker | 18:44 |
| sean-k-mooney | https://github.com/openstack/nova/blob/14bfbaa50ed3c000a691a37afbd20d86f431b3fb/nova/compute/resource_tracker.py#L764-L773 | 18:44 |
| sean-k-mooney | which is invoked as part of _init_compute_node | 18:45 |
| dmitriis | sean-k-mooney: ack. And when it comes to exposing the property, I could populate _has_remote_managed after this line https://github.com/openstack/nova/blob/b6fe7521afa8d42febc68f5f79782f7bcc3b568f/nova/pci/whitelist.py#L51 and expose a property | 18:45 |
| dmitriis | and also expose a property on the spec objects themselves | 18:46 |
| dmitriis | I'd have to do a search over spec objects then and see whether any one of those has a property | 18:46 |
| dmitriis | if that's ok, I'll just do it | 18:46 |
| sean-k-mooney | i think that shoudl be ok | 18:47 |
| sean-k-mooney | it sound cleaner to me overall | 18:48 |
| sean-k-mooney | where/why are you using this by the way | 18:48 |
| dmitriis | sean-k-mooney: this is to make sure remote_managed tags aren't usable on a host where libvirt is too old (doesn't have VPD handling code) | 18:49 |
| sean-k-mooney | right so you dont need this on the spec object or whitelist object | 18:49 |
| sean-k-mooney | that is a check you can do in the libvirt driver at start up | 18:49 |
| sean-k-mooney | you can just loop over the spec objects and check for the tag | 18:49 |
| sean-k-mooney | and check the verisons | 18:50 |
| sean-k-mooney | the device spec will already have the value in the PciDeviceSpec.tags field | 18:50 |
| dmitriis | https://review.opendev.org/c/openstack/nova/+/827839/2/nova/virt/libvirt/driver.py#816 | 18:50 |
| dmitriis | ^ so it's a host-based capability | 18:51 |
| dmitriis | host-dependent * | 18:51 |
| sean-k-mooney | yes | 18:51 |
| sean-k-mooney | that does not need to you modify these data stuctures | 18:52 |
| dmitriis | sean-k-mooney: I don't have access to the host object in those | 18:52 |
| dmitriis | but maybe there's some other way to check the Libvirt version | 18:52 |
| sean-k-mooney | you should not be checkign for them in these | 18:52 |
| sean-k-mooney | dmitriis: you shoudl not be doing https://review.opendev.org/c/openstack/nova/+/827839/2/nova/pci/devspec.py#319 | 18:53 |
| sean-k-mooney | that is not the correct place to raise that excption | 18:53 |
| sean-k-mooney | either the device spec of whitelist shoudl raise that | 18:53 |
| dmitriis | sean-k-mooney: ah, sorry, yes we're moving it elsewhere | 18:53 |
| dmitriis | sean-k-mooney: so maybe in the dev tracker I have access to that info, checking | 18:54 |
| sean-k-mooney | i dont think you do | 18:54 |
| sean-k-mooney | we abstrackt the virt driver info away | 18:55 |
| sean-k-mooney | the pci module is ment ot be virt dirver independent | 18:55 |
| sean-k-mooney | you shoudl be doing this check in the libvirt driver.py | 18:55 |
| sean-k-mooney | you coudl perhaps do it in update_devices_from_hypervisor_resources | 18:56 |
| sean-k-mooney | https://github.com/openstack/nova/blob/b6fe7521afa8d42febc68f5f79782f7bcc3b568f/nova/pci/manager.py#L111 | 18:56 |
| sean-k-mooney | but you would have to modify the device_json which im not sure is the right thing | 18:56 |
| sean-k-mooney | am i need to call it a day | 18:57 |
| dmitriis | sean-k-mooney: ack, I'll think about how to do it | 18:57 |
| sean-k-mooney | dmitriis: can you look at moving the check to the libvirt driver | 18:57 |
| dmitriis | sean-k-mooney: sure | 18:58 |
| *** hemna3 is now known as hemna | 19:20 | |
| opendevreview | Dan Smith proposed openstack/nova master: Join quota exception family trees https://review.opendev.org/c/openstack/nova/+/828185 | 19:32 |
| opendevreview | Dan Smith proposed openstack/nova master: Move keypair quota error message into exception https://review.opendev.org/c/openstack/nova/+/828186 | 19:32 |
| dansmith | melwitt: ^ | 19:32 |
| dansmith | I have one other thing I'm going to stack on there, but it'll take me a few more minutes | 19:32 |
| melwitt | dansmith: ack | 19:33 |
| opendevreview | Dan Smith proposed openstack/nova master: Move keypair quota error message into exception https://review.opendev.org/c/openstack/nova/+/828186 | 19:34 |
| *** noonedeadpunk_ is now known as noonedeadpunk | 19:34 | |
| chateaulav | <nova:flavor name="r1.small"> | 20:02 |
| chateaulav | <nova:memory>4096</nova:memory> | 20:02 |
| chateaulav | <nova:disk>16</nova:disk> | 20:02 |
| chateaulav | <nova:swap>0</nova:swap> | 20:02 |
| chateaulav | <nova:ephemeral>0</nova:ephemeral> | 20:02 |
| chateaulav | <nova:vcpus>2</nova:vcpus> | 20:02 |
| chateaulav | </nova:flavor> | 20:02 |
| chateaulav | sean-k-mooney: so setting any topology items doesnt work | 20:03 |
| chateaulav | the above and below are what is set in regards to cpu | 20:03 |
| chateaulav | https://www.irccloud.com/pastebin/f9YIhb6z/ | 20:03 |
| opendevreview | Dan Smith proposed openstack/nova master: Join quota exception family trees https://review.opendev.org/c/openstack/nova/+/828185 | 20:09 |
| opendevreview | Dan Smith proposed openstack/nova master: Move keypair quota error message into exception https://review.opendev.org/c/openstack/nova/+/828186 | 20:09 |
| opendevreview | melanie witt proposed openstack/nova master: Raise InstanceNotFound on fkey constraint fail saving info cache https://review.opendev.org/c/openstack/nova/+/826942 | 20:12 |
| *** dasm is now known as dasm|off | 22:43 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
