Content-Type: text/plain; charset="UTF-8"
I'm working on bringing automated testing to oVirt Node.
The current code is hosted at , but it would be nice if I could host
at least the ovirt specific client and the ovirt specififc testsuites on
the ovirt infrastructure.
Is there anything specififc for me to do, besides asking for these
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
-----END PGP SIGNATURE-----
You are right.
seems like a few jobs got hang and weren't released by jenkins.
it can sometimes happen in jenkins , i've added a timeout for these job so next time they will fail if they last for too long.
thanks for the heads up.
oVirt Infra Team.
----- Original Message -----
> From: ovirt(a)qip.ru
> To: engine-devel(a)ovirt.org
> Sent: Wednesday, June 27, 2012 1:36:23 PM
> Subject: [Engine-devel] fedora_17_slave_02 on jenkins
> Hi, ALL
> Is it ok that node
> fedora_17_slave_02 on
> has Process leaked file descriptors error about two days?
> Engine-devel mailing list
This has come up a few times but always inside existing threads.
What time is good for doing a meeting?
Karsten 'quaid' Wade used whenisgood to get input on what time works
best for everyone.
I am not 100% sure what timezone I am seeing when I look at it. Since
it doesn't tell you. I am in the EDT timezone and it is showing the
first time as 6:00 AM and the last at 10:00 PM. If someone else outside
my timezone can confirm they are seeing a diff range that would be great.
Sense this has been floating around since June 5th I suggest we set a
deadline. Lets say June 28th and we will plan the 1st meeting for July 2-6?
-----BEGIN PGP SIGNED MESSAGE-----
We're filling up the disk on www.ovirt.org, which is expected since
it's only 10 GB. I'm going to double that, which requires a reboot.
Prior to the reboot I'll come on IRC and make sure everyone is
prepared, and hold-off the reboot if needed.
I know this window lands right in the morning for some of us, so if
this is an issue, email me back. I could reschedule for 2100 UTC or so.
The restart should only take a few minutes. The hour window is to give
me time to start and finish or rollback if there is a problem.
== When ==
0200 to 0300 UTC
date -d "2012-06-25 0200 UTC"
date -d "2012-06-25 0300 UTC"
== Affected services ==
ovirtbot (IRC bot)
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
Red Hat Open Source and Standards (OSAS)
@quaid (identi.ca/twitter/IRC) | gpg: AD0E0C41
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
This has been on two diff weekly sync meetings and in both cases it
sounds like it is a good idea but in both cases it ends with let move
this to the infra list.
Well what does everyone think about this idea?
At one point it was suggested that a weekly meeting be setup for infra
either on IRC or voice. An email was sent out with a link to help
select times but I wasn't sure what timezone it was setup under? I
can't find the link or email so maybe that can be sent out again?
What other topics do we need to address?
A few months ago It was asked on infra@ about how the group should go about building up trust so you all would feel comfortable handing out e.g. ssh and sudo access to servers. Since there is someone activity (me) asking seeking to help and would need that access I guess this is a good time to bring up the question again.
I saw in IRC several people who didn't have redhat addresses testing the
projects. From what I have read this was an improvement over the 3.0
I submitted 2 bz reports and reported 3 other build related reports in IRC.
Despite the fact that it was suppose to be a community coordination what
I saw was a never ending day for Mike Burns (mburns) and a few other
people doing there best to get everything in place.
There were bugs being found but many of the bugs I was dealing with were
packaging issues and not really software bugs. Part of the issues I saw
was the fact that the infrastructure wasn't in place to handle the
testing day. The repo was getting thrown together at the last min.
Most of the packages were added into the repo the night before and there
wasn't any time for testing. There were even a few packages like the
SDK and CLI that were not ready until half way thought the testing day.
Because there just wasn't time to test there were missing packages and
other issues that would likely have been caught if there had been a day
or two for basic testing I am wonder how many more bugs would have been
found if people hadn't been spending so much time getting the installs
I have been though these kind of things with other projects and many of
these kind of issue are normal especially in fairly young projects were
all the infrastructure pieces aren't in place yet but many of these
issues are pretty easy to fix. Here are my suggests for things we need
to get done over the next year. Many of these things have been talked
about before on this list and don't think any of these ideas are coming
out of left field. Now don't get me wrong I am willing to put the time
in to help make these things happen not just asking other people to do
1) Need to set a process for adding people onto the team. Someone else
besides me has offered to help with the infra but there doesn't seem to
be a process to add people to the group. It seems to be really to much
work for the few people I see running things part time and it shows.
2) Linnode and EC2 are great to get things running quickly but they can
also be pretty costly especially EC2. We need to start looking into
ways to save money at the same time giving the project more flexibility
in testing and building. There are several options for this but I
always believe in the old saying that someone should always "eat your
own dog food". So an oVirt or a RHEV cluster should really be on the
table. If there isn't already a working group looking into this maybe
there should be. I will be happy to be a member of this group if the
team decides this is a good idea.
3) We have to get the builds out of Jenkins and into usable repo's in an
automated way this more then anything else will make basic testing of
packages easier and I would guess half the bugs people were hitting
during testing day would have been fixed long before testing day. I
know this is something being worked on by eedri but it really needs to
be in place. I would love to help work though the process.
4) We need to get at least el6 packages produced also I suggest we start
supporting all supported Fedora builds (Right now that would be F16 and
F17). A Debian based system would also be great. Having builds being
ran on more then one os will help remove some of the only works on
fedora XX issues that I am seeing in the code and commits. There are
also bugs that hide behind packages that show themselves rarely but
become very shallow under other OS's. I have seen that in other
projects were code that seems to work great under one OS will start to
bomb under others and so bugs that were masked get found and it forces
the packaging to get more generic.
5) We really need a review of the current structure of the websites and
tweak it some as some resources are really hard to find. Simple things
like adding a top level menu for the wiki most projects have something
like a documentation tab that points to a predefined wiki page with
instructions and links to other parts of the wiki covering important
topics.. Adding a simple URL like wiki.ovirt.org that redirects to
www.ovirt.org/wiki . There have been other idea's tossed out in the
list many of them are good ideas and simple to do but unless someone
really pushes them they tend to go no where. Maybe an official
suggesting list Editable by all and a todo list (editable by just infra
team member) to help capture those idea's
6) As we see more people testing out the software we are going to get
the same set of questions over and over again. Lets face it how many
times has someone emailed users about nfs storage problems. For all
projects there is always certain questions that get asked a lot.
Example getting NFS working. We really need to find a way to help
people get answers before they start emailing the user list. The
requirements are always hard to get right. We need to find something
that the developers are willing to use well still keeping it simple
enough that users wont just bypass or never check.
7) We all know visualization is the future and people are likely going
to take ovirt engine and vdsm in interesting new ways. we already see
changing in the networking stack, glusterfs addon, major improvements in
the UI. There also seems to be a solid todo list that Red Hat is
funding. With all these great changes coming down the pike we are going
to have to handle more and more complex build structure. This one kinda
ties in with #2. We need the ability to spin up other build
environments then just Fedora latest and RHEV that means we are going to
have to bring in people who know Debian, Ubuntu, Gentoo, etc.
8) Look at ways to help members write blogs posts about ovirt and
providing a way for people to find them. Blog posts are great ways to
work on new section of the documentation and/or get publicity for a new
feature. My first ovirt build wasn't based on the wiki but a getting
started blog post by Jason Brooks. There are always great topic idea
out there. Off the top of my head I can think of several topics. These
include things like how to use the glusterfs with oVirt, processor types
and how to get the most out of clusters, Exporting a VM, Importing from
VMware, Importing from Xen. Those are just topics off the top of my
head I am sure there are many more. Personally I have never been a fan
of planet.xxx sites but I personally have found using a wordpress mu and
allowing people to post and let the good stuff float to the top of the
sites really does well. Granted we are not going to see a hundred
articles a day but a place for people to post might make it easier for
people to write blog posts and for other people to find them.
Well I fell like I am writing a book here and even with that I am sure
there are things I have missed.
I want to make it clear I am not saying anything bad about the team and
what has been done already I am just point out things that I fell this
team should be working on to make the infrastructure behind this great
project help the project not hinder it.