opendevreview | zhangqing proposed openstack/nova stable/train: remove redundant statement in SecurityGroupDefaultRulesController https://review.opendev.org/c/openstack/nova/+/853901 | 03:10 |
---|---|---|
opendevreview | zhangqing proposed openstack/nova stable/train: remove redundant statement https://review.opendev.org/c/openstack/nova/+/853901 | 03:11 |
Uggla | Hello o/ | 07:29 |
gibi | Uggla: welcome back | 07:37 |
Uggla | Hi gibi ! | 07:38 |
gibi | fyi folks, we have "Non-client library freeze: August 25th, 2022 (R-6 week)" which is this week. So if you have anything depending on os-traits, os-resource-classes, os-vif, etc then those dependencies needs to land this week | 07:51 |
opendevreview | Rajesh Tailor proposed openstack/nova master: Fix rescue volume-based instance https://review.opendev.org/c/openstack/nova/+/852737 | 08:06 |
opendevreview | Jan Hartkopf proposed openstack/nova master: add support for updating server's user_data https://review.opendev.org/c/openstack/nova/+/816157 | 08:08 |
gibi | sean-k-mooney[m]: this is the code that causes the missing PCI device failure https://github.com/openstack/nova/blob/99dd3f75cd23a4ff419c20826f5abfcfed417889/nova/pci/manager.py#L485-L503 in https://review.opendev.org/c/openstack/nova/+/853835 (I needed fresh brains for it to find) | 08:52 |
sean-k-mooney | ah right just getting started but ill pull your patch and see if i can reporduce locally and take a look | 09:10 |
gibi | I need to refactor that piece of code and move it to the Instance ovo | 09:11 |
sean-k-mooney | i was thinking about this since we last spoke. is there any reason not to have the consturctor generate a uuid automitically when we constuct the pci request objects | 09:13 |
sean-k-mooney | since we will now be creating these on both the neuton and non nueutron path | 09:13 |
gibi | sean-k-mooney: yes, that is a good point too | 09:14 |
gibi | sean-k-mooney: I will do that | 09:14 |
sean-k-mooney | do you recall what test failed? | 09:14 |
sean-k-mooney | i guess it will be in the zuul logs | 09:14 |
sean-k-mooney | test_cold_migrate_server_with_pci | 09:15 |
gibi | yes that one | 09:17 |
gibi | and it fails as when the libvirt driver tries to get the PciDevice objects of the instance to generate the xml it gets [] as the above linked piece of code assumes request_id = None means flavor based PCI request | 09:18 |
gibi | and I break that assumption | 09:18 |
sean-k-mooney | we have a function to figure that out | 09:18 |
sean-k-mooney | which should be used instead | 09:19 |
sean-k-mooney | three is a source atribute | 09:19 |
sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/objects/instance_pci_requests.py#L48-L54 | 09:19 |
gibi | exactly | 09:20 |
Uggla | gibi, sean-k-mooney any objection to rename the options as proposed by stephen here : https://review.opendev.org/c/openstack/python-openstackclient/+/831902/comments/9b4913bd_cee0ed57 | 09:22 |
sean-k-mooney | i havent looked at it but ill check quickly | 09:23 |
* gibi clicks too | 09:23 | |
sean-k-mooney | oh he wants to use the ciso no prefix | 09:23 |
sean-k-mooney | i personaly hate that | 09:23 |
gibi | we have examples with --no-* already in the client and the flag's doc clearly states that this means unpin so I'm OK | 09:26 |
sean-k-mooney | we do but we also have set and unset i belive | 09:27 |
sean-k-mooney | just checkign that now | 09:27 |
sean-k-mooney | yes opnestack flavor set and unset | 09:27 |
gibi | but that is not a flag but a subcommand | 09:27 |
sean-k-mooney | yes but i think openstack server unshleve --unset-az | 09:29 |
sean-k-mooney | would make sense | 09:29 |
gibi | I have nothing against that either | 09:30 |
gibi | stephenfin: are you around? | 09:30 |
sean-k-mooney | gibi: so printing the xml there are not hostdev elements which is why its getting None for elem | 09:40 |
gibi | yes | 09:40 |
gibi | I figured it out this morning | 09:40 |
sean-k-mooney | i find that very odd that adding the request id woudl have resulted in that | 09:40 |
gibi | nova uses PciDevice.request_id == None to signal flavor based PCI devs | 09:41 |
sean-k-mooney | so yes modifying get_instance_pci_devs | 09:41 |
sean-k-mooney | is likely the way to go | 09:41 |
gibi | yes | 09:41 |
sean-k-mooney | well we do in some placees but not all | 09:41 |
gibi | yes | 09:41 |
sean-k-mooney | oh its becasue we have the PciDevice object not the pci request objects here | 09:47 |
sean-k-mooney | i was going to just add or device.source == objects.InstancePCIRequest.FLAVOR_ALIAS | 09:48 |
sean-k-mooney | but device is not an InstancePciREquest object | 09:48 |
sean-k-mooney | we have the pci request too | 09:49 |
gibi | yes | 09:50 |
gibi | there is somewhere a generic code that does PciDevice.request_id = InstancePCIRequest.request_id | 09:51 |
gibi | which is I think correct | 09:51 |
sean-k-mooney | that basically waht im trying locally | 09:52 |
sean-k-mooney | im doing a set comprehention to get the flavor request ids and then checking if the current device is in that when request_id is none | 09:52 |
sean-k-mooney | https://paste.opendev.org/show/bqJUPAfRGibXn8mslgdU/ | 09:54 |
gibi | I added https://paste.opendev.org/show/b1nvksM7Fw7F4w5vnDKw/ to Instance ovo and replaced the get_instance_pci_devs calls with it and it seems to work | 09:54 |
sean-k-mooney | that seams to work | 09:54 |
sean-k-mooney | you could do that but you can do it in the existing fucntion without changing the signiture or moving it | 09:55 |
gibi | yeah but 1) I have the implicit not-providing-request-id meaning give me the flavor based CPI devs | 09:56 |
gibi | s/have/hate/ | 09:56 |
gibi | I want to make the query explicit by the caller | 09:56 |
sean-k-mooney | yep i get that | 09:56 |
gibi | 2) also request_id == 'all' is /o\ | 09:56 |
sean-k-mooney | the duality because of the fact that this code predated neutron sriov i think | 09:57 |
sean-k-mooney | and source | 09:57 |
gibi | yes, it is old code, it served wll but I retired it now :D | 09:57 |
sean-k-mooney | source is relitivly recent | 09:57 |
sean-k-mooney | yep so just runing the func test loocally my change seams to work | 09:58 |
sean-k-mooney | i suspect your will also | 09:58 |
sean-k-mooney | so you have too paths forward you coudl make my small change for not and then have a followup refactor patch to swap to your veriosion | 09:58 |
sean-k-mooney | or you could do that all in one go along with changing all callers to use the new version on the ovo | 09:59 |
gibi | it is < 10 callers so I won't split this into two | 09:59 |
sean-k-mooney | ok this might conflcit with the vdpa seriese although it might not im hopefully goign to adress the last bits in that today and i can stop thinking about that | 10:00 |
sean-k-mooney | im not driectly modifying that function for the vdpa code it just ends up calling it indreictly | 10:01 |
gibi | you vdpa series will have priority over my change and I will rebase, no worries | 10:01 |
sean-k-mooney | im going to grab a drink but it sounds liek you ahve a way forward | 10:01 |
sean-k-mooney | im going to step away for 5 mins and ill be back. i like the simplicty of your new get_pci_devices function | 10:02 |
sean-k-mooney | although im not sure if the deepcopy is correct | 10:03 |
sean-k-mooney | can you add a comment as to why you are doing that. we may want to modify the existing devices and i woudl proably put the deep copy if needed on the caller rather then doing it in this function | 10:04 |
gibi | hm, you are right I need a shallow copy | 10:04 |
gibi | hm, not even that | 10:05 |
gibi | I first tried a startegy that would modify the dev list | 10:05 |
gibi | but now it creates new lists | 10:05 |
gibi | so no copy needed | 10:06 |
gibi | good catch | 10:06 |
sean-k-mooney | i was just comparing your version to mine and noticed you had an extra copy and was not sure why you were doing it if i was totaly honest | 10:13 |
sean-k-mooney | i.e. i was not sure if i missed it in mine or if it was extra in yours. | 10:14 |
sean-k-mooney | so you can just make it devs = self.pci_devices or [] | 10:14 |
gibi | yes | 10:19 |
stephenfin | gibi: Sorry, I am around but I wasn't connected to IRC. What's up? | 10:22 |
gibi | stephenfin: it is about https://review.opendev.org/c/openstack/python-openstackclient/+/831902/comments/9b4913bd_cee0ed57 | 10:23 |
stephenfin | sean-k-mooney: Replied to https://review.opendev.org/c/openstack/python-openstackclient/+/831902/ I realize it's no ideal, but as I've tried to stress in my response, consistency is key when it comes to OSC | 10:23 |
stephenfin | We shouldn't do nova-specific things, even if the terminology used by OSC isn't ideal | 10:23 |
stephenfin | Hopefully what I've said makes sense | 10:23 |
* stephenfin looks | 10:23 | |
sean-k-mooney | it does but i dont think its sufficent | 10:24 |
stephenfin | Oh, one and the same :) | 10:24 |
sean-k-mooney | i really dont think using the no prfix shoudl be allowed | 10:24 |
sean-k-mooney | that siad i wont block on it | 10:24 |
sean-k-mooney | but i dont think we shoudl use it anywere in osc | 10:24 |
stephenfin | It's everywhere already though. That ship sailed so long ago that's it almost home again :) | 10:25 |
sean-k-mooney | i tought the gramer alone would make you recoile from its use :) | 10:25 |
stephenfin | Heh, true. It's a very common pattern though | 10:26 |
stephenfin | Even argparse supports it now | 10:26 |
stephenfin | Look for BooleanOptionalAction on https://docs.python.org/3/library/argparse.html | 10:26 |
sean-k-mooney | its a cisco patteren that they took othres to court over in the past | 10:26 |
sean-k-mooney | they tried to trademark it i belive | 10:26 |
gibi | trademark --no-*? lol, I want to be that lawyer :D | 10:27 |
stephenfin | We've gone off topic now, but how would we do inverse boolean options (flags) without that? | 10:27 |
sean-k-mooney | gibi: they sued as a breach of there copyright when arista tried to use it https://www.networkcomputing.com/networking/cisco-arista-battle-over-cli | 10:28 |
sean-k-mooney | stephenfin: but your githt it is off topic | 10:29 |
sean-k-mooney | i just dislike mimicic that style because of there previous actions and also i find it less clear | 10:30 |
sean-k-mooney | stephenfin: i would not have it as a flag i woudl have =True|False personally | 10:32 |
sean-k-mooney | or use --revert --confrim e.g. two related terms | 10:33 |
sean-k-mooney | i generally perfer --*=True|false type CLIs | 10:34 |
sean-k-mooney | too --* --no-* CLIs | 10:34 |
opendevreview | Jan Hartkopf proposed openstack/python-novaclient master: add support for microversion 2.93 https://review.opendev.org/c/openstack/python-novaclient/+/816158 | 10:41 |
opendevreview | Rajesh Tailor proposed openstack/nova master: Fix rescue volume-based instance https://review.opendev.org/c/openstack/nova/+/852737 | 11:18 |
sean-k-mooney | stephenfin: im not -1ing since im more or less delegating the style desisson to you | 11:23 |
stephenfin | ack, thanks. And I'm just following the OSC guidelines | 11:23 |
sean-k-mooney | its one of those case of i dont like it but also dont plan to work on it to fix it so lets be consitent even if it think its not the best way to do it | 11:24 |
sean-k-mooney | stephenfin: gibi question regarding scope of nova status. can we add checks to that that are not for upgrades or would nova manage be a better place | 11:40 |
sean-k-mooney | i was just thinking about the downstream escalation | 11:40 |
sean-k-mooney | would a nova status command to find all instnace that have incorrect pci device adress in there neutron ports be in scope | 11:41 |
sean-k-mooney | i.e. nova-status validate instance-pci-slots | 11:41 |
sean-k-mooney | and have that print a list of instnace uuids | 11:42 |
sean-k-mooney | as an admin you would either need to manually fix them or just cold migrate them and let nova do it | 11:42 |
sean-k-mooney | we have the binding profile in the network_info_cache so we can actully do the check form the nova db if we do it in python to parse the json blob | 11:44 |
sean-k-mooney | this would be entirely unrelated to upgrades however so not sure if nova-status is the right place | 11:44 |
sean-k-mooney | but it would tell you if there is "db currption" where the neutron db is out of sync with nova's pci allcoations | 11:44 |
sean-k-mooney | there are some other one off validations like this that might be worth adding in the future just wondiging if addign a validate sub command for these types of checks makes sesne | 11:45 |
sean-k-mooney | im not sure if ye have seen https://review.opendev.org/c/openstack/nova-specs/+/853837 that dansmith started for hardening our hostname requirements | 11:47 |
sean-k-mooney | when im thinking about the fallout of hostname changes i think some of the sideeffect are things we coudl detect and codify in nova-status checks | 11:48 |
sean-k-mooney | for example checking that a vm with pci allcoations has them against the compute node its currently on | 11:49 |
sean-k-mooney | so if non upgrade checks are in scope of nova status we could add a set of validations to it for similar things going forward | 11:50 |
sean-k-mooney | if we wanted to have automated fixes i would sugggest using nova-manage | 11:50 |
sean-k-mooney | but detecting the issues i think would fall into nova-status | 11:50 |
sean-k-mooney | or perhaps the health check api if the detachtions are cheap and can be part of a periodic | 11:51 |
sean-k-mooney | for example asseting that the pci adresses in the network info cache are a subset of the pci claims and cyborg devices(if there are any) | 11:52 |
sean-k-mooney | stephenfin: by the way im starting to use the versionadded directive should i drop the histroy table at the end with the planned/inprogress line items | 11:54 |
sean-k-mooney | its proably reduntant now | 11:54 |
gibi | sean-k-mooney: I would add that to nova-manage as it more simila to the audit command there | 11:57 |
sean-k-mooney | ok so nova-manage validate <whatever> or nova-manage check <thing> | 11:58 |
gibi | yes. I would keep the upgrade checks separate as they have a well defined scope | 11:58 |
sean-k-mooney | ack | 11:58 |
sean-k-mooney | im not nessisarly plannign on adding them myslef in the near term. but long term i think we want to codify some of those check rahter then providing a set of sql quriese to custoemr to run | 11:59 |
gibi | I agree | 11:59 |
gibi | my recent leaked migration allocation case could be added there too | 12:00 |
sean-k-mooney | yep and depending on how we write them perhaps they could be reused for healtch checks later | 12:01 |
sean-k-mooney | i feel like many of these checks are two heavy weight for that | 12:01 |
gibi | we need to measure the load they create | 12:01 |
sean-k-mooney | but there are some simple cases where we currently raise excptiont that could set a booleing flag | 12:02 |
gibi | I can imageine that some of them are too heavy | 12:02 |
sean-k-mooney | yep for the reousce tracker brakages we already have a pattern in the code i created for catching expctins and using those to set flags | 12:02 |
sean-k-mooney | which will be the simple way to detect two vms using the same cpus for examle | 12:03 |
sean-k-mooney | we can catch the qemu issue when two vms try to use the same pci device the same way | 12:03 |
sean-k-mooney | without computeing it | 12:03 |
sean-k-mooney | having the ablity to ask nova for the conflciitng vms seperatly however will help operators resolve that | 12:04 |
sean-k-mooney | and thats kind of where i was going with the new commands | 12:04 |
gibi | make sense | 12:04 |
sean-k-mooney | so healtch notices we failed to boot because fo conflciting pci devices. then operartor runs the command to deterim what vms are using the wrong devices | 12:05 |
sean-k-mooney | then they cold migrate them to fix it or manually fix the port in neutron | 12:05 |
opendevreview | Rajesh Tailor proposed openstack/nova master: Fix rescue volume-based instance https://review.opendev.org/c/openstack/nova/+/852737 | 12:47 |
gibi | sean-k-mooney: btw, I cannot set request_id during __init__ of InstancePCIRequest as that is forbiden for ovos :/ https://github.com/openstack/nova/blob/3af84811c8b181a49195f640c9c971d16d6d3477/nova/tests/unit/objects/test_objects.py#L1327 | 13:41 |
opendevreview | ribaudr proposed openstack/nova master: Alphabetizes objects https://review.opendev.org/c/openstack/nova/+/853986 | 13:43 |
sean-k-mooney | oh ok i guess that explains why we do it seperatly | 13:43 |
opendevreview | Balazs Gibizer proposed openstack/nova master: Generate request_id for Flavor based InstancePCIRequest https://review.opendev.org/c/openstack/nova/+/853835 | 13:52 |
gibi | sean-k-mooney: ^^ I will move this into the PCI in placement series so we don't need to merge it before we really need the request_id | 13:52 |
opendevreview | sean mooney proposed openstack/nova master: Add source dev parsing for vdpa interfaces https://review.opendev.org/c/openstack/nova/+/841016 | 13:59 |
opendevreview | sean mooney proposed openstack/nova master: Fix suspend for non hostdev sriov ports https://review.opendev.org/c/openstack/nova/+/841017 | 13:59 |
opendevreview | sean mooney proposed openstack/nova master: Add VDPA support for suspend and livemigrate https://review.opendev.org/c/openstack/nova/+/853704 | 13:59 |
sean-k-mooney | gibi: ack, will this need an offline data migration to populate that on old records or are you jsut going to set it on load from the db when not set and heal it over time | 14:00 |
sean-k-mooney | by the way i dont know if you want to do this or not but you could set the requester_id=flavor.uuid in the flavor case if you wanted too | 14:01 |
sean-k-mooney | we dont need that but it might be nice | 14:02 |
gibi | sean-k-mooney: I think we don't need a data migration. The request_id == None asumption is now removed but those old request and old pci devices that exists already still work as InstancePCIRequest.source works via alias_name | 14:02 |
*** dasm|off is now known as dasm | 14:02 | |
gibi | I could set requester_id, but I don't use it | 14:02 |
sean-k-mooney | its just a nice to have | 14:02 |
gibi | also requester_id pointing to flavor_id is problematic as extra_spec can change on a flavor | 14:02 |
sean-k-mooney | well they can but they should not but i take your point | 14:03 |
sean-k-mooney | it would just be nice if it was also always set | 14:03 |
sean-k-mooney | but it does not have to be | 14:03 |
gibi | anyhow until I don't know how requester_id would be used I don't know if a changing flavor extra spec could cause trouble | 14:04 |
sean-k-mooney | well we woudl use the embeded copy anyway | 14:04 |
sean-k-mooney | i was wondering if it woudl help for resize | 14:05 |
gibi | that would work, but I cannot enforce that when a InstancePCIRequest.requester_id is compared to a flavorid then that flavorid is actually a stored copy or not | 14:05 |
sean-k-mooney | so we can corralate the pci request to the source or dest flavor | 14:05 |
sean-k-mooney | for example today there si no way to differnceate between source and dest flavor when resizing to same host | 14:06 |
gibi | I definitely have to look at the resize case with pci in placement as the move claim re-creates the InstancePCIRequest so new uuids will be generated there | 14:06 |
sean-k-mooney | but if the requester id was the flavor uuid in that case we could | 14:06 |
gibi | yes, it sounds useful | 14:07 |
gibi | I keep it in mind | 14:07 |
sean-k-mooney | ack im trying not to over complicate the requirement for your mvp | 14:07 |
opendevreview | Balazs Gibizer proposed openstack/nova master: Generate request_id for Flavor based InstancePCIRequest https://review.opendev.org/c/openstack/nova/+/853835 | 14:08 |
gibi | sean-k-mooney: no worries :) | 14:08 |
sean-k-mooney | stephenfin: gibi when you have time the vdpa seriese i belive is not ready for review | 14:08 |
stephenfin | now? | 14:08 |
sean-k-mooney | im going to switch to some down stream stuff for a bit | 14:09 |
stephenfin | (or not) | 14:09 |
sean-k-mooney | stephenfin: yes just pushed it | 14:09 |
sean-k-mooney | sorry now | 14:09 |
sean-k-mooney | :) | 14:09 |
gibi | I will review it right now, to fit it before the downstream call | 14:09 |
gibi | sean-k-mooney: there are some service version mistmatches in the last vdpa patch, I left a -1 there | 14:28 |
sean-k-mooney | ya also i just ran those tests localy and 2 of them fail | 14:28 |
sean-k-mooney | i tought i did that but i guess not | 14:28 |
sean-k-mooney | ill fix the issues today but likely after our downstream meetings | 14:29 |
sean-k-mooney | thanks for taking a look | 14:29 |
gibi | ack | 14:30 |
JayF | Hey all again, still looking for reviews on this improvement to CI for Ironic-related patches https://review.opendev.org/c/openstack/nova/+/853529 | 15:02 |
JayF | and a couple of stable patches I'm trying to get through the gate; one is at victoria right now ( https://review.opendev.org/c/openstack/nova/+/821350 ) and the other is at ussuri ( https://review.opendev.org/c/openstack/nova/+/853540 ) | 15:03 |
JayF | Also if there's anything I can do to more properly integrate my requests for reviews into whatever process you all use, I'm happy to take feedback. | 15:03 |
opendevreview | Sofia Enriquez proposed openstack/nova master: WIP: Check NFS protocol https://review.opendev.org/c/openstack/nova/+/854030 | 16:05 |
*** tkajinam is now known as tkajinam|off | 16:35 | |
opendevreview | Jean-Sébastien Bevilacqua proposed openstack/nova master: Add Lustre support to nova https://review.opendev.org/c/openstack/nova/+/853786 | 16:37 |
opendevreview | Rajesh Tailor proposed openstack/nova master: Fix rescue volume-based instance https://review.opendev.org/c/openstack/nova/+/852737 | 16:49 |
opendevreview | sean mooney proposed openstack/nova master: Add VDPA support for suspend and livemigrate https://review.opendev.org/c/openstack/nova/+/853704 | 16:57 |
opendevreview | Elod Illes proposed openstack/nova stable/victoria: Ignore plug_vifs on the ironic driver https://review.opendev.org/c/openstack/nova/+/821350 | 17:15 |
stephenfin | sean-k-mooney: question on the last vDPA patch but good on the other two https://review.opendev.org/c/openstack/nova/+/853704 | 17:16 |
sean-k-mooney | gibi: stephenfin what is the lifetime of this fixture https://github.com/openstack/nova/blob/master/nova/tests/functional/libvirt/test_pci_sriov_servers.py#L83 | 17:17 |
sean-k-mooney | when i inhirt form this class instead it not actully in applied in my live migration test | 17:18 |
sean-k-mooney | do i need to assgin that to a varible | 17:18 |
gibi | a single test case | 17:18 |
sean-k-mooney | to extend it to the full test | 17:18 |
gibi | do you call super() from your class setUp? | 17:18 |
sean-k-mooney | yep | 17:19 |
sean-k-mooney | if i do | 17:19 |
sean-k-mooney | from nova.tests.fixtures.libvirt import Domain as Dom | 17:19 |
sean-k-mooney | self.assertEqual(self._migrate_stub, Dom.migrateToURI3) | 17:19 |
sean-k-mooney | they are not the same | 17:19 |
sean-k-mooney | stephenfin: looking now | 17:19 |
gibi | strange. I would say push the patch and I will look at it but I will only do that tomorrow. I' mostly off for today | 17:20 |
sean-k-mooney | gibi: the current one has the issue | 17:21 |
sean-k-mooney | and no worries | 17:21 |
sean-k-mooney | i might assign it to a var and see if that helps | 17:21 |
gibi | should not make a difference but worth trying as it maybe tease out something else | 17:21 |
sean-k-mooney | gibi: by the way stephenfin question is basicaly somethign i need you to answer https://review.opendev.org/c/openstack/nova/+/853704/5/nova/objects/service.py#236 | 17:22 |
sean-k-mooney | gibi: it can wait till tomorrw but my current answer is becasue gibi said so | 17:22 |
gibi | stephenfin, sean-k-mooney: about the N-1 version list in service.py. I think the easiest way out is not to change that in this patch series | 17:23 |
gibi | we change that at every start of a cycle | 17:23 |
sean-k-mooney | ack i can drop it | 17:24 |
stephenfin | wfm | 17:24 |
gibi | but to answer the question. When I introduced that logic I made it generic to support the case when somebody upgrade nova to beta version (or to m2 version) | 17:24 |
gibi | so the recorded service version for a given release is the first version appeared in that release | 17:24 |
gibi | so when we say Yoga supports Xena computes it means Yoga supports even the first (not just the last) service version of the Xena computes | 17:25 |
sean-k-mooney | hum ok i tought this was ment to be the latest version | 17:25 |
sean-k-mooney | im not sure we make that guarentee | 17:26 |
gibi | I think talked about later that it does not really need to support m2 upgrades | 17:26 |
gibi | so my genericness is not strictly needed | 17:26 |
gibi | but it is not wrong per se | 17:26 |
sean-k-mooney | it does not need to be in this patch anyway | 17:26 |
gibi | but if we change to latest, then I suggest to change it with some extra comments that describes that past values are not latest per release | 17:26 |
gibi | sean-k-mooney: yes, it is not needed in this patch | 17:26 |
sean-k-mooney | cool enjoy your eventing | 17:27 |
gibi | btw, I don't see any obvious problem with your live migration test, but I will look more tomorrow | 17:27 |
sean-k-mooney | im going to finsih soon too as i have a headache | 17:27 |
sean-k-mooney | ya its weired | 17:27 |
sean-k-mooney | im going to try one or two thing and call it aday | 17:27 |
sean-k-mooney | im wondering is this a sideefect fo fixtures._fixtures.monkeypatch.MonkeyPatch vs fixtures._fixtures.mock | 17:29 |
opendevreview | Merged openstack/nova master: Fix a deprecation warning about threading.Thread https://review.opendev.org/c/openstack/nova/+/853869 | 19:07 |
opendevreview | Rico Lin proposed openstack/nova master: Add locked_memory extra spec and image property https://review.opendev.org/c/openstack/nova/+/778347 | 20:35 |
opendevreview | Rico Lin proposed openstack/nova master: libvirt: Add vIOMMU device to guest https://review.opendev.org/c/openstack/nova/+/830646 | 20:35 |
opendevreview | Rico Lin proposed openstack/nova master: Add traits for viommu model https://review.opendev.org/c/openstack/nova/+/844507 | 20:35 |
*** dasm is now known as dasm|off | 21:51 | |
opendevreview | Brett Milford proposed openstack/nova master: Handle "no RAM info was set" migration case https://review.opendev.org/c/openstack/nova/+/852002 | 23:02 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!