Open Stack

On 01/17/2017 09:57 AM, mathieu bultel wrote:
> On 01/17/2017 04:42 PM, Emilien Macchi wrote:
>> On Tue, Jan 17, 2017 at 9:34 AM, mathieu bultel <mbultel at redhat.com> wrote:
>>> Hi Adriano
>>>
>>> On 01/17/2017 03:05 PM, Adriano Petrich wrote:
>>>
>>> So I want to make a backwards compatibility job upstream so from last scrum
>>> I got the feeling that we should not be adding more stuff to the
>>> experimental jobs due to lack of resources (and large queues)
>>>
>>> What kind of "test" do you want to add ?
>>> I ask because since few days we have upstream an upgrade job that does:
>>> master UC -> deploying a Newton OC with Newton OC + tht stable/newton ->
>>> then upgrade the OC to master with tht master branch.
>>> It's sounds like a "small backward compatibility" validation, but I'm not
>>> sure if it's cover what you need.
>> While I understand what is the idea, I don't see the use case.
>> In which case you want to deploy a old version of overcloud by using a
>> recent undercloud?
>> Why don't use deploy a stable undercloud to deploy a stable overcloud?
> From my side, the use case is the major OC upgrade. We don't want to
> test the major upgrade of the undercloud (since a job already exist),

The problem I see with this is that the undercloud upgrade job does 
extremely basic testing of the upgraded undercloud.  It's just a smoke 
test to make sure the upgrade can be completed and no services went down 
after it.  I would not assume that is sufficient coverage of the upgrade 
case, it's just what we could do quickly(-ish) to get _some_ undercloud 
upgrade coverage in place.

> only overcloud, that's why we start by a "master" undercloud, and that
> save us from unwanted/unrelated issues due to the UC upgrade and reduce
> the duration of the job.
>
>>
>>> Is that so? I was thinking about using nonha-multinode-oooq that seems to be
>>> working.
>>>
>>> Is that allright to add this new job or should I wait until we get more
>>> resource and do ci.centos for now, or any idea on where to do this is also
>>> welcome.
>>>
>>>
>>> Cheers,
>>>    Adriano
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>