Colin, +1 on this. I've just created https://github.com/CentOS-PaaS-SIG/centos-paas-ci and will be contributing there PaaS CI things. I intend to use the cciskel-duffy script, and hope to model things similarly. One thought I have been having about the metadata bits we discussed yesterday in the meeting. What if we didn't have duffy do the metadata, but rather consumed the session values, nodes, etc. from duffy, then allowed the cciskel-duffy to pull in a json file that helped define metadata. I can see that you are doing a small inventory bit in the code, it looks mostly around ansible groups. Consider the following use case/story. I've requested three nodes from duffy, for an openshift cluster. One will be the master, the other two will be nodes. Putting a custom built RPM repository on one node (not the master), and then installing using the atomic-openshift-installer. a installer.cfg.yml file will need to be created which details these items. Having this in a dynamically-generated inventory from your cciskel-duffy tool seems like a great location, at least until duffy can do this itself. Thoughts? herlo On Wed, May 18, 2016 at 6:08 PM, Colin Walters <walters at verbum.org> wrote: > > > On Wed, May 18, 2016, at 05:05 PM, Colin Walters wrote: > > Hi, > > > > https://github.com/cgwalters/centos-ci-skeleton/releases/tag/v2016.1 > > > > is a repo I put together today that's factoring out some recent work > > I did on a new duffy wrapper script: > > > > https://github.com/cgwalters/centos-ci-skeleton/releases/tag/v2016.1 > > This second link should have been > https://github.com/cgwalters/centos-ci-skeleton/blob/master/cciskel-duffy > _______________________________________________ > Ci-users mailing list > Ci-users at centos.org > https://lists.centos.org/mailman/listinfo/ci-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/ci-users/attachments/20160519/31d73582/attachment-0003.html>