From abaron at redhat.com  Sun Sep  2 07:32:18 2012
From: abaron at redhat.com (Ayal Baron)
Date: Sun, 2 Sep 2012 03:32:18 -0400 (EDT)
Subject: [vdsm] [RFC] Implied UUIDs in API
In-Reply-To: <1811692057.16247296.1346425109172.JavaMail.root@redhat.com>
Message-ID: <1778031722.63552625.1346571138791.JavaMail.root@redhat.com>

----- Original Message -----
> In my opinion the implications on the engine database storage are not
> relevant, the engine can still choose to store everything as UUID if
> it finds it more easier.
> The only change would be that VDMS wouldn't care if they are UUIDs or
> not. They can still *be* UUIDs.
> The only problem is that if other managers start creating entities
> you will have to be able to gracefully handle that in API responses.

Wrt db - nothing needs to change.  The value is determined by engine today and can go on being a UUID even if VDSM doesn't validate it to be one.

> 
> I also wonder why libvirt chose to validate UUIDs. Because as I said,
> as long as you don't generate them the fact that the are *possibly*
> unique is of no consequence to you. Seeing as the field comes to
> libvirt from an XML stream there is no real issue with parsing and
> putting it in a properly null terminated buffer.
> 

For fields on which underlying components apply limitations such as the VM ID passed to libvirt I think we should validate but note in the documentation that there is no guarantee that it is a UUID as implementation may change.

Wrt Daniel's comment about fixed length - I agree it is easier to deal with fixed length strings (we also rely on this in sanlock iirc) so I would keep a length limitation on the string.

> The main reason I want to rid away the UUID restriction is that I
> think that it will help us have namespacing.
> 
> As VDSM's API becomes open and the ovirt-engine less centralized it
> will be harder to know which VDSM side resources are owned by which
> managing entity.
> Being able to mangle in you data (eg.
> OVIRT_ENGINE_0003-321321-321321-3213) will make it easier to know
> which VMs, domains, storage connections, are owned by which entity
> without actually going into implementing access controls on VDSM
> resources.
> 
> Further more, subsystems that might generate IDs in a different way
> could be fitted more easily.
> 
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > To: "Itamar Heim" <iheim at redhat.com>
> > Cc: "Juan Hernandez" <jhernand at redhat.com>, "arch"
> > <arch at ovirt.org>, "VDSM Project Development"
> > <vdsm-devel at lists.fedorahosted.org>
> > Sent: Friday, August 31, 2012 9:52:33 AM
> > Subject: Re: [vdsm] [RFC] Implied UUIDs in API
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Itamar Heim" <iheim at redhat.com>
> > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > Cc: "Juan Hernandez" <jhernand at redhat.com>, "arch"
> > > <arch at ovirt.org>, "VDSM Project Development"
> > > <vdsm-devel at lists.fedorahosted.org>
> > > Sent: Friday, August 31, 2012 4:22:14 PM
> > > Subject: Re: [vdsm] [RFC] Implied UUIDs in API
> > > 
> > > On 08/31/2012 03:36 PM, Alon Bar-Lev wrote:
> > > >
> > > >
> > > > ----- Original Message -----
> > > >> From: "Juan Hernandez" <jhernand at redhat.com>
> > > >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > >> Cc: "Itamar Heim" <iheim at redhat.com>, "arch" <arch at ovirt.org>,
> > > >> "VDSM Project Development"
> > > >> <vdsm-devel at lists.fedorahosted.org>
> > > >> Sent: Friday, August 31, 2012 12:36:10 PM
> > > >> Subject: Re: [vdsm] [RFC] Implied UUIDs in API
> > > >>
> > > >> On 08/31/2012 11:27 AM, Alon Bar-Lev wrote:
> > > >>>
> > > >>>
> > > >>> ----- Original Message -----
> > > >>>> From: "Itamar Heim" <iheim at redhat.com>
> > > >>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > >>>> Cc: "Saggi Mizrahi" <smizrahi at redhat.com>, "arch"
> > > >>>> <arch at ovirt.org>, "VDSM Project Development"
> > > >>>> <vdsm-devel at lists.fedorahosted.org>
> > > >>>> Sent: Friday, August 31, 2012 12:23:38 PM
> > > >>>> Subject: Re: [vdsm] [RFC] Implied UUIDs in API
> > > >>>>
> > > >>>> On 08/31/2012 12:33 AM, Alon Bar-Lev wrote:
> > > >>>>>
> > > >>>>>
> > > >>>>> ----- Original Message -----
> > > >>>>>> From: "Saggi Mizrahi" <smizrahi at redhat.com>
> > > >>>>>> To: "arch" <arch at ovirt.org>, "VDSM Project Development"
> > > >>>>>> <vdsm-devel at lists.fedorahosted.org>
> > > >>>>>> Sent: Friday, August 31, 2012 12:19:46 AM
> > > >>>>>> Subject: [vdsm] [RFC] Implied UUIDs in API
> > > >>>>>>
> > > >>>>>> Hi, in the API a lot of IDs get passed around are UUIDs.
> > > >>>>>> The point is that as long as you are not the entity
> > > >>>>>> generating
> > > >>>>>> the
> > > >>>>>> UUIDs the fact that these are UUIDs have no real
> > > >>>>>> significance
> > > >>>>>> to
> > > >>>>>> you.
> > > >>>>>> I suggest removing the validation of UUIDs from the
> > > >>>>>> receiving
> > > >>>>>> end.
> > > >>>>>> There is no real reason to make sure these are real UUIDs.
> > > >>>>>> It's another restriction we can remove from the interface
> > > >>>>>> simplifying
> > > >>>>>> the code and the interface.
> > > >>>>>>
> > > >>>>>> Just to be clear I'm not saying that we should stop using
> > > >>>>>> UUIDs.
> > > >>>>>> For example, vdsm will keep generating task IDs as UUIDs.
> > > >>>>>> But
> > > >>>>>> the
> > > >>>>>> documentation will state that it could be *any* string
> > > >>>>>> value.
> > > >>>>>> If for some reason we choose to change the format of task
> > > >>>>>> IDs.
> > > >>>>>> There
> > > >>>>>> will be no need to change the interface.
> > > >>>>>>
> > > >>>>>> The same goes for VM IDs. Currently the engine uses UUIDs
> > > >>>>>> but
> > > >>>>>> there
> > > >>>>>> is no reason for VDSM to enforce this and limit the engine
> > > >>>>>> from
> > > >>>>>> ever
> > > >>>>>> changing it in the future and using other string values.
> > > >>>>>
> > > >>>>> I agree that UUID is just a method of generating unique
> > > >>>>> strings,
> > > >>>>> there is no reason to validate the value nor the format.
> > > >>>>
> > > >>>> I'm with daniel on this one - knowing a field is a uuid
> > > >>>> makes
> > > >>>> it
> > > >>>> easier
> > > >>>> to deal with in the db and code around it compared to a
> > > >>>> string
> > > >>>> (stored
> > > >>>> binary instead of string representation, etc.)
> > > >>>>
> > > >>>
> > > >>> Why to store binary?
> > > >>
> > > >> An UUID stored in its binary format takes 16 bytes. Stored as
> > > >> an
> > > >> string
> > > >> it takes 36 bytes, and more than 72 bytes in memory in the
> > > >> engine.
> > > >> The
> > > >> amount of CPU needed to create/compare/etc is proportional.
> > > >>
> > > >> The engine takes advantage of this and uses an specialized
> > > >> UUID
> > > >> class
> > > >> and a specialized database type to manage them. If we change
> > > >> to
> > > >> arbitrary strings then a *lot* of changes have to be done to
> > > >> the
> > > >> engine.
> > > >
> > > > We are trying to reduce types of vdsm to simplify the VDSM-next
> > > > API.
> > > >
> > > > I guess it will derive a lot of changes in the engine anyway...
> > > >
> > > > 32->72 bytes in memory of JVM is not something that I care, JVM
> > > > is
> > > > not optimized for memory use in any sense.
> > > 
> > > that doesn't mean you should abuse it. it's not a single item.
> > > its
> > > all
> > > the items.
> > 
> > I guess you want me to analyse our current implementation and find
> > optimizations that can be done... or in different words, find
> > entities we abuse now... :)
> >  
> > > 
> > > >
> > > > I am not sure that compare in database of binary or string has
> > > > significant impact, if there is a proper indexing, and if
> > > > foreign
> > > > key is used to cascade.
> > > >
> > > > Regards,
> > > > Alon.
> > > >
> > > 
> > > 
> > > 
> > _______________________________________________
> > vdsm-devel mailing list
> > vdsm-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> > 
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> 


From masayag at redhat.com  Sun Sep  2 21:40:43 2012
From: masayag at redhat.com (Moti Asayag)
Date: Mon, 03 Sep 2012 00:40:43 +0300
Subject: Unifying (parts of) engine and vdsm commit templates.
In-Reply-To: <576909443.1352417.1346067991449.JavaMail.root@redhat.com>
References: <576909443.1352417.1346067991449.JavaMail.root@redhat.com>
Message-ID: <5043D25B.5050903@redhat.com>

On 08/27/2012 02:46 PM, Doron Fediuck wrote:
> ----- Original Message -----
>> From: "Dan Kenigsberg" <danken at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>, "Federico Simoncelli" <fsimonce at redhat.com>
>> Cc: arch at ovirt.org
>> Sent: Monday, August 27, 2012 2:20:46 PM
>> Subject: Re: Unifying (parts of) engine and vdsm commit templates.
>>
>> On Tue, Aug 21, 2012 at 02:59:16PM -0400, Alon Bar-Lev wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Saggi Mizrahi" <smizrahi at redhat.com>
>>>> To: "Omer Frenkel" <ofrenkel at redhat.com>
>>>> Cc: arch at ovirt.org
>>>> Sent: Tuesday, August 21, 2012 9:54:28 PM
>>>> Subject: Re: Unifying (parts of) engine and vdsm commit
>>>> templates.
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Omer Frenkel" <ofrenkel at redhat.com>
>>>>> To: "Mike Kolesnik" <mkolesni at redhat.com>
>>>>> Cc: arch at ovirt.org
>>>>> Sent: Tuesday, August 21, 2012 11:36:54 AM
>>>>> Subject: Re: Unifying (parts of) engine and vdsm commit
>>>>> templates.
>>>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Mike Kolesnik" <mkolesni at redhat.com>
>>>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>>>>> Cc: arch at ovirt.org
>>>>>> Sent: Tuesday, August 21, 2012 2:36:13 PM
>>>>>> Subject: Re: Unifying (parts of) engine and vdsm commit
>>>>>> templates.
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Mike Kolesnik" <mkolesni at redhat.com>
>>>>>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>>>>>>> Cc: arch at ovirt.org, "Dan Kenigsberg" <danken at redhat.com>
>>>>>>>> Sent: Tuesday, August 21, 2012 2:27:05 PM
>>>>>>>> Subject: Re: Unifying (parts of) engine and vdsm commit
>>>>>>>> templates.
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ----- Original Message -----
>>>>>>>>>> From: "Dan Kenigsberg" <danken at redhat.com>
>>>>>>>>>> To: "Doron Fediuck" <dfediuck at redhat.com>
>>>>>>>>>> Cc: arch at ovirt.org, "Alon Bar-Lev"
>>>>>>>>>> <alonbl at redhat.com>,
>>>>>>>>>> "Igor
>>>>>>>>>> Lvovsky" <ilvovsky at redhat.com>
>>>>>>>>>> Sent: Tuesday, August 21, 2012 1:49:18 PM
>>>>>>>>>> Subject: Re: Unifying (parts of) engine and vdsm
>>>>>>>>>> commit
>>>>>>>>>> templates.
>>>>>>>>>
>>>>>>>>> <snip>
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>     Bug-Id: BZ#888888 dummy bz1
>>>>>>>>>>>     Bug-Id: BZ#888889 dummy bz2
>>>>>>>>>>>     Bug-Id: BZ#888890 dummy bz2
>>>>>>>>>>
>>>>>>>>>> I think it's fine, though I find the "BZ#" string
>>>>>>>>>> quite
>>>>>>>>>> redundant
>>>>>>>>>> when
>>>>>>>>>> it appears after "Bug-Id: "
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The BZ# was added (or kept) in order to allow <some>
>>>>>>>>> flexibility
>>>>>>>>> when
>>>>>>>>> referencing to different bug tracking systems (multiple
>>>>>>>>> name-spaces). For example, we may accept conventions of
>>>>>>>>> LP#
>>>>>>>>> for
>>>>>>>>> ubuntu launchpad.
>>>>>>>>
>>>>>>>> Why not simply use a bug link, then?
>>>>>>>
>>>>>>> It is long... I think the bug description is more
>>>>>>> important,
>>>>>>> providing both URL and description will make way too long.
>>>>>>
>>>>>> Bug titles aren't constant. Also they provide little value as
>>>>>> most
>>>>>> of
>>>>>> the time the bug decription and reproduction steps are much
>>>>>> more
>>>>>> informative than what the title says.
>>>>>>
>>>>>> Also in the engine we have lived a long time with bug URL in
>>>>>> the
>>>>>> comment and it was very convenient.
>>>>>>
>>>>>
>>>>> I agree, i find bug url much more convenient than bug title
>>>> +1, most of the time the bug titles don't actually even point to
>>>> what
>>>> the problem actually was but rather what the reporter thought it
>>>> was.
>>
>> Ok. Before this thread finds it way to the land of undecided
>> discussions, let's sum it up:
>>
>>   Bug-Id: https://bugzilla.redhat.com/888890
>>
>> The commit message should be explicit enough to describe the nature
>> of
>> the fixed bug.
>>
>> Dan.
> 
> +1.
> Looks very good, as indeed BZ $SUBJECT does not always reflect the real issue.
> 

+1

> If anyone objects, please respond.
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 



From danken at redhat.com  Mon Sep  3 09:43:58 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Mon, 3 Sep 2012 12:43:58 +0300
Subject: [vdsm] [RFC] Implied UUIDs in API
In-Reply-To: <20120830212354.GB3297@redhat.com>
References: <1700817155.15552304.1346353899259.JavaMail.root@redhat.com>
	<213167067.15587136.1346361586741.JavaMail.root@redhat.com>
	<20120830212354.GB3297@redhat.com>
Message-ID: <20120903094358.GE15074@redhat.com>

On Thu, Aug 30, 2012 at 02:23:54PM -0700, Daniel P. Berrange wrote:
> On Thu, Aug 30, 2012 at 05:19:46PM -0400, Saggi Mizrahi wrote:
> > Hi, in the API a lot of IDs get passed around are UUIDs.
> > The point is that as long as you are not the entity generating the UUIDs the fact that these are UUIDs have no real significance to you.
> > I suggest removing the validation of UUIDs from the receiving end. There is no real reason to make sure these are real UUIDs.
> > It's another restriction we can remove from the interface simplifying the code and the interface.
> > 
> > Just to be clear I'm not saying that we should stop using UUIDs.
> > For example, vdsm will keep generating task IDs as UUIDs. But the documentation will state that it could be *any* string value.
> > If for some reason we choose to change the format of task IDs. There will be no need to change the interface.
> 
> IMHO it is worth having strict UUIDs in preference to arbitrary strings,
> since their fixed size lets you deal with them more efficiently and
> predictably.
> 
> > The same goes for VM IDs. Currently the engine uses UUIDs but there
> > is no reason for VDSM to enforce this and limit the engine from ever
> > changing it in the future and using other string values.
> 
> I'm not sure this is correct. IIUC the vmId value is used set the <uuid>
> element in the libvirt VM XML configuration, and libvirt will strictly
> validate for a well formed UUID string.

Dan, you are correct. vmId==libvirt's domain uuid.


From iheim at redhat.com  Mon Sep  3 10:06:25 2012
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 03 Sep 2012 13:06:25 +0300
Subject: [vdsm] [RFC] Implied UUIDs in API
In-Reply-To: <1778031722.63552625.1346571138791.JavaMail.root@redhat.com>
References: <1778031722.63552625.1346571138791.JavaMail.root@redhat.com>
Message-ID: <50448121.1040806@redhat.com>

On 09/02/2012 10:32 AM, Ayal Baron wrote:
> ----- Original Message -----
>> In my opinion the implications on the engine database storage are not
>> relevant, the engine can still choose to store everything as UUID if
>> it finds it more easier.
>> The only change would be that VDMS wouldn't care if they are UUIDs or
>> not. They can still *be* UUIDs.
>> The only problem is that if other managers start creating entities
>> you will have to be able to gracefully handle that in API responses.
>
> Wrt db - nothing needs to change.  The value is determined by engine today and can go on being a UUID even if VDSM doesn't validate it to be one.
>
>>
>> I also wonder why libvirt chose to validate UUIDs. Because as I said,
>> as long as you don't generate them the fact that the are *possibly*
>> unique is of no consequence to you. Seeing as the field comes to
>> libvirt from an XML stream there is no real issue with parsing and
>> putting it in a properly null terminated buffer.
>>
>
> For fields on which underlying components apply limitations such as the VM ID passed to libvirt I think we should validate but note in the documentation that there is no guarantee that it is a UUID as implementation may change.
>
> Wrt Daniel's comment about fixed length - I agree it is easier to deal with fixed length strings (we also rely on this in sanlock iirc) so I would keep a length limitation on the string.

for identities the caller pass, I think vdsm can use string and engine 
can use uuid as that string.
but for identities generated by vdsm (task id's, maybe tomorrow image 
id's, etc.) - there is a huge different between "not validating" and 
formally using uuid's as the expected type to not throw engine expecting 
a uuid for these fields.

>
>> The main reason I want to rid away the UUID restriction is that I
>> think that it will help us have namespacing.
>>
>> As VDSM's API becomes open and the ovirt-engine less centralized it
>> will be harder to know which VDSM side resources are owned by which
>> managing entity.
>> Being able to mangle in you data (eg.
>> OVIRT_ENGINE_0003-321321-321321-3213) will make it easier to know
>> which VMs, domains, storage connections, are owned by which entity
>> without actually going into implementing access controls on VDSM
>> resources.
>>
>> Further more, subsystems that might generate IDs in a different way
>> could be fitted more easily.
>>
>> ----- Original Message -----
>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
>>> To: "Itamar Heim" <iheim at redhat.com>
>>> Cc: "Juan Hernandez" <jhernand at redhat.com>, "arch"
>>> <arch at ovirt.org>, "VDSM Project Development"
>>> <vdsm-devel at lists.fedorahosted.org>
>>> Sent: Friday, August 31, 2012 9:52:33 AM
>>> Subject: Re: [vdsm] [RFC] Implied UUIDs in API
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Itamar Heim" <iheim at redhat.com>
>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>>> Cc: "Juan Hernandez" <jhernand at redhat.com>, "arch"
>>>> <arch at ovirt.org>, "VDSM Project Development"
>>>> <vdsm-devel at lists.fedorahosted.org>
>>>> Sent: Friday, August 31, 2012 4:22:14 PM
>>>> Subject: Re: [vdsm] [RFC] Implied UUIDs in API
>>>>
>>>> On 08/31/2012 03:36 PM, Alon Bar-Lev wrote:
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Juan Hernandez" <jhernand at redhat.com>
>>>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>>>>> Cc: "Itamar Heim" <iheim at redhat.com>, "arch" <arch at ovirt.org>,
>>>>>> "VDSM Project Development"
>>>>>> <vdsm-devel at lists.fedorahosted.org>
>>>>>> Sent: Friday, August 31, 2012 12:36:10 PM
>>>>>> Subject: Re: [vdsm] [RFC] Implied UUIDs in API
>>>>>>
>>>>>> On 08/31/2012 11:27 AM, Alon Bar-Lev wrote:
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Itamar Heim" <iheim at redhat.com>
>>>>>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>>>>>>> Cc: "Saggi Mizrahi" <smizrahi at redhat.com>, "arch"
>>>>>>>> <arch at ovirt.org>, "VDSM Project Development"
>>>>>>>> <vdsm-devel at lists.fedorahosted.org>
>>>>>>>> Sent: Friday, August 31, 2012 12:23:38 PM
>>>>>>>> Subject: Re: [vdsm] [RFC] Implied UUIDs in API
>>>>>>>>
>>>>>>>> On 08/31/2012 12:33 AM, Alon Bar-Lev wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ----- Original Message -----
>>>>>>>>>> From: "Saggi Mizrahi" <smizrahi at redhat.com>
>>>>>>>>>> To: "arch" <arch at ovirt.org>, "VDSM Project Development"
>>>>>>>>>> <vdsm-devel at lists.fedorahosted.org>
>>>>>>>>>> Sent: Friday, August 31, 2012 12:19:46 AM
>>>>>>>>>> Subject: [vdsm] [RFC] Implied UUIDs in API
>>>>>>>>>>
>>>>>>>>>> Hi, in the API a lot of IDs get passed around are UUIDs.
>>>>>>>>>> The point is that as long as you are not the entity
>>>>>>>>>> generating
>>>>>>>>>> the
>>>>>>>>>> UUIDs the fact that these are UUIDs have no real
>>>>>>>>>> significance
>>>>>>>>>> to
>>>>>>>>>> you.
>>>>>>>>>> I suggest removing the validation of UUIDs from the
>>>>>>>>>> receiving
>>>>>>>>>> end.
>>>>>>>>>> There is no real reason to make sure these are real UUIDs.
>>>>>>>>>> It's another restriction we can remove from the interface
>>>>>>>>>> simplifying
>>>>>>>>>> the code and the interface.
>>>>>>>>>>
>>>>>>>>>> Just to be clear I'm not saying that we should stop using
>>>>>>>>>> UUIDs.
>>>>>>>>>> For example, vdsm will keep generating task IDs as UUIDs.
>>>>>>>>>> But
>>>>>>>>>> the
>>>>>>>>>> documentation will state that it could be *any* string
>>>>>>>>>> value.
>>>>>>>>>> If for some reason we choose to change the format of task
>>>>>>>>>> IDs.
>>>>>>>>>> There
>>>>>>>>>> will be no need to change the interface.
>>>>>>>>>>
>>>>>>>>>> The same goes for VM IDs. Currently the engine uses UUIDs
>>>>>>>>>> but
>>>>>>>>>> there
>>>>>>>>>> is no reason for VDSM to enforce this and limit the engine
>>>>>>>>>> from
>>>>>>>>>> ever
>>>>>>>>>> changing it in the future and using other string values.
>>>>>>>>>
>>>>>>>>> I agree that UUID is just a method of generating unique
>>>>>>>>> strings,
>>>>>>>>> there is no reason to validate the value nor the format.
>>>>>>>>
>>>>>>>> I'm with daniel on this one - knowing a field is a uuid
>>>>>>>> makes
>>>>>>>> it
>>>>>>>> easier
>>>>>>>> to deal with in the db and code around it compared to a
>>>>>>>> string
>>>>>>>> (stored
>>>>>>>> binary instead of string representation, etc.)
>>>>>>>>
>>>>>>>
>>>>>>> Why to store binary?
>>>>>>
>>>>>> An UUID stored in its binary format takes 16 bytes. Stored as
>>>>>> an
>>>>>> string
>>>>>> it takes 36 bytes, and more than 72 bytes in memory in the
>>>>>> engine.
>>>>>> The
>>>>>> amount of CPU needed to create/compare/etc is proportional.
>>>>>>
>>>>>> The engine takes advantage of this and uses an specialized
>>>>>> UUID
>>>>>> class
>>>>>> and a specialized database type to manage them. If we change
>>>>>> to
>>>>>> arbitrary strings then a *lot* of changes have to be done to
>>>>>> the
>>>>>> engine.
>>>>>
>>>>> We are trying to reduce types of vdsm to simplify the VDSM-next
>>>>> API.
>>>>>
>>>>> I guess it will derive a lot of changes in the engine anyway...
>>>>>
>>>>> 32->72 bytes in memory of JVM is not something that I care, JVM
>>>>> is
>>>>> not optimized for memory use in any sense.
>>>>
>>>> that doesn't mean you should abuse it. it's not a single item.
>>>> its
>>>> all
>>>> the items.
>>>
>>> I guess you want me to analyse our current implementation and find
>>> optimizations that can be done... or in different words, find
>>> entities we abuse now... :)
>>>
>>>>
>>>>>
>>>>> I am not sure that compare in database of binary or string has
>>>>> significant impact, if there is a proper indexing, and if
>>>>> foreign
>>>>> key is used to cascade.
>>>>>
>>>>> Regards,
>>>>> Alon.
>>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> vdsm-devel mailing list
>>> vdsm-devel at lists.fedorahosted.org
>>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>>>
>> _______________________________________________
>> vdsm-devel mailing list
>> vdsm-devel at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>




From alonbl at redhat.com  Mon Sep  3 13:59:57 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Mon, 3 Sep 2012 09:59:57 -0400 (EDT)
Subject: Unifying (parts of) engine and vdsm commit templates.
In-Reply-To: <45855113.12576701.1346068413495.JavaMail.root@redhat.com>
Message-ID: <1532370860.4395732.1346680797427.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Mike Kolesnik" <mkolesni at redhat.com>
> To: "Dan Kenigsberg" <danken at redhat.com>
> Cc: arch at ovirt.org
> Sent: Monday, August 27, 2012 2:53:33 PM
> Subject: Re: Unifying (parts of) engine and vdsm commit templates.
> 
> ----- Original Message -----
> > ----- Original Message -----
> > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > To: "Alon Bar-Lev" <alonbl at redhat.com>, "Federico Simoncelli"
> > > <fsimonce at redhat.com>
> > > Cc: arch at ovirt.org
> > > Sent: Monday, August 27, 2012 2:20:46 PM
> > > Subject: Re: Unifying (parts of) engine and vdsm commit
> > > templates.
> > > 
> > > On Tue, Aug 21, 2012 at 02:59:16PM -0400, Alon Bar-Lev wrote:
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Saggi Mizrahi" <smizrahi at redhat.com>
> > > > > To: "Omer Frenkel" <ofrenkel at redhat.com>
> > > > > Cc: arch at ovirt.org
> > > > > Sent: Tuesday, August 21, 2012 9:54:28 PM
> > > > > Subject: Re: Unifying (parts of) engine and vdsm commit
> > > > > templates.
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Omer Frenkel" <ofrenkel at redhat.com>
> > > > > > To: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > > Cc: arch at ovirt.org
> > > > > > Sent: Tuesday, August 21, 2012 11:36:54 AM
> > > > > > Subject: Re: Unifying (parts of) engine and vdsm commit
> > > > > > templates.
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > > > Cc: arch at ovirt.org
> > > > > > > Sent: Tuesday, August 21, 2012 2:36:13 PM
> > > > > > > Subject: Re: Unifying (parts of) engine and vdsm commit
> > > > > > > templates.
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > 
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > > > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > > > > > Cc: arch at ovirt.org, "Dan Kenigsberg"
> > > > > > > > > <danken at redhat.com>
> > > > > > > > > Sent: Tuesday, August 21, 2012 2:27:05 PM
> > > > > > > > > Subject: Re: Unifying (parts of) engine and vdsm
> > > > > > > > > commit
> > > > > > > > > templates.
> > > > > > > > > 
> > > > > > > > > ----- Original Message -----
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > > > > > > > > > To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > > > > > > > Cc: arch at ovirt.org, "Alon Bar-Lev"
> > > > > > > > > > > <alonbl at redhat.com>,
> > > > > > > > > > > "Igor
> > > > > > > > > > > Lvovsky" <ilvovsky at redhat.com>
> > > > > > > > > > > Sent: Tuesday, August 21, 2012 1:49:18 PM
> > > > > > > > > > > Subject: Re: Unifying (parts of) engine and vdsm
> > > > > > > > > > > commit
> > > > > > > > > > > templates.
> > > > > > > > > > 
> > > > > > > > > > <snip>
> > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > >     Bug-Id: BZ#888888 dummy bz1
> > > > > > > > > > > >     Bug-Id: BZ#888889 dummy bz2
> > > > > > > > > > > >     Bug-Id: BZ#888890 dummy bz2
> > > > > > > > > > > 
> > > > > > > > > > > I think it's fine, though I find the "BZ#" string
> > > > > > > > > > > quite
> > > > > > > > > > > redundant
> > > > > > > > > > > when
> > > > > > > > > > > it appears after "Bug-Id: "
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > The BZ# was added (or kept) in order to allow
> > > > > > > > > > <some>
> > > > > > > > > > flexibility
> > > > > > > > > > when
> > > > > > > > > > referencing to different bug tracking systems
> > > > > > > > > > (multiple
> > > > > > > > > > name-spaces). For example, we may accept
> > > > > > > > > > conventions
> > > > > > > > > > of
> > > > > > > > > > LP#
> > > > > > > > > > for
> > > > > > > > > > ubuntu launchpad.
> > > > > > > > > 
> > > > > > > > > Why not simply use a bug link, then?
> > > > > > > > 
> > > > > > > > It is long... I think the bug description is more
> > > > > > > > important,
> > > > > > > > providing both URL and description will make way too
> > > > > > > > long.
> > > > > > > 
> > > > > > > Bug titles aren't constant. Also they provide little
> > > > > > > value
> > > > > > > as
> > > > > > > most
> > > > > > > of
> > > > > > > the time the bug decription and reproduction steps are
> > > > > > > much
> > > > > > > more
> > > > > > > informative than what the title says.
> > > > > > > 
> > > > > > > Also in the engine we have lived a long time with bug URL
> > > > > > > in
> > > > > > > the
> > > > > > > comment and it was very convenient.
> > > > > > >
> > > > > > 
> > > > > > I agree, i find bug url much more convenient than bug title
> > > > > +1, most of the time the bug titles don't actually even point
> > > > > to
> > > > > what
> > > > > the problem actually was but rather what the reporter thought
> > > > > it
> > > > > was.
> > > 
> > > Ok. Before this thread finds it way to the land of undecided
> > > discussions, let's sum it up:
> > > 
> > >   Bug-Id: https://bugzilla.redhat.com/888890
> > > 
> > > The commit message should be explicit enough to describe the
> > > nature
> > > of
> > > the fixed bug.
> > > 
> > > Dan.
> > 
> > +1.
> > Looks very good, as indeed BZ $SUBJECT does not always reflect the
> > real issue.
> 
> +1
> 
> Although maybe Bug-Url key is more appropriate ;)


Hello All,

I am so sorry to bother you for such small issues.

However when 'Bug-Id: ' was suggested it was indeed bug id (source#number).

Now that all in favour of specifying URL, and consider the above note of Mike,
do you prefer keeping the 'Bug-Id: ' or Use 'Bug-Url: '?

I am in favour of Bug-Url, as it is indeed Url now.

Regards,
Alon Bar-Lev.


From fabiand at redhat.com  Mon Sep  3 14:07:58 2012
From: fabiand at redhat.com (Fabian Deutsch)
Date: Mon, 03 Sep 2012 16:07:58 +0200
Subject: Unifying (parts of) engine and vdsm commit templates.
In-Reply-To: <1532370860.4395732.1346680797427.JavaMail.root@redhat.com>
References: <1532370860.4395732.1346680797427.JavaMail.root@redhat.com>
Message-ID: <1346681278.2384.23.camel@fdeutsch-laptop.local>

Am Montag, den 03.09.2012, 09:59 -0400 schrieb Alon Bar-Lev:
> 
> ----- Original Message -----
> > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > To: "Dan Kenigsberg" <danken at redhat.com>
> > Cc: arch at ovirt.org
> > Sent: Monday, August 27, 2012 2:53:33 PM
> > Subject: Re: Unifying (parts of) engine and vdsm commit templates.
> > 
> > ----- Original Message -----
> > > ----- Original Message -----
> > > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > > To: "Alon Bar-Lev" <alonbl at redhat.com>, "Federico Simoncelli"
> > > > <fsimonce at redhat.com>
> > > > Cc: arch at ovirt.org
> > > > Sent: Monday, August 27, 2012 2:20:46 PM
> > > > Subject: Re: Unifying (parts of) engine and vdsm commit
> > > > templates.
> > > > 
> > > > On Tue, Aug 21, 2012 at 02:59:16PM -0400, Alon Bar-Lev wrote:
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Saggi Mizrahi" <smizrahi at redhat.com>
> > > > > > To: "Omer Frenkel" <ofrenkel at redhat.com>
> > > > > > Cc: arch at ovirt.org
> > > > > > Sent: Tuesday, August 21, 2012 9:54:28 PM
> > > > > > Subject: Re: Unifying (parts of) engine and vdsm commit
> > > > > > templates.
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Omer Frenkel" <ofrenkel at redhat.com>
> > > > > > > To: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > > > Cc: arch at ovirt.org
> > > > > > > Sent: Tuesday, August 21, 2012 11:36:54 AM
> > > > > > > Subject: Re: Unifying (parts of) engine and vdsm commit
> > > > > > > templates.
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > > > > Cc: arch at ovirt.org
> > > > > > > > Sent: Tuesday, August 21, 2012 2:36:13 PM
> > > > > > > > Subject: Re: Unifying (parts of) engine and vdsm commit
> > > > > > > > templates.
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > ----- Original Message -----
> > > > > > > > > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > > > > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > > > > > > Cc: arch at ovirt.org, "Dan Kenigsberg"
> > > > > > > > > > <danken at redhat.com>
> > > > > > > > > > Sent: Tuesday, August 21, 2012 2:27:05 PM
> > > > > > > > > > Subject: Re: Unifying (parts of) engine and vdsm
> > > > > > > > > > commit
> > > > > > > > > > templates.
> > > > > > > > > > 
> > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > > > > > > > > > > To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > > > > > > > > Cc: arch at ovirt.org, "Alon Bar-Lev"
> > > > > > > > > > > > <alonbl at redhat.com>,
> > > > > > > > > > > > "Igor
> > > > > > > > > > > > Lvovsky" <ilvovsky at redhat.com>
> > > > > > > > > > > > Sent: Tuesday, August 21, 2012 1:49:18 PM
> > > > > > > > > > > > Subject: Re: Unifying (parts of) engine and vdsm
> > > > > > > > > > > > commit
> > > > > > > > > > > > templates.
> > > > > > > > > > > 
> > > > > > > > > > > <snip>
> > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > >     Bug-Id: BZ#888888 dummy bz1
> > > > > > > > > > > > >     Bug-Id: BZ#888889 dummy bz2
> > > > > > > > > > > > >     Bug-Id: BZ#888890 dummy bz2
> > > > > > > > > > > > 
> > > > > > > > > > > > I think it's fine, though I find the "BZ#"
> string
> > > > > > > > > > > > quite
> > > > > > > > > > > > redundant
> > > > > > > > > > > > when
> > > > > > > > > > > > it appears after "Bug-Id: "
> > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > The BZ# was added (or kept) in order to allow
> > > > > > > > > > > <some>
> > > > > > > > > > > flexibility
> > > > > > > > > > > when
> > > > > > > > > > > referencing to different bug tracking systems
> > > > > > > > > > > (multiple
> > > > > > > > > > > name-spaces). For example, we may accept
> > > > > > > > > > > conventions
> > > > > > > > > > > of
> > > > > > > > > > > LP#
> > > > > > > > > > > for
> > > > > > > > > > > ubuntu launchpad.
> > > > > > > > > > 
> > > > > > > > > > Why not simply use a bug link, then?
> > > > > > > > > 
> > > > > > > > > It is long... I think the bug description is more
> > > > > > > > > important,
> > > > > > > > > providing both URL and description will make way too
> > > > > > > > > long.
> > > > > > > > 
> > > > > > > > Bug titles aren't constant. Also they provide little
> > > > > > > > value
> > > > > > > > as
> > > > > > > > most
> > > > > > > > of
> > > > > > > > the time the bug decription and reproduction steps are
> > > > > > > > much
> > > > > > > > more
> > > > > > > > informative than what the title says.
> > > > > > > > 
> > > > > > > > Also in the engine we have lived a long time with bug
> URL
> > > > > > > > in
> > > > > > > > the
> > > > > > > > comment and it was very convenient.
> > > > > > > >
> > > > > > > 
> > > > > > > I agree, i find bug url much more convenient than bug
> title
> > > > > > +1, most of the time the bug titles don't actually even
> point
> > > > > > to
> > > > > > what
> > > > > > the problem actually was but rather what the reporter
> thought
> > > > > > it
> > > > > > was.
> > > > 
> > > > Ok. Before this thread finds it way to the land of undecided
> > > > discussions, let's sum it up:
> > > > 
> > > >   Bug-Id: https://bugzilla.redhat.com/888890
> > > > 
> > > > The commit message should be explicit enough to describe the
> > > > nature
> > > > of
> > > > the fixed bug.
> > > > 
> > > > Dan.
> > > 
> > > +1.
> > > Looks very good, as indeed BZ $SUBJECT does not always reflect the
> > > real issue.
> > 
> > +1
> > 
> > Although maybe Bug-Url key is more appropriate ;)
> 
> 
> Hello All,
> 
> I am so sorry to bother you for such small issues.
> 
> However when 'Bug-Id: ' was suggested it was indeed bug id
> (source#number).
> 
> Now that all in favour of specifying URL, and consider the above note
> of Mike,
> do you prefer keeping the 'Bug-Id: ' or Use 'Bug-Url: '?
> 
> I am in favour of Bug-Url, as it is indeed Url now. 

+1
Bug-Url seems to be appropriate when using an url.

Greetings
fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20120903/f7699cb4/attachment.sig>

From rgolan at redhat.com  Tue Sep  4 05:37:53 2012
From: rgolan at redhat.com (Roy Golan)
Date: Tue, 4 Sep 2012 01:37:53 -0400 (EDT)
Subject: Unifying (parts of) engine and vdsm commit templates.
In-Reply-To: <1346681278.2384.23.camel@fdeutsch-laptop.local>
Message-ID: <2128134560.7839719.1346737073753.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Fabian Deutsch" <fabiand at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: arch at ovirt.org
> Sent: Monday, September 3, 2012 5:07:58 PM
> Subject: Re: Unifying (parts of) engine and vdsm commit templates.
> 
> Am Montag, den 03.09.2012, 09:59 -0400 schrieb Alon Bar-Lev:
> > 
> > ----- Original Message -----
> > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > To: "Dan Kenigsberg" <danken at redhat.com>
> > > Cc: arch at ovirt.org
> > > Sent: Monday, August 27, 2012 2:53:33 PM
> > > Subject: Re: Unifying (parts of) engine and vdsm commit
> > > templates.
> > > 
> > > ----- Original Message -----
> > > > ----- Original Message -----
> > > > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > > > To: "Alon Bar-Lev" <alonbl at redhat.com>, "Federico Simoncelli"
> > > > > <fsimonce at redhat.com>
> > > > > Cc: arch at ovirt.org
> > > > > Sent: Monday, August 27, 2012 2:20:46 PM
> > > > > Subject: Re: Unifying (parts of) engine and vdsm commit
> > > > > templates.
> > > > > 
> > > > > On Tue, Aug 21, 2012 at 02:59:16PM -0400, Alon Bar-Lev wrote:
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Saggi Mizrahi" <smizrahi at redhat.com>
> > > > > > > To: "Omer Frenkel" <ofrenkel at redhat.com>
> > > > > > > Cc: arch at ovirt.org
> > > > > > > Sent: Tuesday, August 21, 2012 9:54:28 PM
> > > > > > > Subject: Re: Unifying (parts of) engine and vdsm commit
> > > > > > > templates.
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Omer Frenkel" <ofrenkel at redhat.com>
> > > > > > > > To: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > > > > Cc: arch at ovirt.org
> > > > > > > > Sent: Tuesday, August 21, 2012 11:36:54 AM
> > > > > > > > Subject: Re: Unifying (parts of) engine and vdsm commit
> > > > > > > > templates.
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > > > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > > > > > Cc: arch at ovirt.org
> > > > > > > > > Sent: Tuesday, August 21, 2012 2:36:13 PM
> > > > > > > > > Subject: Re: Unifying (parts of) engine and vdsm
> > > > > > > > > commit
> > > > > > > > > templates.
> > > > > > > > > 
> > > > > > > > > ----- Original Message -----
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > > > > > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > > > > > > > Cc: arch at ovirt.org, "Dan Kenigsberg"
> > > > > > > > > > > <danken at redhat.com>
> > > > > > > > > > > Sent: Tuesday, August 21, 2012 2:27:05 PM
> > > > > > > > > > > Subject: Re: Unifying (parts of) engine and vdsm
> > > > > > > > > > > commit
> > > > > > > > > > > templates.
> > > > > > > > > > > 
> > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > > > > > > > > > > > To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > > > > > > > > > Cc: arch at ovirt.org, "Alon Bar-Lev"
> > > > > > > > > > > > > <alonbl at redhat.com>,
> > > > > > > > > > > > > "Igor
> > > > > > > > > > > > > Lvovsky" <ilvovsky at redhat.com>
> > > > > > > > > > > > > Sent: Tuesday, August 21, 2012 1:49:18 PM
> > > > > > > > > > > > > Subject: Re: Unifying (parts of) engine and
> > > > > > > > > > > > > vdsm
> > > > > > > > > > > > > commit
> > > > > > > > > > > > > templates.
> > > > > > > > > > > > 
> > > > > > > > > > > > <snip>
> > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >     Bug-Id: BZ#888888 dummy bz1
> > > > > > > > > > > > > >     Bug-Id: BZ#888889 dummy bz2
> > > > > > > > > > > > > >     Bug-Id: BZ#888890 dummy bz2
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I think it's fine, though I find the "BZ#"
> > string
> > > > > > > > > > > > > quite
> > > > > > > > > > > > > redundant
> > > > > > > > > > > > > when
> > > > > > > > > > > > > it appears after "Bug-Id: "
> > > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > The BZ# was added (or kept) in order to allow
> > > > > > > > > > > > <some>
> > > > > > > > > > > > flexibility
> > > > > > > > > > > > when
> > > > > > > > > > > > referencing to different bug tracking systems
> > > > > > > > > > > > (multiple
> > > > > > > > > > > > name-spaces). For example, we may accept
> > > > > > > > > > > > conventions
> > > > > > > > > > > > of
> > > > > > > > > > > > LP#
> > > > > > > > > > > > for
> > > > > > > > > > > > ubuntu launchpad.
> > > > > > > > > > > 
> > > > > > > > > > > Why not simply use a bug link, then?
> > > > > > > > > > 
> > > > > > > > > > It is long... I think the bug description is more
> > > > > > > > > > important,
> > > > > > > > > > providing both URL and description will make way
> > > > > > > > > > too
> > > > > > > > > > long.
> > > > > > > > > 
> > > > > > > > > Bug titles aren't constant. Also they provide little
> > > > > > > > > value
> > > > > > > > > as
> > > > > > > > > most
> > > > > > > > > of
> > > > > > > > > the time the bug decription and reproduction steps
> > > > > > > > > are
> > > > > > > > > much
> > > > > > > > > more
> > > > > > > > > informative than what the title says.
> > > > > > > > > 
> > > > > > > > > Also in the engine we have lived a long time with bug
> > URL
> > > > > > > > > in
> > > > > > > > > the
> > > > > > > > > comment and it was very convenient.
> > > > > > > > >
> > > > > > > > 
> > > > > > > > I agree, i find bug url much more convenient than bug
> > title
> > > > > > > +1, most of the time the bug titles don't actually even
> > point
> > > > > > > to
> > > > > > > what
> > > > > > > the problem actually was but rather what the reporter
> > thought
> > > > > > > it
> > > > > > > was.
> > > > > 
> > > > > Ok. Before this thread finds it way to the land of undecided
> > > > > discussions, let's sum it up:
> > > > > 
> > > > >   Bug-Id: https://bugzilla.redhat.com/888890
> > > > > 
> > > > > The commit message should be explicit enough to describe the
> > > > > nature
> > > > > of
> > > > > the fixed bug.
> > > > > 
> > > > > Dan.
> > > > 
> > > > +1.
> > > > Looks very good, as indeed BZ $SUBJECT does not always reflect
> > > > the
> > > > real issue.
> > > 
> > > +1
> > > 
> > > Although maybe Bug-Url key is more appropriate ;)
> > 
> > 
> > Hello All,
> > 
> > I am so sorry to bother you for such small issues.
> > 
> > However when 'Bug-Id: ' was suggested it was indeed bug id
> > (source#number).
> > 
> > Now that all in favour of specifying URL, and consider the above
> > note
> > of Mike,
> > do you prefer keeping the 'Bug-Id: ' or Use 'Bug-Url: '?
> > 
> > I am in favour of Bug-Url, as it is indeed Url now.
> 
> +1
> Bug-Url seems to be appropriate when using an url.
+1
> 
> Greetings
> fabian
> 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From dneary at redhat.com  Tue Sep  4 10:59:25 2012
From: dneary at redhat.com (Dave Neary)
Date: Tue, 04 Sep 2012 12:59:25 +0200
Subject: Mailing list scope proposal
In-Reply-To: <503BD933.3020501@redhat.com>
References: <502AB424.3010709@redhat.com> <50328DA8.10206@redhat.com>
	<5034FA0F.5030107@redhat.com> <5037ABD4.2030103@redhat.com>
	<5039CB24.6000704@redhat.com> <503BD933.3020501@redhat.com>
Message-ID: <5045DF0D.6090100@redhat.com>

Hi,

On 08/27/2012 10:31 PM, Karsten 'quaid' Wade wrote:
> On 08/26/2012 12:07 AM, Livnat Peer wrote:
>> On 24/08/12 19:29, Dave Neary wrote:
>>> So - here's my suggestion for that (and as per my suggestion, let's have
>>> this discussion here, and when we reach a consensus ask for the opinion
>>> of the board):
>>>
>>> users@ - User issues

<snip>

>>> arch@ - rename to developers@ - This will be the key developer mailing
>>> list for oVirt

<snip>

>>> board@ - Issues related to the non-technical governance of the project

<snip>

>>> infra@ - issues related to the management of oVirt infrastructure

<snip>

>>> vdsm-devel, node-devel, engine-devel, *-devel: Low-traffic lists related
>>> to the specific implementation issues of the individual components.

<snip>

>>> How does that sound? Does anyone have other/better suggestions?
>>
>> +1, I think this is a good proposal.
>> I would try to avoid discussing patches on the developers list and try
>> to keep it more high level like design discussions etc.
>
> +1 Yes, that makes sense - keep patch discussions in the project, and
> keep discussions that affect oVirt overall on the developers list.
>
> Also, I'm +1 to renaming this list; I reckon arch@ is confusing, dev@ or
> developers@ is a more common Big Main List name.

It seems this has broad support - can we add it to the agenda for the 
weekly meeting this week to give people one last chance to have a say, 
and (assuming there is no major opposition) make it so?

Thanks,
Dave.

-- 
Dave Neary
Community Action and Impact
Open Source and Standards, Red Hat
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13




From dneary at redhat.com  Tue Sep  4 11:08:03 2012
From: dneary at redhat.com (Dave Neary)
Date: Tue, 04 Sep 2012 13:08:03 +0200
Subject: "Download" page: new design
In-Reply-To: <5037A9FA.2060409@redhat.com>
References: <50353031.6070503@redhat.com> <50379B94.6020906@redhat.com>
	<5037A485.2050705@redhat.com> <5037A9FA.2060409@redhat.com>
Message-ID: <5045E113.40102@redhat.com>


Hi all,

On 08/24/2012 06:21 PM, Garrett LeSage wrote:
> Thanks! I'm glad you like it, and that you and Dave both noticed the
> implications of the design for the ?Download? page.

Can I revive this thread post-vacations, please?

Garrett is suggesting modifying the way we package oVirt, which affects 
a lot more than just the web page. We really need to have more input 
into the feasibility, desirability and potential time-scale for the 
changes he's proposing.

Also, we're ready to dive deeper in the 2nd level pages on the site, 
focussed on new users, engaged users, and developers, and we'd like to 
ensure we're on the right track so far. In the absence of negative 
feedback we'll go ahead, in the absence of positive feedback we'll 
probably assume no-one's taken the time to look at the designs! I'm sure 
Garrett would appreciate an email if you don't have anything positive to 
say, just to let him know you like it (off-list, even, if you prefer).

> For oVirt to be really successful, it needs to be super-simple for
> installation and set up. We have to be user-focused, from one end to the
> other ? this includes the website, delivery method (one ISO for CDs/USB
> sticks), and installation (as simple as possible). Of course, oVirt
> itself, when it's up and running also needs to be usable too, but I
> think the RHEV folks put some time into that already, so I'm
> concentrating on the rest for now.
>
> If we can't deliver a really polished all-in-one, installable ISO, then
> we should spend effort to try to make it happen soon. (And, if it's not
> feasible to do this in the immediate future, then I can also work on an
> interim design that bridges the gap a bit too.)
>
> I'm really glad to hear that it sounds like this will be possible.

Thanks,
Dave.

-- 
Dave Neary
Community Action and Impact
Open Source and Standards, Red Hat
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13




From dneary at redhat.com  Tue Sep  4 11:13:51 2012
From: dneary at redhat.com (Dave Neary)
Date: Tue, 04 Sep 2012 13:13:51 +0200
Subject: "Download" page: new design
In-Reply-To: <5045E113.40102@redhat.com>
References: <50353031.6070503@redhat.com> <50379B94.6020906@redhat.com>
	<5037A485.2050705@redhat.com> <5037A9FA.2060409@redhat.com>
	<5045E113.40102@redhat.com>
Message-ID: <5045E26F.9000704@redhat.com>

Hi,

On 09/04/2012 01:08 PM, Dave Neary wrote:
> Also, we're ready to dive deeper in the 2nd level pages on the site,
> focussed on new users, engaged users, and developers, and we'd like to
> ensure we're on the right track so far. In the absence of negative
> feedback we'll go ahead, in the absence of positive feedback we'll
> probably assume no-one's taken the time to look at the designs! I'm sure
> Garrett would appreciate an email if you don't have anything positive to
> say, just to let him know you like it (off-list, even, if you prefer).

Oops! I meant to say "even if you don't have anything negative to say".

The current latest version of the front page is here:
http://people.redhat.com/glesage/oVirt/website/mockup-1/

Cheers,
Dave.

-- 
Dave Neary
Community Action and Impact
Open Source and Standards, Red Hat
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13




From kwade at redhat.com  Tue Sep  4 15:26:53 2012
From: kwade at redhat.com (Karsten 'quaid' Wade)
Date: Tue, 04 Sep 2012 08:26:53 -0700
Subject: Mailing list scope proposal
In-Reply-To: <5045DF0D.6090100@redhat.com>
References: <502AB424.3010709@redhat.com> <50328DA8.10206@redhat.com>
	<5034FA0F.5030107@redhat.com> <5037ABD4.2030103@redhat.com>
	<5039CB24.6000704@redhat.com> <503BD933.3020501@redhat.com>
	<5045DF0D.6090100@redhat.com>
Message-ID: <50461DBD.1050705@redhat.com>

On 09/04/2012 03:59 AM, Dave Neary wrote:
.
> 
> It seems this has broad support - can we add it to the agenda for the
> weekly meeting this week to give people one last chance to have a say,
> and (assuming there is no major opposition) make it so?

+1


-- 
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
http://TheOpenSourceWay.org  .^\  http://community.redhat.com
@quaid (identi.ca/twitter/IRC)  \v'  gpg: AD0E0C41

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

