[openstack-dev] TC candidacy
Emilien Macchi
emilien at redhat.com
Tue Oct 4 13:06:05 UTC 2016
On Tue, Oct 4, 2016 at 8:59 AM, Matt Riedemann
<mriedem at linux.vnet.ibm.com> wrote:
> On 10/3/2016 10:03 PM, Emilien Macchi wrote:
>>
>>
>> I'm actually proposing to run TripleO multinode job in Nova experimental
>> jobs:
>> https://review.openstack.org/#/c/381322/
>> It's non-voting and run at demand, so we're not breaking anything.
>>
>> tripleo-ci-centos-7-nonha-multinode is a CI job that takes ~40-60
>> minutes (we're working on reducing its runtime) and deploy TripleO in
>> multinode environment.
>> I think it would be a good start to see if non-devstack jobs would
>> bring useful feedback.
>>
>
> I'll repeat here what I asked in the review above: on what kinds of changes
> should nova developers and reviewers think to run the experimental queue job
> for tripleo? Since the experimental queue is on-demand we generally only run
> it for specific changes that aren't tested by our normal check/gate jobs.
> Like we have an lxc job in the experimental queue and that's fairly
> straight-forward on when to run it, similar with neutron + dvr + multinode.
>
> But what would prompt me to run the tripleo job on a nova change? Things
> that impact upgrades? Configuration option changes, like dropping deprecated
> configuration options or changing their default behavior?
Generally speaking, making sure it works fine outside the gate is in
my opinion an interesting information, as we know developers tend to
take care of devstack only (and I understand why).
But yes, things like:
- making sure a change is backward compatible outside devstack
(configuration or behaviors): using TripleO job now, but why not Kolla
or another tool in the Big Tent?
- test real upgrades, looking at sdake's reply it seems like Kolla has
a bunch of jobs for that.
Also I proposed to use the experimental pipeline right now because I
like to iterate. If we see some benefits and results, I would be in
favor of moving the jobs to the check pipeline, as non-voting.
Thanks Matt for being open of such a change,
--
Emilien Macchi
More information about the OpenStack-dev
mailing list