From lpeer at redhat.com  Sun Apr  1 06:46:21 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Sun, 01 Apr 2012 09:46:21 +0300
Subject: Updates for the Fedora feature page
In-Reply-To: <4F775E76.20403@redhat.com>
References: <4F775E76.20403@redhat.com>
Message-ID: <4F77F9BD.4080903@redhat.com>

On 31/03/12 22:43, Juan Hernandez wrote:
> Hello,
> 
> It has been discussed and agreed in the latest sync meeting that the
> Fedora feature page needs to be updated. I would greatly appreciate your
> input on what needs to be improved, specially regarding ovirt-engine.
> 

Hi Juan,

I'll be happy to help but not sure what should be done.
I am looking at -

https://fedoraproject.org/wiki/Features/oVirt

Am I looking at the right page?
Which section do you think is lacking information?


Livnat


> Thanks in advance,
> Juan Hernandez
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch



From juan.hernandez at redhat.com  Sun Apr  1 09:28:25 2012
From: juan.hernandez at redhat.com (Juan Hernandez)
Date: Sun, 01 Apr 2012 11:28:25 +0200
Subject: Updates for the Fedora feature page
In-Reply-To: <4F77F9BD.4080903@redhat.com>
References: <4F775E76.20403@redhat.com> <4F77F9BD.4080903@redhat.com>
Message-ID: <4F781FB9.3050709@redhat.com>

On 04/01/2012 08:46 AM, Livnat Peer wrote:
> On 31/03/12 22:43, Juan Hernandez wrote:
>> Hello,
>>
>> It has been discussed and agreed in the latest sync meeting that the
>> Fedora feature page needs to be updated. I would greatly appreciate your
>> input on what needs to be improved, specially regarding ovirt-engine.
>>
> 
> Hi Juan,
> 
> I'll be happy to help but not sure what should be done.
> I am looking at -
> 
> https://fedoraproject.org/wiki/Features/oVirt
> 
> Am I looking at the right page?
> Which section do you think is lacking information?

Thanks Livnat. I believe that is the correct page.

In fact I don't know exactly what is missing. I opened this thread to
ask for clarifications about that, as it is not clear for me from the
meeting log/minutes:

[1] http://ovirt.org/meetings/ovirt/2012/ovirt.2012-03-28-15.01.html
[2] http://ovirt.org/meetings/ovirt/2012/ovirt.2012-03-28-15.01.log.html



From danken at redhat.com  Sun Apr  1 12:26:56 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Sun, 1 Apr 2012 15:26:56 +0300
Subject: ovirt bugzilla
In-Reply-To: <900df1c8-4179-4ee3-bc1e-2ebdd64b28b8@zmail07.collab.prod.int.phx2.redhat.com>
References: <20120330135058.GU31507@us.ibm.com>
	<900df1c8-4179-4ee3-bc1e-2ebdd64b28b8@zmail07.collab.prod.int.phx2.redhat.com>
Message-ID: <20120401122655.GJ20885@redhat.com>

On Fri, Mar 30, 2012 at 09:59:46AM -0400, Andrew Cathrow wrote:
> 
> 
> ----- Original Message -----
> > From: "Ryan Harper" <ryanh at us.ibm.com>
> > To: arch at ovirt.org
> > Sent: Friday, March 30, 2012 9:50:58 AM
> > Subject: ovirt bugzilla
> > 
> > Just going through some of the various bits of code and in the
> > man-page
> > documents, we've got:
> > 
> > Report bugs to <http://bugzilla.redhat.com>
> > 
> > Is the redhat bugzilla open enough to allow ovirt community folks to
> > file bugs against the ovirt release there? or should we think about
> > hosting a community bugzilla for the ovirt packages?
> 
> It's completely open.
> In bugzilla select "Community" then oVirt.

Correct. Note that recently, a Vdsm patch had referred to a non-public
multipath bug 805273. I have no idea why that bug was open non-public,
but that's besides the point, as multipath is not an ovirt component.

All non-security ovirt bugs should be open, and I believe they are.

Regards,
Dan.


From sgordon at redhat.com  Mon Apr  2 15:04:43 2012
From: sgordon at redhat.com (Steve Gordon)
Date: Mon, 02 Apr 2012 11:04:43 -0400 (EDT)
Subject: Updates for the Fedora feature page
In-Reply-To: <4F77F9BD.4080903@redhat.com>
Message-ID: <cbcad1c0-64b7-4f10-8cf9-0c3932eb0d4f@zmail15.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Livnat Peer" <lpeer at redhat.com>
> To: "Juan Hernandez" <juan.hernandez at redhat.com>
> Cc: arch at ovirt.org
> Sent: Sunday, April 1, 2012 2:46:21 AM
> Subject: Re: Updates for the Fedora feature page
> 
> On 31/03/12 22:43, Juan Hernandez wrote:
> > Hello,
> > 
> > It has been discussed and agreed in the latest sync meeting that
> > the
> > Fedora feature page needs to be updated. I would greatly appreciate
> > your
> > input on what needs to be improved, specially regarding
> > ovirt-engine.
> > 
> 
> Hi Juan,
> 
> I'll be happy to help but not sure what should be done.
> I am looking at -
> 
> https://fedoraproject.org/wiki/Features/oVirt
> 
> Am I looking at the right page?
> Which section do you think is lacking information?
> 
> 
> Livnat

Hi,

The feature is marked as targeting F17, my question was if (as listed) a number of packages have not yet been approved should it be changed to target F18 as the feature freeze for F17 was some time ago now. I am aware that there are no technical limitations to pushing packages into releases right up until they go EOL, but it is meant to be done with consideration for the updates policy. I'm not sure that is appropriate for something that has been proposed via the feature process to be pushed in this way (perhaps a question best asked on fedora-devel). 

As a side note as the feature appeared to be incomplete it is not mentioned in the release notes for Fedora 17, if we move to targeting F18 then - assuming it gets completed - it would appear in the release notes for that release.

Steve


From kwade at redhat.com  Wed Apr  4 16:00:34 2012
From: kwade at redhat.com (Karsten 'quaid' Wade)
Date: Wed, 04 Apr 2012 09:00:34 -0700
Subject: Meeting minutes :: Weekly sync 2011-04-04
Message-ID: <4F7C7022.6060303@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Minutes:
        http://ovirt.org/meetings/ovirt/2012/ovirt.2012-04-04-15.01.html

Minutes (text):
        http://ovirt.org/meetings/ovirt/2012/ovirt.2012-04-04-15.01.txt

Log:

http://ovirt.org/meetings/ovirt/2012/ovirt.2012-04-04-15.01.log.html


==============
#ovirt Meeting
==============


Meeting started by quaid at 15:01:05 UTC. The full logs are available at
http://ovirt.org/meetings/ovirt/2012/ovirt.2012-04-04-15.01.log.html .



Meeting summary
- ---------------
* Agenda  (quaid, 15:04:19)
  * LINK: http://www.ovirt.org/wiki/Meetings#Weekly_project_sync_meeting
    (quaid, 15:04:28)

* Meeting timing  (quaid, 15:06:15)
  * AGREED: Weekly meetings are a good thing, just make them quick if
    there isn't much to discuss  (quaid, 15:12:20)
  * AGREED: Keep meetings at 1400 UTC starting 11 Apr  (quaid, 15:12:36)
  * ACTION: quaid and rbergeron to sort out the mass invite  (quaid,
    15:13:07)
  * AGREED: Decide on DST plans in 4 months when it comes around again
    ...  (quaid, 15:13:28)
  * ACTION: quaid to circle with pilhuhn on an oVirt shared calendar,
    then get back to infra@ for approval  (quaid, 15:14:45)

* Release status  (quaid, 15:15:08)
  * ACTION: oschreib to take VDSM-libvirt-F17 target discussion to arch@
    (quaid, 15:31:14)
  * ACTION: oschreib to bring spec file changes decision to arch@
    (quaid, 15:42:43)
  * ACTION: oschreib to make sure sgordon_ has manual steps for upgrade
    for release notes  (quaid, 15:42:56)

* Infrastructure team  (quaid, 15:43:21)
  * ACTION: quaid to prepare thoughts about infra team for next meeting
    (quaid, 15:43:51)

* DCO for all sub-projects  (quaid, 15:44:34)
  * http://kerneltrap.org/files/Jeremy/DCO.txt  (rharper, 15:46:56)
  * ACTION: rharper Settle DCO topic on arch@  (quaid, 15:53:06)
  * AGREED: We don't see any objection to using DCO  (quaid, 15:53:17)

* Do we want some more formal information from sub-projects in the
  weekly sync?  (quaid, 15:54:40)
  * ACTION: quaid to pester arch@ to send a representative from each
    oVirt component project to the weekly sync  (quaid, 15:57:21)

* anything else?  (quaid, 15:57:43)

Meeting ended at 15:58:38 UTC.




Action Items
- ------------
* quaid and rbergeron to sort out the mass invite
* quaid to circle with pilhuhn on an oVirt shared calendar, then get
  back to infra@ for approval
* oschreib to take VDSM-libvirt-F17 target discussion to arch@
* oschreib to bring spec file changes decision to arch@
* oschreib to make sure sgordon_ has manual steps for upgrade for
  release notes
* quaid to prepare thoughts about infra team for next meeting
* rharper Settle DCO topic on arch@
* quaid to pester arch@ to send a representative from each oVirt
  component project to the weekly sync




Action Items, by person
- -----------------------
* oschreib
  * oschreib to take VDSM-libvirt-F17 target discussion to arch@
  * oschreib to bring spec file changes decision to arch@
  * oschreib to make sure sgordon_ has manual steps for upgrade for
    release notes
* quaid
  * quaid and rbergeron to sort out the mass invite
  * quaid to circle with pilhuhn on an oVirt shared calendar, then get
    back to infra@ for approval
  * quaid to prepare thoughts about infra team for next meeting
  * quaid to pester arch@ to send a representative from each oVirt
    component project to the weekly sync
* rharper
  * rharper Settle DCO topic on arch@
* sgordon_
  * oschreib to make sure sgordon_ has manual steps for upgrade for
    release notes
* **UNASSIGNED**
  * (none)




People Present (lines said)
- ---------------------------
* quaid (80)
* oschreib (41)
* mburns (34)
* rharper (23)
* abaron (13)
* ovirtbot (5)
* sgordon_ (4)
* READ10 (1)
* cdub (1)
* fsimonce (1)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot


- -- 
name:  Karsten 'quaid' Wade, Sr. Community Architect
team:    Red Hat Community Architecture & Leadership
uri:              http://communityleadershipteam.org
                         http://TheOpenSourceWay.org
gpg:                                        AD0E0C41
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFPfHAi2ZIOBq0ODEERAguPAJwMdvPh/WlxbPnq35aaDHCfibTaMACcCxAr
N65OEJdqZ84Arg0HHvNK+io=
=bnjl
-----END PGP SIGNATURE-----


From oschreib at redhat.com  Wed Apr  4 16:00:57 2012
From: oschreib at redhat.com (Ofer Schreiber)
Date: Wed, 04 Apr 2012 12:00:57 -0400 (EDT)
Subject: oVirt 3.1 targeted release platform
In-Reply-To: <5acfe2d6-e21e-48db-9eb6-6cf3b7939a9a@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <5e11a6c7-e831-40e2-a9cf-162af9374858@zmail14.collab.prod.int.phx2.redhat.com>

