On Mon, Feb 14, 2022 at 04:56:37PM +0000, Daniel P. Berrangé wrote:
On Mon, Feb 14, 2022 at 08:09:57AM -0800, Andrea Bolognani wrote:
> > > Can you please provide pointers to the OpenStack implementation of
> > > this and the issue that resulted from introducing virt-ssh-helper?
> >
> > I don't know where the code is. I just know that they were broken
> > by our changes in this area.
>
> I have found some of the issues filed at the time
>
>
https://bugs.launchpad.net/tripleo/+bug/1918250
>
https://bugzilla.redhat.com/show_bug.cgi?id=1936804
>
> and the corresponding fix
>
>
https://github.com/rdo-packages/nova-distgit/commit/d5aba75f3b5589e156afe...
>
> The detection logic, as currently implemented, is a bit fragile, but
> updating it so that it keeps working even as we make minor
> adjustments to our ssh tunnel script wasn't particularly difficult
>
>
https://github.com/andreabolognani/nova-distgit/commit/27cee8da127c1d447c...
It isn't about whether it is difficult or not though. It is showing
that the changes in libvirt are creating a compatibility problem for
existing application code, and that any changes we make here will
require further changes in such applications. I've not been explicit
about back compatibility in this area, as we didn't realize apps would
be sensitive to changes. Now we know that, I don't think we should be
knowingly making further changes that are likely to break apps.
I think it's unlikely that other management applications are
performing this kind of naive string matching on our ssh tunnel
script, as evidenced by the fact that there haven't been widespread
breakages reported at the time virt-ssh-helper was introduced.
While obviously not definitive proof of this, a search for
"virt-ssh-helper" on GitHub
https://github.com/search?q=virt-ssh-helper&type=code
only finds the OpenStack code that was affected by this; searching
for "nc ARG -U"
https://github.com/search?q=%22nc+ARG+-U%22&type=code
brings up OpenStack again and a project called "virt-access" which
hasn't seen a single update in 7 years. So it seems reasonable to
conclude that, as long as we update OpenStack before merging these
changes, they're not going to break any deployment.
I've also just realized that the OpenStack fix mentioned above is
less than two weeks old, so there's probably a fair chance that it
hasn't made it into a release yet and we can replace the current
approach with the more resilient one I implemented in a completely
seamless manner.
--
Andrea Bolognani / Red Hat / Virtualization