From iheim at redhat.com  Tue Sep  4 19:25:04 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 04 Sep 2012 22:25:04 +0300
Subject: "Download" page: new design
In-Reply-To: <5045E113.40102@redhat.com>
References: <50353031.6070503@redhat.com> <50379B94.6020906@redhat.com>
	<5037A485.2050705@redhat.com> <5037A9FA.2060409@redhat.com>
	<5045E113.40102@redhat.com>
Message-ID: <50465590.2090703@redhat.com>

On 09/04/2012 02:08 PM, Dave Neary wrote:
>
> Hi all,
>
> On 08/24/2012 06:21 PM, Garrett LeSage wrote:
>> Thanks! I'm glad you like it, and that you and Dave both noticed the
>> implications of the design for the ?Download? page.
>
> Can I revive this thread post-vacations, please?
>
> Garrett is suggesting modifying the way we package oVirt, which affects
> a lot more than just the web page. We really need to have more input
> into the feasibility, desirability and potential time-scale for the
> changes he's proposing.

we need to have oVirt available as part of distros or as a repo for 
distros (fedora exists, i'm guessing ubuntu is next)
the other approach we mentioned was a live-cd approach, which will 
indeed take time to plan and do (also need to decide if going for 
live-cd or live-usb - usb is read/write which will probably be much 
easier for our use case)

>
> Also, we're ready to dive deeper in the 2nd level pages on the site,
> focussed on new users, engaged users, and developers, and we'd like to
> ensure we're on the right track so far. In the absence of negative
> feedback we'll go ahead, in the absence of positive feedback we'll
> probably assume no-one's taken the time to look at the designs! I'm sure
> Garrett would appreciate an email if you don't have anything positive to
> say, just to let him know you like it (off-list, even, if you prefer).
>
>> For oVirt to be really successful, it needs to be super-simple for
>> installation and set up. We have to be user-focused, from one end to the
>> other ? this includes the website, delivery method (one ISO for CDs/USB
>> sticks), and installation (as simple as possible). Of course, oVirt
>> itself, when it's up and running also needs to be usable too, but I
>> think the RHEV folks put some time into that already, so I'm
>> concentrating on the rest for now.
>>
>> If we can't deliver a really polished all-in-one, installable ISO, then
>> we should spend effort to try to make it happen soon. (And, if it's not
>> feasible to do this in the immediate future, then I can also work on an
>> interim design that bridges the gap a bit too.)
>>
>> I'm really glad to hear that it sounds like this will be possible.
>
> Thanks,
> Dave.
>




From mgoldboi at redhat.com  Tue Sep  4 20:25:43 2012
From: mgoldboi at redhat.com (Moran Goldboim)
Date: Tue, 04 Sep 2012 23:25:43 +0300
Subject: "Download" page: new design
In-Reply-To: <50465590.2090703@redhat.com>
References: <50353031.6070503@redhat.com>
	<50379B94.6020906@redhat.com>	<5037A485.2050705@redhat.com>
	<5037A9FA.2060409@redhat.com>	<5045E113.40102@redhat.com>
	<50465590.2090703@redhat.com>
Message-ID: <504663C7.7040705@redhat.com>

On 09/04/2012 10:25 PM, Itamar Heim wrote:
> On 09/04/2012 02:08 PM, Dave Neary wrote:
>>
>> Hi all,
>>
>> On 08/24/2012 06:21 PM, Garrett LeSage wrote:
>>> Thanks! I'm glad you like it, and that you and Dave both noticed the
>>> implications of the design for the ?Download? page.
>>
>> Can I revive this thread post-vacations, please?
>>
>> Garrett is suggesting modifying the way we package oVirt, which affects
>> a lot more than just the web page. We really need to have more input
>> into the feasibility, desirability and potential time-scale for the
>> changes he's proposing.
>
> we need to have oVirt available as part of distros or as a repo for 
> distros (fedora exists, i'm guessing ubuntu is next)
> the other approach we mentioned was a live-cd approach, which will 
> indeed take time to plan and do (also need to decide if going for 
> live-cd or live-usb - usb is read/write which will probably be much 
> easier for our use case)

I'm planing to take both tasks and put the needed time into it:
-live cd on a usb stick - 1st priority and easier task
-packaging for debian/ubunto - the more complex one since lots of our 
packaging code relays on fedora/rhel distros, i have seen some work was 
started on the subject. [1]

[1] http://wiki.ovirt.org/wiki/Ovirt_build_on_debian/ubuntu

>
>>
>> Also, we're ready to dive deeper in the 2nd level pages on the site,
>> focussed on new users, engaged users, and developers, and we'd like to
>> ensure we're on the right track so far. In the absence of negative
>> feedback we'll go ahead, in the absence of positive feedback we'll
>> probably assume no-one's taken the time to look at the designs! I'm sure
>> Garrett would appreciate an email if you don't have anything positive to
>> say, just to let him know you like it (off-list, even, if you prefer).
>>
>>> For oVirt to be really successful, it needs to be super-simple for
>>> installation and set up. We have to be user-focused, from one end to 
>>> the
>>> other ? this includes the website, delivery method (one ISO for CDs/USB
>>> sticks), and installation (as simple as possible). Of course, oVirt
>>> itself, when it's up and running also needs to be usable too, but I
>>> think the RHEV folks put some time into that already, so I'm
>>> concentrating on the rest for now.
>>>
>>> If we can't deliver a really polished all-in-one, installable ISO, then
>>> we should spend effort to try to make it happen soon. (And, if it's not
>>> feasible to do this in the immediate future, then I can also work on an
>>> interim design that bridges the gap a bit too.)
>>>
>>> I'm really glad to hear that it sounds like this will be possible.
>>
>> Thanks,
>> Dave.
>>
>
>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch



From kmayilsa at redhat.com  Wed Sep  5 09:17:45 2012
From: kmayilsa at redhat.com (Kanagaraj)
Date: Wed, 05 Sep 2012 14:47:45 +0530
Subject: Speakers Needed: Upcoming Workshops
In-Reply-To: <5022DEDC.1090007@redhat.com>
References: <5022DEDC.1090007@redhat.com>
Message-ID: <504718B9.9010703@redhat.com>

Hi All,

  I would like to give a session on Overview of Webadmin and UI 
frameworks in Bangalore oVirt Workshop. I will be starting with an 
introduction about the frameworks GWT, GWTP, GIN and MVP. And will be 
explaining about different modules, layers, communication between 
frontend and backend, techniques behind the search and auto-completion, 
bookmarks. Finally about the different modes supported by oVirt and.

  About myself, i am part of Storage Development team in Bangalore, and 
currently working on the Gluster related features in oVirt. I am taking 
care of all the gluster related UI works. Sometimes I do work on backend 
and rest-api as well. I have around 2.5 years of experience in 
developing web based management tools and UI frameworks.

Regards
Kanagaraj M

On Thursday 09 August 2012 03:19 AM, Leslie Hawthorn wrote:
> Hello everyone,
>
> First of all, congratulations to the team on today's release of oVirt 
> 3.1!
>
> As mentioned in today's weekly status IRC meeting, we would like to 
> ensure we have broad community participation in upcoming workshops. 
> [0] For KVM Forum + oVirt in Barcelona [1], a general call for papers 
> will be issued within the next few days. I will send a note to these 
> lists when details of the CFP have been announced.
>
> For the oVirt workshop to be hosted at Red Hat's Bangalore campus on 
> 16 October 2012, it would be wonderful if folks would propose sessions 
> for this workshop. (We have chosen not to go through a formal CFP 
> process for Bangalore so as to leave sufficient time for the KVM Forum 
> + oVirt CFP process to run most smoothly.) If you would like to 
> propose a session for oVirt Bangalore, please email me and I follow up 
> with you.
>
> As usual, any questions, please let me know.
>
> [0] - http://wiki.ovirt.org/wiki/OVirt_Global_Workshops
> [1] - http://events.linuxfoundation.org/events/kvm-forum/
>
> Cheers,
> LH
>



From dneary at redhat.com  Wed Sep  5 14:19:50 2012
From: dneary at redhat.com (Dave Neary)
Date: Wed, 05 Sep 2012 16:19:50 +0200
Subject: Weekly meeting on now
Message-ID: <50475F86.4000502@redhat.com>

Hi all,

The oVirt weekly meeting is on now - and the agenda includes release 
criteria for the next release.

We were expecting at least the project managers to be there to help 
define them, but unfortunately none of them appears to be on IRC now.

The other items on the agenda include quick reports from module owners 
(just to let everyone know what features are in/will go in soon) and a 
review of the website design as it is, to allow us to move forward with 
that.

It's not too late to join up now, if you have half an hour, please.

Thanks!
Dave.

-- 
Dave Neary
Community Action and Impact
Open Source and Standards, Red Hat
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13



From mburns at redhat.com  Wed Sep  5 14:57:04 2012
From: mburns at redhat.com (Mike Burns)
Date: Wed, 05 Sep 2012 10:57:04 -0400
Subject: New Role Proposal in the oVirt Project
Message-ID: <1346857024.11466.16.camel@mburns-laptop.usersys.redhat.com>

Given some of the difficulties we've had recently with planning and
getting releases pulled together, I'd like to propose we have a new role
in the Project.

Project Manager

Responsibilities:

Maintain Schedule
Run weekly meeting
Coordinate with project maintainers on dates, features, etc
Ensure that docs and release materials are ready for release
Final say on what goes into a release
Tracking new features
Tracking action items

This person should be empowered to make decisions for the project (based
on input from maintainers, but final call is theirs).

As for choosing this person, it could be done via general election on
email or an IRC meeting.  I'd suggest having someone do it for a limited
timeline, maybe 2 or 3 releases, max, then someone else takes over.

Any thoughts, suggestions, comments?

Thanks

Mike



From acathrow at redhat.com  Wed Sep  5 15:09:16 2012
From: acathrow at redhat.com (Andrew Cathrow)
Date: Wed, 5 Sep 2012 11:09:16 -0400 (EDT)
Subject: New Role Proposal in the oVirt Project
In-Reply-To: <6DA623DFCD60534EADA0E7BF74885C150C7780C7@SACEXCMBX03-PRD.hq.netapp.com>
Message-ID: <375756040.5867085.1346857756619.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Jon Benedict" <Jon.Benedict at netapp.com>
> To: "Mike Burns" <mburns at redhat.com>, "board" <board at ovirt.org>, "arch" <arch at ovirt.org>
> Sent: Wednesday, September 5, 2012 11:06:04 AM
> Subject: Re: New Role Proposal in the oVirt Project
> 
> On 9/5/12 10:57 AM, "Mike Burns" <mburns at redhat.com> wrote:
> 
> 
> >Given some of the difficulties we've had recently with planning and
> >getting releases pulled together, I'd like to propose we have a new
> >role
> >in the Project.
> >
> >Project Manager
> >
> >Responsibilities:
> >
> >Maintain Schedule
> >Run weekly meeting
> >Coordinate with project maintainers on dates, features, etc
> >Ensure that docs and release materials are ready for release
> >Final say on what goes into a release
> >Tracking new features
> >Tracking action items
> >
> >This person should be empowered to make decisions for the project
> >(based
> >on input from maintainers, but final call is theirs).
> >
> >As for choosing this person, it could be done via general election
> >on
> >email or an IRC meeting.  I'd suggest having someone do it for a
> >limited
> >timeline, maybe 2 or 3 releases, max, then someone else takes over.
> >
> >Any thoughts, suggestions, comments?

Yep a program manager type role would be valuable.

> 
> 
> Mike,
> 
> I'm definitely in favor of a PM. I like the 2-3 term requirement, but
> if
> they want to serve again it should be an option (subject to
> re-election).
> 
> Jon
> 
> _______________________________________________
> Board mailing list
> Board at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/board
> 


From kwade at redhat.com  Wed Sep  5 15:25:05 2012
From: kwade at redhat.com (Karsten 'quaid' Wade)
Date: Wed, 05 Sep 2012 08:25:05 -0700
Subject: New Role Proposal in the oVirt Project
In-Reply-To: <375756040.5867085.1346857756619.JavaMail.root@redhat.com>
References: <375756040.5867085.1346857756619.JavaMail.root@redhat.com>
Message-ID: <50476ED1.8000008@redhat.com>

On 09/05/2012 08:09 AM, Andrew Cathrow wrote:
> Yep a program manager type role would be valuable.

For other projects at Red Hat, we have someone from the program
management team work directly, including in the upstream. (That was
Fedora Project Leader Robyn Bergeron's role before her new job, for
example.)

Can we get that level of commitment for PM work from someone? Is that a
role that one of the sponsoring Board organizations can supply someone
for? Even if it's someone who isn't as familiar with working in open
source, we can help train. :)

- Karsten
-- 
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
http://TheOpenSourceWay.org  .^\  http://community.redhat.com
@quaid (identi.ca/twitter/IRC)  \v'  gpg: AD0E0C41

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

From mburns at redhat.com  Wed Sep  5 15:25:50 2012
From: mburns at redhat.com (Mike Burns)
Date: Wed, 05 Sep 2012 11:25:50 -0400
Subject: New Role Proposal in the oVirt Project
In-Reply-To: <375756040.5867085.1346857756619.JavaMail.root@redhat.com>
References: <375756040.5867085.1346857756619.JavaMail.root@redhat.com>
Message-ID: <1346858750.2004.0.camel@mburns-laptop.usersys.redhat.com>

On Wed, 2012-09-05 at 11:09 -0400, Andrew Cathrow wrote:
> 
> ----- Original Message -----
> > From: "Jon Benedict" <Jon.Benedict at netapp.com>
> > To: "Mike Burns" <mburns at redhat.com>, "board" <board at ovirt.org>, "arch" <arch at ovirt.org>
> > Sent: Wednesday, September 5, 2012 11:06:04 AM
> > Subject: Re: New Role Proposal in the oVirt Project
> > 
> > On 9/5/12 10:57 AM, "Mike Burns" <mburns at redhat.com> wrote:
> > 
> > 
> > >Given some of the difficulties we've had recently with planning and
> > >getting releases pulled together, I'd like to propose we have a new
> > >role
> > >in the Project.
> > >
> > >Project Manager
> > >
> > >Responsibilities:
> > >
> > >Maintain Schedule
> > >Run weekly meeting
> > >Coordinate with project maintainers on dates, features, etc
> > >Ensure that docs and release materials are ready for release
> > >Final say on what goes into a release
> > >Tracking new features
> > >Tracking action items
> > >
> > >This person should be empowered to make decisions for the project
> > >(based
> > >on input from maintainers, but final call is theirs).
> > >
> > >As for choosing this person, it could be done via general election
> > >on
> > >email or an IRC meeting.  I'd suggest having someone do it for a
> > >limited
> > >timeline, maybe 2 or 3 releases, max, then someone else takes over.
> > >
> > >Any thoughts, suggestions, comments?
> 
> Yep a program manager type role would be valuable.
> 
> > 
> > 
> > Mike,
> > 
> > I'm definitely in favor of a PM. I like the 2-3 term requirement, but
> > if
> > they want to serve again it should be an option (subject to
> > re-election).

Correct, they can continue on if they want (if re-elected) and I suppose
we could also let them resign from the post as well.

Mike

> > 
> > Jon
> > 
> > _______________________________________________
> > Board mailing list
> > Board at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/board
> > 
> _______________________________________________
> Board mailing list
> Board at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/board




From cctrieloff at redhat.com  Wed Sep  5 15:41:52 2012
From: cctrieloff at redhat.com (Carl Trieloff)
Date: Wed, 05 Sep 2012 11:41:52 -0400
Subject: New Role Proposal in the oVirt Project
In-Reply-To: <375756040.5867085.1346857756619.JavaMail.root@redhat.com>
References: <375756040.5867085.1346857756619.JavaMail.root@redhat.com>
Message-ID: <504772C0.9030203@redhat.com>



ack, like the idea.


On 09/05/2012 11:09 AM, Andrew Cathrow wrote:
>
> ----- Original Message -----
>> From: "Jon Benedict" <Jon.Benedict at netapp.com>
>> To: "Mike Burns" <mburns at redhat.com>, "board" <board at ovirt.org>, "arch" <arch at ovirt.org>
>> Sent: Wednesday, September 5, 2012 11:06:04 AM
>> Subject: Re: New Role Proposal in the oVirt Project
>>
>> On 9/5/12 10:57 AM, "Mike Burns" <mburns at redhat.com> wrote:
>>
>>
>>> Given some of the difficulties we've had recently with planning and
>>> getting releases pulled together, I'd like to propose we have a new
>>> role
>>> in the Project.
>>>
>>> Project Manager
>>>
>>> Responsibilities:
>>>
>>> Maintain Schedule
>>> Run weekly meeting
>>> Coordinate with project maintainers on dates, features, etc
>>> Ensure that docs and release materials are ready for release
>>> Final say on what goes into a release
>>> Tracking new features
>>> Tracking action items
>>>
>>> This person should be empowered to make decisions for the project
>>> (based
>>> on input from maintainers, but final call is theirs).
>>>
>>> As for choosing this person, it could be done via general election
>>> on
>>> email or an IRC meeting.  I'd suggest having someone do it for a
>>> limited
>>> timeline, maybe 2 or 3 releases, max, then someone else takes over.
>>>
>>> Any thoughts, suggestions, comments?
> Yep a program manager type role would be valuable.
>
>>
>> Mike,
>>
>> I'm definitely in favor of a PM. I like the 2-3 term requirement, but
>> if
>> they want to serve again it should be an option (subject to
>> re-election).
>>
>> Jon
>>
>> _______________________________________________
>> Board mailing list
>> Board at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/board
>>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch




From lhawthor at redhat.com  Wed Sep  5 16:27:37 2012
From: lhawthor at redhat.com (Leslie Hawthorn)
Date: Wed, 05 Sep 2012 09:27:37 -0700
Subject: Speakers Needed: Upcoming Workshops
In-Reply-To: <504718B9.9010703@redhat.com>
References: <5022DEDC.1090007@redhat.com> <504718B9.9010703@redhat.com>
Message-ID: <50477D79.2030002@redhat.com>

On 09/05/2012 02:17 AM, Kanagaraj wrote:

Thank you for your submission, Kanagaraj. I have added your information 
to the oVirt wiki.

http://wiki.ovirt.org/wiki/Bangalore_Abstracts

Cheers,
LH
> Hi All,
>
>  I would like to give a session on Overview of Webadmin and UI 
> frameworks in Bangalore oVirt Workshop. I will be starting with an 
> introduction about the frameworks GWT, GWTP, GIN and MVP. And will be 
> explaining about different modules, layers, communication between 
> frontend and backend, techniques behind the search and 
> auto-completion, bookmarks. Finally about the different modes 
> supported by oVirt and.
>
>  About myself, i am part of Storage Development team in Bangalore, and 
> currently working on the Gluster related features in oVirt. I am 
> taking care of all the gluster related UI works. Sometimes I do work 
> on backend and rest-api as well. I have around 2.5 years of experience 
> in developing web based management tools and UI frameworks.
>
> Regards
> Kanagaraj M
>
> On Thursday 09 August 2012 03:19 AM, Leslie Hawthorn wrote:
>> Hello everyone,
>>
>> First of all, congratulations to the team on today's release of oVirt 
>> 3.1!
>>
>> As mentioned in today's weekly status IRC meeting, we would like to 
>> ensure we have broad community participation in upcoming workshops. 
>> [0] For KVM Forum + oVirt in Barcelona [1], a general call for papers 
>> will be issued within the next few days. I will send a note to these 
>> lists when details of the CFP have been announced.
>>
>> For the oVirt workshop to be hosted at Red Hat's Bangalore campus on 
>> 16 October 2012, it would be wonderful if folks would propose 
>> sessions for this workshop. (We have chosen not to go through a 
>> formal CFP process for Bangalore so as to leave sufficient time for 
>> the KVM Forum + oVirt CFP process to run most smoothly.) If you would 
>> like to propose a session for oVirt Bangalore, please email me and I 
>> follow up with you.
>>
>> As usual, any questions, please let me know.
>>
>> [0] - http://wiki.ovirt.org/wiki/OVirt_Global_Workshops
>> [1] - http://events.linuxfoundation.org/events/kvm-forum/
>>
>> Cheers,
>> LH
>>
>


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

identi.ca/lh
twitter.com/lhawthorn



From lhawthor at redhat.com  Wed Sep  5 16:33:07 2012
From: lhawthor at redhat.com (Leslie Hawthorn)
Date: Wed, 05 Sep 2012 09:33:07 -0700
Subject: Bangalore Workshop Talk Submissions (was: Re: Speakers Needed:
	Upcoming Workshops)
In-Reply-To: <504718B9.9010703@redhat.com>
References: <5022DEDC.1090007@redhat.com> <504718B9.9010703@redhat.com>
Message-ID: <50477EC3.2010807@redhat.com>

Hello everyone,

Many thanks to all the fine folks who have proposed talks thus far for 
the oVirt Bangalore workshop. [0] We're expecting a full house with 60 
registrants already signed up.

If you are interested in speaking at the oVirt Bangalore workshop, I 
have now documented the instructions for submission and all submissions 
received thus far on the oVirt wiki. [1]  Please take a look at the 
document and let me know if you have any questions.

Last but not least, if you have been in contact with me or have been 
discussing a submission with other oVirt folk that does not appear on 
the Bangalore Abstracts wiki page, please go ahead and add it to the page.

[0] - 
http://wiki.ovirt.org/wiki/OVirt_Global_Workshops#Red_Hat_Bangalore_Campus_Workshop

[1] - http://wiki.ovirt.org/wiki/Bangalore_Abstracts

Cheers,
LH

On 09/05/2012 02:17 AM, Kanagaraj wrote:
> Hi All,
>
>  I would like to give a session on Overview of Webadmin and UI 
> frameworks in Bangalore oVirt Workshop. I will be starting with an 
> introduction about the frameworks GWT, GWTP, GIN and MVP. And will be 
> explaining about different modules, layers, communication between 
> frontend and backend, techniques behind the search and 
> auto-completion, bookmarks. Finally about the different modes 
> supported by oVirt and.
>
>  About myself, i am part of Storage Development team in Bangalore, and 
> currently working on the Gluster related features in oVirt. I am 
> taking care of all the gluster related UI works. Sometimes I do work 
> on backend and rest-api as well. I have around 2.5 years of experience 
> in developing web based management tools and UI frameworks.
>
> Regards
> Kanagaraj M
>
> On Thursday 09 August 2012 03:19 AM, Leslie Hawthorn wrote:
>> Hello everyone,
>>
>> First of all, congratulations to the team on today's release of oVirt 
>> 3.1!
>>
>> As mentioned in today's weekly status IRC meeting, we would like to 
>> ensure we have broad community participation in upcoming workshops. 
>> [0] For KVM Forum + oVirt in Barcelona [1], a general call for papers 
>> will be issued within the next few days. I will send a note to these 
>> lists when details of the CFP have been announced.
>>
>> For the oVirt workshop to be hosted at Red Hat's Bangalore campus on 
>> 16 October 2012, it would be wonderful if folks would propose 
>> sessions for this workshop. (We have chosen not to go through a 
>> formal CFP process for Bangalore so as to leave sufficient time for 
>> the KVM Forum + oVirt CFP process to run most smoothly.) If you would 
>> like to propose a session for oVirt Bangalore, please email me and I 
>> follow up with you.
>>
>> As usual, any questions, please let me know.
>>
>> [0] - http://wiki.ovirt.org/wiki/OVirt_Global_Workshops
>> [1] - http://events.linuxfoundation.org/events/kvm-forum/
>>
>> Cheers,
>> LH
>>
>


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

identi.ca/lh
twitter.com/lhawthorn



From jbrooks at redhat.com  Wed Sep  5 18:58:19 2012
From: jbrooks at redhat.com (Jason Brooks)
Date: Wed, 05 Sep 2012 11:58:19 -0700
Subject: New Role Proposal in the oVirt Project
In-Reply-To: <1346857024.11466.16.camel@mburns-laptop.usersys.redhat.com>
References: <1346857024.11466.16.camel@mburns-laptop.usersys.redhat.com>
Message-ID: <5047A0CB.4000403@redhat.com>

On 09/05/2012 07:57 AM, Mike Burns wrote:
> Given some of the difficulties we've had recently with planning and
> getting releases pulled together, I'd like to propose we have a new role
> in the Project.
>
> Project Manager
>
> Responsibilities:
>
> Maintain Schedule
> Run weekly meeting
> Coordinate with project maintainers on dates, features, etc
> Ensure that docs and release materials are ready for release
> Final say on what goes into a release
> Tracking new features
> Tracking action items
>
> This person should be empowered to make decisions for the project (based
> on input from maintainers, but final call is theirs).
>
> As for choosing this person, it could be done via general election on
> email or an IRC meeting.  I'd suggest having someone do it for a limited
> timeline, maybe 2 or 3 releases, max, then someone else takes over.
>
> Any thoughts, suggestions, comments?

This would be very valuable. +1


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


-- 

@jasonbrooks


From mburns at redhat.com  Wed Sep  5 19:08:15 2012
From: mburns at redhat.com (Mike Burns)
Date: Wed, 05 Sep 2012 15:08:15 -0400
Subject: New Role Proposal in the oVirt Project
In-Reply-To: <6DA623DFCD60534EADA0E7BF74885C150C779565@SACEXCMBX03-PRD.hq.netapp.com>
References: <6DA623DFCD60534EADA0E7BF74885C150C779565@SACEXCMBX03-PRD.hq.netapp.com>
Message-ID: <1346872095.2336.0.camel@mburns-laptop.usersys.redhat.com>

On Wed, 2012-09-05 at 18:55 +0000, Benedict, Jon wrote:
> On 9/5/12 11:25 AM, "Mike Burns" <mburns at redhat.com> wrote:
> 
> >Correct, they can continue on if they want (if re-elected) and I suppose
> >we could also let them resign from the post as well.
> 
> Hmmm. I figured one of the benefits of having a 2-3 month term would be
> that if they ~really~ didn't like it that they could see the light at the
> end of the tunnel and hang in for the term. But that's just me.

True, but we're supposedly moving to 6 month release cycle, after this
next release.  I guess the release schedule is also owned by the Project
Manager too, so they can determine it.

Mike
> 
> Jon
> 




From Jon.Benedict at netapp.com  Wed Sep  5 15:06:04 2012
From: Jon.Benedict at netapp.com (Benedict, Jon)
Date: Wed, 5 Sep 2012 15:06:04 +0000
Subject: New Role Proposal in the oVirt Project
In-Reply-To: <1346857024.11466.16.camel@mburns-laptop.usersys.redhat.com>
Message-ID: <6DA623DFCD60534EADA0E7BF74885C150C7780C7@SACEXCMBX03-PRD.hq.netapp.com>

On 9/5/12 10:57 AM, "Mike Burns" <mburns at redhat.com> wrote:


>Given some of the difficulties we've had recently with planning and
>getting releases pulled together, I'd like to propose we have a new role
>in the Project.
>
>Project Manager
>
>Responsibilities:
>
>Maintain Schedule
>Run weekly meeting
>Coordinate with project maintainers on dates, features, etc
>Ensure that docs and release materials are ready for release
>Final say on what goes into a release
>Tracking new features
>Tracking action items
>
>This person should be empowered to make decisions for the project (based
>on input from maintainers, but final call is theirs).
>
>As for choosing this person, it could be done via general election on
>email or an IRC meeting.  I'd suggest having someone do it for a limited
>timeline, maybe 2 or 3 releases, max, then someone else takes over.
>
>Any thoughts, suggestions, comments?


Mike,

I'm definitely in favor of a PM. I like the 2-3 term requirement, but if
they want to serve again it should be an option (subject to re-election).

Jon



From Jon.Benedict at netapp.com  Wed Sep  5 18:55:46 2012
From: Jon.Benedict at netapp.com (Benedict, Jon)
Date: Wed, 5 Sep 2012 18:55:46 +0000
Subject: New Role Proposal in the oVirt Project
In-Reply-To: <1346858750.2004.0.camel@mburns-laptop.usersys.redhat.com>
Message-ID: <6DA623DFCD60534EADA0E7BF74885C150C779565@SACEXCMBX03-PRD.hq.netapp.com>


On 9/5/12 11:25 AM, "Mike Burns" <mburns at redhat.com> wrote:

>Correct, they can continue on if they want (if re-elected) and I suppose
>we could also let them resign from the post as well.

Hmmm. I figured one of the benefits of having a 2-3 month term would be
that if they ~really~ didn't like it that they could see the light at the
end of the tunnel and hang in for the term. But that's just me.

Jon



From mburns at redhat.com  Wed Sep  5 19:25:29 2012
From: mburns at redhat.com (Mike Burns)
Date: Wed, 05 Sep 2012 15:25:29 -0400
Subject: New Role Proposal in the oVirt Project
In-Reply-To: <1346857024.11466.16.camel@mburns-laptop.usersys.redhat.com>
References: <1346857024.11466.16.camel@mburns-laptop.usersys.redhat.com>
Message-ID: <1346873129.2336.7.camel@mburns-laptop.usersys.redhat.com>

There seems to be general agreement that we could use someone filling
this role.  Are there any objections?

Assuming no, are there an nominations or volunteers for someone to take
the role?

On Wed, 2012-09-05 at 10:57 -0400, Mike Burns wrote:
> Given some of the difficulties we've had recently with planning and
> getting releases pulled together, I'd like to propose we have a new role
> in the Project.
> 
> Project Manager
> 
> Responsibilities:
> 
> Maintain Schedule
> Run weekly meeting
> Coordinate with project maintainers on dates, features, etc
> Ensure that docs and release materials are ready for release
> Final say on what goes into a release
> Tracking new features
> Tracking action items
> 
> This person should be empowered to make decisions for the project (based
> on input from maintainers, but final call is theirs).
> 
> As for choosing this person, it could be done via general election on
> email or an IRC meeting.  I'd suggest having someone do it for a limited
> timeline, maybe 2 or 3 releases, max, then someone else takes over.

One slight tweak to the above:  The existing person can continue in the
role if re-elected and there are no term limits.

> 
> Any thoughts, suggestions, comments?
> 
> Thanks
> 
> Mike
> 
> _______________________________________________
> Board mailing list
> Board at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/board




From mgoldboi at redhat.com  Thu Sep  6 08:21:08 2012
From: mgoldboi at redhat.com (Moran Goldboim)
Date: Thu, 06 Sep 2012 11:21:08 +0300
Subject: New Role Proposal in the oVirt Project
In-Reply-To: <1346873129.2336.7.camel@mburns-laptop.usersys.redhat.com>
References: <1346857024.11466.16.camel@mburns-laptop.usersys.redhat.com>
	<1346873129.2336.7.camel@mburns-laptop.usersys.redhat.com>
Message-ID: <50485CF4.9010205@redhat.com>

On 09/05/2012 10:25 PM, Mike Burns wrote:
> There seems to be general agreement that we could use someone filling
> this role.  Are there any objections?
>
> Assuming no, are there an nominations or volunteers for someone to take
> the role?

I would like to nominate myself for this role.
pros:
-I generally have the bellow responsibilities on RHEM, from dev perspective.

cons:
-many of you don't personally knows me since till now i was usually 
taking the backstage roles on upstream matters.

I'm willing to take the step forward, let me know what you think.

> On Wed, 2012-09-05 at 10:57 -0400, Mike Burns wrote:
>> Given some of the difficulties we've had recently with planning and
>> getting releases pulled together, I'd like to propose we have a new role
>> in the Project.
>>
>> Project Manager
>>
>> Responsibilities:
>>
>> Maintain Schedule
>> Run weekly meeting
>> Coordinate with project maintainers on dates, features, etc
>> Ensure that docs and release materials are ready for release
>> Final say on what goes into a release
>> Tracking new features
>> Tracking action items
>>
>> This person should be empowered to make decisions for the project (based
>> on input from maintainers, but final call is theirs).
>>
>> As for choosing this person, it could be done via general election on
>> email or an IRC meeting.  I'd suggest having someone do it for a limited
>> timeline, maybe 2 or 3 releases, max, then someone else takes over.
> One slight tweak to the above:  The existing person can continue in the
> role if re-elected and there are no term limits.
>
>> Any thoughts, suggestions, comments?
>>
>> Thanks
>>
>> Mike
>>
>> _______________________________________________
>> Board mailing list
>> Board at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/board
>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch



From mburns at redhat.com  Thu Sep  6 11:51:51 2012
From: mburns at redhat.com (Mike Burns)
Date: Thu, 06 Sep 2012 07:51:51 -0400
Subject: New Role Proposal in the oVirt Project
In-Reply-To: <50485CF4.9010205@redhat.com>
References: <1346857024.11466.16.camel@mburns-laptop.usersys.redhat.com>
	<1346873129.2336.7.camel@mburns-laptop.usersys.redhat.com>
	<50485CF4.9010205@redhat.com>
Message-ID: <1346932311.2674.2.camel@mburns-laptop.usersys.redhat.com>

On Thu, 2012-09-06 at 11:21 +0300, Moran Goldboim wrote:
> On 09/05/2012 10:25 PM, Mike Burns wrote:
> > There seems to be general agreement that we could use someone filling
> > this role.  Are there any objections?
> >
> > Assuming no, are there an nominations or volunteers for someone to take
> > the role?
> 
> I would like to nominate myself for this role.
> pros:
> -I generally have the bellow responsibilities on RHEM, from dev perspective.
> 
> cons:
> -many of you don't personally knows me since till now i was usually 
> taking the backstage roles on upstream matters.
> 
> I'm willing to take the step forward, let me know what you think.

Thanks Moran.  We'll give it a couple days for other volunteers to step
forward or be nominated and then setup a vote.  

Mike

> 
> > On Wed, 2012-09-05 at 10:57 -0400, Mike Burns wrote:
> >> Given some of the difficulties we've had recently with planning and
> >> getting releases pulled together, I'd like to propose we have a new role
> >> in the Project.
> >>
> >> Project Manager
> >>
> >> Responsibilities:
> >>
> >> Maintain Schedule
> >> Run weekly meeting
> >> Coordinate with project maintainers on dates, features, etc
> >> Ensure that docs and release materials are ready for release
> >> Final say on what goes into a release
> >> Tracking new features
> >> Tracking action items
> >>
> >> This person should be empowered to make decisions for the project (based
> >> on input from maintainers, but final call is theirs).
> >>
> >> As for choosing this person, it could be done via general election on
> >> email or an IRC meeting.  I'd suggest having someone do it for a limited
> >> timeline, maybe 2 or 3 releases, max, then someone else takes over.
> > One slight tweak to the above:  The existing person can continue in the
> > role if re-elected and there are no term limits.
> >
> >> Any thoughts, suggestions, comments?
> >>
> >> Thanks
> >>
> >> Mike
> >>
> >> _______________________________________________
> >> Board mailing list
> >> Board at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/board
> >
> > _______________________________________________
> > Arch mailing list
> > Arch at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> 
> _______________________________________________
> Board mailing list
> Board at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/board




From mburns at redhat.com  Thu Sep  6 11:55:10 2012
From: mburns at redhat.com (Mike Burns)
Date: Thu, 06 Sep 2012 07:55:10 -0400
Subject: New Role Proposal in the oVirt Project
In-Reply-To: <1346873129.2336.7.camel@mburns-laptop.usersys.redhat.com>
References: <1346857024.11466.16.camel@mburns-laptop.usersys.redhat.com>
	<1346873129.2336.7.camel@mburns-laptop.usersys.redhat.com>
Message-ID: <1346932510.2674.6.camel@mburns-laptop.usersys.redhat.com>

On Wed, 2012-09-05 at 15:25 -0400, Mike Burns wrote:
> There seems to be general agreement that we could use someone filling
> this role.  Are there any objections?
> 
> Assuming no, are there an nominations or volunteers for someone to take
> the role?

Forgot to mention that I'm willing to take this role on for the next
couple releases.  

As for my qualifications:

I've been doing a number of the coordination responsibilities already
I'm involved in both the Node (as maintainer) and Infra (as a
contributor) projects.
I've been pretty visible to the community already through both upstream
IRC and meetings and the oVirt Workshops.