As discussed today in oVirt sync meeting (http://ovirt.org/meetings/ovirt/2012/ovirt.2012-04-04-15.01.log.html), upstream VDSM doesn't work anymore on Fedora 16 due to a missing libvirt dependency.

This issue raises an important question - which platform we're trying to target?
Since oVirt is a (very) layered product, I think we can't avoid setting a target platform for every oVirt release, and keep all the different components aligned with it.

Getting back to the next release- I'm suggesting Fedora 17 as our common platform.
According to https://fedoraproject.org/wiki/Releases/17/Schedule, Fedora 17 release date is the 15th of May, which align with the schedule for oVirt 3.1 (www.ovirt.org/wiki/Second_Release).

Thought/Comments?

Ofer Schreiber
oVirt Release Manager


From mburns at redhat.com  Wed Apr  4 16:11:58 2012
From: mburns at redhat.com (Mike Burns)
Date: Wed, 04 Apr 2012 12:11:58 -0400
Subject: oVirt 3.1 targeted release platform
In-Reply-To: <5e11a6c7-e831-40e2-a9cf-162af9374858@zmail14.collab.prod.int.phx2.redhat.com>
References: <5e11a6c7-e831-40e2-a9cf-162af9374858@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <1333555918.8380.80.camel@beelzebub.mburnsfire.net>

On Wed, 2012-04-04 at 12:00 -0400, Ofer Schreiber wrote:
> As discussed today in oVirt sync meeting (http://ovirt.org/meetings/ovirt/2012/ovirt.2012-04-04-15.01.log.html), upstream VDSM doesn't work anymore on Fedora 16 due to a missing libvirt dependency.
> 
> This issue raises an important question - which platform we're trying to target?
> Since oVirt is a (very) layered product, I think we can't avoid setting a target platform for every oVirt release, and keep all the different components aligned with it.
> 
> Getting back to the next release- I'm suggesting Fedora 17 as our common platform.
> According to https://fedoraproject.org/wiki/Releases/17/Schedule, Fedora 17 release date is the 15th of May, which align with the schedule for oVirt 3.1 (www.ovirt.org/wiki/Second_Release).

We should definitely settle on one recommended option for the release.
Going to F17 completely is one option, but there are a couple others.

There is a virt-preview repo that contains newer version of some
virtualization components.  So things like the newest libvirt would be
available on F16.  We can still support F16 and just require this be
available.  This may work, but it opens us up to possible problems with
f17 packages not working quite right on f16.

We can pull the F17 packages into our own ovirt.org repo as a hybrid
repo of f16+selected f17 packages.  This has a similar issue in that we
could run into problems with F17 packages on F16.

IMHO, I think we should just move completely to F17.  There is risk that
F17 doesn't ship when they plan to, or that we hit issues with other F17
packages that we're not expecting.  There is also the question of
upgrades.  Everything is F16 based now, if we require f17, what is the
upgrade path.

One other thing to consider is whether we can support Engine running on
F16 or F17 since it doesn't need vdsm running locally and require F17 on
ovirt-node or Fedora vdsm hosts.

Mike

> 
> Thought/Comments?
> 
> Ofer Schreiber
> oVirt Release Manager
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch




From acathrow at redhat.com  Wed Apr  4 16:50:33 2012
From: acathrow at redhat.com (Andrew Cathrow)
Date: Wed, 04 Apr 2012 12:50:33 -0400 (EDT)
Subject: oVirt 3.1 targeted release platform
In-Reply-To: <1333555918.8380.80.camel@beelzebub.mburnsfire.net>
Message-ID: <b317020e-9266-4738-b3f6-c3b58f865d72@zmail07.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Mike Burns" <mburns at redhat.com>
> To: "Ofer Schreiber" <oschreib at redhat.com>
> Cc: arch at ovirt.org
> Sent: Wednesday, April 4, 2012 12:11:58 PM
> Subject: Re: oVirt 3.1 targeted release platform
> 
> On Wed, 2012-04-04 at 12:00 -0400, Ofer Schreiber wrote:
> > As discussed today in oVirt sync meeting
> > (http://ovirt.org/meetings/ovirt/2012/ovirt.2012-04-04-15.01.log.html),
> > upstream VDSM doesn't work anymore on Fedora 16 due to a missing
> > libvirt dependency.
> > 
> > This issue raises an important question - which platform we're
> > trying to target?
> > Since oVirt is a (very) layered product, I think we can't avoid
> > setting a target platform for every oVirt release, and keep all
> > the different components aligned with it.
> > 
> > Getting back to the next release- I'm suggesting Fedora 17 as our
> > common platform.
> > According to https://fedoraproject.org/wiki/Releases/17/Schedule,
> > Fedora 17 release date is the 15th of May, which align with the
> > schedule for oVirt 3.1 (www.ovirt.org/wiki/Second_Release).
> 
> We should definitely settle on one recommended option for the
> release.
> Going to F17 completely is one option, but there are a couple others.
> 
> There is a virt-preview repo that contains newer version of some
> virtualization components.  So things like the newest libvirt would
> be
> available on F16.  We can still support F16 and just require this be
> available.  This may work, but it opens us up to possible problems
> with
> f17 packages not working quite right on f16.

virt-preview is currently not maintained and hasn't been updated for over a month

> 
> We can pull the F17 packages into our own ovirt.org repo as a hybrid
> repo of f16+selected f17 packages.  This has a similar issue in that
> we
> could run into problems with F17 packages on F16.
> 
> IMHO, I think we should just move completely to F17.  There is risk
> that
> F17 doesn't ship when they plan to, or that we hit issues with other
> F17
> packages that we're not expecting.  There is also the question of
> upgrades.  Everything is F16 based now, if we require f17, what is
> the
> upgrade path.

It's early days for F17, but if we require virt packages that aren't in F16 (or the last virt-preview update) then we might need to.
> 
> One other thing to consider is whether we can support Engine running
> on
> F16 or F17 since it doesn't need vdsm running locally and require F17
> on
> ovirt-node or Fedora vdsm hosts.
> 
> Mike
> 
> > 
> > Thought/Comments?
> > 
> > Ofer Schreiber
> > oVirt Release Manager
> > _______________________________________________
> > 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 cctrieloff at redhat.com  Wed Apr  4 17:14:15 2012
From: cctrieloff at redhat.com (Carl Trieloff)
Date: Wed, 04 Apr 2012 13:14:15 -0400
Subject: oVirt 3.1 targeted release platform
In-Reply-To: <5e11a6c7-e831-40e2-a9cf-162af9374858@zmail14.collab.prod.int.phx2.redhat.com>
References: <5e11a6c7-e831-40e2-a9cf-162af9374858@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <4F7C8167.7080800@redhat.com>



>From a users perspective, it would be best for it to work on both 16 &
17 for a period of time.

Carl.


On 04/04/2012 12:00 PM, Ofer Schreiber wrote:
> As discussed today in oVirt sync meeting (http://ovirt.org/meetings/ovirt/2012/ovirt.2012-04-04-15.01.log.html), upstream VDSM doesn't work anymore on Fedora 16 due to a missing libvirt dependency.
>
> This issue raises an important question - which platform we're trying to target?
> Since oVirt is a (very) layered product, I think we can't avoid setting a target platform for every oVirt release, and keep all the different components aligned with it.
>
> Getting back to the next release- I'm suggesting Fedora 17 as our common platform.
> According to https://fedoraproject.org/wiki/Releases/17/Schedule, Fedora 17 release date is the 15th of May, which align with the schedule for oVirt 3.1 (www.ovirt.org/wiki/Second_Release).
>
> Thought/Comments?
>
> Ofer Schreiber
> oVirt Release Manager
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch



From danken at redhat.com  Wed Apr  4 19:41:52 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Wed, 4 Apr 2012 22:41:52 +0300
Subject: oVirt 3.1 targeted release platform
In-Reply-To: <4F7C8167.7080800@redhat.com>
References: <5e11a6c7-e831-40e2-a9cf-162af9374858@zmail14.collab.prod.int.phx2.redhat.com>
	<4F7C8167.7080800@redhat.com>
Message-ID: <20120404194151.GA19923@redhat.com>

On Wed, Apr 04, 2012 at 01:14:15PM -0400, Carl Trieloff wrote:
> 
> 
> From a users perspective, it would be best for it to work on both 16 &
> 17 for a period of time.

I believe that this makes "it" a "them" - at lease for vdsm this would
require two rpms built and QAed. I hope we can avoid that, and release
only one stack, preferably over f17.

Note that even though vdsm's HEAD requires stuff that is out of f16,
the vdsm team could produce stable vdsm builds for whatever platform
that we choose.


From pmyers at redhat.com  Wed Apr  4 20:29:41 2012
From: pmyers at redhat.com (Perry Myers)
Date: Wed, 04 Apr 2012 16:29:41 -0400
Subject: oVirt 3.1 targeted release platform
In-Reply-To: <20120404194151.GA19923@redhat.com>
References: <5e11a6c7-e831-40e2-a9cf-162af9374858@zmail14.collab.prod.int.phx2.redhat.com>
	<4F7C8167.7080800@redhat.com> <20120404194151.GA19923@redhat.com>
Message-ID: <4F7CAF35.4080009@redhat.com>

On 04/04/2012 03:41 PM, Dan Kenigsberg wrote:
> On Wed, Apr 04, 2012 at 01:14:15PM -0400, Carl Trieloff wrote:
>>
>>
>> From a users perspective, it would be best for it to work on both 16 &
>> 17 for a period of time.
> 
> I believe that this makes "it" a "them" - at lease for vdsm this would
> require two rpms built and QAed. I hope we can avoid that, and release
> only one stack, preferably over f17.

What if we got virt-preview updated again so that it contained the right
packages so that the same version of vdsm would work on both:

* f16 + virt_preview
* f17

Then we can have oVirt Node built based on f16 + virt_preview for now,
and eventually move to pure f17.

Dave/Cole, is updating virt-preview something you guys can help with?

Perry

> Note that even though vdsm's HEAD requires stuff that is out of f16,
> the vdsm team could produce stable vdsm builds for whatever platform
> that we choose.
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch



From acathrow at redhat.com  Wed Apr  4 20:41:28 2012
From: acathrow at redhat.com (Andrew Cathrow)
Date: Wed, 04 Apr 2012 16:41:28 -0400 (EDT)
Subject: oVirt 3.1 targeted release platform
In-Reply-To: <4F7CAF35.4080009@redhat.com>
Message-ID: <fc68244e-68a5-4fb3-960b-860f92faed88@zmail07.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Perry Myers" <pmyers at redhat.com>
> To: "Dan Kenigsberg" <danken at redhat.com>
> Cc: arch at ovirt.org, "Cole Robinson" <crobinso at redhat.com>
> Sent: Wednesday, April 4, 2012 4:29:41 PM
> Subject: Re: oVirt 3.1 targeted release platform
> 
> On 04/04/2012 03:41 PM, Dan Kenigsberg wrote:
> > On Wed, Apr 04, 2012 at 01:14:15PM -0400, Carl Trieloff wrote:
> >>
> >>
> >> From a users perspective, it would be best for it to work on both
> >> 16 &
> >> 17 for a period of time.

anything we can do to enabled F16 and not require F17 will ease the transition.
> > 
> > I believe that this makes "it" a "them" - at lease for vdsm this
> > would
> > require two rpms built and QAed. I hope we can avoid that, and
> > release
> > only one stack, preferably over f17.
> 
> What if we got virt-preview updated again so that it contained the
> right
> packages so that the same version of vdsm would work on both:
> 
> * f16 + virt_preview
> * f17
> 
> Then we can have oVirt Node built based on f16 + virt_preview for
> now,
> and eventually move to pure f17.
> 
> Dave/Cole, is updating virt-preview something you guys can help with?
> 
> Perry
> 
> > Note that even though vdsm's HEAD requires stuff that is out of
> > f16,
> > the vdsm team could produce stable vdsm builds for whatever
> > platform
> > that we choose.
> > _______________________________________________
> > 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 dallan at redhat.com  Thu Apr  5 01:27:13 2012
From: dallan at redhat.com (Dave Allan)
Date: Wed, 4 Apr 2012 21:27:13 -0400
Subject: oVirt 3.1 targeted release platform
In-Reply-To: <4F7CAF35.4080009@redhat.com>
References: <5e11a6c7-e831-40e2-a9cf-162af9374858@zmail14.collab.prod.int.phx2.redhat.com>
	<4F7C8167.7080800@redhat.com> <20120404194151.GA19923@redhat.com>
	<4F7CAF35.4080009@redhat.com>
Message-ID: <20120405012713.GF2351@redhat.com>

On Wed, Apr 04, 2012 at 04:29:41PM -0400, Perry Myers wrote:
> On 04/04/2012 03:41 PM, Dan Kenigsberg wrote:
> > On Wed, Apr 04, 2012 at 01:14:15PM -0400, Carl Trieloff wrote:
> >>
> >>
> >> From a users perspective, it would be best for it to work on both 16 &
> >> 17 for a period of time.
> > 
> > I believe that this makes "it" a "them" - at lease for vdsm this would
> > require two rpms built and QAed. I hope we can avoid that, and release
> > only one stack, preferably over f17.
> 
> What if we got virt-preview updated again so that it contained the right
> packages so that the same version of vdsm would work on both:
> 
> * f16 + virt_preview
> * f17
> 
> Then we can have oVirt Node built based on f16 + virt_preview for now,
> and eventually move to pure f17.
> 
> Dave/Cole, is updating virt-preview something you guys can help with?

Sure, virt-preview is sorely due for an update, and this is good
motivation to do it.

Dave


> Perry
> 
> > Note that even though vdsm's HEAD requires stuff that is out of f16,
> > the vdsm team could produce stable vdsm builds for whatever platform
> > that we choose.
> > _______________________________________________
> > Arch mailing list
> > Arch at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> 


From iheim at redhat.com  Thu Apr  5 06:04:57 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 05 Apr 2012 09:04:57 +0300
Subject: oVirt 3.1 targeted release platform
In-Reply-To: <20120404194151.GA19923@redhat.com>
References: <5e11a6c7-e831-40e2-a9cf-162af9374858@zmail14.collab.prod.int.phx2.redhat.com>
	<4F7C8167.7080800@redhat.com> <20120404194151.GA19923@redhat.com>
Message-ID: <4F7D3609.1010900@redhat.com>

On 04/04/2012 10:41 PM, Dan Kenigsberg wrote:
> On Wed, Apr 04, 2012 at 01:14:15PM -0400, Carl Trieloff wrote:
>>
>>
>>  From a users perspective, it would be best for it to work on both 16&
>> 17 for a period of time.
>
> I believe that this makes "it" a "them" - at lease for vdsm this would
> require two rpms built and QAed. I hope we can avoid that, and release
> only one stack, preferably over f17.
>
> Note that even though vdsm's HEAD requires stuff that is out of f16,
> the vdsm team could produce stable vdsm builds for whatever platform
> that we choose.

need to see amount of overhead for engine side, as it will be moving to 
new jboss rpm's (which were just approved yesterday in f17).
I don't see anyone pushing jboss rpm's for f16 at this point, and need 
to see if makes sense to continue maintaining the ovirt-jboss rpm which 
was created as a temporary solution (and the setup support for it)



From ryanh at us.ibm.com  Fri Apr  6 15:00:15 2012
From: ryanh at us.ibm.com (Ryan Harper)
Date: Fri, 6 Apr 2012 10:00:15 -0500
Subject: code sign-off/DCO for ovirt projects
Message-ID: <20120406150015.GM25807@us.ibm.com>

Re-sending this to arch as in our meeting this week we agreed[1] no reason
to not implement DCO (http://kerneltrap.org/files/Jeremy/DCO.txt) but
that we needed to enlist the maintainers to work out enforcement.


1. http://lists.ovirt.org/pipermail/arch/2012-April/000433.html

----- Forwarded message from Ryan Harper <ryanh at us.ibm.com> -----

From: Ryan Harper <ryanh at us.ibm.com>
Subject: code sign-off/DCO for ovirt projects
Date: Tue, 3 Apr 2012 14:59:40 -0500
Message-ID: <20120403195940.GB5061 at us.ibm.com>
User-Agent: Mutt/1.5.6+20040907i
To: board at ovirt.org

I see that this was discussed in the past on the board list[1] and there
didn't seem to be any disagreement with doing DCO sign-off for code
contributions.  However, not all of the ovirt projects are doing
DCO/Sign-off.  There are a few commits in vdms.git that have a SoB,
ovirt-node seems to be using DCO completely.  Nothing in ovirt-engine
either.  I didn't check all of the ovirt subprojects, but I think
it's safe to assume that's not being applied across all of the
projects consistently.

Can we get that added to the commit process for these projects moving
forward? Is there anything else needed beyond maintainers enforcing the
need for SoB in patches?


1. http://lists.ovirt.org/pipermail/board/2011-October/000168.html

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh at us.ibm.com

----- End forwarded message -----

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh at us.ibm.com



From iheim at redhat.com  Fri Apr  6 22:00:27 2012
From: iheim at redhat.com (Itamar Heim)
Date: Sat, 07 Apr 2012 01:00:27 +0300
Subject: code sign-off/DCO for ovirt projects
In-Reply-To: <20120406150015.GM25807@us.ibm.com>
References: <20120406150015.GM25807@us.ibm.com>
Message-ID: <4F7F677B.3080408@redhat.com>

On 04/06/2012 06:00 PM, Ryan Harper wrote:
> Re-sending this to arch as in our meeting this week we agreed[1] no reason
> to not implement DCO (http://kerneltrap.org/files/Jeremy/DCO.txt) but
> that we needed to enlist the maintainers to work out enforcement.

that's easy enough since we use gerrit.
if acked by all, i can simply enable 'force sign-off' on patches option 
in gerrit and it will be enforced...

>
>
> 1. http://lists.ovirt.org/pipermail/arch/2012-April/000433.html
>
> ----- Forwarded message from Ryan Harper<ryanh at us.ibm.com>  -----
>
> From: Ryan Harper<ryanh at us.ibm.com>
> Subject: code sign-off/DCO for ovirt projects
> Date: Tue, 3 Apr 2012 14:59:40 -0500
> Message-ID:<20120403195940.GB5061 at us.ibm.com>
> User-Agent: Mutt/1.5.6+20040907i
> To: board at ovirt.org
>
> I see that this was discussed in the past on the board list[1] and there
> didn't seem to be any disagreement with doing DCO sign-off for code
> contributions.  However, not all of the ovirt projects are doing
> DCO/Sign-off.  There are a few commits in vdms.git that have a SoB,
> ovirt-node seems to be using DCO completely.  Nothing in ovirt-engine
> either.  I didn't check all of the ovirt subprojects, but I think
> it's safe to assume that's not being applied across all of the
> projects consistently.
>
> Can we get that added to the commit process for these projects moving
> forward? Is there anything else needed beyond maintainers enforcing the
> need for SoB in patches?
>
>
> 1. http://lists.ovirt.org/pipermail/board/2011-October/000168.html
>



From danken at redhat.com  Sun Apr  8 08:11:11 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Sun, 8 Apr 2012 11:11:11 +0300
Subject: code sign-off/DCO for ovirt projects
In-Reply-To: <4F7F677B.3080408@redhat.com>
References: <20120406150015.GM25807@us.ibm.com> <4F7F677B.3080408@redhat.com>
Message-ID: <20120408081111.GB6989@redhat.com>

On Sat, Apr 07, 2012 at 01:00:27AM +0300, Itamar Heim wrote:
> On 04/06/2012 06:00 PM, Ryan Harper wrote:
> >Re-sending this to arch as in our meeting this week we agreed[1] no reason
> >to not implement DCO (http://kerneltrap.org/files/Jeremy/DCO.txt) but
> >that we needed to enlist the maintainers to work out enforcement.
> 
> that's easy enough since we use gerrit.
> if acked by all, i can simply enable 'force sign-off' on patches
> option in gerrit and it will be enforced...
> 
> >
> >
> >1. http://lists.ovirt.org/pipermail/arch/2012-April/000433.html


I do not mind requring the make-my-lawyer-happy line in all Vdsm commits,
and I suppose that this would be fine by everybody on vdsm-devel. Tell
us when this takes effect, we'll prepare our commit-msg hooks by then.

Anything cooler we can do beyond putting

SOB=$(git var GIT_AUTHOR_IDENT | sed -n 's/^\(.*>\).*$/Signed-off-by: \1/p')
grep -qs "^$SOB" "$1" || echo "$SOB" >> "$1"

at the bottom of .git/hooks/commit-msg ?

> >
> >----- Forwarded message from Ryan Harper<ryanh at us.ibm.com>  -----
> >
> >From: Ryan Harper<ryanh at us.ibm.com>
> >Subject: code sign-off/DCO for ovirt projects
> >Date: Tue, 3 Apr 2012 14:59:40 -0500
> >Message-ID:<20120403195940.GB5061 at us.ibm.com>
> >User-Agent: Mutt/1.5.6+20040907i
> >To: board at ovirt.org
> >
> >I see that this was discussed in the past on the board list[1] and there
> >didn't seem to be any disagreement with doing DCO sign-off for code
> >contributions.  However, not all of the ovirt projects are doing
> >DCO/Sign-off.  There are a few commits in vdms.git that have a SoB,
> >ovirt-node seems to be using DCO completely.  Nothing in ovirt-engine
> >either.  I didn't check all of the ovirt subprojects, but I think
> >it's safe to assume that's not being applied across all of the
> >projects consistently.
> >
> >Can we get that added to the commit process for these projects moving
> >forward? Is there anything else needed beyond maintainers enforcing the
> >need for SoB in patches?
> >
> >
> >1. http://lists.ovirt.org/pipermail/board/2011-October/000168.html
> >
> 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch


From oschreib at redhat.com  Sun Apr  8 16:21:42 2012
From: oschreib at redhat.com (Ofer Schreiber)
Date: Sun, 08 Apr 2012 12:21:42 -0400 (EDT)
Subject: oVirt 3.1 targeted release platform
In-Reply-To: <4F7D3609.1010900@redhat.com>
Message-ID: <16f1704b-01b4-4ecf-8fb5-421658e4fa27@zmail14.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> On 04/04/2012 10:41 PM, Dan Kenigsberg wrote:
> > On Wed, Apr 04, 2012 at 01:14:15PM -0400, Carl Trieloff wrote:
> >>
> >>
> >>  From a users perspective, it would be best for it to work on both
> >>  16&
> >> 17 for a period of time.
> >
> > I believe that this makes "it" a "them" - at lease for vdsm this
> > would
> > require two rpms built and QAed. I hope we can avoid that, and
> > release
> > only one stack, preferably over f17.
> >
> > Note that even though vdsm's HEAD requires stuff that is out of
> > f16,
> > the vdsm team could produce stable vdsm builds for whatever
> > platform
> > that we choose.
> 
> need to see amount of overhead for engine side, as it will be moving
> to
> new jboss rpm's (which were just approved yesterday in f17).
> I don't see anyone pushing jboss rpm's for f16 at this point, and
> need
> to see if makes sense to continue maintaining the ovirt-jboss rpm
> which
> was created as a temporary solution (and the setup support for it)

Sounds like the reasonable decision would be:
1. Move to F17 (all components)
2. Consider using jboss official f17 rpms in the upcoming relase.

Any objections? (specifically, I'd like to get acks from the maintainers of ovirt-node, vdsm and engine)


> 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From danken at redhat.com  Sun Apr  8 16:32:10 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Sun, 8 Apr 2012 19:32:10 +0300
Subject: oVirt 3.1 targeted release platform
In-Reply-To: <16f1704b-01b4-4ecf-8fb5-421658e4fa27@zmail14.collab.prod.int.phx2.redhat.com>
References: <4F7D3609.1010900@redhat.com>
	<16f1704b-01b4-4ecf-8fb5-421658e4fa27@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <20120408163209.GH22328@redhat.com>

On Sun, Apr 08, 2012 at 12:21:42PM -0400, Ofer Schreiber wrote:
> 
> 
> ----- Original Message -----
> > On 04/04/2012 10:41 PM, Dan Kenigsberg wrote:
> > > On Wed, Apr 04, 2012 at 01:14:15PM -0400, Carl Trieloff wrote:
> > >>
> > >>
> > >>  From a users perspective, it would be best for it to work on both
> > >>  16&
> > >> 17 for a period of time.
> > >
> > > I believe that this makes "it" a "them" - at lease for vdsm this
> > > would
> > > require two rpms built and QAed. I hope we can avoid that, and
> > > release
> > > only one stack, preferably over f17.
> > >
> > > Note that even though vdsm's HEAD requires stuff that is out of
> > > f16,
> > > the vdsm team could produce stable vdsm builds for whatever
> > > platform
> > > that we choose.
> > 
> > need to see amount of overhead for engine side, as it will be moving
> > to
> > new jboss rpm's (which were just approved yesterday in f17).
> > I don't see anyone pushing jboss rpm's for f16 at this point, and
> > need
> > to see if makes sense to continue maintaining the ovirt-jboss rpm
> > which
> > was created as a temporary solution (and the setup support for it)
> 
> Sounds like the reasonable decision would be:
> 1. Move to F17 (all components)
> 2. Consider using jboss official f17 rpms in the upcoming relase.
> 
> Any objections? (specifically, I'd like to get acks from the maintainers of ovirt-node, vdsm and engine)

ACK from Vdsm - though Hunt Xu reported yesterday that vdsm does not
work on f17 due to considerable changed in ifconfig.
http://gerrit.ovirt.org/3361 . expect more surprises.


From eblake at redhat.com  Mon Apr  9 12:39:22 2012
From: eblake at redhat.com (Eric Blake)
Date: Mon, 09 Apr 2012 06:39:22 -0600
Subject: code sign-off/DCO for ovirt projects
In-Reply-To: <20120408081111.GB6989@redhat.com>
References: <20120406150015.GM25807@us.ibm.com> <4F7F677B.3080408@redhat.com>
	<20120408081111.GB6989@redhat.com>
Message-ID: <4F82D87A.60802@redhat.com>

On 04/08/2012 02:11 AM, Dan Kenigsberg wrote:

> Anything cooler we can do beyond putting
> 
> SOB=$(git var GIT_AUTHOR_IDENT | sed -n 's/^\(.*>\).*$/Signed-off-by: \1/p')
> grep -qs "^$SOB" "$1" || echo "$SOB" >> "$1"
> 
> at the bottom of .git/hooks/commit-msg ?

To fix 'git format-patch' (which is used by 'git send-email'), use:

git config format.signoff true

But that only adds it when you send a patch, not when you make the
commit.  You can also use 'git commit -s' to add the signoff when you
create the commit, but I don't know of a configuration bool that will
make that automatic, short of your hack on the commit-msg hook.

-- 
Eric Blake   eblake at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20120409/55ac7add/attachment.sig>

From sgordon at redhat.com  Mon Apr  9 13:21:55 2012
From: sgordon at redhat.com (Steve Gordon)
Date: Mon, 09 Apr 2012 09:21:55 -0400 (EDT)
Subject: [Users] make rpm error
In-Reply-To: <516e709e-0478-407f-ade7-e3c7fe93a24c@zmail01.collab.prod.int.phx2.redhat.com>
Message-ID: <43ef2f24-cc63-4543-9725-477ed4485429@zmail15.collab.prod.int.phx2.redhat.com>

----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "??????" <zorro at megatrone.ru>
> Cc: users at ovirt.org, "Steve Gordon" <sgordon at redhat.com>
> Sent: Friday, April 6, 2012 9:12:06 AM
> Subject: Re: [Users] make rpm error
> 
> Hi,
> 
> Jenkins is complaining about the same thing, I believe this is where
> it went wrong:
> http://jenkins.ovirt.org/job/ovirt_engine_create_rpms/191/
> 
> Related change:
> http://gerrit.ovirt.org/#patch,sidebyside,3337,2,packaging/fedora/spec/ovirt-engine.spec.in
> 
> Just guessing but maven is not installed on the OS, is that the
> problem?
> 
> Laszlo

Maven must be installed, otherwise builds would never work on it, but I am guessing it has been installed manually outside of the package manager otherwise this dependency would be met. 

CC'ing arch at ovirt.org:

How is maven installed on the jenkins host? Can we get it installed from RPMs?

Thanks,

Steve


From ryanh at us.ibm.com  Mon Apr  9 13:44:42 2012
From: ryanh at us.ibm.com (Ryan Harper)
Date: Mon, 9 Apr 2012 08:44:42 -0500
Subject: code sign-off/DCO for ovirt projects
In-Reply-To: <4F7F677B.3080408@redhat.com>
References: <20120406150015.GM25807@us.ibm.com> <4F7F677B.3080408@redhat.com>
Message-ID: <20120409134442.GT25807@us.ibm.com>

* Itamar Heim <iheim at redhat.com> [2012-04-06 17:01]:
> On 04/06/2012 06:00 PM, Ryan Harper wrote:
> >Re-sending this to arch as in our meeting this week we agreed[1] no reason
> >to not implement DCO (http://kerneltrap.org/files/Jeremy/DCO.txt) but
> >that we needed to enlist the maintainers to work out enforcement.
> 
> that's easy enough since we use gerrit.
> if acked by all, i can simply enable 'force sign-off' on patches option 
> in gerrit and it will be enforced...

Excellent!  Let me know when you've enabled the backend changes and I'll
confirm I'm seeing Signed-off-by's in the repos.  Let's see if we can
target by Wednesday this week; I'll add an update item to the ovirt irc
agenda to checkpoint.

Thanks everyone for getting this working!

Ryan


> 
> >
> >
> >1. http://lists.ovirt.org/pipermail/arch/2012-April/000433.html
> >
> >----- Forwarded message from Ryan Harper<ryanh at us.ibm.com>  -----
> >
> >From: Ryan Harper<ryanh at us.ibm.com>
> >Subject: code sign-off/DCO for ovirt projects
> >Date: Tue, 3 Apr 2012 14:59:40 -0500
> >Message-ID:<20120403195940.GB5061 at us.ibm.com>
> >User-Agent: Mutt/1.5.6+20040907i
> >To: board at ovirt.org
> >
> >I see that this was discussed in the past on the board list[1] and there
> >didn't seem to be any disagreement with doing DCO sign-off for code
> >contributions.  However, not all of the ovirt projects are doing
> >DCO/Sign-off.  There are a few commits in vdms.git that have a SoB,
> >ovirt-node seems to be using DCO completely.  Nothing in ovirt-engine
> >either.  I didn't check all of the ovirt subprojects, but I think
> >it's safe to assume that's not being applied across all of the
> >projects consistently.
> >
> >Can we get that added to the commit process for these projects moving
> >forward? Is there anything else needed beyond maintainers enforcing the
> >need for SoB in patches?
> >
> >
> >1. http://lists.ovirt.org/pipermail/board/2011-October/000168.html
> >

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh at us.ibm.com



From eedri at redhat.com  Mon Apr  9 13:56:08 2012
From: eedri at redhat.com (Eyal Edri)
Date: Mon, 09 Apr 2012 09:56:08 -0400 (EDT)
Subject: [Users] make rpm error
In-Reply-To: <43ef2f24-cc63-4543-9725-477ed4485429@zmail15.collab.prod.int.phx2.redhat.com>
Message-ID: <1aee9e06-c583-4075-b3be-46c019e477b4@zmail17.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Steve Gordon" <sgordon at redhat.com>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: "??????" <zorro at megatrone.ru>, arch at ovirt.org, users at ovirt.org
> Sent: Monday, April 9, 2012 4:21:55 PM
> Subject: Re: [Users] make rpm error
> 
> ----- Original Message -----
> > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > To: "??????" <zorro at megatrone.ru>
> > Cc: users at ovirt.org, "Steve Gordon" <sgordon at redhat.com>
> > Sent: Friday, April 6, 2012 9:12:06 AM
> > Subject: Re: [Users] make rpm error
> > 
> > Hi,
> > 
> > Jenkins is complaining about the same thing, I believe this is
> > where
> > it went wrong:
> > http://jenkins.ovirt.org/job/ovirt_engine_create_rpms/191/
> > 
> > Related change:
> > http://gerrit.ovirt.org/#patch,sidebyside,3337,2,packaging/fedora/spec/ovirt-engine.spec.in
> > 
> > Just guessing but maven is not installed on the OS, is that the
> > problem?
> > 
> > Laszlo
> 
> Maven must be installed, otherwise builds would never work on it, but
> I am guessing it has been installed manually outside of the package
> manager otherwise this dependency would be met.
> 
> CC'ing arch at ovirt.org:
> 
> How is maven installed on the jenkins host? Can we get it installed
> from RPMs?
> 

Jenkins doesn't install the maven package, but uses a mvn bin under $JENKINS_HOME/tools/$mvn_ver/bin/mvn.

I'm not sure that requiring the 'maven' rpm in the make is wise, than rather checking if 'mvn' can be run instead,
since this a standalone pkg that can be on os even without an rpm installed.

but for now, i can make sure all jenkins slaves have the 'maven' rpm installed to solve this issue.

eyal.


> Thanks,
> 
> Steve
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From sgordon at redhat.com  Mon Apr  9 14:21:47 2012
From: sgordon at redhat.com (Steve Gordon)
Date: Mon, 09 Apr 2012 10:21:47 -0400 (EDT)
Subject: [Users] make rpm error
In-Reply-To: <1aee9e06-c583-4075-b3be-46c019e477b4@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <c6462917-5f12-445b-beaf-aa2b78d631cf@zmail15.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Eyal Edri" <eedri at redhat.com>
> To: "Steve Gordon" <sgordon at redhat.com>
> Cc: "??????" <zorro at megatrone.ru>, arch at ovirt.org, users at ovirt.org, "Laszlo Hornyak" <lhornyak at redhat.com>, "Ofer
> Schreiber" <oschreib at redhat.com>, "infra" <infra at ovirt.org>
> Sent: Monday, April 9, 2012 9:56:08 AM
> Subject: Re: [Users] make rpm error
> 
> 
> 
> ----- Original Message -----
> > From: "Steve Gordon" <sgordon at redhat.com>
> > To: "Laszlo Hornyak" <lhornyak at redhat.com>
> > Cc: "??????" <zorro at megatrone.ru>, arch at ovirt.org, users at ovirt.org
> > Sent: Monday, April 9, 2012 4:21:55 PM
> > Subject: Re: [Users] make rpm error
> > 
> > ----- Original Message -----
> > > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > To: "??????" <zorro at megatrone.ru>
> > > Cc: users at ovirt.org, "Steve Gordon" <sgordon at redhat.com>
> > > Sent: Friday, April 6, 2012 9:12:06 AM
> > > Subject: Re: [Users] make rpm error
> > > 
> > > Hi,
> > > 
> > > Jenkins is complaining about the same thing, I believe this is
> > > where
> > > it went wrong:
> > > http://jenkins.ovirt.org/job/ovirt_engine_create_rpms/191/
> > > 
> > > Related change:
> > > http://gerrit.ovirt.org/#patch,sidebyside,3337,2,packaging/fedora/spec/ovirt-engine.spec.in
> > > 
> > > Just guessing but maven is not installed on the OS, is that the
> > > problem?
> > > 
> > > Laszlo
> > 
> > Maven must be installed, otherwise builds would never work on it,
> > but
> > I am guessing it has been installed manually outside of the package
> > manager otherwise this dependency would be met.
> > 
> > CC'ing arch at ovirt.org:
> > 
> > How is maven installed on the jenkins host? Can we get it installed
> > from RPMs?
> > 
> 
> Jenkins doesn't install the maven package, but uses a mvn bin under
> $JENKINS_HOME/tools/$mvn_ver/bin/mvn.
> 
> I'm not sure that requiring the 'maven' rpm in the make is wise, than
> rather checking if 'mvn' can be run instead,
> since this a standalone pkg that can be on os even without an rpm
> installed.

If that was actually a valid reason to not specify package requirements we would never specify any BuildRequires or Requires declarations in the spec file because the packages 'might' have been manually installed. Without this declaration the SRPM we are providing in the builds on ovirt.org can not be used to build in a clean environment such as that provided by mock. Note that this declaration was already in the version submitted to Fedora for review [1] because otherwise it would never pass...

> but for now, i can make sure all jenkins slaves have the 'maven' rpm
> installed to solve this issue.

Thanks.

Steve

[1] http://jhernand.fedorapeople.org/rpms/ovirt-engine/3.0.0_0001-6/ovirt-engine.spec


From iheim at redhat.com  Tue Apr 10 08:57:11 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 10 Apr 2012 11:57:11 +0300
Subject: code sign-off/DCO for ovirt projects
In-Reply-To: <20120408081111.GB6989@redhat.com>
References: <20120406150015.GM25807@us.ibm.com> <4F7F677B.3080408@redhat.com>
	<20120408081111.GB6989@redhat.com>
Message-ID: <4F83F5E7.50501@redhat.com>

top posting to make sure this is visible:
touched based with danken and enabled this for vdsm project.
if there are any issues/more time needed for adjustment, will disable 
and re-enable.

http://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html#Signed-off-by


On 04/08/2012 11:11 AM, Dan Kenigsberg wrote:
> On Sat, Apr 07, 2012 at 01:00:27AM +0300, Itamar Heim wrote:
>> On 04/06/2012 06:00 PM, Ryan Harper wrote:
>>> Re-sending this to arch as in our meeting this week we agreed[1] no reason
>>> to not implement DCO (http://kerneltrap.org/files/Jeremy/DCO.txt) but
>>> that we needed to enlist the maintainers to work out enforcement.
>>
>> that's easy enough since we use gerrit.
>> if acked by all, i can simply enable 'force sign-off' on patches
>> option in gerrit and it will be enforced...
>>
>>>
>>>
>>> 1. http://lists.ovirt.org/pipermail/arch/2012-April/000433.html
>
>
> I do not mind requring the make-my-lawyer-happy line in all Vdsm commits,
> and I suppose that this would be fine by everybody on vdsm-devel. Tell
> us when this takes effect, we'll prepare our commit-msg hooks by then.
>
> Anything cooler we can do beyond putting
>
> SOB=$(git var GIT_AUTHOR_IDENT | sed -n 's/^\(.*>\).*$/Signed-off-by: \1/p')
> grep -qs "^$SOB" "$1" || echo "$SOB">>  "$1"
>
> at the bottom of .git/hooks/commit-msg ?
>
>>>
>>> ----- Forwarded message from Ryan Harper<ryanh at us.ibm.com>   -----
>>>
>>> From: Ryan Harper<ryanh at us.ibm.com>
>>> Subject: code sign-off/DCO for ovirt projects
>>> Date: Tue, 3 Apr 2012 14:59:40 -0500
>>> Message-ID:<20120403195940.GB5061 at us.ibm.com>
>>> User-Agent: Mutt/1.5.6+20040907i
>>> To: board at ovirt.org
>>>
>>> I see that this was discussed in the past on the board list[1] and there
>>> didn't seem to be any disagreement with doing DCO sign-off for code
>>> contributions.  However, not all of the ovirt projects are doing
>>> DCO/Sign-off.  There are a few commits in vdms.git that have a SoB,
>>> ovirt-node seems to be using DCO completely.  Nothing in ovirt-engine
>>> either.  I didn't check all of the ovirt subprojects, but I think
>>> it's safe to assume that's not being applied across all of the
>>> projects consistently.
>>>
>>> Can we get that added to the commit process for these projects moving
>>> forward? Is there anything else needed beyond maintainers enforcing the
>>> need for SoB in patches?
>>>
>>>
>>> 1. http://lists.ovirt.org/pipermail/board/2011-October/000168.html
>>>
>>
>> _______________________________________________
>> Arch mailing list
>> Arch at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch



From mburns at redhat.com  Tue Apr 10 11:58:46 2012
From: mburns at redhat.com (Mike Burns)
Date: Tue, 10 Apr 2012 07:58:46 -0400
Subject: code sign-off/DCO for ovirt projects
In-Reply-To: <4F83F5E7.50501@redhat.com>
References: <20120406150015.GM25807@us.ibm.com>
	<4F7F677B.3080408@redhat.com> <20120408081111.GB6989@redhat.com>
	<4F83F5E7.50501@redhat.com>
Message-ID: <1334059126.4067.6.camel@mburns-laptop.usersys.redhat.com>

On Tue, 2012-04-10 at 11:57 +0300, Itamar Heim wrote:
> top posting to make sure this is visible:
> touched based with danken and enabled this for vdsm project.
> if there are any issues/more time needed for adjustment, will disable 
> and re-enable.
> 
> http://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html#Signed-off-by
> 

You can enable for the ovirt-node project as well.

Thanks

Mike

> 
> On 04/08/2012 11:11 AM, Dan Kenigsberg wrote:
> > On Sat, Apr 07, 2012 at 01:00:27AM +0300, Itamar Heim wrote:
> >> On 04/06/2012 06:00 PM, Ryan Harper wrote:
> >>> Re-sending this to arch as in our meeting this week we agreed[1] no reason
> >>> to not implement DCO (http://kerneltrap.org/files/Jeremy/DCO.txt) but
> >>> that we needed to enlist the maintainers to work out enforcement.
> >>
> >> that's easy enough since we use gerrit.
> >> if acked by all, i can simply enable 'force sign-off' on patches
> >> option in gerrit and it will be enforced...
> >>
> >>>
> >>>
> >>> 1. http://lists.ovirt.org/pipermail/arch/2012-April/000433.html
> >
> >
> > I do not mind requring the make-my-lawyer-happy line in all Vdsm commits,
> > and I suppose that this would be fine by everybody on vdsm-devel. Tell
> > us when this takes effect, we'll prepare our commit-msg hooks by then.
> >
> > Anything cooler we can do beyond putting
> >
> > SOB=$(git var GIT_AUTHOR_IDENT | sed -n 's/^\(.*>\).*$/Signed-off-by: \1/p')
> > grep -qs "^$SOB" "$1" || echo "$SOB">>  "$1"
> >
> > at the bottom of .git/hooks/commit-msg ?
> >
> >>>
> >>> ----- Forwarded message from Ryan Harper<ryanh at us.ibm.com>   -----
> >>>
> >>> From: Ryan Harper<ryanh at us.ibm.com>
> >>> Subject: code sign-off/DCO for ovirt projects
> >>> Date: Tue, 3 Apr 2012 14:59:40 -0500
> >>> Message-ID:<20120403195940.GB5061 at us.ibm.com>
> >>> User-Agent: Mutt/1.5.6+20040907i
> >>> To: board at ovirt.org
> >>>
> >>> I see that this was discussed in the past on the board list[1] and there
> >>> didn't seem to be any disagreement with doing DCO sign-off for code
> >>> contributions.  However, not all of the ovirt projects are doing
> >>> DCO/Sign-off.  There are a few commits in vdms.git that have a SoB,
> >>> ovirt-node seems to be using DCO completely.  Nothing in ovirt-engine
> >>> either.  I didn't check all of the ovirt subprojects, but I think
> >>> it's safe to assume that's not being applied across all of the
> >>> projects consistently.
> >>>
> >>> Can we get that added to the commit process for these projects moving
> >>> forward? Is there anything else needed beyond maintainers enforcing the
> >>> need for SoB in patches?
> >>>
> >>>
> >>> 1. http://lists.ovirt.org/pipermail/board/2011-October/000168.html
> >>>
> >>
> >> _______________________________________________
> >> 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 iheim at redhat.com  Tue Apr 10 13:00:05 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 10 Apr 2012 16:00:05 +0300
Subject: code sign-off/DCO for ovirt projects
In-Reply-To: <1334059126.4067.6.camel@mburns-laptop.usersys.redhat.com>
References: <20120406150015.GM25807@us.ibm.com> <4F7F677B.3080408@redhat.com>
	<20120408081111.GB6989@redhat.com> <4F83F5E7.50501@redhat.com>
	<1334059126.4067.6.camel@mburns-laptop.usersys.redhat.com>
Message-ID: <4F842ED5.5080205@redhat.com>

On 04/10/2012 02:58 PM, Mike Burns wrote:
> On Tue, 2012-04-10 at 11:57 +0300, Itamar Heim wrote:
>> top posting to make sure this is visible:
>> touched based with danken and enabled this for vdsm project.
>> if there are any issues/more time needed for adjustment, will disable
>> and re-enable.
>>
>> http://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html#Signed-off-by
>>
>
> You can enable for the ovirt-node project as well.

enabled for ovirt-node and ovirt-node-iso projects as well.


From ryanh at us.ibm.com  Tue Apr 10 13:13:43 2012
From: ryanh at us.ibm.com (Ryan Harper)
Date: Tue, 10 Apr 2012 08:13:43 -0500
Subject: code sign-off/DCO for ovirt projects
In-Reply-To: <4F83F5E7.50501@redhat.com>
References: <20120406150015.GM25807@us.ibm.com> <4F7F677B.3080408@redhat.com>
	<20120408081111.GB6989@redhat.com> <4F83F5E7.50501@redhat.com>
Message-ID: <20120410131343.GE5593@us.ibm.com>

* Itamar Heim <iheim at redhat.com> [2012-04-10 03:57]:
> top posting to make sure this is visible:
> touched based with danken and enabled this for vdsm project.
> if there are any issues/more time needed for adjustment, will disable 
> and re-enable.
> 
> http://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html#Signed-off-by

Excellent!  When would we enable this for the remaining ovirt-* projects?
(engine, cli, sdk, etc.)?


> 
> 
> On 04/08/2012 11:11 AM, Dan Kenigsberg wrote:
> >On Sat, Apr 07, 2012 at 01:00:27AM +0300, Itamar Heim wrote:
> >>On 04/06/2012 06:00 PM, Ryan Harper wrote:
> >>>Re-sending this to arch as in our meeting this week we agreed[1] no 
> >>>reason
> >>>to not implement DCO (http://kerneltrap.org/files/Jeremy/DCO.txt) but
> >>>that we needed to enlist the maintainers to work out enforcement.
> >>
> >>that's easy enough since we use gerrit.
> >>if acked by all, i can simply enable 'force sign-off' on patches
> >>option in gerrit and it will be enforced...
> >>
> >>>
> >>>
> >>>1. http://lists.ovirt.org/pipermail/arch/2012-April/000433.html
> >
> >
> >I do not mind requring the make-my-lawyer-happy line in all Vdsm commits,
> >and I suppose that this would be fine by everybody on vdsm-devel. Tell
> >us when this takes effect, we'll prepare our commit-msg hooks by then.
> >
> >Anything cooler we can do beyond putting
> >
> >SOB=$(git var GIT_AUTHOR_IDENT | sed -n 's/^\(.*>\).*$/Signed-off-by: 
> >\1/p')
> >grep -qs "^$SOB" "$1" || echo "$SOB">>  "$1"
> >
> >at the bottom of .git/hooks/commit-msg ?
> >
> >>>
> >>>----- Forwarded message from Ryan Harper<ryanh at us.ibm.com>   -----
> >>>
> >>>From: Ryan Harper<ryanh at us.ibm.com>
> >>>Subject: code sign-off/DCO for ovirt projects
> >>>Date: Tue, 3 Apr 2012 14:59:40 -0500
> >>>Message-ID:<20120403195940.GB5061 at us.ibm.com>
> >>>User-Agent: Mutt/1.5.6+20040907i
> >>>To: board at ovirt.org
> >>>
> >>>I see that this was discussed in the past on the board list[1] and there
> >>>didn't seem to be any disagreement with doing DCO sign-off for code
> >>>contributions.  However, not all of the ovirt projects are doing
> >>>DCO/Sign-off.  There are a few commits in vdms.git that have a SoB,
> >>>ovirt-node seems to be using DCO completely.  Nothing in ovirt-engine
> >>>either.  I didn't check all of the ovirt subprojects, but I think
> >>>it's safe to assume that's not being applied across all of the
> >>>projects consistently.
> >>>
> >>>Can we get that added to the commit process for these projects moving
> >>>forward? Is there anything else needed beyond maintainers enforcing the
> >>>need for SoB in patches?
> >>>
> >>>
> >>>1. http://lists.ovirt.org/pipermail/board/2011-October/000168.html
> >>>
> >>
> >>_______________________________________________
> >>Arch mailing list
> >>Arch at ovirt.org
> >>http://lists.ovirt.org/mailman/listinfo/arch

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh at us.ibm.com



From iheim at redhat.com  Tue Apr 10 13:18:47 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 10 Apr 2012 16:18:47 +0300
Subject: code sign-off/DCO for ovirt projects
In-Reply-To: <20120410131343.GE5593@us.ibm.com>
References: <20120406150015.GM25807@us.ibm.com> <4F7F677B.3080408@redhat.com>
	<20120408081111.GB6989@redhat.com> <4F83F5E7.50501@redhat.com>
	<20120410131343.GE5593@us.ibm.com>
Message-ID: <4F843337.2040905@redhat.com>

On 04/10/2012 04:13 PM, Ryan Harper wrote:
> * Itamar Heim<iheim at redhat.com>  [2012-04-10 03:57]:
>> top posting to make sure this is visible:
>> touched based with danken and enabled this for vdsm project.
>> if there are any issues/more time needed for adjustment, will disable
>> and re-enable.
>>
>> http://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html#Signed-off-by
>
> Excellent!  When would we enable this for the remaining ovirt-* projects?
> (engine, cli, sdk, etc.)?

i suggest asking on weekly call per project as it needs to sync 
(vdsm/ovirt-node with mostly a single maintainer easier to sync than engine)

>
>
>>
>>
>> On 04/08/2012 11:11 AM, Dan Kenigsberg wrote:
>>> On Sat, Apr 07, 2012 at 01:00:27AM +0300, Itamar Heim wrote:
>>>> On 04/06/2012 06:00 PM, Ryan Harper wrote:
>>>>> Re-sending this to arch as in our meeting this week we agreed[1] no
>>>>> reason
>>>>> to not implement DCO (http://kerneltrap.org/files/Jeremy/DCO.txt) but
>>>>> that we needed to enlist the maintainers to work out enforcement.
>>>>
>>>> that's easy enough since we use gerrit.
>>>> if acked by all, i can simply enable 'force sign-off' on patches
>>>> option in gerrit and it will be enforced...
>>>>
>>>>>
>>>>>
>>>>> 1. http://lists.ovirt.org/pipermail/arch/2012-April/000433.html
>>>
>>>
>>> I do not mind requring the make-my-lawyer-happy line in all Vdsm commits,
>>> and I suppose that this would be fine by everybody on vdsm-devel. Tell
>>> us when this takes effect, we'll prepare our commit-msg hooks by then.
>>>
>>> Anything cooler we can do beyond putting
>>>
>>> SOB=$(git var GIT_AUTHOR_IDENT | sed -n 's/^\(.*>\).*$/Signed-off-by:
>>> \1/p')
>>> grep -qs "^$SOB" "$1" || echo "$SOB">>   "$1"
>>>
>>> at the bottom of .git/hooks/commit-msg ?
>>>
>>>>>
>>>>> ----- Forwarded message from Ryan Harper<ryanh at us.ibm.com>    -----
>>>>>
>>>>> From: Ryan Harper<ryanh at us.ibm.com>
>>>>> Subject: code sign-off/DCO for ovirt projects
>>>>> Date: Tue, 3 Apr 2012 14:59:40 -0500
>>>>> Message-ID:<20120403195940.GB5061 at us.ibm.com>
>>>>> User-Agent: Mutt/1.5.6+20040907i
>>>>> To: board at ovirt.org
>>>>>
>>>>> I see that this was discussed in the past on the board list[1] and there
>>>>> didn't seem to be any disagreement with doing DCO sign-off for code
>>>>> contributions.  However, not all of the ovirt projects are doing
>>>>> DCO/Sign-off.  There are a few commits in vdms.git that have a SoB,
>>>>> ovirt-node seems to be using DCO completely.  Nothing in ovirt-engine
>>>>> either.  I didn't check all of the ovirt subprojects, but I think
>>>>> it's safe to assume that's not being applied across all of the
>>>>> projects consistently.
>>>>>
>>>>> Can we get that added to the commit process for these projects moving
>>>>> forward? Is there anything else needed beyond maintainers enforcing the
>>>>> need for SoB in patches?
>>>>>
>>>>>
>>>>> 1. http://lists.ovirt.org/pipermail/board/2011-October/000168.html
>>>>>
>>>>
>>>> _______________________________________________
>>>> Arch mailing list
>>>> Arch at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/arch
>



From eedri at redhat.com  Wed Apr 11 07:25:04 2012
From: eedri at redhat.com (Eyal Edri)
Date: Wed, 11 Apr 2012 03:25:04 -0400 (EDT)
Subject: Jenkins Support next week 15/04-18/04
In-Reply-To: <5596b014-d80c-4267-9434-4f5c26ead245@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <a1ac4ca5-b0a3-4e40-b2ae-8e8d92c51ca5@zmail17.collab.prod.int.phx2.redhat.com>

I will be OOO next week, for any urgent issues with jenkins.ovirt.org,
please contact infra at ovirt.org.


Eyal Edri
oVirt Infra Team


From oschreib at redhat.com  Wed Apr 11 14:33:49 2012
From: oschreib at redhat.com (Ofer Schreiber)
Date: Wed, 11 Apr 2012 10:33:49 -0400 (EDT)
Subject: Canceled: oVirt sync meeting (11.04.2012)
In-Reply-To: <6c962cac-2cb8-4eca-a0d7-861b49a647f8@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <89a7dec6-fedf-4a41-9a57-e2bcf8494e98@zmail14.collab.prod.int.phx2.redhat.com>

Due to low number of attendees, the weekly sync meeting [1] is canceled.

Happy holiday,

Ofer Schreiber
oVirt Release Manager

[1] Happens every Wednesday on 14:00 UTC, #ovirt irc channel (oftc)


From kwade at redhat.com  Wed Apr 11 15:47:55 2012
From: kwade at redhat.com (Karsten 'quaid' Wade)
Date: Wed, 11 Apr 2012 08:47:55 -0700
Subject: Weekly sync meeting timing (revisted)
Message-ID: <4F85A7AB.9000808@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

So we never really settled the discussion of whether or not to move
the meeting time with the adjustment for daylight savings.

As it happened, the meeting reminder was set to follow UTC, so for
many of us it moved on the calendar to an hour later. We've been
meeting at that time for some weeks, but it ends up leaving out people
in Tel Aviv who can't stick around the office past 6 pm.

Give a +1 below for what you'd prefer:

A. Follow the US daylight savings change, so the meeting moves to 1400
UTC starting next week (aka 10 am EDT, 7 am PDT)?

B. Stay following UTC, keeping the meeting time at 1500 UTC throughout
the year?

Whatever we decide will be the time we start next week.

- - Karsten
- -- 
name:  Karsten 'quaid' Wade, Sr. Community Architect
team:    Red Hat Community Architecture & Leadership
uri:              http://communityleadershipteam.org
                         http://TheOpenSourceWay.org
gpg:                                        AD0E0C41
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFPhaer2ZIOBq0ODEERAmREAKDGfdZc+jZGXHJs8rWds4c4OijtygCgkhDE
hNUHcI6/7Pt6ezy+avHVTbc=
=wBfB
-----END PGP SIGNATURE-----


From iheim at redhat.com  Wed Apr 11 20:55:06 2012
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 11 Apr 2012 23:55:06 +0300
Subject: Weekly sync meeting timing (revisted)
In-Reply-To: <4F85A7AB.9000808@redhat.com>
References: <4F85A7AB.9000808@redhat.com>
Message-ID: <4F85EFAA.9060004@redhat.com>

On 04/11/2012 06:47 PM, Karsten 'quaid' Wade wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> So we never really settled the discussion of whether or not to move
> the meeting time with the adjustment for daylight savings.
>
> As it happened, the meeting reminder was set to follow UTC, so for
> many of us it moved on the calendar to an hour later. We've been
> meeting at that time for some weeks, but it ends up leaving out people
> in Tel Aviv who can't stick around the office past 6 pm.
>
> Give a +1 below for what you'd prefer:
>
> A. Follow the US daylight savings change, so the meeting moves to 1400
> UTC starting next week (aka 10 am EDT, 7 am PDT)?

+1, as this means it moves with other meetings during the few weeks that 
need alignment

>
> B. Stay following UTC, keeping the meeting time at 1500 UTC throughout
> the year?

-1, since this means meeting is at a different hour for most of the 
world half of the year (I assume most of the world doing DST)

>
> Whatever we decide will be the time we start next week.
>
> - - Karsten
> - --
> name:  Karsten 'quaid' Wade, Sr. Community Architect
> team:    Red Hat Community Architecture&  Leadership
> uri:              http://communityleadershipteam.org
>                           http://TheOpenSourceWay.org
> gpg:                                        AD0E0C41
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iD8DBQFPhaer2ZIOBq0ODEERAmREAKDGfdZc+jZGXHJs8rWds4c4OijtygCgkhDE
> hNUHcI6/7Pt6ezy+avHVTbc=
> =wBfB
> -----END PGP SIGNATURE-----
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch



From abaron at redhat.com  Wed Apr 11 21:21:53 2012
From: abaron at redhat.com (Ayal Baron)
Date: Wed, 11 Apr 2012 17:21:53 -0400 (EDT)
Subject: Weekly sync meeting timing (revisted)
In-Reply-To: <4F85EFAA.9060004@redhat.com>
Message-ID: <f7583863-69a6-47ed-aa7f-c5703b7e7fca@zmail13.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> On 04/11/2012 06:47 PM, Karsten 'quaid' Wade wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > So we never really settled the discussion of whether or not to move
> > the meeting time with the adjustment for daylight savings.
> >
> > As it happened, the meeting reminder was set to follow UTC, so for
> > many of us it moved on the calendar to an hour later. We've been
> > meeting at that time for some weeks, but it ends up leaving out
> > people
> > in Tel Aviv who can't stick around the office past 6 pm.
> >
> > Give a +1 below for what you'd prefer:
> >
> > A. Follow the US daylight savings change, so the meeting moves to
> > 1400
> > UTC starting next week (aka 10 am EDT, 7 am PDT)?
> 
> +1, as this means it moves with other meetings during the few weeks
> that
> need alignment

+1

> 
> >
> > B. Stay following UTC, keeping the meeting time at 1500 UTC
> > throughout
> > the year?
> 
> -1, since this means meeting is at a different hour for most of the
> world half of the year (I assume most of the world doing DST)
> 
> >
> > Whatever we decide will be the time we start next week.
> >
> > - - Karsten
> > - --
> > name:  Karsten 'quaid' Wade, Sr. Community Architect
> > team:    Red Hat Community Architecture&  Leadership
> > uri:              http://communityleadershipteam.org
> >                           http://TheOpenSourceWay.org
> > gpg:                                        AD0E0C41
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.12 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> >
> > iD8DBQFPhaer2ZIOBq0ODEERAmREAKDGfdZc+jZGXHJs8rWds4c4OijtygCgkhDE
> > hNUHcI6/7Pt6ezy+avHVTbc=
> > =wBfB
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > 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 oschreib at redhat.com  Thu Apr 12 07:10:55 2012
From: oschreib at redhat.com (Ofer Schreiber)
Date: Thu, 12 Apr 2012 03:10:55 -0400 (EDT)
Subject: Weekly sync meeting timing (revisted)
In-Reply-To: <f7583863-69a6-47ed-aa7f-c5703b7e7fca@zmail13.collab.prod.int.phx2.redhat.com>
Message-ID: <520d2645-961f-4f39-a4b5-1cfafabdd3e9@zmail14.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> 
> 
> ----- Original Message -----
> > On 04/11/2012 06:47 PM, Karsten 'quaid' Wade wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > So we never really settled the discussion of whether or not to
> > > move
> > > the meeting time with the adjustment for daylight savings.
> > >
> > > As it happened, the meeting reminder was set to follow UTC, so
> > > for
> > > many of us it moved on the calendar to an hour later. We've been
> > > meeting at that time for some weeks, but it ends up leaving out
> > > people
> > > in Tel Aviv who can't stick around the office past 6 pm.
> > >
> > > Give a +1 below for what you'd prefer:
> > >
> > > A. Follow the US daylight savings change, so the meeting moves to
> > > 1400
> > > UTC starting next week (aka 10 am EDT, 7 am PDT)?
> > 
> > +1, as this means it moves with other meetings during the few weeks
> > that
> > need alignment
> 
> +1

+1

> 
> > 
> > >
> > > B. Stay following UTC, keeping the meeting time at 1500 UTC
> > > throughout
> > > the year?
> > 
> > -1, since this means meeting is at a different hour for most of the
> > world half of the year (I assume most of the world doing DST)
> > 
> > >
> > > Whatever we decide will be the time we start next week.
> > >
> > > - - Karsten
> > > - --
> > > name:  Karsten 'quaid' Wade, Sr. Community Architect
> > > team:    Red Hat Community Architecture&  Leadership
> > > uri:              http://communityleadershipteam.org
> > >                           http://TheOpenSourceWay.org
> > > gpg:                                        AD0E0C41
> > > -----BEGIN PGP SIGNATURE-----
> > > Version: GnuPG v1.4.12 (GNU/Linux)
> > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> > >
> > > iD8DBQFPhaer2ZIOBq0ODEERAmREAKDGfdZc+jZGXHJs8rWds4c4OijtygCgkhDE
> > > hNUHcI6/7Pt6ezy+avHVTbc=
> > > =wBfB
> > > -----END PGP SIGNATURE-----
> > > _______________________________________________
> > > 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 mburns at redhat.com  Thu Apr 12 11:16:51 2012
From: mburns at redhat.com (Mike Burns)
Date: Thu, 12 Apr 2012 07:16:51 -0400
Subject: Weekly sync meeting timing (revisted)
In-Reply-To: <520d2645-961f-4f39-a4b5-1cfafabdd3e9@zmail14.collab.prod.int.phx2.redhat.com>
References: <520d2645-961f-4f39-a4b5-1cfafabdd3e9@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <1334229411.3703.52.camel@beelzebub.mburnsfire.net>

On Thu, 2012-04-12 at 03:10 -0400, Ofer Schreiber wrote:
> 
> ----- Original Message -----
> > 
> > 
> > ----- Original Message -----
> > > On 04/11/2012 06:47 PM, Karsten 'quaid' Wade wrote:
> > > > -----BEGIN PGP SIGNED MESSAGE-----
> > > > Hash: SHA1
> > > >
> > > > So we never really settled the discussion of whether or not to
> > > > move
> > > > the meeting time with the adjustment for daylight savings.
> > > >
> > > > As it happened, the meeting reminder was set to follow UTC, so
> > > > for
> > > > many of us it moved on the calendar to an hour later. We've been
> > > > meeting at that time for some weeks, but it ends up leaving out
> > > > people
> > > > in Tel Aviv who can't stick around the office past 6 pm.
> > > >
> > > > Give a +1 below for what you'd prefer:
> > > >
> > > > A. Follow the US daylight savings change, so the meeting moves to
> > > > 1400
> > > > UTC starting next week (aka 10 am EDT, 7 am PDT)?
> > > 
> > > +1, as this means it moves with other meetings during the few weeks
> > > that
> > > need alignment
> > 
> > +1
> 
> +1

+1
> 
> > 
> > > 
> > > >
> > > > B. Stay following UTC, keeping the meeting time at 1500 UTC
> > > > throughout
> > > > the year?
> > > 
> > > -1, since this means meeting is at a different hour for most of the
> > > world half of the year (I assume most of the world doing DST)
> > > 
> > > >
> > > > Whatever we decide will be the time we start next week.
> > > >
> > > > - - Karsten
> > > > - --
> > > > name:  Karsten 'quaid' Wade, Sr. Community Architect
> > > > team:    Red Hat Community Architecture&  Leadership
> > > > uri:              http://communityleadershipteam.org
> > > >                           http://TheOpenSourceWay.org
> > > > gpg:                                        AD0E0C41
> > > > -----BEGIN PGP SIGNATURE-----
> > > > Version: GnuPG v1.4.12 (GNU/Linux)
> > > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> > > >
> > > > iD8DBQFPhaer2ZIOBq0ODEERAmREAKDGfdZc+jZGXHJs8rWds4c4OijtygCgkhDE
> > > > hNUHcI6/7Pt6ezy+avHVTbc=
> > > > =wBfB
> > > > -----END PGP SIGNATURE-----
> > > > _______________________________________________
> > > > 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
> > 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch




From piotr.baranowski at osec.pl  Thu Apr 12 12:27:42 2012
From: piotr.baranowski at osec.pl (Piotr Baranowski)
Date: Thu, 12 Apr 2012 14:27:42 +0200
Subject: Request for Comments/Suggestions/Improvements (and an initial "hello
	all!")
Message-ID: <4F86CA3E.6000009@osec.pl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello list!

I've been pointed to that list by Karsten Wade himself as the best
place to discuss my plan.

I'm Piotr Baranowski, RHCA instructor/examiner working for Red Hat GLS
in EMEA region. As I deliver RHCVA classess as well, I know oVirt/RHEV
pretty well :-)

What I wanted initially from Karsten was to get some info regarding
the workshop in Beijing.

I'm going to deliver a technical workshop at the infoshare conference
this year (19-20.04.2012 - www.infoshare.pl)

I'm looking for some suggestions/inspirations for my workshop and
Karsten suggested that the list will be probably the best place to
look for that info.

My initial plan is to conduct a BYOL session with Fedora 16 LiveCD
custom spin running on participants' laptops.

My idea is to prepare a bootable livecds (livecd-tools) and maybe a
PXE boot env to be launched on atendees laptops with ovirt-engine
preloaded and ready to be configured.

LiveCD would contain ovirt-engine and the audience would follow me
configuring their first datacenter, cluster, storage domains and maybe
use a tiny bootable.iso to run an initial VM.

How is that different from your approach in Beijing?

What do you think about my idea?

Feel free to comment. I'm really looking for your more or less
constructive input.

best regards
- -- 
Piotr Baranowski
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+Gyj4ACgkQTLozaNsAsHhVagCglMoKrTEIDGg0AdArYZjVCPXA
V98AnAlsasNiSKSrNd2LvHhtN82hBIvd
=trQs
-----END PGP SIGNATURE-----


From iheim at redhat.com  Fri Apr 13 05:11:45 2012
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 13 Apr 2012 08:11:45 +0300
Subject: Request for Comments/Suggestions/Improvements (and an initial
	"hello all!")
In-Reply-To: <4F86CA3E.6000009@osec.pl>
References: <4F86CA3E.6000009@osec.pl>
Message-ID: <4F87B591.2020605@redhat.com>

On 04/12/2012 03:27 PM, Piotr Baranowski wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello list!
>
> I've been pointed to that list by Karsten Wade himself as the best
> place to discuss my plan.
>
> I'm Piotr Baranowski, RHCA instructor/examiner working for Red Hat GLS
> in EMEA region. As I deliver RHCVA classess as well, I know oVirt/RHEV
> pretty well :-)
>
> What I wanted initially from Karsten was to get some info regarding
> the workshop in Beijing.
>
> I'm going to deliver a technical workshop at the infoshare conference
> this year (19-20.04.2012 - www.infoshare.pl)
>
> I'm looking for some suggestions/inspirations for my workshop and
> Karsten suggested that the list will be probably the best place to
> look for that info.
>
> My initial plan is to conduct a BYOL session with Fedora 16 LiveCD
> custom spin running on participants' laptops.
>
> My idea is to prepare a bootable livecds (livecd-tools) and maybe a
> PXE boot env to be launched on atendees laptops with ovirt-engine
> preloaded and ready to be configured.

sounds good - please do share the recipe later for others...
if people would boot this on physical machines, I'd consider using this 
as well:
http://www.ovirt.org/wiki/Feature/AllInOne

>
> LiveCD would contain ovirt-engine and the audience would follow me
> configuring their first datacenter, cluster, storage domains and maybe
> use a tiny bootable.iso to run an initial VM.
>
> How is that different from your approach in Beijing?

we did lectures and demo's, not a BYOL, and could not assume network 
access for participants.

>
> What do you think about my idea?

very nice!

>
> Feel free to comment. I'm really looking for your more or less
> constructive input.
>
> best regards
> - --
> Piotr Baranowski
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk+Gyj4ACgkQTLozaNsAsHhVagCglMoKrTEIDGg0AdArYZjVCPXA
> V98AnAlsasNiSKSrNd2LvHhtN82hBIvd
> =trQs
> -----END PGP SIGNATURE-----
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch



From piotr.baranowski at osec.pl  Fri Apr 13 10:13:12 2012
From: piotr.baranowski at osec.pl (Piotr Baranowski)
Date: Fri, 13 Apr 2012 12:13:12 +0200
Subject: Request for Comments/Suggestions/Improvements (and an initial
	"hello all!")
In-Reply-To: <4F87B591.2020605@redhat.com>
References: <4F86CA3E.6000009@osec.pl> <4F87B591.2020605@redhat.com>
Message-ID: <4F87FC38.9070609@osec.pl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

W dniu 13.04.2012 07:11, Itamar Heim pisze:
> On 04/12/2012 03:27 PM, Piotr Baranowski wrote:

> My initial plan is to conduct a BYOL session with Fedora 16 LiveCD 
> custom spin running on participants' laptops.
> 
> My idea is to prepare a bootable livecds (livecd-tools) and maybe
> a PXE boot env to be launched on atendees laptops with
> ovirt-engine preloaded and ready to be configured.
> 
>> sounds good - please do share the recipe later for others...

Once it's done I'm going to contribute my work for future re-use by
community members.

>> if people would boot this on physical machines, I'd consider
>> using this as well: http://www.ovirt.org/wiki/Feature/AllInOne

Sweet! I'll give it a try. Anyone knows if there is a prebuilt rpm
that's mentioned on tat wiki page?

> LiveCD would contain ovirt-engine and the audience would follow me 
> configuring their first datacenter, cluster, storage domains and
> maybe use a tiny bootable.iso to run an initial VM.
> 
> How is that different from your approach in Beijing?
> 
>> we did lectures and demo's, not a BYOL, and could not assume
>> network access for participants.

I'll let You all know how it worked.

> What do you think about my idea?
> 
>> very nice!
> 
> 
> Feel free to comment. I'm really looking for your more or less 
> constructive input.


I still hope to get more suggestions from that list. C'mon ppl! It's
in our common interest to start the spark of interest and my
conference is a very good opportunity to do that.

BTW: I'm going to share the stage with Bruce _THE GURU_ Schneier
himself

- -- 
Piotr Baranowski
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+H/DgACgkQTLozaNsAsHgqPgCfXR7ueDeh0RM4b8T9wvjAPOc4
lkoAnAtMk+2dvndRjH0tmryt69CJqUk/
=G6Dv
-----END PGP SIGNATURE-----


From iheim at redhat.com  Fri Apr 13 10:16:29 2012
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 13 Apr 2012 13:16:29 +0300
Subject: Request for Comments/Suggestions/Improvements (and an initial
	"hello all!")
In-Reply-To: <4F87FC38.9070609@osec.pl>
References: <4F86CA3E.6000009@osec.pl> <4F87B591.2020605@redhat.com>
	<4F87FC38.9070609@osec.pl>
Message-ID: <4F87FCFD.4080004@redhat.com>

On 04/13/2012 12:12 PM, Piotr Baranowski wrote:
...
 > I still hope to get more suggestions from that list. C'mon ppl! It's
 > in our common interest to start the spark of interest and my
 > conference is a very good opportunity to do that.

are you looking for content? flows? use cases?
did you review the various presentations in ovirt.org from previews 
workshops that walk through the project, etc.?


From piotr.baranowski at osec.pl  Fri Apr 13 12:28:07 2012
From: piotr.baranowski at osec.pl (Piotr Baranowski)
Date: Fri, 13 Apr 2012 14:28:07 +0200
Subject: Request for Comments/Suggestions/Improvements (and an initial
	"hello all!")
In-Reply-To: <4F87FCFD.4080004@redhat.com>
References: <4F86CA3E.6000009@osec.pl> <4F87B591.2020605@redhat.com>
	<4F87FC38.9070609@osec.pl> <4F87FCFD.4080004@redhat.com>
Message-ID: <4F881BD7.9090704@osec.pl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

W dniu 13.04.2012 12:16, Itamar Heim pisze:
> On 04/13/2012 12:12 PM, Piotr Baranowski wrote: ...
>> I still hope to get more suggestions from that list. C'mon ppl!
>> It's in our common interest to start the spark of interest and
>> my conference is a very good opportunity to do that.
> 
> are you looking for content? flows? use cases?

Content, conceptual examples, interesing facts, jaw dropping
features... :-)

Anything you know of that's both related to oVirt and interesting.
Blog sites, whitepapers etc.

Besides my tech workshop (90 minutes long) I'm going to deliver a 30m
tech-track talk covering interesting twists and turns in development
of rhev/ovirt development.

I wanted to describe ovirt's unusual history and impressive work done
by lpeer's team (conversion from C#/MsSQL/.NET -> Java/Psql/Jboss)

I also wanted to discuss project's interesing road from proprietary
product into free project.

I'm looking for that kind of facts that will make ovirt interesting to
conference audience.

My approach comes from the fact that if I were to show only
features/graphs/tables/comparisions, my presentation would be
sales-boring. I'm looking to create an interest in ovirt by going
unusual way.

> did you review the various presentations in ovirt.org from
> previews workshops that walk through the project, etc.?

I did it yesterday evening after contacting the list. Seems that I'll
have to glue those things together and produce a presentation.

If anyone has any interesting fact regarding the project's history I'd
appreciate that.

- -- 
Piotr Baranowski
VP - OSEC sp. z o.o.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+IG9cACgkQTLozaNsAsHhrFACbBBWBIEfS/dC4R9C1WIrmr7oh
M+UAoJnwaNJKDmGlIlTLv+tspbmlqBjE
=2qv3
-----END PGP SIGNATURE-----


From kwade at redhat.com  Fri Apr 13 20:49:38 2012
From: kwade at redhat.com (Karsten 'quaid' Wade)
Date: Fri, 13 Apr 2012 13:49:38 -0700
Subject: Request for Comments/Suggestions/Improvements (and an initial
	"hello all!")
In-Reply-To: <4F881BD7.9090704@osec.pl>
References: <4F86CA3E.6000009@osec.pl> <4F87B591.2020605@redhat.com>
	<4F87FC38.9070609@osec.pl> <4F87FCFD.4080004@redhat.com>
	<4F881BD7.9090704@osec.pl>
Message-ID: <4F889162.5030401@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/13/2012 05:28 AM, Piotr Baranowski wrote:

>> did you review the various presentations in ovirt.org from 
>> previews workshops that walk through the project, etc.?
> 
> I did it yesterday evening after contacting the list. Seems that
> I'll have to glue those things together and produce a
> presentation.

If this helps, here is my report on running through an earlier version
of the Ovirt-generic.odp slides:

http://iquaid.org/2012/01/31/report-and-presentation-materials-for-ovirt-infrastructure-and-management-platform-for-the-datacenter/

> If anyone has any interesting fact regarding the project's history
> I'd appreciate that.

My experience starts right before the open sourcing, and the bits I
found interesting (governance, how open sourcing occurred, etc.) are
in the generic presentation. In particular, I think it's valuable to
note the efforts of the project to allow people to participate
everywhere, not just in the code - infrastructure, documentation,
evangelism, etc. - right from the beginning.

- - Karsten
- -- 
name:  Karsten 'quaid' Wade, Sr. Community Architect
team:    Red Hat Community Architecture & Leadership
uri:              http://communityleadershipteam.org
                         http://TheOpenSourceWay.org
gpg:                                        AD0E0C41
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFPiJFi2ZIOBq0ODEERAhgOAKCjpu/GqHkVt6eQD5EW/aHYN6UzhwCgqbfY
5/Y/Jdk/Ms6RTryVI2BuA0M=
=lT9a
-----END PGP SIGNATURE-----


From lpeer at redhat.com  Sun Apr 15 07:42:27 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Sun, 15 Apr 2012 10:42:27 +0300
Subject: Weekly sync meeting timing (revisted)
In-Reply-To: <1334229411.3703.52.camel@beelzebub.mburnsfire.net>
References: <520d2645-961f-4f39-a4b5-1cfafabdd3e9@zmail14.collab.prod.int.phx2.redhat.com>
	<1334229411.3703.52.camel@beelzebub.mburnsfire.net>
Message-ID: <4F8A7BE3.5040506@redhat.com>

On 12/04/12 14:16, Mike Burns wrote:
> On Thu, 2012-04-12 at 03:10 -0400, Ofer Schreiber wrote:
>>
>> ----- Original Message -----
>>>
>>>
>>> ----- Original Message -----
>>>> On 04/11/2012 06:47 PM, Karsten 'quaid' Wade wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> So we never really settled the discussion of whether or not to
>>>>> move
>>>>> the meeting time with the adjustment for daylight savings.
>>>>>
>>>>> As it happened, the meeting reminder was set to follow UTC, so
>>>>> for
>>>>> many of us it moved on the calendar to an hour later. We've been
>>>>> meeting at that time for some weeks, but it ends up leaving out
>>>>> people
>>>>> in Tel Aviv who can't stick around the office past 6 pm.
>>>>>
>>>>> Give a +1 below for what you'd prefer:
>>>>>
>>>>> A. Follow the US daylight savings change, so the meeting moves to
>>>>> 1400
>>>>> UTC starting next week (aka 10 am EDT, 7 am PDT)?
>>>>
>>>> +1, as this means it moves with other meetings during the few weeks
>>>> that
>>>> need alignment
>>>
>>> +1
>>
>> +1
> 
> +1

+1

>>
>>>
>>>>
>>>>>
>>>>> B. Stay following UTC, keeping the meeting time at 1500 UTC
>>>>> throughout
>>>>> the year?
>>>>
>>>> -1, since this means meeting is at a different hour for most of the
>>>> world half of the year (I assume most of the world doing DST)
>>>>
>>>>>
>>>>> Whatever we decide will be the time we start next week.
>>>>>
>>>>> - - Karsten
>>>>> - --
>>>>> name:  Karsten 'quaid' Wade, Sr. Community Architect
>>>>> team:    Red Hat Community Architecture&  Leadership
>>>>> uri:              http://communityleadershipteam.org
>>>>>                           http://TheOpenSourceWay.org
>>>>> gpg:                                        AD0E0C41
>>>>> -----BEGIN PGP SIGNATURE-----
>>>>> Version: GnuPG v1.4.12 (GNU/Linux)
>>>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>>>>
>>>>> iD8DBQFPhaer2ZIOBq0ODEERAmREAKDGfdZc+jZGXHJs8rWds4c4OijtygCgkhDE
>>>>> hNUHcI6/7Pt6ezy+avHVTbc=
>>>>> =wBfB
>>>>> -----END PGP SIGNATURE-----
>>>>> _______________________________________________
>>>>> 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
>>>
>> _______________________________________________
>> 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 sanjal at redhat.com  Tue Apr 17 10:08:25 2012
From: sanjal at redhat.com (Shireesh Anjal)
Date: Tue, 17 Apr 2012 15:38:25 +0530
Subject: Storage Device Management in VDSM and oVirt
Message-ID: <4F8D4119.80901@redhat.com>

Hi all,

As part of adding Gluster support in ovirt, we need to introduce some 
Storage Device management capabilities (on the host). Since these are 
quite generic and not specific to Gluster as such, we think it might be 
useful to add it as a core vdsm and oVirt feature. At a high level, this 
involves following:

  - A "Storage Devices" sub-tab on "Host" entity, displaying information 
about all the storage devices*
  - Listing of different types of storage devices of a host
     - Regular Disks and Partitions*
     - LVM*
     - Software RAID*
  - Various actions related to device configuration
     - Partition disks*
     - Format and mount disks / partitions*
     - Create, resize and delete LVM Volume Groups (VGs)
     - Create, resize, delete, format and mount LVM Logical Volumes (LVs)
     - Create, resize, delete, partition, format and mount Software RAID 
devices
  - Edit properties of the devices
  - UI can be modeled similar to the system-config-lvm tool

The items marked with (*) in above list are urgently required for the 
Gluster feature, and will be developed first.

Comments / inputs welcome.

Thanks,
Shireesh


From ykaul at redhat.com  Tue Apr 17 11:06:40 2012
From: ykaul at redhat.com (Yaniv Kaul)
Date: Tue, 17 Apr 2012 14:06:40 +0300
Subject: Storage Device Management in VDSM and oVirt
In-Reply-To: <4F8D4119.80901@redhat.com>
References: <4F8D4119.80901@redhat.com>
Message-ID: <4F8D4EC0.9050506@redhat.com>

On 04/17/2012 01:08 PM, Shireesh Anjal wrote:
> Hi all,
>
> As part of adding Gluster support in ovirt, we need to introduce some 
> Storage Device management capabilities (on the host). Since these are 
> quite generic and not specific to Gluster as such, we think it might 
> be useful to add it as a core vdsm and oVirt feature. At a high level, 
> this involves following:
>
>  - A "Storage Devices" sub-tab on "Host" entity, displaying 
> information about all the storage devices*
>  - Listing of different types of storage devices of a host
>     - Regular Disks and Partitions*
>     - LVM*
>     - Software RAID*
>  - Various actions related to device configuration
>     - Partition disks*
>     - Format and mount disks / partitions*
>     - Create, resize and delete LVM Volume Groups (VGs)
>     - Create, resize, delete, format and mount LVM Logical Volumes (LVs)
>     - Create, resize, delete, partition, format and mount Software 
> RAID devices
>  - Edit properties of the devices
>  - UI can be modeled similar to the system-config-lvm tool
>
> The items marked with (*) in above list are urgently required for the 
> Gluster feature, and will be developed first.
>
> Comments / inputs welcome.
>
> Thanks,
> Shireesh
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch

Anything we can share with rtslib ( 
http://www.risingtidesystems.com/doc/rtslib/html/) which is the API 
behind targetcli which is the CLI for LIO (linux-iscsi.org) target, 
which is in Linux kernel now) ?
They have some VERY basic LV and VG handling.
Y.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20120417/76f382b5/attachment.html>

From oschreib at redhat.com  Tue Apr 17 13:20:49 2012
From: oschreib at redhat.com (Ofer Schreiber)
Date: Tue, 17 Apr 2012 09:20:49 -0400 (EDT)
Subject: ovirt-engine deployment method
In-Reply-To: <4d56528a-2eb6-48da-ab71-0c66bdeabab7@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <0d88e373-f795-46cc-a63b-cef942edf5a0@zmail14.collab.prod.int.phx2.redhat.com>

As decided earlier, oVirt next release (3.1) is targeted for Fedora 17.
Since the engine uses JBoss, we have two deployment options:
1. Continue working with ovirt-engine-jbossas package
   PROS: Single rpm. known upgrade method.
   CONS: Maintaining un-natural zip based rpm. No official support. Can't be pushed into Fedora.

2. Move to JBoss F17 official packages:
   PROS: Fully supported F17 rpms (including bug fixes, security fixes, etc). "The right thing to do".
   CONS: Upgrade from first release (relaying on old jboss) will be almost impossible, Some open issues (will it work just as as normal service? or will we need to code a new one?), Might cause a delay to Feature Freeze.

Thought? Comments?
Share them with us!
---
Ofer Schreiber
oVirt Release Manager


From mburns at redhat.com  Tue Apr 17 13:31:38 2012
From: mburns at redhat.com (Mike Burns)
Date: Tue, 17 Apr 2012 09:31:38 -0400
Subject: ovirt-engine deployment method
In-Reply-To: <0d88e373-f795-46cc-a63b-cef942edf5a0@zmail14.collab.prod.int.phx2.redhat.com>
References: <0d88e373-f795-46cc-a63b-cef942edf5a0@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <1334669498.3279.67.camel@beelzebub.mburnsfire.net>

On Tue, 2012-04-17 at 09:20 -0400, Ofer Schreiber wrote:
> As decided earlier, oVirt next release (3.1) is targeted for Fedora
> 17.
> Since the engine uses JBoss, we have two deployment options:
> 1. Continue working with ovirt-engine-jbossas package
>    PROS: Single rpm. known upgrade method.
>    CONS: Maintaining un-natural zip based rpm. No official support.
> Can't be pushed into Fedora.
> 
> 2. Move to JBoss F17 official packages:
>    PROS: Fully supported F17 rpms (including bug fixes, security
> fixes, etc). "The right thing to do".
>    CONS: Upgrade from first release (relaying on old jboss) will be
> almost impossible, Some open issues (will it work just as as normal
> service? or will we need to code a new one?), Might cause a delay to
> Feature Freeze.

Quick thoughts -- this will come up for every release until we decide on
#2.  The con for #2 will always be there until we finally switch over.
I think it's less impact to have a more manual upgrade between release 1
and 2 than between later releases.  

As long as we can provide at least a manual upgrade process with well
defined steps so that the early adopters don't have to re-create their
environments, I think we should go with #2.

Mike

> 
> Thought? Comments?
> Share them with us!
> ---
> Ofer Schreiber
> oVirt Release Manager
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch




From iheim at redhat.com  Tue Apr 17 14:02:17 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 17 Apr 2012 17:02:17 +0300
Subject: ovirt-engine deployment method
In-Reply-To: <0d88e373-f795-46cc-a63b-cef942edf5a0@zmail14.collab.prod.int.phx2.redhat.com>
References: <0d88e373-f795-46cc-a63b-cef942edf5a0@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <4F8D77E9.4060906@redhat.com>

On 04/17/2012 04:20 PM, Ofer Schreiber wrote:
> As decided earlier, oVirt next release (3.1) is targeted for Fedora 17.
> Since the engine uses JBoss, we have two deployment options:
> 1. Continue working with ovirt-engine-jbossas package
>     PROS: Single rpm. known upgrade method.
>     CONS: Maintaining un-natural zip based rpm. No official support. Can't be pushed into Fedora.
>
> 2. Move to JBoss F17 official packages:
>     PROS: Fully supported F17 rpms (including bug fixes, security fixes, etc). "The right thing to do".
>     CONS: Upgrade from first release (relaying on old jboss) will be almost impossible, Some open issues (will it work just as as normal service? or will we need to code a new one?), Might cause a delay to Feature Freeze.
>
> Thought? Comments?

we also want to push this version of ovirt into fedora (3.0 already in), 
which will require the native jboss rpms?

> Share them with us!
> ---
> Ofer Schreiber
> oVirt Release Manager
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch



From iheim at redhat.com  Tue Apr 17 14:30:27 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 17 Apr 2012 17:30:27 +0300
Subject: [Engine-devel] ovirt-engine deployment method
In-Reply-To: <1334669498.3279.67.camel@beelzebub.mburnsfire.net>
References: <0d88e373-f795-46cc-a63b-cef942edf5a0@zmail14.collab.prod.int.phx2.redhat.com>
	<1334669498.3279.67.camel@beelzebub.mburnsfire.net>
Message-ID: <4F8D7E83.3040303@redhat.com>

On 04/17/2012 04:31 PM, Mike Burns wrote:
> On Tue, 2012-04-17 at 09:20 -0400, Ofer Schreiber wrote:
>> As decided earlier, oVirt next release (3.1) is targeted for Fedora
>> 17.
>> Since the engine uses JBoss, we have two deployment options:
>> 1. Continue working with ovirt-engine-jbossas package
>>     PROS: Single rpm. known upgrade method.
>>     CONS: Maintaining un-natural zip based rpm. No official support.
>> Can't be pushed into Fedora.
>>
>> 2. Move to JBoss F17 official packages:
>>     PROS: Fully supported F17 rpms (including bug fixes, security
>> fixes, etc). "The right thing to do".
>>     CONS: Upgrade from first release (relaying on old jboss) will be
>> almost impossible, Some open issues (will it work just as as normal
>> service? or will we need to code a new one?), Might cause a delay to
>> Feature Freeze.
>
> Quick thoughts -- this will come up for every release until we decide on
> #2.  The con for #2 will always be there until we finally switch over.
> I think it's less impact to have a more manual upgrade between release 1
> and 2 than between later releases.
>
> As long as we can provide at least a manual upgrade process with well
> defined steps so that the early adopters don't have to re-create their
> environments, I think we should go with #2.

+1


From oschreib at redhat.com  Wed Apr 18 07:51:55 2012
From: oschreib at redhat.com (Ofer Schreiber)
Date: Wed, 18 Apr 2012 03:51:55 -0400 (EDT)
Subject: Jar versions in ovirt-engine
In-Reply-To: <532542d4-8baf-4e1b-bd59-d0a26a805117@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <b9695739-c850-4a7f-8283-d0dd506e62b5@zmail14.collab.prod.int.phx2.redhat.com>

Ever wondered why the version of oVirt's first release is 3.0.0_0001?
The answer is simple - We use ovirt-engine jar's version as our "main" release version.

Personally, I think the current versioning scheme is ugly. Actually, I can't name even one open-source project using "_" in it's version.

What can we do about it? We have couple of options:
1. Leave the engine alone, and use a separate versioning scheme (e.g - use just 3.1.0 as the main version for next release)
2. Remove "_" from engine jars
3. Do nothing.

I'd like to hear your thoughts, as well as the reasons to use such an unusual versioning scheme.

---
Ofer Schreiber
oVirt Release Manager


From danken at redhat.com  Wed Apr 18 08:32:27 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Wed, 18 Apr 2012 11:32:27 +0300
Subject: Storage Device Management in VDSM and oVirt
In-Reply-To: <4F8D4119.80901@redhat.com>
References: <4F8D4119.80901@redhat.com>
Message-ID: <20120418083227.GB24412@redhat.com>

On Tue, Apr 17, 2012 at 03:38:25PM +0530, Shireesh Anjal wrote:
> Hi all,
> 
> As part of adding Gluster support in ovirt, we need to introduce
> some Storage Device management capabilities (on the host). Since
> these are quite generic and not specific to Gluster as such, we
> think it might be useful to add it as a core vdsm and oVirt feature.
> At a high level, this involves following:
> 
>  - A "Storage Devices" sub-tab on "Host" entity, displaying
> information about all the storage devices*
>  - Listing of different types of storage devices of a host
>     - Regular Disks and Partitions*
>     - LVM*
>     - Software RAID*
>  - Various actions related to device configuration
>     - Partition disks*
>     - Format and mount disks / partitions*
>     - Create, resize and delete LVM Volume Groups (VGs)
>     - Create, resize, delete, format and mount LVM Logical Volumes (LVs)
>     - Create, resize, delete, partition, format and mount Software
> RAID devices
>  - Edit properties of the devices
>  - UI can be modeled similar to the system-config-lvm tool
> 
> The items marked with (*) in above list are urgently required for
> the Gluster feature, and will be developed first.
> 
> Comments / inputs welcome.

This seems like a big undertaking, and I would like to understand the
complete use case of this. Is it intended to create the block storage
devices on top of which a Gluster volume will be created?

I must tell that we had a bad experience with exposing low level
commands over the Vdsm API: A Vdsm storage domain is a VG with some
metadata on top. We used to have two API calls for creating a storage
domain: one to create the VG and one to add the metadata and make it an
SD. But it is pretty hard to handle all the error cases remotely. It
proved more useful to have one atomic command for the whole sequence.

I suspect that this would be the case here, too. I'm not sure if using
Vdsm as an ssh-replacement for transporting lvm/md/fdisk commands is the
best approach.

It may be better to have a single verb for creating Gluster volume out
of block storage devices. Something like: "take these disks, partition
them, build a raid, cover with a vg, carve some PVs and make each of
them a Gluster volume".

Obviously, it is not simple to define a good language to describe a
general architecture of a Gluster voluem. But it would have to be done
somewhere - if not in Vdsm then in Engine; and I suspect it would be
better done on the local host, not beyond a fragile network link.

Please note that currently, Vdsm makes a lot of effort not to touch LVM
metadata of existing VGs on regular "HSM" hosts. All such operations are
done on the engine-selected "SPM" host. When implementing this, we must
bear in mind these safeguards and think whether we want to break them.

Regards,
Dan.


From danken at redhat.com  Wed Apr 18 08:45:38 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Wed, 18 Apr 2012 11:45:38 +0300
Subject: Storage Device Management in VDSM and oVirt
In-Reply-To: <4F8D4119.80901@redhat.com>
References: <4F8D4119.80901@redhat.com>
Message-ID: <20120418084522.GE24412@redhat.com>

(Note that vdsm-devel is on fedorahosted.org. vdsm-devel at ovirt.org was
created by mistake, and I believe we agreed to dropped it)

On Tue, Apr 17, 2012 at 03:38:25PM +0530, Shireesh Anjal wrote:
> Hi all,
> 
> As part of adding Gluster support in ovirt, we need to introduce
> some Storage Device management capabilities (on the host). Since
> these are quite generic and not specific to Gluster as such, we
> think it might be useful to add it as a core vdsm and oVirt feature.
> At a high level, this involves following:
> 
>  - A "Storage Devices" sub-tab on "Host" entity, displaying
> information about all the storage devices*
>  - Listing of different types of storage devices of a host
>     - Regular Disks and Partitions*
>     - LVM*
>     - Software RAID*
>  - Various actions related to device configuration
>     - Partition disks*
>     - Format and mount disks / partitions*
>     - Create, resize and delete LVM Volume Groups (VGs)
>     - Create, resize, delete, format and mount LVM Logical Volumes (LVs)
>     - Create, resize, delete, partition, format and mount Software
> RAID devices
>  - Edit properties of the devices
>  - UI can be modeled similar to the system-config-lvm tool
> 
> The items marked with (*) in above list are urgently required for
> the Gluster feature, and will be developed first.
> 
> Comments / inputs welcome.

This seems like a big undertaking, and I would like to understand the
complete use case of this. Is it intended to create the block storage
devices on top of which a Gluster volume will be created?

I must tell that we had a bad experience with exposing low level
commands over the Vdsm API: A Vdsm storage domain is a VG with some
metadata on top. We used to have two API calls for creating a storage
domain: one to create the VG and one to add the metadata and make it an
SD. But it is pretty hard to handle all the error cases remotely. It
proved more useful to have one atomic command for the whole sequence.

I suspect that this would be the case here, too. I'm not sure if using
Vdsm as an ssh-replacement for transporting lvm/md/fdisk commands is the
best approach.

It may be better to have a single verb for creating Gluster volume out
of block storage devices. Something like: "take these disks, partition
them, build a raid, cover with a vg, carve some PVs and make each of
them a Gluster volume".

Obviously, it is not simple to define a good language to describe a
general architecture of a Gluster voluem. But it would have to be done
somewhere - if not in Vdsm then in Engine; and I suspect it would be
better done on the local host, not beyond a fragile network link.

Please note that currently, Vdsm makes a lot of effort not to touch LVM
metadata of existing VGs on regular "HSM" hosts. All such operations are
done on the engine-selected "SPM" host. When implementing this, we must
bear in mind these safeguards and think whether we want to break them.

Regards,
Dan.


From lpeer at redhat.com  Wed Apr 18 09:17:30 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Wed, 18 Apr 2012 12:17:30 +0300
Subject: [Engine-devel] ovirt-engine deployment method
In-Reply-To: <0d88e373-f795-46cc-a63b-cef942edf5a0@zmail14.collab.prod.int.phx2.redhat.com>
References: <0d88e373-f795-46cc-a63b-cef942edf5a0@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <4F8E86AA.3010301@redhat.com>

On 17/04/12 16:20, Ofer Schreiber wrote:
> As decided earlier, oVirt next release (3.1) is targeted for Fedora 17.
> Since the engine uses JBoss, we have two deployment options:
> 1. Continue working with ovirt-engine-jbossas package
>    PROS: Single rpm. known upgrade method.
>    CONS: Maintaining un-natural zip based rpm. No official support. Can't be pushed into Fedora.
> 
> 2. Move to JBoss F17 official packages:
>    PROS: Fully supported F17 rpms (including bug fixes, security fixes, etc). "The right thing to do".
>    CONS: Upgrade from first release (relaying on old jboss) will be almost impossible, Some open issues (will it work just as as normal service? or will we need to code a new one?), Might cause a delay to Feature Freeze.
> 
> Thought? Comments?

I think it is too soon to move to the Jboss packaged for Fedora17.
It was just packaged and I am not aware of any developer actually
working with oVirt on the Jboss packaged for Fedora (except for one).
I expect to at least have the developers working with this Jboss for a
while before releasing on it.

Can anyone provide info on how different is Jboss for Fedora than the
current upstream Jboss we use?



> Share them with us!
> ---
> Ofer Schreiber
> oVirt Release Manager
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From juan.hernandez at redhat.com  Wed Apr 18 09:42:33 2012
From: juan.hernandez at redhat.com (Juan Hernandez)
Date: Wed, 18 Apr 2012 11:42:33 +0200
Subject: [Engine-devel] ovirt-engine deployment method
In-Reply-To: <4F8E86AA.3010301@redhat.com>
References: <0d88e373-f795-46cc-a63b-cef942edf5a0@zmail14.collab.prod.int.phx2.redhat.com>
	<4F8E86AA.3010301@redhat.com>
Message-ID: <4F8E8C89.8080304@redhat.com>

On 04/18/2012 11:17 AM, Livnat Peer wrote:
> On 17/04/12 16:20, Ofer Schreiber wrote:
>> As decided earlier, oVirt next release (3.1) is targeted for Fedora 17.
>> Since the engine uses JBoss, we have two deployment options:
>> 1. Continue working with ovirt-engine-jbossas package
>>    PROS: Single rpm. known upgrade method.
>>    CONS: Maintaining un-natural zip based rpm. No official support. Can't be pushed into Fedora.
>>
>> 2. Move to JBoss F17 official packages:
>>    PROS: Fully supported F17 rpms (including bug fixes, security fixes, etc). "The right thing to do".
>>    CONS: Upgrade from first release (relaying on old jboss) will be almost impossible, Some open issues (will it work just as as normal service? or will we need to code a new one?), Might cause a delay to Feature Freeze.
>>
>> Thought? Comments?
> 
> I think it is too soon to move to the Jboss packaged for Fedora17.
> It was just packaged and I am not aware of any developer actually
> working with oVirt on the Jboss packaged for Fedora (except for one).
> I expect to at least have the developers working with this Jboss for a
> while before releasing on it.
> 
> Can anyone provide info on how different is Jboss for Fedora than the
> current upstream Jboss we use?

The main difference is that the version being packaged for Fedora 17
contains a subset of the modules: those needed for the web profile
except Hibernate. In addition the main configuration file is also
different: standalone-web.xml instead of standalone.xml. Additional
modules will be added as needed. Eventually all the modules available
upstream will be available in the Fedora packaging, but that will take time.

With the currently available packages ovirt-engine 3.0 can run correctly
(only backend and restapi, not the frontend). It needs changes, but it
can run, and most of those changes are not really related to the
differences in jboss-as, but to the differences in other packages like
quartz, resteasy, jackson, spring, etc. I believe that the same applies
to 3.1.

In order for a ovirt developer to use the Fedora packaging it will need
a lot of additional modules and tools, specially for the frontend, that
are not currently available in Fedora 17. If we wait for that then we
should re-target for Fedora 18.

My opinion is that we should use the Fedora 17 packages for deployment,
independently of what we use for development. It is challenging, but I
believe is "the right thing to do".


From lpeer at redhat.com  Wed Apr 18 10:18:54 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Wed, 18 Apr 2012 13:18:54 +0300
Subject: [Engine-devel] ovirt-engine deployment method
In-Reply-To: <4F8E8C89.8080304@redhat.com>
References: <0d88e373-f795-46cc-a63b-cef942edf5a0@zmail14.collab.prod.int.phx2.redhat.com>
	<4F8E86AA.3010301@redhat.com> <4F8E8C89.8080304@redhat.com>
Message-ID: <4F8E950E.2040901@redhat.com>

On 18/04/12 12:42, Juan Hernandez wrote:
> On 04/18/2012 11:17 AM, Livnat Peer wrote:
>> On 17/04/12 16:20, Ofer Schreiber wrote:
>>> As decided earlier, oVirt next release (3.1) is targeted for Fedora 17.
>>> Since the engine uses JBoss, we have two deployment options:
>>> 1. Continue working with ovirt-engine-jbossas package
>>>    PROS: Single rpm. known upgrade method.
>>>    CONS: Maintaining un-natural zip based rpm. No official support. Can't be pushed into Fedora.
>>>
>>> 2. Move to JBoss F17 official packages:
>>>    PROS: Fully supported F17 rpms (including bug fixes, security fixes, etc). "The right thing to do".
>>>    CONS: Upgrade from first release (relaying on old jboss) will be almost impossible, Some open issues (will it work just as as normal service? or will we need to code a new one?), Might cause a delay to Feature Freeze.
>>>
>>> Thought? Comments?
>>
>> I think it is too soon to move to the Jboss packaged for Fedora17.
>> It was just packaged and I am not aware of any developer actually
>> working with oVirt on the Jboss packaged for Fedora (except for one).
>> I expect to at least have the developers working with this Jboss for a
>> while before releasing on it.
>>
>> Can anyone provide info on how different is Jboss for Fedora than the
>> current upstream Jboss we use?
> 
> The main difference is that the version being packaged for Fedora 17
> contains a subset of the modules: those needed for the web profile
> except Hibernate. In addition the main configuration file is also
> different: standalone-web.xml instead of standalone.xml. Additional
> modules will be added as needed. Eventually all the modules available
> upstream will be available in the Fedora packaging, but that will take time.
> 
> With the currently available packages ovirt-engine 3.0 can run correctly
> (only backend and restapi, not the frontend). It needs changes, but it
> can run, and most of those changes are not really related to the
> differences in jboss-as, but to the differences in other packages like
> quartz, resteasy, jackson, spring, etc. I believe that the same applies
> to 3.1.

Maybe for 3.1 we should change upstream to use the same Jar versions as
we use in the Fedora deployment. That would take us one step closer to a
parity version.

> 
> In order for a ovirt developer to use the Fedora packaging it will need
> a lot of additional modules and tools, specially for the frontend, that
> are not currently available in Fedora 17. If we wait for that then we
> should re-target for Fedora 18.
> 

Is that mean that our next release, if we use Jboss packaged in Fedora,
will not include UI?

> My opinion is that we should use the Fedora 17 packages for deployment,
> independently of what we use for development. It is challenging, but I
> believe is "the right thing to do".

Juan, thank you for the detailed answer.

I suggest that for the upcoming release we'll do both, have 2 release
flavors, one RPM's like we released for 3.0 (with Jboss included) and
the other one tailored for Fedora.


Thanks, Livnat



From juan.hernandez at redhat.com  Wed Apr 18 10:42:41 2012
From: juan.hernandez at redhat.com (Juan Hernandez)
Date: Wed, 18 Apr 2012 12:42:41 +0200
Subject: [Engine-devel] ovirt-engine deployment method
In-Reply-To: <4F8E950E.2040901@redhat.com>
References: <0d88e373-f795-46cc-a63b-cef942edf5a0@zmail14.collab.prod.int.phx2.redhat.com>
	<4F8E86AA.3010301@redhat.com> <4F8E8C89.8080304@redhat.com>
	<4F8E950E.2040901@redhat.com>
Message-ID: <4F8E9AA1.4040209@redhat.com>

On 04/18/2012 12:18 PM, Livnat Peer wrote:
> On 18/04/12 12:42, Juan Hernandez wrote:
>> On 04/18/2012 11:17 AM, Livnat Peer wrote:
>>> On 17/04/12 16:20, Ofer Schreiber wrote:
>>>> As decided earlier, oVirt next release (3.1) is targeted for Fedora 17.
>>>> Since the engine uses JBoss, we have two deployment options:
>>>> 1. Continue working with ovirt-engine-jbossas package
>>>>    PROS: Single rpm. known upgrade method.
>>>>    CONS: Maintaining un-natural zip based rpm. No official support. Can't be pushed into Fedora.
>>>>
>>>> 2. Move to JBoss F17 official packages:
>>>>    PROS: Fully supported F17 rpms (including bug fixes, security fixes, etc). "The right thing to do".
>>>>    CONS: Upgrade from first release (relaying on old jboss) will be almost impossible, Some open issues (will it work just as as normal service? or will we need to code a new one?), Might cause a delay to Feature Freeze.
>>>>
>>>> Thought? Comments?
>>>
>>> I think it is too soon to move to the Jboss packaged for Fedora17.
>>> It was just packaged and I am not aware of any developer actually
>>> working with oVirt on the Jboss packaged for Fedora (except for one).
>>> I expect to at least have the developers working with this Jboss for a
>>> while before releasing on it.
>>>
>>> Can anyone provide info on how different is Jboss for Fedora than the
>>> current upstream Jboss we use?
>>
>> The main difference is that the version being packaged for Fedora 17
>> contains a subset of the modules: those needed for the web profile
>> except Hibernate. In addition the main configuration file is also
>> different: standalone-web.xml instead of standalone.xml. Additional
>> modules will be added as needed. Eventually all the modules available
>> upstream will be available in the Fedora packaging, but that will take time.
>>
>> With the currently available packages ovirt-engine 3.0 can run correctly
>> (only backend and restapi, not the frontend). It needs changes, but it
>> can run, and most of those changes are not really related to the
>> differences in jboss-as, but to the differences in other packages like
>> quartz, resteasy, jackson, spring, etc. I believe that the same applies
>> to 3.1.
> 
> Maybe for 3.1 we should change upstream to use the same Jar versions as
> we use in the Fedora deployment. That would take us one step closer to a
> parity version.

That would be great! There are some changes that could help with that:

http://gerrit.ovirt.org/3250 - Update to Quartz 2.1
http://gerrit.ovirt.org/3251 - Update to Jackson 1.9.2
http://gerrit.ovirt.org/1390 - Remove Spring from RESTAPI
http://gerrit.ovirt.org/3002 - Update to Spring 3
http://gerrit.ovirt.org/2347 - Add methods missing in PGHack
http://gerrit.ovirt.org/2354 - Don't require activation
http://gerrit.ovirt.org/3249 - Remove dependency on JNA
http://gerrit.ovirt.org/3086 - Replace pubkey2ssh with ssh-keygen

Some of them still need work from the author ;-)

>> In order for a ovirt developer to use the Fedora packaging it will need
>> a lot of additional modules and tools, specially for the frontend, that
>> are not currently available in Fedora 17. If we wait for that then we
>> should re-target for Fedora 18.
> 
> Is that mean that our next release, if we use Jboss packaged in Fedora,
> will not include UI?

No, I didn't explain it correctly, sorry. It means the the "official"
ovirt-engine package included in Fedora 17 can't contain the UI (because
GWT is not in Fedora 17 yet). But the "unofficial" ovirt-engine package
can include it, and the official jboss-as package should be enough to
run the it.

>> My opinion is that we should use the Fedora 17 packages for deployment,
>> independently of what we use for development. It is challenging, but I
>> believe is "the right thing to do".
> 
> Juan, thank you for the detailed answer.
> 
> I suggest that for the upcoming release we'll do both, have 2 release
> flavors, one RPM's like we released for 3.0 (with Jboss included) and
> the other one tailored for Fedora.

My suggestion is that even if we decide to have two flavors of the
ovirt-engine packages (the official one without the UI and the
unofficial one with the UI) both should use the official jboss-as package.


From oschreib at redhat.com  Wed Apr 18 11:23:14 2012
From: oschreib at redhat.com (Ofer Schreiber)
Date: Wed, 18 Apr 2012 07:23:14 -0400 (EDT)
Subject: [Engine-devel] ovirt-engine deployment method
In-Reply-To: <4F8E950E.2040901@redhat.com>
Message-ID: <a40fb22a-7150-4a37-a565-61a7d76873f7@zmail14.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> On 18/04/12 12:42, Juan Hernandez wrote:
> > On 04/18/2012 11:17 AM, Livnat Peer wrote:
> >> On 17/04/12 16:20, Ofer Schreiber wrote:
> >>> As decided earlier, oVirt next release (3.1) is targeted for
> >>> Fedora 17.
> >>> Since the engine uses JBoss, we have two deployment options:
> >>> 1. Continue working with ovirt-engine-jbossas package
> >>>    PROS: Single rpm. known upgrade method.
> >>>    CONS: Maintaining un-natural zip based rpm. No official
> >>>    support. Can't be pushed into Fedora.
> >>>
> >>> 2. Move to JBoss F17 official packages:
> >>>    PROS: Fully supported F17 rpms (including bug fixes, security
> >>>    fixes, etc). "The right thing to do".
> >>>    CONS: Upgrade from first release (relaying on old jboss) will
> >>>    be almost impossible, Some open issues (will it work just as
> >>>    as normal service? or will we need to code a new one?), Might
> >>>    cause a delay to Feature Freeze.
> >>>
> >>> Thought? Comments?
> >>
> >> I think it is too soon to move to the Jboss packaged for Fedora17.
> >> It was just packaged and I am not aware of any developer actually
> >> working with oVirt on the Jboss packaged for Fedora (except for
> >> one).
> >> I expect to at least have the developers working with this Jboss
> >> for a
> >> while before releasing on it.
> >>
> >> Can anyone provide info on how different is Jboss for Fedora than
> >> the
> >> current upstream Jboss we use?
> > 
> > The main difference is that the version being packaged for Fedora
> > 17
> > contains a subset of the modules: those needed for the web profile
> > except Hibernate. In addition the main configuration file is also
> > different: standalone-web.xml instead of standalone.xml. Additional
> > modules will be added as needed. Eventually all the modules
> > available
> > upstream will be available in the Fedora packaging, but that will
> > take time.
> > 
> > With the currently available packages ovirt-engine 3.0 can run
> > correctly
> > (only backend and restapi, not the frontend). It needs changes, but
> > it
> > can run, and most of those changes are not really related to the
> > differences in jboss-as, but to the differences in other packages
> > like
> > quartz, resteasy, jackson, spring, etc. I believe that the same
> > applies
> > to 3.1.
> 
> Maybe for 3.1 we should change upstream to use the same Jar versions
> as
> we use in the Fedora deployment. That would take us one step closer
> to a
> parity version.
> 
> > 
> > In order for a ovirt developer to use the Fedora packaging it will
> > need
> > a lot of additional modules and tools, specially for the frontend,
> > that
> > are not currently available in Fedora 17. If we wait for that then
> > we
> > should re-target for Fedora 18.
> > 
> 
> Is that mean that our next release, if we use Jboss packaged in
> Fedora,
> will not include UI?
> 
> > My opinion is that we should use the Fedora 17 packages for
> > deployment,
> > independently of what we use for development. It is challenging,
> > but I
> > believe is "the right thing to do".
> 
> Juan, thank you for the detailed answer.
> 
> I suggest that for the upcoming release we'll do both, have 2 release
> flavors, one RPM's like we released for 3.0 (with Jboss included) and
> the other one tailored for Fedora.

Having two release flavors for the next version? sounds wrong to me.
We will have to code & test two separate environments. this will require us to duplicate spec file, setup code and upgrade.


> 
> 
> Thanks, Livnat
> 
> 


From lpeer at redhat.com  Wed Apr 18 12:05:14 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Wed, 18 Apr 2012 15:05:14 +0300
Subject: [Engine-devel] ovirt-engine deployment method
In-Reply-To: <4F8E9AA1.4040209@redhat.com>
References: <0d88e373-f795-46cc-a63b-cef942edf5a0@zmail14.collab.prod.int.phx2.redhat.com>
	<4F8E86AA.3010301@redhat.com> <4F8E8C89.8080304@redhat.com>
	<4F8E950E.2040901@redhat.com> <4F8E9AA1.4040209@redhat.com>
Message-ID: <4F8EADFA.8000702@redhat.com>

On 18/04/12 13:42, Juan Hernandez wrote:
> On 04/18/2012 12:18 PM, Livnat Peer wrote:
>> On 18/04/12 12:42, Juan Hernandez wrote:
>>> On 04/18/2012 11:17 AM, Livnat Peer wrote:
>>>> On 17/04/12 16:20, Ofer Schreiber wrote:
>>>>> As decided earlier, oVirt next release (3.1) is targeted for Fedora 17.
>>>>> Since the engine uses JBoss, we have two deployment options:
>>>>> 1. Continue working with ovirt-engine-jbossas package
>>>>>    PROS: Single rpm. known upgrade method.
>>>>>    CONS: Maintaining un-natural zip based rpm. No official support. Can't be pushed into Fedora.
>>>>>
>>>>> 2. Move to JBoss F17 official packages:
>>>>>    PROS: Fully supported F17 rpms (including bug fixes, security fixes, etc). "The right thing to do".
>>>>>    CONS: Upgrade from first release (relaying on old jboss) will be almost impossible, Some open issues (will it work just as as normal service? or will we need to code a new one?), Might cause a delay to Feature Freeze.
>>>>>
>>>>> Thought? Comments?
>>>>
>>>> I think it is too soon to move to the Jboss packaged for Fedora17.
>>>> It was just packaged and I am not aware of any developer actually
>>>> working with oVirt on the Jboss packaged for Fedora (except for one).
>>>> I expect to at least have the developers working with this Jboss for a
>>>> while before releasing on it.
>>>>
>>>> Can anyone provide info on how different is Jboss for Fedora than the
>>>> current upstream Jboss we use?
>>>
>>> The main difference is that the version being packaged for Fedora 17
>>> contains a subset of the modules: those needed for the web profile
>>> except Hibernate. In addition the main configuration file is also
>>> different: standalone-web.xml instead of standalone.xml. Additional
>>> modules will be added as needed. Eventually all the modules available
>>> upstream will be available in the Fedora packaging, but that will take time.
>>>
>>> With the currently available packages ovirt-engine 3.0 can run correctly
>>> (only backend and restapi, not the frontend). It needs changes, but it
>>> can run, and most of those changes are not really related to the
>>> differences in jboss-as, but to the differences in other packages like
>>> quartz, resteasy, jackson, spring, etc. I believe that the same applies
>>> to 3.1.
>>
>> Maybe for 3.1 we should change upstream to use the same Jar versions as
>> we use in the Fedora deployment. That would take us one step closer to a
>> parity version.
> 
> That would be great! There are some changes that could help with that:
> 
> http://gerrit.ovirt.org/3250 - Update to Quartz 2.1
> http://gerrit.ovirt.org/3251 - Update to Jackson 1.9.2
> http://gerrit.ovirt.org/1390 - Remove Spring from RESTAPI
> http://gerrit.ovirt.org/3002 - Update to Spring 3
> http://gerrit.ovirt.org/2347 - Add methods missing in PGHack
> http://gerrit.ovirt.org/2354 - Don't require activation
> http://gerrit.ovirt.org/3249 - Remove dependency on JNA
> http://gerrit.ovirt.org/3086 - Replace pubkey2ssh with ssh-keygen
> 
> Some of them still need work from the author ;-)

nice :), added some comments myself.

> 
>>> In order for a ovirt developer to use the Fedora packaging it will need
>>> a lot of additional modules and tools, specially for the frontend, that
>>> are not currently available in Fedora 17. If we wait for that then we
>>> should re-target for Fedora 18.
>>
>> Is that mean that our next release, if we use Jboss packaged in Fedora,
>> will not include UI?
> 
> No, I didn't explain it correctly, sorry. It means the the "official"
> ovirt-engine package included in Fedora 17 can't contain the UI (because
> GWT is not in Fedora 17 yet). But the "unofficial" ovirt-engine package
> can include it, and the official jboss-as package should be enough to
> run the it.
> 

Thanks for clarifying it.

>>> My opinion is that we should use the Fedora 17 packages for deployment,
>>> independently of what we use for development. It is challenging, but I
>>> believe is "the right thing to do".
>>
>> Juan, thank you for the detailed answer.
>>
>> I suggest that for the upcoming release we'll do both, have 2 release
>> flavors, one RPM's like we released for 3.0 (with Jboss included) and
>> the other one tailored for Fedora.
> 
> My suggestion is that even if we decide to have two flavors of the
> ovirt-engine packages (the official one without the UI and the
> unofficial one with the UI) both should use the official jboss-as package.

I am interested in 2 flavors as in one using the 'fedora' Jboss and a
second one using the upstream Jboss AS we use today. The main reason for
that is that we need time for the developers to worked with the Jboss
packaged in Fedora and see it does not have major issues.


Livnat



From iheim at redhat.com  Wed Apr 18 12:59:49 2012
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 18 Apr 2012 15:59:49 +0300
Subject: [Engine-devel] ovirt-engine deployment method
In-Reply-To: <4F8E9AA1.4040209@redhat.com>
References: <0d88e373-f795-46cc-a63b-cef942edf5a0@zmail14.collab.prod.int.phx2.redhat.com>
	<4F8E86AA.3010301@redhat.com> <4F8E8C89.8080304@redhat.com>
	<4F8E950E.2040901@redhat.com> <4F8E9AA1.4040209@redhat.com>
Message-ID: <4F8EBAC5.5040501@redhat.com>

On 04/18/2012 01:42 PM, Juan Hernandez wrote:
...
>>
>> I suggest that for the upcoming release we'll do both, have 2 release
>> flavors, one RPM's like we released for 3.0 (with Jboss included) and
>> the other one tailored for Fedora.
>
> My suggestion is that even if we decide to have two flavors of the
> ovirt-engine packages (the official one without the UI and the
> unofficial one with the UI) both should use the official jboss-as package.

we can include an additional repo for the web ui on top of the engine in 
fedora 17.
still using the jboss in fedora.
so no need for an entire additional distro, just the part which is 
"missing" from F17.


From abaron at redhat.com  Wed Apr 18 13:06:36 2012
From: abaron at redhat.com (Ayal Baron)
Date: Wed, 18 Apr 2012 09:06:36 -0400 (EDT)
Subject: Storage Device Management in VDSM and oVirt
In-Reply-To: <20120418083227.GB24412@redhat.com>
Message-ID: <4b71eb2b-712c-472b-ab3c-c7c704b2dbb2@zmail13.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> On Tue, Apr 17, 2012 at 03:38:25PM +0530, Shireesh Anjal wrote:
> > Hi all,
> > 
> > As part of adding Gluster support in ovirt, we need to introduce
> > some Storage Device management capabilities (on the host). Since
> > these are quite generic and not specific to Gluster as such, we
> > think it might be useful to add it as a core vdsm and oVirt
> > feature.
> > At a high level, this involves following:
> > 
> >  - A "Storage Devices" sub-tab on "Host" entity, displaying
> > information about all the storage devices*
> >  - Listing of different types of storage devices of a host
> >     - Regular Disks and Partitions*
> >     - LVM*
> >     - Software RAID*
> >  - Various actions related to device configuration
> >     - Partition disks*
> >     - Format and mount disks / partitions*
> >     - Create, resize and delete LVM Volume Groups (VGs)
> >     - Create, resize, delete, format and mount LVM Logical Volumes
> >     (LVs)
> >     - Create, resize, delete, partition, format and mount Software
> > RAID devices
> >  - Edit properties of the devices
> >  - UI can be modeled similar to the system-config-lvm tool
> > 
> > The items marked with (*) in above list are urgently required for
> > the Gluster feature, and will be developed first.
> > 
> > Comments / inputs welcome.
> 
> This seems like a big undertaking, and I would like to understand the
> complete use case of this. Is it intended to create the block storage
> devices on top of which a Gluster volume will be created?

Yes, but not only.
It could also be used to create the file system on top of which you create a local storage domain (just an example, there are many others, more listed below).

> 
> I must tell that we had a bad experience with exposing low level
> commands over the Vdsm API: A Vdsm storage domain is a VG with some
> metadata on top. We used to have two API calls for creating a storage
> domain: one to create the VG and one to add the metadata and make it
> an
> SD. But it is pretty hard to handle all the error cases remotely. It
> proved more useful to have one atomic command for the whole sequence.
> 
> I suspect that this would be the case here, too. I'm not sure if
> using
> Vdsm as an ssh-replacement for transporting lvm/md/fdisk commands is
> the
> best approach.

I agree, we should either provide added value or figure out a way where we don't need to simply add a verb every time the underlying APIs added something.

> 
> It may be better to have a single verb for creating Gluster volume
> out
> of block storage devices. Something like: "take these disks,
> partition
> them, build a raid, cover with a vg, carve some PVs and make each of
> them a Gluster volume".
> 
> Obviously, it is not simple to define a good language to describe a
> general architecture of a Gluster voluem. But it would have to be
> done
> somewhere - if not in Vdsm then in Engine; and I suspect it would be
> better done on the local host, not beyond a fragile network link.
> 
> Please note that currently, Vdsm makes a lot of effort not to touch
> LVM
> metadata of existing VGs on regular "HSM" hosts. All such operations
> are
> done on the engine-selected "SPM" host. When implementing this, we
> must
> bear in mind these safeguards and think whether we want to break
> them.

I'm not sure I see how this is relevant, we allow creating a VG on any host today and that isn't going to change...

In general, we know that we already need to support using a LUN even if it has partitions on it (with force or something).

We know that we have requirements for more control over the VG that we create e.g. support striping, control over max LV size (limited by pv extent size today) etc.

We also know that users would like a way not only to use a local dir for a storage domain but also create the directory + fs?

We know that in the gLuster use case we would like the ability to setup samba over the gluster volume as well as iSCSI probably.

So although I believe that when we create a gluster volume or an ovirt storage domain then indeed we shouldn't need a lot of low level commands, but it would appear to me that not allowing for more control when needed is not going to work and that there are enough use cases which do not involve a gluster volume nor a storage domain to warrant this to be generic.

> 
> Regards,
> Dan.
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From dfediuck at redhat.com  Wed Apr 18 13:15:11 2012
From: dfediuck at redhat.com (Doron Fediuck)
Date: Wed, 18 Apr 2012 16:15:11 +0300
Subject: Maven 3 here we come!
Message-ID: <4F8EBE5F.6090503@redhat.com>

Hi guys,
We're trying to be as updated as possible in oVirt development.
In order to catch up with recent changes in major distro's,
we'd like to move to Maven 3.

Current oVirt engine code actually can be built with Maven 3 now,
but we still need to handle some minor issues. Also we need
to update our wiki's accordingly.

To make this move coordinated, and give everyone some time
to play with Maven 3, I suggest we do it in 2 weeks from now,
and move on April 29. Basically the code should remain the same,
other than minor changes we may need to do.

If you have substantials considerations against maven3,
please share.
-- 

/d

"Who's General Failure and why's he reading my disk?"


From dfediuck at redhat.com  Wed Apr 18 14:12:06 2012
From: dfediuck at redhat.com (Doron Fediuck)
Date: Wed, 18 Apr 2012 17:12:06 +0300
Subject: [Engine-devel] Maven 3 here we come!
In-Reply-To: <4ccfb404-335f-4e08-a60c-6c077f567936@zmail01.collab.prod.int.phx2.redhat.com>
References: <4ccfb404-335f-4e08-a60c-6c077f567936@zmail01.collab.prod.int.phx2.redhat.com>
Message-ID: <4F8ECBB6.2000508@redhat.com>

Hi Laszlo,
Sure.

As I said, the code already works well with Maven 3,
so no need for further changes.

What Asaf (CC'd) discovered is a corner case of failure,
when trying to start from scratch. This means there's
no local maven repo, and Maven start fetching the
artifacts. One of the GWT artifacts is being fetched,
but then maven reports an error and fails.
When retrying it will succeed. So we need to sort this
out in order to prevent such failures on new environments.

Other than that the code should be fine, and wiki's should
be updated, as well as current development setups.

Once we finish this initial move, we may consider Maven 3's
biggest feature- parallel build[1] !!! 
But we need to finish step one (move to mvn3) in order to get there ;)

[1] https://cwiki.apache.org/MAVEN/parallel-builds-in-maven-3.html
 

On 18/04/12 16:46, Laszlo Hornyak wrote:
> Hi!
> 
> I like the idea. 
> Could you share some the changes you plan to do to move to maven 3?
> 
> Thank you,
> Laszlo
> 
> ----- Original Message -----
>> From: "Doron Fediuck" <dfediuck at redhat.com>
>> To: engine-devel at ovirt.org, "<arch at ovirt.org>" <arch at ovirt.org>
>> Sent: Wednesday, April 18, 2012 3:15:11 PM
>> Subject: [Engine-devel] Maven 3 here we come!
>>
>> Hi guys,
>> We're trying to be as updated as possible in oVirt development.
>> In order to catch up with recent changes in major distro's,
>> we'd like to move to Maven 3.
>>
>> Current oVirt engine code actually can be built with Maven 3 now,
>> but we still need to handle some minor issues. Also we need
>> to update our wiki's accordingly.
>>
>> To make this move coordinated, and give everyone some time
>> to play with Maven 3, I suggest we do it in 2 weeks from now,
>> and move on April 29. Basically the code should remain the same,
>> other than minor changes we may need to do.
>>
>> If you have substantials considerations against maven3,
>> please share.
>> --
>>
>> /d
>>
>> "Who's General Failure and why's he reading my disk?"
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>


-- 

/d

"Common sense is not so common." --Voltaire, Dictionnaire Philosophique (1764)


From mburns at redhat.com  Wed Apr 18 15:29:03 2012
From: mburns at redhat.com (Mike Burns)
Date: Wed, 18 Apr 2012 11:29:03 -0400 (EDT)
Subject: oVirt Weekly Meeting
Message-ID: <0d8235b0-359e-44b9-a2a0-0a98bd573d0e@zmail17.collab.prod.int.phx2.redhat.com>

The following is a new meeting request:

Subject: oVirt Weekly Meeting 
Organizer: "Mike Burns" <mburns at redhat.com> 

Location: #ovirt of oftc.net 
Time: Wednesday, April 25, 2012, 10:00:00 AM - 11:00:00 AM GMT -05:00 US/Canada Eastern
 
Required: danken at redhat.com; oschreib at redhat.com; ykaul at redhat.com; sgordon at redhat.com; dfediuck at redhat.com 
Optional: arch at ovirt.org; board at ovirt.org 

*~*~*~*~*~*~*~*~*~*

Weekly Sync Meeting for the oVirt Project

* This meeting will take place at 10:00 AM EDT and follow US DST.

* A call for agenda items will be sent out weekly on Monday or Tuesday


Standing Agenda items:

* Next Release status
* Sub-Project report

Required Attendees:

* The maintainer or a delegate from each of the core projects (node, engine, vdsm)
* Docs representative
* QE Representative
* Release Manager
* Anyone who proposes a topic for discussion for the meeting
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20120418/5c737447/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meeting.ics
Type: text/calendar
Size: 4024 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20120418/5c737447/attachment.ics>

From Caitlin.Bestler at nexenta.com  Wed Apr 18 19:18:35 2012
From: Caitlin.Bestler at nexenta.com (Caitlin Bestler)
Date: Wed, 18 Apr 2012 19:18:35 +0000
Subject: Storage Device Management in VDSM and oVirt
In-Reply-To: <4F8D4119.80901@redhat.com>
References: <4F8D4119.80901@redhat.com>
Message-ID: <719CD19D2B2BFA4CB1B3F00D2A8CDCD04E11AB16@AUSP01DAG0103.collaborationhost.net>

Shireesh Anjal wrote:


> As part of adding Gluster support in ovirt, we need to introduce some Storage Device management capabilities (on the host). Since these are quite generic and not specific to Gluster as such, we think it might be 
> useful to add it as a core vdsm and oVirt feature. At a high level, this involves following:

>  - A "Storage Devices" sub-tab on "Host" entity, displaying information about all the storage devices*
>  - Listing of different types of storage devices of a host
>     - Regular Disks and Partitions*
>     - LVM*
>     - Software RAID*
>  - Various actions related to device configuration
>     - Partition disks*
>     - Format and mount disks / partitions*
>     - Create, resize and delete LVM Volume Groups (VGs)
>     - Create, resize, delete, format and mount LVM Logical Volumes (LVs)
>     - Create, resize, delete, partition, format and mount Software RAID devices
>  - Edit properties of the devices
>  - UI can be modeled similar to the system-config-lvm tool

This actually strikes me as a very limited set of servi ces from the volume layer.
Storage Devices should also be able to optionally expose the following capabilities:
- Snapshot/rollback
- Clone volume from existing volume (or snapshot)
- Control of thin provisioning.
- Specification of a Class of Storage (to guide selection of drives, SSD vs HDD, etc.)



From danken at redhat.com  Thu Apr 19 06:55:04 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Thu, 19 Apr 2012 09:55:04 +0300
Subject: Storage Device Management in VDSM and oVirt
In-Reply-To: <4b71eb2b-712c-472b-ab3c-c7c704b2dbb2@zmail13.collab.prod.int.phx2.redhat.com>
References: <20120418083227.GB24412@redhat.com>
	<4b71eb2b-712c-472b-ab3c-c7c704b2dbb2@zmail13.collab.prod.int.phx2.redhat.com>
Message-ID: <20120419065502.GA5714@redhat.com>

On Wed, Apr 18, 2012 at 09:06:36AM -0400, Ayal Baron wrote:
> 
> 
> ----- Original Message -----
> > On Tue, Apr 17, 2012 at 03:38:25PM +0530, Shireesh Anjal wrote:
> > > Hi all,
> > > 
> > > As part of adding Gluster support in ovirt, we need to introduce
> > > some Storage Device management capabilities (on the host). Since
> > > these are quite generic and not specific to Gluster as such, we
> > > think it might be useful to add it as a core vdsm and oVirt
> > > feature.
> > > At a high level, this involves following:
> > > 
> > >  - A "Storage Devices" sub-tab on "Host" entity, displaying
> > > information about all the storage devices*
> > >  - Listing of different types of storage devices of a host
> > >     - Regular Disks and Partitions*
> > >     - LVM*
> > >     - Software RAID*
> > >  - Various actions related to device configuration
> > >     - Partition disks*
> > >     - Format and mount disks / partitions*
> > >     - Create, resize and delete LVM Volume Groups (VGs)
> > >     - Create, resize, delete, format and mount LVM Logical Volumes
> > >     (LVs)
> > >     - Create, resize, delete, partition, format and mount Software
> > > RAID devices
> > >  - Edit properties of the devices
> > >  - UI can be modeled similar to the system-config-lvm tool
> > > 
> > > The items marked with (*) in above list are urgently required for
> > > the Gluster feature, and will be developed first.
> > > 
> > > Comments / inputs welcome.
> > 
> > This seems like a big undertaking, and I would like to understand the
> > complete use case of this. Is it intended to create the block storage
> > devices on top of which a Gluster volume will be created?
> 
> Yes, but not only.
> It could also be used to create the file system on top of which you create a local storage domain (just an example, there are many others, more listed below).
> 
> > 
> > I must tell that we had a bad experience with exposing low level
> > commands over the Vdsm API: A Vdsm storage domain is a VG with some
> > metadata on top. We used to have two API calls for creating a storage
> > domain: one to create the VG and one to add the metadata and make it
> > an
> > SD. But it is pretty hard to handle all the error cases remotely. It
> > proved more useful to have one atomic command for the whole sequence.
> > 
> > I suspect that this would be the case here, too. I'm not sure if
> > using
> > Vdsm as an ssh-replacement for transporting lvm/md/fdisk commands is
> > the
> > best approach.
> 
> I agree, we should either provide added value or figure out a way where we don't need to simply add a verb every time the underlying APIs added something.
> 
> > 
> > It may be better to have a single verb for creating Gluster volume
> > out
> > of block storage devices. Something like: "take these disks,
> > partition
> > them, build a raid, cover with a vg, carve some PVs and make each of
> > them a Gluster volume".
> > 
> > Obviously, it is not simple to define a good language to describe a
> > general architecture of a Gluster voluem. But it would have to be
> > done
> > somewhere - if not in Vdsm then in Engine; and I suspect it would be
> > better done on the local host, not beyond a fragile network link.
> > 
> > Please note that currently, Vdsm makes a lot of effort not to touch
> > LVM
> > metadata of existing VGs on regular "HSM" hosts. All such operations
> > are
> > done on the engine-selected "SPM" host. When implementing this, we
> > must
> > bear in mind these safeguards and think whether we want to break
> > them.
> 
> I'm not sure I see how this is relevant, we allow creating a VG on any host today and that isn't going to change...

We have one painful exception, that alone is no reason to add more. Note
that currently, Engine uses the would-be-spm for vg creation. In the
gluster use case, any host is expected to do this on async timing. It
might be required, but it's not warm and fuzzy.

> 
> In general, we know that we already need to support using a LUN even if it has partitions on it (with force or something).
> 
> We know that we have requirements for more control over the VG that we create e.g. support striping, control over max LV size (limited by pv extent size today) etc.
> 
> We also know that users would like a way not only to use a local dir for a storage domain but also create the directory + fs?

These three examples are storage domain flavors..

> 
> We know that in the gLuster use case we would like the ability to setup samba over the gluster volume as well as iSCSI probably.

Now I do not see the relevance. Configuring gluster and how it exposes
its volume is something other than preparing block storage for gluster
bricks.

> 
> So although I believe that when we create a gluster volume or an ovirt storage domain then indeed we shouldn't need a lot of low level commands, but it would appear to me that not allowing for more control when needed is not going to work and that there are enough use cases which do not involve a gluster volume nor a storage domain to warrant this to be generic.

I'm not against more control; I'm against uncontrollable API such as
runThisLvmCommandAsRoot()


From abaron at redhat.com  Thu Apr 19 07:47:43 2012
From: abaron at redhat.com (Ayal Baron)
Date: Thu, 19 Apr 2012 03:47:43 -0400 (EDT)
Subject: Storage Device Management in VDSM and oVirt
In-Reply-To: <20120419065502.GA5714@redhat.com>
Message-ID: <0304e54f-d0be-47d4-b1bc-79ddd7f7c51a@zmail13.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> On Wed, Apr 18, 2012 at 09:06:36AM -0400, Ayal Baron wrote:
> > 
> > 
> > ----- Original Message -----
> > > On Tue, Apr 17, 2012 at 03:38:25PM +0530, Shireesh Anjal wrote:
> > > > Hi all,
> > > > 
> > > > As part of adding Gluster support in ovirt, we need to
> > > > introduce
> > > > some Storage Device management capabilities (on the host).
> > > > Since
> > > > these are quite generic and not specific to Gluster as such, we
> > > > think it might be useful to add it as a core vdsm and oVirt
> > > > feature.
> > > > At a high level, this involves following:
> > > > 
> > > >  - A "Storage Devices" sub-tab on "Host" entity, displaying
> > > > information about all the storage devices*
> > > >  - Listing of different types of storage devices of a host
> > > >     - Regular Disks and Partitions*
> > > >     - LVM*
> > > >     - Software RAID*
> > > >  - Various actions related to device configuration
> > > >     - Partition disks*
> > > >     - Format and mount disks / partitions*
> > > >     - Create, resize and delete LVM Volume Groups (VGs)
> > > >     - Create, resize, delete, format and mount LVM Logical
> > > >     Volumes
> > > >     (LVs)
> > > >     - Create, resize, delete, partition, format and mount
> > > >     Software
> > > > RAID devices
> > > >  - Edit properties of the devices
> > > >  - UI can be modeled similar to the system-config-lvm tool
> > > > 
> > > > The items marked with (*) in above list are urgently required
> > > > for
> > > > the Gluster feature, and will be developed first.
> > > > 
> > > > Comments / inputs welcome.
> > > 
> > > This seems like a big undertaking, and I would like to understand
> > > the
> > > complete use case of this. Is it intended to create the block
> > > storage
> > > devices on top of which a Gluster volume will be created?
> > 
> > Yes, but not only.
> > It could also be used to create the file system on top of which you
> > create a local storage domain (just an example, there are many
> > others, more listed below).
> > 
> > > 
> > > I must tell that we had a bad experience with exposing low level
> > > commands over the Vdsm API: A Vdsm storage domain is a VG with
> > > some
> > > metadata on top. We used to have two API calls for creating a
> > > storage
> > > domain: one to create the VG and one to add the metadata and make
> > > it
> > > an
> > > SD. But it is pretty hard to handle all the error cases remotely.
> > > It
> > > proved more useful to have one atomic command for the whole
> > > sequence.
> > > 
> > > I suspect that this would be the case here, too. I'm not sure if
> > > using
> > > Vdsm as an ssh-replacement for transporting lvm/md/fdisk commands
> > > is
> > > the
> > > best approach.
> > 
> > I agree, we should either provide added value or figure out a way
> > where we don't need to simply add a verb every time the underlying
> > APIs added something.
> > 
> > > 
> > > It may be better to have a single verb for creating Gluster
> > > volume
> > > out
> > > of block storage devices. Something like: "take these disks,
> > > partition
> > > them, build a raid, cover with a vg, carve some PVs and make each
> > > of
> > > them a Gluster volume".
> > > 
> > > Obviously, it is not simple to define a good language to describe
> > > a
> > > general architecture of a Gluster voluem. But it would have to be
> > > done
> > > somewhere - if not in Vdsm then in Engine; and I suspect it would
> > > be
> > > better done on the local host, not beyond a fragile network link.
> > > 
> > > Please note that currently, Vdsm makes a lot of effort not to
> > > touch
> > > LVM
> > > metadata of existing VGs on regular "HSM" hosts. All such
> > > operations
> > > are
> > > done on the engine-selected "SPM" host. When implementing this,
> > > we
> > > must
> > > bear in mind these safeguards and think whether we want to break
> > > them.
> > 
> > I'm not sure I see how this is relevant, we allow creating a VG on
> > any host today and that isn't going to change...
> 
> We have one painful exception, that alone is no reason to add more.
> Note
> that currently, Engine uses the would-be-spm for vg creation. In the
> gluster use case, any host is expected to do this on async timing. It
> might be required, but it's not warm and fuzzy.

Engine does not use the spm for vg creation, it uses whatever host the user wishes to use (there is a drop-down to choose/you can pass host in API).  The default host is SPM in the drop-down, but it's optional.
In addition, next major version we'll have SDM and then there will be no good default.
This also means that the same host would be allowed to manipulate 

> 
> > 
> > In general, we know that we already need to support using a LUN
> > even if it has partitions on it (with force or something).
> > 
> > We know that we have requirements for more control over the VG that
> > we create e.g. support striping, control over max LV size (limited
> > by pv extent size today) etc.
> > 
> > We also know that users would like a way not only to use a local
> > dir for a storage domain but also create the directory + fs?
> 
> These three examples are storage domain flavors..

Yes, but these would bloat createStorageDomain, and the more flexibility we need, the more bloat we'll see.

> 
> > 
> > We know that in the gLuster use case we would like the ability to
> > setup samba over the gluster volume as well as iSCSI probably.
> 
> Now I do not see the relevance. Configuring gluster and how it
> exposes
> its volume is something other than preparing block storage for
> gluster
> bricks.

Not preparing block storage for bricks, exposing a gluster volume as a LUN to other hosts.
Basically we are moving towards a services view here and these services will all need the ability to setup the underlying storage before exposing it.

> 
> > 
> > So although I believe that when we create a gluster volume or an
> > ovirt storage domain then indeed we shouldn't need a lot of low
> > level commands, but it would appear to me that not allowing for
> > more control when needed is not going to work and that there are
> > enough use cases which do not involve a gluster volume nor a
> > storage domain to warrant this to be generic.
> 
> I'm not against more control; I'm against uncontrollable API such as
> runThisLvmCommandAsRoot()

I can't argue with this.
I think what we're missing here though is something similar to setupNetworks which would solve the problem.  Not have 100 verbs (createPartition, createFS, createVG, createLV,  setupRaid,...) but rather have setupStorage (better name suggestions are welcome) which would get the list of objects to use and the final configuration to setup.

This way we'd have a 2 stage process:
1. setupStorage (generic)
2. createSD/createGlusterVolume/...  (plugin specific)


From dfediuck at redhat.com  Thu Apr 19 10:00:51 2012
From: dfediuck at redhat.com (Doron Fediuck)
Date: Thu, 19 Apr 2012 13:00:51 +0300
Subject: [Engine-devel] Jar versions in ovirt-engine
In-Reply-To: <4F8E9FB6.9020703@redhat.com>
References: <b9695739-c850-4a7f-8283-d0dd506e62b5@zmail14.collab.prod.int.phx2.redhat.com>
	<4F8E9FB6.9020703@redhat.com>
Message-ID: <4F8FE253.7060802@redhat.com>

On 18/04/12 14:04, Juan Hernandez wrote:
> On 04/18/2012 09:51 AM, Ofer Schreiber wrote:
>> Ever wondered why the version of oVirt's first release is 3.0.0_0001?
>> The answer is simple - We use ovirt-engine jar's version as our "main" release version.
>>
>> Personally, I think the current versioning scheme is ugly. Actually, I can't name even one open-source project using "_" in it's version.
>>
>> What can we do about it? We have couple of options:
>> 1. Leave the engine alone, and use a separate versioning scheme (e.g - use just 3.1.0 as the main version for next release)
>> 2. Remove "_" from engine jars
>> 3. Do nothing.
>>
>> I'd like to hear your thoughts, as well as the reasons to use such an unusual versioning scheme.
>>
>> ---
>> Ofer Schreiber
>> oVirt Release Manager
>> _______________________________________________
>> Arch mailing list
>> Arch at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch
> 
> From my point of view using the 0001 suffix in the names of the jar
> files is not a big problem, but I agree that using it in the release
> number is ugly, and it produces issues/discussions during packaging. I
> vote for option #1: use 3.1.0 for the next main version.
> 

The original versioning scheme was due to a bug in maven2.

Juan, I've read some of the Java packaging concepts, but didn't see
(or missed) thoughts about modular versioning (ie- artifacts).

Here are the things to consider here;

- Current RPM's are using the version declared in the POM files.
Should this concept remain?
* I think it should remain, as other packaging systems should
be able to use it as well and end-up is the similar project version.

- Do we want to expose oVirt engine artifacts in a Maven repo
for others to consume?
* If we do, we'll need to make sure we have a scheme that works both for
Maven and for packaging (RPM) comparisons.

One last thing...
I know most of the packaging work now is RPM based. Still, I'm
asking you to leave enough room for non-RPM distro's to join in.
-- 

/d

"Forty-two," said Deep Thought, with infinite majesty and calm. --Douglas Adams, The Hitchhiker's Guide to the Galaxy


From juan.hernandez at redhat.com  Thu Apr 19 10:26:08 2012
From: juan.hernandez at redhat.com (Juan Hernandez)
Date: Thu, 19 Apr 2012 12:26:08 +0200
Subject: [Engine-devel] Jar versions in ovirt-engine
In-Reply-To: <4F8FE253.7060802@redhat.com>
References: <b9695739-c850-4a7f-8283-d0dd506e62b5@zmail14.collab.prod.int.phx2.redhat.com>
	<4F8E9FB6.9020703@redhat.com> <4F8FE253.7060802@redhat.com>
Message-ID: <4F8FE840.5080808@redhat.com>

On 04/19/2012 12:00 PM, Doron Fediuck wrote:
> On 18/04/12 14:04, Juan Hernandez wrote:
>> On 04/18/2012 09:51 AM, Ofer Schreiber wrote:
>>> Ever wondered why the version of oVirt's first release is 3.0.0_0001?
>>> The answer is simple - We use ovirt-engine jar's version as our "main" release version.
>>>
>>> Personally, I think the current versioning scheme is ugly. Actually, I can't name even one open-source project using "_" in it's version.
>>>
>>> What can we do about it? We have couple of options:
>>> 1. Leave the engine alone, and use a separate versioning scheme (e.g - use just 3.1.0 as the main version for next release)
>>> 2. Remove "_" from engine jars
>>> 3. Do nothing.
>>>
>>> I'd like to hear your thoughts, as well as the reasons to use such an unusual versioning scheme.
>>>
>>> ---
>>> Ofer Schreiber
>>> oVirt Release Manager
>>> _______________________________________________
>>> Arch mailing list
>>> Arch at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/arch
>>
>> From my point of view using the 0001 suffix in the names of the jar
>> files is not a big problem, but I agree that using it in the release
>> number is ugly, and it produces issues/discussions during packaging. I
>> vote for option #1: use 3.1.0 for the next main version.
>>
> 
> The original versioning scheme was due to a bug in maven2.
> 
> Juan, I've read some of the Java packaging concepts, but didn't see
> (or missed) thoughts about modular versioning (ie- artifacts).
> 
> Here are the things to consider here;
> 
> - Current RPM's are using the version declared in the POM files.
> Should this concept remain?
> * I think it should remain, as other packaging systems should
> be able to use it as well and end-up is the similar project version.

I can talk from the Fedora point of view only, as that is what I know a bit.

In Fedora there can be only one version of a given jar file installed in
the system, so there is no point in adding a version number to the name
of that jar file: the version number is already in the package
containing that jar file. In fact if the build generates jar files with
version numbers in the name the RPM should remove those jar files. That
is why I say that having any kind of numbers in the names of the jars is
not important: we have to remove them anyway.

Packaging guidelines (see [1]) recommend to avoid version numbers in the
jar files, and I think that makes sense.

On the other hand adding that _0001 suffix to the project itself
complicates (just a bit) the packaging. It has to be discussed where
that "postrelease" number has to go: in the version tag of the package,
in the release tag? You can see an example of that discussion in the
review bug of the ovirt-engine package (see [2]).

> - Do we want to expose oVirt engine artifacts in a Maven repo
> for others to consume?
> * If we do, we'll need to make sure we have a scheme that works both for
> Maven and for packaging (RPM) comparisons.

I think that we don't need to make the artifacts available for others
now. Is anyone consuming those artifacts? However I agree that is good
to have numbering that works for Maven and RPM.

> One last thing...
> I know most of the packaging work now is RPM based. Still, I'm
> asking you to leave enough room for non-RPM distro's to join in.

I am a bit (well, maybe a byte) RPM biased, mainly because that is what
I know, but I don't want to complicate packaging with other mechanisms.
Please let me know if I do :-) .

[1] - https://fedoraproject.org/wiki/Packaging:Java#Filenames
[2] - https://bugzilla.redhat.com/show_bug.cgi?id=807017#c13


From dfediuck at redhat.com  Thu Apr 19 13:22:03 2012
From: dfediuck at redhat.com (Doron Fediuck)
Date: Thu, 19 Apr 2012 16:22:03 +0300
Subject: [Engine-devel] Jar versions in ovirt-engine
In-Reply-To: <4F8FE840.5080808@redhat.com>
References: <b9695739-c850-4a7f-8283-d0dd506e62b5@zmail14.collab.prod.int.phx2.redhat.com>
	<4F8E9FB6.9020703@redhat.com> <4F8FE253.7060802@redhat.com>
	<4F8FE840.5080808@redhat.com>
Message-ID: <4F90117B.7060002@redhat.com>

On 19/04/12 13:26, Juan Hernandez wrote:
> On 04/19/2012 12:00 PM, Doron Fediuck wrote:
>> On 18/04/12 14:04, Juan Hernandez wrote:
>>> On 04/18/2012 09:51 AM, Ofer Schreiber wrote:
>>>> Ever wondered why the version of oVirt's first release is 3.0.0_0001?
>>>> The answer is simple - We use ovirt-engine jar's version as our "main" release version.
>>>>
>>>> Personally, I think the current versioning scheme is ugly. Actually, I can't name even one open-source project using "_" in it's version.
>>>>
>>>> What can we do about it? We have couple of options:
>>>> 1. Leave the engine alone, and use a separate versioning scheme (e.g - use just 3.1.0 as the main version for next release)
>>>> 2. Remove "_" from engine jars
>>>> 3. Do nothing.
>>>>
>>>> I'd like to hear your thoughts, as well as the reasons to use such an unusual versioning scheme.
>>>>
>>>> ---
>>>> Ofer Schreiber
>>>> oVirt Release Manager
>>>> _______________________________________________
>>>> Arch mailing list
>>>> Arch at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/arch
>>>
>>> From my point of view using the 0001 suffix in the names of the jar
>>> files is not a big problem, but I agree that using it in the release
>>> number is ugly, and it produces issues/discussions during packaging. I
>>> vote for option #1: use 3.1.0 for the next main version.
>>>
>>
>> The original versioning scheme was due to a bug in maven2.
>>
>> Juan, I've read some of the Java packaging concepts, but didn't see
>> (or missed) thoughts about modular versioning (ie- artifacts).
>>
>> Here are the things to consider here;
>>
>> - Current RPM's are using the version declared in the POM files.
>> Should this concept remain?
>> * I think it should remain, as other packaging systems should
>> be able to use it as well and end-up is the similar project version.
> 
> I can talk from the Fedora point of view only, as that is what I know a bit.
> 
> In Fedora there can be only one version of a given jar file installed in
> the system, so there is no point in adding a version number to the name
> of that jar file: the version number is already in the package
> containing that jar file. In fact if the build generates jar files with
> version numbers in the name the RPM should remove those jar files. That
> is why I say that having any kind of numbers in the names of the jars is
> not important: we have to remove them anyway.
> 
> Packaging guidelines (see [1]) recommend to avoid version numbers in the
> jar files, and I think that makes sense.
> 
This would be the easy solution.
What happens when you have more than a single Java app, and both
using different versions of the same jar file? This means that one
of the app's will need to bring it along and use it locally, rather
than system-level usage.
I'm guessing if we assume such a constraint the solution will be
to force all app's to use latest jar version, which isn't trivial.
So some distro's will allow of concept of slotted installation.
This means I currently /have/ 2 working versions of postgres in
my laptop (using Gentoo)-

equery l postgresql-server
 * Searching for postgresql-server ...
[IP-] [  ] dev-db/postgresql-server-8.4.11:8.4
[IP-] [  ] dev-db/postgresql-server-9.1.3:9.1

The same works on my laptop for Maven, Java, Python and many others.
If you think about it, Fedora supports slotted installation for
kernels, and then added alternatives to do that with other packages
as well (mta, Java..). So there's a need and a way to handle several
versions of the same library (regardless of the language), and
we should be careful when taking such assumptions. At least try
to be as flexible as possible, to allow others to join in.

So learning from Fedora I'd say- let the RPM install in a versioned
folder (ie- /usr/lib/jvm/jre-1.5.0-gcj/..), and leave the jar
files without versions for now. In the future we may need to change it
as some disrto's may use sym links to indicate the latest jar.
In such a case the RPM will stripdown the version from the artifact.

> On the other hand adding that _0001 suffix to the project itself
> complicates (just a bit) the packaging. It has to be discussed where
> that "postrelease" number has to go: in the version tag of the package,
> in the release tag? You can see an example of that discussion in the
> review bug of the ovirt-engine package (see [2]).
>
I agree. As I said- it was meant to be for maven2 bug solution.
Not needed when we move to maven3.
 
>> - Do we want to expose oVirt engine artifacts in a Maven repo
>> for others to consume?
>> * If we do, we'll need to make sure we have a scheme that works both for
>> Maven and for packaging (RPM) comparisons.
> 
> I think that we don't need to make the artifacts available for others
> now. Is anyone consuming those artifacts? However I agree that is good
> to have numbering that works for Maven and RPM.
> 
If we won't allow artifact consumption, we won't have it ;)
The idea is to be able to share artifacts between sibling projects
as well as external ones. As I see it, modular programming is
integrating several sub-projects into a working project,
based on an API. So each sub-project (/module/artifact)
may be shared with others. Does this makes sense?
Still, happy we agree on the bottom line :)

>> One last thing...
>> I know most of the packaging work now is RPM based. Still, I'm
>> asking you to leave enough room for non-RPM distro's to join in.
> 
> I am a bit (well, maybe a byte) RPM biased, mainly because that is what
> I know, but I don't want to complicate packaging with other mechanisms.
> Please let me know if I do :-) .
Simplicity is the best policy, as long as we do not drive away
others.

> 
> [1] - https://fedoraproject.org/wiki/Packaging:Java#Filenames
> [2] - https://bugzilla.redhat.com/show_bug.cgi?


From juan.hernandez at redhat.com  Thu Apr 19 13:53:55 2012
From: juan.hernandez at redhat.com (Juan Hernandez)
Date: Thu, 19 Apr 2012 15:53:55 +0200
Subject: [Engine-devel] Jar versions in ovirt-engine
In-Reply-To: <4F90117B.7060002@redhat.com>
References: <b9695739-c850-4a7f-8283-d0dd506e62b5@zmail14.collab.prod.int.phx2.redhat.com>
	<4F8E9FB6.9020703@redhat.com> <4F8FE253.7060802@redhat.com>
	<4F8FE840.5080808@redhat.com> <4F90117B.7060002@redhat.com>
Message-ID: <4F9018F3.30506@redhat.com>

On 04/19/2012 03:22 PM, Doron Fediuck wrote:
> On 19/04/12 13:26, Juan Hernandez wrote:
>> On 04/19/2012 12:00 PM, Doron Fediuck wrote:
>>> On 18/04/12 14:04, Juan Hernandez wrote:
>>>> On 04/18/2012 09:51 AM, Ofer Schreiber wrote:
>>>>> Ever wondered why the version of oVirt's first release is 3.0.0_0001?
>>>>> The answer is simple - We use ovirt-engine jar's version as our "main" release version.
>>>>>
>>>>> Personally, I think the current versioning scheme is ugly. Actually, I can't name even one open-source project using "_" in it's version.
>>>>>
>>>>> What can we do about it? We have couple of options:
>>>>> 1. Leave the engine alone, and use a separate versioning scheme (e.g - use just 3.1.0 as the main version for next release)
>>>>> 2. Remove "_" from engine jars
>>>>> 3. Do nothing.
>>>>>
>>>>> I'd like to hear your thoughts, as well as the reasons to use such an unusual versioning scheme.
>>>>>
>>>>> ---
>>>>> Ofer Schreiber
>>>>> oVirt Release Manager
>>>>> _______________________________________________
>>>>> Arch mailing list
>>>>> Arch at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/arch
>>>>
>>>> From my point of view using the 0001 suffix in the names of the jar
>>>> files is not a big problem, but I agree that using it in the release
>>>> number is ugly, and it produces issues/discussions during packaging. I
>>>> vote for option #1: use 3.1.0 for the next main version.
>>>>
>>>
>>> The original versioning scheme was due to a bug in maven2.
>>>
>>> Juan, I've read some of the Java packaging concepts, but didn't see
>>> (or missed) thoughts about modular versioning (ie- artifacts).
>>>
>>> Here are the things to consider here;
>>>
>>> - Current RPM's are using the version declared in the POM files.
>>> Should this concept remain?
>>> * I think it should remain, as other packaging systems should
>>> be able to use it as well and end-up is the similar project version.
>>
>> I can talk from the Fedora point of view only, as that is what I know a bit.
>>
>> In Fedora there can be only one version of a given jar file installed in
>> the system, so there is no point in adding a version number to the name
>> of that jar file: the version number is already in the package
>> containing that jar file. In fact if the build generates jar files with
>> version numbers in the name the RPM should remove those jar files. That
>> is why I say that having any kind of numbers in the names of the jars is
>> not important: we have to remove them anyway.
>>
>> Packaging guidelines (see [1]) recommend to avoid version numbers in the
>> jar files, and I think that makes sense.
>>
> This would be the easy solution.

Again talking only about Fedora:

Having just one version of every jar is not simple at all, in fact it
requires a lot of work to make sure that the selected versions work
properly together.

> What happens when you have more than a single Java app, and both
> using different versions of the same jar file? This means that one
> of the app's will need to bring it along and use it locally, rather
> than system-level usage.

What happens is that both applications have to be patched so that they
work correctly with the same version of that jar file. If possible the
patches are pushed upstream, if not they applied as part of the package.
Embedding another version of that jar file in one of the applications is
not allowed, in fact that is something that packagers have to undo quite
often.

> I'm guessing if we assume such a constraint the solution will be
> to force all app's to use latest jar version, which isn't trivial.

I agree completely, it is not trivial at all, that is where packagers
expend most of their time.

> So some distro's will allow of concept of slotted installation.
> This means I currently /have/ 2 working versions of postgres in
> my laptop (using Gentoo)-
> 
> equery l postgresql-server
>  * Searching for postgresql-server ...
> [IP-] [  ] dev-db/postgresql-server-8.4.11:8.4
> [IP-] [  ] dev-db/postgresql-server-9.1.3:9.1
> 
> The same works on my laptop for Maven, Java, Python and many others.
> If you think about it, Fedora supports slotted installation for
> kernels, and then added alternatives to do that with other packages
> as well (mta, Java..). So there's a need and a way to handle several
> versions of the same library (regardless of the language), and
> we should be careful when taking such assumptions. At least try
> to be as flexible as possible, to allow others to join in.

In Fedora that is allowed only for major versions: java-1.7.0 and
java-1.6.0, maven 2 and maven 3, so on, but not usually for minor
versions (there are exceptions).

> So learning from Fedora I'd say- let the RPM install in a versioned
> folder (ie- /usr/lib/jvm/jre-1.5.0-gcj/..), and leave the jar
> files without versions for now. In the future we may need to change it
> as some disrto's may use sym links to indicate the latest jar.
> In such a case the RPM will stripdown the version from the artifact.

What we are currently doing with the Fedora ovirt-engine package is that
jar files are installed to /usr/share/java/ovirt-engine, with names like
bll.jar, common.jar, compat.jar, etc. The RPM takes care of stripping
the version numbers generated by the upstream build. This doesn't
preclude other distros from doing it in a different way, using version
numbers or symlinks.

>> On the other hand adding that _0001 suffix to the project itself
>> complicates (just a bit) the packaging. It has to be discussed where
>> that "postrelease" number has to go: in the version tag of the package,
>> in the release tag? You can see an example of that discussion in the
>> review bug of the ovirt-engine package (see [2]).
>>
> I agree. As I said- it was meant to be for maven2 bug solution.
> Not needed when we move to maven3.
>  
>>> - Do we want to expose oVirt engine artifacts in a Maven repo
>>> for others to consume?
>>> * If we do, we'll need to make sure we have a scheme that works both for
>>> Maven and for packaging (RPM) comparisons.
>>
>> I think that we don't need to make the artifacts available for others
>> now. Is anyone consuming those artifacts? However I agree that is good
>> to have numbering that works for Maven and RPM.
>>
> If we won't allow artifact consumption, we won't have it ;)
> The idea is to be able to share artifacts between sibling projects
> as well as external ones. As I see it, modular programming is
> integrating several sub-projects into a working project,
> based on an API. So each sub-project (/module/artifact)
> may be shared with others. Does this makes sense?
> Still, happy we agree on the bottom line :)
> 
>>> One last thing...
>>> I know most of the packaging work now is RPM based. Still, I'm
>>> asking you to leave enough room for non-RPM distro's to join in.
>>
>> I am a bit (well, maybe a byte) RPM biased, mainly because that is what
>> I know, but I don't want to complicate packaging with other mechanisms.
>> Please let me know if I do :-) .
> Simplicity is the best policy, as long as we do not drive away
> others.
> 
>>
>> [1] - https://fedoraproject.org/wiki/Packaging:Java#Filenames
>> [2] - https://bugzilla.redhat.com/show_bug.cgi?



From dfediuck at redhat.com  Thu Apr 19 14:10:24 2012
From: dfediuck at redhat.com (Doron Fediuck)
Date: Thu, 19 Apr 2012 17:10:24 +0300
Subject: [Engine-devel] Jar versions in ovirt-engine
In-Reply-To: <4F9018F3.30506@redhat.com>
References: <b9695739-c850-4a7f-8283-d0dd506e62b5@zmail14.collab.prod.int.phx2.redhat.com>
	<4F8E9FB6.9020703@redhat.com> <4F8FE253.7060802@redhat.com>
	<4F8FE840.5080808@redhat.com> <4F90117B.7060002@redhat.com>
	<4F9018F3.30506@redhat.com>
Message-ID: <4F901CD0.5080804@redhat.com>

On 19/04/12 16:53, Juan Hernandez wrote:
> On 04/19/2012 03:22 PM, Doron Fediuck wrote:
>> On 19/04/12 13:26, Juan Hernandez wrote:
>>> On 04/19/2012 12:00 PM, Doron Fediuck wrote:
>>>> On 18/04/12 14:04, Juan Hernandez wrote:
>>>>> On 04/18/2012 09:51 AM, Ofer Schreiber wrote:
>>>>>> Ever wondered why the version of oVirt's first release is 3.0.0_0001?
>>>>>> The answer is simple - We use ovirt-engine jar's version as our "main" release version.
>>>>>>
>>>>>> Personally, I think the current versioning scheme is ugly. Actually, I can't name even one open-source project using "_" in it's version.
>>>>>>
>>>>>> What can we do about it? We have couple of options:
>>>>>> 1. Leave the engine alone, and use a separate versioning scheme (e.g - use just 3.1.0 as the main version for next release)
>>>>>> 2. Remove "_" from engine jars
>>>>>> 3. Do nothing.
>>>>>>
>>>>>> I'd like to hear your thoughts, as well as the reasons to use such an unusual versioning scheme.
>>>>>>
>>>>>> ---
>>>>>> Ofer Schreiber
>>>>>> oVirt Release Manager
>>>>>> _______________________________________________
>>>>>> Arch mailing list
>>>>>> Arch at ovirt.org
>>>>>> http://lists.ovirt.org/mailman/listinfo/arch
>>>>>
>>>>> From my point of view using the 0001 suffix in the names of the jar
>>>>> files is not a big problem, but I agree that using it in the release
>>>>> number is ugly, and it produces issues/discussions during packaging. I
>>>>> vote for option #1: use 3.1.0 for the next main version.
>>>>>
>>>>
>>>> The original versioning scheme was due to a bug in maven2.
>>>>
>>>> Juan, I've read some of the Java packaging concepts, but didn't see
>>>> (or missed) thoughts about modular versioning (ie- artifacts).
>>>>
>>>> Here are the things to consider here;
>>>>
>>>> - Current RPM's are using the version declared in the POM files.
>>>> Should this concept remain?
>>>> * I think it should remain, as other packaging systems should
>>>> be able to use it as well and end-up is the similar project version.
>>>
>>> I can talk from the Fedora point of view only, as that is what I know a bit.
>>>
>>> In Fedora there can be only one version of a given jar file installed in
>>> the system, so there is no point in adding a version number to the name
>>> of that jar file: the version number is already in the package
>>> containing that jar file. In fact if the build generates jar files with
>>> version numbers in the name the RPM should remove those jar files. That
>>> is why I say that having any kind of numbers in the names of the jars is
>>> not important: we have to remove them anyway.
>>>
>>> Packaging guidelines (see [1]) recommend to avoid version numbers in the
>>> jar files, and I think that makes sense.
>>>
>> This would be the easy solution.
> 
> Again talking only about Fedora:
> 
> Having just one version of every jar is not simple at all, in fact it
> requires a lot of work to make sure that the selected versions work
> properly together.
> 
See below, we actually share the same view...

>> What happens when you have more than a single Java app, and both
>> using different versions of the same jar file? This means that one
>> of the app's will need to bring it along and use it locally, rather
>> than system-level usage.
> 
> What happens is that both applications have to be patched so that they
> work correctly with the same version of that jar file. If possible the
> patches are pushed upstream, if not they applied as part of the package.
> Embedding another version of that jar file in one of the applications is
> not allowed, in fact that is something that packagers have to undo quite
> often.
> 
See below... converging into the latest jar is what I figured that
will happen. Still, as I see it such constraints are not really needed.
>> I'm guessing if we assume such a constraint the solution will be
>> to force all app's to use latest jar version, which isn't trivial.
> 
> I agree completely, it is not trivial at all, that is where packagers
> expend most of their time.
> 
>> So some distro's will allow of concept of slotted installation.
>> This means I currently /have/ 2 working versions of postgres in
>> my laptop (using Gentoo)-
>>
>> equery l postgresql-server
>>  * Searching for postgresql-server ...
>> [IP-] [  ] dev-db/postgresql-server-8.4.11:8.4
>> [IP-] [  ] dev-db/postgresql-server-9.1.3:9.1
>>
>> The same works on my laptop for Maven, Java, Python and many others.
>> If you think about it, Fedora supports slotted installation for
>> kernels, and then added alternatives to do that with other packages
>> as well (mta, Java..). So there's a need and a way to handle several
>> versions of the same library (regardless of the language), and
>> we should be careful when taking such assumptions. At least try
>> to be as flexible as possible, to allow others to join in.
> 
> In Fedora that is allowed only for major versions: java-1.7.0 and
> java-1.6.0, maven 2 and maven 3, so on, but not usually for minor
> versions (there are exceptions).
> 
It's a good start.

>> So learning from Fedora I'd say- let the RPM install in a versioned
>> folder (ie- /usr/lib/jvm/jre-1.5.0-gcj/..), and leave the jar
>> files without versions for now. In the future we may need to change it
>> as some disrto's may use sym links to indicate the latest jar.
>> In such a case the RPM will stripdown the version from the artifact.
> 
> What we are currently doing with the Fedora ovirt-engine package is that
> jar files are installed to /usr/share/java/ovirt-engine, with names like
> bll.jar, common.jar, compat.jar, etc. The RPM takes care of stripping
> the version numbers generated by the upstream build. This doesn't
> preclude other distros from doing it in a different way, using version
> numbers or symlinks.
> 
Why not /usr/share/java/ovirt-engine-3/ ? I do not see someone using
engine3 and engine4 on the same machine, but he may need to have
engine-config v3 to handle previous instance and engine-config v4
to handle current instance, so we could have a good infra if we
keep the major version.

-- 

/d

"The answer, my friend, is blowing in the wind" --Bob Dylan, Blowin' in the Wind (1963)


From juan.hernandez at redhat.com  Thu Apr 19 14:17:38 2012
From: juan.hernandez at redhat.com (Juan Hernandez)
Date: Thu, 19 Apr 2012 16:17:38 +0200
Subject: [Engine-devel] Jar versions in ovirt-engine
In-Reply-To: <4F901CD0.5080804@redhat.com>
References: <b9695739-c850-4a7f-8283-d0dd506e62b5@zmail14.collab.prod.int.phx2.redhat.com>
	<4F8E9FB6.9020703@redhat.com> <4F8FE253.7060802@redhat.com>
	<4F8FE840.5080808@redhat.com> <4F90117B.7060002@redhat.com>
	<4F9018F3.30506@redhat.com> <4F901CD0.5080804@redhat.com>
Message-ID: <4F901E82.4020800@redhat.com>

On 04/19/2012 04:10 PM, Doron Fediuck wrote:
> On 19/04/12 16:53, Juan Hernandez wrote:
>> On 04/19/2012 03:22 PM, Doron Fediuck wrote:
>>> On 19/04/12 13:26, Juan Hernandez wrote:
>>>> On 04/19/2012 12:00 PM, Doron Fediuck wrote:
>>>>> On 18/04/12 14:04, Juan Hernandez wrote:
>>>>>> On 04/18/2012 09:51 AM, Ofer Schreiber wrote:
>>>>>>> Ever wondered why the version of oVirt's first release is 3.0.0_0001?
>>>>>>> The answer is simple - We use ovirt-engine jar's version as our "main" release version.
>>>>>>>
>>>>>>> Personally, I think the current versioning scheme is ugly. Actually, I can't name even one open-source project using "_" in it's version.
>>>>>>>
>>>>>>> What can we do about it? We have couple of options:
>>>>>>> 1. Leave the engine alone, and use a separate versioning scheme (e.g - use just 3.1.0 as the main version for next release)
>>>>>>> 2. Remove "_" from engine jars
>>>>>>> 3. Do nothing.
>>>>>>>
>>>>>>> I'd like to hear your thoughts, as well as the reasons to use such an unusual versioning scheme.
>>>>>>>
>>>>>>> ---
>>>>>>> Ofer Schreiber
>>>>>>> oVirt Release Manager
>>>>>>> _______________________________________________
>>>>>>> Arch mailing list
>>>>>>> Arch at ovirt.org
>>>>>>> http://lists.ovirt.org/mailman/listinfo/arch
>>>>>>
>>>>>> From my point of view using the 0001 suffix in the names of the jar
>>>>>> files is not a big problem, but I agree that using it in the release
>>>>>> number is ugly, and it produces issues/discussions during packaging. I
>>>>>> vote for option #1: use 3.1.0 for the next main version.
>>>>>>
>>>>>
>>>>> The original versioning scheme was due to a bug in maven2.
>>>>>
>>>>> Juan, I've read some of the Java packaging concepts, but didn't see
>>>>> (or missed) thoughts about modular versioning (ie- artifacts).
>>>>>
>>>>> Here are the things to consider here;
>>>>>
>>>>> - Current RPM's are using the version declared in the POM files.
>>>>> Should this concept remain?
>>>>> * I think it should remain, as other packaging systems should
>>>>> be able to use it as well and end-up is the similar project version.
>>>>
>>>> I can talk from the Fedora point of view only, as that is what I know a bit.
>>>>
>>>> In Fedora there can be only one version of a given jar file installed in
>>>> the system, so there is no point in adding a version number to the name
>>>> of that jar file: the version number is already in the package
>>>> containing that jar file. In fact if the build generates jar files with
>>>> version numbers in the name the RPM should remove those jar files. That
>>>> is why I say that having any kind of numbers in the names of the jars is
>>>> not important: we have to remove them anyway.
>>>>
>>>> Packaging guidelines (see [1]) recommend to avoid version numbers in the
>>>> jar files, and I think that makes sense.
>>>>
>>> This would be the easy solution.
>>
>> Again talking only about Fedora:
>>
>> Having just one version of every jar is not simple at all, in fact it
>> requires a lot of work to make sure that the selected versions work
>> properly together.
>>
> See below, we actually share the same view...
> 
>>> What happens when you have more than a single Java app, and both
>>> using different versions of the same jar file? This means that one
>>> of the app's will need to bring it along and use it locally, rather
>>> than system-level usage.
>>
>> What happens is that both applications have to be patched so that they
>> work correctly with the same version of that jar file. If possible the
>> patches are pushed upstream, if not they applied as part of the package.
>> Embedding another version of that jar file in one of the applications is
>> not allowed, in fact that is something that packagers have to undo quite
>> often.
>>
> See below... converging into the latest jar is what I figured that
> will happen. Still, as I see it such constraints are not really needed.
>>> I'm guessing if we assume such a constraint the solution will be
>>> to force all app's to use latest jar version, which isn't trivial.
>>
>> I agree completely, it is not trivial at all, that is where packagers
>> expend most of their time.
>>
>>> So some distro's will allow of concept of slotted installation.
>>> This means I currently /have/ 2 working versions of postgres in
>>> my laptop (using Gentoo)-
>>>
>>> equery l postgresql-server
>>>  * Searching for postgresql-server ...
>>> [IP-] [  ] dev-db/postgresql-server-8.4.11:8.4
>>> [IP-] [  ] dev-db/postgresql-server-9.1.3:9.1
>>>
>>> The same works on my laptop for Maven, Java, Python and many others.
>>> If you think about it, Fedora supports slotted installation for
>>> kernels, and then added alternatives to do that with other packages
>>> as well (mta, Java..). So there's a need and a way to handle several
>>> versions of the same library (regardless of the language), and
>>> we should be careful when taking such assumptions. At least try
>>> to be as flexible as possible, to allow others to join in.
>>
>> In Fedora that is allowed only for major versions: java-1.7.0 and
>> java-1.6.0, maven 2 and maven 3, so on, but not usually for minor
>> versions (there are exceptions).
>>
> It's a good start.
> 
>>> So learning from Fedora I'd say- let the RPM install in a versioned
>>> folder (ie- /usr/lib/jvm/jre-1.5.0-gcj/..), and leave the jar
>>> files without versions for now. In the future we may need to change it
>>> as some disrto's may use sym links to indicate the latest jar.
>>> In such a case the RPM will stripdown the version from the artifact.
>>
>> What we are currently doing with the Fedora ovirt-engine package is that
>> jar files are installed to /usr/share/java/ovirt-engine, with names like
>> bll.jar, common.jar, compat.jar, etc. The RPM takes care of stripping
>> the version numbers generated by the upstream build. This doesn't
>> preclude other distros from doing it in a different way, using version
>> numbers or symlinks.
>>
> Why not /usr/share/java/ovirt-engine-3/ ? I do not see someone using
> engine3 and engine4 on the same machine, but he may need to have
> engine-config v3 to handle previous instance and engine-config v4
> to handle current instance, so we could have a good infra if we
> keep the major version.

The only thing I have against ovirt-engine-3 is that the packaging
guidelines recommend to use /usr/share/java/%{name}, where %{name} is
the name of the package, and the package has already been approved with
the name ovirt-engine. Next major version (not 3.1, that is a minor
version) can perfectly be named ovirt-engine4 or ovirt4-engine.


From dfediuck at redhat.com  Thu Apr 19 14:21:26 2012
From: dfediuck at redhat.com (Doron Fediuck)
Date: Thu, 19 Apr 2012 17:21:26 +0300
Subject: [Engine-devel] Jar versions in ovirt-engine
In-Reply-To: <4F901E82.4020800@redhat.com>
References: <b9695739-c850-4a7f-8283-d0dd506e62b5@zmail14.collab.prod.int.phx2.redhat.com>
	<4F8E9FB6.9020703@redhat.com> <4F8FE253.7060802@redhat.com>
	<4F8FE840.5080808@redhat.com> <4F90117B.7060002@redhat.com>
	<4F9018F3.30506@redhat.com> <4F901CD0.5080804@redhat.com>
	<4F901E82.4020800@redhat.com>
Message-ID: <4F901F66.1030500@redhat.com>

On 19/04/12 17:17, Juan Hernandez wrote:
> On 04/19/2012 04:10 PM, Doron Fediuck wrote:
>> On 19/04/12 16:53, Juan Hernandez wrote:
>>> On 04/19/2012 03:22 PM, Doron Fediuck wrote:
>>>> On 19/04/12 13:26, Juan Hernandez wrote:
>>>>> On 04/19/2012 12:00 PM, Doron Fediuck wrote:
>>>>>> On 18/04/12 14:04, Juan Hernandez wrote:
>>>>>>> On 04/18/2012 09:51 AM, Ofer Schreiber wrote:
>>>>>>>> Ever wondered why the version of oVirt's first release is 3.0.0_0001?
>>>>>>>> The answer is simple - We use ovirt-engine jar's version as our "main" release version.
>>>>>>>>
>>>>>>>> Personally, I think the current versioning scheme is ugly. Actually, I can't name even one open-source project using "_" in it's version.
>>>>>>>>
>>>>>>>> What can we do about it? We have couple of options:
>>>>>>>> 1. Leave the engine alone, and use a separate versioning scheme (e.g - use just 3.1.0 as the main version for next release)
>>>>>>>> 2. Remove "_" from engine jars
>>>>>>>> 3. Do nothing.
>>>>>>>>
>>>>>>>> I'd like to hear your thoughts, as well as the reasons to use such an unusual versioning scheme.
>>>>>>>>
>>>>>>>> ---
>>>>>>>> Ofer Schreiber
>>>>>>>> oVirt Release Manager
>>>>>>>> _______________________________________________
>>>>>>>> Arch mailing list
>>>>>>>> Arch at ovirt.org
>>>>>>>> http://lists.ovirt.org/mailman/listinfo/arch
>>>>>>>
>>>>>>> From my point of view using the 0001 suffix in the names of the jar
>>>>>>> files is not a big problem, but I agree that using it in the release
>>>>>>> number is ugly, and it produces issues/discussions during packaging. I
>>>>>>> vote for option #1: use 3.1.0 for the next main version.
>>>>>>>
>>>>>>
>>>>>> The original versioning scheme was due to a bug in maven2.
>>>>>>
>>>>>> Juan, I've read some of the Java packaging concepts, but didn't see
>>>>>> (or missed) thoughts about modular versioning (ie- artifacts).
>>>>>>
>>>>>> Here are the things to consider here;
>>>>>>
>>>>>> - Current RPM's are using the version declared in the POM files.
>>>>>> Should this concept remain?
>>>>>> * I think it should remain, as other packaging systems should
>>>>>> be able to use it as well and end-up is the similar project version.
>>>>>
>>>>> I can talk from the Fedora point of view only, as that is what I know a bit.
>>>>>
>>>>> In Fedora there can be only one version of a given jar file installed in
>>>>> the system, so there is no point in adding a version number to the name
>>>>> of that jar file: the version number is already in the package
>>>>> containing that jar file. In fact if the build generates jar files with
>>>>> version numbers in the name the RPM should remove those jar files. That
>>>>> is why I say that having any kind of numbers in the names of the jars is
>>>>> not important: we have to remove them anyway.
>>>>>
>>>>> Packaging guidelines (see [1]) recommend to avoid version numbers in the
>>>>> jar files, and I think that makes sense.
>>>>>
>>>> This would be the easy solution.
>>>
>>> Again talking only about Fedora:
>>>
>>> Having just one version of every jar is not simple at all, in fact it
>>> requires a lot of work to make sure that the selected versions work
>>> properly together.
>>>
>> See below, we actually share the same view...
>>
>>>> What happens when you have more than a single Java app, and both
>>>> using different versions of the same jar file? This means that one
>>>> of the app's will need to bring it along and use it locally, rather
>>>> than system-level usage.
>>>
>>> What happens is that both applications have to be patched so that they
>>> work correctly with the same version of that jar file. If possible the
>>> patches are pushed upstream, if not they applied as part of the package.
>>> Embedding another version of that jar file in one of the applications is
>>> not allowed, in fact that is something that packagers have to undo quite
>>> often.
>>>
>> See below... converging into the latest jar is what I figured that
>> will happen. Still, as I see it such constraints are not really needed.
>>>> I'm guessing if we assume such a constraint the solution will be
>>>> to force all app's to use latest jar version, which isn't trivial.
>>>
>>> I agree completely, it is not trivial at all, that is where packagers
>>> expend most of their time.
>>>
>>>> So some distro's will allow of concept of slotted installation.
>>>> This means I currently /have/ 2 working versions of postgres in
>>>> my laptop (using Gentoo)-
>>>>
>>>> equery l postgresql-server
>>>>  * Searching for postgresql-server ...
>>>> [IP-] [  ] dev-db/postgresql-server-8.4.11:8.4
>>>> [IP-] [  ] dev-db/postgresql-server-9.1.3:9.1
>>>>
>>>> The same works on my laptop for Maven, Java, Python and many others.
>>>> If you think about it, Fedora supports slotted installation for
>>>> kernels, and then added alternatives to do that with other packages
>>>> as well (mta, Java..). So there's a need and a way to handle several
>>>> versions of the same library (regardless of the language), and
>>>> we should be careful when taking such assumptions. At least try
>>>> to be as flexible as possible, to allow others to join in.
>>>
>>> In Fedora that is allowed only for major versions: java-1.7.0 and
>>> java-1.6.0, maven 2 and maven 3, so on, but not usually for minor
>>> versions (there are exceptions).
>>>
>> It's a good start.
>>
>>>> So learning from Fedora I'd say- let the RPM install in a versioned
>>>> folder (ie- /usr/lib/jvm/jre-1.5.0-gcj/..), and leave the jar
>>>> files without versions for now. In the future we may need to change it
>>>> as some disrto's may use sym links to indicate the latest jar.
>>>> In such a case the RPM will stripdown the version from the artifact.
>>>
>>> What we are currently doing with the Fedora ovirt-engine package is that
>>> jar files are installed to /usr/share/java/ovirt-engine, with names like
>>> bll.jar, common.jar, compat.jar, etc. The RPM takes care of stripping
>>> the version numbers generated by the upstream build. This doesn't
>>> preclude other distros from doing it in a different way, using version
>>> numbers or symlinks.
>>>
>> Why not /usr/share/java/ovirt-engine-3/ ? I do not see someone using
>> engine3 and engine4 on the same machine, but he may need to have
>> engine-config v3 to handle previous instance and engine-config v4
>> to handle current instance, so we could have a good infra if we
>> keep the major version.
> 
> The only thing I have against ovirt-engine-3 is that the packaging
> guidelines recommend to use /usr/share/java/%{name}, where %{name} is
> the name of the package, and the package has already been approved with
> the name ovirt-engine. Next major version (not 3.1, that is a minor
> version) can perfectly be named ovirt-engine4 or ovirt4-engine.

Maybe open a bz for it so we'll remember?
Make sure to add this thread so we'll know what happened....
-- 

/d

"Air conditioned environment - Do NOT open Windows!"


From juan.hernandez at redhat.com  Thu Apr 19 14:31:23 2012
From: juan.hernandez at redhat.com (Juan Hernandez)
Date: Thu, 19 Apr 2012 16:31:23 +0200
Subject: [Engine-devel] Jar versions in ovirt-engine
In-Reply-To: <4F901F66.1030500@redhat.com>
References: <b9695739-c850-4a7f-8283-d0dd506e62b5@zmail14.collab.prod.int.phx2.redhat.com>
	<4F8E9FB6.9020703@redhat.com> <4F8FE253.7060802@redhat.com>
	<4F8FE840.5080808@redhat.com> <4F90117B.7060002@redhat.com>
	<4F9018F3.30506@redhat.com> <4F901CD0.5080804@redhat.com>
	<4F901E82.4020800@redhat.com> <4F901F66.1030500@redhat.com>
Message-ID: <4F9021BB.5060107@redhat.com>

On 04/19/2012 04:21 PM, Doron Fediuck wrote:
> On 19/04/12 17:17, Juan Hernandez wrote:
>> On 04/19/2012 04:10 PM, Doron Fediuck wrote:
>>> On 19/04/12 16:53, Juan Hernandez wrote:
>>>> On 04/19/2012 03:22 PM, Doron Fediuck wrote:
>>>>> On 19/04/12 13:26, Juan Hernandez wrote:
>>>>>> On 04/19/2012 12:00 PM, Doron Fediuck wrote:
>>>>>>> On 18/04/12 14:04, Juan Hernandez wrote:
>>>>>>>> On 04/18/2012 09:51 AM, Ofer Schreiber wrote:
>>>>>>>>> Ever wondered why the version of oVirt's first release is 3.0.0_0001?
>>>>>>>>> The answer is simple - We use ovirt-engine jar's version as our "main" release version.
>>>>>>>>>
>>>>>>>>> Personally, I think the current versioning scheme is ugly. Actually, I can't name even one open-source project using "_" in it's version.
>>>>>>>>>
>>>>>>>>> What can we do about it? We have couple of options:
>>>>>>>>> 1. Leave the engine alone, and use a separate versioning scheme (e.g - use just 3.1.0 as the main version for next release)
>>>>>>>>> 2. Remove "_" from engine jars
>>>>>>>>> 3. Do nothing.
>>>>>>>>>
>>>>>>>>> I'd like to hear your thoughts, as well as the reasons to use such an unusual versioning scheme.
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>> Ofer Schreiber
>>>>>>>>> oVirt Release Manager
>>>>>>>>> _______________________________________________
>>>>>>>>> Arch mailing list
>>>>>>>>> Arch at ovirt.org
>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/arch
>>>>>>>>
>>>>>>>> From my point of view using the 0001 suffix in the names of the jar
>>>>>>>> files is not a big problem, but I agree that using it in the release
>>>>>>>> number is ugly, and it produces issues/discussions during packaging. I
>>>>>>>> vote for option #1: use 3.1.0 for the next main version.
>>>>>>>>
>>>>>>>
>>>>>>> The original versioning scheme was due to a bug in maven2.
>>>>>>>
>>>>>>> Juan, I've read some of the Java packaging concepts, but didn't see
>>>>>>> (or missed) thoughts about modular versioning (ie- artifacts).
>>>>>>>
>>>>>>> Here are the things to consider here;
>>>>>>>
>>>>>>> - Current RPM's are using the version declared in the POM files.
>>>>>>> Should this concept remain?
>>>>>>> * I think it should remain, as other packaging systems should
>>>>>>> be able to use it as well and end-up is the similar project version.
>>>>>>
>>>>>> I can talk from the Fedora point of view only, as that is what I know a bit.
>>>>>>
>>>>>> In Fedora there can be only one version of a given jar file installed in
>>>>>> the system, so there is no point in adding a version number to the name
>>>>>> of that jar file: the version number is already in the package
>>>>>> containing that jar file. In fact if the build generates jar files with
>>>>>> version numbers in the name the RPM should remove those jar files. That
>>>>>> is why I say that having any kind of numbers in the names of the jars is
>>>>>> not important: we have to remove them anyway.
>>>>>>
>>>>>> Packaging guidelines (see [1]) recommend to avoid version numbers in the
>>>>>> jar files, and I think that makes sense.
>>>>>>
>>>>> This would be the easy solution.
>>>>
>>>> Again talking only about Fedora:
>>>>
>>>> Having just one version of every jar is not simple at all, in fact it
>>>> requires a lot of work to make sure that the selected versions work
>>>> properly together.
>>>>
>>> See below, we actually share the same view...
>>>
>>>>> What happens when you have more than a single Java app, and both
>>>>> using different versions of the same jar file? This means that one
>>>>> of the app's will need to bring it along and use it locally, rather
>>>>> than system-level usage.
>>>>
>>>> What happens is that both applications have to be patched so that they
>>>> work correctly with the same version of that jar file. If possible the
>>>> patches are pushed upstream, if not they applied as part of the package.
>>>> Embedding another version of that jar file in one of the applications is
>>>> not allowed, in fact that is something that packagers have to undo quite
>>>> often.
>>>>
>>> See below... converging into the latest jar is what I figured that
>>> will happen. Still, as I see it such constraints are not really needed.
>>>>> I'm guessing if we assume such a constraint the solution will be
>>>>> to force all app's to use latest jar version, which isn't trivial.
>>>>
>>>> I agree completely, it is not trivial at all, that is where packagers
>>>> expend most of their time.
>>>>
>>>>> So some distro's will allow of concept of slotted installation.
>>>>> This means I currently /have/ 2 working versions of postgres in
>>>>> my laptop (using Gentoo)-
>>>>>
>>>>> equery l postgresql-server
>>>>>  * Searching for postgresql-server ...
>>>>> [IP-] [  ] dev-db/postgresql-server-8.4.11:8.4
>>>>> [IP-] [  ] dev-db/postgresql-server-9.1.3:9.1
>>>>>
>>>>> The same works on my laptop for Maven, Java, Python and many others.
>>>>> If you think about it, Fedora supports slotted installation for
>>>>> kernels, and then added alternatives to do that with other packages
>>>>> as well (mta, Java..). So there's a need and a way to handle several
>>>>> versions of the same library (regardless of the language), and
>>>>> we should be careful when taking such assumptions. At least try
>>>>> to be as flexible as possible, to allow others to join in.
>>>>
>>>> In Fedora that is allowed only for major versions: java-1.7.0 and
>>>> java-1.6.0, maven 2 and maven 3, so on, but not usually for minor
>>>> versions (there are exceptions).
>>>>
>>> It's a good start.
>>>
>>>>> So learning from Fedora I'd say- let the RPM install in a versioned
>>>>> folder (ie- /usr/lib/jvm/jre-1.5.0-gcj/..), and leave the jar
>>>>> files without versions for now. In the future we may need to change it
>>>>> as some disrto's may use sym links to indicate the latest jar.
>>>>> In such a case the RPM will stripdown the version from the artifact.
>>>>
>>>> What we are currently doing with the Fedora ovirt-engine package is that
>>>> jar files are installed to /usr/share/java/ovirt-engine, with names like
>>>> bll.jar, common.jar, compat.jar, etc. The RPM takes care of stripping
>>>> the version numbers generated by the upstream build. This doesn't
>>>> preclude other distros from doing it in a different way, using version
>>>> numbers or symlinks.
>>>>
>>> Why not /usr/share/java/ovirt-engine-3/ ? I do not see someone using
>>> engine3 and engine4 on the same machine, but he may need to have
>>> engine-config v3 to handle previous instance and engine-config v4
>>> to handle current instance, so we could have a good infra if we
>>> keep the major version.
>>
>> The only thing I have against ovirt-engine-3 is that the packaging
>> guidelines recommend to use /usr/share/java/%{name}, where %{name} is
>> the name of the package, and the package has already been approved with
>> the name ovirt-engine. Next major version (not 3.1, that is a minor
>> version) can perfectly be named ovirt-engine4 or ovirt4-engine.
> 
> Maybe open a bz for it so we'll remember?
> Make sure to add this thread so we'll know what happened....

There you go: https://bugzilla.redhat.com/814295


From dfediuck at redhat.com  Thu Apr 19 14:36:17 2012
From: dfediuck at redhat.com (Doron Fediuck)
Date: Thu, 19 Apr 2012 17:36:17 +0300
Subject: [Engine-devel] Jar versions in ovirt-engine
In-Reply-To: <4F9021BB.5060107@redhat.com>
References: <b9695739-c850-4a7f-8283-d0dd506e62b5@zmail14.collab.prod.int.phx2.redhat.com>
	<4F8E9FB6.9020703@redhat.com> <4F8FE253.7060802@redhat.com>
	<4F8FE840.5080808@redhat.com> <4F90117B.7060002@redhat.com>
	<4F9018F3.30506@redhat.com> <4F901CD0.5080804@redhat.com>
	<4F901E82.4020800@redhat.com> <4F901F66.1030500@redhat.com>
	<4F9021BB.5060107@redhat.com>
Message-ID: <4F9022E1.6090508@redhat.com>

On 19/04/12 17:31, Juan Hernandez wrote:
> On 04/19/2012 04:21 PM, Doron Fediuck wrote:
>> On 19/04/12 17:17, Juan Hernandez wrote:
>>> On 04/19/2012 04:10 PM, Doron Fediuck wrote:
>>>> On 19/04/12 16:53, Juan Hernandez wrote:
>>>>> On 04/19/2012 03:22 PM, Doron Fediuck wrote:
>>>>>> On 19/04/12 13:26, Juan Hernandez wrote:
>>>>>>> On 04/19/2012 12:00 PM, Doron Fediuck wrote:
>>>>>>>> On 18/04/12 14:04, Juan Hernandez wrote:
>>>>>>>>> On 04/18/2012 09:51 AM, Ofer Schreiber wrote:
>>>>>>>>>> Ever wondered why the version of oVirt's first release is 3.0.0_0001?
>>>>>>>>>> The answer is simple - We use ovirt-engine jar's version as our "main" release version.
>>>>>>>>>>
>>>>>>>>>> Personally, I think the current versioning scheme is ugly. Actually, I can't name even one open-source project using "_" in it's version.
>>>>>>>>>>
>>>>>>>>>> What can we do about it? We have couple of options:
>>>>>>>>>> 1. Leave the engine alone, and use a separate versioning scheme (e.g - use just 3.1.0 as the main version for next release)
>>>>>>>>>> 2. Remove "_" from engine jars
>>>>>>>>>> 3. Do nothing.
>>>>>>>>>>
>>>>>>>>>> I'd like to hear your thoughts, as well as the reasons to use such an unusual versioning scheme.
>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>> Ofer Schreiber
>>>>>>>>>> oVirt Release Manager
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Arch mailing list
>>>>>>>>>> Arch at ovirt.org
>>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/arch
>>>>>>>>>
>>>>>>>>> From my point of view using the 0001 suffix in the names of the jar
>>>>>>>>> files is not a big problem, but I agree that using it in the release
>>>>>>>>> number is ugly, and it produces issues/discussions during packaging. I
>>>>>>>>> vote for option #1: use 3.1.0 for the next main version.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The original versioning scheme was due to a bug in maven2.
>>>>>>>>
>>>>>>>> Juan, I've read some of the Java packaging concepts, but didn't see
>>>>>>>> (or missed) thoughts about modular versioning (ie- artifacts).
>>>>>>>>
>>>>>>>> Here are the things to consider here;
>>>>>>>>
>>>>>>>> - Current RPM's are using the version declared in the POM files.
>>>>>>>> Should this concept remain?
>>>>>>>> * I think it should remain, as other packaging systems should
>>>>>>>> be able to use it as well and end-up is the similar project version.
>>>>>>>
>>>>>>> I can talk from the Fedora point of view only, as that is what I know a bit.
>>>>>>>
>>>>>>> In Fedora there can be only one version of a given jar file installed in
>>>>>>> the system, so there is no point in adding a version number to the name
>>>>>>> of that jar file: the version number is already in the package
>>>>>>> containing that jar file. In fact if the build generates jar files with
>>>>>>> version numbers in the name the RPM should remove those jar files. That
>>>>>>> is why I say that having any kind of numbers in the names of the jars is
>>>>>>> not important: we have to remove them anyway.
>>>>>>>
>>>>>>> Packaging guidelines (see [1]) recommend to avoid version numbers in the
>>>>>>> jar files, and I think that makes sense.
>>>>>>>
>>>>>> This would be the easy solution.
>>>>>
>>>>> Again talking only about Fedora:
>>>>>
>>>>> Having just one version of every jar is not simple at all, in fact it
>>>>> requires a lot of work to make sure that the selected versions work
>>>>> properly together.
>>>>>
>>>> See below, we actually share the same view...
>>>>
>>>>>> What happens when you have more than a single Java app, and both
>>>>>> using different versions of the same jar file? This means that one
>>>>>> of the app's will need to bring it along and use it locally, rather
>>>>>> than system-level usage.
>>>>>
>>>>> What happens is that both applications have to be patched so that they
>>>>> work correctly with the same version of that jar file. If possible the
>>>>> patches are pushed upstream, if not they applied as part of the package.
>>>>> Embedding another version of that jar file in one of the applications is
>>>>> not allowed, in fact that is something that packagers have to undo quite
>>>>> often.
>>>>>
>>>> See below... converging into the latest jar is what I figured that
>>>> will happen. Still, as I see it such constraints are not really needed.
>>>>>> I'm guessing if we assume such a constraint the solution will be
>>>>>> to force all app's to use latest jar version, which isn't trivial.
>>>>>
>>>>> I agree completely, it is not trivial at all, that is where packagers
>>>>> expend most of their time.
>>>>>
>>>>>> So some distro's will allow of concept of slotted installation.
>>>>>> This means I currently /have/ 2 working versions of postgres in
>>>>>> my laptop (using Gentoo)-
>>>>>>
>>>>>> equery l postgresql-server
>>>>>>  * Searching for postgresql-server ...
>>>>>> [IP-] [  ] dev-db/postgresql-server-8.4.11:8.4
>>>>>> [IP-] [  ] dev-db/postgresql-server-9.1.3:9.1
>>>>>>
>>>>>> The same works on my laptop for Maven, Java, Python and many others.
>>>>>> If you think about it, Fedora supports slotted installation for
>>>>>> kernels, and then added alternatives to do that with other packages
>>>>>> as well (mta, Java..). So there's a need and a way to handle several
>>>>>> versions of the same library (regardless of the language), and
>>>>>> we should be careful when taking such assumptions. At least try
>>>>>> to be as flexible as possible, to allow others to join in.
>>>>>
>>>>> In Fedora that is allowed only for major versions: java-1.7.0 and
>>>>> java-1.6.0, maven 2 and maven 3, so on, but not usually for minor
>>>>> versions (there are exceptions).
>>>>>
>>>> It's a good start.
>>>>
>>>>>> So learning from Fedora I'd say- let the RPM install in a versioned
>>>>>> folder (ie- /usr/lib/jvm/jre-1.5.0-gcj/..), and leave the jar
>>>>>> files without versions for now. In the future we may need to change it
>>>>>> as some disrto's may use sym links to indicate the latest jar.
>>>>>> In such a case the RPM will stripdown the version from the artifact.
>>>>>
>>>>> What we are currently doing with the Fedora ovirt-engine package is that
>>>>> jar files are installed to /usr/share/java/ovirt-engine, with names like
>>>>> bll.jar, common.jar, compat.jar, etc. The RPM takes care of stripping
>>>>> the version numbers generated by the upstream build. This doesn't
>>>>> preclude other distros from doing it in a different way, using version
>>>>> numbers or symlinks.
>>>>>
>>>> Why not /usr/share/java/ovirt-engine-3/ ? I do not see someone using
>>>> engine3 and engine4 on the same machine, but he may need to have
>>>> engine-config v3 to handle previous instance and engine-config v4
>>>> to handle current instance, so we could have a good infra if we
>>>> keep the major version.
>>>
>>> The only thing I have against ovirt-engine-3 is that the packaging
>>> guidelines recommend to use /usr/share/java/%{name}, where %{name} is
>>> the name of the package, and the package has already been approved with
>>> the name ovirt-engine. Next major version (not 3.1, that is a minor
>>> version) can perfectly be named ovirt-engine4 or ovirt4-engine.
>>
>> Maybe open a bz for it so we'll remember?
>> Make sure to add this thread so we'll know what happened....
> 
> There you go: https://bugzilla.redhat.com/814295
Great, 10x!


-- 

/d

"All computers wait at the same speed."


From mburns at redhat.com  Sun Apr 22 02:43:25 2012
From: mburns at redhat.com (Mike Burns)
Date: Sat, 21 Apr 2012 22:43:25 -0400
Subject: Call for agenda topics -- Weekly Sync 2012-04-24
Message-ID: <1335062605.4148.7.camel@beelzebub.mburnsfire.net>

Reminder:  Meeting moved this week to Tuesday 2012-04-24 due to Israel
Independence Day.

This mail is a call for topics for the 2012-04-24 Weekly Sync meeting.

Standing Agenda Topics:

* Status of Next Release
* Sub-project reports (engine, vdsm, node)

Other topics that need to be covered this week:

* Additional Hardware resources for Jenkins use


If you have additional topics, please reply to this email with the
topic(s) you want to cover.  

A final planned agenda will be sent out prior to the meeting.

Thanks

The oVirt Team



From dlaor at redhat.com  Sun Apr 22 06:31:54 2012
From: dlaor at redhat.com (Dor Laor)
Date: Sun, 22 Apr 2012 09:31:54 +0300
Subject: [Engine-devel] [vdsm] Storage Device Management in VDSM and oVirt
In-Reply-To: <4F914740.2070807@linux.vnet.ibm.com>
References: <0304e54f-d0be-47d4-b1bc-79ddd7f7c51a@zmail13.collab.prod.int.phx2.redhat.com>
	<4F914740.2070807@linux.vnet.ibm.com>
Message-ID: <4F93A5DA.30308@redhat.com>

On 04/20/2012 02:23 PM, Deepak C Shetty wrote:
>
>>>> So although I believe that when we create a gluster volume or an
>>>> ovirt storage domain then indeed we shouldn't need a lot of low
>>>> level commands, but it would appear to me that not allowing for
>>>> more control when needed is not going to work and that there are
>>>> enough use cases which do not involve a gluster volume nor a
>>>> storage domain to warrant this to be generic.
>>> I'm not against more control; I'm against uncontrollable API such as
>>> runThisLvmCommandAsRoot()
>> I can't argue with this.
>> I think what we're missing here though is something similar to
>> setupNetworks which would solve the problem. Not have 100 verbs
>> (createPartition, createFS, createVG, createLV, setupRaid,...) but
>> rather have setupStorage (better name suggestions are welcome) which
>> would get the list of objects to use and the final configuration to
>> setup.
>>
>> This way we'd have a 2 stage process:
>> 1. setupStorage (generic)
>
> I was looking up on the VDSM archives and there are talks of using
> libstoragemgmt (lsm)
> under VDSM. I was wondering if the setupStorage would be something where
> lsm would
> be used to do the work, it seems fit for purpose here.

+1
In case there is some missing functionality in lsm, vdsm should add 
requirements to it.

Regards,
Dor

>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From abaron at redhat.com  Sun Apr 22 06:58:51 2012
From: abaron at redhat.com (Ayal Baron)
Date: Sun, 22 Apr 2012 02:58:51 -0400 (EDT)
Subject: [vdsm] Storage Device Management in VDSM and oVirt
In-Reply-To: <4F914740.2070807@linux.vnet.ibm.com>
Message-ID: <3a5c5eff-286d-46ab-9a72-8d0736f11aa0@zmail13.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> 
> >>> So although I believe that when we create a gluster volume or an
> >>> ovirt storage domain then indeed we shouldn't need a lot of low
> >>> level commands, but it would appear to me that not allowing for
> >>> more control when needed is not going to work and that there are
> >>> enough use cases which do not involve a gluster volume nor a
> >>> storage domain to warrant this to be generic.
> >> I'm not against more control; I'm against uncontrollable API such
> >> as
> >> runThisLvmCommandAsRoot()
> > I can't argue with this.
> > I think what we're missing here though is something similar to
> > setupNetworks which would solve the problem.  Not have 100 verbs
> > (createPartition, createFS, createVG, createLV,  setupRaid,...)
> > but rather have setupStorage (better name suggestions are welcome)
> > which would get the list of objects to use and the final
> > configuration to setup.
> >
> > This way we'd have a 2 stage process:
> > 1. setupStorage (generic)
> 
> I was looking up on the VDSM archives and there are talks of using
> libstoragemgmt (lsm)

Funny, we started using that acronym for Live Storage Migration :)

> under VDSM. I was wondering if the setupStorage would be something
> where
> lsm would
> be used to do the work, it seems fit for purpose here.
> 
> 

I don't think this is the libstoragemgmt mandate.

libstoragemgmt is:
"A library that will provide a vendor agnostic open source storage application programming interface (API) for storage arrays."

i.e. it is there to abstract storage array specifics from the user.
It will be used by things like LVM etc, not the other way around.

setupStorage would use libstoragemgmt wherever appropriate of course.

But as the libstoragemgmt maintainer, Tony (cc'd) can correct me if I'm wrong here.


From oschreib at redhat.com  Sun Apr 22 13:02:27 2012
From: oschreib at redhat.com (Ofer Schreiber)
Date: Sun, 22 Apr 2012 09:02:27 -0400 (EDT)
Subject: Call for agenda topics -- Weekly Sync 2012-04-24
In-Reply-To: <1335062605.4148.7.camel@beelzebub.mburnsfire.net>
Message-ID: <cd2e5574-f53c-4c63-a019-cb4f0fbf3dc5@zmail14.collab.prod.int.phx2.redhat.com>

Some other topic to discuss:
1. Java 7 in oVirt Engine
2. ovirt-engine-jbossas vs. Fedora17-jbossas
3. Moving to Fedora 17

Ofer.

----- Original Message -----
> Reminder:  Meeting moved this week to Tuesday 2012-04-24 due to
> Israel
> Independence Day.
> 
> This mail is a call for topics for the 2012-04-24 Weekly Sync
> meeting.
> 
> Standing Agenda Topics:
> 
> * Status of Next Release
> * Sub-project reports (engine, vdsm, node)
> 
> Other topics that need to be covered this week:
> 
> * Additional Hardware resources for Jenkins use
> 
> 
> If you have additional topics, please reply to this email with the
> topic(s) you want to cover.
> 
> A final planned agenda will be sent out prior to the meeting.
> 
> Thanks
> 
> The oVirt Team
> 
> _______________________________________________
> Board mailing list
> Board at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/board
> 


From iheim at redhat.com  Mon Apr 23 05:18:05 2012
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 23 Apr 2012 08:18:05 +0300
Subject: Call for agenda topics -- Weekly Sync 2012-04-24
In-Reply-To: <1335062605.4148.7.camel@beelzebub.mburnsfire.net>
References: <1335062605.4148.7.camel@beelzebub.mburnsfire.net>
Message-ID: <4F94E60D.4010307@redhat.com>

On 04/22/2012 05:43 AM, Mike Burns wrote:
> Reminder:  Meeting moved this week to Tuesday 2012-04-24 due to Israel
> Independence Day.
>
> This mail is a call for topics for the 2012-04-24 Weekly Sync meeting.
>
> Standing Agenda Topics:
>
> * Status of Next Release

it seems some of the features which feature pages were sent are actively 
being worked on - coupled with the move to java 7, jboss rpm's in fedora 
and fedora 17 - let's discuss the target release date to see how to 
optimize around these.

> * Sub-project reports (engine, vdsm, node)
>
> Other topics that need to be covered this week:
>
> * Additional Hardware resources for Jenkins use
>
>
> If you have additional topics, please reply to this email with the
> topic(s) you want to cover.
>
> A final planned agenda will be sent out prior to the meeting.
>
> Thanks
>
> The oVirt Team
>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch



From juan.hernandez at redhat.com  Mon Apr 23 10:25:07 2012
From: juan.hernandez at redhat.com (Juan Hernandez)
Date: Mon, 23 Apr 2012 12:25:07 +0200
Subject: Running a private instance of JBoss AS7 in Fedora
Message-ID: <4F952E03.3060304@redhat.com>

Hello,

It has been discussed before how to run ovirt-engine side by side with
other JBoss AS7 applications. This is my suggestion:

1. Create an ovirt user and ovirt group to run the application server
(we already do that for the notification service, so this is not new).

2. Replicate the directories used by JBoss AS7 putting them in the
locations suggested by the file system standards:

/usr/share/ovirt-engine/deployments root:ovirt rwxrwxr-t
  engine.ear root:root rw-rw-r--
  engine.ear.dodeploy ovirt:ovirt rw-rw-r--
  engine.ear.deployed ovirt:ovirt rw-rw-r--
  ROOT.war root:root rw-rw-r--
  ROOT.war.dodeploy ovirt:ovirt rw-rw-r--
  ROOT.war.deployed ovirt:ovirt rw-rw-r--

(I would suggest to move ROOT.war to the .ear to reduce the number of
files in this directory)

Note that the deployments should be owned by root:root so that the
ovirt:ovirt user can't write them. Also the directory needs write
permission for the ovirt:ovirt user because that user it is going to
create/remove the .dodeploy and .deployed files. The sticky bit can be
used to avoid that user removing the deployment units (it would be
better to have the .dodeploy and .deployed files in a different
directory, but that is not possible at the moment).

/usr/share/ovirt-engine/modules root:root rwxr-xr-x

We should use this directory to place the jboss modules that are missing
in JBoss AS itself (the PostgreSQL JDBC driver, for example) or that
need to be overridden. Later we should start the engine using
/usr/share/ovirt-engine/modules:/usr/share/jboss-as/modules as the
module path.

/etc/ovirt-engine root:root rwxr-xr-x
  ovirt-engine-users.properties root:root rw-r--r--
  ovirt-engine-logging.properties root:root rw-r--r--
  ovirt-engine.xml ovirt:ovirt rw-r--r--

These files should be based on the mngt-users.properties,
logging.properties and standalone-web.xml files provided by the
application server.

(I think it can be easier to maintain those files than to maintain the
python code that adjusts them during setup)

/var/lib/ovirt-engine ovirt:ovirt rwxr-xr-x

This is the directory where the application server will place the
content of the additional deployments. Will not be used by the engine,
but is needed anyway.

/var/cache/ovirt-engine ovirt:ovirt rwxr-xr-x

The application server will create here temporary auth, vfs and work
directories.

3. Start the application server using the ovirt:ovirt user with the
following system properties (in addition to the typical jboss-as ones):

-Djboss.server.default.config=ovirt-engine.xml
-Dlogging.configuration=file:///etc/ovirt-engine/ovirt-engine-logging.properties
-mp /usr/share/ovirt-engine/modules:/usr/share/jboss-as/modules
-Djboss.home.dir=/usr/share/jboss-as
-Djboss.server.base.dir=/usr/share/ovirt-engine
-Djboss.server.config.dir=/etc/ovirt-engine
-Djboss.server.temp.dir=/var/cache/ovirt-engine
-Djboss.controller.temp.dir=/var/cache/ovirt-engine
-c ovirt-engine.xml

These options should go in a /usr/share/ovirt-engine/bin/ovirt-engine.sh
script.

4. Create a systemd unit file to start the application server using the
ovirt-engine.sh script:

[Unit]
Description=oVirt Engine
After=network.service

[Service]
ExecStart=/usr/share/ovirt-engine/bin/ovirt-engine.sh
User=ovirt

[Install]
WantedBy=multi-user.target

With this the engine will run independently of the application server
from the filesystem point of view.

5 In order to make it independent also from the ports point of view I
would suggest to add a /etc/sysconfig/ovirt-engine containing variables
like these:

ENGINE_HOST=host.example.com
ENGINE_HTTP_PORT=8080
ENGINE_HTTP_PORT=8443

These options can then be used in the start script to generate
corresponding system properties:

-Dengine.host=${ENGINE_HOST}
-Dhttp.port=${ENGINE_HTTP_PORT}
-Dhttps.port=${ENGINE_HTTPS_PORT}

And these system properties can then be used in the ovirt-engine.xml
configuration file:

<interfaces>
  <interface name="public">
     <inet-address value=${ovirt.host}/>
  </interface>
</interfaces>

<socket-binding-group name="standard-sockets" default-interface="public">
  <socket-binding name="http" port="${ovirt.http.port}"/>
  <socket-binding name="https" port="${ovirt.https.port}"/>
  ...
</socket-binding-group>

Let me know what you think.

Regards,
Juan Hernandez


From yzaslavs at redhat.com  Mon Apr 23 10:40:44 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Mon, 23 Apr 2012 13:40:44 +0300
Subject: Running a private instance of JBoss AS7 in Fedora
In-Reply-To: <4F952E03.3060304@redhat.com>
References: <4F952E03.3060304@redhat.com>
Message-ID: <4F9531AC.8010900@redhat.com>

On 04/23/2012 01:25 PM, Juan Hernandez wrote:
> Hello,
> 
> It has been discussed before how to run ovirt-engine side by side with
> other JBoss AS7 applications. This is my suggestion:
> 
> 1. Create an ovirt user and ovirt group to run the application server
> (we already do that for the notification service, so this is not new).
> 
> 2. Replicate the directories used by JBoss AS7 putting them in the
> locations suggested by the file system standards:
> 
> /usr/share/ovirt-engine/deployments root:ovirt rwxrwxr-t
>   engine.ear root:root rw-rw-r--
>   engine.ear.dodeploy ovirt:ovirt rw-rw-r--
>   engine.ear.deployed ovirt:ovirt rw-rw-r--
>   ROOT.war root:root rw-rw-r--
>   ROOT.war.dodeploy ovirt:ovirt rw-rw-r--
>   ROOT.war.deployed ovirt:ovirt rw-rw-r--
> 
> (I would suggest to move ROOT.war to the .ear to reduce the number of
> files in this directory)
> 
> Note that the deployments should be owned by root:root so that the
> ovirt:ovirt user can't write them. Also the directory needs write
> permission for the ovirt:ovirt user because that user it is going to
> create/remove the .dodeploy and .deployed files. The sticky bit can be
> used to avoid that user removing the deployment units (it would be
> better to have the .dodeploy and .deployed files in a different
> directory, but that is not possible at the moment).
> 
> /usr/share/ovirt-engine/modules root:root rwxr-xr-x
> 
> We should use this directory to place the jboss modules that are missing
> in JBoss AS itself (the PostgreSQL JDBC driver, for example) or that
> need to be overridden. Later we should start the engine using
> /usr/share/ovirt-engine/modules:/usr/share/jboss-as/modules as the
> module path.
> 
> /etc/ovirt-engine root:root rwxr-xr-x
>   ovirt-engine-users.properties root:root rw-r--r--
>   ovirt-engine-logging.properties root:root rw-r--r--
>   ovirt-engine.xml ovirt:ovirt rw-r--r--
> 
> These files should be based on the mngt-users.properties,
> logging.properties and standalone-web.xml files provided by the
> application server.
> 
> (I think it can be easier to maintain those files than to maintain the
> python code that adjusts them during setup)
> 
> /var/lib/ovirt-engine ovirt:ovirt rwxr-xr-x
> 
> This is the directory where the application server will place the
> content of the additional deployments. Will not be used by the engine,
> but is needed anyway.
> 
> /var/cache/ovirt-engine ovirt:ovirt rwxr-xr-x
> 
> The application server will create here temporary auth, vfs and work
> directories.
> 
> 3. Start the application server using the ovirt:ovirt user with the
> following system properties (in addition to the typical jboss-as ones):
> 
> -Djboss.server.default.config=ovirt-engine.xml
> -Dlogging.configuration=file:///etc/ovirt-engine/ovirt-engine-logging.properties
> -mp /usr/share/ovirt-engine/modules:/usr/share/jboss-as/modules
> -Djboss.home.dir=/usr/share/jboss-as
> -Djboss.server.base.dir=/usr/share/ovirt-engine
> -Djboss.server.config.dir=/etc/ovirt-engine
> -Djboss.server.temp.dir=/var/cache/ovirt-engine
> -Djboss.controller.temp.dir=/var/cache/ovirt-engine
> -c ovirt-engine.xml
> 
> These options should go in a /usr/share/ovirt-engine/bin/ovirt-engine.sh
> script.
> 
> 4. Create a systemd unit file to start the application server using the
> ovirt-engine.sh script:
> 
> [Unit]
> Description=oVirt Engine
> After=network.service
> 
> [Service]
> ExecStart=/usr/share/ovirt-engine/bin/ovirt-engine.sh
> User=ovirt
> 
> [Install]
> WantedBy=multi-user.target
> 
> With this the engine will run independently of the application server
> from the filesystem point of view.
> 
> 5 In order to make it independent also from the ports point of view I
> would suggest to add a /etc/sysconfig/ovirt-engine containing variables
> like these:
> 
> ENGINE_HOST=host.example.com
> ENGINE_HTTP_PORT=8080
> ENGINE_HTTP_PORT=8443

Are these the only ports we need?
What about jnp/rmi  and stuff like that?
Even if not using, won't we have collisions? I'm asking based on my
experience of doing the same with JBoss AS 4.2.x versions

Thanks,
Yair

> 
> These options can then be used in the start script to generate
> corresponding system properties:
> 
> -Dengine.host=${ENGINE_HOST}
> -Dhttp.port=${ENGINE_HTTP_PORT}
> -Dhttps.port=${ENGINE_HTTPS_PORT}
> 
> And these system properties can then be used in the ovirt-engine.xml
> configuration file:
> 
> <interfaces>
>   <interface name="public">
>      <inet-address value=${ovirt.host}/>
>   </interface>
> </interfaces>
> 
> <socket-binding-group name="standard-sockets" default-interface="public">
>   <socket-binding name="http" port="${ovirt.http.port}"/>
>   <socket-binding name="https" port="${ovirt.https.port}"/>
>   ...
> </socket-binding-group>
> 
> Let me know what you think.
> 
> Regards,
> Juan Hernandez
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch



From juan.hernandez at redhat.com  Mon Apr 23 10:57:56 2012
From: juan.hernandez at redhat.com (Juan Hernandez)
Date: Mon, 23 Apr 2012 12:57:56 +0200
Subject: Running a private instance of JBoss AS7 in Fedora
In-Reply-To: <4F9531AC.8010900@redhat.com>
References: <4F952E03.3060304@redhat.com> <4F9531AC.8010900@redhat.com>
Message-ID: <4F9535B4.7060304@redhat.com>

On 04/23/2012 12:40 PM, Yair Zaslavsky wrote:
> On 04/23/2012 01:25 PM, Juan Hernandez wrote:
>> Hello,
>>
>> It has been discussed before how to run ovirt-engine side by side with
>> other JBoss AS7 applications. This is my suggestion:
>>
>> 1. Create an ovirt user and ovirt group to run the application server
>> (we already do that for the notification service, so this is not new).
>>
>> 2. Replicate the directories used by JBoss AS7 putting them in the
>> locations suggested by the file system standards:
>>
>> /usr/share/ovirt-engine/deployments root:ovirt rwxrwxr-t
>>   engine.ear root:root rw-rw-r--
>>   engine.ear.dodeploy ovirt:ovirt rw-rw-r--
>>   engine.ear.deployed ovirt:ovirt rw-rw-r--
>>   ROOT.war root:root rw-rw-r--
>>   ROOT.war.dodeploy ovirt:ovirt rw-rw-r--
>>   ROOT.war.deployed ovirt:ovirt rw-rw-r--
>>
>> (I would suggest to move ROOT.war to the .ear to reduce the number of
>> files in this directory)
>>
>> Note that the deployments should be owned by root:root so that the
>> ovirt:ovirt user can't write them. Also the directory needs write
>> permission for the ovirt:ovirt user because that user it is going to
>> create/remove the .dodeploy and .deployed files. The sticky bit can be
>> used to avoid that user removing the deployment units (it would be
>> better to have the .dodeploy and .deployed files in a different
>> directory, but that is not possible at the moment).
>>
>> /usr/share/ovirt-engine/modules root:root rwxr-xr-x
>>
>> We should use this directory to place the jboss modules that are missing
>> in JBoss AS itself (the PostgreSQL JDBC driver, for example) or that
>> need to be overridden. Later we should start the engine using
>> /usr/share/ovirt-engine/modules:/usr/share/jboss-as/modules as the
>> module path.
>>
>> /etc/ovirt-engine root:root rwxr-xr-x
>>   ovirt-engine-users.properties root:root rw-r--r--
>>   ovirt-engine-logging.properties root:root rw-r--r--
>>   ovirt-engine.xml ovirt:ovirt rw-r--r--
>>
>> These files should be based on the mngt-users.properties,
>> logging.properties and standalone-web.xml files provided by the
>> application server.
>>
>> (I think it can be easier to maintain those files than to maintain the
>> python code that adjusts them during setup)
>>
>> /var/lib/ovirt-engine ovirt:ovirt rwxr-xr-x
>>
>> This is the directory where the application server will place the
>> content of the additional deployments. Will not be used by the engine,
>> but is needed anyway.
>>
>> /var/cache/ovirt-engine ovirt:ovirt rwxr-xr-x
>>
>> The application server will create here temporary auth, vfs and work
>> directories.
>>
>> 3. Start the application server using the ovirt:ovirt user with the
>> following system properties (in addition to the typical jboss-as ones):
>>
>> -Djboss.server.default.config=ovirt-engine.xml
>> -Dlogging.configuration=file:///etc/ovirt-engine/ovirt-engine-logging.properties
>> -mp /usr/share/ovirt-engine/modules:/usr/share/jboss-as/modules
>> -Djboss.home.dir=/usr/share/jboss-as
>> -Djboss.server.base.dir=/usr/share/ovirt-engine
>> -Djboss.server.config.dir=/etc/ovirt-engine
>> -Djboss.server.temp.dir=/var/cache/ovirt-engine
>> -Djboss.controller.temp.dir=/var/cache/ovirt-engine
>> -c ovirt-engine.xml
>>
>> These options should go in a /usr/share/ovirt-engine/bin/ovirt-engine.sh
>> script.
>>
>> 4. Create a systemd unit file to start the application server using the
>> ovirt-engine.sh script:
>>
>> [Unit]
>> Description=oVirt Engine
>> After=network.service
>>
>> [Service]
>> ExecStart=/usr/share/ovirt-engine/bin/ovirt-engine.sh
>> User=ovirt
>>
>> [Install]
>> WantedBy=multi-user.target
>>
>> With this the engine will run independently of the application server
>> from the filesystem point of view.
>>
>> 5 In order to make it independent also from the ports point of view I
>> would suggest to add a /etc/sysconfig/ovirt-engine containing variables
>> like these:
>>
>> ENGINE_HOST=host.example.com
>> ENGINE_HTTP_PORT=8080
>> ENGINE_HTTP_PORT=8443
> 
> Are these the only ports we need?
> What about jnp/rmi  and stuff like that?
> Even if not using, won't we have collisions? I'm asking based on my
> experience of doing the same with JBoss AS 4.2.x versions

Those are all the ports that ovirt-engine uses/needs. But not all the
ports that JBoss AS uses, so we could have collisions. Those collisions
can be avoided using the same mechanism. For example:

ENGINE_REMOTING_PORT=4447
-Dovirt.remoting.port=${ENGINE_REMOTING_PORT}
<socket-binding name="remoting" port="${ovirt.remoting.port}"/>

I am not trying to be exhaustive at the moment, only sharing the
approach with you.

>> These options can then be used in the start script to generate
>> corresponding system properties:
>>
>> -Dengine.host=${ENGINE_HOST}
>> -Dhttp.port=${ENGINE_HTTP_PORT}
>> -Dhttps.port=${ENGINE_HTTPS_PORT}
>>
>> And these system properties can then be used in the ovirt-engine.xml
>> configuration file:
>>
>> <interfaces>
>>   <interface name="public">
>>      <inet-address value=${ovirt.host}/>
>>   </interface>
>> </interfaces>
>>
>> <socket-binding-group name="standard-sockets" default-interface="public">
>>   <socket-binding name="http" port="${ovirt.http.port}"/>
>>   <socket-binding name="https" port="${ovirt.https.port}"/>
>>   ...
>> </socket-binding-group>
>>
>> Let me know what you think.
>>
>> Regards,
>> Juan Hernandez
>> _______________________________________________
>> Arch mailing list
>> Arch at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch
> 



From ovedo at redhat.com  Mon Apr 23 11:14:56 2012
From: ovedo at redhat.com (Oved Ourfalli)
Date: Mon, 23 Apr 2012 07:14:56 -0400 (EDT)
Subject: Running a private instance of JBoss AS7 in Fedora
In-Reply-To: <4F952E03.3060304@redhat.com>
Message-ID: <9857f6cc-0a9c-4406-98d8-b6e64863fbb9@zmail02.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Juan Hernandez" <juan.hernandez at redhat.com>
> To: "arch" <arch at ovirt.org>
> Sent: Monday, April 23, 2012 1:25:07 PM
> Subject: Running a private instance of JBoss AS7 in Fedora
> 
> Hello,
> 
> It has been discussed before how to run ovirt-engine side by side
> with
> other JBoss AS7 applications. This is my suggestion:

Sound like this is the right way to go.

I think we should try to make this the directory structure both when installing the engine, and when building it from scratch through maven.
The latter is a bit more problematic, although I think we can generate this directory structure using the maven "setup" profile (as we do today to copy the JDBC module, override the standalone.xml configuration, etc...), and that way the build environment will be as close to an installed one as possible.

That will help in developing/testing, especially in the different utilities we provide (some utilities are very hard to run in development environment, due to missing configuration and dependencies).

We somehow need to unify the infrastructure for the "setup" using maven, and the RPM setup, to avoid code duplications.
 
> 
> 1. Create an ovirt user and ovirt group to run the application server
> (we already do that for the notification service, so this is not
> new).
> 
> 2. Replicate the directories used by JBoss AS7 putting them in the
> locations suggested by the file system standards:
> 
> /usr/share/ovirt-engine/deployments root:ovirt rwxrwxr-t
>   engine.ear root:root rw-rw-r--
>   engine.ear.dodeploy ovirt:ovirt rw-rw-r--
>   engine.ear.deployed ovirt:ovirt rw-rw-r--
>   ROOT.war root:root rw-rw-r--
>   ROOT.war.dodeploy ovirt:ovirt rw-rw-r--
>   ROOT.war.deployed ovirt:ovirt rw-rw-r--
> 
> (I would suggest to move ROOT.war to the .ear to reduce the number of
> files in this directory)
> 
> Note that the deployments should be owned by root:root so that the
> ovirt:ovirt user can't write them. Also the directory needs write
> permission for the ovirt:ovirt user because that user it is going to
> create/remove the .dodeploy and .deployed files. The sticky bit can
> be
> used to avoid that user removing the deployment units (it would be
> better to have the .dodeploy and .deployed files in a different
> directory, but that is not possible at the moment).
> 
> /usr/share/ovirt-engine/modules root:root rwxr-xr-x
> 
> We should use this directory to place the jboss modules that are
> missing
> in JBoss AS itself (the PostgreSQL JDBC driver, for example) or that
> need to be overridden. Later we should start the engine using
> /usr/share/ovirt-engine/modules:/usr/share/jboss-as/modules as the
> module path.
> 
> /etc/ovirt-engine root:root rwxr-xr-x
>   ovirt-engine-users.properties root:root rw-r--r--
>   ovirt-engine-logging.properties root:root rw-r--r--
>   ovirt-engine.xml ovirt:ovirt rw-r--r--
> 
> These files should be based on the mngt-users.properties,
> logging.properties and standalone-web.xml files provided by the
> application server.
> 
> (I think it can be easier to maintain those files than to maintain
> the
> python code that adjusts them during setup)
> 
> /var/lib/ovirt-engine ovirt:ovirt rwxr-xr-x
> 
> This is the directory where the application server will place the
> content of the additional deployments. Will not be used by the
> engine,
> but is needed anyway.
> 
> /var/cache/ovirt-engine ovirt:ovirt rwxr-xr-x
> 
> The application server will create here temporary auth, vfs and work
> directories.
> 
> 3. Start the application server using the ovirt:ovirt user with the
> following system properties (in addition to the typical jboss-as
> ones):
> 
> -Djboss.server.default.config=ovirt-engine.xml
> -Dlogging.configuration=file:///etc/ovirt-engine/ovirt-engine-logging.properties
> -mp /usr/share/ovirt-engine/modules:/usr/share/jboss-as/modules
> -Djboss.home.dir=/usr/share/jboss-as
> -Djboss.server.base.dir=/usr/share/ovirt-engine
> -Djboss.server.config.dir=/etc/ovirt-engine
> -Djboss.server.temp.dir=/var/cache/ovirt-engine
> -Djboss.controller.temp.dir=/var/cache/ovirt-engine
> -c ovirt-engine.xml
> 
> These options should go in a
> /usr/share/ovirt-engine/bin/ovirt-engine.sh
> script.
> 
> 4. Create a systemd unit file to start the application server using
> the
> ovirt-engine.sh script:
> 
> [Unit]
> Description=oVirt Engine
> After=network.service
> 
> [Service]
> ExecStart=/usr/share/ovirt-engine/bin/ovirt-engine.sh
> User=ovirt
> 
> [Install]
> WantedBy=multi-user.target
> 
> With this the engine will run independently of the application server
> from the filesystem point of view.
> 
> 5 In order to make it independent also from the ports point of view I
> would suggest to add a /etc/sysconfig/ovirt-engine containing
> variables
> like these:
> 
> ENGINE_HOST=host.example.com
> ENGINE_HTTP_PORT=8080
> ENGINE_HTTP_PORT=8443
> 
> These options can then be used in the start script to generate
> corresponding system properties:
> 
> -Dengine.host=${ENGINE_HOST}
> -Dhttp.port=${ENGINE_HTTP_PORT}
> -Dhttps.port=${ENGINE_HTTPS_PORT}
> 
> And these system properties can then be used in the ovirt-engine.xml
> configuration file:
> 
> <interfaces>
>   <interface name="public">
>      <inet-address value=${ovirt.host}/>
>   </interface>
> </interfaces>
> 
> <socket-binding-group name="standard-sockets"
> default-interface="public">
>   <socket-binding name="http" port="${ovirt.http.port}"/>
>   <socket-binding name="https" port="${ovirt.https.port}"/>
>   ...
> </socket-binding-group>
> 
> Let me know what you think.
> 
> Regards,
> Juan Hernandez
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From yzaslavs at redhat.com  Mon Apr 23 11:57:40 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Mon, 23 Apr 2012 14:57:40 +0300
Subject: Running a private instance of JBoss AS7 in Fedora
In-Reply-To: <4F9535B4.7060304@redhat.com>
References: <4F952E03.3060304@redhat.com> <4F9531AC.8010900@redhat.com>
	<4F9535B4.7060304@redhat.com>
Message-ID: <4F9543B4.9080900@redhat.com>

On 04/23/2012 01:57 PM, Juan Hernandez wrote:
> On 04/23/2012 12:40 PM, Yair Zaslavsky wrote:
>> On 04/23/2012 01:25 PM, Juan Hernandez wrote:
>>> Hello,
>>>
>>> It has been discussed before how to run ovirt-engine side by side with
>>> other JBoss AS7 applications. This is my suggestion:
>>>
>>> 1. Create an ovirt user and ovirt group to run the application server
>>> (we already do that for the notification service, so this is not new).
>>>
>>> 2. Replicate the directories used by JBoss AS7 putting them in the
>>> locations suggested by the file system standards:
>>>
>>> /usr/share/ovirt-engine/deployments root:ovirt rwxrwxr-t
>>>   engine.ear root:root rw-rw-r--
>>>   engine.ear.dodeploy ovirt:ovirt rw-rw-r--
>>>   engine.ear.deployed ovirt:ovirt rw-rw-r--
>>>   ROOT.war root:root rw-rw-r--
>>>   ROOT.war.dodeploy ovirt:ovirt rw-rw-r--
>>>   ROOT.war.deployed ovirt:ovirt rw-rw-r--
>>>
>>> (I would suggest to move ROOT.war to the .ear to reduce the number of
>>> files in this directory)
>>>
>>> Note that the deployments should be owned by root:root so that the
>>> ovirt:ovirt user can't write them. Also the directory needs write
>>> permission for the ovirt:ovirt user because that user it is going to
>>> create/remove the .dodeploy and .deployed files. The sticky bit can be
>>> used to avoid that user removing the deployment units (it would be
>>> better to have the .dodeploy and .deployed files in a different
>>> directory, but that is not possible at the moment).
>>>
>>> /usr/share/ovirt-engine/modules root:root rwxr-xr-x
>>>
>>> We should use this directory to place the jboss modules that are missing
>>> in JBoss AS itself (the PostgreSQL JDBC driver, for example) or that
>>> need to be overridden. Later we should start the engine using
>>> /usr/share/ovirt-engine/modules:/usr/share/jboss-as/modules as the
>>> module path.
>>>
>>> /etc/ovirt-engine root:root rwxr-xr-x
>>>   ovirt-engine-users.properties root:root rw-r--r--
>>>   ovirt-engine-logging.properties root:root rw-r--r--
>>>   ovirt-engine.xml ovirt:ovirt rw-r--r--
>>>
>>> These files should be based on the mngt-users.properties,
>>> logging.properties and standalone-web.xml files provided by the
>>> application server.
>>>
>>> (I think it can be easier to maintain those files than to maintain the
>>> python code that adjusts them during setup)
>>>
>>> /var/lib/ovirt-engine ovirt:ovirt rwxr-xr-x
>>>
>>> This is the directory where the application server will place the
>>> content of the additional deployments. Will not be used by the engine,
>>> but is needed anyway.
>>>
>>> /var/cache/ovirt-engine ovirt:ovirt rwxr-xr-x
>>>
>>> The application server will create here temporary auth, vfs and work
>>> directories.
>>>
>>> 3. Start the application server using the ovirt:ovirt user with the
>>> following system properties (in addition to the typical jboss-as ones):
>>>
>>> -Djboss.server.default.config=ovirt-engine.xml
>>> -Dlogging.configuration=file:///etc/ovirt-engine/ovirt-engine-logging.properties
>>> -mp /usr/share/ovirt-engine/modules:/usr/share/jboss-as/modules
>>> -Djboss.home.dir=/usr/share/jboss-as
>>> -Djboss.server.base.dir=/usr/share/ovirt-engine
>>> -Djboss.server.config.dir=/etc/ovirt-engine
>>> -Djboss.server.temp.dir=/var/cache/ovirt-engine
>>> -Djboss.controller.temp.dir=/var/cache/ovirt-engine
>>> -c ovirt-engine.xml
>>>
>>> These options should go in a /usr/share/ovirt-engine/bin/ovirt-engine.sh
>>> script.
>>>
>>> 4. Create a systemd unit file to start the application server using the
>>> ovirt-engine.sh script:
>>>
>>> [Unit]
>>> Description=oVirt Engine
>>> After=network.service
>>>
>>> [Service]
>>> ExecStart=/usr/share/ovirt-engine/bin/ovirt-engine.sh
>>> User=ovirt
>>>
>>> [Install]
>>> WantedBy=multi-user.target
>>>
>>> With this the engine will run independently of the application server
>>> from the filesystem point of view.
>>>
>>> 5 In order to make it independent also from the ports point of view I
>>> would suggest to add a /etc/sysconfig/ovirt-engine containing variables
>>> like these:
>>>
>>> ENGINE_HOST=host.example.com
>>> ENGINE_HTTP_PORT=8080
>>> ENGINE_HTTP_PORT=8443
>>
>> Are these the only ports we need?
>> What about jnp/rmi  and stuff like that?
>> Even if not using, won't we have collisions? I'm asking based on my
>> experience of doing the same with JBoss AS 4.2.x versions
> 
> Those are all the ports that ovirt-engine uses/needs. But not all the
> ports that JBoss AS uses, so we could have collisions. Those collisions
> can be avoided using the same mechanism. For example:
> 
> ENGINE_REMOTING_PORT=4447
> -Dovirt.remoting.port=${ENGINE_REMOTING_PORT}
> <socket-binding name="remoting" port="${ovirt.remoting.port}"/>

Sure, I just wanted to be sure about this.
In addition, I have a feeling jboss added some ports since my 4.2.x days
:) Correct me if I'm wrong here (back at the company we did that, we had
a document with all the relevant ports and this process in general,
maybe this is something worth doing - i.e using ovirt wiki - when there
is a conclusion about the process)

> 
> I am not trying to be exhaustive at the moment, only sharing the
> approach with you.
> 
>>> These options can then be used in the start script to generate
>>> corresponding system properties:
>>>
>>> -Dengine.host=${ENGINE_HOST}
>>> -Dhttp.port=${ENGINE_HTTP_PORT}
>>> -Dhttps.port=${ENGINE_HTTPS_PORT}
>>>
>>> And these system properties can then be used in the ovirt-engine.xml
>>> configuration file:
>>>
>>> <interfaces>
>>>   <interface name="public">
>>>      <inet-address value=${ovirt.host}/>
>>>   </interface>
>>> </interfaces>
>>>
>>> <socket-binding-group name="standard-sockets" default-interface="public">
>>>   <socket-binding name="http" port="${ovirt.http.port}"/>
>>>   <socket-binding name="https" port="${ovirt.https.port}"/>
>>>   ...
>>> </socket-binding-group>
>>>
>>> Let me know what you think.
>>>
>>> Regards,
>>> Juan Hernandez
>>> _______________________________________________
>>> Arch mailing list
>>> Arch at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/arch
>>
> 



From ryanh at us.ibm.com  Mon Apr 23 12:15:26 2012
From: ryanh at us.ibm.com (Ryan Harper)
Date: Mon, 23 Apr 2012 07:15:26 -0500
Subject: Call for agenda topics -- Weekly Sync 2012-04-24
In-Reply-To: <1335062605.4148.7.camel@beelzebub.mburnsfire.net>
References: <1335062605.4148.7.camel@beelzebub.mburnsfire.net>
Message-ID: <20120423121526.GQ5593@us.ibm.com>

* Mike Burns <mburns at redhat.com> [2012-04-21 21:45]:
> Reminder:  Meeting moved this week to Tuesday 2012-04-24 due to Israel
> Independence Day.
> 
> This mail is a call for topics for the 2012-04-24 Weekly Sync meeting.
> 
> Standing Agenda Topics:
> 
> * Status of Next Release
> * Sub-project reports (engine, vdsm, node)
> 
> Other topics that need to be covered this week:
> 
> * Additional Hardware resources for Jenkins use
> 
> 
> If you have additional topics, please reply to this email with the
> topic(s) you want to cover.  

Signed-off-by in commit tag check-up

> 
> A final planned agenda will be sent out prior to the meeting.
> 
> Thanks
> 
> The oVirt Team
> 
> _______________________________________________
> Board mailing list
> Board at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/board

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh at us.ibm.com



From lhawthor at redhat.com  Mon Apr 23 14:54:00 2012
From: lhawthor at redhat.com (Leslie Hawthorn)
Date: Mon, 23 Apr 2012 07:54:00 -0700
Subject: Call for agenda topics -- Weekly Sync 2012-04-24
In-Reply-To: <1335062605.4148.7.camel@beelzebub.mburnsfire.net>
References: <1335062605.4148.7.camel@beelzebub.mburnsfire.net>
Message-ID: <4F956D08.1000803@redhat.com>

