Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-10-03
15:49:46 mriedem it probably needs to at least be documented in the specs review for code review process
15:49:52 mriedem *specs repo
15:50:33 mriedem https://specs.openstack.org/openstack/nova-specs/readme.html#specification-review-policies
15:52:14 mriedem i have voted on the liaison patch forewith
15:52:18 mriedem forthwith?
15:52:26 mriedem yes
15:55:31 efried thanks
15:57:06 mriedem btw i know this isn't fun,
15:57:08 mriedem welcome to process land
15:57:14 mriedem and my world for 2 years
15:57:23 efried thanks
15:57:39 mriedem yo'ure also very handsome
15:58:25 gmann efried: i have re-proposed the policy spec for ussuri - https://review.opendev.org/#/c/686058/
16:02:26 efried mriedem: is that a thing? Three thank-yous and the bot automatically picks it up?
16:02:34 efried I'll have to be more careful.
16:02:36 efried gmann: ack
16:02:46 mriedem efried: ha, no
16:02:51 mriedem not what i meant
16:03:24 efried gmann: stay tuned for an update on how we're going to be deciding on approvals (once we figure it out ourselves...)
16:06:00 gmann efried: you mean the on ML thread ? but this is re-proposal of already approved spec
16:06:54 efried gmann: yup, that's understood. We're leaning towards making even those conform to the same criteria.
16:07:12 gmann humm
16:08:05 efried gmann: mriedem makes a good point about needing to update the nova-specs readme accordingly, because previously-reviewed specs will need more than just a random single-core +2 now.
16:08:15 gmann I thought re-approved things are fast approved one and new one goes into that criteria
16:08:46 efried gmann: not an unreasonable assumption. We're still working out the details.
16:09:52 dansmith gmann: that's being changed
16:09:56 dansmith well, potentially
16:10:25 dansmith efried: fwiw, I think the re-approval of specs has always been flawed because we just kick things down the road instead of requiring them to muster enough support to be approved again
16:10:28 cdent if a pre-approved spec didn't get done in the previous cycle, one would think that it deserves extra inspection to see if it is maybe a lost cause
16:10:39 cdent yeah, what dansmith said
16:10:42 efried ++
16:10:42 dansmith yup
16:11:08 efried requiring the sponsor to +2 might be enough
16:11:59 efried or we could just completely do away with official special treatment, understanding that previously-approved specs will probably require less technical scrutiny just naturally.
16:17:11 mriedem dansmith: i hope i answered your question in https://review.opendev.org/#/c/686047/ and the one after it
16:23:44 dansmith mriedem: not really, but doesn't matter
16:24:55 SonPham hi
16:25:23 SonPham any way to create live-snapshot + keep vms state ( process) ?
16:29:59 gmann ok, i will wait for the new process or let me know if spec sponsor thing is final so that i can add the same in policy spec.
16:37:14 mriedem would be nice if someone can check my assertions here http://lists.openstack.org/pipermail/openstack-discuss/2019-October/009937.html
16:37:19 mriedem i'm writing a bug
16:42:05 openstack Launchpad bug 1846527 in OpenStack Compute (nova) "online_data_migrations docs don't mention using --config-file to run the migrations per cell db" [Undecided,New]
16:42:05 mriedem mgoddard: https://bugs.launchpad.net/nova/+bug/1846527 if that makes sense to you
16:43:57 mgoddard mriedem: the --config-file option is useful, but the upgrade doc doesn't say ODM needs to be run multiple times at all
16:44:43 mriedem multiple times meaning once per cell db right?
16:44:47 mgoddard mriedem: would be nice if it just clearly said "run at least once with an API DB connection, and for each cell (including cell0?)"
16:44:49 mgoddard mriedem: yeah
16:44:53 mriedem right
16:45:19 mgoddard --config-file option makes that easier for some
16:46:55 SonPham hi If I want to suggest a new feature? What do I do after writing the blueprint?
16:47:06 mriedem an --all-cells would make it uber easy for deployment tooling
16:47:10 mriedem *option
16:47:32 mgoddard mriedem: +1
16:47:34 mriedem SonPham: https://docs.openstack.org/nova/latest/contributor/blueprints.html
16:48:28 mgoddard mriedem: is it possible to run ODM for a cell DB before other cells have been upgraded?
16:49:07 mgoddard just wondering about the upgrade one cell at a time scenario, should I include the data migrations as part of that cell's upgrade, or all together at the end?
16:49:07 mriedem possible? sure
16:49:17 mgoddard advisable?
16:49:47 mriedem i'm not sure
16:49:48 mriedem dansmith: ^?
16:50:04 mriedem i would think it's ok to do it per cell upgrade
16:50:12 dansmith mriedem: mgoddard at the end
16:50:24 mgoddard dansmith: ack, thanks
16:50:44 dansmith mriedem: do you mean target the cell and do data migrations just within that cell?
16:50:53 mriedem i think that's the question yeah
16:51:10 dansmith I mean, I guess that's okay, but since they don't need to be run until later, I would just do them later I guess,
16:51:19 dansmith and if the api is all upgraded first then those migrations would be fine
16:51:29 dansmith so I guess either way, but I'd just do it later personally
16:51:33 dansmith mgoddard: ^
16:51:46 mriedem mayhap we should be capturing some of this in the faqs https://docs.openstack.org/nova/latest/user/cells.html#faqs
16:52:06 mriedem not it
16:58:43 efried Does takashin usually propose the move-implemented-specs thing?
16:58:58 efried we're probably ready for that now
17:01:20 mriedem idk, just do it
17:01:22 openstackgerrit Matt Riedemann proposed openstack/nova master: Use scatter/gather in HostAPI.compute_node_get https://review.opendev.org/686442
17:01:34 mriedem takashi usually does the 'prep for the next release' thing
17:01:39 efried fiber mriedem. fiber.
17:01:48 mriedem delegate to someone else to do it
17:01:49 mriedem that's not me
17:02:17 mriedem dude, you want to talk about fiber. i've been eating raisin bran for breakfast and leftover chili for lunch most of this week.
17:02:25 efried ye gods
17:02:34 mriedem i only put together the reason for the side effects last night
17:05:04 sean-k-mooney lol isnit awsome that everything we type is archive for ever :)
17:06:21 dansmith artom: by "double download niggle" you mean "what happens if an image is re-cached" and/or "what happens if two requests come in for the same image quickly" right?
17:06:58 sean-k-mooney dansmith: i assume we have some kind of lock in the image cache to prevent that already right?
17:07:15 dansmith sean-k-mooney: we do, which is what I was going to say when he replied
17:07:47 sean-k-mooney cool ya because if we didnt it would be an issue for booting two vms on the same host concurrenly
17:08:07 dansmith sean-k-mooney: which is what I said in the review when we were discussing this yesterday yes :)
17:08:47 sean-k-mooney i still have that open to review. i got as far as the commit message then got distracted this morining
17:09:11 sean-k-mooney form what i skimed it makes sense to me so far
17:10:28 SonPham after i write the blueprint , i must upload new spec to https://opendev.org/openstack/nova-specs/src/branch/master/specs ?
17:11:46 openstackgerrit Matt Riedemann proposed openstack/nova master: Fix exception translation when creating volume https://review.opendev.org/678991
17:11:51 mnaser is there a point where placement will be the ultimate authority in nova for resource usage
17:11:59 mnaser (like, in the actual reporting too)
17:12:15 mnaser (i understand if no one wrote the code for it yet, but wondering if its more of a "no we wont do that)
17:12:51 mriedem SonPham: yes https://specs.openstack.org/openstack/nova-specs/readme.html
17:13:45 mriedem mnaser: i think that's the utopian goal
17:13:53 mriedem you can already configure nova to use placement for counting cpu and ram usage
17:13:56 artom dansmith, yes
17:13:58 openstackgerrit Stephen Finucane proposed openstack/nova master: WIP: Group IPs by network UUID, not network names https://review.opendev.org/686444

Earlier   Later