> 
> On Wed, 2012-09-05 at 10:57 -0400, Mike Burns wrote:
> > Given some of the difficulties we've had recently with planning and
> > getting releases pulled together, I'd like to propose we have a new role
> > in the Project.
> > 
> > Project Manager
> > 
> > Responsibilities:
> > 
> > Maintain Schedule
> > Run weekly meeting
> > Coordinate with project maintainers on dates, features, etc
> > Ensure that docs and release materials are ready for release
> > Final say on what goes into a release
> > Tracking new features
> > Tracking action items
> > 
> > This person should be empowered to make decisions for the project (based
> > on input from maintainers, but final call is theirs).
> > 
> > As for choosing this person, it could be done via general election on
> > email or an IRC meeting.  I'd suggest having someone do it for a limited
> > timeline, maybe 2 or 3 releases, max, then someone else takes over.
> 
> One slight tweak to the above:  The existing person can continue in the
> role if re-elected and there are no term limits.
> 
> > 
> > Any thoughts, suggestions, comments?
> > 
> > Thanks
> > 
> > Mike
> > 
> > _______________________________________________
> > Board mailing list
> > Board at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/board
> 
> 
> _______________________________________________
> Board mailing list
> Board at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/board




From Jon.Benedict at netapp.com  Thu Sep  6 12:09:26 2012
From: Jon.Benedict at netapp.com (Benedict, Jon)
Date: Thu, 6 Sep 2012 12:09:26 +0000
Subject: New Role Proposal in the oVirt Project
In-Reply-To: <1346932311.2674.2.camel@mburns-laptop.usersys.redhat.com>
Message-ID: <6DA623DFCD60534EADA0E7BF74885C150C779ED7@SACEXCMBX03-PRD.hq.netapp.com>


On 9/6/12 7:51 AM, "Mike Burns" <mburns at redhat.com> wrote:

>Thanks Moran.  We'll give it a couple days for other volunteers to step
>forward or be nominated and then setup a vote.

Thanks to Mike and Moran for throwing their hats in the ring. Do we want
to wait until next weeks meeting for other volunteers, or was there
another date in mind?

Thanks,

Jon
> 



From dneary at redhat.com  Thu Sep  6 12:20:32 2012
From: dneary at redhat.com (Dave Neary)
Date: Thu, 06 Sep 2012 14:20:32 +0200
Subject: New Role Proposal in the oVirt Project
In-Reply-To: <6DA623DFCD60534EADA0E7BF74885C150C779ED7@SACEXCMBX03-PRD.hq.netapp.com>
References: <6DA623DFCD60534EADA0E7BF74885C150C779ED7@SACEXCMBX03-PRD.hq.netapp.com>
Message-ID: <50489510.5030008@redhat.com>

Hi,

On 09/06/2012 02:09 PM, Benedict, Jon wrote:
> On 9/6/12 7:51 AM, "Mike Burns" <mburns at redhat.com> wrote:
>
>> Thanks Moran.  We'll give it a couple days for other volunteers to step
>> forward or be nominated and then setup a vote.
>
> Thanks to Mike and Moran for throwing their hats in the ring. Do we want
> to wait until next weeks meeting for other volunteers, or was there
> another date in mind?

I think a week is long enough to wait.

Is there a process in place for deciding this sort of thing?

Cheers,
Dave.

-- 
Dave Neary
Community Action and Impact
Open Source and Standards, Red Hat
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13




From mburns at redhat.com  Thu Sep  6 12:28:01 2012
From: mburns at redhat.com (Mike Burns)
Date: Thu, 06 Sep 2012 08:28:01 -0400
Subject: New Role Proposal in the oVirt Project
In-Reply-To: <50489510.5030008@redhat.com>
References: <6DA623DFCD60534EADA0E7BF74885C150C779ED7@SACEXCMBX03-PRD.hq.netapp.com>
	<50489510.5030008@redhat.com>
Message-ID: <1346934481.2674.8.camel@mburns-laptop.usersys.redhat.com>

On Thu, 2012-09-06 at 14:20 +0200, Dave Neary wrote:
> Hi,
> 
> On 09/06/2012 02:09 PM, Benedict, Jon wrote:
> > On 9/6/12 7:51 AM, "Mike Burns" <mburns at redhat.com> wrote:
> >
> >> Thanks Moran.  We'll give it a couple days for other volunteers to step
> >> forward or be nominated and then setup a vote.
> >
> > Thanks to Mike and Moran for throwing their hats in the ring. Do we want
> > to wait until next weeks meeting for other volunteers, or was there
> > another date in mind?
> 
> I think a week is long enough to wait.

+1

> 
> Is there a process in place for deciding this sort of thing?

http://www.ovirt.org/governance/voting/

> 
> Cheers,
> Dave.
> 




From garrett at redhat.com  Thu Sep  6 18:58:51 2012
From: garrett at redhat.com (Garrett LeSage)
Date: Thu, 06 Sep 2012 20:58:51 +0200
Subject: revised download page mockup
Message-ID: <5048F26B.9020307@redhat.com>

Hi everyone,

Based on some feedback from the IRC meeting yesterday, I've scaled back 
the changes needed from oVirt for the download page and designed an 
alternate that we could use for the immediate future.

http://people.redhat.com/glesage/oVirt/website/mockup-1/download-alt.html

It's based on what is currently on oVirt.org, with some minor changes:
? simplification of the installation steps
? inclusion of system requirements and some summary text at the top

As I wanted to communicate what each section would say, I wrote some 
filler text that should be somewhat close to the idea of what we might 
want to use. However, the text on this page is very rough in comparison 
to the other pages, so please keep this in mind.


Also, I should note that the original download design (for comparison) 
is at:
http://people.redhat.com/glesage/oVirt/website/mockup-1/download.html

...and the background thoughts behind the original download page are at:
http://people.redhat.com/glesage/oVirt/website/background-info/design-download.html


Thanks! I'm looking forward to your feedback!
Garrett


From Jon.Benedict at netapp.com  Thu Sep  6 19:19:52 2012
From: Jon.Benedict at netapp.com (Benedict, Jon)
Date: Thu, 6 Sep 2012 19:19:52 +0000
Subject: revised download page mockup
In-Reply-To: <5048F26B.9020307@redhat.com>
Message-ID: <6DA623DFCD60534EADA0E7BF74885C150C77A4BA@SACEXCMBX03-PRD.hq.netapp.com>

Garrett,

This is great: it's clean, it's visually appealing, and it's concise.
Finding non-Fedora distro instructions is easy, and the fact that the page
solicits help for other distributions makes it (hopefully) apparent that
it's not just a Fedora/RHEL party.

Jon

-- 
Jon Benedict
Technical Marketing Engineer
Red Hat Technologies
Data Center Platforms

Blog http://captainkvm.com | Twitter @CaptainKVM







On 9/6/12 2:58 PM, "Garrett LeSage" <garrett at redhat.com> wrote:

>Hi everyone,
>
>Based on some feedback from the IRC meeting yesterday, I've scaled back
>the changes needed from oVirt for the download page and designed an
>alternate that we could use for the immediate future.
>
>http://people.redhat.com/glesage/oVirt/website/mockup-1/download-alt.html
>
>It's based on what is currently on oVirt.org, with some minor changes:
>? simplification of the installation steps
>? inclusion of system requirements and some summary text at the top
>
>As I wanted to communicate what each section would say, I wrote some
>filler text that should be somewhat close to the idea of what we might
>want to use. However, the text on this page is very rough in comparison
>to the other pages, so please keep this in mind.
>
>
>Also, I should note that the original download design (for comparison)
>is at:
>http://people.redhat.com/glesage/oVirt/website/mockup-1/download.html
>
>...and the background thoughts behind the original download page are at:
>http://people.redhat.com/glesage/oVirt/website/background-info/design-down
>load.html
>
>
>Thanks! I'm looking forward to your feedback!
>Garrett
>_______________________________________________
>Board mailing list
>Board at ovirt.org
>http://lists.ovirt.org/mailman/listinfo/board



From deepakcs at linux.vnet.ibm.com  Fri Sep  7 05:34:42 2012
From: deepakcs at linux.vnet.ibm.com (Deepak C Shetty)
Date: Fri, 07 Sep 2012 11:04:42 +0530
Subject: Talk Submission for oVirt Blr workshop [ was Re: [Users] Speakers
	Needed: Upcoming Workshops]
In-Reply-To: <5022DEDC.1090007@redhat.com>
References: <5022DEDC.1090007@redhat.com>
Message-ID: <50498772.6020103@linux.vnet.ibm.com>

Hello Leslie and the list,
     Myself and Harsh (in CC) will like to submit a proposal for this 
workshop. Details are as below.
Pls let me know if any more info is needed.

=============================================================

Biography
---------
* Deepak C Shetty is working with IBM's Linux Technology Center (LTC),
Bangalore, India, in the area of Open Virtualization. Earlier he has
worked in area of Virtualization aware File Systems. Prior to being part
of LTC, Deepak worked in the areas of Platform Management (IBM Systems
Director product) and Hardware Validation of IBM Power systems, in IBM .
Deepak holds a Bachelor of Engineering degree in Electronics from Pune
University, India and Diploma in Advanced Computing from C-DAC, Pune, 
India.
Other areas of interest include software design and stamp collection
(philately).

* Harsh Prateek Bora is working at IBM's Linux Technology Center (LTC) as
an open source developer having interest in the Virtualization stack in
Linux. He has contributed to Qemu, Libvirt and fs/9p for the development
of VirtFS (Qemu/KVM based virtualization aware file-system passthrough)
beside various other projects. Before joining IBM, He has worked at
Honeywell Aerospace for the development of embedded software for an
aircraft gadget (Apex Edge KSN 770). Currently at IBM LTC, He works for 
Linux
RAS team improving VPD (Vital Product Data) tools for Power PC arch based
hardware. He is working on providing support for Qemu-Gluster storage 
backend
in Libvirt out of his personal interest.


Abstract Title
---------------
Integrating GlusterFS as a storage domain in VDSM and supporting storage
array offloads from VDSM

Abstract
--------
This talk will focus on 2 aspects:

* GlusterFS as a storage domain in VDSM - WIP - ~30min.

	This presentation will discuss the challenges in integrating GlusterFS
as storage domain in VDSM, the different approaches taken and the pros and
cons. The new GlusterFS storage domain is necessary to support the native
integration of GlusterFS in QEMU. This talk will also touch upon the Gluster
enablements needed in libvirt and QEMU for VDSM to consume GlusterFS as a storage
domain. This work is part of the bigger goal of positioning GlusterFS as a
storage/Filesystem backend for QEMU in the Open Virtualization stack.

Related Links:
** http://gerrit.ovirt.org/#/c/6856/  - VDSM part
** http://www.redhat.com/archives/libvir-list/2012-August/msg01625.html  
- libvirt part
** http://lists.nongnu.org/archive/html/qemu-devel/2012-08/msg01536.html 
- QEMU part

* Enabling storage array offloads via libStorageMgmt (libSM) - WIP - 
~10min.

     Goal of this work is to provide a framework in VDSM to exploit 
storage array
offload features via libSM. libSM is an open-source project which 
provides vendor
agnostic API for managing external storage arrays. The initial proposal on
integrating libSM with VDSM has been discussed on the VDSM list. This 
talk will
touch upon libSM and its capabilties, VDSM-libSM integration goals, 
approaches,
advantages, challenges, current status&  future work.

Related Link:
** https://lists.fedorahosted.org/pipermail/vdsm-devel/2012-May/001011.html

Total time anticipated is 45 min - 40 min for the talk and 5 min for Q&A.
Deepak & Harsh will be co-presenting in this talk.

Virtualization and Storage administrators, oVirt/VDSM developers as well
as users of KVM virtualization will benefit from this talk.




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

From bpradip at in.ibm.com  Sun Sep  9 16:38:46 2012
From: bpradip at in.ibm.com (Pradipta Kumar Banerjee)
Date: Sun, 09 Sep 2012 22:08:46 +0530
Subject: KVM on IBM POWER (PPC64) support in vdsm and ovirt
Message-ID: <504CC616.60501@in.ibm.com>

Dear All,
Request your comments and suggestions on managing KVM on IBM POWER (PPC64) via
ovirt/vdsm

Please find the feature page here -
http://wiki.ovirt.org/wiki/Features/Vdsm_for_PPC64

The vdsm changes are under discussion and can be found here
http://gerrit.ovirt.org/7072

-- 
Regards,
Pradipta



From kwade at redhat.com  Mon Sep 10 17:53:40 2012
From: kwade at redhat.com (Karsten 'quaid' Wade)
Date: Mon, 10 Sep 2012 10:53:40 -0700
Subject: Mailing list scope proposal
In-Reply-To: <5045DF0D.6090100@redhat.com>
References: <502AB424.3010709@redhat.com> <50328DA8.10206@redhat.com>
	<5034FA0F.5030107@redhat.com> <5037ABD4.2030103@redhat.com>
	<5039CB24.6000704@redhat.com> <503BD933.3020501@redhat.com>
	<5045DF0D.6090100@redhat.com>
Message-ID: <504E2924.3080100@redhat.com>

On 09/04/2012 03:59 AM, Dave Neary wrote:
> Hi,
> 
> On 08/27/2012 10:31 PM, Karsten 'quaid' Wade wrote:
>
>> Also, I'm +1 to renaming this list; I reckon arch@ is confusing, dev@ or
>> developers@ is a more common Big Main List name.
> 
> It seems this has broad support - can we add it to the agenda for the
> weekly meeting this week to give people one last chance to have a say,
> and (assuming there is no major opposition) make it so?

I think we have support to:

i. Accept the mailing list scope, as you specified;
ii. Rename the arch@ mailing list.

Questions:

a. What name to change it to? Is dev@ descriptive enough, or developers@
is better?
b. What does it take to change the name?

As for b), I can do that research. I reckon it will be something like:

1. Create the new list as identical except for the name;
2. Mass subscribe all current subscribers (I can get the list easily via
the Mailman CLI);
3. (Optional) Copy or move all arch@ mail archives to be rebuilt under
the developers@ tree (I think this would work);
4. (Re)subscribe the list to Gmane;
5. Modify arch@ pages to say the list is deprecate, lockout new subscribers.
5.1 (Optional) Hide arch@ list from view or remove it entirely (unsure
of the negative consequences, aside from broken search URLs.)
6. Announce the change.

I reckon I'll find out a few more steps or details than that.

- Karsten
-- 
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
http://TheOpenSourceWay.org  .^\  http://community.redhat.com
@quaid (identi.ca/twitter/IRC)  \v'  gpg: AD0E0C41

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

From iheim at redhat.com  Mon Sep 10 17:57:50 2012
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 10 Sep 2012 20:57:50 +0300
Subject: Mailing list scope proposal
In-Reply-To: <504E2924.3080100@redhat.com>
References: <502AB424.3010709@redhat.com> <50328DA8.10206@redhat.com>
	<5034FA0F.5030107@redhat.com> <5037ABD4.2030103@redhat.com>
	<5039CB24.6000704@redhat.com> <503BD933.3020501@redhat.com>
	<5045DF0D.6090100@redhat.com> <504E2924.3080100@redhat.com>
Message-ID: <504E2A1E.3080405@redhat.com>

On 09/10/2012 08:53 PM, Karsten 'quaid' Wade wrote:
> a. What name to change it to? Is dev@ descriptive enough, or developers@
> is better?