On 04/21/2012 07:43 PM, Mike Burns wrote:
> Reminder:  Meeting moved this week to Tuesday 2012-04-24 due to Israel
> Independence Day.
>
> This mail is a call for topics for the 2012-04-24 Weekly Sync meeting.
I'd like to give a brief update on upcoming oVirt workshops that are 
being planned for LinuxCon conferences and at NetApp's Headquarters in 
California.

Cheers,
LH

-- 
Leslie Hawthorn
Community Action and Impact
Open Source and Standards @ Red Hat

identi.ca/lh
twitter.com/lhawthorn



From eedri at redhat.com  Mon Apr 23 16:16:35 2012
From: eedri at redhat.com (Eyal Edri)
Date: Mon, 23 Apr 2012 12:16:35 -0400 (EDT)
Subject: Gerrit 2.3 Update Process
In-Reply-To: <711343c2-f890-40db-9203-ad911357c40e@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <4aac5bdd-06f4-4d91-be1e-76bd0cc34137@zmail17.collab.prod.int.phx2.redhat.com>

Fyi,

Me and Attila successfully updated gerrit 2.2.1 to 2.3.

you can find the steps below: (to follow for updating gerrit.ovirt.org)

i think it's is very important to make sure the gerrit server is backed up before (we did a snapshot before the upgrade).

