On 04/19/2012 02:18 PM, Martina Kollarova wrote: I'm not sure this merits an 'incubation' project, and I'm fine with creating a separate repo for this as a sub project of the sdk and defining you as a maintainer for it. but looking for comments from others on the mailing list before doing this.

----- Original Message ----- Keep in mind this test hasn't run yet due to missing resources in upstream jenkins environment. (physical server, iscsi storage devices (needs to be mapped to local ones?) )

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/19/2012 12:12 PM, Mike Burns wrote: So we're a bit stuck in a circle, because our current hosting for Jenkins is sub-par due to AIUI EC2 not being the best environment for continuous integration testing. I'd like to bring more on-par resources from Red Hat, but so far the ones we have gotten access to live inside of the private network. I don't yet see anything becoming available from Red Hat for external usage until after June 2012. I wouldn't be surprised if that situation were similar with other people and their supporting organizations or other private hosting situation. External hosting is sometimes more precious than internal labs. I was wondering if it is worth it for the short-term to do CI runs on internal networks and publish just the results externally? Functionally this is the same for some people, but for anyone who wants to help with Infrastructure, it's a closed door. (There may be other considerations to having Jenkins internally that I'm not aware of.) But it might be worth doing for a short period - six months? - to get us what we need on the development side. Itamar reports to me that performance with the EC2 hosts is 3x slower than what they get in their lab. That's a lot of wasted CI time. Of course, Infrastructure supporting that idea means that if anyone has private machines they want to use as Jenkins hosts, we'd want to hook them up with the same situation (somehow.) Ideally, we'll get more hosts provided by community members and supporters, but currently we don't have that. I would want to set a target end-date to return Jenkins et al to external-only hosting so the Infrastructure team can be a full participant. My original goal in setting up Infrastructure as fully open was based on my experience in other projects, but those are already established projects with donated hosting by many providers and none of them started out with that much external hosting. Realistically, this may be something we need to work toward. What do all of you think? BTW, if anyone knows KVM using hosting providers who want to support oVirt development, getting us physical hosts and virtual machines would be a *great* way to help. We can talk with the Board about adding them to the sponsors page. - - Karsten - -- name: Karsten 'quaid' Wade, Sr. Community Architect team: Red Hat Community Architecture & Leadership uri: http://communityleadershipteam.org http://TheOpenSourceWay.org gpg: AD0E0C41

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/23/2012 11:33 PM, Itamar Heim wrote: Itamar and I have been having some progress internally on getting hosts that may be able to be exposed externally so we can have shared community infrastructure. Based on that and the immediate need, I'd like us to start allowing Itamar's team to use whatever they have internally to support development, with these understandings: * Publish all results ASAP publicly, as per usual. * Move the workloads externally ASAP when we can. * Look for the future of how we want to handle enabling Jenkins servers to be used on internal networks so oVirt members can use more readily available internal hosts for infrastructure that doesn't require or benefit from an open collaboration. Basically, it makes sense to me that if we have a standard set of workloads that can be run on any instance, there is no reason anyone can't commit to doing that on infrastructure they run themselves. That is different from the actual participation components that should be run entirely externally. The project needs to have 100% r/w access to all of the online components that make up the project, but that doesn't have to include CI servers running a standard workload on an open source stack. - - Karsten - -- name: Karsten 'quaid' Wade, Sr. Community Architect team: Red Hat Community Architecture & Leadership uri: http://communityleadershipteam.org http://TheOpenSourceWay.org gpg: AD0E0C41

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/07/2012 08:28 PM, Itamar Heim wrote: OK, so far this discussion has been you and I agreeing on how to do things, with no other objections. Unless there is an objection now :) I'm going to say our +1s resolve the question in this thread. Go ahead and run Jenkins slaves internally, etc., and just report back out to this list (and write up on the wiki) as things are figured out and enacted. Does that work for you? - - Karsten - -- name: Karsten 'quaid' Wade, Sr. Community Architect team: Red Hat Community Architecture & Leadership uri: http://communityleadershipteam.org http://TheOpenSourceWay.org gpg: AD0E0C41

The RedHat internal RHEVM tests take about 2 hours to run, but I hope that this will be a lot less time consuming, since it should be a subset of those. I'm not sure about memory/cpu consumption though. The engine should be up, one host and a few storages should be available, ideally both NFS and iSCSI. http://www.mail-archive.com/infra@ovirt.org/msg00117.html Standard XUnit output is supported, since it uses the nosetest framework (test runner for python unittest). Martina

On 04/19/2012 03:27 PM, Mike Burns wrote: from past experience, when a testing repo is used for system test (not unitests), you want to be able to track changes in tests vs. changes in code (and this repo would test some of the engine/vdsm as well). this doesn't lend to branches too well. hence i'm for a separate repo.

On 19/04/12 15:47, Doron Fediuck wrote: One more thing- May we ask for an overview wiki, later to evolve on usage steps, etc? -- /d Why doesn't DOS ever say "EXCELLENT command or filename!"

Martina, per the discussion and since no comments on suggestion, I've created a new project on gerrit called ovirt-engine-sdk-tests. configuration includes: fast forward, change-id and signed-off-by required. I'll define you as maintainer for it once you register to gerrit. please update the website to reflect that sub repo under: http://www.ovirt.org/project/subprojects/ Thanks, Itamar On 04/19/2012 04:02 PM, Mike Burns wrote: