Open Stack

On 29.8.2017 13:22, Giulio Fidente wrote:
> On 08/29/2017 11:14 AM, Jiří Stránský wrote:
>> Hi owls,
>>
>> the CI for containerized deployments with Pacemaker is close! In fact,
>> it works [1][2] (but there are pending changes to merge).
> 
> cool :D
> 
> I also spotted this which we need for ceph
> https://review.openstack.org/#/c/498356/
> 
> but I am not sure if we want to enable ceph in this job as we have it
> already in a couple of scenarios, more below ...

+1 on keeping it in scenarios if that covers our needs.

> 
>> The way it's proposed in gerrit currently is to switch the
>> centos-7-containers-multinode job (featureset010) to deploy with
>> Pacemaker. What do you think about making this switch as a first step?
>> (The OVB job is an option too, but that one is considerably closer to
>> timeouts already, so it may be better left as is.)
> 
> +1 on switching the existing job
> 
>> Later it would be nice to get a proper clustering test with 3
>> controllers. Should we try and switch the centos-7-ovb-ha-oooq job to
>> deploy containers on master and stable/pike? (Probably by adding a new
>> job that only runs on master + Pike, and making the old ovb-ha-oooq only
>> run upto Ocata, to keep the OVB capacity demands unchanged?) I'd be +1
>> on that since containers are the intended way of deploying Pike and
>> beyond. WDYT?
> 
> switching OVB to containers from pike seems fine because that's the
> indended way as you pointed, yet I would like to enable ceph in the
> upgrade job, and it requires multiple MON instances (multiple controllers)
> 
> would it make any sense to deploy the pacemaker / ceph combination using
> multiple controllers in the upgrade job and drop the standard ovb job
> (which doesn't do upgrade) or use it for other purposes?

It makes sense feature-wise to test upgrade with Ceph, i'd say it's a 
pretty common and important use case.

However i'm not sure how can we achieve it time-wise in CI. Is it 
possible to estimate how much time might the Ceph upgrade add?

A bit of context: Currently our only upgrade check job is non-OVB - 
containers-multinode-upgrades-nv. As of late we started hitting 
timeouts, and the job only does mixed-version deploy + 1 node AIO 
overcloud upgrade (just the main step). It doesn't do undercloud 
upgrade, nor compute upgrade, nor converge, and it still times out... 
It's a bit difficult to find things to cut off here. :D We could look 
into speeding things up (e.g. try to reintroduce selective container 
image upload etc.) but i think we might also be approaching the 
"natural" deploy+upgrade limits. We might need to bump up the timeouts 
if we want to test more things. Though it's not only about capacity of 
HW, it could also get unwieldy for devs if we keep increasing the 
feedback time from CI, so we're kinda in a tough spot with upgrade CI...

Jirka