Earlier  
Posted Nick Remark
#openstack-nova - 2018-09-24
19:29:41 karimull efried : yes
19:29:51 efried I see. Have you talked to the glance folks about it?
19:30:50 karimull efried : not yet
19:31:19 melwitt we added support for trusted image certificate validation in rocky https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/nova-validate-certificates.html
19:31:45 dansmith presumably they want encryption
19:31:49 dansmith but that came before, AFAIK
19:32:01 melwitt but I don't know of any support for encrypted images in glance
19:32:34 melwitt yeah, was just mentioning it in case it might be useful
19:33:12 melwitt that's the extent of the handling of "untrusted glance" that I know about
19:33:16 dansmith oh I thought the encryption support was already there
19:33:36 dansmith maybe I'm thinking of encrypted block
19:34:46 melwitt I'm not sure, it might be there. trying to find out. an earlier iteration of the trusted certs stuff mentioned image encryption
19:35:02 dansmith yeah
19:35:24 dansmith looks like just signatures though in the tree
19:35:26 efried assuming the decrypt would happen chunk-wise, it's not in the nova glance code.
19:35:26 karimull I have not seen any support for encrypted image in glance..
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 jaypipes dansmith: the fix for this is not having such fragile friggin code? :(
20:07:04 mriedem dansmith: i don't know what the fix is for that bug
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 jaypipes and Python is case-sensitive, as we know.
20:09:27 dansmith jaypipes: the original
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 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:52 jaypipes dansmith: no, I'm talking about the bug 1793747
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 dansmith blazar host-create Openstack-VirtualBox
20:12:39 mriedem fwiw, bug 1709260 wouldn't be possible by default if they were using postgresql :P
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)

Earlier   Later