Hello, I created a set of tests for the ovirt-engine-sdk that could be run using jenkins on each commit. Could you please create a git (+ gerrit) repo for this? Thanks Martina Kollarova RedHat Brno, RHEVM QE
On 04/19/2012 02:18 PM, Martina Kollarova wrote:
Hello,
I created a set of tests for the ovirt-engine-sdk that could be run using jenkins on each commit. Could you please create a git (+ gerrit) repo for this?
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 -----
On 04/19/2012 02:18 PM, Martina Kollarova wrote:
Hello,
I created a set of tests for the ovirt-engine-sdk that could be run using jenkins on each commit. Could you please create a git (+ gerrit) repo for this?
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.
Sounds like an important project, that will bring up the quality of the sdk. I'm missing some info about those tests: 1. How much resources will it consume? (running all the tests) 2. Any special requirement for the sdk tests? (engine up & running?) 3. What sort of Jenkins integration we're looking for? How the output looks like? Ofer.
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
----- Original Message -----
From: "Ofer Schreiber" <oschreib@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: infra@ovirt.org Sent: Thursday, April 19, 2012 3:23:31 PM Subject: Re: new git repo request
----- Original Message -----
On 04/19/2012 02:18 PM, Martina Kollarova wrote:
Hello,
I created a set of tests for the ovirt-engine-sdk that could be run using jenkins on each commit. Could you please create a git (+ gerrit) repo for this?
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.
Sounds like an important project, that will bring up the quality of the sdk.
I'm missing some info about those tests: 1. How much resources will it consume? (running all the tests) 2. Any special requirement for the sdk tests? (engine up & running?) 3. What sort of Jenkins integration we're looking for? How the output looks like?
Ofer.
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?) )
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
On Thu, 2012-04-19 at 08:26 -0400, Eyal Edri wrote:
----- Original Message -----
From: "Ofer Schreiber" <oschreib@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: infra@ovirt.org Sent: Thursday, April 19, 2012 3:23:31 PM Subject: Re: new git repo request
----- Original Message -----
On 04/19/2012 02:18 PM, Martina Kollarova wrote:
Hello,
I created a set of tests for the ovirt-engine-sdk that could be run using jenkins on each commit. Could you please create a git (+ gerrit) repo for this?
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.
Sounds like an important project, that will bring up the quality of the sdk.
I'm missing some info about those tests: 1. How much resources will it consume? (running all the tests) 2. Any special requirement for the sdk tests? (engine up & running?) 3. What sort of Jenkins integration we're looking for? How the output looks like?
Ofer.
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?) )
I'm adding hardware for jenkins to the agenda for the weekly meeting next week. Mike
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/19/2012 12:12 PM, Mike Burns wrote:
I'm adding hardware for jenkins to the agenda for the weekly meeting next week.
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 SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFPlgfY2ZIOBq0ODEERAnhaAJwMoIoBBX1lNMxGZADux48Xj7tvzwCg4mep TNNK7ymfuZ0C6kKBtm30+XE= =wcba -----END PGP SIGNATURE-----
On 04/24/2012 04:54 AM, Karsten 'quaid' Wade wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/19/2012 12:12 PM, Mike Burns wrote:
I'm adding hardware for jenkins to the agenda for the weekly meeting next week.
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?
my view is until we can resolve how to do this over publicly accessible community resources via some hosting provider, private CI is better to no CI. it will give the email/gerrit comment the patch broke a test, but not sure more details than that to lookup (hopefully, we can solve this by having the CI server push the reports out to the community one in EC2 somehow to make this more useful). however, it is not trivial to 'share' CI hosts across private networks, as the jenkins server needs access to the slaves (other than partitioning the responsibility for some of the jobs).
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 SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFPlgfY2ZIOBq0ODEERAnhaAJwMoIoBBX1lNMxGZADux48Xj7tvzwCg4mep TNNK7ymfuZ0C6kKBtm30+XE= =wcba -----END PGP SIGNATURE----- _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/23/2012 11:33 PM, Itamar Heim wrote:
my view is until we can resolve how to do this over publicly accessible community resources via some hosting provider, private CI is better to no CI.
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 SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFPqC4X2ZIOBq0ODEERAqTgAKCJx6k7c06qp/lUO+5l35o6SiH4nwCglkRr i9CJLIXQwAMnPK92H9V0mF8= =eq3m -----END PGP SIGNATURE-----
On 05/07/2012 11:18 PM, Karsten 'quaid' Wade wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/23/2012 11:33 PM, Itamar Heim wrote:
my view is until we can resolve how to do this over publicly accessible community resources via some hosting provider, private CI is better to no CI.
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.
the idea is any such server will be a jenkins slave, so the results are part of public jenkins.
* 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.
actually, that's one of the things we are looking at right now - allowing usage of servers as slaves without community access, where the slaves will run the batch. we are looking at this assuming this will be easier for most to contribute, rather than remote/external/accessible hosts. we are looking at a solution with community access as well - we may need to mix both due to space/connectivity and other constraints.
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.
as stated above - we are looking at this as well.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/07/2012 08:28 PM, Itamar Heim wrote:
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.
as stated above - we are looking at this as well.
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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFPqJyt2ZIOBq0ODEERAgr6AJ9G54f9OiIW7GdArZZ/Gh239+fehwCgvroW firVYtUF3uCLYZCfAoaTOAE= =4s/r -----END PGP SIGNATURE-----
On 05/08/2012 07:10 AM, Karsten 'quaid' Wade wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/07/2012 08:28 PM, Itamar Heim wrote:
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.
as stated above - we are looking at this as well.
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?
yes, once we resolve some internal logistics to use those hosts.
I'm missing some info about those tests: 1. How much resources will it consume? (running all the tests) 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.
2. Any special requirement for the sdk tests? (engine up& running?) 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
3. What sort of Jenkins integration we're looking for? How the output looks like? Standard XUnit output is supported, since it uses the nosetest framework (test runner for python unittest).
Martina
On Thu, 2012-04-19 at 14:35 +0300, Itamar Heim wrote:
On 04/19/2012 02:18 PM, Martina Kollarova wrote:
Hello,
I created a set of tests for the ovirt-engine-sdk that could be run using jenkins on each commit. Could you please create a git (+ gerrit) repo for this?
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.
I'm ok with the new repo, but couldn't it be included as a directory of the ovirt-engine-sdk project? If that doesn't make sense in this case, then it's fine. Agree that no incubation would be needed. Mike
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
On 04/19/2012 03:27 PM, Mike Burns wrote:
On Thu, 2012-04-19 at 14:35 +0300, Itamar Heim wrote:
On 04/19/2012 02:18 PM, Martina Kollarova wrote:
Hello,
I created a set of tests for the ovirt-engine-sdk that could be run using jenkins on each commit. Could you please create a git (+ gerrit) repo for this?
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.
I'm ok with the new repo, but couldn't it be included as a directory of the ovirt-engine-sdk project? If that doesn't make sense in this case, then it's fine.
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.
Agree that no incubation would be needed.
Mike
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
On 19/04/12 15:41, Itamar Heim wrote:
On 04/19/2012 03:27 PM, Mike Burns wrote:
On Thu, 2012-04-19 at 14:35 +0300, Itamar Heim wrote:
On 04/19/2012 02:18 PM, Martina Kollarova wrote:
Hello,
I created a set of tests for the ovirt-engine-sdk that could be run using jenkins on each commit. Could you please create a git (+ gerrit) repo for this?
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.
I'm ok with the new repo, but couldn't it be included as a directory of the ovirt-engine-sdk project? If that doesn't make sense in this case, then it's fine.
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.
Agree that no incubation would be needed.
Mike
+1 on Sub-project in a separate repo, as this has complete dependency in ovirt-engine-sdk, yet the other way around isn't so.
-- /d "The answer, my friend, is blowing in the wind" --Bob Dylan, Blowin' in the Wind (1963)
On 19/04/12 15:47, Doron Fediuck wrote:
On 19/04/12 15:41, Itamar Heim wrote:
On 04/19/2012 03:27 PM, Mike Burns wrote:
On Thu, 2012-04-19 at 14:35 +0300, Itamar Heim wrote:
On 04/19/2012 02:18 PM, Martina Kollarova wrote:
Hello,
I created a set of tests for the ovirt-engine-sdk that could be run using jenkins on each commit. Could you please create a git (+ gerrit) repo for this?
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.
I'm ok with the new repo, but couldn't it be included as a directory of the ovirt-engine-sdk project? If that doesn't make sense in this case, then it's fine.
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.
Agree that no incubation would be needed.
Mike
+1 on Sub-project in a separate repo, as this has complete dependency in ovirt-engine-sdk, yet the other way around isn't so.
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!"
On Thu, 2012-04-19 at 15:41 +0300, Itamar Heim wrote:
On 04/19/2012 03:27 PM, Mike Burns wrote:
On Thu, 2012-04-19 at 14:35 +0300, Itamar Heim wrote:
On 04/19/2012 02:18 PM, Martina Kollarova wrote:
Hello,
I created a set of tests for the ovirt-engine-sdk that could be run using jenkins on each commit. Could you please create a git (+ gerrit) repo for this?
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.
I'm ok with the new repo, but couldn't it be included as a directory of the ovirt-engine-sdk project? If that doesn't make sense in this case, then it's fine.
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.
Ok, just needed to ask the question. ACK from me. Mike
Agree that no incubation would be needed.
Mike
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
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:
On Thu, 2012-04-19 at 15:41 +0300, Itamar Heim wrote:
On 04/19/2012 03:27 PM, Mike Burns wrote:
On Thu, 2012-04-19 at 14:35 +0300, Itamar Heim wrote:
On 04/19/2012 02:18 PM, Martina Kollarova wrote:
Hello,
I created a set of tests for the ovirt-engine-sdk that could be run using jenkins on each commit. Could you please create a git (+ gerrit) repo for this?
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.
I'm ok with the new repo, but couldn't it be included as a directory of the ovirt-engine-sdk project? If that doesn't make sense in this case, then it's fine.
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.
Ok, just needed to ask the question.
ACK from me.
Mike
Agree that no incubation would be needed.
Mike
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
participants (7)
-
Doron Fediuck -
Eyal Edri -
Itamar Heim -
Karsten 'quaid' Wade -
Martina Kollarova -
Mike Burns -
Ofer Schreiber