| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-10-03 | |||
| 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 | mriedem | possible? sure | |
| 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: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 | |
| 17:14:05 | artom | dansmith, the second one, specifically | |
| 17:14:16 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Add a placement audit command https://review.opendev.org/670112 | |
| 17:14:30 | mnaser | wait, really (about nova for counting cpu and ram usage) | |
| 17:14:34 | mriedem | artom: also note that the windriver krew added a semaphore on image downloads awhile back | |
| 17:14:46 | mriedem | i think by default it's unbounded but they use it to serialize at edge sites | |
| 17:15:07 | mriedem | https://docs.openstack.org/nova/latest/configuration/config.html#compute.max_concurrent_disk_ops | |
| 17:15:30 | artom | mriedem, if that does what I think it does, then that's the piece I was missing | |
| 17:15:43 | bauzas | mriedem: gibi: dansmith: I know you folks are pretty busy those days but reviews would be appreciated for https://review.opendev.org/#/c/670112 | |
| 17:15:50 | bauzas | (placement audit command) | |
| 17:15:52 | mriedem | mnaser: https://docs.openstack.org/nova/latest/configuration/config.html#quota.count_usage_from_placement | |
| 17:16:03 | mriedem | artom: note that's relatively new, | |
| 17:16:09 | artom | Although if set to 2 or more, it doesn't strictly speaking solve the simultaneous requests for the same image problem | |
| 17:16:10 | mriedem | the image cache might already have a lock on the image id | |
| 17:16:23 | bauzas | mriedem: gibi: dansmith: it's now in a good shape with a few functests, so before I'm writing unittests, I'd appreciate comments | |
| 17:16:23 | mriedem | if only the code were freely available and online... | |
| 17:16:25 | SonPham | any way to make a snapshot keep vms state? | |
| 17:16:41 | artom | But... since booting an image had the same problem, we probably have something in place fo that | |
| 17:16:43 | artom | *for | |
| 17:16:48 | dansmith | artom: ack, then it's already handled by a lock.. I looked it up but didn't call it out in the spec because it's existing | |
| 17:16:54 | dansmith | artom: so just FYI | |
| 17:17:03 | mnaser | mriedem: oh neat, that's pretty cool | |
| 17:17:06 | artom | mriedem, aww, but it's way more fun to blindly rant and speculate | |
| 17:17:36 | artom | dansmith, yeah that's fair, thanks for taking the time to look it up | |
| 17:18:44 | mriedem | artom: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/imagebackend.py#L257 i think? | |
| 17:19:48 | artom | mriedem, looks like it, yeah | |
| 17:20:06 | artom | That imagecache code though... *shudder* | |
| 17:20:14 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Add a placement audit command https://review.opendev.org/670112 | |
| 17:20:27 | mriedem | dansmith: that reminds me, one thing we'll likely want documented with using your thing is making sure a service user token is configured to avoid the user token timing out while triyng to download an image across a bunch of computes | |
| 17:20:42 | mriedem | https://docs.openstack.org/nova/latest/admin/support-compute.html#user-token-times-out-during-long-running-operations | |
| 17:21:00 | dansmith | mriedem: ack | |
| 17:23:30 | mriedem | bauzas: easy and fast -1 from me | |
| 17:23:33 | mriedem | you're welcome | |
| 17:25:29 | mnaser | but i dont think a token timing out during download might an issue | |
| 17:25:38 | mnaser | cause the request will be done with the download is done anyways | |
| 17:25:47 | mnaser | i think image upload are an issue for things like submitting properties/etc when dnoe | |
| 17:26:41 | dansmith | mnaser: we're talking about image pre-caching, where the process may take an hour | |
| 17:26:59 | dansmith | mnaser: so by the time the last compute starts doing the work, the token may have expired and it can't pull the image | |
| 17:27:20 | mnaser | oh i see, this isnt necessarily the on-vm-launch thing | |
| 17:27:21 | mriedem | lyarwood: i'm not sure i got your question correct in https://review.opendev.org/#/c/541420/ | |
| 17:27:32 | dansmith | mnaser: unrelated to vm launch entirely | |
| 17:27:39 | mnaser | okay, right :> | |
| 17:28:48 | dansmith | mnaser: is image pre-caching a thing you care about btw? I think your cloud is too general purpose to care maybe, but... ? | |
| 17:29:23 | dansmith | or you use ceph so not a thing anyway | |
| 17:29:25 | mnaser | dansmith: i think in our case most of our stuff is ceph based, and yeah, too general purpose to have images precached *but* it might be something as we are considering having VMs that are entirely local storage | |