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

Dmitry Tantsur dtantsur at redhat.com
Tue Aug 25 10:59:47 UTC 2020


On Tue, Aug 25, 2020 at 12:39 PM Harald Jensas <hjensas at redhat.com> wrote:

> 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?
>

Yes, unless it's explicitly disabled. Although storing raw images from the
beginning may make deployments a bit faster and save some disk space for
this conversion.

Dmitry


>
> >> 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
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200825/3077b3c4/attachment.html>


More information about the openstack-discuss mailing list