| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-08 | |||
| 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 | |
| 20:04:52 | melwitt | dansmith: oh, yeah. if it's just me and you then we don't need to meet. mriedem would be the only potential other person if the rest are out today | |
| 20:05:39 | mriedem | humbug | |
| 20:07:00 | melwitt | I'm cool with skipping. just if mriedem had anything to discuss. from me I'm doing edits to the step-by-step examples and another patch for cells v1 step-by-step | |
| 20:07:34 | mriedem | i probably need to update the wiki, some of the stuff out there is already done | |
| 20:07:49 | mriedem | i think we're basically in get ocata out the door mode and then start preparing for ptg topics | |
| 20:08:17 | mriedem | plus i'm just generally tired and cranky right now | |
| 20:08:22 | dansmith | same | |
| 20:08:26 | dansmith | so cancel then? | |
| 20:08:36 | mriedem | 2nd | |
| 20:09:04 | mriedem | as in yes | |
| 20:09:12 | dansmith | motion passes. next order of business: we need to decide on the color of the shed | |
| 20:09:35 | mriedem | baby diarreha black | |
| 20:09:35 | melwitt | who wants to email the ML | |
| 20:09:40 | mriedem | *diarrhea | |
| 20:09:48 | dansmith | Iwill | |
| 20:10:00 | artom | Schoolkid diaorama purple | |
| 20:10:00 | dansmith | mriedem: is baby diarrhea black? | |
| 20:10:13 | mriedem | dansmith: the first shit they take once their born is yes | |
| 20:10:18 | mriedem | *they're | |
| 20:10:24 | tbachman | baby got (diarrhea) black | |
| 20:10:34 | mriedem | Meconium | |
| 20:10:52 | artom | mriedem, that's technically meconium, not shit </pedant> | |
| 20:10:59 | mriedem | i'd like to start a new openstack big tent project and call it Meconium | |
| 20:11:06 | mriedem | artom: meh | |
| 20:11:10 | artom | Bah, and there you go jinxing me while I look up the damn spelling | |
| 20:11:47 | dansmith | that is .. not a thing I needed to know | |
| 20:11:57 | artom | mriedem, the first release will change the world, but after that it's all shit? | |
| 20:12:06 | mriedem | artom: heh | |
| 20:12:08 | cdent | artom++ | |
| 20:14:13 | mriedem | dansmith: jaypipes: also, fyi, i emailed the foundation people back about this boston ocata recap session asking if it was required or "optional" - so far no reply | |
| 20:14:27 | mriedem | probably trying to figure out the best way to say yes it's optional but not really | |
| 20:14:30 | jaypipes | mriedem: kk | |
| 20:15:05 | dansmith | it's probably "optional" but not optional | |
| 20:15:38 | jaypipes | dansmith: you know, like MySQL in OpenStack. | |