Hi,
at the moment kubernetes, docker, etcd and other atomic packages has no CI testing in CentOS. The packages built for CentOS are taken from Fedora's repositories. There is already an effort to create CI for Fedora builds. Currently kubernetes has its own CI job which can be taken as an template for other jobs for docker, etcd, etc. in Fedora. The job among other things consists of a builder, i.e. script that can be broken down into two parts: installation and testing. The installation part takes care of installing, updating and downloading all necessary builds. Testing part runs tests. As the script is universal and differs only in the installation part, other distributions can reuse it. RHEL does that after a simple modification of the installation part. The workflow is following: update kubernetes ci job for Fedora, if it works, update it for RHEL.
I would like to continue in the same sense for CentOS. Create a job for centos's kubernetes. The question is where should it run? All jobs (for Fedora and RHEL) are run in redhat's internal Jenkins. For CentOS it would be better to run the job in its own CI environment as this is not the only job. Docker, possible etcd and cadvisor can have its own set of sets that are suitable. So distributing CI effort among all distributions that are involved is natural. Another option is to run all centos jobs related to atomic packages in the internal Jenkins.
Why should we bother with running centos's jobs in redhat's environment? I have all jobs at one place so I can update them all at once and they don't get out of sync. It does not take me much time to create another ci job for CentOS once I have created one for Fedora. However, I need a trigger that will trigger the job (I have started a discussion on setting up fedmsg for CentOS that could provide such a trigger [1]). Second, the CI environment is internal so everyone who wants to take a look at run jobs must have RH credentials. If CentOS's CI is used the responsibility for maintaining all jobs and keeping them in sync is completely on CentOS side.
Or something between? What about I will first test the new or updated job for CentOS in internal env and then forward all changes to someone responsible for CentOS's CI which would be who? I am not against taking care of this part if I get an access/credentials to CentOS to access your CI.
Some jobs in internal RH Ci environment contain private data so I can not go public. What can go public is the builder (script) for Fedora. However I don't see any benefit sharing the script without the entire *.yaml files that create the job. On the other hand if you provide a public repository I can contribute to I will update CentOS's jobs as changes or new jobs appears. Provided your template for a job.
[1] http://lists.centos.org/pipermail/centos-devel/2015-June/013415.html
Kind Regards Jan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/08/2015 09:23 AM, Jan Chaloupka wrote:
What about I will first test the new or updated job for CentOS in internal env and then forward all changes to someone responsible for CentOS's CI which would be who? I am not against taking care of this part if I get an access/credentials to CentOS to access your CI.
I'll let others speak up about this, but if I'm reading you correctly, the above is what we are looking for -- upstream project teams willing and able to "own" their jobs in ci.centos.org. There really aren't many spare resources (people's time) waiting to take jobs thrown over a wall and own them for you.
You would join the Atomic SIG and ask for credentials to build and run CI jobs for all of the above. In fact, you are probably welcome to move all your jobs to ci.centos.org as your single place to work from rather than the internal-to-RH CI.
Regards, - - Karsten - -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Mon, Jun 8, 2015, at 04:24 PM, Karsten Wade wrote:
You would join the Atomic SIG and ask for credentials to build and run CI jobs for all of the above. In fact, you are probably welcome to move all your jobs to ci.centos.org as your single place to work from rather than the internal-to-RH CI.
I don't think it's realistic to have CI/testing decoupled in infrastructure from the rel-eng/delivery - you really want tight integration to support things like "promotion" workflows where a build gets shipped in a broader channel after testing.
That argues for a model where Fedora has an independent Jenkins that's ideally similar in capabilities and model to what CentOS has. I think most of the work in Fedora currently is around Taskotron, which... it's not really worth going into the details too much, but I'm sure a Jenkins instance could be dedicated to this.
We could stand up something in projectatomic.io which gathers a summary of reporting but does not actually perform testing on its own, like what we're doing for links to images.
I don't see why we need to move anything as long as we can produce the results and artifacts and have it be outward facing.
I am currently getting all atomic fedora, centos, and RHEL on our internal CI infrastructure.
The main thing missing for Centos that we have for Fedora and RHEL is a notification mechanism. We use fedmsg and CI message bus for those. I know Jan Chaloupke was advocating something similar for Centos.
I think it is a good idea since the mechanism for notification and triggering are essentially the same.
On Fri, 2015-06-12 at 15:36 -0400, Colin Walters wrote:
On Mon, Jun 8, 2015, at 04:24 PM, Karsten Wade wrote:
You would join the Atomic SIG and ask for credentials to build and run CI jobs for all of the above. In fact, you are probably welcome to move all your jobs to ci.centos.org as your single place to work from rather than the internal-to-RH CI.
I don't think it's realistic to have CI/testing decoupled in infrastructure from the rel-eng/delivery - you really want tight integration to support things like "promotion" workflows where a build gets shipped in a broader channel after testing.
That argues for a model where Fedora has an independent Jenkins that's ideally similar in capabilities and model to what CentOS has. I think most of the work in Fedora currently is around Taskotron, which... it's not really worth going into the details too much, but I'm sure a Jenkins instance could be dedicated to this.
We could stand up something in projectatomic.io which gathers a summary of reporting but does not actually perform testing on its own, like what we're doing for links to images.
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 06/08/2015 10:24 PM, Karsten Wade wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/08/2015 09:23 AM, Jan Chaloupka wrote:
What about I will first test the new or updated job for CentOS in internal env and then forward all changes to someone responsible for CentOS's CI which would be who? I am not against taking care of this part if I get an access/credentials to CentOS to access your CI.
I'll let others speak up about this, but if I'm reading you correctly, the above is what we are looking for -- upstream project teams willing and able to "own" their jobs in ci.centos.org. There really aren't many spare resources (people's time) waiting to take jobs thrown over a wall and own them for you.
You would join the Atomic SIG and ask for credentials to build and run CI jobs for all of the above. In fact, you are probably welcome to move all your jobs to ci.centos.org as your single place to work from rather than the internal-to-RH CI.
How can join the Atomic SIG? Is there a workflow for it I have to follow?
Still I would like to be a mediator that would "just" update jobs in ci.centos.org and left analysis of errors/fails for one who is responsible for given component in CentOS. Kubernets Navid, Docker and etcd Lokesh, ...
Regards,
- Karsten
Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux)
iEYEARECAAYFAlV1+eQACgkQ2ZIOBq0ODEGBGgCgo6VqxyUwu0XDWumQwZpO6gaz 54YAn1TvuENm0iNa3WAnC6xdGJZj/mdQ =oPRg -----END PGP SIGNATURE----- _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
-
Ari LiVigni -
Colin Walters -
Jan Chaloupka -
Karsten Wade