From dneary at redhat.com Mon Jul 2 13:19:14 2012 From: dneary at redhat.com (Dave Neary) Date: Mon, 02 Jul 2012 15:19:14 +0200 Subject: [Users] oVirt Workshop at LinuxCon North America In-Reply-To: <4FE38487.7050004@redhat.com> References: <4FE38487.7050004@redhat.com> Message-ID: <4FF19FD2.5060408@redhat.com> Hi Leslie, On 06/21/2012 10:31 PM, Leslie Hawthorn wrote: > Following up from this week's IRC meeting, we've asked the Linux > Foundation to replicate the agenda from LinuxCon Japan on the LC North > America site. That's in process, but they'd like us to get the names and > bios of our confirmed speakers to them no later than next Wednesday, 27 > June 2012. > > I'll leave it to everyone to wrangle about who would like to speak and > cover particular sessions. My goal with this workshop is to have a more > diverse speaker line up, so please do volunteer if you're attending > LinuxCon North America and would be willing to lead a session(s). I got some great responses from people on the list when I asked what they were using oVirt for - perhaps you/we could invite someone to do an oVirt user case study or two? That would be an interesting session to me. Cheers, Dave. -- Dave Neary Community Action and Impact Open Source and Standards Team, Red Hat Phone: +33 9 50 71 55 62 From mburns at redhat.com Mon Jul 2 13:27:17 2012 From: mburns at redhat.com (Mike Burns) Date: Mon, 02 Jul 2012 09:27:17 -0400 Subject: oVirt Weekly Meeting -- 2012-07-04 Message-ID: <1341235637.4733.2.camel@mburns-laptop> This mail will double as a question and call for agenda items. Since this Wednesday is 04-July, all US people will be un-available. Do we want to reschedule the meeting? Mike From lhawthor at redhat.com Mon Jul 2 19:03:47 2012 From: lhawthor at redhat.com (Leslie Hawthorn) Date: Mon, 02 Jul 2012 12:03:47 -0700 Subject: [Users] oVirt Workshop at LinuxCon North America In-Reply-To: <4FF19FD2.5060408@redhat.com> References: <4FE38487.7050004@redhat.com> <4FF19FD2.5060408@redhat.com> Message-ID: <4FF1F093.20405@redhat.com> On 07/02/2012 06:19 AM, Dave Neary wrote: > Hi Leslie, > > On 06/21/2012 10:31 PM, Leslie Hawthorn wrote: >> Following up from this week's IRC meeting, we've asked the Linux >> Foundation to replicate the agenda from LinuxCon Japan on the LC North >> America site. That's in process, but they'd like us to get the names and >> bios of our confirmed speakers to them no later than next Wednesday, 27 >> June 2012. >> >> I'll leave it to everyone to wrangle about who would like to speak and >> cover particular sessions. My goal with this workshop is to have a more >> diverse speaker line up, so please do volunteer if you're attending >> LinuxCon North America and would be willing to lead a session(s). > > I got some great responses from people on the list when I asked what > they were using oVirt for - perhaps you/we could invite someone to do > an oVirt user case study or two? That would be an interesting session > to me. > I think this plan would be wonderful. We haven't yet establish a CFP process or other means to do this outreach formally. What would folks like to see happen? I would propose we decide on the number of slots we'd like to dedicate to case studies or other in the field oriented presentations and, for now, directly invite those we would like to present. Establishing a CFP process quickly would be welcome, as I believe we will have more speaking slots to fill at the KVM Forum + oVirt workshop at LinuxCon Europe. I'm getting specifics on the schedule for that from the Linux Foundation and will return with an update when I have more details. Cheers, LH -- Leslie Hawthorn Community Action and Impact Open Source and Standards @ Red Hat identi.ca/lh twitter.com/lhawthorn From oschreib at redhat.com Tue Jul 3 06:46:33 2012 From: oschreib at redhat.com (Ofer Schreiber) Date: Tue, 03 Jul 2012 02:46:33 -0400 (EDT) Subject: oVirt Weekly Meeting -- 2012-07-04 In-Reply-To: <1341235637.4733.2.camel@mburns-laptop> Message-ID: ----- Original Message ----- > This mail will double as a question and call for agenda items. Since > this Wednesday is 04-July, all US people will be un-available. Do we > want to reschedule the meeting? I suggest reschedule to 05-July (same hour). > > Mike > > _______________________________________________ > Board mailing list > Board at ovirt.org > http://lists.ovirt.org/mailman/listinfo/board > From dneary at redhat.com Tue Jul 3 11:51:48 2012 From: dneary at redhat.com (Dave Neary) Date: Tue, 03 Jul 2012 07:51:48 -0400 (EDT) Subject: [Users] oVirt Weekly Meeting -- 2012-07-04 In-Reply-To: Message-ID: <65dd1913-564b-4097-8f18-58ab0b040b64@zmail19.collab.prod.int.phx2.redhat.com> Hi, Ofer wrote: > Mike wrote: > > This mail will double as a question and call for agenda items. Since > > this Wednesday is 04-July, all US people will be un-available. Do we > > want to reschedule the meeting? > > I suggest reschedule to 05-July (same hour). Sounds good to me - although I'm available either day. Cheers, Dave. From kwade at redhat.com Tue Jul 3 15:24:34 2012 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Tue, 03 Jul 2012 08:24:34 -0700 Subject: Meeting :: oVirt Infrastructure Team :: 2012-07-03 Message-ID: <4FF30EB2.9050506@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Minutes: http://ovirt.org/meetings/ovirt/2012/ovirt.2012-07-03-14.00.html Minutes (text): http://ovirt.org/meetings/ovirt/2012/ovirt.2012-07-03-14.00.txt Log: http://ovirt.org/meetings/ovirt/2012/ovirt.2012-07-03-14.00.log.html ============== #ovirt Meeting ============== Meeting started by quaid at 14:00:28 UTC. The full logs are available at http://ovirt.org/meetings/ovirt/2012/ovirt.2012-07-03-14.00.log.html . Meeting summary - --------------- * Introductions (short) (quaid, 14:02:10) * LINK: http://ovirt.org/wiki/Infrastructure_team_meetings#2012-07-03 is the agenda (quaid, 14:04:38) * IDEA: Publican quickstart for OpenShift to run Publican-based doc sites (quaid, 14:07:05) * Agenda affirmation - anything to add? (quaid, 14:08:18) * LINK: http://ovirt.org/wiki/Infrastructure_team_meetings#2012-07-03 (ewoud, 14:08:37) * Review of open infrastructure topics - what do we care about? (quaid, 14:10:13) * LINK: http://www.ovirt.org/wiki/Infrastructure_team_task_list (quaid, 14:11:25) * LINK: http://ovirt.org/wiki/Design_of_oVirt_project_infrastructure (quaid, 14:12:19) * ACTION: Fill out infrastructure design page with a list of hosts and what goes on top of them, as a way to feed our scope discussion (quaid, 14:15:03) * ACTION: Plan to potentially move Jenkins from EC2 to a dedicated host for performance and cost reasons (quaid, 14:15:28) * AGREED: Linode box == kitchen sink, jenkins, gerrit, and slaves are mostly EC2 (quaid, 14:15:56) * IDEA: Puppet or chef FTW! (quaid, 14:16:03) * ACTION: setup a Puppet server for ovirt infra (quaid, 14:18:32) * ACTION: Define what is the purview of infra@ and what is purview of generic arch@ (quaid, 14:33:32) * LINK: http://fedorareloaded.com/ (sgordon, 14:35:37) * LINK: http://www.fedorareloaded.com:8080/TopicIndex/Books/index.seam (sgordon, 14:36:13) * 07:24 < skvidal> quaid: in the private git repo (quaid, 14:37:13) * How are we going to be more open & enable others to do Infra work? (quaid, 14:37:36) * ACTION: Finish building trust on the mailing list (ewoud, 14:51:01) * ACTION: quaid to propose himself as seed for a trust circle on infra@ (quaid, 14:56:25) * Formal meeting at an end, informal chat which we'll log for now since we're on the same topics :) (quaid, 15:03:53) * ACTION: quaid to do first draft of services, servers, and infrastructure design for http://ovirt.org/wiki/Design_of_oVirt_project_infrastructure (quaid, 15:11:21) Meeting ended at 15:16:47 UTC. Action Items - ------------ * Fill out infrastructure design page with a list of hosts and what goes on top of them, as a way to feed our scope discussion * Plan to potentially move Jenkins from EC2 to a dedicated host for performance and cost reasons * setup a Puppet server for ovirt infra * Define what is the purview of infra@ and what is purview of generic arch@ * Finish building trust on the mailing list * quaid to propose himself as seed for a trust circle on infra@ * quaid to do first draft of services, servers, and infrastructure design for http://ovirt.org/wiki/Design_of_oVirt_project_infrastructure Action Items, by person - ----------------------- * quaid * quaid to propose himself as seed for a trust circle on infra@ * quaid to do first draft of services, servers, and infrastructure design for http://ovirt.org/wiki/Design_of_oVirt_project_infrastructure * **UNASSIGNED** * Fill out infrastructure design page with a list of hosts and what goes on top of them, as a way to feed our scope discussion * Plan to potentially move Jenkins from EC2 to a dedicated host for performance and cost reasons * setup a Puppet server for ovirt infra * Define what is the purview of infra@ and what is purview of generic arch@ * Finish building trust on the mailing list People Present (lines said) - --------------------------- * quaid (170) * ewoud (51) * sgordon (47) * RobertM (27) * dneary (23) * ovirtbot (8) * apevec (7) * rgolan (4) * jbrooks (3) * mburns (2) * tjikkun_work (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot - -- Karsten 'quaid' Wade, Sr. Analyst - Community Growth http://community.redhat.com .^\ http://TheOpenSourceWay.org @quaid (identi.ca/twitter/IRC) \v. gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFP8w6y2ZIOBq0ODEERAnUmAKCl6Z6C1DfM7edGJ6+5pJYCPU6eegCgutJW 4PQcwrSIHnfjFNvVNHkqA8o= =QmCR -----END PGP SIGNATURE----- From oschreib at redhat.com Wed Jul 4 14:18:06 2012 From: oschreib at redhat.com (Ofer Schreiber) Date: Wed, 04 Jul 2012 10:18:06 -0400 (EDT) Subject: oVirt Weekly Meeting - Delayed to 2012-07-05 In-Reply-To: <232d2914-70fe-43db-ace8-b2b60c3c5619@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: Since today is 04-July, all US people are un-available. The meeting will take place tomorrow, same place, same hour. Thanks, Ofer Schreiber oVirt Release Manager From oschreib at redhat.com Wed Jul 4 14:51:13 2012 From: oschreib at redhat.com (Ofer Schreiber) Date: Wed, 04 Jul 2012 10:51:13 -0400 (EDT) Subject: oVirt 3.1 - New beta RPMs available In-Reply-To: Message-ID: <7e8320e8-a234-4d55-993c-a0460e8b4aba@zmail14.collab.prod.int.phx2.redhat.com> New set of VDSM & oVirt Engine RPMs (Fedora 17 based) has been uploaded to ovirt.org [1] As those RPMs contains critical bug fixes, the oVirt team will appreciate any kind input and bug verification [2]. Thanks, Ofer Schreiber oVirt Release Manager [1] www.ovirt.org/releases/beta/fedora/17/ [2] Specifically, We would like to verify the following BZs: https://bugzilla.redhat.com/buglist.cgi?quicksearch=831998%20832577%20833119%20833201&list_id=246593 From mburns at redhat.com Thu Jul 5 14:51:21 2012 From: mburns at redhat.com (Mike Burns) Date: Thu, 05 Jul 2012 10:51:21 -0400 Subject: oVirt Weekly Meeting Minutes -- 2012-07-05 Message-ID: <1341499881.10141.3.camel@mburns-laptop> Minutes: http://ovirt.org/meetings/ovirt/2012/ovirt.2012-07-05-14.00.html Minutes (text): http://ovirt.org/meetings/ovirt/2012/ovirt.2012-07-05-14.00.txt Log: http://ovirt.org/meetings/ovirt/2012/ovirt.2012-07-05-14.00.log.html ========================= #ovirt: ovirt weekly sync ========================= Meeting started by mburns at 14:00:49 UTC. The full logs are available at http://ovirt.org/meetings/ovirt/2012/ovirt.2012-07-05-14.00.log.html . Meeting summary --------------- * roll call and agenda (mburns, 14:01:10) * Release Status (mburns, 14:06:00) * Current release date is July 9th (oschreib, 14:08:37) * 9 blocker currently for 3.1 release, 5 ON_QA, 2 MODIFIED and 2 POST (oschreib, 14:09:11) * LINK: https://bugzilla.redhat.com/showdependencytree.cgi?id=822145&hide_resolved=1 (oschreib, 14:09:16) * Blockers review (oschreib, 14:11:00) * vdsmd init script times out due to lengthy semanage operation (vdsm, POST) (oschreib, 14:11:16) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=832199 (oschreib, 14:11:24) * new patch should be reviewed soon (oschreib, 14:14:59) * 3.1: sshd daemon is not starting correctly after complete the installation of oVirt Node (ovirt-node, MODIFIED) (oschreib, 14:15:46) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=832517 (oschreib, 14:15:53) * verification blocks on BZ#837443 (oschreib, 14:17:41) * ovirt-node fails to register with ovirt-engine (vdsm, POST) (oschreib, 14:18:52) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=837443 (oschreib, 14:18:57) * patch in review (oschreib, 14:21:24) * 3.1: iptables blocking communication between node and engine (ovirt-node, MODIFIED) (oschreib, 14:21:56) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=832539 (oschreib, 14:22:06) * blocks on BZ 837443 as well (oschreib, 14:24:48) * AGREED: release date will slip to 25 July (mburns, 14:34:46) * Workshops and Conferences (mburns, 14:36:02) * next workshop is August 28 in San Diego (mburns, 14:36:57) * release announcements (mburns, 14:42:14) * oschreib mburns to work with jbrooks to coordinate release announcements (mburns, 14:42:53) * ACTION: jclift and/or dneary to recruit RobertM to do feature screencasts (mburns, 14:46:22) Meeting ended at 14:48:44 UTC. Action Items ------------ * jclift and/or dneary to recruit RobertM to do feature screencasts Action Items, by person ----------------------- * dneary * jclift and/or dneary to recruit RobertM to do feature screencasts * jclift * jclift and/or dneary to recruit RobertM to do feature screencasts * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * oschreib (59) * mburns (54) * dneary (21) * dougsland (15) * jclift (14) * ovirtbot (5) * ilvovsky (4) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot From mburns at redhat.com Thu Jul 5 14:57:42 2012 From: mburns at redhat.com (Mike Burns) Date: Thu, 05 Jul 2012 10:57:42 -0400 Subject: Update on oVirt 3.1 Release Date Message-ID: <1341500262.10141.6.camel@mburns-laptop> Due to some critical issues that are still outstanding, we've decided to delay the release of oVirt 3.1 by about 2 weeks. We are now targeting 2012-07-25 for the release. For details on the issues currently blocking the release, please see the bugs listed here[1]. Thanks The oVirt Team https://bugzilla.redhat.com/showdependencytree.cgi?id=822145&hide_resolved=1 From dneary at redhat.com Thu Jul 5 17:11:01 2012 From: dneary at redhat.com (Dave Neary) Date: Thu, 05 Jul 2012 19:11:01 +0200 Subject: Getting some 3.1 screencasts Message-ID: <4FF5CAA5.80301@redhat.com> Hi everyone, At the team meeting today Jason Clift suggested that it would be great to have some screencasts for the 3.1 release. I agree. So let's see if we can make some! To spread the load as much as possible, here's what I propose: 1. We come up with a set (5-10) of demo stories we want to tell in the wiki. These should contain: * The feature we want to demo * The "before recording" set-up that needs to be done * The steps to demo the feature * A quick script that someone can follow to explain what they're doing. I'd like a few of these scripts to be for existing oVirt features (say, migrating a VM to a different node) and a few to be for features which are new in 3.1 (see the release notes at http://ovirt.org/wiki/Release_Notes_Draft for details there, we should pick one or two nice visible features like all-in-one install). 2. From the scripts, we record the demos as .ogv using RecordMyDesktop or GNOME Shell's built-in desktop recording 3. Finally, we do voice-overs to add a sound track to the demo (and if we have any skilled sound engineers, some tasteful CC licenced background music would be great!) This way, we've broken down the creation of 5 screencasts into 15 different byte-sized tasks - script, video, voiceover - none of which should take someone more that 20 minutes or half an hour - which hopefully will make it easier to get them done together. How does this plan sound? If it sounds good, which features do you think we should screencast as top priority? Thanks! Dave. -- Dave Neary Community Action and Impact Open Source and Standards Team, Red Hat Phone: +33 9 50 71 55 62 From acathrow at redhat.com Thu Jul 5 17:50:36 2012 From: acathrow at redhat.com (Andrew Cathrow) Date: Thu, 05 Jul 2012 13:50:36 -0400 (EDT) Subject: [Users] What are you looking for from oVirt? In-Reply-To: Message-ID: ----- Original Message ----- > From: "Romain Vrignaud" > To: "Dave Neary" , "arch" , > "Users" , "board" > Sent: Friday, June 29, 2012 4:13:32 AM > Subject: Re: [Users] What are you looking for from oVirt? > Hello, > I don't run currently any oVirt deployement in production but I have > a lab. > I used to run in production the old oVirt product (in rails). > My best wishes for the future release of oVirt are : > * GluserFS support as many of us > * Nova (OpenStack Hypervisor) driver support ( > http://docs.openstack.org/trunk/openstack-compute/admin/content/selecting-a-hypervisor.html > ). > I choose oVirt because my first goal is to manage a virtualized > datacenter with OSS. But we begin to look at private cloud > deployement. > I think Aeolus would work with oVirt virtualization backend but AFAIK > it only support redhat based linux which is not possible for us as > we run > Aelous has a RHEVM/oVirt driver that works today. > If there are problems getting Aeolus working with oVirt we should dig > into it, there shouldn't be any issues. > almost only debian server except for virtualisation layer. So we > would like to deploy OpenStack but to rely on oVirt for KVM > hypervisors. > Out of interest what are you getting from OpenStack that you don't > get from oVirt > * Fully supported stateless ovirt-node > Regards, > Romain > 2012/6/28 Robert Middleswarth < robert at middleswarth.net > > > On 06/15/2012 06:23 AM, Dave Neary wrote: > > > > Hi, > > > > > > On 06/13/2012 04:28 PM, Dave Neary wrote: > > > > > > > So - how are you using oVirt? Why did you choose it over > > > > alternatives? > > > > > > > > > > What do you like about it? and what would you like to see > > > > change, > > > > > > > > > > whether that is in terms of technical, process, or marketing > > > > changes? > > > > > > > > > > I'm here to help, but to do so I need your help first! > > > > > > > > > Thank you to all those who have replied, on and off list, so far. > > > For > > > those of you who sent me private messages, I'll be (anonymously) > > > collating your feedback and forwarding it on. > > > > > > The range of users who have replied so far includes: > > > > > > * Sysadmin at small web hosting business > > > > > > * Cost-sensitive IT department of an unrelated industry > > > > > That would be me. > > > > * Hosting provider specialising in HA > > > > > > * Running a private cloud > > > > > > * Test lab set-up considering for production deployment > > > > > Well no one should be crazy enough to go live with a product they > > haven't at least ran inside a testing lab. > > > > And the top features you've cited are: > > > > > > * Stateless hypervisor > > > > > > * Ability to migrate VMs > > > > > Number one reason I am working with oVirt > > > > * RHEL and KVM > > > > > We are a debian based org so changing over to the RHEL based OS's > > is > > more a pain then a benefit. KVM is still kinda young compared to > > both Xen / Vmware it seems to work well but there aren't as many > > os's covered by the vitro drivers and there seem to be more bugs / > > race conditions but that has been steadily changing as it has been > > getting more mature > > > > * Cost > > > > > > * The ability to have your preferred OS as both hypervisor and > > > guest > > > as a first class citizen > > > > > > * Aimed for data center use-case rather than cloud > > > > > This would be number 2 in the list. > > > > And the top gaps you've identified so far: > > > > > > * Insufficient resources (docs) to help with production > > > deployment > > > on > > > ovirt.org > > > > > > * Difficulty of configuration and getting started > > > > > > * You'd like to see a more diverse contributor community > > > > > > * Stability (unfortunately, I don't have any concrete examples of > > > this from the commenter) > > > > > > * History on resource usage in hypervisors and guests > > > > > > * Integration with Gluster > > > > > > * Offer choices of guest agents with other distributions than > > > RHEL > > > > > I could have created this list myself. I have hit pretty much every > > one of these limits in the last few months working with the > > project. > > 3.1 adds limited support for Gluster and ovirt seems to be more > > stable dispute F17 instability. > > > As for the question of stability the file storage system in 3.0 can > > be a bit unstable. If your NFS share disappears for a few mins the > > file system tends to go offline and wont reactivate. Not sure about > > iscsi or FC since I don't have access to those file systems. > > > > This is all giving me great insight into who's here - please keep > > > it > > > coming! > > > > > > Cheers, > > > > > > Dave. > > > > > ______________________________ _________________ > > > Users mailing list > > > Users at ovirt.org > > > http://lists.ovirt.org/ mailman/listinfo/users > > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at middleswarth.net Thu Jul 5 19:40:06 2012 From: robert at middleswarth.net (Robert Middleswarth) Date: Thu, 05 Jul 2012 15:40:06 -0400 Subject: [Users] Getting some 3.1 screencasts In-Reply-To: <4FF5CAA5.80301@redhat.com> References: <4FF5CAA5.80301@redhat.com> Message-ID: <4FF5ED96.6000808@middleswarth.net> On 07/05/2012 01:11 PM, Dave Neary wrote: > Hi everyone, > > At the team meeting today Jason Clift suggested that it would be great > to have some screencasts for the 3.1 release. I agree. So let's see if > we can make some! > > To spread the load as much as possible, here's what I propose: > > 1. We come up with a set (5-10) of demo stories we want to tell in the > wiki. These should contain: > * The feature we want to demo > * The "before recording" set-up that needs to be done > * The steps to demo the feature > * A quick script that someone can follow to explain what they're doing. > > I'd like a few of these scripts to be for existing oVirt features > (say, migrating a VM to a different node) and a few to be for features > which are new in 3.1 (see the release notes at > http://ovirt.org/wiki/Release_Notes_Draft for details there, we should > pick one or two nice visible features like all-in-one install). > How are we going to decide on these features we want to demo? Also some of the features like Glusterfs integration might be to complex for a 5 to 10 min video. > 2. From the scripts, we record the demos as .ogv using RecordMyDesktop > or GNOME Shell's built-in desktop recording > > 3. Finally, we do voice-overs to add a sound track to the demo (and if > we have any skilled sound engineers, some tasteful CC licenced > background music would be great!) > > This way, we've broken down the creation of 5 screencasts into 15 > different byte-sized tasks - script, video, voiceover - none of which > should take someone more that 20 minutes or half an hour - which > hopefully will make it easier to get them done together. > > How does this plan sound? Sounding like a good overview now it is time to get into the mud and figure out how to implement that. > > If it sounds good, which features do you think we should screencast as > top priority? Well I think you have already hit one of the most useful ones. 1) VM migrations Other simple idea that might make useful video's are. 2) The Log Collector (engine-log-collector), Maybe even showing the creation of a BZ report? 3) Uploading ISO (engine-iso-uploader), May be a little simple but we could combine with getting the ISO for windows drivers? 4) How to upload images (engine-image-uploader) or Migrating from another system using something like virt-v2v / virt-p2v 5) Cloning a Virtual Machine from a Snapshot. 6) Creating Templates 7) Pinning Virtual Machines to specific physical CPUs 8) Setup multiple networks showing how to activate and connecting to a hosts. 9) Adding storage domains? Building a data center? 10) Exporting VM for backup or moving to another data center. Thanks Robert > > Thanks! > Dave. From dneary at redhat.com Thu Jul 5 20:07:32 2012 From: dneary at redhat.com (Dave Neary) Date: Thu, 05 Jul 2012 22:07:32 +0200 Subject: [Users] Getting some 3.1 screencasts In-Reply-To: <4FF5ED96.6000808@middleswarth.net> References: <4FF5CAA5.80301@redhat.com> <4FF5ED96.6000808@middleswarth.net> Message-ID: <4FF5F404.9050102@redhat.com> Hi, On 07/05/2012 09:40 PM, Robert Middleswarth wrote: > On 07/05/2012 01:11 PM, Dave Neary wrote: >> 1. We come up with a set (5-10) of demo stories we want to tell in the >> wiki. These should contain: >> * The feature we want to demo >> * The "before recording" set-up that needs to be done >> * The steps to demo the feature >> * A quick script that someone can follow to explain what they're doing. >> >> I'd like a few of these scripts to be for existing oVirt features >> (say, migrating a VM to a different node) and a few to be for features >> which are new in 3.1 (see the release notes at >> http://ovirt.org/wiki/Release_Notes_Draft for details there, we should >> pick one or two nice visible features like all-in-one install). >> > How are we going to decide on these features we want to demo? Also some My thoughts were low-tech - everyone propose that we demo their favourite feature. I was going to see the page with what I thought were the most promising features from the release notes and the home page, and throw in a couple of ringers that people would disagree with to start discussion & debate ;-) I'm guessing that the number of things we'll want to demo will be small enough that the priority will be obvious. We can always do more, as long as we respect the priority listand get the most important ones done before the release, if possible. > of the features like Glusterfs integration might be to complex for a 5 > to 10 min video. True. Although the actual "add Glusterfs as a storage node" demo could be literally 30s - but of course, we wouldn't be showing how to set up the Glusterfs cluster in that. As I understand it, the steps are: 1. Turn on Gluster support in the Clusters preferences of the Engine 2. Ensure vdsm-gluster is installed on the node 3. Create a volume in the Engine preferences, add some bricks, and make it available to nodes. I got all this from your tutorials, there may be small but important steps I've left out - but if we assume that someone has an engine, some nodes, and a Gluster set-up as prerequisites, then we can get it down to a 10 minute webcast. I do take your point, though. In general anything longer than 5-10 minutes (5 minutes is the sweet spot, anything longer than 15, people won't watch) is too long, and we should break it up into steps, each of which makes sense on its own. >> 3. Finally, we do voice-overs to add a sound track to the demo (and if >> we have any skilled sound engineers, some tasteful CC licenced >> background music would be great!) > Sounding like a good overview now it is time to get into the mud and > figure out how to implement that. Cool :) What I like to hear. For recording audio, I was thinking very simply, record a sound-track while talking along to the video. You'll need some kind of a script to make it go well, and I'd expect that it'll take 4 or 5 takes before you'll have something you're happy with, but if you cut down the demo to the bare bones, it can work really well. >> If it sounds good, which features do you think we should screencast as >> top priority? > Well I think you have already hit one of the most useful ones. > > 1) VM migrations > > Other simple idea that might make useful video's are. > > 2) The Log Collector (engine-log-collector), Maybe even showing the > creation of a BZ report? > 3) Uploading ISO (engine-iso-uploader), May be a little simple but we > could combine with getting the ISO for windows drivers? > 4) How to upload images (engine-image-uploader) or Migrating from > another system using something like virt-v2v / virt-p2v > 5) Cloning a Virtual Machine from a Snapshot. > 6) Creating Templates > 7) Pinning Virtual Machines to specific physical CPUs > 8) Setup multiple networks showing how to activate and connecting to a > hosts. > 9) Adding storage domains? Building a data center? > 10) Exporting VM for backup or moving to another data center. I definitely like adding storage domains/new disks, uploading images/ISOs, creating new images from templates or snapshots, migrating from another system. Someone would need to explain to me why Log Collector and CPU pinning are cool, and I'm not sure if setting up multiple networks would make for a cool demo. I was thinking stuff like "adding a new node/VM" or "connecting remotely to a VM" would be kind of simple, but useful. Cheers, Dave. -- Dave Neary Community Action and Impact Open Source and Standards Team, Red Hat Phone: +33 9 50 71 55 62 From acathrow at redhat.com Thu Jul 5 20:24:58 2012 From: acathrow at redhat.com (Andrew Cathrow) Date: Thu, 05 Jul 2012 16:24:58 -0400 (EDT) Subject: [Users] Getting some 3.1 screencasts In-Reply-To: <4FF5F404.9050102@redhat.com> Message-ID: ----- Original Message ----- > From: "Dave Neary" > To: "Robert Middleswarth" > Cc: "arch" , "users" > Sent: Thursday, July 5, 2012 4:07:32 PM > Subject: Re: [Users] Getting some 3.1 screencasts > > Hi, > > On 07/05/2012 09:40 PM, Robert Middleswarth wrote: > > On 07/05/2012 01:11 PM, Dave Neary wrote: > >> 1. We come up with a set (5-10) of demo stories we want to tell in > >> the > >> wiki. These should contain: > >> * The feature we want to demo > >> * The "before recording" set-up that needs to be done > >> * The steps to demo the feature > >> * A quick script that someone can follow to explain what they're > >> doing. > >> > >> I'd like a few of these scripts to be for existing oVirt features > >> (say, migrating a VM to a different node) and a few to be for > >> features > >> which are new in 3.1 (see the release notes at > >> http://ovirt.org/wiki/Release_Notes_Draft for details there, we > >> should > >> pick one or two nice visible features like all-in-one install). > >> > > > How are we going to decide on these features we want to demo? Also > > some > > My thoughts were low-tech - everyone propose that we demo their > favourite feature. I was going to see the page with what I thought > were > the most promising features from the release notes and the home page, > and throw in a couple of ringers that people would disagree with to > start discussion & debate ;-) > Everyone on this list (hopefully) has a good idea what oVirt can do ans se we tend to jump to the new, sexy features like Gluster, but the majority of people won't know the basics - they'll be shocked when they see a GUI with the amount of functionality oVirt 3.0 had let alone 3.1. We've got a lot of experience demoing RHEV and it never ceases to amaze me how many people don't even know we have the basics. So don't forget or the basic features - creating a VM, making it highly available with just a mouse click, live migration, etc. > I'm guessing that the number of things we'll want to demo will be > small > enough that the priority will be obvious. We can always do more, as > long > as we respect the priority listand get the most important ones done > before the release, if possible. > > > of the features like Glusterfs integration might be to complex for > > a 5 > > to 10 min video. > > True. Although the actual "add Glusterfs as a storage node" demo > could > be literally 30s - but of course, we wouldn't be showing how to set > up > the Glusterfs cluster in that. > > As I understand it, the steps are: > > 1. Turn on Gluster support in the Clusters preferences of the Engine > 2. Ensure vdsm-gluster is installed on the node > 3. Create a volume in the Engine preferences, add some bricks, and > make > it available to nodes. > > I got all this from your tutorials, there may be small but important > steps I've left out - but if we assume that someone has an engine, > some > nodes, and a Gluster set-up as prerequisites, then we can get it down > to > a 10 minute webcast. > > I do take your point, though. In general anything longer than 5-10 > minutes (5 minutes is the sweet spot, anything longer than 15, people > won't watch) is too long, and we should break it up into steps, each > of > which makes sense on its own. > > >> 3. Finally, we do voice-overs to add a sound track to the demo > >> (and if > >> we have any skilled sound engineers, some tasteful CC licenced > >> background music would be great!) > > > Sounding like a good overview now it is time to get into the mud > > and > > figure out how to implement that. > > Cool :) What I like to hear. For recording audio, I was thinking very > simply, record a sound-track while talking along to the video. You'll > need some kind of a script to make it go well, and I'd expect that > it'll > take 4 or 5 takes before you'll have something you're happy with, but > if > you cut down the demo to the bare bones, it can work really well. > > >> If it sounds good, which features do you think we should > >> screencast as > >> top priority? > > > Well I think you have already hit one of the most useful ones. > > > > 1) VM migrations > > > > Other simple idea that might make useful video's are. > > > > 2) The Log Collector (engine-log-collector), Maybe even showing > > the > > creation of a BZ report? > > 3) Uploading ISO (engine-iso-uploader), May be a little simple but > > we > > could combine with getting the ISO for windows drivers? > > 4) How to upload images (engine-image-uploader) or Migrating from > > another system using something like virt-v2v / virt-p2v > > 5) Cloning a Virtual Machine from a Snapshot. > > 6) Creating Templates > > 7) Pinning Virtual Machines to specific physical CPUs > > 8) Setup multiple networks showing how to activate and connecting > > to a > > hosts. > > 9) Adding storage domains? Building a data center? > > 10) Exporting VM for backup or moving to another data center. > > I definitely like adding storage domains/new disks, uploading > images/ISOs, creating new images from templates or snapshots, > migrating > from another system. Someone would need to explain to me why Log > Collector and CPU pinning are cool, and I'm not sure if setting up > multiple networks would make for a cool demo. > > I was thinking stuff like "adding a new node/VM" or "connecting > remotely > to a VM" would be kind of simple, but useful. > > Cheers, > Dave. > > -- > Dave Neary > Community Action and Impact > Open Source and Standards Team, Red Hat > Phone: +33 9 50 71 55 62 > > > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > From robert at middleswarth.net Thu Jul 5 20:32:17 2012 From: robert at middleswarth.net (Robert Middleswarth) Date: Thu, 05 Jul 2012 16:32:17 -0400 Subject: [Users] Getting some 3.1 screencasts In-Reply-To: <4FF5F404.9050102@redhat.com> References: <4FF5CAA5.80301@redhat.com> <4FF5ED96.6000808@middleswarth.net> <4FF5F404.9050102@redhat.com> Message-ID: <4FF5F9D1.6090704@middleswarth.net> On 07/05/2012 04:07 PM, Dave Neary wrote: > Hi, > > On 07/05/2012 09:40 PM, Robert Middleswarth wrote: >> On 07/05/2012 01:11 PM, Dave Neary wrote: >>> 1. We come up with a set (5-10) of demo stories we want to tell in the >>> wiki. These should contain: >>> * The feature we want to demo >>> * The "before recording" set-up that needs to be done >>> * The steps to demo the feature >>> * A quick script that someone can follow to explain what they're >>> doing. >>> >>> I'd like a few of these scripts to be for existing oVirt features >>> (say, migrating a VM to a different node) and a few to be for features >>> which are new in 3.1 (see the release notes at >>> http://ovirt.org/wiki/Release_Notes_Draft for details there, we should >>> pick one or two nice visible features like all-in-one install). >>> > >> How are we going to decide on these features we want to demo? Also some > > My thoughts were low-tech - everyone propose that we demo their > favourite feature. I was going to see the page with what I thought > were the most promising features from the release notes and the home > page, and throw in a couple of ringers that people would disagree with > to start discussion & debate ;-) > > I'm guessing that the number of things we'll want to demo will be > small enough that the priority will be obvious. We can always do more, > as long as we respect the priority listand get the most important ones > done before the release, if possible. > >> of the features like Glusterfs integration might be to complex for a 5 >> to 10 min video. > > True. Although the actual "add Glusterfs as a storage node" demo could > be literally 30s - but of course, we wouldn't be showing how to set up > the Glusterfs cluster in that. > > As I understand it, the steps are: > > 1. Turn on Gluster support in the Clusters preferences of the Engine > 2. Ensure vdsm-gluster is installed on the node > 3. Create a volume in the Engine preferences, add some bricks, and > make it available to nodes. A few of those steps make the diff between an working and not working setup. This morning I upgraded to a newer beta and had to engine-cleanup my setup. I forgot one of my own steps. Should have read my own guide :) In fact I had to pull up my own guide to remember the step I missed. > > I got all this from your tutorials, there may be small but important > steps I've left out - but if we assume that someone has an engine, > some nodes, and a Gluster set-up as prerequisites, then we can get it > down to a 10 minute webcast. > > I do take your point, though. In general anything longer than 5-10 > minutes (5 minutes is the sweet spot, anything longer than 15, people > won't watch) is too long, and we should break it up into steps, each > of which makes sense on its own. Most projects don't have to bandwidth to hosts there own video's and use either Vimeo or Youtube. Youtube limits you to 10 min video so that is a good max :) But 5 min is a good length. > >>> 3. Finally, we do voice-overs to add a sound track to the demo (and if >>> we have any skilled sound engineers, some tasteful CC licenced >>> background music would be great!) > >> Sounding like a good overview now it is time to get into the mud and >> figure out how to implement that. > > Cool :) What I like to hear. For recording audio, I was thinking very > simply, record a sound-track while talking along to the video. You'll > need some kind of a script to make it go well, and I'd expect that > it'll take 4 or 5 takes before you'll have something you're happy > with, but if you cut down the demo to the bare bones, it can work > really well. > >>> If it sounds good, which features do you think we should screencast as >>> top priority? > >> Well I think you have already hit one of the most useful ones. >> >> 1) VM migrations >> >> Other simple idea that might make useful video's are. >> >> 2) The Log Collector (engine-log-collector), Maybe even showing the >> creation of a BZ report? >> 3) Uploading ISO (engine-iso-uploader), May be a little simple but we >> could combine with getting the ISO for windows drivers? >> 4) How to upload images (engine-image-uploader) or Migrating from >> another system using something like virt-v2v / virt-p2v >> 5) Cloning a Virtual Machine from a Snapshot. >> 6) Creating Templates >> 7) Pinning Virtual Machines to specific physical CPUs >> 8) Setup multiple networks showing how to activate and connecting to a >> hosts. >> 9) Adding storage domains? Building a data center? >> 10) Exporting VM for backup or moving to another data center. > > I definitely like adding storage domains/new disks, uploading > images/ISOs, creating new images from templates or snapshots, > migrating from another system. Someone would need to explain to me why > Log Collector and CPU pinning are cool, and I'm not sure if setting up > multiple networks would make for a cool demo. > It might not be sexy to some but to an admin like me it would be. A utility to helps me collect the need info for a bug report and makes my life easier would be very sexy to me. Also really useful for internal use as we could point people to the video/howto for submitting bugs. > I was thinking stuff like "adding a new node/VM" or "connecting > remotely to a VM" would be kind of simple, but useful. I could see creating a VM. But connecting to VNC might actually turn some users off. Showing spice under might be because it is more integrated. > > Cheers, > Dave. > From robert at middleswarth.net Thu Jul 5 20:43:53 2012 From: robert at middleswarth.net (Robert Middleswarth) Date: Thu, 05 Jul 2012 16:43:53 -0400 Subject: [Users] Getting some 3.1 screencasts In-Reply-To: References: Message-ID: <4FF5FC89.2000603@middleswarth.net> On 07/05/2012 04:24 PM, Andrew Cathrow wrote: > > ----- Original Message ----- >> From: "Dave Neary" >> To: "Robert Middleswarth" >> Cc: "arch" , "users" >> Sent: Thursday, July 5, 2012 4:07:32 PM >> Subject: Re: [Users] Getting some 3.1 screencasts >> >> Hi, >> >> On 07/05/2012 09:40 PM, Robert Middleswarth wrote: >>> On 07/05/2012 01:11 PM, Dave Neary wrote: >>>> 1. We come up with a set (5-10) of demo stories we want to tell in >>>> the >>>> wiki. These should contain: >>>> * The feature we want to demo >>>> * The "before recording" set-up that needs to be done >>>> * The steps to demo the feature >>>> * A quick script that someone can follow to explain what they're >>>> doing. >>>> >>>> I'd like a few of these scripts to be for existing oVirt features >>>> (say, migrating a VM to a different node) and a few to be for >>>> features >>>> which are new in 3.1 (see the release notes at >>>> http://ovirt.org/wiki/Release_Notes_Draft for details there, we >>>> should >>>> pick one or two nice visible features like all-in-one install). >>>> >>> How are we going to decide on these features we want to demo? Also >>> some >> My thoughts were low-tech - everyone propose that we demo their >> favourite feature. I was going to see the page with what I thought >> were >> the most promising features from the release notes and the home page, >> and throw in a couple of ringers that people would disagree with to >> start discussion & debate ;-) >> > Everyone on this list (hopefully) has a good idea what oVirt can do ans se we tend to jump to the new, sexy features like Gluster, but the majority of people won't know the basics - they'll be shocked when they see a GUI with the amount of functionality oVirt 3.0 had let alone 3.1. > We've got a lot of experience demoing RHEV and it never ceases to amaze me how many people don't even know we have the basics. > > So don't forget or the basic features - creating a VM, making it highly available with just a mouse click, live migration, etc. > Yes my list missed the basic one creating a VM and you are right the basic's are what we want to start with. We also need to get it simple unless we are looking at creating a movie that can work but you need to do it in short segments demoing certain features in each video but it can be hard to get right. Best to remember kiss when working with video's. Thanks Robert > >> I'm guessing that the number of things we'll want to demo will be >> small >> enough that the priority will be obvious. We can always do more, as >> long >> as we respect the priority listand get the most important ones done >> before the release, if possible. >> >>> of the features like Glusterfs integration might be to complex for >>> a 5 >>> to 10 min video. >> True. Although the actual "add Glusterfs as a storage node" demo >> could >> be literally 30s - but of course, we wouldn't be showing how to set >> up >> the Glusterfs cluster in that. >> >> As I understand it, the steps are: >> >> 1. Turn on Gluster support in the Clusters preferences of the Engine >> 2. Ensure vdsm-gluster is installed on the node >> 3. Create a volume in the Engine preferences, add some bricks, and >> make >> it available to nodes. >> >> I got all this from your tutorials, there may be small but important >> steps I've left out - but if we assume that someone has an engine, >> some >> nodes, and a Gluster set-up as prerequisites, then we can get it down >> to >> a 10 minute webcast. >> >> I do take your point, though. In general anything longer than 5-10 >> minutes (5 minutes is the sweet spot, anything longer than 15, people >> won't watch) is too long, and we should break it up into steps, each >> of >> which makes sense on its own. >> >>>> 3. Finally, we do voice-overs to add a sound track to the demo >>>> (and if >>>> we have any skilled sound engineers, some tasteful CC licenced >>>> background music would be great!) >>> Sounding like a good overview now it is time to get into the mud >>> and >>> figure out how to implement that. >> Cool :) What I like to hear. For recording audio, I was thinking very >> simply, record a sound-track while talking along to the video. You'll >> need some kind of a script to make it go well, and I'd expect that >> it'll >> take 4 or 5 takes before you'll have something you're happy with, but >> if >> you cut down the demo to the bare bones, it can work really well. >> >>>> If it sounds good, which features do you think we should >>>> screencast as >>>> top priority? >>> Well I think you have already hit one of the most useful ones. >>> >>> 1) VM migrations >>> >>> Other simple idea that might make useful video's are. >>> >>> 2) The Log Collector (engine-log-collector), Maybe even showing >>> the >>> creation of a BZ report? >>> 3) Uploading ISO (engine-iso-uploader), May be a little simple but >>> we >>> could combine with getting the ISO for windows drivers? >>> 4) How to upload images (engine-image-uploader) or Migrating from >>> another system using something like virt-v2v / virt-p2v >>> 5) Cloning a Virtual Machine from a Snapshot. >>> 6) Creating Templates >>> 7) Pinning Virtual Machines to specific physical CPUs >>> 8) Setup multiple networks showing how to activate and connecting >>> to a >>> hosts. >>> 9) Adding storage domains? Building a data center? >>> 10) Exporting VM for backup or moving to another data center. >> I definitely like adding storage domains/new disks, uploading >> images/ISOs, creating new images from templates or snapshots, >> migrating >> from another system. Someone would need to explain to me why Log >> Collector and CPU pinning are cool, and I'm not sure if setting up >> multiple networks would make for a cool demo. >> >> I was thinking stuff like "adding a new node/VM" or "connecting >> remotely >> to a VM" would be kind of simple, but useful. >> >> Cheers, >> Dave. >> >> -- >> Dave Neary >> Community Action and Impact >> Open Source and Standards Team, Red Hat >> Phone: +33 9 50 71 55 62 >> >> >> _______________________________________________ >> Arch mailing list >> Arch at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/arch >> From robert at middleswarth.net Thu Jul 5 22:05:00 2012 From: robert at middleswarth.net (Robert Middleswarth) Date: Thu, 05 Jul 2012 18:05:00 -0400 Subject: What is it going to take to get EL6 builds? Message-ID: <4FF60F8C.3010004@middleswarth.net> I know there are a few things that don't work under oVirt on EL6 but there are unofficial builds out there and they seem to work pretty well. What is the major stopper from getting EL6 builds? Is it just a mater of getting patches submitted for building the spec files? Is there a need for EL 6 based slaves? Is there a concern about the features that don't work like Live Migration? I guess a good starting point is to build a todo list of what has to be done. Thanks Robert From robert at middleswarth.net Thu Jul 5 23:08:02 2012 From: robert at middleswarth.net (Robert Middleswarth) Date: Thu, 05 Jul 2012 19:08:02 -0400 Subject: [Users] What is it going to take to get EL6 builds? In-Reply-To: References: <4FF60F8C.3010004@middleswarth.net> Message-ID: <4FF61E52.40601@middleswarth.net> On 07/05/2012 07:02 PM, Trey Dockendorf wrote: > > > On Jul 5, 2012 5:05 PM, "Robert Middleswarth" > wrote: > > > > I know there are a few things that don't work under oVirt on EL6 but > there are unofficial builds out there and they seem to work pretty well. > > > > What is the major stopper from getting EL6 builds? Is it just a > mater of getting patches submitted for building the spec files? Is > there a need for EL 6 based slaves? Is there a concern about the > features that don't work like Live Migration? > > > > I guess a good starting point is to build a todo list of what has to > be done. > > > > Thanks > > Robert > > _______________________________________________ > > Users mailing list > > Users at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/users > > Based on personal attempts to rebuild ovirt for EL6 the biggest hurdle > I ran into is build dependencies. > > Thanks to the help of Dreyou Im using the work around of a binary > download of Maven and packages from jpackage repo. Ive built latest > vdsm without much issue and am setting up my mock environment to > rebuild the latest ovirt-engine release. > I bet that is why I am having so much trouble. I installed Maven but am not using jpackage repo for the rest of Java Thanks Robert > > Before Dreyou's repo I spent considerable time attempting to rebuild > Fedora SRPMs in EL6 to meet all dependencies but there were numerous > circular dependency issues building maven2 in EL6. This was before > 3.1 and have not attempted a full dependency build since. > > Id be interested in knowing what other challenges exist for an EL6 > release and would like to help where I can. > > - Trey > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iheim at redhat.com Fri Jul 6 12:57:39 2012 From: iheim at redhat.com (Itamar Heim) Date: Fri, 06 Jul 2012 15:57:39 +0300 Subject: What is it going to take to get EL6 builds? In-Reply-To: <4FF60F8C.3010004@middleswarth.net> References: <4FF60F8C.3010004@middleswarth.net> Message-ID: <4FF6E0C3.2080109@redhat.com> On 07/06/2012 01:05 AM, Robert Middleswarth wrote: > I know there are a few things that don't work under oVirt on EL6 but > there are unofficial builds out there and they seem to work pretty well. > > What is the major stopper from getting EL6 builds? Is it just a mater > of getting patches submitted for building the spec files? Is there a > need for EL 6 based slaves? Is there a concern about the features that > don't work like Live Migration? > > I guess a good starting point is to build a todo list of what has to be > done. just time. i see both el6 and debian distro's as next on the list, but current focus is on getting 3.1 out, then additional distros. help on pushing other distros is welcome of course. From mburns at redhat.com Tue Jul 10 16:28:09 2012 From: mburns at redhat.com (Mike Burns) Date: Tue, 10 Jul 2012 12:28:09 -0400 Subject: Call For Agenda Items -- oVirt Weekly Meeting 2012-07-11 Message-ID: <1341937689.26430.39.camel@beelzebub.mburnsfire.net> This is the agenda for the 2012-07-11 meeting: * Status of Next Release * Sub-project reports (engine, vdsm, node) * Upcoming workshops * wiki organization (dneary) If you have additional topics you would like to discuss, please let me know. Thanks Mike From kwade at redhat.com Tue Jul 10 19:14:34 2012 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Tue, 10 Jul 2012 12:14:34 -0700 Subject: Call For Agenda Items -- oVirt Weekly Meeting 2012-07-11 In-Reply-To: <1341937689.26430.39.camel@beelzebub.mburnsfire.net> References: <1341937689.26430.39.camel@beelzebub.mburnsfire.net> Message-ID: <4FFC7F1A.5060506@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/10/2012 09:28 AM, Mike Burns wrote:> This is the agenda for the 2012-07-11 meeting: > * Status of Next Release * Sub-project reports (engine, vdsm, > node) Can you put in a slot for a regular update from the Infrastructure team? For the next few months at least I expect we'll want to hear regularly what is going on there, as we focus on growing the team, splitting out services, migrating services around, improvements, etc. - - Karsten - -- Karsten 'quaid' Wade, Sr. Analyst - Community Growth http://TheOpenSourceWay.org .^\ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFP/H8a2ZIOBq0ODEERAlp5AJ4mFX83+jUmdDpx7XuzLCgYcAaayQCgtRHr pmKMcTuhagtlOWEL58VJy9c= =tY2U -----END PGP SIGNATURE----- From mburns at redhat.com Tue Jul 10 19:45:28 2012 From: mburns at redhat.com (Mike Burns) Date: Tue, 10 Jul 2012 15:45:28 -0400 Subject: Call For Agenda Items -- oVirt Weekly Meeting 2012-07-11 In-Reply-To: <4FFC7F1A.5060506@redhat.com> References: <1341937689.26430.39.camel@beelzebub.mburnsfire.net> <4FFC7F1A.5060506@redhat.com> Message-ID: <1341949528.26430.41.camel@beelzebub.mburnsfire.net> On Tue, 2012-07-10 at 12:14 -0700, Karsten 'quaid' Wade wrote: > On 07/10/2012 09:28 AM, Mike Burns wrote:> This is the agenda for the > 2012-07-11 meeting: > > * Status of Next Release * Sub-project reports (engine, vdsm, > > node) > > Can you put in a slot for a regular update from the Infrastructure > team? For the next few months at least I expect we'll want to hear > regularly what is going on there, as we focus on growing the team, > splitting out services, migrating services around, improvements, etc. Done > - Karsten > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch From mburns at redhat.com Wed Jul 11 15:13:38 2012 From: mburns at redhat.com (Mike Burns) Date: Wed, 11 Jul 2012 11:13:38 -0400 Subject: oVirt Weekly Meeting Minutes -- 2012-07-11 Message-ID: <1342019618.26417.16.camel@beelzebub.mburnsfire.net> Minutes: http://ovirt.org/meetings/ovirt/2012/ovirt.2012-07-11-14.00.html Minutes (text): http://ovirt.org/meetings/ovirt/2012/ovirt.2012-07-11-14.00.txt Log: http://ovirt.org/meetings/ovirt/2012/ovirt.2012-07-11-14.00.log.html ============================ #ovirt: ovirt weekly meeting ============================ Meeting started by mburns at 14:00:12 UTC. The full logs are available at http://ovirt.org/meetings/ovirt/2012/ovirt.2012-07-11-14.00.log.html . Meeting summary --------------- * agenda and roll call (mburns, 14:00:24) * Status of next release (mburns, 14:02:17) * Scheduled for July 25 (mburns, 14:02:30) * Blocker tree - https://bugzilla.redhat.com/showdependencytree.cgi?id=822145&hide_resolved=1 (oschreib, 14:03:17) * LINK: https://bugzilla.redhat.com/showdependencytree.cgi?id=822145&hide_resolved=1 (oschreib, 14:03:21) * 5 open issues (oschreib, 14:03:27) * 3.1: sshd daemon is not starting correctly after complete the installation of oVirt Node (node, MODIFIED) (oschreib, 14:05:20) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=832517 (oschreib, 14:05:36) * waiting for vdsm fix for BZ#837443 (oschreib, 14:06:33) * LINK: http://ovirt.org/releases/nightly/binary/ovirt-node-iso-2.4.0-999.mburns201207102007.fc17.iso (mburns, 14:06:48) * ovirt-node fails to register with ovirt-engine (vdsm, POST) (oschreib, 14:08:19) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=837443 (oschreib, 14:08:54) * still in review process (oschreib, 14:12:49) * 3.1: iptables blocking communication between node and engine (vdsm, MODIFIED) (oschreib, 14:13:37) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=832539 (oschreib, 14:13:51) * bug is on ovirt-node, not vdsm (oschreib, 14:16:55) * blocks on BZ#837443 as well (oschreib, 14:17:29) * Fedora 16 and 17 guests hang during boot (vdsm, NEW) (oschreib, 14:18:25) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=837925 (oschreib, 14:18:37) * still in work (oschreib, 14:21:58) * ACTION: dougsland to push and update the bug (oschreib, 14:22:59) * ovirtmgmt network issue when registering a host in 3.1 (vdsm, POST) (oschreib, 14:23:33) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=838097 (oschreib, 14:23:49) * ACTION: danken to make sure Saggi/Federico handles this quickly (oschreib, 14:27:52) * still in work (oschreib, 14:27:59) * ACTION: RobertM and oschreib to document 3.0->3.1 upgrade (oschreib, 14:40:04) * project status -- Engine (mburns, 14:40:39) * covered primarily in release status (mburns, 14:40:48) * no real bugs outstanding on the engine (mburns, 14:40:56) * project status -- vdsm (mburns, 14:47:58) * A couple blocking bugs -- 837443 838097 837925 (mburns, 14:48:23) * possibly 835920 (mburns, 14:48:29) * 835920 not a blocker, but very much a desired fix (mburns, 14:52:06) * project status -- node (mburns, 14:52:16) * all blockers fixed, just awaiting fixed vdsm (mburns, 14:52:28) * temporary scratch build uploaded to nightly area on ovirt.org for testing (mburns, 14:52:44) * ACTION: get an ack for 835920 from abaron or someone (danken, 14:52:46) * project status -- infra (mburns, 14:53:11) * mission statement seems to be agreed upon (mburns, 14:53:47) * now finalizing a list of initial members (mburns, 14:54:19) * biggest issue is storage on ovirt.org host, will require downtime (mburns, 14:54:58) * another major task: finalize criteria for how new people join infra team (mburns, 14:56:01) * other topics being actively worked: jenkins, wiki cleanup, etc... (mburns, 14:56:30) * all discussions are held on IRC or in email, all decisions are published to infra@ (mburns, 14:57:09) * also exploring puppet (mburns, 14:57:26) * workshops and conferences (mburns, 14:57:48) * LINK: http://www.ovirt.org/wiki/OVirt_Global_Workshops (lh, 14:58:15) * LINK: http://www.ovirt.org/wiki/OVirt_Global_Workshops (mburns, 14:58:44) * on track for LinuxCon North America August 28 (mburns, 15:00:35) * Red Hat Bangalore has offered to host a workshop on October 16 (mburns, 15:00:53) * hope is to have call for papers for bangalore workshop (mburns, 15:01:35) * other topics (mburns, 15:02:35) * dneary has a conflict, so deferring his discussion on wiki cleanup (mburns, 15:03:15) * proposed idea: appliance with allinone (mburns, 15:06:10) * AGREED: it's a good idea (mburns, 15:06:26) * ACTION: RobertM to kick off thread on arch about allinone appliance (mburns, 15:09:54) Meeting ended at 15:12:37 UTC. Action Items ------------ * dougsland to push and update the bug * danken to make sure Saggi/Federico handles this quickly * RobertM and oschreib to document 3.0->3.1 upgrade * get an ack for 835920 from abaron or someone * RobertM to kick off thread on arch about allinone appliance Action Items, by person ----------------------- * danken * danken to make sure Saggi/Federico handles this quickly * dougsland * dougsland to push and update the bug * oschreib * RobertM and oschreib to document 3.0->3.1 upgrade * RobertM * RobertM and oschreib to document 3.0->3.1 upgrade * RobertM to kick off thread on arch about allinone appliance * **UNASSIGNED** * get an ack for 835920 from abaron or someone People Present (lines said) --------------------------- * mburns (116) * oschreib (77) * RobertM (29) * lh (13) * danken (13) * dougsland (12) * ovirtbot (7) * dneary (5) * sgordon_ (3) * jbrooks (3) * pmyers (3) * joncox (2) * jb_netapp (1) * rharper (1) * rickyh (1) * quaid (1) * ilvovsky (1) * eedri (1) * ofrenkel (1) * dustins (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot From kwade at redhat.com Fri Jul 13 01:26:56 2012 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Thu, 12 Jul 2012 18:26:56 -0700 Subject: Outage :: www.ovirt.org :: 2012-07-13 2300 to 2330 UTC (7 pm EDT/4 pm PDT) Message-ID: <4FFF7960.7000300@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm back with the rescheduled outage for the www.ovirt.org server. We're filling up the disk on www.ovirt.org, which is expected since it's only 10 GB. I'm going to add 15 GB, which requires a reboot. Prior to the reboot I'll come on IRC and make sure everyone is prepared. 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. If anyone has done this before on Linode and wants to offer suggestions or hold my hand :) let me know. == When == 2300 to 2330 UTC date -d "2012-07-13 2300 UTC" == Affected services == lists.ovirt.org www.ovirt.org/wiki www.ovirt.org/.* ovirtbot (IRC bot) - -- Karsten 'quaid' Wade, Sr. Analyst - Community Growth http://TheOpenSourceWay.org .^\ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFP/3lg2ZIOBq0ODEERAlP4AJ4hbvBeUNcuoDe0PYPOPjauqc6BZwCdFLGm 3nkaZ1xffyW0T7w4nz7RH8Y= =2zx3 -----END PGP SIGNATURE----- From robert at middleswarth.net Fri Jul 13 16:38:25 2012 From: robert at middleswarth.net (Robert Middleswarth) Date: Fri, 13 Jul 2012 12:38:25 -0400 Subject: All In One ISO. Message-ID: <50004F01.5070301@middleswarth.net> During this weeks meeting I brought up the idea of building an All In One ISO. The idea is it would install the OS then on first boot run you though engine-setup with the all in one plug-in installed. This would make it really easy for Admin to test oVirt and see if it works for them before putting there time into building things out the correct way. Everyone at the meeting though it was a good idea and suggest I bring it up in Arch to see what the group as a whole thought. Thanks Robert From Dustin.Schoenbrun at netapp.com Fri Jul 13 16:53:44 2012 From: Dustin.Schoenbrun at netapp.com (Schoenbrun, Dustin) Date: Fri, 13 Jul 2012 16:53:44 +0000 Subject: All In One ISO. In-Reply-To: <50004F01.5070301@middleswarth.net> Message-ID: I know that I would use it for test and development in my labs here. This sounds like a fantastic idea! -- Dustin On 7/13/12 12:38 PM, "Robert Middleswarth" wrote: >During this weeks meeting I brought up the idea of building an All In >One ISO. The idea is it would install the OS then on first boot run you >though engine-setup with the all in one plug-in installed. This would >make it really easy for Admin to test oVirt and see if it works for them >before putting there time into building things out the correct way. > >Everyone at the meeting though it was a good idea and suggest I bring it >up in Arch to see what the group as a whole thought. > >Thanks >Robert >_______________________________________________ >Arch mailing list >Arch at ovirt.org >http://lists.ovirt.org/mailman/listinfo/arch From kwade at redhat.com Sat Jul 14 01:02:34 2012 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Fri, 13 Jul 2012 18:02:34 -0700 Subject: Outage :: www.ovirt.org :: 2012-07-13 2300 to 2330 UTC (7 pm EDT/4 pm PDT) In-Reply-To: <4FFF7960.7000300@redhat.com> References: <4FFF7960.7000300@redhat.com> Message-ID: <5000C52A.1060804@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This outage is now complete. All services have been tested as having come back up successfully. We know have an addition 15 GB of storage to hold us for the immediate future ... barely. Thanks - Karsten On 07/12/2012 06:26 PM, Karsten 'quaid' Wade wrote: > I'm back with the rescheduled outage for the www.ovirt.org server. > > We're filling up the disk on www.ovirt.org, which is expected > since it's only 10 GB. I'm going to add 15 GB, which requires a > reboot. > > Prior to the reboot I'll come on IRC and make sure everyone is > prepared. > > 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. > > If anyone has done this before on Linode and wants to offer > suggestions or hold my hand :) let me know. > > == When == > > 2300 to 2330 UTC > > date -d "2012-07-13 2300 UTC" > > == Affected services == > > lists.ovirt.org www.ovirt.org/wiki www.ovirt.org/.* ovirtbot (IRC > bot) > > _______________________________________________ Arch mailing list > Arch at ovirt.org http://lists.ovirt.org/mailman/listinfo/arch > - -- Karsten 'quaid' Wade, Sr. Analyst - Community Growth http://TheOpenSourceWay.org .^\ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFQAMUp2ZIOBq0ODEERAszgAKCngaU+rLbQcH9HmtDonmdIOVxJ6wCeK+eo PxvtI/akMRfAft5mZsHuKwo= =pVrs -----END PGP SIGNATURE----- From iheim at redhat.com Sun Jul 15 07:31:47 2012 From: iheim at redhat.com (Itamar Heim) Date: Sun, 15 Jul 2012 10:31:47 +0300 Subject: All In One ISO. In-Reply-To: <50004F01.5070301@middleswarth.net> References: <50004F01.5070301@middleswarth.net> Message-ID: <500271E3.9040603@redhat.com> On 07/13/2012 07:38 PM, Robert Middleswarth wrote: > During this weeks meeting I brought up the idea of building an All In > One ISO. The idea is it would install the OS then on first boot run you > though engine-setup with the all in one plug-in installed. This would > make it really easy for Admin to test oVirt and see if it works for them > before putting there time into building things out the correct way. > > Everyone at the meeting though it was a good idea and suggest I bring it > up in Arch to see what the group as a whole thought. are you talking about a spin[1] would probably require to turn the few questions into an anaconda screen, but will look as professional as it can get. [1] http://spins.fedoraproject.org/ From abaron at redhat.com Sun Jul 15 08:53:04 2012 From: abaron at redhat.com (Ayal Baron) Date: Sun, 15 Jul 2012 04:53:04 -0400 (EDT) Subject: Getting rid of arch@ovirt.org? In-Reply-To: <09b48d98-8055-466a-9cbb-0134f29e6878@zmail13.collab.prod.int.phx2.redhat.com> Message-ID: <266239e3-dcdc-4db5-b121-f37c42052ffc@zmail13.collab.prod.int.phx2.redhat.com> Hi all, Sorry for cross-posting, but in this case I think it's relevant. The original idea was that every time we wish to discuss a new cross-component feature we should do it over arch list. However, it would appear that de-facto usually engine-devel and vdsm-devel are being used (cross posted). Currently engine-devel has 211 subscribers, arch has 160 and vdsm-devel has 128 so from this perspective again, arch seems less relevant. I propose we ditch arch and keep the other 2 mailing lists. I'm not sure whether new cross-component features should be discussed solely on engine-devel or cross-posted (there are probably people who wouldn't care about engine side but would still like to know about such changes). Thoughts? Regards, Ayal. From agl at us.ibm.com Sun Jul 15 14:00:38 2012 From: agl at us.ibm.com (Adam Litke) Date: Sun, 15 Jul 2012 09:00:38 -0500 Subject: [vdsm] Getting rid of arch@ovirt.org? In-Reply-To: <266239e3-dcdc-4db5-b121-f37c42052ffc@zmail13.collab.prod.int.phx2.redhat.com> References: <09b48d98-8055-466a-9cbb-0134f29e6878@zmail13.collab.prod.int.phx2.redhat.com> <266239e3-dcdc-4db5-b121-f37c42052ffc@zmail13.collab.prod.int.phx2.redhat.com> Message-ID: <20120715140038.GH2937@aglitke> On Sun, Jul 15, 2012 at 04:53:04AM -0400, Ayal Baron wrote: > Hi all, > > Sorry for cross-posting, but in this case I think it's relevant. > > The original idea was that every time we wish to discuss a new cross-component feature we should do it over arch list. However, it would appear that de-facto usually engine-devel and vdsm-devel are being used (cross posted). > Currently engine-devel has 211 subscribers, arch has 160 and vdsm-devel has 128 so from this perspective again, arch seems less relevant. > I propose we ditch arch and keep the other 2 mailing lists. > I'm not sure whether new cross-component features should be discussed solely on engine-devel or cross-posted (there are probably people who wouldn't care about engine side but would still like to know about such changes). +1 to ditching arch. I would still prefer that cross-component features cross-post to vdsm-devel and engine-devel. My current focus is on vdsm and the traffic level on that list is currently far more manageable than that of engine-devel. -- Adam Litke IBM Linux Technology Center From abaron at redhat.com Sun Jul 15 14:16:11 2012 From: abaron at redhat.com (Ayal Baron) Date: Sun, 15 Jul 2012 10:16:11 -0400 (EDT) Subject: [vdsm] Getting rid of arch@ovirt.org? In-Reply-To: <20120715140038.GH2937@aglitke> Message-ID: <9f4325ea-d1df-4481-919e-f1e7270d9129@zmail13.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > On Sun, Jul 15, 2012 at 04:53:04AM -0400, Ayal Baron wrote: > > Hi all, > > > > Sorry for cross-posting, but in this case I think it's relevant. > > > > The original idea was that every time we wish to discuss a new > > cross-component feature we should do it over arch list. However, > > it would appear that de-facto usually engine-devel and vdsm-devel > > are being used (cross posted). > > Currently engine-devel has 211 subscribers, arch has 160 and > > vdsm-devel has 128 so from this perspective again, arch seems less > > relevant. > > I propose we ditch arch and keep the other 2 mailing lists. > > I'm not sure whether new cross-component features should be > > discussed solely on engine-devel or cross-posted (there are > > probably people who wouldn't care about engine side but would > > still like to know about such changes). > > +1 to ditching arch. I would still prefer that cross-component > features > cross-post to vdsm-devel and engine-devel. My current focus is on > vdsm and the > traffic level on that list is currently far more manageable than that > of > engine-devel. That's my sentiment as well (plus I have a rule to drop duplicates so I don't care much about it ;) > > -- > Adam Litke > IBM Linux Technology Center > > From kwade at redhat.com Sun Jul 15 19:37:06 2012 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Sun, 15 Jul 2012 12:37:06 -0700 Subject: Getting rid of arch@ovirt.org? In-Reply-To: <266239e3-dcdc-4db5-b121-f37c42052ffc@zmail13.collab.prod.int.phx2.redhat.com> References: <266239e3-dcdc-4db5-b121-f37c42052ffc@zmail13.collab.prod.int.phx2.redhat.com> Message-ID: <50031BE2.4010507@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/15/2012 01:53 AM, Ayal Baron wrote: > Hi all, > > Sorry for cross-posting, but in this case I think it's relevant. > > The original idea was that every time we wish to discuss a new > cross-component feature we should do it over arch list. However, it > would appear that de-facto usually engine-devel and vdsm-devel are > being used (cross posted). Currently engine-devel has 211 > subscribers, arch has 160 and vdsm-devel has 128 so from this > perspective again, arch seems less relevant. I propose we ditch > arch and keep the other 2 mailing lists. I'm not sure whether new > cross-component features should be discussed solely on engine-devel > or cross-posted (there are probably people who wouldn't care about > engine side but would still like to know about such changes). > > Thoughts? - -1 I don't normally read engine-devel and vdsm-devel, so I hadn't noticed that discussions I would expect to be on arch@ are not happening here. I'm probably not the only person in that situation. If this project were 100% about Engine and VDSM, then I could understand your reasoning. But we've already added a few new incubating projects, we have subsystem teams such as documentation and infrastructure, and we all need a single location where we know we can reach *all* contributors to this project. If we try to force all that discussion on to engine-devel, not everyone would be interested. There is enough on engine-devel that is not general interest that it would become noise (as it has for me, so I filter it) or people would drop it all together. Perhaps what we need to do is have the discipline to cross-post *all* general interest discussions from the project mailing list back to arch@? Enforce the rule that decisions that affect the whole project have to be ratified on arch@ instead of whatever project list the discussions started on? Strongly suggest that all contributors be on arch@ and announce@ as a minimum? I'm sure there are open source projects that don't have a general interest contributor list, preferring to run all that discussion on a technical-focused list. But I don't recommend it. It's the kind of thing that repels contributors who don't want to sort through deep developer discussions just to find out what is generally going on. - - Karsten - -- Karsten 'quaid' Wade, Sr. Analyst - Community Growth http://TheOpenSourceWay.org .^\ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFQAxvi2ZIOBq0ODEERAlaXAKDMCwHjZzS/mtWkzvYt+Px+iEhl/wCZASvN AYHTXhHYq33yJMebr4bmijE= =iBdY -----END PGP SIGNATURE----- From abaron at redhat.com Sun Jul 15 19:59:45 2012 From: abaron at redhat.com (Ayal Baron) Date: Sun, 15 Jul 2012 15:59:45 -0400 (EDT) Subject: [vdsm] Getting rid of arch@ovirt.org? In-Reply-To: <50031BE2.4010507@redhat.com> Message-ID: <66371106-0980-4506-9855-af5c24b6b051@zmail13.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/15/2012 01:53 AM, Ayal Baron wrote: > > Hi all, > > > > Sorry for cross-posting, but in this case I think it's relevant. > > > > The original idea was that every time we wish to discuss a new > > cross-component feature we should do it over arch list. However, it > > would appear that de-facto usually engine-devel and vdsm-devel are > > being used (cross posted). Currently engine-devel has 211 > > subscribers, arch has 160 and vdsm-devel has 128 so from this > > perspective again, arch seems less relevant. I propose we ditch > > arch and keep the other 2 mailing lists. I'm not sure whether new > > cross-component features should be discussed solely on engine-devel > > or cross-posted (there are probably people who wouldn't care about > > engine side but would still like to know about such changes). > > > > Thoughts? > > - -1 > > I don't normally read engine-devel and vdsm-devel, so I hadn't > noticed > that discussions I would expect to be on arch@ are not happening > here. > I'm probably not the only person in that situation. > > If this project were 100% about Engine and VDSM, then I could > understand your reasoning. But we've already added a few new > incubating projects, we have subsystem teams such as documentation > and > infrastructure, and we all need a single location where we know we > can > reach *all* contributors to this project. > > If we try to force all that discussion on to engine-devel, not > everyone would be interested. There is enough on engine-devel that is > not general interest that it would become noise (as it has for me, so > I filter it) or people would drop it all together. > > Perhaps what we need to do is have the discipline to cross-post *all* > general interest discussions from the project mailing list back to > arch@? Enforce the rule that decisions that affect the whole project > have to be ratified on arch@ instead of whatever project list the > discussions started on? Strongly suggest that all contributors be on > arch@ and announce@ as a minimum? I find that anything that should go on arch would interest anyone on the devel lists (as it is about new features, design, etc) so I believe that arch should have at least everyone on engine-devel and vdsm-devel. However, right now this is not the case as is evident by number of subs to each list (e.g. I haven't compared to see if everyone on arch is on engine). So imo something needs to be done. I'm fine with keeping arch, but as you said, that means we need to enforce it to be *the* list for feature discussions and I'm not exactly sure how you'd go about doing that. > > I'm sure there are open source projects that don't have a general > interest contributor list, preferring to run all that discussion on a > technical-focused list. But I don't recommend it. It's the kind of > thing that repels contributors who don't want to sort through deep > developer discussions just to find out what is generally going on. > > - - Karsten > - -- > Karsten 'quaid' Wade, Sr. Analyst - Community Growth > http://TheOpenSourceWay.org .^\ http://community.redhat.com > @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iD8DBQFQAxvi2ZIOBq0ODEERAlaXAKDMCwHjZzS/mtWkzvYt+Px+iEhl/wCZASvN > AYHTXhHYq33yJMebr4bmijE= > =iBdY > -----END PGP SIGNATURE----- > _______________________________________________ > vdsm-devel mailing list > vdsm-devel at lists.fedorahosted.org > https://fedorahosted.org/mailman/listinfo/vdsm-devel > From robert at middleswarth.net Sun Jul 15 22:46:03 2012 From: robert at middleswarth.net (Robert Middleswarth) Date: Sun, 15 Jul 2012 18:46:03 -0400 Subject: Getting rid of arch@ovirt.org? In-Reply-To: <66371106-0980-4506-9855-af5c24b6b051@zmail13.collab.prod.int.phx2.redhat.com> References: <66371106-0980-4506-9855-af5c24b6b051@zmail13.collab.prod.int.phx2.redhat.com> Message-ID: <5003482B.60406@middleswarth.net> On 07/15/2012 03:59 PM, Ayal Baron wrote: > > ----- Original Message ----- >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 07/15/2012 01:53 AM, Ayal Baron wrote: >>> Hi all, >>> >>> Sorry for cross-posting, but in this case I think it's relevant. >>> >>> The original idea was that every time we wish to discuss a new >>> cross-component feature we should do it over arch list. However, it >>> would appear that de-facto usually engine-devel and vdsm-devel are >>> being used (cross posted). Currently engine-devel has 211 >>> subscribers, arch has 160 and vdsm-devel has 128 so from this >>> perspective again, arch seems less relevant. I propose we ditch >>> arch and keep the other 2 mailing lists. I'm not sure whether new >>> cross-component features should be discussed solely on engine-devel >>> or cross-posted (there are probably people who wouldn't care about >>> engine side but would still like to know about such changes). >>> >>> Thoughts? >> - -1 >> >> I don't normally read engine-devel and vdsm-devel, so I hadn't >> noticed >> that discussions I would expect to be on arch@ are not happening >> here. >> I'm probably not the only person in that situation. >> >> If this project were 100% about Engine and VDSM, then I could >> understand your reasoning. But we've already added a few new >> incubating projects, we have subsystem teams such as documentation >> and >> infrastructure, and we all need a single location where we know we >> can >> reach *all* contributors to this project. >> >> If we try to force all that discussion on to engine-devel, not >> everyone would be interested. There is enough on engine-devel that is >> not general interest that it would become noise (as it has for me, so >> I filter it) or people would drop it all together. >> >> Perhaps what we need to do is have the discipline to cross-post *all* >> general interest discussions from the project mailing list back to >> arch@? Enforce the rule that decisions that affect the whole project >> have to be ratified on arch@ instead of whatever project list the >> discussions started on? Strongly suggest that all contributors be on >> arch@ and announce@ as a minimum? > I find that anything that should go on arch would interest anyone on the devel lists (as it is about new features, design, etc) so I believe that arch should have at least everyone on engine-devel and vdsm-devel. > However, right now this is not the case as is evident by number of subs to each list (e.g. I haven't compared to see if everyone on arch is on engine). > So imo something needs to be done. > I'm fine with keeping arch, but as you said, that means we need to enforce it to be *the* list for feature discussions and I'm not exactly sure how you'd go about doing that. Maybe arch needs renamed to make it clear what if is for? Maybe something simple like ovirt-devel to make it clear it is for generally ovirt development? Thanks Robert >> I'm sure there are open source projects that don't have a general >> interest contributor list, preferring to run all that discussion on a >> technical-focused list. But I don't recommend it. It's the kind of >> thing that repels contributors who don't want to sort through deep >> developer discussions just to find out what is generally going on. >> >> - - Karsten >> - -- >> Karsten 'quaid' Wade, Sr. Analyst - Community Growth >> http://TheOpenSourceWay.org .^\ http://community.redhat.com >> @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.12 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iD8DBQFQAxvi2ZIOBq0ODEERAlaXAKDMCwHjZzS/mtWkzvYt+Px+iEhl/wCZASvN >> AYHTXhHYq33yJMebr4bmijE= >> =iBdY >> -----END PGP SIGNATURE----- >> _______________________________________________ >> vdsm-devel mailing list >> vdsm-devel at lists.fedorahosted.org >> https://fedorahosted.org/mailman/listinfo/vdsm-devel >> > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From robert at middleswarth.net Mon Jul 16 00:14:18 2012 From: robert at middleswarth.net (Robert Middleswarth) Date: Sun, 15 Jul 2012 20:14:18 -0400 Subject: Moved www.orvirt.org/wiki to wiki.ovrit.org Message-ID: <50035CDA.9020903@middleswarth.net> Over the weekend we move the wiki fromwww.ovirt.org/wiki to wiki.ovirt.org and add redirectswww.ovirt.org/wiki to wiki.ovirt.org. This will make it easier to break up the site into 2 servers at some point. Including quaid idea of using openshift to managing the wordpress and media wiki sites. Thanks Robert From eedri at redhat.com Mon Jul 16 06:10:12 2012 From: eedri at redhat.com (Eyal Edri) Date: Mon, 16 Jul 2012 02:10:12 -0400 (EDT) Subject: Moved www.orvirt.org/wiki to wiki.ovrit.org In-Reply-To: <50035CDA.9020903@middleswarth.net> Message-ID: Just a small question, any reason we kept the /wiki folder when redirecting from wiki.ovirt.org? e.g. http://wiki.ovirt.org/wiki/Jenkins instead of just wiki.ovirt.org/Jenkins? Eyal. ----- Original Message ----- > From: "Robert Middleswarth" > To: "arch" > Sent: Monday, July 16, 2012 3:14:18 AM > Subject: Moved www.orvirt.org/wiki to wiki.ovrit.org > > Over the weekend we move the wiki fromwww.ovirt.org/wiki to > wiki.ovirt.org and add redirectswww.ovirt.org/wiki to > wiki.ovirt.org. This will make it easier to break up the site into > 2 servers at some point. Including quaid idea of using openshift to > managing the wordpress and media wiki sites. > > Thanks > Robert > > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > From iheim at redhat.com Mon Jul 16 06:41:51 2012 From: iheim at redhat.com (Itamar Heim) Date: Mon, 16 Jul 2012 09:41:51 +0300 Subject: [vdsm] Getting rid of arch@ovirt.org? In-Reply-To: <5003482B.60406@middleswarth.net> References: <66371106-0980-4506-9855-af5c24b6b051@zmail13.collab.prod.int.phx2.redhat.com> <5003482B.60406@middleswarth.net> Message-ID: <5003B7AF.8020409@redhat.com> On 07/16/2012 01:46 AM, Robert Middleswarth wrote: > On 07/15/2012 03:59 PM, Ayal Baron wrote: >> >> ----- Original Message ----- >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 07/15/2012 01:53 AM, Ayal Baron wrote: >>>> Hi all, >>>> >>>> Sorry for cross-posting, but in this case I think it's relevant. >>>> >>>> The original idea was that every time we wish to discuss a new >>>> cross-component feature we should do it over arch list. However, it >>>> would appear that de-facto usually engine-devel and vdsm-devel are >>>> being used (cross posted). Currently engine-devel has 211 >>>> subscribers, arch has 160 and vdsm-devel has 128 so from this >>>> perspective again, arch seems less relevant. I propose we ditch >>>> arch and keep the other 2 mailing lists. I'm not sure whether new >>>> cross-component features should be discussed solely on engine-devel >>>> or cross-posted (there are probably people who wouldn't care about >>>> engine side but would still like to know about such changes). >>>> >>>> Thoughts? >>> - -1 >>> >>> I don't normally read engine-devel and vdsm-devel, so I hadn't >>> noticed >>> that discussions I would expect to be on arch@ are not happening >>> here. >>> I'm probably not the only person in that situation. >>> >>> If this project were 100% about Engine and VDSM, then I could >>> understand your reasoning. But we've already added a few new >>> incubating projects, we have subsystem teams such as documentation >>> and >>> infrastructure, and we all need a single location where we know we >>> can >>> reach *all* contributors to this project. >>> >>> If we try to force all that discussion on to engine-devel, not >>> everyone would be interested. There is enough on engine-devel that is >>> not general interest that it would become noise (as it has for me, so >>> I filter it) or people would drop it all together. >>> >>> Perhaps what we need to do is have the discipline to cross-post *all* >>> general interest discussions from the project mailing list back to >>> arch@? Enforce the rule that decisions that affect the whole project >>> have to be ratified on arch@ instead of whatever project list the >>> discussions started on? Strongly suggest that all contributors be on >>> arch@ and announce@ as a minimum? >> I find that anything that should go on arch would interest anyone on >> the devel lists (as it is about new features, design, etc) so I >> believe that arch should have at least everyone on engine-devel and >> vdsm-devel. >> However, right now this is not the case as is evident by number of >> subs to each list (e.g. I haven't compared to see if everyone on arch >> is on engine). >> So imo something needs to be done. >> I'm fine with keeping arch, but as you said, that means we need to >> enforce it to be *the* list for feature discussions and I'm not >> exactly sure how you'd go about doing that. > Maybe arch needs renamed to make it clear what if is for? > > Maybe something simple like ovirt-devel to make it clear it is for > generally ovirt development? we can simply make it arch include the other mailing lists, so sending to arch would be sending to all other mailing lists. wouldn't resolve the dupes, but will resolve need of everyone to subscribe to it as well. (for dupes i also use a mail filter to delete emails arriving from engine-devel and cc other mailing list, etc. From lpeer at redhat.com Mon Jul 16 06:56:27 2012 From: lpeer at redhat.com (Livnat Peer) Date: Mon, 16 Jul 2012 09:56:27 +0300 Subject: [vdsm] Getting rid of arch@ovirt.org? In-Reply-To: <5003B7AF.8020409@redhat.com> References: <66371106-0980-4506-9855-af5c24b6b051@zmail13.collab.prod.int.phx2.redhat.com> <5003482B.60406@middleswarth.net> <5003B7AF.8020409@redhat.com> Message-ID: <5003BB1B.8040002@redhat.com> On 16/07/12 09:41, Itamar Heim wrote: > On 07/16/2012 01:46 AM, Robert Middleswarth wrote: >> On 07/15/2012 03:59 PM, Ayal Baron wrote: >>> >>> ----- Original Message ----- >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> On 07/15/2012 01:53 AM, Ayal Baron wrote: >>>>> Hi all, >>>>> >>>>> Sorry for cross-posting, but in this case I think it's relevant. >>>>> >>>>> The original idea was that every time we wish to discuss a new >>>>> cross-component feature we should do it over arch list. However, it >>>>> would appear that de-facto usually engine-devel and vdsm-devel are >>>>> being used (cross posted). Currently engine-devel has 211 >>>>> subscribers, arch has 160 and vdsm-devel has 128 so from this >>>>> perspective again, arch seems less relevant. I propose we ditch >>>>> arch and keep the other 2 mailing lists. I'm not sure whether new >>>>> cross-component features should be discussed solely on engine-devel >>>>> or cross-posted (there are probably people who wouldn't care about >>>>> engine side but would still like to know about such changes). >>>>> >>>>> Thoughts? >>>> - -1 >>>> >>>> I don't normally read engine-devel and vdsm-devel, so I hadn't >>>> noticed >>>> that discussions I would expect to be on arch@ are not happening >>>> here. >>>> I'm probably not the only person in that situation. >>>> >>>> If this project were 100% about Engine and VDSM, then I could >>>> understand your reasoning. But we've already added a few new >>>> incubating projects, we have subsystem teams such as documentation >>>> and >>>> infrastructure, and we all need a single location where we know we >>>> can >>>> reach *all* contributors to this project. >>>> >>>> If we try to force all that discussion on to engine-devel, not >>>> everyone would be interested. There is enough on engine-devel that is >>>> not general interest that it would become noise (as it has for me, so >>>> I filter it) or people would drop it all together. >>>> >>>> Perhaps what we need to do is have the discipline to cross-post *all* >>>> general interest discussions from the project mailing list back to >>>> arch@? Enforce the rule that decisions that affect the whole project >>>> have to be ratified on arch@ instead of whatever project list the >>>> discussions started on? Strongly suggest that all contributors be on >>>> arch@ and announce@ as a minimum? >>> I find that anything that should go on arch would interest anyone on >>> the devel lists (as it is about new features, design, etc) so I >>> believe that arch should have at least everyone on engine-devel and >>> vdsm-devel. >>> However, right now this is not the case as is evident by number of >>> subs to each list (e.g. I haven't compared to see if everyone on arch >>> is on engine). >>> So imo something needs to be done. >>> I'm fine with keeping arch, but as you said, that means we need to >>> enforce it to be *the* list for feature discussions and I'm not >>> exactly sure how you'd go about doing that. >> Maybe arch needs renamed to make it clear what if is for? >> >> Maybe something simple like ovirt-devel to make it clear it is for >> generally ovirt development? > > we can simply make it arch include the other mailing lists, so sending > to arch would be sending to all other mailing lists. What would happen if someone reply on the engine-list to a mail originally sent to arch? wouldn't we end-up starting a thread on arch and then loosing it to one of the other lists? > wouldn't resolve the dupes, but will resolve need of everyone to > subscribe to it as well. > (for dupes i also use a mail filter to delete emails arriving from > engine-devel and cc other mailing list, etc. > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch From iheim at redhat.com Mon Jul 16 07:01:26 2012 From: iheim at redhat.com (Itamar Heim) Date: Mon, 16 Jul 2012 10:01:26 +0300 Subject: [vdsm] Getting rid of arch@ovirt.org? In-Reply-To: <5003BB1B.8040002@redhat.com> References: <66371106-0980-4506-9855-af5c24b6b051@zmail13.collab.prod.int.phx2.redhat.com> <5003482B.60406@middleswarth.net> <5003B7AF.8020409@redhat.com> <5003BB1B.8040002@redhat.com> Message-ID: <5003BC46.9040903@redhat.com> On 07/16/2012 09:56 AM, Livnat Peer wrote: > On 16/07/12 09:41, Itamar Heim wrote: >> On 07/16/2012 01:46 AM, Robert Middleswarth wrote: >>> On 07/15/2012 03:59 PM, Ayal Baron wrote: >>>> >>>> ----- Original Message ----- >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA1 >>>>> >>>>> On 07/15/2012 01:53 AM, Ayal Baron wrote: >>>>>> Hi all, >>>>>> >>>>>> Sorry for cross-posting, but in this case I think it's relevant. >>>>>> >>>>>> The original idea was that every time we wish to discuss a new >>>>>> cross-component feature we should do it over arch list. However, it >>>>>> would appear that de-facto usually engine-devel and vdsm-devel are >>>>>> being used (cross posted). Currently engine-devel has 211 >>>>>> subscribers, arch has 160 and vdsm-devel has 128 so from this >>>>>> perspective again, arch seems less relevant. I propose we ditch >>>>>> arch and keep the other 2 mailing lists. I'm not sure whether new >>>>>> cross-component features should be discussed solely on engine-devel >>>>>> or cross-posted (there are probably people who wouldn't care about >>>>>> engine side but would still like to know about such changes). >>>>>> >>>>>> Thoughts? >>>>> - -1 >>>>> >>>>> I don't normally read engine-devel and vdsm-devel, so I hadn't >>>>> noticed >>>>> that discussions I would expect to be on arch@ are not happening >>>>> here. >>>>> I'm probably not the only person in that situation. >>>>> >>>>> If this project were 100% about Engine and VDSM, then I could >>>>> understand your reasoning. But we've already added a few new >>>>> incubating projects, we have subsystem teams such as documentation >>>>> and >>>>> infrastructure, and we all need a single location where we know we >>>>> can >>>>> reach *all* contributors to this project. >>>>> >>>>> If we try to force all that discussion on to engine-devel, not >>>>> everyone would be interested. There is enough on engine-devel that is >>>>> not general interest that it would become noise (as it has for me, so >>>>> I filter it) or people would drop it all together. >>>>> >>>>> Perhaps what we need to do is have the discipline to cross-post *all* >>>>> general interest discussions from the project mailing list back to >>>>> arch@? Enforce the rule that decisions that affect the whole project >>>>> have to be ratified on arch@ instead of whatever project list the >>>>> discussions started on? Strongly suggest that all contributors be on >>>>> arch@ and announce@ as a minimum? >>>> I find that anything that should go on arch would interest anyone on >>>> the devel lists (as it is about new features, design, etc) so I >>>> believe that arch should have at least everyone on engine-devel and >>>> vdsm-devel. >>>> However, right now this is not the case as is evident by number of >>>> subs to each list (e.g. I haven't compared to see if everyone on arch >>>> is on engine). >>>> So imo something needs to be done. >>>> I'm fine with keeping arch, but as you said, that means we need to >>>> enforce it to be *the* list for feature discussions and I'm not >>>> exactly sure how you'd go about doing that. >>> Maybe arch needs renamed to make it clear what if is for? >>> >>> Maybe something simple like ovirt-devel to make it clear it is for >>> generally ovirt development? >> >> we can simply make it arch include the other mailing lists, so sending >> to arch would be sending to all other mailing lists. > > What would happen if someone reply on the engine-list to a mail > originally sent to arch? > > wouldn't we end-up starting a thread on arch and then loosing it to one > of the other lists? reply-to is not set to reply-to-list, rather to original sender/cc list, so shouldn't be an issue > > >> wouldn't resolve the dupes, but will resolve need of everyone to >> subscribe to it as well. >> (for dupes i also use a mail filter to delete emails arriving from >> engine-devel and cc other mailing list, etc. >> _______________________________________________ >> Arch mailing list >> Arch at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/arch > > From lpeer at redhat.com Mon Jul 16 07:55:20 2012 From: lpeer at redhat.com (Livnat Peer) Date: Mon, 16 Jul 2012 10:55:20 +0300 Subject: [vdsm] Getting rid of arch@ovirt.org? In-Reply-To: <5003BC46.9040903@redhat.com> References: <66371106-0980-4506-9855-af5c24b6b051@zmail13.collab.prod.int.phx2.redhat.com> <5003482B.60406@middleswarth.net> <5003B7AF.8020409@redhat.com> <5003BB1B.8040002@redhat.com> <5003BC46.9040903@redhat.com> Message-ID: <5003C8E8.306@redhat.com> On 16/07/12 10:01, Itamar Heim wrote: > On 07/16/2012 09:56 AM, Livnat Peer wrote: >> On 16/07/12 09:41, Itamar Heim wrote: >>> On 07/16/2012 01:46 AM, Robert Middleswarth wrote: >>>> On 07/15/2012 03:59 PM, Ayal Baron wrote: >>>>> >>>>> ----- Original Message ----- >>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>> Hash: SHA1 >>>>>> >>>>>> On 07/15/2012 01:53 AM, Ayal Baron wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Sorry for cross-posting, but in this case I think it's relevant. >>>>>>> >>>>>>> The original idea was that every time we wish to discuss a new >>>>>>> cross-component feature we should do it over arch list. However, it >>>>>>> would appear that de-facto usually engine-devel and vdsm-devel are >>>>>>> being used (cross posted). Currently engine-devel has 211 >>>>>>> subscribers, arch has 160 and vdsm-devel has 128 so from this >>>>>>> perspective again, arch seems less relevant. I propose we ditch >>>>>>> arch and keep the other 2 mailing lists. I'm not sure whether new >>>>>>> cross-component features should be discussed solely on engine-devel >>>>>>> or cross-posted (there are probably people who wouldn't care about >>>>>>> engine side but would still like to know about such changes). >>>>>>> >>>>>>> Thoughts? >>>>>> - -1 >>>>>> >>>>>> I don't normally read engine-devel and vdsm-devel, so I hadn't >>>>>> noticed >>>>>> that discussions I would expect to be on arch@ are not happening >>>>>> here. >>>>>> I'm probably not the only person in that situation. >>>>>> >>>>>> If this project were 100% about Engine and VDSM, then I could >>>>>> understand your reasoning. But we've already added a few new >>>>>> incubating projects, we have subsystem teams such as documentation >>>>>> and >>>>>> infrastructure, and we all need a single location where we know we >>>>>> can >>>>>> reach *all* contributors to this project. >>>>>> >>>>>> If we try to force all that discussion on to engine-devel, not >>>>>> everyone would be interested. There is enough on engine-devel that is >>>>>> not general interest that it would become noise (as it has for me, so >>>>>> I filter it) or people would drop it all together. >>>>>> >>>>>> Perhaps what we need to do is have the discipline to cross-post *all* >>>>>> general interest discussions from the project mailing list back to >>>>>> arch@? Enforce the rule that decisions that affect the whole project >>>>>> have to be ratified on arch@ instead of whatever project list the >>>>>> discussions started on? Strongly suggest that all contributors be on >>>>>> arch@ and announce@ as a minimum? >>>>> I find that anything that should go on arch would interest anyone on >>>>> the devel lists (as it is about new features, design, etc) so I >>>>> believe that arch should have at least everyone on engine-devel and >>>>> vdsm-devel. >>>>> However, right now this is not the case as is evident by number of >>>>> subs to each list (e.g. I haven't compared to see if everyone on arch >>>>> is on engine). >>>>> So imo something needs to be done. >>>>> I'm fine with keeping arch, but as you said, that means we need to >>>>> enforce it to be *the* list for feature discussions and I'm not >>>>> exactly sure how you'd go about doing that. >>>> Maybe arch needs renamed to make it clear what if is for? >>>> >>>> Maybe something simple like ovirt-devel to make it clear it is for >>>> generally ovirt development? >>> >>> we can simply make it arch include the other mailing lists, so sending >>> to arch would be sending to all other mailing lists. >> >> What would happen if someone reply on the engine-list to a mail >> originally sent to arch? >> >> wouldn't we end-up starting a thread on arch and then loosing it to one >> of the other lists? > > reply-to is not set to reply-to-list, rather to original sender/cc list, > so shouldn't be an issue > ok so if reply to such mail de-facto I'll send a mail to the arch list - shouldn't I be register to the arch list (or I need someone to approve the mail)? >> >> >>> wouldn't resolve the dupes, but will resolve need of everyone to >>> subscribe to it as well. >>> (for dupes i also use a mail filter to delete emails arriving from >>> engine-devel and cc other mailing list, etc. >>> _______________________________________________ >>> Arch mailing list >>> Arch at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/arch >> >> > > From iheim at redhat.com Mon Jul 16 10:18:49 2012 From: iheim at redhat.com (Itamar Heim) Date: Mon, 16 Jul 2012 13:18:49 +0300 Subject: [vdsm] Getting rid of arch@ovirt.org? In-Reply-To: <5003C8E8.306@redhat.com> References: <66371106-0980-4506-9855-af5c24b6b051@zmail13.collab.prod.int.phx2.redhat.com> <5003482B.60406@middleswarth.net> <5003B7AF.8020409@redhat.com> <5003BB1B.8040002@redhat.com> <5003BC46.9040903@redhat.com> <5003C8E8.306@redhat.com> Message-ID: <5003EA89.8060206@redhat.com> On 07/16/2012 10:55 AM, Livnat Peer wrote: > On 16/07/12 10:01, Itamar Heim wrote: >> On 07/16/2012 09:56 AM, Livnat Peer wrote: >>> On 16/07/12 09:41, Itamar Heim wrote: >>>> On 07/16/2012 01:46 AM, Robert Middleswarth wrote: >>>>> On 07/15/2012 03:59 PM, Ayal Baron wrote: >>>>>> >>>>>> ----- Original Message ----- >>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>> Hash: SHA1 >>>>>>> >>>>>>> On 07/15/2012 01:53 AM, Ayal Baron wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Sorry for cross-posting, but in this case I think it's relevant. >>>>>>>> >>>>>>>> The original idea was that every time we wish to discuss a new >>>>>>>> cross-component feature we should do it over arch list. However, it >>>>>>>> would appear that de-facto usually engine-devel and vdsm-devel are >>>>>>>> being used (cross posted). Currently engine-devel has 211 >>>>>>>> subscribers, arch has 160 and vdsm-devel has 128 so from this >>>>>>>> perspective again, arch seems less relevant. I propose we ditch >>>>>>>> arch and keep the other 2 mailing lists. I'm not sure whether new >>>>>>>> cross-component features should be discussed solely on engine-devel >>>>>>>> or cross-posted (there are probably people who wouldn't care about >>>>>>>> engine side but would still like to know about such changes). >>>>>>>> >>>>>>>> Thoughts? >>>>>>> - -1 >>>>>>> >>>>>>> I don't normally read engine-devel and vdsm-devel, so I hadn't >>>>>>> noticed >>>>>>> that discussions I would expect to be on arch@ are not happening >>>>>>> here. >>>>>>> I'm probably not the only person in that situation. >>>>>>> >>>>>>> If this project were 100% about Engine and VDSM, then I could >>>>>>> understand your reasoning. But we've already added a few new >>>>>>> incubating projects, we have subsystem teams such as documentation >>>>>>> and >>>>>>> infrastructure, and we all need a single location where we know we >>>>>>> can >>>>>>> reach *all* contributors to this project. >>>>>>> >>>>>>> If we try to force all that discussion on to engine-devel, not >>>>>>> everyone would be interested. There is enough on engine-devel that is >>>>>>> not general interest that it would become noise (as it has for me, so >>>>>>> I filter it) or people would drop it all together. >>>>>>> >>>>>>> Perhaps what we need to do is have the discipline to cross-post *all* >>>>>>> general interest discussions from the project mailing list back to >>>>>>> arch@? Enforce the rule that decisions that affect the whole project >>>>>>> have to be ratified on arch@ instead of whatever project list the >>>>>>> discussions started on? Strongly suggest that all contributors be on >>>>>>> arch@ and announce@ as a minimum? >>>>>> I find that anything that should go on arch would interest anyone on >>>>>> the devel lists (as it is about new features, design, etc) so I >>>>>> believe that arch should have at least everyone on engine-devel and >>>>>> vdsm-devel. >>>>>> However, right now this is not the case as is evident by number of >>>>>> subs to each list (e.g. I haven't compared to see if everyone on arch >>>>>> is on engine). >>>>>> So imo something needs to be done. >>>>>> I'm fine with keeping arch, but as you said, that means we need to >>>>>> enforce it to be *the* list for feature discussions and I'm not >>>>>> exactly sure how you'd go about doing that. >>>>> Maybe arch needs renamed to make it clear what if is for? >>>>> >>>>> Maybe something simple like ovirt-devel to make it clear it is for >>>>> generally ovirt development? >>>> >>>> we can simply make it arch include the other mailing lists, so sending >>>> to arch would be sending to all other mailing lists. >>> >>> What would happen if someone reply on the engine-list to a mail >>> originally sent to arch? >>> >>> wouldn't we end-up starting a thread on arch and then loosing it to one >>> of the other lists? >> >> reply-to is not set to reply-to-list, rather to original sender/cc list, >> so shouldn't be an issue >> > > ok so if reply to such mail de-facto I'll send a mail to the arch list - > shouldn't I be register to the arch list (or I need someone to approve > the mail)? you would be moderated the first time you reply to it, yes. same as for all other mailing lists - not an issue usually. > > >>> >>> >>>> wouldn't resolve the dupes, but will resolve need of everyone to >>>> subscribe to it as well. >>>> (for dupes i also use a mail filter to delete emails arriving from >>>> engine-devel and cc other mailing list, etc. >>>> _______________________________________________ >>>> Arch mailing list >>>> Arch at ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/arch >>> >>> >> >> > > From mburns at redhat.com Mon Jul 16 12:20:13 2012 From: mburns at redhat.com (Mike Burns) Date: Mon, 16 Jul 2012 08:20:13 -0400 Subject: Call for Agenda Items -- oVirt Weekly Sync Meeting 2012-07-18 Message-ID: <1342441213.6902.0.camel@beelzebub.mburnsfire.net> This is the current agenda for the 2012-07-18 meeting: * Status of Next Release * Sub-project reports (engine, vdsm, node, infra) * Upcoming workshops * wiki organization (dneary) If you have additional topics to cover, please reply and I'll add them to the agenda. Thanks Mike From kwade at redhat.com Mon Jul 16 16:07:04 2012 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Mon, 16 Jul 2012 09:07:04 -0700 Subject: Moved www.orvirt.org/wiki to wiki.ovrit.org In-Reply-To: References: Message-ID: <50043C28.6040301@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/15/2012 11:10 PM, Eyal Edri wrote: > Just a small question, any reason we kept the /wiki folder when > redirecting from wiki.ovirt.org? > > e.g. http://wiki.ovirt.org/wiki/Jenkins instead of just > wiki.ovirt.org/Jenkins? MediaWiki is designed to be at /wiki regardless of the sub-domain. I've heard this asserted over the years, and my research the other showed it is still the case. It's not impossible to put the wiki at the root, but there are parts of MediaWiki that expect it at /wiki so it would introduce unknown possible troubles. At the least, we aren't any worse than e.g. wikipedia.com/wiki - it's what people see in other MediaWiki sites. - - Karsten > Eyal. > > ----- Original Message ----- >> From: "Robert Middleswarth" To: "arch" >> Sent: Monday, July 16, 2012 3:14:18 AM Subject: >> Moved www.orvirt.org/wiki to wiki.ovrit.org >> >> Over the weekend we move the wiki fromwww.ovirt.org/wiki to >> wiki.ovirt.org and add redirectswww.ovirt.org/wiki to >> wiki.ovirt.org. This will make it easier to break up the site >> into 2 servers at some point. Including quaid idea of using >> openshift to managing the wordpress and media wiki sites. >> >> Thanks Robert >> >> _______________________________________________ Arch mailing >> list Arch at ovirt.org http://lists.ovirt.org/mailman/listinfo/arch >> > _______________________________________________ Arch mailing list > Arch at ovirt.org http://lists.ovirt.org/mailman/listinfo/arch > - -- Karsten 'quaid' Wade, Sr. Analyst - Community Growth http://TheOpenSourceWay.org .^\ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFQBDwo2ZIOBq0ODEERAojrAJ9+18HUpEszFxlsu76sZv2eRdI+DACcCuXC 2V2nQU2GYKMwA666X0yk8i0= =Di00 -----END PGP SIGNATURE----- From jbrooks at redhat.com Mon Jul 16 19:34:41 2012 From: jbrooks at redhat.com (Jason Brooks) Date: Mon, 16 Jul 2012 12:34:41 -0700 Subject: All In One ISO. In-Reply-To: <50004F01.5070301@middleswarth.net> References: <50004F01.5070301@middleswarth.net> Message-ID: <50046CD1.2030807@redhat.com> On 07/13/2012 09:38 AM, Robert Middleswarth wrote: > During this weeks meeting I brought up the idea of building an All In > One ISO. The idea is it would install the OS then on first boot run you > though engine-setup with the all in one plug-in installed. This would > make it really easy for Admin to test oVirt and see if it works for them > before putting there time into building things out the correct way. > > Everyone at the meeting though it was a good idea and suggest I bring it > up in Arch to see what the group as a whole thought. I've experimented a bit with the kickstart file and command below. It makes a live-bootable image (should be installable, as well, though I haven't tested that): sudo livecd-creator --config=ovirt-live.ks --cache=cache --fslabel=ovirt-live *** lang en_US.UTF-8 keyboard us timezone US/Eastern auth --useshadow --enablemd5 selinux --enforcing firewall --disabled part / --size 7178 rootpw "" repo --name=ovirt-beta --baseurl=http://www.ovirt.org/releases/beta/fedora/$releasever repo --name=Fedora --mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch repo --name=Fedora-updates --mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=updates-released-f$releasever&arch=$basearch %packages @core anaconda-runtime bash kernel passwd policycoreutils chkconfig authconfig rootfiles ovirt-engine ovirt-engine-setup-plugin-allinone %end > > Thanks > Robert > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch -- Jason Brooks Media & Communications Open Source and Standards @ Red Hat identi.ca/jasonbrooks twitter.com/jasonbrooks From dneary at redhat.com Tue Jul 17 15:28:32 2012 From: dneary at redhat.com (Dave Neary) Date: Tue, 17 Jul 2012 08:28:32 -0700 Subject: Getting rid of arch@ovirt.org? In-Reply-To: <266239e3-dcdc-4db5-b121-f37c42052ffc@zmail13.collab.prod.int.phx2.redhat.com> References: <266239e3-dcdc-4db5-b121-f37c42052ffc@zmail13.collab.prod.int.phx2.redhat.com> Message-ID: <500584A0.4050802@redhat.com> Hi, On 07/15/2012 01:53 AM, Ayal Baron wrote: > Sorry for cross-posting, but in this case I think it's relevant. > > The original idea was that every time we wish to discuss a new cross-component feature we should do it over arch list. However, it would appear that de-facto usually engine-devel and vdsm-devel are being used (cross posted). > Currently engine-devel has 211 subscribers, arch has 160 and vdsm-devel has 128 so from this perspective again, arch seems less relevant. > I propose we ditch arch and keep the other 2 mailing lists. > I'm not sure whether new cross-component features should be discussed solely on engine-devel or cross-posted (there are probably people who wouldn't care about engine side but would still like to know about such changes). > > Thoughts? It's a tricky problem, as Karsten said. In fact, one of the questions I had when joining the list is, where do all the developers hang out? And outside of arch@ there wasn't a good answer. I'm not on vdsm-devel, neither vdsm-devel or engine-devel are mentioned at all on http://www.ovirt.org/project/community/ and like Karsten I think there is a role for a list which allows everyone to talk about topics unrelated to a specific component, but also not related to "users" who are not contributing to the project. I agree, though, that the cross-posting is an issue. It seems like I need to cross-post every message to at least 2 or 3 lists to get everyone I'm interested in reaching - this suggests to me that we have too many communication channels, and need to consolidate a little. That, or we need to help people understand which forums they should be in for which types of communications, so that we don't constantly have the problem of cross-posting to be on the safe side. That's the solution I prefer. Cheers, Dave. -- Dave Neary Community Action and Impact Open Source and Standards Team, Red Hat Phone: +33 9 50 71 55 62 From dneary at redhat.com Tue Jul 17 15:48:50 2012 From: dneary at redhat.com (Dave Neary) Date: Tue, 17 Jul 2012 08:48:50 -0700 Subject: Call for Agenda Items -- oVirt Weekly Sync Meeting 2012-07-18 In-Reply-To: <1342441213.6902.0.camel@beelzebub.mburnsfire.net> References: <1342441213.6902.0.camel@beelzebub.mburnsfire.net> Message-ID: <50058962.80000@redhat.com> Hi, On 07/16/2012 05:20 AM, Mike Burns wrote: > This is the current agenda for the 2012-07-18 meeting: > > * Status of Next Release > * Sub-project reports (engine, vdsm, node, infra) > * Upcoming workshops > * wiki organization (dneary) > > If you have additional topics to cover, please reply and I'll add them > to the agenda. I am travelling this week for OSCON, so I have limited internet availability, and I'm way outside my usual timezone. I will be lurking in IRC tomorrow at that time, but I would love to hear any questions/suggestions beforehand, and I'll give a quick summary here of where we are for the wiki & release work that's going on. * Wiki organisation I created this page to list things we need to do: http://wiki.ovirt.org/wiki/Website_organisation - some of the top priorities I have are to take care of things like consistent page naming: http://www.ovirt.org/project/community/ and orphan pages: http://wiki.ovirt.org/wiki/Special:LonelyPages - the orphan pages link looks really bad, but most of the pages there are in a category (this, however, does not count as being linked for this page - and I would like to see us explicitly linking to pages from others, grouping and structuring pages). We need to figure out what should be on the front page, how we're going to group all the information that's in the wiki already, and redo the front page to reflect that. * Release work I would really like to have some demo videos, and have created a skeleton page for the video screencasts here: http://wiki.ovirt.org/wiki/Screencasts - I identified ~10 features from the thread we had last week which we'd like to see demoed. Now I need help. Each feature needs prerequisites/set-up (things you need to do or have before you start the demo), and instructions for giving the demo. I created a template for each feature, and gave my best effort for two features (adding a new VM, and migrating a guest to a different node), but I really do not yet have the domain knowledge or experience with the project to do this work, at this point I need volunteers to help out. Once we have the features we want to test described, people can start recording the videos (we still need to figure out how to gather them, I was thinking attachments to the wiki would be fine for the time being, eventually they should end up on YouTube). And once we have the raw video, we can add voice-overs. So please help! Thanks, Dave. -- Dave Neary Community Action and Impact Open Source and Standards Team, Red Hat Phone: +33 9 50 71 55 62 From dneary at redhat.com Tue Jul 17 15:52:03 2012 From: dneary at redhat.com (Dave Neary) Date: Tue, 17 Jul 2012 08:52:03 -0700 Subject: Moved www.orvirt.org/wiki to wiki.ovrit.org In-Reply-To: <50043C28.6040301@redhat.com> References: <50043C28.6040301@redhat.com> Message-ID: <50058A23.1060308@redhat.com> Hi, On 07/16/2012 09:07 AM, Karsten 'quaid' Wade wrote: > On 07/15/2012 11:10 PM, Eyal Edri wrote: >> Just a small question, any reason we kept the /wiki folder when >> redirecting from wiki.ovirt.org? > > MediaWiki is designed to be at /wiki regardless of the sub-domain. > I've heard this asserted over the years, and my research the other > showed it is still the case. It's not impossible to put the wiki at > the root, but there are parts of MediaWiki that expect it at /wiki so > it would introduce unknown possible troubles. > > At the least, we aren't any worse than e.g. wikipedia.com/wiki - it's > what people see in other MediaWiki sites. Really? That's surprising - I thought it was a configuration parameter when installing the wiki. In MeeGo we used to have http://wiki.meego.com/Metrics (for example) with no issues I can remember. Cheers, Dave. -- Dave Neary Community Action and Impact Open Source and Standards Team, Red Hat Phone: +33 9 50 71 55 62 From kwade at redhat.com Tue Jul 17 17:10:47 2012 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Tue, 17 Jul 2012 10:10:47 -0700 Subject: Moved www.orvirt.org/wiki to wiki.ovrit.org In-Reply-To: <50058A23.1060308@redhat.com> References: <50043C28.6040301@redhat.com> <50058A23.1060308@redhat.com> Message-ID: <50059C97.9060208@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/17/2012 08:52 AM, Dave Neary wrote: > Hi, > > On 07/16/2012 09:07 AM, Karsten 'quaid' Wade wrote: >> On 07/15/2012 11:10 PM, Eyal Edri wrote: >>> Just a small question, any reason we kept the /wiki folder >>> when redirecting from wiki.ovirt.org? >> >> MediaWiki is designed to be at /wiki regardless of the >> sub-domain. I've heard this asserted over the years, and my >> research the other showed it is still the case. It's not >> impossible to put the wiki at the root, but there are parts of >> MediaWiki that expect it at /wiki so it would introduce unknown >> possible troubles. >> >> At the least, we aren't any worse than e.g. wikipedia.com/wiki - >> it's what people see in other MediaWiki sites. > > Really? That's surprising - I thought it was a configuration > parameter when installing the wiki. In MeeGo we used to have > http://wiki.meego.com/Metrics (for example) with no issues I can > remember. I think I've done that configuration before, but it was a while ago. I read this article: http://www.mediawiki.org/wiki/Manual:Wiki_in_site_root_directory and am familiar with this one: http://www.mediawiki.org/wiki/Manual:Short_URL In general, I try to follow what MediaWiki recommends, and look to their flagship Wikipedia for best practice on how to do articles, names, etc. But they are largely recommendations, we can do what we want. A few considerations: * Can we make that wiki at webroot work on OpenShift? * Does wiki at webroot put us in a corner where we have to carefully upgrade each time so we don't break our URL scheme? Personally, I like clean, short, friendly URLs, and have always been bothered by having to use /wiki (or /w), but I haven't researched enough to know if I would be tilting at windmills to remove it, or just doing a configuration choice. - - Karsten - -- Karsten 'quaid' Wade, Sr. Analyst - Community Growth http://TheOpenSourceWay.org .^\ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFQBZyX2ZIOBq0ODEERAkpkAJ9Fm70CyaP+XrQB2X6Ufp9xK3Ax4ACg42S6 VS8kTrUrzTQNtZKKVuuI8xY= =TkUo -----END PGP SIGNATURE----- From dneary at redhat.com Tue Jul 17 17:45:41 2012 From: dneary at redhat.com (Dave Neary) Date: Tue, 17 Jul 2012 10:45:41 -0700 Subject: Looking for help: Demo videos Message-ID: <5005A4C5.20409@redhat.com> Hi everyone, Last week I pitched the idea of having some demo videos (I called them "screencasts" although that's not quite accurate) ready before the 3.1 release next week. I don't have the domain knowledge to do this myself, so I need your help! What is there to do? 1. Go to http://wiki.ovirt.org/wiki/Screencasts - have a look at the features I've proposed for the first round of videos. If you really think one of them shouldn't be there, or there's a really important feature you'd like to see a demo for, please reply here and we'll discuss it. You can always add a proposed feature with the skeleton template to the Screencasts page also, but there's no guarantee we'll have a video by the time the release comes around. It would helkp me prioritise if we could gather feedback here. 2. For each feature, we should have a scenario/script for the demo, including: * Required pre-requisites and set-up (what do I need to do before I start the demo) * A step by step description of how to show the feature being demoed Right now, only two features are described, and those descriptions may need work. If you see a feature which is not yet described, and you know how to use it, please add a little script following the template. If you see a feature which is not described well enough, please update the description. 3. For each feature with a script, we need a video. I have started a page to help people record videos of their screen, for the systems I know about: http://wiki.ovirt.org/wiki/Recording_video - the videos (without sound) can, I think, be attached to the wiki page - ogv or webm format preferably, please! 4. For each video, we will need a sound-track. I'm happy to voice over some of the videos, but again, it would be nice to spread the load. We're not even here yet, though. Thanks everyone for your help! It will be greatly appreciated. Regards, Dave. -- Dave Neary Community Action and Impact Open Source and Standards Team, Red Hat Phone: +33 9 50 71 55 62 From robert at middleswarth.net Tue Jul 17 21:13:09 2012 From: robert at middleswarth.net (Robert Middleswarth) Date: Tue, 17 Jul 2012 17:13:09 -0400 Subject: Moved www.orvirt.org/wiki to wiki.ovrit.org In-Reply-To: <50058A23.1060308@redhat.com> References: <50043C28.6040301@redhat.com> <50058A23.1060308@redhat.com> Message-ID: <5005D565.8000509@middleswarth.net> On 07/17/2012 11:52 AM, Dave Neary wrote: > Hi, > > On 07/16/2012 09:07 AM, Karsten 'quaid' Wade wrote: >> On 07/15/2012 11:10 PM, Eyal Edri wrote: >>> Just a small question, any reason we kept the /wiki folder when >>> redirecting from wiki.ovirt.org? >> >> MediaWiki is designed to be at /wiki regardless of the sub-domain. >> I've heard this asserted over the years, and my research the other >> showed it is still the case. It's not impossible to put the wiki at >> the root, but there are parts of MediaWiki that expect it at /wiki so >> it would introduce unknown possible troubles. >> >> At the least, we aren't any worse than e.g. wikipedia.com/wiki - it's >> what people see in other MediaWiki sites. > > Really? That's surprising - I thought it was a configuration parameter > when installing the wiki. In MeeGo we used to have > http://wiki.meego.com/Metrics (for example) with no issues I can > remember. > > Cheers, > Dave. > It didn't look that closely. I was working on a live system we don't have a staging system so I didn't what to have the site down to long well moving things. My biggest concern was breakage so leaving the /wiki in was the safer option. Thanks Robert From treydock at gmail.com Thu Jul 5 23:02:21 2012 From: treydock at gmail.com (Trey Dockendorf) Date: Thu, 5 Jul 2012 18:02:21 -0500 Subject: [Users] What is it going to take to get EL6 builds? In-Reply-To: <4FF60F8C.3010004@middleswarth.net> References: <4FF60F8C.3010004@middleswarth.net> Message-ID: On Jul 5, 2012 5:05 PM, "Robert Middleswarth" wrote: > > I know there are a few things that don't work under oVirt on EL6 but there are unofficial builds out there and they seem to work pretty well. > > What is the major stopper from getting EL6 builds? Is it just a mater of getting patches submitted for building the spec files? Is there a need for EL 6 based slaves? Is there a concern about the features that don't work like Live Migration? > > I guess a good starting point is to build a todo list of what has to be done. > > Thanks > Robert > _______________________________________________ > Users mailing list > Users at ovirt.org > http://lists.ovirt.org/mailman/listinfo/users Based on personal attempts to rebuild ovirt for EL6 the biggest hurdle I ran into is build dependencies. Thanks to the help of Dreyou Im using the work around of a binary download of Maven and packages from jpackage repo. Ive built latest vdsm without much issue and am setting up my mock environment to rebuild the latest ovirt-engine release. Before Dreyou's repo I spent considerable time attempting to rebuild Fedora SRPMs in EL6 to meet all dependencies but there were numerous circular dependency issues building maven2 in EL6. This was before 3.1 and have not attempted a full dependency build since. Id be interested in knowing what other challenges exist for an EL6 release and would like to help where I can. - Trey -------------- next part -------------- An HTML attachment was scrubbed... URL: From mburns at redhat.com Wed Jul 11 13:49:22 2012 From: mburns at redhat.com (Mike Burns) Date: Wed, 11 Jul 2012 09:49:22 -0400 (EDT) Subject: oVirt Weekly Meeting Message-ID: <947193da-c5a2-446e-8a4c-2e6d9d2d0a5b@zmail17.collab.prod.int.phx2.redhat.com> The following meeting has been modified: Subject: oVirt Weekly Meeting Organizer: "Mike Burns" Location: #ovirt of oftc.net Time: 10:00:00 AM - 11:00:00 AM GMT -05:00 US/Canada Eastern [MODIFIED] Recurrence : Every 1 week(s) on No end date Effective Apr 25, 2012 Required: danken at redhat.com; oschreib at redhat.com; ykaul at redhat.com; sgordon at redhat.com; dfediuck at redhat.com; Jon.Benedict at netapp.com; pmyers at redhat.com; simon at redhat.com; imad.sousou at intel.com; aliguori at us.ibm.com; lhawthor at redhat.com ... Optional: arch at ovirt.org; board at ovirt.org; menescu at cisco.com *~*~*~*~*~*~*~*~*~* Weekly Sync Meeting for the oVirt Project * This meeting will take place at 10:00 AM EDT and follow US DST. * A call for agenda items will be sent out weekly on Monday or Tuesday Standing Agenda items: * Next Release status * Sub-Project report Required Attendees: * The maintainer or a delegate from each of the core projects (node, engine, vdsm) * Docs representative * QE Representative * Release Manager * Anyone who proposes a topic for discussion for the meeting -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: meeting.ics Type: text/calendar Size: 10087 bytes Desc: not available URL: From oschreib at redhat.com Wed Jul 25 15:34:40 2012 From: oschreib at redhat.com (Ofer Schreiber) Date: Wed, 25 Jul 2012 11:34:40 -0400 (EDT) Subject: Update on oVirt 3.1 Release Date In-Reply-To: <1229993976.3523160.1343230064866.JavaMail.root@redhat.com> Message-ID: <1883854849.3524688.1343230480343.JavaMail.root@redhat.com> Due to some critical issues that are still outstanding, we've decided to delay the release of oVirt 3.1 by 2 weeks. We are now targeting 2012-08-08 for the release. For details on the issues currently blocking the release, please see the bugs listed here[1]. Thanks, Ofer Schreiber oVirt Release Manager [1] https://bugzilla.redhat.com/showdependencytree.cgi?id=822145&hide_resolved=1 From robert at middleswarth.net Sun Jul 29 20:25:55 2012 From: robert at middleswarth.net (Robert Middleswarth) Date: Sun, 29 Jul 2012 16:25:55 -0400 Subject: Outage :: jenkins.ovirt.org :: 2012-07-29 2300 to 2400 UTC (7 pm EDT/4 pm PDT) In-Reply-To: <4FFF7960.7000300@redhat.com> References: <4FFF7960.7000300@redhat.com> Message-ID: <50159C53.3030502@middleswarth.net> With the recent release of Jenkins 1.466.1 we are now two version behind on the Jenkins builds. I am going to apply all update to jenkins.ovirt.org. This will require taking the build server offline for up to an hour. I will stop all new builds at 7:00 PM and allow any that are running to complete. Then I will do a full backup and run all updates. == When == 2300 to 2400 UTC date -d "2012-07-29 2300 UTC" == Affected services == Jenkins.ovirt.org -- Thanks Robert Middleswarth @rmiddle (twitter/IRC) From robert at middleswarth.net Mon Jul 30 03:13:09 2012 From: robert at middleswarth.net (Robert Middleswarth) Date: Sun, 29 Jul 2012 23:13:09 -0400 Subject: Outage :: jenkins.ovirt.org :: 2012-07-29 2300 to 2400 UTC (7 pm EDT/4 pm PDT) In-Reply-To: <50159C53.3030502@middleswarth.net> References: <4FFF7960.7000300@redhat.com> <50159C53.3030502@middleswarth.net> Message-ID: <5015FBC5.9080101@middleswarth.net> On 07/29/2012 04:25 PM, Robert Middleswarth wrote: > With the recent release of Jenkins 1.466.1 we are now two version > behind on the Jenkins builds. I am going to apply all update to > jenkins.ovirt.org. This will require taking the build server offline > for up to an hour. I will stop all new builds at 7:00 PM and allow > any that are running to complete. Then I will do a full backup and > run all updates. > > == When == > 2300 to 2400 UTC > date -d "2012-07-29 2300 UTC" > > == Affected services == > Jenkins.ovirt.org > It took longer then expected in part because a build had to finish before I could start the backup that was close to an hour. Then backup also took 40 Min. The actually downtime was kept to under 30 min. -- Thanks Robert Middleswarth @rmiddle (twitter/IRC) From kwade at redhat.com Mon Jul 30 17:04:48 2012 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Mon, 30 Jul 2012 10:04:48 -0700 Subject: Outage :: jenkins.ovirt.org :: 2012-07-29 2300 to 2400 UTC (7 pm EDT/4 pm PDT) In-Reply-To: <5015FBC5.9080101@middleswarth.net> References: <4FFF7960.7000300@redhat.com> <50159C53.3030502@middleswarth.net> <5015FBC5.9080101@middleswarth.net> Message-ID: <5016BEB0.9030204@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/29/2012 08:13 PM, Robert Middleswarth wrote: > On 07/29/2012 04:25 PM, Robert Middleswarth wrote: >> With the recent release of Jenkins 1.466.1 we are now two >> version behind on the Jenkins builds. I am going to apply all >> update to jenkins.ovirt.org. This will require taking the build >> server offline for up to an hour. I will stop all new builds at >> 7:00 PM and allow any that are running to complete. Then I will >> do a full backup and run all updates. >> >> == When == 2300 to 2400 UTC date -d "2012-07-29 2300 UTC" >> >> == Affected services == Jenkins.ovirt.org >> > It took longer then expected in part because a build had to finish > before I could start the backup that was close to an hour. Then > backup also took 40 Min. The actually downtime was kept to under > 30 min. Looks great, thanks. - - Karsten - -- Karsten 'quaid' Wade, Sr. Analyst - Community Growth http://TheOpenSourceWay.org .^\ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFQFr6w2ZIOBq0ODEERAnwtAKDela8NpdXar/awPBO3dtG2brVmtACgliz1 lm/tQsl2Alg6eCxm9PvYlNo= =nd8F -----END PGP SIGNATURE-----