[openstack-dev] [all] re-introducing twisted to global-requirements

Jim Rollenhagen jim at jimrollenhagen.com
Fri Jan 8 17:56:46 UTC 2016


On Fri, Jan 08, 2016 at 11:00:35AM +0100, Thierry Carrez wrote:
> Jim Rollenhagen wrote:
> >[...]
> >Here's the catch - mimic is built on twisted. I know twisted was
> >previously removed from OpenStack (or at least people said "pls no", I
> >don't know the full history). We didn't intend to stealth-introduce
> >twisted back into g-r, but it was pointed out to me that it may appear
> >this way, so here I am letting everyone know. lifeless pointed out that
> >when tests are failing, people may end up digging into mimic or twisted
> >code, which most people in this community aren't familiar with AFAIK,
> >which is a valid point though I hope it isn't required often.
> 
> A bit of history with Twisted.
> 
> Back in 2010 we decided we could not afford asking OpenStack developers to
> be familiar with multiple service architecture frameworks, and eventlet was
> chosen as the simplest framework to learn and debug. The best reference I
> found on this is still visible in the wiki:
> 
> https://wiki.openstack.org/wiki/UnifiedServiceArchitecture
> 
> >So, the primary question here is: do folks have a problem with adding
> >twisted here? We're holding off on Ironic changes that depend on this
> >until this discussion has happened, but aren't reverting the g-r change
> >until we decide one way or another.
> 
> The only friction I see is how many developers would be expected to need to
> learn Twisted in order to complete their jobs. My understanding is that
> Twisted expertise could be needed to debug python-ironicclient functional
> tests, which makes the cost relatively limited. So if Mimic brings in a
> clear and significant benefit, I don't think its Twisted dependence should
> play that much against it.
> 
> However, I agree with Sean and Jay that the benefit is unclear -- the few
> features that Mimic brings seem to be outweighed by the increased risk of
> introducing a delta between the implementation and the mock. If the main
> benefit is that it's used in other Rackspace projects for testing (like Ben
> said), I'm not sure that makes a compelling argument for the rest of the
> community...

No, that is not the main benefit, at all. Ben isn't involved in Ironic
and until now has had nothing to do with this work to add mimic here, so
I'm not sure where he got that impression from, or why he's speaking on
our behalf as to the goals here.

As pointed out before, the risk of a delta between the mocks in mimic
and reality is identical to the risk of a delta between the mocks in a
client's unit tests and reality, so I don't see a particular downside
there.

Again, I think "benefit is unclear" isn't a valid reason to block this,
so unless someone posts a revert we're going to move forward with this.

// jim



More information about the OpenStack-dev mailing list