| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-11-08 | |||
| 15:07:30 | mriedem | your new one is a dupe | |
| 15:08:05 | melwitt | ah dangit | |
| 15:08:24 | melwitt | I didn't know there was already a bug related to that | |
| 15:08:31 | melwitt | ok let me update | |
| 15:08:42 | mriedem | i think i pointed it out in your functional test that changed from sleep to use the oslo stuff, but sure :) | |
| 15:09:07 | melwitt | you did but it didn't register in my brain somehow | |
| 15:09:22 | mriedem | it was pre-halloween so i only speak in riddles | |
| 15:09:45 | mriedem | take a peek at this patch, it holds the key to the answers you seek | |
| 15:09:51 | mriedem | *smoke bomb* | |
| 15:10:02 | melwitt | lol | |
| 15:13:04 | melwitt | mriedem: hey, that patch is mine, not gibi_ptg's (lp comment) :P | |
| 15:14:06 | openstackgerrit | melanie witt proposed openstack/nova master: Replace time.sleep(10) with service forced_down in tests https://review.opendev.org/692252 | |
| 15:15:28 | dansmith | lyarwood: do you know anything about how bcache actually works? | |
| 15:16:05 | mriedem | melwitt: oh heh, i saw you said gibi above so assumed it was his | |
| 15:16:19 | melwitt | I said he was +2 on it | |
| 15:16:34 | mriedem | yeah, sorry | |
| 15:16:38 | mriedem | commented in lp for posterity | |
| 15:16:58 | melwitt | yesss | |
| 15:21:17 | lyarwood | dansmith: nope not bcache or CAS tbh | |
| 15:22:35 | dansmith | lyarwood: well, CAS is six months old and just exists as source to create kernel modules, so I assume we can ignore that | |
| 15:22:50 | dansmith | lyarwood: bcache requires a specially-formatted backing device.. it's not transparent | |
| 15:23:35 | dansmith | lyarwood: meaning brick would have to *convert* your volume before hooking it up under bcache, and then apparently it's difficult to reverse if you attach that volume elsewhere that isn't using bcache | |
| 15:23:54 | dansmith | which to me makes it nearly useless for nova | |
| 15:32:42 | melwitt | seems like the gate is back to being angry again | |
| 15:42:15 | mriedem | efried: i did my professional sleuthing on that arcane NOTE in the resource tracker https://review.opendev.org/#/c/693435/ - let me know if you want me to just address those comments inline or follow up | |
| 15:42:21 | mriedem | tl;dr the note should be removed | |
| 15:44:41 | efried | ack, thanks. | |
| 15:48:18 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/rocky: doc: fix and clarify --block-device usage in user docs https://review.opendev.org/693554 | |
| 15:49:30 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/rocky: Revert "openstack server create" to "nova boot" in nova docs https://review.opendev.org/693240 | |
| 15:49:30 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/rocky: doc: fix and clarify --block-device usage in user docs https://review.opendev.org/693554 | |
| 15:58:44 | lyarwood | dansmith: sorry calls-- , agreed on CAS, seems like it's the main driver behind Intel looking into this even if it's brand spanking new. | |
| 15:58:57 | lyarwood | dansmith: eww okay so bcache also wouldn't work | |
| 15:59:10 | dansmith | lyarwood: yes, another "sell more hardware" feature for nova for sure:/ | |
| 16:00:01 | dansmith | lyarwood: yeah, so I think the only way to do this reasonably is with CAS, which is crazy new and unproven, would require compiling kernel modules from source, etc | |
| 16:00:05 | mriedem | when is the last time zvm or powervm ci actually reported and worked? is it time for a warning log on startup of those drivers? | |
| 16:00:22 | lyarwood | dansmith: isn't dm-cache also an option here? | |
| 16:00:28 | dansmith | lyarwood: I love their FAQ page which says "Why do filesystem benchmark tools report that there is disk corruption? Oh don't worry about those silly errors!" | |
| 16:00:38 | lyarwood | L O L | |
| 16:00:39 | dansmith | lyarwood: not AFAIK, see my comments | |
| 16:01:07 | dansmith | lyarwood: dm-cache is static partitioning only as far as I know.. i.e. one cache device per block device to be cached | |
| 16:02:10 | lyarwood | dansmith: ack | |
| 16:02:32 | mriedem | oh i see a recent zvm ci job, took 2 hours, failed | |
| 16:03:33 | dansmith | mriedem: no (real) changes to either of them in 2019 either, as far as I can tell. I bet that doesn't mean "they just work and have happy customers" either :) | |
| 16:03:53 | efried | mriedem: +2 but prefer fix-here | |
| 16:04:18 | dansmith | the most recent change to zvm was "add get console support" which was part of the original set of work, IIRC, from feb 2018 | |
| 16:04:25 | mriedem | huh zvm ci passed on an earlier patch set in the same change, the latter ps ci failure was due to ssh failing on some guests | |
| 16:04:32 | mriedem | i'm surprised they even enable ssh validatoin in their tempest runs | |
| 16:04:46 | mriedem | yeah zvm in tree is mostly not a usable driver | |
| 16:04:53 | mriedem | create, get console, destroy | |
| 16:04:58 | dansmith | yeah | |
| 16:05:21 | dansmith | I believe I called that as abandonware before we merged :) | |
| 16:05:47 | mriedem | efried: i can do it in there, it just means rebasing and pushing the other 3 changes on top as well | |
| 16:05:57 | mriedem | which likely means i'll be doing rechecks | |
| 16:06:01 | efried | oh | |
| 16:06:10 | efried | then I guess fup it | |
| 16:06:24 | efried | unless it waits too long to get another +2 | |
| 16:06:50 | mriedem | yeah if i have to resolve a merge conflict obviously i'd fix there, but i'll fup for now | |
| 16:07:04 | mriedem | dansmith: you just still have s390x ptsd from your early days | |
| 16:07:27 | mriedem | remember, they were doing virtualization since before it was hip | |
| 16:07:43 | dansmith | no, I have ptsd from all of ibm's drivers | |
| 16:07:46 | melwitt | mriedem: we had to ask them to enable ssh validation bc otherwise their config drive stuff could not be tested | |
| 16:07:54 | mriedem | melwitt: ah that's right | |
| 16:08:18 | mriedem | the powervm driver in tree can at least do some things, but i haven't seen ci working for it in years | |
| 16:09:13 | mriedem | looks like maintenance of the out of tree driver has basically been farmed out https://github.com/openstack/nova-powervm/commits/master | |
| 16:14:21 | openstackgerrit | Merged openstack/nova master: Replace time.sleep(10) with service forced_down in tests https://review.opendev.org/692252 | |
| 16:16:50 | openstackgerrit | Matt Riedemann proposed openstack/nova master: FUP for Ib62ac0b692eb92a2ed364ec9f486ded05def39ad https://review.opendev.org/693556 | |
| 16:20:50 | openstackgerrit | Lee Yarwood proposed openstack/nova master: compute: Use long_rpc_timeout in reserve_block_device_name https://review.opendev.org/693537 | |
| 16:22:06 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Convert nova-live-migration job to zuulv3 https://review.opendev.org/693364 | |
| 16:39:38 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove service_uuids_online_data_migration https://review.opendev.org/693421 | |
| 16:51:53 | openstack | bugzilla.redhat.com bug 1761864 in openstack-nova "[RFE] Preemtable Instances" [High,New] - Assigned to smooney | |
| 16:51:53 | sean-k-mooney | mriedem: i filed https://bugzilla.redhat.com/show_bug.cgi?id=1761864 to track adding support for it at somepoint but its in our backlog and not prioritised yet. | |
| 16:52:12 | sean-k-mooney | actully that should not have an assignee | |
| 16:53:02 | sean-k-mooney | dansmith: bcache is pretty stable | |
| 16:53:09 | sean-k-mooney | dansmith: i have been using it for years | |
| 16:53:26 | dansmith | sean-k-mooney: didn't say it wasn't | |
| 16:54:24 | sean-k-mooney | true | |
| 16:54:33 | sean-k-mooney | vs dm-cache i found bcache more flexible | |
| 16:54:39 | dansmith | yup | |
| 16:55:10 | sean-k-mooney | dm-cache also has a longer warmup time but when both caches are hot they perform about the same | |
| 16:55:35 | sean-k-mooney | the bcache dev has moved on to make a bcache file system. | |
| 16:56:26 | sean-k-mooney | bcache is still mainatined upstream in the kernel but they change there focus because tehy though it was feature complete | |
| 16:56:55 | sean-k-mooney | https://bcachefs.org/ | |
| 16:57:19 | sean-k-mooney | i would not really use ^ if you like your data yet | |
| 16:58:41 | sean-k-mooney | dansmith: what was the context for the bcache disucssion? | |
| 16:58:59 | sean-k-mooney | is someone asking us to use it to cache remote volumes? | |
| 16:59:01 | dansmith | sean-k-mooney: the spec proposed for volume caching | |
| 16:59:46 | sean-k-mooney | ah that might work for isci volumes | |
| 16:59:58 | sean-k-mooney | we mount those via the kernel right? | |
| 17:00:10 | sean-k-mooney | rather then natively in qemu | |
| 17:00:24 | dansmith | it won't, IMHO, because bcache requires the volumes to be a special format, AFAICT | |
| 17:00:30 | dansmith | which is in the backscroll and the comments on that spec | |
| 17:01:19 | sean-k-mooney | oh right so it did not requrie that orginally | |
| 17:01:43 | sean-k-mooney | but the current version i think require teh backing volume to be converted | |
| 17:01:49 | dansmith | their pre-merge docs all talk about it, so it's been that way for quite a while | |
| 17:01:53 | dansmith | but..yeah | |
| 17:02:17 | sean-k-mooney | well when i first used bcache a few years ago they allowed you to cache an existing volume | |
| 17:02:31 | sean-k-mooney | but they remove that as it lead to data curruption in some cases i think | |
| 17:03:14 | sean-k-mooney | the idea of having fast local storage cache network volumes does have merrit but ya its hard to get right | |
| 17:04:09 | sean-k-mooney | this spec right https://review.opendev.org/#/c/689070/2/specs/ussuri/approved/support-volume-local-cache.rst | |
| 17:05:00 | dansmith | sean-k-mooney: doesn't work for multi-attach, or rbd, or the future where we use qemu-integrated iscsi, and can be done inside the guest with local ssd ephemeral disks | |