0. backup configuration files under gerrit home dir (review_site/etc/gerrit.config and secure.config)
1. /home/gerrit2/review_site/bin/gerrit.sh stop
2. su - gerrit2
3. wget http://gerrit.googlecode.com/files/gerrit-2.3.war
4. unlink gerrit.war; ln -s gerrit-2.3.war gerrit.war
5. java -jar gerrit.war init -d review_site/

- this will now show you interactive questions about gerrit configuration, 
  you should just keep current configuration (press enter).
  and compare the new conf after to make sure nothing was changed.

6. /home/gerrit2/review_site/bin/gerrit.sh start


Hope this helps,

here are the 2.3 release notes: http://gerrit-documentation.googlecode.com/svn/ReleaseNotes/ReleaseNotes-2.3.html

Enjoy,

Eyal. 


From jhernand at redhat.com  Wed Apr 18 11:04:22 2012
From: jhernand at redhat.com (Juan Hernandez)
Date: Wed, 18 Apr 2012 13:04:22 +0200
Subject: Jar versions in ovirt-engine
In-Reply-To: <b9695739-c850-4a7f-8283-d0dd506e62b5@zmail14.collab.prod.int.phx2.redhat.com>
References: <b9695739-c850-4a7f-8283-d0dd506e62b5@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <4F8E9FB6.9020703@redhat.com>

On 04/18/2012 09:51 AM, Ofer Schreiber wrote:
> Ever wondered why the version of oVirt's first release is 3.0.0_0001?
> The answer is simple - We use ovirt-engine jar's version as our "main" release version.
> 
> Personally, I think the current versioning scheme is ugly. Actually, I can't name even one open-source project using "_" in it's version.
> 
> What can we do about it? We have couple of options:
> 1. Leave the engine alone, and use a separate versioning scheme (e.g - use just 3.1.0 as the main version for next release)
> 2. Remove "_" from engine jars
> 3. Do nothing.
> 
> I'd like to hear your thoughts, as well as the reasons to use such an unusual versioning scheme.
> 
> ---
> Ofer Schreiber
> oVirt Release Manager
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch

>From my point of view using the 0001 suffix in the names of the jar
files is not a big problem, but I agree that using it in the release
number is ugly, and it produces issues/discussions during packaging. I
vote for option #1: use 3.1.0 for the next main version.

-- 
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 lhornyak at redhat.com  Wed Apr 18 13:46:08 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Wed, 18 Apr 2012 09:46:08 -0400 (EDT)
Subject: [Engine-devel] Maven 3 here we come!
In-Reply-To: <4F8EBE5F.6090503@redhat.com>
Message-ID: <4ccfb404-335f-4e08-a60c-6c077f567936@zmail01.collab.prod.int.phx2.redhat.com>

Hi!

I like the idea. 
Could you share some the changes you plan to do to move to maven 3?

Thank you,
Laszlo

----- Original Message -----
> From: "Doron Fediuck" <dfediuck at redhat.com>
> To: engine-devel at ovirt.org, "<arch at ovirt.org>" <arch at ovirt.org>
> Sent: Wednesday, April 18, 2012 3:15:11 PM
> Subject: [Engine-devel] Maven 3 here we come!
> 
> Hi guys,
> We're trying to be as updated as possible in oVirt development.
> In order to catch up with recent changes in major distro's,
> we'd like to move to Maven 3.
> 
> Current oVirt engine code actually can be built with Maven 3 now,
> but we still need to handle some minor issues. Also we need
> to update our wiki's accordingly.
> 
> To make this move coordinated, and give everyone some time
> to play with Maven 3, I suggest we do it in 2 weeks from now,
> and move on April 29. Basically the code should remain the same,
> other than minor changes we may need to do.
> 
> If you have substantials considerations against maven3,
> please share.
> --
> 
> /d
> 
> "Who's General Failure and why's he reading my disk?"
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From jhernand at redhat.com  Thu Apr 19 10:28:19 2012
From: jhernand at redhat.com (Juan Hernandez)
Date: Thu, 19 Apr 2012 12:28:19 +0200
Subject: [Engine-devel] Jar versions in ovirt-engine
In-Reply-To: <4F8FE840.5080808@redhat.com>
References: <b9695739-c850-4a7f-8283-d0dd506e62b5@zmail14.collab.prod.int.phx2.redhat.com>
	<4F8E9FB6.9020703@redhat.com> <4F8FE253.7060802@redhat.com>
	<4F8FE840.5080808@redhat.com>
Message-ID: <4F8FE8C3.4050706@redhat.com>

On 04/19/2012 12:26 PM, Juan Hernandez wrote:

> In fact if the build generates jar files with
> version numbers in the name the RPM should remove those jar files.

I wanted to say "the RPM should remove those version numbers", sorry.

-- 
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  Thu Apr 19 19:13:57 2012
From: mburns at redhat.com (Mike Burns)
Date: Thu, 19 Apr 2012 15:13:57 -0400 (EDT)
Subject: oVirt Weekly Meeting
Message-ID: <a6e43a67-38ed-475e-bf88-f87f470663c5@zmail17.collab.prod.int.phx2.redhat.com>

The following meeting has been modified:

Subject: oVirt Weekly Meeting 
Organizer: "Mike Burns" <mburns at redhat.com> 

Location: #ovirt of oftc.net 
Time: 10:00:00 AM - 11:00:00 AM GMT -05:00 US/Canada Eastern
 Recurrence : Every Wednesday No end date Effective Apr 25, 2012

Required: danken at redhat.com; oschreib at redhat.com; ykaul at redhat.com; sgordon at redhat.com; dfediuck at redhat.com; Jon.Benedict at netapp.com; pmyers at redhat.com; simon at redhat.com; imad.sousou at intel.com; aliguori at us.ibm.com; lhawthor at redhat.com ... 
Optional: arch at ovirt.org; board at ovirt.org; menescu at cisco.com 

*~*~*~*~*~*~*~*~*~*

Weekly Sync Meeting for the oVirt Project 

* This meeting will take place at 10:00 AM EDT and follow US DST. 

* A call for agenda items will be sent out weekly on Monday or Tuesday 


Standing Agenda items: 

* Next Release status 
* Sub-Project report 

Required Attendees: 

* The maintainer or a delegate from each of the core projects (node, engine, vdsm) 
* Docs representative 
* QE Representative 
* Release Manager 
* Anyone who proposes a topic for discussion for the meeting 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20120419/2f3ea9e9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meeting.ics
Type: text/calendar
Size: 5829 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20120419/2f3ea9e9/attachment.ics>

From mburns at redhat.com  Thu Apr 19 19:15:05 2012
From: mburns at redhat.com (Mike Burns)
Date: Thu, 19 Apr 2012 15:15:05 -0400 (EDT)
Subject: oVirt Weekly Meeting
Message-ID: <3953734b-5d47-4077-b545-259240c81315@zmail17.collab.prod.int.phx2.redhat.com>

A single instance of the following meeting has been modified:

Subject: oVirt Weekly Meeting 
Organizer: "Mike Burns" <mburns at redhat.com> 

Location: #ovirt of oftc.net 
Time: Tuesday, April 24, 2012, 10:00:00 AM - 11:00:00 AM GMT -05:00 US/Canada Eastern [MODIFIED]
 
Required: danken at redhat.com; oschreib at redhat.com; ykaul at redhat.com; sgordon at redhat.com; dfediuck at redhat.com; Jon.Benedict at netapp.com; pmyers at redhat.com; simon at redhat.com; imad.sousou at intel.com; aliguori at us.ibm.com; lhawthor at redhat.com ... 
Optional: arch at ovirt.org; board at ovirt.org; menescu at cisco.com 

*~*~*~*~*~*~*~*~*~*

Moving April 25 Meeting to April 24 due to Israel Independence Day.

------

Weekly Sync Meeting for the oVirt Project 

* This meeting will take place at 10:00 AM EDT and follow US DST. 

* A call for agenda items will be sent out weekly on Monday or Tuesday 


Standing Agenda items: 

* Next Release status 
* Sub-Project report 

Required Attendees: 

* The maintainer or a delegate from each of the core projects (node, engine, vdsm) 
* Docs representative 
* QE Representative 
* Release Manager 
* Anyone who proposes a topic for discussion for the meeting 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20120419/84964836/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meeting.ics
Type: text/calendar
Size: 5977 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20120419/84964836/attachment.ics>

From deepakcs at linux.vnet.ibm.com  Fri Apr 20 11:23:44 2012
From: deepakcs at linux.vnet.ibm.com (Deepak C Shetty)
Date: Fri, 20 Apr 2012 16:53:44 +0530
Subject: [vdsm] Storage Device Management in VDSM and oVirt
In-Reply-To: <0304e54f-d0be-47d4-b1bc-79ddd7f7c51a@zmail13.collab.prod.int.phx2.redhat.com>
References: <0304e54f-d0be-47d4-b1bc-79ddd7f7c51a@zmail13.collab.prod.int.phx2.redhat.com>
Message-ID: <4F914740.2070807@linux.vnet.ibm.com>


>>> So although I believe that when we create a gluster volume or an
>>> ovirt storage domain then indeed we shouldn't need a lot of low
>>> level commands, but it would appear to me that not allowing for
>>> more control when needed is not going to work and that there are
>>> enough use cases which do not involve a gluster volume nor a
>>> storage domain to warrant this to be generic.
>> I'm not against more control; I'm against uncontrollable API such as
>> runThisLvmCommandAsRoot()
> I can't argue with this.
> I think what we're missing here though is something similar to setupNetworks which would solve the problem.  Not have 100 verbs (createPartition, createFS, createVG, createLV,  setupRaid,...) but rather have setupStorage (better name suggestions are welcome) which would get the list of objects to use and the final configuration to setup.
>
> This way we'd have a 2 stage process:
> 1. setupStorage (generic)

I was looking up on the VDSM archives and there are talks of using 
libstoragemgmt (lsm)
under VDSM. I was wondering if the setupStorage would be something where 
lsm would
be used to do the work, it seems fit for purpose here.



From deepakcs at linux.vnet.ibm.com  Mon Apr 23 11:28:52 2012
From: deepakcs at linux.vnet.ibm.com (Deepak C Shetty)
Date: Mon, 23 Apr 2012 16:58:52 +0530
Subject: [vdsm] Storage Device Management in VDSM and oVirt
In-Reply-To: <3a5c5eff-286d-46ab-9a72-8d0736f11aa0@zmail13.collab.prod.int.phx2.redhat.com>
References: <3a5c5eff-286d-46ab-9a72-8d0736f11aa0@zmail13.collab.prod.int.phx2.redhat.com>
Message-ID: <4F953CF4.80703@linux.vnet.ibm.com>

On 04/22/2012 12:28 PM, Ayal Baron wrote:
>
>>> This way we'd have a 2 stage process:
>>> 1. setupStorage (generic)
>> I was looking up on the VDSM archives and there are talks of using
>> libstoragemgmt (lsm)
> Funny, we started using that acronym for Live Storage Migration :)
>
>> under VDSM. I was wondering if the setupStorage would be something
>> where
>> lsm would
>> be used to do the work, it seems fit for purpose here.
>>
>>
> I don't think this is the libstoragemgmt mandate.
>
> libstoragemgmt is:
> "A library that will provide a vendor agnostic open source storage application programming interface (API) for storage arrays."
>
> i.e. it is there to abstract storage array specifics from the user.
> It will be used by things like LVM etc, not the other way around.
>
> setupStorage would use libstoragemgmt wherever appropriate of course.
>
> But as the libstoragemgmt maintainer, Tony (cc'd) can correct me if I'm wrong here.
>
>

I was looking at setupStorage as Provisioning + Setting up.
I know one of the basic goals of lsm is provision the storage to the host
and preparing the storage for consumption is higher layers work.

With that, i think then its becomes a 3 stage process, from oVirt/VDSM 
pov...
1) Provision Storage (using lsm if applicable, based on whether external 
storage is connected)
2) Setup Storage (prepare the provisioned LUNs for usage)
3) createSD/createGlusterVolume/...  (plugin specific)

Since we are talking about Storage management using VDSM, i was
interested in understanding the plans, strategy of how VDSM + lsm
will integrate ?

thanx,
deepak





From tasleson at redhat.com  Mon Apr 23 15:45:27 2012
From: tasleson at redhat.com (Tony Asleson)
Date: Mon, 23 Apr 2012 10:45:27 -0500
Subject: [vdsm] Storage Device Management in VDSM and oVirt
In-Reply-To: <3a5c5eff-286d-46ab-9a72-8d0736f11aa0@zmail13.collab.prod.int.phx2.redhat.com>
References: <3a5c5eff-286d-46ab-9a72-8d0736f11aa0@zmail13.collab.prod.int.phx2.redhat.com>
Message-ID: <4F957917.80402@redhat.com>

On 04/22/2012 01:58 AM, Ayal Baron wrote:
> On 04/20/2012 02:23 PM, Deepak C Shetty wrote:
>> under VDSM. I was wondering if the setupStorage would be something
>> where lsm would be used to do the work, it seems fit for purpose
>> here.
>> 
>> 
> 
> I don't think this is the libstoragemgmt mandate.
> 
> libstoragemgmt is: "A library that will provide a vendor agnostic
> open source storage application programming interface (API) for
> storage arrays."
> 
> i.e. it is there to abstract storage array specifics from the user. 
> It will be used by things like LVM etc, not the other way around.

Yes, this is the current plan for libStorageMgmt.  To provide the
missing management path to third party storage arrays in a consistent
manner.

I'm starting to think that the project name is causing some confusion.
Some of the ambiguity was intentional as eventually the library will
hopefully allow users to manage other pieces of the storage puzzle like
FC switches, but perhaps it is too general.

I believe users would like tools/libraries to manage and simplify the
whole area of storage and
http://sourceforge.net/p/storagemanager/home/Home/ is working towards that.

-Tony


From abaron at redhat.com  Mon Apr 23 20:37:05 2012
From: abaron at redhat.com (Ayal Baron)
Date: Mon, 23 Apr 2012 16:37:05 -0400 (EDT)
Subject: [vdsm] Storage Device Management in VDSM and oVirt
In-Reply-To: <4F953CF4.80703@linux.vnet.ibm.com>
Message-ID: <fddd9805-e679-4122-8385-5181ca2e25b5@zmail13.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> On 04/22/2012 12:28 PM, Ayal Baron wrote:
> >
> >>> This way we'd have a 2 stage process:
> >>> 1. setupStorage (generic)
> >> I was looking up on the VDSM archives and there are talks of using
> >> libstoragemgmt (lsm)
> > Funny, we started using that acronym for Live Storage Migration :)
> >
> >> under VDSM. I was wondering if the setupStorage would be something
> >> where
> >> lsm would
> >> be used to do the work, it seems fit for purpose here.
> >>
> >>
> > I don't think this is the libstoragemgmt mandate.
> >
> > libstoragemgmt is:
> > "A library that will provide a vendor agnostic open source storage
> > application programming interface (API) for storage arrays."
> >
> > i.e. it is there to abstract storage array specifics from the user.
> > It will be used by things like LVM etc, not the other way around.
> >
> > setupStorage would use libstoragemgmt wherever appropriate of
> > course.
> >
> > But as the libstoragemgmt maintainer, Tony (cc'd) can correct me if
> > I'm wrong here.
> >
> >
> 
> I was looking at setupStorage as Provisioning + Setting up.
> I know one of the basic goals of lsm is provision the storage to the
> host
> and preparing the storage for consumption is higher layers work.
> 
> With that, i think then its becomes a 3 stage process, from
> oVirt/VDSM
> pov...
> 1) Provision Storage (using lsm if applicable, based on whether
> external
> storage is connected)
> 2) Setup Storage (prepare the provisioned LUNs for usage)
> 3) createSD/createGlusterVolume/...  (plugin specific)
> 
> Since we are talking about Storage management using VDSM, i was
> interested in understanding the plans, strategy of how VDSM + lsm
> will integrate ?


There are various ways of approaching this.
1. Given proper storage you could just provision new LUNs whenever you need a new virtual disk and utilize storage side thin provisioning and snapshots for most of your needs.
When you have such storage you don't really need steps 2 and 3 above.  Your storage is your virtual images repository.
Although quite simple and powerful, very few arrays are capable of growing to a very large number of objects (luns + snapshots + whatever) today, so I don't see this being the most common use case any time soon.

2. Provision LUNs (either statically or dynamically using lsm) once, preferably thinly provisioned. Then setupStorage (storage domain over VG / gLuster / other) and use lsm for creating snapshots/clones on the fly
In my opinion this will be more prevalent to begin with.

With lsm we will (hopefully) have a way of enumerating storage side capabilities so then when we create a repository (gluster / sd / ...) we'd be able to determine on the fly what capabilities it has and determine if to use these or to use virtualized capabilities (e.g. in the virt case when you need to create a snapshot use qcowX).

In oVirt, once you've defined a storage domain and it exposes a set of capabilities, user should be able to override (e.g. even though storage supports snapshots, I want to use qcow as this storage can only create 255 snapshots per volume and I need more than that).

I'm assuming that we will not have any way of knowing the limits per machine.

Does that make sense?

> 
> thanx,
> deepak
> 
> 
> 
> 


From lhawthor at redhat.com  Mon Apr 23 23:42:49 2012
From: lhawthor at redhat.com (Leslie Hawthorn)
Date: Mon, 23 Apr 2012 16:42:49 -0700
Subject: Planning oVirt Workshops
Message-ID: <4F95E8F9.7060508@redhat.com>

(N.B.: This message was copied to users at ovirt.org but I am not clear if 
my subscription was approved. If you happen to note that this message 
did not get to that list, let me know.)

Hello everyone,

I am a new(ish) hire at Red Hat working on Carl Trieloff's team. I will 
be attending tomorrow's oVirt IRC meeting to provide an update on 
upcoming oVirt workshops, but in the interim wanted to circulate a 
proposed agenda.

Please note that we're planning one day workshops at LinuxCon Japan, 
North America and Europe, as well as a 2 day workshop at NetApp HQ in 
California (target date 8 and 9th August 2012). As we're discussing 
workshop agendas for the one day events, it would be good to have an 
idea of what we'd like to present given the additional day.

Here is a *very* preliminary agenda:

- intro & arch
- engine, vdsm deep dives
- storage roadmap/discussion
- network roadmap/discussion

Open Questions:
1) What other topics should be covered during the workshop?
2) Who would like to volunteer to be an instructor?

Cheers,
LH

-- 
Leslie Hawthorn
Community Action and Impact
Open Source and Standards @ Red Hat

identi.ca/lh
twitter.com/lhawthorn



From mburns at redhat.com  Tue Apr 24 00:18:25 2012
From: mburns at redhat.com (Mike Burns)
Date: Mon, 23 Apr 2012 20:18:25 -0400
Subject: Planning oVirt Workshops
In-Reply-To: <4F95E8F9.7060508@redhat.com>
References: <4F95E8F9.7060508@redhat.com>
Message-ID: <1335226705.9449.3.camel@mburns-laptop.usersys.redhat.com>

On Mon, 2012-04-23 at 16:42 -0700, Leslie Hawthorn wrote:
> (N.B.: This message was copied to users at ovirt.org but I am not clear if 
> my subscription was approved. If you happen to note that this message 
> did not get to that list, let me know.)
> 
> Hello everyone,
> 
> I am a new(ish) hire at Red Hat working on Carl Trieloff's team. I will 
> be attending tomorrow's oVirt IRC meeting to provide an update on 
> upcoming oVirt workshops, but in the interim wanted to circulate a 
> proposed agenda.

I'm adding this to our agenda for tomorrow.

> 
> Please note that we're planning one day workshops at LinuxCon Japan, 
> North America and Europe, as well as a 2 day workshop at NetApp HQ in 
> California (target date 8 and 9th August 2012). As we're discussing 
> workshop agendas for the one day events, it would be good to have an 
> idea of what we'd like to present given the additional day.
> 
> Here is a *very* preliminary agenda:
> 
> - intro & arch
> - engine, vdsm deep dives
> - storage roadmap/discussion
> - network roadmap/discussion
> 
> Open Questions:
> 1) What other topics should be covered during the workshop?

oVirt Node is a core piece of oVirt.  It may be wise to add it as a
topic to cover, though who would present is a question.  If it's
something that we want to cover, then I'll need to request travel budget
for someone to attend.

> 2) Who would like to volunteer to be an instructor?
> 
> Cheers,
> LH
> 




From mburns at redhat.com  Tue Apr 24 00:49:59 2012
From: mburns at redhat.com (Mike Burns)
Date: Mon, 23 Apr 2012 20:49:59 -0400
Subject: Agenda for oVirt Weekly Sync 2012-04-24
Message-ID: <1335228599.9449.20.camel@mburns-laptop.usersys.redhat.com>

The latest agenda will always be online[1].

      * Status of Next Release
      * Sub-project reports (engine, vdsm, node)
      * Signed-off-by in commit tag check-up (rharper)
      * Java 7 in oVirt Engine (oschreib)
      * ovirt-engine-jbossas vs. Fedora17-jbossas (oschreib)
      * Moving to Fedora 17 (oschreib)
      * Do we need to re-evaluate release date based on above 3 items?
        (itamar)
      * Upcoming workshops
              * Topics
              * Dates/Events
      * Hardware availability for automated testing (mburns)
              * Would be good to have board members from sponsor
                companies available for this discussion


[1] http://www.ovirt.org/wiki/Meetings#Weekly_project_sync_meeting




From iheim at redhat.com  Tue Apr 24 04:00:39 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 24 Apr 2012 07:00:39 +0300
Subject: [Users] Planning oVirt Workshops
In-Reply-To: <4F95E8F9.7060508@redhat.com>
References: <4F95E8F9.7060508@redhat.com>
Message-ID: <4F962567.30905@redhat.com>

On 04/24/2012 02:42 AM, Leslie Hawthorn wrote:
> (N.B.: This message was copied to users at ovirt.org but I am not clear if
> my subscription was approved. If you happen to note that this message
> did not get to that list, let me know.)
>
> Hello everyone,
>
> I am a new(ish) hire at Red Hat working on Carl Trieloff's team. I will
> be attending tomorrow's oVirt IRC meeting to provide an update on
> upcoming oVirt workshops, but in the interim wanted to circulate a
> proposed agenda.
>
> Please note that we're planning one day workshops at LinuxCon Japan,
> North America and Europe, as well as a 2 day workshop at NetApp HQ in

small correction - LinuxCon Japan just has an ovirt intro session, not a 
workshop. nothing bigger planned for LinuxCon NA as of yet, less we 
coordinate something (CFP closes June 1st - community members encouraged 
to submit papers)
(it's also in California, two weeks after the workshop planned at Netapp)

as for LinuxCon Europe, we'll be joining the 2.5 days KVM forum (which 
is after linuxcon date wise). plan is for joint sessions in the mornings 
and separate tracks in the afternoon.


> California (target date 8 and 9th August 2012). As we're discussing
> workshop agendas for the one day events, it would be good to have an
> idea of what we'd like to present given the additional day.
>
> Here is a *very* preliminary agenda:
>
> - intro & arch
> - engine, vdsm deep dives
> - storage roadmap/discussion
> - network roadmap/discussion
>
> Open Questions:
> 1) What other topics should be covered during the workshop?
> 2) Who would like to volunteer to be an instructor?
>
> Cheers,
> LH
>



From dfediuck at redhat.com  Tue Apr 24 06:48:52 2012
From: dfediuck at redhat.com (Doron Fediuck)
Date: Tue, 24 Apr 2012 09:48:52 +0300
Subject: Planning oVirt Workshops
In-Reply-To: <1335226705.9449.3.camel@mburns-laptop.usersys.redhat.com>
References: <4F95E8F9.7060508@redhat.com>
	<1335226705.9449.3.camel@mburns-laptop.usersys.redhat.com>
Message-ID: <4F964CD4.7030900@redhat.com>

On 24/04/12 03:18, Mike Burns wrote:
> On Mon, 2012-04-23 at 16:42 -0700, Leslie Hawthorn wrote:
>> (N.B.: This message was copied to users at ovirt.org but I am not clear if 
>> my subscription was approved. If you happen to note that this message 
>> did not get to that list, let me know.)
>>
>> Hello everyone,
>>
>> I am a new(ish) hire at Red Hat working on Carl Trieloff's team. I will 
>> be attending tomorrow's oVirt IRC meeting to provide an update on 
>> upcoming oVirt workshops, but in the interim wanted to circulate a 
>> proposed agenda.
> 
> I'm adding this to our agenda for tomorrow.
> 
>>
>> Please note that we're planning one day workshops at LinuxCon Japan, 
>> North America and Europe, as well as a 2 day workshop at NetApp HQ in 
>> California (target date 8 and 9th August 2012). As we're discussing 
>> workshop agendas for the one day events, it would be good to have an 
>> idea of what we'd like to present given the additional day.
>>
>> Here is a *very* preliminary agenda:
>>
>> - intro & arch
>> - engine, vdsm deep dives
>> - storage roadmap/discussion
>> - network roadmap/discussion
>>
>> Open Questions:
>> 1) What other topics should be covered during the workshop?
> 
> oVirt Node is a core piece of oVirt.  It may be wise to add it as a
> topic to cover, though who would present is a question.  If it's
> something that we want to cover, then I'll need to request travel budget
> for someone to attend.
> 
+1 on the importance of ovirt-node.
Not going into the traveling logistics, I think every proper presentation
of oVirt projects should include an ovirt-node session.

>> 2) Who would like to volunteer to be an instructor?
>>
>> Cheers,
>> LH
>>
> 
> 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch



From deepakcs at linux.vnet.ibm.com  Tue Apr 24 11:30:28 2012
From: deepakcs at linux.vnet.ibm.com (Deepak C Shetty)
Date: Tue, 24 Apr 2012 17:00:28 +0530
Subject: [vdsm] Storage Device Management in VDSM and oVirt
In-Reply-To: <fddd9805-e679-4122-8385-5181ca2e25b5@zmail13.collab.prod.int.phx2.redhat.com>
References: <fddd9805-e679-4122-8385-5181ca2e25b5@zmail13.collab.prod.int.phx2.redhat.com>
Message-ID: <4F968ED4.7010809@linux.vnet.ibm.com>

On 04/24/2012 02:07 AM, Ayal Baron wrote:
>
> ----- Original Message -----
>> On 04/22/2012 12:28 PM, Ayal Baron wrote:
>>>>> This way we'd have a 2 stage process:
>>>>> 1. setupStorage (generic)
>>>> I was looking up on the VDSM archives and there are talks of using
>>>> libstoragemgmt (lsm)
>>> Funny, we started using that acronym for Live Storage Migration :)
>>>
>>>> under VDSM. I was wondering if the setupStorage would be something
>>>> where
>>>> lsm would
>>>> be used to do the work, it seems fit for purpose here.
>>>>
>>>>
>>> I don't think this is the libstoragemgmt mandate.
>>>
>>> libstoragemgmt is:
>>> "A library that will provide a vendor agnostic open source storage
>>> application programming interface (API) for storage arrays."
>>>
>>> i.e. it is there to abstract storage array specifics from the user.
>>> It will be used by things like LVM etc, not the other way around.
>>>
>>> setupStorage would use libstoragemgmt wherever appropriate of
>>> course.
>>>
>>> But as the libstoragemgmt maintainer, Tony (cc'd) can correct me if
>>> I'm wrong here.
>>>
>>>
>> I was looking at setupStorage as Provisioning + Setting up.
>> I know one of the basic goals of lsm is provision the storage to the
>> host
>> and preparing the storage for consumption is higher layers work.
>>
>> With that, i think then its becomes a 3 stage process, from
>> oVirt/VDSM
>> pov...
>> 1) Provision Storage (using lsm if applicable, based on whether
>> external
>> storage is connected)
>> 2) Setup Storage (prepare the provisioned LUNs for usage)
>> 3) createSD/createGlusterVolume/...  (plugin specific)
>>
>> Since we are talking about Storage management using VDSM, i was
>> interested in understanding the plans, strategy of how VDSM + lsm
>> will integrate ?
>
> There are various ways of approaching this.
> 1. Given proper storage you could just provision new LUNs whenever you need a new virtual disk and utilize storage side thin provisioning and snapshots for most of your needs.
> When you have such storage you don't really need steps 2 and 3 above.  Your storage is your virtual images repository.
> Although quite simple and powerful, very few arrays are capable of growing to a very large number of objects (luns + snapshots + whatever) today, so I don't see this being the most common use case any time soon.

