*** Guest0 is now known as prometheanfire | 00:29 | |
opendevreview | Wenping Song proposed openstack/os-traits master: Update python testing as per zed cycle testing runtime https://review.opendev.org/c/openstack/os-traits/+/841682 | 07:04 |
---|---|---|
*** lajoskatona_ is now known as lajoskatona | 07:42 | |
*** songwenping__ is now known as songwenping | 08:00 | |
opendevreview | Wenping Song proposed openstack/placement master: Update python testing as per zed cycle testing runtime https://review.opendev.org/c/openstack/placement/+/841690 | 08:42 |
opendevreview | Wenping Song proposed openstack/placement master: Update python testing as per zed cycle testing runtime https://review.opendev.org/c/openstack/placement/+/841690 | 08:42 |
opendevreview | Wenping Song proposed openstack/os-resource-classes master: Update python testing as per zed cycle testing runtime https://review.opendev.org/c/openstack/os-resource-classes/+/841700 | 09:20 |
opendevreview | Wenping Song proposed openstack/os-resource-classes master: Update python testing as per zed cycle testing runtime https://review.opendev.org/c/openstack/os-resource-classes/+/841700 | 09:46 |
sean-k-mooney | ricolin: +1 on the spec | 10:12 |
sean-k-mooney | ricolin: i have resotred the mlock patch too so feel free to updated it | 10:12 |
ricolin | thanks sean-k-mooney :) | 10:12 |
sean-k-mooney | ricolin: if you adress the extra spec name im baicly +2 ill read over it again when you respin but no rush | 10:15 |
opendevreview | Rico Lin proposed openstack/nova-specs master: Add vIOMMU device support for libvirt driver https://review.opendev.org/c/openstack/nova-specs/+/840310 | 10:24 |
ricolin | sean-k-mooney: done ^^^ :) | 10:25 |
sean-k-mooney | +2 :) am milestone 1 i think is thursday. assuming gibi or others approve the spec can you submit the patch to os-traits to add the traits | 10:28 |
sean-k-mooney | if we merge that before tursday then the traits can be included in the m1 relases of os-traits | 10:28 |
sean-k-mooney | nova's unit tests need the traits to be in a release version of os-traits to pass if its not merge by then its not really a big deal we will just do another release whenever they land and the nova code look good to merge | 10:30 |
stephenfin | sean-k-mooney: gibi: melwitt: Reviewed that PCI in placement spec. Looks pretty good, though I'm convinced you're making an unnecessary rod for your own back in trying to port that dynamic PF/VF logic to placement land ;-) | 10:51 |
sean-k-mooney | stephenfin: ya it is complicating things | 11:00 |
sean-k-mooney | stephenfin: that use case is really only for sriov nics | 11:01 |
sean-k-mooney | as in for neuton ports | 11:01 |
sean-k-mooney | i dont think it really exists for pci alias | 11:01 |
sean-k-mooney | so we can kind of punt. technialy it applise to the alias too but i dont think that is a common usecase there | 11:02 |
sean-k-mooney | stephenfin: you might want to look over ricolin's spec for the viommu support | 11:02 |
sean-k-mooney | its pretty short | 11:02 |
sean-k-mooney | https://review.opendev.org/c/openstack/nova-specs/+/840310 | 11:03 |
stephenfin | sure | 11:04 |
gibi | stephenfin: so you suggest that deciding to whitelist either the PF or its VFs are rarely used? I think the opposite. It is so easy to just whitelist everthing under 0000:81:* both PF and VF, without thingking to much, and then start using the compute for both direct and direct-physical ports, it just works, so I think there is a lot of deployment out there that might not need to whitelist both but | 11:06 |
gibi | they did | 11:06 |
gibi | if we start rejecting such config there will be a lot of pain figuring out a whitelist in these deployments that matches the current consumption | 11:07 |
sean-k-mooney | im not sure really. im tempted to say perhaps we sould only support that if you are not trackign devices in placment | 11:08 |
sean-k-mooney | and in the mvp implement supprot for only tracking deivces as PFs or VFs | 11:08 |
sean-k-mooney | and then we could add the mixed suport after if needed | 11:09 |
stephenfin | No, I'm suggesting people wanting to use both 'direct' and 'direct-physical' on a single host is likely rare. I think it's reasonable to insist that users that use wildcard device addresses (or vendor/device IDs) choose whether they want to consume the VFs or PFs | 11:09 |
sean-k-mooney | stephenfin: well your suggestiong they make that dissionc staticaly at deployment time | 11:09 |
stephenfin | At the moment, a user can dynamically choose whether they consume the PF or one or more of the VFs. I think moving to a static model makes sense now | 11:09 |
stephenfin | Yup | 11:09 |
sean-k-mooney | rather then dynmical as workloads are schulded | 11:10 |
stephenfin | exactly | 11:10 |
sean-k-mooney | i think pf passhtough is much less common then vf | 11:10 |
gibi | I have no problems forcing this to new deployments, but I still believe upgrade will be a pain | 11:10 |
stephenfin | *borderline non-existent (I say, with no actual evidence either way :) However, it seems like an odd thing to do, especially when we don't support nested virt) | 11:11 |
gibi | but yeah, we can push out the pain to the future by keepin the pci tracking in placement optional | 11:11 |
sean-k-mooney | stephenfin: well my evidence is that live migrtation, cold migration and unshelve have basicaly been broken since the feature was added until like 2 cylces ago | 11:11 |
stephenfin | I mean, it's been more than three years and people can still avoid tracking of pinned CPUs in placement | 11:11 |
stephenfin | so that can can be kicked endlessly down the road | 11:12 |
sean-k-mooney | so while i know we have some customer using PFs those custoemr also have static deployments | 11:12 |
sean-k-mooney | gibi: i guess its really up to you | 11:13 |
sean-k-mooney | if you want to include it in the mvp | 11:13 |
gibi | OK, I see an agreement forming. Let's implement PCI tracking with placement without the dynamic selection. Keep the everything working as today if the PCI tracking in placement is disabled | 11:13 |
sean-k-mooney | i think it could be a patch at the end of the seirse by the way | 11:13 |
sean-k-mooney | gibi: sound good to me that means the prefilter will not have an auto mode | 11:14 |
gibi | then when everythin (except the dynamic thing works with placemnet) deprecate the old way | 11:14 |
gibi | and wait for feedback | 11:14 |
gibi | yeah that means no auto mode | 11:15 |
sean-k-mooney | you will opt in on the compute with the new config option and opt in on schduler by enabling prefilter | 11:15 |
gibi | operator needs to first enable tracking in the compute config | 11:15 |
gibi | then enable prefiltering in the scheduler | 11:15 |
sean-k-mooney | yep | 11:15 |
gibi | and if somebody only opt in on a set of computes then enables the prefilter then we say sorry you lost the non enabled computes from the PCI scheduling | 11:16 |
stephenfin | I think lack of auto mode is a good thing. I called that out in the review as something weird (and I think melwitt had similar concerns) | 11:16 |
stephenfin | The less magic, the better | 11:16 |
sean-k-mooney | ack its nice form an opts perspectvie if an only if it means they dont have to do anything on upgrade | 11:17 |
stephenfin | sean-k-mooney: woah, that vIOMMU thing has got way bigger. I was proposing enabling by default on supported platforms with zero configurability. We now have...three knobs? :-O | 11:17 |
stephenfin | I've asked ricolin to clarify the need for each knob since it's not at all obvious from reading the spec. If they're really necessary, we'll need this info to document the extra specs. | 11:18 |
gibi | upgrading to Zed (if it lands) with default config will mean only the old PCI scheduling will be used by nova. So no real upgrade impact. Then operators needs to enable the new tracking | 11:18 |
sean-k-mooney | stephenfin: yep. the model, bit with which i dont like exposing but is required and locked memroy wich is technialy unrealted | 11:18 |
sean-k-mooney | but they need locked memroy for there specific hardware and you can only get that with realtim or sev today | 11:19 |
sean-k-mooney | gibi: yep with no config changes old behavior | 11:19 |
gibi | so we need to incentivise ops to enable the new behavior | 11:19 |
stephenfin | At risk of pre-empting discussion on the spec, why is the model necessary? Are these guest OS behavior implications or something? Is there not a sane default we can pick? | 11:20 |
sean-k-mooney | so no upgrade impact by defualt but we will ahve to document how to move form one to the other | 11:20 |
sean-k-mooney | stephenfin: the sane default would be virtio but it need a very new libvirt/qemu | 11:20 |
sean-k-mooney | we cant use intel because well there usecase is for aarch64 servers | 11:21 |
sean-k-mooney | we could choose dynmically i guess | 11:21 |
* gibi gets something to eat then sit down and update the PCI spec | 11:21 | |
stephenfin | And I'm guessing we can't check what the libvirt version is and use 'virtio' if libvirt > 8.3.0 else 'intel'/'smmuv3' for Intel/ARM respectively? | 11:21 |
sean-k-mooney | based on the machine-type but i dont like the live migration implciations of that | 11:21 |
stephenfin | So long as we record the model used in system metadata, we should be fine | 11:22 |
sean-k-mooney | well we could but ya | 11:22 |
stephenfin | (i.e. so we don't change during rebuild) | 11:22 |
stephenfin | *migration | 11:22 |
sean-k-mooney | record in system_metadta or elsewhere for migration | 11:22 |
stephenfin | Yup | 11:22 |
sean-k-mooney | i was hoping we woudl only expose the model extra spec initally | 11:22 |
stephenfin | In case it's not obvious, I hate exposing knobs unless they're really useful. If people want all the knobs, use libvirt/oVirt :) | 11:22 |
sean-k-mooney | yep i know it had 6 i think at one point | 11:23 |
sean-k-mooney | i have been slowing getting it down to the minimal set | 11:23 |
stephenfin | what about aw_bits? | 11:25 |
sean-k-mooney | stephenfin: by the way im not sure if we can just turn the viommu on always or if there are performance overhead even if you dont explicty try to use it for say realtime guests | 11:25 |
sean-k-mooney | stephenfin: that i really did not want to expose | 11:26 |
sean-k-mooney | stephenfin: mnaser left a comment about why they needed it i dont knwo if we can always set it to the max support or if it need to be tuneable | 11:26 |
sean-k-mooney | actully it was on irc let me see if i can find it | 11:29 |
sean-k-mooney | stephenfin: i actully tought you exposed that in your patch by the way | 11:31 |
sean-k-mooney | the aw_bit | 11:31 |
stephenfin | Nope https://review.opendev.org/c/openstack/nova/+/830646/1/nova/virt/libvirt/config.py#3676 | 11:31 |
sean-k-mooney | oh so ricolin added it | 11:32 |
sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/830646/5/nova/virt/libvirt/config.py#3700= | 11:33 |
sean-k-mooney | ah you just found it | 11:33 |
sean-k-mooney | stephenfin: so if this really is needed i woudl liek to tie its value to the vm. | 11:34 |
sean-k-mooney | stephenfin: so either in instance_system_metadta | 11:34 |
sean-k-mooney | or as a flavor/image property | 11:34 |
sean-k-mooney | if it was a per host option we would have to schdule on it some how | 11:34 |
sean-k-mooney | and possible extend the migration data objects if we did not store it in the instace_system_metadata | 11:35 |
stephenfin | Yeah, no arguments from me there. Host-level configuration for guest-specific knobs is always a problem | 11:35 |
sean-k-mooney | i was hoping we could jsut not set it and let it up ot libvirt | 11:35 |
stephenfin | me too | 11:37 |
sean-k-mooney | """Use virtio if libvirt >= 8.5.0, else intel or the aarch64 equivalent""" hehe i can say the aarch64 equivalent so i cant rememeber it either | 11:38 |
sean-k-mooney | stephenfin: since i have your attention do you have any feedback on https://review.opendev.org/c/openstack/oslo-specs/+/839819 im trying to poc it now | 11:39 |
stephenfin | Sure | 11:40 |
* sean-k-mooney spent 4 hours yesterday fixing emac. i fixed it by deleting my config directory and cloning int again... | 11:40 | |
stephenfin | I think I know what the problem is there already 🙃 | 11:41 |
sean-k-mooney | your right i should have stuck with nano | 11:42 |
sean-k-mooney | actully the problem was it was sudenly in vim mode i think | 11:42 |
stephenfin | touché | 11:42 |
sean-k-mooney | i use the spacemecs deistribution which has the evil plugin | 11:42 |
sean-k-mooney | which by default make it have vim key bindings | 11:42 |
sean-k-mooney | so for some reason i coudl not use any of the ones im use to or select text | 11:43 |
sean-k-mooney | anyway its back to working in emacs/nano like mode and i can use it again but that was not fun | 11:44 |
stephenfin | gibi: sean-k-mooney: I think this is ready to merge now https://review.opendev.org/c/openstack/nova/+/839029 | 12:24 |
stephenfin | also, it passes 🎉 | 12:24 |
gibi | stephenfin: yepp, +2 | 12:25 |
sean-k-mooney | oh cool let me run it locally first since i have 3.10 and then ill +w | 12:26 |
sean-k-mooney | stephenfin: i could have sworne i made the fucntional evne generitive at some point | 12:29 |
stephenfin | you did, but it hasn't merged. I stole that idea sorrynotsorry :) | 12:29 |
sean-k-mooney | oh i tought that merged ages ago | 12:30 |
sean-k-mooney | i guess i should take a look at that again | 12:30 |
sean-k-mooney | cool your patch is running locally | 12:30 |
sean-k-mooney | there are a bunch of deprecations warnings | 12:31 |
stephenfin | 3.10 specific? | 12:31 |
sean-k-mooney | home/sean/repos/openstack/nova-3/nova/tests/fixtures/notifications.py:42: DeprecationWarning: notifyAll() is deprecated, use notify_all() instead | 12:31 |
sean-k-mooney | self._cond.notifyAll() | 12:31 |
stephenfin | I know distutils is puking everywhere since that's going away in 3.12 | 12:32 |
sean-k-mooney | stephenfin: so yes i think that is 3.10 related | 12:32 |
sean-k-mooney | it seams to just be that actully | 12:32 |
sean-k-mooney | but its multiple times on every test | 12:32 |
sean-k-mooney | ok not every test | 12:34 |
sean-k-mooney | https://zuul.opendev.org/t/openstack/build/8a45e04d9dbf4703bb1fb9f7d91a549b/log/job-output.txt#8815 | 12:34 |
sean-k-mooney | but we see it in the ci too anything that uses that fixture | 12:34 |
sean-k-mooney | that seams to be the only one | 12:34 |
sean-k-mooney | care to fix that in a followup maybe or respin | 12:35 |
stephenfin | sure | 12:35 |
opendevreview | Alexey Stupnikov proposed openstack/nova stable/wallaby: Test aborting queued live migration https://review.opendev.org/c/openstack/nova/+/841483 | 12:47 |
sean-k-mooney | stephenfin: actully do you want me to just fix the notificaiton fixture in a followup or are you already working on it | 12:54 |
stephenfin | go for it; I'm playing around with cinder stuff rn | 12:54 |
sean-k-mooney | cool will do | 12:55 |
gibi | stephenfin, sean-k-mooney: should we just rename the whitelist to device_list or we make the two config totally separate and use the device_list also to enable the new feature? | 13:03 |
gibi | if we make them separate then in the initial release the whitelist still needed for the neutron based sriov even if the device_list is used for the alias based PCI passthrough | 13:04 |
gibi | now I think that renaming is simpler and then I would add an extra config to enable the new placement based PCI tracking | 13:05 |
sean-k-mooney | ok | 13:05 |
sean-k-mooney | lets rename and add a hopefully tempoery extra option for placment tracking | 13:05 |
gibi | should the placement PCI tracking config be on libvirt virt driver level or on the compute level? | 13:06 |
gibi | compute level is future proof | 13:06 |
gibi | but a bit confusing as it will only be used by the libvirt driver now | 13:06 |
sean-k-mooney | good question | 13:06 |
sean-k-mooney | you could put it in the pci section | 13:06 |
gibi | that is a good middle ground | 13:07 |
gibi | thanks | 13:07 |
sean-k-mooney | [pci]/report_in_placement=True|False | 13:07 |
gibi | ack | 13:08 |
sean-k-mooney | stephenfin: any opipion ^ | 13:08 |
stephenfin | Agreed. Sounds like a '[pci]' option | 13:09 |
sean-k-mooney | gibi: i know there are some that want us to do the rename anyway for policital reasons so we proably should not make operators choose between fucntionality and politics | 13:09 |
gibi | yeah that also a + of this approach we just deprecate the old name, but the old name still get all the new tags for now | 13:10 |
gibi | so the deployer can choose when to rename it in their config | 13:10 |
sean-k-mooney | works for me | 13:11 |
sean-k-mooney | are those all the outstanding question in the pci spec adressed then? | 13:12 |
gibi | I feel like it, but I'm doing the update now so I might bump into qustions along the way | 13:13 |
bauzas | folks, limited connectivity here probably for the end of the day, my optic fiber is changed | 13:15 |
bauzas | I changed the provider, but it looks like the older provider made some mistakes | 13:20 |
opendevreview | sean mooney proposed openstack/nova master: trivial: fix deprecation warning in notification fixture https://review.opendev.org/c/openstack/nova/+/841756 | 13:20 |
sean-k-mooney | stephenfin: ok done ^ back to oslo dirver | 13:21 |
sean-k-mooney | bauzas: ack | 13:21 |
sean-k-mooney | bauzas: when i change my mobile provider recently my old provider blocked the number porting by mistake and i lost my old number that i have had for alomts 15-20 years | 13:22 |
sean-k-mooney | changing providers sucks | 13:22 |
sean-k-mooney | on the other hand no more spam calls | 13:23 |
* sean-k-mooney just because its illegal in ireland to cold call a mobile number does not stop uk investment brokers trying to offer me advice on stock inverstments.... | 13:24 | |
bauzas | sean-k-mooney: the problem here is that my FTTH ONT number was wrote wrong | 13:25 |
bauzas | written* | 13:25 |
bauzas | the ONT number, not the phone number | 13:25 |
bauzas | so, the infrastructure operator thought it was a new fiber | 13:26 |
sean-k-mooney | ya apparently the same happened for me more or less the account number was apprently wrong but i got it from the bill and gave it directly to the new operator so im not sure how that could have been | 13:26 |
opendevreview | Alexey Stupnikov proposed openstack/nova stable/wallaby: Add functional tests to reproduce bug #1960412 https://review.opendev.org/c/openstack/nova/+/841760 | 13:26 |
sean-k-mooney | i actully no have 2 seperate FTTH lines and ONTs | 13:26 |
sean-k-mooney | i now have EIR FTTH i used to have SIRO form vodaphone | 13:27 |
opendevreview | Alexey Stupnikov proposed openstack/nova stable/wallaby: Clean up when queued live migration aborted https://review.opendev.org/c/openstack/nova/+/841736 | 13:27 |
bauzas | but eventually, my new fiber tech found the right ONT number, so he went to the OLT | 13:28 |
sean-k-mooney | we have 2 semi state owned fiber networks in ireland | 13:28 |
bauzas | sean-k-mooney: I guess that's like in France | 13:28 |
sean-k-mooney | one is owned by what used to be the nationalise telecom company and the other is owned by the state owned electic network infra ownwer | 13:29 |
bauzas | we have different networks, depending on the town | 13:29 |
sean-k-mooney | both are then open to telecoms to offer servies over | 13:29 |
bauzas | like here, in Isere department, we have a specific network | 13:29 |
bauzas | for this network, we have an infra operator | 13:29 |
bauzas | that creates fibers for the whole town up to either a block of flats or a street | 13:30 |
sean-k-mooney | in ireland we are trying to avoid that and have 2 state owned/semi state owned open fiber networks | 13:30 |
bauzas | and then, every customer can ask a network operator to get a fiber until their either flat or house | 13:31 |
sean-k-mooney | ya that is similar here | 13:32 |
bauzas | like for me, this is changing from the infra operator to the network operator 5 meters off my house | 13:32 |
bauzas | in the street | 13:32 |
*** dasm|off is now known as dasm | 14:01 | |
dansmith | yea/query sean-k-mooney | 14:51 |
dansmith | wow | 14:51 |
opendevreview | sean mooney proposed openstack/nova master: trivial: fix deprecation warning in notification fixture https://review.opendev.org/c/openstack/nova/+/841756 | 15:15 |
sean-k-mooney | stephenfin: fixed nits ^ | 15:15 |
opendevreview | Merged openstack/nova master: Add Python 3.10 functional jobs https://review.opendev.org/c/openstack/nova/+/839029 | 15:15 |
opendevreview | Balazs Gibizer proposed openstack/nova-specs master: PCI device tracking in Placement https://review.opendev.org/c/openstack/nova-specs/+/791047 | 15:33 |
gibi | sean-k-mooney, stephenfin, melwitt: fresh and simplified ^^ | 15:34 |
opendevreview | Alexey Stupnikov proposed openstack/nova stable/wallaby: Add functional tests to reproduce bug #1960412 https://review.opendev.org/c/openstack/nova/+/841760 | 15:37 |
opendevreview | Alexey Stupnikov proposed openstack/nova stable/wallaby: Clean up when queued live migration aborted https://review.opendev.org/c/openstack/nova/+/841736 | 15:37 |
sean-k-mooney | gibi: thanks im not sure i have the brain power left to read it fully at 5 pm on a friday | 16:04 |
sean-k-mooney | but ill defintly take a look on monday | 16:04 |
gibi | I totally understand :) | 16:04 |
gibi | have a nice weekend | 16:05 |
sean-k-mooney | you too o/ | 16:05 |
opendevreview | sean mooney proposed openstack/os-vif stable/xena: Use TCP keepalives for ovsdb connections https://review.opendev.org/c/openstack/os-vif/+/841771 | 16:09 |
opendevreview | sean mooney proposed openstack/os-vif stable/xena: only register tables used by os-vif https://review.opendev.org/c/openstack/os-vif/+/841772 | 16:09 |
opendevreview | sean mooney proposed openstack/os-vif stable/wallaby: Use TCP keepalives for ovsdb connections https://review.opendev.org/c/openstack/os-vif/+/841773 | 16:10 |
opendevreview | sean mooney proposed openstack/os-vif stable/wallaby: only register tables used by os-vif https://review.opendev.org/c/openstack/os-vif/+/841774 | 16:10 |
opendevreview | sean mooney proposed openstack/os-vif stable/victoria: Use TCP keepalives for ovsdb connections https://review.opendev.org/c/openstack/os-vif/+/841775 | 16:13 |
opendevreview | sean mooney proposed openstack/os-vif stable/victoria: only register tables used by os-vif https://review.opendev.org/c/openstack/os-vif/+/841776 | 16:13 |
opendevreview | sean mooney proposed openstack/os-vif stable/ussuri: Use TCP keepalives for ovsdb connections https://review.opendev.org/c/openstack/os-vif/+/841777 | 16:13 |
opendevreview | sean mooney proposed openstack/os-vif stable/ussuri: only register tables used by os-vif https://review.opendev.org/c/openstack/os-vif/+/841778 | 16:13 |
opendevreview | sean mooney proposed openstack/os-vif stable/train: Use TCP keepalives for ovsdb connections https://review.opendev.org/c/openstack/os-vif/+/841779 | 16:14 |
opendevreview | sean mooney proposed openstack/os-vif stable/train: only register tables used by os-vif https://review.opendev.org/c/openstack/os-vif/+/841780 | 16:14 |
*** gibi is now known as gibi_pto | 16:39 | |
opendevreview | Merged openstack/nova master: trivial: fix deprecation warning in notification fixture https://review.opendev.org/c/openstack/nova/+/841756 | 16:45 |
mnaser | happy friday -- https://review.opendev.org/c/openstack/nova/+/840985 + https://review.opendev.org/c/openstack/nova/+/840993 are trivial nice to have fixes that could use reviews =) | 18:53 |
opendevreview | melanie witt proposed openstack/placement stable/victoria: placement-status: check only consumers in allocation table https://review.opendev.org/c/openstack/placement/+/840702 | 20:04 |
opendevreview | melanie witt proposed openstack/placement stable/ussuri: placement-status: check only consumers in allocation table https://review.opendev.org/c/openstack/placement/+/840703 | 20:05 |
*** dasm is now known as dasm|off | 21:18 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!