Open Stack

On 14 August 2014 09:48, Duncan Thomas <duncan.thomas at gmail.com> wrote:
> On 13 August 2014 13:57, Matthew Treinish <mtreinish at kortar.org> wrote:

>> So this is actually the communication problem I mentioned before. Singling out
>> individual projects and getting them to add a rally job is not "cross project"
>> communication. (this is part of what I meant by "push using Rally") There was no
>> larger discussion on the ML or a topic in the project meeting about adding these
>> jobs. There was no discussion about the value vs risk of adding new jobs to the
>> gate. Also, this is why less than half of the integrated projects have these
>> jobs. Having asymmetry like this between gating workloads on projects helps no
>> one.

W.r.t. communication we had a very limited number of slots at Atlanta
for cross-project discussion; osprofiler *did* get a slot (I forget
under what banner) - and it has iterated to address deployer concerns
(the ones I know of anyhow).

I'm very keen to see osprofiler integrated in close to or even by
default, its an essential bit of operator and diagnostic tooling. I'd
like to ask that we address Rally and osprofiler separately.

> So the advantage of the approach, rather than having a massive
> cross-product discussion, is that interested projects (I've been very
> interested for a cinder core PoV) act as a test bed for other
> projects. 'Cross project' discussions rather come to other teams, they
> rely on people to find them, where as Boris came to us, said I've got
> this thing you might like, try it out, tell me what you want. He took
> feedback, iterated fast and investigated bugs. It has been a genuine
> pleasure to work with him, and I feel we made progress faster than we
> would have done if it was trying to please everybody.

Right - try early, fail fast, iterate. Making everything get consensus
before anyone tries it is a waste of everyones time. Most ideas won't
be hits, so lets wait for them to be successful before we standardise.

>> That being said the reason I think osprofiler has been more accepted and it's
>> adoption into oslo is not nearly as contentious is because it's an independent
>> library that has value outside of itself. You don't need to pull in a monolithic
>> stack to use it. Which is a design point more conducive with the rest of
>> OpenStack.
>
> Sorry, are you suggesting tempest isn't a giant monolithic thing?
> Because I was able to comprehend the rally code very quickly, that
> isn't even slightly true of tempest. Having one simple tool that does
> one thing well is exactly what rally has tried to do - tempest seems
> to want to be five different things at once (CI, instalation tests,
> trademark, preformance, stress testing, ...)
...
> So I put in a change to dump out the raw data from each run into a
> zipped json file so that I can start looking at the value of
> collecting this data.... As an experiment I think it is very worth
> while. The gate job is none voting, and apparently, at least on the
> cinder front, highly reliable. The job runs fast enough it isn't
> slowing the gate down - we aren't running out of nodes on the gate as
> far as I can tell, so I don't understand the hostility towards it.
> We'll run it for a bit, see if it proves useful, if it doesn't then we
> can turn it off and try something else.
>
> I'm confused by the hostility about this gate job - it is costing us
> nothing, if it turns out to be a pain we'll turn it off.
>
> Rally as a general tool has enabled me do do things that I wouldn't
> even consider trying with tempest. There shouldn't be a problem with a
> small number of parallel efforts - that's a founding principle of
> opensource in general.

+1

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud