Nova tracks bugs in launchpad, not storyboard, so this is OK for the nova bug. SB is fine for tracking ironic-specific work.
> Saving the data to nova seems like it might be a little more complex, but if we have the host volume connector type being wiped by default on tear_down, then I think it would be okay.
With the new style attachments flow for volumes in nova/cinder, the connector dict gets stored with the volume attachment record in Cinder, so you don't need that in nova, although even with the legacy volume attach flows, nova stashes the host connector dict in the BlockDeviceMapping.connection_info, see:
Nova tracks bugs in launchpad, not storyboard, so this is OK for the nova bug. SB is fine for tracking ironic-specific work.
> Saving the data to nova seems like it might be a little more complex, but if we have the host volume connector type being wiped by default on tear_down, then I think it would be okay.
With the new style attachments flow for volumes in nova/cinder, the connector dict gets stored with the volume attachment record in Cinder, so you don't need that in nova, although even with the legacy volume attach flows, nova stashes the host connector dict in the BlockDeviceMapp ing.connection_ info, see:
https:/ /github. com/openstack/ nova/blob/ 93f4364a4e75394 70edc8bde4e335a 9b0d650c57/ nova/volume/ cinder. py#L568
So we should have the host connector persisted either way. How you access it depends on the flow used to create the volume attachment.