Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-10-22
16:27:01 openstackgerrit Adrian Chiris proposed openstack/nova stable/train: Revert "vif: Resolve a TODO and update another" https://review.opendev.org/690126
16:27:18 openstackgerrit Merged openstack/nova master: Don't populate resources for not-yet-migrated inst https://review.opendev.org/689842
16:27:25 openstackgerrit Merged openstack/nova stable/queens: Stop sending bad values from libosinfo to libvirt https://review.opendev.org/688069
16:27:32 openstackgerrit Merged openstack/nova stable/stein: Ignore sqla-migrate inspect.getargspec deprecation warnings on py36 https://review.opendev.org/685072
16:39:35 mriedem gah, this horizon thing is actually kind of a mess,
16:39:45 mriedem they have their own config option for blacklisting compute API extensions,
16:39:57 mriedem so i essentially have to remove that without a deprecation period in horizon
16:40:14 mriedem and the novaclient change https://review.opendev.org/#/c/686516/ definitely jumped the gun on removal of the deprecated list_extensions stuff
16:40:24 mriedem didn't even wait a full server side release
16:40:48 dansmith blargh
16:41:17 mriedem so, not sure what to do. i could plow ahead with the horizon thing, release note it and hope the horizon people are lax about their compat rules (makes me feel dirty)
16:41:30 mriedem or we revert the novaclient thing, blacklist 16.0.0, release a patch and then deprecate the option in horizon
16:41:33 mriedem maybe it's time for the ML
16:42:02 dansmith or release a 15.2.0 and keep everything on 15.x for a cycle?
16:42:09 mriedem always fun cleaning up the fallout from cores with itchy trigger fingers to delete shit
16:42:42 mriedem dansmith: that doesn't solve the upper-constraints issue
16:42:55 mriedem you need something for osc, and horizon needs to not be broken
16:43:18 dansmith mriedem: can't we set u-c to 15.9 or something to keep everything from getting 16?
16:43:36 mriedem dansmith: the novaclient change you need is only in 16.0.0 though
16:43:58 mriedem iow you're tied to the sinking ship unless we revert this other novaclient patch
16:43:59 dansmith right, that's why I said release 15.2, essentially backporting what we need to 15.x for a cycle
16:44:21 mriedem you mean backport your aggregate-image-cache feature to stable/train?
16:44:29 mriedem in novaclient i mean
16:44:32 dansmith well,
16:44:43 dansmith don't we have branches in the clients for number versions
16:44:43 mriedem that's what we'd have to do i think, and that's not really kosher
16:44:44 dansmith ?
16:45:01 mriedem we have branches and stable/train is the 15.x series yeah,
16:45:06 mriedem but still it would mean backporting the feature
16:45:15 dansmith yeah so your concern is train would pull in 15.2?
16:45:19 mriedem right
16:45:21 dansmith but yeah, it's a backport
16:45:40 mriedem simpler just to revert this rushed removal patch to me
16:45:46 mriedem but i'll send to the ML to see what the horizon people say
16:46:04 dansmith okay so what does that mean for versions? 16.1 becomes the next version with the stuff back in it?
16:46:11 dansmith so we effectively bumped to 16 for no reason?
16:46:47 mriedem 16.0.0 would be blacklisted, we'd revert https://review.opendev.org/#/c/686516/ and release as 16.0.1 i thnk
16:46:49 mriedem *think
16:46:52 mriedem not sure it needs to be a minor
16:46:58 dansmith that's what I mean yeah
16:47:13 mriedem u-c would get 16.0.1
16:47:17 mriedem you'd get your thing for osc,
16:47:22 mriedem and horizon would have a release to deprecate it's option
16:47:29 mriedem and we revert the revert in X
16:47:53 mriedem which is what should have happened anyway according to our novaclient deprecation removal guidelines https://docs.openstack.org/python-novaclient/latest/contributor/deprecation-policy.html
16:48:02 dansmith idk, I agree that plan would be the by-the-book way,
16:48:21 dansmith but being a client it seems like it shouldn't be that big of a deal, but I'm clearly not the expert on the politics here
16:49:14 mriedem it's not really politics, it's just that we screwed horizon without time to react,
16:49:39 mriedem so they can find an alternative solution without novaclient (i don't know how to write that patch), they can drop their thing without a deprecation period, or we can try to make it right
16:50:05 mriedem and option 5 is i just stop caring and let someone else sort out this mess :)
16:50:15 mriedem like stephenfin!
16:50:43 dansmith I mean the "getting everyone to agree on the solution" where some want the by-the-book and some might go a more pragmatic route
16:50:45 dansmith anyhoo
16:56:41 dansmith if we leave it to stephenfin then we're not going to get anything resolved until well after ptg
16:56:54 mriedem i know, i was joking
16:56:54 dansmith so hopefully that isn't the strategy
16:57:10 mriedem crap, forgot i was preheating an oven, oops
17:18:10 mriedem will see if this does the trick https://review.opendev.org/690134
18:00:44 dansmith mriedem: were you going to send an email about this or just hope horizon peeps are okay with that?
18:02:46 openstackgerrit Matt Riedemann proposed openstack/nova master: Adds view builders for keypairs controller https://review.opendev.org/347289
18:03:02 mriedem dansmith: i started working up the email but then if that change is OK i don't think it's worth the email
18:03:06 mriedem or revert discussion
18:42:18 openstackgerrit Matt Riedemann proposed openstack/nova master: FakeDriver: adding and removing instances on live migration. https://review.opendev.org/243613
19:24:52 openstackgerrit Matt Riedemann proposed openstack/nova master: api-ref: mark device response param as optional for list/show vol attachments https://review.opendev.org/690383
19:36:45 mriedem this is pretty funny https://review.opendev.org/#/c/323250/
19:36:53 mriedem "Happy 3rd birthday patch!! Soon you will go to school!"
19:37:57 dansmith lol
19:50:31 mriedem unfortunately i still have to -1 them
19:54:07 mriedem is there some way we could have an instance that is both deleted (instance.deleted != 0) and SOFT_DELETED? (instance.vm_state == 'soft-delete')?
20:18:17 openstackgerrit Matthew Booth proposed openstack/nova master: Add new simple test base for functional tests https://review.opendev.org/689186
20:18:17 openstackgerrit Matthew Booth proposed openstack/nova master: Functional test for UnexpectedDeletingTaskStateError https://review.opendev.org/689278
20:18:18 openstackgerrit Matthew Booth proposed openstack/nova master: Unplug VIFs as part of cleanup of networks https://review.opendev.org/663382
20:18:18 openstackgerrit Matthew Booth proposed openstack/nova master: Fix incorrect vm and task state after build failure race https://review.opendev.org/689388
20:18:19 openstackgerrit Matthew Booth proposed openstack/nova master: Make image fixtures simpler to reference https://review.opendev.org/690403
20:19:55 mdbooth mriedem: https://review.opendev.org/#/c/689186/3/nova/tests/functional/integrated_helpers.py is what I did to ProviderUsageBaseTestCase
20:20:42 mdbooth tl;dr renamed it to SimpleTestBase and put all the provider test specific support code in a ProviderUsageBaseTestCase subclass
20:21:14 mdbooth Then I subclassed SimpleTestBase, which is clean without the provider stuff
20:22:58 mriedem i don't want to backport any of those refactors
20:23:03 mriedem i thought i was pretty clear about that
20:23:13 mdbooth I can't explain the locking thing I hit, btw, but it made no sense, went away when I looked harder, and never came back. I assume it was PEBKAC and I probably had an unsaved editor window open or something.
20:23:19 mdbooth mriedem: Sure, if you like.
20:23:48 mdbooth mriedem: For the backport we could just use ProviderUsageBaseTestCase
20:23:54 mriedem yes, please
20:23:58 mdbooth And for the image fixture thing we could just use a hardcoded image
20:24:04 mriedem right now you have 2 refactor changes before the new regression test
20:24:05 mdbooth But lets do that in the backport
20:26:46 melwitt mriedem: without looking at the code first, I'd have thought "yes" because the instance would begin as SOFT_DELETED and then when the reclaim interval comes around and it's time to permadelete it, it would then become deleted != 0 as well. it would surprise me if the vm_state is cleared when that happens, but who knows
20:27:58 mriedem melwitt: the periodic queries the db for instances which are SOFT_DELETED and not undergoing some task_state transition on the given host,
20:28:10 mriedem then deletes them which changes the vm_state to DELETED and destroys the instance
20:28:26 mriedem so if we updated the vm_state to DELETED it shouldn't be in the db query results in the periodic
20:28:47 mriedem and if we didn't update that, like the update failed, then the instance won't be deleted either (deleted == 0)
20:29:17 mriedem the db api query will return deleted instances by default since the filter being used doesn't include deleted=False
20:29:31 mriedem but still, not sure how to get into deleted=id and vm_state=soft-delete at the same time
20:29:55 mriedem i was thinking maybe some local delete in the api wonkiness but didn't see anything obvoius
20:30:31 mriedem melwitt: also while i've got you, it looks like NOVA_CONSOLE_PROXY_COMPUTE_TLS in our nova-next job isn't getting honored anymore, i.e. we don't have the vencrypt config in that job
20:30:40 melwitt ok, it sounds like by "could have" you mean can the periodic return an instance like that. I answered it as though it were, "can we have any records in that state?" and I thought yes. so... nevermind me
20:30:49 mriedem because NOVA_CONSOLE_PROXY_COMPUTE_TLS=true in localrc but https://github.com/openstack/devstack/blob/1a46c898db9c16173013d95e2bc954992121077c/lib/nova#L175
20:31:04 melwitt mriedem: argh again huh... ok, I'll look. I've had to fix that before in the past
20:31:26 mriedem i'm trying to figure out why https://review.opendev.org/#/c/683988/ is intermittenly failing novnc tests,
20:31:41 melwitt I'll look up what I did last time and compare to see what has changed

Earlier   Later