[ironic] question regarding attributes required for a non-admin to boot from volume
Hi, I've been looking into what it would take to allow non-admins to boot from volume. It looks like they'd need to update a node's storage_interface; and if you'd like to boot from an iSCSI volume, then you also need to update a node's capabilities property. Are these fields that we want non-admins to be able to update? If not, is there an alternative that might be possible? Thanks, Tzu-Mainn Chen
Hi, On Tue, Jan 12, 2021 at 3:45 PM Tzu-Mainn Chen <tzumainn@redhat.com> wrote:
Hi,
I've been looking into what it would take to allow non-admins to boot from volume. It looks like they'd need to update a node's storage_interface; and if you'd like to boot from an iSCSI volume, then you also need to update a node's capabilities property.
FWIW we have a similar situation with the ramdisk deploy and the necessity to update deploy_interface. In both cases I don't feel well about updating node.*_interface itself, because such changes are permanent and there is no code to un-do them before the node becomes available again. My plan (if I ever get to it) is to accept deploy_interface (and now storage_interface) in node.instance_info. This solves both problems: instance_info is writable by non-admins and is wiped automatically on tear down. As to capabilities, I think it's fine if you set the iscsi_boot capability for every node that supports it in advance. You don't need non-admins to do that. Otherwise, most capabilities can be overridden via instance_info[capabilities] (although not this one). Dmitry
Are these fields that we want non-admins to be able to update? If not, is there an alternative that might be possible?
Thanks, Tzu-Mainn Chen
-- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
participants (2)
-
Dmitry Tantsur
-
Tzu-Mainn Chen