← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 2126675] Re: ironic compute driver hardcodes volume fields which does not work for many driver types

 

I'm going to add ironic for visibility. I guess a base issue is this
sort of highlights a inconsistency which results in initiator/source
data and how it gets handled with Cinder. Its a bit harder because you
don't always know, but all we really knew from base examples in original
boot from volume work with ironic was the iscsi driver so we leaned
towards that as well. Seems like it also needs to be triaged to Cinder
since it is a lack of cross-driver consistency.

** Also affects: ironic
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/2126675

Title:
  ironic compute driver hardcodes volume fields which does not work for
  many driver types

Status in Ironic:
  New
Status in OpenStack Compute (nova):
  New

Bug description:
  The ironic compute driver in nova/virt/ironic/driver.py in the
  get_volume_connector() hardcodes a number of fields and the way the
  operation works in a way that's only compatible with iSCSI (as
  documented by the function) but then its not compatible with all
  cinder driver backends.

  There likely needs to be some coordination between Ironic, Cinder and
  Nova as to how these fields should be mapped and standardized. For
  example, the Nova code reads from Ironic the 1st "iqn" and passes it
  to Cinder in the "initiator" field. But not all Cinder backends
  consistently use that. Some have used "iqn".

  While the comments in the function say that its only compatible with
  iSCSI, if there was some flexibility in these field names then other
  drivers could be supported. For example, NVMeoF works for other
  backends if the field is passed in as "nqn".

  Another field is the "os_type" field. It is currently hardcoded to
  "baremetal" but not all Cinder backends will accept this for iSCSI and
  NVMe and have different values for a "generic" type.

  It feels like there should ultimately be a cinder-lib like neutron-lib
  which defines standard keys and standard values which this driver
  could use and Ironic could use to facilitate in the connection.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ironic/+bug/2126675/+subscriptions



References