Well testing day is done. As someone that is fairly new to the day to day of the project it looked pretty successful to me.
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 testing day. 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 to work. 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 the work. 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. Thanks Robert
----- Original Message -----
This shouldn't take more than a an hour to setup. i just need access to jenkins user from the jenkins build slave to ovirt.org server. i can copy the built rpms there, and from there there should be a script that listens to the drop dir via inotify and publish them to ovirt.org/builds/latest/f17/ovirt-engine... or similar. Let me know once i've have access so i can enable it. jenkins pub key: ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAykXy+X1qUI/TyblF5J35A1bexPeFWj7SmzzcClS3GzQ8jEaV7AaOzbvyl2dQ8P4nh8tr2nSeT7LAFYWhIGscy6V7p5vMRr3mUzRA/E/g3r9wdmdDcPLOqfpJWiLTDlA3XQyFhJnwQopGRBSf5yzFGWFezH+rjzlwBDDN2mQkI/WuSEBh+UT/9+E7JvQBVhg2hapXszfSrrtrVniw/1TvNJEvR+wdwxCUkJWP+LZOtdbGIYQZMkmw8yMNy/fkEfxR3CLge65rDCbxqlDkqFff0VWcwd3SBXdIo4T1401kIjcPiPR9npib7Ra88QiWXIazHW05ejp+m2W136zmYmfxFw== jenkins@ip-10-114-123-188 Eyal Edri.
On 06/21/2012 08:04 AM, Robert Middleswarth wrote:
Hi Robert, Thanks for taking the time to both test and reflect on it. your feedback is most welcome. some notes below. ...
Karsten - can you please weigh in on getting the infra group bigger. not every infra member need to own/help with all hosts, since each has its own expertise, but more people could help maintaining them. maybe a weekly infra call to orchestrate efforts around this?
we have two main hosts on EC2 - gerrit and jenkins. the jenkins slaves can be contributed by anyone to the effort, hopefully with different distros (and maintained by them to keep the jobs running correctly on them). I can update from red hat side we are looking at contributing more hosts/guests to this not on EC2, for both cost and more importantly, performance reasons. the guests would be based on RHEV probably. again, anyone can contribute computing resources to the jenkins effort. ...
i agree. both .el6 and debian are things i'd like to see and plan to allocate resources to. this will go faster if more people pick some of these up.
agree. I believe Dave Neary started looking at this. Dave?
or add more robust/defensive code around these places to give proper error messages. (not we had these for NFS in the past, but they were too hard to maintain as their semantics were hard to keep 100% correct over time). but maybe a side utility to check this may help, or showing the link to the relevant troubleshooting wiki in the error message.
looking forward to that.
Dave?
again - your feedback is most welcome, thanks, Itamar
On Thu, Jun 21, 2012 at 09:50:25AM +0300, Itamar Heim wrote:
+1
+1. I would be interested here.
Since it's been approved I can tell that I'm working on a F17 guest on my employers RHEV cluster. Once it's really available I'll send a proper announcement.
As a Gentoo (desktop), Debian (personal servers) and CentOS (employers servers) user I like the idea of supporting different distros. However, there is some work to be done. Looking at the engine (which I think is easiest because of less interaction with the system) we do notice that JBoss isn't packaged. I'm sure there are other dependencies as well. When we look at VDSM there's work to be done in the software itself. Think of how network interfaces are managed, installed packages which are reported to engine. Also a much wider range of versions should be supported because of different stable versions. Maybe that integrating nova for network management could help here because lots of openstack work is done on Debian and derivates.
Maybe move to a pure wiki website? I think mediawiki has some control options to protect some pages if we need it.
It's the only way you can improve.
Hi all, On 06/21/2012 08:50 AM, Itamar Heim wrote:
Yes! This week we've been busy with last minute finishing touches to a project that we're launching next week, and I was giving a keynote presentation at a conference, but indeed I've been talking to Itamar and others from oVirt over the past few weeks about how we can help oVirt. We have a grand plan, and a major part of it is to refocus the content of the website and the wiki on the mùain target audience of the oVirt project - cost-sensitive sysadmins setting up relatively small virtualisation networks to test, or deploying virtualisation in organisations with little or no budget. That hypothetical target user wants great technology for free and loves open source because it means he doesn't have to ask for approval before getting to work, and he can play around with it to make it suit his needs. And his needs are the ability to get started with no outside help fairly easily based on the documentation and software available on the site. Our priorities for the site and the wiki fall out of that - focus on the documentation for getting started with one server (engine and nodes on the same machine), getting started with a minimal multi-host set-up (one engine running on a laptop, two nodes, with up to 5 or 6 VMs), integrating with Gluster for storage, etc. - Fix the navigation and organisation of the wiki, and start building up a wiki team to ensure it stays clean over time, so that the wiki becomes a resource for users to help each other - Ensure that packages for oVirt are available not just for Fedora but also for other popular distros Following on from that, we want to help promote the project with articles, conference outreach, organising local meet-ups around the world and so on. For all of this, I'm personally more interested in helping build those skills within the project than in doing them short-term.
Yes, promotion is definitely something we need to beef up. As oVirt gets adopted, we will have more reviews, how-tos, and so on mentioning it, and we should gather these together periodically on ovirt.org. And Jason is a member of the OSAS team, and I will definitely want to get him and others blogging about oVirt (whether it's things like getting started tutorials as you mention, or new features that are getting done, or oVirt workshops and conferences that are coming up, whatever). I'll follow up with a little more detail on what I think we should be doing short, medium and long term to ensure that oVirt is a great success. Thanks, Dave. -- Dave Neary Community Action and Impact Open Source and Standards Team, Red Hat Phone: +33 9 50 71 55 62
participants (5)
-
Dave Neary -
Ewoud Kohl van Wijngaarden -
Eyal Edri -
Itamar Heim -
Robert Middleswarth