Earlier  
Posted Nick Remark
#openstack-nova - 2017-12-14
14:14:19 mriedem so either 1 or 2 intermediate releases (6 month or 4 month between them), and do our normal spec review, spec freeze, code churn, feature freeze, stability minute, then open up for new specs again
14:14:31 mriedem i don't think we can freeze out specs for an entire year,
14:14:45 mriedem and i don't think we can leave spec reviews open for an entire year and focus on actually getting things done
14:14:52 edleafe mriedem: so would they be Rocky I, Rocky II, ...
14:15:11 mriedem rocky IV is where we fight the mirantis guys
14:15:18 mriedem us guys,
14:15:19 mriedem and yous guys
14:16:37 mriedem having said that, i don't know what we'd do for upgrade testing with intermediate releases
14:16:53 mriedem do you do queens->rocky.1, queens->rocky.2, or queens->rocky.1->rocky.2?
14:17:09 mriedem today it would be the former because of how the CI system works on branches
14:17:31 mriedem i assume we would use minor version bumps for intermediate releases
14:17:34 edleafe yuck
14:17:46 cdent blargh
14:17:49 mriedem so rocky 1 would be 17.1.0
14:17:53 mriedem if rocky GA was 18.0.0
14:17:56 mriedem but,
14:18:08 mriedem that gets tricky if we actually need to backport something to stable/pike which would normally be a minor update
14:18:12 mriedem like a schema migration
14:19:09 mriedem likely a question i'll need to ask about in "the thread"
14:20:18 stephenfin efried_cya_jan: See your comments now. I'll address them shortly
14:20:30 stephenfin Fwiw, I'll keep trying to do the minimum possible amount to keep everyone happy and get it in (ignored most of my own comments/preferences for this reason)
14:20:57 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Refactor encryptor attach and detach calls https://review.openstack.org/460243
14:20:58 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Introduce disk encryption config classes https://review.openstack.org/464008
14:20:58 openstackgerrit Lee Yarwood proposed openstack/nova master: WIP libvirt: Use QEMU's native LUKS support https://review.openstack.org/523958
14:24:22 openstackgerrit Lee Yarwood proposed openstack/nova master: WIP libvirt: Use QEMU's native LUKS support https://review.openstack.org/523958
14:26:08 openstackgerrit Merged openstack/nova master: [placement] add name to resource provider create error https://review.openstack.org/526710
14:26:14 openstackgerrit Merged openstack/nova master: [placement] Add 'Location' parameters in API ref https://review.openstack.org/521541
14:26:20 openstackgerrit Merged openstack/nova master: doc: link in some Sydney summit content https://review.openstack.org/526587
14:27:09 dansmith bauzas: need you to look at https://review.openstack.org/#/c/527799/2
14:30:01 takashin mriedem: The compute API microversion 2.57 was added in "Deprecate file injection" https://review.openstack.org/#/c/522027/ .
14:30:06 takashin mriedem: But I cannot find a patch for microversion 2.57 in python-novaclient. Would you submit the patch?
14:31:11 takashin mriedem: Are you around?
14:33:22 jaypipes mriedem: ok, looking at it now.
14:37:04 mriedem takashin: i plan on working on that novaclient patch today
14:37:16 mriedem takashin: didn't get the time yesterday - too much other stuff going on
14:38:26 takashin mriedem: okay. Thanks.
14:43:53 jroll mriedem: we should talk about releases/upgrades at PTG if this goes through, ironic has some experience with that
14:46:41 cdent jroll: are you back on the scene?
14:46:48 cdent as in: gonna be in dublin?
14:46:54 mriedem jroll: yeah i was going to ask in the thread to get the experience of other teams already doing it
14:47:27 jroll cdent: waiting for approval but hopefully yes
14:47:33 jroll mriedem: ++
14:49:55 mriedem i didn't want to ask jroll that question
14:50:05 mriedem something something "don't ask a question you don't already know the answer to"
14:50:20 jroll you don't wanna know anyway
15:01:02 stephenfin mdbooth: So if I'm understanding this correctly, this fixes and issue we'd only see when using microversion < 2.25? https://review.openstack.org/#/c/524681/
15:09:21 cdent zounds, an email thread has drawn dansmith, this is a banner day
15:09:52 dansmith cdent: I really really wanted to ignore this one even more than usual
15:10:14 cdent dansmith: I'm glad you didn't.
15:15:34 openstackgerrit Takashi NATSUME proposed openstack/nova master: [placement] Separate API schemas (usage) https://review.openstack.org/520603
15:16:01 openstackgerrit Jianghua Wang proposed openstack/nova master: XenAPI: create vGPU for instance https://review.openstack.org/516899
15:16:02 openstackgerrit Takashi NATSUME proposed openstack/nova master: [placement] Separate API schemas (trait) https://review.openstack.org/520605
15:16:28 openstackgerrit Takashi NATSUME proposed openstack/nova master: [placement] Separate API schemas (aggregate) https://review.openstack.org/520608
15:16:49 dansmith apparently I'm just replying to edleafe's emails today
15:16:54 openstackgerrit Takashi NATSUME proposed openstack/nova master: [placement] Add functional tests for resource class API https://review.openstack.org/524506
15:16:58 mriedem sdague: bauzas: can you take a look at these ocata backports? https://review.openstack.org/#/q/topic:bug/1732947+status:open+branch:stable/ocata - holding up newton backports for the same changes which is holding up newton eol
15:17:15 openstackgerrit Takashi NATSUME proposed openstack/nova master: [placement] Separate API schemas (inventory) https://review.openstack.org/520613
15:17:29 bauzas mriedem: roger, captain
15:17:34 mriedem bauzas: sdague: and this ocata one https://review.openstack.org/#/c/526426/
15:17:35 mriedem same story
15:17:49 mriedem tonyb: i sent an email to the dev list about what i think needs to happen to get nova to newton-eol
15:19:16 jianghuaw_ hi bauzas, need your help to look at this patch: https://review.openstack.org/#/c/516899/
15:19:36 mriedem tonyb: http://lists.openstack.org/pipermail/openstack-dev/2017-December/125592.html
15:24:19 lyarwood mriedem: did we also want to fix https://review.openstack.org/#/c/526426/1 in newton?
15:25:30 lyarwood mriedem: ah nvm, you listed the stable/newton version in that query, ignore me
15:29:04 cdent shiny pretty edleafe
15:32:22 mriedem i did think about the impact to the deprecation policy this morning when i got up, glad dan mentioned that
15:32:37 mriedem we will be supporting turds for longer, and hamstrung by said turds potentially
15:32:47 mriedem i'm glad we said rocky is the target to drop nova-net and cellsv1
15:33:58 cdent the bits with "support both ways of doing this thing" have to stay around longer too, which is icky
15:34:09 cdent but then again, apparently the style is something the ff-upgrade people don't like?
15:39:18 dansmith mriedem: so my goal on that reqspec fix is to try to converse with bauzas about it today to make sure he's okay with it and/or there's not something huge we're missing on it
15:39:47 mriedem ack
15:39:49 dansmith mriedem: and then hand over the patch and backports to artom, who unfortunately is the recipient of many such turdish patches of mine right before I leave on vacay :P
15:40:12 artom Seriously, I'm like dansmith's crap scapegaot
15:40:17 artom Crapgoat
15:40:19 mriedem dansmith: i'm personally not comfortable with that one going to newton right before we eol
15:40:24 dansmith artom: as you will henceforth be known.
15:40:26 mriedem i think the column alter is fine
15:40:27 mriedem for newton
15:40:42 mriedem i'm worried too much about reqspec/group side effects
15:40:50 dansmith mriedem: well, I'd rather just not backport any of it to newton myself,
15:41:04 dansmith mriedem: and don't really want to backport the migration at all, but that's fine
15:41:14 dansmith we will, of course, but newton needs to go at some point
15:41:24 artom I agree that the migration might have more side effects than the load by UUID patch
15:41:25 mriedem i know but i love it so
15:41:27 artom Er, less
15:41:27 dansmith and this is something that has been this way since the release and which we've only _just_ heard about
15:41:44 artom So if we're going to backport something, it might actually be safer to do just the migration
15:41:44 mriedem yeah, because people are just now upgraded
15:41:46 mriedem *upgrading
15:42:02 mriedem well, people with big ass server groups apparently :)
15:42:14 artom Also good point - there's like a 1-2 year lag between upstream and what's actually running
15:42:36 dansmith well, there are definitely people already on newton and beyond, but I understand that reasoning
15:43:02 dansmith mriedem: fwiw, there were only four such instances in a database of tens of thousands that were affected here
15:43:15 dansmith mriedem: and it seemed like it was a very specific case, which might have been testing and/or a script run amok
15:43:26 dansmith just for the data point
15:43:43 mriedem ok
15:44:10 dansmith the fact that we're crystallizing known-bad server groups in the database at creation time is almost more concerning to me than the overrun case
15:44:48 artom Known-bad?

Earlier   Later