[rdo-list] ceph-ansible auto builds in cbs.centos.org

Giulio Fidente gfidente at redhat.com
Tue Sep 19 09:54:18 UTC 2017


On 09/18/2017 10:55 PM, John Fulton wrote:
> On Mon, Sep 18, 2017 at 3:10 PM, Ken Dreyer <kdreyer at redhat.com> wrote:
>> Hi folks,
>>
>> TL;DR new ceph-ansible tags are automatically built in the CentOS Storage SIG.
>>
>> The RDO team members have been building ceph-related RPMs in the
>> CentOS Storage SIG, including ceph-ansible. Specifically this has been
>> handled by Giulio Fidente and John Fulton on the OpenStack (RDO/OSP)
>> team.
>>
>> The reason is that TripleO relies on ceph-ansible to install Ceph, and
>> TripleO expects to install a ceph-ansible RPM. So RDO depends on the
>> ceph-ansible CBS builds.
>>
>> In the past Giulio had been doing these CentOS builds by hand,
>> rebuilding upstream SRPMs from shaman.ceph.com, for example
>> http://cbs.centos.org/koji/buildinfo?buildID=19762
>>
>> I have a job running in an internal Jenkins instance that now polls
>> https://github.com/ceph/ceph-ansible every hour and builds any new Git
>> tags within CBS. An example is
>> http://cbs.centos.org/koji/taskinfo?taskID=227958 , although that was
>> "scratch = True", and future builds will not be scratch builds. It is
>> using the script at https://github.com/ktdreyer/ceph-ansible-cbs
> 
> Thanks for working on this Ken.
> 
> For which repos are you doing this? I.e. what subset of the following
> is this now the case for?
> 
>  echo ceph-{jewel,luminous}-{release,testing,candidate}
> 
> TripleO CI uses ceph-ansible from centos-jewel (release) for the
> voting job scenario001-multinode-oooq-container, so I'd rather we
> didn't promote from testing to release until we know that
> scenario001-multinode-oooq-container is passing with the new
> ceph-ansible (otherwise we could break TripleO CI).
> 
> One way to test this is to have a submission which varies the line
> below to use not ceph-jewel but ceph-jewel-testing (though there is no
> mirror).
> 
> https://github.com/openstack/tripleo-quickstart/blob/5389b4c44b1e2c1dc30848359f8a415481cc86d1/config/release/tripleo-ci/consistent-master.yml#L74
+1 we have a DO-NOT-MERGE submission to test newer versions of
ceph-ansible already: https://review.openstack.org/#/c/501987/

this is currently using the -testing repo [1]

If I understand correctly, the automated builds are tagged -candidate so
I could tag -testing any of them to test it in tripleo/ci

At which point, should it pass tripleo/ci, we can give green light to
the ceph-ansible tagging and tag the same build -release in cbs too,
does it sound a viable plan?

On a side note, I think it'd be also useful to have some more coverage
in ceph-ansible ci for the parameters which tripleo uses and
specifically gate ceph-ansible commits with a job which uses those
parameters; do you think it would be feasible?

The list of params can be gathered from the tripleo templates; I am
adding some links here to the files which are "composed" (depending on
the services enabled) to build the full list of params

https://github.com/openstack/tripleo-heat-templates/blob/master/docker/services/ceph-ansible/ceph-base.yaml#L198-L294

https://github.com/openstack/tripleo-heat-templates/blob/master/docker/services/ceph-ansible/ceph-mon.yaml#L84-L86

https://github.com/openstack/tripleo-heat-templates/blob/master/docker/services/ceph-ansible/ceph-osd.yaml#L37-L41

https://github.com/openstack/tripleo-heat-templates/blob/master/docker/services/ceph-ansible/ceph-mds.yaml#L81-L83

https://github.com/openstack/tripleo-heat-templates/blob/master/docker/services/ceph-ansible/ceph-rgw.yaml#L74-L77

https://github.com/openstack/tripleo-heat-templates/blob/master/docker/services/ceph-ansible/ceph-external.yaml#L66

Thanks!

1. https://review.openstack.org/#/c/501810/
-- 
Giulio Fidente
GPG KEY: 08D733BA




More information about the dev mailing list