From vincent at vanderkussen.org Tue Mar 5 20:59:12 2013 From: vincent at vanderkussen.org (Vincent Van der Kussen) Date: Tue, 5 Mar 2013 21:59:12 +0100 Subject: Concerning Loadays 2013 In-Reply-To: <511B7B8B.6050303@redhat.com> References: <20121205224626.15444l2co26x8k36@horde.vanderkussen.org> <50CB3D3B.1040205@redhat.com> <20121215094410.GB3314@faramir.homebase.local> <50D0EEF5.6030303@redhat.com> <20130116203816.GA29953@faramir.homebase.local> <511B7B8B.6050303@redhat.com> Message-ID: <20130305205912.GA26318@faramir.homebase.local> Hi all, Depending on my workload i might submit something myself. I'll keep you posted. Vincent. On Wed, Feb 13, 2013 at 12:39:55PM +0100, Dave Neary wrote: > Hi everyone, > > This invitation is still outstanding, and I would love to see an > oVirt presentation at the conference. > > Unfortunately, I am already sure I will not be able to attend, the > dates do not work for me. > > So I am looking for a brave volunteer in Europe, preferably near > Antwerp, to give a presentation on oVirt for an audience of > sysadmins and DevOps. I'll be happy to help you with the slides and > the presentation content beforehand! > > Please let me know (on list preferably, but off list if you're shy > and I'll let people know here I have a volunteer) before the > opportunity passes us by. > > Vincent, thank you for your patience! > > Regards, > Dave. > > > On 01/16/2013 09:38 PM, Vincent Van der Kussen wrote: > >On Wed, Dec 19, 2012 at 12:32:21AM +0200, Itamar Heim wrote: > >>On 12/15/2012 11:44 AM, Vincent Van der Kussen wrote: > >>>On Fri, Dec 14, 2012 at 03:52:43PM +0100, Dave Neary wrote: > >>> > >>>Hi, > >>> > >>> > >>>>Hi, > >>>> > >>>>I would love to see us have a speaker at this conference. > >>>> > >>>>Vincent, what is the level of the audience usually? Would the > >>>>audience be more interested in an "overview of oVirt"? or more > >>>>community outreach ("how to get involved")? > >>> > >>>Most people are active in several open source projects and have a technical background. > >>>So a more in depth and practical overview + how to participate in the oVirt community would cover it. > >>>There's always place (depending on the other talks/workshops of course) to do a workshop to show > >>>the technical/practical side of oVirt. > >>> > >>>I think most people would like to know more about how oVirt handles storage, networking, does Gluster work?, etc.. > >>>> > >>>>I can think of a few potential speakers, if they're willing to > >>>>try... Ewoud is the nearest community member to Brussels, but I am > >>>>also very close. > >>>> > >>>>When is the deadline for proposals? > >>> > >>>Deadline is arounf 1st of March. > >>> > >>>If you have any further questions you can always contact me. > >> > >>sounds interesting, are you looking for 1-2 sessions, or more than > >>that (intro, arch, ovirt-live hands-on session, etc.)? > >> > >>thanks, > >> Itamar > > > >Hi, > > > >FYI : the CFP is open until mid of March. > >info at http://www.loadays.org > > > >Regards, > >Vincent > > > >> > >> > > -- > Dave Neary - Community Action and Impact > Open Source and Standards, Red Hat - http://community.redhat.com > Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13 From dneary at redhat.com Wed Mar 6 10:28:48 2013 From: dneary at redhat.com (Dave Neary) Date: Wed, 06 Mar 2013 11:28:48 +0100 Subject: CentOS 6 repo for oVirt In-Reply-To: <512E7F4C.4050604@redhat.com> References: <512CC9B1.9020500@centos.org> <512E7F4C.4050604@redhat.com> Message-ID: <51371A60.5080305@redhat.com> Hi Itamar, On 02/27/2013 10:49 PM, Itamar Heim wrote: > we are working on making the ovirt repo compatible with .el6 "out of the > box", and probably generate nightly .el6 rpms like we do for fedora > today. so hopefully other than the various deps you've mentioned, gap > for the distro should be minimal. Can you (or someone else) give some insight into the issues which are delaying the release of .el6 packages? I would love to know when we can expect "official" .el6 packages. Thanks! Dave. -- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13 From jhernand at redhat.com Wed Mar 6 10:47:09 2013 From: jhernand at redhat.com (Juan Hernandez) Date: Wed, 06 Mar 2013 11:47:09 +0100 Subject: CentOS 6 repo for oVirt In-Reply-To: <51371A60.5080305@redhat.com> References: <512CC9B1.9020500@centos.org> <512E7F4C.4050604@redhat.com> <51371A60.5080305@redhat.com> Message-ID: <51371EAD.2030407@redhat.com> On 03/06/2013 11:28 AM, Dave Neary wrote: > Hi Itamar, > > On 02/27/2013 10:49 PM, Itamar Heim wrote: >> we are working on making the ovirt repo compatible with .el6 "out of the >> box", and probably generate nightly .el6 rpms like we do for fedora >> today. so hopefully other than the various deps you've mentioned, gap >> for the distro should be minimal. > > Can you (or someone else) give some insight into the issues which are > delaying the release of .el6 packages? I would love to know when we can > expect "official" .el6 packages. > > Thanks! > Dave. > The patches to simplify the .el6 build are already merged in the master branch, and are back-ported and ready for review and test in the 3.2 branch: http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:engine_3.2+topic:el6_build,n,z If I understood it correctly in the last weekly meeting (see [1]) it was agreed to make a new minor 3.2.1 release containing some bug fixes and these back-ported patches, so that the .el6 build will be possible/easier. Mike, Ofer, what should be the next step towards this 3.2.1 minor release? [1] http://resources.ovirt.org/meetings/ovirt/2013/ovirt.2013-02-27-15.00.txt * AGREED: makes sense to coordinate the engine f18 refresh with el6 release (as 3.2.1) (mburns, 15:53:21) -- Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3?D, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L. From mburns at redhat.com Wed Mar 6 11:37:37 2013 From: mburns at redhat.com (Mike Burns) Date: Wed, 06 Mar 2013 06:37:37 -0500 Subject: Feature Request for oVirt 3.3 Release Message-ID: <51372A81.4060409@redhat.com> Hi Everyone, It's that time again. Please create feature pages and update the 3.3 Release Tracking site [1] with features planned for the 3.3 release. This page will help to make sure that we highlight the major features for the 3.3 release as well as keep track of progress of the features throughout the release cycle. Thanks Mike [1] http://www.ovirt.org/OVirt_3.3_release-management From mburns at redhat.com Wed Mar 6 11:42:25 2013 From: mburns at redhat.com (Mike Burns) Date: Wed, 06 Mar 2013 06:42:25 -0500 Subject: Point of Contact for each Sub Project for 3.3 Message-ID: <51372BA1.4000208@redhat.com> Hi all, As part of the release process, I'd like to make sure that each sub-project is represented on the weekly meetings. This means having someone available on the meeting to give status updates and take action items for the team. The group of contacts will be responsible for getting the release out on time and making sure everything is done that needs to be done. It also allows the person coordinating the entire release to know who to talk to for a specific component. Please reply to this email with the point of contact for each sub-project. Thanks Mike From mburns at redhat.com Wed Mar 6 11:42:57 2013 From: mburns at redhat.com (Mike Burns) Date: Wed, 06 Mar 2013 06:42:57 -0500 Subject: Point of Contact for each Sub Project for 3.3 In-Reply-To: <51372BA1.4000208@redhat.com> References: <51372BA1.4000208@redhat.com> Message-ID: <51372BC1.4040802@redhat.com> On 03/06/2013 06:42 AM, Mike Burns wrote: > Hi all, > > As part of the release process, I'd like to make sure that each > sub-project is represented on the weekly meetings. This means having > someone available on the meeting to give status updates and take action > items for the team. The group of contacts will be responsible for > getting the release out on time and making sure everything is done that > needs to be done. It also allows the person coordinating the entire > release to know who to talk to for a specific component. > > Please reply to this email with the point of contact for each sub-project. > Node: Mike Burns > Thanks > > Mike > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch From mburns at redhat.com Wed Mar 6 11:54:14 2013 From: mburns at redhat.com (Mike Burns) Date: Wed, 06 Mar 2013 06:54:14 -0500 Subject: Proposal: Reorganization of the Project Management Message-ID: <51372E66.9060703@redhat.com> After having coordinated the 3.2 release with questionable success, I have some thoughts on the ways to do this better going forward. I brought this up on the meeting last week, and was supposed to follow up quickly on list with the proposal, so here it is. 1. We need to have a group of stakeholders from each of the projects/components in the our release that will make up the release committee. 2. Members of that group should be available on the weekly meeting or have someone else on the team fill in for them 3. There should be someone that is in charge of this group of stakeholders with a preference for someone that is not tied to any one sub-project.[1] 4. The person who leads the committee should run the weekly meeting 5. The person who leads the committee should track docs, publicity, marketing, etc I've already sent out a request for people from each of the sub-projects for the 3.3 release. I will continue to run the weekly meeting until we find someone to take on that role, but I feel that I'm not the right person to do this long term. If you have thoughts on who could fill the leadership role or wish to volunteer yourself, please reply to this email. Thanks Mike [1] If there isn't someone from the community who is not tied to a sub-project, then elect someone from group on a per-release basis. From dneary at redhat.com Wed Mar 6 15:29:27 2013 From: dneary at redhat.com (Dave Neary) Date: Wed, 06 Mar 2013 16:29:27 +0100 Subject: Proposal: Reorganization of the Project Management In-Reply-To: <51372E66.9060703@redhat.com> References: <51372E66.9060703@redhat.com> Message-ID: <513760D7.6000907@redhat.com> Hi Mike, On 03/06/2013 12:54 PM, Mike Burns wrote: > After having coordinated the 3.2 release with questionable success, I > have some thoughts on the ways to do this better going forward. I > brought this up on the meeting last week, and was supposed to follow up > quickly on list with the proposal, so here it is. I also have some thoughts on general release process and improving it, and have discussed this a little bit with Moran already. > 1. We need to have a group of stakeholders from each of the > projects/components in the our release that will make up the release > committee. > 2. Members of that group should be available on the weekly meeting or > have someone else on the team fill in for them > 3. There should be someone that is in charge of this group of > stakeholders with a preference for someone that is not tied to any one > sub-project.[1] > 4. The person who leads the committee should run the weekly meeting > 5. The person who leads the committee should track docs, publicity, > marketing, etc My fear with this type of scheme is that the weekly meetings will continue to be a focal point, to the detriment of getting engagement from the community to get a release out the door (with everything that entails, including docs, release notes, marketing and promotion, packaging, translations...). > If you have thoughts on who could fill the leadership role or wish to > volunteer yourself, please reply to this email. Perhaps more important than the person is that we agree on the process for getting releases, and that we get buy-in into that process. I have previously mentioned GNOME as a good example for a release process: GNOME release process: https://live.gnome.org/ReleasePlanning This process talks only about time - if you want to release on date X, you need a code freeze at X-4 days, a string freeze at X-3 weeks, etc. It does not describe the frenzy of release-related activity that happens after these freezes, or the branching policy that most projects have. For example, after the string freeze, translators and documentation people kick into high gear. After the UI freeze, we start taking screenshots for release notes and doing screencasts. After the feature freeze, the release team starts hammering home the release blocker bugs for the release, and we increase the emphasis on integration testing. Another nice GNOME feature is the feature proposal period, when features are proposed and discussed on the developer mailing list, and then prioritised by the release team. I think we could mix and match this nicely with a roadmap process like the one I proposed previously here: http://blogs.gnome.org/bolsh/2011/02/07/drawing-up-a-roadmap/ In fact, I don't think GNOME's branching policy is terribly good - development happens on trunk through to the release, and then a release branch is made. I would prefer to see release branches made when the code freezes (or even feature freeze) comes in, to allow people to continue committing complete but too-late-for-release features to trunk. Max Kanat-Alexander from Bugzilla wrote about the value of doing things like this, even though it makes life harder for the core team: http://www.codesimplicity.com/post/open-source-community-simplified/ There's an extended mailing list thread on the subject: https://groups.google.com/d/topic/mozilla.dev.apps.bugzilla/Ug9aoykXpRc/discussion In brief: when you freeze, you lose non-professional developers who just stop working on the project until after the release. So it's worthwhile keeping the trunk open, and doing your feature & code freezes on a release branch. Here's a link on the value of timeboxed feature planning and having a hard go/no go for features that get in or don't (especially the advice close to the end): http://www.joelonsoftware.com/items/2007/10/26.html In short, you prioritise features, and start working on the most important ones, and then the ones that are not ready to ship by feature freeze get deferred to the next feature prioritisation discussion. General advice based on my experience with oVirt: * I recommend a 6 month cadence with ~4 months feature development and ~2 months release preparation * Ensure that documentation, release marketing and website updates are included in the release plan * Move regular release prep to arch@ - the weekly meeting hasn't been effective to getting people engaged in the release process. The real-time meetings will be good for the release team you've proposed to sync up and agree on what the blocker bugs are, but you really need to have people reading those threads and prioritising their work to align with that * Make regular point releases (alpha, beta 1, beta 2, RC1, whatever they're called) before and after a release. I'm looking forward to 3.2.1! * Avoid tying oVirt releases to a specific release of an operating system (be it RHEL 7 or F18). I know that F18 was a special case and complicated things because of significant platform changes, but we still need to support F17 and CentOS 6.3/4 for this release, and hopefully next release we'll also be adding Debian & Ubuntu support. I would love to hear feedback/see how we can ensure that all this happens for this coming release. Step 1 is to prioritise the feature requests we gathered from the community (and from the oVirt team) and say what we would like to achieve with the 3.3 release and beyond. Cheers, Dave. -- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13 From mgoldboi at redhat.com Wed Mar 6 15:32:39 2013 From: mgoldboi at redhat.com (Moran Goldboim) Date: Wed, 06 Mar 2013 17:32:39 +0200 Subject: Point of Contact for each Sub Project for 3.3 In-Reply-To: <51372BC1.4040802@redhat.com> References: <51372BA1.4000208@redhat.com> <51372BC1.4040802@redhat.com> Message-ID: <51376197.1000506@redhat.com> On 03/06/2013 01:42 PM, Mike Burns wrote: > On 03/06/2013 06:42 AM, Mike Burns wrote: >> Hi all, >> >> As part of the release process, I'd like to make sure that each >> sub-project is represented on the weekly meetings. This means having >> someone available on the meeting to give status updates and take action >> items for the team. The group of contacts will be responsible for >> getting the release out on time and making sure everything is done that >> needs to be done. It also allows the person coordinating the entire >> release to know who to talk to for a specific component. >> >> Please reply to this email with the point of contact for each >> sub-project. >> > > Node: Mike Burns Moran Goldboim ovirt-engine-setup/ all-in-one ovirt-iso-uploader ovirt-image-uploader ovirt-log-collector > >> Thanks >> >> Mike >> _______________________________________________ >> 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 From mburns at redhat.com Wed Mar 6 19:06:39 2013 From: mburns at redhat.com (Mike Burns) Date: Wed, 06 Mar 2013 14:06:39 -0500 Subject: Proposal: Reorganization of the Project Management In-Reply-To: <513760D7.6000907@redhat.com> References: <51372E66.9060703@redhat.com> <513760D7.6000907@redhat.com> Message-ID: <513793BF.2090005@redhat.com> On 03/06/2013 10:29 AM, Dave Neary wrote: > Hi Mike, > > On 03/06/2013 12:54 PM, Mike Burns wrote: >> After having coordinated the 3.2 release with questionable success, I >> have some thoughts on the ways to do this better going forward. I >> brought this up on the meeting last week, and was supposed to follow up >> quickly on list with the proposal, so here it is. > > I also have some thoughts on general release process and improving it, > and have discussed this a little bit with Moran already. > >> 1. We need to have a group of stakeholders from each of the >> projects/components in the our release that will make up the release >> committee. >> 2. Members of that group should be available on the weekly meeting or >> have someone else on the team fill in for them >> 3. There should be someone that is in charge of this group of >> stakeholders with a preference for someone that is not tied to any one >> sub-project.[1] >> 4. The person who leads the committee should run the weekly meeting >> 5. The person who leads the committee should track docs, publicity, >> marketing, etc > > My fear with this type of scheme is that the weekly meetings will > continue to be a focal point, to the detriment of getting engagement > from the community to get a release out the door (with everything that > entails, including docs, release notes, marketing and promotion, > packaging, translations...). We don't necessarily have to concentrate the work on the weekly meeting. It can be organized however people want. I do strongly believe that we need *some* organization around a Project Manager and group or committee of people that are involved with each of the sub-projects. One of my big takeaways from 3.2 was that I had trouble reaching people for some of the projects. Having this sort of committee approach where each sub-project has a representative and designated contact can alleviate that problem. Having a person who essentially chairs that committee is essential, so there is a single person who has a view into the overall release and all the parts and is responsible for making sure all the projects and release related things get done. I think it's important that they be disconnected from one sub-project, but that's not a requirement. I think that coordinating everything that goes into the release is too big a job to do well while also working closely with a sub-project. > >> If you have thoughts on who could fill the leadership role or wish to >> volunteer yourself, please reply to this email. > > Perhaps more important than the person is that we agree on the process > for getting releases, and that we get buy-in into that process. > > I have previously mentioned GNOME as a good example for a release process: > > GNOME release process: https://live.gnome.org/ReleasePlanning > > This process talks only about time - if you want to release on date X, > you need a code freeze at X-4 days, a string freeze at X-3 weeks, etc. > It does not describe the frenzy of release-related activity that happens > after these freezes, or the branching policy that most projects have. > For example, after the string freeze, translators and documentation > people kick into high gear. After the UI freeze, we start taking > screenshots for release notes and doing screencasts. After the feature > freeze, the release team starts hammering home the release blocker bugs > for the release, and we increase the emphasis on integration testing.dne We can certainly base our process on this time based approach. I think we tried to do this initially. We need to work out what the right timeframes are for oVirt though. How much time do we need between freeze and RC and GA, etc? Some of those can be estimated now that we've done a few releases, but they should probably be discussed. > > Another nice GNOME feature is the feature proposal period, when features > are proposed and discussed on the developer mailing list, and then > prioritised by the release team. I think we could mix and match this > nicely with a roadmap process like the one I proposed previously here: > http://blogs.gnome.org/bolsh/2011/02/07/drawing-up-a-roadmap/ > > In fact, I don't think GNOME's branching policy is terribly good - > development happens on trunk through to the release, and then a release > branch is made. I would prefer to see release branches made when the > code freezes (or even feature freeze) comes in, to allow people to > continue committing complete but too-late-for-release features to trunk. > > Max Kanat-Alexander from Bugzilla wrote about the value of doing things > like this, even though it makes life harder for the core team: > > http://www.codesimplicity.com/post/open-source-community-simplified/ > > There's an extended mailing list thread on the subject: > > https://groups.google.com/d/topic/mozilla.dev.apps.bugzilla/Ug9aoykXpRc/discussion > > > In brief: when you freeze, you lose non-professional developers who just > stop working on the project until after the release. So it's worthwhile > keeping the trunk open, and doing your feature & code freezes on a > release branch. Agree completely. This is why we branch where we do. I would argue strongly against moving the branching to later in the cycle. > > > Here's a link on the value of timeboxed feature planning and having a > hard go/no go for features that get in or don't (especially the advice > close to the end): > > http://www.joelonsoftware.com/items/2007/10/26.html > > In short, you prioritise features, and start working on the most > important ones, and then the ones that are not ready to ship by feature > freeze get deferred to the next feature prioritisation discussion. I'm perfectly happy to go to a more structured feature process. The one we have now is a bit too open, for my tastes. > > > General advice based on my experience with oVirt: > * I recommend a 6 month cadence with ~4 months feature development and > ~2 months release preparation Agree in general, but not willing to make that call. > * Ensure that documentation, release marketing and website updates are > included in the release plan Agreed > * Move regular release prep to arch@ - the weekly meeting hasn't been > effective to getting people engaged in the release process. The > real-time meetings will be good for the release team you've proposed to > sync up and agree on what the blocker bugs are, but you really need to > have people reading those threads and prioritising their work to align > with that Needs discussion. I'm not sure giving up the meeting is the right step, but making this more continuous rather than in weekly increments is an admirable goal. I think we should figure out what the right pieces are for arch vs the weekly meeting. > * Make regular point releases (alpha, beta 1, beta 2, RC1, whatever > they're called) before and after a release. I'm looking forward to 3.2.1! Not sure I agree with this. I do this for critical issues with ovirt-node, but I hesitate to say "regular" point releases. As needed, yes, but not regular. I'm all for having an alpha early in the cycle and official beta and RC releases. > * Avoid tying oVirt releases to a specific release of an operating > system (be it RHEL 7 or F18). I know that F18 was a special case and > complicated things because of significant platform changes, but we still > need to support F17 and CentOS 6.3/4 for this release, and hopefully > next release we'll also be adding Debian & Ubuntu support. Agreed, no tying it to a specific release/distro. I'm bought in on that, but there was push back when I tried to get it even on F17 and F18. > > I would love to hear feedback/see how we can ensure that all this > happens for this coming release. Step 1 is to prioritise the feature > requests we gathered from the community (and from the oVirt team) and > say what we would like to achieve with the 3.3 release and beyond. > > Cheers, > Dave. > Just an observation -- Dave is more concentrated on the "how" of the release, while I was more focused on the "who" aspect. They're both certainly related, and both very important. Thanks Mike From vfeenstr at redhat.com Thu Mar 7 11:31:30 2013 From: vfeenstr at redhat.com (Vinzenz Feenstra) Date: Thu, 07 Mar 2013 12:31:30 +0100 Subject: Point of Contact for each Sub Project for 3.3 In-Reply-To: <51376197.1000506@redhat.com> References: <51372BA1.4000208@redhat.com> <51372BC1.4040802@redhat.com> <51376197.1000506@redhat.com> Message-ID: <51387A92.9030705@redhat.com> On 03/06/2013 04:32 PM, Moran Goldboim wrote: > On 03/06/2013 01:42 PM, Mike Burns wrote: >> On 03/06/2013 06:42 AM, Mike Burns wrote: >>> Hi all, >>> >>> As part of the release process, I'd like to make sure that each >>> sub-project is represented on the weekly meetings. This means having >>> someone available on the meeting to give status updates and take action >>> items for the team. The group of contacts will be responsible for >>> getting the release out on time and making sure everything is done that >>> needs to be done. It also allows the person coordinating the entire >>> release to know who to talk to for a specific component. >>> >>> Please reply to this email with the point of contact for each >>> sub-project. >>> >> >> Node: Mike Burns > > Moran Goldboim > ovirt-engine-setup/ all-in-one > ovirt-iso-uploader > ovirt-image-uploader > ovirt-log-collector ovirt-guest-agent: Vinzenz Feenstra (vfeenstr/evilissimo) > >> >>> Thanks >>> >>> Mike >>> _______________________________________________ >>> 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 > > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch -- Regards, Vinzenz Feenstra | Senior Software Engineer RedHat Engineering Virtualization R & D Phone: +420 532 294 625 IRC: vfeenstr or evilissimo Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com From dfediuck at redhat.com Thu Mar 7 11:42:37 2013 From: dfediuck at redhat.com (Doron Fediuck) Date: Thu, 7 Mar 2013 06:42:37 -0500 (EST) Subject: Point of Contact for each Sub Project for 3.3 In-Reply-To: <51372BA1.4000208@redhat.com> Message-ID: <1964537144.16213641.1362656557456.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Mike Burns" > To: "arch" > Sent: Wednesday, March 6, 2013 1:42:25 PM > Subject: Point of Contact for each Sub Project for 3.3 > > Hi all, > > As part of the release process, I'd like to make sure that each > sub-project is represented on the weekly meetings. This means having > someone available on the meeting to give status updates and take > action > items for the team. The group of contacts will be responsible for > getting the release out on time and making sure everything is done > that > needs to be done. It also allows the person coordinating the entire > release to know who to talk to for a specific component. > > Please reply to this email with the point of contact for each > sub-project. > > Thanks > > Mike Hi Mike, Ofri Masad will represent any SLA & scheduling related activities in VDSM, Engine and UI. Note that this is a vertical responsibility (ie- cross sub-projects). Doron From iheim at redhat.com Fri Mar 8 09:23:30 2013 From: iheim at redhat.com (Itamar Heim) Date: Fri, 08 Mar 2013 11:23:30 +0200 Subject: [RFC] oVirtLive image In-Reply-To: <5139A86C.2010700@linux.vnet.ibm.com> References: <12815560.48008292.1355516680528.JavaMail.root@redhat.com> <5139A86C.2010700@linux.vnet.ibm.com> Message-ID: <5139AE12.5070509@redhat.com> On 03/08/2013 10:59 AM, Zhou Zheng Sheng wrote: > Hi all! > > I can see the oVirt Live page in oVirt wiki, but it seems the project is > not listed in www.ovirt.org/project/subprojects/ . Is there anyone > adding it? I also can see oVirt Live patches are in Gerrit, and there is > a Jenkins job to build ISO nightly, it's great. However I cannot find > the IRC channel and mail lists for oVirt Live. Does anyone know where to > discuss? same irc channel. same mailing lists - mostly users/engine-devel moran - please add to the subjprojects page. thanks, Itamar > > Thanks! > > on 12/15/2012 04:24, Steve Gordon wrote: >> ----- Original Message ----- >>> From: "Shahar Havivi" >>> To: "Dave Neary" >>> Cc: "infra" , arch at ovirt.org >>> Sent: Sunday, December 2, 2012 2:38:26 AM >>> Subject: Re: [RFC] oVirtLive image >>> >>> On 29.11.12 16:07, Dave Neary wrote: >>>> Hi Itamar, >>>> >>>> On 11/29/2012 03:08 PM, Itamar Heim wrote: >>>>> don't remember seeing any comments against this. created the repo. >>>>> moran, please work with dave to add it to: >>>>> http://www.ovirt.org/project/subprojects/ >>>> As you may have seen on infra@ and elsewhere, we are working hard >>>> to >>>> migrate to the new website before the end of the month. I'll touch >>>> base with Moran, but normally, from this evening we will be >>>> migrated >>>> to the new wiki-based website running on OpenShift, which will mean >>>> that anyone will be able to edit the "Subprojects" page. >>>> >>>> Given how close we are to moving, I do not plan on making any edits >>>> in the wordpress site from now on. >>>> >>>> Thanks, >>>> Dave. >>> Hi, >>> Please update when we can update the wiki. >>> Thanks. >> Hi guys, >> >> Two things here: >> >> - The sub-projects wiki page still doesn't list this. >> - The repo still doesn't contain anything. >> >> I had a look to see if I could edit the wiki page myself but I can't >> even see how to log in with the new skin (probably blind I guess). >> >> Steve >> _______________________________________________ >> Infra mailing list >> Infra at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/infra >> > From abaron at redhat.com Sat Mar 9 21:31:15 2013 From: abaron at redhat.com (Ayal Baron) Date: Sat, 9 Mar 2013 16:31:15 -0500 (EST) Subject: Proposal: Reorganization of the Project Management In-Reply-To: <513760D7.6000907@redhat.com> Message-ID: <1445181233.4799410.1362864675943.JavaMail.root@redhat.com> ----- Original Message ----- > Hi Mike, > > On 03/06/2013 12:54 PM, Mike Burns wrote: > > After having coordinated the 3.2 release with questionable success, > > I > > have some thoughts on the ways to do this better going forward. I > > brought this up on the meeting last week, and was supposed to > > follow up > > quickly on list with the proposal, so here it is. > > I also have some thoughts on general release process and improving > it, > and have discussed this a little bit with Moran already. > > > 1. We need to have a group of stakeholders from each of the > > projects/components in the our release that will make up the > > release > > committee. > > 2. Members of that group should be available on the weekly meeting > > or > > have someone else on the team fill in for them > > 3. There should be someone that is in charge of this group of > > stakeholders with a preference for someone that is not tied to any > > one > > sub-project.[1] > > 4. The person who leads the committee should run the weekly > > meeting > > 5. The person who leads the committee should track docs, > > publicity, > > marketing, etc > > My fear with this type of scheme is that the weekly meetings will > continue to be a focal point, to the detriment of getting engagement > from the community to get a release out the door (with everything > that > entails, including docs, release notes, marketing and promotion, > packaging, translations...). > > > If you have thoughts on who could fill the leadership role or wish > > to > > volunteer yourself, please reply to this email. > > Perhaps more important than the person is that we agree on the > process > for getting releases, and that we get buy-in into that process. > > I have previously mentioned GNOME as a good example for a release > process: > > GNOME release process: https://live.gnome.org/ReleasePlanning > > This process talks only about time - if you want to release on date > X, > you need a code freeze at X-4 days, a string freeze at X-3 weeks, > etc. > It does not describe the frenzy of release-related activity that > happens > after these freezes, or the branching policy that most projects have. > For example, after the string freeze, translators and documentation > people kick into high gear. After the UI freeze, we start taking > screenshots for release notes and doing screencasts. After the > feature > freeze, the release team starts hammering home the release blocker > bugs > for the release, and we increase the emphasis on integration testing. > > Another nice GNOME feature is the feature proposal period, when > features > are proposed and discussed on the developer mailing list, and then > prioritised by the release team. I think we could mix and match this > nicely with a roadmap process like the one I proposed previously > here: > http://blogs.gnome.org/bolsh/2011/02/07/drawing-up-a-roadmap/ > > In fact, I don't think GNOME's branching policy is terribly good - > development happens on trunk through to the release, and then a > release > branch is made. I would prefer to see release branches made when the > code freezes (or even feature freeze) comes in, to allow people to > continue committing complete but too-late-for-release features to > trunk. > > Max Kanat-Alexander from Bugzilla wrote about the value of doing > things > like this, even though it makes life harder for the core team: > > http://www.codesimplicity.com/post/open-source-community-simplified/ > > There's an extended mailing list thread on the subject: > > https://groups.google.com/d/topic/mozilla.dev.apps.bugzilla/Ug9aoykXpRc/discussion > > In brief: when you freeze, you lose non-professional developers who > just > stop working on the project until after the release. So it's > worthwhile > keeping the trunk open, and doing your feature & code freezes on a > release branch. > > > Here's a link on the value of timeboxed feature planning and having a > hard go/no go for features that get in or don't (especially the > advice > close to the end): > > http://www.joelonsoftware.com/items/2007/10/26.html > > In short, you prioritise features, and start working on the most > important ones, and then the ones that are not ready to ship by > feature > freeze get deferred to the next feature prioritisation discussion. > +1 on all of the above > > General advice based on my experience with oVirt: > * I recommend a 6 month cadence with ~4 months feature development > and > ~2 months release preparation > * Ensure that documentation, release marketing and website updates > are > included in the release plan > * Move regular release prep to arch@ - the weekly meeting hasn't been > effective to getting people engaged in the release process. The > real-time meetings will be good for the release team you've proposed > to > sync up and agree on what the blocker bugs are, but you really need > to > have people reading those threads and prioritising their work to > align > with that > * Make regular point releases (alpha, beta 1, beta 2, RC1, whatever > they're called) before and after a release. I'm looking forward to > 3.2.1! if we have a 6 month release cycle, do you envision 1-2 point releases? e.g. 3.2.1 2 months after 3.2 and 3.2.2 2 months after that and then after another couple of months 3.3? > * Avoid tying oVirt releases to a specific release of an operating > system (be it RHEL 7 or F18). I know that F18 was a special case and > complicated things because of significant platform changes, but we > still > need to support F17 and CentOS 6.3/4 for this release, and hopefully > next release we'll also be adding Debian & Ubuntu support. +100 on this one. This means that we need to make new features that require capabilities that are only available in specific versions of other components optional (not stop development on the one hand, but not break if underlying components have not been updated to latest and greatest). > > I would love to hear feedback/see how we can ensure that all this > happens for this coming release. Step 1 is to prioritise the feature > requests we gathered from the community (and from the oVirt team) and > say what we would like to achieve with the 3.3 release and beyond. > > Cheers, > Dave. > > -- > Dave Neary - Community Action and Impact > Open Source and Standards, Red Hat - http://community.redhat.com > Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13 > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > From masayag at redhat.com Sun Mar 10 11:49:34 2013 From: masayag at redhat.com (Moti Asayag) Date: Sun, 10 Mar 2013 13:49:34 +0200 Subject: Point of Contact for each Sub Project for 3.3 In-Reply-To: <51372BA1.4000208@redhat.com> References: <51372BA1.4000208@redhat.com> Message-ID: <513C734E.7010405@redhat.com> On 03/06/2013 01:42 PM, Mike Burns wrote: > Hi all, > > As part of the release process, I'd like to make sure that each > sub-project is represented on the weekly meetings. This means having > someone available on the meeting to give status updates and take action > items for the team. The group of contacts will be responsible for > getting the release out on time and making sure everything is done that > needs to be done. It also allows the person coordinating the entire > release to know who to talk to for a specific component. > > Please reply to this email with the point of contact for each sub-project. > Muli Salem (msalem) will represent engine-side of networking. > Thanks > > Mike > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch From abaron at redhat.com Sun Mar 10 15:33:54 2013 From: abaron at redhat.com (Ayal Baron) Date: Sun, 10 Mar 2013 11:33:54 -0400 (EDT) Subject: Backup Restore API integration feature page available. In-Reply-To: <512F7366.2040907@redhat.com> Message-ID: <1153432475.5187141.1362929634961.JavaMail.root@redhat.com> ----- Original Message ----- > On 27/02/2013 22:34, snmishra at linux.vnet.ibm.com wrote: > > Hi, > > > > Please take a look at the feature page and provide feedback. > > This is > > still a work in progress and more details will be added as we make > > progress. > > > > http://www.ovirt.org/Features/Backup-Restore_API_Integration > > > > Thanks > > Sharad Mishra > > > > would be great to close this gap. > a few questions: > - do we differentiate between the backup snapshots and the regular > snapshots? > i.e., can user see them? yes (but only while backup is not running) > delete them? yes (but only while backup is not running) > revert to a snapshot before > them? yes (but only while backup is not running) > what happens if they go stale since backup process failed/broke - > can > admin intervene and clean them up? I'm not sure what you mean by stale as the snapshot is independent of the backup. If backup fails either backup system or admin need to clean up by calling the teardown API call (specific name tbd) > > - in 'prepare backup disk', there is a lock disk phase. when is the > lock released? which operations are blocked by this lock? released when teardown issued (as described above). Operations that are blocked depend on engine, i.e. all operations that cannot run while disk is locked. Specifically merge snapshot/delete disk but due to other limitations (not backup related) there will probably be other operations as well. > > - the flow seems to be directed at a running guest ('live snapshot') > - > what happens if the guest to be backed up isn't currently running? snapshot today is 'liveness' agnostic. This would be the same. The only question is do we create a snapshot when a VM is not running or not. For simplicity sake we would (V1) but this could be optimized so that going forward we'd create the snapshot only if the user tries to run the VM while it is being backed up. > > - i'm missing a bit more details on the exact flow, as it happens on > each component. > -- on which node is the nbd launched / consumed the node where the backup app is running (be it at physical layer or virt appliance) This is probably a dedicated backup host (single host cluster or something) to avoid running any VM other than the virt-appliance. But we do not need to and should not limit this imo (i.e. it would be a 'best practices' recommendation) > -- where does the backup agent/appliance run (same node as the ndb > one?) > > Thanks, > Itamar > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > From dfediuck at redhat.com Mon Mar 11 14:19:31 2013 From: dfediuck at redhat.com (Doron Fediuck) Date: Mon, 11 Mar 2013 10:19:31 -0400 (EDT) Subject: Proposal: Reorganization of the Project Management In-Reply-To: <1445181233.4799410.1362864675943.JavaMail.root@redhat.com> Message-ID: <1137208320.18033468.1363011571440.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Ayal Baron" > To: "Dave Neary" > Cc: "arch" , board at ovirt.org > Sent: Saturday, March 9, 2013 11:31:15 PM > Subject: Re: Proposal: Reorganization of the Project Management > > > > ----- Original Message ----- > > Hi Mike, > > > > On 03/06/2013 12:54 PM, Mike Burns wrote: > > > After having coordinated the 3.2 release with questionable > > > success, > > > I > > > have some thoughts on the ways to do this better going forward. > > > I > > > brought this up on the meeting last week, and was supposed to > > > follow up > > > quickly on list with the proposal, so here it is. > > > > I also have some thoughts on general release process and improving > > it, > > and have discussed this a little bit with Moran already. > > > > > 1. We need to have a group of stakeholders from each of the > > > projects/components in the our release that will make up the > > > release > > > committee. > > > 2. Members of that group should be available on the weekly > > > meeting > > > or > > > have someone else on the team fill in for them > > > 3. There should be someone that is in charge of this group of > > > stakeholders with a preference for someone that is not tied to > > > any > > > one > > > sub-project.[1] > > > 4. The person who leads the committee should run the weekly > > > meeting > > > 5. The person who leads the committee should track docs, > > > publicity, > > > marketing, etc > > > > My fear with this type of scheme is that the weekly meetings will > > continue to be a focal point, to the detriment of getting > > engagement > > from the community to get a release out the door (with everything > > that > > entails, including docs, release notes, marketing and promotion, > > packaging, translations...). > > > > > If you have thoughts on who could fill the leadership role or > > > wish > > > to > > > volunteer yourself, please reply to this email. > > > > Perhaps more important than the person is that we agree on the > > process > > for getting releases, and that we get buy-in into that process. > > > > I have previously mentioned GNOME as a good example for a release > > process: > > > > GNOME release process: https://live.gnome.org/ReleasePlanning > > > > This process talks only about time - if you want to release on date > > X, > > you need a code freeze at X-4 days, a string freeze at X-3 weeks, > > etc. > > It does not describe the frenzy of release-related activity that > > happens > > after these freezes, or the branching policy that most projects > > have. > > For example, after the string freeze, translators and documentation > > people kick into high gear. After the UI freeze, we start taking > > screenshots for release notes and doing screencasts. After the > > feature > > freeze, the release team starts hammering home the release blocker > > bugs > > for the release, and we increase the emphasis on integration > > testing. > > > > Another nice GNOME feature is the feature proposal period, when > > features > > are proposed and discussed on the developer mailing list, and then > > prioritised by the release team. I think we could mix and match > > this > > nicely with a roadmap process like the one I proposed previously > > here: > > http://blogs.gnome.org/bolsh/2011/02/07/drawing-up-a-roadmap/ > > Agree on both; feature nomination period is much needed as demonstrated by the responses Itamar got to his mail. I'd like to see some commitment to assist development &&|| testing the suggested feature coming from the feature proposer. As for roadmap, I agree as well, we should strive to have it charted and modify as needed. The biggest obstacle with such maps is how much the project is committed to it; when do you drop a feature which does not align with the map and when do you modify the map for the feature. I think this is resolvable mostly by discussions, and eventually a much needed map will help others as well. > > In fact, I don't think GNOME's branching policy is terribly good - > > development happens on trunk through to the release, and then a > > release > > branch is made. I would prefer to see release branches made when > > the > > code freezes (or even feature freeze) comes in, to allow people to > > continue committing complete but too-late-for-release features to > > trunk. > > > > Max Kanat-Alexander from Bugzilla wrote about the value of doing > > things > > like this, even though it makes life harder for the core team: > > > > http://www.codesimplicity.com/post/open-source-community-simplified/ > > > > There's an extended mailing list thread on the subject: > > > > https://groups.google.com/d/topic/mozilla.dev.apps.bugzilla/Ug9aoykXpRc/discussion > > > > In brief: when you freeze, you lose non-professional developers who > > just > > stop working on the project until after the release. So it's > > worthwhile > > keeping the trunk open, and doing your feature & code freezes on a > > release branch. > > > > > > Here's a link on the value of timeboxed feature planning and having > > a > > hard go/no go for features that get in or don't (especially the > > advice > > close to the end): > > > > http://www.joelonsoftware.com/items/2007/10/26.html > > > > In short, you prioritise features, and start working on the most > > important ones, and then the ones that are not ready to ship by > > feature > > freeze get deferred to the next feature prioritisation discussion. > > > > +1 on all of the above > > > > > General advice based on my experience with oVirt: > > * I recommend a 6 month cadence with ~4 months feature development > > and > > ~2 months release preparation > > * Ensure that documentation, release marketing and website updates > > are > > included in the release plan > > * Move regular release prep to arch@ - the weekly meeting hasn't > > been > > effective to getting people engaged in the release process. The > > real-time meetings will be good for the release team you've > > proposed > > to > > sync up and agree on what the blocker bugs are, but you really need > > to > > have people reading those threads and prioritising their work to > > align > > with that > > * Make regular point releases (alpha, beta 1, beta 2, RC1, whatever > > they're called) before and after a release. I'm looking forward to > > 3.2.1! > > if we have a 6 month release cycle, do you envision 1-2 point > releases? > e.g. 3.2.1 2 months after 3.2 and 3.2.2 2 months after that and then > after another couple of months 3.3? > > > * Avoid tying oVirt releases to a specific release of an operating > > system (be it RHEL 7 or F18). I know that F18 was a special case > > and > > complicated things because of significant platform changes, but we > > still > > need to support F17 and CentOS 6.3/4 for this release, and > > hopefully > > next release we'll also be adding Debian & Ubuntu support. > > +100 on this one. This means that we need to make new features that > require capabilities that are only available in specific versions of > other components optional (not stop development on the one hand, but > not break if underlying components have not been updated to latest > and greatest). > I'm afraid today we are using some tools / concepts which are distro- specific. Still, the first step must be done in order to have ovirt available in other distro's. One of the most common questions I got in FOSDEM was about having a Debian packaging. So full ack from me on this one, knowing that it will take time and efforts. > > > > I would love to hear feedback/see how we can ensure that all this > > happens for this coming release. Step 1 is to prioritise the > > feature > > requests we gathered from the community (and from the oVirt team) > > and > > say what we would like to achieve with the 3.3 release and beyond. > > > > Cheers, > > Dave. > > > > -- > > Dave Neary - Community Action and Impact > > Open Source and Standards, Red Hat - http://community.redhat.com > > Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13 From dneary at redhat.com Mon Mar 11 15:07:33 2013 From: dneary at redhat.com (Dave Neary) Date: Mon, 11 Mar 2013 16:07:33 +0100 Subject: Proposal: Reorganization of the Project Management In-Reply-To: <1445181233.4799410.1362864675943.JavaMail.root@redhat.com> References: <1445181233.4799410.1362864675943.JavaMail.root@redhat.com> Message-ID: <513DF335.3040901@redhat.com> Hi Ayal, On 03/09/2013 10:31 PM, Ayal Baron wrote: >> General advice based on my experience with oVirt: >> * I recommend a 6 month cadence with ~4 months feature development >> and >> ~2 months release preparation >> * Make regular point releases (alpha, beta 1, beta 2, RC1, whatever >> they're called) before and after a release. I'm looking forward to >> 3.2.1! > > if we have a 6 month release cycle, do you envision 1-2 point releases? > e.g. 3.2.1 2 months after 3.2 and 3.2.2 2 months after that and then after another couple of months 3.3? I was thinking we could lower the cost of making a point release to the point where we could have a release every month... like this: February: 3.2.0 released March: 3.2.1 released - contains fixes for important issues discovered post-release in 3.2.0 - in the meantime, feature proposal and prioritisation (and development) continues on the trunk April: 3.2.2 released - only if there are significant bug fixes or new translations May: 3.3.alpha1 released - in-progress work, contains some early features, aimed for testing to identify features that need additional work early. Release branch is made now. June: 3.3.alpha2 released - corresponds to feature freeze. At this stage, incomplete features should no longer be committed. Work can start on testing, integration testing, bug day July: 3.3.beta1 released - Corresponds to UI and string freeze - translations and docs, and release notes, should be underway already, but can hit full speed. Testing and bug fixing continues August: 3.3.0 released The only release that should take longer than a couple of hours to put out is 3.3.0 - the other releases are a tag in the source code, and a pointer to specific nightly builds. Cheers, Dave. -- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13 From abaron at redhat.com Mon Mar 11 16:15:59 2013 From: abaron at redhat.com (Ayal Baron) Date: Mon, 11 Mar 2013 12:15:59 -0400 (EDT) Subject: Proposal: Reorganization of the Project Management In-Reply-To: <513DF335.3040901@redhat.com> Message-ID: <1118012980.5974175.1363018559281.JavaMail.root@redhat.com> ----- Original Message ----- > Hi Ayal, > > On 03/09/2013 10:31 PM, Ayal Baron wrote: > >> General advice based on my experience with oVirt: > >> * I recommend a 6 month cadence with ~4 months feature development > >> and > >> ~2 months release preparation > > > > >> * Make regular point releases (alpha, beta 1, beta 2, RC1, > >> whatever > >> they're called) before and after a release. I'm looking forward to > >> 3.2.1! > > > > if we have a 6 month release cycle, do you envision 1-2 point > > releases? > > e.g. 3.2.1 2 months after 3.2 and 3.2.2 2 months after that and > > then after another couple of months 3.3? > > I was thinking we could lower the cost of making a point release to > the > point where we could have a release every month... like this: I'm not sure I understand what below reduces cost of making the point release. > > February: 3.2.0 released > March: 3.2.1 released - contains fixes for important issues > discovered > post-release in 3.2.0 - in the meantime, feature proposal and > prioritisation (and development) continues on the trunk > April: 3.2.2 released - only if there are significant bug fixes or > new > translations I have yet to see a month pass without important fixes. > May: 3.3.alpha1 released - in-progress work, contains some early > features, aimed for testing to identify features that need additional > work early. Release branch is made now. >From this point there are no more point releases to 3.2 then, correct? > June: 3.3.alpha2 released - corresponds to feature freeze. At this > stage, incomplete features should no longer be committed. Work can > start > on testing, integration testing, bug day No longer committed to the 3.3.alpha2 branch you mean? since as you've stated above, there shouldn't be a 'quiet' period in master as it deters contributors. > July: 3.3.beta1 released - Corresponds to UI and string freeze - > translations and docs, and release notes, should be underway already, > but can hit full speed. Testing and bug fixing continues > > August: 3.3.0 released > > The only release that should take longer than a couple of hours to > put > out is 3.3.0 - the other releases are a tag in the source code, and a > pointer to specific nightly builds. I don't see how that is possible. 3.2.1 in this way will contain new features and code which is not fully tested yet (negative flows etc) so you may come out with a release which is less stable than the base version (3.2). > > Cheers, > Dave. > > -- > Dave Neary - Community Action and Impact > Open Source and Standards, Red Hat - http://community.redhat.com > Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13 > From dneary at redhat.com Mon Mar 11 16:54:10 2013 From: dneary at redhat.com (Dave Neary) Date: Mon, 11 Mar 2013 17:54:10 +0100 Subject: Proposal: Reorganization of the Project Management In-Reply-To: <1118012980.5974175.1363018559281.JavaMail.root@redhat.com> References: <1118012980.5974175.1363018559281.JavaMail.root@redhat.com> Message-ID: <513E0C32.3090309@redhat.com> Hi, On 03/11/2013 05:15 PM, Ayal Baron wrote: >> I was thinking we could lower the cost of making a point release to >> the point where we could have a release every month... like this: > > I'm not sure I understand what below reduces cost of making the point release. Just this: >> The only release that should take longer than a couple of hours to >> put >> out is 3.3.0 - the other releases are a tag in the source code, and a >> pointer to specific nightly builds. >> May: 3.3.alpha1 released - in-progress work, contains some early >> features, aimed for testing to identify features that need additional >> work early. Release branch is made now. > > From this point there are no more point releases to 3.2 then, correct? It's always possible, but that's the general idea. You're 2 months from the stable release, no new features go in the release branch, and you need to concentrate on getting the next release out. >> June: 3.3.alpha2 released - corresponds to feature freeze. At this >> stage, incomplete features should no longer be committed. Work can >> start >> on testing, integration testing, bug day > > No longer committed to the 3.3.alpha2 branch you mean? since as you've stated above, there shouldn't be a 'quiet' period in master as it deters contributors. Let me explain the branching strategy below - it's pretty standard in several open source projects, but maybe people aren't familiar with it. >> The only release that should take longer than a couple of hours to >> put >> out is 3.3.0 - the other releases are a tag in the source code, and a >> pointer to specific nightly builds. > > I don't see how that is possible. 3.2.1 in this way will contain new features and code which is not fully tested yet (negative flows etc) so you may come out with a release which is less stable than the base version (3.2). OK - here's a quick ASCII Art branching strategy for a release cycle. If everything is committed to trunk, your branch tree looks like this: Trunk | | Feature 1 +---+ | | Feature 2 +---+---------+ | | | | | | +---+ Merge | | | +-------------+ Merge | | Now, you want to make a new major release. At feature freeze (when all features to be included are complete), you create a release branch. Trunk | | 3.3 release branch +---------------------------+ <- Feature freeze/branch creation | | | | | | | Feature | +---+ | | | Merge fix | +---+---------------------> | | | | | | | +---+ Merge | | X <- 3.3.beta1 release | | | Merge fix | +-------------------------> | | | Features and bug fixes continue to get done on the trunk, and those which are for the 3.3 release get merged into the 3.3 release branch. 3.3 releases are made off the 3.3 release branch. The 3.3.0, 3.3.1 and 3.3.2 releases are all tagged on the 3.3 release branch. Development continues on the trunk throughout this time. At some point, the difficult part of this (committing fixes to the trunk and then merging them to the 2.3 branch) slows down or stops, and everyone is once again concentrating on the trunk, until such time as the 3.4 or 4.0 (or whatever you decide to call it) release branch is created. Once we "abandon" the 3.3 branch, there is no point in continuing to make point releases there. It serves the project better to have a period where everyone is concentrating on implementing new features and integrating them into the trunk, rather than having attention split between maintenance and new development indefinitely. In general, 6 weeks after a release is enough time to identify and take xcare of the biggest issues in the release. Does that help explain what I have in mind better? Thanks, Dave. -- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13 From abaron at redhat.com Mon Mar 11 20:42:56 2013 From: abaron at redhat.com (Ayal Baron) Date: Mon, 11 Mar 2013 16:42:56 -0400 (EDT) Subject: Proposal: Reorganization of the Project Management In-Reply-To: <513E0C32.3090309@redhat.com> Message-ID: <945545331.6095453.1363034576893.JavaMail.root@redhat.com> ----- Original Message ----- > Hi, > > On 03/11/2013 05:15 PM, Ayal Baron wrote: > >> I was thinking we could lower the cost of making a point release > >> to > >> the point where we could have a release every month... like this: > > > > I'm not sure I understand what below reduces cost of making the > > point release. > > Just this: > > >> The only release that should take longer than a couple of hours > >> to > >> put > >> out is 3.3.0 - the other releases are a tag in the source code, > >> and a > >> pointer to specific nightly builds. > > >> May: 3.3.alpha1 released - in-progress work, contains some early > >> features, aimed for testing to identify features that need > >> additional > >> work early. Release branch is made now. > > > > From this point there are no more point releases to 3.2 then, > > correct? > > It's always possible, but that's the general idea. You're 2 months > from > the stable release, no new features go in the release branch, and you > need to concentrate on getting the next release out. > > >> June: 3.3.alpha2 released - corresponds to feature freeze. At this > >> stage, incomplete features should no longer be committed. Work can > >> start > >> on testing, integration testing, bug day > > > > No longer committed to the 3.3.alpha2 branch you mean? since as > > you've stated above, there shouldn't be a 'quiet' period in master > > as it deters contributors. > > Let me explain the branching strategy below - it's pretty standard in > several open source projects, but maybe people aren't familiar with > it. > > >> The only release that should take longer than a couple of hours to > >> put > >> out is 3.3.0 - the other releases are a tag in the source code, > >> and a > >> pointer to specific nightly builds. > > > > I don't see how that is possible. 3.2.1 in this way will contain > > new features and code which is not fully tested yet (negative > > flows etc) so you may come out with a release which is less stable > > than the base version (3.2). > > OK - here's a quick ASCII Art branching strategy for a release cycle. > > If everything is committed to trunk, your branch tree looks like > this: > > Trunk > | > | Feature 1 > +---+ > | | Feature 2 > +---+---------+ > | | | > | | | > +---+ Merge | > | | > +-------------+ Merge > | > | > > > Now, you want to make a new major release. At feature freeze (when > all > features to be included are complete), you create a release branch. > > Trunk > | > | 3.3 release branch > +---------------------------+ <- Feature freeze/branch creation > | | > | | > | | > | Feature | > +---+ | > | | Merge fix | > +---+---------------------> | > | | | > | | | > +---+ Merge | > | X <- 3.3.beta1 release > | | > | Merge fix | > +-------------------------> | > | | > > Features and bug fixes continue to get done on the trunk, and those > which are for the 3.3 release get merged into the 3.3 release branch. > 3.3 releases are made off the 3.3 release branch. > > The 3.3.0, 3.3.1 and 3.3.2 releases are all tagged on the 3.3 release > branch. > > Development continues on the trunk throughout this time. At some > point, > the difficult part of this (committing fixes to the trunk and then > merging them to the 2.3 branch) slows down or stops, and everyone is > once again concentrating on the trunk, until such time as the 3.4 or > 4.0 > (or whatever you decide to call it) release branch is created. > > Once we "abandon" the 3.3 branch, there is no point in continuing to > make point releases there. It serves the project better to have a > period > where everyone is concentrating on implementing new features and > integrating them into the trunk, rather than having attention split > between maintenance and new development indefinitely. In general, 6 > weeks after a release is enough time to identify and take xcare of > the > biggest issues in the release. > > Does that help explain what I have in mind better? Yes, it is fine, but saying that making the point release is a no brainer is misleading since you take a major hit during the entire period you have a branch (and you have a branch almost all the time - 3.2.1, 3.2.2, 3.3.alpha1, 3.3.alpha2...). The further you are from the last release the more difficult it is to backport from trunk to the branch (3.2.2 has to be based on 3.2.1 and not directly from trunk for stability). In fact, you need to branch 3.2.1 from 3.2 and not from trunk otherwise you immediately get patches that are not about stability. If we do this we'd need to define the criteria of what is backported and what is not. > > Thanks, > Dave. > > -- > Dave Neary - Community Action and Impact > Open Source and Standards, Red Hat - http://community.redhat.com > Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13 > From mgoldboi at redhat.com Mon Mar 11 23:06:07 2013 From: mgoldboi at redhat.com (Moran Goldboim) Date: Tue, 12 Mar 2013 01:06:07 +0200 Subject: Proposal: Reorganization of the Project Management In-Reply-To: <513DF335.3040901@redhat.com> References: <1445181233.4799410.1362864675943.JavaMail.root@redhat.com> <513DF335.3040901@redhat.com> Message-ID: <513E635F.3020704@redhat.com> On 03/11/2013 05:07 PM, Dave Neary wrote: > Hi Ayal, > > On 03/09/2013 10:31 PM, Ayal Baron wrote: >>> General advice based on my experience with oVirt: >>> * I recommend a 6 month cadence with ~4 months feature development >>> and >>> ~2 months release preparation > > > >>> * Make regular point releases (alpha, beta 1, beta 2, RC1, whatever >>> they're called) before and after a release. I'm looking forward to >>> 3.2.1! >> >> if we have a 6 month release cycle, do you envision 1-2 point releases? >> e.g. 3.2.1 2 months after 3.2 and 3.2.2 2 months after that and then >> after another couple of months 3.3? > > I was thinking we could lower the cost of making a point release to > the point where we could have a release every month... like this: > > February: 3.2.0 released > March: 3.2.1 released - contains fixes for important issues discovered > post-release in 3.2.0 - in the meantime, feature proposal and > prioritisation (and development) continues on the trunk > April: 3.2.2 released - only if there are significant bug fixes or new > translations > May: 3.3.alpha1 released - in-progress work, contains some early > features, aimed for testing to identify features that need additional > work early. Release branch is made now. > June: 3.3.alpha2 released - corresponds to feature freeze. At this > stage, incomplete features should no longer be committed. Work can > start on testing, integration testing, bug day > July: 3.3.beta1 released - Corresponds to UI and string freeze - > translations and docs, and release notes, should be underway already, > but can hit full speed. Testing and bug fixing continues > > August: 3.3.0 released > > The only release that should take longer than a couple of hours to put > out is 3.3.0 - the other releases are a tag in the source code, and a > pointer to specific nightly builds. > > Cheers, > Dave. > +1 on release roadmap. I was lacking some additional items on the release process of 3.2 and i would like to bring it up for 3.3: -ovirt functional dev group involvement -representative on weekly meetings -communication on when a new feature is in the code (nightly builds) - to engage early testing from the community -wiki page with contacts/maintainers, features roadmap and status, howto, etc. -lack of tracking/monitoring priority bugs/common issues -weekly meetings has been ran by very few people mostly by doing monologues- we might want to change the agenda of the meetings. I think the area coming from all above items is the need to improve communication between developers-> project PM ->community Thanks, Moran. From alonbl at redhat.com Mon Mar 11 23:31:50 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Mon, 11 Mar 2013 19:31:50 -0400 (EDT) Subject: Proposal: Reorganization of the Project Management In-Reply-To: <513E635F.3020704@redhat.com> Message-ID: <403615467.6175285.1363044710598.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Moran Goldboim" > To: "Dave Neary" > Cc: "arch" , board at ovirt.org > Sent: Tuesday, March 12, 2013 1:06:07 AM > Subject: Re: Proposal: Reorganization of the Project Management > > -weekly meetings has been ran by very few people mostly by doing > monologues- we might want to change the agenda of the meetings. Hello, Please do understand that these 'weekly' meetings are synchronous mechanism of communication. Provided a project is small or controlled by a group that is located at specific territory, it might be productive. However, asynchronous communication between parties allows much larger audience to participate. But there is some magic to make it happen. Although people thing of mailing list a good mechanism to communicate asynchronously with the world, it is very hard to actually manage a process. A good mechanism is to have a project manager that pulls upon demand the relevant parties and submit summaries to the public, in this method each party gets only the relevant approaches and provides the response based on his responsibility, while the project manager integrate the information into a complete picture, to be reviewed by the public. A better mechanism is to automate the system using information technology. Bugzilla is not the perfect tool but it is able to provide some remedy if used correctly. Currently, we misuse bugzilla instead of producing value from it we are working against it. In a nut shell, we need upstream bugzilla where PM and QE can participate at early planning stage, we need to separate products per anything that has its own release cycle, we should have proper milestones per upstream release, and we should have proper assignment per component. After we use bugzilla correctly we can evaluate other tools to provide even better productivity, but let's first utilize our current resources. After we organize bugzilla, it will be easier to manage the process, as every task will be assigned to a specific contact, product, component, version and milestone, tasks such as build issues and integration are included, no more splitting information between four different systems. A substitution of the synchronous weekly meeting would be a list of tasks to update, and focused discussion with the relevant parties on issues that request project width attention. Regards, Alon Bar-Lev. From iheim at redhat.com Tue Mar 12 09:14:39 2013 From: iheim at redhat.com (Itamar Heim) Date: Tue, 12 Mar 2013 11:14:39 +0200 Subject: Proposal: Reorganization of the Project Management In-Reply-To: <945545331.6095453.1363034576893.JavaMail.root@redhat.com> References: <945545331.6095453.1363034576893.JavaMail.root@redhat.com> Message-ID: <513EF1FF.4000507@redhat.com> On 03/11/2013 10:42 PM, Ayal Baron wrote: > > > ----- Original Message ----- >> Hi, >> >> On 03/11/2013 05:15 PM, Ayal Baron wrote: >>>> I was thinking we could lower the cost of making a point release >>>> to >>>> the point where we could have a release every month... like this: >>> >>> I'm not sure I understand what below reduces cost of making the >>> point release. >> >> Just this: >> >> >> The only release that should take longer than a couple of hours >> >> to >> >> put >> >> out is 3.3.0 - the other releases are a tag in the source code, >> >> and a >> >> pointer to specific nightly builds. >> >>>> May: 3.3.alpha1 released - in-progress work, contains some early >>>> features, aimed for testing to identify features that need >>>> additional >>>> work early. Release branch is made now. >>> >>> From this point there are no more point releases to 3.2 then, >>> correct? >> >> It's always possible, but that's the general idea. You're 2 months >> from >> the stable release, no new features go in the release branch, and you >> need to concentrate on getting the next release out. >> >>>> June: 3.3.alpha2 released - corresponds to feature freeze. At this >>>> stage, incomplete features should no longer be committed. Work can >>>> start >>>> on testing, integration testing, bug day >>> >>> No longer committed to the 3.3.alpha2 branch you mean? since as >>> you've stated above, there shouldn't be a 'quiet' period in master >>> as it deters contributors. >> >> Let me explain the branching strategy below - it's pretty standard in >> several open source projects, but maybe people aren't familiar with >> it. >> >>>> The only release that should take longer than a couple of hours to >>>> put >>>> out is 3.3.0 - the other releases are a tag in the source code, >>>> and a >>>> pointer to specific nightly builds. >>> >>> I don't see how that is possible. 3.2.1 in this way will contain >>> new features and code which is not fully tested yet (negative >>> flows etc) so you may come out with a release which is less stable >>> than the base version (3.2). >> >> OK - here's a quick ASCII Art branching strategy for a release cycle. >> >> If everything is committed to trunk, your branch tree looks like >> this: >> >> Trunk >> | >> | Feature 1 >> +---+ >> | | Feature 2 >> +---+---------+ >> | | | >> | | | >> +---+ Merge | >> | | >> +-------------+ Merge >> | >> | >> >> >> Now, you want to make a new major release. At feature freeze (when >> all >> features to be included are complete), you create a release branch. >> >> Trunk >> | >> | 3.3 release branch >> +---------------------------+ <- Feature freeze/branch creation >> | | >> | | >> | | >> | Feature | >> +---+ | >> | | Merge fix | >> +---+---------------------> | >> | | | >> | | | >> +---+ Merge | >> | X <- 3.3.beta1 release >> | | >> | Merge fix | >> +-------------------------> | >> | | >> >> Features and bug fixes continue to get done on the trunk, and those >> which are for the 3.3 release get merged into the 3.3 release branch. >> 3.3 releases are made off the 3.3 release branch. >> >> The 3.3.0, 3.3.1 and 3.3.2 releases are all tagged on the 3.3 release >> branch. >> >> Development continues on the trunk throughout this time. At some >> point, >> the difficult part of this (committing fixes to the trunk and then >> merging them to the 2.3 branch) slows down or stops, and everyone is >> once again concentrating on the trunk, until such time as the 3.4 or >> 4.0 >> (or whatever you decide to call it) release branch is created. >> >> Once we "abandon" the 3.3 branch, there is no point in continuing to >> make point releases there. It serves the project better to have a >> period >> where everyone is concentrating on implementing new features and >> integrating them into the trunk, rather than having attention split >> between maintenance and new development indefinitely. In general, 6 >> weeks after a release is enough time to identify and take xcare of >> the >> biggest issues in the release. >> >> Does that help explain what I have in mind better? > > Yes, it is fine, but saying that making the point release is a no brainer is misleading since you take a major hit during the entire period you have a branch (and you have a branch almost all the time - 3.2.1, 3.2.2, 3.3.alpha1, 3.3.alpha2...). > The further you are from the last release the more difficult it is to backport from trunk to the branch (3.2.2 has to be based on 3.2.1 and not directly from trunk for stability). > In fact, you need to branch 3.2.1 from 3.2 and not from trunk otherwise you immediately get patches that are not about stability. > If we do this we'd need to define the criteria of what is backported and what is not. we don't want to deter contributions so we don't want to block continued work on master. but taking the 3.3 stabilization branch earlier than alpha will only mean it gets less bug fixes due to the overhead of backporting them. I think it is fine to specify beta is in two weeks, and only bug fixes should go in at that period. or we don't do this. but considering the amount of bug fixes around the "alpha" period, doesn't make sense to branch before it (the risk from new features is lesser from amount of bugs which won't be backported in my view). > > >> >> Thanks, >> Dave. >> >> -- >> Dave Neary - Community Action and Impact >> Open Source and Standards, Red Hat - http://community.redhat.com >> Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13 >> > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > From dneary at redhat.com Tue Mar 12 09:39:06 2013 From: dneary at redhat.com (Dave Neary) Date: Tue, 12 Mar 2013 10:39:06 +0100 Subject: Proposal: Reorganization of the Project Management In-Reply-To: <513EF1FF.4000507@redhat.com> References: <945545331.6095453.1363034576893.JavaMail.root@redhat.com> <513EF1FF.4000507@redhat.com> Message-ID: <513EF7BA.7010502@redhat.com> Hi, On 03/12/2013 10:14 AM, Itamar Heim wrote: > On 03/11/2013 10:42 PM, Ayal Baron wrote: >> Dave Neary wrote: >>> Now, you want to make a new major release. At feature freeze (when >>> all >>> features to be included are complete), you create a release branch. >>> Features and bug fixes continue to get done on the trunk, and those >>> which are for the 3.3 release get merged into the 3.3 release branch. >>> 3.3 releases are made off the 3.3 release branch. >>> >>> The 3.3.0, 3.3.1 and 3.3.2 releases are all tagged on the 3.3 release >>> branch. >>> Does that help explain what I have in mind better? >> >> Yes, it is fine, but saying that making the point release is a no >> brainer is misleading since you take a major hit during the entire >> period you have a branch (and you have a branch almost all the time - >> 3.2.1, 3.2.2, 3.3.alpha1, 3.3.alpha2...). Yes, that's correct - all of the time when you have a release branch, you have the additional cost of merging back, and the longer the release branch lasts, the bigger the cost becomes. >> In fact, you need to branch 3.2.1 from 3.2 and not from trunk >> otherwise you immediately get patches that are not about stability. >> If we do this we'd need to define the criteria of what is backported >> and what is not. 3.2.1 does not get a branch, it's a tag on the 3.2 branch. The criteria for what gets backported and what is not is straightforward, I think - the only thing that gets backported are bug fixes to released features - no new features. > we don't want to deter contributions so we don't want to block continued > work on master. > but taking the 3.3 stabilization branch earlier than alpha will only > mean it gets less bug fixes due to the overhead of backporting them. > I think it is fine to specify beta is in two weeks, and only bug fixes > should go in at that period. or we don't do this. but considering the > amount of bug fixes around the "alpha" period, doesn't make sense to > branch before it (the risk from new features is lesser from amount of > bugs which won't be backported in my view). As you can see, I am suggesting branching after feature freeze - after alpha releases, and before beta releases. It could be delayed a few days, perhaps a couple of weeks, for sure, but I would like to have a place to land new features that are ready to be integrated after the feature freeze, but which we have agreed should not go into the next stable release. IMHO, that place should be the trunk (and that is only possible if you have already made a release branch). Cheers, Dave. -- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13 From iheim at redhat.com Tue Mar 12 09:44:20 2013 From: iheim at redhat.com (Itamar Heim) Date: Tue, 12 Mar 2013 11:44:20 +0200 Subject: Proposal: Reorganization of the Project Management In-Reply-To: <513EF7BA.7010502@redhat.com> References: <945545331.6095453.1363034576893.JavaMail.root@redhat.com> <513EF1FF.4000507@redhat.com> <513EF7BA.7010502@redhat.com> Message-ID: <513EF8F4.4020807@redhat.com> On 03/12/2013 11:39 AM, Dave Neary wrote: > 3.2.1 does not get a branch, it's a tag on the 3.2 branch. The criteria > for what gets backported and what is not is straightforward, I think - > the only thing that gets backported are bug fixes to released features - > no new features. it also gets the patches for .el6 support in 3.2 as an exception this time. > >> we don't want to deter contributions so we don't want to block continued >> work on master. >> but taking the 3.3 stabilization branch earlier than alpha will only >> mean it gets less bug fixes due to the overhead of backporting them. >> I think it is fine to specify beta is in two weeks, and only bug fixes >> should go in at that period. or we don't do this. but considering the >> amount of bug fixes around the "alpha" period, doesn't make sense to >> branch before it (the risk from new features is lesser from amount of >> bugs which won't be backported in my view). > > As you can see, I am suggesting branching after feature freeze - after > alpha releases, and before beta releases. It could be delayed a few > days, perhaps a couple of weeks, for sure, but I would like to have a > place to land new features that are ready to be integrated after the > feature freeze, but which we have agreed should not go into the next > stable release. IMHO, that place should be the trunk (and that is only > possible if you have already made a release branch). if the branch is temporary, to only fix critical issues for that phase, then goes away and we rebase for the next branch - i'm fine with it. but since you can't assess how many patches would be needed, usually at early phases snapshots are used - snapshots are just taking master, testing it, fixing all broken things and taking master again for next snapshot (hence snapshots are usually weekly builds). i think it is a better approach as a concept till the beta build. From danken at redhat.com Wed Mar 13 20:03:39 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Wed, 13 Mar 2013 22:03:39 +0200 Subject: [Users] oVirt 3.2 on CentOS with Gluster 3.3 In-Reply-To: <20130311103451.GF27440@redhat.com> References: <20130310073450.GC26454@redhat.com> <45579377.12020578.1362996596616.JavaMail.root@redhat.com> <20130311103451.GF27440@redhat.com> Message-ID: <20130313200339.GD17480@redhat.com> On Mon, Mar 11, 2013 at 12:34:51PM +0200, Dan Kenigsberg wrote: > On Mon, Mar 11, 2013 at 06:09:56AM -0400, Balamurugan Arumugam wrote: > > > > >>>Rob, > > > > >>> > > > > >>>It seems that a bug in vdsm code is hiding the real issue. > > > > >>>Could you do a > > > > >>> > > > > >>> sed -i s/ParseError/ElementTree.ParseError > > > > >>> /usr/share/vdsm/gluster/cli.py > > > > >>> > > > > >>>restart vdsmd, and retry? > > > > >>> > > > > >>>Bala, would you send a patch fixing the ParseError issue (and > > > > >>>adding a Ok, both issues have fixes which are in the ovirt-3.2 git branch. I believe this deserves a respin of vdsm, as having an undeclated requirement is impolite. Federico, Mike, would you take care for that? Dan. From fsimonce at redhat.com Wed Mar 13 20:10:56 2013 From: fsimonce at redhat.com (Federico Simoncelli) Date: Wed, 13 Mar 2013 16:10:56 -0400 (EDT) Subject: [Users] oVirt 3.2 on CentOS with Gluster 3.3 In-Reply-To: <20130313200339.GD17480@redhat.com> Message-ID: <150610356.14529239.1363205456063.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Dan Kenigsberg" > To: "Balamurugan Arumugam" , "Federico Simoncelli" , "Mike Burns" > > Cc: "Rob Zwissler" , users at ovirt.org, arch at ovirt.org, "Aravinda VK" , "Ayal > Baron" > Sent: Wednesday, March 13, 2013 9:03:39 PM > Subject: Re: [Users] oVirt 3.2 on CentOS with Gluster 3.3 > > On Mon, Mar 11, 2013 at 12:34:51PM +0200, Dan Kenigsberg wrote: > > On Mon, Mar 11, 2013 at 06:09:56AM -0400, Balamurugan Arumugam > > wrote: > > > > > >>>Rob, > > > > > >>> > > > > > >>>It seems that a bug in vdsm code is hiding the real issue. > > > > > >>>Could you do a > > > > > >>> > > > > > >>> sed -i s/ParseError/ElementTree.ParseError > > > > > >>> /usr/share/vdsm/gluster/cli.py > > > > > >>> > > > > > >>>restart vdsmd, and retry? > > > > > >>> > > > > > >>>Bala, would you send a patch fixing the ParseError issue > > > > > >>>(and > > > > > >>>adding a > > Ok, both issues have fixes which are in the ovirt-3.2 git branch. > I believe this deserves a respin of vdsm, as having an undeclated > requirement is impolite. > > Federico, Mike, would you take care for that? Since we're at it... I have the feeling that this might be important enough to be backported to 3.2 too: http://gerrit.ovirt.org/#/c/12178/ -- Federico From abaron at redhat.com Wed Mar 13 20:19:26 2013 From: abaron at redhat.com (Ayal Baron) Date: Wed, 13 Mar 2013 16:19:26 -0400 (EDT) Subject: [Users] oVirt 3.2 on CentOS with Gluster 3.3 In-Reply-To: <150610356.14529239.1363205456063.JavaMail.root@redhat.com> Message-ID: <655417114.7612086.1363205966504.JavaMail.root@redhat.com> ----- Original Message ----- > ----- Original Message ----- > > From: "Dan Kenigsberg" > > To: "Balamurugan Arumugam" , "Federico > > Simoncelli" , "Mike Burns" > > > > Cc: "Rob Zwissler" , users at ovirt.org, > > arch at ovirt.org, "Aravinda VK" , "Ayal > > Baron" > > Sent: Wednesday, March 13, 2013 9:03:39 PM > > Subject: Re: [Users] oVirt 3.2 on CentOS with Gluster 3.3 > > > > On Mon, Mar 11, 2013 at 12:34:51PM +0200, Dan Kenigsberg wrote: > > > On Mon, Mar 11, 2013 at 06:09:56AM -0400, Balamurugan Arumugam > > > wrote: > > > > > > >>>Rob, > > > > > > >>> > > > > > > >>>It seems that a bug in vdsm code is hiding the real > > > > > > >>>issue. > > > > > > >>>Could you do a > > > > > > >>> > > > > > > >>> sed -i s/ParseError/ElementTree.ParseError > > > > > > >>> /usr/share/vdsm/gluster/cli.py > > > > > > >>> > > > > > > >>>restart vdsmd, and retry? > > > > > > >>> > > > > > > >>>Bala, would you send a patch fixing the ParseError issue > > > > > > >>>(and > > > > > > >>>adding a > > > > Ok, both issues have fixes which are in the ovirt-3.2 git branch. > > I believe this deserves a respin of vdsm, as having an undeclated > > requirement is impolite. > > > > Federico, Mike, would you take care for that? > > Since we're at it... I have the feeling that this might be important > enough to be backported to 3.2 too: > > http://gerrit.ovirt.org/#/c/12178/ > Without a doubt! > -- > Federico > From danken at redhat.com Wed Mar 13 20:28:57 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Wed, 13 Mar 2013 22:28:57 +0200 Subject: [Users] oVirt 3.2 on CentOS with Gluster 3.3 In-Reply-To: <150610356.14529239.1363205456063.JavaMail.root@redhat.com> References: <20130313200339.GD17480@redhat.com> <150610356.14529239.1363205456063.JavaMail.root@redhat.com> Message-ID: <20130313202857.GE17480@redhat.com> On Wed, Mar 13, 2013 at 04:10:56PM -0400, Federico Simoncelli wrote: > ----- Original Message ----- > > From: "Dan Kenigsberg" > > To: "Balamurugan Arumugam" , "Federico Simoncelli" , "Mike Burns" > > > > Cc: "Rob Zwissler" , users at ovirt.org, arch at ovirt.org, "Aravinda VK" , "Ayal > > Baron" > > Sent: Wednesday, March 13, 2013 9:03:39 PM > > Subject: Re: [Users] oVirt 3.2 on CentOS with Gluster 3.3 > > > > On Mon, Mar 11, 2013 at 12:34:51PM +0200, Dan Kenigsberg wrote: > > > On Mon, Mar 11, 2013 at 06:09:56AM -0400, Balamurugan Arumugam > > > wrote: > > > > > > >>>Rob, > > > > > > >>> > > > > > > >>>It seems that a bug in vdsm code is hiding the real issue. > > > > > > >>>Could you do a > > > > > > >>> > > > > > > >>> sed -i s/ParseError/ElementTree.ParseError > > > > > > >>> /usr/share/vdsm/gluster/cli.py > > > > > > >>> > > > > > > >>>restart vdsmd, and retry? > > > > > > >>> > > > > > > >>>Bala, would you send a patch fixing the ParseError issue > > > > > > >>>(and > > > > > > >>>adding a > > > > Ok, both issues have fixes which are in the ovirt-3.2 git branch. > > I believe this deserves a respin of vdsm, as having an undeclated > > requirement is impolite. > > > > Federico, Mike, would you take care for that? > > Since we're at it... I have the feeling that this might be important > enough to be backported to 3.2 too: > > http://gerrit.ovirt.org/#/c/12178/ Yes, it is quite horrible. Could you include that, too? From mkolesni at redhat.com Mon Mar 18 07:20:45 2013 From: mkolesni at redhat.com (Mike Kolesnik) Date: Mon, 18 Mar 2013 03:20:45 -0400 (EDT) Subject: OpenStack Quantum integration feature page for 3.3 In-Reply-To: <1153443022.2095373.1363591214115.JavaMail.root@redhat.com> Message-ID: <971394683.2095416.1363591245101.JavaMail.root@redhat.com> Hi all, The feature page for integrating OpenStack Quantum into oVirt is available on the wiki: http://www.ovirt.org/Features/Quantum_Integration Please comment. Regards, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From danken at redhat.com Mon Mar 18 08:10:15 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Mon, 18 Mar 2013 10:10:15 +0200 Subject: OpenStack Quantum integration feature page for 3.3 In-Reply-To: <971394683.2095416.1363591245101.JavaMail.root@redhat.com> References: <1153443022.2095373.1363591214115.JavaMail.root@redhat.com> <971394683.2095416.1363591245101.JavaMail.root@redhat.com> Message-ID: <20130318081015.GC5072@redhat.com> On Mon, Mar 18, 2013 at 03:20:45AM -0400, Mike Kolesnik wrote: > Hi all, > > The feature page for integrating OpenStack Quantum into oVirt is available on the wiki: > http://www.ovirt.org/Features/Quantum_Integration > A quote from "Network discovery": > Currently, we assume that the networks provided by the provider are > available on all hosts in the data center... it is not completely clear who are "we" there. I suppose that you mean that Engine takes this assumption, and does not verify that a specific host is actually connectable by the network provider. That's not much worse than what Engine does elsewhere: it does not verify that network "green" in one host can actually connect with network "green" on another host. A quote from "Network provisioning": > The network can be exported from oVirt into the network provider, but > from that moment on it will be as if the network was discovered from > the provider - i.e. if it goes out of sync, that's OK from oVirt's > perspective. Could you explain what does "exporting a network from oVirt" means? Do you plan an API for that? Could you elaborate on why this feature depends on http://www.ovirt.org/Features/Device_Custom_Properties ? This feature heavily depends on http://www.ovirt.org/Network_Provider . Is there a real difference between the two? If not, I'd rename Network_Provider to Features/Network_Provider and have Quantum_Integration redirect to there. Regards, Dan. From mkolesni at redhat.com Mon Mar 18 08:23:32 2013 From: mkolesni at redhat.com (Mike Kolesnik) Date: Mon, 18 Mar 2013 04:23:32 -0400 (EDT) Subject: OpenStack Quantum integration feature page for 3.3 In-Reply-To: <20130318081015.GC5072@redhat.com> Message-ID: <118069132.2113469.1363595012092.JavaMail.root@redhat.com> ----- Original Message ----- > On Mon, Mar 18, 2013 at 03:20:45AM -0400, Mike Kolesnik wrote: > > Hi all, > > > > The feature page for integrating OpenStack Quantum into oVirt is > > available on the wiki: > > http://www.ovirt.org/Features/Quantum_Integration > > > > A quote from "Network discovery": > > Currently, we assume that the networks provided by the provider are > > available on all hosts in the data center... > > it is not completely clear who are "we" there. I suppose that you > mean > that Engine takes this assumption, and does not verify that a > specific > host is actually connectable by the network provider. That's not much > worse than what Engine does elsewhere: it does not verify that > network > "green" in one host can actually connect with network "green" on > another > host. "We" is oVirt as a whole. Currently we do know which network is available on which host since the user set it up. In the planned integration we wouldn't know, thus we will consider external network as "provided". It is not quite the same as the example you gave about "green" network. > > A quote from "Network provisioning": > > > The network can be exported from oVirt into the network provider, > > but > > from that moment on it will be as if the network was discovered > > from > > the provider - i.e. if it goes out of sync, that's OK from oVirt's > > perspective. > > Could you explain what does "exporting a network from oVirt" means? > Do you > plan an API for that? Yes, we plan to be able to create a network on the provider via oVirt, instead of having the user do it via the Quantum API. > > Could you elaborate on why this feature depends on > http://www.ovirt.org/Features/Device_Custom_Properties ? We need this to specify custom properties per vNIC also for hot plug/wire. Otherwise we won't be able to support these features for externally provided networks. > > This feature heavily depends on http://www.ovirt.org/Network_Provider Yes, it is an elaboration of the feture, not something independent. > . > Is there a real difference between the two? If not, I'd rename > Network_Provider to Features/Network_Provider and have > Quantum_Integration redirect to there. > > Regards, > > Dan. > From danken at redhat.com Tue Mar 19 15:06:44 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Tue, 19 Mar 2013 17:06:44 +0200 Subject: [vdsm] Per device custom properties In-Reply-To: <1264235091.46742390.1363528220157.JavaMail.root@redhat.com> References: <262555909.46739874.1363523087978.JavaMail.root@redhat.com> <1264235091.46742390.1363528220157.JavaMail.root@redhat.com> Message-ID: <20130319150644.GJ25513@redhat.com> adding arch at ovirt, as this feature is cross sub-project On Sun, Mar 17, 2013 at 09:50:20AM -0400, Assaf Muller wrote: > Hi all, > > Right now we have the ability to define VM-wide properties that may be > used by hooks. > It is time we have the same functionality on a device basis: > http://www.ovirt.org/Features/Device_Custom_Properties This feature page needs some love and attention. * I received a private communication about the suggested GUI: there should not be an independent vNIC action called "custom Properties" - the dialog for editing per-vNIC custom properties should be part of defining a new vNIC or editting an existing one. I believe Eldan (our GUI designer) concurs. * http://www.ovirt.org/Features/Device_Custom_Properties#Engine is rather lacking concrete details. Yair, could you improve it, as well as the completely empty REST section? > > For example: If the VM has 2 disks called disk1 and disk2, and two > NICs called nic1 and nic2, and the admin (From the engine) added a > custom property qos: 0.5 for nic1 and a custom property defrag: None > for disk2. When the VM is started we'll run a hook for nic1 with its > XML and qos: 0.5 added as an environment variable, and a hook for > disk2 with its XML and defrag: None. > > When a device is hot plugged and it has custom properties we'll run > that hook as well. > > Implementation-wise, hot plug/unplug for disks and NICs is dead simple > - vmCreate is more problematic: > If the user set a custom property called 'qos: 0.8' for nic3, I'd want > it exposed as an environment variable called 'qos' for hot plug nic > hooks, but for vmCreate I'd like to prefix the nic's alias. However, > when vmCreate is called we don't have the aliases for NICs and disks. > > The proposed solution is to create a new hook point called something > like: 'before_device_creation' that will be called before vmCreate. > We'll then call that hook specifically for devices that contains > custom properties, as described in the second paragraph of this mail. > > > I would love to hear smarter ideas before I move forward. Thanks! I find it quite intuitive, but I'd rather hear if it feats Izik's use case. Dan. From yzaslavs at redhat.com Wed Mar 20 07:43:54 2013 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Wed, 20 Mar 2013 03:43:54 -0400 (EDT) Subject: [vdsm] Per device custom properties In-Reply-To: <4488206DC085244C886DBC9E7038B6897353BE06@MTLDAG02.mtl.com> Message-ID: <391020210.11407030.1363765434106.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Itzik Brown" > To: "Dan Kenigsberg" , "Assaf Muller" , "Yair Zaslavsky" > , "Eldan Hildesheim" , izikb at mellanox.com > Cc: vdsm-devel at lists.fedorahosted.org, arch at ovirt.org, "Irena Berezovsky" > Sent: Wednesday, March 20, 2013 9:17:08 AM > Subject: RE: [vdsm] Per device custom properties > > Hi, > > I think that this feature is a good start for enabling vendor > specific hints which apply to VM Network/Disk devices. > There is a need to add migration hooks to the list. > > Itzik > > -----Original Message----- > From: Dan Kenigsberg [mailto:danken at redhat.com] > Sent: ????? 19 ??? 2013 17:12 > To: Assaf Muller; Yair Zaslavsky; Eldan Hildesheim; > izikb at mellanox.com > Cc: vdsm-devel at lists.fedorahosted.org; arch at ovirt.org > Subject: Re: [vdsm] Per device custom properties > > adding arch at ovirt, as this feature is cross sub-project > > On Sun, Mar 17, 2013 at 09:50:20AM -0400, Assaf Muller wrote: > > Hi all, > > > > Right now we have the ability to define VM-wide properties that may > > be > > used by hooks. > > It is time we have the same functionality on a device basis: > > http://www.ovirt.org/Features/Device_Custom_Properties > > This feature page needs some love and attention. > > * I received a private communication about the suggested GUI: there > should not be an independent vNIC action called "custom Properties" > - > the dialog for editing per-vNIC custom properties should be part of > defining a new vNIC or editting an existing one. I believe Eldan > (our > GUI designer) concurs. > > * http://www.ovirt.org/Features/Device_Custom_Properties#Engine is > rather lacking concrete details. Yair, could you improve it, as > well > as the completely empty REST section? I would prefer Michael Pasternak handles REST-API. Regarding the rest of the engine side- I'll assist. I would consult with Eli on this, as he was/is the feature owner of VM devices. > > > > > For example: If the VM has 2 disks called disk1 and disk2, and two > > NICs called nic1 and nic2, and the admin (From the engine) added a > > custom property qos: 0.5 for nic1 and a custom property defrag: > > None > > for disk2. When the VM is started we'll run a hook for nic1 with > > its > > XML and qos: 0.5 added as an environment variable, and a hook for > > disk2 with its XML and defrag: None. > > > > When a device is hot plugged and it has custom properties we'll run > > that hook as well. > > > > Implementation-wise, hot plug/unplug for disks and NICs is dead > > simple > > - vmCreate is more problematic: > > If the user set a custom property called 'qos: 0.8' for nic3, I'd > > want > > it exposed as an environment variable called 'qos' for hot plug nic > > hooks, but for vmCreate I'd like to prefix the nic's alias. > > However, > > when vmCreate is called we don't have the aliases for NICs and > > disks. > > > > The proposed solution is to create a new hook point called > > something > > like: 'before_device_creation' that will be called before vmCreate. > > We'll then call that hook specifically for devices that contains > > custom properties, as described in the second paragraph of this > > mail. > > > > > > I would love to hear smarter ideas before I move forward. Thanks! > > I find it quite intuitive, but I'd rather hear if it feats Izik's use > case. > > Dan. > From danken at redhat.com Thu Mar 21 13:12:20 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Thu, 21 Mar 2013 15:12:20 +0200 Subject: OpenStack Quantum integration feature page for 3.3 In-Reply-To: <118069132.2113469.1363595012092.JavaMail.root@redhat.com> References: <20130318081015.GC5072@redhat.com> <118069132.2113469.1363595012092.JavaMail.root@redhat.com> Message-ID: <20130321131219.GH26392@redhat.com> On Mon, Mar 18, 2013 at 04:23:32AM -0400, Mike Kolesnik wrote: > ----- Original Message ----- > > On Mon, Mar 18, 2013 at 03:20:45AM -0400, Mike Kolesnik wrote: > > > Hi all, > > > > > > The feature page for integrating OpenStack Quantum into oVirt is > > > available on the wiki: > > > http://www.ovirt.org/Features/Quantum_Integration > > > > > > > A quote from "Network discovery": > > > Currently, we assume that the networks provided by the provider are > > > available on all hosts in the data center... > > > > it is not completely clear who are "we" there. I suppose that you > > mean > > that Engine takes this assumption, and does not verify that a > > specific > > host is actually connectable by the network provider. That's not much > > worse than what Engine does elsewhere: it does not verify that > > network > > "green" in one host can actually connect with network "green" on > > another > > host. > > "We" is oVirt as a whole. > > Currently we do know which network is available on which host since the user set it up. > In the planned integration we wouldn't know, thus we will consider external network as "provided". So *Engine* cannot tell if a host is controllable by the defined quantum server, and therefore it has to assume that everything is all right, putting this burden on the end user. Garry, does Quantum provide any means to tell - ahead of time - if provisioning a virtual network to a specific work is expected to succeed? Or, let's say, that the host is utterly misconfigured and is unknown to Quantum? Can it at least be done for plugins with host agents? > > It is not quite the same as the example you gave about "green" network. Of course. My "green" example was only showing that we can never really tell that a future VM would see its required network. > > > > > A quote from "Network provisioning": > > > > > The network can be exported from oVirt into the network provider, > > > but > > > from that moment on it will be as if the network was discovered > > > from > > > the provider - i.e. if it goes out of sync, that's OK from oVirt's > > > perspective. > > > > Could you explain what does "exporting a network from oVirt" means? > > Do you > > plan an API for that? > > Yes, we plan to be able to create a network on the provider via oVirt, > instead of having the user do it via the Quantum API. Could you define this "export" term on the feature page, or state which Quantum API is going to be used for it? > > > > > Could you elaborate on why this feature depends on > > http://www.ovirt.org/Features/Device_Custom_Properties ? > > We need this to specify custom properties per vNIC also for hot > plug/wire. Otherwise we won't be able to support these features for > externally provided networks. Which custom properties would you need? Are they going to depend on the specific quatum vif type? > > > > This feature heavily depends on http://www.ovirt.org/Network_Provider > > Yes, it is an elaboration of the feture, not something independent. To me, this separtion incur confusion. The fact that it happens for many other features (http://www.ovirt.org/Features/Design/) only makes it worse ;-) > > > . > > Is there a real difference between the two? If not, I'd rename > > Network_Provider to Features/Network_Provider and have > > Quantum_Integration redirect to there. > > > > Regards, > > > > Dan. > > From gkotton at redhat.com Thu Mar 21 13:53:38 2013 From: gkotton at redhat.com (Gary Kotton) Date: Thu, 21 Mar 2013 15:53:38 +0200 Subject: OpenStack Quantum integration feature page for 3.3 In-Reply-To: <20130321131219.GH26392@redhat.com> References: <20130318081015.GC5072@redhat.com> <118069132.2113469.1363595012092.JavaMail.root@redhat.com> <20130321131219.GH26392@redhat.com> Message-ID: <514B10E2.60306@redhat.com> On 03/21/2013 03:12 PM, Dan Kenigsberg wrote: > On Mon, Mar 18, 2013 at 04:23:32AM -0400, Mike Kolesnik wrote: >> ----- Original Message ----- >>> On Mon, Mar 18, 2013 at 03:20:45AM -0400, Mike Kolesnik wrote: >>>> Hi all, >>>> >>>> The feature page for integrating OpenStack Quantum into oVirt is >>>> available on the wiki: >>>> http://www.ovirt.org/Features/Quantum_Integration >>>> >>> A quote from "Network discovery": >>>> Currently, we assume that the networks provided by the provider are >>>> available on all hosts in the data center... >>> it is not completely clear who are "we" there. I suppose that you >>> mean >>> that Engine takes this assumption, and does not verify that a >>> specific >>> host is actually connectable by the network provider. That's not much >>> worse than what Engine does elsewhere: it does not verify that >>> network >>> "green" in one host can actually connect with network "green" on >>> another >>> host. >> "We" is oVirt as a whole. >> >> Currently we do know which network is available on which host since the user set it up. >> In the planned integration we wouldn't know, thus we will consider external network as "provided". > So *Engine* cannot tell if a host is controllable by the defined quantum > server, and therefore it has to assume that everything is all right, > putting this burden on the end user. > > Garry, does Quantum provide any means to tell - ahead of time - if > provisioning a virtual network to a specific work is expected to > succeed? Or, let's say, that the host is utterly misconfigured and is > unknown to Quantum? Can it at least be done for plugins with host > agents? I am not really sure that I understand your question. Can you please clarify what you mean by "if provisioning a virtual network ... is expected to succeed". Lets take two open source examples: openvswitch - a integration bridge is provisioned ahed of time, that is, each host will need to provision an integration bridge on the OVS. When the agent detects that new port is created on the bridge then it will configure the relevant VLAN. The Quantum service will be notified that the port is "UP" linuxbridge - the nova host that is deplying the VM will create the networkwork if it does not exist. If this fails the a VM will not be spawned. Once the network is up the agent will configure the VLAN. The quantum service will be notified that the port is "UP" The assumption is that the hosts will be configured correctly. If not the the Quantum port will be "DOWN" (this can be detected via interfacing with the quantum service) In Grizzly things are complicated a little more as the hosts are also responsible for the configuartion of the security groups for the port in question. Hope that this helps unless I have completely misunderstood your question. Thanks Gary > >> It is not quite the same as the example you gave about "green" network. > Of course. My "green" example was only showing that we can never really > tell that a future VM would see its required network. > >>> A quote from "Network provisioning": >>> >>>> The network can be exported from oVirt into the network provider, >>>> but >>>> from that moment on it will be as if the network was discovered >>>> from >>>> the provider - i.e. if it goes out of sync, that's OK from oVirt's >>>> perspective. >>> Could you explain what does "exporting a network from oVirt" means? >>> Do you >>> plan an API for that? >> Yes, we plan to be able to create a network on the provider via oVirt, >> instead of having the user do it via the Quantum API. > Could you define this "export" term on the feature page, or state which > Quantum API is going to be used for it? > >>> Could you elaborate on why this feature depends on >>> http://www.ovirt.org/Features/Device_Custom_Properties ? >> We need this to specify custom properties per vNIC also for hot >> plug/wire. Otherwise we won't be able to support these features for >> externally provided networks. > Which custom properties would you need? Are they going to depend on the > specific quatum vif type? > >>> This feature heavily depends on http://www.ovirt.org/Network_Provider >> Yes, it is an elaboration of the feture, not something independent. > To me, this separtion incur confusion. The fact that it happens for many > other features (http://www.ovirt.org/Features/Design/) only makes it > worse ;-) > >>> . >>> Is there a real difference between the two? If not, I'd rename >>> Network_Provider to Features/Network_Provider and have >>> Quantum_Integration redirect to there. >>> >>> Regards, >>> >>> Dan. >>> From johnny at centos.org Thu Mar 21 15:48:58 2013 From: johnny at centos.org (Johnny Hughes) Date: Thu, 21 Mar 2013 10:48:58 -0500 Subject: Missing SRPMS Message-ID: <514B2BEA.2080400@centos.org> The ovirt-engine-3.2.1-1.beta1.el6.src.rpm is missing from: http://resources.ovirt.org/releases/3.2/rpm/EL/6/ As is the jboss-as-*.src.rpm. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From danken at redhat.com Thu Mar 21 21:06:20 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Thu, 21 Mar 2013 23:06:20 +0200 Subject: OpenStack Quantum integration feature page for 3.3 In-Reply-To: <514B10E2.60306@redhat.com> References: <20130318081015.GC5072@redhat.com> <118069132.2113469.1363595012092.JavaMail.root@redhat.com> <20130321131219.GH26392@redhat.com> <514B10E2.60306@redhat.com> Message-ID: <20130321210619.GA10337@redhat.com> On Thu, Mar 21, 2013 at 03:53:38PM +0200, Gary Kotton wrote: > On 03/21/2013 03:12 PM, Dan Kenigsberg wrote: > >On Mon, Mar 18, 2013 at 04:23:32AM -0400, Mike Kolesnik wrote: > >>----- Original Message ----- > >>>On Mon, Mar 18, 2013 at 03:20:45AM -0400, Mike Kolesnik wrote: > >>>>Hi all, > >>>> > >>>>The feature page for integrating OpenStack Quantum into oVirt is > >>>>available on the wiki: > >>>>http://www.ovirt.org/Features/Quantum_Integration > >>>> > >>>A quote from "Network discovery": > >>>>Currently, we assume that the networks provided by the provider are > >>>>available on all hosts in the data center... > >>>it is not completely clear who are "we" there. I suppose that you > >>>mean > >>>that Engine takes this assumption, and does not verify that a > >>>specific > >>>host is actually connectable by the network provider. That's not much > >>>worse than what Engine does elsewhere: it does not verify that > >>>network > >>>"green" in one host can actually connect with network "green" on > >>>another > >>>host. > >>"We" is oVirt as a whole. > >> > >>Currently we do know which network is available on which host since the user set it up. > >>In the planned integration we wouldn't know, thus we will consider external network as "provided". > >So *Engine* cannot tell if a host is controllable by the defined quantum > >server, and therefore it has to assume that everything is all right, > >putting this burden on the end user. > > > >Garry, does Quantum provide any means to tell - ahead of time - if > >provisioning a virtual network to a specific work is expected to > >succeed? Or, let's say, that the host is utterly misconfigured and is > >unknown to Quantum? Can it at least be done for plugins with host > >agents? > > I am not really sure that I understand your question. Can you please > clarify what you mean by "if provisioning a virtual network ... is > expected to succeed". > > Lets take two open source examples: > openvswitch - a integration bridge is provisioned ahed of time, that > is, each host will need to provision an integration bridge on the > OVS. When the agent detects that new port is created on the bridge > then it will configure the relevant VLAN. The Quantum service will > be notified that the port is "UP" > linuxbridge - the nova host that is deplying the VM will create the > networkwork if it does not exist. If this fails the a VM will not be > spawned. Once the network is up the agent will configure the VLAN. > The quantum service will be notified that the port is "UP" > > The assumption is that the hosts will be configured correctly. If I would like to have a clue - ahead of time - if that assumption is valid. The two examples above require the host to notify the Quantum service. But what if the host agent is notifying an utterly different service? Is there some kind of liveliness check between the host and its Quantum service? > not the the Quantum port will be "DOWN" (this can be detected via > interfacing with the quantum service) > > In Grizzly things are complicated a little more as the hosts are > also responsible for the configuartion of the security groups for > the port in question. > > Hope that this helps unless I have completely misunderstood your question. > > Thanks > Gary From gkotton at redhat.com Fri Mar 22 06:34:14 2013 From: gkotton at redhat.com (Gary Kotton) Date: Fri, 22 Mar 2013 08:34:14 +0200 Subject: OpenStack Quantum integration feature page for 3.3 In-Reply-To: <20130321210619.GA10337@redhat.com> References: <20130318081015.GC5072@redhat.com> <118069132.2113469.1363595012092.JavaMail.root@redhat.com> <20130321131219.GH26392@redhat.com> <514B10E2.60306@redhat.com> <20130321210619.GA10337@redhat.com> Message-ID: <514BFB66.5040106@redhat.com> On 03/21/2013 11:06 PM, Dan Kenigsberg wrote: > On Thu, Mar 21, 2013 at 03:53:38PM +0200, Gary Kotton wrote: >> On 03/21/2013 03:12 PM, Dan Kenigsberg wrote: >>> On Mon, Mar 18, 2013 at 04:23:32AM -0400, Mike Kolesnik wrote: >>>> ----- Original Message ----- >>>>> On Mon, Mar 18, 2013 at 03:20:45AM -0400, Mike Kolesnik wrote: >>>>>> Hi all, >>>>>> >>>>>> The feature page for integrating OpenStack Quantum into oVirt is >>>>>> available on the wiki: >>>>>> http://www.ovirt.org/Features/Quantum_Integration >>>>>> >>>>> A quote from "Network discovery": >>>>>> Currently, we assume that the networks provided by the provider are >>>>>> available on all hosts in the data center... >>>>> it is not completely clear who are "we" there. I suppose that you >>>>> mean >>>>> that Engine takes this assumption, and does not verify that a >>>>> specific >>>>> host is actually connectable by the network provider. That's not much >>>>> worse than what Engine does elsewhere: it does not verify that >>>>> network >>>>> "green" in one host can actually connect with network "green" on >>>>> another >>>>> host. >>>> "We" is oVirt as a whole. >>>> >>>> Currently we do know which network is available on which host since the user set it up. >>>> In the planned integration we wouldn't know, thus we will consider external network as "provided". >>> So *Engine* cannot tell if a host is controllable by the defined quantum >>> server, and therefore it has to assume that everything is all right, >>> putting this burden on the end user. >>> >>> Garry, does Quantum provide any means to tell - ahead of time - if >>> provisioning a virtual network to a specific work is expected to >>> succeed? Or, let's say, that the host is utterly misconfigured and is >>> unknown to Quantum? Can it at least be done for plugins with host >>> agents? >> I am not really sure that I understand your question. Can you please >> clarify what you mean by "if provisioning a virtual network ... is >> expected to succeed". >> >> Lets take two open source examples: >> openvswitch - a integration bridge is provisioned ahed of time, that >> is, each host will need to provision an integration bridge on the >> OVS. When the agent detects that new port is created on the bridge >> then it will configure the relevant VLAN. The Quantum service will >> be notified that the port is "UP" >> linuxbridge - the nova host that is deplying the VM will create the >> networkwork if it does not exist. If this fails the a VM will not be >> spawned. Once the network is up the agent will configure the VLAN. >> The quantum service will be notified that the port is "UP" >> >> The assumption is that the hosts will be configured correctly. If > I would like to have a clue - ahead of time - if that assumption is > valid. The two examples above require the host to notify the Quantum > service. But what if the host agent is notifying an utterly different > service? Is there some kind of liveliness check between the host and its > Quantum service? The communication between the host and the quantum service is done by a message broker. If the host is updating a different service then the port state will not be set as "UP" In grizzy a feature was added where one is able to get the state of the agents for example: openstack at dhcp-4-227:~/devstack$ quantum agent-list +--------------------------------------+--------------------+---------------------------+-------+----------------+ | id | agent_type | host | alive | admin_state_up | +--------------------------------------+--------------------+---------------------------+-------+----------------+ | 1ab54438-9338-4050-a818-7faf28d31eb2 | DHCP agent | dhcp-4-227.tlv.redhat.com | :-) | True | | 396f03eb-b3af-4ddf-b52f-6a0de65b0574 | L3 agent | dhcp-4-227.tlv.redhat.com | :-) | True | | 876c7474-9e2e-4533-a27e-1de8ac3544c6 | Open vSwitch agent | dhcp-4-227.tlv.redhat.com | :-) | True | +--------------------------------------+--------------------+---------------------------+-------+----------------+ If you get an XXX instead of a :) then the agent is down. The above is used for scheduling networks and routers to the dhcp and l3 agents respectively. Does this help? > >> not the the Quantum port will be "DOWN" (this can be detected via >> interfacing with the quantum service) >> >> In Grizzly things are complicated a little more as the hosts are >> also responsible for the configuartion of the security groups for >> the port in question. >> >> Hope that this helps unless I have completely misunderstood your question. >> >> Thanks >> Gary From mburns at redhat.com Fri Mar 22 12:26:21 2013 From: mburns at redhat.com (Mike Burns) Date: Fri, 22 Mar 2013 08:26:21 -0400 Subject: Missing SRPMS In-Reply-To: <514B2BEA.2080400@centos.org> References: <514B2BEA.2080400@centos.org> Message-ID: <514C4DED.3000008@redhat.com> On 03/21/2013 11:48 AM, Johnny Hughes wrote: > The ovirt-engine-3.2.1-1.beta1.el6.src.rpm is missing from: > > http://resources.ovirt.org/releases/3.2/rpm/EL/6/ > > As is the jboss-as-*.src.rpm. Ofer, can you get these uploaded? > > Thanks, > Johnny Hughes > > > > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > From wudxw at linux.vnet.ibm.com Mon Mar 25 10:06:14 2013 From: wudxw at linux.vnet.ibm.com (Mark Wu) Date: Mon, 25 Mar 2013 18:06:14 +0800 Subject: oVirt cluster level test proposal Message-ID: <51502196.6070508@linux.vnet.ibm.com> Hi guys, As per the discussion before, we don't have integrated functional tests for oVirt. So I would like to propose a cluster level test plan. Basically, it's composed of igord, cobbler and test cases based on engine REST api. Cobbler stores kickstart files, installation images and test packages repo. Igor is responsible to setup test environment according to the test plan and run the test cases inside test host. I write down a wiki page to describe the work flow: http://www.ovirt.org/Ovirt_cluster_level_test @Fabian, according to my investigation on igor, it should be not difficult to enhance igor to support this proposal. I would like to get your opinion on it. Any feedback will be appreciated. Mark. From bigclouds at 163.com Tue Mar 26 12:13:06 2013 From: bigclouds at 163.com (bigclouds) Date: Tue, 26 Mar 2013 20:13:06 +0800 (CST) Subject: proposal:supply a way to allow to change ethernet name. Message-ID: <1021657e.2b321.13da69db4ed.Coremail.bigclouds@163.com> hi,all i take the liberty of proposal a feature, give admin the opportunity to change ethernet name. my reasones: 1.modern server has several ethernets,but traditional ethernet naming scheme is hard for people to know what its name represent. 2.sometime ethernet name is unpredictable .for example ifc-xxxx is lost, having to change a new ethernet card. all those can lead confusion. thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From wudxw at linux.vnet.ibm.com Wed Mar 27 00:52:42 2013 From: wudxw at linux.vnet.ibm.com (Mark Wu) Date: Wed, 27 Mar 2013 08:52:42 +0800 Subject: proposal:supply a way to allow to change ethernet name. In-Reply-To: <1021657e.2b321.13da69db4ed.Coremail.bigclouds@163.com> References: <1021657e.2b321.13da69db4ed.Coremail.bigclouds@163.com> Message-ID: <515242DA.1070401@linux.vnet.ibm.com> On 03/26/2013 08:13 PM, bigclouds wrote: > hi,all > i take the liberty of proposal a feature, give admin the > opportunity to change ethernet name. > my reasones: > 1.modern server has several ethernets,but traditional ethernet naming > scheme is hard for people to know what its name represent. > 2.sometime ethernet name is unpredictable .for example ifc-xxxx is > lost, having to change a n ew ethernet card. all those can lead confusion. > > Are you talking about the same problem resolved by biosdevname developed by Dell? You could take a look at the following links to confirm it. http://linux.dell.com/files/whitepapers/consistent_network_device_naming_in_linux.pdf https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/appe-Consistent_Network_Device_Naming.html Mark > > thanks > > > > > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch -------------- next part -------------- An HTML attachment was scrubbed... URL: From asegurap at redhat.com Wed Mar 27 07:23:18 2013 From: asegurap at redhat.com (Antoni Segura Puimedon) Date: Wed, 27 Mar 2013 03:23:18 -0400 (EDT) Subject: proposal:supply a way to allow to change ethernet name. In-Reply-To: <515242DA.1070401@linux.vnet.ibm.com> Message-ID: <501864594.9293240.1364368998273.JavaMail.root@redhat.com> If I understand correctly, it would be about the ability to use the webadmin set names for the vnics, i.e., to write udev rules. ----- Original Message ----- > From: "Mark Wu" > To: "bigclouds" > Cc: arch at ovirt.org > Sent: Wednesday, March 27, 2013 1:52:42 AM > Subject: Re: proposal:supply a way to allow to change ethernet name. > > > > On 03/26/2013 08:13 PM, bigclouds wrote: > > > > > hi,all > i take the liberty of proposal a feature, give admin the opportunity > to change ethernet name. > my reasones: > 1.modern server has several ethernets,but traditional ethernet naming > scheme is hard for people to know what its name represent. > 2.sometime ethernet name is unpredictable .for example ifc-xxxx is > lost, having to change a n ew ethernet card. all those can lead > confusion. > > > > Are you talking about the same problem resolved by biosdevname > developed by Dell? > > You could take a look at the following links to confirm it. > http://linux.dell.com/files/whitepapers/consistent_network_device_naming_in_linux.pdf > https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/appe-Consistent_Network_Device_Naming.html > > Mark > > > > > > > > > thanks > > > > _______________________________________________ > 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 > From bigclouds at 163.com Wed Mar 27 11:02:26 2013 From: bigclouds at 163.com (bigclouds) Date: Wed, 27 Mar 2013 19:02:26 +0800 (CST) Subject: proposal:supply a way to allow to change ethernet name. In-Reply-To: <501864594.9293240.1364368998273.JavaMail.root@redhat.com> References: <501864594.9293240.1364368998273.JavaMail.root@redhat.com> Message-ID: <3f506eff.f53c.13dab83617e.Coremail.bigclouds@163.com> i mean HOST's(not guest) ethernet. Consistent Network Device Naming is what i proposal. if someone is working on implementing it in ovirt? thanks At 2013-03-27 15:23:18,"Antoni Segura Puimedon" wrote: >If I understand correctly, it would be about the ability to use the >webadmin set names for the vnics, i.e., to write udev rules. > >----- Original Message ----- >> From: "Mark Wu" >> To: "bigclouds" >> Cc: arch at ovirt.org >> Sent: Wednesday, March 27, 2013 1:52:42 AM >> Subject: Re: proposal:supply a way to allow to change ethernet name. >> >> >> >> On 03/26/2013 08:13 PM, bigclouds wrote: >> >> >> >> >> hi,all >> i take the liberty of proposal a feature, give admin the opportunity >> to change ethernet name. >> my reasones: >> 1.modern server has several ethernets,but traditional ethernet naming >> scheme is hard for people to know what its name represent. >> 2.sometime ethernet name is unpredictable .for example ifc-xxxx is >> lost, having to change a n ew ethernet card. all those can lead >> confusion. >> >> >> >> Are you talking about the same problem resolved by biosdevname >> developed by Dell? >> >> You could take a look at the following links to confirm it. >> http://linux.dell.com/files/whitepapers/consistent_network_device_naming_in_linux.pdf >> https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/appe-Consistent_Network_Device_Naming.html >> >> Mark >> >> >> >> >> >> >> >> >> thanks >> >> >> >> _______________________________________________ >> 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 >> >_______________________________________________ >Arch mailing list >Arch at ovirt.org >http://lists.ovirt.org/mailman/listinfo/arch -------------- next part -------------- An HTML attachment was scrubbed... URL: From asegurap at redhat.com Wed Mar 27 11:42:26 2013 From: asegurap at redhat.com (Antoni Segura Puimedon) Date: Wed, 27 Mar 2013 07:42:26 -0400 (EDT) Subject: proposal:supply a way to allow to change ethernet name. In-Reply-To: <3f506eff.f53c.13dab83617e.Coremail.bigclouds@163.com> Message-ID: <2119044838.9342223.1364384546738.JavaMail.root@redhat.com> Ah! Sorry I misunderstood. Well, as Mark said, the consistency is guaranteed by biosdevname, by Dell. AFAIK nobody has put any work on doing udev renaming for hosts. We'd have to see whether the community gets behind this and then try to come up with an API for that. ----- Original Message ----- > From: "bigclouds" > To: "Antoni Segura Puimedon" > Cc: arch at ovirt.org > Sent: Wednesday, March 27, 2013 12:02:26 PM > Subject: Re:Re: proposal:supply a way to allow to change ethernet name. > > > > i mean HOST's(not guest) ethernet. > Consistent Network Device Naming is what i proposal. > if someone is working on implementing it in ovirt? > > thanks > > > > > > > > At?2013-03-27?15:23:18,"Antoni?Segura?Puimedon"? > ?wrote: > >If?I?understand?correctly,?it?would?be?about?the?ability?to?use?the > >webadmin?set?names?for?the?vnics,?i.e.,?to?write?udev?rules. > > > >-----?Original?Message?----- > >>?From:?"Mark?Wu"? > >>?To:?"bigclouds"? > >>?Cc:?arch at ovirt.org > >>?Sent:?Wednesday,?March?27,?2013?1:52:42?AM > >>?Subject:?Re:?proposal:supply?a?way?to?allow?to?change?ethernet > >>??name. > >>? > >>? > >>? > >>?On?03/26/2013?08:13?PM,?bigclouds?wrote: > >>? > >>? > >>? > >>? > >>?hi,all > >>?i?take?the?liberty?of?proposal?a?feature,?give?admin?the > >>??opportunity > >>?to?change?ethernet?name. > >>?my?reasones: > >>?1.modern?server?has?several?ethernets,but?traditional?ethernet > >>??naming > >>?scheme?is?hard?for?people?to?know?what?its?name?represent. > >>?2.sometime?ethernet?name?is?unpredictable?.for?example?ifc-xxxx?is > >>?lost,?having?to?change?a?n?ew?ethernet?card.?all?those?can?lead > >>?confusion. > >>? > >>? > >>? > >>?Are?you?talking?about?the?same?problem?resolved?by?biosdevname > >>?developed?by?Dell? > >>? > >>?You?could?take?a?look?at?the?following?links?to?confirm?it. > >>?http://linux.dell.com/files/whitepapers/consistent_network_device_naming_in_linux.pdf > >>?https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/appe-Consistent_Network_Device_Naming.html > >>? > >>?Mark > >>? > >>? > >>? > >>? > >>? > >>? > >>? > >>? > >>?thanks > >>? > >>? > >>? > >>?_______________________________________________ > >>?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 > >>? > >_______________________________________________ > >Arch?mailing?list > >Arch at ovirt.org > >http://lists.ovirt.org/mailman/listinfo/arch > > From ehildesh at redhat.com Tue Mar 19 16:10:23 2013 From: ehildesh at redhat.com (Eldan Hildesheim) Date: Tue, 19 Mar 2013 16:10:23 -0000 Subject: [vdsm] Per device custom properties In-Reply-To: <20130319150644.GJ25513@redhat.com> Message-ID: <1311147937.21112602.1363709418888.JavaMail.root@redhat.com> Hello, I accept Dan's proposition, an updated mock up has been uploaded to the wiki. E. ----- Original Message ----- From: "Dan Kenigsberg" To: "Assaf Muller" , "Yair Zaslavsky" , "Eldan Hildesheim" , izikb at mellanox.com Cc: vdsm-devel at lists.fedorahosted.org, arch at ovirt.org Sent: Tuesday, March 19, 2013 5:06:44 PM Subject: Re: [vdsm] Per device custom properties adding arch at ovirt, as this feature is cross sub-project On Sun, Mar 17, 2013 at 09:50:20AM -0400, Assaf Muller wrote: > Hi all, > > Right now we have the ability to define VM-wide properties that may be > used by hooks. > It is time we have the same functionality on a device basis: > http://www.ovirt.org/Features/Device_Custom_Properties This feature page needs some love and attention. * I received a private communication about the suggested GUI: there should not be an independent vNIC action called "custom Properties" - the dialog for editing per-vNIC custom properties should be part of defining a new vNIC or editting an existing one. I believe Eldan (our GUI designer) concurs. * http://www.ovirt.org/Features/Device_Custom_Properties#Engine is rather lacking concrete details. Yair, could you improve it, as well as the completely empty REST section? > > For example: If the VM has 2 disks called disk1 and disk2, and two > NICs called nic1 and nic2, and the admin (From the engine) added a > custom property qos: 0.5 for nic1 and a custom property defrag: None > for disk2. When the VM is started we'll run a hook for nic1 with its > XML and qos: 0.5 added as an environment variable, and a hook for > disk2 with its XML and defrag: None. > > When a device is hot plugged and it has custom properties we'll run > that hook as well. > > Implementation-wise, hot plug/unplug for disks and NICs is dead simple > - vmCreate is more problematic: > If the user set a custom property called 'qos: 0.8' for nic3, I'd want > it exposed as an environment variable called 'qos' for hot plug nic > hooks, but for vmCreate I'd like to prefix the nic's alias. However, > when vmCreate is called we don't have the aliases for NICs and disks. > > The proposed solution is to create a new hook point called something > like: 'before_device_creation' that will be called before vmCreate. > We'll then call that hook specifically for devices that contains > custom properties, as described in the second paragraph of this mail. > > > I would love to hear smarter ideas before I move forward. Thanks! I find it quite intuitive, but I'd rather hear if it feats Izik's use case. Dan. From ItzikB at mellanox.com Wed Mar 20 07:17:16 2013 From: ItzikB at mellanox.com (Itzik Brown) Date: Wed, 20 Mar 2013 07:17:16 -0000 Subject: [vdsm] Per device custom properties In-Reply-To: <20130319150644.GJ25513@redhat.com> References: <262555909.46739874.1363523087978.JavaMail.root@redhat.com> <1264235091.46742390.1363528220157.JavaMail.root@redhat.com> <20130319150644.GJ25513@redhat.com> Message-ID: <4488206DC085244C886DBC9E7038B6897353BE06@MTLDAG02.mtl.com> Hi, I think that this feature is a good start for enabling vendor specific hints which apply to VM Network/Disk devices. There is a need to add migration hooks to the list. Itzik -----Original Message----- From: Dan Kenigsberg [mailto:danken at redhat.com] Sent: ????? 19 ??? 2013 17:12 To: Assaf Muller; Yair Zaslavsky; Eldan Hildesheim; izikb at mellanox.com Cc: vdsm-devel at lists.fedorahosted.org; arch at ovirt.org Subject: Re: [vdsm] Per device custom properties adding arch at ovirt, as this feature is cross sub-project On Sun, Mar 17, 2013 at 09:50:20AM -0400, Assaf Muller wrote: > Hi all, > > Right now we have the ability to define VM-wide properties that may be > used by hooks. > It is time we have the same functionality on a device basis: > http://www.ovirt.org/Features/Device_Custom_Properties This feature page needs some love and attention. * I received a private communication about the suggested GUI: there should not be an independent vNIC action called "custom Properties" - the dialog for editing per-vNIC custom properties should be part of defining a new vNIC or editting an existing one. I believe Eldan (our GUI designer) concurs. * http://www.ovirt.org/Features/Device_Custom_Properties#Engine is rather lacking concrete details. Yair, could you improve it, as well as the completely empty REST section? > > For example: If the VM has 2 disks called disk1 and disk2, and two > NICs called nic1 and nic2, and the admin (From the engine) added a > custom property qos: 0.5 for nic1 and a custom property defrag: None > for disk2. When the VM is started we'll run a hook for nic1 with its > XML and qos: 0.5 added as an environment variable, and a hook for > disk2 with its XML and defrag: None. > > When a device is hot plugged and it has custom properties we'll run > that hook as well. > > Implementation-wise, hot plug/unplug for disks and NICs is dead simple > - vmCreate is more problematic: > If the user set a custom property called 'qos: 0.8' for nic3, I'd want > it exposed as an environment variable called 'qos' for hot plug nic > hooks, but for vmCreate I'd like to prefix the nic's alias. However, > when vmCreate is called we don't have the aliases for NICs and disks. > > The proposed solution is to create a new hook point called something > like: 'before_device_creation' that will be called before vmCreate. > We'll then call that hook specifically for devices that contains > custom properties, as described in the second paragraph of this mail. > > > I would love to hear smarter ideas before I move forward. Thanks! I find it quite intuitive, but I'd rather hear if it feats Izik's use case. Dan.