| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-08 | |||
| 17:46:28 | dansmith | it depends on the wsgi patch | |
| 17:46:36 | dansmith | but nothing to unpin nova afaict | |
| 17:46:42 | dansmith | even though it says it does | |
| 17:48:07 | EmilienM | cdent: the exact same in theory | |
| 17:48:17 | cdent | "in theory"? | |
| 17:48:27 | EmilienM | yeah, the version of openstack-nova rpm was the same | |
| 17:48:36 | dansmith | it doesn't depend on the wsgi patch actually | |
| 17:48:45 | dansmith | it depends on the nova canary that was depending on the wsgi patch | |
| 17:48:47 | EmilienM | but 'delorean' builds packages from git master so maybe something merged in the meantime? | |
| 17:48:57 | EmilienM | dansmith: yeah it's a canary | |
| 17:49:13 | dansmith | EmilienM: but why depend on the nova patch that does nothing from the tripleo patch? | |
| 17:49:32 | EmilienM | dansmith: to run a job that didn't run in nova gate | |
| 17:49:34 | EmilienM | dansmith: ovb-ha | |
| 17:49:54 | EmilienM | check experimental in nova doesn't run ovb-ha | |
| 17:49:56 | dansmith | EmilienM: how does the depends-on accomplish that? | |
| 17:50:26 | dansmith | EmilienM: I don't think anything is likely to have merged related to this in the last few hours, and even still, if you're not testing the rc1 branch you're not testing ocata anyway | |
| 17:50:59 | EmilienM | dansmith: our Ci tooling read Zuul env and build packages | |
| 17:51:15 | dansmith | EmilienM: if you wanted the nova experimental job to run on the tripleo change the depends-on should go the other way no? | |
| 17:51:24 | EmilienM | dansmith: right, gimme some hours to figure if it works now and if it's not racy & if it's stable | |
| 17:51:55 | EmilienM | I wanted to see ovb-ha so I did https://review.openstack.org/#/c/430571/ which depends-on a nova patch | |
| 17:52:43 | EmilienM | so our ci tooling built the nova patch and ran ovb-ha | |
| 17:52:51 | EmilienM | and it failed. That's the logs we investigated this morning | |
| 17:53:03 | EmilienM | but I did recheck and it pass | |
| 17:53:09 | EmilienM | that's where we are now | |
| 17:53:56 | dansmith | that's not how depends-on works for any other jobs that I know of, but okay | |
| 17:54:33 | oomichi | mriedem: one comment on https://review.openstack.org/#/c/430497 | |
| 18:02:18 | oomichi | Kevin_Zheng: gmann puts a question on https://review.openstack.org/#/c/403568/18/nova/compute/manager.py | |
| 18:16:45 | mriedem | oomichi: replied | |
| 18:16:56 | oomichi | sfinucan: can you take a look at https://review.openstack.org/#/c/389338/ again ? | |
| 18:17:29 | dansmith | mriedem: can you re-hit https://review.openstack.org/430354 ? | |
| 18:18:34 | sfinucan | oomichi: Done and done | |
| 18:18:43 | oomichi | sfinucan: thanks :) | |
| 18:18:56 | cfriesen | dansmith: can you check my question earlier about commit 2c0a306? I think that was your commit. | |
| 18:18:58 | sfinucan | any time :) | |
| 18:19:22 | mriedem | dansmith: yeah | |
| 18:19:42 | mriedem | gabor_antal: fyi https://review.openstack.org/#/c/389338/ | |
| 18:19:46 | openstackgerrit | John Garbutt proposed openstack/nova master: Default live_migration_progress_timeout to off https://review.openstack.org/429798 | |
| 18:20:10 | gabor_antal | mriedem: thanks, I already saw that patchset :) | |
| 18:20:29 | gabor_antal | And built mine on the top of it: https://review.openstack.org/#/c/431030/ | |
| 18:22:14 | dansmith | cfriesen: yeah, it probably did drop a little of that, although libvirt was spawn'ing in its driver too, so just adding those to the helper thread might affect more behavior than you expect | |
| 18:24:13 | cfriesen | dansmith: looking at @wrap_instance_event in particular, won't that generate start/finish events potentially before we even do any work? | |
| 18:24:42 | dansmith | cfriesen: yeah, but that didn't wait until it was complete before anyway because libvirt was doing its own spawn'ing | |
| 18:25:28 | cfriesen | dansmith: fair enough, but we used to at least do the pre_live_migration stuff before that spawn in libvirt | |
| 18:25:57 | dansmith | cfriesen: well, we also used to exhaust the rpc worker pool, but.. yeah :) | |
| 18:26:55 | cfriesen | dansmith: the reason I noticed this was we tried using the same model with cold migrations, but got bit by no longer having the errors_out_migration wrapper | |
| 18:28:08 | dansmith | cfriesen: looks like the other drivers were all synchronous, so maybe just moving it to the thread function would be okay, but it's definitely another change | |
| 18:29:10 | cfriesen | dansmith: okay, thanks for the retrospective. | |
| 18:35:35 | oomichi | mriedem: thanks, replied again | |
| 18:35:50 | cfriesen | mdbooth: you around? | |
| 18:36:14 | oomichi | sdague: can you take a look at https://review.openstack.org/#/c/389338/ again ? | |
| 18:39:47 | openstackgerrit | John Garbutt proposed openstack/nova master: Remove stuck live-migration detection https://review.openstack.org/430218 | |
| 19:00:18 | jaypipes | mdbooth, dansmith, mriedem1: in your opinion, has boot-from-volume been the "feature" added to Nova that has resulted in the most bugs, non-cloudy behaviour, and general hackiness? | |
| 19:00:42 | dansmith | jaypipes: it's definitely up there on the list | |
| 19:00:45 | dansmith | and one of my most hated | |
| 19:02:02 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Run api sample tests against 2.latest https://review.openstack.org/430352 | |
| 19:02:42 | alaski | jaypipes: dansmith +1 | |
| 19:04:30 | melwitt | it's so notorious we had to acronym it: bfv | |
| 19:04:45 | mriedem | non-cloudy behavior? | |
| 19:04:57 | mriedem | seems more cloudy than shelve... | |
| 19:05:14 | mriedem | the combination of ways to boot from volume and attach block devices is insane though | |
| 19:05:31 | dansmith | to me, bfv is 100% non-cloudy | |
| 19:05:43 | dansmith | so I'm not sure how something can be less cloudy | |
| 19:05:56 | dansmith | equally uncloudy perhaps | |
| 19:06:24 | mriedem | because there is a volume involved? | |
| 19:06:58 | alaski | I think it would be a perfectly cromulent feature if Nova was not involved in managing the lifecycle of the volume at all | |
| 19:07:56 | dansmith | no, volumes are fine | |
| 19:08:06 | mriedem | yeah so i'm asking to distinguish the orchestration vs having a volume attached | |
| 19:08:08 | dansmith | volumes in general I mean | |
| 19:08:29 | mriedem | also, wtf does cromulent mean? | |
| 19:08:30 | dansmith | actually, tbh, shelve is really not as bad | |
| 19:08:52 | dansmith | shelve is mostly a snapshot/restore workflow optimization | |
| 19:09:00 | dansmith | bfv is for building pets | |
| 19:12:46 | mriedem | where do quotas rank? | |
| 19:12:58 | mriedem | in the pantheon of hacks and bugs? | |
| 19:13:03 | openstackgerrit | melanie witt proposed openstack/nova master: Edits for Cells V2 step-by-step examples https://review.openstack.org/431115 | |
| 19:13:45 | alaski | quotas go to 11 IMO | |
| 19:13:58 | melwitt | haha | |
| 19:15:47 | mriedem | like spinal tap 11? | |
| 19:16:09 | alaski | yeah | |
| 19:17:11 | cfriesen | dansmith: why is bfv less cloudy than volumes generally? | |
| 19:18:34 | jaypipes | mdbooth, lyarwood: thank you SO much for getting me reading all these bugs about boot-from-volume and detaching root volumes :P | |
| 19:18:37 | cfriesen | is a pet volume any less of a pet than a pet instance? | |
| 19:19:00 | dansmith | cfriesen: volumes are for storing persistent data, bfv is for building instances with configured state i.e. not repeatable, and not cattle | |
| 19:19:20 | dansmith | cfriesen: no you can commit the same crime with a knife as a gun | |
| 19:19:55 | jaypipes | cfriesen: volumes used as persistent storage of your data is still cloudy. boot-from-volume isn't cloudy because you're coupling your application state with your configuration state. | |
| 19:20:03 | jaypipes | cfriesen: and what dansmith said :) | |
| 19:20:14 | dansmith | exactly | |
| 19:24:35 | cfriesen | jaypipes: dansmith: what if you didn't store everything on the boot volume? I mean you could still bfv and then attach a separate volume for persistant data. This might be useful in an environment with little local storage on the compute nodes. | |
| 19:24:44 | cfriesen | (probably not the common case though) | |
| 19:25:22 | dansmith | cfriesen: then use centralized storage for your ephemeral (root) disks | |
| 19:25:50 | cfriesen | dansmith: fair enough | |
| 19:27:26 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Allow None for block_device_mapping_v2.boot_index https://review.openstack.org/430497 | |
| 19:28:19 | jaypipes | alaski: btw, fantastic use of the word cromulent. | |
| 19:37:12 | cdent | surely it was a perfectly cromulent use of cromulent? | |
| 19:42:42 | sdague | of all the people that I thought would be stumped by cromulent, mriedem was not one of them | |
| 19:58:19 | dansmith | mriedem: I actually prefer the ambiguous language because I think changing those values at runtime is likely to be rare, have unpredictable results, and different behavior soon when we make the cells cache properly age | |
| 19:58:34 | dansmith | mriedem: so ready my arguments and if you feel strongly then I'll just change it and complain later | |
| 20:00:38 | artom | Hrmm, I think we forgot to document 'tags' in the server details response as of 2.26... | |
| 20:03:25 | dansmith | melwitt: what do you think about a cells meeting? dtp and bauzas are out and other people have other stuff going on | |
| 20:03:40 | dansmith | melwitt: so I think it would just be the two of us and I'm not sure what we'd discuss | |