Re: [Gluster-infra] qcow2 images / jenkins machines
On Thu, Mar 10, 2016 at 07:09:29PM -0500, Dan Lambright wrote: > > > - Original Message - > > From: "Michael Scherer" > > To: "Dan Lambright" > > Cc: "gluster-infra" > > Sent: Thursday, March 10, 2016 2:10:10 PM > > Subject: Re: [Gluster-infra] qcow2 images / jenkins machines > > > > Le mercredi 09 mars 2016 à 11:49 -0500, Dan Lambright a écrit : > > > I would like to load onto openstack qcow2 images and profiles most closely > > > resembling what we run in jenkins, to recreate problems seen in > > > regression. > > > > > > What are the OS levels do we use on Jenkins for testing? I see: > > > > > > netbsd7 > > > > > > centos6 > > > > > > fedora22 > > > > > > and "nbslave", RHEL7 ? > > > > > > This is a very cursory look. How much memory and cores are these images > > > given? > > > > > > If anyone knows the answer to these questions, response is appreciated. > > > > so we have mostly centos 6 and netbsd 7, running on rackspace > > > > The centos 6 are > > 2g of ram, 2 core > > model name : Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz > > > > Fedora 22 is just for smoke tests. > > Ther eis another Centos - who was here to validate the automated > > deployment, and a freebsd server for smoke test. > > > > We do not use image based deployment, but mostly salt, using this > > states : > > https://github.com/gluster/gluster.org_salt_states/blob/master/jenkins/slave.sls > > > > We will be converting this to ansible in the coming month, and > > Raghavendra Talur was working on a vagrant/ansible setup for testing too > > (hope we can unify both at some time in the future too) > > > > No RHEL/Centos 7 yet, but we should. > > I think RHEL/Centos7 would be a good thing from the point of view of testing. Indeed. And coincidentally I spoke with Kaushal and MS about it yesterday. We plan to setup a shadow job in the CentOS CI that runs regression tests on CentOS 7. It will not start voting in Gerrit immediately, we'll need to see if it runs stable enough for that first. This makes it easy to try out the amazing infrastructure that the CentOS team provides for us, and see how our tests function on CentOS 7. Hopefully more details about this follow soon. Niels signature.asc Description: PGP signature ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] Restore github mirror sync for libgfapi-python and gluster-swift
- Original Message - > From: "Michael Scherer" > To: "gluster-infra" > Sent: Wednesday, March 9, 2016 3:01:01 PM > Subject: Re: [Gluster-infra] Restore github mirror sync for libgfapi-python > and gluster-swift > > Le mercredi 09 mars 2016 à 12:44 +0530, Kaushal M a écrit : > > This happened because of the changes we did with ssh-keys used for > > replication. I'd forgotten that this had been done, and was expecting > > pushes to happen automatically. > > > > Earlier, a single users key was used (key of one of the admins of the > > gluster organization, Avati initially) to push changes from gerrit to > > github. > > This enabled all repositories in gerrit to be automatically be pushed > > into to its replica in github ( in gerrit would be > > automatically pushed to github/). > > This key got changed/deleted which caused replication to fail a while back. > > > > To avoid tying pushes to a single user like this, a separate key was > > setup for each github repo, and gerrit was setup to use the respective > > keys to push to each repo. > > This requires manual replication configuration. This change was > > implemented only for the glusterfs and glusterfs-specs repos. > > All other repos require manual configuration. > > Yep. I did sent the process on the list, but didn't automate as i was > not expecting more repo to be added. > > > We'll try to comeup with a better way to do this replication. If we > > can't, we'll need to manually set up the keys and encryption for each > > repo. > > Yeah, so the ideal situation is that we have some automation. However, > doing that for gluster seems a bit more complicated (there is API, but > then you have to deal with oauth, did I already said how much SaaS > service make our life harder today ? ). > > We did discuss on irc about it, and so there is basically 2 solutions: > > - go back to a gluster bot account, but that requires a way to secure > the password properly (especially since no one will be checking the > audit log for it). We could use 2FA for that account using a remote > command line script on a secure server, but we still need a way to store > the password in a secure way. And of course, like all password > management, it requires that we decide who has access, etc, etc. > > - make something that automate part of it, and let the part about adding > credentials to github to a admin. That's the part I plan to do later, > since that could be just some ansible playbook > > - make something more like self service. Have people declare "I want to > sync that repo to that repo I am admin of", and have it done > automatically on their behalf. It would requires a lot more coding > around github api, but would be the cleanest. > > > Another issue that arise with the current scheme is that push are made > under my name as I am the one that added the keys. That was somewhat > unexpected, and I do not see a easy way out of it. (unfortunately, it > doesn't appear in my stats, so I can't have a endless commit streak..) > I am not sure if that's a problem in practice or not, since that's not > impacting the git repo, just the activity stream. (again, we can't fix > it to be correct, because we are depending on a proprietary SaaS > offering, but I already complained about it today) > > Oh, and I did add the replication for the 2 repos for now. This does not seem to have worked. I was hoping it would be triggered from Gerrit when a change on review is merged. At least one change on review was merged yesterday to both repos after the replication was re-established but I still don't see them on github. For now, I'll keep the github repo as is if it helps finding out why the sync failed to happen. I did take a look at the gerrit plugin[1] for replication but I don't have access to look at existing config. I'll push the changes manually to github repos later if this can't work. [1]: https://gerrit.googlesource.com/plugins/replication/+doc/master/src/main/resources/Documentation/config.md > -- > Michael Scherer > Sysadmin, Community Infrastructure and Platform, OSAS > > > > ___ > Gluster-infra mailing list > Gluster-infra@gluster.org > http://www.gluster.org/mailman/listinfo/gluster-infra ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] qcow2 images / jenkins machines
- Original Message - > From: "Michael Scherer" > To: "Dan Lambright" > Cc: "gluster-infra" > Sent: Thursday, March 10, 2016 2:10:10 PM > Subject: Re: [Gluster-infra] qcow2 images / jenkins machines > > Le mercredi 09 mars 2016 à 11:49 -0500, Dan Lambright a écrit : > > I would like to load onto openstack qcow2 images and profiles most closely > > resembling what we run in jenkins, to recreate problems seen in > > regression. > > > > What are the OS levels do we use on Jenkins for testing? I see: > > > > netbsd7 > > > > centos6 > > > > fedora22 > > > > and "nbslave", RHEL7 ? > > > > This is a very cursory look. How much memory and cores are these images > > given? > > > > If anyone knows the answer to these questions, response is appreciated. > > so we have mostly centos 6 and netbsd 7, running on rackspace > > The centos 6 are > 2g of ram, 2 core > model name: Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz > > Fedora 22 is just for smoke tests. > Ther eis another Centos - who was here to validate the automated > deployment, and a freebsd server for smoke test. > > We do not use image based deployment, but mostly salt, using this > states : > https://github.com/gluster/gluster.org_salt_states/blob/master/jenkins/slave.sls > > We will be converting this to ansible in the coming month, and > Raghavendra Talur was working on a vagrant/ansible setup for testing too > (hope we can unify both at some time in the future too) > > No RHEL/Centos 7 yet, but we should. I think RHEL/Centos7 would be a good thing from the point of view of testing. > > -- > Michael Scherer > Sysadmin, Community Infrastructure and Platform, OSAS > > > ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
[Gluster-infra] Jenkins Down for Maintenance on Tuesday, March 15
Hi all, This is advanced notice that jenkins is coming down for maintenance on March 15, 12pm UTC for a maintenance window of 4 hours. Let me know if this disrupts any plans you've made. Thanks! - amye -- Amye Scavarda | a...@redhat.com | Gluster Community Lead ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] qcow2 images / jenkins machines
Le mercredi 09 mars 2016 à 11:49 -0500, Dan Lambright a écrit : > I would like to load onto openstack qcow2 images and profiles most closely > resembling what we run in jenkins, to recreate problems seen in regression. > > What are the OS levels do we use on Jenkins for testing? I see: > > netbsd7 > > centos6 > > fedora22 > > and "nbslave", RHEL7 ? > > This is a very cursory look. How much memory and cores are these images given? > > If anyone knows the answer to these questions, response is appreciated. so we have mostly centos 6 and netbsd 7, running on rackspace The centos 6 are 2g of ram, 2 core model name : Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz Fedora 22 is just for smoke tests. Ther eis another Centos - who was here to validate the automated deployment, and a freebsd server for smoke test. We do not use image based deployment, but mostly salt, using this states : https://github.com/gluster/gluster.org_salt_states/blob/master/jenkins/slave.sls We will be converting this to ansible in the coming month, and Raghavendra Talur was working on a vagrant/ansible setup for testing too (hope we can unify both at some time in the future too) No RHEL/Centos 7 yet, but we should. -- Michael Scherer Sysadmin, Community Infrastructure and Platform, OSAS signature.asc Description: This is a digitally signed message part ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] Mirror of the gluster packages.
On 02/16/2016 09:20 AM, Mike Hulsman wrote: Hi, I had a chat with Michael Scherer about setting up a mirror for download.gluster.org As one of the mirror admins of ftp.nluug.nl I can setup a mirror for gluster. Please let me know if that is interesting for Gluster. Yes, please do it. What information is needed to setup the sync ? We prefer rsync, is you add "192.87.102.41" to your acl's than I can proceed with the setup on our side. Just a reminder, if a mirror of gluster is still needed. At the moment we are connected with an 10G adapter, and therefore ip adresses are changed. Our new addresses are: 145.220.21.40 and on Ipv6 2001:67c:6ec:221:145:220:21:40 Mike -- Kaleb Mike ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] Requesting CentOS regression machine to debug!
You can use slave23.cloud.gluster.org . I've marked it offline in Jenkins for now. Let us know once you're done, so that it can be re-enabled. ~kaushal On Thu, Mar 10, 2016 at 6:27 PM, Kotresh Hiremath Ravishankar wrote: > Hi, > > Please provide me CentOS regression machine offline to debug the regression > failure. > > Thanks and Regards, > Kotresh H R > > ___ > Gluster-infra mailing list > Gluster-infra@gluster.org > http://www.gluster.org/mailman/listinfo/gluster-infra ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
[Gluster-infra] Requesting CentOS regression machine to debug!
Hi, Please provide me CentOS regression machine offline to debug the regression failure. Thanks and Regards, Kotresh H R ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
[Gluster-infra] [Bug 1316432] All jenkins slaves should have netstat installed
https://bugzilla.redhat.com/show_bug.cgi?id=1316432 Raghavendra Talur changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |WORKSFORME Last Closed||2016-03-10 03:52:34 --- Comment #1 from Raghavendra Talur --- My bad, Michael Scherer has already made the changes and jenkins slaves have netstat installed too. More info here: https://www.mail-archive.com/gluster-infra@gluster.org/msg01015.html -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=yxfdaQtXH8&a=cc_unsubscribe ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
[Gluster-infra] [Bug 1316432] All jenkins slaves should have netstat installed
https://bugzilla.redhat.com/show_bug.cgi?id=1316432 Raghavendra Talur changed: What|Removed |Added Blocks||1312832 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1312832 [Bug 1312832] tests fail because bug-924726.t depends on netstat -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=iS5kC50wcK&a=cc_unsubscribe ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
[Gluster-infra] [Bug 1316432] New: All jenkins slaves should have netstat installed
https://bugzilla.redhat.com/show_bug.cgi?id=1316432 Bug ID: 1316432 Summary: All jenkins slaves should have netstat installed Product: GlusterFS Version: mainline Component: project-infrastructure Assignee: b...@gluster.org Reporter: rta...@redhat.com CC: b...@gluster.org, gluster-infra@gluster.org Description of problem: netstat is a useful tool to have while testing. Some of the tests already use it. We have also made it a requirement of our tests framework. We now need to make sure that jenkins slaves have netstat installed. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=1Dt6t0h4Vr&a=cc_unsubscribe ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
