On Mon, Sep 18, 2017 at 3:10 PM, Ken Dreyer
<kdreyer(a)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/5389b4c44b1e2c1dc308...
+1 we have a DO-NOT-MERGE submission to test newer versions of
ceph-ansible already:
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
Thanks!
1.