Earlier  
Posted Nick Remark
#openstack-nova - 2019-10-22
15:40:23 umbSublime Ok that explains it !
15:40:26 sean-k-mooney but a hard reboot of the vm would loose any manual change you make
15:40:32 umbSublime yes absolutely
15:40:48 sean-k-mooney dumb question but do you neeed live migration. or would cold migration be enough
15:40:53 umbSublime this was just for testing purposes
15:41:23 umbSublime live-migration would really be the ideal goal (we need sometimes to update compute hosts without impacting guests)
15:42:06 umbSublime If this really isn't possible at the moment, I'm sure that aspect could be discussed internally
15:42:08 sean-k-mooney i think unfotuetly the best path forwad would be to add this as a new feature
15:42:15 sean-k-mooney what release of openstack are you running
15:43:13 umbSublime Currently that stack is on Queens
15:44:24 sean-k-mooney this is the only reference to invtsc in the nova code base
15:44:26 sean-k-mooney https://github.com/openstack/nova/blob/1ec87c227c4a506ddc3355108a95390cdaa57d62/nova/conf/libvirt.py#L608-L613
15:45:32 umbSublime hehe yes, that's the only one I found also. Most of the work to make exposing that flag to the guest possible was made in qemu/libvirt projects. There many discussions in the MLs about this
15:46:21 sean-k-mooney umbSublime: can i suggest you file a bluepirnt for this. or maybe a bug fix.
15:47:25 sean-k-mooney i would like to call it a bug so it could be backproted but its really a feautre since invtsc frequesce configuration was never previously supproted so it shoudl be a specless blueprint not a bug
15:49:45 umbSublime sean-k-mooney: I'll add it to my todo list :) (I've never done any of those, but would gladly do it)
15:50:20 umbSublime Thanks a lot helping me out :) really appreciated
15:51:05 sean-k-mooney no worries. sorry i could not point you at an exisitng knob to tweak
15:51:30 openstackgerrit Matt Riedemann proposed openstack/nova master: Stop converting Migration objects to dicts for migrate_instance_start https://review.opendev.org/690115
15:59:49 mriedem dansmith: this is the requirements bump you'll need for your osc change https://review.opendev.org/#/c/690097/
15:59:57 mriedem but the latest novaclient is breaking horizon...
15:59:59 dansmith mriedem: woot, I was just looking for it
16:00:05 dansmith guh
16:02:32 mriedem https://bugs.launchpad.net/horizon/+bug/1849351
16:02:32 openstack Launchpad bug 1849351 in OpenStack Dashboard (Horizon) "horizon doesn't work with python-novaclient 16.0.0" [Undecided,New]
16:04:36 cdent I think I know that bug. That's the "horizon needs more maintainers" bug.
16:04:37 dansmith mriedem: do you know what the deal is? brin's list of changes does't include anything that pops out at me
16:04:43 mriedem https://docs.openstack.org/releasenotes/python-novaclient/unreleased.html#upgrade-notes
16:04:56 mriedem we removed the list_extensions stuff
16:05:13 mriedem which horizon uses here https://github.com/openstack/horizon/blob/master/openstack_dashboard/api/nova.py#L1018
16:05:30 mriedem i'm guessing to enable/disable features based on extensions but since i think liberty everything is enabled and non-configurable
16:05:34 mriedem unless you have out of tree hacks
16:05:42 mriedem anyway, i'm cloning horizon to hack on it
16:05:43 dansmith oh this is more of a bump for them just the latest novaclient release?
16:06:13 mriedem horizon just has to remove usage of deprecated novaclient code that is now gone
16:07:35 dansmith novaclient hash 364cad41912e2c0f99a30f78b2835f3480a18d6e is what I was looking for
16:07:40 dansmith I guess that's why we went from 15 to 16
16:07:44 mriedem efried: ooo hot damn this is working now https://review.opendev.org/#/c/683988/
16:07:56 mriedem dansmith: that and the cells v1 things that were removed also yeah
16:08:03 dansmith ack
16:08:13 efried \o/
16:13:07 mriedem since stephen is MIA until after the summit, i wonder if we should move py27 jobs to experimental so we can run them on-demand but not automatically on every change?
16:13:27 mriedem that would at least be py27 and functional
16:13:41 mriedem maybe that's not worth the trouble right now
16:14:07 dansmith shouldn't we change functional-py3whatever to functional and functional to functional-py27 ?
16:14:07 cdent why bother?
16:14:19 cdent that was in response to mriedem not dansmith
16:14:21 dansmith just to make it default for people running local?
16:14:27 dansmith cdent: I know :)
16:14:49 mriedem dansmith: stephen's patch might do that...i'd have to check. but at some point i'm guessing we'll have functional-py37 too
16:14:55 mriedem i think that's already in experimental
16:15:11 mriedem yup https://github.com/openstack/nova/blob/master/.zuul.yaml#L97
16:15:23 dansmith mriedem: I've been typing py27 for unit for ten years almost, it's annoying to have the target name change every time we bump py3 versions
16:15:36 dansmith so I'd love to have a -efunctional and -eunit so I don't have to track
16:15:54 sean-k-mooney dansmith: we did that in os-vif
16:15:59 mriedem i've been typing -e functional-py36 for years now b/c that's the one i always broke :)
16:16:10 sean-k-mooney https://github.com/openstack/os-vif/blob/master/tox.ini#L32-L43
16:16:36 mriedem anyway, just a thought, ignore me
16:16:57 sean-k-mooney ya i have that in muscel memory too
16:17:49 sean-k-mooney dansmith: oh we did it that way in os-vif because we only had py27 fucntional tests at the time
16:18:33 sean-k-mooney so when we added python3 func tests i decided to make functional py3 by defualt
16:22:00 sean-k-mooney dansmith: i would like to see a "-e unit" too by the way as i woudl liek a way to have just "tox" work on any system regardless of what version of python you have installed
16:22:10 dansmith yeah
16:23:46 mriedem this horizon fix is pretty simple, should have it up soon
16:24:06 sean-k-mooney that said 90% of the time i run it by typeing "CTRL-r tox" to grab the command form my bash history so it does not really bother me.
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?

Earlier   Later