On 29/11/2017 15:46, Alfredo Moralejo Alonso wrote:
On Wed, Nov 29, 2017 at 3:32 PM, Haïkel <hgue...@fedoraproject.org
<mailto:hgue...@fedoraproject.org>> wrote:
2017-11-29 13:16 GMT+01:00 Alan Pevec <ape...@redhat.com
<mailto:ape...@redhat.com>>:
> Hi all,
>
> we as a community last discussed RDO definition of done more than a
> year ago and it was documented[1]
>
> In the meantime we have multiple changes in the RDO promotion
> process, most significant is that we do not run all the CI promotion
> jobs in the single Jenkins pipeline, instead there is now an
> increasing number of periodic Zuul jobs in review.rdoproject.org
<http://review.rdoproject.org>
> reporting to DLRN API database.
> Promotion is performed asynchronously when all the required jobs report
success.
>
> At the same time, TripleO as the deployment project with the most
> coverage in the promotion CI, has moved to be completely containerized
> in Queens.
> While RDO does provide container registry which is used with RDO
> Trunk, there aren't currently plans to provide containers built from
> the stable RPM builds as discussed on this list [2] around Pike GA.
> Even if we do all the work listed in [2] problem stays that containers
> are currently installer specific and we cannot realistically provide
> separate set of containers for each of TripleO, Kolla, OSA...
>
It makes sense as RDO is installer-agnostic. It's an opportunity to
reconsider how
we collaborate with those projects.
> Proposal would be to redefine DoD as follows:
> - RDO GA release delivers RPM packages via CentOS Cloud SIG repos,
> built from pristine upstream source tarballs
ack
> - CI promotion GA criteria is changed from Jenkins pipeline to the
> list of jobs running with RPM packages directly, initial set would be
> all weirdo jobs running in [3]
I'd like to ensure that TripleO CI is still monitored closely during
the development cycle.
So it can be a non-blocking criteria for GA.
As Javier noticed it means that our jobs will be based upon POI and
packstack. It should encourage
us to work with other installers supporting "raw" packages to make
sure that we will be able to test our
artefacts long-term.
> - TripleO jobs would not be part of RDO GA criteria since TripelO now
> requires containers which RDO will not ship.TripleO promotion CI will
> continue running with containers built with RDO Trunk packages.
>
Question is to know if upstream is okay with shipping containers
images using
our trunk packages. Otherwise ack.
Would it make sense to include a job to build containers using RPMs
cloudsig repos as release criteria?, I'm not talking about publish those
containers, just make sure that they can be built using kolla with
tripleo overrides.
Partially yes, we still need to run the full suite of tests during
development cycle so that we don't discover very late packaging issues.
But in a sense, it shouldn't be a blocker, as David pointed out, nearing
GA, our packaging should be in a good shape, so installers bugs should
not block us.
But it's only true if we pay attention to keep containers building and
running using our packages during the whole cycle.
H.
Regards,
H.
> I'm adding this topic on the agenda for the RDO meeting today, I
won't
> be able to join but we need to get that discussion going so we have
> updated DoD ready for Queens GA.
>
> Cheers,
> Alan
>
> [1]
https://www.rdoproject.org/blog/2016/05/technical-definition-of-done/
<https://www.rdoproject.org/blog/2016/05/technical-definition-of-done/>
> [2]
https://www.redhat.com/archives/rdo-list/2017-August/msg00069.html
<https://www.redhat.com/archives/rdo-list/2017-August/msg00069.html>
> [3]
https://ci.centos.org/view/rdo/view/promotion-pipeline/job/rdo_trunk-promote-master-current-tripleo/
<https://ci.centos.org/view/rdo/view/promotion-pipeline/job/rdo_trunk-promote-master-current-tripleo/>
> _______________________________________________
> dev mailing list
> d...@lists.rdoproject.org <mailto:d...@lists.rdoproject.org>
> http://lists.rdoproject.org/mailman/listinfo/dev
<http://lists.rdoproject.org/mailman/listinfo/dev>
>
> To unsubscribe: dev-unsubscr...@lists.rdoproject.org
<mailto:dev-unsubscr...@lists.rdoproject.org>
_______________________________________________
dev mailing list
d...@lists.rdoproject.org <mailto:d...@lists.rdoproject.org>
http://lists.rdoproject.org/mailman/listinfo/dev
<http://lists.rdoproject.org/mailman/listinfo/dev>
To unsubscribe: dev-unsubscr...@lists.rdoproject.org
<mailto:dev-unsubscr...@lists.rdoproject.org>
_______________________________________________
dev mailing list
d...@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev
To unsubscribe: dev-unsubscr...@lists.rdoproject.org
_______________________________________________
users mailing list
users@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/users
To unsubscribe: users-unsubscr...@lists.rdoproject.org