+1 on dev - shorter.
devel also ok - in sync with other mailing lists (engine-devel, 
vdsm-devel, etc.)




From dneary at redhat.com  Mon Sep 10 18:36:04 2012
From: dneary at redhat.com (Dave Neary)
Date: Mon, 10 Sep 2012 20:36:04 +0200
Subject: Mailing list scope proposal
In-Reply-To: <504E2924.3080100@redhat.com>
References: <502AB424.3010709@redhat.com> <50328DA8.10206@redhat.com>
	<5034FA0F.5030107@redhat.com> <5037ABD4.2030103@redhat.com>
	<5039CB24.6000704@redhat.com> <503BD933.3020501@redhat.com>
	<5045DF0D.6090100@redhat.com> <504E2924.3080100@redhat.com>
Message-ID: <504E3314.6010809@redhat.com>

Hi,

On 09/10/2012 07:53 PM, Karsten 'quaid' Wade wrote:
> I think we have support to:
>
> i. Accept the mailing list scope, as you specified;
> ii. Rename the arch@ mailing list.

Excellent.

> Questions:
>
> a. What name to change it to? Is dev@ descriptive enough, or developers@
> is better?

Personally I liked the symmetry of "users" and "developers" but I'm 
happy with devel@ (and not a fan of dev@)

> b. What does it take to change the name?

Mailman can be a bit tricky that way, but as I understand it, you can:

1) Stop Mailman
2) Migrate all the subscribers from the old list to the new, and move 
archives (all in files on the filesystem)
3) Create an email alias forwarding email from the old list to the new 
(for backwards compatibility)
4) Restart Mailman and update various parameters, add the old address as 
an alias

https://chris-lamb.co.uk/2007/10/02/renaming-a-mailman-list/ has a step 
by step guide.

Cheers,
Dave.

-- 
Dave Neary
Community Action and Impact
Open Source and Standards, Red Hat
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From dfediuck at redhat.com  Tue Sep 11 06:40:06 2012
From: dfediuck at redhat.com (Doron Fediuck)
Date: Tue, 11 Sep 2012 02:40:06 -0400 (EDT)
Subject: Etherpad down
Message-ID: <369288200.8728352.1347345606209.JavaMail.root@redhat.com>

etherpad-ovirtapps.rhcloud.com

Can someone please take a look?
I have a pad there with an agenda for meeting today ;(


From jbrooks at redhat.com  Tue Sep 11 21:33:12 2012
From: jbrooks at redhat.com (Jason Brooks)
Date: Tue, 11 Sep 2012 14:33:12 -0700
Subject: revised download page mockup
In-Reply-To: <5048F26B.9020307@redhat.com>
References: <5048F26B.9020307@redhat.com>
Message-ID: <504FAE18.8020302@redhat.com>

On 09/06/2012 11:58 AM, Garrett LeSage wrote:
> Hi everyone,
>
> Based on some feedback from the IRC meeting yesterday, I've scaled back
> the changes needed from oVirt for the download page and designed an
> alternate that we could use for the immediate future.

This looks very nice, Garrett.

Some comments/thoughts:

The minimum RAM for ovirt is 4GB. You can get by with less, but the 
engine-setup script won't run if it detects less RAM. There is a command 
line argument, --no-mem-check, that disables the minimum memory check.

If we're going for simplicity, we may want to go with the 
ovirt-engine-setup-plugin-allinone as the suggested package to install. 
This way, you come out of these directions ready to create and run VMs. 
For a complete setup, it may be that the steps required are too many to 
include on this page. We could link to the quick start guide here: 
http://wiki.ovirt.org/wiki/Quick_Start_Guide.

Right now, oVirt only works with Fedora and CentOS/RHEL. We shouldn't 
give people the wrong idea about multi-distro possibilities. Someone 
could get the engine app running on jboss on a different platform, but 
vdsm, an essential component for doing anything w/ ovirt, is very much 
tied to fedora/el right now.

I really like the "you can help us make ovirt easy to run everywhere" 
link -- we need that help!




>
> http://people.redhat.com/glesage/oVirt/website/mockup-1/download-alt.html
>
> It's based on what is currently on oVirt.org, with some minor changes:
> ? simplification of the installation steps
> ? inclusion of system requirements and some summary text at the top
>
> As I wanted to communicate what each section would say, I wrote some
> filler text that should be somewhat close to the idea of what we might
> want to use. However, the text on this page is very rough in comparison
> to the other pages, so please keep this in mind.
>
>
> Also, I should note that the original download design (for comparison)
> is at:
> http://people.redhat.com/glesage/oVirt/website/mockup-1/download.html
>
> ...and the background thoughts behind the original download page are at:
> http://people.redhat.com/glesage/oVirt/website/background-info/design-download.html
>
>
>
> Thanks! I'm looking forward to your feedback!
> Garrett
> _______________________________________________
> Board mailing list
> Board at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/board


-- 

@jasonbrooks


From dneary at redhat.com  Wed Sep 12 08:01:57 2012
From: dneary at redhat.com (Dave Neary)
Date: Wed, 12 Sep 2012 10:01:57 +0200
Subject: revised download page mockup
In-Reply-To: <504FAE18.8020302@redhat.com>
References: <5048F26B.9020307@redhat.com> <504FAE18.8020302@redhat.com>
Message-ID: <50504175.5070900@redhat.com>

Hi,

On 09/11/2012 11:33 PM, Jason Brooks wrote:
> Right now, oVirt only works with Fedora and CentOS/RHEL. We shouldn't
> give people the wrong idea about multi-distro possibilities. Someone
> could get the engine app running on jboss on a different platform, but
> vdsm, an essential component for doing anything w/ ovirt, is very much
> tied to fedora/el right now.

While I accept that this is the current situation, I think we definitely 
want to give people the impression on the website that this is not a Red 
Hat only virtualisation manager - yes, there's work to be done to 
integrate it on other distros, but we are more than happy to integrate 
that work, and we plan on doing it ourselves for Ubuntu in the near 
future. The message "we welcome people who want to run other distros as 
oVirt nodes" is important.

Cheers,
Dave.


-- 
Dave Neary
Community Action and Impact
Open Source and Standards, Red Hat
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From dneary at redhat.com  Wed Sep 12 08:53:29 2012
From: dneary at redhat.com (Dave Neary)
Date: Wed, 12 Sep 2012 10:53:29 +0200
Subject: Mailing list scope proposal
In-Reply-To: <504E3314.6010809@redhat.com>
References: <502AB424.3010709@redhat.com> <50328DA8.10206@redhat.com>
	<5034FA0F.5030107@redhat.com> <5037ABD4.2030103@redhat.com>
	<5039CB24.6000704@redhat.com> <503BD933.3020501@redhat.com>
	<5045DF0D.6090100@redhat.com> <504E2924.3080100@redhat.com>
	<504E3314.6010809@redhat.com>
Message-ID: <50504D89.8070104@redhat.com>

Hi,

On 09/10/2012 08:36 PM, Dave Neary wrote:
>> b. What does it take to change the name?
>
> Mailman can be a bit tricky that way, but as I understand it, you can:
>
> 1) Stop Mailman
> 2) Migrate all the subscribers from the old list to the new, and move
> archives (all in files on the filesystem)
> 3) Create an email alias forwarding email from the old list to the new
> (for backwards compatibility)
> 4) Restart Mailman and update various parameters, add the old address as
> an alias
>
> https://chris-lamb.co.uk/2007/10/02/renaming-a-mailman-list/ has a step
> by step guide.

Turns out it's unsurprisingly a Mailman FAQ:
* http://wiki.list.org/pages/viewpage.action?pageId=4030617
* http://www.gnu.org/software/mailman/faq.html (search for "rename")

Cheers,
Dave.

-- 
Dave Neary
Community Action and Impact
Open Source and Standards, Red Hat
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From jbrooks at redhat.com  Wed Sep 12 14:48:15 2012
From: jbrooks at redhat.com (Jason Brooks)
Date: Wed, 12 Sep 2012 07:48:15 -0700
Subject: revised download page mockup
In-Reply-To: <50504175.5070900@redhat.com>
References: <5048F26B.9020307@redhat.com> <504FAE18.8020302@redhat.com>
	<50504175.5070900@redhat.com>
Message-ID: <5050A0AF.3080503@redhat.com>

On 09/12/2012 01:01 AM, Dave Neary wrote:
> Hi,
>
> On 09/11/2012 11:33 PM, Jason Brooks wrote:
>> Right now, oVirt only works with Fedora and CentOS/RHEL. We shouldn't
>> give people the wrong idea about multi-distro possibilities. Someone
>> could get the engine app running on jboss on a different platform, but
>> vdsm, an essential component for doing anything w/ ovirt, is very much
>> tied to fedora/el right now.
>
> While I accept that this is the current situation, I think we definitely
> want to give people the impression on the website that this is not a Red
> Hat only virtualisation manager - yes, there's work to be done to
> integrate it on other distros, but we are more than happy to integrate
> that work, and we plan on doing it ourselves for Ubuntu in the near
> future. The message "we welcome people who want to run other distros as
> oVirt nodes" is important.

Definitely -- I hope to see us make multi-distro a reality asap, and 
it's important to make that goal clear -- and make clear that currently, 
a goal is what it is.

>
> Cheers,
> Dave.
>
>


-- 

@jasonbrooks


From mburns at redhat.com  Wed Sep 12 15:07:10 2012
From: mburns at redhat.com (Mike Burns)
Date: Wed, 12 Sep 2012 11:07:10 -0400
Subject: Election for Project Manager -- Voting Closes 2012-09-14
Message-ID: <1347462430.7227.10.camel@mburns-laptop.usersys.redhat.com>

This is a call for votes for one of the two candidates for the oVirt
Project Manager Position.  Voting closes at EOD 2012-09-14.

The Candidates

Moran Goldboim
Mike Burns

The Role:

Project Manager

Responsibilities:

Maintain Schedule
Run weekly meeting
Coordinate with project maintainers on dates, features, etc
Ensure that docs and release materials are ready for release
Final say on what goes into a release
Tracking new features
Tracking action items
Release Schedule

This person should be empowered to make decisions for the project (based
on input from maintainers, but final call is theirs).

As for choosing this person, it could be done via general election on
email or an IRC meeting.  I'd suggest having someone do it for a limited
timeline, maybe 2 or 3 releases, then another election is held.  There
are no term limits, so if a person wants to continue past the 2 or 3
releases, all they need is to be reelected.  


Please submit your votes by the deadline!

Thanks

Mike



From dneary at redhat.com  Wed Sep 12 15:25:33 2012
From: dneary at redhat.com (Dave Neary)
Date: Wed, 12 Sep 2012 17:25:33 +0200
Subject: Election for Project Manager -- Voting Closes 2012-09-14
In-Reply-To: <1347462430.7227.10.camel@mburns-laptop.usersys.redhat.com>
References: <1347462430.7227.10.camel@mburns-laptop.usersys.redhat.com>
Message-ID: <5050A96D.4010606@redhat.com>

Hi Mike,

What's the voting procedure? Reply to the arch list indicating one's 
preference?

Cheers,
Dave.

On 09/12/2012 05:07 PM, Mike Burns wrote:
> This is a call for votes for one of the two candidates for the oVirt
> Project Manager Position.  Voting closes at EOD 2012-09-14.
>
> The Candidates
>
> Moran Goldboim
> Mike Burns
>
> The Role:
>
> Project Manager
>
> Responsibilities:
>
> Maintain Schedule
> Run weekly meeting
> Coordinate with project maintainers on dates, features, etc
> Ensure that docs and release materials are ready for release
> Final say on what goes into a release
> Tracking new features
> Tracking action items
> Release Schedule
>
> This person should be empowered to make decisions for the project (based
> on input from maintainers, but final call is theirs).
>
> As for choosing this person, it could be done via general election on
> email or an IRC meeting.  I'd suggest having someone do it for a limited
> timeline, maybe 2 or 3 releases, then another election is held.  There
> are no term limits, so if a person wants to continue past the 2 or 3
> releases, all they need is to be reelected.
>
>
> Please submit your votes by the deadline!
>
> Thanks
>
> Mike
>
> _______________________________________________
> Board mailing list
> Board at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/board
>

-- 
Dave Neary
Community Action and Impact
Open Source and Standards, Red Hat
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From mburns at redhat.com  Wed Sep 12 15:54:51 2012
From: mburns at redhat.com (Mike Burns)
Date: Wed, 12 Sep 2012 11:54:51 -0400
Subject: Election for Project Manager -- Voting Closes 2012-09-14
In-Reply-To: <5050A96D.4010606@redhat.com>
References: <1347462430.7227.10.camel@mburns-laptop.usersys.redhat.com>
	<5050A96D.4010606@redhat.com>
Message-ID: <1347465291.7227.13.camel@mburns-laptop.usersys.redhat.com>

On Wed, 2012-09-12 at 17:25 +0200, Dave Neary wrote:
> Hi Mike,
> 
> What's the voting procedure? Reply to the arch list indicating one's 
> preference?

Hmm,  I had thought that we would do the election in the open, but maybe
people don't want to do that.  Maybe have people reply on arch@ if
they're willing to do voting in the open, and otherwise, send the vote
directly to you, Dave?

Thoughts?

Mike

> 
> Cheers,
> Dave.
> 
> On 09/12/2012 05:07 PM, Mike Burns wrote:
> > This is a call for votes for one of the two candidates for the oVirt
> > Project Manager Position.  Voting closes at EOD 2012-09-14.
> >
> > The Candidates
> >
> > Moran Goldboim
> > Mike Burns
> >
> > The Role:
> >
> > Project Manager
> >
> > Responsibilities:
> >
> > Maintain Schedule
> > Run weekly meeting
> > Coordinate with project maintainers on dates, features, etc
> > Ensure that docs and release materials are ready for release
> > Final say on what goes into a release
> > Tracking new features
> > Tracking action items
> > Release Schedule
> >
> > This person should be empowered to make decisions for the project (based
> > on input from maintainers, but final call is theirs).
> >
> > As for choosing this person, it could be done via general election on
> > email or an IRC meeting.  I'd suggest having someone do it for a limited
> > timeline, maybe 2 or 3 releases, then another election is held.  There
> > are no term limits, so if a person wants to continue past the 2 or 3
> > releases, all they need is to be reelected.
> >
> >
> > Please submit your votes by the deadline!
> >
> > Thanks
> >
> > Mike
> >
> > _______________________________________________
> > Board mailing list
> > Board at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/board
> >
> 




From mgoldboi at redhat.com  Wed Sep 12 16:00:38 2012
From: mgoldboi at redhat.com (Moran Goldboim)
Date: Wed, 12 Sep 2012 19:00:38 +0300
Subject: Election for Project Manager -- Voting Closes 2012-09-14
In-Reply-To: <1347465291.7227.13.camel@mburns-laptop.usersys.redhat.com>
References: <1347462430.7227.10.camel@mburns-laptop.usersys.redhat.com>	<5050A96D.4010606@redhat.com>
	<1347465291.7227.13.camel@mburns-laptop.usersys.redhat.com>
Message-ID: <5050B1A6.2020403@redhat.com>

On 09/12/2012 06:54 PM, Mike Burns wrote:
> On Wed, 2012-09-12 at 17:25 +0200, Dave Neary wrote:
>> Hi Mike,
>>
>> What's the voting procedure? Reply to the arch list indicating one's
>> preference?
> Hmm,  I had thought that we would do the election in the open, but maybe
> people don't want to do that.  Maybe have people reply on arch@ if
> they're willing to do voting in the open, and otherwise, send the vote
> directly to you, Dave?
>
> Thoughts?

http://www.surveymonkey.com/ ?
Moran.

> Mike
>
>> Cheers,
>> Dave.
>>
>> On 09/12/2012 05:07 PM, Mike Burns wrote:
>>> This is a call for votes for one of the two candidates for the oVirt
>>> Project Manager Position.  Voting closes at EOD 2012-09-14.
>>>
>>> The Candidates
>>>
>>> Moran Goldboim
>>> Mike Burns
>>>
>>> The Role:
>>>
>>> Project Manager
>>>
>>> Responsibilities:
>>>
>>> Maintain Schedule
>>> Run weekly meeting
>>> Coordinate with project maintainers on dates, features, etc
>>> Ensure that docs and release materials are ready for release
>>> Final say on what goes into a release
>>> Tracking new features
>>> Tracking action items
>>> Release Schedule
>>>
>>> This person should be empowered to make decisions for the project (based
>>> on input from maintainers, but final call is theirs).
>>>
>>> As for choosing this person, it could be done via general election on
>>> email or an IRC meeting.  I'd suggest having someone do it for a limited
>>> timeline, maybe 2 or 3 releases, then another election is held.  There
>>> are no term limits, so if a person wants to continue past the 2 or 3
>>> releases, all they need is to be reelected.
>>>
>>>
>>> Please submit your votes by the deadline!
>>>
>>> Thanks
>>>
>>> Mike
>>>
>>> _______________________________________________
>>> Board mailing list
>>> Board at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/board
>>>
>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch



From mgoldboi at redhat.com  Wed Sep 12 16:25:22 2012
From: mgoldboi at redhat.com (Moran Goldboim)
Date: Wed, 12 Sep 2012 19:25:22 +0300
Subject: Election for Project Manager -- Voting Closes 2012-09-14
In-Reply-To: <5050B1A6.2020403@redhat.com>
References: <1347462430.7227.10.camel@mburns-laptop.usersys.redhat.com>	<5050A96D.4010606@redhat.com>	<1347465291.7227.13.camel@mburns-laptop.usersys.redhat.com>
	<5050B1A6.2020403@redhat.com>
Message-ID: <5050B772.9070905@redhat.com>

On 09/12/2012 07:00 PM, Moran Goldboim wrote:
> On 09/12/2012 06:54 PM, Mike Burns wrote:
>> On Wed, 2012-09-12 at 17:25 +0200, Dave Neary wrote:
>>> Hi Mike,
>>>
>>> What's the voting procedure? Reply to the arch list indicating one's
>>> preference?
>> Hmm,  I had thought that we would do the election in the open, but maybe
>> people don't want to do that.  Maybe have people reply on arch@ if
>> they're willing to do voting in the open, and otherwise, send the vote
>> directly to you, Dave?
>>
>> Thoughts?
>
> http://www.surveymonkey.com/ ?
> Moran.
>

I shouldn't be the one running it but take a look: 
http://www.surveymonkey.com/s/B8FTBJJ

>> Mike
>>
>>> Cheers,
>>> Dave.
>>>
>>> On 09/12/2012 05:07 PM, Mike Burns wrote:
>>>> This is a call for votes for one of the two candidates for the oVirt
>>>> Project Manager Position.  Voting closes at EOD 2012-09-14.
>>>>
>>>> The Candidates
>>>>
>>>> Moran Goldboim
>>>> Mike Burns
>>>>
>>>> The Role:
>>>>
>>>> Project Manager
>>>>
>>>> Responsibilities:
>>>>
>>>> Maintain Schedule
>>>> Run weekly meeting
>>>> Coordinate with project maintainers on dates, features, etc
>>>> Ensure that docs and release materials are ready for release
>>>> Final say on what goes into a release
>>>> Tracking new features
>>>> Tracking action items
>>>> Release Schedule
>>>>
>>>> This person should be empowered to make decisions for the project 
>>>> (based
>>>> on input from maintainers, but final call is theirs).
>>>>
>>>> As for choosing this person, it could be done via general election on
>>>> email or an IRC meeting.  I'd suggest having someone do it for a 
>>>> limited
>>>> timeline, maybe 2 or 3 releases, then another election is held.  There
>>>> are no term limits, so if a person wants to continue past the 2 or 3
>>>> releases, all they need is to be reelected.
>>>>
>>>>
>>>> Please submit your votes by the deadline!
>>>>
>>>> Thanks
>>>>
>>>> Mike
>>>>
>>>> _______________________________________________
>>>> Board mailing list
>>>> Board at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/board
>>>>
>>
>> _______________________________________________
>> Arch mailing list
>> Arch at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch
>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch



From mburns at redhat.com  Wed Sep 12 16:55:23 2012
From: mburns at redhat.com (Mike Burns)
Date: Wed, 12 Sep 2012 12:55:23 -0400
Subject: Election for Project Manager -- Voting Closes 2012-09-14
In-Reply-To: <5050B772.9070905@redhat.com>
References: <1347462430.7227.10.camel@mburns-laptop.usersys.redhat.com>
	<5050A96D.4010606@redhat.com>
	<1347465291.7227.13.camel@mburns-laptop.usersys.redhat.com>
	<5050B1A6.2020403@redhat.com> <5050B772.9070905@redhat.com>
Message-ID: <1347468923.7227.14.camel@mburns-laptop.usersys.redhat.com>

On Wed, 2012-09-12 at 19:25 +0300, Moran Goldboim wrote:
> On 09/12/2012 07:00 PM, Moran Goldboim wrote:
> > On 09/12/2012 06:54 PM, Mike Burns wrote:
> >> On Wed, 2012-09-12 at 17:25 +0200, Dave Neary wrote:
> >>> Hi Mike,
> >>>
> >>> What's the voting procedure? Reply to the arch list indicating one's
> >>> preference?
> >> Hmm,  I had thought that we would do the election in the open, but maybe
> >> people don't want to do that.  Maybe have people reply on arch@ if
> >> they're willing to do voting in the open, and otherwise, send the vote
> >> directly to you, Dave?
> >>
> >> Thoughts?
> >
> > http://www.surveymonkey.com/ ?
> > Moran.
> >
> 
> I shouldn't be the one running it but take a look: 
> http://www.surveymonkey.com/s/B8FTBJJ
> 

works for me

Mike
> >> Mike
> >>
> >>> Cheers,
> >>> Dave.
> >>>
> >>> On 09/12/2012 05:07 PM, Mike Burns wrote:
> >>>> This is a call for votes for one of the two candidates for the oVirt
> >>>> Project Manager Position.  Voting closes at EOD 2012-09-14.
> >>>>
> >>>> The Candidates
> >>>>
> >>>> Moran Goldboim
> >>>> Mike Burns
> >>>>
> >>>> The Role:
> >>>>
> >>>> Project Manager
> >>>>
> >>>> Responsibilities:
> >>>>
> >>>> Maintain Schedule
> >>>> Run weekly meeting
> >>>> Coordinate with project maintainers on dates, features, etc
> >>>> Ensure that docs and release materials are ready for release
> >>>> Final say on what goes into a release
> >>>> Tracking new features
> >>>> Tracking action items
> >>>> Release Schedule
> >>>>
> >>>> This person should be empowered to make decisions for the project 
> >>>> (based
> >>>> on input from maintainers, but final call is theirs).
> >>>>
> >>>> As for choosing this person, it could be done via general election on
> >>>> email or an IRC meeting.  I'd suggest having someone do it for a 
> >>>> limited
> >>>> timeline, maybe 2 or 3 releases, then another election is held.  There
> >>>> are no term limits, so if a person wants to continue past the 2 or 3
> >>>> releases, all they need is to be reelected.
> >>>>
> >>>>
> >>>> Please submit your votes by the deadline!
> >>>>
> >>>> Thanks
> >>>>
> >>>> Mike
> >>>>
> >>>> _______________________________________________
> >>>> Board mailing list
> >>>> Board at ovirt.org
> >>>> http://lists.ovirt.org/mailman/listinfo/board
> >>>>
> >>
> >> _______________________________________________
> >> 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 Jon.Benedict at netapp.com  Wed Sep 12 17:30:01 2012
From: Jon.Benedict at netapp.com (Benedict, Jon)
Date: Wed, 12 Sep 2012 17:30:01 +0000
Subject: Election for Project Manager -- Voting Closes 2012-09-14
In-Reply-To: <5050B772.9070905@redhat.com>
Message-ID: <6DA623DFCD60534EADA0E7BF74885C150C784D1B@SACEXCMBX03-PRD.hq.netapp.com>

On 9/12/12 12:25 PM, "Moran Goldboim" <mgoldboi at redhat.com> wrote:


>On 09/12/2012 07:00 PM, Moran Goldboim wrote:
>> On 09/12/2012 06:54 PM, Mike Burns wrote:
>>> On Wed, 2012-09-12 at 17:25 +0200, Dave Neary wrote:
>>>> Hi Mike,
>>>>
>>>> What's the voting procedure? Reply to the arch list indicating one's
>>>> preference?
>>> Hmm,  I had thought that we would do the election in the open, but
>>>maybe
>>> people don't want to do that.  Maybe have people reply on arch@ if
>>> they're willing to do voting in the open, and otherwise, send the vote
>>> directly to you, Dave?
>>>
>>> Thoughts?
>>
>> http://www.surveymonkey.com/ ?
>> Moran.
>>
>
>I shouldn't be the one running it but take a look:
>http://www.surveymonkey.com/s/B8FTBJJ

I'm fine with it.

Jon



From garrett at redhat.com  Wed Sep 12 18:04:53 2012
From: garrett at redhat.com (Garrett LeSage)
Date: Wed, 12 Sep 2012 20:04:53 +0200
Subject: revised download page mockup
In-Reply-To: <504FAE18.8020302@redhat.com>
References: <5048F26B.9020307@redhat.com> <504FAE18.8020302@redhat.com>
Message-ID: <5050CEC5.1020107@redhat.com>

On 09/11/2012 11:33 PM, Jason Brooks wrote:
> This looks very nice, Garrett.

Thanks!

> Some comments/thoughts:
>
> The minimum RAM for ovirt is 4GB. You can get by with less, but the 
> engine-setup script won't run if it detects less RAM. There is a 
> command line argument, --no-mem-check, that disables the minimum 
> memory check.

Thanks for the correction!

It was a placeholder to express the desire for minimum requirements on 
that page ? but accuracy even on mockups is a great thing, so I'm 
modifying them now.

