Open Stack

On 4/10/2015 10:29 AM, Matt Riedemann wrote:
>
>
> On 4/8/2015 4:07 PM, Michael Still wrote:
>> I just wanted to send a note about John running in the PTL election
>> for Nova.
>>
>> I want to make it clear that I think having more than one candidate is
>> a good thing -- its a healthy part of a functional democracy, and it
>> also means regardless of the outcome we have at least one succession
>> planning option should a PTL need to step down at some point in the
>> future.
>>
>> That said, I think there are a few things we need to do in Liberty,
>> regardless of who is PTL. I started this as a Google doc to share with
>> John if he won so that we didn’t drop the ball, but then I realised
>> that nothing here is secret. So, here is my brain dump of things we
>> need to do in Liberty, in no particular order:
>>
>> nova-coresec reboot
>> ================
>>
>> The nova-coresec team has been struggling recently to keep up with
>> their workload. We need to drop people off this team who haven’t had
>> time recently to work on security bugs, and we need to find new people
>> to volunteer for this team, noting that the team is kept deliberately
>> small because of embargoed security vulnerabilities. If I am not
>> re-elected as PTL, I will probably volunteer for this team.
>>
>> priorities and specs
>> ===============
>>
>> I think the current spec process is starting to work well for us, and
>> that priorities was a success. We should continue with specs, but with
>> an attempt to analyse why so many approved specs don’t land (we have
>> had about 50% of our approved specs not land in Juno and Kilo). Is
>> that as simple as code review bandwidth? Or is the problem more
>> complicated than that? We just don’t know until someone goes digging.
>>
>> Priorities worked well. We need to start talking about what should be
>> a priority in Liberty now, and the first step is to decide as a team
>> what we think the big problems we’re trying to solve in Liberty are.
>>
>> nova-core
>> ========
>>
>> I think there are a couple of things to be done here.
>>
>> There are still a few idle cores, particularly people who haven’t done
>> less than ten reviews in the last 90 days. We should drop those people
>> from core and thank them for their work in the past noting once again
>> that this is a natural part of the Open Source process -- those people
>> are off working on other problems now and that’s cool.
>>
>> We also need to come up with a way to grow more cores. Passive
>> approaches like asking existing cores to keep an eye out for talent
>> they trust haven’t worked, so I think its time to actively start
>> mentoring core candidates.
>>
>> I am not convinced that just adding cores will solve our review
>> bandwidth problems though. We have these conversations about why
>> people’s reviews sit around without a lot of data to back them up, and
>> I feel like we often jump to conclusions that feel intuitive but that
>> aren’t supported by the data.
>>
>> nova-net
>> =======
>>
>> OMG, this is still a thing. We need to actually work out what we’re
>> doing here, and then do it. The path isn’t particularly clear to me
>> any more, I thought I understood what we needed to do in Kilo, but it
>> turns out that operators don’t feel that plan meets their needs.
>> Somehow we need to get this work done. This is an obvious candidate
>> for a summit session, if we can come up with a concrete proposal to
>> discuss.
>>
>> bugs
>> ====
>>
>> Trivial bug monkey’ing has worked well for us in Kilo, but one of our
>> monkeys is off running as a PTL. We need to ensure we have this
>> staffed with people who understand the constraints on the bugs we’re
>> willing to let through this process. It would be sad to see this die
>> on the vine.
>>
>> We also need to fix more bugs. I know we always say this, but we don’t
>> have enough senior developers just kicking around looking at bugs to
>> fix in a systematic way. This is something I used to do when I had
>> more time before PTL’ing became a thing. If I am not elected this is
>> the other thing I’ll probably go back to spending time on.
>>
>> conclusion
>> ========
>>
>> I make no claim that my list is exhaustive. What else do you think we
>> should be tackling in Liberty?
>>
>> Michael
>>
>
> For better test coverage, we have a few things to do:
>
> 1. Make the ceph job voting: https://review.openstack.org/#/c/170913/
>
> 2. Get the aiocpu job (which tests live block migrate) stable and
> voting, it has already caught some live migrate regressions recently.
>
> 3. Get the cells job stable and voting (we're pretty close).
>
> 4. We can get the Fedora 21 job in Nova's experimental queue:
>
> https://review.openstack.org/#/c/171795/
>
> That allows us to test libvirt features (like live snapshot) on a newer
> version than what's in the gate on ubuntu 14.04.
>

An update:

1. The ceph job is voting on master (and eventually stable/kilo) for 
nova/cinder/glance.

2. The aiopcpu job is in the process of being stabilized and should soon 
be voting.

3. WIP

4. The fc21 job is in the nova experimental queue now.

--

Adding 5:

We don't have any evacuate testing in Tempest today.  We have rebuild, 
but not evacuate.  I'll start working on that as a per-requisite for 
Dan's spec on making evacuate more robust:

https://review.openstack.org/#/c/161444/

-- 

Thanks,

Matt Riedemann