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