Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-02-08
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 melwitt who wants to email the ML
20:09:35 mriedem baby diarreha black
20:09:40 mriedem *diarrhea
20:09:48 dansmith Iwill
20:10:00 dansmith mriedem: is baby diarrhea black?
20:10:00 artom Schoolkid diaorama purple
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.
20:15:50 dansmith jaypipes: and support for bfv instances in nova
20:19:29 openstackgerrit Artom Lifshitz proposed openstack/nova master: api-ref: Add tags to server detail response https://review.openstack.org/431149
20:31:36 cfriesen if I do a "nova delete" on an instance with a mounted cinder volume, is it guaranteed to do a clean shutdown or do I need to do a "nova stop" first to avoid potential disk corruption?
20:32:05 mriedem cfriesen: you shouldn't need to stop a vm before deleting it
20:32:48 sdague mriedem: clean shutdown I think was the critical bit
20:33:02 mriedem hey, i didn't say it "worked"
20:40:05 cfriesen mriedem: sdague: looking at the code, the "nova delete" path calls guest.poweroff(), which calls self._domain.destroy(). The libvirt docs say it sends a SIGTERM then after a "reasonable timeout" a SIGKILL, but that timeout appears to be really small.
20:41:55 cfriesen okay, the libvirt docs describe a virDomainDestroy as the equivalent of having the virtual power cord pulled, so not exactly safe
20:42:27 melwitt cfriesen: I just got to the same conclusion. apparently the VIR_DOMAIN_DESTROY_GRACEFUL flag should be used with destroyFlags to avoid possible corruption. but in that case, it could return an error instead of doing the destroy
20:42:46 cburgess cfriesen Yeah I would say if the concern is data integrity on the volume, you should do a stop first.
20:44:30 mriedem https://www.redhat.com/archives/libvir-list/2012-February/msg00124.html
20:44:54 openstackgerrit Maciej Szankin proposed openstack/nova master: WIP conf: remove invalid TODOs https://review.openstack.org/428811
20:45:00 dansmith I really thought we did a graceful shutdown even on delete
20:45:04 mriedem "Once this patch is in, the recommended method for applications to call virDomainDestroyFlags will be with VIR_DOMAIN_DESTROY_GRACEFUL included. If that fails, then the application can decide if and when to call virDomainDestroyFlags again without VIR_DOMAIN_DESTROY_GRACEFUL (to force the issue with SIGKILL)."
20:45:32 mriedem so, if we have attached volumes, do a graceful destroy, else we don't care?
20:45:38 openstackgerrit Artom Lifshitz proposed openstack/nova master: api-ref: Add tags to server(s) detail response https://review.openstack.org/431149
20:45:49 cburgess dansmith Well we do... but its just not very graceful
20:45:56 gatuus virsh stop vs virsh destroy
20:46:08 dansmith cburgess: I'm talking about an acpi event
20:46:10 cburgess dansmith ahh oh no sorry according to cfriesen we don't my bad.
20:46:35 cburgess dansmith Oh... no I think thats only on stop. I suppose we could call stop first from destroy if the power state is not already stopped or errored.
20:46:41 cburgess mriedem I think ^^ is a better idea.
20:47:03 dansmith I know it was part of phil's original blueprint, but maybe it never got implemented
20:47:05 dansmith I know we do on stop
20:47:08 cburgess The stop logic today as I recall (and reboot) is to send the ACPI event, wait some period of time, and then go hard kill.
20:47:10 dansmith and didn't originally
20:47:18 cfriesen mriedem: yeah, I think that'd make sense to use VIR_DOMAIN_DESTROY_GRACEFUL if we have attached volumes.
20:47:44 cburgess cfriesen Why not call stop internall? That already has logic to attempt to gracefully stop and if that fails hard kill. Then do the cleanup in destroy.
20:47:54 cfriesen dansmith: on stop we currently use virDomainShutdown first, then virDomainDestroy
20:48:23 dansmith cfriesen: I know
20:48:31 cfriesen cburgess: there's no need for a graceful stop if there are no attached volumes
20:48:41 gatuus even virsh will not allow such a corruption
20:48:53 cfriesen cburgess: but yeah, we could make it do a shutdown the same way we do for "nova stop"
20:48:57 cburgess cfriesen I agree but again rather then having different logic for being graceful, why not simple say if volumes, call stop, then destroy.
20:49:19 cburgess cfriesen Right. Then we don't have to implement a 2nd 'be graceful' routine.
20:50:04 openstackgerrit Artom Lifshitz proposed openstack/nova master: api-ref: Add tags to server(s) detail response https://review.openstack.org/431149
20:50:26 cfriesen okay....does this need a spec, just a blueprint, or is it a bugfix?
20:50:48 dansmith it's not just a bugfix, IMHO
20:51:00 dansmith and I'm not sure we can call stop without some real refactoring
20:51:13 cburgess That might true
20:51:24 cburgess Some of the logic might need to come out into its own function that can be shared with destroy
20:51:50 melwitt does mounting a volume in the vm mean it has to be attached from nova's perspective? like mounting of a shared drive?
20:52:03 openstackgerrit Artom Lifshitz proposed openstack/nova master: api-ref: Add tags to server(s) detail response https://review.openstack.org/431149
20:52:31 cfriesen melwitt: you're thinking some non-cinder volume?
20:52:44 melwitt cfriesen: yeah
20:53:02 cfriesen melwitt: right, for something like that you'd want a clean shutdown even if there aren't any cinder volumes attached.

Earlier   Later