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 <mbul...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
