Earlier  
Posted Nick Remark
#openstack-nova - 2017-02-08
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
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

Earlier   Later