| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-09-24 | |||
| 19:35:02 | dansmith | yeah | |
| 19:35:24 | dansmith | looks like just signatures though in the tree | |
| 19:35:26 | karimull | I have not seen any support for encrypted image in glance.. | |
| 19:35:26 | efried | assuming the decrypt would happen chunk-wise, it's not in the nova glance code. | |
| 19:36:15 | karimull | wanted to support user defined encryption of image at nova compute for more flexibility | |
| 19:36:44 | efried | karimull: Point is, assuming it's not already there, you would likely be looking to make your changes in a lot of the same places as the bp melwitt mentioned ( https://review.openstack.org/#/q/topic:bp/nova-validate-certificates+(status:open+OR+status:merged) ) | |
| 19:39:12 | karimull | by using Castellan which support key manager interface and by having a plugin in nova to perform user defined decryption process it will be more transparent..just a thought still framing on all possibilities | |
| 19:39:53 | karimull | efried: will look into that blueprint.. | |
| 19:39:58 | melwitt | karimull: are you thinking this would be transparent to glance? like you would encrypt the image before uploading to glance using your nova keypair, for example, and then you'd like nova to decrypt it? we would need the private key for that though and we don't store them | |
| 19:40:16 | karimull | yes | |
| 19:40:47 | dansmith | that's where castellan or barbican comes in | |
| 19:41:04 | dansmith | nova gets a key the user provides there to decrypt | |
| 19:41:25 | melwitt | right.. ok | |
| 19:41:34 | dansmith | AFAIK, glance needs to look at the image when you upload it so it's not like you can do this without glance at all I think | |
| 19:41:43 | dansmith | unless there is some way to tell glance not to look at the image, but I'm not sure | |
| 19:42:17 | karimull | user will get the key from either barbican or from their own KMS and encrypt and upload the image with information in meta data , using that information and castellan libraries key will be retrieved for decryption of image | |
| 19:42:21 | dansmith | unless you care about hiding the boot content from everything other than nova, this is pretty easy to do internal to the image without a lot of fanfare | |
| 19:43:22 | dansmith | also, you'd probably want to make sure we don't cache the decrypted image, especially if the cache is on shared storage | |
| 19:43:27 | dansmith | gets out of hand pretty quick :) | |
| 19:43:44 | karimull | ok | |
| 19:46:29 | karimull | dansmith: wanted to decrypt the image at compute host before it is launched..is this possible?..if we can have hooks at libvirt or nova-compute level wanted to make it a plugin | |
| 19:46:43 | dansmith | karimull: we don't have plugins | |
| 19:47:02 | dansmith | we have some aging hooks that are slowly being removed from the code | |
| 19:47:35 | dansmith | but obviously doing the decryption on the compute host is where it would need to happen | |
| 19:49:28 | karimull | having a plugin kind of functionality will give user flexibility to use their own decryption process..hence look in that way..do we have any similar way to do it in Nova | |
| 19:50:00 | karimull | dansmith : looking* | |
| 19:50:24 | dansmith | we don't have plugins | |
| 19:55:39 | dansmith | mriedem: jaypipes: what's the fix for this? https://bugs.launchpad.net/nova/+bug/1793747 | |
| 19:55:40 | openstack | Launchpad bug 1793747 in OpenStack Compute (nova) "Fails to boot instance using Blazar flavor if compute host names are in uppercase" [High,Triaged] - Assigned to Neha Alhat (nehaalhat) | |
| 19:58:26 | dansmith | I don't even think I get what the problem is | |
| 19:59:14 | openstackgerrit | Merged openstack/nova stable/ocata: Cleanup RP and HM records while deleting a compute service. https://review.openstack.org/603749 | |
| 19:59:20 | dansmith | oh, I see, I was looking at the wrong thing.. we're lower()ing all the hostnames | |
| 20:02:12 | dansmith | s10: okay I got all those backports you tagged me on | |
| 20:04:08 | s10 | dansmith: thank you, finally we will get this fixes in queens after two month of waiting :) | |
| 20:04:27 | dansmith | s10: we just got a queens release this morning though right? | |
| 20:04:35 | dansmith | might already be time to queue up another one :) | |
| 20:06:43 | mriedem | and we just released that blazar regression https://review.openstack.org/#/c/585334/ | |
| 20:07:04 | mriedem | dansmith: i don't know what the fix is for that bug | |
| 20:07:04 | jaypipes | dansmith: the fix for this is not having such fragile friggin code? :( | |
| 20:07:16 | jaypipes | fix one thing, breaks another. :( | |
| 20:07:23 | dansmith | jaypipes: yeah we should totes just depend on our backend database ignoring case for us :) | |
| 20:07:41 | dansmith | mriedem: we could try to lower() the hostname everywhere else, but I kinda think the original "fix" was broken | |
| 20:08:01 | jaypipes | dansmith: the user expects a case-insensitive search. | |
| 20:08:02 | dansmith | if they pass a hostname that is different from what the machine reports, they should expect it to not work | |
| 20:08:32 | dansmith | jaypipes: I don't | |
| 20:08:42 | dansmith | the aggregate code must not be validating hostnames when you go to add one right? | |
| 20:09:03 | dansmith | in which case maybe the fix is just to make host-add fail if you specify something wrong? | |
| 20:09:04 | jaypipes | dansmith: this isn't about that. this is about the collection of host aggregate states in the scheduler (in Python, not in the DB) | |
| 20:09:27 | dansmith | jaypipes: the original | |
| 20:09:27 | jaypipes | and Python is case-sensitive, as we know. | |
| 20:09:44 | dansmith | fix and the new regression are all about us allowing you to add a host with a non-matching case, | |
| 20:09:58 | dansmith | and then us not also ignoring case when we go to join it up right? | |
| 20:10:20 | dansmith | if we just refuse to let them add non-matching hostnames in the first place, everything else can be consistent right? | |
| 20:10:22 | jaypipes | I need to look (again) at the code. it's a giant ball of turds. | |
| 20:11:02 | jaypipes | dansmith: I don't think this is about them adding non-case-matching hostnames. | |
| 20:11:06 | dansmith | I don't expect to have case ignored. what I do expect is for nova to tell me "that's, like, not a host maan" when I go to add one to an aggregate | |
| 20:11:11 | mriedem | non-matching by looking up the host from the compute_nodes table? | |
| 20:11:31 | dansmith | jaypipes: it is.. the original fix says "accidentally typed COMPUTE0 instead of compute0" | |
| 20:11:52 | jaypipes | dansmith: no, I'm talking about the bug 1793747 | |
| 20:11:52 | openstack | bug 1793747 in OpenStack Compute (nova) "Fails to boot instance using Blazar flavor if compute host names are in uppercase" [High,Triaged] https://launchpad.net/bugs/1793747 - Assigned to Neha Alhat (nehaalhat) | |
| 20:11:58 | dansmith | jaypipes: and the regression is that blazar is taking the mixed-case hostname from the hypervisors api, and using that to add the host to an aggregate | |
| 20:12:04 | jaypipes | dansmith: there's no indication that that bug reporter has used non-matching hostname... | |
| 20:12:05 | dansmith | jaypipes: they're the same thing | |
| 20:12:27 | dansmith | jaypipes: blazar is looking at hypervisors and using that value.. | |
| 20:12:39 | mriedem | fwiw, bug 1709260 wouldn't be possible by default if they were using postgresql :P | |
| 20:12:39 | dansmith | blazar host-create Openstack-VirtualBox | |
| 20:12:40 | openstack | bug 1709260 in OpenStack Compute (nova) queens "Addition of host to host-aggregate should be case -sensitive" [Low,Fix committed] https://launchpad.net/bugs/1709260 - Assigned to Rajesh Tailor (ratailor) | |
| 20:12:55 | jaypipes | dansmith: that's the correct hostname. | |
| 20:13:05 | dansmith | jaypipes: right exactrly | |
| 20:13:12 | dansmith | jaypipes: but we're mangling it internally by lower()ing it | |
| 20:13:16 | dansmith | and they can't see that | |
| 20:13:46 | jaypipes | dansmith: where are we mangling it internally other than the host manager's host aggregate state internal map? | |
| 20:13:58 | dansmith | exactly there | |
| 20:14:03 | dansmith | that's the problem right? | |
| 20:14:12 | jaypipes | dansmith: and how exactly would PG vs. MySQL "solve" this problem? | |
| 20:14:19 | dansmith | jaypipes: mriedem said that not me | |
| 20:14:25 | dansmith | I don't think it would | |
| 20:14:45 | dansmith | unless PG honors case, but rejects duplicates that differ only by case | |
| 20:14:56 | jaypipes | "<dansmith> jaypipes: yeah we should totes just depend on our backend database ignoring case for us :)" | |
| 20:14:58 | mriedem | PG is case sensitive by default | |
| 20:15:07 | openstackgerrit | Merged openstack/python-novaclient stable/queens: Switch to stestr https://review.openstack.org/601933 | |
| 20:15:08 | openstackgerrit | Merged openstack/python-novaclient stable/queens: import zuul job settings from project-config https://review.openstack.org/601400 | |
| 20:15:09 | mriedem | so fat fingering COMPUTE0 should result in HostNotFound | |
| 20:15:20 | dansmith | mriedem: I don't think it would if we're not checking | |
| 20:15:38 | mriedem | 1709260 | |
| 20:15:39 | mriedem | oops | |
| 20:15:44 | dansmith | or maybe you mean we're "checking" by just looking it up? | |
| 20:15:45 | mriedem | mapping = objects.HostMapping.get_by_host(context, host_name) | |
| 20:15:47 | mriedem | yes | |
| 20:15:49 | dansmith | gotcha | |
| 20:15:55 | dansmith | then yeah, mysql _is_ hurting us here | |
| 20:15:58 | dansmith | (IMHO) | |
| 20:16:08 | mriedem | there are lots of things like this in the api | |
| 20:16:12 | dansmith | yup | |
| 20:16:44 | jaypipes | I still don't see how MySQL is hurting us | |
| 20:16:57 | mriedem | because adding the host to the aggregate with the wrong name doesn't puke in the api | |
| 20:17:00 | jaypipes | the user expects a case-insenstive API. | |
| 20:17:10 | dansmith | I don't and I'm a user | |
| 20:17:11 | mriedem | you keep saying that but i'm not sure why | |
| 20:17:13 | dansmith | yeah | |