[openstack-dev] [all] re-introducing twisted to global-requirements
ben.meyer at rackspace.com
Fri Jan 8 19:21:36 UTC 2016
On 01/08/2016 12:56 PM, Jim Rollenhagen wrote:
> 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:
>>> 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
> 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.
I never claimed involvement in Ironic and from the outset noted my
status on this list. I've only commented in so far as trying to show the
value of mimic and similar tools.
I'm sorry if there was any confusion in that with respect to ironic.
That was certainly not my intent.
> 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
More information about the OpenStack-dev