Open Stack

On Tue, 2020-05-12 at 13:08 +0200, Johannes Kulik wrote:
> > > 在 2020/3/20 下午10:10，“Stephen Finucane”<stephenfin at redhat.com> 写入:
> > > The suds-jurko library used by oslo.vmware is emitting the following
> > > warnings in nova tests.
> > > 
> > >  /nova/.tox/py36/lib/python3.6/site-packages/suds/resolver.py:89: DeprecationWarning: invalid escape sequence \%
> > >    self.splitp = re.compile('({.+})*[^\%s]+' % ps[0])
> > >  /nova/.tox/py36/lib/python3.6/site-packages/suds/wsdl.py:619: DeprecationWarning: invalid escape sequence \s
> > >    body.parts = re.split('[\s,]', parts)
> > > 
> > > These warnings are going to be errors in Python 3.10 [1]. We have over
> > > 18 months before we need to worry about this [2], but I'd like to see
> > > some movement on this well before then. It seems the suds-jurko fork is
> > > dead [3] and movement on yet another fork, suds-community, is slow [4].
> > > How difficult would it be to switch over to something that does seem
> > > maintained like zeep [5] and, assuming it's doable, is anyone from
> > > VMWare/SAP able to do this work?
> > > 
> > > Stephen
> > 
> > Stephen,
> > 
> > Thank you very much for pointing this out. Lichao (xuel at vmware.com) and I from VMware will involve into this issue.
> > 
> > Do you think zeep is a good alternative of suds ? Or did the replacement already take place on other project ?
> > 
> > We would like to make assessment to the zeep first and then make an action plan.
> > 
> > Yingji.
> 
> Hi Yingji, Stephen,
> 
> we've been working downstream on switching oslo.vmware away from suds.
> We're still on queens, but oslo.vmware didn't change too much since then ...
> 
> We've opted for zeep, because it's
> 1) currently still maintained
> 2) promises python 3 support
> 3) uses lxml at it's base, thus giving a performance boost, which we need
> 
> In our tests, a script doing some simple queries against vSphere 6.5 
> finished in ~5s (zeep) instead of ~10s (suds). Looking at nova-compute
> nodes, the CPU-usage decreased drastically. Which is what we were aiming
> for. We haven't run it in production, yet, but are planning to do so
> gradually.
> 
> We're willing to put some more work into getting the changes upstream,
> if someone can assist in the process and if you're fine with that.
> 
> To get a glimpse at the changes necessary for oslo.vmare, have a look
> at [1]. These are for queens, though.
> We've also put some work in to make the transition easier, by moving
> suds-specific code from nova into oslo.vmare and providing some
> helper-functions for the differences in ManagedObjectReference
> attribute access [2], [3], [4], [5].
> 
> Obviously, there are changes needed in nova and cinder, if we need
> to use helper-functions. For nova, we've got a couple of patches,
> that are not public, yet.
> 
> Sorry for coming into this with a "solution" already, but we have
> a direct need for switching downstream, as explained above.

I'd missed Lichao and Yingji's reply to my original post. If you have
something ready to go, I suggest you work with them to get patches
pushed up and ready for review. I'm happy to review them along with the
other oslo maintainers. Feel free to ping us on #openstack-oslo (nick:
stephenfin) if you run into any issues.

Cheers,
Stephen

> Have nice day otherwise,
> Johannes
> 
> [1] https://github.com/sapcc/oslo.vmware/pull/4/files
> [2] https://github.com/sapcc/oslo.vmware/commit/84d3e3177affa8dbffdbc0ecf0cbc2aea6b3dbde
> [3] https://github.com/sapcc/oslo.vmware/commit/385a0352beab3ddb8273138abd31f0788638bb76
> [4] https://github.com/sapcc/oslo.vmware/commit/6a531ba84e8db43db1cb9ff433e6d18cdd98a4c6
> [5] https://github.com/sapcc/oslo.vmware/commit/993fe5f98a7b8172710af4f27b6c1a3eabb1c7d4