| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-11-08 | |||
| 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 | |
| 17:05:10 | dansmith | but yes, I understand caching and why it's desirable | |
| 17:05:20 | sean-k-mooney | ya just looking at the spec now | |
| 17:05:20 | dansmith | yes, that's the spec | |
| 17:05:47 | sean-k-mooney | a better way to arrpoch this woudl be to add a feature to qemu/libvirt | |
| 17:06:05 | sean-k-mooney | so that we could tell qemu to use a device as a cache for another | |
| 17:08:18 | dansmith | sean-k-mooney: yep, but the spec is actually "sell moar intel SSDs through new feature for obscure brand new opensource caching project" | |
| 17:09:46 | sean-k-mooney | funnaily enough i just baught one of those ssds to use a a bcache device in front of the raid5 i use for my cinder lvm backend | |
| 17:10:25 | mriedem | hardware nerd alert | |
| 17:11:22 | sean-k-mooney | hehe it helps hide that my vms are on spinning rust and with random io but its not ssd speed by any means | |
| 17:11:44 | mriedem | you mean you haven't gone plaid yet? | |
| 17:12:27 | sean-k-mooney | plaid ? as in the shirt matail or intels 3d cross point | |
| 17:12:33 | mriedem | as in spaceballs | |
| 17:12:33 | sean-k-mooney | aka optane | |
| 17:12:38 | mriedem | https://www.youtube.com/watch?v=mk7VWcuVOf0 | |
| 17:14:47 | sean-k-mooney | ha i should really watch that sometime | |
| 17:15:45 | mriedem | "emergency stop - never use" | |
| 17:15:46 | mriedem | classic | |
| 17:15:48 | mriedem | it's like software | |
| 17:58:03 | openstack | Launchpad bug 1851871 in OpenStack Compute (nova) "Functional tests intermittently fail with "TypeError: Can't upgrade a READER transaction to a WRITER mid-transaction" during service destroy" [Undecided,New] | |
| 17:58:03 | mriedem | gate bug fun https://bugs.launchpad.net/nova/+bug/1851871 | |
| 21:16:13 | openstackgerrit | Merged openstack/nova master: Use admin neutron client to see if instance has qos ports https://review.opendev.org/691900 | |
| 22:29:28 | efried | okay, where do I get a VM image I can actually do something with? | |
| 22:29:44 | efried | like run python | |
| 22:42:28 | efried | jroll: I'm off PoCing vTPM and am at the point where it would be nice to be able to run $test_program that uses one so I can tell if it's "working". Before I go trying to hack something together (and wind up not even knowing whether it's doing what it's supposed to) do you (or could you obtain/create) something easy? | |
| 22:42:38 | efried | The "hello world" of tpm | |
| #openstack-nova - 2019-11-09 | |||
| 15:08:08 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Convert nova-live-migration job to zuulv3 https://review.opendev.org/693364 | |
| #openstack-nova - 2019-11-10 | |||
| 14:29:29 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove TODOs around claim_resources_on_destination https://review.opendev.org/693635 | |
| 14:31:45 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove TODOs around claim_resources_on_destination https://review.opendev.org/693635 | |
| 14:43:51 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Resolve TODO in _remove_host_allocations https://review.opendev.org/693636 | |
| 15:47:46 | openstackgerrit | Brin Zhang proposed openstack/nova-specs master: Add flavor extra specs group https://review.opendev.org/663563 | |
| 19:29:27 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove TODOs around claim_resources_on_destination https://review.opendev.org/693635 | |
| 21:15:34 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Fix driver tests on Windows https://review.opendev.org/518525 | |
| #openstack-nova - 2019-11-11 | |||
| 05:30:19 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Update keypairs in saving an instance object https://review.opendev.org/683043 | |
| 06:58:52 | openstackgerrit | Brin Zhang proposed openstack/nova master: libvirt:driver:Disallow AIO=native when 'O_DIRECT' is not available https://review.opendev.org/682772 | |
| 07:36:01 | openstackgerrit | ya.wang proposed openstack/nova-specs master: Add spec for live migration no performance impact. https://review.opendev.org/693655 | |
| 07:38:48 | danil | hello folks. Please help me. Is there a way to get nova client through openstacksdk? I mean that I can not just use novaclient library due to dependencies. Thanks | |
| 09:46:28 | danil | hello folks. Please help me. Is there a way to get nova client through openstacksdk? I mean that I can not just use novaclient library due to dependencies. Thanks | |
| 12:47:00 | brinzhang | dansmith: efried: In nova PTG in Shanghai we talked about this spec https://review.opendev.org/#/c/663563/, and we reached the agreement on this feature, you can see ML/Etherpad https://etherpad.openstack.org/p/nova-shanghai-ptg http://lists.openstack.org/pipermail/openstack-discuss/2019-November/010643.html | |
| 12:47:22 | jroll | efried: I don't have anything, may be able to get something but not sure it'll be simple :) this might be a reasonable starting point: https://github.com/tpm2-software/tpm2-tools/wiki/Getting-Started | |
| 12:47:44 | jroll | efried: if you don't like the looks of that, I can bug an expert here | |
| 12:48:00 | brinzhang | dansmith: efried: I was updated (re-write) this spec, please review again (there are -2 on it now) | |
| 13:38:39 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove TODO from ComputeTaskManager._live_migrate https://review.opendev.org/693696 | |
| 14:01:48 | Erdosip | Hy! | |
| 14:03:48 | Erdosip | I would like to investigate about CEPH multiple pool support in the same nova process.. AFAIK this is not supported now, since nova only able to use one RBD, but we would like to use multiple... Are there any technical problems with this, to implement? | |
| 14:04:43 | Erdosip | I would like to investigate about CEPH multiple pool support in the same nova process.. AFAIK this is not supported now, since nova only able to use one RBD pool, but we would like to use multiple... Are there any technical problems with this, to implement? | |
| 14:05:57 | Erdosip | (sorry, i thinked, i can edit my previous message...) | |
| 14:23:51 | mriedem | Erdosip: this is likely a better question for the openstack-discuss mailing list, tag the subject line with [nova] so it's filtered properly | |
| 14:24:11 | Erdosip | okay, thanks! | |
| 14:29:10 | sean-k-mooney | Erdosip: the only way to connect to multiple cephs form the same nova host today is via cinder today as far as i know | |
| 14:30:00 | sean-k-mooney | i dont know what it would take to support it with the rbd image backend but as mriedem says if you ask on the mailing list someone more familar with that may respond | |
| 14:33:21 | dansmith | brinzhang_: skimming your changes, it does not look like my core concerns are addressed, so I'll leave my -2 on there | |
| 14:52:01 | efried | brinzhang_: I'll look again | |
| 14:53:07 | efried | jroll: oh, nice, good link, will read. | |
| 14:54:11 | jroll | :) | |
| 14:55:07 | dansmith | Erdosip: I've planned to add a tiny bit of multiple-pool support to nova when glance becomes able to replicate images in multiple pools | |
| 14:55:54 | dansmith | Erdosip: but it would just be the ability to know about multiple pools, there'd still be one "primary" pool that nova tries to get everything into in order to use them | |
| 14:56:31 | efried | jroll: I've gotten to the point where I can create an encrypted vTPM. I had found another "hello world" type script out there. It runs seamlessly whether encrypted or not -- that is, afaict the encryption/decryption happens at the libvirt level, and is transparent from the perspective of the VM. | |
| 14:56:55 | jroll | \o/ | |
| 14:57:01 | jroll | efried: cool, that makes sense to me | |
| 14:57:10 | efried | There have been some points of awkwardness thus far, including the need to recycle the libvirtd service before it'll pick up the "secret" | |
| 14:57:15 | jroll | or rather, aligns with how I understood the encrypted vtpm bits | |
| 14:57:19 | jroll | eek | |
| 14:57:23 | efried | Which would kind of be ... yeah, eek. | |
| 14:57:49 | jroll | I hope that's an unintentional bug :) | |
| 14:57:51 | efried | I'm still playing; it may be the case that creating the secret via the API rather than CLI could circumvent that -- not sure. | |
| 14:58:30 | efried | but even then, I'm still worried about your security requirements being satisfied here. | |
| 14:59:06 | efried | You create a "secret" in libvirt and give it a value. And then you create the libvirt XML with the UUID of that secret. And... that's it. There never seems to be a need to retype that secret value. | |
| 14:59:23 | dansmith | efried: libvirt's cli is just an api client, in case you didn't know | |
| 14:59:32 | dansmith | efried: virsh is, I mean | |
| 14:59:43 | efried | dansmith: I figured, point being to do it from the same process as wants to use the secret | |
| 15:00:08 | efried | sorry, I wasn't clear on that: use the libvirt API from within nova, rather than me typing in the CLI for my PoC. | |
| 15:00:12 | jroll | efried: huh, yeah, I wonder where libvirt keeps that secret | |
| 15:00:22 | efried | jroll: well, it keeps it in a file in a directory. | |
| 15:00:30 | jroll | sigh. | |
| 15:00:34 | dansmith | efried: yeah and my point is virsh and nova look the same to libvirtd, which is the thing that manipulates the guests, xmls, etc | |
| 15:00:39 | jroll | the secret itself is in a file? | |
| 15:01:37 | sean-k-mooney | efried: ideally you would want to store the secret in the hosts tpm rather then on disk | |
| 15:01:51 | efried | dansmith: Okay, I think I understand what you're saying. There's just one libvirtd "server side" and it hears things the same way whether through API or virsh. | |
| 15:02:12 | dansmith | efried: virsh is just an api client like nova, but yes that's what I'm saying | |
| 15:02:13 | efried | jroll: Yes, the secret is in a file. Presumably the fact that said file is encrypted is the thing that makes this more "secure". | |
| 15:02:16 | sean-k-mooney | efried: ya kind of virsh is just like the nova client | |
| 15:02:33 | efried | sean-k-mooney: we're 100% virtual here, there is no TPM on the host. | |
| 15:02:33 | sean-k-mooney | all of the logic is implemetne in the libvirt deamon | |
| 15:02:46 | sean-k-mooney | efried: well there could be | |