| opendevreview | Callum Dickinson proposed openstack/nova master: Add image meta to libvirt XML metadata https://review.opendev.org/c/openstack/nova/+/942766 | 05:05 |
|---|---|---|
| *** ralonsoh_ is now known as ralonsoh | 07:04 | |
| sean-k-mooney | melwitt: would you mind readding your +2 adn approving https://review.opendev.org/c/openstack/nova/+/939411/10 the only differnce since you last reviewd was the addtion of a release note | 11:15 |
| sean-k-mooney | bauzas: this ^ was a regression breaking rebuild last cycle so we will have to backport it anyway but still nice ot have before rc1 | 11:16 |
| opendevreview | Merged openstack/nova master: libvirt: fix maxphysaddr passthrough dom parsing https://review.opendev.org/c/openstack/nova/+/942371 | 12:13 |
| opendevreview | Yaguang Tang proposed openstack/nova stable/2024.2: Fix device type when booting from ISO image https://review.opendev.org/c/openstack/nova/+/943924 | 12:16 |
| bauzas | sean-k-mooney: ack, stephenfin already sent it to the gate fwiw | 13:19 |
| bauzas | sean-k-mooney: I started a new etherpad for rc tracking https://etherpad.opendev.org/p/nova-epoxy-rc-potential | 13:19 |
| bauzas | sean-k-mooney: you can as usual add some changes if you think those are important before RC1 in the right section 'bugfixes requiring attention before RC1' | 13:20 |
| sean-k-mooney | bauzas: ack, this is/was a latent issue form the ironic leeasee serise so not super urgent. i.e. if it missed rc 1 it woul dnot be a new regression intoduced in epoxy, just nice to have sooner rtahter then later | 13:32 |
| sean-k-mooney | stephenfin: thanks for reviewing :) | 13:33 |
| sean-k-mooney | bauzas: as it stand im not really aware of anyting super urgent for RC1 outside of the mechanical patches we do every release | 13:33 |
| opendevreview | Merged openstack/nova master: api: project/tenant and user IDs are not UUIDs https://review.opendev.org/c/openstack/nova/+/940369 | 13:46 |
| opendevreview | Merged openstack/nova master: api: Address TODO in microversion v2.99 https://review.opendev.org/c/openstack/nova/+/943253 | 13:46 |
| opendevreview | Yaguang Tang proposed openstack/nova stable/2024.2: Handle iso+gpt detections https://review.opendev.org/c/openstack/nova/+/943940 | 13:54 |
| opendevreview | Merged openstack/nova master: Fix parameter order in add_instance_info_to_node https://review.opendev.org/c/openstack/nova/+/939411 | 14:09 |
| gibi | dansmith: o/ regarding https://review.opendev.org/c/openstack/nova/+/943816/1/nova/compute/pci_placement_translator.py | 14:10 |
| gibi | that palce exists in the pci in placement code to implement missing allocation healing and not intended to remain there for ever. It is more like a transitional code to support upgrade and gradual enablement of the featureh | 14:11 |
| dansmith | orly, okay | 14:11 |
| gibi | in general pci allocation should only happen during scheduling in the scheduler / conductor. | 14:11 |
| gibi | this allocation healing is like the old healing periodic when we introduced placement | 14:12 |
| gibi | 5+ years ago | 14:12 |
| dansmith | right, well, this is not really allocation and I think the consensus (me, sean, sylvain) is that the reservation should be in the compute node | 14:12 |
| gibi | I think you ended up looking at this code as friday in your env the allocation happened in this code | 14:12 |
| gibi | yeah I know that your code is not allocation | 14:12 |
| dansmith | but yeah I traced the placement update stuff looking for a good place to do it and this looked perfect :) | 14:12 |
| gibi | but the code path seem to only exists for allocation | 14:12 |
| gibi | so far | 14:12 |
| dansmith | I had originally written my own inventory update in the RT | 14:13 |
| dansmith | so I can go back to that approach, which it sounds like would be better so this healing can be ripped out later yeah? | 14:13 |
| gibi | I might be mistake. I have to dig a bit deeper where we do the actual inventory reporting of PCI in placement | 14:13 |
| gibi | https://github.com/openstack/nova/blob/5f3133efc04dde15d64679e1e7564d2e575549db/nova/compute/resource_tracker.py#L1325-L1342 | 14:14 |
| dansmith | okay, tbh, this looked like it was intended to be permanent.. it seems related to making sure placement inventory gets healed if our resources ever changed | 14:14 |
| gibi | I'm reacting based on this comment | 14:14 |
| dansmith | okay, so the rest of update_to_placement() seems to intent to stay there long-term right? | 14:15 |
| dansmith | you're just thinking the pci part is not permanent? | 14:16 |
| gibi | https://github.com/openstack/nova/blob/5f3133efc04dde15d64679e1e7564d2e575549db/nova/compute/pci_placement_translator.py#L554-L556 OK this says both inventory and allocation handling so maybe this is both at the moment and then it means it will remain the same | 14:16 |
| dansmith | right, it's doing both | 14:16 |
| dansmith | gibi: this is the "don't do it here because..." feedback I wanted before going further, but if you need to dig in deeper, feel free to punt until you have time to do proper thinking | 14:17 |
| gibi | in short, there is allocation healing in that code path which will go away. There is inventory generation there which remains there. So extending the inventory generation with this feature might be OK. | 14:20 |
| gibi | so maybe it is OK | 14:20 |
| dansmith | okay | 14:20 |
| gibi | independenty I'm not sure how racy this is with the pci_claim | 14:20 |
| dansmith | the pci claim on the compute node happens before this | 14:21 |
| gibi | if this happens independently from the pci_claim in the periodic then we have a race window | 14:21 |
| dansmith | the benefit here is that if you mark a device as OTU after it has already been allocated to an instance, it will be "healed" to reserved state | 14:21 |
| dansmith | s/the/a benefit/ | 14:21 |
| gibi | I see | 14:21 |
| dansmith | I'm not sure what race you mean, | 14:21 |
| dansmith | there's a small window where we could fail before we do the reserve, but if that happens, the instance will not boot | 14:22 |
| dansmith | so it's safe and the window is very small | 14:22 |
| dansmith | I don't think there's a race | 14:22 |
| dansmith | this happens synchronously at the end of the instance_claim() method | 14:22 |
| dansmith | (*and* in the periodic) | 14:22 |
| gibi | I mean the pci claim claims an OTU device and returns to the compute manager spawn a VM and a periodic update_available_resouces runs after a while and sees the allocated OTU device and reserve it | 14:22 |
| dansmith | no, | 14:23 |
| dansmith | it happens synchronously | 14:23 |
| gibi | if this happens in the same code path as the claim then cool | 14:23 |
| dansmith | this doesn't depend on the periodic running before it's reserved | 14:23 |
| gibi | OK | 14:23 |
| gibi | that was basically my second question | 14:23 |
| dansmith | runs right here in instance_claim() https://github.com/openstack/nova/blob/276685b3db6e8f2ad59c33bc254461c255700ff8/nova/compute/resource_tracker.py#L215 | 14:23 |
| dansmith | that _update() all calls the _update_to_placement() as its first thing, which your first link above | 14:24 |
| sean-k-mooney | dansmith from my perspective anything after self.pci_tracker.claim_instance in that function is ok, that is the earise that doing the reserved=total make sense | 14:25 |
| dansmith | if that all seems reasonable now, I can document all the above details in the spec more thoroughly so that review is easier | 14:25 |
| dansmith | sean-k-mooney: cool | 14:26 |
| sean-k-mooney | althought there are ways we can fail later so it could be later | 14:26 |
| gibi | dansmith: OK I see it now, no race | 14:26 |
| dansmith | sean-k-mooney: I think there's always going to be some compromise, but it seems like when we're doing the pci accounting is the right balance to me | 14:26 |
| sean-k-mooney | dansmith: so what your propsoing i think will work for spawn and unshleve and evacuate | 14:30 |
| sean-k-mooney | i suspect self._update is reusted for cold migration/resize | 14:30 |
| sean-k-mooney | ya it is here https://github.com/openstack/nova/blob/276685b3db6e8f2ad59c33bc254461c255700ff8/nova/compute/resource_tracker.py#L378 | 14:30 |
| sean-k-mooney | so i think that is fine too | 14:31 |
| sean-k-mooney | live migration is out os scope for this this cycle? | 14:31 |
| sean-k-mooney | live migration does use a move claim but the claiming of the device in the nova db happens a littel earlier | 14:33 |
| sean-k-mooney | i think its fine to still do the reserved=total in the same place, im just asking for the scope fo testing/support | 14:34 |
| dansmith | I'll track down the live case, but yeah the cold move case is also good | 14:34 |
| sean-k-mooney | so for cold migration i think we just need to document that the device is burned once we have got to verify_resize | 14:35 |
| dansmith | I think I'm fine with live being out of scope here, especially since we can mark a device as live_migratable=false now, but there's no reason this shouldn't work the same I think, even if we have to do it in a slightly different place on the dest | 14:35 |
| dansmith | sean-k-mooney: yeah once you've touched both devices on either end, both are burned :) | 14:35 |
| sean-k-mooney | exactly, some opt might assuem that happens at confirm | 14:36 |
| sean-k-mooney | so we just need to document that | 14:36 |
| opendevreview | Merged openstack/nova master: Update conductor and filters allowing migration with SR-IOV devices https://review.opendev.org/c/openstack/nova/+/942146 | 14:36 |
| dansmith | sure | 14:37 |
| gibi | dansmith: yeah by default flavor based PCI devices are not live migratable, only exception is via the recently added live_migratable flag in the dev_spec and alias but we don't expect that will be set for OTU devices | 14:40 |
| dansmith | oh, okay well, that's even easier I guess | 14:40 |
| sean-k-mooney | ya the default helps | 14:41 |
| gibi | only neutron based PCI devs are live migrated by default via unplug and plug | 14:41 |
| sean-k-mooney | right but we dont support them in placment yet | 14:41 |
| gibi | yes | 14:41 |
| sean-k-mooney | so we can also ignor them | 14:41 |
| gibi | yes | 14:41 |
| sean-k-mooney | we could add a check | 14:41 |
| sean-k-mooney | that you dont set otu and physical_network | 14:41 |
| sean-k-mooney | since we know thats invalid today | 14:41 |
| sean-k-mooney | but its not strictly required | 14:42 |
| opendevreview | Gaudenz Steinlin proposed openstack/nova master: Make SSH compression for remote copy configurable https://review.opendev.org/c/openstack/nova/+/943377 | 14:42 |
| dansmith | Okay well, I'll add some notes to the spec for this to cover the above details | 14:44 |
| opendevreview | Sylvain Bauza proposed openstack/nova master: doc: mark the maximum microversion for 2025.1 Epoxy https://review.opendev.org/c/openstack/nova/+/943948 | 15:06 |
| opendevreview | Dan Smith proposed openstack/nova-specs master: Add one-time-use-devices spec https://review.opendev.org/c/openstack/nova-specs/+/943486 | 15:10 |
| gibi | dansmith: left couple of comments but I think the direction looks good | 15:11 |
| dansmith | gibi: thanks! | 15:11 |
| gibi | the only think I'm a bit hesitant about it is the long term effect of the decision that we go with placement to solve this while and therefore we are forced not to support OTU VFs. | 15:12 |
| dansmith | gibi: tbh, I'm not really sure when VFs would need to use this, as I suspect any virt-knowing device would be sensitive to exposure between uses (perhaps not) | 15:13 |
| dansmith | that said, I think that from the operator point of view, it doesn't necessarily matter that it's happening in placement (other than the steps to unreserve after cleaning I guess).. but the devspec wouldn't need to change if we started accounting for the one-time-use in, say, PCI tracker | 15:14 |
| gibi | yeah that is a valid point. This is why I'm not against going with the placement route, just hesitant that our udnerstanding of SRIOV VFs are correct | 15:14 |
| gibi | dansmith: yeah the unreserve is the problematic step if we go with the PCI tracker route | 15:14 |
| dansmith | right | 15:14 |
| gibi | nova has no API for that | 15:15 |
| dansmith | an SRIOV NIC is safe for use without cleaning, because you can't update firmware I think | 15:15 |
| dansmith | not sure about a VGPU and memory exposure I guess, but .. they have to know that the point of that is sharing, so I would expect it's okay | 15:15 |
| gibi | I also think that, but I never checked what happens with GPU VFs or NVMe VFs | 15:15 |
| dansmith | an SRIOV NVMe would be a problem I guess, but if you're de- and re-allocating them they should be safe (like new namespaces on a regular one) | 15:16 |
| gibi | true, if the VF is mapped to a namespace then it is OK | 15:17 |
| dansmith | yeah | 15:17 |
| gibi | OK. I'm less hesitant now. We have good reasons to believe that this feature is not needed for VFs | 15:17 |
| gibi | a sane VF implementor needs to handle the sharing issue | 15:17 |
| dansmith | I think we just make sure it's clear in the doc that this is only for whole devices because they're not virt-aware, and we can also say "for more comprehensive situations you need cyborg anyway" :) | 15:17 |
| dansmith | yeah | 15:17 |
| gibi | OK | 15:18 |
| gibi | and :) for cyborg as a fallback | 15:18 |
| dansmith | I really don't want to blur the line of nova-vs-cyborg much, so I think keeping this limited to specific uses is helpful to avoid people trying to push nova to do more | 15:19 |
| opendevreview | Sylvain Bauza proposed openstack/nova master: Update compute rpc alias for epoxy https://review.opendev.org/c/openstack/nova/+/943952 | 15:19 |
| sean-k-mooney | dansmith: gibi you cant update teh frimware vai the vf from an nic i have worked with | 15:19 |
| dansmith | right | 15:20 |
| sean-k-mooney | dansmith: you can flash ab bitrstream via a specific VF on an fpga that change the behvior of other VFs | 15:20 |
| sean-k-mooney | but that a very different usecasue | 15:20 |
| sean-k-mooney | to me that is not what you are creating this for | 15:20 |
| dansmith | definitely not | 15:20 |
| sean-k-mooney | if we add pci groups in the future | 15:20 |
| sean-k-mooney | we could extend the concpet to the group | 15:21 |
| sean-k-mooney | i.e. a one time group | 15:21 |
| dansmith | tbh, the pci-in-placement approach seems to me to be a bit of a stretch of the model, since placement really assumes resources of a given class are fungible and does not track actual assignment | 15:21 |
| sean-k-mooney | dansmith: well in general tehy are fungible | 15:22 |
| dansmith | so anything specific to a given VF probably needs a new model and new API (which cyborg is well-positioned to handle, IMHO) | 15:22 |
| dansmith | sean-k-mooney: VFs are, but not whole PCI devices | 15:22 |
| sean-k-mooney | maybe you could argue it either way | 15:23 |
| sean-k-mooney | i get where your coming form | 15:23 |
| dansmith | the fact that we have a custom resource type for each device, even if its identical to another, with a total=1 is, I think, the stretch of the model | 15:23 |
| sean-k-mooney | on the cyborg side do we watn to reach out to them during the ptg on any of these topics? | 15:23 |
| dansmith | we're calling two devices that are identical but have different PCI addresses "different" :) | 15:24 |
| gibi | yeah we made the assumption in PCI in Placement that the same RC inventory on an RP means fungible devices | 15:24 |
| sean-k-mooney | dansmith: we are not | 15:24 |
| sean-k-mooney | they have the saem resouce class if they have the same vendor_id and product id | 15:24 |
| gibi | and we opted in to represent a PF as RC=1 while VFs as RC=N | 15:24 |
| sean-k-mooney | the reason they are diffent RPs is because fo VFs | 15:25 |
| gibi | two RPs with the same RC=1 inventory are non fungible due to the RP name encoding the PCI address | 15:25 |
| dansmith | sean-k-mooney: okay, sorry, terminology.. same resource class, but separate providers.. | 15:25 |
| dansmith | right ^ | 15:25 |
| sean-k-mooney | gibi: yep and that because of other factors like numa or phsynet associativity | 15:26 |
| sean-k-mooney | as it stands to day we could have an invetlory of PFs directly off the compute RP | 15:26 |
| gibi | yeah exactly numa and physnet granurality is also aligned with that | 15:26 |
| sean-k-mooney | the reason we dont was to allow numa and physnets to be modleed in the future | 15:27 |
| dansmith | I guess it's not unlike if we had two storage providers on a host that you can't just arbitrarily sum together.. however, the inventory within those are still fungible, but it's not within a PCI provider, hence the only one inventory | 15:27 |
| sean-k-mooney | we only need 1 RP per device in the VF case today | 15:27 |
| sean-k-mooney | dansmith: we could in some cases coalese multipel PCI invetories into one provider | 15:28 |
| sean-k-mooney | it just seamed harder to have it sometiems on the root provider and sometimes on its own | 15:29 |
| sean-k-mooney | depending on what you set in the devspec | 15:29 |
| dansmith | sean-k-mooney: I'm just saying, I think we're bordering on breaking/abusing the model... it still fits nicely, but only just | 15:29 |
| sean-k-mooney | and what we discoverd (vendor/product id) | 15:29 |
| dansmith | and tbc, I'm not complaining :) | 15:30 |
| sean-k-mooney | dansmith: to b efair we have a design for numa in palcment and neutorn port in placment | 15:30 |
| sean-k-mooney | im also hesitant to proceed with the numa part for similar reasons | 15:30 |
| sean-k-mooney | i think part of the orginal selling point for palcemetn (moveing all or almost all the schduling work to it) didnt really pan out | 15:31 |
| sean-k-mooney | if we are beign pargmatic and say the nova schduler will always be needed to do find grained choices liek numa | 15:31 |
| dansmith | I have no mental space to consider that now, but a numa node with fungible inventory inside is a closer fit to the original goal I think | 15:31 |
| sean-k-mooney | then there is an argrument to say palcment should never know about it | 15:31 |
| sean-k-mooney | it being numa | 15:32 |
| sean-k-mooney | ack lets leave it there for now | 15:32 |
| dansmith | I wonder if we could introduce another data type to placement that represents actual physical allocations where needed | 15:32 |
| sean-k-mooney | maybe | 15:32 |
| dansmith | something that ties an allocation uuid to that other thing that represents an actual thing with an address | 15:32 |
| sean-k-mooney | im happy to disucss that at some point just also dont have the brain power to context switch to this in detail right now | 15:33 |
| gibi | lets add more metadata :) | 15:33 |
| dansmith | memory has no address or serial number, but a pci device does, a disk might | 15:33 |
| sean-k-mooney | memory kind of does | 15:33 |
| dansmith | gibi: it would only be good if we can drop something else in favor, of course :) | 15:33 |
| sean-k-mooney | its at least got a numa node | 15:33 |
| sean-k-mooney | it might not be a unique idetifier across all host | 15:34 |
| sean-k-mooney | but there are ways to talk about fungible pools of it | 15:34 |
| dansmith | sean-k-mooney: if the numa node is a nested provider, then the allocation within has no (further) addressing | 15:34 |
| dansmith | right | 15:34 |
| dansmith | anyway, we're way off in the weeds, didn't mean to start digging a hole | 15:34 |
| sean-k-mooney | https://collection.nam.ac.uk/images/960/204000-204999/204324.jpg | 15:35 |
| dansmith | heh yeah | 15:36 |
| sean-k-mooney | thats not actuly the meme i was loogkign for but it will do | 15:36 |
| gibi | :) | 15:36 |
| bauzas | folks I just saw your discussion, will review again dansmith's spec tomorrow | 15:50 |
| opendevreview | Masahito Muroi proposed openstack/nova master: Use dict object for request_specs_dict in the _list_view https://review.opendev.org/c/openstack/nova/+/939658 | 16:52 |
| masahito | sean-k-mooney: gibi: please review this api bug fix again https://review.opendev.org/c/openstack/nova/+/939658 thank you. | 16:54 |
| gmann | sean-k-mooney: do you remember the some missing package for pcre.h in bindep.txt for doc job running on noble. this one https://review.opendev.org/c/openstack/nova/+/935577 | 18:25 |
| sean-k-mooney | yes | 18:25 |
| sean-k-mooney | didnt htat go away? | 18:25 |
| sean-k-mooney | or is that still a thing | 18:25 |
| gmann | sean-k-mooney: no, I tired some but still error | 18:25 |
| sean-k-mooney | what job was failing | 18:26 |
| gmann | libpcre3-dev should include it but that is already in bindep file | 18:26 |
| sean-k-mooney | docs and apiref it seams | 18:26 |
| sean-k-mooney | i thinki have noble somewhere | 18:26 |
| gmann | openstack-tox-docs this one https://zuul.opendev.org/t/openstack/build/a1a1fbda6cf24246a3ed9912c5e952b3 | 18:26 |
| gmann | yeah | 18:26 |
| gmann | I am not able to produce it locally I think I installed some extra package there | 18:27 |
| sean-k-mooney | if you install devstack on the know it fixes the porblem if i recall | 18:28 |
| sean-k-mooney | im runnign the docs target localy now | 18:29 |
| sean-k-mooney | ill check where that header came form after | 18:29 |
| sean-k-mooney | gmann: oh you kno what it might be that if you have to build the wheel form source it fails but if you can get it form the wheel cache ti works | 18:31 |
| sean-k-mooney | the ci job is trying to build the wheel for python-pcre | 18:31 |
| gmann | yeah | 18:34 |
| sean-k-mooney | ubuntu@sean-devstack-watcher-1:~/repos/nova-docs$ find /usr -name "pcre.h" | 18:36 |
| sean-k-mooney | /usr/include/pcre.h | 18:36 |
| sean-k-mooney | ubuntu@sean-devstack-watcher-1:~/repos/nova-docs$ apt-file search /usr/include/pcre.h | 18:36 |
| sean-k-mooney | libpcre3-dev: /usr/include/pcre.h | 18:37 |
| sean-k-mooney | gmann: so no noble https://review.opendev.org/c/openstack/nova/+/935577/3/bindep.txt is not correct | 18:37 |
| sean-k-mooney | line 53 should be all that is required | 18:37 |
| sean-k-mooney | libpcre3-dev [platform:dpkg test] | 18:37 |
| gmann | yeah, libpcre3-dev should be enough but it is not finding it when building wheel for python-pcre | 18:39 |
| sean-k-mooney | i can try doing it in a clean vm and see what happens | 18:39 |
| gmann | or you can see PS2 test run and it fails there too https://review.opendev.org/c/openstack/nova/+/935577/2 | 18:40 |
| gmann | but log expire there | 18:40 |
| gmann | expired | 18:40 |
| gmann | oh, its there https://zuul.opendev.org/t/openstack/build/5ddcd6d9f0a94008a722346992cf499b | 18:40 |
| sean-k-mooney | ya so this sound like somethign to do with the build chain | 18:42 |
| sean-k-mooney | and by that i mean how the toll chain is set up in the vm | 18:42 |
| sean-k-mooney | like its missing one of the devel packages like make or something is missing | 18:43 |
| sean-k-mooney | i dont think this is it but one thing i do notice is i have a slightly old verion of virutal env locally then it used in the failed buil | 18:47 |
| sean-k-mooney | virtualenv = 20.26.3 locally | 18:47 |
| sean-k-mooney | gmann: so not a clean vm but https://paste.opendev.org/show/bv240D3BK3XVEKBywbMN/ | 18:58 |
| sean-k-mooney | if i disable using all binaireas and force a build it definly works | 18:58 |
| sean-k-mooney | gmann: ok i create a clean ubuntu vm on our internal cloud. im gong to confirm pcre.h is not pre installed in the image and then only install the bindep package with the test profile | 19:04 |
| sean-k-mooney | and ill see if mater doc target fail or not | 19:04 |
| sean-k-mooney | ... cloning nova is painful aat 500KiB/s | 19:06 |
| sean-k-mooney | gmann: so this is what im going to install | 19:12 |
| sean-k-mooney | .venv) ubuntu@sean-upstream-docs:~/nova$ bindep -b test | nc termbin.com 9999 | 19:12 |
| sean-k-mooney | https://termbin.com/hrrp | 19:12 |
| sean-k-mooney | that is for master | 19:12 |
| sean-k-mooney | i guess i should also include the docs target | 19:12 |
| sean-k-mooney | gmann: so locally that works for me on a clean vm | 19:23 |
| sean-k-mooney | gmann: what i did was as followes | 19:23 |
| sean-k-mooney | sudo apt install python3.12-venv | 19:23 |
| sean-k-mooney | python3 -m venv .venv | 19:24 |
| sean-k-mooney | actully ill past it | 19:24 |
| sean-k-mooney | https://paste.opendev.org/show/bq494eyZBhcRJTR1ATEm/ | 19:25 |
| sean-k-mooney | this seams to be somethign either specific to the ci vms or to the playbooks we are using to do this in ci | 19:27 |
| gmann | yeah, it seems so. something wit editable install with pyproject.toml ? but not sure | 19:29 |
| opendevreview | Ghanshyam proposed openstack/nova master: Testing doc job on Ubuntu Noble https://review.opendev.org/c/openstack/nova/+/935577 | 19:29 |
| opendevreview | Merged openstack/nova master: Update libvirt fixtures to support hostdevs https://review.opendev.org/c/openstack/nova/+/943207 | 20:12 |
| opendevreview | Merged openstack/nova master: Update driver to map the targeted address for SR-IOV PCI devices https://review.opendev.org/c/openstack/nova/+/942147 | 20:20 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