This is not clear to me. This only talks about provisioning but not consuming.
2 and 3 above are required from a consumability perspective. The LUNs will have
to prepared and used by LVM (pv, vg, lv, metadata) for VDSM to host a storage domain.


> 2. Provision LUNs (either statically or dynamically using lsm) once, preferably thinly provisioned. Then setupStorage (storage domain over VG / gLuster / other) and use lsm for creating snapshots/clones on the fly
> In my opinion this will be more prevalent to begin with.
>
> With lsm we will (hopefully) have a way of enumerating storage side capabilities so then when we create a repository (gluster / sd / ...) we'd be able to determine on the fly what capabilities it has and determine if to use these or to use virtualized capabilities (e.g. in the virt case when you need to create a snapshot use qcowX).
>
> In oVirt, once you've defined a storage domain and it exposes a set of capabilities, user should be able to override (e.g. even though storage supports snapshots, I want to use qcow as this storage can only create 255 snapshots per volume and I need more than that).
>
> I'm assuming that we will not have any way of knowing the limits per machine.
>
> Does that make sense?
>

Agree to #2. Thinking deeper....

1) Provisioning Storage

Provisioning storage using lsm would require new VDSM verbs to be added,
which can create / show the LUNs to the oVirt user and user can then
select which LUN(s) to use for setupStorage.

Provisioning LUNs will probably exploit the lsm capabilities and provide
the options to the user to create the LUNs using the available array
features.

With GlusterFS also providing some of the array capabilities (stripe,
replicate etc), user might want to provision GlusterFS volume (with
whatever capabilities gluster offers) to host storage upon, especially
if the storage is coming from not-so-reliable commodity hw storage.

I feel this also has to be considered as part of provisioning and should
come before the setupStorage step.

IMHO, there should be a "Storage Provisioning" tab in oVirt which will
allow user to ...

     1a) Carve LUNs from external Storage array.

     1b) Provision storage as GlusterFS volume. User can select the LUNs
carved (from #1a) as bricks for GlusterFS volume, if need be.

     1c) Use local host free disk space.

Somewhere here there should be option ( as applicable) for user to
select whether to exploit storage array features or host virt
capabilities for say snapshot, in cases where both are applicable.

2) Setup Storage

Here the user would create VDSM file or block based storage domain,
based on the storage provisioned from the "Storage Provisioning" tab.
I believe this is where  VDSM will add its metadata to the provisioned
storage to make it a storage domain.

IMHO for image operations like snapshot/clone, VDSM will have to track&
maintain whether the image is served by local host, external storage
array or gluster volume and accordingly use the lvm, lsm or gluster apis
to get the job done.

3) Not sure if anymore steps needed ?


thanx,
deepak



From abaron at redhat.com  Tue Apr 24 14:07:55 2012
From: abaron at redhat.com (Ayal Baron)
Date: Tue, 24 Apr 2012 10:07:55 -0400 (EDT)
Subject: [vdsm] Storage Device Management in VDSM and oVirt
In-Reply-To: <4F968ED4.7010809@linux.vnet.ibm.com>
Message-ID: <a555ebae-952d-4d7a-82cc-6a9489da8e40@zmail13.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> On 04/24/2012 02:07 AM, Ayal Baron wrote:
> >
> > ----- Original Message -----
> >> On 04/22/2012 12:28 PM, Ayal Baron wrote:
> >>>>> This way we'd have a 2 stage process:
> >>>>> 1. setupStorage (generic)
> >>>> I was looking up on the VDSM archives and there are talks of
> >>>> using
> >>>> libstoragemgmt (lsm)
> >>> Funny, we started using that acronym for Live Storage Migration
> >>> :)
> >>>
> >>>> under VDSM. I was wondering if the setupStorage would be
> >>>> something
> >>>> where
> >>>> lsm would
> >>>> be used to do the work, it seems fit for purpose here.
> >>>>
> >>>>
> >>> I don't think this is the libstoragemgmt mandate.
> >>>
> >>> libstoragemgmt is:
> >>> "A library that will provide a vendor agnostic open source
> >>> storage
> >>> application programming interface (API) for storage arrays."
> >>>
> >>> i.e. it is there to abstract storage array specifics from the
> >>> user.
> >>> It will be used by things like LVM etc, not the other way around.
> >>>
> >>> setupStorage would use libstoragemgmt wherever appropriate of
> >>> course.
> >>>
> >>> But as the libstoragemgmt maintainer, Tony (cc'd) can correct me
> >>> if
> >>> I'm wrong here.
> >>>
> >>>
> >> I was looking at setupStorage as Provisioning + Setting up.
> >> I know one of the basic goals of lsm is provision the storage to
> >> the
> >> host
> >> and preparing the storage for consumption is higher layers work.
> >>
> >> With that, i think then its becomes a 3 stage process, from
> >> oVirt/VDSM
> >> pov...
> >> 1) Provision Storage (using lsm if applicable, based on whether
> >> external
> >> storage is connected)
> >> 2) Setup Storage (prepare the provisioned LUNs for usage)
> >> 3) createSD/createGlusterVolume/...  (plugin specific)
> >>
> >> Since we are talking about Storage management using VDSM, i was
> >> interested in understanding the plans, strategy of how VDSM + lsm
> >> will integrate ?
> >
> > There are various ways of approaching this.
> > 1. Given proper storage you could just provision new LUNs whenever
> > you need a new virtual disk and utilize storage side thin
> > provisioning and snapshots for most of your needs.
> > When you have such storage you don't really need steps 2 and 3
> > above.  Your storage is your virtual images repository.
> > Although quite simple and powerful, very few arrays are capable of
> > growing to a very large number of objects (luns + snapshots +
> > whatever) today, so I don't see this being the most common use
> > case any time soon.
> 
> This is not clear to me. This only talks about provisioning but not
> consuming.
> 2 and 3 above are required from a consumability perspective. The LUNs
> will have
> to prepared and used by LVM (pv, vg, lv, metadata) for VDSM to host a
> storage domain.

There are several ways of managing the repo in such a scenario, just an example is to provision a LUN where vdsm would manage metadata (listing of images, relations between snapshots, logical sizes of images, etc) and every image is another LUN that we would provision, so there would be no need for LVM in such a scenario.

> 
> 
> > 2. Provision LUNs (either statically or dynamically using lsm)
> > once, preferably thinly provisioned. Then setupStorage (storage
> > domain over VG / gLuster / other) and use lsm for creating
> > snapshots/clones on the fly
> > In my opinion this will be more prevalent to begin with.
> >
> > With lsm we will (hopefully) have a way of enumerating storage side
> > capabilities so then when we create a repository (gluster / sd /
> > ...) we'd be able to determine on the fly what capabilities it has
> > and determine if to use these or to use virtualized capabilities
> > (e.g. in the virt case when you need to create a snapshot use
> > qcowX).
> >
> > In oVirt, once you've defined a storage domain and it exposes a set
> > of capabilities, user should be able to override (e.g. even though
> > storage supports snapshots, I want to use qcow as this storage can
> > only create 255 snapshots per volume and I need more than that).
> >
> > I'm assuming that we will not have any way of knowing the limits
> > per machine.
> >
> > Does that make sense?
> >
> 
> Agree to #2. Thinking deeper....
> 
> 1) Provisioning Storage
> 
> Provisioning storage using lsm would require new VDSM verbs to be
> added,
> which can create / show the LUNs to the oVirt user and user can then
> select which LUN(s) to use for setupStorage.

create LUN doesn't exist today, but show LUNs does.

Currently the (simplified) flow is:
1. connect to storage (when relevant)
2. get listing of devices
3. create a storage domain on selected devices

> 
> Provisioning LUNs will probably exploit the lsm capabilities and
> provide
> the options to the user to create the LUNs using the available array
> features.
> 
> With GlusterFS also providing some of the array capabilities (stripe,
> replicate etc), user might want to provision GlusterFS volume (with
> whatever capabilities gluster offers) to host storage upon,
> especially
> if the storage is coming from not-so-reliable commodity hw storage.
> 
> I feel this also has to be considered as part of provisioning and
> should
> come before the setupStorage step.
> 
> IMHO, there should be a "Storage Provisioning" tab in oVirt which
> will
> allow user to ...
> 
>      1a) Carve LUNs from external Storage array.
> 
>      1b) Provision storage as GlusterFS volume. User can select the
>      LUNs
> carved (from #1a) as bricks for GlusterFS volume, if need be.
> 
>      1c) Use local host free disk space.
> 
> Somewhere here there should be option ( as applicable) for user to
> select whether to exploit storage array features or host virt
> capabilities for say snapshot, in cases where both are applicable.
> 
> 2) Setup Storage
> 
> Here the user would create VDSM file or block based storage domain,
> based on the storage provisioned from the "Storage Provisioning" tab.
> I believe this is where  VDSM will add its metadata to the
> provisioned
> storage to make it a storage domain.
> 
> IMHO for image operations like snapshot/clone, VDSM will have to
> track&
> maintain whether the image is served by local host, external storage
> array or gluster volume and accordingly use the lvm, lsm or gluster
> apis
> to get the job done.

For sure.  That would be part of the domain metadata.

> 
> 3) Not sure if anymore steps needed ?

In general I agree with the above.  wrt the scope of setupStorage, it's semantics.  Personally I think we should differentiate between provisioning storage on the target side and provisioning on the initiator side.

The flow (from GUI) as I see it is (with lsm and an array that supports dynamic provisioning):
1. provide credentials and login into storage (out of band, using lsm)
2. enumerate capabilities
3. based on 2, define required storage domain characteristics (size, thin provisioning, etc) 
  - but note that this is generic, so should apply to gluster as well
4. create a storage domain - would implicitly create 1 or more LUNs and anything else that is needed according to above specifications.  API wise, this is probably 3 calls, 1. provision LUNs, 2. setupStorage and 3. createStorageDomain/createGlusterVolume/...

Characteristics might include things like partitions, encryption?, compression?, raid, file systems, etc.

> 
> 
> thanx,
> deepak
> 
> 


From mburns at redhat.com  Tue Apr 24 15:18:35 2012
From: mburns at redhat.com (Mike Burns)
Date: Tue, 24 Apr 2012 11:18:35 -0400
Subject: oVirt Weekly Sync Meeting - 2012-04-24
Message-ID: <1335280715.8073.71.camel@beelzebub.mburnsfire.net>

Minutes:        http://ovirt.org/meetings/ovirt/2012/ovirt.2012-04-24-14.00.html
Minutes (text): http://ovirt.org/meetings/ovirt/2012/ovirt.2012-04-24-14.00.txt
Log:            http://ovirt.org/meetings/ovirt/2012/ovirt.2012-04-24-14.00.log.html

=========================
#ovirt: oVirt Weekly Sync
=========================


Meeting started by mburns at 14:00:30 UTC. The full logs are available
at http://ovirt.org/meetings/ovirt/2012/ovirt.2012-04-24-14.00.log.html
.



Meeting summary
---------------
* Agenda and Roll Call  (mburns, 14:00:47)
  * LINK: http://www.ovirt.org/wiki/Meetings#Weekly_project_sync_meeting
    (mburns, 14:02:59)

* Next Release Status  (mburns, 14:03:47)
  * feature freeze is April 30  (mburns, 14:04:54)
  * AGREED: move release to 2012-06-30 and feature freeze to 2012-05-31
    (mburns, 14:13:41)
  * test day will move out as well  (mburns, 14:15:57)
  * AGREED: release date June 27, possible slip to Jul 2  (mburns,
    14:20:26)
  * AGREED: target May 15 for alpha release  (mburns, 14:23:51)
  * ACTION: oschreib to send notification of release date change to
    arch@ users@ board@  (mburns, 14:25:31)
  * AGREED: alpha testing is on F17 RC  (mburns, 14:28:23)

* java 7, f17 and jboss rpms  (mburns, 14:32:11)
  * we're trying to use F17 with java 7 and distro specific jboss rpms
    where available  (mburns, 14:32:39)
  * AGREED: Fedora 17 support is a blocker  (mburns, 14:34:54)
  * AGREED: using distro jboss rpms is not a blocker, but is a goal
    (mburns, 14:38:37)
  * we should re-evaluate if we're going to miss using distro jboss rpms
    (mburns, 14:39:19)
  * if small delay, we may choose to slip the release to get it in
    (mburns, 14:39:39)
  * ACTION: mburns to add fedora jboss and java 7 to agenda to
    re-evaluate  (mburns, 14:43:11)
  * AGREED: java 7 is a goal, will re-evaluate for blocker status on the
    next meeting  (mburns, 14:44:08)

* Upcoming workshops  (mburns, 14:44:42)
  * one-day workshops added at LC Japan, NA, Europe  (mburns, 14:45:49)
  * LINK: http://lists.ovirt.org/pipermail/arch/2012-April/000528.html
    (mburns, 14:47:51)

* Signed-off-by  (mburns, 15:04:11)
  * enabled in ovirt-node and ovirt-node-iso  (mburns, 15:04:28)
  * AGREED: all projects will require signed-off-by starting may 1st
    (mburns, 15:06:31)
  * LINK: http://kerneltrap.org/files/Jeremy/DCO.txt   (mburns,
    15:09:28)

* sub-project status  (mburns, 15:10:38)
  * node should be good with new dates, only major tasks left are
    stability and f17 testing which are starting this week  (mburns,
    15:11:18)

* Other Topics  (mburns, 15:12:45)
  * Next Week's Meeting is Wednesday 2012-05-01 at 14:00 UTC (10:00 AM
    EDT)  (mburns, 15:14:02)

Meeting ended at 15:14:43 UTC.




Action Items
------------
* oschreib to send notification of release date change to arch@ users@
  board@
* mburns to add fedora jboss and java 7 to agenda to re-evaluate




Action Items, by person
-----------------------
* mburns
  * mburns to add fedora jboss and java 7 to agenda to re-evaluate
* oschreib
  * oschreib to send notification of release date change to arch@ users@
    board@
* **UNASSIGNED**
  * (none)




People Present (lines said)
---------------------------
* mburns (138)
* itamar (58)
* oschreib (27)
* lh (26)
* lpeer (22)
* doronf (22)
* cctrieloff (21)
* aglitke_ (8)
* ovirtbot (6)
* jb_netapp (5)
* miki (4)
* rharper (4)
* quaid (4)
* bazulay (3)
* masayag (2)
* sgordon (2)
* aliguori (1)
* jhernand (1)
* ofrenkel (1)
* dustins (1)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot



From oschreib at redhat.com  Tue Apr 24 16:23:21 2012
From: oschreib at redhat.com (Ofer Schreiber)
Date: Tue, 24 Apr 2012 12:23:21 -0400 (EDT)
Subject: UPDATE: oVirt 3.1 release date changed
In-Reply-To: <841357b3-e51d-401d-a830-be5cec867995@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <1b854f4d-94da-4579-bf55-96c0e05e1a34@zmail14.collab.prod.int.phx2.redhat.com>

Due to multiple integration issues (Java 7, Fedora 17 and JBoss official rpm support) we've decided to postpone the next release of oVirt [1] to June 27th.

This one month delay will hopefully give us enough time to stabilize all the different layers of oVirt, and produce a better release.

Stay tuned,

--
Ofer Schreiber
oVirt Release Manager

[1] http://www.ovirt.org/wiki/Second_Release


From deepakcs at linux.vnet.ibm.com  Wed Apr 25 11:22:34 2012
From: deepakcs at linux.vnet.ibm.com (Deepak C Shetty)
Date: Wed, 25 Apr 2012 16:52:34 +0530
Subject: [vdsm] Storage Device Management in VDSM and oVirt
In-Reply-To: <a555ebae-952d-4d7a-82cc-6a9489da8e40@zmail13.collab.prod.int.phx2.redhat.com>
References: <a555ebae-952d-4d7a-82cc-6a9489da8e40@zmail13.collab.prod.int.phx2.redhat.com>
Message-ID: <4F97DE7A.2040808@linux.vnet.ibm.com>

On 04/24/2012 07:37 PM, Ayal Baron wrote:
>
> ----- Original Message -----
>> On 04/24/2012 02:07 AM, Ayal Baron wrote:
>>> ----- Original Message -----
>>>> On 04/22/2012 12:28 PM, Ayal Baron wrote:
>>>>>>> This way we'd have a 2 stage process:
>>>>>>> 1. setupStorage (generic)
>>>>>> I was looking up on the VDSM archives and there are talks of
>>>>>> using
>>>>>> libstoragemgmt (lsm)
>>>>> Funny, we started using that acronym for Live Storage Migration
>>>>> :)
>>>>>
>>>>>> under VDSM. I was wondering if the setupStorage would be
>>>>>> something
>>>>>> where
>>>>>> lsm would
>>>>>> be used to do the work, it seems fit for purpose here.
>>>>>>
>>>>>>
>>>>> I don't think this is the libstoragemgmt mandate.
>>>>>
>>>>> libstoragemgmt is:
>>>>> "A library that will provide a vendor agnostic open source
>>>>> storage
>>>>> application programming interface (API) for storage arrays."
>>>>>
>>>>> i.e. it is there to abstract storage array specifics from the
>>>>> user.
>>>>> It will be used by things like LVM etc, not the other way around.
>>>>>
>>>>> setupStorage would use libstoragemgmt wherever appropriate of
>>>>> course.
>>>>>
>>>>> But as the libstoragemgmt maintainer, Tony (cc'd) can correct me
>>>>> if
>>>>> I'm wrong here.
>>>>>
>>>>>
>>>> I was looking at setupStorage as Provisioning + Setting up.
>>>> I know one of the basic goals of lsm is provision the storage to
>>>> the
>>>> host
>>>> and preparing the storage for consumption is higher layers work.
>>>>
>>>> With that, i think then its becomes a 3 stage process, from
>>>> oVirt/VDSM
>>>> pov...
>>>> 1) Provision Storage (using lsm if applicable, based on whether
>>>> external
>>>> storage is connected)
>>>> 2) Setup Storage (prepare the provisioned LUNs for usage)
>>>> 3) createSD/createGlusterVolume/...  (plugin specific)
>>>>
>>>> Since we are talking about Storage management using VDSM, i was
>>>> interested in understanding the plans, strategy of how VDSM + lsm
>>>> will integrate ?
>>> There are various ways of approaching this.
>>> 1. Given proper storage you could just provision new LUNs whenever
>>> you need a new virtual disk and utilize storage side thin
>>> provisioning and snapshots for most of your needs.
>>> When you have such storage you don't really need steps 2 and 3
>>> above.  Your storage is your virtual images repository.
>>> Although quite simple and powerful, very few arrays are capable of
>>> growing to a very large number of objects (luns + snapshots +
>>> whatever) today, so I don't see this being the most common use
>>> case any time soon.
>> This is not clear to me. This only talks about provisioning but not
>> consuming.
>> 2 and 3 above are required from a consumability perspective. The LUNs
>> will have
>> to prepared and used by LVM (pv, vg, lv, metadata) for VDSM to host a
>> storage domain.
> There are several ways of managing the repo in such a scenario, just an example is to provision a LUN where vdsm would manage metadata (listing of images, relations between snapshots, logical sizes of images, etc) and every image is another LUN that we would provision, so there would be no need for LVM in such a scenario.
>

Sorry, but not clear to me. If vdsm is configured for file based storage 
domain, it would expect the LUN to have a fs, and vdsm would create the 
fs storage domain over it. If vdsm is configured for block based storage 
domain, it would end up using the LUN as a pv, over which the VG/LV 
would sit (hence the need for lvm) and form the block storage domain, 
unless you are talking of vdsm using raw LUNs which is not supported today ?

>>
>>> 2. Provision LUNs (either statically or dynamically using lsm)
>>> once, preferably thinly provisioned. Then setupStorage (storage
>>> domain over VG / gLuster / other) and use lsm for creating
>>> snapshots/clones on the fly
>>> In my opinion this will be more prevalent to begin with.
>>>
>>> With lsm we will (hopefully) have a way of enumerating storage side
>>> capabilities so then when we create a repository (gluster / sd /
>>> ...) we'd be able to determine on the fly what capabilities it has
>>> and determine if to use these or to use virtualized capabilities
>>> (e.g. in the virt case when you need to create a snapshot use
>>> qcowX).
>>>
>>> In oVirt, once you've defined a storage domain and it exposes a set
>>> of capabilities, user should be able to override (e.g. even though
>>> storage supports snapshots, I want to use qcow as this storage can
>>> only create 255 snapshots per volume and I need more than that).
>>>
>>> I'm assuming that we will not have any way of knowing the limits
>>> per machine.
>>>
>>> Does that make sense?
>>>
>> Agree to #2. Thinking deeper....
>>
>> 1) Provisioning Storage
>>
>> Provisioning storage using lsm would require new VDSM verbs to be
>> added,
>> which can create / show the LUNs to the oVirt user and user can then
>> select which LUN(s) to use for setupStorage.
> create LUN doesn't exist today, but show LUNs does.
>
> Currently the (simplified) flow is:
> 1. connect to storage (when relevant)
> 2. get listing of devices
> 3. create a storage domain on selected devices
>
>> Provisioning LUNs will probably exploit the lsm capabilities and
>> provide
>> the options to the user to create the LUNs using the available array
>> features.
>>
>> With GlusterFS also providing some of the array capabilities (stripe,
>> replicate etc), user might want to provision GlusterFS volume (with
>> whatever capabilities gluster offers) to host storage upon,
>> especially
>> if the storage is coming from not-so-reliable commodity hw storage.
>>
>> I feel this also has to be considered as part of provisioning and
>> should
>> come before the setupStorage step.
>>
>> IMHO, there should be a "Storage Provisioning" tab in oVirt which
>> will
>> allow user to ...
>>
>>       1a) Carve LUNs from external Storage array.
>>
>>       1b) Provision storage as GlusterFS volume. User can select the
>>       LUNs
>> carved (from #1a) as bricks for GlusterFS volume, if need be.
>>
>>       1c) Use local host free disk space.
>>
>> Somewhere here there should be option ( as applicable) for user to
>> select whether to exploit storage array features or host virt
>> capabilities for say snapshot, in cases where both are applicable.
>>
>> 2) Setup Storage
>>
>> Here the user would create VDSM file or block based storage domain,
>> based on the storage provisioned from the "Storage Provisioning" tab.
>> I believe this is where  VDSM will add its metadata to the
>> provisioned
>> storage to make it a storage domain.
>>
>> IMHO for image operations like snapshot/clone, VDSM will have to
>> track&
>> maintain whether the image is served by local host, external storage
>> array or gluster volume and accordingly use the lvm, lsm or gluster
>> apis
>> to get the job done.
> For sure.  That would be part of the domain metadata.
>
>> 3) Not sure if anymore steps needed ?
> In general I agree with the above.  wrt the scope of setupStorage, it's semantics.  Personally I think we should differentiate between provisioning storage on the target side and provisioning on the initiator side.
>
> The flow (from GUI) as I see it is (with lsm and an array that supports dynamic provisioning):
> 1. provide credentials and login into storage (out of band, using lsm)
> 2. enumerate capabilities
> 3. based on 2, define required storage domain characteristics (size, thin provisioning, etc)
>    - but note that this is generic, so should apply to gluster as well
> 4. create a storage domain - would implicitly create 1 or more LUNs and anything else that is needed according to above specifications.  API wise, this is probably 3 calls, 1. provision LUNs, 2. setupStorage and 3. createStorageDomain/createGlusterVolume/...
>
> Characteristics might include things like partitions, encryption?, compression?, raid, file systems, etc.
>

This seems interesting.

I am interested in pursuing this further and helping contribute to the 
vdsm lsm integration. lsm is still in the early stages, but i feel its 
the right time to start influencing it so that vdsm integration can be 
smooth. My interest mainly lies in how external storage array can be 
integrated into oVirt/VDSM and help oVirt exploit the array offload 
features as part of the virtualization stack.

I didn't find any oVirt wiki page on this topic, tho' there is a old 
mailing list thread on vdsm lsm integration, which when read brings up 
more issues to discuss :)
How does storage repo engine and possible vdsm services framework ( i 
learnt about these in my brief chat with Saggie some time back) play a 
role here ?

Can "Provisioning Storage" itself be like a high level service, with 
gluster and lsm  exposing storage services, which vdsm can enumerate and 
send to oVirt GUI, is that the idea ?
Is there any wiki page on this topic which lists the todos on this 
front, which I can start looking at ?

thanx,
deepak



From cctrieloff at redhat.com  Thu Apr 26 23:54:02 2012
From: cctrieloff at redhat.com (Carl Trieloff)
Date: Thu, 26 Apr 2012 19:54:02 -0400
Subject: CFP -- volunteer to submit an oVirt talk?
Message-ID: <4F99E01A.7020508@redhat.com>



7th Workshop on Virtualization in High Performance Computing - closes
June 4th
http://vhpc.org/


regards
Carl.


From gkotton at redhat.com  Sun Apr 29 10:38:19 2012
From: gkotton at redhat.com (Gary Kotton)
Date: Sun, 29 Apr 2012 13:38:19 +0300
Subject: oVirt and Quantum
Message-ID: <4F9D1A1B.2020900@redhat.com>

Hi,
As part of a POC we have integrated Quantum 
(http://wiki.openstack.org/Quantum) into oVirt (http://www.ovirt.org/). 
This has been tested with the OVS and Linux Bridge plugins.
The details of the integration can be found at - 
https://fedoraproject.org/wiki/Quantum_and_oVirt.
Any comments and suggestions would be greatly appreciated.
Thanks
Gary


From ovedo at redhat.com  Sun Apr 29 11:50:42 2012
From: ovedo at redhat.com (Oved Ourfalli)
Date: Sun, 29 Apr 2012 07:50:42 -0400 (EDT)
Subject: oVirt and Quantum
In-Reply-To: <4F9D1A1B.2020900@redhat.com>
Message-ID: <444331bf-10b9-47a9-aa40-cf84bbfdbe84@zmail02.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Gary Kotton" <gkotton at redhat.com>
> To: arch at ovirt.org
> Sent: Sunday, April 29, 2012 1:38:19 PM
> Subject: oVirt and Quantum
> 
> Hi,
> As part of a POC we have integrated Quantum
> (http://wiki.openstack.org/Quantum) into oVirt
> (http://www.ovirt.org/).
> This has been tested with the OVS and Linux Bridge plugins.
> The details of the integration can be found at -
> https://fedoraproject.org/wiki/Quantum_and_oVirt.
> Any comments and suggestions would be greatly appreciated.

Hey,
I know it is only a POC, but if you can share the source code via gerrit that would be great.
That way we will be able to track all the locations in which you did your changes, and we might be able to give input on the issues you had.

Also, on the issue:
"Quantum enables a vNic to be assigned to a different network at run time - this can now be enabled by oVirt, that is, for oVirt to add or edit a NIC, the VM has to be stopped) "
I guess you meant to say "this can not be enabled..." instead of "this can now be enabled...". Also, remove the closing bracket there.
However, we added the ability to hot-plug/unplug a NIC to a running VM, so I guess the change can now be done when the VM is up, and the NIC is unplugged, so you can add a comment about that as well.

Thank you,
Oved

> Thanks
> Gary
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From gkotton at redhat.com  Sun Apr 29 12:01:27 2012
From: gkotton at redhat.com (Gary Kotton)
Date: Sun, 29 Apr 2012 15:01:27 +0300
Subject: oVirt and Quantum
In-Reply-To: <444331bf-10b9-47a9-aa40-cf84bbfdbe84@zmail02.collab.prod.int.phx2.redhat.com>
References: <444331bf-10b9-47a9-aa40-cf84bbfdbe84@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <4F9D2D97.1000200@redhat.com>

On 04/29/2012 02:50 PM, Oved Ourfalli wrote:
>
> I know it is only a POC, but if you can share the source code via gerrit that would be great.
I am in the process of doing this. I encountered a number of problems 
with the way in which oVirt handles the host "availability" status - the 
code that I was using did not work well with Quantum (I understand that 
a fix was done upstream a a short while ago). I am currently doing a 
rebase and a merge. When this compiles and works I'll post the updates.

> That way we will be able to track all the locations in which you did your changes, and we might be able to give input on the issues you had.
>
> Also, on the issue:
> "Quantum enables a vNic to be assigned to a different network at run time - this can now be enabled by oVirt, that is, for oVirt to add or edit a NIC, the VM has to be stopped)"
> I guess you meant to say "this can not be enabled..." instead of "this can now be enabled...". Also, remove the closing bracket there.
In the oVirt version that I have if the user wishes to update a network, 
he/she has to shutdown the VM, perform the network change and then 
restart the VM. In the case of Quantum one can perform the updates 
whilst the VM is running.
> However, we added the ability to hot-plug/unplug a NIC to a running VM, so I guess the change can now be done when the VM is up, and the NIC is unplugged, so you can add a comment about that as well.
If the plug/unplug feature exists then I'll remove the comment on the 
wiki. In which oVirt version does this exist?

Thanks for the comments
Gary

> Thank you,
> Oved
>
>> Thanks
>> Gary
>> _______________________________________________
>> Arch mailing list
>> Arch at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch
>>



From ovedo at redhat.com  Sun Apr 29 12:04:49 2012
From: ovedo at redhat.com (Oved Ourfalli)
Date: Sun, 29 Apr 2012 08:04:49 -0400 (EDT)
Subject: oVirt and Quantum
In-Reply-To: <4F9D2D97.1000200@redhat.com>
Message-ID: <c5067548-1159-4d73-b905-6f99a476810f@zmail02.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Gary Kotton" <gkotton at redhat.com>
> To: "Oved Ourfalli" <ovedo at redhat.com>
> Cc: arch at ovirt.org
> Sent: Sunday, April 29, 2012 3:01:27 PM
> Subject: Re: oVirt and Quantum
> 
> On 04/29/2012 02:50 PM, Oved Ourfalli wrote:
> >
> > I know it is only a POC, but if you can share the source code via
> > gerrit that would be great.
> I am in the process of doing this. I encountered a number of problems
> with the way in which oVirt handles the host "availability" status -
> the
> code that I was using did not work well with Quantum (I understand
> that
> a fix was done upstream a a short while ago). I am currently doing a
> rebase and a merge. When this compiles and works I'll post the
> updates.
> 
> > That way we will be able to track all the locations in which you
> > did your changes, and we might be able to give input on the issues
> > you had.
> >
> > Also, on the issue:
> > "Quantum enables a vNic to be assigned to a different network at
> > run time - this can now be enabled by oVirt, that is, for oVirt to
> > add or edit a NIC, the VM has to be stopped)"
> > I guess you meant to say "this can not be enabled..." instead of
> > "this can now be enabled...". Also, remove the closing bracket
> > there.
> In the oVirt version that I have if the user wishes to update a
> network,
> he/she has to shutdown the VM, perform the network change and then
> restart the VM. In the case of Quantum one can perform the updates
> whilst the VM is running.
> > However, we added the ability to hot-plug/unplug a NIC to a running
> > VM, so I guess the change can now be done when the VM is up, and
> > the NIC is unplugged, so you can add a comment about that as well.
> If the plug/unplug feature exists then I'll remove the comment on the
> wiki. In which oVirt version does this exist?
> 
It was recently pushed upstream, so I guess there is no official version with that, but the next one will have this feature.

> Thanks for the comments
> Gary
> 
> > Thank you,
> > Oved
> >
> >> Thanks
> >> Gary
> >> _______________________________________________
> >> Arch mailing list
> >> Arch at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/arch
> >>
> 
> 


From gkotton at redhat.com  Sun Apr 29 12:05:44 2012
From: gkotton at redhat.com (Gary Kotton)
Date: Sun, 29 Apr 2012 15:05:44 +0300
Subject: oVirt and Quantum
In-Reply-To: <c5067548-1159-4d73-b905-6f99a476810f@zmail02.collab.prod.int.phx2.redhat.com>
References: <c5067548-1159-4d73-b905-6f99a476810f@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <4F9D2E98.4050607@redhat.com>

On 04/29/2012 03:04 PM, Oved Ourfalli wrote:
> It was recently pushed upstream, so I guess there is no official version with that, but the next one will have this feature.
>
Great - I have removed the comment from the wiki.
Thanks
Gary


From mburns at redhat.com  Mon Apr 30 12:36:18 2012
From: mburns at redhat.com (Mike Burns)
Date: Mon, 30 Apr 2012 08:36:18 -0400
Subject: oVirt and Quantum
In-Reply-To: <4F9D1A1B.2020900@redhat.com>
References: <4F9D1A1B.2020900@redhat.com>
Message-ID: <1335789378.9282.3.camel@beelzebub.mburnsfire.net>

On Sun, 2012-04-29 at 13:38 +0300, Gary Kotton wrote:
> Hi,
> As part of a POC we have integrated Quantum 
> (http://wiki.openstack.org/Quantum) into oVirt (http://www.ovirt.org/). 
> This has been tested with the OVS and Linux Bridge plugins.
> The details of the integration can be found at - 
> https://fedoraproject.org/wiki/Quantum_and_oVirt.

Is there a reason for this being on the fedoraproject wiki rather than
the ovirt.org wiki?

> Any comments and suggestions would be greatly appreciated.
> Thanks
> Gary
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch




From gkotton at redhat.com  Mon Apr 30 12:40:39 2012
From: gkotton at redhat.com (Gary Kotton)
Date: Mon, 30 Apr 2012 15:40:39 +0300
Subject: oVirt and Quantum
In-Reply-To: <1335789378.9282.3.camel@beelzebub.mburnsfire.net>
References: <4F9D1A1B.2020900@redhat.com>
	<1335789378.9282.3.camel@beelzebub.mburnsfire.net>
Message-ID: <4F9E8847.5080601@redhat.com>

On 04/30/2012 03:36 PM, Mike Burns wrote:
> On Sun, 2012-04-29 at 13:38 +0300, Gary Kotton wrote:
>> Hi,
>> As part of a POC we have integrated Quantum
>> (http://wiki.openstack.org/Quantum) into oVirt (http://www.ovirt.org/).
>> This has been tested with the OVS and Linux Bridge plugins.
>> The details of the integration can be found at -
>> https://fedoraproject.org/wiki/Quantum_and_oVirt.
> Is there a reason for this being on the fedoraproject wiki rather than
> the ovirt.org wiki?
We originally created a page for Quantum on Fedora and worked on that. I 
agree with you that it should also exist on the oVirt wiki. I try and do 
this soon
>> Any comments and suggestions would be greatly appreciated.
>> Thanks
>> Gary
>> _______________________________________________
>> Arch mailing list
>> Arch at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch
>



From lhawthor at redhat.com  Mon Apr 30 16:55:46 2012
From: lhawthor at redhat.com (Leslie Hawthorn)
Date: Mon, 30 Apr 2012 09:55:46 -0700
Subject: Agenda for LinuxCon Japan Workshop
Message-ID: <4F9EC412.2080603@redhat.com>

Hello everyone,

As mentioned during last week's IRC meeting, we have an oVirt workshop 
scheduled for LinuxCon Japan. [0] The Linux Foundation needs our agenda, 
as well as speaker list and bios,  by this Thursday, 3 May, so they can 
begin promoting.

Here's the proposed agenda for the upcoming workshop:

* 09:00 - 11:00 :: Welcome, introduction to oVirt architecture & demo 
(includes API/SDK/CLI)
* 11:00 - 12:00 :: Engine core
* 12:00 - 13:30 :: Lunch
* 13:30 - 14:30 :: VDSM
* 14:30 - 15:30 :: Node arch and details
* 15:30 - 16:00 :: Break
* 16:00 - 17:00 :: Linux virtualization panel (main conference)

Open Questions:

1) Are there additional sessions that folks would like to propose for 
this workshop?
2) Would anyone like to volunteer as an instructor for any of the above 
proposed sessions?

As mentioned, we need to have all of this information in to the Linux 
Foundation by this Thursday, so please send in your feedback as soon as 
you are able.

[0] - https://events.linuxfoundation.org/events/linuxcon-japan

Thank you,
LH

-- 
Leslie Hawthorn
Community Action and Impact
Open Source and Standards @ Red Hat

identi.ca/lh
twitter.com/lhawthorn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20120430/bfa27b1c/attachment.html>

From mburns at redhat.com  Mon Apr 30 17:01:21 2012
From: mburns at redhat.com (Mike Burns)
Date: Mon, 30 Apr 2012 13:01:21 -0400
Subject: Agenda for LinuxCon Japan Workshop
In-Reply-To: <4F9EC412.2080603@redhat.com>
References: <4F9EC412.2080603@redhat.com>
Message-ID: <1335805281.9282.8.camel@beelzebub.mburnsfire.net>

On Mon, 2012-04-30 at 09:55 -0700, Leslie Hawthorn wrote:
> Hello everyone,
> 
> As mentioned during last week's IRC meeting, we have an oVirt workshop
> scheduled for LinuxCon Japan. [0] The Linux Foundation needs our
> agenda, as well as speaker list and bios,  by this Thursday, 3 May, so
> they can begin promoting.
> 
> Here's the proposed agenda for the upcoming workshop:
> 
> * 09:00 - 11:00 :: Welcome, introduction to oVirt architecture & demo
> (includes API/SDK/CLI) 
> * 11:00 - 12:00 :: Engine core
> * 12:00 - 13:30 :: Lunch 
> * 13:30 - 14:30 :: VDSM 
> * 14:30 - 15:30 :: Node arch and details 

I can't get anyone there to discuss the Node.  If there are people
attending that are willing to give a presentation, I'd be happy to work
with you on the content.  But as of right now, there isn't anyone going
who could give this talk.

Mike

> * 15:30 - 16:00 :: Break 
> * 16:00 - 17:00 :: Linux virtualization panel (main conference)
> 
> Open Questions:
> 
> 1) Are there additional sessions that folks would like to propose for
> this workshop?
> 2) Would anyone like to volunteer as an instructor for any of the
> above proposed sessions?
> 
> As mentioned, we need to have all of this information in to the Linux
> Foundation by this Thursday, so please send in your feedback as soon
> as you are able.
> 
> [0] - https://events.linuxfoundation.org/events/linuxcon-japan
> 
> Thank you,
> LH
> -- 
> Leslie Hawthorn
> Community Action and Impact
> Open Source and Standards @ Red Hat
> 
> identi.ca/lh
> twitter.com/lhawthorn
> _______________________________________________
> Board mailing list
> Board at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/board




From mburns at redhat.com  Mon Apr 30 17:01:30 2012
From: mburns at redhat.com (Mike Burns)
Date: Mon, 30 Apr 2012 13:01:30 -0400
Subject: Call for Agenda Items -- oVirt Weekly Meeting 2012-05-02
Message-ID: <1335805290.9282.9.camel@beelzebub.mburnsfire.net>

Any agenda items for this week?

Currently on the agenda:

* Status of Next Release
* Sub-project reports (engine, vdsm, node)
* Review decision on Java 7 and Fedora jboss rpms in oVirt Engine
* Upcoming workshops

Also, I will not be able to attend this meeting, so if someone else can
run it, I would appreciate it.

Thanks

Mike