Do you know the other requirements too? Such as hard disk space, etc. ? 
or anything I might be leaving out??


> If we're going for simplicity, we may want to go with the 
> ovirt-engine-setup-plugin-allinone as the suggested package to 
> install. This way, you come out of these directions ready to create 
> and run VMs. For a complete setup, it may be that the steps required 
> are too many to include on this page. We could link to the quick start 
> guide here: http://wiki.ovirt.org/wiki/Quick_Start_Guide.

That's the intent of the original download mockup:
http://people.redhat.com/glesage/oVirt/website/mockup-1/download.html
&
Info: 
http://people.redhat.com/glesage/oVirt/website/background-info/design-download.html

 From my understanding, it'll take effort from multiple people to get 
the all-in-one install ISO working how we want it to.

The goal of the download-alt mockup was to make sure we can move forward 
with the website and still launch in the near future, even if the 
all-in-one ISO isn't quite yet ready.

(Hopefully we can move to the fully packaged version soon, as I think 
it's conceptually friendlier to those installing oVirt.)


> Right now, oVirt only works with Fedora and CentOS/RHEL. We shouldn't 
> give people the wrong idea about multi-distro possibilities.

Agreed.

That's why I focused on using Fedora in both download page mockups and 
added a plea-for-help.

When other OSes are 100% *fully* supported in an all-in-one install ISO, 
we could then (perhaps) add some way to switch the page when we're 
comfortable enough that they work. Until that time, I firmly believe 
having a recommended install path with links to secondary support is fine.


> Someone could get the engine app running on jboss on a different 
> platform, but vdsm, an essential component for doing anything w/ 
> ovirt, is very much tied to fedora/el right now.

For the time being, "other distros" just means having the management UI 
running on various platforms, and that everyone using oVirt is using 
Fedora/RHEL/RHEL-derivative doing the heavy lifting on the servers, right?

What's the general plan & timeframe for getting VDSM et al. working 
cross-distro, so that all of oVirt can run everywhere?


Garrett


From jbrooks at redhat.com  Wed Sep 12 18:17:15 2012
From: jbrooks at redhat.com (Jason Brooks)
Date: Wed, 12 Sep 2012 11:17:15 -0700
Subject: revised download page mockup
In-Reply-To: <5050CEC5.1020107@redhat.com>
References: <5048F26B.9020307@redhat.com> <504FAE18.8020302@redhat.com>
	<5050CEC5.1020107@redhat.com>
Message-ID: <5050D1AB.1080505@redhat.com>

On 09/12/2012 11:04 AM, Garrett LeSage wrote:

>> If we're going for simplicity, we may want to go with the
>> ovirt-engine-setup-plugin-allinone as the suggested package to
>> install. This way, you come out of these directions ready to create
>> and run VMs. For a complete setup, it may be that the steps required
>> are too many to include on this page. We could link to the quick start
>> guide here: http://wiki.ovirt.org/wiki/Quick_Start_Guide.
>
> That's the intent of the original download mockup:
> http://people.redhat.com/glesage/oVirt/website/mockup-1/download.html
> &
> Info:
> http://people.redhat.com/glesage/oVirt/website/background-info/design-download.html
>
>
>  From my understanding, it'll take effort from multiple people to get
> the all-in-one install ISO working how we want it to.

This is different from ISO -- I'm talking about the all-in-one 
engine-setup plugin that's currently available. Right now, you can 
install the package "ovirt-engine-setup-plugin-allinone" which pulls in 
all the same stuff as ovirt-engine, but adds the option, in the 
engine-setup script, to make your engine also be a virtualization host.

With the regular setup, you come out of the script with the engine, a 
default data center, and an (optional) iso domain running on the engine 
machine. You then have to go create a data domain and add a host before 
you can use ovirt.

The AIO plugin adds a local data domain, and configures the engine to 
host VMs, so when you first visit the web console, you're ready to roll.


>
> For the time being, "other distros" just means having the management UI
> running on various platforms, and that everyone using oVirt is using
> Fedora/RHEL/RHEL-derivative doing the heavy lifting on the servers, right?
>
> What's the general plan & timeframe for getting VDSM et al. working
> cross-distro, so that all of oVirt can run everywhere?

I don't know the plan -- it'd be good to have a "things needed to enable 
multi-distro" page on the wiki. I'll try to start one.


>
>
> Garrett


-- 

@jasonbrooks


From garrett at redhat.com  Wed Sep 12 18:56:37 2012
From: garrett at redhat.com (Garrett LeSage)
Date: Wed, 12 Sep 2012 20:56:37 +0200
Subject: revised download page mockup
In-Reply-To: <5050D1AB.1080505@redhat.com>
References: <5048F26B.9020307@redhat.com> <504FAE18.8020302@redhat.com>
	<5050CEC5.1020107@redhat.com> <5050D1AB.1080505@redhat.com>
Message-ID: <5050DAE5.2070509@redhat.com>

On 09/12/2012 08:17 PM, Jason Brooks wrote:
> This is different from ISO

Aha, okay.

That's also great, and it's probably a requirement for an all-in-one 
installer that would allow someone to download just one ISO to install:
A) All of oVirt (this would be the default)
B) The server part ("node")
C) The web-based management UI

(Another approach could be to _always_ install everything on each 
machine, and oVirt could run in one of the above modes.)

>> What's the general plan & timeframe for getting VDSM et al. working 
>> cross-distro, so that all of oVirt can run everywhere?
>
> I don't know the plan -- it'd be good to have a "things needed to 
> enable multi-distro" page on the wiki. I'll try to start one.

Great idea!

Garrett


From mburns at redhat.com  Thu Sep 13 19:37:11 2012
From: mburns at redhat.com (Mike Burns)
Date: Thu, 13 Sep 2012 15:37:11 -0400
Subject: Project Manager Election (Cancelled)
Message-ID: <1347565031.17868.28.camel@mburns-laptop.usersys.redhat.com>

Just a quick update.  Moran and I had a couple behind the scenes emails
about this.  We decided that:

1.  Mike will be Project Manager and continue to lead the meetings, etc.
2.  Moran will server as the backup or VPM (vice project manager)
3.  We'll both share the responsibilities, though we haven't worked out
who will cover what yet.

Any objections?

Thanks

Mike



From Jon.Benedict at netapp.com  Thu Sep 13 19:43:47 2012
From: Jon.Benedict at netapp.com (Benedict, Jon)
Date: Thu, 13 Sep 2012 19:43:47 +0000
Subject: Project Manager Election (Cancelled)
In-Reply-To: <1347565031.17868.28.camel@mburns-laptop.usersys.redhat.com>
Message-ID: <6DA623DFCD60534EADA0E7BF74885C150C7867B2@SACEXCMBX03-PRD.hq.netapp.com>



On 9/13/12 3:37 PM, "Mike Burns" <mburns at redhat.com> wrote:

>Just a quick update.  Moran and I had a couple behind the scenes emails
>about this.  We decided that:
>
>1.  Mike will be Project Manager and continue to lead the meetings, etc.
>2.  Moran will server as the backup or VPM (vice project manager)
>3.  We'll both share the responsibilities, though we haven't worked out
>who will cover what yet.
>
>Any objections?
>
>Thanks
>
>Mike
>
>_______________________________________________
>Board mailing list
>Board at ovirt.org
>http://lists.ovirt.org/mailman/listinfo/board


No problem here.

Jon



From ryanh at us.ibm.com  Thu Sep 13 19:53:18 2012
From: ryanh at us.ibm.com (Ryan Harper)
Date: Thu, 13 Sep 2012 14:53:18 -0500
Subject: Project Manager Election (Cancelled)
In-Reply-To: <1347565031.17868.28.camel@mburns-laptop.usersys.redhat.com>
References: <1347565031.17868.28.camel@mburns-laptop.usersys.redhat.com>
Message-ID: <20120913195318.GA2104@frylock.phx.austin.ibm.com>

* Mike Burns <mburns at redhat.com> [2012-09-13 14:37]:
> Just a quick update.  Moran and I had a couple behind the scenes emails
> about this.  We decided that:
> 
> 1.  Mike will be Project Manager and continue to lead the meetings, etc.
> 2.  Moran will server as the backup or VPM (vice project manager)
> 3.  We'll both share the responsibilities, though we haven't worked out
> who will cover what yet.
> 
> Any objections?

No objection, sounds good.


> 
> Thanks
> 
> Mike
> 
> _______________________________________________
> 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 mgoldboi at redhat.com  Thu Sep 13 23:03:11 2012
From: mgoldboi at redhat.com (Moran Goldboim)
Date: Fri, 14 Sep 2012 02:03:11 +0300
Subject: Project Manager Election (Cancelled)
In-Reply-To: <1347565031.17868.28.camel@mburns-laptop.usersys.redhat.com>
References: <1347565031.17868.28.camel@mburns-laptop.usersys.redhat.com>
Message-ID: <5052662F.9000200@redhat.com>

On 09/13/2012 10:37 PM, Mike Burns wrote:
> Just a quick update.  Moran and I had a couple behind the scenes emails
> about this.  We decided that:
>
> 1.  Mike will be Project Manager and continue to lead the meetings, etc.
> 2.  Moran will server as the backup or VPM (vice project manager)
> 3.  We'll both share the responsibilities, though we haven't worked out
> who will cover what yet.
>
> Any objections?

I think this approach would be beneficial for for the project and for us 
as well.
Moran.

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



From kanagaraj.rk at gmail.com  Fri Sep 14 05:02:21 2012
From: kanagaraj.rk at gmail.com (R.Kanagaraj (RK))
Date: Fri, 14 Sep 2012 10:32:21 +0530
Subject: Project Manager Election (Cancelled)
In-Reply-To: <5052662F.9000200@redhat.com>
References: <1347565031.17868.28.camel@mburns-laptop.usersys.redhat.com>
	<5052662F.9000200@redhat.com>
Message-ID: <CALVLwtZNgpaTcDsqmNUtMK1X_6H16V50Mjd3UF8Kx9MFutHV_g@mail.gmail.com>

no objection

On Fri, Sep 14, 2012 at 4:33 AM, Moran Goldboim <mgoldboi at redhat.com> wrote:

