Re: [openstack-dev] [nova] Concern about trusted certificates API change
> Maybe it wasn't clear but I'm not advocating that we block the change > until volume-backed instances are supported with trusted certs. I'm > suggesting we add a policy rule which allows deployers to at least > disable it via policy if it's not supported for their cloud. That's fine with me, and provides an out for another issue I pointed out on the code review. Basically, the operator has no way to disable this feature. If they haven't set this up properly and have no desire to, a user reading the API spec and passing trusted certs will not be able to boot an instance and not really understand why. > I agree. I'm the one that noticed the issue and pointed out in the > code review that we should explicitly fail the request if we can't > honor it. I agree for the moment for sure, but it would obviously be nice not to open another gap we're not going to close. There's no reason this can't be supported for volume-backed instances, it just requires some help from cinder. I would think that it'd be nice if we could declare the "can't do this for reasons" response as a valid one regardless of the cause so we don't need another microversion for the future where volume-backed instances can do this. > Again, I'm not advocating that we block until boot from volume is > supported. However, we have a lot of technical debt for "good > functionality" added over the years that failed to consider > volume-backed instances, like rebuild, rescue, backup, etc and it's > painful to deal with that after the fact, as can be seen from the > various specs proposed for adding that support to those APIs. Totes agree. --Dan __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Concern about trusted certificates API change
On 04/18/2018 01:14 PM, Matt Riedemann wrote: On 4/18/2018 12:09 PM, Chris Friesen wrote: If this happens, is it clear to the end-user that the reason the boot failed is that the cloud doesn't support trusted cert IDs for boot-from-vol? If so, then I think that's totally fine. If you're creating an image-backed server and requesting specific trusted certs, you'll get by the API but could land on a compute host that doesn't support image validation, like any non-libvirt driver, and at that point the trusted certs request is ignored. We could fix that the same way I've proposed we fix it for boot from volume with multiattach volumes in that the compute node resource provider would have a trait on it for the capability, and we'd add a placement request filter that detects, from the RequestSpec, that you're trying to do this specific thing that requires a compute that supports that capability, otherwise you get NoValidHost. +1 Still looking for reviews on https://review.openstack.org/#/c/546713/. Thanks, -jay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Concern about trusted certificates API change
On 4/18/2018 12:09 PM, Chris Friesen wrote: If this happens, is it clear to the end-user that the reason the boot failed is that the cloud doesn't support trusted cert IDs for boot-from-vol? If so, then I think that's totally fine. If you're creating an image-backed server and requesting specific trusted certs, you'll get by the API but could land on a compute host that doesn't support image validation, like any non-libvirt driver, and at that point the trusted certs request is ignored. We could fix that the same way I've proposed we fix it for boot from volume with multiattach volumes in that the compute node resource provider would have a trait on it for the capability, and we'd add a placement request filter that detects, from the RequestSpec, that you're trying to do this specific thing that requires a compute that supports that capability, otherwise you get NoValidHost. -- Thanks, Matt __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Concern about trusted certificates API change
On 4/18/2018 11:57 AM, Jay Pipes wrote: There is a compute REST API change proposed [1] which will allow users to pass trusted certificate IDs to be used with validation of images when creating or rebuilding a server. The trusted cert IDs are based on certificates stored in some key manager, e.g. Barbican. The full nova spec is here [2]. The main concern I have is that trusted certs will not be supported for volume-backed instances, and some clouds only support volume-backed instances. Yes. And some clouds only support VMWare vCenter virt driver. And some only support Hyper-V. I don't believe we should delay adding good functionality to (large percentage of) clouds because it doesn't yet work with one virt driver or one piece of (badly-designed) functionality. Maybe it wasn't clear but I'm not advocating that we block the change until volume-backed instances are supported with trusted certs. I'm suggesting we add a policy rule which allows deployers to at least disable it via policy if it's not supported for their cloud. > The way the patch is written is that if the user attempts to boot from volume with trusted certs, it will fail. And... I think that's perfectly fine. I agree. I'm the one that noticed the issue and pointed out in the code review that we should explicitly fail the request if we can't honor it. In thinking about a semi-discoverable/configurable solution, I'm thinking we should add a policy rule around trusted certs to indicate if they can be used or not. Beyond the boot from volume issue, the only virt driver that supports trusted cert image validation is the libvirt driver, so any cloud that's not using the libvirt driver simply cannot support this feature, regardless of boot from volume. We have added similar policy rules in the past for backend-dependent features like volume extend and volume multi-attach, so I don't think this is a new issue. Alternatively we can block the change in nova until it supports boot from volume, but that would mean needing to add trusted cert image validation support into cinder along with API changes, effectively killing the chance of this getting done in nova in Rocky, and this blueprint has been around since at least Ocata so it would be good to make progress if possible. As mentioned above, I don't want to derail progress until (if ever?) trusted certs achieves this magical works-for-every-driver-and-functionality state. It's not realistic to expect this to be done, IMHO, and just keeps good functionality out of the hands of many cloud users. Again, I'm not advocating that we block until boot from volume is supported. However, we have a lot of technical debt for "good functionality" added over the years that failed to consider volume-backed instances, like rebuild, rescue, backup, etc and it's painful to deal with that after the fact, as can be seen from the various specs proposed for adding that support to those APIs. -- Thanks, Matt __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Concern about trusted certificates API change
On 04/18/2018 10:57 AM, Jay Pipes wrote: On 04/18/2018 12:41 PM, Matt Riedemann wrote: There is a compute REST API change proposed [1] which will allow users to pass trusted certificate IDs to be used with validation of images when creating or rebuilding a server. The trusted cert IDs are based on certificates stored in some key manager, e.g. Barbican. The full nova spec is here [2]. The main concern I have is that trusted certs will not be supported for volume-backed instances, and some clouds only support volume-backed instances. Yes. And some clouds only support VMWare vCenter virt driver. And some only support Hyper-V. I don't believe we should delay adding good functionality to (large percentage of) clouds because it doesn't yet work with one virt driver or one piece of (badly-designed) functionality. > The way the patch is written is that if the user attempts to boot from volume with trusted certs, it will fail. And... I think that's perfectly fine. If this happens, is it clear to the end-user that the reason the boot failed is that the cloud doesn't support trusted cert IDs for boot-from-vol? If so, then I think that's totally fine. If the error message is unclear, then maybe we should just improve it. Chris __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Concern about trusted certificates API change
On 04/18/2018 12:41 PM, Matt Riedemann wrote: There is a compute REST API change proposed [1] which will allow users to pass trusted certificate IDs to be used with validation of images when creating or rebuilding a server. The trusted cert IDs are based on certificates stored in some key manager, e.g. Barbican. The full nova spec is here [2]. The main concern I have is that trusted certs will not be supported for volume-backed instances, and some clouds only support volume-backed instances. Yes. And some clouds only support VMWare vCenter virt driver. And some only support Hyper-V. I don't believe we should delay adding good functionality to (large percentage of) clouds because it doesn't yet work with one virt driver or one piece of (badly-designed) functionality. > The way the patch is written is that if the user attempts to boot from volume with trusted certs, it will fail. And... I think that's perfectly fine. In thinking about a semi-discoverable/configurable solution, I'm thinking we should add a policy rule around trusted certs to indicate if they can be used or not. Beyond the boot from volume issue, the only virt driver that supports trusted cert image validation is the libvirt driver, so any cloud that's not using the libvirt driver simply cannot support this feature, regardless of boot from volume. We have added similar policy rules in the past for backend-dependent features like volume extend and volume multi-attach, so I don't think this is a new issue. Alternatively we can block the change in nova until it supports boot from volume, but that would mean needing to add trusted cert image validation support into cinder along with API changes, effectively killing the chance of this getting done in nova in Rocky, and this blueprint has been around since at least Ocata so it would be good to make progress if possible. As mentioned above, I don't want to derail progress until (if ever?) trusted certs achieves this magical works-for-every-driver-and-functionality state. It's not realistic to expect this to be done, IMHO, and just keeps good functionality out of the hands of many cloud users. Just my 2 cents. -jay [1] https://review.openstack.org/#/c/486204/ [2] https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/nova-validate-certificates.html __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] Concern about trusted certificates API change
There is a compute REST API change proposed [1] which will allow users to pass trusted certificate IDs to be used with validation of images when creating or rebuilding a server. The trusted cert IDs are based on certificates stored in some key manager, e.g. Barbican. The full nova spec is here [2]. The main concern I have is that trusted certs will not be supported for volume-backed instances, and some clouds only support volume-backed instances. The way the patch is written is that if the user attempts to boot from volume with trusted certs, it will fail. In thinking about a semi-discoverable/configurable solution, I'm thinking we should add a policy rule around trusted certs to indicate if they can be used or not. Beyond the boot from volume issue, the only virt driver that supports trusted cert image validation is the libvirt driver, so any cloud that's not using the libvirt driver simply cannot support this feature, regardless of boot from volume. We have added similar policy rules in the past for backend-dependent features like volume extend and volume multi-attach, so I don't think this is a new issue. Alternatively we can block the change in nova until it supports boot from volume, but that would mean needing to add trusted cert image validation support into cinder along with API changes, effectively killing the chance of this getting done in nova in Rocky, and this blueprint has been around since at least Ocata so it would be good to make progress if possible. [1] https://review.openstack.org/#/c/486204/ [2] https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/nova-validate-certificates.html -- Thanks, Matt __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
