<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 24, 2020 at 1:52 PM Sean Mooney <<a href="mailto:smooney@redhat.com">smooney@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 2020-08-24 at 10:32 +0200, Dmitry Tantsur wrote:<br>
> Hi,<br>
> <br>
> On Mon, Aug 24, 2020 at 10:24 AM Arne Wiebalck <<a href="mailto:arne.wiebalck@cern.ch" target="_blank">arne.wiebalck@cern.ch</a>><br>
> wrote:<br>
> <br>
> > Hi!<br>
> > <br>
> > CERN's deployment is using the iscsi deploy interface since we started<br>
> > with Ironic a couple of years ago (and we installed around 5000 nodes<br>
> > with it by now). The reason we chose it at the time was simplicity: we<br>
> > did not (and still do not) have a Swift backend to Glance, and the iscsi<br>
> > interface provided a straightforward alternative.<br>
> > <br>
> > While we have not seen obscure bugs/issues with it, I can certainly back<br>
> > the scalability issues mentioned by Dmitry: the tunneling of the images<br>
> > through the controllers can create issues when deploying hundreds of<br>
> > nodes at the same time. The security of the iscsi interface is less of a<br>
> > concern in our specific environment.<br>
> > <br>
> > So, why did we not move to direct (yet)? In addition to the lack of<br>
> > Swift, mostly since iscsi works for us and the scalability issues were<br>
> > not that much of a burning problem ... so we focused on other things :)<br>
> > <br>
> > Here are some thoughts/suggestions for this discussion:<br>
> > <br>
> > How would 'direct' work with other Glance backends (like Ceph/RBD in our<br>
> > case)? If using direct requires to duplicate images from Glance to<br>
> > Ironic (or somewhere else) to be served, I think this would be an<br>
> > argument against deprecating iscsi.<br>
> > <br>
> <br>
> With image_download_source=http ironic will download the image to the<br>
> conductor to be able serve it to the node. Which is exactly what the iscsi<br>
> is doing, so not much of a change for you (except for s/iSCSI/HTTP/ as a<br>
> means of serving the image).<br>
> <br>
> Would it be an option for you to test direct deploy with<br>
> image_download_source=http?<br>
i think if there is still an option to not force deployemnt to altere any of there<br>
other sevices this is likely ok but i think the onious shoudl be on the ironic<br>
and ooo teams to ensure there is an upgrade path for those useres before this deprecation<br>
becomes a removal without deploying swift or a swift compatibale api e.g. RadosGW<br>
<br>
perhaps a ci job could be put in place maybe using grenade that starts with iscsi and moves<br>
to direct with http porvided to show that just setting that weill allow the conductor to download<br>
the image from glance and server it to the ipa.<br></blockquote><div><br></div><div>This is the CI job with direct deploy in a low RAM environment with a large image (CentOS) without Swift: <a href="https://zuul.opendev.org/t/openstack/build/58f623d90435470f9095eb68202c25f8">https://zuul.opendev.org/t/openstack/build/58f623d90435470f9095eb68202c25f8</a></div><div><br></div><div>The change is <a href="https://review.opendev.org/#/c/747413/">https://review.opendev.org/#/c/747413/</a></div><div><br></div><div>Dmitry<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
unlike cern i just use ironic in a tiny home deployment where i have an all in one deployment + 4 addtional<br>
nodes for ironic. i cant deploy swift as all my disks are already in use for cinder so down the line when <br>
i eventually upgrade to vicortia and wallaby  i would either have to drop ironic or not upgrade it<br>
if there is not a option to just pull the image from glance or glance via the conductor. enhancing the ipa<br>
to pull directly from glance would also proably work for many who use iscsi today but that would depend on your network<br>
toplogy i guess.<br>
> <br>
> <br>
> > <br>
> > Equally, if this would require to completely move the Glance backend to<br>
> > something else, like from RBD to RadosGW, I would not expect happy<br>
> > operators. (Does anyone know if RadosGW could even replace Swift for<br>
> > this specific use case?)<br>
> > <br>
> <br>
> AFAIK ironic works with RadosGW, we have some support code for it.<br>
> <br>
> <br>
> > <br>
> > Do we have numbers on how many deployments use iscsi vs direct? If many<br>
> > rely on iscsi, I would also suggest to establish a migration guide for<br>
> > operators on how to move from iscsi to direct, for the various configs.<br>
> > Recent versions of Glance support multiple backends, so a migration path<br>
> > may be to add a new (direct compatible) backend for new images.<br>
> > <br>
> <br>
> I don't have any numbers, but a migration guide is a must in any case.<br>
> <br>
> I expect most TripleO consumers to use the iscsi deploy, but only because<br>
> it's the default. Their Edge solution uses the direct deploy. I've polled a<br>
> few operators I know, they all (except for you, obviously :) seem to use<br>
> the direct deploy. Metal3 uses direct deploy.<br>
> <br>
> Dmitry<br>
> <br>
> <br>
> > <br>
> > Cheers,<br>
> >   Arne<br>
> > <br>
> > On 20.08.20 17:49, Julia Kreger wrote:<br>
> > > I'm having a sense of deja vu!<br>
> > > <br>
> > > Because of the way the mechanics work, the iscsi deploy driver is in<br>
> > > an unfortunate position of being harder to troubleshoot and diagnose<br>
> > > failures. Which basically means we've not been able to really identify<br>
> > > common failures and add logic to handle them appropriately, like we<br>
> > > are able to with a tcp socket and file download. Based on this alone,<br>
> > > I think it makes a solid case for us to seriously consider<br>
> > > deprecation.<br>
> > > <br>
> > > Overall, I'm +1 for the proposal and I believe over two cycles is the<br>
> > > right way to go.<br>
> > > <br>
> > > I suspect we're going to have lots of push back from the TripleO<br>
> > > community because there has been resistance to change their default<br>
> > > usage in the past. As such I'm adding them to the subject so hopefully<br>
> > > they will be at least aware.<br>
> > > <br>
> > > I guess my other worry is operators who already have a substantial<br>
> > > operational infrastructure investment built around the iscsi deploy<br>
> > > interface. I wonder why they didn't use direct, but maybe they have<br>
> > > all migrated in the past ?5? years. This could just be a non-concern<br>
> > > in reality, I'm just not sure.<br>
> > > <br>
> > > Of course, if someone is willing to step up and make the iscsi<br>
> > > deployment interface their primary focus, that also shifts the<br>
> > > discussion to making direct the default interface?<br>
> > > <br>
> > > -Julia<br>
> > > <br>
> > > <br>
> > > On Thu, Aug 20, 2020 at 1:57 AM Dmitry Tantsur <<a href="mailto:dtantsur@redhat.com" target="_blank">dtantsur@redhat.com</a>><br>
> > <br>
> > wrote:<br>
> > > > <br>
> > > > Hi all,<br>
> > > > <br>
> > > > Side note for those lacking context: this proposal concerns deprecating<br>
> > <br>
> > one of the ironic deploy interfaces detailed in<br>
> > <a href="https://docs.openstack.org/ironic/latest/admin/interfaces/deploy.html" rel="noreferrer" target="_blank">https://docs.openstack.org/ironic/latest/admin/interfaces/deploy.html</a>. It<br>
> > does not affect the boot-from-iSCSI feature.<br>
> > > > <br>
> > > > I would like to propose deprecating and removing the 'iscsi' deploy<br>
> > <br>
> > interface over the course of the next 2 cycles. The reasons are:<br>
> > > > 1) The iSCSI deploy is a source of occasional cryptic bugs when a<br>
> > <br>
> > target cannot be discovered or mounted properly.<br>
> > > > 2) Its security is questionable: I don't think we even use<br>
> > <br>
> > authentication.<br>
> > > > 3) Operators confusion: right now we default to the iSCSI deploy but<br>
> > <br>
> > pretty much direct everyone who cares about scalability or security to the<br>
> > 'direct' deploy.<br>
> > > > 4) Cost of maintenance: our feature set is growing, our team - not so<br>
> > <br>
> > much. iscsi_deploy.py is 800 lines of code that can be removed, and some<br>
> > dependencies that can be dropped as well.<br>
> > > > <br>
> > > > As far as I can remember, we've kept the iSCSI deploy for two reasons:<br>
> > > > 1) The direct deploy used to require Glance with Swift backend. The<br>
> > <br>
> > recently added [agent]image_download_source option allows caching and<br>
> > serving images via the ironic's HTTP server, eliminating this problem. I<br>
> > guess we'll have to switch to 'http' by default for this option to keep the<br>
> > out-of-box experience.<br>
> > > > 2) Memory footprint of the direct deploy. With the raw images streaming<br>
> > <br>
> > we no longer have to cache the downloaded images in the agent memory,<br>
> > removing this problem as well (I'm not even sure how much of a problem it<br>
> > is in 2020, even my phone has 4GiB of RAM).<br>
> > > > <br>
> > > > If this proposal is accepted, I suggest to execute it as follows:<br>
> > > > Victoria release:<br>
> > > > 1) Put an early deprecation warning in the release notes.<br>
> > > > 2) Announce the future change of the default value for<br>
> > <br>
> > [agent]image_download_source.<br>
> > > > W release:<br>
> > > > 3) Change [agent]image_download_source to 'http' by default.<br>
> > > > 4) Remove iscsi from the default enabled_deploy_interfaces and move it<br>
> > <br>
> > to the back of the supported list (effectively making direct deploy the<br>
> > default).<br>
> > > > X release:<br>
> > > > 5) Remove the iscsi deploy code from both ironic and IPA.<br>
> > > > <br>
> > > > Thoughts, opinions, suggestions?<br>
> > > > <br>
> > > > Dmitry<br>
> > <br>
> > <br>
<br>
</blockquote></div></div>