> On 09/13/2012 10:37 PM, Mike Burns wrote:
>
>> Just a quick update.  Moran and I had a couple behind the scenes emails
>> about this.  We decided that:
>>
>> 1.  Mike will be Project Manager and continue to lead the meetings, etc.
>> 2.  Moran will server as the backup or VPM (vice project manager)
>> 3.  We'll both share the responsibilities, though we haven't worked out
>> who will cover what yet.
>>
>> Any objections?
>>
>
> I think this approach would be beneficial for for the project and for us
> as well.
> Moran.
>
>
>  Thanks
>>
>> Mike
>>
>> ______________________________**_________________
>> Arch mailing list
>> Arch at ovirt.org
>> http://lists.ovirt.org/**mailman/listinfo/arch<http://lists.ovirt.org/mailman/listinfo/arch>
>>
>
> ______________________________**_________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/**mailman/listinfo/arch<http://lists.ovirt.org/mailman/listinfo/arch>
>



-- 

With Regards,
RK,
+91 98404 83044
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20120914/2b8cf7ef/attachment.html>

From dneary at redhat.com  Fri Sep 14 07:29:43 2012
From: dneary at redhat.com (Dave Neary)
Date: Fri, 14 Sep 2012 09:29:43 +0200
Subject: Project Manager Election (Cancelled)
In-Reply-To: <1347565031.17868.28.camel@mburns-laptop.usersys.redhat.com>
References: <1347565031.17868.28.camel@mburns-laptop.usersys.redhat.com>
Message-ID: <5052DCE7.8050008@redhat.com>

Hi Mike,

Sounds good to me. Thanks Moran & Mike for working this out!

Cheers,
Dave.

On 09/13/2012 09:37 PM, Mike Burns wrote:
> Just a quick update.  Moran and I had a couple behind the scenes emails
> about this.  We decided that:
>
> 1.  Mike will be Project Manager and continue to lead the meetings, etc.
> 2.  Moran will server as the backup or VPM (vice project manager)
> 3.  We'll both share the responsibilities, though we haven't worked out
> who will cover what yet.
>
> Any objections?
>
> Thanks
>
> Mike
>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>

-- 
Dave Neary
Community Action and Impact
Open Source and Standards, Red Hat
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From fabiand at redhat.com  Fri Sep 14 08:17:01 2012
From: fabiand at redhat.com (Fabian Deutsch)
Date: Fri, 14 Sep 2012 10:17:01 +0200
Subject: Project Manager Election (Cancelled)
In-Reply-To: <5052DCE7.8050008@redhat.com>
References: <1347565031.17868.28.camel@mburns-laptop.usersys.redhat.com>
	<5052DCE7.8050008@redhat.com>
Message-ID: <1347610621.2270.8.camel@fdeutsch-laptop.local>

Am Freitag, den 14.09.2012, 09:29 +0200 schrieb Dave Neary:
> Hi Mike,
> 
> Sounds good to me. Thanks Moran & Mike for working this out!

+1

- fabian

> 
> Cheers,
> Dave.
> 
> On 09/13/2012 09:37 PM, Mike Burns wrote:
> > Just a quick update.  Moran and I had a couple behind the scenes emails
> > about this.  We decided that:
> >
> > 1.  Mike will be Project Manager and continue to lead the meetings, etc.
> > 2.  Moran will server as the backup or VPM (vice project manager)
> > 3.  We'll both share the responsibilities, though we haven't worked out
> > who will cover what yet.
> >
> > Any objections?
> >
> > Thanks
> >
> > Mike
> >
> > _______________________________________________
> > Arch mailing list
> > Arch at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> >
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20120914/c81d5586/attachment.sig>

From eedri at redhat.com  Fri Sep 14 08:49:27 2012
From: eedri at redhat.com (Eyal Edri)
Date: Fri, 14 Sep 2012 04:49:27 -0400 (EDT)
Subject: Project Manager Election (Cancelled)
In-Reply-To: <1347565031.17868.28.camel@mburns-laptop.usersys.redhat.com>
Message-ID: <1930985289.5562775.1347612567996.JavaMail.root@redhat.com>

+1.

sounds good.

----- Original Message -----
> From: "Mike Burns" <mburns at redhat.com>
> To: "board" <board at ovirt.org>, "arch" <arch at ovirt.org>
> Sent: Thursday, September 13, 2012 10:37:11 PM
> Subject: Project Manager Election (Cancelled)
> 
> Just a quick update.  Moran and I had a couple behind the scenes
> emails
> about this.  We decided that:
> 
> 1.  Mike will be Project Manager and continue to lead the meetings,
> etc.
> 2.  Moran will server as the backup or VPM (vice project manager)
> 3.  We'll both share the responsibilities, though we haven't worked
> out
> who will cover what yet.
> 
> Any objections?
> 
> Thanks
> 
> Mike
> 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From mburns at redhat.com  Mon Sep 17 11:59:47 2012
From: mburns at redhat.com (Mike Burns)
Date: Mon, 17 Sep 2012 07:59:47 -0400
Subject: Call for Agenda Items -- oVirt Weekly Meeting 2012-09-19
Message-ID: <1347883187.17868.32.camel@mburns-laptop.usersys.redhat.com>

Meeting Time and Place
oVirt Weekly Sync
      * Wednesdays @ 15:00 UTC (may change during DST changes) - always
at 7:00am US Pacific, 10:00am US Eastern.
              * To see in your timezone date -d 'WEDNESDAY 1000 EDT'
              * On IRC: #ovirt on irc.oftc.net

This is the agenda for the 2012-09-19 meeting:

        * Status of Next Release (Release Criteria, Target GA date)
        * Sub-project reports (engine, vdsm, node, infra)
        * Workshops

If you have other topics, please reply to me and I will add them to the
agenda.  If you propose a topic, please be prepared to lead the
discussion during the meeting.

Thanks

Mike



From kwade at redhat.com  Mon Sep 17 20:51:51 2012
From: kwade at redhat.com (Karsten 'quaid' Wade)
Date: Mon, 17 Sep 2012 13:51:51 -0700
Subject: Project Manager Election (Cancelled)
In-Reply-To: <1347565031.17868.28.camel@mburns-laptop.usersys.redhat.com>
References: <1347565031.17868.28.camel@mburns-laptop.usersys.redhat.com>
Message-ID: <50578D67.3090708@redhat.com>

On 09/13/2012 12:37 PM, Mike Burns wrote:
> Just a quick update.  Moran and I had a couple behind the scenes emails
> about this.  We decided that:
> 
> 1.  Mike will be Project Manager and continue to lead the meetings, etc.
> 2.  Moran will server as the backup or VPM (vice project manager)
> 3.  We'll both share the responsibilities, though we haven't worked out
> who will cover what yet.
> 
> Any objections?

None. Sounds like a good compromise, which I much prefer to voting and
elections. :)

- Karsten
-- 
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
http://TheOpenSourceWay.org  .^\  http://community.redhat.com
@quaid (identi.ca/twitter/IRC)  \v'  gpg: AD0E0C41

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

From dneary at redhat.com  Tue Sep 18 09:35:09 2012
From: dneary at redhat.com (Dave Neary)
Date: Tue, 18 Sep 2012 11:35:09 +0200
Subject: Call for Agenda Items -- oVirt Weekly Meeting 2012-09-19
In-Reply-To: <1347883187.17868.32.camel@mburns-laptop.usersys.redhat.com>
References: <1347883187.17868.32.camel@mburns-laptop.usersys.redhat.com>
Message-ID: <5058404D.5050708@redhat.com>

Hi,

Given that this week is Rosh Hashana and next week is Yom Kippur, 
traditionally 2 weeks holiday in Israel, does it make sense to maintain 
the weekly call? I'd suggest cancelling this week and next week's 
meetings, and having a "drive to 3.2" meeting in 2 weeks time.

What do you think, Mike?

Thanks,
Dave.

On 09/17/2012 01:59 PM, Mike Burns wrote:
> Meeting Time and Place
> oVirt Weekly Sync
>        * Wednesdays @ 15:00 UTC (may change during DST changes) - always
> at 7:00am US Pacific, 10:00am US Eastern.
>                * To see in your timezone date -d 'WEDNESDAY 1000 EDT'
>                * On IRC: #ovirt on irc.oftc.net
>
> This is the agenda for the 2012-09-19 meeting:
>
>          * Status of Next Release (Release Criteria, Target GA date)
>          * Sub-project reports (engine, vdsm, node, infra)
>          * Workshops
>
> If you have other topics, please reply to me and I will add them to the
> agenda.  If you propose a topic, please be prepared to lead the
> discussion during the meeting.
>
> Thanks
>
> Mike
>
> _______________________________________________
> Board mailing list
> Board at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/board
>

-- 
Dave Neary
Community Action and Impact
Open Source and Standards, Red Hat
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From Jon.Benedict at netapp.com  Tue Sep 18 11:45:40 2012
From: Jon.Benedict at netapp.com (Benedict, Jon)
Date: Tue, 18 Sep 2012 11:45:40 +0000
Subject: Call for Agenda Items -- oVirt Weekly Meeting 2012-09-19
In-Reply-To: <5058404D.5050708@redhat.com>
Message-ID: <6DA623DFCD60534EADA0E7BF74885C150C7A3920@SACEXCMBX03-PRD.hq.netapp.com>


On 9/18/12 5:35 AM, "Dave Neary" <dneary at redhat.com> wrote:

>Hi,
>
>Given that this week is Rosh Hashana and next week is Yom Kippur,
>traditionally 2 weeks holiday in Israel, does it make sense to maintain
>the weekly call? I'd suggest cancelling this week and next week's
>meetings, and having a "drive to 3.2" meeting in 2 weeks time.
>
>What do you think, Mike?
>
>Thanks,
>Dave.

No issues here, unless there are some good updates from folks who aren't
on holiday.

Jon



From dneary at redhat.com  Tue Sep 18 14:25:08 2012
From: dneary at redhat.com (Dave Neary)
Date: Tue, 18 Sep 2012 16:25:08 +0200
Subject: Call for Agenda Items -- oVirt Weekly Meeting 2012-09-19
In-Reply-To: <50585F7B.4030303@redhat.com>
References: <1347883187.17868.32.camel@mburns-laptop.usersys.redhat.com>
	<5058404D.5050708@redhat.com> <50585F7B.4030303@redhat.com>
Message-ID: <50588444.8020006@redhat.com>

Hi,

On 09/18/2012 01:48 PM, Robyn Bergeron wrote:
> Results usually vary, but it might be worth trying to have meetings;
> there are other activities which don't necessarily require the presence
> of the folks in Israel.  I've found that using holiday-ish times is
> usually good for things like brainstorming, finding easy fix-it items,
> etc; "top 5 wiki pages that need love," analyzing data/statistics on
> downloads from a new release.

That's a good point - we would need a different agenda to focus the 
meetings and help people decide if they should be there.

> These things are always difficult; it's less exciting to have not as
> many folks in the meeting, and sometimes not incredibly productive, but
> I always feel like I'm somehow discouraging/disenfranchising people in
> other regions when cancelling meetings because of local holidays.  I
> usually try to just keep the pulse going and try and bring in other
> folks to do some fun stuff that may be more enticing than usual :)

Yes, fair point - it's the wrong thing to do, and the wrong message to 
send. Let's maintain it - we can certainly have anopther meeting re the 
website redesign (Garrett's been working on a MediaWiki theme for a 
couple of weeks now) and release management, as you suggest.

Cheers,
Dave.

-- 
Dave Neary
Community Action and Impact
Open Source and Standards, Red Hat
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From garrett at redhat.com  Wed Sep 19 07:56:46 2012
From: garrett at redhat.com (Garrett LeSage)
Date: Wed, 19 Sep 2012 09:56:46 +0200
Subject: the new oVirt website: live preview!
Message-ID: <50597ABE.6050102@redhat.com>

Hi everyone!

Check out the new site here: http://mediawiki-garrett.rhcloud.com/

I've turned the Inkscape mockups into a real, working website, powered 
by MediaWiki.


## Background ##

During last week's IRC meeting, we talked about the possibility of using 
MediaWiki as community CMS. I spent this week making a custom skin that 
both works with some simple layout as well as standard MediaWiki pages.

It's also worth noting that it works on all screen resolutions and 
browser widths ? the whole design is ?responsive? which means it's 
optimized for mobile phones too, which is perfect for looking up 
documentation or telling people about oVirt at conferences and while 
traveling.


## Discussion ##

I would like to propose that we discuss the new website design & 
implementation during this week's IRC meeting, especially since there's 
now even more to see.


## Next steps ##

The website theme (including the signed-in state) is nearly done and 
looks amazingly similar to the mockups[1]. We have some content for the 
first few pages. There's still a bit more to do before making it live, 
however.

[1] mockups: http://people.redhat.com/glesage/oVirt/website/mockup-1/

The next steps are:

1. Fix any bugs found with the MediaWiki skin / theme
2. Work on content for the remaining pages
3. Map links on the main pages to existing content
4. Write additional content where necessary (if there's no page yet)
5. Upgrade MediaWiki on oVirt
6. Make sure the new pages are on the current wiki
7. Install the skin and a few configuration settings
8. Flip the switch (immediately after step 7), and we have a new site!


## One more thing... ##

It wouldn't be a great demo without letting you all testdrive the 
wiki-ness of the site, right? I've created a test user for everyone to 
quickly sign in and kick the tires on the wiki instance.

User: test
Pass: demodemo

You can also create your own account, if you'd like to. Please note that 
this is a temporary site for development purposes, and is not intended 
as a production website for oVirt. That said, it's a good place to play 
around.

You'll only see the wiki-ish stuff when you're signed in, and I worked 
hard to put them at the top of the page in an orderly fashion. Click on 
the items at the top to see menus with all the standard MediaWiki 
features, except grouped. Even the header is a dropdown (to see the 
different modes on the page). Since editing is key to any wiki, I made 
the edit action a stand-alone button at the top.

Also, when you're logged in, you'll notice that "Home", "Download", and 
"Community" are locked down so that only those in the administrator 
group can edit. Feel free to edit other pages or make new ones.

In addition, you might see some weirdness when using the site, as I'm 
not 100% done developing it. It's fairly stable, but it still is an 
alpha preview. I may alter things further or turn on some debugging 
output from time to time. Generally, though, I'll try to keep it in a 
working state. Just ping me on IRC if you have any concerns.


## In closing ##

I'd like to thank the team for challenging me during last week's meeting 
about using MediaWiki in this wiki-as-a-website concept. It's been a fun 
and interesting week jumping back into PHP after so long. I like the 
results, and I hope you do too!

= = =

I'm looking forward to your feedback, both here on the list, and also in 
the IRC meeting!

Garrett


From mburns at redhat.com  Wed Sep 19 12:24:36 2012
From: mburns at redhat.com (Mike Burns)
Date: Wed, 19 Sep 2012 08:24:36 -0400
Subject: Call for Agenda Items -- oVirt Weekly Meeting 2012-09-19
In-Reply-To: <50588444.8020006@redhat.com>
References: <1347883187.17868.32.camel@mburns-laptop.usersys.redhat.com>
	<5058404D.5050708@redhat.com> <50585F7B.4030303@redhat.com>
	<50588444.8020006@redhat.com>
Message-ID: <1348057476.4059.2.camel@beelzebub.mburnsfire.net>

On Tue, 2012-09-18 at 16:25 +0200, Dave Neary wrote:
> Hi,
> 
> On 09/18/2012 01:48 PM, Robyn Bergeron wrote:
> > Results usually vary, but it might be worth trying to have meetings;
> > there are other activities which don't necessarily require the presence
> > of the folks in Israel.  I've found that using holiday-ish times is
> > usually good for things like brainstorming, finding easy fix-it items,
> > etc; "top 5 wiki pages that need love," analyzing data/statistics on
> > downloads from a new release.
> 
> That's a good point - we would need a different agenda to focus the 
> meetings and help people decide if they should be there.
> 
> > These things are always difficult; it's less exciting to have not as
> > many folks in the meeting, and sometimes not incredibly productive, but
> > I always feel like I'm somehow discouraging/disenfranchising people in
> > other regions when cancelling meetings because of local holidays.  I
> > usually try to just keep the pulse going and try and bring in other
> > folks to do some fun stuff that may be more enticing than usual :)
> 
> Yes, fair point - it's the wrong thing to do, and the wrong message to 
> send. Let's maintain it - we can certainly have anopther meeting re the 
> website redesign (Garrett's been working on a MediaWiki theme for a 
> couple of weeks now) and release management, as you suggest.

Yes, I'd rather not cancel the meeting (even if we just meet for 10 min
and decide that there isn't much to discuss today).  

Dave, perhaps we can organize a different agenda for next week with some
of these other topics?  

Mike

> 
> Cheers,
> Dave.
> 




From ewoud+ovirt at kohlvanwijngaarden.nl  Wed Sep 19 13:38:26 2012
From: ewoud+ovirt at kohlvanwijngaarden.nl (Ewoud Kohl van Wijngaarden)
Date: Wed, 19 Sep 2012 15:38:26 +0200
Subject: the new oVirt website: live preview!
In-Reply-To: <50597ABE.6050102@redhat.com>
References: <50597ABE.6050102@redhat.com>
Message-ID: <20120919133825.GL9201@bogey.xentower.nl>

On Wed, Sep 19, 2012 at 09:56:46AM +0200, Garrett LeSage wrote:
> Check out the new site here: http://mediawiki-garrett.rhcloud.com/
>
> I've turned the Inkscape mockups into a real, working website,
> powered by MediaWiki.

Awesome job to base it on mediawiki. I love having a single place to
edit the site, guarded by permissions for stuff like the frontpage. How
easy to maintain is it when we want to upgrade mediawiki?

Haven't checked it in-depth yet but I'm wondering if the search should
be promoted to the top navigation. Also would like to a see a difference
in existing and non-existing links.


From veillard at redhat.com  Thu Sep 20 06:17:39 2012
From: veillard at redhat.com (Daniel Veillard)
Date: Thu, 20 Sep 2012 14:17:39 +0800
Subject: the new oVirt website: live preview!
In-Reply-To: <20120919133825.GL9201@bogey.xentower.nl>
References: <50597ABE.6050102@redhat.com>
	<20120919133825.GL9201@bogey.xentower.nl>
Message-ID: <20120920061739.GP31752@redhat.com>

On Wed, Sep 19, 2012 at 03:38:26PM +0200, Ewoud Kohl van Wijngaarden wrote:
> On Wed, Sep 19, 2012 at 09:56:46AM +0200, Garrett LeSage wrote:
> > Check out the new site here: http://mediawiki-garrett.rhcloud.com/
> >
> > I've turned the Inkscape mockups into a real, working website,
> > powered by MediaWiki.
> 
> Awesome job to base it on mediawiki. I love having a single place to
> edit the site, guarded by permissions for stuff like the frontpage. How
> easy to maintain is it when we want to upgrade mediawiki?

  Looks nice indeed !

  A bit of feedback too:

> Haven't checked it in-depth yet but I'm wondering if the search should
> be promoted to the top navigation.

  Seconded, even if the new site makes a better use of today's large
screens, the search is currently always hidden until one scrolls down

  The vertical spacing between 2 paragraphs or bulleted items looks a
tad bit too large to my eye compared to the spacing between lines.

  The top page and the Download page don't even tell what licence
is applicable, IMHO that crucial information should be presented to
the user between the time it hits the home page and the time he's told
how to install it on Fedora 17.

   thanks !

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/


From garrett at redhat.com  Thu Sep 20 12:16:17 2012
From: garrett at redhat.com (Garrett LeSage)
Date: Thu, 20 Sep 2012 14:16:17 +0200
Subject: the new oVirt website: live preview!
In-Reply-To: <20120919133825.GL9201@bogey.xentower.nl>
References: <50597ABE.6050102@redhat.com>
	<20120919133825.GL9201@bogey.xentower.nl>
Message-ID: <505B0911.7060401@redhat.com>

On 09/19/2012 03:38 PM, Ewoud Kohl van Wijngaarden wrote:
> Awesome job to base it on mediawiki. 

Thanks!

> I love having a single place to edit the site, guarded by permissions 
> for stuff like the frontpage. 

Yeah, I think it'll make a much more cohesive site, and would make it 
easier for everyone to edit everything (provided they have permissions 
to do so ? but I'm only suggesting the main pages be locked down to a 
select group).

> How easy to maintain is it when we want to upgrade mediawiki? 

Two of my main goals when making this were to make the site:
1) editable by all
2) easily maintainable for the oVirt infrastructure team

A complimentary goal was to make the skin:
3) reusable by others

I met all three above goals by basing it on MediaWiki's default theme 
"Vector" (although it has a lot of changes) and also on Twitter's 
Bootstrap, so that we would benefit from updates from both projects, and 
we can use formatting from each. (Basically: Near-instant documentation 
and support for updates!)

Since I intentionally made the base skin reusable, it *could* easily be 
picked up by other sites. (The oVirt theme is just a little layer on top 
of the MediaWiki skin that simply changes the fonts and colors and adds 
a little bit of oVirt style elsewhere in the site too.) The more popular 
it is elsewhere, the more bugfixes, improvements, and quick updates to 
new MediaWiki versions we'll get.


> Haven't checked it in-depth yet but I'm wondering if the search should 
> be promoted to the top navigation. 

I've gotten a lot of feedback about that. I'm going to consider ways to 
fit it in.

It's probably useful to point out that oVirt.org, right now, doesn't 
have a working search (try searching for "download", "git", etc.) ? yet 
it's one of the most prominent elements. The theme, as-is, is a huge 
step in the right direction, as search actually *works*. (The results 
still need to be a bit beautified, but that's on the todo.)

Also, I strongly believe search shouldn't be *needed* on a site... but 
it's good to have, however. People should be able to find the content 
they're looking for without having to resort to a search. On a website, 
search should secondary to navigation and hyperlinked content, used when 
all else fails.


> Also would like to a see a difference in existing and non-existing links. 

It's actually there in the CSS, but I commented it out for now, as most 
all of the links are non-existing.

Here's how it works:

* When you're signed in, right now the links turn orange. I could make 
them red (like the default) or underlined or strikethrough ? or even 
blink (if we really wanted to). I could also display icons or text 
before or afterward too.

* When you're *not* signed in, I will have it so that the link doesn't 
change color or change the mouse when it is hovered. (Basically: it 
looks like the text on the rest of the page.) Naturally, since we don't 
have much content on this website preview right now, and I wanted to 
display what it _would_ look like on the actual site, I decided to 
disable this feature for the time being.

-=-=-

Thanks for the feedback!
Garrett


From garrett at redhat.com  Thu Sep 20 12:27:28 2012
From: garrett at redhat.com (Garrett LeSage)
Date: Thu, 20 Sep 2012 14:27:28 +0200
Subject: the new oVirt website: live preview!
In-Reply-To: <20120920061739.GP31752@redhat.com>
References: <50597ABE.6050102@redhat.com>
	<20120919133825.GL9201@bogey.xentower.nl>
	<20120920061739.GP31752@redhat.com>
Message-ID: <505B0BB0.7090001@redhat.com>

On 09/20/2012 08:17 AM, Daniel Veillard wrote:
>    Looks nice indeed !

Thanks!

>    Seconded, even if the new site makes a better use of today's large
> screens, the search is currently always hidden until one scrolls down

This sentence gives me an idea about how to possibly incorporate search. 
I'll have to play around with it a bit, but I might have something to 
show pretty soon.


>    The vertical spacing between 2 paragraphs or bulleted items looks a
> tad bit too large to my eye compared to the spacing between lines.

I adjusted the spacing so that the line rhythm was maintained on the 
page. It's especially needed on pages like:

http://mediawiki-garrett.rhcloud.com/OVirt_3.1_release_notes
(Which is a copy/paste of the wiki text from the official oVirt wiki.)

I will probably tweak the fonts and text a bit further, especially when 
we have another reskinned instance of MediaWiki (containing all of the 
content from wiki.ovirt.org) up and running.


>    The top page and the Download page don't even tell what licence
> is applicable, IMHO that crucial information should be presented to
> the user between the time it hits the home page and the time he's told
> how to install it on Fedora 17.

That's a great point.

Is it enough to mention "ASL2.0" in the footer and link to a licensing 
page, like the current oVirt.org website does? Or should we say more?


Thanks for the feedback!
Garrett


From dneary at redhat.com  Thu Sep 20 12:57:07 2012
From: dneary at redhat.com (Dave Neary)
Date: Thu, 20 Sep 2012 14:57:07 +0200
Subject: the new oVirt website: live preview!
In-Reply-To: <505B0BB0.7090001@redhat.com>
References: <50597ABE.6050102@redhat.com>
	<20120919133825.GL9201@bogey.xentower.nl>
	<20120920061739.GP31752@redhat.com> <505B0BB0.7090001@redhat.com>
Message-ID: <505B12A3.9080809@redhat.com>

Hi,

On 09/20/2012 02:27 PM, Garrett LeSage wrote:
> On 09/20/2012 08:17 AM, Daniel Veillard wrote:
>>    The top page and the Download page don't even tell what licence
>> is applicable, IMHO that crucial information should be presented to
>> the user between the time it hits the home page and the time he's told
>> how to install it on Fedora 17.
>
> That's a great point.
>
> Is it enough to mention "ASL2.0" in the footer and link to a licensing
> page, like the current oVirt.org website does? Or should we say more?

IMHO, the license matters at earliest when you're downloading (so not on 
the front page), and probably only when you're making changes (the 
"Developer" or "Contributor" pages). The important thing is to let 
people know that the product is open source - that they are free to 
modify and redistribute it. The actual license only matters at the point 
where you want to do that.

Cheers,
Dave.

-- 
Dave Neary
Community Action and Impact
Open Source and Standards, Red Hat
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From veillard at redhat.com  Thu Sep 20 13:30:08 2012
From: veillard at redhat.com (Daniel Veillard)
Date: Thu, 20 Sep 2012 21:30:08 +0800
Subject: the new oVirt website: live preview!
In-Reply-To: <505B0BB0.7090001@redhat.com>
References: <50597ABE.6050102@redhat.com>
	<20120919133825.GL9201@bogey.xentower.nl>
	<20120920061739.GP31752@redhat.com> <505B0BB0.7090001@redhat.com>
Message-ID: <20120920133008.GQ31752@redhat.com>

On Thu, Sep 20, 2012 at 02:27:28PM +0200, Garrett LeSage wrote:
> On 09/20/2012 08:17 AM, Daniel Veillard wrote:

> >   The vertical spacing between 2 paragraphs or bulleted items looks a
> >tad bit too large to my eye compared to the spacing between lines.
> 
> I adjusted the spacing so that the line rhythm was maintained on the
> page. It's especially needed on pages like:
> 
> http://mediawiki-garrett.rhcloud.com/OVirt_3.1_release_notes
> (Which is a copy/paste of the wiki text from the official oVirt wiki.)
> 
> I will probably tweak the fonts and text a bit further, especially
> when we have another reskinned instance of MediaWiki (containing all
> of the content from wiki.ovirt.org) up and running.

  okay, well it's use one person feedback and i don't claim any
UI sense :-) but again the space left between the last bullet of
Installer section and the title of the Tools session looks quite large to
my eye (I can put a finger between the bottom of the '(' and the top of
the T here), vertical space is scarce especially on new screens :-\

> 
> >   The top page and the Download page don't even tell what licence
> >is applicable, IMHO that crucial information should be presented to
> >the user between the time it hits the home page and the time he's told
> >how to install it on Fedora 17.
> 
> That's a great point.
> 
> Is it enough to mention "ASL2.0" in the footer and link to a
> licensing page, like the current oVirt.org website does? Or should
> we say more?

  Saying it's OpenSource under "ASL2.0" with a link is sufficient sure !

    thanks Garrett :-)

Daniel


-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/


From iheim at redhat.com  Thu Sep 20 13:40:14 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 20 Sep 2012 16:40:14 +0300
Subject: the new oVirt website: live preview!
In-Reply-To: <50597ABE.6050102@redhat.com>
References: <50597ABE.6050102@redhat.com>
Message-ID: <505B1CBE.5030107@redhat.com>

On 09/19/2012 10:56 AM, Garrett LeSage wrote:
> Hi everyone!
>
> Check out the new site here: http://mediawiki-garrett.rhcloud.com/
>
> I've turned the Inkscape mockups into a real, working website, powered
> by MediaWiki.
>
>
> ## Background ##
>
> During last week's IRC meeting, we talked about the possibility of using
> MediaWiki as community CMS. I spent this week making a custom skin that
> both works with some simple layout as well as standard MediaWiki pages.
>
> It's also worth noting that it works on all screen resolutions and
> browser widths ? the whole design is ?responsive? which means it's
> optimized for mobile phones too, which is perfect for looking up
> documentation or telling people about oVirt at conferences and while
> traveling.
>
>
> ## Discussion ##
>
> I would like to propose that we discuss the new website design &
> implementation during this week's IRC meeting, especially since there's
> now even more to see.
>
>
> ## Next steps ##
>
> The website theme (including the signed-in state) is nearly done and
> looks amazingly similar to the mockups[1]. We have some content for the
> first few pages. There's still a bit more to do before making it live,
> however.
>
> [1] mockups: http://people.redhat.com/glesage/oVirt/website/mockup-1/
>
> The next steps are:
>
> 1. Fix any bugs found with the MediaWiki skin / theme
> 2. Work on content for the remaining pages
> 3. Map links on the main pages to existing content
> 4. Write additional content where necessary (if there's no page yet)
> 5. Upgrade MediaWiki on oVirt
> 6. Make sure the new pages are on the current wiki
> 7. Install the skin and a few configuration settings
> 8. Flip the switch (immediately after step 7), and we have a new site!
>
>
> ## One more thing... ##
>
> It wouldn't be a great demo without letting you all testdrive the
> wiki-ness of the site, right? I've created a test user for everyone to
> quickly sign in and kick the tires on the wiki instance.
>
> User: test
> Pass: demodemo
>
> You can also create your own account, if you'd like to. Please note that
> this is a temporary site for development purposes, and is not intended
> as a production website for oVirt. That said, it's a good place to play
> around.
>
> You'll only see the wiki-ish stuff when you're signed in, and I worked
> hard to put them at the top of the page in an orderly fashion. Click on
> the items at the top to see menus with all the standard MediaWiki
> features, except grouped. Even the header is a dropdown (to see the
> different modes on the page). Since editing is key to any wiki, I made
> the edit action a stand-alone button at the top.
>
> Also, when you're logged in, you'll notice that "Home", "Download", and
> "Community" are locked down so that only those in the administrator
> group can edit. Feel free to edit other pages or make new ones.
>
> In addition, you might see some weirdness when using the site, as I'm
> not 100% done developing it. It's fairly stable, but it still is an
> alpha preview. I may alter things further or turn on some debugging
> output from time to time. Generally, though, I'll try to keep it in a
> working state. Just ping me on IRC if you have any concerns.
>
>
> ## In closing ##
>
> I'd like to thank the team for challenging me during last week's meeting
> about using MediaWiki in this wiki-as-a-website concept. It's been a fun
> and interesting week jumping back into PHP after so long. I like the
> results, and I hope you do too!
>
> = = =
>
> I'm looking forward to your feedback, both here on the list, and also in
> the IRC meeting!

very nice!

small question - would the twitter feed work with mediawiki?

Thanks,
    Itamar


From cctrieloff at redhat.com  Thu Sep 20 13:45:32 2012
From: cctrieloff at redhat.com (Carl Trieloff)
Date: Thu, 20 Sep 2012 09:45:32 -0400
Subject: the new oVirt website: live preview!
In-Reply-To: <505B0BB0.7090001@redhat.com>
References: <50597ABE.6050102@redhat.com>
	<20120919133825.GL9201@bogey.xentower.nl>
	<20120920061739.GP31752@redhat.com> <505B0BB0.7090001@redhat.com>
Message-ID: <505B1DFC.1010201@redhat.com>

On 09/20/2012 08:27 AM, Garrett LeSage wrote:
>
> Is it enough to mention "ASL2.0" in the footer and link to a licensing
> page, like the current oVirt.org website does? Or should we say more? 


yes, and if needed, link it to the a licensing page saying that
everything is under AL2



From veillard at redhat.com  Thu Sep 20 14:06:59 2012
From: veillard at redhat.com (Daniel Veillard)
Date: Thu, 20 Sep 2012 22:06:59 +0800
Subject: the new oVirt website: live preview!
In-Reply-To: <505B12A3.9080809@redhat.com>
References: <50597ABE.6050102@redhat.com>
	<20120919133825.GL9201@bogey.xentower.nl>
	<20120920061739.GP31752@redhat.com> <505B0BB0.7090001@redhat.com>
	<505B12A3.9080809@redhat.com>
Message-ID: <20120920140659.GR31752@redhat.com>

On Thu, Sep 20, 2012 at 02:57:07PM +0200, Dave Neary wrote:
> Hi,
> 
> On 09/20/2012 02:27 PM, Garrett LeSage wrote:
> >On 09/20/2012 08:17 AM, Daniel Veillard wrote:
> >>   The top page and the Download page don't even tell what licence
> >>is applicable, IMHO that crucial information should be presented to
> >>the user between the time it hits the home page and the time he's told
> >>how to install it on Fedora 17.
> >
> >That's a great point.
> >
> >Is it enough to mention "ASL2.0" in the footer and link to a licensing
> >page, like the current oVirt.org website does? Or should we say more?
> 
> IMHO, the license matters at earliest when you're downloading (so
> not on the front page), and probably only when you're making changes
> (the "Developer" or "Contributor" pages). The important thing is to

  I think you're optimistic there. Lot of people won't download stuff
if they can't tell the Licence upfront, not just me :-)

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/


From dneary at redhat.com  Thu Sep 20 14:13:35 2012
From: dneary at redhat.com (Dave Neary)
Date: Thu, 20 Sep 2012 16:13:35 +0200
Subject: the new oVirt website: live preview!
In-Reply-To: <20120920140659.GR31752@redhat.com>
References: <50597ABE.6050102@redhat.com>
	<20120919133825.GL9201@bogey.xentower.nl>
	<20120920061739.GP31752@redhat.com>
	<505B0BB0.7090001@redhat.com> <505B12A3.9080809@redhat.com>
	<20120920140659.GR31752@redhat.com>
Message-ID: <505B248F.4000504@redhat.com>

Hi,

On 09/20/2012 04:06 PM, Daniel Veillard wrote:
> On Thu, Sep 20, 2012 at 02:57:07PM +0200, Dave Neary wrote:
>> IMHO, the license matters at earliest when you're downloading (so
>> not on the front page), and probably only when you're making changes
>> (the "Developer" or "Contributor" pages). The important thing is to
>
>    I think you're optimistic there. Lot of people won't download stuff
> if they can't tell the Licence upfront, not just me :-)

Like I said, I think that what is important is to say that this is open 
source, that you can use, modify and resistribute it - and then put the 
license information/legalese in the download page or elsewhere.

Cheers,
Dave.

-- 
Dave Neary
Community Action and Impact
Open Source and Standards, Red Hat
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From mburns at redhat.com  Thu Sep 20 14:50:42 2012
From: mburns at redhat.com (Mike Burns)
Date: Thu, 20 Sep 2012 10:50:42 -0400
Subject: the new oVirt website: live preview!
In-Reply-To: <20120920133008.GQ31752@redhat.com>
References: <50597ABE.6050102@redhat.com>
	<20120919133825.GL9201@bogey.xentower.nl>
	<20120920061739.GP31752@redhat.com> <505B0BB0.7090001@redhat.com>
	<20120920133008.GQ31752@redhat.com>
Message-ID: <1348152642.3977.19.camel@beelzebub.mburnsfire.net>

On Thu, 2012-09-20 at 21:30 +0800, Daniel Veillard wrote:
> On Thu, Sep 20, 2012 at 02:27:28PM +0200, Garrett LeSage wrote:
> > On 09/20/2012 08:17 AM, Daniel Veillard wrote:
> 
> > >   The vertical spacing between 2 paragraphs or bulleted items looks a
> > >tad bit too large to my eye compared to the spacing between lines.
> > 
> > I adjusted the spacing so that the line rhythm was maintained on the
> > page. It's especially needed on pages like:
> > 
> > http://mediawiki-garrett.rhcloud.com/OVirt_3.1_release_notes
> > (Which is a copy/paste of the wiki text from the official oVirt wiki.)
> > 
> > I will probably tweak the fonts and text a bit further, especially
> > when we have another reskinned instance of MediaWiki (containing all
> > of the content from wiki.ovirt.org) up and running.
> 
>   okay, well it's use one person feedback and i don't claim any
> UI sense :-) but again the space left between the last bullet of
> Installer section and the title of the Tools session looks quite large to
> my eye (I can put a finger between the bottom of the '(' and the top of
> the T here), vertical space is scarce especially on new screens :-\
> 
> > 
> > >   The top page and the Download page don't even tell what licence
> > >is applicable, IMHO that crucial information should be presented to
> > >the user between the time it hits the home page and the time he's told
> > >how to install it on Fedora 17.
> > 
> > That's a great point.
> > 
> > Is it enough to mention "ASL2.0" in the footer and link to a
> > licensing page, like the current oVirt.org website does? Or should
> > we say more?
> 
>   Saying it's OpenSource under "ASL2.0" with a link is sufficient sure !
> 
>     thanks Garrett :-)
> 
> Daniel

See other part of this thread -- we have projects in oVirt that are
*not* ASL 2.0.  ovirt-node is GPL2 and content on the site and wiki are
something else as well, iirc.

Mike

> 
> 




From garrett at redhat.com  Thu Sep 20 16:19:09 2012
From: garrett at redhat.com (Garrett LeSage)
Date: Thu, 20 Sep 2012 18:19:09 +0200
Subject: the new oVirt website: live preview!
In-Reply-To: <505B1CBE.5030107@redhat.com>
References: <50597ABE.6050102@redhat.com> <505B1CBE.5030107@redhat.com>
Message-ID: <505B41FD.3000804@redhat.com>

On 09/20/2012 03:40 PM, Itamar Heim wrote:
> very nice!

Thanks!

> small question - would the twitter feed work with mediawiki?

Sure. We'll definitely make it work.

We will most likely use a Twitter extension for MediaWiki:
http://www.mediawiki.org/wiki/Category:Twitter_extensions

And since we're on the topic of extensions, I know a few have been asked 
about before, notably YouTube and an events calendar.

YouTube:
http://www.mediawiki.org/wiki/Category:YouTube_extensions

Calendaring/events:
http://www.mediawiki.org/wiki/Extension:Calendar
http://www.mediawiki.org/wiki/Category:Calendar_extensions
(We could simply use the wiki itself to have text about the events too. 
We don't have to make it any more complex than it has to be.)


Garrett


From veillard at redhat.com  Fri Sep 21 00:29:52 2012
From: veillard at redhat.com (Daniel Veillard)
Date: Fri, 21 Sep 2012 08:29:52 +0800
Subject: the new oVirt website: live preview!
In-Reply-To: <1348152642.3977.19.camel@beelzebub.mburnsfire.net>
References: <50597ABE.6050102@redhat.com>
	<20120919133825.GL9201@bogey.xentower.nl>
	<20120920061739.GP31752@redhat.com> <505B0BB0.7090001@redhat.com>
	<20120920133008.GQ31752@redhat.com>
	<1348152642.3977.19.camel@beelzebub.mburnsfire.net>
Message-ID: <20120921002952.GS31752@redhat.com>

On Thu, Sep 20, 2012 at 10:50:42AM -0400, Mike Burns wrote:
> On Thu, 2012-09-20 at 21:30 +0800, Daniel Veillard wrote:
> > > Is it enough to mention "ASL2.0" in the footer and link to a
> > > licensing page, like the current oVirt.org website does? Or should
> > > we say more?
> > 
> >   Saying it's OpenSource under "ASL2.0" with a link is sufficient sure !
> > 
> >     thanks Garrett :-)
> > 
> > Daniel
> 
> See other part of this thread -- we have projects in oVirt that are
> *not* ASL 2.0.  ovirt-node is GPL2 and content on the site and wiki are
> something else as well, iirc.

  I wasn't arguing for a licence, just arguing for it to be clarified
before suggesting downloading the code.

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/


From kanagaraj.rk at gmail.com  Sun Sep 23 17:45:09 2012
From: kanagaraj.rk at gmail.com (R.Kanagaraj (RK))
Date: Sun, 23 Sep 2012 23:15:09 +0530
Subject: the new oVirt website: live preview!
In-Reply-To: <20120921002952.GS31752@redhat.com>
References: <50597ABE.6050102@redhat.com>
	<20120919133825.GL9201@bogey.xentower.nl>
	<20120920061739.GP31752@redhat.com> <505B0BB0.7090001@redhat.com>
	<20120920133008.GQ31752@redhat.com>
	<1348152642.3977.19.camel@beelzebub.mburnsfire.net>
	<20120921002952.GS31752@redhat.com>
Message-ID: <CALVLwta8JLmdxNHqNoEBK97hRdD9VWfjUvYs25njqQLzMQ3YVA@mail.gmail.com>

Excellent look and feel, eager to see it in live.

On Fri, Sep 21, 2012 at 5:59 AM, Daniel Veillard <veillard at redhat.com>wrote:

> On Thu, Sep 20, 2012 at 10:50:42AM -0400, Mike Burns wrote:
> > On Thu, 2012-09-20 at 21:30 +0800, Daniel Veillard wrote:
> > > > Is it enough to mention "ASL2.0" in the footer and link to a
> > > > licensing page, like the current oVirt.org website does? Or should
> > > > we say more?
> > >
> > >   Saying it's OpenSource under "ASL2.0" with a link is sufficient sure
> !
> > >
> > >     thanks Garrett :-)
> > >
> > > Daniel
> >
> > See other part of this thread -- we have projects in oVirt that are
> > *not* ASL 2.0.  ovirt-node is GPL2 and content on the site and wiki are
> > something else as well, iirc.
>
>   I wasn't arguing for a licence, just arguing for it to be clarified
> before suggesting downloading the code.
>
> Daniel
>
> --
> Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
> daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
> http://veillard.com/ | virtualization library  http://libvirt.org/
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>



-- 

With Regards,
RK,
+91 9840483044
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20120923/a6ab26f5/attachment.html>

From jhernand at redhat.com  Mon Sep 24 16:30:43 2012
From: jhernand at redhat.com (Juan Hernandez)
Date: Mon, 24 Sep 2012 18:30:43 +0200
Subject: [Engine-devel] libosinfo integration
In-Reply-To: <20120924152403.GI18952@redhat.com>
References: <50607379.7020102@redhat.com> <20120924152403.GI18952@redhat.com>
Message-ID: <50608AB3.1010808@redhat.com>

On 09/24/2012 05:24 PM, Daniel P. Berrange wrote:
> On Mon, Sep 24, 2012 at 04:51:37PM +0200, Roy Golan wrote:
>> Here's a draft wiki of the libosinfo integration with the engine
>> http://wiki.ovirt.org/wiki/Libosinfo
>>
>> please share your comments on this thread and I'll update the wiki
>> accordingly.
> 
> As a libosinfo maintainer I strongly discourage you from writing a custom
> API directly against the XML. While the format is stable from the POV
> that vendors/users can create new XML docs for new/customized OS variants
> they have, we do not consider it something for applications to be using
> directly. The libosinfo library API includes alot of logic beyond simply
> being an convenient way to process the XML. In particular dealing with
> the inheritance of data across OS, searching for data across a variety
> of data sources, relying on GIO for URI resolving, live update of the
> database, and more.
> 
> We're also not really interested in maintaining manually written bindings
> for any languages. Rather than putting effort into such bindings for Java,
> time is better spent on finishing the GOBject introspection mapping layer
> for Java. There was a proof of concept, which was never finished / updated
> to the final introspection spec, which can be used as a basis for ongoing
> development.
> 
>  https://live.gnome.org/JGIR
> 
> This work will be applicable way beyond just libosinfo, to a wide
> variety of useful APIs. Of possible interest to VDSM in the future will
> be things like the new libvirt-designer & libvirt-builder APIs which
> are going to provide a bridge between libvirt + libosinfo to simply
> life for application developers constructing XML for provisioning
> guests.

I think that the use of JGIR has already been discussed as a way to
interface the engine with libvdsm.so:

http://lists.ovirt.org/pipermail/arch/2012-August/000760.html

If I remember correctly the outcome of that discussion was that it
shouldn't be used because it is considered dangerous to use native
libraries from Java and because JGIR itself is very outdated. I don't
100% agree with the first part, but the second part is completely true.

Anyhow, as it seems to be the right way to interface with libosinfo and
future libvirt capabilities, we may want to rethink and put some effort
to bring it up to date.

-- 
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 alonbl at redhat.com  Mon Sep 24 18:59:33 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Mon, 24 Sep 2012 14:59:33 -0400 (EDT)
Subject: [Engine-devel] libosinfo integration
In-Reply-To: <50608AB3.1010808@redhat.com>
Message-ID: <418834811.224466.1348513173334.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Juan Hernandez" <jhernand at redhat.com>
> To: "Daniel P. Berrange" <berrange at redhat.com>
> Cc: "arch" <arch at ovirt.org>, engine-devel at ovirt.org
> Sent: Monday, September 24, 2012 6:30:43 PM
> Subject: Re: [Engine-devel] libosinfo integration
> 
> On 09/24/2012 05:24 PM, Daniel P. Berrange wrote:
> > On Mon, Sep 24, 2012 at 04:51:37PM +0200, Roy Golan wrote:
> >> Here's a draft wiki of the libosinfo integration with the engine
> >> http://wiki.ovirt.org/wiki/Libosinfo
> >>
> >> please share your comments on this thread and I'll update the wiki
> >> accordingly.
> > 
> > As a libosinfo maintainer I strongly discourage you from writing a
> > custom
> > API directly against the XML. While the format is stable from the
> > POV
> > that vendors/users can create new XML docs for new/customized OS
> > variants
> > they have, we do not consider it something for applications to be
> > using
> > directly. The libosinfo library API includes alot of logic beyond
> > simply
> > being an convenient way to process the XML. In particular dealing
> > with
> > the inheritance of data across OS, searching for data across a
> > variety
> > of data sources, relying on GIO for URI resolving, live update of
> > the
> > database, and more.
> > 
> > We're also not really interested in maintaining manually written
> > bindings
> > for any languages. Rather than putting effort into such bindings
> > for Java,
> > time is better spent on finishing the GOBject introspection mapping
> > layer
> > for Java. There was a proof of concept, which was never finished /
> > updated
> > to the final introspection spec, which can be used as a basis for
> > ongoing
> > development.
> > 
> >  https://live.gnome.org/JGIR
> > 
> > This work will be applicable way beyond just libosinfo, to a wide
> > variety of useful APIs. Of possible interest to VDSM in the future
> > will
> > be things like the new libvirt-designer & libvirt-builder APIs
> > which
> > are going to provide a bridge between libvirt + libosinfo to simply
> > life for application developers constructing XML for provisioning
> > guests.
> 
> I think that the use of JGIR has already been discussed as a way to
> interface the engine with libvdsm.so:
> 
> http://lists.ovirt.org/pipermail/arch/2012-August/000760.html
> 
> If I remember correctly the outcome of that discussion was that it
> shouldn't be used because it is considered dangerous to use native
> libraries from Java and because JGIR itself is very outdated. I don't
> 100% agree with the first part, but the second part is completely
> true.
> 
> Anyhow, as it seems to be the right way to interface with libosinfo
> and
> future libvirt capabilities, we may want to rethink and put some
> effort
> to bring it up to date.

I don't think Java should go native to obtain data, using JNI or whatever native interface that is offered. It can totally break the JVM and cause leaks and stability issues JRE would like to avoid.

Having language binding for data access logic seems a bit strange for me, as it should be easy to stabilize a schema either using XML or a set of CSVs, for all to read and use.

I do understand why JNI is to be used when OS specific features are to be used, for example unix domain sockets, shared memory, security, but not for data access.

The alternatives would be:

1. Run a python program at ovirt-engine start-up, use the python API to fetch the data we need, and generate our own tiny XML of the subset or even load it to the database. We can use the output safely in Java. Disadvantage is that we need to stop/start service or have a "refresh" verb for reload after libosinfo update.

2. When data is requested, execute a python process with cmdline arguments and get result from stdout of the process. The disadvantage is the overhead of clone().

3. Read the XML directly on runtime, disadvantage is if XML is changed.

4. Use the libosinfo python API during build and distribute an update to the information in versions of ovirt, disadvantage is slow refresh of data, not sure how often this data is updated.

5. Provide a web service that has specific XML-RPC / RESTful API, that can provide data out of the libosinfo, and publish it at internet. Configure ovirt to use it, disadvantage is the need for internet connection.

6. Configure cgi-bin locally at apache where ovirt is running, which provide XML-RPC / RESTful API, and access it locally.

In any case I would avoid exiting the JVM to interact with data provider.

Regards,
Alon.


From jhernand at redhat.com  Mon Sep 24 19:33:38 2012
From: jhernand at redhat.com (Juan Hernandez)
Date: Mon, 24 Sep 2012 21:33:38 +0200
Subject: [Engine-devel] libosinfo integration
In-Reply-To: <418834811.224466.1348513173334.JavaMail.root@redhat.com>
References: <418834811.224466.1348513173334.JavaMail.root@redhat.com>
Message-ID: <5060B592.2080104@redhat.com>

On 09/24/2012 08:59 PM, Alon Bar-Lev wrote:
> 
> 
> ----- Original Message -----
>> From: "Juan Hernandez" <jhernand at redhat.com>
>> To: "Daniel P. Berrange" <berrange at redhat.com>
>> Cc: "arch" <arch at ovirt.org>, engine-devel at ovirt.org
>> Sent: Monday, September 24, 2012 6:30:43 PM
>> Subject: Re: [Engine-devel] libosinfo integration
>>
>> On 09/24/2012 05:24 PM, Daniel P. Berrange wrote:
>>> On Mon, Sep 24, 2012 at 04:51:37PM +0200, Roy Golan wrote:
>>>> Here's a draft wiki of the libosinfo integration with the engine
>>>> http://wiki.ovirt.org/wiki/Libosinfo
>>>>
>>>> please share your comments on this thread and I'll update the wiki
>>>> accordingly.
>>>
>>> As a libosinfo maintainer I strongly discourage you from writing a
>>> custom
>>> API directly against the XML. While the format is stable from the
>>> POV
>>> that vendors/users can create new XML docs for new/customized OS
>>> variants
>>> they have, we do not consider it something for applications to be
>>> using
>>> directly. The libosinfo library API includes alot of logic beyond
>>> simply
>>> being an convenient way to process the XML. In particular dealing
>>> with
>>> the inheritance of data across OS, searching for data across a
>>> variety
>>> of data sources, relying on GIO for URI resolving, live update of
>>> the
>>> database, and more.
>>>
>>> We're also not really interested in maintaining manually written
>>> bindings
>>> for any languages. Rather than putting effort into such bindings
>>> for Java,
>>> time is better spent on finishing the GOBject introspection mapping
>>> layer
>>> for Java. There was a proof of concept, which was never finished /
>>> updated
>>> to the final introspection spec, which can be used as a basis for
>>> ongoing
>>> development.
>>>
>>>  https://live.gnome.org/JGIR
>>>
>>> This work will be applicable way beyond just libosinfo, to a wide
>>> variety of useful APIs. Of possible interest to VDSM in the future
>>> will
>>> be things like the new libvirt-designer & libvirt-builder APIs
>>> which
>>> are going to provide a bridge between libvirt + libosinfo to simply
>>> life for application developers constructing XML for provisioning
>>> guests.
>>
>> I think that the use of JGIR has already been discussed as a way to
>> interface the engine with libvdsm.so:
>>
>> http://lists.ovirt.org/pipermail/arch/2012-August/000760.html
>>
>> If I remember correctly the outcome of that discussion was that it
>> shouldn't be used because it is considered dangerous to use native
>> libraries from Java and because JGIR itself is very outdated. I don't
>> 100% agree with the first part, but the second part is completely
>> true.
>>
>> Anyhow, as it seems to be the right way to interface with libosinfo
>> and
>> future libvirt capabilities, we may want to rethink and put some
>> effort
>> to bring it up to date.
> 
> I don't think Java should go native to obtain data, using JNI or whatever native interface that is offered. It can totally break the JVM and cause leaks and stability issues JRE would like to avoid.

This is were I disagree, only a bit. It is true that using JNI *without
care* can totally break the JVM, generate leaks, and bring down all the
application. But if the JNI layer is developed carefully this should not
be more risky than any of the other multiple native libraries that you
use every day from Java without noticing.

In addition JGIR is based on JNA (which is well maintained and stable)
and doesn't include any "dangerous" native C code.

> Having language binding for data access logic seems a bit strange for me, as it should be easy to stabilize a schema either using XML or a set of CSVs, for all to read and use.
> 
> I do understand why JNI is to be used when OS specific features are to be used, for example unix domain sockets, shared memory, security, but not for data access.
> 
> The alternatives would be:
> 
> 1. Run a python program at ovirt-engine start-up, use the python API to fetch the data we need, and generate our own tiny XML of the subset or even load it to the database. We can use the output safely in Java. Disadvantage is that we need to stop/start service or have a "refresh" verb for reload after libosinfo update.
> 
> 2. When data is requested, execute a python process with cmdline arguments and get result from stdout of the process. The disadvantage is the overhead of clone().
> 
> 3. Read the XML directly on runtime, disadvantage is if XML is changed.
> 
> 4. Use the libosinfo python API during build and distribute an update to the information in versions of ovirt, disadvantage is slow refresh of data, not sure how often this data is updated.
> 
> 5. Provide a web service that has specific XML-RPC / RESTful API, that can provide data out of the libosinfo, and publish it at internet. Configure ovirt to use it, disadvantage is the need for internet connection.
> 
> 6. Configure cgi-bin locally at apache where ovirt is running, which provide XML-RPC / RESTful API, and access it locally.
> 
> In any case I would avoid exiting the JVM to interact with data provider.
> 
> Regards,
> Alon.
> 


-- 
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 alonbl at redhat.com  Mon Sep 24 20:01:08 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Mon, 24 Sep 2012 16:01:08 -0400 (EDT)
Subject: [Engine-devel] libosinfo integration
In-Reply-To: <5060B592.2080104@redhat.com>
Message-ID: <1716804551.237454.1348516868577.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Juan Hernandez" <jhernand at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "arch" <arch at ovirt.org>, engine-devel at ovirt.org, "Daniel P. Berrange" <berrange at redhat.com>
> Sent: Monday, September 24, 2012 9:33:38 PM
> Subject: Re: [Engine-devel] libosinfo integration
> 
> On 09/24/2012 08:59 PM, Alon Bar-Lev wrote:
> > 
> > 
> > ----- Original Message -----
> >> From: "Juan Hernandez" <jhernand at redhat.com>
> >> To: "Daniel P. Berrange" <berrange at redhat.com>
> >> Cc: "arch" <arch at ovirt.org>, engine-devel at ovirt.org
> >> Sent: Monday, September 24, 2012 6:30:43 PM
> >> Subject: Re: [Engine-devel] libosinfo integration
> >>
> >> On 09/24/2012 05:24 PM, Daniel P. Berrange wrote:
> >>> On Mon, Sep 24, 2012 at 04:51:37PM +0200, Roy Golan wrote:
> >>>> Here's a draft wiki of the libosinfo integration with the engine
> >>>> http://wiki.ovirt.org/wiki/Libosinfo
> >>>>
> >>>> please share your comments on this thread and I'll update the
> >>>> wiki
> >>>> accordingly.
> >>>
> >>> As a libosinfo maintainer I strongly discourage you from writing
> >>> a
> >>> custom
> >>> API directly against the XML. While the format is stable from the
> >>> POV
> >>> that vendors/users can create new XML docs for new/customized OS
> >>> variants
> >>> they have, we do not consider it something for applications to be
> >>> using
> >>> directly. The libosinfo library API includes alot of logic beyond
> >>> simply
> >>> being an convenient way to process the XML. In particular dealing
> >>> with
> >>> the inheritance of data across OS, searching for data across a
> >>> variety
> >>> of data sources, relying on GIO for URI resolving, live update of
> >>> the
> >>> database, and more.
> >>>
> >>> We're also not really interested in maintaining manually written
> >>> bindings
> >>> for any languages. Rather than putting effort into such bindings
> >>> for Java,
> >>> time is better spent on finishing the GOBject introspection
> >>> mapping
> >>> layer
> >>> for Java. There was a proof of concept, which was never finished
> >>> /
> >>> updated
> >>> to the final introspection spec, which can be used as a basis for
> >>> ongoing
> >>> development.
> >>>
> >>>  https://live.gnome.org/JGIR
> >>>
> >>> This work will be applicable way beyond just libosinfo, to a wide
> >>> variety of useful APIs. Of possible interest to VDSM in the
> >>> future
> >>> will
> >>> be things like the new libvirt-designer & libvirt-builder APIs
> >>> which
> >>> are going to provide a bridge between libvirt + libosinfo to
> >>> simply
> >>> life for application developers constructing XML for provisioning
> >>> guests.
> >>
> >> I think that the use of JGIR has already been discussed as a way
> >> to
> >> interface the engine with libvdsm.so:
> >>
> >> http://lists.ovirt.org/pipermail/arch/2012-August/000760.html
> >>
> >> If I remember correctly the outcome of that discussion was that it
> >> shouldn't be used because it is considered dangerous to use native
> >> libraries from Java and because JGIR itself is very outdated. I
> >> don't
> >> 100% agree with the first part, but the second part is completely
> >> true.
> >>
> >> Anyhow, as it seems to be the right way to interface with
> >> libosinfo
> >> and
> >> future libvirt capabilities, we may want to rethink and put some
> >> effort
> >> to bring it up to date.
> > 
> > I don't think Java should go native to obtain data, using JNI or
> > whatever native interface that is offered. It can totally break
> > the JVM and cause leaks and stability issues JRE would like to
> > avoid.
> 
> This is were I disagree, only a bit. It is true that using JNI
> *without
> care* can totally break the JVM, generate leaks, and bring down all
> the
> application. But if the JNI layer is developed carefully this should
> not
> be more risky than any of the other multiple native libraries that
> you
> use every day from Java without noticing.
> In addition JGIR is based on JNA (which is well maintained and
> stable)
> and doesn't include any "dangerous" native C code.
>

Well, you can call me old fashioned...

But I don't think that any none critical task should be run out of process of the production component.

It is not GObject layer I am afraid of, it is what it eventually runs.

I believe that the data provided by libosinfo is not vital for our runtime, no problem in fetching it before start.

And again, I don't think data provider should be language binding... this concept alone is making me scared, as instead of using well defined data container people will start to use mesh of components... I don't see how you can stabilize an application this way.

For the native library that you use "every day", I don't know what you referring to, I've done lsof of engine and saw no exception... which other native library we use these days?
 
> > Having language binding for data access logic seems a bit strange
> > for me, as it should be easy to stabilize a schema either using
> > XML or a set of CSVs, for all to read and use.
> > 
> > I do understand why JNI is to be used when OS specific features are
> > to be used, for example unix domain sockets, shared memory,
> > security, but not for data access.
> > 
> > The alternatives would be:
> > 
> > 1. Run a python program at ovirt-engine start-up, use the python
> > API to fetch the data we need, and generate our own tiny XML of
> > the subset or even load it to the database. We can use the output
> > safely in Java. Disadvantage is that we need to stop/start service
> > or have a "refresh" verb for reload after libosinfo update.
> > 
> > 2. When data is requested, execute a python process with cmdline
> > arguments and get result from stdout of the process. The
> > disadvantage is the overhead of clone().
> > 
> > 3. Read the XML directly on runtime, disadvantage is if XML is
> > changed.
> > 
> > 4. Use the libosinfo python API during build and distribute an
> > update to the information in versions of ovirt, disadvantage is
> > slow refresh of data, not sure how often this data is updated.
> > 
> > 5. Provide a web service that has specific XML-RPC / RESTful API,
> > that can provide data out of the libosinfo, and publish it at
> > internet. Configure ovirt to use it, disadvantage is the need for
> > internet connection.
> > 
> > 6. Configure cgi-bin locally at apache where ovirt is running,
> > which provide XML-RPC / RESTful API, and access it locally.
> > 
> > In any case I would avoid exiting the JVM to interact with data
> > provider.
> > 
> > Regards,
> > Alon.
> > 
> 
> 
> --
> 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 dougsland at redhat.com  Thu Sep 27 15:20:51 2012
From: dougsland at redhat.com (Douglas Landgraf)
Date: Thu, 27 Sep 2012 11:20:51 -0400
Subject: node upgrade: moving /data/updates to a different location
Message-ID: <50646ED3.7010607@redhat.com>

Hi,

Currently, we use /data/updates/ as place to archive the new ovirt-node 
iso that will be used during the oVirt Node upgrade.
This place is not standard, what about move to /var/lib/vdsm-reg ? Comments?

Thanks!

-- 
Cheers
Douglas

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

From alonbl at redhat.com  Thu Sep 27 14:37:14 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Thu, 27 Sep 2012 10:37:14 -0400 (EDT)
Subject: node upgrade: moving /data/updates to a different location
In-Reply-To: <50646ED3.7010607@redhat.com>
Message-ID: <2050715052.830233.1348756634722.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Douglas Landgraf" <dougsland at redhat.com>
> To: arch at ovirt.org
> Cc: "Mike Burns" <mburns at redhat.com>, "Federico Simoncelli" <fsimonce at redhat.com>, "Dan Kenigsberg"
> <danken at redhat.com>, "Barak Azulay" <bazulay at redhat.com>, "Alon Bar-Lev" <alonbl at redhat.com>
> Sent: Thursday, September 27, 2012 5:20:51 PM
> Subject: node upgrade: moving /data/updates to a different location
> 
> Hi,
> 
> Currently, we use /data/updates/ as place to archive the new
> ovirt-node iso that will be used during the oVirt Node upgrade.
> This place is not standard, what about move to /var/lib/vdsm-reg ?
> Comments?
> 
> Thanks!

Better focus on proper solution[1].

We should not care how upgrade process of node is done or where to put files.
Image should be piped to stdin of node specific upgrade while the upgrade which knows the node filesystem layout best choose where to temporary store it.

Alon.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=858596


From alonbl at redhat.com  Sun Sep 30 08:27:00 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Sun, 30 Sep 2012 04:27:00 -0400 (EDT)
Subject: [ATTENTION] Engine now uses PKCS#12 format to store private keys
In-Reply-To: <1123520528.1172148.1348992937576.JavaMail.root@redhat.com>
Message-ID: <630488619.1172228.1348993620855.JavaMail.root@redhat.com>

Hello All,

We committed a change in the method engine uses to store private keys.

So far the engine used Java proprietary JKS format, this format enabled only Java applications to access the keys, and made it hard to manipulate them using external programs.

>From now the engine is using the standard PKCS#12 format to store keys and associated certificate chain.

PKCS#12 format is standard and supported by many applications, and it allowed simpler enrollment procedure.

We also issue different certificate and key to be used as engine authentication (SSH, VDSM), and to be used for engine web interface (HTTPS). This change has two reasons:

1. Allow simpler migration to 3rd party certificate for the web interface.

2. Separate between different private key usages (signature and key exchange).

engine-upgrade script has been modified to upgrade the environment to the new state.

Please CC me for every issue you may experience.

Regards,
Alon.


From rbergero at redhat.com  Tue Sep 18 11:48:12 2012
From: rbergero at redhat.com (Robyn Bergeron)
Date: Tue, 18 Sep 2012 11:48:12 -0000
Subject: Call for Agenda Items -- oVirt Weekly Meeting 2012-09-19
In-Reply-To: <5058404D.5050708@redhat.com>
References: <1347883187.17868.32.camel@mburns-laptop.usersys.redhat.com>
	<5058404D.5050708@redhat.com>
Message-ID: <50585F7B.4030303@redhat.com>

On 09/18/2012 02:35 AM, Dave Neary wrote:
> Hi,
>
> Given that this week is Rosh Hashana and next week is Yom Kippur, 
> traditionally 2 weeks holiday in Israel, does it make sense to 
> maintain the weekly call? I'd suggest cancelling this week and next 
> week's meetings, and having a "drive to 3.2" meeting in 2 weeks time.
>
> What do you think, Mike?
As "the casual observer who used to be in these meetings more often" -- 
I know that it was mentioned last week that there would be a number of 
folks out through mid-october; holidays off in Israel extend past Yom 
Kippur. I'm not sure how large that group is, but that would actually be 
more like 3+ weeks; Sukkot ends on October 8th.  That's a fairly good 
stretch of time with (hopefully) other activities in the works that need 
updating.

Results usually vary, but it might be worth trying to have meetings; 
there are other activities which don't necessarily require the presence 
of the folks in Israel.  I've found that using holiday-ish times is 
usually good for things like brainstorming, finding easy fix-it items, 
etc; "top 5 wiki pages that need love," analyzing data/statistics on 
downloads from a new release.  I'd be happy to pop in one of the weeks 
and talk a bit about release manager stuff from a features/schedule/etc. 
perspective, and I know Leslie has ongoing things with events -- maybe 
looking at collateral/flyers/handouts, new swag ideas, marketing stuff 
might be fun. Or there's always try out oVirt in the Fedora 18 Alpha 
release, or plan a test day around it :D... oh, wait, I might be biased 
there :D

These things are always difficult; it's less exciting to have not as 
many folks in the meeting, and sometimes not incredibly productive, but 
I always feel like I'm somehow discouraging/disenfranchising people in 
other regions when cancelling meetings because of local holidays.  I 
usually try to just keep the pulse going and try and bring in other 
folks to do some fun stuff that may be more enticing than usual :)

Of course, all IMO - not trying to throw myself under the bus for 
anything here (except the release manager notes/observances).  Those 
intending to show up get to make the decision! :)

-robyn

>
> Thanks,
> Dave.
>
> On 09/17/2012 01:59 PM, Mike Burns wrote:
>> Meeting Time and Place
>> oVirt Weekly Sync
>>        * Wednesdays @ 15:00 UTC (may change during DST changes) - always
>> at 7:00am US Pacific, 10:00am US Eastern.
>>                * To see in your timezone date -d 'WEDNESDAY 1000 EDT'
>>                * On IRC: #ovirt on irc.oftc.net
>>
>> This is the agenda for the 2012-09-19 meeting:
>>
>>          * Status of Next Release (Release Criteria, Target GA date)
>>          * Sub-project reports (engine, vdsm, node, infra)
>>          * Workshops
>>
>> If you have other topics, please reply to me and I will add them to the
>> agenda.  If you propose a topic, please be prepared to lead the
>> discussion during the meeting.
>>
>> Thanks
>>
>> Mike
>>
>> _______________________________________________
>> Board mailing list
>> Board at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/board
>>
>