[ironic][tripleo] RFC: deprecate the iSCSI deploy interface?

Harald Jensas hjensas at redhat.com
Tue Aug 25 10:35:47 UTC 2020

On 8/20/20 5:49 PM, Julia Kreger wrote:
> I suspect we're going to have lots of push back from the TripleO
> community because there has been resistance to change their default
> usage in the past. As such I'm adding them to the subject so hopefully
> they will be at least aware.

Since TripleO already support using the direct interface, it's 
recommended and tested by the TripleO group focusing on edge type 
deployments, switching to direct by default might not be too much of a 
hassle for TripleO.

We may want to change the disk-image format used by TripleO to raw as 
well, to benefit from the raw image streaming capabilities? Or would 
enabling image_download_source = http convert the images as they are 
cached on conductors? (see question inline below.)

> On Thu, Aug 20, 2020 at 1:57 AM Dmitry Tantsur <dtantsur at redhat.com> wrote:
>> Hi all,
>> Side note for those lacking context: this proposal concerns deprecating one of the ironic deploy interfaces detailed in https://docs.openstack.org/ironic/latest/admin/interfaces/deploy.html. It does not affect the boot-from-iSCSI feature.
>> I would like to propose deprecating and removing the 'iscsi' deploy interface over the course of the next 2 cycles. The reasons are:
>> 1) The iSCSI deploy is a source of occasional cryptic bugs when a target cannot be discovered or mounted properly.
>> 2) Its security is questionable: I don't think we even use authentication.
>> 3) Operators confusion: right now we default to the iSCSI deploy but pretty much direct everyone who cares about scalability or security to the 'direct' deploy.
>> 4) Cost of maintenance: our feature set is growing, our team - not so much. iscsi_deploy.py is 800 lines of code that can be removed, and some dependencies that can be dropped as well.
>> As far as I can remember, we've kept the iSCSI deploy for two reasons:
>> 1) The direct deploy used to require Glance with Swift backend. The recently added [agent]image_download_source option allows caching and serving images via the ironic's HTTP server, eliminating this problem. I guess we'll have to switch to 'http' by default for this option to keep the out-of-box experience.
>> 2) Memory footprint of the direct deploy. With the raw images streaming we no longer have to cache the downloaded images in the agent memory, removing this problem as well (I'm not even sure how much of a problem it is in 2020, even my phone has 4GiB of RAM).

When using image_download_source = http, does Ironic convert non-raw 
images when they are placed on each conductors cache? To benefit from 
the raw image streaming?

>> If this proposal is accepted, I suggest to execute it as follows:
>> Victoria release:
>> 1) Put an early deprecation warning in the release notes.
>> 2) Announce the future change of the default value for [agent]image_download_source.
>> W release:
>> 3) Change [agent]image_download_source to 'http' by default.
>> 4) Remove iscsi from the default enabled_deploy_interfaces and move it to the back of the supported list (effectively making direct deploy the default).
>> X release:
>> 5) Remove the iscsi deploy code from both ironic and IPA.
>> Thoughts, opinions, suggestions?
>> Dmitry

More information about the openstack-discuss mailing list