Earlier  
Posted Nick Remark
#openstack-nova - 2020-03-10
12:29:26 sean-k-mooney isnint the ironic node RP name also the uuid
12:30:10 sean-k-mooney the name has to be unique so that what i would have done to make it as simple as possible but uuid for ironic makes sense
12:31:34 gibi yes, for ironic name and uuid are the same in placement
12:41:53 openstackgerrit Merged openstack/nova stable/rocky: libvirt: Ignore DiskNotFound during update_available_resource https://review.opendev.org/711278
13:15:55 mordred smcginnis: https://review.opendev.org/#/c/710214/
13:16:06 mordred smcginnis: that would be the patch that broke that test
13:22:29 mordred jkulik: https://review.opendev.org/#/c/710214/ caused a behavior change and broke SDK's functional tests
13:23:52 gibi mordred: did you depend on the HTTP 500 from nova? or what was the exact behavior change that broke the SDK?
13:24:17 mordred the opposite - we were getting NotFound before when trying to delete something by name
13:24:24 mordred and now we're getting BadRequest
13:24:49 mordred to be fair - there's ALSO a bug in SDK which this has shown
13:25:54 gibi can nova do something to help SDK out? the only thing I can imagine is to revert https://review.opendev.org/#/c/710214/ and re-propose it with a microversion bump on the API
13:26:06 gibi would that help?
13:26:07 mordred which is that we were accepting a name_or_id argument to our delete method and then it looks like we're passing taht straight on - which will never have worked
13:26:50 mordred gibi: I'm not sure - I keep going back and forth about whether the behavior change is one of those "someone might break but that person was already broken" times
13:27:16 gibi yeah, I'm hesitant too
13:27:18 mordred I think the more I talk out loud about it - the more I'm coming to think it's actually all a bug on our side that this just showed
13:32:47 gibi if SDK is need to be changed anyhow then I would not jump on the revert
13:33:04 gibi but I can be convinced otherwise
13:38:36 mordred gibi: yeah - I just pushed up https://review.opendev.org/712068 - we had a layer that was erroneously passing name_or_id. we weren't noticing the change because we trapped for ResourceNotFound and then returned False (saying we didn't delete it) - so we _were_ telling the user it wasn't working ... but we can do better there and delete by name (with a GET first) if they pass us a nane
13:46:28 jkulik mordred: I'm sorry, that this caused you problems. Any way I could have checked for this?
13:47:33 mordred jkulik: well - maybe we should consider running sdk functional tests on nova changes
13:47:57 mordred other than that - it was really just uncovering a latent bug on our side - so I think it's a good breakage :)
13:48:07 brinzhang gibi, lyarwood: I find some patch always failed by nova-live-migration task, sometimes we recheck it, that it can be passed, but sut still fails
13:48:27 brinzhang gibi, lyarwood:such as https://review.opendev.org/#/c/706897/ and https://review.opendev.org/#/c/700072/
13:49:28 brinzhang From their zuul log, I am not find some useful message caused by live migration failed, or I missing something
13:50:44 brinzhang I think we should find why it always failed, IMO, that always a hidden danger
13:54:05 brinzhang lyarwood: I saw you want to migrate nova-live-migration job https://review.opendev.org/#/c/711604/3, that can fix this issue? I will check together :)
13:57:17 openstackgerrit Monty Taylor proposed openstack/nova master: Run sdk functional tests on nova changes https://review.opendev.org/712092
13:57:26 sean-k-mooney brinzhang: i dont think that lyarwood new job will fix it
13:57:34 sean-k-mooney brinzhang: but it will make it less complex
13:57:45 sean-k-mooney so that might help us determin why its failing
13:58:01 mordred gibi, jkulik, smcginnis: ^^ sake of argument patch to run sdk functional tests over here
13:58:24 brinzhang sean-k-mooney: cool, that good
13:59:28 brinzhang sean-k-mooney: maybe lyarwood wants to migrate this job to zuulv3
14:00:28 brinzhang I remembered he looks for that migrate v3 documents the day before yesterday
14:01:32 sean-k-mooney brinzhang: yes that is what he is doing
14:02:31 sean-k-mooney brinzhang: so i was suggesting spliting the job into two 1 for ceph image backend and one for cinder/lvm and qcow block migration
14:02:51 sean-k-mooney that will avoid the reconfiguration of the services in the post script and create 2 shorter jobs
14:03:14 sean-k-mooney brinzhang: lyarwood was also considering if the evacuation tests should be seperate. or not
14:03:30 sean-k-mooney i think they should stay in the same job
14:03:58 sean-k-mooney we should be able to merge the nova-livemiration-ceph job with devstack-plugin-ceph-tempest-py3
14:04:07 sean-k-mooney and just run that multinode with live migration enabled
14:04:42 brinzhang sean-k-mooney: yeah, agree
14:05:25 sean-k-mooney so ideally the total job cout wont increase and devstack-plugin-ceph-tempest-py3 will just get sligly longer since it will be multi node and and nova-livemigation with cinder/qcow will get shorter
14:05:39 lyarwood brinzhang: it isn't going to help stable/pike
14:05:59 brinzhang they should stay in the same job, but when find that issue that we can separate it as two job, but finally we should merged
14:06:08 lyarwood there's an open bug for the vif plugging issue in master
14:06:25 sean-k-mooney lyarwood: there is?
14:06:39 sean-k-mooney that sound like something i should proably be aware of
14:07:20 lyarwood sean-k-mooney: it's an old one, I'll dig it up in a min
14:07:41 lyarwood sean-k-mooney: http://status.openstack.org/elastic-recheck/#1813789
14:08:11 sean-k-mooney ah ok
14:08:48 sean-k-mooney oh right this si a rache with registering for the event
14:08:58 sean-k-mooney *this is a race
14:09:05 gibi mordred: I have a meeting in paralle. I will read back later
14:09:11 lyarwood brinzhang: for stable/pike we might want to make the LM job NV tbh unless anyone steps up to fix it
14:09:21 brinzhang lyarwood: Maybe vif plug has some influence, let's take a look
14:10:33 brinzhang lyarwood: For stable / pike, I agree with you.
14:11:26 sean-k-mooney we skipped this on master https://review.opendev.org/#/c/663405/
14:14:21 sean-k-mooney https://review.opendev.org/#/c/667177/ i think is the final fix
14:14:28 sean-k-mooney we went back and fort a few times
14:14:53 brinzhang sean-k-mooney: this is in stable/stein, right? so from stable/stein we skip to test the migration
14:15:41 brinzhang sean-k-mooney: oh..sorry, that's vif-plug issue
14:16:25 sean-k-mooney ya but that should already be on rock too
14:16:34 sean-k-mooney https://review.opendev.org/#/c/670648/2
14:17:29 dansmith I wonder if it's time to consider dropping the vmware driver? http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013066.html
14:17:30 sean-k-mooney right so ^ is marked as a partial fix for https://bugs.launchpad.net/nova/+bug/1813789
14:17:30 openstack Launchpad bug 1813789 in OpenStack Compute (nova) "Evacuate test intermittently fails with network-vif-plugged timeout exception" [Medium,In progress] - Assigned to Artom Lifshitz (notartom)
14:18:44 sean-k-mooney dansmith: well one devstack failure is proably not enough but if we have no idea how to fix it an no one responds the maybe
14:19:15 artom sean-k-mooney, that patch was very specific to revert resize tho
14:19:23 sean-k-mooney it would help if they had included the compute agent patch
14:19:29 dansmith sean-k-mooney: point being that was a week ago with no answer
14:19:42 dansmith sean-k-mooney: and I don't even know who to point them to these days
14:19:59 sean-k-mooney artom: yes it was but i think there were other cases too
14:20:16 artom sean-k-mooney, yeah, but IIRC those were a different cause?
14:20:17 sean-k-mooney dansmith: ya i would say cdent but ya
14:20:22 artom I don't think we ever dug into those
14:20:48 sean-k-mooney artom: probably i just remember this being really hairy to untangel
14:20:55 artom sean-k-mooney, that it as
14:20:56 dansmith sean-k-mooney: and no vmware CI reporting lately, that I've seen
14:20:56 artom *was
14:21:37 sean-k-mooney dansmith: i guess we could propose deprecation if its not fix by ussuring and drop it in Victoria?
14:21:45 sean-k-mooney *ussuri
14:22:05 sean-k-mooney dansmith: we have to give 1 cycle notice right
14:22:37 dansmith sean-k-mooney: yeah, all I mean by "consider dropping" is starting the clock
14:23:22 sean-k-mooney ya did we ever follow through on the xen support
14:23:54 sean-k-mooney was it xen we talked about one of the other dirvers a few months ago right
14:26:09 dansmith yep, it's been deprecated and warning on startup for a while
14:26:13 dansmith don't think I've heard anything from anyone
14:26:40 dansmith Well, only since september I guess.. maybe that's too soon still
14:28:40 dansmith I guess we did merge a trivial log message fix to xenapi in January
14:28:47 dansmith hardly indicates heavy usage though :)
14:29:51 dansmith quality warning has been in place since May 2019
14:30:24 dansmith last actual change was Feb 2019, but from canonical which may or may not indicate actual usage, just a failed test or something
14:34:48 lyarwood stephenfin: https://review.opendev.org/#/c/706900/ - could you hit this again when you have time?
14:35:47 sean-k-mooney dansmith: ya well we could always move it out of tree, into a repo in the x namespace and if people care they can use it or step up to support it for xen
14:36:01 dansmith -2 on that plan :)
14:36:13 dansmith it's in the git tree if they want to find it
14:36:13 sean-k-mooney i know you hate out of tree drivers

Earlier   Later