From lhornyak at redhat.com  Thu Nov  1 08:43:14 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Thu, 1 Nov 2012 04:43:14 -0400 (EDT)
Subject: [Engine-devel] operation mode
In-Reply-To: <1468143136.2780490.1351759294726.JavaMail.root@redhat.com>
Message-ID: <1153605388.2785506.1351759394992.JavaMail.root@redhat.com>

Hi,

I have just run into this. Vm's have an OperationMode attribute, it can be FullVirtualized or ParaVirtualized. It appears the attribute does not play in any decision, not sent to vdsm. Can it be removed or anyone need it?

thx,
Laszlo


From lhornyak at redhat.com  Thu Nov  1 08:57:33 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Thu, 1 Nov 2012 04:57:33 -0400 (EDT)
Subject: [Engine-devel] operation mode
In-Reply-To: <1153605388.2785506.1351759394992.JavaMail.root@redhat.com>
Message-ID: <1105967946.2803136.1351760253765.JavaMail.root@redhat.com>

The same question applies to HypervisorType, since only KVM is supported.

----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Thursday, November 1, 2012 9:43:14 AM
> Subject: [Engine-devel] operation mode
> 
> Hi,
> 
> I have just run into this. Vm's have an OperationMode attribute, it
> can be FullVirtualized or ParaVirtualized. It appears the attribute
> does not play in any decision, not sent to vdsm. Can it be removed
> or anyone need it?
> 
> thx,
> Laszlo
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From shaohef at linux.vnet.ibm.com  Thu Nov  1 09:23:49 2012
From: shaohef at linux.vnet.ibm.com (Sheldon)
Date: Thu, 01 Nov 2012 17:23:49 +0800
Subject: [Engine-devel] [help]how to get the CA certificate when
 uploader ISO
In-Reply-To: <50912982.5000606@redhat.com>
References: <508FA5CB.8040504@linux.vnet.ibm.com> <508FA70D.1010802@redhat.com>
	<508FB647.9020002@linux.vnet.ibm.com> <508FC373.8080901@redhat.com>
	<5090B9D7.8050302@linux.vnet.ibm.com> <50912982.5000606@redhat.com>
Message-ID: <50923FA5.3080903@linux.vnet.ibm.com>

On 10/31/2012 09:37 PM, Keith Robertson wrote:
> On 10/31/2012 01:40 AM, Sheldon wrote:
>> I make a domain name "ISO", Domain type is ISO, Storage Type is NFS, 
>> Format is V1
>>
>> $ sudo engine-iso-uploader -v --iso-domain=ISO upload 
>> Fedora-17-x86_64-DVD.iso
>> [sudo] password for ovirt:
>> Please provide the REST API username for oVirt Engine (CTRL+D to 
>> abort): admin at internal
>> Please provide the REST API password for the admin at internal oVirt 
>> Engine user (CTRL+D to abort):
>> ERROR: Problem connecting to the REST API.  Is the service available 
>> and does the CA certificate exist?
>> ERROR: 'NoneType' object is not iterable
>> INFO: Use the -h option to see usage. 
>
> Just to be clear the error in [1] is simply a symptom.  It isn't the 
> root cause.  The root cause is quite possibly the CA certificate.
>
> I have created a patch in [2] that I'd appreciate if you could test as 
> it will provide more debugging information about why the API creation 
> is failing.  Simply follow the steps in [3]
>
> Cheers,
> Keith
>
> [1] ERROR: 'NoneType' object is not iterable
> [2] http://gerrit.ovirt.org/8954
> [3]
> Step 1: git clone http://gerrit.ovirt.org/p/ovirt-iso-uploader.git
> Step 2: Cherry pick the patch...
> git fetch git://gerrit.ovirt.org/ovirt-iso-uploader 
> refs/changes/54/8954/2 && git cherry-pick FETCH_HEAD
> Step 3: export APP_VERSION=3.0.0; export APP_RELEASE=1
> Step 4: cd ovirt-iso-uploader
> Step 5: make
> Step 6: Notice the ovirt-iso-uploader*.rpm location in the STDOUT
> Step 7: yum install /path/to/ovirt-iso-uploader*.rpm

still error. but different debug info.

$ sudo engine-iso-uploader -v --iso-domain=ISO upload 
RHEL6.3-20120531.0-Server-x86_64-DVD1.iso
Please provide the REST API username for oVirt Engine (CTRL+D to abort): 
admin at internal
Please provide the REST API password for the admin at internal oVirt Engine 
user (CTRL+D to abort):
DEBUG: url(https://localhost:443/api)
DEBUG: user(admin at internal)
DEBUG: ca(/etc/pki/ovirt-engine/ca.pem)
DEBUG: insecure(False)
ERROR: Problem connecting to the REST API.  Is the service available and 
does the CA certificate exist? Error: [ERROR]::oVirt API connection 
failure, [Errno 111] Connection refused
DEBUG: Unable to get host and path information from API.


-- 
Sheldon Feng(???)<shaohef at linux.vnet.ibm.com>
IBM Linux Technology Center

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121101/1fa64469/attachment.html>

From kroberts at redhat.com  Thu Nov  1 13:52:19 2012
From: kroberts at redhat.com (Keith Robertson)
Date: Thu, 01 Nov 2012 09:52:19 -0400
Subject: [Engine-devel] [help]how to get the CA certificate when
 uploader ISO
In-Reply-To: <50923FA5.3080903@linux.vnet.ibm.com>
References: <508FA5CB.8040504@linux.vnet.ibm.com> <508FA70D.1010802@redhat.com>
	<508FB647.9020002@linux.vnet.ibm.com> <508FC373.8080901@redhat.com>
	<5090B9D7.8050302@linux.vnet.ibm.com> <50912982.5000606@redhat.com>
	<50923FA5.3080903@linux.vnet.ibm.com>
Message-ID: <50927E93.7060307@redhat.com>

On 11/01/2012 05:23 AM, Sheldon wrote:
> On 10/31/2012 09:37 PM, Keith Robertson wrote:
>> On 10/31/2012 01:40 AM, Sheldon wrote:
>>> I make a domain name "ISO", Domain type is ISO, Storage Type is NFS, 
>>> Format is V1
>>>
>>> $ sudo engine-iso-uploader -v --iso-domain=ISO upload 
>>> Fedora-17-x86_64-DVD.iso
>>> [sudo] password for ovirt:
>>> Please provide the REST API username for oVirt Engine (CTRL+D to 
>>> abort): admin at internal
>>> Please provide the REST API password for the admin at internal oVirt 
>>> Engine user (CTRL+D to abort):
>>> ERROR: Problem connecting to the REST API.  Is the service available 
>>> and does the CA certificate exist?
>>> ERROR: 'NoneType' object is not iterable
>>> INFO: Use the -h option to see usage. 
>>
>> Just to be clear the error in [1] is simply a symptom.  It isn't the 
>> root cause.  The root cause is quite possibly the CA certificate.
>>
>> I have created a patch in [2] that I'd appreciate if you could test 
>> as it will provide more debugging information about why the API 
>> creation is failing.  Simply follow the steps in [3]
>>
>> Cheers,
>> Keith
>>
>> [1] ERROR: 'NoneType' object is not iterable
>> [2] http://gerrit.ovirt.org/8954
>> [3]
>> Step 1: git clone http://gerrit.ovirt.org/p/ovirt-iso-uploader.git
>> Step 2: Cherry pick the patch...
>> git fetch git://gerrit.ovirt.org/ovirt-iso-uploader 
>> refs/changes/54/8954/2 && git cherry-pick FETCH_HEAD
>> Step 3: export APP_VERSION=3.0.0; export APP_RELEASE=1
>> Step 4: cd ovirt-iso-uploader
>> Step 5: make
>> Step 6: Notice the ovirt-iso-uploader*.rpm location in the STDOUT
>> Step 7: yum install /path/to/ovirt-iso-uploader*.rpm
>
> still error. but different debug info.
Yes.  The patch adds additional debug info.
>
> $ sudo engine-iso-uploader -v --iso-domain=ISO upload 
> RHEL6.3-20120531.0-Server-x86_64-DVD1.iso
> Please provide the REST API username for oVirt Engine (CTRL+D to 
> abort): admin at internal
> Please provide the REST API password for the admin at internal oVirt 
> Engine user (CTRL+D to abort):
> DEBUG: url(https://localhost:443/api)
> DEBUG: user(admin at internal)
> DEBUG: ca(/etc/pki/ovirt-engine/ca.pem)
> DEBUG: insecure(False)
> ERROR: Problem connecting to the REST API.  Is the service available 
> and does the CA certificate exist? Error: [ERROR]::oVirt API 
> connection failure, 
Now we're getting to the good stuff as you can see that you are getting 
a connection refused.  Questions for you:

1) Are you *certain* that 'https://localhost:443/api' is accessible from 
the local system, that it is the address of your oVirt engine, and is 
not being blocked by a FW?  Easy test on the local box point your 
browser at that url.

2) Are you certain that the CA is valid?  To verify this you will need 
to issue a 'curl' statement and supply the CA.  Example:
  curl -v -k -u $USER:$PASS --cacert /etc/pki/ovirt-engine/ca.pem  -X 
GET -H 'Accept: application/xml'  'https://localhost:443/api/api/vms
> [Errno 111] Connection refused
> DEBUG: Unable to get host and path information from API.
>
>
> -- 
> Sheldon Feng(???)<shaohef at linux.vnet.ibm.com>
> IBM Linux Technology Center

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121101/2113ae82/attachment.html>

From iheim at redhat.com  Thu Nov  1 18:35:27 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 01 Nov 2012 20:35:27 +0200
Subject: [Engine-devel] operation mode
In-Reply-To: <1153605388.2785506.1351759394992.JavaMail.root@redhat.com>
References: <1153605388.2785506.1351759394992.JavaMail.root@redhat.com>
Message-ID: <5092C0EF.6010704@redhat.com>

On 11/01/2012 10:43 AM, Laszlo Hornyak wrote:
> Hi,
>
> I have just run into this. Vm's have an OperationMode attribute, it can be FullVirtualized or ParaVirtuaized. It appears the attribute does not play in any decision, not sent 
to vdsm. Can it be removed or anyone need it?

wow, that's old...
iirc, back in 2007, some cases required to boot with qemu instead of kvm 
(some real mode stuff (ghost?))

i think can be removed...

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




From iheim at redhat.com  Thu Nov  1 19:16:48 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 01 Nov 2012 21:16:48 +0200
Subject: [Engine-devel] operation mode
In-Reply-To: <1105967946.2803136.1351760253765.JavaMail.root@redhat.com>
References: <1105967946.2803136.1351760253765.JavaMail.root@redhat.com>
Message-ID: <5092CAA0.6070202@redhat.com>

On 11/01/2012 10:57 AM, Laszlo Hornyak wrote:
> The same question applies to HypervisorType, since only KVM is supported.

I think this one is worth a bit more thinking before removing actually, 
but if you remove it in a single patch, easy enough to revert should we 
want to add something like this back (and the enum is far from all that 
needs to be done anyway for such a thing)

>
> ----- Original Message -----
>> From: "Laszlo Hornyak" <lhornyak at redhat.com>
>> To: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Thursday, November 1, 2012 9:43:14 AM
>> Subject: [Engine-devel] operation mode
>>
>> Hi,
>>
>> I have just run into this. Vm's have an OperationMode attribute, it
>> can be FullVirtualized or ParaVirtualized. It appears the attribute
>> does not play in any decision, not sent to vdsm. Can it be removed
>> or anyone need it?
>>
>> thx,
>> Laszlo
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>




From lhornyak at redhat.com  Thu Nov  1 21:07:00 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Thu, 1 Nov 2012 17:07:00 -0400 (EDT)
Subject: [Engine-devel] operation mode
In-Reply-To: <5092C0EF.6010704@redhat.com>
Message-ID: <2114390018.3246777.1351804020272.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Thursday, November 1, 2012 7:35:27 PM
> Subject: Re: [Engine-devel] operation mode
> 
> On 11/01/2012 10:43 AM, Laszlo Hornyak wrote:
> > Hi,
> >
> > I have just run into this. Vm's have an OperationMode attribute, it
> > can be FullVirtualized or ParaVirtuaized. It appears the attribute
> > does not play in any decision, not sent
> to vdsm. Can it be removed or anyone need it?
> 
> wow, that's old...
> iirc, back in 2007, some cases required to boot with qemu instead of
> kvm
> (some real mode stuff (ghost?))
> 
> i think can be removed...

http://gerrit.ovirt.org/8986

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


From lhornyak at redhat.com  Thu Nov  1 21:13:12 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Thu, 1 Nov 2012 17:13:12 -0400 (EDT)
Subject: [Engine-devel] operation mode
In-Reply-To: <5092CAA0.6070202@redhat.com>
Message-ID: <638216585.3248344.1351804392348.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Thursday, November 1, 2012 8:16:48 PM
> Subject: Re: [Engine-devel] operation mode
> 
> On 11/01/2012 10:57 AM, Laszlo Hornyak wrote:
> > The same question applies to HypervisorType, since only KVM is
> > supported.
> 
> I think this one is worth a bit more thinking before removing
> actually,
> but if you remove it in a single patch, easy enough to revert should
> we
> want to add something like this back (and the enum is far from all
> that
> needs to be done anyway for such a thing)

Do you plan to support hypervisors other than qemu+kvm?

> 
> >
> > ----- Original Message -----
> >> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> >> To: "engine-devel" <engine-devel at ovirt.org>
> >> Sent: Thursday, November 1, 2012 9:43:14 AM
> >> Subject: [Engine-devel] operation mode
> >>
> >> Hi,
> >>
> >> I have just run into this. Vm's have an OperationMode attribute,
> >> it
> >> can be FullVirtualized or ParaVirtualized. It appears the
> >> attribute
> >> does not play in any decision, not sent to vdsm. Can it be removed
> >> or anyone need it?
> >>
> >> thx,
> >> Laszlo
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 
> 
> 


From lhornyak at redhat.com  Thu Nov  1 21:33:30 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Thu, 1 Nov 2012 17:33:30 -0400 (EDT)
Subject: [Engine-devel] ovirt on wikipedia
In-Reply-To: <5090DBA7.6090808@redhat.com>
Message-ID: <1598090670.3255913.1351805610056.JavaMail.root@redhat.com>


----- Original Message -----
> From: "Yaniv Kaul" <ykaul at redhat.com>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, October 31, 2012 9:04:55 AM
> Subject: Re: [Engine-devel] ovirt on wikipedia
> 
> On 10/29/2012 05:40 PM, Laszlo Hornyak wrote:
> > Hi,
> >
> > http://en.wikipedia.org/wiki/OVirt
> > At the moment there are OVirt pages in english, russian and
> > hungarian.
> > Any volunteers to write czech, hebrew, german, spanish, catalan? -
> > just to mention the languages some ovirt-developers speak :-)
> >
> > Laszlo
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> While I could have translated it to Hebrew, I thought it might be
> more
> productive to beef-up the English content.
> I've added information on networking, frontends and API. Once I get
> how
> to edit with table of contents, I'll split to:
> release history
> components
> features

For the hungarian page I broke it down to 
- history
- components
 - storage
 - console protocols
- references (release notes, blog, wiki)

and indeed some content is missing there :)

Btw, is there a logo that could be uploaded? I guess the ASL license is good enough for wikipedia, but it would need some editing. The one on the stickers would be probably better.

> 
> Y.
> 
> 


From mpastern at redhat.com  Fri Nov  2 06:49:08 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Fri, 02 Nov 2012 08:49:08 +0200
Subject: [Engine-devel] ovirt-sdk 3.2.0.3 released
Message-ID: <50936CE4.5080007@redhat.com>


For more details see [1].

[1] http://wiki.ovirt.org/wiki/SDK#Change_Log

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From mpastern at redhat.com  Fri Nov  2 06:56:03 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Fri, 02 Nov 2012 08:56:03 +0200
Subject: [Engine-devel] ovirt-cli 3.2.0.6 released
In-Reply-To: <50936CE4.5080007@redhat.com>
References: <50936CE4.5080007@redhat.com>
Message-ID: <50936E83.3050105@redhat.com>

For more details see [1].

[1] http://wiki.ovirt.org/wiki/CLI#Change_Log

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From mpastern at redhat.com  Fri Nov  2 07:44:40 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Fri, 02 Nov 2012 09:44:40 +0200
Subject: [Engine-devel] ovirt-sdk at pypi
Message-ID: <509379E8.8040803@redhat.com>

>From now on latest ovirt-sdk will be available at pypi,
for more details see [1].

[1] http://wiki.ovirt.org/wiki/SDK#pypi

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From mpastern at redhat.com  Fri Nov  2 07:44:49 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Fri, 02 Nov 2012 09:44:49 +0200
Subject: [Engine-devel] ovirt-cli at pypi
Message-ID: <509379F1.5000801@redhat.com>

>From now on latest ovirt-cli will be available at pypi,
for more details see [1].

[1] http://wiki.ovirt.org/wiki/CLI#pypi

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From shaohef at linux.vnet.ibm.com  Fri Nov  2 08:01:00 2012
From: shaohef at linux.vnet.ibm.com (Sheldon)
Date: Fri, 02 Nov 2012 16:01:00 +0800
Subject: [Engine-devel] [help]how to get the CA certificate when
 uploader ISO
In-Reply-To: <50927E93.7060307@redhat.com>
References: <508FA5CB.8040504@linux.vnet.ibm.com> <508FA70D.1010802@redhat.com>
	<508FB647.9020002@linux.vnet.ibm.com> <508FC373.8080901@redhat.com>
	<5090B9D7.8050302@linux.vnet.ibm.com> <50912982.5000606@redhat.com>
	<50923FA5.3080903@linux.vnet.ibm.com> <50927E93.7060307@redhat.com>
Message-ID: <50937DBC.3040109@linux.vnet.ibm.com>

On 11/01/2012 09:52 PM, Keith Robertson wrote:
> On 11/01/2012 05:23 AM, Sheldon wrote:
>> On 10/31/2012 09:37 PM, Keith Robertson wrote:
>>> On 10/31/2012 01:40 AM, Sheldon wrote:
>>>> I make a domain name "ISO", Domain type is ISO, Storage Type is 
>>>> NFS, Format is V1
>>>>
>>>> $ sudo engine-iso-uploader -v --iso-domain=ISO upload 
>>>> Fedora-17-x86_64-DVD.iso
>>>> [sudo] password for ovirt:
>>>> Please provide the REST API username for oVirt Engine (CTRL+D to 
>>>> abort): admin at internal
>>>> Please provide the REST API password for the admin at internal oVirt 
>>>> Engine user (CTRL+D to abort):
>>>> ERROR: Problem connecting to the REST API.  Is the service 
>>>> available and does the CA certificate exist?
>>>> ERROR: 'NoneType' object is not iterable
>>>> INFO: Use the -h option to see usage. 
>>>
>>> Just to be clear the error in [1] is simply a symptom.  It isn't the 
>>> root cause.  The root cause is quite possibly the CA certificate.
>>>
>>> I have created a patch in [2] that I'd appreciate if you could test 
>>> as it will provide more debugging information about why the API 
>>> creation is failing.  Simply follow the steps in [3]
>>>
>>> Cheers,
>>> Keith
>>>
>>> [1] ERROR: 'NoneType' object is not iterable
>>> [2] http://gerrit.ovirt.org/8954
>>> [3]
>>> Step 1: git clone http://gerrit.ovirt.org/p/ovirt-iso-uploader.git
>>> Step 2: Cherry pick the patch...
>>> git fetch git://gerrit.ovirt.org/ovirt-iso-uploader 
>>> refs/changes/54/8954/2 && git cherry-pick FETCH_HEAD
>>> Step 3: export APP_VERSION=3.0.0; export APP_RELEASE=1
>>> Step 4: cd ovirt-iso-uploader
>>> Step 5: make
>>> Step 6: Notice the ovirt-iso-uploader*.rpm location in the STDOUT
>>> Step 7: yum install /path/to/ovirt-iso-uploader*.rpm
>>
>> still error. but different debug info.
> Yes.  The patch adds additional debug info.
>>
>> $ sudo engine-iso-uploader -v --iso-domain=ISO upload 
>> RHEL6.3-20120531.0-Server-x86_64-DVD1.iso
>> Please provide the REST API username for oVirt Engine (CTRL+D to 
>> abort): admin at internal
>> Please provide the REST API password for the admin at internal oVirt 
>> Engine user (CTRL+D to abort):
>> DEBUG: url(https://localhost:443/api)
>> DEBUG: user(admin at internal)
>> DEBUG: ca(/etc/pki/ovirt-engine/ca.pem)
>> DEBUG: insecure(False)
>> ERROR: Problem connecting to the REST API.  Is the service available 
>> and does the CA certificate exist? Error: [ERROR]::oVirt API 
>> connection failure, 
> Now we're getting to the good stuff as you can see that you are 
> getting a connection refused.  Questions for you:
>
> 1) Are you *certain* that 'https://localhost:443/api' is accessible 
> from the local system, that it is the address of your oVirt engine, 
> and is not being blocked by a FW?  Easy test on the local box point 
> your browser at that url.
I have edited the tls port, it is not 443.  It is 4301.
I can access https://localhost:4301/api'
>
> 2) Are you certain that the CA is valid?  To verify this you will need 
> to issue a 'curl' statement and supply the CA.  Example:
>  curl -v -k -u $USER:$PASS --cacert /etc/pki/ovirt-engine/ca.pem -X 
> GET -H 'Accept: application/xml'  'https://localhost:443/api/api/vms
also:
$ curl -v -k -u admin at internal:letmein! --cacert 
/etc/pki/ovirt-engine/ca.pem  -X GET -H 'Accept: application/xml' 
'https://localhost:4301/api/vms'
is ok

and I designate the tls port, now it can work.
$ sudo engine-iso-uploader -rlocalhost:4301 -v --iso-domain=ISO upload 
Fedora-17-x86_64-DVD.iso

Thank you.
>> [Errno 111] Connection refused
>> DEBUG: Unable to get host and path information from API.
>>
>>
>> -- 
>> Sheldon Feng(???)<shaohef at linux.vnet.ibm.com>
>> IBM Linux Technology Center
>


-- 
Sheldon Feng(???)<shaohef at linux.vnet.ibm.com>
IBM Linux Technology Center

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121102/c596cf7b/attachment.html>

From asegurap at redhat.com  Fri Nov  2 09:27:50 2012
From: asegurap at redhat.com (Antoni Segura Puimedon)
Date: Fri, 2 Nov 2012 05:27:50 -0400 (EDT)
Subject: [Engine-devel] ovirt-sdk at pypi
In-Reply-To: <509379E8.8040803@redhat.com>
Message-ID: <589674525.6895023.1351848470859.JavaMail.root@redhat.com>

Great Michael!

I will update the wiki part I did the other day for different
distros.

----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Cc: users at ovirt.org
> Sent: Friday, November 2, 2012 8:44:40 AM
> Subject: [Engine-devel] ovirt-sdk at pypi
> 
> From now on latest ovirt-sdk will be available at pypi,
> for more details see [1].
> 
> [1] http://wiki.ovirt.org/wiki/SDK#pypi
> 
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From iheim at redhat.com  Fri Nov  2 09:52:44 2012
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 02 Nov 2012 11:52:44 +0200
Subject: [Engine-devel] [help]how to get the CA certificate when
 uploader ISO
In-Reply-To: <50937DBC.3040109@linux.vnet.ibm.com>
References: <508FA5CB.8040504@linux.vnet.ibm.com> <508FA70D.1010802@redhat.com>
	<508FB647.9020002@linux.vnet.ibm.com> <508FC373.8080901@redhat.com>
	<5090B9D7.8050302@linux.vnet.ibm.com> <50912982.5000606@redhat.com>
	<50923FA5.3080903@linux.vnet.ibm.com> <50927E93.7060307@redhat.com>
	<50937DBC.3040109@linux.vnet.ibm.com>
Message-ID: <509397EC.9000209@redhat.com>

On 11/02/2012 10:01 AM, Sheldon wrote:
> On 11/01/2012 09:52 PM, Keith Robertson wrote:
>> On 11/01/2012 05:23 AM, Sheldon wrote:
>>> On 10/31/2012 09:37 PM, Keith Robertson wrote:
>>>> On 10/31/2012 01:40 AM, Sheldon wrote:
>>>>> I make a domain name "ISO", Domain type is ISO, Storage Type is
>>>>> NFS, Format is V1
>>>>>
>>>>> $ sudo engine-iso-uploader -v --iso-domain=ISO upload
>>>>> Fedora-17-x86_64-DVD.iso
>>>>> [sudo] password for ovirt:
>>>>> Please provide the REST API username for oVirt Engine (CTRL+D to
>>>>> abort): admin at internal
>>>>> Please provide the REST API password for the admin at internal oVirt
>>>>> Engine user (CTRL+D to abort):
>>>>> ERROR: Problem connecting to the REST API.  Is the service
>>>>> available and does the CA certificate exist?
>>>>> ERROR: 'NoneType' object is not iterable
>>>>> INFO: Use the -h option to see usage.
>>>>
>>>> Just to be clear the error in [1] is simply a symptom.  It isn't the
>>>> root cause.  The root cause is quite possibly the CA certificate.
>>>>
>>>> I have created a patch in [2] that I'd appreciate if you could test
>>>> as it will provide more debugging information about why the API
>>>> creation is failing.  Simply follow the steps in [3]
>>>>
>>>> Cheers,
>>>> Keith
>>>>
>>>> [1] ERROR: 'NoneType' object is not iterable
>>>> [2] http://gerrit.ovirt.org/8954
>>>> [3]
>>>> Step 1: git clone http://gerrit.ovirt.org/p/ovirt-iso-uploader.git
>>>> Step 2: Cherry pick the patch...
>>>> git fetch git://gerrit.ovirt.org/ovirt-iso-uploader
>>>> refs/changes/54/8954/2 && git cherry-pick FETCH_HEAD
>>>> Step 3: export APP_VERSION=3.0.0; export APP_RELEASE=1
>>>> Step 4: cd ovirt-iso-uploader
>>>> Step 5: make
>>>> Step 6: Notice the ovirt-iso-uploader*.rpm location in the STDOUT
>>>> Step 7: yum install /path/to/ovirt-iso-uploader*.rpm
>>>
>>> still error. but different debug info.
>> Yes.  The patch adds additional debug info.
>>>
>>> $ sudo engine-iso-uploader -v --iso-domain=ISO upload
>>> RHEL6.3-20120531.0-Server-x86_64-DVD1.iso
>>> Please provide the REST API username for oVirt Engine (CTRL+D to
>>> abort): admin at internal
>>> Please provide the REST API password for the admin at internal oVirt
>>> Engine user (CTRL+D to abort):
>>> DEBUG: url(https://localhost:443/api)
>>> DEBUG: user(admin at internal)
>>> DEBUG: ca(/etc/pki/ovirt-engine/ca.pem)
>>> DEBUG: insecure(False)
>>> ERROR: Problem connecting to the REST API.  Is the service available
>>> and does the CA certificate exist? Error: [ERROR]::oVirt API
>>> connection failure,
>> Now we're getting to the good stuff as you can see that you are
>> getting a connection refused.  Questions for you:
>>
>> 1) Are you *certain* that 'https://localhost:443/api' is accessible
>> from the local system, that it is the address of your oVirt engine,
>> and is not being blocked by a FW?  Easy test on the local box point
>> your browser at that url.
> I have edited the tls port, it is not 443.  It is 4301.
> I can access https://localhost:4301/api'
>>
>> 2) Are you certain that the CA is valid?  To verify this you will need
>> to issue a 'curl' statement and supply the CA.  Example:
>>  curl -v -k -u $USER:$PASS --cacert /etc/pki/ovirt-engine/ca.pem -X
>> GET -H 'Accept: application/xml'  'https://localhost:443/api/api/vms
> also:
> $ curl -v -k -u admin at internal:letmein! --cacert
> /etc/pki/ovirt-engine/ca.pem  -X GET -H 'Accept: application/xml'
> 'https://localhost:4301/api/vms'
> is ok
>
> and I designate the tls port, now it can work.
> $ sudo engine-iso-uploader -rlocalhost:4301 -v --iso-domain=ISO upload
> Fedora-17-x86_64-DVD.iso
>
> Thank you.

not sure how common are non-default ports.
i guess on a local run, the tool can get these parameters from the 
engine config, but that's won't work for a remote run.




From lhornyak at redhat.com  Fri Nov  2 10:18:41 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Fri, 2 Nov 2012 06:18:41 -0400 (EDT)
Subject: [Engine-devel] eclipse juno vs gwt
In-Reply-To: <1990229886.3463319.1351851256712.JavaMail.root@redhat.com>
Message-ID: <1160690454.3463590.1351851521226.JavaMail.root@redhat.com>

Hi,

Just noticed that eclipse juno is adding @Ovewrride annotations to methods that are actually overriding something, like in many cases clone and equals methods in some of the classes. This is fine for the java compiler, but it in some cases the GWT compiler is not going to accept this annotation. E.g. if the return type is different than the method with same name in the superclass.

Juno is doing this by default without asking, when saving the file. So be extra-careful when editing java classes if they are shared with GWT

Laszlo


From kroberts at redhat.com  Fri Nov  2 11:02:28 2012
From: kroberts at redhat.com (Keith Robertson)
Date: Fri, 02 Nov 2012 07:02:28 -0400
Subject: [Engine-devel] [help]how to get the CA certificate when
 uploader ISO
In-Reply-To: <50937DBC.3040109@linux.vnet.ibm.com>
References: <508FA5CB.8040504@linux.vnet.ibm.com> <508FA70D.1010802@redhat.com>
	<508FB647.9020002@linux.vnet.ibm.com> <508FC373.8080901@redhat.com>
	<5090B9D7.8050302@linux.vnet.ibm.com> <50912982.5000606@redhat.com>
	<50923FA5.3080903@linux.vnet.ibm.com> <50927E93.7060307@redhat.com>
	<50937DBC.3040109@linux.vnet.ibm.com>
Message-ID: <5093A844.1040005@redhat.com>

On 11/02/2012 04:01 AM, Sheldon wrote:
> On 11/01/2012 09:52 PM, Keith Robertson wrote:
>> On 11/01/2012 05:23 AM, Sheldon wrote:
>>> On 10/31/2012 09:37 PM, Keith Robertson wrote:
>>>> On 10/31/2012 01:40 AM, Sheldon wrote:
>>>>> I make a domain name "ISO", Domain type is ISO, Storage Type is 
>>>>> NFS, Format is V1
>>>>>
>>>>> $ sudo engine-iso-uploader -v --iso-domain=ISO upload 
>>>>> Fedora-17-x86_64-DVD.iso
>>>>> [sudo] password for ovirt:
>>>>> Please provide the REST API username for oVirt Engine (CTRL+D to 
>>>>> abort): admin at internal
>>>>> Please provide the REST API password for the admin at internal oVirt 
>>>>> Engine user (CTRL+D to abort):
>>>>> ERROR: Problem connecting to the REST API.  Is the service 
>>>>> available and does the CA certificate exist?
>>>>> ERROR: 'NoneType' object is not iterable
>>>>> INFO: Use the -h option to see usage. 
>>>>
>>>> Just to be clear the error in [1] is simply a symptom.  It isn't 
>>>> the root cause.  The root cause is quite possibly the CA certificate.
>>>>
>>>> I have created a patch in [2] that I'd appreciate if you could test 
>>>> as it will provide more debugging information about why the API 
>>>> creation is failing.  Simply follow the steps in [3]
>>>>
>>>> Cheers,
>>>> Keith
>>>>
>>>> [1] ERROR: 'NoneType' object is not iterable
>>>> [2] http://gerrit.ovirt.org/8954
>>>> [3]
>>>> Step 1: git clone http://gerrit.ovirt.org/p/ovirt-iso-uploader.git
>>>> Step 2: Cherry pick the patch...
>>>> git fetch git://gerrit.ovirt.org/ovirt-iso-uploader 
>>>> refs/changes/54/8954/2 && git cherry-pick FETCH_HEAD
>>>> Step 3: export APP_VERSION=3.0.0; export APP_RELEASE=1
>>>> Step 4: cd ovirt-iso-uploader
>>>> Step 5: make
>>>> Step 6: Notice the ovirt-iso-uploader*.rpm location in the STDOUT
>>>> Step 7: yum install /path/to/ovirt-iso-uploader*.rpm
>>>
>>> still error. but different debug info.
>> Yes.  The patch adds additional debug info.
>>>
>>> $ sudo engine-iso-uploader -v --iso-domain=ISO upload 
>>> RHEL6.3-20120531.0-Server-x86_64-DVD1.iso
>>> Please provide the REST API username for oVirt Engine (CTRL+D to 
>>> abort): admin at internal
>>> Please provide the REST API password for the admin at internal oVirt 
>>> Engine user (CTRL+D to abort):
>>> DEBUG: url(https://localhost:443/api)
>>> DEBUG: user(admin at internal)
>>> DEBUG: ca(/etc/pki/ovirt-engine/ca.pem)
>>> DEBUG: insecure(False)
>>> ERROR: Problem connecting to the REST API.  Is the service available 
>>> and does the CA certificate exist? Error: [ERROR]::oVirt API 
>>> connection failure, 
>> Now we're getting to the good stuff as you can see that you are 
>> getting a connection refused.  Questions for you:
>>
>> 1) Are you *certain* that 'https://localhost:443/api' is accessible 
>> from the local system, that it is the address of your oVirt engine, 
>> and is not being blocked by a FW?  Easy test on the local box point 
>> your browser at that url.
> I have edited the tls port, it is not 443.  It is 4301.
OK, here *here* is the problem. The ISO Uploader has been configured to 
use 'localhost:443' while you have customized it to 'localhost:4301'.  
You need to edit /etc/ovirt-engine/logcollector.conf and set the 
variable that tells the uploader which host/port combination to use.

Note: The other 2 tools will have similar issues (ie. Log Collector and 
Image Uploader) and, they each have conf files in /etc/ovirt-engine.

> I can access https://localhost:4301/api'
>>
>> 2) Are you certain that the CA is valid?  To verify this you will 
>> need to issue a 'curl' statement and supply the CA. Example:
>>  curl -v -k -u $USER:$PASS --cacert /etc/pki/ovirt-engine/ca.pem  -X 
>> GET -H 'Accept: application/xml'  'https://localhost:443/api/api/vms
> also:
> $ curl -v -k -u admin at internal:letmein! --cacert 
> /etc/pki/ovirt-engine/ca.pem  -X GET -H 'Accept: application/xml' 
> 'https://localhost:4301/api/vms'
> is ok
>
> and I designate the tls port, now it can work.
> $ sudo engine-iso-uploader -rlocalhost:4301 -v --iso-domain=ISO upload 
> Fedora-17-x86_64-DVD.iso
>
> Thank you.
>>> [Errno 111] Connection refused
>>> DEBUG: Unable to get host and path information from API.
>>>
>>>
>>> -- 
>>> Sheldon Feng(???)<shaohef at linux.vnet.ibm.com>
>>> IBM Linux Technology Center
>>
>
>
> -- 
> Sheldon Feng(???)<shaohef at linux.vnet.ibm.com>
> IBM Linux Technology Center

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121102/993d79f4/attachment.html>

From jhernand at redhat.com  Fri Nov  2 13:42:10 2012
From: jhernand at redhat.com (Juan Hernandez)
Date: Fri, 02 Nov 2012 14:42:10 +0100
Subject: [Engine-devel] Time to bump version to 3.2.0?
Message-ID: <5093CDB2.8010208@redhat.com>

I think that it is time to bump the version number in the POMs and in
the RPM spec to 3.2.0:

http://gerrit.ovirt.org/8993

In general I think that we should do this immediately after each
release, bumping to the next expected version number.

Thoughts?
-- 
Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3?D, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L.


From lhornyak at redhat.com  Fri Nov  2 13:54:53 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Fri, 2 Nov 2012 09:54:53 -0400 (EDT)
Subject: [Engine-devel] Time to bump version to 3.2.0?
In-Reply-To: <5093CDB2.8010208@redhat.com>
Message-ID: <363958346.3631462.1351864493355.JavaMail.root@redhat.com>

Hi Juan,

I think it is time to correct the version, but I was always wondering why we do not use the -SNAPSHOT versioning the maven developers designed? I think once we start pushing artifacts to public repositories, it will be a pain to have released version in our pom files. I think frontend and backend plugin developers will need this.

http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-syntax.html

Laszlo

----- Original Message -----
> From: "Juan Hernandez" <jhernand at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Friday, November 2, 2012 2:42:10 PM
> Subject: [Engine-devel] Time to bump version to 3.2.0?
> 
> I think that it is time to bump the version number in the POMs and in
> the RPM spec to 3.2.0:
> 
> http://gerrit.ovirt.org/8993
> 
> In general I think that we should do this immediately after each
> release, bumping to the next expected version number.
> 
> Thoughts?
> --
> 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.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From jhernand at redhat.com  Fri Nov  2 14:47:09 2012
From: jhernand at redhat.com (Juan Hernandez)
Date: Fri, 02 Nov 2012 15:47:09 +0100
Subject: [Engine-devel] Time to bump version to 3.2.0?
In-Reply-To: <363958346.3631462.1351864493355.JavaMail.root@redhat.com>
References: <363958346.3631462.1351864493355.JavaMail.root@redhat.com>
Message-ID: <5093DCED.4040600@redhat.com>

On 11/02/2012 02:54 PM, Laszlo Hornyak wrote:
> Hi Juan,
> 
> I think it is time to correct the version, but I was always wondering why we do not use the -SNAPSHOT versioning the maven developers designed? I think once we start pushing artifacts to public repositories, it will be a pain to have released version in our pom files. I think frontend and backend plugin developers will need this.
> 
> http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-syntax.html

Well, I don't have anything against that, but it will break some of the
things that we currently do in the Makefile. We deploy artifacts to a
local temporary directory during the build process, and we expect them
to be named "whatever-3.2.0.jar". If we use the SNAPSHOT capability then
they will be named "whatever-3.2.0-20121102.143802-1.jar" and that
breaks our build. I prefer not to touch the Makefile at this point, but
I am open to fix it and use SNAPSHOT in the future.

> ----- Original Message -----
>> From: "Juan Hernandez" <jhernand at redhat.com>
>> To: engine-devel at ovirt.org
>> Sent: Friday, November 2, 2012 2:42:10 PM
>> Subject: [Engine-devel] Time to bump version to 3.2.0?
>>
>> I think that it is time to bump the version number in the POMs and in
>> the RPM spec to 3.2.0:
>>
>> http://gerrit.ovirt.org/8993
>>
>> In general I think that we should do this immediately after each
>> release, bumping to the next expected version number.
>>
>> Thoughts?
>> --
>> 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.
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


-- 
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 Christopher.Morrissey at netapp.com  Fri Nov  2 22:40:59 2012
From: Christopher.Morrissey at netapp.com (Morrissey, Christopher)
Date: Fri, 2 Nov 2012 22:40:59 +0000
Subject: [Engine-devel] eclipse juno vs gwt
In-Reply-To: <1160690454.3463590.1351851521226.JavaMail.root@redhat.com>
References: <1990229886.3463319.1351851256712.JavaMail.root@redhat.com>
	<1160690454.3463590.1351851521226.JavaMail.root@redhat.com>
Message-ID: <D290AD8432118048947689BA3AE8A9B3EA3022@SACEXCMBX04-PRD.hq.netapp.com>

Hi Laszlo,

I have several methods that define the @Override annotation and return something different from the super class. I haven't had any problems compiling them in GWT. The return value does extend from the return value of the super class, although this is a requirement in Java as well so I'm not sure where the difference is.

-Chris


-----Original Message-----
From: engine-devel-bounces at ovirt.org [mailto:engine-devel-bounces at ovirt.org] On Behalf Of Laszlo Hornyak
Sent: Friday, November 02, 2012 6:19 AM
To: engine-devel
Subject: [Engine-devel] eclipse juno vs gwt

Hi,

Just noticed that eclipse juno is adding @Ovewrride annotations to methods that are actually overriding something, like in many cases clone and equals methods in some of the classes. This is fine for the java compiler, but it in some cases the GWT compiler is not going to accept this annotation. E.g. if the return type is different than the method with same name in the superclass.

Juno is doing this by default without asking, when saving the file. So be extra-careful when editing java classes if they are shared with GWT

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


From Christopher.Morrissey at netapp.com  Fri Nov  2 22:43:23 2012
From: Christopher.Morrissey at netapp.com (Morrissey, Christopher)
Date: Fri, 2 Nov 2012 22:43:23 +0000
Subject: [Engine-devel] eclipse juno vs gwt
References: <1990229886.3463319.1351851256712.JavaMail.root@redhat.com>
	<1160690454.3463590.1351851521226.JavaMail.root@redhat.com> 
Message-ID: <D290AD8432118048947689BA3AE8A9B3EA3037@SACEXCMBX04-PRD.hq.netapp.com>

Sorry to follow up my own question, but can you give some specific cases where this would be a problem? Thanks!

-Chris


-----Original Message-----
From: Morrissey, Christopher 
Sent: Friday, November 02, 2012 6:41 PM
To: 'Laszlo Hornyak'; engine-devel
Subject: RE: [Engine-devel] eclipse juno vs gwt

Hi Laszlo,

I have several methods that define the @Override annotation and return something different from the super class. I haven't had any problems compiling them in GWT. The return value does extend from the return value of the super class, although this is a requirement in Java as well so I'm not sure where the difference is.

-Chris


-----Original Message-----
From: engine-devel-bounces at ovirt.org [mailto:engine-devel-bounces at ovirt.org] On Behalf Of Laszlo Hornyak
Sent: Friday, November 02, 2012 6:19 AM
To: engine-devel
Subject: [Engine-devel] eclipse juno vs gwt

Hi,

Just noticed that eclipse juno is adding @Ovewrride annotations to methods that are actually overriding something, like in many cases clone and equals methods in some of the classes. This is fine for the java compiler, but it in some cases the GWT compiler is not going to accept this annotation. E.g. if the return type is different than the method with same name in the superclass.

Juno is doing this by default without asking, when saving the file. So be extra-careful when editing java classes if they are shared with GWT

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


From msalem at redhat.com  Sun Nov  4 07:01:04 2012
From: msalem at redhat.com (Muli Salem)
Date: Sun, 4 Nov 2012 02:01:04 -0500 (EST)
Subject: [Engine-devel] ovirt on wikipedia
In-Reply-To: <165147602.449665.1351525228071.JavaMail.root@redhat.com>
Message-ID: <983612.80.1352012082301.JavaMail.msalem@dhcp-1-23.tlv.redhat.com>

Hi all,

Will take care of the Hebrew part.
Although I would love to help more, I still need to work on my Spanish :)

Muli

----- Original Message -----
From: "Laszlo Hornyak" <lhornyak at redhat.com>
To: "engine-devel" <engine-devel at ovirt.org>
Sent: Monday, 29 October, 2012 5:40:28 PM
Subject: [Engine-devel] ovirt on wikipedia

Hi,

http://en.wikipedia.org/wiki/OVirt
At the moment there are OVirt pages in english, russian and hungarian.
Any volunteers to write czech, hebrew, german, spanish, catalan? - just to mention the languages some ovirt-developers speak :-)

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


From mpastern at redhat.com  Sun Nov  4 08:12:05 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 04 Nov 2012 10:12:05 +0200
Subject: [Engine-devel] ovirt-sdk at pypi
In-Reply-To: <2001787234.6895372.1351848581473.JavaMail.root@redhat.com>
References: <2001787234.6895372.1351848581473.JavaMail.root@redhat.com>
Message-ID: <50962355.6060503@redhat.com>



Hi Toni,

do:

1. nics = api.hosts.get(name=xxx).nics
2. nics_arr = nics.list()
   (change nics_arr as you need, according to __doc__, also see [1])
3. my_nics = params.HostNics(host_nic=[nics_arr[0],nics_arr[1],...])
   or
   my_nics = params.HostNics(host_nic=nics_arr)
4. nics.setupnetworks(action=params.Action(host_nics=my_nics))

[1] http://wiki.ovirt.org/wiki/SDK#Development_tips

On 11/02/2012 11:29 AM, Antoni Segura Puimedon wrote:
> Hi Michael,
> 
> One question though, I would like to use the setupNetworks command
> and the docstring says that I should use params (ovirtsdk.xml.params)
> and inside those ivars. I don't know how or were these ivars are to
> be used. Could you point me where I should look at or, alternatively,
> give me an example?
> 
> Thanks a lot for this nice api.
> 
> Best,
> 
> Toni
> 
> ----- Original Message -----
>> From: "Michael Pasternak" <mpastern at redhat.com>
>> To: "engine-devel" <engine-devel at ovirt.org>
>> Cc: users at ovirt.org
>> Sent: Friday, November 2, 2012 8:44:40 AM
>> Subject: [Engine-devel] ovirt-sdk at pypi
>>
>> From now on latest ovirt-sdk will be available at pypi,
>> for more details see [1].
>>
>> [1] http://wiki.ovirt.org/wiki/SDK#pypi
>>
>> --
>>
>> Michael Pasternak
>> RedHat, ENG-Virtualization R&D
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From asegurap at redhat.com  Sun Nov  4 09:50:13 2012
From: asegurap at redhat.com (Antoni Segura Puimedon)
Date: Sun, 4 Nov 2012 04:50:13 -0500 (EST)
Subject: [Engine-devel] ovirt-sdk at pypi
In-Reply-To: <50962355.6060503@redhat.com>
Message-ID: <53206607.7070405.1352022613524.JavaMail.root@redhat.com>

Thanks!

----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "Antoni Segura Puimedon" <asegurap at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, November 4, 2012 9:12:05 AM
> Subject: Re: [Engine-devel] ovirt-sdk at pypi
> 
> 
> 
> Hi Toni,
> 
> do:
> 
> 1. nics = api.hosts.get(name=xxx).nics
> 2. nics_arr = nics.list()
>    (change nics_arr as you need, according to __doc__, also see [1])
> 3. my_nics = params.HostNics(host_nic=[nics_arr[0],nics_arr[1],...])
>    or
>    my_nics = params.HostNics(host_nic=nics_arr)
> 4. nics.setupnetworks(action=params.Action(host_nics=my_nics))
> 
> [1] http://wiki.ovirt.org/wiki/SDK#Development_tips
> 
> On 11/02/2012 11:29 AM, Antoni Segura Puimedon wrote:
> > Hi Michael,
> > 
> > One question though, I would like to use the setupNetworks command
> > and the docstring says that I should use params
> > (ovirtsdk.xml.params)
> > and inside those ivars. I don't know how or were these ivars are to
> > be used. Could you point me where I should look at or,
> > alternatively,
> > give me an example?
> > 
> > Thanks a lot for this nice api.
> > 
> > Best,
> > 
> > Toni
> > 
> > ----- Original Message -----
> >> From: "Michael Pasternak" <mpastern at redhat.com>
> >> To: "engine-devel" <engine-devel at ovirt.org>
> >> Cc: users at ovirt.org
> >> Sent: Friday, November 2, 2012 8:44:40 AM
> >> Subject: [Engine-devel] ovirt-sdk at pypi
> >>
> >> From now on latest ovirt-sdk will be available at pypi,
> >> for more details see [1].
> >>
> >> [1] http://wiki.ovirt.org/wiki/SDK#pypi
> >>
> >> --
> >>
> >> Michael Pasternak
> >> RedHat, ENG-Virtualization R&D
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> 
> 
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
> 


From msalem at redhat.com  Sun Nov  4 17:17:20 2012
From: msalem at redhat.com (Muli Salem)
Date: Sun, 4 Nov 2012 12:17:20 -0500 (EST)
Subject: [Engine-devel] ovirt on wikipedia
In-Reply-To: <983612.80.1352012082301.JavaMail.msalem@dhcp-1-23.tlv.redhat.com>
Message-ID: <3700803.163.1352049055445.JavaMail.msalem@dhcp-1-23.tlv.redhat.com>

Hi,

The Hebrew wiki for oVirt can be found in:
http://he.wikipedia.org/wiki/OVirt

You are more than welcome to make changes/add stuff.

Cheers,
Muli

----- Original Message -----
From: "Muli Salem" <msalem at redhat.com>
To: "Laszlo Hornyak" <lhornyak at redhat.com>
Cc: "engine-devel" <engine-devel at ovirt.org>
Sent: Sunday, 4 November, 2012 9:01:04 AM
Subject: Re: [Engine-devel] ovirt on wikipedia

Hi all,

Will take care of the Hebrew part.
Although I would love to help more, I still need to work on my Spanish :)

Muli

----- Original Message -----
From: "Laszlo Hornyak" <lhornyak at redhat.com>
To: "engine-devel" <engine-devel at ovirt.org>
Sent: Monday, 29 October, 2012 5:40:28 PM
Subject: [Engine-devel] ovirt on wikipedia

Hi,

http://en.wikipedia.org/wiki/OVirt
At the moment there are OVirt pages in english, russian and hungarian.
Any volunteers to write czech, hebrew, german, spanish, catalan? - just to mention the languages some ovirt-developers speak :-)

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


From mpastern at redhat.com  Mon Nov  5 05:51:49 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Mon, 05 Nov 2012 07:51:49 +0200
Subject: [Engine-devel] [Users] Related to python script for Attach Cd
	(.iso) to a vm
In-Reply-To: <CAAtRV8PS_adCe_AvBtUmSJ+6g1qiZMNxj6Ex5WQAxQ=yG+5+Pg@mail.gmail.com>
References: <CAAtRV8PS_adCe_AvBtUmSJ+6g1qiZMNxj6Ex5WQAxQ=yG+5+Pg@mail.gmail.com>
Message-ID: <509753F5.2080305@redhat.com>


Hi Romil,

In general you can use api guide [1] for this, anyway here is example:

1. create vm
============
...

2. insert cdrom
===============

vm = api.vms.get(name="myvm")
cdrom = vm.cdroms.get(id="00000000-0000-0000-0000-000000000000")
isofile = params.File(id="myiso.iso")
cdrom.set_file(isofile)
cdrom.update()

3. change boot order (to boot from cdrom and then from hd)
==========================================================

os=params.OperatingSystem(boot=[params.Boot(dev='cdrom'), params.Boot(dev='hd')], ...)
api.vms.add(params.VM(name='myvm2',
                      os=os,
                      cluster=api.clusters.get('mycluster'),
                      template=api.templates.get('mytemplate')))

4. run vm
=========
...

[1] https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Virtualization/3.1-Beta/html-single/Developer_Guide/index.html#sect-REST_API_Guide-Example-Attach_CDROM


On 11/02/2012 09:56 AM, Romil Gupta wrote:
> 
> Hello ,
> 
> *I want to  write a script to attach a  '.iso' image to a vm *
> so ,can you please help me or tell me some api so that i can continue my work !!!
> I have some '.iso ' file in my storage .
> 
> script       *rhevm_test.py*
> 
> from ovirtsdk.api import API
> from ovirtsdk.xml import params
> import time
> 
> rhevm_uri = "https://rhevm301.xxx.xx.com:8443/api"
> rhevm_username = "admin at rhevm301.xxx.xx.com <mailto:admin at rhevm301.xxx.xx.com>"
> rhevm_password = "iso*help"
> 
> api = API(url=rhevm_uri, username=rhevm_username, password=rhevm_password)
> print "Connected to RHEVM Successful"
> 
> MB = 1024*1024
> GB = 1024*MB
> VM_NAME = 'test_vm'
> DESCRIP = 'testing vm'
> CLUSTER_NAME =  'Default'
> STORAGE_NAME =  'rhevmVMdata'
> 
> domain_name= 'rhevmiso'  
> domain_type = 'ISO'
> 
> 
> try:
>     api.vms.add(params.VM(name=VM_NAME,description=DESCRIP, memory=2*GB,cluster=api.clusters.get(CLUSTER_NAME), template=api.templates.get('Blank') , cdroms =
> 'CentOS-6.2-x86_64-LiveCD.iso '))
>     
>     print 'VM created'
> 
>     api.vms.get(VM_NAME).nics.add(params.NIC(name='nic1', network=params.Network(name='rhevm'), interface='Red Hat VirtIO'))
>     print 'NIC added to VM'
> 
>    
> api.vms.get(VM_NAME).disks.add(params.Disk(storage_domains=params.StorageDomains(storage_domain=[api.storagedomains.get(STORAGE_NAME)]),size=512*MB,status=None,interface='VirtIO',format='Preallocated',sparse=True,bootable=True))
> 
>     print 'Disk added to VM'
>     print 'Waiting for VM to reach Down status'
>     while api.vms.get(VM_NAME).status.state != 'down':
>         time.sleep(1)
> except Exception as e:
>     print 'Failed to create VM with disk and NIC\n%s' % str(e)
> 
> time.sleep(10)
> 
> try:
>     if api.vms.get(VM_NAME).status.state != 'up':
>         print 'Starting VM'
>         api.vms.get(VM_NAME).start()
>         print 'Waiting for VM to reach Up status'
>         while api.vms.get(VM_NAME).status.state != 'up':
>             time.sleep(1)
>     else:
>         print 'VM already up'
> except Exception as e:
>      print 'Failed to Start VM:\n%s' % str(e)
> 
>  
> and got some exceptions
> 
> Connected to RHEVM Successful
> Failed to create VM with disk and NIC
> 'str' object has no attribute 'export'
> Failed to Start VM:
> 'NoneType' object has no attribute 'status'
> 
> if i remove this cdroms = 'CentOS-6.2-x86_64-LiveCD.iso '  the code will works fine and it will create a vm with blank template w/o any '.iso' attached !!
> 
> 
> *
> *
> *
> *
> *
> *
> *
> *
> *With Regards,*
> *Romil*
> 
> 
> 
> 
> 
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From mpastern at redhat.com  Mon Nov  5 05:55:28 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Mon, 05 Nov 2012 07:55:28 +0200
Subject: [Engine-devel] [Users] Related to python script for Attach Cd
	(.iso) to a vm
In-Reply-To: <509753F5.2080305@redhat.com>
References: <CAAtRV8PS_adCe_AvBtUmSJ+6g1qiZMNxj6Ex5WQAxQ=yG+5+Pg@mail.gmail.com>
	<509753F5.2080305@redhat.com>
Message-ID: <509754D0.7050900@redhat.com>

On 11/05/2012 07:51 AM, Michael Pasternak wrote:
> Hi Romil,
> 
> In general you can use api guide [1] for this, anyway here is example:
> 
> 1. create vm
> ============
> ...
> 
> 2. insert cdrom
> ===============
> 
> vm = api.vms.get(name="myvm")
> cdrom = vm.cdroms.get(id="00000000-0000-0000-0000-000000000000")
> isofile = params.File(id="myiso.iso")
> cdrom.set_file(isofile)
> cdrom.update()
> 
> 3. change boot order (to boot from cdrom and then from hd)
> ==========================================================
> 
> os=params.OperatingSystem(boot=[params.Boot(dev='cdrom'), params.Boot(dev='hd')], ...)
> api.vms.add(params.VM(name='myvm2',
>                       os=os,
>                       cluster=api.clusters.get('mycluster'),
>                       template=api.templates.get('mytemplate')))

use this ^ example for #1, or update boot order using same semantics
on existent vm.

> 
> 4. run vm
> =========
> ...
> 
> [1] https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Virtualization/3.1-Beta/html-single/Developer_Guide/index.html#sect-REST_API_Guide-Example-Attach_CDROM


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From mpastern at redhat.com  Mon Nov  5 08:34:15 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Mon, 05 Nov 2012 10:34:15 +0200
Subject: [Engine-devel] [Users] Related to python script for Attach Cd
	(.iso) to a vm
In-Reply-To: <CAAtRV8M00aLFkAV=0z_5S3wuADbpn2OqBGt2ReurpFa1VYrX3A@mail.gmail.com>
References: <CAAtRV8PS_adCe_AvBtUmSJ+6g1qiZMNxj6Ex5WQAxQ=yG+5+Pg@mail.gmail.com>	<509753F5.2080305@redhat.com>	<509754D0.7050900@redhat.com>
	<CAAtRV8M00aLFkAV=0z_5S3wuADbpn2OqBGt2ReurpFa1VYrX3A@mail.gmail.com>
Message-ID: <50977A07.5070901@redhat.com>

On 11/05/2012 09:58 AM, Romil Gupta wrote:
>  Do we have any refresh or update function in ovirt sdk  so that after coping the image  RHEVM will get refresh automatically ?? 
> 
> Regards,
> Romil

yes, just do GET on /api/storagedomains/xxx/files


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From mpastern at redhat.com  Mon Nov  5 14:04:07 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Mon, 05 Nov 2012 16:04:07 +0200
Subject: [Engine-devel] Fwd: [Users] Related to python script for Attach
 Cd (.iso) to a vm
In-Reply-To: <CAAtRV8NM7ESSM7HhLjnocmG_Jt5Fn4wDQ7e36MhUGtPuneMc3A@mail.gmail.com>
References: <CAAtRV8PS_adCe_AvBtUmSJ+6g1qiZMNxj6Ex5WQAxQ=yG+5+Pg@mail.gmail.com>	<509753F5.2080305@redhat.com>	<509754D0.7050900@redhat.com>	<CAAtRV8M00aLFkAV=0z_5S3wuADbpn2OqBGt2ReurpFa1VYrX3A@mail.gmail.com>	<50977A07.5070901@redhat.com>
	<CAAtRV8NM7ESSM7HhLjnocmG_Jt5Fn4wDQ7e36MhUGtPuneMc3A@mail.gmail.com>
Message-ID: <5097C757.4080400@redhat.com>

On 11/05/2012 01:23 PM, Romil Gupta wrote:
> 
> On 11/05/2012 09:58 AM, Romil Gupta wrote:
>>  Do we have any refresh or update function in ovirt sdk  so that after coping the image  RHEVM will get refresh automatically ??
>>
>> Regards,
>> Romil
> 
> yes, just do GET on /api/storagedomains/xxx/files
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
> 
> 
> Hi,
> 
> I have to write a python script  using ovirt sdk !
> Please tell me the refresh iso domain function in python :)

sdk using very same semantics as apy does,

sd = api.storagedomains.get(name="iso_domain")
sd.files.list() // will produce [GET on /api/storagedomains/xxx/files]


> 
> Regards ,
> Romil 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From mpastern at redhat.com  Mon Nov  5 14:47:58 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Mon, 05 Nov 2012 16:47:58 +0200
Subject: [Engine-devel] Fwd: [Users] Related to python script for Attach
 Cd (.iso) to a vm
In-Reply-To: <CAAtRV8MwGoR7iaUPS7rgxh0bOEiKO30kvtpFgdTq+Js0xKe36w@mail.gmail.com>
References: <CAAtRV8PS_adCe_AvBtUmSJ+6g1qiZMNxj6Ex5WQAxQ=yG+5+Pg@mail.gmail.com>	<509753F5.2080305@redhat.com>	<509754D0.7050900@redhat.com>	<CAAtRV8M00aLFkAV=0z_5S3wuADbpn2OqBGt2ReurpFa1VYrX3A@mail.gmail.com>	<50977A07.5070901@redhat.com>	<CAAtRV8NM7ESSM7HhLjnocmG_Jt5Fn4wDQ7e36MhUGtPuneMc3A@mail.gmail.com>	<5097C757.4080400@redhat.com>
	<CAAtRV8MwGoR7iaUPS7rgxh0bOEiKO30kvtpFgdTq+Js0xKe36w@mail.gmail.com>
Message-ID: <5097D19E.1030504@redhat.com>

On 11/05/2012 04:22 PM, Romil Gupta wrote:
> HI,
> I already tried this :
> 
> api.storagedomains.get(name='rhevmiso').update()
>     print 'updated'
>     rhevmiso=api.storagedomains.get(name='rhevmiso').files.list()
>     for iso  in rhevmiso:
>         print ' iso --> %s \n' % iso
>     image =  api.storagedomains.get(name='rhevmiso').files.get(name='tinycore.iso')
>     print 'image found %s' %image
>     try:
>         api.vms.get(VM_NAME).cdroms.add(params.CdRom(name='cdrom',file=image))
>         print 'image added to VM'
>     except Exception as e:
>         print 'Failed to add image \n%s' % str(e)
> 
> 
> But ,*it will not show the latest image that I have copied to 'rhevmiso' storage domain i.e tinycore.iso*
> 
> and o/p  is : 
> image found none
> Failed to add image \n%s' % str(e)
> 
> 
> Please help me !!

listing files in api should force iso-refresh [1],
make sure your iso-upload is succeeded and your iso
file has right permissions,

if it's not the case, it's sounds like a bug, please
file ovirt-engine bug on this.

[1] queryParams.setForceRefresh(true);

> 
> 
> Regards
> Romil
> 
> 
> On Mon, Nov 5, 2012 at 7:34 PM, Michael Pasternak <mpastern at redhat.com <mailto:mpastern at redhat.com>> wrote:
> 
>     On 11/05/2012 01:23 PM, Romil Gupta wrote:
>     >
>     > On 11/05/2012 09:58 AM, Romil Gupta wrote:
>     >>  Do we have any refresh or update function in ovirt sdk  so that after coping the image  RHEVM will get refresh automatically ??
>     >>
>     >> Regards,
>     >> Romil
>     >
>     > yes, just do GET on /api/storagedomains/xxx/files
>     > --
>     >
>     > Michael Pasternak
>     > RedHat, ENG-Virtualization R&D
>     >
>     >
>     > Hi,
>     >
>     > I have to write a python script  using ovirt sdk !
>     > Please tell me the refresh iso domain function in python :)
> 
>     sdk using very same semantics as apy does,
> 
>     sd = api.storagedomains.get(name="iso_domain")
>     sd.files.list() // will produce [GET on /api/storagedomains/xxx/files]
> 
> 
>     >
>     > Regards ,
>     > Romil
> 
> 
>     --
> 
>     Michael Pasternak
>     RedHat, ENG-Virtualization R&D
> 
> 
> 
> 
> -- 
> I don't wish to be everything to everyone, but I would like to be something to someone.


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From lhornyak at redhat.com  Mon Nov  5 17:08:05 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Mon, 5 Nov 2012 12:08:05 -0500 (EST)
Subject: [Engine-devel] eclipse juno vs gwt
In-Reply-To: <D290AD8432118048947689BA3AE8A9B3EA3037@SACEXCMBX04-PRD.hq.netapp.com>
Message-ID: <1099622011.5129712.1352135285352.JavaMail.root@redhat.com>

http://youtu.be/XQ0JmfKs21g



----- Original Message -----
> From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Friday, November 2, 2012 11:43:23 PM
> Subject: RE: [Engine-devel] eclipse juno vs gwt
> 
> Sorry to follow up my own question, but can you give some specific
> cases where this would be a problem? Thanks!
> 
> -Chris
> 
> 
> -----Original Message-----
> From: Morrissey, Christopher
> Sent: Friday, November 02, 2012 6:41 PM
> To: 'Laszlo Hornyak'; engine-devel
> Subject: RE: [Engine-devel] eclipse juno vs gwt
> 
> Hi Laszlo,
> 
> I have several methods that define the @Override annotation and
> return something different from the super class. I haven't had any
> problems compiling them in GWT. The return value does extend from
> the return value of the super class, although this is a requirement
> in Java as well so I'm not sure where the difference is.
> 
> -Chris
> 
> 
> -----Original Message-----
> From: engine-devel-bounces at ovirt.org
> [mailto:engine-devel-bounces at ovirt.org] On Behalf Of Laszlo Hornyak
> Sent: Friday, November 02, 2012 6:19 AM
> To: engine-devel
> Subject: [Engine-devel] eclipse juno vs gwt
> 
> Hi,
> 
> Just noticed that eclipse juno is adding @Ovewrride annotations to
> methods that are actually overriding something, like in many cases
> clone and equals methods in some of the classes. This is fine for
> the java compiler, but it in some cases the GWT compiler is not
> going to accept this annotation. E.g. if the return type is
> different than the method with same name in the superclass.
> 
> Juno is doing this by default without asking, when saving the file.
> So be extra-careful when editing java classes if they are shared
> with GWT
> 
> Laszlo
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From lhornyak at redhat.com  Mon Nov  5 17:10:11 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Mon, 5 Nov 2012 12:10:11 -0500 (EST)
Subject: [Engine-devel] ovirt on wikipedia
In-Reply-To: <3700803.163.1352049055445.JavaMail.msalem@dhcp-1-23.tlv.redhat.com>
Message-ID: <815962368.5130014.1352135411843.JavaMail.root@redhat.com>

Thank you, Muli! :)

----- Original Message -----
> From: "Muli Salem" <msalem at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Cc: "Laszlo Hornyak" <lhornyak at redhat.com>
> Sent: Sunday, November 4, 2012 6:17:20 PM
> Subject: Re: [Engine-devel] ovirt on wikipedia
> 
> Hi,
> 
> The Hebrew wiki for oVirt can be found in:
> http://he.wikipedia.org/wiki/OVirt
> 
> You are more than welcome to make changes/add stuff.
> 
> Cheers,
> Muli
> 
> ----- Original Message -----
> From: "Muli Salem" <msalem at redhat.com>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, 4 November, 2012 9:01:04 AM
> Subject: Re: [Engine-devel] ovirt on wikipedia
> 
> Hi all,
> 
> Will take care of the Hebrew part.
> Although I would love to help more, I still need to work on my
> Spanish :)
> 
> Muli
> 
> ----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, 29 October, 2012 5:40:28 PM
> Subject: [Engine-devel] ovirt on wikipedia
> 
> Hi,
> 
> http://en.wikipedia.org/wiki/OVirt
> At the moment there are OVirt pages in english, russian and
> hungarian.
> Any volunteers to write czech, hebrew, german, spanish, catalan? -
> just to mention the languages some ovirt-developers speak :-)
> 
> Laszlo
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From mlipchuk at redhat.com  Tue Nov  6 12:48:19 2012
From: mlipchuk at redhat.com (Maor Lipchuk)
Date: Tue, 06 Nov 2012 14:48:19 +0200
Subject: [Engine-devel] eclipse juno vs gwt
In-Reply-To: <1099622011.5129712.1352135285352.JavaMail.root@redhat.com>
References: <1099622011.5129712.1352135285352.JavaMail.root@redhat.com>
Message-ID: <50990713.1010506@redhat.com>

Hi Laszlo,
Why not change the eclipse configuration, that it won't add @override
annotation when saving the class (Java - Editor -Save Actions)
but instead use warning instead (java - compiler - Errors/Warnings)

Regards,
Maor

On 11/05/2012 07:08 PM, Laszlo Hornyak wrote:
> http://youtu.be/XQ0JmfKs21g
> 
> 
> 
> ----- Original Message -----
>> From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
>> To: "Laszlo Hornyak" <lhornyak at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
>> Sent: Friday, November 2, 2012 11:43:23 PM
>> Subject: RE: [Engine-devel] eclipse juno vs gwt
>>
>> Sorry to follow up my own question, but can you give some specific
>> cases where this would be a problem? Thanks!
>>
>> -Chris
>>
>>
>> -----Original Message-----
>> From: Morrissey, Christopher
>> Sent: Friday, November 02, 2012 6:41 PM
>> To: 'Laszlo Hornyak'; engine-devel
>> Subject: RE: [Engine-devel] eclipse juno vs gwt
>>
>> Hi Laszlo,
>>
>> I have several methods that define the @Override annotation and
>> return something different from the super class. I haven't had any
>> problems compiling them in GWT. The return value does extend from
>> the return value of the super class, although this is a requirement
>> in Java as well so I'm not sure where the difference is.
>>
>> -Chris
>>
>>
>> -----Original Message-----
>> From: engine-devel-bounces at ovirt.org
>> [mailto:engine-devel-bounces at ovirt.org] On Behalf Of Laszlo Hornyak
>> Sent: Friday, November 02, 2012 6:19 AM
>> To: engine-devel
>> Subject: [Engine-devel] eclipse juno vs gwt
>>
>> Hi,
>>
>> Just noticed that eclipse juno is adding @Ovewrride annotations to
>> methods that are actually overriding something, like in many cases
>> clone and equals methods in some of the classes. This is fine for
>> the java compiler, but it in some cases the GWT compiler is not
>> going to accept this annotation. E.g. if the return type is
>> different than the method with same name in the superclass.
>>
>> Juno is doing this by default without asking, when saving the file.
>> So be extra-careful when editing java classes if they are shared
>> with GWT
>>
>> Laszlo
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 




From lpeer at redhat.com  Tue Nov  6 13:56:56 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Tue, 06 Nov 2012 15:56:56 +0200
Subject: [Engine-devel] Managing permissions on network
Message-ID: <50991728.8070702@redhat.com>

Hi All,

This is a proposal for handling network permissions in oVirt.

In this proposal we took the more permissive approach as we find it
simple and a good starting point, we also think a more restrict approach
makes the configuration of a network cumbersome for ovirt administrators.

Inputs are welcomed as always...

Here is an overview of the approach, for more detailed description
please read the wiki page:
http://wiki.ovirt.org/wiki/Feature/NetworkPermissions

---------------------------------------------------------------------------
Admin
======

-> For creating a network in a data center you need to be a Superuser or
a DCAdmin or a networkAdmin on the DC.

-> After creating the network you can manipulate the network if you are
a DCAdmin or a networkAdmin on the relevant network (or the whole DC).

-> For attaching the network to cluster you need to be a networkAdmin on
the network (no requirement to have permission on the cluster)

-> Cluster administrator can not attach/detach a network from the
cluster, the motivation for this is that as long as the network is not
attached to the cluster it is not part of the cluster resources thus can
not be managed by the cluster administrator.
In addition once a network is attached to a cluster the cluster
administrator can change the network from required to non-required for
controlling the impact of the network within the cluster.

-> For setting a network on the host you need to be host administrator
on the host and you don't need to be network administrator.
This implies that if you are a host administrator you can add/remove all
the cluster networks from your host without the need for network related
permissions (this is the permissive approach).

User
====

-> For attaching a network to a Vnic in the VM you need to have the role
of VmNetworkUser on the network and vmAdmin on the VM.

-> In user portal - the list of shown network for a user will include
only the list of networks the user is allowed to attach to its vnics
(instead of all cluster's networks).

Port-mirroring
===============

->  For configuring in the VM port mirroring you need to have the role
of VmAdvancedNetworkUser on the network and vmAdmin on the VM.
VmAdvancedNetworkUser includes the VmNetworkUser actions in addition to
port mirroring.




For all DB upgrade information and new roles/action groups please review
the wiki.

Thanks,
Livnat & Moti


From lhornyak at redhat.com  Tue Nov  6 15:24:37 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Tue, 6 Nov 2012 10:24:37 -0500 (EST)
Subject: [Engine-devel] eclipse juno vs gwt
In-Reply-To: <50990713.1010506@redhat.com>
Message-ID: <1857250570.5694606.1352215477363.JavaMail.root@redhat.com>

That's what I was looking for! Thank you, Maor! :)

----- Original Message -----
> From: "Maor Lipchuk" <mlipchuk at redhat.com>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, November 6, 2012 1:48:19 PM
> Subject: Re: [Engine-devel] eclipse juno vs gwt
> 
> Hi Laszlo,
> Why not change the eclipse configuration, that it won't add @override
> annotation when saving the class (Java - Editor -Save Actions)
> but instead use warning instead (java - compiler - Errors/Warnings)
> 
> Regards,
> Maor
> 
> On 11/05/2012 07:08 PM, Laszlo Hornyak wrote:
> > http://youtu.be/XQ0JmfKs21g
> > 
> > 
> > 
> > ----- Original Message -----
> >> From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
> >> To: "Laszlo Hornyak" <lhornyak at redhat.com>, "engine-devel"
> >> <engine-devel at ovirt.org>
> >> Sent: Friday, November 2, 2012 11:43:23 PM
> >> Subject: RE: [Engine-devel] eclipse juno vs gwt
> >>
> >> Sorry to follow up my own question, but can you give some specific
> >> cases where this would be a problem? Thanks!
> >>
> >> -Chris
> >>
> >>
> >> -----Original Message-----
> >> From: Morrissey, Christopher
> >> Sent: Friday, November 02, 2012 6:41 PM
> >> To: 'Laszlo Hornyak'; engine-devel
> >> Subject: RE: [Engine-devel] eclipse juno vs gwt
> >>
> >> Hi Laszlo,
> >>
> >> I have several methods that define the @Override annotation and
> >> return something different from the super class. I haven't had any
> >> problems compiling them in GWT. The return value does extend from
> >> the return value of the super class, although this is a
> >> requirement
> >> in Java as well so I'm not sure where the difference is.
> >>
> >> -Chris
> >>
> >>
> >> -----Original Message-----
> >> From: engine-devel-bounces at ovirt.org
> >> [mailto:engine-devel-bounces at ovirt.org] On Behalf Of Laszlo
> >> Hornyak
> >> Sent: Friday, November 02, 2012 6:19 AM
> >> To: engine-devel
> >> Subject: [Engine-devel] eclipse juno vs gwt
> >>
> >> Hi,
> >>
> >> Just noticed that eclipse juno is adding @Ovewrride annotations to
> >> methods that are actually overriding something, like in many cases
> >> clone and equals methods in some of the classes. This is fine for
> >> the java compiler, but it in some cases the GWT compiler is not
> >> going to accept this annotation. E.g. if the return type is
> >> different than the method with same name in the superclass.
> >>
> >> Juno is doing this by default without asking, when saving the
> >> file.
> >> So be extra-careful when editing java classes if they are shared
> >> with GWT
> >>
> >> Laszlo
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 
> 
> 


From snmishra at linux.vnet.ibm.com  Tue Nov  6 16:54:44 2012
From: snmishra at linux.vnet.ibm.com (snmishra at linux.vnet.ibm.com)
Date: Tue, 06 Nov 2012 08:54:44 -0800
Subject: [Engine-devel] Updated screen shots for GlusterFS.
Message-ID: <20121106085444.Horde.QMGOMJir309QmUDU6jBTigA@imap.linux.ibm.com>


Hi,

   The wiki page at  
http://wiki.ovirt.org/wiki/Features/GlusterFS_Storage_Domain#Usability_enhancements has been updated with screenshots to support Gluster FS. Please review and provide  
feedback.

  1. What other screens need updates?
  2. How to autofill VFSType text box with "glusterfs". It is grayed  
out but should be pre-filled with "glusterfs". I am new to UI. Need  
help.
  3. Patches are located at http://gerrit.ovirt.org/#/dashboard/1000137

Regards
Sharad Mishra
IBM






From michal.skrivanek at redhat.com  Tue Nov  6 21:39:58 2012
From: michal.skrivanek at redhat.com (Michal Skrivanek)
Date: Tue, 6 Nov 2012 22:39:58 +0100
Subject: [Engine-devel] SPICE IP override
Message-ID: <2CEBE9E7-1C7A-4E52-AE42-04D51983FF6F@redhat.com>

Hi all,
On behalf of Tomas - please check out the proposal for enhancing our SPICE integration to allow to return a custom IP/FQDN instead of the host IP address.
http://wiki.ovirt.org/wiki/Features/Display_Address_Override
All comments are welcome...

Thanks,
michal



From simon at redhat.com  Wed Nov  7 08:52:14 2012
From: simon at redhat.com (Simon Grinberg)
Date: Wed, 7 Nov 2012 03:52:14 -0500 (EST)
Subject: [Engine-devel] SPICE IP override
In-Reply-To: <2CEBE9E7-1C7A-4E52-AE42-04D51983FF6F@redhat.com>
Message-ID: <1197121097.6204891.1352278334446.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Tuesday, November 6, 2012 10:39:58 PM
> Subject: [Engine-devel] SPICE IP override
> 
> Hi all,
> On behalf of Tomas - please check out the proposal for enhancing our
> SPICE integration to allow to return a custom IP/FQDN instead of the
> host IP address.
> http://wiki.ovirt.org/wiki/Features/Display_Address_Override
> All comments are welcome...

My 2 cents, 

This works under the assumption that all the users are either outside of the organization or inside. 
But think of some of the following scenarios based on a topology where users in the main office are inside the corporate network while users on remote offices / WAN are on a detached different network on the other side of the NAT / public firewall :

With current 'per host override' proposal: 
1. Admin from the main office won't be able to access the VM console
2. No Mixed environment, meaning that you have to have designated clusters for remote offices users vs main office users - otherwise connectivity to the console is determined based on scheduler decision, or may break by live migration.
3. Based on #2, If I'm a user travelling between offices I'll have to ask the admin to turn off my VM and move it to internal cluster before I can reconnect

My suggestion is to covert this to 'alternative' IP/FQDN sending the spice client both internal fqdn/ip and the alternative. The spice client should detect which is available of the two and auto-connect. 

This requires enhancement of the spice client, but still solves all the issues raised above (actually it solves about 90% of the use cases I've heard about in the past). 

Another alternative is for the engine to 'guess' or 'elect' which to use, alternative or main, based on the IP of the client - meaning admin provides the client ranges for providing internal host address vs alternative - but this is more complicated compared for the previous suggestion  

Thoughts?
 

Simon.

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


From iheim at redhat.com  Wed Nov  7 09:46:24 2012
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 07 Nov 2012 10:46:24 +0100
Subject: [Engine-devel] SPICE IP override
In-Reply-To: <1197121097.6204891.1352278334446.JavaMail.root@redhat.com>
References: <1197121097.6204891.1352278334446.JavaMail.root@redhat.com>
Message-ID: <509A2DF0.7080702@redhat.com>

On 11/07/2012 09:52 AM, Simon Grinberg wrote:
>
>
> ----- Original Message -----
>> From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
>> To: engine-devel at ovirt.org
>> Sent: Tuesday, November 6, 2012 10:39:58 PM
>> Subject: [Engine-devel] SPICE IP override
>>
>> Hi all,
>> On behalf of Tomas - please check out the proposal for enhancing our
>> SPICE integration to allow to return a custom IP/FQDN instead of the
>> host IP address.
>> http://wiki.ovirt.org/wiki/Features/Display_Address_Override
>> All comments are welcome...
>
> My 2 cents,
>
> This works under the assumption that all the users are either outside of the organization or inside.
> But think of some of the following scenarios based on a topology where users in the main office are inside the corporate network while users on remote offices / WAN are on a detached different network on the other side of the NAT / public firewall :
>
> With current 'per host override' proposal:
> 1. Admin from the main office won't be able to access the VM console
> 2. No Mixed environment, meaning that you have to have designated clusters for remote offices users vs main office users - otherwise connectivity to the console is determined based on scheduler decision, or may break by live migration.
> 3. Based on #2, If I'm a user travelling between offices I'll have to ask the admin to turn off my VM and move it to internal cluster before I can reconnect
>
> My suggestion is to covert this to 'alternative' IP/FQDN sending the spice client both internal fqdn/ip and the alternative. The spice client should detect which is available of the two and auto-connect.
>
> This requires enhancement of the spice client, but still solves all the issues raised above (actually it solves about 90% of the use cases I've heard about in the past).
>
> Another alternative is for the engine to 'guess' or 'elect' which to use, alternative or main, based on the IP of the client - meaning admin provides the client ranges for providing internal host address vs alternative - but this is more complicated compared for the previous suggestion
>
> Thoughts?

i think this is over complicating things.
I'd expect someone that wants to handle internal and external 
differently to use DNS, and resolve the DNS differently for external and 
internal clients.

(note this is different from specifying the spice proxy address at 
cluster level, which is something you want user to choose if they want 
to enable or not per their location)


From iheim at redhat.com  Wed Nov  7 09:49:00 2012
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 07 Nov 2012 10:49:00 +0100
Subject: [Engine-devel] SPICE IP override
In-Reply-To: <2CEBE9E7-1C7A-4E52-AE42-04D51983FF6F@redhat.com>
References: <2CEBE9E7-1C7A-4E52-AE42-04D51983FF6F@redhat.com>
Message-ID: <509A2E8C.3050503@redhat.com>

On 11/06/2012 10:39 PM, Michal Skrivanek wrote:
> Hi all,
> On behalf of Tomas - please check out the proposal for enhancing our SPICE integration to allow to return a custom IP/FQDN instead of the host IP address.
> http://wiki.ovirt.org/wiki/Features/Display_Address_Override
> All comments are welcome...
>
> Thanks,
> michal

please note users don't see/get the host entities, so REST API should 
provide this info under the vm display element.




From simon at redhat.com  Wed Nov  7 09:52:25 2012
From: simon at redhat.com (Simon Grinberg)
Date: Wed, 7 Nov 2012 04:52:25 -0500 (EST)
Subject: [Engine-devel] SPICE IP override
In-Reply-To: <509A2DF0.7080702@redhat.com>
Message-ID: <1190246211.6251087.1352281945100.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Simon Grinberg" <simon at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, November 7, 2012 10:46:24 AM
> Subject: Re: [Engine-devel] SPICE IP override
> 
> On 11/07/2012 09:52 AM, Simon Grinberg wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
> >> To: engine-devel at ovirt.org
> >> Sent: Tuesday, November 6, 2012 10:39:58 PM
> >> Subject: [Engine-devel] SPICE IP override
> >>
> >> Hi all,
> >> On behalf of Tomas - please check out the proposal for enhancing
> >> our
> >> SPICE integration to allow to return a custom IP/FQDN instead of
> >> the
> >> host IP address.
> >> http://wiki.ovirt.org/wiki/Features/Display_Address_Override
> >> All comments are welcome...
> >
> > My 2 cents,
> >
> > This works under the assumption that all the users are either
> > outside of the organization or inside.
> > But think of some of the following scenarios based on a topology
> > where users in the main office are inside the corporate network
> > while users on remote offices / WAN are on a detached different
> > network on the other side of the NAT / public firewall :
> >
> > With current 'per host override' proposal:
> > 1. Admin from the main office won't be able to access the VM
> > console
> > 2. No Mixed environment, meaning that you have to have designated
> > clusters for remote offices users vs main office users - otherwise
> > connectivity to the console is determined based on scheduler
> > decision, or may break by live migration.
> > 3. Based on #2, If I'm a user travelling between offices I'll have
> > to ask the admin to turn off my VM and move it to internal cluster
> > before I can reconnect
> >
> > My suggestion is to covert this to 'alternative' IP/FQDN sending
> > the spice client both internal fqdn/ip and the alternative. The
> > spice client should detect which is available of the two and
> > auto-connect.
> >
> > This requires enhancement of the spice client, but still solves all
> > the issues raised above (actually it solves about 90% of the use
> > cases I've heard about in the past).
> >
> > Another alternative is for the engine to 'guess' or 'elect' which
> > to use, alternative or main, based on the IP of the client -
> > meaning admin provides the client ranges for providing internal
> > host address vs alternative - but this is more complicated
> > compared for the previous suggestion
> >
> > Thoughts?
> 
> i think this is over complicating things.
> I'd expect someone that wants to handle internal and external
> differently to use DNS, and resolve the DNS differently for external
> and
> internal clients.

That will not necessarily solve the issue - what about WAN users from home? the DNS is not under their control -> they need redirection to the public facing NAT servers. 

+ At least currently (and this must change, unless you accept the proposal I've raised) the engine sends fqdn if the display network in on the engine management network and IP on any other selected Display-Network.  

No DNS will help you in this case, so you still need alternate FQDN. 

> 
> (note this is different from specifying the spice proxy address at
> cluster level, which is something you want user to choose if they
> want
> to enable or not per their location)
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From iheim at redhat.com  Wed Nov  7 10:12:30 2012
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 07 Nov 2012 11:12:30 +0100
Subject: [Engine-devel] SPICE IP override
In-Reply-To: <1190246211.6251087.1352281945100.JavaMail.root@redhat.com>
References: <1190246211.6251087.1352281945100.JavaMail.root@redhat.com>
Message-ID: <509A340E.9040901@redhat.com>

On 11/07/2012 10:52 AM, Simon Grinberg wrote:
>
>
> ----- Original Message -----
>> From: "Itamar Heim" <iheim at redhat.com>
>> To: "Simon Grinberg" <simon at redhat.com>
>> Cc: engine-devel at ovirt.org
>> Sent: Wednesday, November 7, 2012 10:46:24 AM
>> Subject: Re: [Engine-devel] SPICE IP override
>>
>> On 11/07/2012 09:52 AM, Simon Grinberg wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
>>>> To: engine-devel at ovirt.org
>>>> Sent: Tuesday, November 6, 2012 10:39:58 PM
>>>> Subject: [Engine-devel] SPICE IP override
>>>>
>>>> Hi all,
>>>> On behalf of Tomas - please check out the proposal for enhancing
>>>> our
>>>> SPICE integration to allow to return a custom IP/FQDN instead of
>>>> the
>>>> host IP address.
>>>> http://wiki.ovirt.org/wiki/Features/Display_Address_Override
>>>> All comments are welcome...
>>>
>>> My 2 cents,
>>>
>>> This works under the assumption that all the users are either
>>> outside of the organization or inside.
>>> But think of some of the following scenarios based on a topology
>>> where users in the main office are inside the corporate network
>>> while users on remote offices / WAN are on a detached different
>>> network on the other side of the NAT / public firewall :
>>>
>>> With current 'per host override' proposal:
>>> 1. Admin from the main office won't be able to access the VM
>>> console
>>> 2. No Mixed environment, meaning that you have to have designated
>>> clusters for remote offices users vs main office users - otherwise
>>> connectivity to the console is determined based on scheduler
>>> decision, or may break by live migration.
>>> 3. Based on #2, If I'm a user travelling between offices I'll have
>>> to ask the admin to turn off my VM and move it to internal cluster
>>> before I can reconnect
>>>
>>> My suggestion is to covert this to 'alternative' IP/FQDN sending
>>> the spice client both internal fqdn/ip and the alternative. The
>>> spice client should detect which is available of the two and
>>> auto-connect.
>>>
>>> This requires enhancement of the spice client, but still solves all
>>> the issues raised above (actually it solves about 90% of the use
>>> cases I've heard about in the past).
>>>
>>> Another alternative is for the engine to 'guess' or 'elect' which
>>> to use, alternative or main, based on the IP of the client -
>>> meaning admin provides the client ranges for providing internal
>>> host address vs alternative - but this is more complicated
>>> compared for the previous suggestion
>>>
>>> Thoughts?
>>
>> i think this is over complicating things.
>> I'd expect someone that wants to handle internal and external
>> differently to use DNS, and resolve the DNS differently for external
>> and
>> internal clients.
>
> That will not necessarily solve the issue - what about WAN users from home? the DNS is not under their control -> they need redirection to the public facing NAT servers.

if a public service, not relevant.
if a private service, i expect they would be using a VPN, with dns 
resolution provided by the organization for external vpn users, if they 
need to resolve IPs differently internally and externally.

>
> + At least currently (and this must change, unless you accept the proposal I've raised) the engine sends fqdn if the display network in on the engine management network and IP on any other selected Display-Network.

not with this patch, which sends the dns the admin configured, 
regardless of display logical network used.

>
> No DNS will help you in this case, so you still need alternate FQDN.
>
>>
>> (note this is different from specifying the spice proxy address at
>> cluster level, which is something you want user to choose if they
>> want
>> to enable or not per their location)
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>




From ewoud+ovirt at kohlvanwijngaarden.nl  Wed Nov  7 10:16:28 2012
From: ewoud+ovirt at kohlvanwijngaarden.nl (Ewoud Kohl van Wijngaarden)
Date: Wed, 7 Nov 2012 11:16:28 +0100
Subject: [Engine-devel] SPICE IP override
In-Reply-To: <1197121097.6204891.1352278334446.JavaMail.root@redhat.com>
References: <2CEBE9E7-1C7A-4E52-AE42-04D51983FF6F@redhat.com>
	<1197121097.6204891.1352278334446.JavaMail.root@redhat.com>
Message-ID: <20121107101628.GZ2094@bogey.xentower.nl>

On Wed, Nov 07, 2012 at 03:52:14AM -0500, Simon Grinberg wrote:
> ----- Original Message -----
> > From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
> > To: engine-devel at ovirt.org
> > Sent: Tuesday, November 6, 2012 10:39:58 PM
> > Subject: [Engine-devel] SPICE IP override
> >
> > Hi all,
> > On behalf of Tomas - please check out the proposal for enhancing our
> > SPICE integration to allow to return a custom IP/FQDN instead of the
> > host IP address.
> > http://wiki.ovirt.org/wiki/Features/Display_Address_Override
> > All comments are welcome...
>
> My 2 cents,
>
> This works under the assumption that all the users are either outside
> of the organization or inside.
> But think of some of the following scenarios based on a topology where
> users in the main office are inside the corporate network while users
> on remote offices / WAN are on a detached different network on the
> other side of the NAT / public firewall :
>
> With current 'per host override' proposal:
> 1. Admin from the main office won't be able to access the VM console
> 2. No Mixed environment, meaning that you have to have designated
>    clusters for remote offices users vs main office users - otherwise
>    connectivity to the console is determined based on scheduler
>    decision, or may break by live migration.
> 3. Based on #2, If I'm a user travelling between offices I'll have to
>    ask the admin to turn off my VM and move it to internal cluster
>    before I can reconnect
>
> My suggestion is to covert this to 'alternative' IP/FQDN sending the
> spice client both internal fqdn/ip and the alternative. The spice
> client should detect which is available of the two and auto-connect.
>
> This requires enhancement of the spice client, but still solves all
> the issues raised above (actually it solves about 90% of the use cases
> I've heard about in the past).
>
> Another alternative is for the engine to 'guess' or 'elect' which to
> use, alternative or main, based on the IP of the client - meaning
> admin provides the client ranges for providing internal host address
> vs alternative - but this is more complicated compared for the
> previous suggestion
>
> Thoughts?

I agree with where you're going with this. The story I'd like to see
supported is close to this. We have external customers who should know
nothing about our internal network, but should be able to access the
console of their VMs. Currently we do this with a custom frontend which
uses the API (and is about as old as the RHEV 2.2 API) and a TCP proxy,
but we'd like to move to the standard UI. Currently the console
connection prevents us from doing so.

Users are able to create VMs based on the resources they have (RAM, CPU,
storage, network) without admin intervention. This means we'd like to
see this override on a cluster / DC / global level so there is no need
for admin intervention. Ideally this would also come with a programmable
proxy so the engine can enable/disable forwards instead of a NAT
firewall.


From djasa at redhat.com  Wed Nov  7 10:23:27 2012
From: djasa at redhat.com (David =?UTF-8?Q?Ja=C5=A1a?=)
Date: Wed, 07 Nov 2012 11:23:27 +0100
Subject: [Engine-devel] SPICE IP override
In-Reply-To: <20121107101628.GZ2094@bogey.xentower.nl>
References: <2CEBE9E7-1C7A-4E52-AE42-04D51983FF6F@redhat.com>
	<1197121097.6204891.1352278334446.JavaMail.root@redhat.com>
	<20121107101628.GZ2094@bogey.xentower.nl>
Message-ID: <1352283807.13273.67.camel@dhcp-29-7.brq.redhat.com>

Ewoud Kohl van Wijngaarden p??e v St 07. 11. 2012 v 11:16 +0100:
> On Wed, Nov 07, 2012 at 03:52:14AM -0500, Simon Grinberg wrote:
> > ----- Original Message -----
> > > From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
> > > To: engine-devel at ovirt.org
> > > Sent: Tuesday, November 6, 2012 10:39:58 PM
> > > Subject: [Engine-devel] SPICE IP override
> > >
> > > Hi all,
> > > On behalf of Tomas - please check out the proposal for enhancing our
> > > SPICE integration to allow to return a custom IP/FQDN instead of the
> > > host IP address.
> > > http://wiki.ovirt.org/wiki/Features/Display_Address_Override
> > > All comments are welcome...
> >
> > My 2 cents,
> >
> > This works under the assumption that all the users are either outside
> > of the organization or inside.
> > But think of some of the following scenarios based on a topology where
> > users in the main office are inside the corporate network while users
> > on remote offices / WAN are on a detached different network on the
> > other side of the NAT / public firewall :
> >
> > With current 'per host override' proposal:
> > 1. Admin from the main office won't be able to access the VM console
> > 2. No Mixed environment, meaning that you have to have designated
> >    clusters for remote offices users vs main office users - otherwise
> >    connectivity to the console is determined based on scheduler
> >    decision, or may break by live migration.
> > 3. Based on #2, If I'm a user travelling between offices I'll have to
> >    ask the admin to turn off my VM and move it to internal cluster
> >    before I can reconnect
> >
> > My suggestion is to covert this to 'alternative' IP/FQDN sending the
> > spice client both internal fqdn/ip and the alternative. The spice
> > client should detect which is available of the two and auto-connect.
> >
> > This requires enhancement of the spice client, but still solves all
> > the issues raised above (actually it solves about 90% of the use cases
> > I've heard about in the past).
> >
> > Another alternative is for the engine to 'guess' or 'elect' which to
> > use, alternative or main, based on the IP of the client - meaning
> > admin provides the client ranges for providing internal host address
> > vs alternative - but this is more complicated compared for the
> > previous suggestion
> >
> > Thoughts?
> 
> I agree with where you're going with this. The story I'd like to see
> supported is close to this. We have external customers who should know
> nothing about our internal network, but should be able to access the
> console of their VMs. Currently we do this with a custom frontend which
> uses the API (and is about as old as the RHEV 2.2 API) and a TCP proxy,
> but we'd like to move to the standard UI. Currently the console
> connection prevents us from doing so.

You could do that with this proposal, if you:
1) DNAT some external-facing IPs to your hypervisor display network IPs
2) resolve display network FQDN to the DNATing machine IPs for external
queries.

David

> 
> Users are able to create VMs based on the resources they have (RAM, CPU,
> storage, network) without admin intervention. This means we'd like to
> see this override on a cluster / DC / global level so there is no need
> for admin intervention. Ideally this would also come with a programmable
> proxy so the engine can enable/disable forwards instead of a NAT
> firewall.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel

-- 

David Ja?a, RHCE

SPICE QE based in Brno
GPG Key:     22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24





From masayag at redhat.com  Wed Nov  7 10:26:49 2012
From: masayag at redhat.com (Moti Asayag)
Date: Wed, 07 Nov 2012 12:26:49 +0200
Subject: [Engine-devel] Managing permissions on network
In-Reply-To: <50991728.8070702@redhat.com>
References: <50991728.8070702@redhat.com>
Message-ID: <509A3769.9090907@redhat.com>

On 11/06/2012 03:56 PM, Livnat Peer wrote:
> Hi All,
> 
> This is a proposal for handling network permissions in oVirt.
> 
> In this proposal we took the more permissive approach as we find it
> simple and a good starting point, we also think a more restrict approach
> makes the configuration of a network cumbersome for ovirt administrators.
> 
> Inputs are welcomed as always...
> 
> Here is an overview of the approach, for more detailed description
> please read the wiki page:
> http://wiki.ovirt.org/wiki/Feature/NetworkPermissions
> 
> ---------------------------------------------------------------------------
> Admin
> ======
> 
> -> For creating a network in a data center you need to be a Superuser or
> a DCAdmin or a networkAdmin on the DC.
> 
> -> After creating the network you can manipulate the network if you are
> a DCAdmin or a networkAdmin on the relevant network (or the whole DC).
> 
> -> For attaching the network to cluster you need to be a networkAdmin on
> the network (no requirement to have permission on the cluster)
> 
> -> Cluster administrator can not attach/detach a network from the
> cluster, the motivation for this is that as long as the network is not
> attached to the cluster it is not part of the cluster resources thus can
> not be managed by the cluster administrator.
> In addition once a network is attached to a cluster the cluster
> administrator can change the network from required to non-required for
> controlling the impact of the network within the cluster.

I'd like to clarify that NetworkAdmin is authorized to update the
cluster network's properties (set network as display network or set
network as required/optional). NetworkAdmin is capable of doing so with
permissions on the Network only (not on the cluster).

The ClusterAdmin is capable of updating the cluster network's properties
as well.

A restrictive approach would be requiring permissions on both Cluster
and Network with NetworkAdmin role in order to perform those actions.
This approach assures that changes committed for a network within a
cluster could be performed by user that owns permissions on both network
and cluster. However it will make the permission granting process a bit
toilsome: Granting the NetworkAdmin role of a specific cluster and also
a NetworkAdmin per each network to be assigned for the cluster.

I'd like to get opinions for the approaches mentioned above.

> 
> -> For setting a network on the host you need to be host administrator
> on the host and you don't need to be network administrator.
> This implies that if you are a host administrator you can add/remove all
> the cluster networks from your host without the need for network related
> permissions (this is the permissive approach).
> 
> User
> ====
> 
> -> For attaching a network to a Vnic in the VM you need to have the role
> of VmNetworkUser on the network and vmAdmin on the VM.
> 
> -> In user portal - the list of shown network for a user will include
> only the list of networks the user is allowed to attach to its vnics
> (instead of all cluster's networks).
> 
> Port-mirroring
> ===============
> 
> ->  For configuring in the VM port mirroring you need to have the role
> of VmAdvancedNetworkUser on the network and vmAdmin on the VM.
> VmAdvancedNetworkUser includes the VmNetworkUser actions in addition to
> port mirroring.
> 
> 
> 
> 
> For all DB upgrade information and new roles/action groups please review
> the wiki.
> 
> Thanks,
> Livnat & Moti
> 



From ewoud+ovirt at kohlvanwijngaarden.nl  Wed Nov  7 11:08:02 2012
From: ewoud+ovirt at kohlvanwijngaarden.nl (Ewoud Kohl van Wijngaarden)
Date: Wed, 7 Nov 2012 12:08:02 +0100
Subject: [Engine-devel] SPICE IP override
In-Reply-To: <1352283807.13273.67.camel@dhcp-29-7.brq.redhat.com>
References: <2CEBE9E7-1C7A-4E52-AE42-04D51983FF6F@redhat.com>
	<1197121097.6204891.1352278334446.JavaMail.root@redhat.com>
	<20121107101628.GZ2094@bogey.xentower.nl>
	<1352283807.13273.67.camel@dhcp-29-7.brq.redhat.com>
Message-ID: <20121107110801.GA2094@bogey.xentower.nl>

On Wed, Nov 07, 2012 at 11:23:27AM +0100, David Ja?a wrote:
> Ewoud Kohl van Wijngaarden p??e v St 07. 11. 2012 v 11:16 +0100:
> > On Wed, Nov 07, 2012 at 03:52:14AM -0500, Simon Grinberg wrote:
> > > ----- Original Message -----
> > > > From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
> > > > To: engine-devel at ovirt.org
> > > > Sent: Tuesday, November 6, 2012 10:39:58 PM
> > > > Subject: [Engine-devel] SPICE IP override
> > > >
> > > > Hi all,
> > > > On behalf of Tomas - please check out the proposal for enhancing our
> > > > SPICE integration to allow to return a custom IP/FQDN instead of the
> > > > host IP address.
> > > > http://wiki.ovirt.org/wiki/Features/Display_Address_Override
> > > > All comments are welcome...
> > >
> > > My 2 cents,
> > >
> > > This works under the assumption that all the users are either outside
> > > of the organization or inside.
> > > But think of some of the following scenarios based on a topology where
> > > users in the main office are inside the corporate network while users
> > > on remote offices / WAN are on a detached different network on the
> > > other side of the NAT / public firewall :
> > >
> > > With current 'per host override' proposal:
> > > 1. Admin from the main office won't be able to access the VM console
> > > 2. No Mixed environment, meaning that you have to have designated
> > >    clusters for remote offices users vs main office users - otherwise
> > >    connectivity to the console is determined based on scheduler
> > >    decision, or may break by live migration.
> > > 3. Based on #2, If I'm a user travelling between offices I'll have to
> > >    ask the admin to turn off my VM and move it to internal cluster
> > >    before I can reconnect
> > >
> > > My suggestion is to covert this to 'alternative' IP/FQDN sending the
> > > spice client both internal fqdn/ip and the alternative. The spice
> > > client should detect which is available of the two and auto-connect.
> > >
> > > This requires enhancement of the spice client, but still solves all
> > > the issues raised above (actually it solves about 90% of the use cases
> > > I've heard about in the past).
> > >
> > > Another alternative is for the engine to 'guess' or 'elect' which to
> > > use, alternative or main, based on the IP of the client - meaning
> > > admin provides the client ranges for providing internal host address
> > > vs alternative - but this is more complicated compared for the
> > > previous suggestion
> > >
> > > Thoughts?
> > 
> > I agree with where you're going with this. The story I'd like to see
> > supported is close to this. We have external customers who should know
> > nothing about our internal network, but should be able to access the
> > console of their VMs. Currently we do this with a custom frontend which
> > uses the API (and is about as old as the RHEV 2.2 API) and a TCP proxy,
> > but we'd like to move to the standard UI. Currently the console
> > connection prevents us from doing so.
> 
> You could do that with this proposal, if you:
> 1) DNAT some external-facing IPs to your hypervisor display network IPs
> 2) resolve display network FQDN to the DNATing machine IPs for external
> queries.

I imagine you need 1 external-facing IP per host, which makes it
expensive to scale since IPv4 space is very limited. This is why I
suggested a proxy. In theory this could also be used to modify a forward
to have seamless host migrations because the end point for the client
wouldn't change.


From djasa at redhat.com  Wed Nov  7 11:40:50 2012
From: djasa at redhat.com (David =?UTF-8?Q?Ja=C5=A1a?=)
Date: Wed, 07 Nov 2012 12:40:50 +0100
Subject: [Engine-devel] SPICE IP override
In-Reply-To: <20121107110801.GA2094@bogey.xentower.nl>
References: <2CEBE9E7-1C7A-4E52-AE42-04D51983FF6F@redhat.com>
	<1197121097.6204891.1352278334446.JavaMail.root@redhat.com>
	<20121107101628.GZ2094@bogey.xentower.nl>
	<1352283807.13273.67.camel@dhcp-29-7.brq.redhat.com>
	<20121107110801.GA2094@bogey.xentower.nl>
Message-ID: <1352288450.13273.87.camel@dhcp-29-7.brq.redhat.com>

Ewoud Kohl van Wijngaarden p??e v St 07. 11. 2012 v 12:08 +0100:
> On Wed, Nov 07, 2012 at 11:23:27AM +0100, David Ja?a wrote:
> > Ewoud Kohl van Wijngaarden p??e v St 07. 11. 2012 v 11:16 +0100:
> > > On Wed, Nov 07, 2012 at 03:52:14AM -0500, Simon Grinberg wrote:
> > > > ----- Original Message -----
> > > > > From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
> > > > > To: engine-devel at ovirt.org
> > > > > Sent: Tuesday, November 6, 2012 10:39:58 PM
> > > > > Subject: [Engine-devel] SPICE IP override
> > > > >
> > > > > Hi all,
> > > > > On behalf of Tomas - please check out the proposal for enhancing our
> > > > > SPICE integration to allow to return a custom IP/FQDN instead of the
> > > > > host IP address.
> > > > > http://wiki.ovirt.org/wiki/Features/Display_Address_Override
> > > > > All comments are welcome...
> > > >
> > > > My 2 cents,
> > > >
> > > > This works under the assumption that all the users are either outside
> > > > of the organization or inside.
> > > > But think of some of the following scenarios based on a topology where
> > > > users in the main office are inside the corporate network while users
> > > > on remote offices / WAN are on a detached different network on the
> > > > other side of the NAT / public firewall :
> > > >
> > > > With current 'per host override' proposal:
> > > > 1. Admin from the main office won't be able to access the VM console
> > > > 2. No Mixed environment, meaning that you have to have designated
> > > >    clusters for remote offices users vs main office users - otherwise
> > > >    connectivity to the console is determined based on scheduler
> > > >    decision, or may break by live migration.
> > > > 3. Based on #2, If I'm a user travelling between offices I'll have to
> > > >    ask the admin to turn off my VM and move it to internal cluster
> > > >    before I can reconnect
> > > >
> > > > My suggestion is to covert this to 'alternative' IP/FQDN sending the
> > > > spice client both internal fqdn/ip and the alternative. The spice
> > > > client should detect which is available of the two and auto-connect.
> > > >
> > > > This requires enhancement of the spice client, but still solves all
> > > > the issues raised above (actually it solves about 90% of the use cases
> > > > I've heard about in the past).
> > > >
> > > > Another alternative is for the engine to 'guess' or 'elect' which to
> > > > use, alternative or main, based on the IP of the client - meaning
> > > > admin provides the client ranges for providing internal host address
> > > > vs alternative - but this is more complicated compared for the
> > > > previous suggestion
> > > >
> > > > Thoughts?
> > > 
> > > I agree with where you're going with this. The story I'd like to see
> > > supported is close to this. We have external customers who should know
> > > nothing about our internal network, but should be able to access the
> > > console of their VMs. Currently we do this with a custom frontend which
> > > uses the API (and is about as old as the RHEV 2.2 API) and a TCP proxy,
> > > but we'd like to move to the standard UI. Currently the console
> > > connection prevents us from doing so.
> > 
> > You could do that with this proposal, if you:
> > 1) DNAT some external-facing IPs to your hypervisor display network IPs
> > 2) resolve display network FQDN to the DNATing machine IPs for external
> > queries.
> 
> I imagine you need 1 external-facing IP per host, which makes it
> expensive to scale since IPv4 space is very limited.

That's the cost of quick-to-implement solution.

If it is possible to have per-host display port range, you could work
this limitation around by setting non-overlapping ranges for each host
and use a single proxy or DNAT machine that would decide which port to
forward based on the range.

David

>  This is why I
> suggested a proxy. In theory this could also be used to modify a forward
> to have seamless host migrations because the end point for the client
> wouldn't change.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel

-- 

David Ja?a, RHCE

SPICE QE based in Brno
GPG Key:     22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24





From ewoud+ovirt at kohlvanwijngaarden.nl  Wed Nov  7 12:42:04 2012
From: ewoud+ovirt at kohlvanwijngaarden.nl (Ewoud Kohl van Wijngaarden)
Date: Wed, 7 Nov 2012 13:42:04 +0100
Subject: [Engine-devel] SPICE IP override
In-Reply-To: <1352288450.13273.87.camel@dhcp-29-7.brq.redhat.com>
References: <2CEBE9E7-1C7A-4E52-AE42-04D51983FF6F@redhat.com>
	<1197121097.6204891.1352278334446.JavaMail.root@redhat.com>
	<20121107101628.GZ2094@bogey.xentower.nl>
	<1352283807.13273.67.camel@dhcp-29-7.brq.redhat.com>
	<20121107110801.GA2094@bogey.xentower.nl>
	<1352288450.13273.87.camel@dhcp-29-7.brq.redhat.com>
Message-ID: <20121107124204.GB2094@bogey.xentower.nl>

On Wed, Nov 07, 2012 at 12:40:50PM +0100, David Ja?a wrote:
> Ewoud Kohl van Wijngaarden p??e v St 07. 11. 2012 v 12:08 +0100:
> > On Wed, Nov 07, 2012 at 11:23:27AM +0100, David Ja?a wrote:
> > > Ewoud Kohl van Wijngaarden p??e v St 07. 11. 2012 v 11:16 +0100:
> > > > On Wed, Nov 07, 2012 at 03:52:14AM -0500, Simon Grinberg wrote:
> > > > > ----- Original Message -----
> > > > > > From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
> > > > > > To: engine-devel at ovirt.org
> > > > > > Sent: Tuesday, November 6, 2012 10:39:58 PM
> > > > > > Subject: [Engine-devel] SPICE IP override
> > > > > >
> > > > > > Hi all,
> > > > > > On behalf of Tomas - please check out the proposal for enhancing our
> > > > > > SPICE integration to allow to return a custom IP/FQDN instead of the
> > > > > > host IP address.
> > > > > > http://wiki.ovirt.org/wiki/Features/Display_Address_Override
> > > > > > All comments are welcome...
> > > > >
> > > > > My 2 cents,
> > > > >
> > > > > This works under the assumption that all the users are either outside
> > > > > of the organization or inside.
> > > > > But think of some of the following scenarios based on a topology where
> > > > > users in the main office are inside the corporate network while users
> > > > > on remote offices / WAN are on a detached different network on the
> > > > > other side of the NAT / public firewall :
> > > > >
> > > > > With current 'per host override' proposal:
> > > > > 1. Admin from the main office won't be able to access the VM console
> > > > > 2. No Mixed environment, meaning that you have to have designated
> > > > >    clusters for remote offices users vs main office users - otherwise
> > > > >    connectivity to the console is determined based on scheduler
> > > > >    decision, or may break by live migration.
> > > > > 3. Based on #2, If I'm a user travelling between offices I'll have to
> > > > >    ask the admin to turn off my VM and move it to internal cluster
> > > > >    before I can reconnect
> > > > >
> > > > > My suggestion is to covert this to 'alternative' IP/FQDN sending the
> > > > > spice client both internal fqdn/ip and the alternative. The spice
> > > > > client should detect which is available of the two and auto-connect.
> > > > >
> > > > > This requires enhancement of the spice client, but still solves all
> > > > > the issues raised above (actually it solves about 90% of the use cases
> > > > > I've heard about in the past).
> > > > >
> > > > > Another alternative is for the engine to 'guess' or 'elect' which to
> > > > > use, alternative or main, based on the IP of the client - meaning
> > > > > admin provides the client ranges for providing internal host address
> > > > > vs alternative - but this is more complicated compared for the
> > > > > previous suggestion
> > > > >
> > > > > Thoughts?
> > > > 
> > > > I agree with where you're going with this. The story I'd like to see
> > > > supported is close to this. We have external customers who should know
> > > > nothing about our internal network, but should be able to access the
> > > > console of their VMs. Currently we do this with a custom frontend which
> > > > uses the API (and is about as old as the RHEV 2.2 API) and a TCP proxy,
> > > > but we'd like to move to the standard UI. Currently the console
> > > > connection prevents us from doing so.
> > > 
> > > You could do that with this proposal, if you:
> > > 1) DNAT some external-facing IPs to your hypervisor display network IPs
> > > 2) resolve display network FQDN to the DNATing machine IPs for external
> > > queries.
> > 
> > I imagine you need 1 external-facing IP per host, which makes it
> > expensive to scale since IPv4 space is very limited.
> 
> That's the cost of quick-to-implement solution.
> 
> If it is possible to have per-host display port range, you could work
> this limitation around by setting non-overlapping ranges for each host
> and use a single proxy or DNAT machine that would decide which port to
> forward based on the range.

I was also thinking about port ranges, but I have no idea how hard it is
to implement. It does sound like a good balance between
quick-to-implement and usability in production.


From emesika at redhat.com  Wed Nov  7 19:43:42 2012
From: emesika at redhat.com (Eli Mesika)
Date: Wed, 7 Nov 2012 14:43:42 -0500 (EST)
Subject: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection
 algorithm for Power Management operations
Message-ID: <647522806.7885833.1352317422827.JavaMail.root@redhat.com>

Hi

Please review , any comments are welcomed

Requirements : http://wiki.ovirt.org/wiki/Features/HostPMProxyPreferences
Detailed Design : http://wiki.ovirt.org/wiki/Features/Design/DetailedHostPMProxyPreferences

DR for this RFE will be next week, exact schedule & place will follow.

Thanks

Eli


From iheim at redhat.com  Thu Nov  8 15:25:48 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 08 Nov 2012 16:25:48 +0100
Subject: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection
 algorithm for Power Management operations
In-Reply-To: <647522806.7885833.1352317422827.JavaMail.root@redhat.com>
References: <647522806.7885833.1352317422827.JavaMail.root@redhat.com>
Message-ID: <509BCEFC.70406@redhat.com>

On 11/07/2012 08:43 PM, Eli Mesika wrote:
> Hi
>
> Please review , any comments are welcomed
>
> Requirements : http://wiki.ovirt.org/wiki/Features/HostPMProxyPreferences
> Detailed Design : http://wiki.ovirt.org/wiki/Features/Design/DetailedHostPMProxyPreferences
>
> DR for this RFE will be next week, exact schedule & place will follow.

1. what's the logic on deciding to move to next proxy ? is it per action 
(restart being comprised of stop and start. can the stop and start 
happen from different proxies)?

2. I'm guessing for 'engine' as proxy, vdsm will be installed with 
engine on same host.

is the plan to teat it as a separate instance of vdsm, listening on a 
separate port, or to assume an all-in-one deployment always?
if it is added as a host, just for fencing, it requires special 
treatment for that host. while if added as a separate instance (on a 
different tcp port), it doesn't have to be defined as a host in the system.

iirc, we can install vdsm, and launch multiple instances of it (at least 
we could in the past).

3. i didn't understand the fqdn/ip proxy mode, if it is not an existing 
host in the system, how will engine communicate with it over secure 
xml/rpc? (i can understand selecting a specific host, but not a text box 
for fqdn/ip).

thanks,
    Itamar


From emesika at redhat.com  Thu Nov  8 16:09:05 2012
From: emesika at redhat.com (Eli Mesika)
Date: Thu, 8 Nov 2012 11:09:05 -0500 (EST)
Subject: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection
 algorithm for Power Management operations
In-Reply-To: <509BCEFC.70406@redhat.com>
Message-ID: <2010870482.8227071.1352390945807.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "Dan Kenigsberg" <danken at redhat.com>
> Sent: Thursday, November 8, 2012 5:25:48 PM
> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
> 
> On 11/07/2012 08:43 PM, Eli Mesika wrote:
> > Hi
> >
> > Please review , any comments are welcomed
> >
> > Requirements :
> > http://wiki.ovirt.org/wiki/Features/HostPMProxyPreferences
> > Detailed Design :
> > http://wiki.ovirt.org/wiki/Features/Design/DetailedHostPMProxyPreferences
> >
> > DR for this RFE will be next week, exact schedule & place will
> > follow.
> 
> 1. what's the logic on deciding to move to next proxy ? is it per
> action
> (restart being comprised of stop and start. can the stop and start
> happen from different proxies)?

Yes, it is per action so stop & start may use different proxies.

> 
> 2. I'm guessing for 'engine' as proxy, vdsm will be installed with
> engine on same host.
> 
> is the plan to teat it as a separate instance of vdsm, listening on a
> separate port, or to assume an all-in-one deployment always?
> if it is added as a host, just for fencing, it requires special
> treatment for that host. while if added as a separate instance (on a
> different tcp port), it doesn't have to be defined as a host in the
> system.
> 
> iirc, we can install vdsm, and launch multiple instances of it (at
> least
> we could in the past).

we have 3 options here 
1) VDSM instance 
2) Lightweight VDSM (with only PM abilities)
3) Accessing the fenece-agents package scripts directly

I have talked with danken , he think we should apply 3)  


> 
> 3. i didn't understand the fqdn/ip proxy mode, if it is not an
> existing
> host in the system, how will engine communicate with it over secure
> xml/rpc? (i can understand selecting a specific host, but not a text
> box
> for fqdn/ip).

Good point, I will change the design accordingly 

> 
> thanks,
>     Itamar
> 


From emesika at redhat.com  Thu Nov  8 16:17:10 2012
From: emesika at redhat.com (Eli Mesika)
Date: Thu, 8 Nov 2012 11:17:10 -0500 (EST)
Subject: [Engine-devel] [Design for 3.2 RFE] Adding support for external
	events
In-Reply-To: <65374848.8228742.1352391200770.JavaMail.root@redhat.com>
Message-ID: <1170459730.8229589.1352391430661.JavaMail.root@redhat.com>

Hi

Please review , any comments are welcomed (please note that API section is still in TBD)

RFE :https://bugzilla.redhat.com/show_bug.cgi?id=873223
Requirements : http://wiki.ovirt.org/wiki/Features/ExternalEvents
Detailed Design :http://wiki.ovirt.org/wiki/Features/Design/DetailedExternalEvents

DR for this RFE will follow.

Thanks

Eli


From iheim at redhat.com  Fri Nov  9 08:38:41 2012
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 09 Nov 2012 09:38:41 +0100
Subject: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection
 algorithm for Power Management operations
In-Reply-To: <647522806.7885833.1352317422827.JavaMail.root@redhat.com>
References: <647522806.7885833.1352317422827.JavaMail.root@redhat.com>
Message-ID: <509CC111.6050608@redhat.com>

On 11/07/2012 08:43 PM, Eli Mesika wrote:
> Hi
>
> Please review , any comments are welcomed
>
> Requirements : http://wiki.ovirt.org/wiki/Features/HostPMProxyPreferences
> Detailed Design : http://wiki.ovirt.org/wiki/Features/Design/DetailedHostPMProxyPreferences
>
> DR for this RFE will be next week, exact schedule & place will follow.
>

some comments on the Detailed part:

 > The default value for this column will be : 'engine,cluster,dc'

1. so if this is not passed via REST API, this will be the default value?
2. i didn't see any comment about backward compatibility/upgrade (since 
the default value now is actually "DC", so setting a different default 
will change behavior in upgrade, which it shouldn't).
3. would it make sense to make this default value per compatibility 
version? otherwise, adding a 3.1 host via API in 3.1 and 3.2 will give 
different behavior (since default for this in 3.1 is "DC").

 > API

we also want to allow defining different types of fencing going forward, 
how will the new API support this (proxy list will be per fence type?).

see note above for default value behavior for api backward compatibility 
as well

 > Installation/Upgrade

see note above for upgrade wrt default value and backward compatibility

 > pre-defined values

I'm not sure how important is the random ip/host vs. engine/cluster/dc.
but if you keep it (and change it to configured hosts in the system), 
then you should keep hosts uuid's.
(it adds complexity, since those hosts can be deleted, and if only such 
a host was defined, it leaves another host without PM configured, so 
you'll be asked to add more and more validations.

my 2 cents: supporting "another specific host", rather than 
engine/cluster/dc is adding complexity, and should be given a valid use 
case to justify that complexity (and even if needed, i'd consider doing 
the implementation in two phases)

 > FenceWrapper

i understand danken suggested going this way, rather than than another 
instance of vdsm.
is vdsm only calling these scripts today and all logic is in engine, or 
does vdsm has any logic in wrapping these scripts (not a blocker to 
doing FenceWrapper, just worth extracting that logic from vdsm to such a 
script, then using it in both. i hope answer is 'no logic'...)


From iheim at redhat.com  Fri Nov  9 08:55:58 2012
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 09 Nov 2012 09:55:58 +0100
Subject: [Engine-devel] [Design for 3.2 RFE] Adding support for external
 events
In-Reply-To: <1170459730.8229589.1352391430661.JavaMail.root@redhat.com>
References: <1170459730.8229589.1352391430661.JavaMail.root@redhat.com>
Message-ID: <509CC51E.5050604@redhat.com>

On 11/08/2012 05:17 PM, Eli Mesika wrote:
> Hi
>
> Please review , any comments are welcomed (please note that API section is still in TBD)
>
> RFE :https://bugzilla.redhat.com/show_bug.cgi?id=873223
> Requirements : http://wiki.ovirt.org/wiki/Features/ExternalEvents

> Events are classified as NORMAL , WARNING or ERROR and UI will display different icon according to that.
any reason to not allow external ALERTs?

> Detailed Design :http://wiki.ovirt.org/wiki/Features/Design/DetailedExternalEvents

> Adding is_external boolean field to audit_log with a default value of false

hmmm, i'm not sure it makes sense to inject any event, just flagging it 
as external.
why not just add a new AuditLogType of 'External' (i.e., just another 
event id?
it is easy enough to search for it, etc.

> New command is exposed currently only to SuperUser

I assume you mean there is a new permission, which by default is added 
only to superuser role, and admin can add it to other custom roles?
I also assume this is only relevant to admin users, not to user roles?

other questions:
1. worth detailing all fields of the event which could be passed to this.
2. can an admin add events to entities they don't have permissions on 
(I'm guessing yes, since admins aren't filtered from seeing all 
entities, so implicitly, they have permission to all entities)
otherwise (if intent is to limit permisisons), an event is an action on 
multiple entities, so for any field which is passed for the event 
(vm_id, (vds)host_id, etc.), you'd need to check admin has 
'AddExternalEvent' permission on.

the main reason i think doing permissions may hold merit is it will 
allow to give this permission by default in more roles, rather than only 
for superuser, which may make it more viable for UI plugins that would 
try to leverage this.

3. REST API modeling for adding an event (is that a PUT on the event 
collection, a POST)?
can it be done only on root events collection, or on events of entities 
as well (taking the entity id from url, rather than as a parameter), etc.


From emesika at redhat.com  Fri Nov  9 09:52:07 2012
From: emesika at redhat.com (Eli Mesika)
Date: Fri, 9 Nov 2012 04:52:07 -0500 (EST)
Subject: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection
 algorithm for Power Management operations
In-Reply-To: <509CC111.6050608@redhat.com>
Message-ID: <2909492.8559766.1352454727559.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "Michael Pasternak" <mpastern at redhat.com>, "Simon Grinberg"
> <sgrinber at redhat.com>, "Dan Kenigsberg" <danken at redhat.com>
> Sent: Friday, November 9, 2012 10:38:41 AM
> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
> 
> On 11/07/2012 08:43 PM, Eli Mesika wrote:
> > Hi
> >
> > Please review , any comments are welcomed
> >
> > Requirements :
> > http://wiki.ovirt.org/wiki/Features/HostPMProxyPreferences
> > Detailed Design :
> > http://wiki.ovirt.org/wiki/Features/Design/DetailedHostPMProxyPreferences
> >
> > DR for this RFE will be next week, exact schedule & place will
> > follow.
> >
> 
> some comments on the Detailed part:
> 
>  > The default value for this column will be : 'engine,cluster,dc'
> 
> 1. so if this is not passed via REST API, this will be the default
> value?

Yes

> 2. i didn't see any comment about backward compatibility/upgrade
> (since
> the default value now is actually "DC", so setting a different
> default
> will change behavior in upgrade, which it shouldn't).
> 3. would it make sense to make this default value per compatibility
> version? otherwise, adding a 3.1 host via API in 3.1 and 3.2 will
> give
> different behavior (since default for this in 3.1 is "DC").

Currently, this default is only reflected in the BLL , but you are right, we should add a new configuration value per version that will have the default value, then we can be backward compatible and support the new default value for 3.2. 
I will add this to the design

> 
>  > API
> 
> we also want to allow defining different types of fencing going
> forward,
> how will the new API support this (proxy list will be per fence
> type?).

I had talked with that with Simon, there is no requirement for a proxy list per agent type.
The RFE of supporting secondary agent per Host is orthogonal to this RFE as well
> 
> see note above for default value behavior for api backward
> compatibility
> as well
> 
>  > Installation/Upgrade
> 
> see note above for upgrade wrt default value and backward
> compatibility

OK, see my comments above...

> 
>  > pre-defined values
> 
> I'm not sure how important is the random ip/host vs.
> engine/cluster/dc.
> but if you keep it (and change it to configured hosts in the system),
> then you should keep hosts uuid's.
> (it adds complexity, since those hosts can be deleted, and if only
> such
> a host was defined, it leaves another host without PM configured, so
> you'll be asked to add more and more validations.
> 
> my 2 cents: supporting "another specific host", rather than
> engine/cluster/dc is adding complexity, and should be given a valid
> use
> case to justify that complexity (and even if needed, i'd consider
> doing
> the implementation in two phases)

Agree, this will be much simpler ...
Simon, if you have no objection to that, I will change it to support only engine,cluster,datacenter for now...

> 
>  > FenceWrapper
> 
> i understand danken suggested going this way, rather than than
> another
> instance of vdsm.
> is vdsm only calling these scripts today and all logic is in engine,
> or
> does vdsm has any logic in wrapping these scripts (not a blocker to
> doing FenceWrapper, just worth extracting that logic from vdsm to
> such a
> script, then using it in both. i hope answer is 'no logic'...)

vdsm has some logic that maps between the call passed to it from engine and the actual parameters generated for the script.
AFAIK, this logic only "builds" the correct arguments for the command according to the agent type 

> 


From iheim at redhat.com  Fri Nov  9 10:02:37 2012
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 09 Nov 2012 11:02:37 +0100
Subject: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection
 algorithm for Power Management operations
In-Reply-To: <2909492.8559766.1352454727559.JavaMail.root@redhat.com>
References: <2909492.8559766.1352454727559.JavaMail.root@redhat.com>
Message-ID: <509CD4BD.4010606@redhat.com>

On 11/09/2012 10:52 AM, Eli Mesika wrote:

>> >
>> >  > FenceWrapper
>> >
>> >i understand danken suggested going this way, rather than than
>> >another
>> >instance of vdsm.
>> >is vdsm only calling these scripts today and all logic is in engine,
>> >or
>> >does vdsm has any logic in wrapping these scripts (not a blocker to
>> >doing FenceWrapper, just worth extracting that logic from vdsm to
>> >such a
>> >script, then using it in both. i hope answer is 'no logic'...)
> vdsm has some logic that maps between the call passed to it from engine and the actual parameters generated for the script.
> AFAIK, this logic only "builds" the correct arguments for the command according to the agent type
>

can we extract it to an external wrapper?
I'd hate to fix bugs/changes twice for this.


From emesika at redhat.com  Fri Nov  9 10:06:05 2012
From: emesika at redhat.com (Eli Mesika)
Date: Fri, 9 Nov 2012 05:06:05 -0500 (EST)
Subject: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection
 algorithm for Power Management operations
In-Reply-To: <509CD4BD.4010606@redhat.com>
Message-ID: <1357032386.8570374.1352455565925.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "Michael Pasternak" <mpastern at redhat.com>, "Simon Grinberg"
> <sgrinber at redhat.com>, "Dan Kenigsberg" <danken at redhat.com>
> Sent: Friday, November 9, 2012 12:02:37 PM
> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
> 
> On 11/09/2012 10:52 AM, Eli Mesika wrote:
> 
> >> >
> >> >  > FenceWrapper
> >> >
> >> >i understand danken suggested going this way, rather than than
> >> >another
> >> >instance of vdsm.
> >> >is vdsm only calling these scripts today and all logic is in
> >> >engine,
> >> >or
> >> >does vdsm has any logic in wrapping these scripts (not a blocker
> >> >to
> >> >doing FenceWrapper, just worth extracting that logic from vdsm to
> >> >such a
> >> >script, then using it in both. i hope answer is 'no logic'...)
> > vdsm has some logic that maps between the call passed to it from
> > engine and the actual parameters generated for the script.
> > AFAIK, this logic only "builds" the correct arguments for the
> > command according to the agent type
> >
> 
> can we extract it to an external wrapper?
> I'd hate to fix bugs/changes twice for this.

I'll check it with danken on SUN

> 


From sander at hoentjen.eu  Fri Nov  9 16:07:39 2012
From: sander at hoentjen.eu (Sander Hoentjen)
Date: Fri, 09 Nov 2012 17:07:39 +0100
Subject: [Engine-devel] SPICE IP override
In-Reply-To: <1352288450.13273.87.camel@dhcp-29-7.brq.redhat.com>
References: <2CEBE9E7-1C7A-4E52-AE42-04D51983FF6F@redhat.com>
	<1197121097.6204891.1352278334446.JavaMail.root@redhat.com>
	<20121107101628.GZ2094@bogey.xentower.nl>
	<1352283807.13273.67.camel@dhcp-29-7.brq.redhat.com>
	<20121107110801.GA2094@bogey.xentower.nl>
	<1352288450.13273.87.camel@dhcp-29-7.brq.redhat.com>
Message-ID: <1352477259.24625.15.camel@peecee.hoentjen.eu>

On Wed, 2012-11-07 at 12:40 +0100, David Ja?a wrote:
> Ewoud Kohl van Wijngaarden p??e v St 07. 11. 2012 v 12:08 +0100:
> > On Wed, Nov 07, 2012 at 11:23:27AM +0100, David Ja?a wrote:
> > > Ewoud Kohl van Wijngaarden p??e v St 07. 11. 2012 v 11:16 +0100:
> > > > On Wed, Nov 07, 2012 at 03:52:14AM -0500, Simon Grinberg wrote:
> > > > > ----- Original Message -----
> > > > > > From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
> > > > > > To: engine-devel at ovirt.org
> > > > > > Sent: Tuesday, November 6, 2012 10:39:58 PM
> > > > > > Subject: [Engine-devel] SPICE IP override
> > > > > >
> > > > > > Hi all,
> > > > > > On behalf of Tomas - please check out the proposal for enhancing our
> > > > > > SPICE integration to allow to return a custom IP/FQDN instead of the
> > > > > > host IP address.
> > > > > > http://wiki.ovirt.org/wiki/Features/Display_Address_Override
> > > > > > All comments are welcome...
> > > > >
> > > > > My 2 cents,
> > > > >
> > > > > This works under the assumption that all the users are either outside
> > > > > of the organization or inside.
> > > > > But think of some of the following scenarios based on a topology where
> > > > > users in the main office are inside the corporate network while users
> > > > > on remote offices / WAN are on a detached different network on the
> > > > > other side of the NAT / public firewall :
> > > > >
> > > > > With current 'per host override' proposal:
> > > > > 1. Admin from the main office won't be able to access the VM console
> > > > > 2. No Mixed environment, meaning that you have to have designated
> > > > >    clusters for remote offices users vs main office users - otherwise
> > > > >    connectivity to the console is determined based on scheduler
> > > > >    decision, or may break by live migration.
> > > > > 3. Based on #2, If I'm a user travelling between offices I'll have to
> > > > >    ask the admin to turn off my VM and move it to internal cluster
> > > > >    before I can reconnect
> > > > >
> > > > > My suggestion is to covert this to 'alternative' IP/FQDN sending the
> > > > > spice client both internal fqdn/ip and the alternative. The spice
> > > > > client should detect which is available of the two and auto-connect.
> > > > >
> > > > > This requires enhancement of the spice client, but still solves all
> > > > > the issues raised above (actually it solves about 90% of the use cases
> > > > > I've heard about in the past).
> > > > >
> > > > > Another alternative is for the engine to 'guess' or 'elect' which to
> > > > > use, alternative or main, based on the IP of the client - meaning
> > > > > admin provides the client ranges for providing internal host address
> > > > > vs alternative - but this is more complicated compared for the
> > > > > previous suggestion
> > > > >
> > > > > Thoughts?
> > > > 
> > > > I agree with where you're going with this. The story I'd like to see
> > > > supported is close to this. We have external customers who should know
> > > > nothing about our internal network, but should be able to access the
> > > > console of their VMs. Currently we do this with a custom frontend which
> > > > uses the API (and is about as old as the RHEV 2.2 API) and a TCP proxy,
> > > > but we'd like to move to the standard UI. Currently the console
> > > > connection prevents us from doing so.
> > > 
> > > You could do that with this proposal, if you:
> > > 1) DNAT some external-facing IPs to your hypervisor display network IPs
> > > 2) resolve display network FQDN to the DNATing machine IPs for external
> > > queries.
> > 
> > I imagine you need 1 external-facing IP per host, which makes it
> > expensive to scale since IPv4 space is very limited.
> 
> That's the cost of quick-to-implement solution.
> 
> If it is possible to have per-host display port range, you could work
> this limitation around by setting non-overlapping ranges for each host
> and use a single proxy or DNAT machine that would decide which port to
> forward based on the range.

I am a colleague of Ewoud, and want to explain a bit more about how we
currently have implemented this.
All our virtualization hosts, but also the manager only live in the
internal network. We have written a webapplication that is a
self-service portal for our customers. This webapplication lives on a
host that is publicly reachable. This host can also reach the
virtualization servers on the internal network. Now for all actions
except for viewing a console the webhost only needs to access the api,
so what happens when a user wants to view the console (we currently use
vnc):
On the webhost we have reserved a number of ports.
Api request is made to get the host/port, and we set the ticket (vnc
password).
We create a tunnel (currently use socat, but can of course also be DNAT
or any kind of proxy) that connects one of the free ports on the
external webhost to the host/port combo we got back from the api.
This is a very simple implementation, but it works well in our
experience.

For added points you can make the proxy smarter, things like handling vm
migrations and maybe adding websockets support for a html5 spice
client ;)

Kind regards,
Sander





From djasa at redhat.com  Fri Nov  9 16:38:17 2012
From: djasa at redhat.com (David =?UTF-8?Q?Ja=C5=A1a?=)
Date: Fri, 09 Nov 2012 17:38:17 +0100
Subject: [Engine-devel] SPICE IP override
In-Reply-To: <1352477259.24625.15.camel@peecee.hoentjen.eu>
References: <2CEBE9E7-1C7A-4E52-AE42-04D51983FF6F@redhat.com>
	<1197121097.6204891.1352278334446.JavaMail.root@redhat.com>
	<20121107101628.GZ2094@bogey.xentower.nl>
	<1352283807.13273.67.camel@dhcp-29-7.brq.redhat.com>
	<20121107110801.GA2094@bogey.xentower.nl>
	<1352288450.13273.87.camel@dhcp-29-7.brq.redhat.com>
	<1352477259.24625.15.camel@peecee.hoentjen.eu>
Message-ID: <1352479097.13273.266.camel@dhcp-29-7.brq.redhat.com>

Sander Hoentjen p??e v P? 09. 11. 2012 v 17:07 +0100:
> On Wed, 2012-11-07 at 12:40 +0100, David Ja?a wrote:
> > Ewoud Kohl van Wijngaarden p??e v St 07. 11. 2012 v 12:08 +0100:
> > > On Wed, Nov 07, 2012 at 11:23:27AM +0100, David Ja?a wrote:
> > > > Ewoud Kohl van Wijngaarden p??e v St 07. 11. 2012 v 11:16 +0100:
> > > > > On Wed, Nov 07, 2012 at 03:52:14AM -0500, Simon Grinberg wrote:
> > > > > > ----- Original Message -----
> > > > > > > From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
> > > > > > > To: engine-devel at ovirt.org
> > > > > > > Sent: Tuesday, November 6, 2012 10:39:58 PM
> > > > > > > Subject: [Engine-devel] SPICE IP override
> > > > > > >
> > > > > > > Hi all,
> > > > > > > On behalf of Tomas - please check out the proposal for enhancing our
> > > > > > > SPICE integration to allow to return a custom IP/FQDN instead of the
> > > > > > > host IP address.
> > > > > > > http://wiki.ovirt.org/wiki/Features/Display_Address_Override
> > > > > > > All comments are welcome...
> > > > > >
> > > > > > My 2 cents,
> > > > > >
> > > > > > This works under the assumption that all the users are either outside
> > > > > > of the organization or inside.
> > > > > > But think of some of the following scenarios based on a topology where
> > > > > > users in the main office are inside the corporate network while users
> > > > > > on remote offices / WAN are on a detached different network on the
> > > > > > other side of the NAT / public firewall :
> > > > > >
> > > > > > With current 'per host override' proposal:
> > > > > > 1. Admin from the main office won't be able to access the VM console
> > > > > > 2. No Mixed environment, meaning that you have to have designated
> > > > > >    clusters for remote offices users vs main office users - otherwise
> > > > > >    connectivity to the console is determined based on scheduler
> > > > > >    decision, or may break by live migration.
> > > > > > 3. Based on #2, If I'm a user travelling between offices I'll have to
> > > > > >    ask the admin to turn off my VM and move it to internal cluster
> > > > > >    before I can reconnect
> > > > > >
> > > > > > My suggestion is to covert this to 'alternative' IP/FQDN sending the
> > > > > > spice client both internal fqdn/ip and the alternative. The spice
> > > > > > client should detect which is available of the two and auto-connect.
> > > > > >
> > > > > > This requires enhancement of the spice client, but still solves all
> > > > > > the issues raised above (actually it solves about 90% of the use cases
> > > > > > I've heard about in the past).
> > > > > >
> > > > > > Another alternative is for the engine to 'guess' or 'elect' which to
> > > > > > use, alternative or main, based on the IP of the client - meaning
> > > > > > admin provides the client ranges for providing internal host address
> > > > > > vs alternative - but this is more complicated compared for the
> > > > > > previous suggestion
> > > > > >
> > > > > > Thoughts?
> > > > > 
> > > > > I agree with where you're going with this. The story I'd like to see
> > > > > supported is close to this. We have external customers who should know
> > > > > nothing about our internal network, but should be able to access the
> > > > > console of their VMs. Currently we do this with a custom frontend which
> > > > > uses the API (and is about as old as the RHEV 2.2 API) and a TCP proxy,
> > > > > but we'd like to move to the standard UI. Currently the console
> > > > > connection prevents us from doing so.
> > > > 
> > > > You could do that with this proposal, if you:
> > > > 1) DNAT some external-facing IPs to your hypervisor display network IPs
> > > > 2) resolve display network FQDN to the DNATing machine IPs for external
> > > > queries.
> > > 
> > > I imagine you need 1 external-facing IP per host, which makes it
> > > expensive to scale since IPv4 space is very limited.
> > 
> > That's the cost of quick-to-implement solution.
> > 
> > If it is possible to have per-host display port range, you could work
> > this limitation around by setting non-overlapping ranges for each host
> > and use a single proxy or DNAT machine that would decide which port to
> > forward based on the range.
> 
> I am a colleague of Ewoud, and want to explain a bit more about how we
> currently have implemented this.
> All our virtualization hosts, but also the manager only live in the
> internal network. We have written a webapplication that is a
> self-service portal for our customers. This webapplication lives on a
> host that is publicly reachable. This host can also reach the
> virtualization servers on the internal network. Now for all actions
> except for viewing a console the webhost only needs to access the api,
> so what happens when a user wants to view the console (we currently use
> vnc):
> On the webhost we have reserved a number of ports.
> Api request is made to get the host/port, and we set the ticket (vnc
> password).
> We create a tunnel (currently use socat, but can of course also be DNAT
> or any kind of proxy) that connects one of the free ports on the
> external webhost to the host/port combo we got back from the api.
> This is a very simple implementation, but it works well in our
> experience.

This would work with spice as well apart from one thing -- migration. To
support it really cleanly in these cases, one of these two things would
have to exist:
      * spice proxy that would handle migrations on client behalf (but
        then you'd lose end-to-end encryption)
      * tweak to libvirt and vdsm and engine (engine via upcoming engine
        plugins maybe?) so that when migration with connected client is
        about to begin, vdsm will ask engine for external ip/fqdn:port
        that will match the ports it is about to configure for qemu and
        instruct libvirt to send these values to client_migrate_info
        qemu command instead of direct host/port/tls-port values.

2nd way seems more appropriate to me but the "ask engine to ask for
external ip and ports" sounds like something that won't be easy to get
properly.

David

> 
> For added points you can make the proxy smarter, things like handling vm
> migrations and maybe adding websockets support for a html5 spice
> client ;)
> 
> Kind regards,
> Sander
> 
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel

-- 

David Ja?a, RHCE

SPICE QE based in Brno
GPG Key:     22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24





From ykaul at redhat.com  Fri Nov  9 18:30:52 2012
From: ykaul at redhat.com (Yaniv Kaul)
Date: Fri, 09 Nov 2012 20:30:52 +0200
Subject: [Engine-devel] SPICE IP override
In-Reply-To: <509A340E.9040901@redhat.com>
References: <1190246211.6251087.1352281945100.JavaMail.root@redhat.com>
	<509A340E.9040901@redhat.com>
Message-ID: <509D4BDC.7070801@redhat.com>

On 11/07/2012 12:12 PM, Itamar Heim wrote:
> On 11/07/2012 10:52 AM, Simon Grinberg wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Itamar Heim" <iheim at redhat.com>
>>> To: "Simon Grinberg" <simon at redhat.com>
>>> Cc: engine-devel at ovirt.org
>>> Sent: Wednesday, November 7, 2012 10:46:24 AM
>>> Subject: Re: [Engine-devel] SPICE IP override
>>>
>>> On 11/07/2012 09:52 AM, Simon Grinberg wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
>>>>> To: engine-devel at ovirt.org
>>>>> Sent: Tuesday, November 6, 2012 10:39:58 PM
>>>>> Subject: [Engine-devel] SPICE IP override
>>>>>
>>>>> Hi all,
>>>>> On behalf of Tomas - please check out the proposal for enhancing
>>>>> our
>>>>> SPICE integration to allow to return a custom IP/FQDN instead of
>>>>> the
>>>>> host IP address.
>>>>> http://wiki.ovirt.org/wiki/Features/Display_Address_Override
>>>>> All comments are welcome...
>>>>
>>>> My 2 cents,
>>>>
>>>> This works under the assumption that all the users are either
>>>> outside of the organization or inside.
>>>> But think of some of the following scenarios based on a topology
>>>> where users in the main office are inside the corporate network
>>>> while users on remote offices / WAN are on a detached different
>>>> network on the other side of the NAT / public firewall :
>>>>
>>>> With current 'per host override' proposal:
>>>> 1. Admin from the main office won't be able to access the VM
>>>> console
>>>> 2. No Mixed environment, meaning that you have to have designated
>>>> clusters for remote offices users vs main office users - otherwise
>>>> connectivity to the console is determined based on scheduler
>>>> decision, or may break by live migration.
>>>> 3. Based on #2, If I'm a user travelling between offices I'll have
>>>> to ask the admin to turn off my VM and move it to internal cluster
>>>> before I can reconnect
>>>>
>>>> My suggestion is to covert this to 'alternative' IP/FQDN sending
>>>> the spice client both internal fqdn/ip and the alternative. The
>>>> spice client should detect which is available of the two and
>>>> auto-connect.
>>>>
>>>> This requires enhancement of the spice client, but still solves all
>>>> the issues raised above (actually it solves about 90% of the use
>>>> cases I've heard about in the past).
>>>>
>>>> Another alternative is for the engine to 'guess' or 'elect' which
>>>> to use, alternative or main, based on the IP of the client -
>>>> meaning admin provides the client ranges for providing internal
>>>> host address vs alternative - but this is more complicated
>>>> compared for the previous suggestion
>>>>
>>>> Thoughts?
>>>
>>> i think this is over complicating things.
>>> I'd expect someone that wants to handle internal and external
>>> differently to use DNS, and resolve the DNS differently for external
>>> and
>>> internal clients.
>>
>> That will not necessarily solve the issue - what about WAN users from 
>> home? the DNS is not under their control -> they need redirection to 
>> the public facing NAT servers.
>
> if a public service, not relevant.
> if a private service, i expect they would be using a VPN, with dns 
> resolution provided by the organization for external vpn users, if 
> they need to resolve IPs differently internally and externally.

If they are using VPN, they don't need all that NAT stuff. If they are 
using VPN and STILL need that NAT stuff, it is probably on the same box 
(FW+NAT+VPN), and then it's a non-issue. If the VPN and the NAT is NOT 
on the same setup, best of luck to them.
Y.

>
>>
>> + At least currently (and this must change, unless you accept the 
>> proposal I've raised) the engine sends fqdn if the display network in 
>> on the engine management network and IP on any other selected 
>> Display-Network.
>
> not with this patch, which sends the dns the admin configured, 
> regardless of display logical network used.
>
>>
>> No DNS will help you in this case, so you still need alternate FQDN.
>>
>>>
>>> (note this is different from specifying the spice proxy address at
>>> cluster level, which is something you want user to choose if they
>>> want
>>> to enable or not per their location)
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From deadhorseconsulting at gmail.com  Fri Nov  9 20:28:18 2012
From: deadhorseconsulting at gmail.com (Dead Horse)
Date: Fri, 9 Nov 2012 14:28:18 -0600
Subject: [Engine-devel] engine database upgrade failure with latest
Message-ID: <CAEWPe=ompc9NNOrt0RFgn2KFDiPNDAgyzq23DBADN6ZOETR3iQ@mail.gmail.com>

I built the latest ovirt-engine from GIT and attempted to upgrade. Version
that I attempting to upgrade was built Monday from master (commit:
a665ec3af7b2dd04e80007b1c062868d3e049fce).

Below is the what was logged by engine-upgrade:
2012-11-09 14:15:54::DEBUG::engine-upgrade::425::root:: DB Update started
2012-11-09 14:15:54::DEBUG::common_utils::390::root:: Executing command -->
'/usr/share/ovirt-engine/dbscripts/upgrade.sh -s localhost -p 5432 -u
engine -d engine_2012_11_09_14_12_52'
2012-11-09 14:15:58::DEBUG::common_utils::428::root:: output = upgrade
script detected a change in Config, View or Stored Procedure...

2012-11-09 14:15:58::DEBUG::common_utils::429::root:: stderr =
psql:create_functions.sql:666: ERROR:  must be owner of function
uuid_generate_v1

2012-11-09 14:15:58::DEBUG::common_utils::430::root:: retcode = 3
2012-11-09 14:15:58::ERROR::engine-upgrade::1072::root:: Traceback (most
recent call last):
  File "/usr/bin/engine-upgrade", line 1059, in main
    runFunc([db.update], MSG_INFO_DB_UPDATE)
  File "/usr/bin/engine-upgrade", line 607, in runFunc
    func()
  File "/usr/bin/engine-upgrade", line 442, in update
    output, rc = utils.execCmd(cmdList=cmd, failOnError=True,
msg=MSG_ERROR_UPDATE_DB)
  File "/usr/share/ovirt-engine/scripts/common_utils.py", line 433, in
execCmd
    raise Exception(msg)
Exception: Error: Database update failed

 - DHC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121109/b37b23cd/attachment.html>

From alonbl at redhat.com  Fri Nov  9 20:32:11 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Fri, 9 Nov 2012 15:32:11 -0500 (EST)
Subject: [Engine-devel] engine database upgrade failure with latest
In-Reply-To: <CAEWPe=ompc9NNOrt0RFgn2KFDiPNDAgyzq23DBADN6ZOETR3iQ@mail.gmail.com>
Message-ID: <120348863.8209230.1352493131554.JavaMail.root@redhat.com>


Strange...

This[1] patch should have solved this. It is merged to master.
Are you using master?

[1] http://gerrit.ovirt.org/#/c/8955/

----- Original Message -----
> From: "Dead Horse" <deadhorseconsulting at gmail.com>
> To: engine-devel at ovirt.org
> Sent: Friday, November 9, 2012 10:28:18 PM
> Subject: [Engine-devel] engine database upgrade failure with latest
> 
> 
> I built the latest ovirt-engine from GIT and attempted to upgrade.
> Version that I attempting to upgrade was built Monday from master
> (commit: a665ec3af7b2dd04e80007b1c062868d3e049fce).
> 
> Below is the what was logged by engine-upgrade:
> 2012-11-09 14:15:54::DEBUG::engine-upgrade::425::root:: DB Update
> started
> 2012-11-09 14:15:54::DEBUG::common_utils::390::root:: Executing
> command --> '/usr/share/ovirt-engine/dbscripts/upgrade.sh -s
> localhost -p 5432 -u engine -d engine_2012_11_09_14_12_52'
> 2012-11-09 14:15:58::DEBUG::common_utils::428::root:: output =
> upgrade script detected a change in Config, View or Stored
> Procedure...
> 
> 2012-11-09 14:15:58::DEBUG::common_utils::429::root:: stderr =
> psql:create_functions.sql:666: ERROR: must be owner of function
> uuid_generate_v1
> 
> 2012-11-09 14:15:58::DEBUG::common_utils::430::root:: retcode = 3
> 2012-11-09 14:15:58::ERROR::engine-upgrade::1072::root:: Traceback
> (most recent call last):
> File "/usr/bin/engine-upgrade", line 1059, in main
> runFunc([db.update], MSG_INFO_DB_UPDATE)
> File "/usr/bin/engine-upgrade", line 607, in runFunc
> func()
> File "/usr/bin/engine-upgrade", line 442, in update
> output, rc = utils.execCmd(cmdList=cmd, failOnError=True,
> msg=MSG_ERROR_UPDATE_DB)
> File "/usr/share/ovirt-engine/scripts/common_utils.py", line 433, in
> execCmd
> raise Exception(msg)
> Exception: Error: Database update failed
> 
> - DHC
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From deadhorseconsulting at gmail.com  Fri Nov  9 20:42:28 2012
From: deadhorseconsulting at gmail.com (Dead Horse)
Date: Fri, 9 Nov 2012 14:42:28 -0600
Subject: [Engine-devel] engine database upgrade failure with latest
In-Reply-To: <120348863.8209230.1352493131554.JavaMail.root@redhat.com>
References: <CAEWPe=ompc9NNOrt0RFgn2KFDiPNDAgyzq23DBADN6ZOETR3iQ@mail.gmail.com>
	<120348863.8209230.1352493131554.JavaMail.root@redhat.com>
Message-ID: <CAEWPe=rdCPYU37J73kXMZhf0rm7oRjG8VPzk6z7jAyJ+go61Yg@mail.gmail.com>

cloned via git clone http://gerrit.ovirt.org/p/ovirt-engine (so master by
default)
current master commit appears to me as:
commit2dc9b518099ec1ac3995abf1483f43cdcb6eb2b8


On Fri, Nov 9, 2012 at 2:32 PM, Alon Bar-Lev <alonbl at redhat.com> wrote:

>
> Strange...
>
> This[1] patch should have solved this. It is merged to master.
> Are you using master?
>
> [1] http://gerrit.ovirt.org/#/c/8955/
>
> ----- Original Message -----
> > From: "Dead Horse" <deadhorseconsulting at gmail.com>
> > To: engine-devel at ovirt.org
> > Sent: Friday, November 9, 2012 10:28:18 PM
> > Subject: [Engine-devel] engine database upgrade failure with latest
> >
> >
> > I built the latest ovirt-engine from GIT and attempted to upgrade.
> > Version that I attempting to upgrade was built Monday from master
> > (commit: a665ec3af7b2dd04e80007b1c062868d3e049fce).
> >
> > Below is the what was logged by engine-upgrade:
> > 2012-11-09 14:15:54::DEBUG::engine-upgrade::425::root:: DB Update
> > started
> > 2012-11-09 14:15:54::DEBUG::common_utils::390::root:: Executing
> > command --> '/usr/share/ovirt-engine/dbscripts/upgrade.sh -s
> > localhost -p 5432 -u engine -d engine_2012_11_09_14_12_52'
> > 2012-11-09 14:15:58::DEBUG::common_utils::428::root:: output =
> > upgrade script detected a change in Config, View or Stored
> > Procedure...
> >
> > 2012-11-09 14:15:58::DEBUG::common_utils::429::root:: stderr =
> > psql:create_functions.sql:666: ERROR: must be owner of function
> > uuid_generate_v1
> >
> > 2012-11-09 14:15:58::DEBUG::common_utils::430::root:: retcode = 3
> > 2012-11-09 14:15:58::ERROR::engine-upgrade::1072::root:: Traceback
> > (most recent call last):
> > File "/usr/bin/engine-upgrade", line 1059, in main
> > runFunc([db.update], MSG_INFO_DB_UPDATE)
> > File "/usr/bin/engine-upgrade", line 607, in runFunc
> > func()
> > File "/usr/bin/engine-upgrade", line 442, in update
> > output, rc = utils.execCmd(cmdList=cmd, failOnError=True,
> > msg=MSG_ERROR_UPDATE_DB)
> > File "/usr/share/ovirt-engine/scripts/common_utils.py", line 433, in
> > execCmd
> > raise Exception(msg)
> > Exception: Error: Database update failed
> >
> > - DHC
> >
> >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121109/366db237/attachment.html>

From alonbl at redhat.com  Fri Nov  9 20:49:24 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Fri, 9 Nov 2012 15:49:24 -0500 (EST)
Subject: [Engine-devel] engine database upgrade failure with latest
In-Reply-To: <CAEWPe=rdCPYU37J73kXMZhf0rm7oRjG8VPzk6z7jAyJ+go61Yg@mail.gmail.com>
Message-ID: <210237391.8211710.1352494164990.JavaMail.root@redhat.com>

You wrote version from Monday... (a665ec3af7b2dd04e80007b1c062868d3e049fce)
Which was before patch was applied.

----- Original Message -----
> From: "Dead Horse" <deadhorseconsulting at gmail.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Friday, November 9, 2012 10:42:28 PM
> Subject: Re: [Engine-devel] engine database upgrade failure with latest
> 
> cloned via git clone http://gerrit.ovirt.org/p/ovirt-engine (so
> master by default)
> current master commit appears to me as:
> commit 	2dc9b518099ec1ac3995abf1483f43cdcb6eb2b8
> 
> 
> 
> On Fri, Nov 9, 2012 at 2:32 PM, Alon Bar-Lev < alonbl at redhat.com >
> wrote:
> 
> 
> 
> Strange...
> 
> This[1] patch should have solved this. It is merged to master.
> Are you using master?
> 
> [1] http://gerrit.ovirt.org/#/c/8955/
> 
> 
> 
> ----- Original Message -----
> > From: "Dead Horse" < deadhorseconsulting at gmail.com >
> > To: engine-devel at ovirt.org
> > Sent: Friday, November 9, 2012 10:28:18 PM
> > Subject: [Engine-devel] engine database upgrade failure with latest
> > 
> > 
> > I built the latest ovirt-engine from GIT and attempted to upgrade.
> > Version that I attempting to upgrade was built Monday from master
> > (commit: a665ec3af7b2dd04e80007b1c062868d3e049fce).
> > 
> > Below is the what was logged by engine-upgrade:
> > 2012-11-09 14:15:54::DEBUG::engine-upgrade::425::root:: DB Update
> > started
> > 2012-11-09 14:15:54::DEBUG::common_utils::390::root:: Executing
> > command --> '/usr/share/ovirt-engine/dbscripts/upgrade.sh -s
> > localhost -p 5432 -u engine -d engine_2012_11_09_14_12_52'
> > 2012-11-09 14:15:58::DEBUG::common_utils::428::root:: output =
> > upgrade script detected a change in Config, View or Stored
> > Procedure...
> > 
> > 2012-11-09 14:15:58::DEBUG::common_utils::429::root:: stderr =
> > psql:create_functions.sql:666: ERROR: must be owner of function
> > uuid_generate_v1
> > 
> > 2012-11-09 14:15:58::DEBUG::common_utils::430::root:: retcode = 3
> > 2012-11-09 14:15:58::ERROR::engine-upgrade::1072::root:: Traceback
> > (most recent call last):
> > File "/usr/bin/engine-upgrade", line 1059, in main
> > runFunc([db.update], MSG_INFO_DB_UPDATE)
> > File "/usr/bin/engine-upgrade", line 607, in runFunc
> > func()
> > File "/usr/bin/engine-upgrade", line 442, in update
> > output, rc = utils.execCmd(cmdList=cmd, failOnError=True,
> > msg=MSG_ERROR_UPDATE_DB)
> > File "/usr/share/ovirt-engine/scripts/common_utils.py", line 433,
> > in
> > execCmd
> > raise Exception(msg)
> > Exception: Error: Database update failed
> > 
> > - DHC
> > 
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 
> 


From deadhorseconsulting at gmail.com  Fri Nov  9 20:52:32 2012
From: deadhorseconsulting at gmail.com (Dead Horse)
Date: Fri, 9 Nov 2012 14:52:32 -0600
Subject: [Engine-devel] engine database upgrade failure with latest
In-Reply-To: <210237391.8211710.1352494164990.JavaMail.root@redhat.com>
References: <CAEWPe=rdCPYU37J73kXMZhf0rm7oRjG8VPzk6z7jAyJ+go61Yg@mail.gmail.com>
	<210237391.8211710.1352494164990.JavaMail.root@redhat.com>
Message-ID: <CAEWPe=og6zfr05Ji2xDPDPSKbisY5KcXYpU27C1G5kLPZFnMmA@mail.gmail.com>

Correct the version I am attempting to upgrade was built from master on
Monday. I just built master from today and attempted to upgrade the running
instance I built from master on Monday.


On Fri, Nov 9, 2012 at 2:49 PM, Alon Bar-Lev <alonbl at redhat.com> wrote:

> You wrote version from Monday... (a665ec3af7b2dd04e80007b1c062868d3e049fce)
> Which was before patch was applied.
>
> ----- Original Message -----
> > From: "Dead Horse" <deadhorseconsulting at gmail.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Friday, November 9, 2012 10:42:28 PM
> > Subject: Re: [Engine-devel] engine database upgrade failure with latest
> >
> > cloned via git clone http://gerrit.ovirt.org/p/ovirt-engine (so
> > master by default)
> > current master commit appears to me as:
> > commit        2dc9b518099ec1ac3995abf1483f43cdcb6eb2b8
> >
> >
> >
> > On Fri, Nov 9, 2012 at 2:32 PM, Alon Bar-Lev < alonbl at redhat.com >
> > wrote:
> >
> >
> >
> > Strange...
> >
> > This[1] patch should have solved this. It is merged to master.
> > Are you using master?
> >
> > [1] http://gerrit.ovirt.org/#/c/8955/
> >
> >
> >
> > ----- Original Message -----
> > > From: "Dead Horse" < deadhorseconsulting at gmail.com >
> > > To: engine-devel at ovirt.org
> > > Sent: Friday, November 9, 2012 10:28:18 PM
> > > Subject: [Engine-devel] engine database upgrade failure with latest
> > >
> > >
> > > I built the latest ovirt-engine from GIT and attempted to upgrade.
> > > Version that I attempting to upgrade was built Monday from master
> > > (commit: a665ec3af7b2dd04e80007b1c062868d3e049fce).
> > >
> > > Below is the what was logged by engine-upgrade:
> > > 2012-11-09 14:15:54::DEBUG::engine-upgrade::425::root:: DB Update
> > > started
> > > 2012-11-09 14:15:54::DEBUG::common_utils::390::root:: Executing
> > > command --> '/usr/share/ovirt-engine/dbscripts/upgrade.sh -s
> > > localhost -p 5432 -u engine -d engine_2012_11_09_14_12_52'
> > > 2012-11-09 14:15:58::DEBUG::common_utils::428::root:: output =
> > > upgrade script detected a change in Config, View or Stored
> > > Procedure...
> > >
> > > 2012-11-09 14:15:58::DEBUG::common_utils::429::root:: stderr =
> > > psql:create_functions.sql:666: ERROR: must be owner of function
> > > uuid_generate_v1
> > >
> > > 2012-11-09 14:15:58::DEBUG::common_utils::430::root:: retcode = 3
> > > 2012-11-09 14:15:58::ERROR::engine-upgrade::1072::root:: Traceback
> > > (most recent call last):
> > > File "/usr/bin/engine-upgrade", line 1059, in main
> > > runFunc([db.update], MSG_INFO_DB_UPDATE)
> > > File "/usr/bin/engine-upgrade", line 607, in runFunc
> > > func()
> > > File "/usr/bin/engine-upgrade", line 442, in update
> > > output, rc = utils.execCmd(cmdList=cmd, failOnError=True,
> > > msg=MSG_ERROR_UPDATE_DB)
> > > File "/usr/share/ovirt-engine/scripts/common_utils.py", line 433,
> > > in
> > > execCmd
> > > raise Exception(msg)
> > > Exception: Error: Database update failed
> > >
> > > - DHC
> > >
> > >
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121109/2d48cf81/attachment.html>

From deadhorseconsulting at gmail.com  Fri Nov  9 21:10:46 2012
From: deadhorseconsulting at gmail.com (Dead Horse)
Date: Fri, 9 Nov 2012 15:10:46 -0600
Subject: [Engine-devel] engine database upgrade failure with latest
In-Reply-To: <CAEWPe=og6zfr05Ji2xDPDPSKbisY5KcXYpU27C1G5kLPZFnMmA@mail.gmail.com>
References: <CAEWPe=rdCPYU37J73kXMZhf0rm7oRjG8VPzk6z7jAyJ+go61Yg@mail.gmail.com>
	<210237391.8211710.1352494164990.JavaMail.root@redhat.com>
	<CAEWPe=og6zfr05Ji2xDPDPSKbisY5KcXYpU27C1G5kLPZFnMmA@mail.gmail.com>
Message-ID: <CAEWPe=rqDACn2L_ABpkfVyiHR3i+qsoawQLhS=f2OxwmW=oWAg@mail.gmail.com>

Clarifying further:
What is running that I am attempting to upgrade:
(parent: 6125e33<http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=6125e335cbb49730899c6feeb05147db6d0c4eaa>
)
core: Improve error logging when there are LDAP queries errors
<http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commitdiff;h=a665ec3af7b2dd04e80007b1c062868d3e049fce>
28/9028/2<http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=shortlog;h=refs/changes/28/9028/2>
authorYair Zaslavsky<http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=search;h=a665ec3af7b2dd04e80007b1c062868d3e049fce;s=Yair+Zaslavsky;st=author>
 <yzaslavs at redhat.com><http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=search;h=a665ec3af7b2dd04e80007b1c062868d3e049fce;s=yzaslavs at redhat.com;st=author>

Mon, 5 Nov 2012 10:28:23 +0000 (12:28 +0200)committerYair
Zaslavsky<http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=search;h=a665ec3af7b2dd04e80007b1c062868d3e049fce;s=Yair+Zaslavsky;st=committer>
 <yzaslavs at redhat.com><http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=search;h=a665ec3af7b2dd04e80007b1c062868d3e049fce;s=yzaslavs at redhat.com;st=committer>

Mon, 5 Nov 2012 15:43:40 +0000 (17:43 +0200)commit
a665ec3af7b2dd04e80007b1c062868d3e049fcetree
f448ae8313c2417dd578469de20e7d332e085490<http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=tree;h=f448ae8313c2417dd578469de20e7d332e085490;hb=a665ec3af7b2dd04e80007b1c062868d3e049fce><http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=tree;h=f448ae8313c2417dd578469de20e7d332e085490;hb=a665ec3af7b2dd04e80007b1c062868d3e049fce>
parent6125e335cbb49730899c6feeb05147db6d0c4eaa<http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=6125e335cbb49730899c6feeb05147db6d0c4eaa><http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=6125e335cbb49730899c6feeb05147db6d0c4eaa>

What I just built and attempting to upgrade with:
(parent: 025b98c<http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=025b98c2a7f7b4a7f4bca417d2dfa95199adfa91>
)
core: removed getVmNetworkInterfaceDao
<http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commitdiff;h=2dc9b518099ec1ac3995abf1483f43cdcb6eb2b8>
05/9105/2<http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=shortlog;h=refs/changes/05/9105/2>
 master<http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=shortlog;h=refs/heads/master>
authorLaszlo Hornyak<http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=search;h=2dc9b518099ec1ac3995abf1483f43cdcb6eb2b8;s=Laszlo+Hornyak;st=author>
 <lhornyak at redhat.com><http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=search;h=2dc9b518099ec1ac3995abf1483f43cdcb6eb2b8;s=lhornyak at redhat.com;st=author>

Wed, 7 Nov 2012 14:25:03 +0000 (15:25 +0100)committerLaszlo
Hornyak<http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=search;h=2dc9b518099ec1ac3995abf1483f43cdcb6eb2b8;s=Laszlo+Hornyak;st=committer>
 <lhornyak at redhat.com><http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=search;h=2dc9b518099ec1ac3995abf1483f43cdcb6eb2b8;s=lhornyak at redhat.com;st=committer>

Thu, 8 Nov 2012 20:01:59 +0000 (21:01 +0100)commit
2dc9b518099ec1ac3995abf1483f43cdcb6eb2b8tree
71f522f4a30dea8871e7d5f95dbd126045aa8135<http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=tree;h=71f522f4a30dea8871e7d5f95dbd126045aa8135;hb=2dc9b518099ec1ac3995abf1483f43cdcb6eb2b8>
parent025b98c2a7f7b4a7f4bca417d2dfa95199adfa91<http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=025b98c2a7f7b4a7f4bca417d2dfa95199adfa91>



On Fri, Nov 9, 2012 at 2:52 PM, Dead Horse <deadhorseconsulting at gmail.com>wrote:

> Correct the version I am attempting to upgrade was built from master on
> Monday. I just built master from today and attempted to upgrade the running
> instance I built from master on Monday.
>
>
>
> On Fri, Nov 9, 2012 at 2:49 PM, Alon Bar-Lev <alonbl at redhat.com> wrote:
>
>> You wrote version from Monday...
>> (a665ec3af7b2dd04e80007b1c062868d3e049fce)
>> Which was before patch was applied.
>>
>> ----- Original Message -----
>> > From: "Dead Horse" <deadhorseconsulting at gmail.com>
>> > To: "Alon Bar-Lev" <alonbl at redhat.com>
>> > Cc: engine-devel at ovirt.org
>> > Sent: Friday, November 9, 2012 10:42:28 PM
>> > Subject: Re: [Engine-devel] engine database upgrade failure with latest
>> >
>> > cloned via git clone http://gerrit.ovirt.org/p/ovirt-engine (so
>> > master by default)
>> > current master commit appears to me as:
>> > commit        2dc9b518099ec1ac3995abf1483f43cdcb6eb2b8
>> >
>> >
>> >
>> > On Fri, Nov 9, 2012 at 2:32 PM, Alon Bar-Lev < alonbl at redhat.com >
>> > wrote:
>> >
>> >
>> >
>> > Strange...
>> >
>> > This[1] patch should have solved this. It is merged to master.
>> > Are you using master?
>> >
>> > [1] http://gerrit.ovirt.org/#/c/8955/
>> >
>> >
>> >
>> > ----- Original Message -----
>> > > From: "Dead Horse" < deadhorseconsulting at gmail.com >
>> > > To: engine-devel at ovirt.org
>> > > Sent: Friday, November 9, 2012 10:28:18 PM
>> > > Subject: [Engine-devel] engine database upgrade failure with latest
>> > >
>> > >
>> > > I built the latest ovirt-engine from GIT and attempted to upgrade.
>> > > Version that I attempting to upgrade was built Monday from master
>> > > (commit: a665ec3af7b2dd04e80007b1c062868d3e049fce).
>> > >
>> > > Below is the what was logged by engine-upgrade:
>> > > 2012-11-09 14:15:54::DEBUG::engine-upgrade::425::root:: DB Update
>> > > started
>> > > 2012-11-09 14:15:54::DEBUG::common_utils::390::root:: Executing
>> > > command --> '/usr/share/ovirt-engine/dbscripts/upgrade.sh -s
>> > > localhost -p 5432 -u engine -d engine_2012_11_09_14_12_52'
>> > > 2012-11-09 14:15:58::DEBUG::common_utils::428::root:: output =
>> > > upgrade script detected a change in Config, View or Stored
>> > > Procedure...
>> > >
>> > > 2012-11-09 14:15:58::DEBUG::common_utils::429::root:: stderr =
>> > > psql:create_functions.sql:666: ERROR: must be owner of function
>> > > uuid_generate_v1
>> > >
>> > > 2012-11-09 14:15:58::DEBUG::common_utils::430::root:: retcode = 3
>> > > 2012-11-09 14:15:58::ERROR::engine-upgrade::1072::root:: Traceback
>> > > (most recent call last):
>> > > File "/usr/bin/engine-upgrade", line 1059, in main
>> > > runFunc([db.update], MSG_INFO_DB_UPDATE)
>> > > File "/usr/bin/engine-upgrade", line 607, in runFunc
>> > > func()
>> > > File "/usr/bin/engine-upgrade", line 442, in update
>> > > output, rc = utils.execCmd(cmdList=cmd, failOnError=True,
>> > > msg=MSG_ERROR_UPDATE_DB)
>> > > File "/usr/share/ovirt-engine/scripts/common_utils.py", line 433,
>> > > in
>> > > execCmd
>> > > raise Exception(msg)
>> > > Exception: Error: Database update failed
>> > >
>> > > - DHC
>> > >
>> > >
>> > > _______________________________________________
>> > > Engine-devel mailing list
>> > > Engine-devel at ovirt.org
>> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
>> > >
>> >
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121109/74c9eade/attachment.html>

From deadhorseconsulting at gmail.com  Sat Nov 10 00:14:30 2012
From: deadhorseconsulting at gmail.com (Dead Horse)
Date: Fri, 9 Nov 2012 18:14:30 -0600
Subject: [Engine-devel] engine database upgrade failure with latest
In-Reply-To: <CAEWPe=rqDACn2L_ABpkfVyiHR3i+qsoawQLhS=f2OxwmW=oWAg@mail.gmail.com>
References: <CAEWPe=rdCPYU37J73kXMZhf0rm7oRjG8VPzk6z7jAyJ+go61Yg@mail.gmail.com>
	<210237391.8211710.1352494164990.JavaMail.root@redhat.com>
	<CAEWPe=og6zfr05Ji2xDPDPSKbisY5KcXYpU27C1G5kLPZFnMmA@mail.gmail.com>
	<CAEWPe=rqDACn2L_ABpkfVyiHR3i+qsoawQLhS=f2OxwmW=oWAg@mail.gmail.com>
Message-ID: <CAEWPe=oUEzx55tijPLS4yYAmUkMMZs=Cr50nHwjRrrFG6yOCjw@mail.gmail.com>

Very odd I stopped the engine service manually and ran engine-upgrade. This
time it succeeded. For fun I removed the engine and re-installed the prior
build. I again ran engine-upgrade and the failure reproduced again. I
stopped the engine service again and ran engine-upgrade and it succeeded
the second attempt.
- DHC


On Fri, Nov 9, 2012 at 3:10 PM, Dead Horse <deadhorseconsulting at gmail.com>wrote:

> Clarifying further:
> What is running that I am attempting to upgrade:
> (parent: 6125e33<http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=6125e335cbb49730899c6feeb05147db6d0c4eaa>
> )
> core: Improve error logging when there are LDAP queries errors <http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commitdiff;h=a665ec3af7b2dd04e80007b1c062868d3e049fce>
> 28/9028/2<http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=shortlog;h=refs/changes/28/9028/2>
>  authorYair Zaslavsky<http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=search;h=a665ec3af7b2dd04e80007b1c062868d3e049fce;s=Yair+Zaslavsky;st=author>
>  <yzaslavs at redhat.com><http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=search;h=a665ec3af7b2dd04e80007b1c062868d3e049fce;s=yzaslavs at redhat.com;st=author>
>
> Mon, 5 Nov 2012 10:28:23 +0000 (12:28 +0200)committerYair Zaslavsky<http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=search;h=a665ec3af7b2dd04e80007b1c062868d3e049fce;s=Yair+Zaslavsky;st=committer>
>  <yzaslavs at redhat.com><http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=search;h=a665ec3af7b2dd04e80007b1c062868d3e049fce;s=yzaslavs at redhat.com;st=committer>
>
> Mon, 5 Nov 2012 15:43:40 +0000 (17:43 +0200)commita665ec3af7b2dd04e80007b1c062868d3e049fce
> treef448ae8313c2417dd578469de20e7d332e085490<http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=tree;h=f448ae8313c2417dd578469de20e7d332e085490;hb=a665ec3af7b2dd04e80007b1c062868d3e049fce>
> <http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=tree;h=f448ae8313c2417dd578469de20e7d332e085490;hb=a665ec3af7b2dd04e80007b1c062868d3e049fce>
> parent6125e335cbb49730899c6feeb05147db6d0c4eaa<http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=6125e335cbb49730899c6feeb05147db6d0c4eaa>
> <http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=6125e335cbb49730899c6feeb05147db6d0c4eaa>
>
> What I just built and attempting to upgrade with:
> (parent: 025b98c<http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=025b98c2a7f7b4a7f4bca417d2dfa95199adfa91>
> )
> core: removed getVmNetworkInterfaceDao <http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commitdiff;h=2dc9b518099ec1ac3995abf1483f43cdcb6eb2b8>
> 05/9105/2<http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=shortlog;h=refs/changes/05/9105/2>
>  master<http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=shortlog;h=refs/heads/master>
>  authorLaszlo Hornyak<http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=search;h=2dc9b518099ec1ac3995abf1483f43cdcb6eb2b8;s=Laszlo+Hornyak;st=author>
>  <lhornyak at redhat.com><http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=search;h=2dc9b518099ec1ac3995abf1483f43cdcb6eb2b8;s=lhornyak at redhat.com;st=author>
>
> Wed, 7 Nov 2012 14:25:03 +0000 (15:25 +0100)committerLaszlo Hornyak<http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=search;h=2dc9b518099ec1ac3995abf1483f43cdcb6eb2b8;s=Laszlo+Hornyak;st=committer>
>  <lhornyak at redhat.com><http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=search;h=2dc9b518099ec1ac3995abf1483f43cdcb6eb2b8;s=lhornyak at redhat.com;st=committer>
>
> Thu, 8 Nov 2012 20:01:59 +0000 (21:01 +0100)commit2dc9b518099ec1ac3995abf1483f43cdcb6eb2b8
> tree71f522f4a30dea8871e7d5f95dbd126045aa8135<http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=tree;h=71f522f4a30dea8871e7d5f95dbd126045aa8135;hb=2dc9b518099ec1ac3995abf1483f43cdcb6eb2b8>
> parent 025b98c2a7f7b4a7f4bca417d2dfa95199adfa91<http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=025b98c2a7f7b4a7f4bca417d2dfa95199adfa91>
>
>
>
> On Fri, Nov 9, 2012 at 2:52 PM, Dead Horse <deadhorseconsulting at gmail.com>wrote:
>
>> Correct the version I am attempting to upgrade was built from master on
>> Monday. I just built master from today and attempted to upgrade the running
>> instance I built from master on Monday.
>>
>>
>>
>> On Fri, Nov 9, 2012 at 2:49 PM, Alon Bar-Lev <alonbl at redhat.com> wrote:
>>
>>> You wrote version from Monday...
>>> (a665ec3af7b2dd04e80007b1c062868d3e049fce)
>>> Which was before patch was applied.
>>>
>>> ----- Original Message -----
>>> > From: "Dead Horse" <deadhorseconsulting at gmail.com>
>>> > To: "Alon Bar-Lev" <alonbl at redhat.com>
>>> > Cc: engine-devel at ovirt.org
>>> > Sent: Friday, November 9, 2012 10:42:28 PM
>>> > Subject: Re: [Engine-devel] engine database upgrade failure with latest
>>> >
>>> > cloned via git clone http://gerrit.ovirt.org/p/ovirt-engine (so
>>> > master by default)
>>> > current master commit appears to me as:
>>> > commit        2dc9b518099ec1ac3995abf1483f43cdcb6eb2b8
>>> >
>>> >
>>> >
>>> > On Fri, Nov 9, 2012 at 2:32 PM, Alon Bar-Lev < alonbl at redhat.com >
>>> > wrote:
>>> >
>>> >
>>> >
>>> > Strange...
>>> >
>>> > This[1] patch should have solved this. It is merged to master.
>>> > Are you using master?
>>> >
>>> > [1] http://gerrit.ovirt.org/#/c/8955/
>>> >
>>> >
>>> >
>>> > ----- Original Message -----
>>> > > From: "Dead Horse" < deadhorseconsulting at gmail.com >
>>> > > To: engine-devel at ovirt.org
>>> > > Sent: Friday, November 9, 2012 10:28:18 PM
>>> > > Subject: [Engine-devel] engine database upgrade failure with latest
>>> > >
>>> > >
>>> > > I built the latest ovirt-engine from GIT and attempted to upgrade.
>>> > > Version that I attempting to upgrade was built Monday from master
>>> > > (commit: a665ec3af7b2dd04e80007b1c062868d3e049fce).
>>> > >
>>> > > Below is the what was logged by engine-upgrade:
>>> > > 2012-11-09 14:15:54::DEBUG::engine-upgrade::425::root:: DB Update
>>> > > started
>>> > > 2012-11-09 14:15:54::DEBUG::common_utils::390::root:: Executing
>>> > > command --> '/usr/share/ovirt-engine/dbscripts/upgrade.sh -s
>>> > > localhost -p 5432 -u engine -d engine_2012_11_09_14_12_52'
>>> > > 2012-11-09 14:15:58::DEBUG::common_utils::428::root:: output =
>>> > > upgrade script detected a change in Config, View or Stored
>>> > > Procedure...
>>> > >
>>> > > 2012-11-09 14:15:58::DEBUG::common_utils::429::root:: stderr =
>>> > > psql:create_functions.sql:666: ERROR: must be owner of function
>>> > > uuid_generate_v1
>>> > >
>>> > > 2012-11-09 14:15:58::DEBUG::common_utils::430::root:: retcode = 3
>>> > > 2012-11-09 14:15:58::ERROR::engine-upgrade::1072::root:: Traceback
>>> > > (most recent call last):
>>> > > File "/usr/bin/engine-upgrade", line 1059, in main
>>> > > runFunc([db.update], MSG_INFO_DB_UPDATE)
>>> > > File "/usr/bin/engine-upgrade", line 607, in runFunc
>>> > > func()
>>> > > File "/usr/bin/engine-upgrade", line 442, in update
>>> > > output, rc = utils.execCmd(cmdList=cmd, failOnError=True,
>>> > > msg=MSG_ERROR_UPDATE_DB)
>>> > > File "/usr/share/ovirt-engine/scripts/common_utils.py", line 433,
>>> > > in
>>> > > execCmd
>>> > > raise Exception(msg)
>>> > > Exception: Error: Database update failed
>>> > >
>>> > > - DHC
>>> > >
>>> > >
>>> > > _______________________________________________
>>> > > Engine-devel mailing list
>>> > > Engine-devel at ovirt.org
>>> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
>>> > >
>>> >
>>> >
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121109/68d63a2f/attachment.html>

From alonbl at redhat.com  Sat Nov 10 11:20:23 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Sat, 10 Nov 2012 06:20:23 -0500 (EST)
Subject: [Engine-devel] engine database upgrade failure with latest
In-Reply-To: <CAEWPe=oUEzx55tijPLS4yYAmUkMMZs=Cr50nHwjRrrFG6yOCjw@mail.gmail.com>
Message-ID: <2127103489.8242475.1352546423799.JavaMail.root@redhat.com>

Indeed odd, as the engine-upgrade stops the engine service if you answer 'yes' at the beginning.
Or maybe you upgrade using unattended mode and this is skipped.

----- Original Message -----
> From: "Dead Horse" <deadhorseconsulting at gmail.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Saturday, November 10, 2012 2:14:30 AM
> Subject: Re: [Engine-devel] engine database upgrade failure with latest
> 
> Very odd I stopped the engine service manually and ran
> engine-upgrade. This time it succeeded. For fun I removed the engine
> and re-installed the prior build. I again ran engine-upgrade and the
> failure reproduced again. I stopped the engine service again and ran
> engine-upgrade and it succeeded the second attempt.
> - DHC
> 
> 
> 
> 
> On Fri, Nov 9, 2012 at 3:10 PM, Dead Horse <
> deadhorseconsulting at gmail.com > wrote:
> 
> 
> Clarifying further:
> What is running that I am attempting to upgrade:
> 
> (parent: 6125e33 )
> 
> core: Improve error logging when there are LDAP queries errors
> 28/9028/2
> author 	Yair Zaslavsky <yzaslavs at redhat.com>
> 
> 
> 	Mon, 5 Nov 2012 10:28:23 +0000 (12:28 +0200)
> committer 	Yair Zaslavsky <yzaslavs at redhat.com>
> 
> 
> 	Mon, 5 Nov 2012 15:43:40 +0000 (17:43 +0200)
> commit 	a665ec3af7b2dd04e80007b1c062868d3e049fce
> tree 	f448ae8313c2417dd578469de20e7d332e085490
> 
> parent 	6125e335cbb49730899c6feeb05147db6d0c4eaa
> 
> What I just built and attempting to upgrade with:
> 
> (parent: 025b98c )
> 
> core: removed getVmNetworkInterfaceDao 05/9105/2 master
> author 	Laszlo Hornyak <lhornyak at redhat.com>
> 
> 
> 	Wed, 7 Nov 2012 14:25:03 +0000 (15:25 +0100)
> committer 	Laszlo Hornyak <lhornyak at redhat.com>
> 
> 
> 	Thu, 8 Nov 2012 20:01:59 +0000 (21:01 +0100)
> commit 	2dc9b518099ec1ac3995abf1483f43cdcb6eb2b8
> tree 	71f522f4a30dea8871e7d5f95dbd126045aa8135
> 
> parent 	025b98c2a7f7b4a7f4bca417d2dfa95199adfa91
> 
> 
> 
> 
> 
> 
> 
> On Fri, Nov 9, 2012 at 2:52 PM, Dead Horse <
> deadhorseconsulting at gmail.com > wrote:
> 
> 
> Correct the version I am attempting to upgrade was built from master
> on Monday. I just built master from today and attempted to upgrade
> the running instance I built from master on Monday.
> 
> 
> 
> 
> 
> 
> On Fri, Nov 9, 2012 at 2:49 PM, Alon Bar-Lev < alonbl at redhat.com >
> wrote:
> 
> 
> You wrote version from Monday...
> (a665ec3af7b2dd04e80007b1c062868d3e049fce)
> Which was before patch was applied.
> 
> 
> ----- Original Message -----
> > From: "Dead Horse" < deadhorseconsulting at gmail.com >
> 
> 
> > To: "Alon Bar-Lev" < alonbl at redhat.com >
> > Cc: engine-devel at ovirt.org
> > Sent: Friday, November 9, 2012 10:42:28 PM
> > Subject: Re: [Engine-devel] engine database upgrade failure with
> > latest
> > 
> > cloned via git clone http://gerrit.ovirt.org/p/ovirt-engine (so
> > master by default)
> > current master commit appears to me as:
> > commit 2dc9b518099ec1ac3995abf1483f43cdcb6eb2b8
> > 
> > 
> > 
> > On Fri, Nov 9, 2012 at 2:32 PM, Alon Bar-Lev < alonbl at redhat.com >
> > wrote:
> > 
> > 
> > 
> > Strange...
> > 
> > This[1] patch should have solved this. It is merged to master.
> > Are you using master?
> > 
> > [1] http://gerrit.ovirt.org/#/c/8955/
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Dead Horse" < deadhorseconsulting at gmail.com >
> > > To: engine-devel at ovirt.org
> > > Sent: Friday, November 9, 2012 10:28:18 PM
> > > Subject: [Engine-devel] engine database upgrade failure with
> > > latest
> > > 
> > > 
> > > I built the latest ovirt-engine from GIT and attempted to
> > > upgrade.
> > > Version that I attempting to upgrade was built Monday from master
> > > (commit: a665ec3af7b2dd04e80007b1c062868d3e049fce).
> > > 
> > > Below is the what was logged by engine-upgrade:
> > > 2012-11-09 14:15:54::DEBUG::engine-upgrade::425::root:: DB Update
> > > started
> > > 2012-11-09 14:15:54::DEBUG::common_utils::390::root:: Executing
> > > command --> '/usr/share/ovirt-engine/dbscripts/upgrade.sh -s
> > > localhost -p 5432 -u engine -d engine_2012_11_09_14_12_52'
> > > 2012-11-09 14:15:58::DEBUG::common_utils::428::root:: output =
> > > upgrade script detected a change in Config, View or Stored
> > > Procedure...
> > > 
> > > 2012-11-09 14:15:58::DEBUG::common_utils::429::root:: stderr =
> > > psql:create_functions.sql:666: ERROR: must be owner of function
> > > uuid_generate_v1
> > > 
> > > 2012-11-09 14:15:58::DEBUG::common_utils::430::root:: retcode = 3
> > > 2012-11-09 14:15:58::ERROR::engine-upgrade::1072::root::
> > > Traceback
> > > (most recent call last):
> > > File "/usr/bin/engine-upgrade", line 1059, in main
> > > runFunc([db.update], MSG_INFO_DB_UPDATE)
> > > File "/usr/bin/engine-upgrade", line 607, in runFunc
> > > func()
> > > File "/usr/bin/engine-upgrade", line 442, in update
> > > output, rc = utils.execCmd(cmdList=cmd, failOnError=True,
> > > msg=MSG_ERROR_UPDATE_DB)
> > > File "/usr/share/ovirt-engine/scripts/common_utils.py", line 433,
> > > in
> > > execCmd
> > > raise Exception(msg)
> > > Exception: Error: Database update failed
> > > 
> > > - DHC
> > > 
> > > 
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > 
> > 
> 
> 
> 
> 


From acathrow at redhat.com  Sat Nov 10 19:56:41 2012
From: acathrow at redhat.com (Andrew Cathrow)
Date: Sat, 10 Nov 2012 14:56:41 -0500 (EST)
Subject: [Engine-devel] SPICE IP override
In-Reply-To: <1352477259.24625.15.camel@peecee.hoentjen.eu>
Message-ID: <13206606.38.1352546039944.JavaMail.javamailuser@localhost>



----- Original Message -----
> From: "Sander Hoentjen" <sander at hoentjen.eu>
> To: engine-devel at ovirt.org
> Sent: Friday, November 9, 2012 11:07:39 AM
> Subject: Re: [Engine-devel] SPICE IP override
> 
> On Wed, 2012-11-07 at 12:40 +0100, David Ja?a wrote:
> > Ewoud Kohl van Wijngaarden p??e v St 07. 11. 2012 v 12:08 +0100:
> > > On Wed, Nov 07, 2012 at 11:23:27AM +0100, David Ja?a wrote:
> > > > Ewoud Kohl van Wijngaarden p??e v St 07. 11. 2012 v 11:16
> > > > +0100:
> > > > > On Wed, Nov 07, 2012 at 03:52:14AM -0500, Simon Grinberg
> > > > > wrote:
> > > > > > ----- Original Message -----
> > > > > > > From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
> > > > > > > To: engine-devel at ovirt.org
> > > > > > > Sent: Tuesday, November 6, 2012 10:39:58 PM
> > > > > > > Subject: [Engine-devel] SPICE IP override
> > > > > > >
> > > > > > > Hi all,
> > > > > > > On behalf of Tomas - please check out the proposal for
> > > > > > > enhancing our
> > > > > > > SPICE integration to allow to return a custom IP/FQDN
> > > > > > > instead of the
> > > > > > > host IP address.
> > > > > > > http://wiki.ovirt.org/wiki/Features/Display_Address_Override
> > > > > > > All comments are welcome...
> > > > > >
> > > > > > My 2 cents,
> > > > > >
> > > > > > This works under the assumption that all the users are
> > > > > > either outside
> > > > > > of the organization or inside.
> > > > > > But think of some of the following scenarios based on a
> > > > > > topology where
> > > > > > users in the main office are inside the corporate network
> > > > > > while users
> > > > > > on remote offices / WAN are on a detached different network
> > > > > > on the
> > > > > > other side of the NAT / public firewall :
> > > > > >
> > > > > > With current 'per host override' proposal:
> > > > > > 1. Admin from the main office won't be able to access the
> > > > > > VM console
> > > > > > 2. No Mixed environment, meaning that you have to have
> > > > > > designated
> > > > > >    clusters for remote offices users vs main office users -
> > > > > >    otherwise
> > > > > >    connectivity to the console is determined based on
> > > > > >    scheduler
> > > > > >    decision, or may break by live migration.
> > > > > > 3. Based on #2, If I'm a user travelling between offices
> > > > > > I'll have to
> > > > > >    ask the admin to turn off my VM and move it to internal
> > > > > >    cluster
> > > > > >    before I can reconnect
> > > > > >
> > > > > > My suggestion is to covert this to 'alternative' IP/FQDN
> > > > > > sending the
> > > > > > spice client both internal fqdn/ip and the alternative. The
> > > > > > spice
> > > > > > client should detect which is available of the two and
> > > > > > auto-connect.
> > > > > >
> > > > > > This requires enhancement of the spice client, but still
> > > > > > solves all
> > > > > > the issues raised above (actually it solves about 90% of
> > > > > > the use cases
> > > > > > I've heard about in the past).
> > > > > >
> > > > > > Another alternative is for the engine to 'guess' or 'elect'
> > > > > > which to
> > > > > > use, alternative or main, based on the IP of the client -
> > > > > > meaning
> > > > > > admin provides the client ranges for providing internal
> > > > > > host address
> > > > > > vs alternative - but this is more complicated compared for
> > > > > > the
> > > > > > previous suggestion
> > > > > >
> > > > > > Thoughts?
> > > > > 
> > > > > I agree with where you're going with this. The story I'd like
> > > > > to see
> > > > > supported is close to this. We have external customers who
> > > > > should know
> > > > > nothing about our internal network, but should be able to
> > > > > access the
> > > > > console of their VMs. Currently we do this with a custom
> > > > > frontend which
> > > > > uses the API (and is about as old as the RHEV 2.2 API) and a
> > > > > TCP proxy,
> > > > > but we'd like to move to the standard UI. Currently the
> > > > > console
> > > > > connection prevents us from doing so.
> > > > 
> > > > You could do that with this proposal, if you:
> > > > 1) DNAT some external-facing IPs to your hypervisor display
> > > > network IPs
> > > > 2) resolve display network FQDN to the DNATing machine IPs for
> > > > external
> > > > queries.
> > > 
> > > I imagine you need 1 external-facing IP per host, which makes it
> > > expensive to scale since IPv4 space is very limited.
> > 
> > That's the cost of quick-to-implement solution.
> > 
> > If it is possible to have per-host display port range, you could
> > work
> > this limitation around by setting non-overlapping ranges for each
> > host
> > and use a single proxy or DNAT machine that would decide which port
> > to
> > forward based on the range.
> 
> I am a colleague of Ewoud, and want to explain a bit more about how
> we
> currently have implemented this.
> All our virtualization hosts, but also the manager only live in the
> internal network. We have written a webapplication that is a
> self-service portal for our customers. This webapplication lives on a
> host that is publicly reachable. This host can also reach the
> virtualization servers on the internal network. Now for all actions
> except for viewing a console the webhost only needs to access the
> api,
> so what happens when a user wants to view the console (we currently
> use
> vnc):
> On the webhost we have reserved a number of ports.
> Api request is made to get the host/port, and we set the ticket (vnc
> password).
> We create a tunnel (currently use socat, but can of course also be
> DNAT
> or any kind of proxy) that connects one of the free ports on the
> external webhost to the host/port combo we got back from the api.
> This is a very simple implementation, but it works well in our
> experience.
> 
> For added points you can make the proxy smarter, things like handling
> vm
> migrations and maybe adding websockets support for a html5 spice
> client ;)
> 

the new remote-viewer client no supports a tunneled connection through a proxy like squid. It's not socks or http it's just a tunneled IP connection but will address a number of issues

The plan is to add support for this into 3.2

Aic

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


From alonbl at redhat.com  Sat Nov 10 20:34:22 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Sat, 10 Nov 2012 15:34:22 -0500 (EST)
Subject: [Engine-devel] ovirt-engine master - no hosts in hosts tab!
In-Reply-To: <951497915.8249721.1352579393759.JavaMail.root@redhat.com>
Message-ID: <1203573587.8249737.1352579662925.JavaMail.root@redhat.com>

Hello,

Last working:
a665ec3af7b2dd04e80007b1c062868d3e049fce from Mon Nov 5 12:28:23 2012 +0200

Master head:
2dc9b518099ec1ac3995abf1483f43cdcb6eb2b8 from Wed Nov 7 15:25:03 2012 +0100

When adding a new host, host is added to database, bootstrap is running, but hosts tab is empty!

Did not find anything that directly relates to this, CCing all committers.

Please fix,
Alon.


From emesika at redhat.com  Sat Nov 10 21:00:05 2012
From: emesika at redhat.com (Eli Mesika)
Date: Sat, 10 Nov 2012 16:00:05 -0500 (EST)
Subject: [Engine-devel] ovirt-engine master - no hosts in hosts tab!
In-Reply-To: <1203573587.8249737.1352579662925.JavaMail.root@redhat.com>
Message-ID: <389690847.8949081.1352581205133.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Cc: "Laszlo Hornyak" <lhornyak at redhat.com>, "Dhandapani" <dgopal at redhat.com>, "Eli Mesika" <emesika at redhat.com>,
> "Daniel Erez" <derez at redhat.com>, "Maor Lipchuk" <mlipchuk at redhat.com>, "Omer Frenkel" <ofrenkel at redhat.com>,
> "Kanagaraj M" <kmayilsa at redhat.com>, "Sharad Mishra" <snmishra at linux.vnet.ibm.com>, "Vered Volansky"
> <vvolansk at redhat.com>, "Juan Hernandez" <juan.hernandez at redhat.com>, "Shireesh Anjal" <sanjal at redhat.com>, "Shahar
> Havivi" <shavivi at redhat.com>, "Michael Kublin" <mkublin at redhat.com>, "Ravi Nori" <rnori at redhat.com>, "Alona Kaplan"
> <alkaplan at redhat.com>, "Michael Pasternak" <mpastern at redhat.com>, "Yair Zaslavsky" <yzaslavs at redhat.com>, "Allon
> Mureinik" <amureini at redhat.com>
> Sent: Saturday, November 10, 2012 10:34:22 PM
> Subject: ovirt-engine master - no hosts in hosts tab!
> 
> Hello,
> 
> Last working:
> a665ec3af7b2dd04e80007b1c062868d3e049fce from Mon Nov 5 12:28:23 2012
> +0200
> 
> Master head:
> 2dc9b518099ec1ac3995abf1483f43cdcb6eb2b8 from Wed Nov 7 15:25:03 2012
> +0100
> 
> When adding a new host, host is added to database, bootstrap is
> running, but hosts tab is empty!
> 
> Did not find anything that directly relates to this, CCing all
> committers.


Seems that your database is not updated with recent changes 
Can you please run the upgrade.sh script on your db ?

> 
> Please fix,
> Alon.
> 


From alonbl at redhat.com  Sat Nov 10 21:03:13 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Sat, 10 Nov 2012 16:03:13 -0500 (EST)
Subject: [Engine-devel] ovirt-engine master - no hosts in hosts tab!
In-Reply-To: <389690847.8949081.1352581205133.JavaMail.root@redhat.com>
Message-ID: <355343361.8249970.1352581393597.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Laszlo Hornyak" <lhornyak at redhat.com>, "Dhandapani" <dgopal at redhat.com>, "Daniel Erez" <derez at redhat.com>, "Maor
> Lipchuk" <mlipchuk at redhat.com>, "Omer Frenkel" <ofrenkel at redhat.com>, "Kanagaraj M" <kmayilsa at redhat.com>, "Sharad
> Mishra" <snmishra at linux.vnet.ibm.com>, "Vered Volansky" <vvolansk at redhat.com>, "Juan Hernandez"
> <juan.hernandez at redhat.com>, "Shireesh Anjal" <sanjal at redhat.com>, "Shahar Havivi" <shavivi at redhat.com>, "Michael
> Kublin" <mkublin at redhat.com>, "Ravi Nori" <rnori at redhat.com>, "Alona Kaplan" <alkaplan at redhat.com>, "Michael
> Pasternak" <mpastern at redhat.com>, "Yair Zaslavsky" <yzaslavs at redhat.com>, "Allon Mureinik" <amureini at redhat.com>,
> "engine-devel" <engine-devel at ovirt.org>
> Sent: Saturday, November 10, 2012 11:00:05 PM
> Subject: Re: ovirt-engine master - no hosts in hosts tab!
> 
> 
> 
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Cc: "Laszlo Hornyak" <lhornyak at redhat.com>, "Dhandapani"
> > <dgopal at redhat.com>, "Eli Mesika" <emesika at redhat.com>,
> > "Daniel Erez" <derez at redhat.com>, "Maor Lipchuk"
> > <mlipchuk at redhat.com>, "Omer Frenkel" <ofrenkel at redhat.com>,
> > "Kanagaraj M" <kmayilsa at redhat.com>, "Sharad Mishra"
> > <snmishra at linux.vnet.ibm.com>, "Vered Volansky"
> > <vvolansk at redhat.com>, "Juan Hernandez"
> > <juan.hernandez at redhat.com>, "Shireesh Anjal" <sanjal at redhat.com>,
> > "Shahar
> > Havivi" <shavivi at redhat.com>, "Michael Kublin"
> > <mkublin at redhat.com>, "Ravi Nori" <rnori at redhat.com>, "Alona
> > Kaplan"
> > <alkaplan at redhat.com>, "Michael Pasternak" <mpastern at redhat.com>,
> > "Yair Zaslavsky" <yzaslavs at redhat.com>, "Allon
> > Mureinik" <amureini at redhat.com>
> > Sent: Saturday, November 10, 2012 10:34:22 PM
> > Subject: ovirt-engine master - no hosts in hosts tab!
> > 
> > Hello,
> > 
> > Last working:
> > a665ec3af7b2dd04e80007b1c062868d3e049fce from Mon Nov 5 12:28:23
> > 2012
> > +0200
> > 
> > Master head:
> > 2dc9b518099ec1ac3995abf1483f43cdcb6eb2b8 from Wed Nov 7 15:25:03
> > 2012
> > +0100
> > 
> > When adding a new host, host is added to database, bootstrap is
> > running, but hosts tab is empty!
> > 
> > Did not find anything that directly relates to this, CCing all
> > committers.
> 
> 
> Seems that your database is not updated with recent changes
> Can you please run the upgrade.sh script on your db ?

This is fresh install.

> 
> > 
> > Please fix,
> > Alon.
> > 
> 


From emesika at redhat.com  Sat Nov 10 21:18:39 2012
From: emesika at redhat.com (Eli Mesika)
Date: Sat, 10 Nov 2012 16:18:39 -0500 (EST)
Subject: [Engine-devel] ovirt-engine master - no hosts in hosts tab!
In-Reply-To: <355343361.8249970.1352581393597.JavaMail.root@redhat.com>
Message-ID: <2044370054.8951893.1352582319213.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "Laszlo Hornyak" <lhornyak at redhat.com>, "Dhandapani" <dgopal at redhat.com>, "Daniel Erez" <derez at redhat.com>, "Maor
> Lipchuk" <mlipchuk at redhat.com>, "Omer Frenkel" <ofrenkel at redhat.com>, "Kanagaraj M" <kmayilsa at redhat.com>, "Sharad
> Mishra" <snmishra at linux.vnet.ibm.com>, "Vered Volansky" <vvolansk at redhat.com>, "Juan Hernandez"
> <juan.hernandez at redhat.com>, "Shireesh Anjal" <sanjal at redhat.com>, "Shahar Havivi" <shavivi at redhat.com>, "Michael
> Kublin" <mkublin at redhat.com>, "Ravi Nori" <rnori at redhat.com>, "Alona Kaplan" <alkaplan at redhat.com>, "Michael
> Pasternak" <mpastern at redhat.com>, "Yair Zaslavsky" <yzaslavs at redhat.com>, "Allon Mureinik" <amureini at redhat.com>,
> "engine-devel" <engine-devel at ovirt.org>
> Sent: Saturday, November 10, 2012 11:03:13 PM
> Subject: Re: ovirt-engine master - no hosts in hosts tab!
> 
> 
> 
> ----- Original Message -----
> > From: "Eli Mesika" <emesika at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "Laszlo Hornyak" <lhornyak at redhat.com>, "Dhandapani"
> > <dgopal at redhat.com>, "Daniel Erez" <derez at redhat.com>, "Maor
> > Lipchuk" <mlipchuk at redhat.com>, "Omer Frenkel"
> > <ofrenkel at redhat.com>, "Kanagaraj M" <kmayilsa at redhat.com>,
> > "Sharad
> > Mishra" <snmishra at linux.vnet.ibm.com>, "Vered Volansky"
> > <vvolansk at redhat.com>, "Juan Hernandez"
> > <juan.hernandez at redhat.com>, "Shireesh Anjal" <sanjal at redhat.com>,
> > "Shahar Havivi" <shavivi at redhat.com>, "Michael
> > Kublin" <mkublin at redhat.com>, "Ravi Nori" <rnori at redhat.com>,
> > "Alona Kaplan" <alkaplan at redhat.com>, "Michael
> > Pasternak" <mpastern at redhat.com>, "Yair Zaslavsky"
> > <yzaslavs at redhat.com>, "Allon Mureinik" <amureini at redhat.com>,
> > "engine-devel" <engine-devel at ovirt.org>
> > Sent: Saturday, November 10, 2012 11:00:05 PM
> > Subject: Re: ovirt-engine master - no hosts in hosts tab!
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > To: "engine-devel" <engine-devel at ovirt.org>
> > > Cc: "Laszlo Hornyak" <lhornyak at redhat.com>, "Dhandapani"
> > > <dgopal at redhat.com>, "Eli Mesika" <emesika at redhat.com>,
> > > "Daniel Erez" <derez at redhat.com>, "Maor Lipchuk"
> > > <mlipchuk at redhat.com>, "Omer Frenkel" <ofrenkel at redhat.com>,
> > > "Kanagaraj M" <kmayilsa at redhat.com>, "Sharad Mishra"
> > > <snmishra at linux.vnet.ibm.com>, "Vered Volansky"
> > > <vvolansk at redhat.com>, "Juan Hernandez"
> > > <juan.hernandez at redhat.com>, "Shireesh Anjal"
> > > <sanjal at redhat.com>,
> > > "Shahar
> > > Havivi" <shavivi at redhat.com>, "Michael Kublin"
> > > <mkublin at redhat.com>, "Ravi Nori" <rnori at redhat.com>, "Alona
> > > Kaplan"
> > > <alkaplan at redhat.com>, "Michael Pasternak" <mpastern at redhat.com>,
> > > "Yair Zaslavsky" <yzaslavs at redhat.com>, "Allon
> > > Mureinik" <amureini at redhat.com>
> > > Sent: Saturday, November 10, 2012 10:34:22 PM
> > > Subject: ovirt-engine master - no hosts in hosts tab!
> > > 
> > > Hello,
> > > 
> > > Last working:
> > > a665ec3af7b2dd04e80007b1c062868d3e049fce from Mon Nov 5 12:28:23
> > > 2012
> > > +0200
> > > 
> > > Master head:
> > > 2dc9b518099ec1ac3995abf1483f43cdcb6eb2b8 from Wed Nov 7 15:25:03
> > > 2012
> > > +0100
> > > 
> > > When adding a new host, host is added to database, bootstrap is
> > > running, but hosts tab is empty!
> > > 
> > > Did not find anything that directly relates to this, CCing all
> > > committers.
> > 
> > 
> > Seems that your database is not updated with recent changes
> > Can you please run the upgrade.sh script on your db ?
> 
> This is fresh install.

We had talked in IRC
Agreed to try reproducing tomorrow ...

> 
> > 
> > > 
> > > Please fix,
> > > Alon.
> > > 
> > 
> 


From emesika at redhat.com  Sat Nov 10 21:40:29 2012
From: emesika at redhat.com (Eli Mesika)
Date: Sat, 10 Nov 2012 16:40:29 -0500 (EST)
Subject: [Engine-devel] [Design for 3.2 RFE] Adding support for external
 events
In-Reply-To: <509CC51E.5050604@redhat.com>
Message-ID: <1368899630.8953606.1352583629355.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "Einav Cohen" <ecohen at redhat.com>, "Michael Pasternak"
> <mpastern at redhat.com>
> Sent: Friday, November 9, 2012 10:55:58 AM
> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Adding support for external events
> 
> On 11/08/2012 05:17 PM, Eli Mesika wrote:
> > Hi
> >
> > Please review , any comments are welcomed (please note that API
> > section is still in TBD)
> >
> > RFE :https://bugzilla.redhat.com/show_bug.cgi?id=873223
> > Requirements : http://wiki.ovirt.org/wiki/Features/ExternalEvents
> 
> > Events are classified as NORMAL , WARNING or ERROR and UI will
> > display different icon according to that.
> any reason to not allow external ALERTs?

Currently we are using ALERTS only for PM events, do we have to allow displaying external Alerts in the Alerts TAB as well???

> 
> > Detailed Design
> > :http://wiki.ovirt.org/wiki/Features/Design/DetailedExternalEvents
> 
> > Adding is_external boolean field to audit_log with a default value
> > of false
> 
> hmmm, i'm not sure it makes sense to inject any event, just flagging
> it
> as external.
> why not just add a new AuditLogType of 'External' (i.e., just another
> event id?
> it is easy enough to search for it, etc.

We are adding not one AuditLogType rather , it will be 3 or 4 (depends on we support also Alerts)
The additional is_external is defaulted to false , so , existing code is not influenced
I think that in the search it will be simpler to refer to is_external rather to the 3 or 4 specific types
Also , cleanup of old external events should use this column 


> 
> > New command is exposed currently only to SuperUser
> 
> I assume you mean there is a new permission, which by default is
> added
> only to superuser role, and admin can add it to other custom roles?
> I also assume this is only relevant to admin users, not to user
> roles?

Yes

> 
> other questions:
> 1. worth detailing all fields of the event which could be passed to
> this.

Currently only the severity and the message text as stated in the doc.

> 2. can an admin add events to entities they don't have permissions on
> (I'm guessing yes, since admins aren't filtered from seeing all
> entities, so implicitly, they have permission to all entities)
> otherwise (if intent is to limit permisisons), an event is an action
> on
> multiple entities, so for any field which is passed for the event
> (vm_id, (vds)host_id, etc.), you'd need to check admin has
> 'AddExternalEvent' permission on.
> 
> the main reason i think doing permissions may hold merit is it will
> allow to give this permission by default in more roles, rather than
> only
> for superuser, which may make it more viable for UI plugins that
> would
> try to leverage this.


I am missing here something, it should be an external event, i.e. additional command invoked by any plug-in
What is the relation to current events ?

> 
> 3. REST API modeling for adding an event (is that a PUT on the event
> collection, a POST)?
> can it be done only on root events collection, or on events of
> entities
> as well (taking the entity id from url, rather than as a parameter),
> etc.
> 

Again, the only info I have from the requirement is to support an additional command.
The command invoker is responsible for the event text 
It seems that you are talking about invoking our events from external plug-ins as well 




From iheim at redhat.com  Sun Nov 11 07:10:32 2012
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 11 Nov 2012 09:10:32 +0200
Subject: [Engine-devel] [Design for 3.2 RFE] Adding support for external
 events
In-Reply-To: <1368899630.8953606.1352583629355.JavaMail.root@redhat.com>
References: <1368899630.8953606.1352583629355.JavaMail.root@redhat.com>
Message-ID: <509F4F68.1060409@redhat.com>

On 11/10/2012 11:40 PM, Eli Mesika wrote:
>
>
> ----- Original Message -----
>> From: "Itamar Heim" <iheim at redhat.com>
>> To: "Eli Mesika" <emesika at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>, "Einav Cohen" <ecohen at redhat.com>, "Michael Pasternak"
>> <mpastern at redhat.com>
>> Sent: Friday, November 9, 2012 10:55:58 AM
>> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Adding support for external events
>>
>> On 11/08/2012 05:17 PM, Eli Mesika wrote:
>>> Hi
>>>
>>> Please review , any comments are welcomed (please note that API
>>> section is still in TBD)
>>>
>>> RFE :https://bugzilla.redhat.com/show_bug.cgi?id=873223
>>> Requirements : http://wiki.ovirt.org/wiki/Features/ExternalEvents
>>
>>> Events are classified as NORMAL , WARNING or ERROR and UI will
>>> display different icon according to that.
>> any reason to not allow external ALERTs?
>
> Currently we are using ALERTS only for PM events, do we have to allow displaying external Alerts in the Alerts TAB as well???

not a must, just asking.
if an external system wants to inject an event the temperature of a host 
is critical, its sounds more like an 'alert' to me than 'error'.

>
>>
>>> Detailed Design
>>> :http://wiki.ovirt.org/wiki/Features/Design/DetailedExternalEvents
>>
>>> Adding is_external boolean field to audit_log with a default value
>>> of false
>>
>> hmmm, i'm not sure it makes sense to inject any event, just flagging
>> it
>> as external.
>> why not just add a new AuditLogType of 'External' (i.e., just another
>> event id?
>> it is easy enough to search for it, etc.
>
> We are adding not one AuditLogType rather , it will be 3 or 4 (depends on we support also Alerts)

can't we separate the severity from the event id?
why are the two tightly coupled?

> The additional is_external is defaulted to false , so , existing code is not influenced
> I think that in the search it will be simpler to refer to is_external rather to the 3 or 4 specific types
> Also , cleanup of old external events should use this column

why should cleanup be different for internal and external events?

>
>
>>
>>> New command is exposed currently only to SuperUser
>>
>> I assume you mean there is a new permission, which by default is
>> added
>> only to superuser role, and admin can add it to other custom roles?
>> I also assume this is only relevant to admin users, not to user
>> roles?
>
> Yes
>
>>
>> other questions:
>> 1. worth detailing all fields of the event which could be passed to
>> this.
>
> Currently only the severity and the message text as stated in the doc.

I don't think this is good enough. idea is to be able to inject events 
as they relate to entities (host,storage,vm,etc.)

>
>> 2. can an admin add events to entities they don't have permissions on
>> (I'm guessing yes, since admins aren't filtered from seeing all
>> entities, so implicitly, they have permission to all entities)
>> otherwise (if intent is to limit permisisons), an event is an action
>> on
>> multiple entities, so for any field which is passed for the event
>> (vm_id, (vds)host_id, etc.), you'd need to check admin has
>> 'AddExternalEvent' permission on.
>>
>> the main reason i think doing permissions may hold merit is it will
>> allow to give this permission by default in more roles, rather than
>> only
>> for superuser, which may make it more viable for UI plugins that
>> would
>> try to leverage this.
>
>
> I am missing here something, it should be an external event, i.e. additional command invoked by any plug-in
> What is the relation to current events ?

to current entities, not current events.
since the external events are about entities...

>
>>
>> 3. REST API modeling for adding an event (is that a PUT on the event
>> collection, a POST)?
>> can it be done only on root events collection, or on events of
>> entities
>> as well (taking the entity id from url, rather than as a parameter),
>> etc.
>>
>
> Again, the only info I have from the requirement is to support an additional command.
> The command invoker is responsible for the event text

my question was about the REST modeling of this new command (especially 
as it is relevant only to the REST API, not to the UI).
not sure what you mean by 'event text' here.

> It seems that you are talking about invoking our events from external plug-ins as well

well, anything external. in any case they would be using the REST API 
for this.


From ykaul at redhat.com  Sun Nov 11 07:50:41 2012
From: ykaul at redhat.com (Yaniv Kaul)
Date: Sun, 11 Nov 2012 09:50:41 +0200
Subject: [Engine-devel] [Design for 3.2 RFE] Adding support for external
 events
In-Reply-To: <1368899630.8953606.1352583629355.JavaMail.root@redhat.com>
References: <1368899630.8953606.1352583629355.JavaMail.root@redhat.com>
Message-ID: <509F58D1.6070300@redhat.com>

On 11/10/2012 11:40 PM, Eli Mesika wrote:
>
> ----- Original Message -----
>> From: "Itamar Heim" <iheim at redhat.com>
>> To: "Eli Mesika" <emesika at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>, "Einav Cohen" <ecohen at redhat.com>, "Michael Pasternak"
>> <mpastern at redhat.com>
>> Sent: Friday, November 9, 2012 10:55:58 AM
>> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Adding support for external events
>>
>> On 11/08/2012 05:17 PM, Eli Mesika wrote:
>>> Hi
>>>
>>> Please review , any comments are welcomed (please note that API
>>> section is still in TBD)
>>>
>>> RFE :https://bugzilla.redhat.com/show_bug.cgi?id=873223
>>> Requirements : http://wiki.ovirt.org/wiki/Features/ExternalEvents
>>> Events are classified as NORMAL , WARNING or ERROR and UI will
>>> display different icon according to that.
>> any reason to not allow external ALERTs?
> Currently we are using ALERTS only for PM events, do we have to allow displaying external Alerts in the Alerts TAB as well???
>
>>> Detailed Design
>>> :http://wiki.ovirt.org/wiki/Features/Design/DetailedExternalEvents
>>> Adding is_external boolean field to audit_log with a default value
>>> of false
>> hmmm, i'm not sure it makes sense to inject any event, just flagging
>> it
>> as external.
>> why not just add a new AuditLogType of 'External' (i.e., just another
>> event id?
>> it is easy enough to search for it, etc.
> We are adding not one AuditLogType rather , it will be 3 or 4 (depends on we support also Alerts)
> The additional is_external is defaulted to false , so , existing code is not influenced
> I think that in the search it will be simpler to refer to is_external rather to the 3 or 4 specific types
> Also , cleanup of old external events should use this column
>
>
>>> New command is exposed currently only to SuperUser
>> I assume you mean there is a new permission, which by default is
>> added
>> only to superuser role, and admin can add it to other custom roles?
>> I also assume this is only relevant to admin users, not to user
>> roles?
> Yes

What's the protection against LDAP injection, SQL injection, Javascript 
injection ... ?
How do we sanitize the input of the event?

Regardless, what about localization? Can the plugin know in which 
language it should inject the event?
Y.

>
>> other questions:
>> 1. worth detailing all fields of the event which could be passed to
>> this.
> Currently only the severity and the message text as stated in the doc.
>
>> 2. can an admin add events to entities they don't have permissions on
>> (I'm guessing yes, since admins aren't filtered from seeing all
>> entities, so implicitly, they have permission to all entities)
>> otherwise (if intent is to limit permisisons), an event is an action
>> on
>> multiple entities, so for any field which is passed for the event
>> (vm_id, (vds)host_id, etc.), you'd need to check admin has
>> 'AddExternalEvent' permission on.
>>
>> the main reason i think doing permissions may hold merit is it will
>> allow to give this permission by default in more roles, rather than
>> only
>> for superuser, which may make it more viable for UI plugins that
>> would
>> try to leverage this.
>
> I am missing here something, it should be an external event, i.e. additional command invoked by any plug-in
> What is the relation to current events ?
>
>> 3. REST API modeling for adding an event (is that a PUT on the event
>> collection, a POST)?
>> can it be done only on root events collection, or on events of
>> entities
>> as well (taking the entity id from url, rather than as a parameter),
>> etc.
>>
> Again, the only info I have from the requirement is to support an additional command.
> The command invoker is responsible for the event text
> It seems that you are talking about invoking our events from external plug-ins as well
>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From iheim at redhat.com  Sun Nov 11 08:06:19 2012
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 11 Nov 2012 10:06:19 +0200
Subject: [Engine-devel] [Design for 3.2 RFE] Adding support for external
 events
In-Reply-To: <509F58D1.6070300@redhat.com>
References: <1368899630.8953606.1352583629355.JavaMail.root@redhat.com>
	<509F58D1.6070300@redhat.com>
Message-ID: <509F5C7B.2030801@redhat.com>

On 11/11/2012 09:50 AM, Yaniv Kaul wrote:
> On 11/10/2012 11:40 PM, Eli Mesika wrote:
>>
>> ----- Original Message -----
>>> From: "Itamar Heim" <iheim at redhat.com>
>>> To: "Eli Mesika" <emesika at redhat.com>
>>> Cc: "engine-devel" <engine-devel at ovirt.org>, "Einav Cohen"
>>> <ecohen at redhat.com>, "Michael Pasternak"
>>> <mpastern at redhat.com>
>>> Sent: Friday, November 9, 2012 10:55:58 AM
>>> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Adding support for
>>> external events
>>>
>>> On 11/08/2012 05:17 PM, Eli Mesika wrote:
>>>> Hi
>>>>
>>>> Please review , any comments are welcomed (please note that API
>>>> section is still in TBD)
>>>>
>>>> RFE :https://bugzilla.redhat.com/show_bug.cgi?id=873223
>>>> Requirements : http://wiki.ovirt.org/wiki/Features/ExternalEvents
>>>> Events are classified as NORMAL , WARNING or ERROR and UI will
>>>> display different icon according to that.
>>> any reason to not allow external ALERTs?
>> Currently we are using ALERTS only for PM events, do we have to allow
>> displaying external Alerts in the Alerts TAB as well???
>>
>>>> Detailed Design
>>>> :http://wiki.ovirt.org/wiki/Features/Design/DetailedExternalEvents
>>>> Adding is_external boolean field to audit_log with a default value
>>>> of false
>>> hmmm, i'm not sure it makes sense to inject any event, just flagging
>>> it
>>> as external.
>>> why not just add a new AuditLogType of 'External' (i.e., just another
>>> event id?
>>> it is easy enough to search for it, etc.
>> We are adding not one AuditLogType rather , it will be 3 or 4 (depends
>> on we support also Alerts)
>> The additional is_external is defaulted to false , so , existing code
>> is not influenced
>> I think that in the search it will be simpler to refer to is_external
>> rather to the 3 or 4 specific types
>> Also , cleanup of old external events should use this column
>>
>>
>>>> New command is exposed currently only to SuperUser
>>> I assume you mean there is a new permission, which by default is
>>> added
>>> only to superuser role, and admin can add it to other custom roles?
>>> I also assume this is only relevant to admin users, not to user
>>> roles?
>> Yes
>
> What's the protection against LDAP injection, SQL injection, Javascript
> injection ... ?
> How do we sanitize the input of the event?
>
> Regardless, what about localization? Can the plugin know in which
> language it should inject the event?

audit log is not localized at this point.


From ykaul at redhat.com  Sun Nov 11 09:45:34 2012
From: ykaul at redhat.com (Yaniv Kaul)
Date: Sun, 11 Nov 2012 11:45:34 +0200
Subject: [Engine-devel] SPICE IP override
In-Reply-To: <1197121097.6204891.1352278334446.JavaMail.root@redhat.com>
References: <1197121097.6204891.1352278334446.JavaMail.root@redhat.com>
Message-ID: <509F73BE.4020301@redhat.com>

On 11/07/2012 10:52 AM, Simon Grinberg wrote:
>
> ----- Original Message -----
>> From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
>> To: engine-devel at ovirt.org
>> Sent: Tuesday, November 6, 2012 10:39:58 PM
>> Subject: [Engine-devel] SPICE IP override
>>
>> Hi all,
>> On behalf of Tomas - please check out the proposal for enhancing our
>> SPICE integration to allow to return a custom IP/FQDN instead of the
>> host IP address.
>> http://wiki.ovirt.org/wiki/Features/Display_Address_Override
>> All comments are welcome...
> My 2 cents,
>
> This works under the assumption that all the users are either outside of the organization or inside.
> But think of some of the following scenarios based on a topology where users in the main office are inside the corporate network while users on remote offices / WAN are on a detached different network on the other side of the NAT / public firewall :
>
> With current 'per host override' proposal:
> 1. Admin from the main office won't be able to access the VM console
> 2. No Mixed environment, meaning that you have to have designated clusters for remote offices users vs main office users - otherwise connectivity to the console is determined based on scheduler decision, or may break by live migration.
> 3. Based on #2, If I'm a user travelling between offices I'll have to ask the admin to turn off my VM and move it to internal cluster before I can reconnect
>
> My suggestion is to covert this to 'alternative' IP/FQDN sending the spice client both internal fqdn/ip and the alternative. The spice client should detect which is available of the two and auto-connect.
>
> This requires enhancement of the spice client, but still solves all the issues raised above (actually it solves about 90% of the use cases I've heard about in the past).
>
> Another alternative is for the engine to 'guess' or 'elect' which to use, alternative or main, based on the IP of the client - meaning admin provides the client ranges for providing internal host address vs alternative - but this is more complicated compared for the previous suggestion
>
> Thoughts?

Lets not re-invent the wheel. This problem has been pondered before and 
solved[1], for all scenarios:
internal clients connecting to internal resources;
internal clients connecting to external resources, without the need for 
any intermediate assistance
external clients connecting to internal resources, with the need for 
intermediate assistance.
VPN clients connecting to internal resources, with or without an 
internal IP.

Any other solution you'll try to come up with will bring you back to 
this standard, well known (along with its faults) method.

The browser client will use PAC to determine how to connect to the hosts 
and will deliver this to the client. It's also a good path towards real 
proxy support for Spice.
(Regardless, we still need to deal with the Spice protocol's migration 
command of course).


[1] http://en.wikipedia.org/wiki/Proxy_auto-config




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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121111/17c7b539/attachment.html>

From emesika at redhat.com  Sun Nov 11 11:18:53 2012
From: emesika at redhat.com (Eli Mesika)
Date: Sun, 11 Nov 2012 06:18:53 -0500 (EST)
Subject: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection
 algorithm for Power Management operations
In-Reply-To: <1357032386.8570374.1352455565925.JavaMail.root@redhat.com>
Message-ID: <1008746778.9047332.1352632733372.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Friday, November 9, 2012 12:06:05 PM
> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
> 
> 
> 
> ----- Original Message -----
> > From: "Itamar Heim" <iheim at redhat.com>
> > To: "Eli Mesika" <emesika at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>, "Michael Pasternak"
> > <mpastern at redhat.com>, "Simon Grinberg"
> > <sgrinber at redhat.com>, "Dan Kenigsberg" <danken at redhat.com>
> > Sent: Friday, November 9, 2012 12:02:37 PM
> > Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy
> > selection algorithm for Power Management operations
> > 
> > On 11/09/2012 10:52 AM, Eli Mesika wrote:
> > 
> > >> >
> > >> >  > FenceWrapper
> > >> >
> > >> >i understand danken suggested going this way, rather than than
> > >> >another
> > >> >instance of vdsm.
> > >> >is vdsm only calling these scripts today and all logic is in
> > >> >engine,
> > >> >or
> > >> >does vdsm has any logic in wrapping these scripts (not a
> > >> >blocker
> > >> >to
> > >> >doing FenceWrapper, just worth extracting that logic from vdsm
> > >> >to
> > >> >such a
> > >> >script, then using it in both. i hope answer is 'no logic'...)
> > > vdsm has some logic that maps between the call passed to it from
> > > engine and the actual parameters generated for the script.
> > > AFAIK, this logic only "builds" the correct arguments for the
> > > command according to the agent type
> > >
> > 
> > can we extract it to an external wrapper?
> > I'd hate to fix bugs/changes twice for this.
> 
> I'll check it with danken on SUN

Well, looked at it a bit , the VDSM code is in fenceNote function in API.py
What I think is that we can exclude the fenceNote implementation to a separate fence.py file and call it from the API.py
Then we can use one of the following in Java to call the method from fence.py
1) jython
2) org.python.util.PythonInterpreter

See http://stackoverflow.com/questions/8898765/calling-python-in-java

danken, what do you think ?

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


From danken at redhat.com  Sun Nov 11 11:27:59 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Sun, 11 Nov 2012 13:27:59 +0200
Subject: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection
 algorithm for Power Management operations
In-Reply-To: <1357032386.8570374.1352455565925.JavaMail.root@redhat.com>
References: <509CD4BD.4010606@redhat.com>
	<1357032386.8570374.1352455565925.JavaMail.root@redhat.com>
Message-ID: <20121111112759.GQ28849@redhat.com>

On Fri, Nov 09, 2012 at 05:06:05AM -0500, Eli Mesika wrote:
> 
> 
> ----- Original Message -----
> > From: "Itamar Heim" <iheim at redhat.com>
> > To: "Eli Mesika" <emesika at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>, "Michael Pasternak" <mpastern at redhat.com>, "Simon Grinberg"
> > <sgrinber at redhat.com>, "Dan Kenigsberg" <danken at redhat.com>
> > Sent: Friday, November 9, 2012 12:02:37 PM
> > Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
> > 
> > On 11/09/2012 10:52 AM, Eli Mesika wrote:
> > 
> > >> >
> > >> >  > FenceWrapper
> > >> >
> > >> >i understand danken suggested going this way, rather than than
> > >> >another
> > >> >instance of vdsm.
> > >> >is vdsm only calling these scripts today and all logic is in
> > >> >engine,
> > >> >or
> > >> >does vdsm has any logic in wrapping these scripts (not a blocker
> > >> >to
> > >> >doing FenceWrapper, just worth extracting that logic from vdsm to
> > >> >such a
> > >> >script, then using it in both. i hope answer is 'no logic'...)
> > > vdsm has some logic that maps between the call passed to it from
> > > engine and the actual parameters generated for the script.
> > > AFAIK, this logic only "builds" the correct arguments for the
> > > command according to the agent type
> > >
> > 
> > can we extract it to an external wrapper?
> > I'd hate to fix bugs/changes twice for this.
> 
> I'll check it with danken on SUN

Saggi has had a nascent attempt to factor the little logic we have out
http://gerrit.ovirt.org/#/c/7190/7/vdsm/API.py
AFAIR there's nothing there beyond:
- log everything but passwords,
- build the input stream,
- run the script
- convert its return code
and there's also killing dormant scripts on vdsm exist (which I find not
important at all).

Dan.


From iheim at redhat.com  Sun Nov 11 11:44:50 2012
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 11 Nov 2012 13:44:50 +0200
Subject: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection
 algorithm for Power Management operations
In-Reply-To: <20121111112759.GQ28849@redhat.com>
References: <509CD4BD.4010606@redhat.com>
	<1357032386.8570374.1352455565925.JavaMail.root@redhat.com>
	<20121111112759.GQ28849@redhat.com>
Message-ID: <509F8FB2.9050601@redhat.com>

On 11/11/2012 01:27 PM, Dan Kenigsberg wrote:
> On Fri, Nov 09, 2012 at 05:06:05AM -0500, Eli Mesika wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Itamar Heim" <iheim at redhat.com>
>>> To: "Eli Mesika" <emesika at redhat.com>
>>> Cc: "engine-devel" <engine-devel at ovirt.org>, "Michael Pasternak" <mpastern at redhat.com>, "Simon Grinberg"
>>> <sgrinber at redhat.com>, "Dan Kenigsberg" <danken at redhat.com>
>>> Sent: Friday, November 9, 2012 12:02:37 PM
>>> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
>>>
>>> On 11/09/2012 10:52 AM, Eli Mesika wrote:
>>>
>>>>>>
>>>>>>   > FenceWrapper
>>>>>>
>>>>>> i understand danken suggested going this way, rather than than
>>>>>> another
>>>>>> instance of vdsm.
>>>>>> is vdsm only calling these scripts today and all logic is in
>>>>>> engine,
>>>>>> or
>>>>>> does vdsm has any logic in wrapping these scripts (not a blocker
>>>>>> to
>>>>>> doing FenceWrapper, just worth extracting that logic from vdsm to
>>>>>> such a
>>>>>> script, then using it in both. i hope answer is 'no logic'...)
>>>> vdsm has some logic that maps between the call passed to it from
>>>> engine and the actual parameters generated for the script.
>>>> AFAIK, this logic only "builds" the correct arguments for the
>>>> command according to the agent type
>>>>
>>>
>>> can we extract it to an external wrapper?
>>> I'd hate to fix bugs/changes twice for this.
>>
>> I'll check it with danken on SUN
>
> Saggi has had a nascent attempt to factor the little logic we have out
> http://gerrit.ovirt.org/#/c/7190/7/vdsm/API.py
> AFAIR there's nothing there beyond:
> - log everything but passwords,
> - build the input stream,
> - run the script
> - convert its return code
> and there's also killing dormant scripts on vdsm exist (which I find not
> important at all).

if the wrapping isn't doing anything but calling the scripts, then doing 
it again from java isn't an issue.
it's only an issue if there is any business logic in the wrapping.


From iheim at redhat.com  Sun Nov 11 11:45:53 2012
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 11 Nov 2012 13:45:53 +0200
Subject: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection
 algorithm for Power Management operations
In-Reply-To: <1008746778.9047332.1352632733372.JavaMail.root@redhat.com>
References: <1008746778.9047332.1352632733372.JavaMail.root@redhat.com>
Message-ID: <509F8FF1.7080906@redhat.com>

On 11/11/2012 01:18 PM, Eli Mesika wrote:
>
>
> ----- Original Message -----
>> From: "Eli Mesika" <emesika at redhat.com>
>> To: "Itamar Heim" <iheim at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Friday, November 9, 2012 12:06:05 PM
>> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
>>
>>
>>
>> ----- Original Message -----
>>> From: "Itamar Heim" <iheim at redhat.com>
>>> To: "Eli Mesika" <emesika at redhat.com>
>>> Cc: "engine-devel" <engine-devel at ovirt.org>, "Michael Pasternak"
>>> <mpastern at redhat.com>, "Simon Grinberg"
>>> <sgrinber at redhat.com>, "Dan Kenigsberg" <danken at redhat.com>
>>> Sent: Friday, November 9, 2012 12:02:37 PM
>>> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy
>>> selection algorithm for Power Management operations
>>>
>>> On 11/09/2012 10:52 AM, Eli Mesika wrote:
>>>
>>>>>>
>>>>>>   > FenceWrapper
>>>>>>
>>>>>> i understand danken suggested going this way, rather than than
>>>>>> another
>>>>>> instance of vdsm.
>>>>>> is vdsm only calling these scripts today and all logic is in
>>>>>> engine,
>>>>>> or
>>>>>> does vdsm has any logic in wrapping these scripts (not a
>>>>>> blocker
>>>>>> to
>>>>>> doing FenceWrapper, just worth extracting that logic from vdsm
>>>>>> to
>>>>>> such a
>>>>>> script, then using it in both. i hope answer is 'no logic'...)
>>>> vdsm has some logic that maps between the call passed to it from
>>>> engine and the actual parameters generated for the script.
>>>> AFAIK, this logic only "builds" the correct arguments for the
>>>> command according to the agent type
>>>>
>>>
>>> can we extract it to an external wrapper?
>>> I'd hate to fix bugs/changes twice for this.
>>
>> I'll check it with danken on SUN
>
> Well, looked at it a bit , the VDSM code is in fenceNote function in API.py
> What I think is that we can exclude the fenceNote implementation to a separate fence.py file and call it from the API.py
> Then we can use one of the following in Java to call the method from fence.py
> 1) jython
> 2) org.python.util.PythonInterpreter
>
> See http://stackoverflow.com/questions/8898765/calling-python-in-java

if this is JNI, i think it won't fly for engine.
JNA may be viable.
or just shell launch


>
> danken, what do you think ?
>
>>
>>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>




From shaharh at redhat.com  Sun Nov 11 11:59:36 2012
From: shaharh at redhat.com (Shahar Havivi)
Date: Sun, 11 Nov 2012 13:59:36 +0200
Subject: [Engine-devel] ovirt-engine master - no hosts in hosts tab!
In-Reply-To: <2044370054.8951893.1352582319213.JavaMail.root@redhat.com>
References: <355343361.8249970.1352581393597.JavaMail.root@redhat.com>
	<2044370054.8951893.1352582319213.JavaMail.root@redhat.com>
Message-ID: <20121111115935.GA24929@redhat.com>

On 10.11.12 16:18, Eli Mesika wrote:
> 
> 
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > To: "Eli Mesika" <emesika at redhat.com>
> > Cc: "Laszlo Hornyak" <lhornyak at redhat.com>, "Dhandapani" <dgopal at redhat.com>, "Daniel Erez" <derez at redhat.com>, "Maor
> > Lipchuk" <mlipchuk at redhat.com>, "Omer Frenkel" <ofrenkel at redhat.com>, "Kanagaraj M" <kmayilsa at redhat.com>, "Sharad
> > Mishra" <snmishra at linux.vnet.ibm.com>, "Vered Volansky" <vvolansk at redhat.com>, "Juan Hernandez"
> > <juan.hernandez at redhat.com>, "Shireesh Anjal" <sanjal at redhat.com>, "Shahar Havivi" <shavivi at redhat.com>, "Michael
> > Kublin" <mkublin at redhat.com>, "Ravi Nori" <rnori at redhat.com>, "Alona Kaplan" <alkaplan at redhat.com>, "Michael
> > Pasternak" <mpastern at redhat.com>, "Yair Zaslavsky" <yzaslavs at redhat.com>, "Allon Mureinik" <amureini at redhat.com>,
> > "engine-devel" <engine-devel at ovirt.org>
> > Sent: Saturday, November 10, 2012 11:03:13 PM
> > Subject: Re: ovirt-engine master - no hosts in hosts tab!
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Eli Mesika" <emesika at redhat.com>
> > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > Cc: "Laszlo Hornyak" <lhornyak at redhat.com>, "Dhandapani"
> > > <dgopal at redhat.com>, "Daniel Erez" <derez at redhat.com>, "Maor
> > > Lipchuk" <mlipchuk at redhat.com>, "Omer Frenkel"
> > > <ofrenkel at redhat.com>, "Kanagaraj M" <kmayilsa at redhat.com>,
> > > "Sharad
> > > Mishra" <snmishra at linux.vnet.ibm.com>, "Vered Volansky"
> > > <vvolansk at redhat.com>, "Juan Hernandez"
> > > <juan.hernandez at redhat.com>, "Shireesh Anjal" <sanjal at redhat.com>,
> > > "Shahar Havivi" <shavivi at redhat.com>, "Michael
> > > Kublin" <mkublin at redhat.com>, "Ravi Nori" <rnori at redhat.com>,
> > > "Alona Kaplan" <alkaplan at redhat.com>, "Michael
> > > Pasternak" <mpastern at redhat.com>, "Yair Zaslavsky"
> > > <yzaslavs at redhat.com>, "Allon Mureinik" <amureini at redhat.com>,
> > > "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Saturday, November 10, 2012 11:00:05 PM
> > > Subject: Re: ovirt-engine master - no hosts in hosts tab!
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > To: "engine-devel" <engine-devel at ovirt.org>
> > > > Cc: "Laszlo Hornyak" <lhornyak at redhat.com>, "Dhandapani"
> > > > <dgopal at redhat.com>, "Eli Mesika" <emesika at redhat.com>,
> > > > "Daniel Erez" <derez at redhat.com>, "Maor Lipchuk"
> > > > <mlipchuk at redhat.com>, "Omer Frenkel" <ofrenkel at redhat.com>,
> > > > "Kanagaraj M" <kmayilsa at redhat.com>, "Sharad Mishra"
> > > > <snmishra at linux.vnet.ibm.com>, "Vered Volansky"
> > > > <vvolansk at redhat.com>, "Juan Hernandez"
> > > > <juan.hernandez at redhat.com>, "Shireesh Anjal"
> > > > <sanjal at redhat.com>,
> > > > "Shahar
> > > > Havivi" <shavivi at redhat.com>, "Michael Kublin"
> > > > <mkublin at redhat.com>, "Ravi Nori" <rnori at redhat.com>, "Alona
> > > > Kaplan"
> > > > <alkaplan at redhat.com>, "Michael Pasternak" <mpastern at redhat.com>,
> > > > "Yair Zaslavsky" <yzaslavs at redhat.com>, "Allon
> > > > Mureinik" <amureini at redhat.com>
> > > > Sent: Saturday, November 10, 2012 10:34:22 PM
> > > > Subject: ovirt-engine master - no hosts in hosts tab!
> > > > 
> > > > Hello,
> > > > 
> > > > Last working:
> > > > a665ec3af7b2dd04e80007b1c062868d3e049fce from Mon Nov 5 12:28:23
> > > > 2012
> > > > +0200
> > > > 
> > > > Master head:
> > > > 2dc9b518099ec1ac3995abf1483f43cdcb6eb2b8 from Wed Nov 7 15:25:03
> > > > 2012
> > > > +0100
> > > > 
> > > > When adding a new host, host is added to database, bootstrap is
> > > > running, but hosts tab is empty!
> > > > 
> > > > Did not find anything that directly relates to this, CCing all
> > > > committers.
> > > 
> > > 
> > > Seems that your database is not updated with recent changes
> > > Can you please run the upgrade.sh script on your db ?
> > 
> > This is fresh install.
> 
> We had talked in IRC
> Agreed to try reproducing tomorrow ...
its look like this patch cause the problem,
I am fixing it.
> 
> > 
> > > 
> > > > 
> > > > Please fix,
> > > > Alon.
> > > > 
> > > 
> > 


From emesika at redhat.com  Sun Nov 11 12:20:31 2012
From: emesika at redhat.com (Eli Mesika)
Date: Sun, 11 Nov 2012 07:20:31 -0500 (EST)
Subject: [Engine-devel] [Design for 3.2 RFE] Adding support for external
 events
In-Reply-To: <509F4F68.1060409@redhat.com>
Message-ID: <996319562.9059890.1352636431719.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "Einav Cohen" <ecohen at redhat.com>, "Michael Pasternak"
> <mpastern at redhat.com>
> Sent: Sunday, November 11, 2012 9:10:32 AM
> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Adding support for external events
> 
> On 11/10/2012 11:40 PM, Eli Mesika wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Itamar Heim" <iheim at redhat.com>
> >> To: "Eli Mesika" <emesika at redhat.com>
> >> Cc: "engine-devel" <engine-devel at ovirt.org>, "Einav Cohen"
> >> <ecohen at redhat.com>, "Michael Pasternak"
> >> <mpastern at redhat.com>
> >> Sent: Friday, November 9, 2012 10:55:58 AM
> >> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Adding support
> >> for external events
> >>
> >> On 11/08/2012 05:17 PM, Eli Mesika wrote:
> >>> Hi
> >>>
> >>> Please review , any comments are welcomed (please note that API
> >>> section is still in TBD)
> >>>
> >>> RFE :https://bugzilla.redhat.com/show_bug.cgi?id=873223
> >>> Requirements : http://wiki.ovirt.org/wiki/Features/ExternalEvents
> >>
> >>> Events are classified as NORMAL , WARNING or ERROR and UI will
> >>> display different icon according to that.
> >> any reason to not allow external ALERTs?
> >
> > Currently we are using ALERTS only for PM events, do we have to
> > allow displaying external Alerts in the Alerts TAB as well???
> 
> not a must, just asking.
> if an external system wants to inject an event the temperature of a
> host
> is critical, its sounds more like an 'alert' to me than 'error'.
OK,make sense , I will add it to the design 
> 
> >
> >>
> >>> Detailed Design
> >>> :http://wiki.ovirt.org/wiki/Features/Design/DetailedExternalEvents
> >>
> >>> Adding is_external boolean field to audit_log with a default
> >>> value
> >>> of false
> >>
> >> hmmm, i'm not sure it makes sense to inject any event, just
> >> flagging
> >> it
> >> as external.
> >> why not just add a new AuditLogType of 'External' (i.e., just
> >> another
> >> event id?
> >> it is easy enough to search for it, etc.
> >
> > We are adding not one AuditLogType rather , it will be 3 or 4
> > (depends on we support also Alerts)
> 
> can't we separate the severity from the event id?
> why are the two tightly coupled?

No we can't currently , we are assigning each AuditLogType a certain severity, so , I will have to define here 4 for NORMAL , WARNING , ERROR and ALERT

> 
> > The additional is_external is defaulted to false , so , existing
> > code is not influenced
> > I think that in the search it will be simpler to refer to
> > is_external rather to the 3 or 4 specific types
> > Also , cleanup of old external events should use this column
> 
> why should cleanup be different for internal and external events?

I think that since those are external events ,it may clean up on a different period and forced by the regular application event clean-up value

> 
> >
> >
> >>
> >>> New command is exposed currently only to SuperUser
> >>
> >> I assume you mean there is a new permission, which by default is
> >> added
> >> only to superuser role, and admin can add it to other custom
> >> roles?
> >> I also assume this is only relevant to admin users, not to user
> >> roles?
> >
> > Yes
> >
> >>
> >> other questions:
> >> 1. worth detailing all fields of the event which could be passed
> >> to
> >> this.
> >
> > Currently only the severity and the message text as stated in the
> > doc.
> 
> I don't think this is good enough. idea is to be able to inject
> events
> as they relate to entities (host,storage,vm,etc.)
> 
> >
> >> 2. can an admin add events to entities they don't have permissions
> >> on
> >> (I'm guessing yes, since admins aren't filtered from seeing all
> >> entities, so implicitly, they have permission to all entities)
> >> otherwise (if intent is to limit permisisons), an event is an
> >> action
> >> on
> >> multiple entities, so for any field which is passed for the event
> >> (vm_id, (vds)host_id, etc.), you'd need to check admin has
> >> 'AddExternalEvent' permission on.
> >>
> >> the main reason i think doing permissions may hold merit is it
> >> will
> >> allow to give this permission by default in more roles, rather
> >> than
> >> only
> >> for superuser, which may make it more viable for UI plugins that
> >> would
> >> try to leverage this.
> >
> >
> > I am missing here something, it should be an external event, i.e.
> > additional command invoked by any plug-in
> > What is the relation to current events ?
> 
> to current entities, not current events.
> since the external events are about entities...

How entities are passed to the engine?
Do we have a full use-case for that ?

> 
> >
> >>
> >> 3. REST API modeling for adding an event (is that a PUT on the
> >> event
> >> collection, a POST)?
> >> can it be done only on root events collection, or on events of
> >> entities
> >> as well (taking the entity id from url, rather than as a
> >> parameter),
> >> etc.
> >>
> >
> > Again, the only info I have from the requirement is to support an
> > additional command.
> > The command invoker is responsible for the event text
> 
> my question was about the REST modeling of this new command
> (especially
> as it is relevant only to the REST API, not to the UI).
> not sure what you mean by 'event text' here.
> 
> > It seems that you are talking about invoking our events from
> > external plug-ins as well
> 
> well, anything external. in any case they would be using the REST API
> for this.
> 


From yzaslavs at redhat.com  Sun Nov 11 12:23:43 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Sun, 11 Nov 2012 07:23:43 -0500 (EST)
Subject: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection
 algorithm for Power Management operations
In-Reply-To: <1008746778.9047332.1352632733372.JavaMail.root@redhat.com>
Message-ID: <1447181418.30164286.1352636623495.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: "Dan Kenigsberg" <danken at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, November 11, 2012 1:18:53 PM
> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
> 
> 
> 
> ----- Original Message -----
> > From: "Eli Mesika" <emesika at redhat.com>
> > To: "Itamar Heim" <iheim at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Friday, November 9, 2012 12:06:05 PM
> > Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy
> > selection algorithm for Power Management operations
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Itamar Heim" <iheim at redhat.com>
> > > To: "Eli Mesika" <emesika at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>, "Michael Pasternak"
> > > <mpastern at redhat.com>, "Simon Grinberg"
> > > <sgrinber at redhat.com>, "Dan Kenigsberg" <danken at redhat.com>
> > > Sent: Friday, November 9, 2012 12:02:37 PM
> > > Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy
> > > selection algorithm for Power Management operations
> > > 
> > > On 11/09/2012 10:52 AM, Eli Mesika wrote:
> > > 
> > > >> >
> > > >> >  > FenceWrapper
> > > >> >
> > > >> >i understand danken suggested going this way, rather than
> > > >> >than
> > > >> >another
> > > >> >instance of vdsm.
> > > >> >is vdsm only calling these scripts today and all logic is in
> > > >> >engine,
> > > >> >or
> > > >> >does vdsm has any logic in wrapping these scripts (not a
> > > >> >blocker
> > > >> >to
> > > >> >doing FenceWrapper, just worth extracting that logic from
> > > >> >vdsm
> > > >> >to
> > > >> >such a
> > > >> >script, then using it in both. i hope answer is 'no
> > > >> >logic'...)
> > > > vdsm has some logic that maps between the call passed to it
> > > > from
> > > > engine and the actual parameters generated for the script.
> > > > AFAIK, this logic only "builds" the correct arguments for the
> > > > command according to the agent type
> > > >
> > > 
> > > can we extract it to an external wrapper?
> > > I'd hate to fix bugs/changes twice for this.
> > 
> > I'll check it with danken on SUN
> 
> Well, looked at it a bit , the VDSM code is in fenceNote function in
> API.py
> What I think is that we can exclude the fenceNote implementation to a
> separate fence.py file and call it from the API.py
> Then we can use one of the following in Java to call the method from
> fence.py
> 1) jython
> 2) org.python.util.PythonInterpreter
> 
> See http://stackoverflow.com/questions/8898765/calling-python-in-java
> 
> danken, what do you think ?

Hi,
JDK 6 (and above) has a ScriptEngine.
I would suggest using this JSR.

For example, look at - http://www.alittlemadness.com/2008/07/15/java-6-using-python-via-the-new-scripting-engine/

What kinda bothers me is the fact that both your link, the link I provided use Jython, and not Python - i.e the script itself has to run over the jvm.
We should see if the JVM allows us to run the fencing script (no JVM restrictions).
It's kinda surprising to me - I was sure that ScriptEngine can run Python (i.e - on the linux machine itself) and not Jython.
I will continue checking.

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


From yzaslavs at redhat.com  Sun Nov 11 12:27:06 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Sun, 11 Nov 2012 07:27:06 -0500 (EST)
Subject: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection
 algorithm for Power Management operations
In-Reply-To: <509F8FF1.7080906@redhat.com>
Message-ID: <978100951.30164358.1352636826217.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, November 11, 2012 1:45:53 PM
> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
> 
> On 11/11/2012 01:18 PM, Eli Mesika wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Eli Mesika" <emesika at redhat.com>
> >> To: "Itamar Heim" <iheim at redhat.com>
> >> Cc: "engine-devel" <engine-devel at ovirt.org>
> >> Sent: Friday, November 9, 2012 12:06:05 PM
> >> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy
> >> selection algorithm for Power Management operations
> >>
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Itamar Heim" <iheim at redhat.com>
> >>> To: "Eli Mesika" <emesika at redhat.com>
> >>> Cc: "engine-devel" <engine-devel at ovirt.org>, "Michael Pasternak"
> >>> <mpastern at redhat.com>, "Simon Grinberg"
> >>> <sgrinber at redhat.com>, "Dan Kenigsberg" <danken at redhat.com>
> >>> Sent: Friday, November 9, 2012 12:02:37 PM
> >>> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy
> >>> selection algorithm for Power Management operations
> >>>
> >>> On 11/09/2012 10:52 AM, Eli Mesika wrote:
> >>>
> >>>>>>
> >>>>>>   > FenceWrapper
> >>>>>>
> >>>>>> i understand danken suggested going this way, rather than than
> >>>>>> another
> >>>>>> instance of vdsm.
> >>>>>> is vdsm only calling these scripts today and all logic is in
> >>>>>> engine,
> >>>>>> or
> >>>>>> does vdsm has any logic in wrapping these scripts (not a
> >>>>>> blocker
> >>>>>> to
> >>>>>> doing FenceWrapper, just worth extracting that logic from vdsm
> >>>>>> to
> >>>>>> such a
> >>>>>> script, then using it in both. i hope answer is 'no logic'...)
> >>>> vdsm has some logic that maps between the call passed to it from
> >>>> engine and the actual parameters generated for the script.
> >>>> AFAIK, this logic only "builds" the correct arguments for the
> >>>> command according to the agent type
> >>>>
> >>>
> >>> can we extract it to an external wrapper?
> >>> I'd hate to fix bugs/changes twice for this.
> >>
> >> I'll check it with danken on SUN
> >
> > Well, looked at it a bit , the VDSM code is in fenceNote function
> > in API.py
> > What I think is that we can exclude the fenceNote implementation to
> > a separate fence.py file and call it from the API.py
> > Then we can use one of the following in Java to call the method
> > from fence.py
> > 1) jython
> > 2) org.python.util.PythonInterpreter
> >
> > See
> > http://stackoverflow.com/questions/8898765/calling-python-in-java
> 
> if this is JNI, i think it won't fly for engine.
> JNA may be viable.
> or just shell launch


Can you elaborate here on JNI vs JNA? (besides of course the risks of invoking JNI code from JEE code)?
Am I missing something else here?



> 
> 
> >
> > danken, what do you think ?
> >
> >>
> >>>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From iheim at redhat.com  Sun Nov 11 12:30:00 2012
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 11 Nov 2012 14:30:00 +0200
Subject: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection
 algorithm for Power Management operations
In-Reply-To: <978100951.30164358.1352636826217.JavaMail.root@redhat.com>
References: <978100951.30164358.1352636826217.JavaMail.root@redhat.com>
Message-ID: <509F9A48.7010608@redhat.com>

On 11/11/2012 02:27 PM, Yair Zaslavsky wrote:
>
>
> ----- Original Message -----
>> From: "Itamar Heim" <iheim at redhat.com>
>> To: "Eli Mesika" <emesika at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Sunday, November 11, 2012 1:45:53 PM
>> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
>>
>> On 11/11/2012 01:18 PM, Eli Mesika wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Eli Mesika" <emesika at redhat.com>
>>>> To: "Itamar Heim" <iheim at redhat.com>
>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>> Sent: Friday, November 9, 2012 12:06:05 PM
>>>> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy
>>>> selection algorithm for Power Management operations
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Itamar Heim" <iheim at redhat.com>
>>>>> To: "Eli Mesika" <emesika at redhat.com>
>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>, "Michael Pasternak"
>>>>> <mpastern at redhat.com>, "Simon Grinberg"
>>>>> <sgrinber at redhat.com>, "Dan Kenigsberg" <danken at redhat.com>
>>>>> Sent: Friday, November 9, 2012 12:02:37 PM
>>>>> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy
>>>>> selection algorithm for Power Management operations
>>>>>
>>>>> On 11/09/2012 10:52 AM, Eli Mesika wrote:
>>>>>
>>>>>>>>
>>>>>>>>    > FenceWrapper
>>>>>>>>
>>>>>>>> i understand danken suggested going this way, rather than than
>>>>>>>> another
>>>>>>>> instance of vdsm.
>>>>>>>> is vdsm only calling these scripts today and all logic is in
>>>>>>>> engine,
>>>>>>>> or
>>>>>>>> does vdsm has any logic in wrapping these scripts (not a
>>>>>>>> blocker
>>>>>>>> to
>>>>>>>> doing FenceWrapper, just worth extracting that logic from vdsm
>>>>>>>> to
>>>>>>>> such a
>>>>>>>> script, then using it in both. i hope answer is 'no logic'...)
>>>>>> vdsm has some logic that maps between the call passed to it from
>>>>>> engine and the actual parameters generated for the script.
>>>>>> AFAIK, this logic only "builds" the correct arguments for the
>>>>>> command according to the agent type
>>>>>>
>>>>>
>>>>> can we extract it to an external wrapper?
>>>>> I'd hate to fix bugs/changes twice for this.
>>>>
>>>> I'll check it with danken on SUN
>>>
>>> Well, looked at it a bit , the VDSM code is in fenceNote function
>>> in API.py
>>> What I think is that we can exclude the fenceNote implementation to
>>> a separate fence.py file and call it from the API.py
>>> Then we can use one of the following in Java to call the method
>>> from fence.py
>>> 1) jython
>>> 2) org.python.util.PythonInterpreter
>>>
>>> See
>>> http://stackoverflow.com/questions/8898765/calling-python-in-java
>>
>> if this is JNI, i think it won't fly for engine.
>> JNA may be viable.
>> or just shell launch
>
>
> Can you elaborate here on JNI vs JNA? (besides of course the risks of invoking JNI code from JEE code)?
> Am I missing something else here?

you are not missing, it's about JNI from JEE

>
>
>
>>
>>
>>>
>>> danken, what do you think ?
>>>
>>>>
>>>>>
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>
>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>




From iheim at redhat.com  Sun Nov 11 12:37:34 2012
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 11 Nov 2012 14:37:34 +0200
Subject: [Engine-devel] [Design for 3.2 RFE] Adding support for external
 events
In-Reply-To: <996319562.9059890.1352636431719.JavaMail.root@redhat.com>
References: <996319562.9059890.1352636431719.JavaMail.root@redhat.com>
Message-ID: <509F9C0E.5080805@redhat.com>

On 11/11/2012 02:20 PM, Eli Mesika wrote:
>
>
> ----- Original Message -----
>> From: "Itamar Heim" <iheim at redhat.com>
>> To: "Eli Mesika" <emesika at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>, "Einav Cohen" <ecohen at redhat.com>, "Michael Pasternak"
>> <mpastern at redhat.com>
>> Sent: Sunday, November 11, 2012 9:10:32 AM
>> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Adding support for external events
>>
>> On 11/10/2012 11:40 PM, Eli Mesika wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Itamar Heim" <iheim at redhat.com>
>>>> To: "Eli Mesika" <emesika at redhat.com>
>>>> Cc: "engine-devel" <engine-devel at ovirt.org>, "Einav Cohen"
>>>> <ecohen at redhat.com>, "Michael Pasternak"
>>>> <mpastern at redhat.com>
>>>> Sent: Friday, November 9, 2012 10:55:58 AM
>>>> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Adding support
>>>> for external events
>>>>
>>>> On 11/08/2012 05:17 PM, Eli Mesika wrote:
>>>>> Hi
>>>>>
>>>>> Please review , any comments are welcomed (please note that API
>>>>> section is still in TBD)
>>>>>
>>>>> RFE :https://bugzilla.redhat.com/show_bug.cgi?id=873223
>>>>> Requirements : http://wiki.ovirt.org/wiki/Features/ExternalEvents
>>>>
>>>>> Events are classified as NORMAL , WARNING or ERROR and UI will
>>>>> display different icon according to that.
>>>> any reason to not allow external ALERTs?
>>>
>>> Currently we are using ALERTS only for PM events, do we have to
>>> allow displaying external Alerts in the Alerts TAB as well???
>>
>> not a must, just asking.
>> if an external system wants to inject an event the temperature of a
>> host
>> is critical, its sounds more like an 'alert' to me than 'error'.
> OK,make sense , I will add it to the design
>>
>>>
>>>>
>>>>> Detailed Design
>>>>> :http://wiki.ovirt.org/wiki/Features/Design/DetailedExternalEvents
>>>>
>>>>> Adding is_external boolean field to audit_log with a default
>>>>> value
>>>>> of false
>>>>
>>>> hmmm, i'm not sure it makes sense to inject any event, just
>>>> flagging
>>>> it
>>>> as external.
>>>> why not just add a new AuditLogType of 'External' (i.e., just
>>>> another
>>>> event id?
>>>> it is easy enough to search for it, etc.
>>>
>>> We are adding not one AuditLogType rather , it will be 3 or 4
>>> (depends on we support also Alerts)
>>
>> can't we separate the severity from the event id?
>> why are the two tightly coupled?
>
> No we can't currently , we are assigning each AuditLogType a certain severity, so , I will have to define here 4 for NORMAL , WARNING , ERROR and ALERT
>
>>
>>> The additional is_external is defaulted to false , so , existing
>>> code is not influenced
>>> I think that in the search it will be simpler to refer to
>>> is_external rather to the 3 or 4 specific types
>>> Also , cleanup of old external events should use this column
>>
>> why should cleanup be different for internal and external events?
>
> I think that since those are external events ,it may clean up on a different period and forced by the regular application event clean-up value
>
>>
>>>
>>>
>>>>
>>>>> New command is exposed currently only to SuperUser
>>>>
>>>> I assume you mean there is a new permission, which by default is
>>>> added
>>>> only to superuser role, and admin can add it to other custom
>>>> roles?
>>>> I also assume this is only relevant to admin users, not to user
>>>> roles?
>>>
>>> Yes
>>>
>>>>
>>>> other questions:
>>>> 1. worth detailing all fields of the event which could be passed
>>>> to
>>>> this.
>>>
>>> Currently only the severity and the message text as stated in the
>>> doc.
>>
>> I don't think this is good enough. idea is to be able to inject
>> events
>> as they relate to entities (host,storage,vm,etc.)
>>
>>>
>>>> 2. can an admin add events to entities they don't have permissions
>>>> on
>>>> (I'm guessing yes, since admins aren't filtered from seeing all
>>>> entities, so implicitly, they have permission to all entities)
>>>> otherwise (if intent is to limit permisisons), an event is an
>>>> action
>>>> on
>>>> multiple entities, so for any field which is passed for the event
>>>> (vm_id, (vds)host_id, etc.), you'd need to check admin has
>>>> 'AddExternalEvent' permission on.
>>>>
>>>> the main reason i think doing permissions may hold merit is it
>>>> will
>>>> allow to give this permission by default in more roles, rather
>>>> than
>>>> only
>>>> for superuser, which may make it more viable for UI plugins that
>>>> would
>>>> try to leverage this.
>>>
>>>
>>> I am missing here something, it should be an external event, i.e.
>>> additional command invoked by any plug-in
>>> What is the relation to current events ?
>>
>> to current entities, not current events.
>> since the external events are about entities...
>
> How entities are passed to the engine?
> Do we have a full use-case for that ?

an audit log event today can specify multiple entities (well, one of 
each type) it is relevant to.
why wouldn't an external event be able to?

use case?
external host monitoring system to inject an event that a host fan has 
malfunctioned.
external antivirus appliance scan to inject an event a vm has a virus.
etc.

there are two questions here:
1. API modeling wrt which action is "adding an event" (PUT on event
    collection, or POST for an action). if allowing entities, than
    probably entity is assumed from the action happening on the entity
    events collection.

2. permission check
- inject with single entity - requires permission for this action on
   the relevant entity). this permission could probably part of regular
   roles?
- inject with multiple entities - need to check the permission for each
   entity
- inject with no entity - requires system level permission to inject.
   this by default would only be in super user role.

btw - all are the exact same single permission.


>
>>
>>>
>>>>
>>>> 3. REST API modeling for adding an event (is that a PUT on the
>>>> event
>>>> collection, a POST)?
>>>> can it be done only on root events collection, or on events of
>>>> entities
>>>> as well (taking the entity id from url, rather than as a
>>>> parameter),
>>>> etc.
>>>>
>>>
>>> Again, the only info I have from the requirement is to support an
>>> additional command.
>>> The command invoker is responsible for the event text
>>
>> my question was about the REST modeling of this new command
>> (especially
>> as it is relevant only to the REST API, not to the UI).
>> not sure what you mean by 'event text' here.
>>
>>> It seems that you are talking about invoking our events from
>>> external plug-ins as well
>>
>> well, anything external. in any case they would be using the REST API
>> for this.
>>




From danken at redhat.com  Sun Nov 11 12:47:25 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Sun, 11 Nov 2012 14:47:25 +0200
Subject: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection
 algorithm for Power Management operations
In-Reply-To: <509F8FB2.9050601@redhat.com>
References: <509CD4BD.4010606@redhat.com>
	<1357032386.8570374.1352455565925.JavaMail.root@redhat.com>
	<20121111112759.GQ28849@redhat.com> <509F8FB2.9050601@redhat.com>
Message-ID: <20121111124725.GU28849@redhat.com>

On Sun, Nov 11, 2012 at 01:44:50PM +0200, Itamar Heim wrote:
> On 11/11/2012 01:27 PM, Dan Kenigsberg wrote:
> >On Fri, Nov 09, 2012 at 05:06:05AM -0500, Eli Mesika wrote:
> >>
> >>
> >>----- Original Message -----
> >>>From: "Itamar Heim" <iheim at redhat.com>
> >>>To: "Eli Mesika" <emesika at redhat.com>
> >>>Cc: "engine-devel" <engine-devel at ovirt.org>, "Michael Pasternak" <mpastern at redhat.com>, "Simon Grinberg"
> >>><sgrinber at redhat.com>, "Dan Kenigsberg" <danken at redhat.com>
> >>>Sent: Friday, November 9, 2012 12:02:37 PM
> >>>Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
> >>>
> >>>On 11/09/2012 10:52 AM, Eli Mesika wrote:
> >>>
> >>>>>>
> >>>>>>  > FenceWrapper
> >>>>>>
> >>>>>>i understand danken suggested going this way, rather than than
> >>>>>>another
> >>>>>>instance of vdsm.
> >>>>>>is vdsm only calling these scripts today and all logic is in
> >>>>>>engine,
> >>>>>>or
> >>>>>>does vdsm has any logic in wrapping these scripts (not a blocker
> >>>>>>to
> >>>>>>doing FenceWrapper, just worth extracting that logic from vdsm to
> >>>>>>such a
> >>>>>>script, then using it in both. i hope answer is 'no logic'...)
> >>>>vdsm has some logic that maps between the call passed to it from
> >>>>engine and the actual parameters generated for the script.
> >>>>AFAIK, this logic only "builds" the correct arguments for the
> >>>>command according to the agent type
> >>>>
> >>>
> >>>can we extract it to an external wrapper?
> >>>I'd hate to fix bugs/changes twice for this.
> >>
> >>I'll check it with danken on SUN
> >
> >Saggi has had a nascent attempt to factor the little logic we have out
> >http://gerrit.ovirt.org/#/c/7190/7/vdsm/API.py
> >AFAIR there's nothing there beyond:
> >- log everything but passwords,
> >- build the input stream,
> >- run the script
> >- convert its return code
> >and there's also killing dormant scripts on vdsm exist (which I find not
> >important at all).
> 
> if the wrapping isn't doing anything but calling the scripts, then
> doing it again from java isn't an issue.
> it's only an issue if there is any business logic in the wrapping.

I believe there's no issue. The only so-called-reason for this verb
existing in Vdsm is the pre-historical platform of oVirt-Engine's
predecessor, which did not support[*] running the fence-agent scripts.
That's why I'm advocating to cut the middle man (even though he is I).

[*] "no support" meaning: "possible, but no one's gonna help you if
there's trouble."



From yzaslavs at redhat.com  Sun Nov 11 13:09:05 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Sun, 11 Nov 2012 08:09:05 -0500 (EST)
Subject: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection
 algorithm for Power Management operations
In-Reply-To: <509F9A48.7010608@redhat.com>
Message-ID: <1351676922.30166896.1352639345389.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "Eli Mesika" <emesika at redhat.com>
> Sent: Sunday, November 11, 2012 2:30:00 PM
> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
> 
> On 11/11/2012 02:27 PM, Yair Zaslavsky wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Itamar Heim" <iheim at redhat.com>
> >> To: "Eli Mesika" <emesika at redhat.com>
> >> Cc: "engine-devel" <engine-devel at ovirt.org>
> >> Sent: Sunday, November 11, 2012 1:45:53 PM
> >> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy
> >> selection algorithm for Power Management operations
> >>
> >> On 11/11/2012 01:18 PM, Eli Mesika wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Eli Mesika" <emesika at redhat.com>
> >>>> To: "Itamar Heim" <iheim at redhat.com>
> >>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> >>>> Sent: Friday, November 9, 2012 12:06:05 PM
> >>>> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy
> >>>> selection algorithm for Power Management operations
> >>>>
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Itamar Heim" <iheim at redhat.com>
> >>>>> To: "Eli Mesika" <emesika at redhat.com>
> >>>>> Cc: "engine-devel" <engine-devel at ovirt.org>, "Michael
> >>>>> Pasternak"
> >>>>> <mpastern at redhat.com>, "Simon Grinberg"
> >>>>> <sgrinber at redhat.com>, "Dan Kenigsberg" <danken at redhat.com>
> >>>>> Sent: Friday, November 9, 2012 12:02:37 PM
> >>>>> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving
> >>>>> proxy
> >>>>> selection algorithm for Power Management operations
> >>>>>
> >>>>> On 11/09/2012 10:52 AM, Eli Mesika wrote:
> >>>>>
> >>>>>>>>
> >>>>>>>>    > FenceWrapper
> >>>>>>>>
> >>>>>>>> i understand danken suggested going this way, rather than
> >>>>>>>> than
> >>>>>>>> another
> >>>>>>>> instance of vdsm.
> >>>>>>>> is vdsm only calling these scripts today and all logic is in
> >>>>>>>> engine,
> >>>>>>>> or
> >>>>>>>> does vdsm has any logic in wrapping these scripts (not a
> >>>>>>>> blocker
> >>>>>>>> to
> >>>>>>>> doing FenceWrapper, just worth extracting that logic from
> >>>>>>>> vdsm
> >>>>>>>> to
> >>>>>>>> such a
> >>>>>>>> script, then using it in both. i hope answer is 'no
> >>>>>>>> logic'...)
> >>>>>> vdsm has some logic that maps between the call passed to it
> >>>>>> from
> >>>>>> engine and the actual parameters generated for the script.
> >>>>>> AFAIK, this logic only "builds" the correct arguments for the
> >>>>>> command according to the agent type
> >>>>>>
> >>>>>
> >>>>> can we extract it to an external wrapper?
> >>>>> I'd hate to fix bugs/changes twice for this.
> >>>>
> >>>> I'll check it with danken on SUN
> >>>
> >>> Well, looked at it a bit , the VDSM code is in fenceNote function
> >>> in API.py
> >>> What I think is that we can exclude the fenceNote implementation
> >>> to
> >>> a separate fence.py file and call it from the API.py
> >>> Then we can use one of the following in Java to call the method
> >>> from fence.py
> >>> 1) jython
> >>> 2) org.python.util.PythonInterpreter
> >>>
> >>> See
> >>> http://stackoverflow.com/questions/8898765/calling-python-in-java
> >>
> >> if this is JNI, i think it won't fly for engine.
> >> JNA may be viable.
> >> or just shell launch
> >
> >
> > Can you elaborate here on JNI vs JNA? (besides of course the risks
> > of invoking JNI code from JEE code)?
> > Am I missing something else here?
> 
> you are not missing, it's about JNI from JEE
> 
Hmm... now that I remember our previous JNA adventure , and after looking at some resources, I'm staring to think whether JNA code is really safer (not talking about the ease of development here).
I started digging at JNA code -and JNA is actually JNI (i.e - uses native methods) based framework (infra to ease native code development) -
So one can say it relies on the fact this is open source and used by various comments, but at the end - this is still JNI behind the scene (see jna/src/com/sun/jna/Native.java)
Bugs still can occur at JNA code (maybe less, as it's supposed to be "cleaner" code) - but if there are bugs, JVM crashes.

> >
> >
> >
> >>
> >>
> >>>
> >>> danken, what do you think ?
> >>>
> >>>>
> >>>>>
> >>>> _______________________________________________
> >>>> Engine-devel mailing list
> >>>> Engine-devel at ovirt.org
> >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>
> >>
> >>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> 
> 
> 


From emesika at redhat.com  Sun Nov 11 14:04:00 2012
From: emesika at redhat.com (Eli Mesika)
Date: Sun, 11 Nov 2012 09:04:00 -0500 (EST)
Subject: [Engine-devel] [Design for 3.2 RFE] Adding support for external
 events
In-Reply-To: <509F9C0E.5080805@redhat.com>
Message-ID: <2126195170.9070975.1352642640660.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "Einav Cohen" <ecohen at redhat.com>, "Michael Pasternak"
> <mpastern at redhat.com>
> Sent: Sunday, November 11, 2012 2:37:34 PM
> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Adding support for external events
> 
> On 11/11/2012 02:20 PM, Eli Mesika wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Itamar Heim" <iheim at redhat.com>
> >> To: "Eli Mesika" <emesika at redhat.com>
> >> Cc: "engine-devel" <engine-devel at ovirt.org>, "Einav Cohen"
> >> <ecohen at redhat.com>, "Michael Pasternak"
> >> <mpastern at redhat.com>
> >> Sent: Sunday, November 11, 2012 9:10:32 AM
> >> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Adding support
> >> for external events
> >>
> >> On 11/10/2012 11:40 PM, Eli Mesika wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Itamar Heim" <iheim at redhat.com>
> >>>> To: "Eli Mesika" <emesika at redhat.com>
> >>>> Cc: "engine-devel" <engine-devel at ovirt.org>, "Einav Cohen"
> >>>> <ecohen at redhat.com>, "Michael Pasternak"
> >>>> <mpastern at redhat.com>
> >>>> Sent: Friday, November 9, 2012 10:55:58 AM
> >>>> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Adding support
> >>>> for external events
> >>>>
> >>>> On 11/08/2012 05:17 PM, Eli Mesika wrote:
> >>>>> Hi
> >>>>>
> >>>>> Please review , any comments are welcomed (please note that API
> >>>>> section is still in TBD)
> >>>>>
> >>>>> RFE :https://bugzilla.redhat.com/show_bug.cgi?id=873223
> >>>>> Requirements :
> >>>>> http://wiki.ovirt.org/wiki/Features/ExternalEvents
> >>>>
> >>>>> Events are classified as NORMAL , WARNING or ERROR and UI will
> >>>>> display different icon according to that.
> >>>> any reason to not allow external ALERTs?
> >>>
> >>> Currently we are using ALERTS only for PM events, do we have to
> >>> allow displaying external Alerts in the Alerts TAB as well???
> >>
> >> not a must, just asking.
> >> if an external system wants to inject an event the temperature of
> >> a
> >> host
> >> is critical, its sounds more like an 'alert' to me than 'error'.
> > OK,make sense , I will add it to the design
> >>
> >>>
> >>>>
> >>>>> Detailed Design
> >>>>> :http://wiki.ovirt.org/wiki/Features/Design/DetailedExternalEvents
> >>>>
> >>>>> Adding is_external boolean field to audit_log with a default
> >>>>> value
> >>>>> of false
> >>>>
> >>>> hmmm, i'm not sure it makes sense to inject any event, just
> >>>> flagging
> >>>> it
> >>>> as external.
> >>>> why not just add a new AuditLogType of 'External' (i.e., just
> >>>> another
> >>>> event id?
> >>>> it is easy enough to search for it, etc.
> >>>
> >>> We are adding not one AuditLogType rather , it will be 3 or 4
> >>> (depends on we support also Alerts)
> >>
> >> can't we separate the severity from the event id?
> >> why are the two tightly coupled?
> >
> > No we can't currently , we are assigning each AuditLogType a
> > certain severity, so , I will have to define here 4 for NORMAL ,
> > WARNING , ERROR and ALERT
> >
> >>
> >>> The additional is_external is defaulted to false , so , existing
> >>> code is not influenced
> >>> I think that in the search it will be simpler to refer to
> >>> is_external rather to the 3 or 4 specific types
> >>> Also , cleanup of old external events should use this column
> >>
> >> why should cleanup be different for internal and external events?
> >
> > I think that since those are external events ,it may clean up on a
> > different period and forced by the regular application event
> > clean-up value
> >
> >>
> >>>
> >>>
> >>>>
> >>>>> New command is exposed currently only to SuperUser
> >>>>
> >>>> I assume you mean there is a new permission, which by default is
> >>>> added
> >>>> only to superuser role, and admin can add it to other custom
> >>>> roles?
> >>>> I also assume this is only relevant to admin users, not to user
> >>>> roles?
> >>>
> >>> Yes
> >>>
> >>>>
> >>>> other questions:
> >>>> 1. worth detailing all fields of the event which could be passed
> >>>> to
> >>>> this.
> >>>
> >>> Currently only the severity and the message text as stated in the
> >>> doc.
> >>
> >> I don't think this is good enough. idea is to be able to inject
> >> events
> >> as they relate to entities (host,storage,vm,etc.)
> >>
> >>>
> >>>> 2. can an admin add events to entities they don't have
> >>>> permissions
> >>>> on
> >>>> (I'm guessing yes, since admins aren't filtered from seeing all
> >>>> entities, so implicitly, they have permission to all entities)
> >>>> otherwise (if intent is to limit permisisons), an event is an
> >>>> action
> >>>> on
> >>>> multiple entities, so for any field which is passed for the
> >>>> event
> >>>> (vm_id, (vds)host_id, etc.), you'd need to check admin has
> >>>> 'AddExternalEvent' permission on.
> >>>>
> >>>> the main reason i think doing permissions may hold merit is it
> >>>> will
> >>>> allow to give this permission by default in more roles, rather
> >>>> than
> >>>> only
> >>>> for superuser, which may make it more viable for UI plugins that
> >>>> would
> >>>> try to leverage this.
> >>>
> >>>
> >>> I am missing here something, it should be an external event, i.e.
> >>> additional command invoked by any plug-in
> >>> What is the relation to current events ?
> >>
> >> to current entities, not current events.
> >> since the external events are about entities...
> >
> > How entities are passed to the engine?
> > Do we have a full use-case for that ?
> 
> an audit log event today can specify multiple entities (well, one of
> each type) it is relevant to.
> why wouldn't an external event be able to?
> 
> use case?
> external host monitoring system to inject an event that a host fan
> has
> malfunctioned.
> external antivirus appliance scan to inject an event a vm has a
> virus.
> etc.

OK, got it now, thanks

> 
> there are two questions here:
> 1. API modeling wrt which action is "adding an event" (PUT on event
>     collection, or POST for an action). if allowing entities, than
>     probably entity is assumed from the action happening on the
>     entity
>     events collection.

I think it should be POST (new action/command)
> 
> 2. permission check
> - inject with single entity - requires permission for this action on
>    the relevant entity). this permission could probably part of
>    regular
>    roles?
> - inject with multiple entities - need to check the permission for
> each
>    entity
> - inject with no entity - requires system level permission to inject.
>    this by default would only be in super user role.
> 
> btw - all are the exact same single permission.

Thanks

> 
> 
> >
> >>
> >>>
> >>>>
> >>>> 3. REST API modeling for adding an event (is that a PUT on the
> >>>> event
> >>>> collection, a POST)?
> >>>> can it be done only on root events collection, or on events of
> >>>> entities
> >>>> as well (taking the entity id from url, rather than as a
> >>>> parameter),
> >>>> etc.
> >>>>
> >>>
> >>> Again, the only info I have from the requirement is to support an
> >>> additional command.
> >>> The command invoker is responsible for the event text
> >>
> >> my question was about the REST modeling of this new command
> >> (especially
> >> as it is relevant only to the REST API, not to the UI).
> >> not sure what you mean by 'event text' here.
> >>
> >>> It seems that you are talking about invoking our events from
> >>> external plug-ins as well
> >>
> >> well, anything external. in any case they would be using the REST
> >> API
> >> for this.
> >>
> 
> 
> 


From mkenneth at redhat.com  Sun Nov 11 15:12:23 2012
From: mkenneth at redhat.com (Miki Kenneth)
Date: Sun, 11 Nov 2012 17:12:23 +0200
Subject: [Engine-devel] [Design for 3.2 RFE] Adding support for external
 events
In-Reply-To: <509F5C7B.2030801@redhat.com>
References: <1368899630.8953606.1352583629355.JavaMail.root@redhat.com>
	<509F58D1.6070300@redhat.com> <509F5C7B.2030801@redhat.com>
Message-ID: <509FC057.7030404@redhat.com>

On 11/11/2012 10:06 AM, Itamar Heim wrote:
> On 11/11/2012 09:50 AM, Yaniv Kaul wrote:
>> On 11/10/2012 11:40 PM, Eli Mesika wrote:
>>>
>>> ----- Original Message -----
>>>> From: "Itamar Heim" <iheim at redhat.com>
>>>> To: "Eli Mesika" <emesika at redhat.com>
>>>> Cc: "engine-devel" <engine-devel at ovirt.org>, "Einav Cohen"
>>>> <ecohen at redhat.com>, "Michael Pasternak"
>>>> <mpastern at redhat.com>
>>>> Sent: Friday, November 9, 2012 10:55:58 AM
>>>> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Adding support for
>>>> external events
>>>>
>>>> On 11/08/2012 05:17 PM, Eli Mesika wrote:
>>>>> Hi
>>>>>
>>>>> Please review , any comments are welcomed (please note that API
>>>>> section is still in TBD)
>>>>>
>>>>> RFE :https://bugzilla.redhat.com/show_bug.cgi?id=873223
>>>>> Requirements : http://wiki.ovirt.org/wiki/Features/ExternalEvents
>>>>> Events are classified as NORMAL , WARNING or ERROR and UI will
>>>>> display different icon according to that.
>>>> any reason to not allow external ALERTs?
>>> Currently we are using ALERTS only for PM events, do we have to allow
>>> displaying external Alerts in the Alerts TAB as well???
>>>
>>>>> Detailed Design
>>>>> :http://wiki.ovirt.org/wiki/Features/Design/DetailedExternalEvents
>>>>> Adding is_external boolean field to audit_log with a default value
>>>>> of false
>>>> hmmm, i'm not sure it makes sense to inject any event, just flagging
>>>> it
>>>> as external.
>>>> why not just add a new AuditLogType of 'External' (i.e., just another
>>>> event id?
>>>> it is easy enough to search for it, etc.
>>> We are adding not one AuditLogType rather , it will be 3 or 4 (depends
>>> on we support also Alerts)
>>> The additional is_external is defaulted to false , so , existing code
>>> is not influenced
>>> I think that in the search it will be simpler to refer to is_external
>>> rather to the 3 or 4 specific types
>>> Also , cleanup of old external events should use this column
regarding the clean-up events/alerts, is that possible while we are on 
the subject?
It would be nice to indicate that alert was viewed and acknowledged and 
we can filter it out of the tab.
>>>
>>>
>>>>> New command is exposed currently only to SuperUser
>>>> I assume you mean there is a new permission, which by default is
>>>> added
>>>> only to superuser role, and admin can add it to other custom roles?
>>>> I also assume this is only relevant to admin users, not to user
>>>> roles?
>>> Yes
>>
>> What's the protection against LDAP injection, SQL injection, Javascript
>> injection ... ?
>> How do we sanitize the input of the event?
>>
>> Regardless, what about localization? Can the plugin know in which
>> language it should inject the event?
>
> audit log is not localized at this point.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From simon at redhat.com  Sun Nov 11 15:45:41 2012
From: simon at redhat.com (Simon Grinberg)
Date: Sun, 11 Nov 2012 10:45:41 -0500 (EST)
Subject: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection
 algorithm for Power Management operations
In-Reply-To: <1008746778.9047332.1352632733372.JavaMail.root@redhat.com>
Message-ID: <252984368.8434351.1352648741682.JavaMail.root@redhat.com>

Trying to answer open questions + provide feedback

-1. We need to change the term Power Management, we only do fencing here so why not call it by name, it may confuse with real power modes management that we'll probably do via VDSM and not via OOB management. Especially as some of the devices external to the host can only do fencing anyhow. 

I'll change the requirement page, to reflect that + I'll split the proxy from dual card support, as the design should. 


-2. Default value should be 'cluster, dc, engine' not the other way around. Actually most users I've been talking to will just use 'cluster' since this matches the classic cluster definition where host could only be fenced by another host in the cluster. 

I'll change requirements to reflect that. 

-3. The directly selected hosts comes to accommodate two use cases:
   -3.1- Switch failure - if the fence network for hosts in a DC/Cluster have to split between two switches. Then you will prefer to use hosts that are for sure on the other switch
   -3.2- Legacy clusters merged into larger clusters due to a move to oVirt then the infrastructural may still fit to the legacy connectivity - lot's of firewalls rules or direct connections that limit access to fencing devices to specific hosts. 
   -3.3- Clustered applications within the VMs, you only want your pears to be allowed to fence you. This is limited for VMs running on specific host group (affinity management that we don't have yet, but we can lock VMs to specific hosts).

   Note that the above was not meant to accommodate any random server, just hosts in the setup, hosts that already run VDSM.
   Meaning that maybe instead of the FQDN we can just use hostname - so the UUID will be registered in the tables
   I don't why it's so complex, if a host provided is removed from the system you either get a canDoAction to remove it from the configuration as well (or a warning that this will remove the host from the fencing configuration). Your only risk if all of them are removed, then you need to set the exclamation mark again (power management is not configured for this host)

- 4. Assumption that every host will have all elements is wrong. In the requirement page I've gave combinations where it isn't. 
   Like said there are use cases where you don't want to diverge from hosts in the same cluster. Reason is that if the last host in the cluster (assuming clustered VMs running on this host) you may actually prefer it won't be fenced. Similar to -3.3-

- 5. Thinking about it more, Though the chain is more generic and flexible, I would like to return to my original suggestion, of having just primary and secondary proxy:
     Primary Proxy 1 => Drop down -> Any cluster host / Any DC host / RHEV Manager / Named host out of the list of all the hosts 
     Secondary Proxy 2 => Drop down -> Any cluster host / Any DC host / RHEV Manager / Named host out of the list of all the hosts
     I think is simpler as far as a user is concerned and it's simpler for us to implement two fields single value in each. And I don't believe we really need more, even in the simple case of cluster only hosts, for clusters larger then 4 hosts by the time you get to the secondary it may be too late. Secondary is more critical for the 'Named host' option or small clusters. 

I'll look at it some more later today, but sending now to get as much feedback as possible.

Regards,
Simon
 

----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: "Dan Kenigsberg" <danken at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, November 11, 2012 1:18:53 PM
> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
> 
> 
> 
> ----- Original Message -----
> > From: "Eli Mesika" <emesika at redhat.com>
> > To: "Itamar Heim" <iheim at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Friday, November 9, 2012 12:06:05 PM
> > Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy
> > selection algorithm for Power Management operations
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Itamar Heim" <iheim at redhat.com>
> > > To: "Eli Mesika" <emesika at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>, "Michael Pasternak"
> > > <mpastern at redhat.com>, "Simon Grinberg"
> > > <sgrinber at redhat.com>, "Dan Kenigsberg" <danken at redhat.com>
> > > Sent: Friday, November 9, 2012 12:02:37 PM
> > > Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy
> > > selection algorithm for Power Management operations
> > > 
> > > On 11/09/2012 10:52 AM, Eli Mesika wrote:
> > > 
> > > >> >
> > > >> >  > FenceWrapper
> > > >> >
> > > >> >i understand danken suggested going this way, rather than
> > > >> >than
> > > >> >another
> > > >> >instance of vdsm.
> > > >> >is vdsm only calling these scripts today and all logic is in
> > > >> >engine,
> > > >> >or
> > > >> >does vdsm has any logic in wrapping these scripts (not a
> > > >> >blocker
> > > >> >to
> > > >> >doing FenceWrapper, just worth extracting that logic from
> > > >> >vdsm
> > > >> >to
> > > >> >such a
> > > >> >script, then using it in both. i hope answer is 'no
> > > >> >logic'...)
> > > > vdsm has some logic that maps between the call passed to it
> > > > from
> > > > engine and the actual parameters generated for the script.
> > > > AFAIK, this logic only "builds" the correct arguments for the
> > > > command according to the agent type
> > > >
> > > 
> > > can we extract it to an external wrapper?
> > > I'd hate to fix bugs/changes twice for this.
> > 
> > I'll check it with danken on SUN
> 
> Well, looked at it a bit , the VDSM code is in fenceNote function in
> API.py
> What I think is that we can exclude the fenceNote implementation to a
> separate fence.py file and call it from the API.py
> Then we can use one of the following in Java to call the method from
> fence.py
> 1) jython
> 2) org.python.util.PythonInterpreter
> 
> See http://stackoverflow.com/questions/8898765/calling-python-in-java
> 
> danken, what do you think ?
> 
> > 
> > > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From emesika at redhat.com  Sun Nov 11 16:18:57 2012
From: emesika at redhat.com (Eli Mesika)
Date: Sun, 11 Nov 2012 11:18:57 -0500 (EST)
Subject: [Engine-devel] [Design for 3.2 RFE] Adding support for external
 events
In-Reply-To: <509FC057.7030404@redhat.com>
Message-ID: <757274600.9082254.1352650737935.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Miki Kenneth" <mkenneth at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, November 11, 2012 5:12:23 PM
> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Adding support for external events
> 
> On 11/11/2012 10:06 AM, Itamar Heim wrote:
> > On 11/11/2012 09:50 AM, Yaniv Kaul wrote:
> >> On 11/10/2012 11:40 PM, Eli Mesika wrote:
> >>>
> >>> ----- Original Message -----
> >>>> From: "Itamar Heim" <iheim at redhat.com>
> >>>> To: "Eli Mesika" <emesika at redhat.com>
> >>>> Cc: "engine-devel" <engine-devel at ovirt.org>, "Einav Cohen"
> >>>> <ecohen at redhat.com>, "Michael Pasternak"
> >>>> <mpastern at redhat.com>
> >>>> Sent: Friday, November 9, 2012 10:55:58 AM
> >>>> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Adding support
> >>>> for
> >>>> external events
> >>>>
> >>>> On 11/08/2012 05:17 PM, Eli Mesika wrote:
> >>>>> Hi
> >>>>>
> >>>>> Please review , any comments are welcomed (please note that API
> >>>>> section is still in TBD)
> >>>>>
> >>>>> RFE :https://bugzilla.redhat.com/show_bug.cgi?id=873223
> >>>>> Requirements :
> >>>>> http://wiki.ovirt.org/wiki/Features/ExternalEvents
> >>>>> Events are classified as NORMAL , WARNING or ERROR and UI will
> >>>>> display different icon according to that.
> >>>> any reason to not allow external ALERTs?
> >>> Currently we are using ALERTS only for PM events, do we have to
> >>> allow
> >>> displaying external Alerts in the Alerts TAB as well???
> >>>
> >>>>> Detailed Design
> >>>>> :http://wiki.ovirt.org/wiki/Features/Design/DetailedExternalEvents
> >>>>> Adding is_external boolean field to audit_log with a default
> >>>>> value
> >>>>> of false
> >>>> hmmm, i'm not sure it makes sense to inject any event, just
> >>>> flagging
> >>>> it
> >>>> as external.
> >>>> why not just add a new AuditLogType of 'External' (i.e., just
> >>>> another
> >>>> event id?
> >>>> it is easy enough to search for it, etc.
> >>> We are adding not one AuditLogType rather , it will be 3 or 4
> >>> (depends
> >>> on we support also Alerts)
> >>> The additional is_external is defaulted to false , so , existing
> >>> code
> >>> is not influenced
> >>> I think that in the search it will be simpler to refer to
> >>> is_external
> >>> rather to the 3 or 4 specific types
> >>> Also , cleanup of old external events should use this column
> regarding the clean-up events/alerts, is that possible while we are
> on
> the subject?
> It would be nice to indicate that alert was viewed and acknowledged
> and
> we can filter it out of the tab.

I think I should Support ALERT_ON and ALERT_OFF for that ...
So, ALERT_ON will add that to the tab and ALERT_OFF will remove it 

> >>>
> >>>
> >>>>> New command is exposed currently only to SuperUser
> >>>> I assume you mean there is a new permission, which by default is
> >>>> added
> >>>> only to superuser role, and admin can add it to other custom
> >>>> roles?
> >>>> I also assume this is only relevant to admin users, not to user
> >>>> roles?
> >>> Yes
> >>
> >> What's the protection against LDAP injection, SQL injection,
> >> Javascript
> >> injection ... ?
> >> How do we sanitize the input of the event?
> >>
> >> Regardless, what about localization? Can the plugin know in which
> >> language it should inject the event?
> >
> > audit log is not localized at this point.
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From emesika at redhat.com  Sun Nov 11 16:24:39 2012
From: emesika at redhat.com (Eli Mesika)
Date: Sun, 11 Nov 2012 11:24:39 -0500 (EST)
Subject: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection
 algorithm for Power Management operations
In-Reply-To: <252984368.8434351.1352648741682.JavaMail.root@redhat.com>
Message-ID: <1520195958.9082359.1352651079030.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Simon Grinberg" <simon at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "Dan Kenigsberg" <danken at redhat.com>
> Sent: Sunday, November 11, 2012 5:45:41 PM
> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
> 
> Trying to answer open questions + provide feedback
> 
> -1. We need to change the term Power Management, we only do fencing
> here so why not call it by name, it may confuse with real power
> modes management that we'll probably do via VDSM and not via OOB
> management. Especially as some of the devices external to the host
> can only do fencing anyhow.
> 
> I'll change the requirement page, to reflect that + I'll split the
> proxy from dual card support, as the design should.

This was already done:
http://wiki.ovirt.org/wiki/Features/Design/HostPMProxyPreferences
http://wiki.ovirt.org/wiki/Features/Design/HostPMMultipleAgents


Have to move, will comment on other issues later on, please modify the new slitted wiki pages

> 
> 
> -2. Default value should be 'cluster, dc, engine' not the other way
> around. Actually most users I've been talking to will just use
> 'cluster' since this matches the classic cluster definition where
> host could only be fenced by another host in the cluster.
> 
> I'll change requirements to reflect that.
> 
> -3. The directly selected hosts comes to accommodate two use cases:
>    -3.1- Switch failure - if the fence network for hosts in a
>    DC/Cluster have to split between two switches. Then you will
>    prefer to use hosts that are for sure on the other switch
>    -3.2- Legacy clusters merged into larger clusters due to a move to
>    oVirt then the infrastructural may still fit to the legacy
>    connectivity - lot's of firewalls rules or direct connections
>    that limit access to fencing devices to specific hosts.
>    -3.3- Clustered applications within the VMs, you only want your
>    pears to be allowed to fence you. This is limited for VMs running
>    on specific host group (affinity management that we don't have
>    yet, but we can lock VMs to specific hosts).
> 
>    Note that the above was not meant to accommodate any random
>    server, just hosts in the setup, hosts that already run VDSM.
>    Meaning that maybe instead of the FQDN we can just use hostname -
>    so the UUID will be registered in the tables
>    I don't why it's so complex, if a host provided is removed from
>    the system you either get a canDoAction to remove it from the
>    configuration as well (or a warning that this will remove the
>    host from the fencing configuration). Your only risk if all of
>    them are removed, then you need to set the exclamation mark again
>    (power management is not configured for this host)
> 
> - 4. Assumption that every host will have all elements is wrong. In
> the requirement page I've gave combinations where it isn't.
>    Like said there are use cases where you don't want to diverge from
>    hosts in the same cluster. Reason is that if the last host in the
>    cluster (assuming clustered VMs running on this host) you may
>    actually prefer it won't be fenced. Similar to -3.3-
> 
> - 5. Thinking about it more, Though the chain is more generic and
> flexible, I would like to return to my original suggestion, of
> having just primary and secondary proxy:
>      Primary Proxy 1 => Drop down -> Any cluster host / Any DC host /
>      RHEV Manager / Named host out of the list of all the hosts
>      Secondary Proxy 2 => Drop down -> Any cluster host / Any DC host
>      / RHEV Manager / Named host out of the list of all the hosts
>      I think is simpler as far as a user is concerned and it's
>      simpler for us to implement two fields single value in each.
>      And I don't believe we really need more, even in the simple
>      case of cluster only hosts, for clusters larger then 4 hosts by
>      the time you get to the secondary it may be too late. Secondary
>      is more critical for the 'Named host' option or small clusters.
> 
> I'll look at it some more later today, but sending now to get as much
> feedback as possible.
> 
> Regards,
> Simon
>  
> 
> ----- Original Message -----
> > From: "Eli Mesika" <emesika at redhat.com>
> > To: "Dan Kenigsberg" <danken at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Sunday, November 11, 2012 1:18:53 PM
> > Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy
> > selection algorithm for Power Management operations
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Eli Mesika" <emesika at redhat.com>
> > > To: "Itamar Heim" <iheim at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Friday, November 9, 2012 12:06:05 PM
> > > Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy
> > > selection algorithm for Power Management operations
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Itamar Heim" <iheim at redhat.com>
> > > > To: "Eli Mesika" <emesika at redhat.com>
> > > > Cc: "engine-devel" <engine-devel at ovirt.org>, "Michael
> > > > Pasternak"
> > > > <mpastern at redhat.com>, "Simon Grinberg"
> > > > <sgrinber at redhat.com>, "Dan Kenigsberg" <danken at redhat.com>
> > > > Sent: Friday, November 9, 2012 12:02:37 PM
> > > > Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving
> > > > proxy
> > > > selection algorithm for Power Management operations
> > > > 
> > > > On 11/09/2012 10:52 AM, Eli Mesika wrote:
> > > > 
> > > > >> >
> > > > >> >  > FenceWrapper
> > > > >> >
> > > > >> >i understand danken suggested going this way, rather than
> > > > >> >than
> > > > >> >another
> > > > >> >instance of vdsm.
> > > > >> >is vdsm only calling these scripts today and all logic is
> > > > >> >in
> > > > >> >engine,
> > > > >> >or
> > > > >> >does vdsm has any logic in wrapping these scripts (not a
> > > > >> >blocker
> > > > >> >to
> > > > >> >doing FenceWrapper, just worth extracting that logic from
> > > > >> >vdsm
> > > > >> >to
> > > > >> >such a
> > > > >> >script, then using it in both. i hope answer is 'no
> > > > >> >logic'...)
> > > > > vdsm has some logic that maps between the call passed to it
> > > > > from
> > > > > engine and the actual parameters generated for the script.
> > > > > AFAIK, this logic only "builds" the correct arguments for the
> > > > > command according to the agent type
> > > > >
> > > > 
> > > > can we extract it to an external wrapper?
> > > > I'd hate to fix bugs/changes twice for this.
> > > 
> > > I'll check it with danken on SUN
> > 
> > Well, looked at it a bit , the VDSM code is in fenceNote function
> > in
> > API.py
> > What I think is that we can exclude the fenceNote implementation to
> > a
> > separate fence.py file and call it from the API.py
> > Then we can use one of the following in Java to call the method
> > from
> > fence.py
> > 1) jython
> > 2) org.python.util.PythonInterpreter
> > 
> > See
> > http://stackoverflow.com/questions/8898765/calling-python-in-java
> > 
> > danken, what do you think ?
> > 
> > > 
> > > > 
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 


From iheim at redhat.com  Sun Nov 11 17:04:21 2012
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 11 Nov 2012 19:04:21 +0200
Subject: [Engine-devel] [Design for 3.2 RFE] Adding support for external
 events
In-Reply-To: <757274600.9082254.1352650737935.JavaMail.root@redhat.com>
References: <757274600.9082254.1352650737935.JavaMail.root@redhat.com>
Message-ID: <509FDA95.5040103@redhat.com>

On 11/11/2012 06:18 PM, Eli Mesika wrote:
>
>
> ----- Original Message -----
>> From: "Miki Kenneth" <mkenneth at redhat.com>
>> To: "Itamar Heim" <iheim at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Sunday, November 11, 2012 5:12:23 PM
>> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Adding support for external events
>>
>> On 11/11/2012 10:06 AM, Itamar Heim wrote:
>>> On 11/11/2012 09:50 AM, Yaniv Kaul wrote:
>>>> On 11/10/2012 11:40 PM, Eli Mesika wrote:
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Itamar Heim" <iheim at redhat.com>
>>>>>> To: "Eli Mesika" <emesika at redhat.com>
>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>, "Einav Cohen"
>>>>>> <ecohen at redhat.com>, "Michael Pasternak"
>>>>>> <mpastern at redhat.com>
>>>>>> Sent: Friday, November 9, 2012 10:55:58 AM
>>>>>> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Adding support
>>>>>> for
>>>>>> external events
>>>>>>
>>>>>> On 11/08/2012 05:17 PM, Eli Mesika wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>> Please review , any comments are welcomed (please note that API
>>>>>>> section is still in TBD)
>>>>>>>
>>>>>>> RFE :https://bugzilla.redhat.com/show_bug.cgi?id=873223
>>>>>>> Requirements :
>>>>>>> http://wiki.ovirt.org/wiki/Features/ExternalEvents
>>>>>>> Events are classified as NORMAL , WARNING or ERROR and UI will
>>>>>>> display different icon according to that.
>>>>>> any reason to not allow external ALERTs?
>>>>> Currently we are using ALERTS only for PM events, do we have to
>>>>> allow
>>>>> displaying external Alerts in the Alerts TAB as well???
>>>>>
>>>>>>> Detailed Design
>>>>>>> :http://wiki.ovirt.org/wiki/Features/Design/DetailedExternalEvents
>>>>>>> Adding is_external boolean field to audit_log with a default
>>>>>>> value
>>>>>>> of false
>>>>>> hmmm, i'm not sure it makes sense to inject any event, just
>>>>>> flagging
>>>>>> it
>>>>>> as external.
>>>>>> why not just add a new AuditLogType of 'External' (i.e., just
>>>>>> another
>>>>>> event id?
>>>>>> it is easy enough to search for it, etc.
>>>>> We are adding not one AuditLogType rather , it will be 3 or 4
>>>>> (depends
>>>>> on we support also Alerts)
>>>>> The additional is_external is defaulted to false , so , existing
>>>>> code
>>>>> is not influenced
>>>>> I think that in the search it will be simpler to refer to
>>>>> is_external
>>>>> rather to the 3 or 4 specific types
>>>>> Also , cleanup of old external events should use this column
>> regarding the clean-up events/alerts, is that possible while we are
>> on
>> the subject?
>> It would be nice to indicate that alert was viewed and acknowledged
>> and
>> we can filter it out of the tab.
>
> I think I should Support ALERT_ON and ALERT_OFF for that ...
> So, ALERT_ON will add that to the tab and ALERT_OFF will remove it

I think the more important thing (and generic to events as well) is for 
someone to flag the event/alert as owned/being handled by themselves, 
commenting on what they did/are doing, etc.
not sure why alert should have an off mode, since iirc, alerts are 
automatically cleaned when their root issue is solved.
(if anything, you would want to have an 'ignore alert' action by an 
admin (for X days/forever)


>
>>>>>
>>>>>
>>>>>>> New command is exposed currently only to SuperUser
>>>>>> I assume you mean there is a new permission, which by default is
>>>>>> added
>>>>>> only to superuser role, and admin can add it to other custom
>>>>>> roles?
>>>>>> I also assume this is only relevant to admin users, not to user
>>>>>> roles?
>>>>> Yes
>>>>
>>>> What's the protection against LDAP injection, SQL injection,
>>>> Javascript
>>>> injection ... ?
>>>> How do we sanitize the input of the event?
>>>>
>>>> Regardless, what about localization? Can the plugin know in which
>>>> language it should inject the event?
>>>
>>> audit log is not localized at this point.
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>




From simon at redhat.com  Sun Nov 11 18:31:11 2012
From: simon at redhat.com (Simon Grinberg)
Date: Sun, 11 Nov 2012 13:31:11 -0500 (EST)
Subject: [Engine-devel] SPICE IP override
In-Reply-To: <509F73BE.4020301@redhat.com>
Message-ID: <327082939.8452474.1352658671453.JavaMail.root@redhat.com>


----- Original Message ----- 

> From: "Yaniv Kaul" <ykaul at redhat.com>
> To: "Simon Grinberg" <simon at redhat.com>, "Michal Skrivanek"
> <michal.skrivanek at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Sunday, November 11, 2012 11:45:34 AM
> Subject: Re: [Engine-devel] SPICE IP override

> On 11/07/2012 10:52 AM, Simon Grinberg wrote:

> > ----- Original Message -----
> 
> > > From: "Michal Skrivanek" <michal.skrivanek at redhat.com> To:
> > > engine-devel at ovirt.org Sent: Tuesday, November 6, 2012 10:39:58
> > > PM
> > 
> 
> > > Subject: [Engine-devel] SPICE IP override
> > 
> 

> > > Hi all,
> > 
> 
> > > On behalf of Tomas - please check out the proposal for enhancing
> > > our
> > 
> 
> > > SPICE integration to allow to return a custom IP/FQDN instead of
> > > the
> > 
> 
> > > host IP address.
> > > http://wiki.ovirt.org/wiki/Features/Display_Address_Override All
> > > comments are welcome...
> > 
> 
> > My 2 cents,
> 

> > This works under the assumption that all the users are either
> > outside
> > of the organization or inside.
> 
> > But think of some of the following scenarios based on a topology
> > where users in the main office are inside the corporate network
> > while users on remote offices / WAN are on a detached different
> > network on the other side of the NAT / public firewall :
> 

> > With current 'per host override' proposal:
> 
> > 1. Admin from the main office won't be able to access the VM
> > console
> 
> > 2. No Mixed environment, meaning that you have to have designated
> > clusters for remote offices users vs main office users - otherwise
> > connectivity to the console is determined based on scheduler
> > decision, or may break by live migration.
> 
> > 3. Based on #2, If I'm a user travelling between offices I'll have
> > to
> > ask the admin to turn off my VM and move it to internal cluster
> > before I can reconnect
> 

> > My suggestion is to covert this to 'alternative' IP/FQDN sending
> > the
> > spice client both internal fqdn/ip and the alternative. The spice
> > client should detect which is available of the two and
> > auto-connect.
> 

> > This requires enhancement of the spice client, but still solves all
> > the issues raised above (actually it solves about 90% of the use
> > cases I've heard about in the past).
> 

> > Another alternative is for the engine to 'guess' or 'elect' which
> > to
> > use, alternative or main, based on the IP of the client - meaning
> > admin provides the client ranges for providing internal host
> > address
> > vs alternative - but this is more complicated compared for the
> > previous suggestion
> 

> > Thoughts?
> 
> Lets not re-invent the wheel. This problem has been pondered before
> and solved[1], for all scenarios:
> internal clients connecting to internal resources;
> internal clients connecting to external resources, without the need
> for any intermediate assistance
> external clients connecting to internal resources, with the need for
> intermediate assistance.
> VPN clients connecting to internal resources, with or without an
> internal IP.

> Any other solution you'll try to come up with will bring you back to
> this standard, well known (along with its faults) method.

> The browser client will use PAC to determine how to connect to the
> hosts and will deliver this to the client. It's also a good path
> towards real proxy support for Spice.
> (Regardless, we still need to deal with the Spice protocol's
> migration command of course).

> [1] http://en.wikipedia.org/wiki/Proxy_auto-confi

If I'm reading this correctly the engine should prepare a URL with a PAC script for the Spice client, where the spice client should connect basea on the info in the PAC file. It's still means that we need to provide both internal and external connection option (just through PAC file). 

Nice. 





> > Simon.
> 
> > > Thanks,
> > 
> 
> > > michal
> > 
> 

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


From iheim at redhat.com  Sun Nov 11 20:52:53 2012
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 11 Nov 2012 22:52:53 +0200
Subject: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection
 algorithm for Power Management operations
In-Reply-To: <252984368.8434351.1352648741682.JavaMail.root@redhat.com>
References: <252984368.8434351.1352648741682.JavaMail.root@redhat.com>
Message-ID: <50A01025.7000300@redhat.com>

On 11/11/2012 05:45 PM, Simon Grinberg wrote:
> 3. The directly selected hosts comes to accommodate two use cases:
>     -3.1- Switch failure - if the fence network for hosts in a DC/Cluster have to split between two switches. Then you will prefer to use hosts that are for sure on the other switch
>     -3.2- Legacy clusters merged into larger clusters due to a move to oVirt then the infrastructural may still fit to the legacy connectivity - lot's of firewalls rules or direct connections that limit access to fencing devices to specific hosts.
>     -3.3- Clustered applications within the VMs, you only want your peers to be allowed to fence you. This is limited for VMs running on specific host group (affinity management that we don't have yet, but we can lock VMs to specific hosts).

that's VMs asking to fence (stop) other VMs, not hosts. why are you 
mixing it with host fencing?

>
>     Note that the above was not meant to accommodate any random server, just hosts in the setup, hosts that already run VDSM.
>     Meaning that maybe instead of the FQDN we can just use hostname - so the UUID will be registered in the tables
>     I don't why it's so complex, if a host provided is removed from the system you either get a canDoAction to remove it from the configuration as well (or a warning that this will remove the host from the fencing configuration). Your only risk if all of them are removed, then you need to set the exclamation mark again (power management is not configured for this host)

because this was a text field, and i don't like code having to know to 
check some obscure field and parse it for dependencies.
relations between entities are supposed to be via db referential 
integrity if possible (we had some locking issues with these).
i prefer implementation will start with the more simple use case not 
covering these complexities.


> - 5. Thinking about it more, Though the chain is more generic and flexible, I would like to return to my original suggestion, of having just primary and secondary proxy:
>       Primary Proxy 1 => Drop down -> Any cluster host / Any DC host / RHEV Manager / Named host out of the list of all the hosts
>       Secondary Proxy 2 => Drop down -> Any cluster host / Any DC host / RHEV Manager / Named host out of the list of all the hosts
>       I think is simpler as far as a user is concerned and it's simpler for us to implement two fields single value in each. And I don't believe we really need more, even in the simple case of cluster only hosts, for clusters larger then 4 hosts by the time you get to the secondary it may be too late. Secondary is more critical for the 'Named host' option or small clusters.

this is a bit simpler. but as for specifying a specific host:
- now you are asking to check two fields (proxy1, proxy2)
- probably to also alert if all these hosts moved to maint, or when
   moving them to another cluster, etc.
- it doesn't cover the use case of splitting between switches, sub 
clusters, etc. as you are limited to two hosts, which may have been 
moved to maint/shutdown for power saving, etc. (since you are using a 
static host assignment, rather than an implied group of hosts (cluster, 
dc, engine)




From emesika at redhat.com  Sun Nov 11 21:16:14 2012
From: emesika at redhat.com (Eli Mesika)
Date: Sun, 11 Nov 2012 16:16:14 -0500 (EST)
Subject: [Engine-devel] [Design for 3.2 RFE] Adding support for external
 events
In-Reply-To: <509FDA95.5040103@redhat.com>
Message-ID: <1931831744.9104157.1352668574642.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: mkenneth at redhat.com, "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, November 11, 2012 7:04:21 PM
> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Adding support for external events
> 
> On 11/11/2012 06:18 PM, Eli Mesika wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Miki Kenneth" <mkenneth at redhat.com>
> >> To: "Itamar Heim" <iheim at redhat.com>
> >> Cc: "engine-devel" <engine-devel at ovirt.org>
> >> Sent: Sunday, November 11, 2012 5:12:23 PM
> >> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Adding support
> >> for external events
> >>
> >> On 11/11/2012 10:06 AM, Itamar Heim wrote:
> >>> On 11/11/2012 09:50 AM, Yaniv Kaul wrote:
> >>>> On 11/10/2012 11:40 PM, Eli Mesika wrote:
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Itamar Heim" <iheim at redhat.com>
> >>>>>> To: "Eli Mesika" <emesika at redhat.com>
> >>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>, "Einav Cohen"
> >>>>>> <ecohen at redhat.com>, "Michael Pasternak"
> >>>>>> <mpastern at redhat.com>
> >>>>>> Sent: Friday, November 9, 2012 10:55:58 AM
> >>>>>> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Adding
> >>>>>> support
> >>>>>> for
> >>>>>> external events
> >>>>>>
> >>>>>> On 11/08/2012 05:17 PM, Eli Mesika wrote:
> >>>>>>> Hi
> >>>>>>>
> >>>>>>> Please review , any comments are welcomed (please note that
> >>>>>>> API
> >>>>>>> section is still in TBD)
> >>>>>>>
> >>>>>>> RFE :https://bugzilla.redhat.com/show_bug.cgi?id=873223
> >>>>>>> Requirements :
> >>>>>>> http://wiki.ovirt.org/wiki/Features/ExternalEvents
> >>>>>>> Events are classified as NORMAL , WARNING or ERROR and UI
> >>>>>>> will
> >>>>>>> display different icon according to that.
> >>>>>> any reason to not allow external ALERTs?
> >>>>> Currently we are using ALERTS only for PM events, do we have to
> >>>>> allow
> >>>>> displaying external Alerts in the Alerts TAB as well???
> >>>>>
> >>>>>>> Detailed Design
> >>>>>>> :http://wiki.ovirt.org/wiki/Features/Design/DetailedExternalEvents
> >>>>>>> Adding is_external boolean field to audit_log with a default
> >>>>>>> value
> >>>>>>> of false
> >>>>>> hmmm, i'm not sure it makes sense to inject any event, just
> >>>>>> flagging
> >>>>>> it
> >>>>>> as external.
> >>>>>> why not just add a new AuditLogType of 'External' (i.e., just
> >>>>>> another
> >>>>>> event id?
> >>>>>> it is easy enough to search for it, etc.
> >>>>> We are adding not one AuditLogType rather , it will be 3 or 4
> >>>>> (depends
> >>>>> on we support also Alerts)
> >>>>> The additional is_external is defaulted to false , so ,
> >>>>> existing
> >>>>> code
> >>>>> is not influenced
> >>>>> I think that in the search it will be simpler to refer to
> >>>>> is_external
> >>>>> rather to the 3 or 4 specific types
> >>>>> Also , cleanup of old external events should use this column
> >> regarding the clean-up events/alerts, is that possible while we
> >> are
> >> on
> >> the subject?
> >> It would be nice to indicate that alert was viewed and
> >> acknowledged
> >> and
> >> we can filter it out of the tab.
> >
> > I think I should Support ALERT_ON and ALERT_OFF for that ...
> > So, ALERT_ON will add that to the tab and ALERT_OFF will remove it
> 
> I think the more important thing (and generic to events as well) is
> for
> someone to flag the event/alert as owned/being handled by themselves,
> commenting on what they did/are doing, etc.
> not sure why alert should have an off mode, since iirc, alerts are
> automatically cleaned when their root issue is solved.

Up to now, we had used Alerts only for PM , so , if for example we have no PM configured on a Host , we will got an Alert that will be deleted (from audit_log table) when we successfully configurer and tested PM on that Host.
So, in the case events , they really stay in DB until they become OLD and the clean-up mechanism removes them, but , in Alerts , I believe that we should give an option to remove and Alert or create the Alert with a deprecation time and remove it when this time is passed... 

> (if anything, you would want to have an 'ignore alert' action by an
> admin (for X days/forever)
> 
> 
> >
> >>>>>
> >>>>>
> >>>>>>> New command is exposed currently only to SuperUser
> >>>>>> I assume you mean there is a new permission, which by default
> >>>>>> is
> >>>>>> added
> >>>>>> only to superuser role, and admin can add it to other custom
> >>>>>> roles?
> >>>>>> I also assume this is only relevant to admin users, not to
> >>>>>> user
> >>>>>> roles?
> >>>>> Yes
> >>>>
> >>>> What's the protection against LDAP injection, SQL injection,
> >>>> Javascript
> >>>> injection ... ?
> >>>> How do we sanitize the input of the event?
> >>>>
> >>>> Regardless, what about localization? Can the plugin know in
> >>>> which
> >>>> language it should inject the event?
> >>>
> >>> audit log is not localized at this point.
> >>> _______________________________________________
> >>> Engine-devel mailing list
> >>> Engine-devel at ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> 
> 
> 


From simon at redhat.com  Sun Nov 11 21:22:29 2012
From: simon at redhat.com (Simon Grinberg)
Date: Sun, 11 Nov 2012 16:22:29 -0500 (EST)
Subject: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection
 algorithm for Power Management operations
In-Reply-To: <50A01025.7000300@redhat.com>
Message-ID: <1122691004.8473397.1352668949964.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Simon Grinberg" <simon at redhat.com>
> Cc: "Eli Mesika" <emesika at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, November 11, 2012 10:52:53 PM
> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
> 
> On 11/11/2012 05:45 PM, Simon Grinberg wrote:
> > 3. The directly selected hosts comes to accommodate two use cases:
> >     -3.1- Switch failure - if the fence network for hosts in a
> >     DC/Cluster have to split between two switches. Then you will
> >     prefer to use hosts that are for sure on the other switch
> >     -3.2- Legacy clusters merged into larger clusters due to a move
> >     to oVirt then the infrastructural may still fit to the legacy
> >     connectivity - lot's of firewalls rules or direct connections
> >     that limit access to fencing devices to specific hosts.
> >     -3.3- Clustered applications within the VMs, you only want your
> >     peers to be allowed to fence you. This is limited for VMs
> >     running on specific host group (affinity management that we
> >     don't have yet, but we can lock VMs to specific hosts).
> 
> that's VMs asking to fence (stop) other VMs, not hosts. why are you
> mixing it with host fencing?

What happens if the host on which the peer VM is down?  
You need to fence the host. I was thinking about preventing a race where the VM asks to fence it's peer while the engine fences the host. In this case the fence of the peer VM may be reported as failed (no option to send stop to the VM) while the host status is yet unknown, or worse may succeed after the host rebooted killing the VM again after it restarted.

To prevent that you request to fence the host instead of fencing the VM a. But you are right that it does not matter which host will do the fencing, I was thinking on the old stile infra.


> 
> >
> >     Note that the above was not meant to accommodate any random
> >     server, just hosts in the setup, hosts that already run VDSM.
> >     Meaning that maybe instead of the FQDN we can just use hostname
> >     - so the UUID will be registered in the tables
> >     I don't why it's so complex, if a host provided is removed from
> >     the system you either get a canDoAction to remove it from the
> >     configuration as well (or a warning that this will remove the
> >     host from the fencing configuration). Your only risk if all of
> >     them are removed, then you need to set the exclamation mark
> >     again (power management is not configured for this host)
> 
> because this was a text field, and i don't like code having to know
> to
> check some obscure field and parse it for dependencies.
> relations between entities are supposed to be via db referential
> integrity if possible (we had some locking issues with these).
> i prefer implementation will start with the more simple use case not
> covering these complexities.
> 
> 
> > - 5. Thinking about it more, Though the chain is more generic and
> > flexible, I would like to return to my original suggestion, of
> > having just primary and secondary proxy:
> >       Primary Proxy 1 => Drop down -> Any cluster host / Any DC
> >       host / RHEV Manager / Named host out of the list of all the
> >       hosts
> >       Secondary Proxy 2 => Drop down -> Any cluster host / Any DC
> >       host / RHEV Manager / Named host out of the list of all the
> >       hosts
> >       I think is simpler as far as a user is concerned and it's
> >       simpler for us to implement two fields single value in each.
> >       And I don't believe we really need more, even in the simple
> >       case of cluster only hosts, for clusters larger then 4 hosts
> >       by the time you get to the secondary it may be too late.
> >       Secondary is more critical for the 'Named host' option or
> >       small clusters.
> 
> this is a bit simpler. but as for specifying a specific host:
> - now you are asking to check two fields (proxy1, proxy2)
> - probably to also alert if all these hosts moved to maint, or when
>    moving them to another cluster, etc.
> - it doesn't cover the use case of splitting between switches, sub
> clusters, etc. as you are limited to two hosts, which may have been
> moved to maint/shutdown for power saving, etc. (since you are using a
> static host assignment, rather than an implied group of hosts
> (cluster,
> dc, engine)

Are you offering to allow defining hosts-groups? :). I'll be happy if you do, we really need that for some cases of the affinity feature. Especially those involving multi-site. 

Hosts group == "A set of named hosts within the same cluster" 


> 
> 
> 


From simon at redhat.com  Mon Nov 12 09:40:07 2012
From: simon at redhat.com (Simon Grinberg)
Date: Mon, 12 Nov 2012 04:40:07 -0500 (EST)
Subject: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection
 algorithm for Power Management operations
In-Reply-To: <1122691004.8473397.1352668949964.JavaMail.root@redhat.com>
Message-ID: <373806.36.1352713204727.JavaMail.javamailuser@localhost>



----- Original Message -----
> From: "Simon Grinberg" <simon at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: "Eli Mesika" <emesika at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, November 11, 2012 11:22:29 PM
> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
> 
> 
> 
> ----- Original Message -----
> > From: "Itamar Heim" <iheim at redhat.com>
> > To: "Simon Grinberg" <simon at redhat.com>
> > Cc: "Eli Mesika" <emesika at redhat.com>, "engine-devel"
> > <engine-devel at ovirt.org>
> > Sent: Sunday, November 11, 2012 10:52:53 PM
> > Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy
> > selection algorithm for Power Management operations
> > 
> > On 11/11/2012 05:45 PM, Simon Grinberg wrote:
> > > 3. The directly selected hosts comes to accommodate two use
> > > cases:
> > >     -3.1- Switch failure - if the fence network for hosts in a
> > >     DC/Cluster have to split between two switches. Then you will
> > >     prefer to use hosts that are for sure on the other switch
> > >     -3.2- Legacy clusters merged into larger clusters due to a
> > >     move
> > >     to oVirt then the infrastructural may still fit to the legacy
> > >     connectivity - lot's of firewalls rules or direct connections
> > >     that limit access to fencing devices to specific hosts.
> > >     -3.3- Clustered applications within the VMs, you only want
> > >     your
> > >     peers to be allowed to fence you. This is limited for VMs
> > >     running on specific host group (affinity management that we
> > >     don't have yet, but we can lock VMs to specific hosts).
> > 
> > that's VMs asking to fence (stop) other VMs, not hosts. why are you
> > mixing it with host fencing?
> 
> What happens if the host on which the peer VM is down?
> You need to fence the host. I was thinking about preventing a race
> where the VM asks to fence it's peer while the engine fences the
> host. In this case the fence of the peer VM may be reported as
> failed (no option to send stop to the VM) while the host status is
> yet unknown, or worse may succeed after the host rebooted killing
> the VM again after it restarted.
> 
> To prevent that you request to fence the host instead of fencing the
> VM a. But you are right that it does not matter which host will do
> the fencing, I was thinking on the old stile infra.
> 
> 
> > 
> > >
> > >     Note that the above was not meant to accommodate any random
> > >     server, just hosts in the setup, hosts that already run VDSM.
> > >     Meaning that maybe instead of the FQDN we can just use
> > >     hostname
> > >     - so the UUID will be registered in the tables
> > >     I don't why it's so complex, if a host provided is removed
> > >     from
> > >     the system you either get a canDoAction to remove it from the
> > >     configuration as well (or a warning that this will remove the
> > >     host from the fencing configuration). Your only risk if all
> > >     of
> > >     them are removed, then you need to set the exclamation mark
> > >     again (power management is not configured for this host)
> > 
> > because this was a text field, and i don't like code having to know
> > to
> > check some obscure field and parse it for dependencies.
> > relations between entities are supposed to be via db referential
> > integrity if possible (we had some locking issues with these).
> > i prefer implementation will start with the more simple use case
> > not
> > covering these complexities.
> > 
> > 
> > > - 5. Thinking about it more, Though the chain is more generic and
> > > flexible, I would like to return to my original suggestion, of
> > > having just primary and secondary proxy:
> > >       Primary Proxy 1 => Drop down -> Any cluster host / Any DC
> > >       host / RHEV Manager / Named host out of the list of all the
> > >       hosts
> > >       Secondary Proxy 2 => Drop down -> Any cluster host / Any DC
> > >       host / RHEV Manager / Named host out of the list of all the
> > >       hosts
> > >       I think is simpler as far as a user is concerned and it's
> > >       simpler for us to implement two fields single value in
> > >       each.
> > >       And I don't believe we really need more, even in the simple
> > >       case of cluster only hosts, for clusters larger then 4
> > >       hosts
> > >       by the time you get to the secondary it may be too late.
> > >       Secondary is more critical for the 'Named host' option or
> > >       small clusters.
> > 
> > this is a bit simpler. but as for specifying a specific host:
> > - now you are asking to check two fields (proxy1, proxy2)
> > - probably to also alert if all these hosts moved to maint, or when
> >    moving them to another cluster, etc.
> > - it doesn't cover the use case of splitting between switches, sub
> > clusters, etc. as you are limited to two hosts, which may have been
> > moved to maint/shutdown for power saving, etc. (since you are using
> > a
> > static host assignment, rather than an implied group of hosts
> > (cluster,
> > dc, engine)
> 
> Are you offering to allow defining hosts-groups? :). I'll be happy if
> you do, we really need that for some cases of the affinity feature.
> Especially those involving multi-site.
> 
> Hosts group == "A set of named hosts within the same cluster" 

Reading again, I actually like it better then using specific host, it may be worth while to wait while making sure that when we implement this for SLA we design the hosts grouping generic enough to be used by the fencing mechanism. 


> 
> 
> > 
> > 
> >


From danken at redhat.com  Mon Nov 12 09:47:14 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Mon, 12 Nov 2012 11:47:14 +0200
Subject: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection
 algorithm for Power Management operations
In-Reply-To: <1008746778.9047332.1352632733372.JavaMail.root@redhat.com>
References: <1357032386.8570374.1352455565925.JavaMail.root@redhat.com>
	<1008746778.9047332.1352632733372.JavaMail.root@redhat.com>
Message-ID: <20121112094714.GB28849@redhat.com>

On Sun, Nov 11, 2012 at 06:18:53AM -0500, Eli Mesika wrote:
> 
> 
> ----- Original Message -----
> > From: "Eli Mesika" <emesika at redhat.com>
> > To: "Itamar Heim" <iheim at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Friday, November 9, 2012 12:06:05 PM
> > Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Itamar Heim" <iheim at redhat.com>
> > > To: "Eli Mesika" <emesika at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>, "Michael Pasternak"
> > > <mpastern at redhat.com>, "Simon Grinberg"
> > > <sgrinber at redhat.com>, "Dan Kenigsberg" <danken at redhat.com>
> > > Sent: Friday, November 9, 2012 12:02:37 PM
> > > Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy
> > > selection algorithm for Power Management operations
> > > 
> > > On 11/09/2012 10:52 AM, Eli Mesika wrote:
> > > 
> > > >> >
> > > >> >  > FenceWrapper
> > > >> >
> > > >> >i understand danken suggested going this way, rather than than
> > > >> >another
> > > >> >instance of vdsm.
> > > >> >is vdsm only calling these scripts today and all logic is in
> > > >> >engine,
> > > >> >or
> > > >> >does vdsm has any logic in wrapping these scripts (not a
> > > >> >blocker
> > > >> >to
> > > >> >doing FenceWrapper, just worth extracting that logic from vdsm
> > > >> >to
> > > >> >such a
> > > >> >script, then using it in both. i hope answer is 'no logic'...)
> > > > vdsm has some logic that maps between the call passed to it from
> > > > engine and the actual parameters generated for the script.
> > > > AFAIK, this logic only "builds" the correct arguments for the
> > > > command according to the agent type
> > > >
> > > 
> > > can we extract it to an external wrapper?
> > > I'd hate to fix bugs/changes twice for this.
> > 
> > I'll check it with danken on SUN
> 
> Well, looked at it a bit , the VDSM code is in fenceNote function in API.py
> What I think is that we can exclude the fenceNote implementation to a separate fence.py file and call it from the API.py
> Then we can use one of the following in Java to call the method from fence.py
> 1) jython
> 2) org.python.util.PythonInterpreter
> 
> See http://stackoverflow.com/questions/8898765/calling-python-in-java
> 
> danken, what do you think ?

BTW, no one has promised the the fence script is implemented in Python

$ file `which fence_ipmilan `
/usr/sbin/fence_ipmilan: ELF 64-bit LSB executable...


From simon at redhat.com  Mon Nov 12 10:01:19 2012
From: simon at redhat.com (Simon Grinberg)
Date: Mon, 12 Nov 2012 05:01:19 -0500 (EST)
Subject: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection
 algorithm for Power Management operations
In-Reply-To: <20121112094714.GB28849@redhat.com>
Message-ID: <1860708784.8640411.1352714479658.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, November 12, 2012 11:47:14 AM
> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
> 
> On Sun, Nov 11, 2012 at 06:18:53AM -0500, Eli Mesika wrote:
> > 
> > 
> > ----- Original Message -----
> > > From: "Eli Mesika" <emesika at redhat.com>
> > > To: "Itamar Heim" <iheim at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Friday, November 9, 2012 12:06:05 PM
> > > Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy
> > > selection algorithm for Power Management operations
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Itamar Heim" <iheim at redhat.com>
> > > > To: "Eli Mesika" <emesika at redhat.com>
> > > > Cc: "engine-devel" <engine-devel at ovirt.org>, "Michael
> > > > Pasternak"
> > > > <mpastern at redhat.com>, "Simon Grinberg"
> > > > <sgrinber at redhat.com>, "Dan Kenigsberg" <danken at redhat.com>
> > > > Sent: Friday, November 9, 2012 12:02:37 PM
> > > > Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving
> > > > proxy
> > > > selection algorithm for Power Management operations
> > > > 
> > > > On 11/09/2012 10:52 AM, Eli Mesika wrote:
> > > > 
> > > > >> >
> > > > >> >  > FenceWrapper
> > > > >> >
> > > > >> >i understand danken suggested going this way, rather than
> > > > >> >than
> > > > >> >another
> > > > >> >instance of vdsm.
> > > > >> >is vdsm only calling these scripts today and all logic is
> > > > >> >in
> > > > >> >engine,
> > > > >> >or
> > > > >> >does vdsm has any logic in wrapping these scripts (not a
> > > > >> >blocker
> > > > >> >to
> > > > >> >doing FenceWrapper, just worth extracting that logic from
> > > > >> >vdsm
> > > > >> >to
> > > > >> >such a
> > > > >> >script, then using it in both. i hope answer is 'no
> > > > >> >logic'...)
> > > > > vdsm has some logic that maps between the call passed to it
> > > > > from
> > > > > engine and the actual parameters generated for the script.
> > > > > AFAIK, this logic only "builds" the correct arguments for the
> > > > > command according to the agent type
> > > > >
> > > > 
> > > > can we extract it to an external wrapper?
> > > > I'd hate to fix bugs/changes twice for this.
> > > 
> > > I'll check it with danken on SUN
> > 
> > Well, looked at it a bit , the VDSM code is in fenceNote function
> > in API.py
> > What I think is that we can exclude the fenceNote implementation to
> > a separate fence.py file and call it from the API.py
> > Then we can use one of the following in Java to call the method
> > from fence.py
> > 1) jython
> > 2) org.python.util.PythonInterpreter
> > 
> > See
> > http://stackoverflow.com/questions/8898765/calling-python-in-java
> > 
> > danken, what do you think ?
> 
> BTW, no one has promised the the fence script is implemented in
> Python
> 
> $ file `which fence_ipmilan `
> /usr/sbin/fence_ipmilan: ELF 64-bit LSB executable...

PS, if it's really that complex I don't see the a big issue dropping engine fence
It is mostly useful when you have small number of hosts, or collection of small clusters where the admin limits the hosts that are allowed to fence to cluster hosts and as a failsafe the 'engine' 

*It does however solves at the same time the issue that we (still) can't 'Approve a host have been rebooted' if it's the last host in the DC since the path goes through the fencing logic. 


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


From iheim at redhat.com  Mon Nov 12 10:21:57 2012
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 12 Nov 2012 12:21:57 +0200
Subject: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection
 algorithm for Power Management operations
In-Reply-To: <1860708784.8640411.1352714479658.JavaMail.root@redhat.com>
References: <1860708784.8640411.1352714479658.JavaMail.root@redhat.com>
Message-ID: <50A0CDC5.3020205@redhat.com>

On 11/12/2012 12:01 PM, Simon Grinberg wrote:
>
>
> ----- Original Message -----
>> From: "Dan Kenigsberg" <danken at redhat.com>
>> To: "Eli Mesika" <emesika at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Monday, November 12, 2012 11:47:14 AM
>> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
>>
>> On Sun, Nov 11, 2012 at 06:18:53AM -0500, Eli Mesika wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Eli Mesika" <emesika at redhat.com>
>>>> To: "Itamar Heim" <iheim at redhat.com>
>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>> Sent: Friday, November 9, 2012 12:06:05 PM
>>>> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy
>>>> selection algorithm for Power Management operations
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Itamar Heim" <iheim at redhat.com>
>>>>> To: "Eli Mesika" <emesika at redhat.com>
>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>, "Michael
>>>>> Pasternak"
>>>>> <mpastern at redhat.com>, "Simon Grinberg"
>>>>> <sgrinber at redhat.com>, "Dan Kenigsberg" <danken at redhat.com>
>>>>> Sent: Friday, November 9, 2012 12:02:37 PM
>>>>> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving
>>>>> proxy
>>>>> selection algorithm for Power Management operations
>>>>>
>>>>> On 11/09/2012 10:52 AM, Eli Mesika wrote:
>>>>>
>>>>>>>>
>>>>>>>>   > FenceWrapper
>>>>>>>>
>>>>>>>> i understand danken suggested going this way, rather than
>>>>>>>> than
>>>>>>>> another
>>>>>>>> instance of vdsm.
>>>>>>>> is vdsm only calling these scripts today and all logic is
>>>>>>>> in
>>>>>>>> engine,
>>>>>>>> or
>>>>>>>> does vdsm has any logic in wrapping these scripts (not a
>>>>>>>> blocker
>>>>>>>> to
>>>>>>>> doing FenceWrapper, just worth extracting that logic from
>>>>>>>> vdsm
>>>>>>>> to
>>>>>>>> such a
>>>>>>>> script, then using it in both. i hope answer is 'no
>>>>>>>> logic'...)
>>>>>> vdsm has some logic that maps between the call passed to it
>>>>>> from
>>>>>> engine and the actual parameters generated for the script.
>>>>>> AFAIK, this logic only "builds" the correct arguments for the
>>>>>> command according to the agent type
>>>>>>
>>>>>
>>>>> can we extract it to an external wrapper?
>>>>> I'd hate to fix bugs/changes twice for this.
>>>>
>>>> I'll check it with danken on SUN
>>>
>>> Well, looked at it a bit , the VDSM code is in fenceNote function
>>> in API.py
>>> What I think is that we can exclude the fenceNote implementation to
>>> a separate fence.py file and call it from the API.py
>>> Then we can use one of the following in Java to call the method
>>> from fence.py
>>> 1) jython
>>> 2) org.python.util.PythonInterpreter
>>>
>>> See
>>> http://stackoverflow.com/questions/8898765/calling-python-in-java
>>>
>>> danken, what do you think ?
>>
>> BTW, no one has promised the the fence script is implemented in
>> Python
>>
>> $ file `which fence_ipmilan `
>> /usr/sbin/fence_ipmilan: ELF 64-bit LSB executable...
>
> PS, if it's really that complex I don't see the a big issue dropping engine fence
> It is mostly useful when you have small number of hosts, or collection of small clusters where the admin limits the hosts that are allowed to fence to cluster hosts and as a failsafe the 'engine'
>
> *It does however solves at the same time the issue that we (still) can't 'Approve a host have been rebooted' if it's the last host in the DC since the path goes through the fencing logic.

exactly, we need to allow engine fence to solve the single/last host 
private case.


From simon at redhat.com  Mon Nov 12 10:29:41 2012
From: simon at redhat.com (Simon Grinberg)
Date: Mon, 12 Nov 2012 05:29:41 -0500 (EST)
Subject: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection
 algorithm for Power Management operations
In-Reply-To: <50A0CDC5.3020205@redhat.com>
Message-ID: <441174977.8705203.1352716181874.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Simon Grinberg" <simon at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, November 12, 2012 12:21:57 PM
> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
> 
> On 11/12/2012 12:01 PM, Simon Grinberg wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Dan Kenigsberg" <danken at redhat.com>
> >> To: "Eli Mesika" <emesika at redhat.com>
> >> Cc: "engine-devel" <engine-devel at ovirt.org>
> >> Sent: Monday, November 12, 2012 11:47:14 AM
> >> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy
> >> selection algorithm for Power Management operations
> >>
> >> On Sun, Nov 11, 2012 at 06:18:53AM -0500, Eli Mesika wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Eli Mesika" <emesika at redhat.com>
> >>>> To: "Itamar Heim" <iheim at redhat.com>
> >>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> >>>> Sent: Friday, November 9, 2012 12:06:05 PM
> >>>> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy
> >>>> selection algorithm for Power Management operations
> >>>>
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Itamar Heim" <iheim at redhat.com>
> >>>>> To: "Eli Mesika" <emesika at redhat.com>
> >>>>> Cc: "engine-devel" <engine-devel at ovirt.org>, "Michael
> >>>>> Pasternak"
> >>>>> <mpastern at redhat.com>, "Simon Grinberg"
> >>>>> <sgrinber at redhat.com>, "Dan Kenigsberg" <danken at redhat.com>
> >>>>> Sent: Friday, November 9, 2012 12:02:37 PM
> >>>>> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving
> >>>>> proxy
> >>>>> selection algorithm for Power Management operations
> >>>>>
> >>>>> On 11/09/2012 10:52 AM, Eli Mesika wrote:
> >>>>>
> >>>>>>>>
> >>>>>>>>   > FenceWrapper
> >>>>>>>>
> >>>>>>>> i understand danken suggested going this way, rather than
> >>>>>>>> than
> >>>>>>>> another
> >>>>>>>> instance of vdsm.
> >>>>>>>> is vdsm only calling these scripts today and all logic is
> >>>>>>>> in
> >>>>>>>> engine,
> >>>>>>>> or
> >>>>>>>> does vdsm has any logic in wrapping these scripts (not a
> >>>>>>>> blocker
> >>>>>>>> to
> >>>>>>>> doing FenceWrapper, just worth extracting that logic from
> >>>>>>>> vdsm
> >>>>>>>> to
> >>>>>>>> such a
> >>>>>>>> script, then using it in both. i hope answer is 'no
> >>>>>>>> logic'...)
> >>>>>> vdsm has some logic that maps between the call passed to it
> >>>>>> from
> >>>>>> engine and the actual parameters generated for the script.
> >>>>>> AFAIK, this logic only "builds" the correct arguments for the
> >>>>>> command according to the agent type
> >>>>>>
> >>>>>
> >>>>> can we extract it to an external wrapper?
> >>>>> I'd hate to fix bugs/changes twice for this.
> >>>>
> >>>> I'll check it with danken on SUN
> >>>
> >>> Well, looked at it a bit , the VDSM code is in fenceNote function
> >>> in API.py
> >>> What I think is that we can exclude the fenceNote implementation
> >>> to
> >>> a separate fence.py file and call it from the API.py
> >>> Then we can use one of the following in Java to call the method
> >>> from fence.py
> >>> 1) jython
> >>> 2) org.python.util.PythonInterpreter
> >>>
> >>> See
> >>> http://stackoverflow.com/questions/8898765/calling-python-in-java
> >>>
> >>> danken, what do you think ?
> >>
> >> BTW, no one has promised the the fence script is implemented in
> >> Python
> >>
> >> $ file `which fence_ipmilan `
> >> /usr/sbin/fence_ipmilan: ELF 64-bit LSB executable...
> >
> > PS, if it's really that complex I don't see the a big issue
> > dropping engine fence
> > It is mostly useful when you have small number of hosts, or
> > collection of small clusters where the admin limits the hosts that
> > are allowed to fence to cluster hosts and as a failsafe the
> > 'engine'
> >
> > *It does however solves at the same time the issue that we (still)
> > can't 'Approve a host have been rebooted' if it's the last host in
> > the DC since the path goes through the fencing logic.
> 
> exactly, we need to allow engine fence to solve the single/last host
> private case.

Indeed 

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


From yzaslavs at redhat.com  Mon Nov 12 15:33:19 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Mon, 12 Nov 2012 10:33:19 -0500 (EST)
Subject: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection
 algorithm for Power Management operations
In-Reply-To: <20121112094714.GB28849@redhat.com>
Message-ID: <696836638.30543206.1352734399140.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, November 12, 2012 11:47:14 AM
> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
> 
> On Sun, Nov 11, 2012 at 06:18:53AM -0500, Eli Mesika wrote:
> > 
> > 
> > ----- Original Message -----
> > > From: "Eli Mesika" <emesika at redhat.com>
> > > To: "Itamar Heim" <iheim at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Friday, November 9, 2012 12:06:05 PM
> > > Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy
> > > selection algorithm for Power Management operations
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Itamar Heim" <iheim at redhat.com>
> > > > To: "Eli Mesika" <emesika at redhat.com>
> > > > Cc: "engine-devel" <engine-devel at ovirt.org>, "Michael
> > > > Pasternak"
> > > > <mpastern at redhat.com>, "Simon Grinberg"
> > > > <sgrinber at redhat.com>, "Dan Kenigsberg" <danken at redhat.com>
> > > > Sent: Friday, November 9, 2012 12:02:37 PM
> > > > Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving
> > > > proxy
> > > > selection algorithm for Power Management operations
> > > > 
> > > > On 11/09/2012 10:52 AM, Eli Mesika wrote:
> > > > 
> > > > >> >
> > > > >> >  > FenceWrapper
> > > > >> >
> > > > >> >i understand danken suggested going this way, rather than
> > > > >> >than
> > > > >> >another
> > > > >> >instance of vdsm.
> > > > >> >is vdsm only calling these scripts today and all logic is
> > > > >> >in
> > > > >> >engine,
> > > > >> >or
> > > > >> >does vdsm has any logic in wrapping these scripts (not a
> > > > >> >blocker
> > > > >> >to
> > > > >> >doing FenceWrapper, just worth extracting that logic from
> > > > >> >vdsm
> > > > >> >to
> > > > >> >such a
> > > > >> >script, then using it in both. i hope answer is 'no
> > > > >> >logic'...)
> > > > > vdsm has some logic that maps between the call passed to it
> > > > > from
> > > > > engine and the actual parameters generated for the script.
> > > > > AFAIK, this logic only "builds" the correct arguments for the
> > > > > command according to the agent type
> > > > >
> > > > 
> > > > can we extract it to an external wrapper?
> > > > I'd hate to fix bugs/changes twice for this.
> > > 
> > > I'll check it with danken on SUN
> > 
> > Well, looked at it a bit , the VDSM code is in fenceNote function
> > in API.py
> > What I think is that we can exclude the fenceNote implementation to
> > a separate fence.py file and call it from the API.py
> > Then we can use one of the following in Java to call the method
> > from fence.py
> > 1) jython
> > 2) org.python.util.PythonInterpreter
> > 
> > See
> > http://stackoverflow.com/questions/8898765/calling-python-in-java
> > 
> > danken, what do you think ?
> 
> BTW, no one has promised the the fence script is implemented in
> Python

Hmm, in this case, maybe we should invoke the script as process from JVM (ugly, but ScriptEngine, or Eli's suggestion will not work
unless we know the type of the script).

> 
> $ file `which fence_ipmilan `
> /usr/sbin/fence_ipmilan: ELF 64-bit LSB executable...
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From yzaslavs at redhat.com  Mon Nov 12 15:37:26 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Mon, 12 Nov 2012 10:37:26 -0500 (EST)
Subject: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection
 algorithm for Power Management operations
In-Reply-To: <50A0CDC5.3020205@redhat.com>
Message-ID: <1462064246.30545269.1352734646024.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Simon Grinberg" <simon at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, November 12, 2012 12:21:57 PM
> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
> 
> On 11/12/2012 12:01 PM, Simon Grinberg wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Dan Kenigsberg" <danken at redhat.com>
> >> To: "Eli Mesika" <emesika at redhat.com>
> >> Cc: "engine-devel" <engine-devel at ovirt.org>
> >> Sent: Monday, November 12, 2012 11:47:14 AM
> >> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy
> >> selection algorithm for Power Management operations
> >>
> >> On Sun, Nov 11, 2012 at 06:18:53AM -0500, Eli Mesika wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Eli Mesika" <emesika at redhat.com>
> >>>> To: "Itamar Heim" <iheim at redhat.com>
> >>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> >>>> Sent: Friday, November 9, 2012 12:06:05 PM
> >>>> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy
> >>>> selection algorithm for Power Management operations
> >>>>
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Itamar Heim" <iheim at redhat.com>
> >>>>> To: "Eli Mesika" <emesika at redhat.com>
> >>>>> Cc: "engine-devel" <engine-devel at ovirt.org>, "Michael
> >>>>> Pasternak"
> >>>>> <mpastern at redhat.com>, "Simon Grinberg"
> >>>>> <sgrinber at redhat.com>, "Dan Kenigsberg" <danken at redhat.com>
> >>>>> Sent: Friday, November 9, 2012 12:02:37 PM
> >>>>> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving
> >>>>> proxy
> >>>>> selection algorithm for Power Management operations
> >>>>>
> >>>>> On 11/09/2012 10:52 AM, Eli Mesika wrote:
> >>>>>
> >>>>>>>>
> >>>>>>>>   > FenceWrapper
> >>>>>>>>
> >>>>>>>> i understand danken suggested going this way, rather than
> >>>>>>>> than
> >>>>>>>> another
> >>>>>>>> instance of vdsm.
> >>>>>>>> is vdsm only calling these scripts today and all logic is
> >>>>>>>> in
> >>>>>>>> engine,
> >>>>>>>> or
> >>>>>>>> does vdsm has any logic in wrapping these scripts (not a
> >>>>>>>> blocker
> >>>>>>>> to
> >>>>>>>> doing FenceWrapper, just worth extracting that logic from
> >>>>>>>> vdsm
> >>>>>>>> to
> >>>>>>>> such a
> >>>>>>>> script, then using it in both. i hope answer is 'no
> >>>>>>>> logic'...)
> >>>>>> vdsm has some logic that maps between the call passed to it
> >>>>>> from
> >>>>>> engine and the actual parameters generated for the script.
> >>>>>> AFAIK, this logic only "builds" the correct arguments for the
> >>>>>> command according to the agent type
> >>>>>>
> >>>>>
> >>>>> can we extract it to an external wrapper?
> >>>>> I'd hate to fix bugs/changes twice for this.
> >>>>
> >>>> I'll check it with danken on SUN
> >>>
> >>> Well, looked at it a bit , the VDSM code is in fenceNote function
> >>> in API.py
> >>> What I think is that we can exclude the fenceNote implementation
> >>> to
> >>> a separate fence.py file and call it from the API.py
> >>> Then we can use one of the following in Java to call the method
> >>> from fence.py
> >>> 1) jython
> >>> 2) org.python.util.PythonInterpreter
> >>>
> >>> See
> >>> http://stackoverflow.com/questions/8898765/calling-python-in-java
> >>>
> >>> danken, what do you think ?
> >>
> >> BTW, no one has promised the the fence script is implemented in
> >> Python
> >>
> >> $ file `which fence_ipmilan `
> >> /usr/sbin/fence_ipmilan: ELF 64-bit LSB executable...
> >
> > PS, if it's really that complex I don't see the a big issue
> > dropping engine fence
> > It is mostly useful when you have small number of hosts, or
> > collection of small clusters where the admin limits the hosts that
> > are allowed to fence to cluster hosts and as a failsafe the
> > 'engine'

Not sure if this is that complex, I would personally be glad to get more information on the nature of these fence scripts.
Basically, we have several "patterns" for external invocation:
a. Use ScriptEngine - but we must know the type
b. Exec process
c. JNI/JNA

And - in many java enterprise applications options A and C are implemented on a separate Java process (if it crashes, the jvm that runs the enterprise application does not crash) - but I don't think this approach is viable for 3.2.


> >
> > *It does however solves at the same time the issue that we (still)
> > can't 'Approve a host have been rebooted' if it's the last host in
> > the DC since the path goes through the fencing logic.
> 
> exactly, we need to allow engine fence to solve the single/last host
> private case.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From mbenanta at us.ibm.com  Mon Nov 12 16:14:19 2012
From: mbenanta at us.ibm.com (Messaoud Benantar)
Date: Mon, 12 Nov 2012 10:14:19 -0600
Subject: [Engine-devel] use of VM payload to set static IP info
Message-ID: <OFDAFFEC1D.A1E012C1-ON87257AB4.0058D2D3-86257AB4.00593580@us.ibm.com>

Hello folks,
              in our case we do need to assign static IP information to 
the KVM VMs that we provision.
In looking at RHEV 3.1 i see a new Rest function for sending a payload to 
a VM.

<vm>
   ...
     <payloads>
         <payload type='cdrom'>
             <file name='my.txt'>
                <content>some content</content>
             </file>
         </payload>
     </payloads>
  </vm>


I was wondering if anyone knows how to use VM payload to set static IP 
information for a VM (both linux and windows).
Thank you.

Regards,
Messaoud Benantar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121112/f385573d/attachment.html>

From iheim at redhat.com  Tue Nov 13 08:57:33 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 13 Nov 2012 10:57:33 +0200
Subject: [Engine-devel] Managing permissions on network
In-Reply-To: <50991728.8070702@redhat.com>
References: <50991728.8070702@redhat.com>
Message-ID: <50A20B7D.8000401@redhat.com>

On 11/06/2012 02:56 PM, Livnat Peer wrote:
> Hi All,
>
> This is a proposal for handling network permissions in oVirt.
>
> In this proposal we took the more permissive approach as we find it
> simple and a good starting point, we also think a more restrict approach
> makes the configuration of a network cumbersome for ovirt administrators.
>
> Inputs are welcomed as always...
>
> Here is an overview of the approach, for more detailed description
> please read the wiki page:
> http://wiki.ovirt.org/wiki/Feature/NetworkPermissions
>


> High Level Feature Description
> Admin
>
>     For creating a network in a DC you need to be SuperUser or DataCenterAdmin or NetworkAdmin on the DC.

since there are multiple permissions among the differnet roles, maybe 
worth specifying the actual permissions (actiongroups), rather than just 
the roles?

>     After creating the network you can manipulate the network if you are a DataCenterAdmin or NetworkAdmin on the relevant network (or the whole DC).
>     For attaching the network to cluster user needs to be NetworkAdmin on the network (no requirement to have permission on the cluster)
>     ClusterAdmin cannot attach/detach a network from the cluster, the motivation for this is that as long as the network is not attached to the cluster it is not part of the cluster resources thus can not be managed by the cluster administrator.

I'm not sure above two lines are intuitive to manage (a network admin 
can manipulate a cluster, but the cluster admin can't change networks in 
the cluster? this means you must give network permissions, at DC level, 
so you can't limit an admin to network attach/detach to a specific cluster.

>         The ClusterAdmin can change a network from required to non-required for controlling the impact of the network within the cluster.
>     For setting or manipulating a network on the host you need to be host administrator on the host and you don't need to be network administrator.
>
> User
>
>     For attaching a network to a Vnic in the VM you need to have the role of VmNetworkUser on the network and VmAdmin on the VM.

again, roles are just default roles, please specify the actual 
permission (actiongroup)

>     In user portal - the list of shown network for a user will include only the list of networks the user is allowed to attach to its vnics (instead of all cluster's networks).

or attached to user VMs.
and need to handle case of network attached to template but user has no 
permission to that network?

<snip>


From lpeer at redhat.com  Tue Nov 13 10:45:01 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Tue, 13 Nov 2012 12:45:01 +0200
Subject: [Engine-devel] Managing permissions on network
In-Reply-To: <50A20B7D.8000401@redhat.com>
References: <50991728.8070702@redhat.com> <50A20B7D.8000401@redhat.com>
Message-ID: <50A224AD.60205@redhat.com>

On 13/11/12 10:57, Itamar Heim wrote:
> On 11/06/2012 02:56 PM, Livnat Peer wrote:
>> Hi All,
>>
>> This is a proposal for handling network permissions in oVirt.
>>
>> In this proposal we took the more permissive approach as we find it
>> simple and a good starting point, we also think a more restrict approach
>> makes the configuration of a network cumbersome for ovirt administrators.
>>
>> Inputs are welcomed as always...
>>
>> Here is an overview of the approach, for more detailed description
>> please read the wiki page:
>> http://wiki.ovirt.org/wiki/Feature/NetworkPermissions
>>
> 
> 
>> High Level Feature Description
>> Admin
>>
>>     For creating a network in a DC you need to be SuperUser or
>> DataCenterAdmin or NetworkAdmin on the DC.
> 
> since there are multiple permissions among the differnet roles, maybe
> worth specifying the actual permissions (actiongroups), rather than just
> the roles?
> 

you can find this info in the wiki page itself,this is only high level
summary.

>>     After creating the network you can manipulate the network if you
>> are a DataCenterAdmin or NetworkAdmin on the relevant network (or the
>> whole DC).
>>     For attaching the network to cluster user needs to be NetworkAdmin
>> on the network (no requirement to have permission on the cluster)
>>     ClusterAdmin cannot attach/detach a network from the cluster, the
>> motivation for this is that as long as the network is not attached to
>> the cluster it is not part of the cluster resources thus can not be
>> managed by the cluster administrator.
> 
> I'm not sure above two lines are intuitive to manage (a network admin
> can manipulate a cluster, but the cluster admin can't change networks in
> the cluster? this means you must give network permissions, at DC level,
> so you can't limit an admin to network attach/detach to a specific cluster.
> 

That is true but looking on the alternative I think it make sense.
The alternative is to require two permissions for attaching a network to
a cluster one is networkAdmin (for editing network properties) on a
network and the other is networkAttach (a separate Role?) on a cluster
or the DC (if you want the user to be able to add the network for all
the clusters in the DC).
While I think the common use case is that a network administrator will
be able to attach the network to all the clusters I find the above
cumbersome and rather stick to the approach that you need only a single
permission and you can't limit the network manager to specific cluster.

I think that if a requirement for limiting the network to specific
clusters comes from our users only then we should make the model more
strict and require two permissions.


>>         The ClusterAdmin can change a network from required to
>> non-required for controlling the impact of the network within the
>> cluster.
>>     For setting or manipulating a network on the host you need to be
>> host administrator on the host and you don't need to be network
>> administrator.
>>
>> User
>>
>>     For attaching a network to a Vnic in the VM you need to have the
>> role of VmNetworkUser on the network and VmAdmin on the VM.
> 
> again, roles are just default roles, please specify the actual
> permission (actiongroup)

take a look in the wiki for exact details (which role is composed out of
which action groups)
> 
>>     In user portal - the list of shown network for a user will include
>> only the list of networks the user is allowed to attach to its vnics
>> (instead of all cluster's networks).
> 
> or attached to user VMs.
> and need to handle case of network attached to template but user has no
> permission to that network?
> 

Interesting point, I think that if a user has permission to create a VM
from a specific template we should give him permission to use the
template networks on this VM implicitly upon the VM creation.

I noticed the wiki page is missing which permission should be given to
users on which networks/VMs during upgrade - Moti?


> <snip>



From masayag at redhat.com  Tue Nov 13 13:17:18 2012
From: masayag at redhat.com (Moti Asayag)
Date: Tue, 13 Nov 2012 15:17:18 +0200
Subject: [Engine-devel] Managing permissions on network
In-Reply-To: <50A224AD.60205@redhat.com>
References: <50991728.8070702@redhat.com> <50A20B7D.8000401@redhat.com>
	<50A224AD.60205@redhat.com>
Message-ID: <50A2485E.8060403@redhat.com>

On 11/13/2012 12:45 PM, Livnat Peer wrote:
> On 13/11/12 10:57, Itamar Heim wrote:
>> On 11/06/2012 02:56 PM, Livnat Peer wrote:
>>> Hi All,
>>>
>>> This is a proposal for handling network permissions in oVirt.
>>>
>>> In this proposal we took the more permissive approach as we find it
>>> simple and a good starting point, we also think a more restrict approach
>>> makes the configuration of a network cumbersome for ovirt administrators.
>>>
>>> Inputs are welcomed as always...
>>>
>>> Here is an overview of the approach, for more detailed description
>>> please read the wiki page:
>>> http://wiki.ovirt.org/wiki/Feature/NetworkPermissions
>>>
>>
>>
>>> High Level Feature Description
>>> Admin
>>>
>>>     For creating a network in a DC you need to be SuperUser or
>>> DataCenterAdmin or NetworkAdmin on the DC.
>>
>> since there are multiple permissions among the differnet roles, maybe
>> worth specifying the actual permissions (actiongroups), rather than just
>> the roles?
>>
> 
> you can find this info in the wiki page itself,this is only high level
> summary.
> 
>>>     After creating the network you can manipulate the network if you
>>> are a DataCenterAdmin or NetworkAdmin on the relevant network (or the
>>> whole DC).
>>>     For attaching the network to cluster user needs to be NetworkAdmin
>>> on the network (no requirement to have permission on the cluster)
>>>     ClusterAdmin cannot attach/detach a network from the cluster, the
>>> motivation for this is that as long as the network is not attached to
>>> the cluster it is not part of the cluster resources thus can not be
>>> managed by the cluster administrator.
>>
>> I'm not sure above two lines are intuitive to manage (a network admin
>> can manipulate a cluster, but the cluster admin can't change networks in
>> the cluster? this means you must give network permissions, at DC level,
>> so you can't limit an admin to network attach/detach to a specific cluster.
>>
> 
> That is true but looking on the alternative I think it make sense.
> The alternative is to require two permissions for attaching a network to
> a cluster one is networkAdmin (for editing network properties) on a
> network and the other is networkAttach (a separate Role?) on a cluster
> or the DC (if you want the user to be able to add the network for all
> the clusters in the DC).
> While I think the common use case is that a network administrator will
> be able to attach the network to all the clusters I find the above
> cumbersome and rather stick to the approach that you need only a single
> permission and you can't limit the network manager to specific cluster.
> 
> I think that if a requirement for limiting the network to specific
> clusters comes from our users only then we should make the model more
> strict and require two permissions.
> 
> 
>>>         The ClusterAdmin can change a network from required to
>>> non-required for controlling the impact of the network within the
>>> cluster.
>>>     For setting or manipulating a network on the host you need to be
>>> host administrator on the host and you don't need to be network
>>> administrator.
>>>
>>> User
>>>
>>>     For attaching a network to a Vnic in the VM you need to have the
>>> role of VmNetworkUser on the network and VmAdmin on the VM.
>>
>> again, roles are just default roles, please specify the actual
>> permission (actiongroup)
> 
> take a look in the wiki for exact details (which role is composed out of
> which action groups)
>>
>>>     In user portal - the list of shown network for a user will include
>>> only the list of networks the user is allowed to attach to its vnics
>>> (instead of all cluster's networks).
>>
>> or attached to user VMs.
>> and need to handle case of network attached to template but user has no
>> permission to that network?
>>
> 
> Interesting point, I think that if a user has permission to create a VM
> from a specific template we should give him permission to use the
> template networks on this VM implicitly upon the VM creation.
> 
> I noticed the wiki page is missing which permission should be given to
> users on which networks/VMs during upgrade - Moti?
> 

Added:

* '''VmNetworkUser''' role will be given to the user on each network
attached to the VM/Template.
* '''AdvancedVmNetworkUser''' role will be given to the user on each
network attached to the VM with port-mirroring enabled.


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



From iheim at redhat.com  Tue Nov 13 13:19:36 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 13 Nov 2012 15:19:36 +0200
Subject: [Engine-devel] Managing permissions on network
In-Reply-To: <50A224AD.60205@redhat.com>
References: <50991728.8070702@redhat.com> <50A20B7D.8000401@redhat.com>
	<50A224AD.60205@redhat.com>
Message-ID: <50A248E8.10504@redhat.com>

On 11/13/2012 12:45 PM, Livnat Peer wrote:
> Interesting point, I think that if a user has permission to create a VM
> from a specific template we should give him permission to use the
> template networks on this VM implicitly upon the VM creation.

having a permission to a template does not mean a permission to the 
default network of that VM, especially as we'll use templates more as 
instance types.


From iheim at redhat.com  Tue Nov 13 13:21:47 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 13 Nov 2012 15:21:47 +0200
Subject: [Engine-devel] Managing permissions on network
In-Reply-To: <50A2485E.8060403@redhat.com>
References: <50991728.8070702@redhat.com> <50A20B7D.8000401@redhat.com>
	<50A224AD.60205@redhat.com> <50A2485E.8060403@redhat.com>
Message-ID: <50A2496B.1030004@redhat.com>

On 11/13/2012 03:17 PM, Moti Asayag wrote:
> On 11/13/2012 12:45 PM, Livnat Peer wrote:
>> On 13/11/12 10:57, Itamar Heim wrote:
>>> On 11/06/2012 02:56 PM, Livnat Peer wrote:
>>>> Hi All,
>>>>
>>>> This is a proposal for handling network permissions in oVirt.
>>>>
>>>> In this proposal we took the more permissive approach as we find it
>>>> simple and a good starting point, we also think a more restrict approach
>>>> makes the configuration of a network cumbersome for ovirt administrators.
>>>>
>>>> Inputs are welcomed as always...
>>>>
>>>> Here is an overview of the approach, for more detailed description
>>>> please read the wiki page:
>>>> http://wiki.ovirt.org/wiki/Feature/NetworkPermissions
>>>>
>>>
>>>
>>>> High Level Feature Description
>>>> Admin
>>>>
>>>>      For creating a network in a DC you need to be SuperUser or
>>>> DataCenterAdmin or NetworkAdmin on the DC.
>>>
>>> since there are multiple permissions among the differnet roles, maybe
>>> worth specifying the actual permissions (actiongroups), rather than just
>>> the roles?
>>>
>>
>> you can find this info in the wiki page itself,this is only high level
>> summary.
>>
>>>>      After creating the network you can manipulate the network if you
>>>> are a DataCenterAdmin or NetworkAdmin on the relevant network (or the
>>>> whole DC).
>>>>      For attaching the network to cluster user needs to be NetworkAdmin
>>>> on the network (no requirement to have permission on the cluster)
>>>>      ClusterAdmin cannot attach/detach a network from the cluster, the
>>>> motivation for this is that as long as the network is not attached to
>>>> the cluster it is not part of the cluster resources thus can not be
>>>> managed by the cluster administrator.
>>>
>>> I'm not sure above two lines are intuitive to manage (a network admin
>>> can manipulate a cluster, but the cluster admin can't change networks in
>>> the cluster? this means you must give network permissions, at DC level,
>>> so you can't limit an admin to network attach/detach to a specific cluster.
>>>
>>
>> That is true but looking on the alternative I think it make sense.
>> The alternative is to require two permissions for attaching a network to
>> a cluster one is networkAdmin (for editing network properties) on a
>> network and the other is networkAttach (a separate Role?) on a cluster
>> or the DC (if you want the user to be able to add the network for all
>> the clusters in the DC).
>> While I think the common use case is that a network administrator will
>> be able to attach the network to all the clusters I find the above
>> cumbersome and rather stick to the approach that you need only a single
>> permission and you can't limit the network manager to specific cluster.
>>
>> I think that if a requirement for limiting the network to specific
>> clusters comes from our users only then we should make the model more
>> strict and require two permissions.
>>
>>
>>>>          The ClusterAdmin can change a network from required to
>>>> non-required for controlling the impact of the network within the
>>>> cluster.
>>>>      For setting or manipulating a network on the host you need to be
>>>> host administrator on the host and you don't need to be network
>>>> administrator.
>>>>
>>>> User
>>>>
>>>>      For attaching a network to a Vnic in the VM you need to have the
>>>> role of VmNetworkUser on the network and VmAdmin on the VM.
>>>
>>> again, roles are just default roles, please specify the actual
>>> permission (actiongroup)
>>
>> take a look in the wiki for exact details (which role is composed out of
>> which action groups)
>>>
>>>>      In user portal - the list of shown network for a user will include
>>>> only the list of networks the user is allowed to attach to its vnics
>>>> (instead of all cluster's networks).
>>>
>>> or attached to user VMs.
>>> and need to handle case of network attached to template but user has no
>>> permission to that network?
>>>
>>
>> Interesting point, I think that if a user has permission to create a VM
>> from a specific template we should give him permission to use the
>> template networks on this VM implicitly upon the VM creation.
>>
>> I noticed the wiki page is missing which permission should be given to
>> users on which networks/VMs during upgrade - Moti?
>>
>
> Added:
>
> * '''VmNetworkUser''' role will be given to the user on each network
> attached to the VM/Template.
> * '''AdvancedVmNetworkUser''' role will be given to the user on each
> network attached to the VM with port-mirroring enabled.

Hi Moti,

I'm not sure what you mean by 'give to the user'.
if the VM has the permission, it doesn't mean the user should get it as 
well, it only means user should be able to see networks their VM have 
associated with.

can you please elaborate more.

Thanks,
   Itamar


From lpeer at redhat.com  Tue Nov 13 13:37:34 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Tue, 13 Nov 2012 15:37:34 +0200
Subject: [Engine-devel] Managing permissions on network
In-Reply-To: <50A248E8.10504@redhat.com>
References: <50991728.8070702@redhat.com> <50A20B7D.8000401@redhat.com>
	<50A224AD.60205@redhat.com> <50A248E8.10504@redhat.com>
Message-ID: <50A24D1E.8070906@redhat.com>

On 13/11/12 15:19, Itamar Heim wrote:
> On 11/13/2012 12:45 PM, Livnat Peer wrote:
>> Interesting point, I think that if a user has permission to create a VM
>> from a specific template we should give him permission to use the
>> template networks on this VM implicitly upon the VM creation.
> 
> having a permission to a template does not mean a permission to the
> default network of that VM, especially as we'll use templates more as
> instance types.

Another alternative is to require permission on the network as well as
the template.
I must say I don't really like it, although I agree with your comment,
we require too many operations for enabling a user to create a VM from
template (permission on the template, quota on the storage, permissions
on the network, next we'll require a PHD ;)).

Anyone has a better idea?

Livnat


From iheim at redhat.com  Tue Nov 13 13:39:45 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 13 Nov 2012 15:39:45 +0200
Subject: [Engine-devel] Managing permissions on network
In-Reply-To: <50A24D1E.8070906@redhat.com>
References: <50991728.8070702@redhat.com> <50A20B7D.8000401@redhat.com>
	<50A224AD.60205@redhat.com> <50A248E8.10504@redhat.com>
	<50A24D1E.8070906@redhat.com>
Message-ID: <50A24DA1.2030909@redhat.com>

On 11/13/2012 03:37 PM, Livnat Peer wrote:
> On 13/11/12 15:19, Itamar Heim wrote:
>> On 11/13/2012 12:45 PM, Livnat Peer wrote:
>>> Interesting point, I think that if a user has permission to create a VM
>>> from a specific template we should give him permission to use the
>>> template networks on this VM implicitly upon the VM creation.
>>
>> having a permission to a template does not mean a permission to the
>> default network of that VM, especially as we'll use templates more as
>> instance types.
>
> Another alternative is to require permission on the network as well as
> the template.
> I must say I don't really like it, although I agree with your comment,
> we require too many operations for enabling a user to create a VM from
> template (permission on the template, quota on the storage, permissions
> on the network, next we'll require a PHD ;)).
>
> Anyone has a better idea?

I assume most networks would be given either to 'everyone' or groups of 
users, not per user (and if the network is per user/tenant, then it must 
be done per user.
i may not remember correctly, but i thought when giving quota to user we 
also give some permissions with it (on cluster and storage)?


From masayag at redhat.com  Tue Nov 13 13:41:08 2012
From: masayag at redhat.com (Moti Asayag)
Date: Tue, 13 Nov 2012 15:41:08 +0200
Subject: [Engine-devel] Managing permissions on network
In-Reply-To: <50A248E8.10504@redhat.com>
References: <50991728.8070702@redhat.com> <50A20B7D.8000401@redhat.com>
	<50A224AD.60205@redhat.com> <50A248E8.10504@redhat.com>
Message-ID: <50A24DF4.9050202@redhat.com>

On 11/13/2012 03:19 PM, Itamar Heim wrote:
> On 11/13/2012 12:45 PM, Livnat Peer wrote:
>> Interesting point, I think that if a user has permission to create a VM
>> from a specific template we should give him permission to use the
>> template networks on this VM implicitly upon the VM creation.
> 
> having a permission to a template does not mean a permission to the
> default network of that VM, especially as we'll use templates more as
> instance types.

If a user is the template's owner he should be capable to modify the its
nics. I'd expect the user will modify the networks of the template only
if he has permissions for the required network.
Else, a user can update the template's nics to any of cluster's network
and to create a VM with a network the user doesn't suppose to use.

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



From iheim at redhat.com  Tue Nov 13 13:42:54 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 13 Nov 2012 15:42:54 +0200
Subject: [Engine-devel] Managing permissions on network
In-Reply-To: <50A24DF4.9050202@redhat.com>
References: <50991728.8070702@redhat.com> <50A20B7D.8000401@redhat.com>
	<50A224AD.60205@redhat.com> <50A248E8.10504@redhat.com>
	<50A24DF4.9050202@redhat.com>
Message-ID: <50A24E5E.4040107@redhat.com>

On 11/13/2012 03:41 PM, Moti Asayag wrote:
> On 11/13/2012 03:19 PM, Itamar Heim wrote:
>> On 11/13/2012 12:45 PM, Livnat Peer wrote:
>>> Interesting point, I think that if a user has permission to create a VM
>>> from a specific template we should give him permission to use the
>>> template networks on this VM implicitly upon the VM creation.
>>
>> having a permission to a template does not mean a permission to the
>> default network of that VM, especially as we'll use templates more as
>> instance types.
>
> If a user is the template's owner he should be capable to modify the its
> nics. I'd expect the user will modify the networks of the template only
> if he has permissions for the required network.

true.

> Else, a user can update the template's nics to any of cluster's network
> and to create a VM with a network the user doesn't suppose to use.

template having a default network doesn't mean user can create a vm with 
that network as well, if user doesn't have a permission to that network.



From masayag at redhat.com  Tue Nov 13 13:56:57 2012
From: masayag at redhat.com (Moti Asayag)
Date: Tue, 13 Nov 2012 15:56:57 +0200
Subject: [Engine-devel] Managing permissions on network
In-Reply-To: <50A2496B.1030004@redhat.com>
References: <50991728.8070702@redhat.com> <50A20B7D.8000401@redhat.com>
	<50A224AD.60205@redhat.com> <50A2485E.8060403@redhat.com>
	<50A2496B.1030004@redhat.com>
Message-ID: <50A251A9.1060101@redhat.com>

On 11/13/2012 03:21 PM, Itamar Heim wrote:
> On 11/13/2012 03:17 PM, Moti Asayag wrote:
>> On 11/13/2012 12:45 PM, Livnat Peer wrote:
>>> On 13/11/12 10:57, Itamar Heim wrote:
>>>> On 11/06/2012 02:56 PM, Livnat Peer wrote:
>>>>> Hi All,
>>>>>
>>>>> This is a proposal for handling network permissions in oVirt.
>>>>>
>>>>> In this proposal we took the more permissive approach as we find it
>>>>> simple and a good starting point, we also think a more restrict
>>>>> approach
>>>>> makes the configuration of a network cumbersome for ovirt
>>>>> administrators.
>>>>>
>>>>> Inputs are welcomed as always...
>>>>>
>>>>> Here is an overview of the approach, for more detailed description
>>>>> please read the wiki page:
>>>>> http://wiki.ovirt.org/wiki/Feature/NetworkPermissions
>>>>>
>>>>
>>>>
>>>>> High Level Feature Description
>>>>> Admin
>>>>>
>>>>>      For creating a network in a DC you need to be SuperUser or
>>>>> DataCenterAdmin or NetworkAdmin on the DC.
>>>>
>>>> since there are multiple permissions among the differnet roles, maybe
>>>> worth specifying the actual permissions (actiongroups), rather than
>>>> just
>>>> the roles?
>>>>
>>>
>>> you can find this info in the wiki page itself,this is only high level
>>> summary.
>>>
>>>>>      After creating the network you can manipulate the network if you
>>>>> are a DataCenterAdmin or NetworkAdmin on the relevant network (or the
>>>>> whole DC).
>>>>>      For attaching the network to cluster user needs to be
>>>>> NetworkAdmin
>>>>> on the network (no requirement to have permission on the cluster)
>>>>>      ClusterAdmin cannot attach/detach a network from the cluster, the
>>>>> motivation for this is that as long as the network is not attached to
>>>>> the cluster it is not part of the cluster resources thus can not be
>>>>> managed by the cluster administrator.
>>>>
>>>> I'm not sure above two lines are intuitive to manage (a network admin
>>>> can manipulate a cluster, but the cluster admin can't change
>>>> networks in
>>>> the cluster? this means you must give network permissions, at DC level,
>>>> so you can't limit an admin to network attach/detach to a specific
>>>> cluster.
>>>>
>>>
>>> That is true but looking on the alternative I think it make sense.
>>> The alternative is to require two permissions for attaching a network to
>>> a cluster one is networkAdmin (for editing network properties) on a
>>> network and the other is networkAttach (a separate Role?) on a cluster
>>> or the DC (if you want the user to be able to add the network for all
>>> the clusters in the DC).
>>> While I think the common use case is that a network administrator will
>>> be able to attach the network to all the clusters I find the above
>>> cumbersome and rather stick to the approach that you need only a single
>>> permission and you can't limit the network manager to specific cluster.
>>>
>>> I think that if a requirement for limiting the network to specific
>>> clusters comes from our users only then we should make the model more
>>> strict and require two permissions.
>>>
>>>
>>>>>          The ClusterAdmin can change a network from required to
>>>>> non-required for controlling the impact of the network within the
>>>>> cluster.
>>>>>      For setting or manipulating a network on the host you need to be
>>>>> host administrator on the host and you don't need to be network
>>>>> administrator.
>>>>>
>>>>> User
>>>>>
>>>>>      For attaching a network to a Vnic in the VM you need to have the
>>>>> role of VmNetworkUser on the network and VmAdmin on the VM.
>>>>
>>>> again, roles are just default roles, please specify the actual
>>>> permission (actiongroup)
>>>
>>> take a look in the wiki for exact details (which role is composed out of
>>> which action groups)
>>>>
>>>>>      In user portal - the list of shown network for a user will
>>>>> include
>>>>> only the list of networks the user is allowed to attach to its vnics
>>>>> (instead of all cluster's networks).
>>>>
>>>> or attached to user VMs.
>>>> and need to handle case of network attached to template but user has no
>>>> permission to that network?
>>>>
>>>
>>> Interesting point, I think that if a user has permission to create a VM
>>> from a specific template we should give him permission to use the
>>> template networks on this VM implicitly upon the VM creation.
>>>
>>> I noticed the wiki page is missing which permission should be given to
>>> users on which networks/VMs during upgrade - Moti?
>>>
>>
>> Added:
>>
>> * '''VmNetworkUser''' role will be given to the user on each network
>> attached to the VM/Template.
>> * '''AdvancedVmNetworkUser''' role will be given to the user on each
>> network attached to the VM with port-mirroring enabled.
> 
> Hi Moti,
> 
> I'm not sure what you mean by 'give to the user'.
> if the VM has the permission, it doesn't mean the user should get it as
> well, it only means user should be able to see networks their VM have
> associated with.
> 
> can you please elaborate more.

The role 'VmNetworkUser' is consist of action group 'CONFIGURE_VM_NETWORK':
 - AddVmInterface
 - RemoveVmInterface
 - UpdateVmInterface
 - ActivateDeactivateVmNic

If the user already have a role that contains 'CONFIGURE_VM_NETWORK'
action group, he should be granted with 'VmNetworkUser' role on the
networks of that VMs for parity.

Else, the actions he was able to perform will not be available to him
any more.

However, he won't be able to create/update nics with networks that
weren't already attached to the VM, and those will require an explicit
permission.

> 
> Thanks,
>   Itamar



From iheim at redhat.com  Tue Nov 13 13:59:33 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 13 Nov 2012 15:59:33 +0200
Subject: [Engine-devel] Managing permissions on network
In-Reply-To: <50A251A9.1060101@redhat.com>
References: <50991728.8070702@redhat.com> <50A20B7D.8000401@redhat.com>
	<50A224AD.60205@redhat.com> <50A2485E.8060403@redhat.com>
	<50A2496B.1030004@redhat.com> <50A251A9.1060101@redhat.com>
Message-ID: <50A25245.1050605@redhat.com>

On 11/13/2012 03:56 PM, Moti Asayag wrote:
> On 11/13/2012 03:21 PM, Itamar Heim wrote:
>> On 11/13/2012 03:17 PM, Moti Asayag wrote:
>>> On 11/13/2012 12:45 PM, Livnat Peer wrote:
>>>> On 13/11/12 10:57, Itamar Heim wrote:
>>>>> On 11/06/2012 02:56 PM, Livnat Peer wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> This is a proposal for handling network permissions in oVirt.
>>>>>>
>>>>>> In this proposal we took the more permissive approach as we find it
>>>>>> simple and a good starting point, we also think a more restrict
>>>>>> approach
>>>>>> makes the configuration of a network cumbersome for ovirt
>>>>>> administrators.
>>>>>>
>>>>>> Inputs are welcomed as always...
>>>>>>
>>>>>> Here is an overview of the approach, for more detailed description
>>>>>> please read the wiki page:
>>>>>> http://wiki.ovirt.org/wiki/Feature/NetworkPermissions
>>>>>>
>>>>>
>>>>>
>>>>>> High Level Feature Description
>>>>>> Admin
>>>>>>
>>>>>>       For creating a network in a DC you need to be SuperUser or
>>>>>> DataCenterAdmin or NetworkAdmin on the DC.
>>>>>
>>>>> since there are multiple permissions among the differnet roles, maybe
>>>>> worth specifying the actual permissions (actiongroups), rather than
>>>>> just
>>>>> the roles?
>>>>>
>>>>
>>>> you can find this info in the wiki page itself,this is only high level
>>>> summary.
>>>>
>>>>>>       After creating the network you can manipulate the network if you
>>>>>> are a DataCenterAdmin or NetworkAdmin on the relevant network (or the
>>>>>> whole DC).
>>>>>>       For attaching the network to cluster user needs to be
>>>>>> NetworkAdmin
>>>>>> on the network (no requirement to have permission on the cluster)
>>>>>>       ClusterAdmin cannot attach/detach a network from the cluster, the
>>>>>> motivation for this is that as long as the network is not attached to
>>>>>> the cluster it is not part of the cluster resources thus can not be
>>>>>> managed by the cluster administrator.
>>>>>
>>>>> I'm not sure above two lines are intuitive to manage (a network admin
>>>>> can manipulate a cluster, but the cluster admin can't change
>>>>> networks in
>>>>> the cluster? this means you must give network permissions, at DC level,
>>>>> so you can't limit an admin to network attach/detach to a specific
>>>>> cluster.
>>>>>
>>>>
>>>> That is true but looking on the alternative I think it make sense.
>>>> The alternative is to require two permissions for attaching a network to
>>>> a cluster one is networkAdmin (for editing network properties) on a
>>>> network and the other is networkAttach (a separate Role?) on a cluster
>>>> or the DC (if you want the user to be able to add the network for all
>>>> the clusters in the DC).
>>>> While I think the common use case is that a network administrator will
>>>> be able to attach the network to all the clusters I find the above
>>>> cumbersome and rather stick to the approach that you need only a single
>>>> permission and you can't limit the network manager to specific cluster.
>>>>
>>>> I think that if a requirement for limiting the network to specific
>>>> clusters comes from our users only then we should make the model more
>>>> strict and require two permissions.
>>>>
>>>>
>>>>>>           The ClusterAdmin can change a network from required to
>>>>>> non-required for controlling the impact of the network within the
>>>>>> cluster.
>>>>>>       For setting or manipulating a network on the host you need to be
>>>>>> host administrator on the host and you don't need to be network
>>>>>> administrator.
>>>>>>
>>>>>> User
>>>>>>
>>>>>>       For attaching a network to a Vnic in the VM you need to have the
>>>>>> role of VmNetworkUser on the network and VmAdmin on the VM.
>>>>>
>>>>> again, roles are just default roles, please specify the actual
>>>>> permission (actiongroup)
>>>>
>>>> take a look in the wiki for exact details (which role is composed out of
>>>> which action groups)
>>>>>
>>>>>>       In user portal - the list of shown network for a user will
>>>>>> include
>>>>>> only the list of networks the user is allowed to attach to its vnics
>>>>>> (instead of all cluster's networks).
>>>>>
>>>>> or attached to user VMs.
>>>>> and need to handle case of network attached to template but user has no
>>>>> permission to that network?
>>>>>
>>>>
>>>> Interesting point, I think that if a user has permission to create a VM
>>>> from a specific template we should give him permission to use the
>>>> template networks on this VM implicitly upon the VM creation.
>>>>
>>>> I noticed the wiki page is missing which permission should be given to
>>>> users on which networks/VMs during upgrade - Moti?
>>>>
>>>
>>> Added:
>>>
>>> * '''VmNetworkUser''' role will be given to the user on each network
>>> attached to the VM/Template.
>>> * '''AdvancedVmNetworkUser''' role will be given to the user on each
>>> network attached to the VM with port-mirroring enabled.
>>
>> Hi Moti,
>>
>> I'm not sure what you mean by 'give to the user'.
>> if the VM has the permission, it doesn't mean the user should get it as
>> well, it only means user should be able to see networks their VM have
>> associated with.
>>
>> can you please elaborate more.
>
> The role 'VmNetworkUser' is consist of action group 'CONFIGURE_VM_NETWORK':
>   - AddVmInterface
>   - RemoveVmInterface
>   - UpdateVmInterface
>   - ActivateDeactivateVmNic
>
> If the user already have a role that contains 'CONFIGURE_VM_NETWORK'
> action group, he should be granted with 'VmNetworkUser' role on the
> networks of that VMs for parity.
>
> Else, the actions he was able to perform will not be available to him
> any more.
>
> However, he won't be able to create/update nics with networks that
> weren't already attached to the VM, and those will require an explicit
> permission.
>
>>
>> Thanks,
>>    Itamar
>

ok, please note from user api filtering aspect, i don't have to have any 
permission to the network, to be able to see it, if i have a VM with 
that network (i.e., I'm just a VmUser).
i would still not be able to associate it with another VM which i may be 
admin of.


From masayag at redhat.com  Tue Nov 13 14:04:40 2012
From: masayag at redhat.com (Moti Asayag)
Date: Tue, 13 Nov 2012 16:04:40 +0200
Subject: [Engine-devel] Managing permissions on network
In-Reply-To: <50A24E5E.4040107@redhat.com>
References: <50991728.8070702@redhat.com> <50A20B7D.8000401@redhat.com>
	<50A224AD.60205@redhat.com> <50A248E8.10504@redhat.com>
	<50A24DF4.9050202@redhat.com> <50A24E5E.4040107@redhat.com>
Message-ID: <50A25378.5030404@redhat.com>

On 11/13/2012 03:42 PM, Itamar Heim wrote:
> On 11/13/2012 03:41 PM, Moti Asayag wrote:
>> On 11/13/2012 03:19 PM, Itamar Heim wrote:
>>> On 11/13/2012 12:45 PM, Livnat Peer wrote:
>>>> Interesting point, I think that if a user has permission to create a VM
>>>> from a specific template we should give him permission to use the
>>>> template networks on this VM implicitly upon the VM creation.
>>>
>>> having a permission to a template does not mean a permission to the
>>> default network of that VM, especially as we'll use templates more as
>>> instance types.
>>
>> If a user is the template's owner he should be capable to modify the its
>> nics. I'd expect the user will modify the networks of the template only
>> if he has permissions for the required network.
> 
> true.
> 
>> Else, a user can update the template's nics to any of cluster's network
>> and to create a VM with a network the user doesn't suppose to use.
> 
> template having a default network doesn't mean user can create a vm with
> that network as well, if user doesn't have a permission to that network.
> 

In that case, no permissions will be granted to template's user on upgrade.


From alkaplan at redhat.com  Tue Nov 13 14:46:52 2012
From: alkaplan at redhat.com (Alona Kaplan)
Date: Tue, 13 Nov 2012 09:46:52 -0500 (EST)
Subject: [Engine-devel] Network Wiring
In-Reply-To: <2134410552.1076243.1352814421243.JavaMail.root@redhat.com>
Message-ID: <999476552.1216069.1352818012177.JavaMail.root@redhat.com>

Hi all,

Please review the wiki and add your comments.

http://wiki.ovirt.org/wiki/Feature/NetworkWiring


Thanks,
Alona.


From emesika at redhat.com  Tue Nov 13 16:18:27 2012
From: emesika at redhat.com (Eli Mesika)
Date: Tue, 13 Nov 2012 11:18:27 -0500 (EST)
Subject: [Engine-devel] MOM [DR for 3.2] Host Power Management Proxy
	Preferences
Message-ID: <887538074.10095557.1352823507006.JavaMail.root@redhat.com>

Hi

DR MOM : http://wiki.ovirt.org/wiki/Talk:HostPMProxyPreferences

Requirements Page : http://wiki.ovirt.org/wiki/Features/HostPMProxyPreferences
DR                : http://wiki.ovirt.org/wiki/Features/Design/DetailedHostPMProxyPreferences


From satimis at yahoo.com  Tue Nov 13 16:20:46 2012
From: satimis at yahoo.com (Stephen Liu)
Date: Tue, 13 Nov 2012 08:20:46 -0800 (PST)
Subject: [Engine-devel] Building oVirt from source
Message-ID: <1352823646.4124.YahooMailNeo@web125104.mail.ne1.yahoo.com>

Hi all,

Have another round to build oVirt from source following;

Building Engine Draft
http://wiki.ovirt.org/wiki/Building_Engine_Draft

OS - Fedora 17 desktop 64bit, fresh and clean installed.

Not much problem encountered up to "Installing JBoss AS" except follows:

1)
Maven personal settings
==================

$ mkdir $HOME/.m2 
$ wget -O $HOME/.m2/settings.xml http://wiki.ovirt.org/w/images/1/18/Settings.xml.png

(it should read "http://wiki.ovirt.org/w/images/1/18/Settings.xml.png")
??????????????????? ? ? ? ? ? ? ?? ^^^^ (not www)

2)
Check that the application server starts correctly: 

$ cd $JBOSS_HOME/bin
$
 ./standalone.sh -b 0.0.0.0
===================================================

? JBoss Bootstrap Environment

? JBOSS_HOME: /home/satimis/jboss-as

? JAVA: java

?
 JAVA_OPTS:? -server -XX:+UseCompressedOops -XX:+TieredCompilation 
-Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true 
-Dorg.jboss.resolver.warning=true 
-Dsun.rmi.dgc.client.gcInterval=3600000 
-Dsun.rmi.dgc.server.gcInterval=3600000 
-Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=tr
....
.....

22:14:38,217
 INFO? [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 
7.1.1.Final "Brontes" started in 6662ms - Started 133 of 208 services 
(74 services are passive or on-demand)


It hung here;

Press [Ctrl] + c
it continued to display:

19:49,653 INFO? [org.jboss.as.osgi] (MSC service thread 1-3) JBAS011942: Stopping OSGi Framework
22:19:49,701 INFO?
 [org.jboss.as.logging] JBAS011503: Restored bootstrap log handlers
22:19:49,726 INFO? [org.apache.coyote.http11.Http11Protocol] Pausing Coyote HTTP/1.1 on http--0.0.0.0-8080
22:19:49,727 INFO? [org.apache.coyote.http11.Http11Protocol] Stopping Coyote HTTP/1.1 on http--0.0.0.0-8080
22:19:49,729 INFO? [com.arjuna.ats.jbossatx] ARJUNA032018: Destroying TransactionManagerService
22:19:49,730 INFO? [com.arjuna.ats.jbossatx] ARJUNA032014: Stopping transaction recovery manager
22:19:49,753 INFO? [org.jboss.as] JBAS015950: JBoss AS 7.1.1.Final "Brontes" stopped in 111ms

Is it normal?? Without problem?

Thanks

B.R.
Stephen L
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121113/56af71d0/attachment.html>

From lpeer at redhat.com  Tue Nov 13 17:18:28 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Tue, 13 Nov 2012 19:18:28 +0200
Subject: [Engine-devel] Managing permissions on network
In-Reply-To: <50A24DA1.2030909@redhat.com>
References: <50991728.8070702@redhat.com> <50A20B7D.8000401@redhat.com>
	<50A224AD.60205@redhat.com> <50A248E8.10504@redhat.com>
	<50A24D1E.8070906@redhat.com> <50A24DA1.2030909@redhat.com>
Message-ID: <50A280E4.5010000@redhat.com>

On 13/11/12 15:39, Itamar Heim wrote:
> On 11/13/2012 03:37 PM, Livnat Peer wrote:
>> On 13/11/12 15:19, Itamar Heim wrote:
>>> On 11/13/2012 12:45 PM, Livnat Peer wrote:
>>>> Interesting point, I think that if a user has permission to create a VM
>>>> from a specific template we should give him permission to use the
>>>> template networks on this VM implicitly upon the VM creation.
>>>
>>> having a permission to a template does not mean a permission to the
>>> default network of that VM, especially as we'll use templates more as
>>> instance types.
>>
>> Another alternative is to require permission on the network as well as
>> the template.
>> I must say I don't really like it, although I agree with your comment,
>> we require too many operations for enabling a user to create a VM from
>> template (permission on the template, quota on the storage, permissions
>> on the network, next we'll require a PHD ;)).
>>
>> Anyone has a better idea?
> 
> I assume most networks would be given either to 'everyone' or groups of
> users, not per user (and if the network is per user/tenant, then it must
> be done per user.

Which reminds that I wanted to propose adding a property on a network
which is called public.
It's just a UI feature to give a NetworkUser on this network to
'everyone'. It makes making a network public easier for the user.

In addition during upgrade we should make all existing networks public
networks and not allocate specific permissions for users on networks.

In addition it also means a user is given permission on a network and
then he can use it for any VM he owns. Isn't that problematic? We can't
limit a user to use a network on a specific VM.

> i may not remember correctly, but i thought when giving quota to user we
> also give some permissions with it (on cluster and storage)?

I am not sure what is the current implementation as it changed a lot,
but last I tracked we checked for either quota or permissions we did not
give implicit permissions when creating a quota.



From simon at redhat.com  Tue Nov 13 17:58:01 2012
From: simon at redhat.com (Simon Grinberg)
Date: Tue, 13 Nov 2012 12:58:01 -0500 (EST)
Subject: [Engine-devel] Network Wiring
In-Reply-To: <999476552.1216069.1352818012177.JavaMail.root@redhat.com>
Message-ID: <12967320.548.1352829479334.JavaMail.javamailuser@localhost>

>From the summary:
"...It supports the following actions without unplugging the Vnic, and it maintains the device address of the Vnic ...."

But in the dialogue section:
"If the Vnic is plugged there should be a message on top of the dialog "Please notice, changing Type or MAC will cause unplugging and plugging the Vnic" 

Looking at the detailed design indeed any change indeed goes through plug/unplug.
Please correct me if I got the above wrong. 

To support real live rewire == "Move a card from one network to another" 
The sequence should be for wired-plugged card: 
- Unwire
- Change network 
- Rewire 

I would argue that we should actually force the user to perform these steps, but we can do it in one go.

Any other state may change network freely.

To change name - it's just DB, so any state goes 

To change type or MAC address (= property), must go through unplug regardless to the wired state 
So:
- Unplug 
- Change property 
- Plug 

Again should probably ask the user to do these 3 steps so he'll know what he is doing, but we can do it for him with proper warning.

I also wander I do we have to drop the PCI address in the persisted table in this case - loosing the PCI location is redundant and will cause a move to another eth0 number in the guest. On the other hand changing of MAC may break network scripts anyhow - so I don't have a strong argument to keep it. 


Another issue:
If the nic is there to be use by a hook, then you probably want to allow 'none' network.
This may also be useful when allowing to purge a network while it is connected to VMs: unwire on all nics and connect to the none network.


Overall, looking great, and I like the wired vs unplugged that emulate real behavior. 

Regards, 
Simon


 







----- Original Message -----
> From: "Alona Kaplan" <alkaplan at redhat.com>
> To: engine-devel at ovirt.org, "Simon Grinberg" <sgrinber at redhat.com>, rhevm-qe-network at redhat.com
> Sent: Tuesday, November 13, 2012 4:46:52 PM
> Subject: Network Wiring
> 
> Hi all,
> 
> Please review the wiki and add your comments.
> 
> http://wiki.ovirt.org/wiki/Feature/NetworkWiring
> 
> 
> Thanks,
> Alona.
> 


From iheim at redhat.com  Tue Nov 13 18:19:01 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 13 Nov 2012 20:19:01 +0200
Subject: [Engine-devel] Managing permissions on network
In-Reply-To: <50A280E4.5010000@redhat.com>
References: <50991728.8070702@redhat.com> <50A20B7D.8000401@redhat.com>
	<50A224AD.60205@redhat.com> <50A248E8.10504@redhat.com>
	<50A24D1E.8070906@redhat.com> <50A24DA1.2030909@redhat.com>
	<50A280E4.5010000@redhat.com>
Message-ID: <50A28F15.8010603@redhat.com>

On 11/13/2012 07:18 PM, Livnat Peer wrote:
> On 13/11/12 15:39, Itamar Heim wrote:
>> On 11/13/2012 03:37 PM, Livnat Peer wrote:
>>> On 13/11/12 15:19, Itamar Heim wrote:
>>>> On 11/13/2012 12:45 PM, Livnat Peer wrote:
>>>>> Interesting point, I think that if a user has permission to create a VM
>>>>> from a specific template we should give him permission to use the
>>>>> template networks on this VM implicitly upon the VM creation.
>>>>
>>>> having a permission to a template does not mean a permission to the
>>>> default network of that VM, especially as we'll use templates more as
>>>> instance types.
>>>
>>> Another alternative is to require permission on the network as well as
>>> the template.
>>> I must say I don't really like it, although I agree with your comment,
>>> we require too many operations for enabling a user to create a VM from
>>> template (permission on the template, quota on the storage, permissions
>>> on the network, next we'll require a PHD ;)).
>>>
>>> Anyone has a better idea?
>>
>> I assume most networks would be given either to 'everyone' or groups of
>> users, not per user (and if the network is per user/tenant, then it must
>> be done per user.
>
> Which reminds that I wanted to propose adding a property on a network
> which is called public.
> It's just a UI feature to give a NetworkUser on this network to
> 'everyone'. It makes making a network public easier for the user.
>
> In addition during upgrade we should make all existing networks public
> networks and not allocate specific permissions for users on networks.
>
> In addition it also means a user is given permission on a network and
> then he can use it for any VM he owns. Isn't that problematic? We can't
> limit a user to use a network on a specific VM.

I think that's fine.
don't let user edit that vm if you don't trust them.

>
>> i may not remember correctly, but i thought when giving quota to user we
>> also give some permissions with it (on cluster and storage)?
>
> I am not sure what is the current implementation as it changed a lot,
> but last I tracked we checked for either quota or permissions we did not
> give implicit permissions when creating a quota.
>

gilad/doron?


From masayag at redhat.com  Tue Nov 13 19:55:22 2012
From: masayag at redhat.com (Moti Asayag)
Date: Tue, 13 Nov 2012 21:55:22 +0200
Subject: [Engine-devel] Network Wiring
In-Reply-To: <12967320.548.1352829479334.JavaMail.javamailuser@localhost>
References: <12967320.548.1352829479334.JavaMail.javamailuser@localhost>
Message-ID: <50A2A5AA.9050302@redhat.com>

On 11/13/2012 07:58 PM, Simon Grinberg wrote:
> From the summary:
> "...It supports the following actions without unplugging the Vnic, and it maintains the device address of the Vnic ...."
> 
> But in the dialogue section:
> "If the Vnic is plugged there should be a message on top of the dialog "Please notice, changing Type or MAC will cause unplugging and plugging the Vnic" 
> 
> Looking at the detailed design indeed any change indeed goes through plug/unplug.
> Please correct me if I got the above wrong. 

Changing the network (rewiring network) is done using new API with VDSM,
updateVmInteface.

Therefore plug/unplug won't be executed for any of:
1. Changing the network to other network or disconnecting/unwiring it).
2. Update the name of the VM (db only).

Other changes to VM properties (i.e. MAC address, driver type) will
require the plug/unplug. Same goes to any explicit 'unplug' command.

> 
> To support real live rewire == "Move a card from one network to another" 
> The sequence should be for wired-plugged card: 
> - Unwire
> - Change network 
> - Rewire 
> 
> I would argue that we should actually force the user to perform these steps, but we can do it in one go.

The intention is to use the new API VDSM.libvirtVm.updateVmInteface for
performing the network rewire in a single command.

> 
> Any other state may change network freely.
> 
> To change name - it's just DB, so any state goes 
> 
> To change type or MAC address (= property), must go through unplug regardless to the wired state 
> So:
> - Unplug 
> - Change property 
> - Plug 
> 
> Again should probably ask the user to do these 3 steps so he'll know what he is doing, but we can do it for him with proper warning.
> 
> I also wander I do we have to drop the PCI address in the persisted table in this case - loosing the PCI location is redundant and will cause a move to another eth0 number in the guest. On the other hand changing of MAC may break network scripts anyhow - so I don't have a strong argument to keep it. 
> 
> 
> Another issue:
> If the nic is there to be use by a hook, then you probably want to allow 'none' network.
> This may also be useful when allowing to purge a network while it is connected to VMs: unwire on all nics and connect to the none network.
> 
> 
> Overall, looking great, and I like the wired vs unplugged that emulate real behavior. 
> 
> Regards, 
> Simon
> 
> 
>  
> 
> 
> 
> 
> 
> 
> 
> ----- Original Message -----
>> From: "Alona Kaplan" <alkaplan at redhat.com>
>> To: engine-devel at ovirt.org, "Simon Grinberg" <sgrinber at redhat.com>, rhevm-qe-network at redhat.com
>> Sent: Tuesday, November 13, 2012 4:46:52 PM
>> Subject: Network Wiring
>>
>> Hi all,
>>
>> Please review the wiki and add your comments.
>>
>> http://wiki.ovirt.org/wiki/Feature/NetworkWiring
>>
>>
>> Thanks,
>> Alona.
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 



From medievalist at gmail.com  Tue Nov 13 19:57:53 2012
From: medievalist at gmail.com (Charlie)
Date: Tue, 13 Nov 2012 14:57:53 -0500
Subject: [Engine-devel] Managing permissions on network
In-Reply-To: <50A28F15.8010603@redhat.com>
References: <50991728.8070702@redhat.com> <50A20B7D.8000401@redhat.com>
	<50A224AD.60205@redhat.com> <50A248E8.10504@redhat.com>
	<50A24D1E.8070906@redhat.com> <50A24DA1.2030909@redhat.com>
	<50A280E4.5010000@redhat.com> <50A28F15.8010603@redhat.com>
Message-ID: <CAJb3uA5jPnV8thwpDY46dnBby_PS4C3+MiLs9KQAXM+na3tJLw@mail.gmail.com>

Will any of these groups and/or permissions be drawn from LDAP?

Frankly, system admins are not looking for yet another console to
manage permissions.

--Charlie


On Tue, Nov 13, 2012 at 1:19 PM, Itamar Heim <iheim at redhat.com> wrote:
> On 11/13/2012 07:18 PM, Livnat Peer wrote:
>>
>> On 13/11/12 15:39, Itamar Heim wrote:
>>>
>>> On 11/13/2012 03:37 PM, Livnat Peer wrote:
>>>>
>>>> On 13/11/12 15:19, Itamar Heim wrote:
>>>>>
>>>>> On 11/13/2012 12:45 PM, Livnat Peer wrote:
>>>>>>
>>>>>> Interesting point, I think that if a user has permission to create a
>>>>>> VM
>>>>>> from a specific template we should give him permission to use the
>>>>>> template networks on this VM implicitly upon the VM creation.
>>>>>
>>>>>
>>>>> having a permission to a template does not mean a permission to the
>>>>> default network of that VM, especially as we'll use templates more as
>>>>> instance types.
>>>>
>>>>
>>>> Another alternative is to require permission on the network as well as
>>>> the template.
>>>> I must say I don't really like it, although I agree with your comment,
>>>> we require too many operations for enabling a user to create a VM from
>>>> template (permission on the template, quota on the storage, permissions
>>>> on the network, next we'll require a PHD ;)).
>>>>
>>>> Anyone has a better idea?
>>>
>>>
>>> I assume most networks would be given either to 'everyone' or groups of
>>> users, not per user (and if the network is per user/tenant, then it must
>>> be done per user.
>>
>>
>> Which reminds that I wanted to propose adding a property on a network
>> which is called public.
>> It's just a UI feature to give a NetworkUser on this network to
>> 'everyone'. It makes making a network public easier for the user.
>>
>> In addition during upgrade we should make all existing networks public
>> networks and not allocate specific permissions for users on networks.
>>
>> In addition it also means a user is given permission on a network and
>> then he can use it for any VM he owns. Isn't that problematic? We can't
>> limit a user to use a network on a specific VM.
>
>
> I think that's fine.
> don't let user edit that vm if you don't trust them.
>
>
>>
>>> i may not remember correctly, but i thought when giving quota to user we
>>> also give some permissions with it (on cluster and storage)?
>>
>>
>> I am not sure what is the current implementation as it changed a lot,
>> but last I tracked we checked for either quota or permissions we did not
>> give implicit permissions when creating a quota.
>>
>
> gilad/doron?
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel


From Christopher.Morrissey at netapp.com  Tue Nov 13 22:10:14 2012
From: Christopher.Morrissey at netapp.com (Morrissey, Christopher)
Date: Tue, 13 Nov 2012 22:10:14 +0000
Subject: [Engine-devel] Unable to view the storage domains - SQL error
Message-ID: <D290AD8432118048947689BA3AE8A9B3EBA578@SACEXCMBX04-PRD.hq.netapp.com>

Hi All,

I'm getting an error when trying to view the storage domains using the REST API:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<fault>
    <reason>Operation Failed</reason>
    <detail>statementcallback; bad sql grammar [select * from (select * from storage domains for search where ( id in (select storage domains with hosts view.id from storage domains with hosts view )) order by storage name asc ) as t1 offset (1 -1) limit 100]; nested exception is org.postgresql.util.psqlexception: error: relation "storage domains for search" does not exist position: 30</detail>
</fault>

Also, through the web admin console, when viewing the storage domains the list never loads.

Did something change in the DB recently such that I would need to rebuild it?

-Chris

Chris Morrissey
Software Engineer
NetApp Inc.
919.476.4428

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121113/2de52ba3/attachment.html>

From yzaslavs at redhat.com  Wed Nov 14 03:02:17 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Tue, 13 Nov 2012 22:02:17 -0500 (EST)
Subject: [Engine-devel] Unable to view the storage domains - SQL error
In-Reply-To: <D290AD8432118048947689BA3AE8A9B3EBA578@SACEXCMBX04-PRD.hq.netapp.com>
Message-ID: <1533070984.31325703.1352862137082.JavaMail.root@redhat.com>

Hi Christopher, 
In general - as a developer at engine project, I would recommend to run the upgrade script on a frequent basis. 
What troubles me with the query you sent (maybe some problematic copy paste issue?) are the following issues: 
a. storage domains for search - not sure what this is 
b. storage domains with hosts view - I guess you have some underline issue at the copy paste. 

I would appreciate if you attach engine.log (or a part of it that reflects the error you encountered) 

Kind regards, 
Yair 

----- Original Message -----

> From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
> To: engine-devel at ovirt.org
> Sent: Wednesday, November 14, 2012 12:10:14 AM
> Subject: [Engine-devel] Unable to view the storage domains - SQL
> error

> Hi All,

> I?m getting an error when trying to view the storage domains using
> the REST API:

> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> <fault>
> <reason>Operation Failed</reason>
> <detail>statementcallback; bad sql grammar [select * from (select *
> from storage domains for search where ( id in (select storage
> domains with hosts view.id from storage domains with hosts view ))
> order by storage name asc ) as t1 offset (1 -1) limit 100]; nested
> exception is org.postgresql.util.psqlexception: error: relation
> "storage domains for search" does not exist position: 30</detail>
> </fault>

> Also, through the web admin console, when viewing the storage domains
> the list never loads.

> Did something change in the DB recently such that I would need to
> rebuild it?
> -Chris

> Chris Morrissey
> Software Engineer
> NetApp Inc.
> 919.476.4428

> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121113/10ccfe64/attachment.html>

From iheim at redhat.com  Wed Nov 14 04:12:09 2012
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 14 Nov 2012 06:12:09 +0200
Subject: [Engine-devel] Proposal to add Allon Mureinik as maintainer to
	engine core
Message-ID: <50A31A19.7040602@redhat.com>

Allon has worked on oVirt for the past 10 months.
With 534 patches ranging from cleanups, to complex features like user 
level api and storage live migration. In addition, Allon has been 
instrumental in the number of patch reviews he has done.

I'd like to propose Allon as a maintainer of engine core.

Thanks,
    Itamar


From yzaslavs at redhat.com  Wed Nov 14 04:16:52 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Tue, 13 Nov 2012 23:16:52 -0500 (EST)
Subject: [Engine-devel] Proposal to add Allon Mureinik as maintainer
	to	engine core
In-Reply-To: <50A31A19.7040602@redhat.com>
Message-ID: <669761583.31334534.1352866612858.JavaMail.root@redhat.com>

+1

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Wednesday, November 14, 2012 6:12:09 AM
> Subject: [Engine-devel] Proposal to add Allon Mureinik as maintainer to	engine core
> 
> Allon has worked on oVirt for the past 10 months.
> With 534 patches ranging from cleanups, to complex features like user
> level api and storage live migration. In addition, Allon has been
> instrumental in the number of patch reviews he has done.
> 
> I'd like to propose Allon as a maintainer of engine core.
> 
> Thanks,
>     Itamar
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From iheim at redhat.com  Wed Nov 14 04:28:21 2012
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 14 Nov 2012 06:28:21 +0200
Subject: [Engine-devel] Managing permissions on network
In-Reply-To: <CAJb3uA5jPnV8thwpDY46dnBby_PS4C3+MiLs9KQAXM+na3tJLw@mail.gmail.com>
References: <50991728.8070702@redhat.com> <50A20B7D.8000401@redhat.com>
	<50A224AD.60205@redhat.com> <50A248E8.10504@redhat.com>
	<50A24D1E.8070906@redhat.com> <50A24DA1.2030909@redhat.com>
	<50A280E4.5010000@redhat.com> <50A28F15.8010603@redhat.com>
	<CAJb3uA5jPnV8thwpDY46dnBby_PS4C3+MiLs9KQAXM+na3tJLw@mail.gmail.com>
Message-ID: <50A31DE5.2070201@redhat.com>

On 11/13/2012 09:57 PM, Charlie wrote:
> Will any of these groups and/or permissions be drawn from LDAP?
>
> Frankly, system admins are not looking for yet another console to
> manage permissions.

all users/groups come from LDAP.
you just need to give permissions to these groups/users in ovirt.
is that what you meant?

>
> --Charlie
>
>
> On Tue, Nov 13, 2012 at 1:19 PM, Itamar Heim <iheim at redhat.com> wrote:
>> On 11/13/2012 07:18 PM, Livnat Peer wrote:
>>>
>>> On 13/11/12 15:39, Itamar Heim wrote:
>>>>
>>>> On 11/13/2012 03:37 PM, Livnat Peer wrote:
>>>>>
>>>>> On 13/11/12 15:19, Itamar Heim wrote:
>>>>>>
>>>>>> On 11/13/2012 12:45 PM, Livnat Peer wrote:
>>>>>>>
>>>>>>> Interesting point, I think that if a user has permission to create a
>>>>>>> VM
>>>>>>> from a specific template we should give him permission to use the
>>>>>>> template networks on this VM implicitly upon the VM creation.
>>>>>>
>>>>>>
>>>>>> having a permission to a template does not mean a permission to the
>>>>>> default network of that VM, especially as we'll use templates more as
>>>>>> instance types.
>>>>>
>>>>>
>>>>> Another alternative is to require permission on the network as well as
>>>>> the template.
>>>>> I must say I don't really like it, although I agree with your comment,
>>>>> we require too many operations for enabling a user to create a VM from
>>>>> template (permission on the template, quota on the storage, permissions
>>>>> on the network, next we'll require a PHD ;)).
>>>>>
>>>>> Anyone has a better idea?
>>>>
>>>>
>>>> I assume most networks would be given either to 'everyone' or groups of
>>>> users, not per user (and if the network is per user/tenant, then it must
>>>> be done per user.
>>>
>>>
>>> Which reminds that I wanted to propose adding a property on a network
>>> which is called public.
>>> It's just a UI feature to give a NetworkUser on this network to
>>> 'everyone'. It makes making a network public easier for the user.
>>>
>>> In addition during upgrade we should make all existing networks public
>>> networks and not allocate specific permissions for users on networks.
>>>
>>> In addition it also means a user is given permission on a network and
>>> then he can use it for any VM he owns. Isn't that problematic? We can't
>>> limit a user to use a network on a specific VM.
>>
>>
>> I think that's fine.
>> don't let user edit that vm if you don't trust them.
>>
>>
>>>
>>>> i may not remember correctly, but i thought when giving quota to user we
>>>> also give some permissions with it (on cluster and storage)?
>>>
>>>
>>> I am not sure what is the current implementation as it changed a lot,
>>> but last I tracked we checked for either quota or permissions we did not
>>> give implicit permissions when creating a quota.
>>>
>>
>> gilad/doron?
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>




From rgolan at redhat.com  Wed Nov 14 08:47:24 2012
From: rgolan at redhat.com (Roy Golan)
Date: Wed, 14 Nov 2012 10:47:24 +0200
Subject: [Engine-devel] Proposal to add Allon Mureinik as maintainer to
 engine core
In-Reply-To: <50A31A19.7040602@redhat.com>
References: <50A31A19.7040602@redhat.com>
Message-ID: <50A35A9C.7090405@redhat.com>

On 11/14/2012 06:12 AM, Itamar Heim wrote:
> Allon has worked on oVirt for the past 10 months.
> With 534 patches ranging from cleanups, to complex features like user 
> level api and storage live migration. In addition, Allon has been 
> instrumental in the number of patch reviews he has done.
>
> I'd like to propose Allon as a maintainer of engine core.
>
> Thanks,
>    Itamar
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
+1 no doubt


From ovedo at redhat.com  Wed Nov 14 08:54:02 2012
From: ovedo at redhat.com (Oved Ourfalli)
Date: Wed, 14 Nov 2012 03:54:02 -0500 (EST)
Subject: [Engine-devel] Proposal to add Allon Mureinik as maintainer
	to	engine core
In-Reply-To: <50A31A19.7040602@redhat.com>
Message-ID: <1906628668.39175505.1352883242558.JavaMail.root@redhat.com>

+1 on that.
His contribution and help were remarkable in the last few months!

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Wednesday, November 14, 2012 6:12:09 AM
> Subject: [Engine-devel] Proposal to add Allon Mureinik as maintainer to	engine core
> 
> Allon has worked on oVirt for the past 10 months.
> With 534 patches ranging from cleanups, to complex features like user
> level api and storage live migration. In addition, Allon has been
> instrumental in the number of patch reviews he has done.
> 
> I'd like to propose Allon as a maintainer of engine core.
> 
> Thanks,
>     Itamar
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From lhornyak at redhat.com  Wed Nov 14 08:36:16 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Wed, 14 Nov 2012 03:36:16 -0500 (EST)
Subject: [Engine-devel] Building oVirt from source
In-Reply-To: <1352881556.51991.YahooMailNeo@web125101.mail.ne1.yahoo.com>
Message-ID: <310628282.9363428.1352882176738.JavaMail.root@redhat.com>

Hi,

We may have some infrastructure problems. Looks like gerrit is dead as well :(
Does this directory exist?
/usr/share/jboss-as/standalone/deployments/engine.ear/


----- Original Message -----
> From: "Stephen Liu" <satimis at yahoo.com>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, November 14, 2012 9:25:56 AM
> Subject: Re: [Engine-devel] Building oVirt from source
> 
> 
> 
> Hi,
> 
> I have sent another email to the list under the subject: "Deploy
> error again". But it never came to the list:
> 
> Subject : Deploy error again
> 
> Failure:-
> 
> $ mvn clean install -Pdep,setup
> /usr/lib/jvm/java
> [INFO] Scanning for projects...
> [WARNING]
> [WARNING] Some problems were encountered while building the effective
> model for org.ovirt.engine:engine-server-ear:ear:3.1.0
> [WARNING] 'build.plugins.plugin.version' for
> org.apache.maven.plugins:maven-ear-plugin is missing. @ line 154,
> column 15
> [WARNING] 'distributionManagement.repository.id' must not be 'local',
> this identifier is reserved for the local repository, using it for
> other repositories will corrupt your repository metadata. @ line 18,
> column 11
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer
> support building such malformed projects.
> [WARNING]
> [INFO]
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Building oVirt Server EAR 3.1.0
> [INFO]
> ------------------------------------------------------------------------
> Downloading:
> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-antrun-plugin/1.3/maven-antrun-plugin-1.3.pom
> Downloaded:
> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-antrun-plugin/1.3/maven-antrun-plugin-1.3.pom
> (5 KB at 46.7 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-antrun-plugin/1.3/maven-antrun-plugin-1.3.jar
> Downloaded:
> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-antrun-plugin/1.3/maven-antrun-plugin-1.3.jar
> (24 KB at 255.8 KB/sec)
> [INFO]
> [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @
> engine-server-ear ---
> [INFO] Deleting /home/satimis/ovirt-engine/ear/target
> [INFO]
> [INFO] --- maven-antrun-plugin:1.3:run (undeploy) @ engine-server-ear
> ---
> Downloading:
> http://repo1.maven.org/maven2/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.pom
> Downloaded:
> http://repo1.maven.org/maven2/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.pom
> (3 KB at 77.6 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/org/apache/ant/ant-parent/1.7.1/ant-parent-1.7.1.pom
> Downloaded:
> http://repo1.maven.org/maven2/org/apache/ant/ant-parent/1.7.1/ant-parent-1.7.1.pom
> (5 KB at 137.9 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/org/apache/ant/ant/1.7.1/ant-1.7.1.pom
> Downloaded:
> http://repo1.maven.org/maven2/org/apache/ant/ant/1.7.1/ant-1.7.1.pom
> (10 KB at 232.4 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/1.5.6/plexus-utils-1.5.6.jar
> Downloading:
> http://repo1.maven.org/maven2/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.jar
> Downloading:
> http://repo1.maven.org/maven2/org/apache/ant/ant/1.7.1/ant-1.7.1.jar
> Downloaded:
> http://repo1.maven.org/maven2/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.jar
> (12 KB at 79.1 KB/sec)
> Downloaded:
> http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/1.5.6/plexus-utils-1.5.6.jar
> (245 KB at 226.5 KB/sec)
> Downloaded:
> http://repo1.maven.org/maven2/org/apache/ant/ant/1.7.1/ant-1.7.1.jar
> (1292 KB at 384.3 KB/sec)
> [INFO] Executing tasks
> [echo] *** Deleting
> /usr/share/jboss-as/standalone/deployments/engine.ear/...
> [INFO] Executed tasks
> [INFO]
> [INFO] --- maven-ear-plugin:2.6:generate-application-xml
> (default-generate-application-xml) @ engine-server-ear ---
> [INFO] Generating application.xml
> [INFO]
> [INFO] --- maven-resources-plugin:2.4.3:resources (default-resources)
> @ engine-server-ear ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> /home/satimis/ovirt-engine/ear/src/main/java
> [INFO] Copying 1 resource
> [INFO]
> [INFO] --- maven-ear-plugin:2.6:ear (default-ear) @ engine-server-ear
> ---
> [INFO] Copying artifact[jar:org.ovirt.engine.core:common:3.1.0]
> to[lib/engine-common.jar]
> [INFO] Copying artifact[jar:org.ovirt.engine.core:compat:3.1.0]
> to[lib/engine-compat.jar]
> [INFO] Copying artifact[jar:org.ovirt.engine.core:dal:3.1.0]
> to[lib/engine-dal.jar]
> [INFO] Copying artifact[jar:org.ovirt.engine.core:utils:3.1.0]
> to[lib/engine-utils.jar]
> [INFO] Copying
> artifact[jar:org.ovirt.engine.core:engineencryptutils:3.1.0]
> to[lib/engine-encryptutils.jar]
> [INFO] Copying artifact[jar:org.ovirt.engine.core:vdsbroker:3.1.0]
> to[lib/engine-vdsbroker.jar]
> [INFO] Copying artifact[war:org.ovirt.engine.core:root-war:3.1.0]
> to[root.war] (unpacked)
> [INFO] Copying artifact[war:org.ovirt.engine.ui:rmw-war:3.1.0]
> to[ovirtengineweb.war] (unpacked)
> [INFO] Copying
> artifact[war:org.ovirt.engine.api:restapi-webapp:3.1.0]
> to[restapi.war] (unpacked)
> [INFO] Copying artifact[war:org.ovirt.engine.ui:userportal:3.1.0]
> to[userportal.war] (unpacked)
> [INFO] Copying artifact[war:org.ovirt.engine.ui:webadmin:3.1.0]
> to[webadmin.war] (unpacked)
> [INFO] Copying artifact[ejb:org.ovirt.engine.ui:genericapi:3.1.0]
> to[engine-genericapi.jar] (unpacked)
> [INFO] Copying artifact[ejb:org.ovirt.engine.core:scheduler:3.1.0]
> to[engine-scheduler.jar] (unpacked)
> [INFO] Copying artifact[ejb:org.ovirt.engine.core:bll:3.1.0]
> to[engine-bll.jar] (unpacked)
> [INFO] Copying artifact[jar:commons-codec:commons-codec:1.4]
> to[lib/commons-codec-1.4.jar]
> [INFO] Copying
> artifact[jar:org.hibernate:hibernate-validator:4.0.2.GA]
> to[lib/hibernate-validator-4.0.2.GA.jar]
> [INFO] Copying artifact[jar:javax.validation:validation-api:1.0.0.GA]
> to[lib/validation-api-1.0.0.GA.jar]
> [INFO] Copying artifact[jar:org.slf4j:slf4j-api:1.5.6]
> to[lib/slf4j-api-1.5.6.jar]
> [INFO] Copying artifact[jar:javax.xml.bind:jaxb-api:2.1]
> to[lib/jaxb-api-2.1.jar]
> [INFO] Copying artifact[jar:javax.xml.stream:stax-api:1.0-2]
> to[lib/stax-api-1.0-2.jar]
> [INFO] Copying artifact[jar:javax.activation:activation:1.1]
> to[lib/activation-1.1.jar]
> [INFO] Copying artifact[jar:com.sun.xml.bind:jaxb-impl:2.1.3]
> to[lib/jaxb-impl-2.1.3.jar]
> [INFO] Copying
> artifact[jar:org.hibernate:hibernate-annotations:3.4.0.GA]
> to[lib/hibernate-annotations-3.4.0.GA.jar]
> [INFO] Copying artifact[jar:org.hibernate:ejb3-persistence:1.0.2.GA]
> to[lib/ejb3-persistence-1.0.2.GA.jar]
> [INFO] Copying
> artifact[jar:org.hibernate:hibernate-commons-annotations:3.1.0.GA]
> to[lib/hibernate-commons-annotations-3.1.0.GA.jar]
> [INFO] Copying artifact[jar:org.hibernate:hibernate-core:3.3.0.SP1]
> to[lib/hibernate-core-3.3.0.SP1.jar]
> [INFO] Copying artifact[jar:antlr:antlr:2.7.6]
> to[lib/antlr-2.7.6.jar]
> [INFO] Copying artifact[jar:dom4j:dom4j:1.6.1]
> to[lib/dom4j-1.6.1.jar]
> [INFO] Copying artifact[jar:xml-apis:xml-apis:1.0.b2]
> to[lib/xml-apis-1.0.b2.jar]
> [INFO] Copying
> artifact[jar:org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.1_spec:1.0.0.Final]
> to[lib/jboss-interceptors-api_1.1_spec-1.0.0.Final.jar]
> [INFO] Copying
> artifact[jar:org.ovirt.engine.core:engine-tools-common:3.1.0]
> to[lib/engine-tools-common-3.1.0.jar]
> [INFO] Copying
> artifact[jar:commons-beanutils:commons-beanutils:1.8.2]
> to[lib/commons-beanutils-1.8.2.jar]
> [INFO] Copying artifact[jar:org.apache.mina:mina-core:2.0.1]
> to[lib/mina-core-2.0.1.jar]
> [INFO] Copying artifact[jar:org.apache.sshd:sshd-core:0.7.0]
> to[lib/sshd-core-0.7.0.jar]
> [INFO] Copying artifact[jar:org.apache.commons:commons-compress:1.3]
> to[lib/commons-compress-1.3.jar]
> [INFO] Copying artifact[jar:commons-lang:commons-lang:2.4]
> to[lib/commons-lang-2.4.jar]
> [INFO] Copying artifact[jar:org.apache.xmlrpc:xmlrpc-client:3.1.3]
> to[lib/xmlrpc-client-3.1.3.jar]
> [INFO] Copying artifact[jar:org.apache.xmlrpc:xmlrpc-common:3.1.3]
> to[lib/xmlrpc-common-3.1.3.jar]
> [INFO] Copying
> artifact[jar:org.apache.ws.commons.util:ws-commons-util:1.0.2]
> to[lib/ws-commons-util-1.0.2.jar]
> [INFO] Copying
> artifact[jar:org.springframework:spring-jdbc:3.1.1.RELEASE]
> to[lib/spring-jdbc-3.1.1.RELEASE.jar]
> [INFO] Copying
> artifact[jar:org.springframework:spring-tx:3.1.1.RELEASE]
> to[lib/spring-tx-3.1.1.RELEASE.jar]
> [INFO] Copying
> artifact[jar:org.springframework.ldap:spring-ldap-core:1.3.1.RELEASE]
> to[lib/spring-ldap-core-1.3.1.RELEASE.jar]
> [INFO] Copying
> artifact[jar:commons-httpclient:commons-httpclient:3.1]
> to[lib/commons-httpclient-3.1.jar]
> [INFO] Copying
> artifact[jar:commons-collections:commons-collections:3.1]
> to[lib/commons-collections-3.1.jar]
> [INFO] Copying artifact[jar:org.quartz-scheduler:quartz:2.1.2]
> to[lib/quartz-2.1.2.jar]
> [INFO] Copying artifact[jar:c3p0:c3p0:0.9.1.1]
> to[lib/c3p0-0.9.1.1.jar]
> [INFO] Copying
> artifact[jar:org.ovirt.engine.core:searchbackend:3.1.0]
> to[lib/searchbackend-3.1.0.jar]
> [INFO] Copying
> artifact[jar:org.springframework:spring-core:3.1.1.RELEASE]
> to[lib/spring-core-3.1.1.RELEASE.jar]
> [INFO] Copying
> artifact[jar:org.springframework:spring-asm:3.1.1.RELEASE]
> to[lib/spring-asm-3.1.1.RELEASE.jar]
> [INFO] Copying
> artifact[jar:org.springframework:spring-beans:3.1.1.RELEASE]
> to[lib/spring-beans-3.1.1.RELEASE.jar]
> [INFO] Copying
> artifact[jar:org.springframework:spring-context:3.1.1.RELEASE]
> to[lib/spring-context-3.1.1.RELEASE.jar]
> [INFO] Copying
> artifact[jar:org.springframework:spring-aop:3.1.1.RELEASE]
> to[lib/spring-aop-3.1.1.RELEASE.jar]
> [INFO] Copying artifact[jar:aopalliance:aopalliance:1.0]
> to[lib/aopalliance-1.0.jar]
> [INFO] Copying
> artifact[jar:org.springframework:spring-expression:3.1.1.RELEASE]
> to[lib/spring-expression-3.1.1.RELEASE.jar]
> [INFO] Copy ear sources to
> /home/satimis/ovirt-engine/ear/target/engine
> [WARNING] resourcesDir is deprecated. Please use the
> earSourceDirectory property instead.
> [INFO] Copy ear resources to
> /home/satimis/ovirt-engine/ear/target/engine
> [INFO] Including custom manifest
> file[/home/satimis/ovirt-engine/ear/target/engine/META-INF/MANIFEST.MF]
> [INFO] Building jar: /home/satimis/ovirt-engine/ear/target/engine.ear
> [INFO]
> [INFO] --- maven-dependency-plugin:2.1:copy (copy-quartz-jar) @
> engine-server-ear ---
> [INFO] Configured Artifact: org.quartz-scheduler:quartz:2.1.2:jar
> [INFO] Copying quartz-2.1.2.jar to
> /home/satimis/ovirt-engine/ear/target/quartz/quartz-2.1.2.jar
> [INFO]
> [INFO] --- maven-antrun-plugin:1.3:run (deploy) @ engine-server-ear
> ---
> [INFO] Executing tasks
> [echo] *** Copying updated files from target/engine/ to
> /usr/share/jboss-as/standalone/deployments/engine.ear/...
> [copy] Copying 1168 files to
> /usr/share/jboss-as/standalone/deployments/engine.ear
> [copy] Copying
> /home/satimis/ovirt-engine/ear/target/engine/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class
> to
> /usr/share/jboss-as/standalone/deployments/engine.ear/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 15.761s
> [INFO] Finished at: Wed Nov 14 14:34:56 HKT 2012
> [INFO] Final Memory: 16M/295M
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-antrun-plugin:1.3:run (deploy) on
> project engine-server-ear: An Ant BuildException has occured: Failed
> to copy
> /home/satimis/ovirt-engine/ear/target/engine/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class
> to
> /usr/share/jboss-as/standalone/deployments/engine.ear/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class
> due to java.io.FileNotFoundException
> /usr/share/jboss-as/standalone/deployments/engine.ear/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class
> (No such file or directory) -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with
> the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug
> logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> 
> 
> PluginExecutionException
> https://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
> .....
> You should report this problem to the maintainer of the plugin.
> 
> 
> Please help. How to fix this problem and continue?
> 
> TIA
> 
> B.R.
> Stephen L
> 
> 
> 
> 
> 
> 
> 
> From: Laszlo Hornyak <lhornyak at redhat.com>
> To: Stephen Liu <satimis at yahoo.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, November 14, 2012 3:43 PM
> Subject: Re: [Engine-devel] Building oVirt from source
> 
> 
> 
> ----- Original Message -----
> > From: "Stephen Liu" < satimis at yahoo.com >
> > To: engine-devel at ovirt.org
> > Sent: Tuesday, November 13, 2012 5:20:46 PM
> > Subject: [Engine-devel] Building oVirt from source
> > 
> > 
> > 
> > 
> > Hi all,
> > 
> > Have another round to build oVirt from source following;
> > 
> > Building Engine Draft
> > http://wiki.ovirt.org/wiki/Building_Engine_Draft
> > 
> > OS - Fedora 17 desktop 64bit, fresh and clean installed.
> > 
> > Not much problem encountered up to "Installing JBoss AS" except
> > follows:
> > 
> > 1)
> > Maven personal settings
> > ==================
> > 
> > $ mkdir $HOME/.m2
> > $ wget -O $HOME/.m2/settings.xml
> > http://wiki.ovirt.org/w/images/1/18/Settings.xml.png
> > 
> > (it should read
> > " http://wiki.ovirt.org/w/images/1/18/Settings.xml.png ")
> > ^^^^ (not www)
> > 
> > 2)
> > Check that the application server starts correctly:
> > 
> > $ cd $JBOSS_HOME/bin
> > $ ./standalone.sh -b 0.0.0.0
> > ===================================================
> > 
> > JBoss Bootstrap Environment
> > 
> > JBOSS_HOME: /home/satimis/jboss-as
> > 
> > JAVA: java
> > 
> > JAVA_OPTS: -server -XX:+UseCompressedOops -XX:+TieredCompilation
> > -Xms64m -Xmx512m -XX:MaxPermSize=256m
> > -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true
> > -Dsun.rmi.dgc.client.gcInterval=3600000
> > -Dsun.rmi.dgc.server.gcInterval=3600000
> > -Djboss.modules.system.pkgs=org.jboss.byteman
> > -Djava.awt.headless=tr
> > ....
> > .....
> > 
> > 22:14:38,217 INFO [org.jboss.as] (Controller Boot Thread)
> > JBAS015874:
> > JBoss AS 7.1.1.Final "Brontes" started in 6662ms - Started 133 of
> > 208 services (74 services are passive or on-demand)
> 
> So your jboss is started at this point and should e listening on 8080
> for http connections. Is ovirt running?
> If not you should check if it is there in
> standalone/deployments/engine.ear
> Also, see if engine.ear.deployed exists. touch engine.dodeploy to
> kick jboss and deploy it.
> 
> > 
> > 
> > It hung here;
> > 
> > Press [Ctrl] + c
> > it continued to display:
> > 
> > 19:49,653 INFO [org.jboss.as.osgi] (MSC service thread 1-3)
> > JBAS011942: Stopping OSGi Framework
> > 22:19:49,701 INFO [org.jboss.as.logging] JBAS011503: Restored
> > bootstrap log handlers
> > 22:19:49,726 INFO [org.apache.coyote.http11.Http11Protocol] Pausing
> > Coyote HTTP/1.1 on http--0.0.0.0-8080
> > 22:19:49,727 INFO [org.apache.coyote.http11.Http11Protocol]
> > Stopping
> > Coyote HTTP/1.1 on http--0.0.0.0-8080
> > 22:19:49,729 INFO [com.arjuna.ats.jbossatx] ARJUNA032018:
> > Destroying
> > TransactionManagerService
> > 22:19:49,730 INFO [com.arjuna.ats.jbossatx] ARJUNA032014: Stopping
> > transaction recovery manager
> > 22:19:49,753 INFO [org.jboss.as] JBAS015950: JBoss AS 7.1.1.Final
> > "Brontes" stopped in 111ms
> > 
> > Is it normal? Without problem?
> > 
> > Thanks
> > 
> > B.R.
> > Stephen L
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 
> 
> 


From lhornyak at redhat.com  Wed Nov 14 08:02:35 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Wed, 14 Nov 2012 03:02:35 -0500 (EST)
Subject: [Engine-devel] wiki
Message-ID: <1286074710.9359643.1352880155679.JavaMail.root@redhat.com>

Hi,

The wiki is behaving strangely today. It does not accept login and claims that 'You have cookies disabled'. Also, the password reset form is showing error messages. 
Is there a server-side problem?

Thx,
Laszlo


From lhornyak at redhat.com  Wed Nov 14 07:37:07 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Wed, 14 Nov 2012 02:37:07 -0500 (EST)
Subject: [Engine-devel] Proposal to add Allon Mureinik as maintainer
	to	engine core
In-Reply-To: <50A31A19.7040602@redhat.com>
Message-ID: <151606547.9355807.1352878627685.JavaMail.root@redhat.com>

+1

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Wednesday, November 14, 2012 5:12:09 AM
> Subject: [Engine-devel] Proposal to add Allon Mureinik as maintainer to	engine core
> 
> Allon has worked on oVirt for the past 10 months.
> With 534 patches ranging from cleanups, to complex features like user
> level api and storage live migration. In addition, Allon has been
> instrumental in the number of patch reviews he has done.
> 
> I'd like to propose Allon as a maintainer of engine core.
> 
> Thanks,
>     Itamar
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From gchaplik at redhat.com  Wed Nov 14 08:21:11 2012
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Wed, 14 Nov 2012 03:21:11 -0500 (EST)
Subject: [Engine-devel] Managing permissions on network
In-Reply-To: <50A28F15.8010603@redhat.com>
Message-ID: <2063905816.7314332.1352881271393.JavaMail.root@redhat.com>

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Livnat Peer" <lpeer at redhat.com>
> Cc: engine-devel at ovirt.org, "Michal Skrivanek" <mskrivan at redhat.com>, "Andrew Cathrow" <acathrow at redhat.com>, "Gilad
> Chaplik" <gchaplik at redhat.com>, "Doron Fediuck" <dfediuck at redhat.com>
> Sent: Tuesday, November 13, 2012 8:19:01 PM
> Subject: Re: [Engine-devel] Managing permissions on network
> 
> On 11/13/2012 07:18 PM, Livnat Peer wrote:
> > On 13/11/12 15:39, Itamar Heim wrote:
> >> On 11/13/2012 03:37 PM, Livnat Peer wrote:
> >>> On 13/11/12 15:19, Itamar Heim wrote:
> >>>> On 11/13/2012 12:45 PM, Livnat Peer wrote:
> >>>>> Interesting point, I think that if a user has permission to
> >>>>> create a VM
> >>>>> from a specific template we should give him permission to use
> >>>>> the
> >>>>> template networks on this VM implicitly upon the VM creation.
> >>>>
> >>>> having a permission to a template does not mean a permission to
> >>>> the
> >>>> default network of that VM, especially as we'll use templates
> >>>> more as
> >>>> instance types.
> >>>
> >>> Another alternative is to require permission on the network as
> >>> well as
> >>> the template.
> >>> I must say I don't really like it, although I agree with your
> >>> comment,
> >>> we require too many operations for enabling a user to create a VM
> >>> from
> >>> template (permission on the template, quota on the storage,
> >>> permissions
> >>> on the network, next we'll require a PHD ;)).
> >>>
> >>> Anyone has a better idea?
> >>
> >> I assume most networks would be given either to 'everyone' or
> >> groups of
> >> users, not per user (and if the network is per user/tenant, then
> >> it must
> >> be done per user.
> >
> > Which reminds that I wanted to propose adding a property on a
> > network
> > which is called public.
> > It's just a UI feature to give a NetworkUser on this network to
> > 'everyone'. It makes making a network public easier for the user.
> >
> > In addition during upgrade we should make all existing networks
> > public
> > networks and not allocate specific permissions for users on
> > networks.
> >
> > In addition it also means a user is given permission on a network
> > and
> > then he can use it for any VM he owns. Isn't that problematic? We
> > can't
> > limit a user to use a network on a specific VM.
> 
> I think that's fine.
> don't let user edit that vm if you don't trust them.
> 
> >
> >> i may not remember correctly, but i thought when giving quota to
> >> user we
> >> also give some permissions with it (on cluster and storage)?
> >
> > I am not sure what is the current implementation as it changed a
> > lot,
> > but last I tracked we checked for either quota or permissions we
> > did not
> > give implicit permissions when creating a quota.
> >
> 
> gilad/doron?

No implicit permissions. IIRC it was never implemented

> 


From iheim at redhat.com  Wed Nov 14 10:53:32 2012
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 14 Nov 2012 12:53:32 +0200
Subject: [Engine-devel] Managing permissions on network
In-Reply-To: <2005776138.8788245.1352880676972.JavaMail.root@redhat.com>
References: <2005776138.8788245.1352880676972.JavaMail.root@redhat.com>
Message-ID: <50A3782C.5090405@redhat.com>

On 11/14/2012 10:11 AM, Antoni Segura Puimedon wrote:
>
>
> ----- Original Message -----
>> From: "Itamar Heim" <iheim at redhat.com>
>> To: "Charlie" <medievalist at gmail.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Wednesday, November 14, 2012 5:28:21 AM
>> Subject: Re: [Engine-devel] Managing permissions on network
>>
>> On 11/13/2012 09:57 PM, Charlie wrote:
>>> Will any of these groups and/or permissions be drawn from LDAP?
>>>
>>> Frankly, system admins are not looking for yet another console to
>>> manage permissions.
>>
>> all users/groups come from LDAP.
>> you just need to give permissions to these groups/users in ovirt.
>> is that what you meant?
>
> Would it be possible to somehow allow the admins to set permissions
> on the LDAP console?

afaik, the concept of changing ldap scheme's to manage permissions from 
it is not very popular (unrelated to ovirt only).
it also means integration per ldap scheme.
but i'm open to hear otherwise from people using ldap to manage 
permission in ldap, and not just groups.

>
>>
>>>
>>> --Charlie
>>>
>>>
>>> On Tue, Nov 13, 2012 at 1:19 PM, Itamar Heim <iheim at redhat.com>
>>> wrote:
>>>> On 11/13/2012 07:18 PM, Livnat Peer wrote:
>>>>>
>>>>> On 13/11/12 15:39, Itamar Heim wrote:
>>>>>>
>>>>>> On 11/13/2012 03:37 PM, Livnat Peer wrote:
>>>>>>>
>>>>>>> On 13/11/12 15:19, Itamar Heim wrote:
>>>>>>>>
>>>>>>>> On 11/13/2012 12:45 PM, Livnat Peer wrote:
>>>>>>>>>
>>>>>>>>> Interesting point, I think that if a user has permission to
>>>>>>>>> create a
>>>>>>>>> VM
>>>>>>>>> from a specific template we should give him permission to use
>>>>>>>>> the
>>>>>>>>> template networks on this VM implicitly upon the VM creation.
>>>>>>>>
>>>>>>>>
>>>>>>>> having a permission to a template does not mean a permission
>>>>>>>> to the
>>>>>>>> default network of that VM, especially as we'll use templates
>>>>>>>> more as
>>>>>>>> instance types.
>>>>>>>
>>>>>>>
>>>>>>> Another alternative is to require permission on the network as
>>>>>>> well as
>>>>>>> the template.
>>>>>>> I must say I don't really like it, although I agree with your
>>>>>>> comment,
>>>>>>> we require too many operations for enabling a user to create a
>>>>>>> VM from
>>>>>>> template (permission on the template, quota on the storage,
>>>>>>> permissions
>>>>>>> on the network, next we'll require a PHD ;)).
>>>>>>>
>>>>>>> Anyone has a better idea?
>>>>>>
>>>>>>
>>>>>> I assume most networks would be given either to 'everyone' or
>>>>>> groups of
>>>>>> users, not per user (and if the network is per user/tenant, then
>>>>>> it must
>>>>>> be done per user.
>>>>>
>>>>>
>>>>> Which reminds that I wanted to propose adding a property on a
>>>>> network
>>>>> which is called public.
>>>>> It's just a UI feature to give a NetworkUser on this network to
>>>>> 'everyone'. It makes making a network public easier for the user.
>>>>>
>>>>> In addition during upgrade we should make all existing networks
>>>>> public
>>>>> networks and not allocate specific permissions for users on
>>>>> networks.
>>>>>
>>>>> In addition it also means a user is given permission on a network
>>>>> and
>>>>> then he can use it for any VM he owns. Isn't that problematic? We
>>>>> can't
>>>>> limit a user to use a network on a specific VM.
>>>>
>>>>
>>>> I think that's fine.
>>>> don't let user edit that vm if you don't trust them.
>>>>
>>>>
>>>>>
>>>>>> i may not remember correctly, but i thought when giving quota to
>>>>>> user we
>>>>>> also give some permissions with it (on cluster and storage)?
>>>>>
>>>>>
>>>>> I am not sure what is the current implementation as it changed a
>>>>> lot,
>>>>> but last I tracked we checked for either quota or permissions we
>>>>> did not
>>>>> give implicit permissions when creating a quota.
>>>>>
>>>>
>>>> gilad/doron?
>>>>
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>




From dfediuck at redhat.com  Wed Nov 14 12:48:24 2012
From: dfediuck at redhat.com (Doron Fediuck)
Date: Wed, 14 Nov 2012 07:48:24 -0500 (EST)
Subject: [Engine-devel] Proposal to add Allon Mureinik as
	maintainer	to	engine core
In-Reply-To: <669761583.31334534.1352866612858.JavaMail.root@redhat.com>
Message-ID: <66450676.26259108.1352897304077.JavaMail.root@redhat.com>

I'd like to add Allon is doing a very good reviewing job,
giving constructive reviews alongside relevant explanations.

So for this and everything Itamar mentioned, Allon gets my +1.

----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, November 14, 2012 6:16:52 AM
> Subject: Re: [Engine-devel] Proposal to add Allon Mureinik as maintainer	to	engine core
> 
> +1
> 
> ----- Original Message -----
> > From: "Itamar Heim" <iheim at redhat.com>
> > To: engine-devel at ovirt.org
> > Sent: Wednesday, November 14, 2012 6:12:09 AM
> > Subject: [Engine-devel] Proposal to add Allon Mureinik as
> > maintainer to	engine core
> > 
> > Allon has worked on oVirt for the past 10 months.
> > With 534 patches ranging from cleanups, to complex features like
> > user
> > level api and storage live migration. In addition, Allon has been
> > instrumental in the number of patch reviews he has done.
> > 
> > I'd like to propose Allon as a maintainer of engine core.
> > 
> > Thanks,
> >     Itamar
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From lhornyak at redhat.com  Wed Nov 14 10:33:21 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Wed, 14 Nov 2012 05:33:21 -0500 (EST)
Subject: [Engine-devel] Building oVirt from source
In-Reply-To: <1352888283.25478.YahooMailNeo@web125101.mail.ne1.yahoo.com>
Message-ID: <2147216738.9403862.1352889201520.JavaMail.root@redhat.com>

Ah, just noticed that the build process deleted the directory, or at least attempted to. And then I did not find in the log where did it create again...
There must be a problem around the build, maybe a permission issue. I recommend to just copy the engine.ear dir to the deploy directory for now, and then of course touch engine.ear.dodeploy in the same directory and see if it works.

I hope the mailing lists will recover soon and the build guys will be able to tell what went wrong.

----- Original Message -----
> From: "Stephen Liu" <satimis at yahoo.com>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, November 14, 2012 11:18:03 AM
> Subject: Re: [Engine-devel] Building oVirt from source
> 
> 
> Hi Laszlo,
> 
> # find / -name engine.ear
> find: `/run/user/satimis/gvfs': Permission denied
> /home/satimis/ovirt-engine/ear/target/engine.ear
> 
> NOT;
> /usr/share/jboss-as/standalone/deployments/engine.ear/
> 
> # find / -name jboss-as
> find: `/run/user/satimis/gvfs': Permission denied
> /home/satimis/jboss-as
> 
> 
> B.R.
> Stephen L
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> From: Laszlo Hornyak <lhornyak at redhat.com>
> To: Stephen Liu <satimis at yahoo.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, November 14, 2012 4:36 PM
> Subject: Re: [Engine-devel] Building oVirt from source
> 
> Hi,
> 
> We may have some infrastructure problems. Looks like gerrit is dead
> as well :(
> Does this directory exist?
> /usr/share/jboss-as/standalone/deployments/engine.ear/
> 
> 
> ----- Original Message -----
> > From: "Stephen Liu" < satimis at yahoo.com >
> > To: "Laszlo Hornyak" < lhornyak at redhat.com >
> > Cc: engine-devel at ovirt.org
> > Sent: Wednesday, November 14, 2012 9:25:56 AM
> > Subject: Re: [Engine-devel] Building oVirt from source
> > 
> > 
> > 
> > Hi,
> > 
> > I have sent another email to the list under the subject: "Deploy
> > error again". But it never came to the list:
> > 
> > Subject : Deploy error again
> > 
> > Failure:-
> > 
> > $ mvn clean install -Pdep,setup
> > /usr/lib/jvm/java
> > [INFO] Scanning for projects...
> > [WARNING]
> > [WARNING] Some problems were encountered while building the
> > effective
> > model for org.ovirt.engine:engine-server-ear:ear:3.1.0
> > [WARNING] 'build.plugins.plugin.version' for
> > org.apache.maven.plugins:maven-ear-plugin is missing. @ line 154,
> > column 15
> > [WARNING] 'distributionManagement.repository.id' must not be
> > 'local',
> > this identifier is reserved for the local repository, using it for
> > other repositories will corrupt your repository metadata. @ line
> > 18,
> > column 11
> > [WARNING]
> > [WARNING] It is highly recommended to fix these problems because
> > they
> > threaten the stability of your build.
> > [WARNING]
> > [WARNING] For this reason, future Maven versions might no longer
> > support building such malformed projects.
> > [WARNING]
> > [INFO]
> > [INFO]
> > ------------------------------------------------------------------------
> > [INFO] Building oVirt Server EAR 3.1.0
> > [INFO]
> > ------------------------------------------------------------------------
> > Downloading:
> > http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-antrun-plugin/1.3/maven-antrun-plugin-1.3.pom
> > Downloaded:
> > http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-antrun-plugin/1.3/maven-antrun-plugin-1.3.pom
> > (5 KB at 46.7 KB/sec)
> > Downloading:
> > http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-antrun-plugin/1.3/maven-antrun-plugin-1.3.jar
> > Downloaded:
> > http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-antrun-plugin/1.3/maven-antrun-plugin-1.3.jar
> > (24 KB at 255.8 KB/sec)
> > [INFO]
> > [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @
> > engine-server-ear ---
> > [INFO] Deleting /home/satimis/ovirt-engine/ear/target
> > [INFO]
> > [INFO] --- maven-antrun-plugin:1.3:run (undeploy) @
> > engine-server-ear
> > ---
> > Downloading:
> > http://repo1.maven.org/maven2/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.pom
> > Downloaded:
> > http://repo1.maven.org/maven2/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.pom
> > (3 KB at 77.6 KB/sec)
> > Downloading:
> > http://repo1.maven.org/maven2/org/apache/ant/ant-parent/1.7.1/ant-parent-1.7.1.pom
> > Downloaded:
> > http://repo1.maven.org/maven2/org/apache/ant/ant-parent/1.7.1/ant-parent-1.7.1.pom
> > (5 KB at 137.9 KB/sec)
> > Downloading:
> > http://repo1.maven.org/maven2/org/apache/ant/ant/1.7.1/ant-1.7.1.pom
> > Downloaded:
> > http://repo1.maven.org/maven2/org/apache/ant/ant/1.7.1/ant-1.7.1.pom
> > (10 KB at 232.4 KB/sec)
> > Downloading:
> > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/1.5.6/plexus-utils-1.5.6.jar
> > Downloading:
> > http://repo1.maven.org/maven2/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.jar
> > Downloading:
> > http://repo1.maven.org/maven2/org/apache/ant/ant/1.7.1/ant-1.7.1.jar
> > Downloaded:
> > http://repo1.maven.org/maven2/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.jar
> > (12 KB at 79.1 KB/sec)
> > Downloaded:
> > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/1.5.6/plexus-utils-1.5.6.jar
> > (245 KB at 226.5 KB/sec)
> > Downloaded:
> > http://repo1.maven.org/maven2/org/apache/ant/ant/1.7.1/ant-1.7.1.jar
> > (1292 KB at 384.3 KB/sec)
> > [INFO] Executing tasks
> > [echo] *** Deleting
> > /usr/share/jboss-as/standalone/deployments/engine.ear/...
> > [INFO] Executed tasks
> > [INFO]
> > [INFO] --- maven-ear-plugin:2.6:generate-application-xml
> > (default-generate-application-xml) @ engine-server-ear ---
> > [INFO] Generating application.xml
> > [INFO]
> > [INFO] --- maven-resources-plugin:2.4.3:resources
> > (default-resources)
> > @ engine-server-ear ---
> > [INFO] Using 'UTF-8' encoding to copy filtered resources.
> > [INFO] skip non existing resourceDirectory
> > /home/satimis/ovirt-engine/ear/src/main/java
> > [INFO] Copying 1 resource
> > [INFO]
> > [INFO] --- maven-ear-plugin:2.6:ear (default-ear) @
> > engine-server-ear
> > ---
> > [INFO] Copying artifact[jar:org.ovirt.engine.core:common:3.1.0]
> > to[lib/engine-common.jar]
> > [INFO] Copying artifact[jar:org.ovirt.engine.core:compat:3.1.0]
> > to[lib/engine-compat.jar]
> > [INFO] Copying artifact[jar:org.ovirt.engine.core:dal:3.1.0]
> > to[lib/engine-dal.jar]
> > [INFO] Copying artifact[jar:org.ovirt.engine.core:utils:3.1.0]
> > to[lib/engine-utils.jar]
> > [INFO] Copying
> > artifact[jar:org.ovirt.engine.core:engineencryptutils:3.1.0]
> > to[lib/engine-encryptutils.jar]
> > [INFO] Copying artifact[jar:org.ovirt.engine.core:vdsbroker:3.1.0]
> > to[lib/engine-vdsbroker.jar]
> > [INFO] Copying artifact[war:org.ovirt.engine.core:root-war:3.1.0]
> > to[root.war] (unpacked)
> > [INFO] Copying artifact[war:org.ovirt.engine.ui:rmw-war:3.1.0]
> > to[ovirtengineweb.war] (unpacked)
> > [INFO] Copying
> > artifact[war:org.ovirt.engine.api:restapi-webapp:3.1.0]
> > to[restapi.war] (unpacked)
> > [INFO] Copying artifact[war:org.ovirt.engine.ui:userportal:3.1.0]
> > to[userportal.war] (unpacked)
> > [INFO] Copying artifact[war:org.ovirt.engine.ui:webadmin:3.1.0]
> > to[webadmin.war] (unpacked)
> > [INFO] Copying artifact[ejb:org.ovirt.engine.ui:genericapi:3.1.0]
> > to[engine-genericapi.jar] (unpacked)
> > [INFO] Copying artifact[ejb:org.ovirt.engine.core:scheduler:3.1.0]
> > to[engine-scheduler.jar] (unpacked)
> > [INFO] Copying artifact[ejb:org.ovirt.engine.core:bll:3.1.0]
> > to[engine-bll.jar] (unpacked)
> > [INFO] Copying artifact[jar:commons-codec:commons-codec:1.4]
> > to[lib/commons-codec-1.4.jar]
> > [INFO] Copying
> > artifact[jar:org.hibernate:hibernate-validator:4.0.2.GA]
> > to[lib/hibernate-validator-4.0.2.GA.jar]
> > [INFO] Copying
> > artifact[jar:javax.validation:validation-api:1.0.0.GA]
> > to[lib/validation-api-1.0.0.GA.jar]
> > [INFO] Copying artifact[jar:org.slf4j:slf4j-api:1.5.6]
> > to[lib/slf4j-api-1.5.6.jar]
> > [INFO] Copying artifact[jar:javax.xml.bind:jaxb-api:2.1]
> > to[lib/jaxb-api-2.1.jar]
> > [INFO] Copying artifact[jar:javax.xml.stream:stax-api:1.0-2]
> > to[lib/stax-api-1.0-2.jar]
> > [INFO] Copying artifact[jar:javax.activation:activation:1.1]
> > to[lib/activation-1.1.jar]
> > [INFO] Copying artifact[jar:com.sun.xml.bind:jaxb-impl:2.1.3]
> > to[lib/jaxb-impl-2.1.3.jar]
> > [INFO] Copying
> > artifact[jar:org.hibernate:hibernate-annotations:3.4.0.GA]
> > to[lib/hibernate-annotations-3.4.0.GA.jar]
> > [INFO] Copying
> > artifact[jar:org.hibernate:ejb3-persistence:1.0.2.GA]
> > to[lib/ejb3-persistence-1.0.2.GA.jar]
> > [INFO] Copying
> > artifact[jar:org.hibernate:hibernate-commons-annotations:3.1.0.GA]
> > to[lib/hibernate-commons-annotations-3.1.0.GA.jar]
> > [INFO] Copying artifact[jar:org.hibernate:hibernate-core:3.3.0.SP1]
> > to[lib/hibernate-core-3.3.0.SP1.jar]
> > [INFO] Copying artifact[jar:antlr:antlr:2.7.6]
> > to[lib/antlr-2.7.6.jar]
> > [INFO] Copying artifact[jar:dom4j:dom4j:1.6.1]
> > to[lib/dom4j-1.6.1.jar]
> > [INFO] Copying artifact[jar:xml-apis:xml-apis:1.0.b2]
> > to[lib/xml-apis-1.0.b2.jar]
> > [INFO] Copying
> > artifact[jar:org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.1_spec:1.0.0.Final]
> > to[lib/jboss-interceptors-api_1.1_spec-1.0.0.Final.jar]
> > [INFO] Copying
> > artifact[jar:org.ovirt.engine.core:engine-tools-common:3.1.0]
> > to[lib/engine-tools-common-3.1.0.jar]
> > [INFO] Copying
> > artifact[jar:commons-beanutils:commons-beanutils:1.8.2]
> > to[lib/commons-beanutils-1.8.2.jar]
> > [INFO] Copying artifact[jar:org.apache.mina:mina-core:2.0.1]
> > to[lib/mina-core-2.0.1.jar]
> > [INFO] Copying artifact[jar:org.apache.sshd:sshd-core:0.7.0]
> > to[lib/sshd-core-0.7.0.jar]
> > [INFO] Copying
> > artifact[jar:org.apache.commons:commons-compress:1.3]
> > to[lib/commons-compress-1.3.jar]
> > [INFO] Copying artifact[jar:commons-lang:commons-lang:2.4]
> > to[lib/commons-lang-2.4.jar]
> > [INFO] Copying artifact[jar:org.apache.xmlrpc:xmlrpc-client:3.1.3]
> > to[lib/xmlrpc-client-3.1.3.jar]
> > [INFO] Copying artifact[jar:org.apache.xmlrpc:xmlrpc-common:3.1.3]
> > to[lib/xmlrpc-common-3.1.3.jar]
> > [INFO] Copying
> > artifact[jar:org.apache.ws.commons.util:ws-commons-util:1.0.2]
> > to[lib/ws-commons-util-1.0.2.jar]
> > [INFO] Copying
> > artifact[jar:org.springframework:spring-jdbc:3.1.1.RELEASE]
> > to[lib/spring-jdbc-3.1.1.RELEASE.jar]
> > [INFO] Copying
> > artifact[jar:org.springframework:spring-tx:3.1.1.RELEASE]
> > to[lib/spring-tx-3.1.1.RELEASE.jar]
> > [INFO] Copying
> > artifact[jar:org.springframework.ldap:spring-ldap-core:1.3.1.RELEASE]
> > to[lib/spring-ldap-core-1.3.1.RELEASE.jar]
> > [INFO] Copying
> > artifact[jar:commons-httpclient:commons-httpclient:3.1]
> > to[lib/commons-httpclient-3.1.jar]
> > [INFO] Copying
> > artifact[jar:commons-collections:commons-collections:3.1]
> > to[lib/commons-collections-3.1.jar]
> > [INFO] Copying artifact[jar:org.quartz-scheduler:quartz:2.1.2]
> > to[lib/quartz-2.1.2.jar]
> > [INFO] Copying artifact[jar:c3p0:c3p0:0.9.1.1]
> > to[lib/c3p0-0.9.1.1.jar]
> > [INFO] Copying
> > artifact[jar:org.ovirt.engine.core:searchbackend:3.1.0]
> > to[lib/searchbackend-3.1.0.jar]
> > [INFO] Copying
> > artifact[jar:org.springframework:spring-core:3.1.1.RELEASE]
> > to[lib/spring-core-3.1.1.RELEASE.jar]
> > [INFO] Copying
> > artifact[jar:org.springframework:spring-asm:3.1.1.RELEASE]
> > to[lib/spring-asm-3.1.1.RELEASE.jar]
> > [INFO] Copying
> > artifact[jar:org.springframework:spring-beans:3.1.1.RELEASE]
> > to[lib/spring-beans-3.1.1.RELEASE.jar]
> > [INFO] Copying
> > artifact[jar:org.springframework:spring-context:3.1.1.RELEASE]
> > to[lib/spring-context-3.1.1.RELEASE.jar]
> > [INFO] Copying
> > artifact[jar:org.springframework:spring-aop:3.1.1.RELEASE]
> > to[lib/spring-aop-3.1.1.RELEASE.jar]
> > [INFO] Copying artifact[jar:aopalliance:aopalliance:1.0]
> > to[lib/aopalliance-1.0.jar]
> > [INFO] Copying
> > artifact[jar:org.springframework:spring-expression:3.1.1.RELEASE]
> > to[lib/spring-expression-3.1.1.RELEASE.jar]
> > [INFO] Copy ear sources to
> > /home/satimis/ovirt-engine/ear/target/engine
> > [WARNING] resourcesDir is deprecated. Please use the
> > earSourceDirectory property instead.
> > [INFO] Copy ear resources to
> > /home/satimis/ovirt-engine/ear/target/engine
> > [INFO] Including custom manifest
> > file[/home/satimis/ovirt-engine/ear/target/engine/META-INF/MANIFEST.MF]
> > [INFO] Building jar:
> > /home/satimis/ovirt-engine/ear/target/engine.ear
> > [INFO]
> > [INFO] --- maven-dependency-plugin:2.1:copy (copy-quartz-jar) @
> > engine-server-ear ---
> > [INFO] Configured Artifact: org.quartz-scheduler:quartz:2.1.2:jar
> > [INFO] Copying quartz-2.1.2.jar to
> > /home/satimis/ovirt-engine/ear/target/quartz/quartz-2.1.2.jar
> > [INFO]
> > [INFO] --- maven-antrun-plugin:1.3:run (deploy) @ engine-server-ear
> > ---
> > [INFO] Executing tasks
> > [echo] *** Copying updated files from target/engine/ to
> > /usr/share/jboss-as/standalone/deployments/engine.ear/...
> > [copy] Copying 1168 files to
> > /usr/share/jboss-as/standalone/deployments/engine.ear
> > [copy] Copying
> > /home/satimis/ovirt-engine/ear/target/engine/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class
> > to
> > /usr/share/jboss-as/standalone/deployments/engine.ear/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class
> > [INFO]
> > ------------------------------------------------------------------------
> > [INFO] BUILD FAILURE
> > [INFO]
> > ------------------------------------------------------------------------
> > [INFO] Total time: 15.761s
> > [INFO] Finished at: Wed Nov 14 14:34:56 HKT 2012
> > [INFO] Final Memory: 16M/295M
> > [INFO]
> > ------------------------------------------------------------------------
> > [ERROR] Failed to execute goal
> > org.apache.maven.plugins:maven-antrun-plugin:1.3:run (deploy) on
> > project engine-server-ear: An Ant BuildException has occured:
> > Failed
> > to copy
> > /home/satimis/ovirt-engine/ear/target/engine/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class
> > to
> > /usr/share/jboss-as/standalone/deployments/engine.ear/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class
> > due to java.io.FileNotFoundException
> > /usr/share/jboss-as/standalone/deployments/engine.ear/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class
> > (No such file or directory) -> [Help 1]
> > [ERROR]
> > [ERROR] To see the full stack trace of the errors, re-run Maven
> > with
> > the -e switch.
> > [ERROR] Re-run Maven using the -X switch to enable full debug
> > logging.
> > [ERROR]
> > [ERROR] For more information about the errors and possible
> > solutions,
> > please read the following articles:
> > [ERROR] [Help 1]
> > http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> > 
> > 
> > PluginExecutionException
> > https://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
> > .....
> > You should report this problem to the maintainer of the plugin.
> > 
> > 
> > Please help. How to fix this problem and continue?
> > 
> > TIA
> > 
> > B.R.
> > Stephen L
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > From: Laszlo Hornyak < lhornyak at redhat.com >
> > To: Stephen Liu < satimis at yahoo.com >
> > Cc: engine-devel at ovirt.org
> > Sent: Wednesday, November 14, 2012 3:43 PM
> > Subject: Re: [Engine-devel] Building oVirt from source
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Stephen Liu" < satimis at yahoo.com >
> > > To: engine-devel at ovirt.org
> > > Sent: Tuesday, November 13, 2012 5:20:46 PM
> > > Subject: [Engine-devel] Building oVirt from source
> > > 
> > > 
> > > 
> > > 
> > > Hi all,
> > > 
> > > Have another round to build oVirt from source following;
> > > 
> > > Building Engine Draft
> > > http://wiki.ovirt.org/wiki/Building_Engine_Draft
> > > 
> > > OS - Fedora 17 desktop 64bit, fresh and clean installed.
> > > 
> > > Not much problem encountered up to "Installing JBoss AS" except
> > > follows:
> > > 
> > > 1)
> > > Maven personal settings
> > > ==================
> > > 
> > > $ mkdir $HOME/.m2
> > > $ wget -O $HOME/.m2/settings.xml
> > > http://wiki.ovirt.org/w/images/1/18/Settings.xml.png
> > > 
> > > (it should read
> > > " http://wiki.ovirt.org/w/images/1/18/Settings.xml.png ")
> > > ^^^^ (not www)
> > > 
> > > 2)
> > > Check that the application server starts correctly:
> > > 
> > > $ cd $JBOSS_HOME/bin
> > > $ ./standalone.sh -b 0.0.0.0
> > > ===================================================
> > > 
> > > JBoss Bootstrap Environment
> > > 
> > > JBOSS_HOME: /home/satimis/jboss-as
> > > 
> > > JAVA: java
> > > 
> > > JAVA_OPTS: -server -XX:+UseCompressedOops -XX:+TieredCompilation
> > > -Xms64m -Xmx512m -XX:MaxPermSize=256m
> > > -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true
> > > -Dsun.rmi.dgc.client.gcInterval=3600000
> > > -Dsun.rmi.dgc.server.gcInterval=3600000
> > > -Djboss.modules.system.pkgs=org.jboss.byteman
> > > -Djava.awt.headless=tr
> > > ....
> > > .....
> > > 
> > > 22:14:38,217 INFO [org.jboss.as] (Controller Boot Thread)
> > > JBAS015874:
> > > JBoss AS 7.1.1.Final "Brontes" started in 6662ms - Started 133 of
> > > 208 services (74 services are passive or on-demand)
> > 
> > So your jboss is started at this point and should e listening on
> > 8080
> > for http connections. Is ovirt running?
> > If not you should check if it is there in
> > standalone/deployments/engine.ear
> > Also, see if engine.ear.deployed exists. touch engine.dodeploy to
> > kick jboss and deploy it.
> > 
> > > 
> > > 
> > > It hung here;
> > > 
> > > Press [Ctrl] + c
> > > it continued to display:
> > > 
> > > 19:49,653 INFO [org.jboss.as.osgi] (MSC service thread 1-3)
> > > JBAS011942: Stopping OSGi Framework
> > > 22:19:49,701 INFO [org.jboss.as.logging] JBAS011503: Restored
> > > bootstrap log handlers
> > > 22:19:49,726 INFO [org.apache.coyote.http11.Http11Protocol]
> > > Pausing
> > > Coyote HTTP/1.1 on http--0.0.0.0-8080
> > > 22:19:49,727 INFO [org.apache.coyote.http11.Http11Protocol]
> > > Stopping
> > > Coyote HTTP/1.1 on http--0.0.0.0-8080
> > > 22:19:49,729 INFO [com.arjuna.ats.jbossatx] ARJUNA032018:
> > > Destroying
> > > TransactionManagerService
> > > 22:19:49,730 INFO [com.arjuna.ats.jbossatx] ARJUNA032014:
> > > Stopping
> > > transaction recovery manager
> > > 22:19:49,753 INFO [org.jboss.as] JBAS015950: JBoss AS 7.1.1.Final
> > > "Brontes" stopped in 111ms
> > > 
> > > Is it normal? Without problem?
> > > 
> > > Thanks
> > > 
> > > B.R.
> > > Stephen L
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > 
> > 
> > 
> 
> 
> 


From lhornyak at redhat.com  Wed Nov 14 11:01:51 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Wed, 14 Nov 2012 06:01:51 -0500 (EST)
Subject: [Engine-devel] Unable to view the storage domains - SQL error
In-Reply-To: <1533070984.31325703.1352862137082.JavaMail.root@redhat.com>
Message-ID: <594204690.9425857.1352890911109.JavaMail.root@redhat.com>

hi,

The search queries generate these statements. It looks like something replaced the underscores with spaces in the view names, and that is not good for SQL. But the backend should not do this, maybe only restapi replaces something in the erromessages?
Possibly the db upgrade failed somewhere and it left the schema without views?


----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> To: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, November 14, 2012 4:02:17 AM
> Subject: Re: [Engine-devel] Unable to view the storage domains - SQL error
> 
> 
> 
> Hi Christopher,
> In general - as a developer at engine project, I would recommend to
> run the upgrade script on a frequent basis.
> What troubles me with the query you sent (maybe some problematic copy
> paste issue?) are the following issues:
> a. storage domains for search - not sure what this is
> b. storage domains with hosts view - I guess you have some underline
> issue at the copy paste.
> 
> 
> I would appreciate if you attach engine.log (or a part of it that
> reflects the error you encountered)
> 
> 
> Kind regards,
> Yair
> 
> 
> 
> 
> 
> 
> From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
> To: engine-devel at ovirt.org
> Sent: Wednesday, November 14, 2012 12:10:14 AM
> Subject: [Engine-devel] Unable to view the storage domains - SQL
> error
> 
> 
> 
> 
> Hi All,
> 
> 
> 
> I?m getting an error when trying to view the storage domains using
> the REST API:
> 
> 
> 
> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> 
> <fault>
> 
> <reason>Operation Failed</reason>
> 
> <detail>statementcallback; bad sql grammar [select * from (select *
> from storage domains for search where ( id in (select storage
> domains with hosts view.id from storage domains with hosts view ))
> order by storage name asc ) as t1 offset (1 -1) limit 100]; nested
> exception is org.postgresql.util.psqlexception: error: relation
> "storage domains for search" does not exist position: 30</detail>
> 
> </fault>
> 
> 
> 
> Also, through the web admin console, when viewing the storage domains
> the list never loads.
> 
> 
> 
> Did something change in the DB recently such that I would need to
> rebuild it?
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -Chris
> 
> 
> 
> Chris Morrissey
> 
> Software Engineer
> 
> NetApp Inc.
> 
> 919.476.4428
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From eedri at redhat.com  Wed Nov 14 08:08:05 2012
From: eedri at redhat.com (Eyal Edri)
Date: Wed, 14 Nov 2012 03:08:05 -0500 (EST)
Subject: [Engine-devel] Proposal to add Allon Mureinik as maintainer
	to	engine core
In-Reply-To: <50A31A19.7040602@redhat.com>
Message-ID: <770641086.344977.1352880484996.JavaMail.root@redhat.com>

+1

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Wednesday, November 14, 2012 6:12:09 AM
> Subject: [Engine-devel] Proposal to add Allon Mureinik as maintainer to	engine core
> 
> Allon has worked on oVirt for the past 10 months.
> With 534 patches ranging from cleanups, to complex features like user
> level api and storage live migration. In addition, Allon has been
> instrumental in the number of patch reviews he has done.
> 
> I'd like to propose Allon as a maintainer of engine core.
> 
> Thanks,
>     Itamar
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From lhornyak at redhat.com  Wed Nov 14 07:43:28 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Wed, 14 Nov 2012 02:43:28 -0500 (EST)
Subject: [Engine-devel] Building oVirt from source
In-Reply-To: <1352823646.4124.YahooMailNeo@web125104.mail.ne1.yahoo.com>
Message-ID: <1544042310.9356324.1352879008391.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Stephen Liu" <satimis at yahoo.com>
> To: engine-devel at ovirt.org
> Sent: Tuesday, November 13, 2012 5:20:46 PM
> Subject: [Engine-devel] Building oVirt from source
> 
> 
> 
> 
> Hi all,
> 
> Have another round to build oVirt from source following;
> 
> Building Engine Draft
> http://wiki.ovirt.org/wiki/Building_Engine_Draft
> 
> OS - Fedora 17 desktop 64bit, fresh and clean installed.
> 
> Not much problem encountered up to "Installing JBoss AS" except
> follows:
> 
> 1)
> Maven personal settings
> ==================
> 
> $ mkdir $HOME/.m2
> $ wget -O $HOME/.m2/settings.xml
> http://wiki.ovirt.org/w/images/1/18/Settings.xml.png
> 
> (it should read
> "http://wiki.ovirt.org/w/images/1/18/Settings.xml.png")
> ^^^^ (not www)
> 
> 2)
> Check that the application server starts correctly:
> 
> $ cd $JBOSS_HOME/bin
> $ ./standalone.sh -b 0.0.0.0
> ===================================================
> 
> JBoss Bootstrap Environment
> 
> JBOSS_HOME: /home/satimis/jboss-as
> 
> JAVA: java
> 
> JAVA_OPTS: -server -XX:+UseCompressedOops -XX:+TieredCompilation
> -Xms64m -Xmx512m -XX:MaxPermSize=256m
> -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true
> -Dsun.rmi.dgc.client.gcInterval=3600000
> -Dsun.rmi.dgc.server.gcInterval=3600000
> -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=tr
> ....
> .....
> 
> 22:14:38,217 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874:
> JBoss AS 7.1.1.Final "Brontes" started in 6662ms - Started 133 of
> 208 services (74 services are passive or on-demand)

So your jboss is started at this point and should e listening on 8080 for http connections. Is ovirt running?
If not you should check if it is there in standalone/deployments/engine.ear
Also, see if engine.ear.deployed exists. touch engine.dodeploy to kick jboss and deploy it.

> 
> 
> It hung here;
> 
> Press [Ctrl] + c
> it continued to display:
> 
> 19:49,653 INFO [org.jboss.as.osgi] (MSC service thread 1-3)
> JBAS011942: Stopping OSGi Framework
> 22:19:49,701 INFO [org.jboss.as.logging] JBAS011503: Restored
> bootstrap log handlers
> 22:19:49,726 INFO [org.apache.coyote.http11.Http11Protocol] Pausing
> Coyote HTTP/1.1 on http--0.0.0.0-8080
> 22:19:49,727 INFO [org.apache.coyote.http11.Http11Protocol] Stopping
> Coyote HTTP/1.1 on http--0.0.0.0-8080
> 22:19:49,729 INFO [com.arjuna.ats.jbossatx] ARJUNA032018: Destroying
> TransactionManagerService
> 22:19:49,730 INFO [com.arjuna.ats.jbossatx] ARJUNA032014: Stopping
> transaction recovery manager
> 22:19:49,753 INFO [org.jboss.as] JBAS015950: JBoss AS 7.1.1.Final
> "Brontes" stopped in 111ms
> 
> Is it normal? Without problem?
> 
> Thanks
> 
> B.R.
> Stephen L
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From asegurap at redhat.com  Wed Nov 14 08:11:16 2012
From: asegurap at redhat.com (Antoni Segura Puimedon)
Date: Wed, 14 Nov 2012 03:11:16 -0500 (EST)
Subject: [Engine-devel] Managing permissions on network
In-Reply-To: <50A31DE5.2070201@redhat.com>
Message-ID: <2005776138.8788245.1352880676972.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Charlie" <medievalist at gmail.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, November 14, 2012 5:28:21 AM
> Subject: Re: [Engine-devel] Managing permissions on network
> 
> On 11/13/2012 09:57 PM, Charlie wrote:
> > Will any of these groups and/or permissions be drawn from LDAP?
> >
> > Frankly, system admins are not looking for yet another console to
> > manage permissions.
> 
> all users/groups come from LDAP.
> you just need to give permissions to these groups/users in ovirt.
> is that what you meant?

Would it be possible to somehow allow the admins to set permissions
on the LDAP console?

> 
> >
> > --Charlie
> >
> >
> > On Tue, Nov 13, 2012 at 1:19 PM, Itamar Heim <iheim at redhat.com>
> > wrote:
> >> On 11/13/2012 07:18 PM, Livnat Peer wrote:
> >>>
> >>> On 13/11/12 15:39, Itamar Heim wrote:
> >>>>
> >>>> On 11/13/2012 03:37 PM, Livnat Peer wrote:
> >>>>>
> >>>>> On 13/11/12 15:19, Itamar Heim wrote:
> >>>>>>
> >>>>>> On 11/13/2012 12:45 PM, Livnat Peer wrote:
> >>>>>>>
> >>>>>>> Interesting point, I think that if a user has permission to
> >>>>>>> create a
> >>>>>>> VM
> >>>>>>> from a specific template we should give him permission to use
> >>>>>>> the
> >>>>>>> template networks on this VM implicitly upon the VM creation.
> >>>>>>
> >>>>>>
> >>>>>> having a permission to a template does not mean a permission
> >>>>>> to the
> >>>>>> default network of that VM, especially as we'll use templates
> >>>>>> more as
> >>>>>> instance types.
> >>>>>
> >>>>>
> >>>>> Another alternative is to require permission on the network as
> >>>>> well as
> >>>>> the template.
> >>>>> I must say I don't really like it, although I agree with your
> >>>>> comment,
> >>>>> we require too many operations for enabling a user to create a
> >>>>> VM from
> >>>>> template (permission on the template, quota on the storage,
> >>>>> permissions
> >>>>> on the network, next we'll require a PHD ;)).
> >>>>>
> >>>>> Anyone has a better idea?
> >>>>
> >>>>
> >>>> I assume most networks would be given either to 'everyone' or
> >>>> groups of
> >>>> users, not per user (and if the network is per user/tenant, then
> >>>> it must
> >>>> be done per user.
> >>>
> >>>
> >>> Which reminds that I wanted to propose adding a property on a
> >>> network
> >>> which is called public.
> >>> It's just a UI feature to give a NetworkUser on this network to
> >>> 'everyone'. It makes making a network public easier for the user.
> >>>
> >>> In addition during upgrade we should make all existing networks
> >>> public
> >>> networks and not allocate specific permissions for users on
> >>> networks.
> >>>
> >>> In addition it also means a user is given permission on a network
> >>> and
> >>> then he can use it for any VM he owns. Isn't that problematic? We
> >>> can't
> >>> limit a user to use a network on a specific VM.
> >>
> >>
> >> I think that's fine.
> >> don't let user edit that vm if you don't trust them.
> >>
> >>
> >>>
> >>>> i may not remember correctly, but i thought when giving quota to
> >>>> user we
> >>>> also give some permissions with it (on cluster and storage)?
> >>>
> >>>
> >>> I am not sure what is the current implementation as it changed a
> >>> lot,
> >>> but last I tracked we checked for either quota or permissions we
> >>> did not
> >>> give implicit permissions when creating a quota.
> >>>
> >>
> >> gilad/doron?
> >>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From dfediuck at redhat.com  Wed Nov 14 09:18:41 2012
From: dfediuck at redhat.com (Doron Fediuck)
Date: Wed, 14 Nov 2012 04:18:41 -0500 (EST)
Subject: [Engine-devel] Managing permissions on network
In-Reply-To: <2063905816.7314332.1352881271393.JavaMail.root@redhat.com>
Message-ID: <1665325433.26181821.1352884721041.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Gilad Chaplik" <gchaplik at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: engine-devel at ovirt.org, "Michal Skrivanek" <mskrivan at redhat.com>, "Andrew Cathrow" <acathrow at redhat.com>, "Doron
> Fediuck" <dfediuck at redhat.com>, "Livnat Peer" <lpeer at redhat.com>
> Sent: Wednesday, November 14, 2012 10:21:11 AM
> Subject: Re: [Engine-devel] Managing permissions on network
> 
> ----- Original Message -----
> > From: "Itamar Heim" <iheim at redhat.com>
> > To: "Livnat Peer" <lpeer at redhat.com>
> > Cc: engine-devel at ovirt.org, "Michal Skrivanek"
> > <mskrivan at redhat.com>, "Andrew Cathrow" <acathrow at redhat.com>,
> > "Gilad
> > Chaplik" <gchaplik at redhat.com>, "Doron Fediuck"
> > <dfediuck at redhat.com>
> > Sent: Tuesday, November 13, 2012 8:19:01 PM
> > Subject: Re: [Engine-devel] Managing permissions on network
> > 
> > On 11/13/2012 07:18 PM, Livnat Peer wrote:
> > > On 13/11/12 15:39, Itamar Heim wrote:
> > >> On 11/13/2012 03:37 PM, Livnat Peer wrote:
> > >>> On 13/11/12 15:19, Itamar Heim wrote:
> > >>>> On 11/13/2012 12:45 PM, Livnat Peer wrote:
> > >>>>> Interesting point, I think that if a user has permission to
> > >>>>> create a VM
> > >>>>> from a specific template we should give him permission to use
> > >>>>> the
> > >>>>> template networks on this VM implicitly upon the VM creation.
> > >>>>
> > >>>> having a permission to a template does not mean a permission
> > >>>> to
> > >>>> the
> > >>>> default network of that VM, especially as we'll use templates
> > >>>> more as
> > >>>> instance types.
> > >>>
> > >>> Another alternative is to require permission on the network as
> > >>> well as
> > >>> the template.
> > >>> I must say I don't really like it, although I agree with your
> > >>> comment,
> > >>> we require too many operations for enabling a user to create a
> > >>> VM
> > >>> from
> > >>> template (permission on the template, quota on the storage,
> > >>> permissions
> > >>> on the network, next we'll require a PHD ;)).
> > >>>
> > >>> Anyone has a better idea?
> > >>
> > >> I assume most networks would be given either to 'everyone' or
> > >> groups of
> > >> users, not per user (and if the network is per user/tenant, then
> > >> it must
> > >> be done per user.
> > >
> > > Which reminds that I wanted to propose adding a property on a
> > > network
> > > which is called public.
> > > It's just a UI feature to give a NetworkUser on this network to
> > > 'everyone'. It makes making a network public easier for the user.
> > >
> > > In addition during upgrade we should make all existing networks
> > > public
> > > networks and not allocate specific permissions for users on
> > > networks.
> > >
> > > In addition it also means a user is given permission on a network
> > > and
> > > then he can use it for any VM he owns. Isn't that problematic? We
> > > can't
> > > limit a user to use a network on a specific VM.
> > 
> > I think that's fine.
> > don't let user edit that vm if you don't trust them.
> > 
> > >
> > >> i may not remember correctly, but i thought when giving quota to
> > >> user we
> > >> also give some permissions with it (on cluster and storage)?
> > >
> > > I am not sure what is the current implementation as it changed a
> > > lot,
> > > but last I tracked we checked for either quota or permissions we
> > > did not
> > > give implicit permissions when creating a quota.
> > >
> > 
> > gilad/doron?
> 
> No implicit permissions. IIRC it was never implemented

As the quota is a logical limitation for a resource, the user should first have relevant permissions
for the relevant entity, and if needed, he should have consumption right (ActionGroup.CONSUME_QUOTA)
to use the resource. So going forward I expect network quota to behave the same; ie- a user should have
consumption rights for the relevant network resource on top of security permissions.


From dougsland at redhat.com  Wed Nov 14 16:31:54 2012
From: dougsland at redhat.com (Douglas Landgraf)
Date: Wed, 14 Nov 2012 11:31:54 -0500
Subject: [Engine-devel] wiki
In-Reply-To: <1286074710.9359643.1352880155679.JavaMail.root@redhat.com>
References: <1286074710.9359643.1352880155679.JavaMail.root@redhat.com>
Message-ID: <50A3C77A.408@redhat.com>

Hi,

On 11/14/2012 03:02 AM, Laszlo Hornyak wrote:
> Hi,
>
> The wiki is behaving strangely today. It does not accept login and claims that 'You have cookies disabled'. Also, the password reset form is showing error messages.
> Is there a server-side problem?
Looks like server-side, I am facing the same errors.


-- 
Cheers
Douglas



From mlipchuk at redhat.com  Wed Nov 14 13:35:11 2012
From: mlipchuk at redhat.com (Maor Lipchuk)
Date: Wed, 14 Nov 2012 15:35:11 +0200
Subject: [Engine-devel] Proposal to add Allon Mureinik as maintainer to
 engine core
In-Reply-To: <50A31A19.7040602@redhat.com>
References: <50A31A19.7040602@redhat.com>
Message-ID: <50A39E0F.1040801@redhat.com>

+1

On 11/14/2012 06:12 AM, Itamar Heim wrote:
> Allon has worked on oVirt for the past 10 months.
> With 534 patches ranging from cleanups, to complex features like user
> level api and storage live migration. In addition, Allon has been
> instrumental in the number of patch reviews he has done.
> 
> I'd like to propose Allon as a maintainer of engine core.
> 
> Thanks,
>    Itamar
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel




From lhornyak at redhat.com  Wed Nov 14 13:35:35 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Wed, 14 Nov 2012 08:35:35 -0500 (EST)
Subject: [Engine-devel] wiki
In-Reply-To: <50A3C77A.408@redhat.com>
Message-ID: <907984251.9457602.1352900135382.JavaMail.root@redhat.com>

It works now, probably the same root reason as for the mailing list.

----- Original Message -----
> From: "Douglas Landgraf" <dougsland at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Wednesday, November 14, 2012 5:31:54 PM
> Subject: Re: [Engine-devel] wiki
> 
> Hi,
> 
> On 11/14/2012 03:02 AM, Laszlo Hornyak wrote:
> > Hi,
> >
> > The wiki is behaving strangely today. It does not accept login and
> > claims that 'You have cookies disabled'. Also, the password reset
> > form is showing error messages.
> > Is there a server-side problem?
> Looks like server-side, I am facing the same errors.
> 
> 
> --
> Cheers
> Douglas
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From masayag at redhat.com  Wed Nov 14 12:49:44 2012
From: masayag at redhat.com (Moti Asayag)
Date: Wed, 14 Nov 2012 14:49:44 +0200
Subject: [Engine-devel] Proposal to add Allon Mureinik as maintainer to
 engine core
In-Reply-To: <50A31A19.7040602@redhat.com>
References: <50A31A19.7040602@redhat.com>
Message-ID: <50A39368.1080208@redhat.com>

On 11/14/2012 06:12 AM, Itamar Heim wrote:
> Allon has worked on oVirt for the past 10 months.
> With 534 patches ranging from cleanups, to complex features like user
> level api and storage live migration. In addition, Allon has been
> instrumental in the number of patch reviews he has done.
> 
> I'd like to propose Allon as a maintainer of engine core.

+1

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



From jhernand at redhat.com  Wed Nov 14 10:36:16 2012
From: jhernand at redhat.com (Juan Hernandez)
Date: Wed, 14 Nov 2012 11:36:16 +0100
Subject: [Engine-devel] Building oVirt from source
In-Reply-To: <1352889268.47516.YahooMailNeo@web125104.mail.ne1.yahoo.com>
References: <1352823646.4124.YahooMailNeo@web125104.mail.ne1.yahoo.com>
	<50A36C2C.5030602@redhat.com>
	<1352887836.22748.YahooMailNeo@web125102.mail.ne1.yahoo.com>
	<50A37116.1040102@redhat.com>
	<1352889268.47516.YahooMailNeo@web125104.mail.ne1.yahoo.com>
Message-ID: <50A37420.7090400@redhat.com>

On 11/14/2012 11:34 AM, Stephen Liu wrote:
> # find / -name jboss-as
> find: `/run/user/satimis/gvfs': Permission denied
> /home/satimis/jboss-as
> 
> jbozz-as is NOT on /usr/share/jboss-as

Then you need to fix your $HOME/.m2/settings.xml file, the jbossHome
property must contain the directory where you have installed the
application server.

>     ------------------------------------------------------------------------
>     *From:* Juan Hernandez <jhernand at redhat.com>
>     *To:* Stephen Liu <satimis at yahoo.com>
>     *Cc:* "engine-devel at ovirt.org" <engine-devel at ovirt.org>
>     *Sent:* Wednesday, November 14, 2012 6:23 PM
>     *Subject:* Re: [Engine-devel] Building oVirt from source
> 
>     On 11/14/2012 11:10 AM, Stephen Liu wrote:
>     >
>     > Hi Juan,
>     >
>     > I have sent another email to the list under the subject: "Deploy error
>     > again".  But it never came to the list.  Is the server in problem?
>     >
>     > Subject : Deploy error again
> 
>     I think you are having problems with the permissions in the
>     /usr/share/jboss-as directory. Make sure that you have the following
>     content in your $HOME/.m2/settings.xml file:
> 
>     <settings
>       xmlns="http://maven.apache.org/POM/4.0.0"
>       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>       xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>     http://maven.apache.org/xsd/settings-1.0.0.xsd">
> 
>       <activeProfiles>
>         <activeProfile>oVirtEnvSettings</activeProfile>
>       </activeProfiles>
> 
>       <profiles>
>         <profile>
>           <id>oVirtEnvSettings</id>
>           <properties>
>             <jbossHome>/home/satimis/jboss-as</jbossHome>
>           </properties>
>         </profile>
>       </profiles>
> 
>     </settings>
> 
>     Pay special attention to the "jbossHome" property, it should be the
>     directory where you have the application server installed, and you need
>     to have permissions to write to it. Currently you are using
>     /usr/share/jboss-as, and I guess you don't have permissions to write
>     there. Install the application server to /home/staimis/jboss-as and use
>     that instead.
> 
>     -- 
>     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.
> 
> 


-- 
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 lpeer at redhat.com  Wed Nov 14 07:48:31 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Wed, 14 Nov 2012 09:48:31 +0200
Subject: [Engine-devel] Proposal to add Allon Mureinik as maintainer to
 engine core
In-Reply-To: <669761583.31334534.1352866612858.JavaMail.root@redhat.com>
References: <669761583.31334534.1352866612858.JavaMail.root@redhat.com>
Message-ID: <50A34CCF.9060003@redhat.com>

+1
I especially appreciate his involvement and contribution to the testing
framework.

Livnat

On 14/11/12 06:16, Yair Zaslavsky wrote:
> +1
> 
> ----- Original Message -----
>> From: "Itamar Heim" <iheim at redhat.com>
>> To: engine-devel at ovirt.org
>> Sent: Wednesday, November 14, 2012 6:12:09 AM
>> Subject: [Engine-devel] Proposal to add Allon Mureinik as maintainer to	engine core
>>
>> Allon has worked on oVirt for the past 10 months.
>> With 534 patches ranging from cleanups, to complex features like user
>> level api and storage live migration. In addition, Allon has been
>> instrumental in the number of patch reviews he has done.
>>
>> I'd like to propose Allon as a maintainer of engine core.
>>
>> Thanks,
>>     Itamar
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 



From jhernand at redhat.com  Wed Nov 14 11:17:32 2012
From: jhernand at redhat.com (Juan Hernandez)
Date: Wed, 14 Nov 2012 12:17:32 +0100
Subject: [Engine-devel] Building oVirt from source
In-Reply-To: <1352891345.11371.YahooMailNeo@web125106.mail.ne1.yahoo.com>
References: <1352823646.4124.YahooMailNeo@web125104.mail.ne1.yahoo.com>
	<50A36C2C.5030602@redhat.com>
	<1352887836.22748.YahooMailNeo@web125102.mail.ne1.yahoo.com>
	<50A37116.1040102@redhat.com>
	<1352889268.47516.YahooMailNeo@web125104.mail.ne1.yahoo.com>
	<50A37420.7090400@redhat.com>
	<1352891345.11371.YahooMailNeo@web125106.mail.ne1.yahoo.com>
Message-ID: <50A37DCC.40100@redhat.com>

On 11/14/2012 12:09 PM, Stephen Liu wrote:
> 
> Hi all,
> 
> $ sudo find / -name .m2
> find: `/run/user/satimis/gvfs': Permission denied
> /home/satimis/.m2
> 
> $ sudo ls -ald /home/satimis/.m2
> drwxrwxr-x. 3 satimis satimis 4096 Nov 14 14:12 /home/satimis/.m2
> 
> 
> $ cat $HOME/.m2/settings.xml
> <settings xmlns="http://maven.apache.org/POM/4.0.0"
> <http://maven.apache.org/POM/4.0.0%22>;
>           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> <http://www.w3.org/2001/XMLSchema-instance%22>;
>           xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd"
> <http://maven.apache.org/xsd/settings-1.0.0.xsd%22>;>
> 
> <!--**************************** PROFILES ****************************-->
> 
>         <activeProfiles>
>                         <activeProfile>oVirtEnvSettings</activeProfile>
>         </activeProfiles>
> 
>         <profiles>
>             <profile>
>                 <id>oVirtEnvSettings</id>
>                     <properties>
>                         <jbossHome>/usr/share/jboss-as</jbossHome>
>                            
> <JAVA_HOME>/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/bin/java</JAVA_HOME>
>                     </properties>
>             </profile>
>          </profiles>
> </settings>

This ^ (/home/satimis/.m2/settings.xml) is the file that you need to
change, and you need to change the "jbossHome" property so that it
contains the directory where you actually have the application server
installed.

Please remove or fix the JAVA_HOME property as well, as it is not needed
and pointing a location that doesn't exist in Fedora 17.

> 
> This file is on /home/satimis/.m2/
> 
> $ locate settings.xml
> /home/satimis/.m2/settings.xml
> /usr/share/maven/conf/settings.xml
> /usr/share/mime/application/x-cisco-vpn-settings.xml
> 
> There are 2 settings.xml files
> 
> I attend the later file on /usr/share/maven/conf/settings.xml to this email
> 
> B.R.
> Stephen L
> 
> 
> 
> 
>>________________________________
>> From: Juan Hernandez <jhernand at redhat.com>
>>To: Stephen Liu <satimis at yahoo.com>
>>Cc: "engine-devel at ovirt.org" <engine-devel at ovirt.org>
>>Sent: Wednesday, November 14, 2012 6:36 PM
>>Subject: Re: [Engine-devel] Building oVirt from source
>>
>>On 11/14/2012 11:34 AM, Stephen Liu wrote:
>>> # find / -name jboss-as
>>> find: `/run/user/satimis/gvfs': Permission denied
>>> /home/satimis/jboss-as
>>>
>>> jbozz-as is NOT on /usr/share/jboss-as
>>
>>Then you need to fix your $HOME/.m2/settings.xml file, the jbossHome
>>property must contain the directory where you have installed the
>>application server.
>>
>>> 
>    ------------------------------------------------------------------------
>>>     *From:* Juan Hernandez <jhernand at redhat.com>
>>>     *To:* Stephen Liu <satimis at yahoo.com>
>>>     *Cc:* "engine-devel at ovirt.org" <engine-devel at ovirt.org>
>>>     *Sent:* Wednesday, November 14, 2012 6:23 PM
>>>     *Subject:* Re: [Engine-devel] Building oVirt from source
>>>
>>>     On 11/14/2012 11:10 AM, Stephen Liu wrote:
>>>     >
>>>     > Hi Juan,
>>>     >
>>>     > I have sent another email to the list under the subject:
> "Deploy error
>>>     > again".  But it never came to the list.  Is the server in problem?
>>>     >
>>>     > Subject : Deploy error again
>>>
>>>     I think you are having problems with the permissions in the
>>>     /usr/share/jboss-as directory. Make sure that you have the following
>>>     content in your $HOME/.m2/settings.xml file:
>>>
>>>     <settings
>>>       xmlns="http://maven.apache.org/POM/4.0.0"
> <http://maven.apache.org/POM/4.0.0%22>;
>>>       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> <http://www.w3.org/2001/XMLSchema-instance%22>;
>>>       xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>>>    http://maven.apache.org/xsd/settings-1.0.0.xsd"
> <http://maven.apache.org/xsd/settings-1.0.0.xsd%22>;>
>>>
>>>       <activeProfiles>
>>>         <activeProfile>oVirtEnvSettings</activeProfile>
>>>       </activeProfiles>
>>>
>>>       <profiles>
>>>         <profile>
>>>           <id>oVirtEnvSettings</id>
>>>           <properties>
>>>             <jbossHome>/home/satimis/jboss-as</jbossHome>
>>>           </properties>
>>>         </profile>
>>>       </profiles>
>>>
>>>     </settings>
>>>
>>>     Pay special attention to the "jbossHome" property, it should be the
>>>     directory where you have the application server installed, and
> you need
>>>     to have permissions to write to it. Currently you are using
>>>     /usr/share/jboss-as, and I guess you don't have permissions to write
>>>     there. Install the application server to /home/staimis/jboss-as
> and use
>>>     that instead.


-- 
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 jhernand at redhat.com  Wed Nov 14 10:23:18 2012
From: jhernand at redhat.com (Juan Hernandez)
Date: Wed, 14 Nov 2012 11:23:18 +0100
Subject: [Engine-devel] Building oVirt from source
In-Reply-To: <1352887836.22748.YahooMailNeo@web125102.mail.ne1.yahoo.com>
References: <1352823646.4124.YahooMailNeo@web125104.mail.ne1.yahoo.com>
	<50A36C2C.5030602@redhat.com>
	<1352887836.22748.YahooMailNeo@web125102.mail.ne1.yahoo.com>
Message-ID: <50A37116.1040102@redhat.com>

On 11/14/2012 11:10 AM, Stephen Liu wrote:
> 
> Hi Juan,
> 
> I have sent another email to the list under the subject: "Deploy error
> again".  But it never came to the list.  Is the server in problem?
> 
> Subject : Deploy error again

I think you are having problems with the permissions in the
/usr/share/jboss-as directory. Make sure that you have the following
content in your $HOME/.m2/settings.xml file:

<settings
  xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">

  <activeProfiles>
    <activeProfile>oVirtEnvSettings</activeProfile>
  </activeProfiles>

  <profiles>
    <profile>
      <id>oVirtEnvSettings</id>
      <properties>
        <jbossHome>/home/satimis/jboss-as</jbossHome>
      </properties>
    </profile>
  </profiles>

</settings>

Pay special attention to the "jbossHome" property, it should be the
directory where you have the application server installed, and you need
to have permissions to write to it. Currently you are using
/usr/share/jboss-as, and I guess you don't have permissions to write
there. Install the application server to /home/staimis/jboss-as and use
that instead.

-- 
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 jhernand at redhat.com  Wed Nov 14 10:02:20 2012
From: jhernand at redhat.com (Juan Hernandez)
Date: Wed, 14 Nov 2012 11:02:20 +0100
Subject: [Engine-devel] Building oVirt from source
In-Reply-To: <1352823646.4124.YahooMailNeo@web125104.mail.ne1.yahoo.com>
References: <1352823646.4124.YahooMailNeo@web125104.mail.ne1.yahoo.com>
Message-ID: <50A36C2C.5030602@redhat.com>

On 11/13/2012 05:20 PM, Stephen Liu wrote:
> Hi all,
> 
> Have another round to build oVirt from source following;
> 
> Building Engine Draft
> http://wiki.ovirt.org/wiki/Building_Engine_Draft
> 
> OS - Fedora 17 desktop 64bit, fresh and clean installed.
> 
> Not much problem encountered up to "Installing JBoss AS" except follows:
> 
> 1)
> Maven personal settings
> ==================
> 
> $ mkdir $HOME/.m2
> $ wget -O $HOME/.m2/settings.xml
> http://wiki.ovirt.org/w/images/1/18/Settings.xml.png
> 
> (it should read "http://wiki.ovirt.org/w/images/1/18/Settings.xml.png")
>                                    ^^^^ (not www)
> 
> 2)
> Check that the application server starts correctly:
> 
> $ cd $JBOSS_HOME/bin
> $ ./standalone.sh -b 0.0.0.0
> ===================================================
> 
>   JBoss Bootstrap Environment
> 
>   JBOSS_HOME: /home/satimis/jboss-as
> 
>   JAVA: java
> 
>   JAVA_OPTS:  -server -XX:+UseCompressedOops -XX:+TieredCompilation
> -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true
> -Dorg.jboss.resolver.warning=true
> -Dsun.rmi.dgc.client.gcInterval=3600000
> -Dsun.rmi.dgc.server.gcInterval=3600000
> -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=tr
> ....
> .....
> 
> 22:14:38,217 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874:
> JBoss AS 7.1.1.Final "Brontes" started in 6662ms - Started 133 of 208
> services (74 services are passive or on-demand)
> 
> 
> It hung here;
> 
> Press [Ctrl] + c
> it continued to display:
> 
> 19:49,653 INFO  [org.jboss.as.osgi] (MSC service thread 1-3) JBAS011942:
> Stopping OSGi Framework
> 22:19:49,701 INFO  [org.jboss.as.logging] JBAS011503: Restored bootstrap
> log handlers
> 22:19:49,726 INFO  [org.apache.coyote.http11.Http11Protocol] Pausing
> Coyote HTTP/1.1 on http--0.0.0.0-8080
> 22:19:49,727 INFO  [org.apache.coyote.http11.Http11Protocol] Stopping
> Coyote HTTP/1.1 on http--0.0.0.0-8080
> 22:19:49,729 INFO  [com.arjuna.ats.jbossatx] ARJUNA032018: Destroying
> TransactionManagerService
> 22:19:49,730 INFO  [com.arjuna.ats.jbossatx] ARJUNA032014: Stopping
> transaction recovery manager
> 22:19:49,753 INFO  [org.jboss.as] JBAS015950: JBoss AS 7.1.1.Final
> "Brontes" stopped in 111ms
> 
> Is it normal?  Without problem?

That is normal, when you start the application server from the command
line with standalone.sh it keeps attached to your terminal until you
stop it with Ctrl+C.

-- 
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 masayag at redhat.com  Wed Nov 14 07:16:42 2012
From: masayag at redhat.com (Moti Asayag)
Date: Wed, 14 Nov 2012 09:16:42 +0200
Subject: [Engine-devel] Proposal to add Allon Mureinik as maintainer to
 engine core
In-Reply-To: <50A31A19.7040602@redhat.com>
References: <50A31A19.7040602@redhat.com>
Message-ID: <50A3455A.3020608@redhat.com>

On 11/14/2012 06:12 AM, Itamar Heim wrote:
> Allon has worked on oVirt for the past 10 months.
> With 534 patches ranging from cleanups, to complex features like user
> level api and storage live migration. In addition, Allon has been
> instrumental in the number of patch reviews he has done.
> 
> I'd like to propose Allon as a maintainer of engine core.
> 

+1

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



From satimis at yahoo.com  Wed Nov 14 13:40:14 2012
From: satimis at yahoo.com (Stephen Liu)
Date: Wed, 14 Nov 2012 05:40:14 -0800 (PST)
Subject: [Engine-devel] Building oVirt from source
In-Reply-To: <50A37DCC.40100@redhat.com>
References: <1352823646.4124.YahooMailNeo@web125104.mail.ne1.yahoo.com>
	<50A36C2C.5030602@redhat.com>
	<1352887836.22748.YahooMailNeo@web125102.mail.ne1.yahoo.com>
	<50A37116.1040102@redhat.com>
	<1352889268.47516.YahooMailNeo@web125104.mail.ne1.yahoo.com>
	<50A37420.7090400@redhat.com>
	<1352891345.11371.YahooMailNeo@web125106.mail.ne1.yahoo.com>
	<50A37DCC.40100@redhat.com>
Message-ID: <1352900414.97967.YahooMailNeo@web125102.mail.ne1.yahoo.com>



----- Original Message -----
> From: Juan Hernandez <jhernand at redhat.com>
> To: Stephen Liu <satimis at yahoo.com>
> Cc: Laszlo Hornyak <lhornyak at redhat.com>; "engine-devel at ovirt.org" <engine-devel at ovirt.org>
> Sent: Wednesday, November 14, 2012 7:17 PM
> Subject: Re: [Engine-devel] Building oVirt from source
> 
> On 11/14/2012 12:09 PM, Stephen Liu wrote:
>> 
>>  Hi all,
>> 
>>  $ sudo find / -name .m2
>>  find: `/run/user/satimis/gvfs': Permission denied
>>  /home/satimis/.m2
>> 
>>  $ sudo ls -ald /home/satimis/.m2
>>  drwxrwxr-x. 3 satimis satimis 4096 Nov 14 14:12 /home/satimis/.m2
>> 
>> 
>>  $ cat $HOME/.m2/settings.xml
>>  <settings xmlns="http://maven.apache.org/POM/4.0.0"
>>  <http://maven.apache.org/POM/4.0.0%22>;
>> ? ? ? ? ?  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>  <http://www.w3.org/2001/XMLSchema-instance%22>;
>> ? ? ? ? ?  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>>  http://maven.apache.org/xsd/settings-1.0.0.xsd"
>>  <http://maven.apache.org/xsd/settings-1.0.0.xsd%22>;>
>> 
>>  <!--**************************** PROFILES 
> ****************************-->
>> 
>> ? ? ? ?  <activeProfiles>
>> ? ? ? ? ? ? ? ? ? ? ? ? 
> <activeProfile>oVirtEnvSettings</activeProfile>
>> ? ? ? ?  </activeProfiles>
>> 
>> ? ? ? ?  <profiles>
>> ? ? ? ? ? ?  <profile>
>> ? ? ? ? ? ? ? ?  <id>oVirtEnvSettings</id>
>> ? ? ? ? ? ? ? ? ? ?  <properties>
>> ? ? ? ? ? ? ? ? ? ? ? ? 
> <jbossHome>/usr/share/jboss-as</jbossHome>
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? 
>> 
> <JAVA_HOME>/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/bin/java</JAVA_HOME>
>> ? ? ? ? ? ? ? ? ? ?  </properties>
>> ? ? ? ? ? ?  </profile>
>> ? ? ? ? ? </profiles>
>>  </settings>
> 
> This ^ (/home/satimis/.m2/settings.xml) is the file that you need to
> change, and you need to change the "jbossHome" property so that it
> contains the directory where you actually have the application server
> installed.
> 
> Please remove or fix the JAVA_HOME property as well, as it is not needed
> and pointing a location that doesn't exist in Fedora 17.


Whether to run:-

# mv /home/satimis/jboss-as /usr/share/
# rm -rf /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64
# service jboss-as restart

#> ps ax | grep java (to check jboss running)

Then run again;
$> cd $OVIRT_HOME/ear
$> mvn clean install -Pdep,setup

followed by;
Deploying engine-config & engine-manage-domains

$> cd $OVIRT_HOME
$> make create_dirs
$> make install_tools
$> make install_config

etc.

Stephen L


From satimis at yahoo.com  Wed Nov 14 10:10:36 2012
From: satimis at yahoo.com (Stephen Liu)
Date: Wed, 14 Nov 2012 02:10:36 -0800 (PST)
Subject: [Engine-devel] Building oVirt from source
In-Reply-To: <50A36C2C.5030602@redhat.com>
References: <1352823646.4124.YahooMailNeo@web125104.mail.ne1.yahoo.com>
	<50A36C2C.5030602@redhat.com>
Message-ID: <1352887836.22748.YahooMailNeo@web125102.mail.ne1.yahoo.com>



Hi Juan,

I have sent another email to the list under the subject: "Deploy error again".? But it never came to the list.? Is the server in problem?

Subject : Deploy error again

Failure:-

$ mvn clean install -Pdep,setup
/usr/lib/jvm/java
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for org.ovirt.engine:engine-server-ear:ear:3.1.0
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-ear-plugin is missing. @ line 154, column 15
[WARNING]
 'distributionManagement.repository.id' must not be 'local', this 
identifier is reserved for the local repository, using it for other 
repositories will corrupt your repository metadata. @ line 18, column 11
[WARNING]
[WARNING] It is highly recommended to fix these problems because
 they threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING]
[INFO]??????????????????????????????????????????????????????????????????????? 
[INFO] ------------------------------------------------------------------------
[INFO] Building oVirt Server EAR 3.1.0
[INFO] ------------------------------------------------------------------------
Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-antrun-plugin/1.3/maven-antrun-plugin-1.3.pom
Downloaded:

 
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-antrun-plugin/1.3/maven-antrun-plugin-1.3.pom
 (5 KB at 46.7 KB/sec)
Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-antrun-plugin/1.3/maven-antrun-plugin-1.3.jar
Downloaded:
 
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-antrun-plugin/1.3/maven-antrun-plugin-1.3.jar
 (24 KB at 255.8 KB/sec)
[INFO]
[INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ engine-server-ear ---
[INFO] Deleting /home/satimis/ovirt-engine/ear/target
[INFO]
[INFO] --- maven-antrun-plugin:1.3:run (undeploy) @ engine-server-ear ---
Downloading: http://repo1.maven.org/maven2/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.pom
Downloaded: http://repo1.maven.org/maven2/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.pom (3 KB at 77.6 KB/sec)
Downloading:
 http://repo1.maven.org/maven2/org/apache/ant/ant-parent/1.7.1/ant-parent-1.7.1.pom
Downloaded: http://repo1.maven.org/maven2/org/apache/ant/ant-parent/1.7.1/ant-parent-1.7.1.pom (5 KB at 137.9 KB/sec)
Downloading: http://repo1.maven.org/maven2/org/apache/ant/ant/1.7.1/ant-1.7.1.pom
Downloaded: http://repo1.maven.org/maven2/org/apache/ant/ant/1.7.1/ant-1.7.1.pom (10 KB at 232.4 KB/sec)
Downloading: http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/1.5.6/plexus-utils-1.5.6.jar
Downloading: http://repo1.maven.org/maven2/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.jar
Downloading: http://repo1.maven.org/maven2/org/apache/ant/ant/1.7.1/ant-1.7.1.jar
Downloaded: http://repo1.maven.org/maven2/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.jar (12 KB at 79.1 KB/sec)
Downloaded: http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/1.5.6/plexus-utils-1.5.6.jar (245 KB at 226.5 KB/sec)
Downloaded:
 http://repo1.maven.org/maven2/org/apache/ant/ant/1.7.1/ant-1.7.1.jar (1292 KB at 384.3 KB/sec)
[INFO] Executing tasks
???? [echo] *** Deleting /usr/share/jboss-as/standalone/deployments/engine.ear/...
[INFO] Executed tasks
[INFO]
[INFO] --- maven-ear-plugin:2.6:generate-application-xml (default-generate-application-xml) @ engine-server-ear ---
[INFO] Generating application.xml
[INFO]
[INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ engine-server-ear ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /home/satimis/ovirt-engine/ear/src/main/java
[INFO] Copying 1 resource
[INFO]
[INFO] --- maven-ear-plugin:2.6:ear (default-ear) @ engine-server-ear ---
[INFO] Copying artifact[jar:org.ovirt.engine.core:common:3.1.0] to[lib/engine-common.jar]
[INFO] Copying artifact[jar:org.ovirt.engine.core:compat:3.1.0]
 to[lib/engine-compat.jar]
[INFO] Copying artifact[jar:org.ovirt.engine.core:dal:3.1.0] to[lib/engine-dal.jar]
[INFO] Copying artifact[jar:org.ovirt.engine.core:utils:3.1.0] to[lib/engine-utils.jar]
[INFO] Copying artifact[jar:org.ovirt.engine.core:engineencryptutils:3.1.0] to[lib/engine-encryptutils.jar]
[INFO] Copying artifact[jar:org.ovirt.engine.core:vdsbroker:3.1.0] to[lib/engine-vdsbroker.jar]
[INFO] Copying artifact[war:org.ovirt.engine.core:root-war:3.1.0] to[root.war] (unpacked)
[INFO] Copying artifact[war:org.ovirt.engine.ui:rmw-war:3.1.0] to[ovirtengineweb.war] (unpacked)
[INFO] Copying artifact[war:org.ovirt.engine.api:restapi-webapp:3.1.0] to[restapi.war] (unpacked)
[INFO] Copying artifact[war:org.ovirt.engine.ui:userportal:3.1.0] to[userportal.war] (unpacked)
[INFO] Copying artifact[war:org.ovirt.engine.ui:webadmin:3.1.0] to[webadmin.war] (unpacked)
[INFO] Copying
 artifact[ejb:org.ovirt.engine.ui:genericapi:3.1.0] to[engine-genericapi.jar] (unpacked)
[INFO] Copying artifact[ejb:org.ovirt.engine.core:scheduler:3.1.0] to[engine-scheduler.jar] (unpacked)
[INFO] Copying artifact[ejb:org.ovirt.engine.core:bll:3.1.0] to[engine-bll.jar] (unpacked)
[INFO] Copying artifact[jar:commons-codec:commons-codec:1.4] to[lib/commons-codec-1.4.jar]
[INFO] Copying artifact[jar:org.hibernate:hibernate-validator:4.0.2.GA] to[lib/hibernate-validator-4.0.2.GA.jar]
[INFO] Copying artifact[jar:javax.validation:validation-api:1.0.0.GA] to[lib/validation-api-1.0.0.GA.jar]
[INFO] Copying artifact[jar:org.slf4j:slf4j-api:1.5.6] to[lib/slf4j-api-1.5.6.jar]
[INFO] Copying artifact[jar:javax.xml.bind:jaxb-api:2.1] to[lib/jaxb-api-2.1.jar]
[INFO] Copying artifact[jar:javax.xml.stream:stax-api:1.0-2] to[lib/stax-api-1.0-2.jar]
[INFO] Copying artifact[jar:javax.activation:activation:1.1]
 to[lib/activation-1.1.jar]
[INFO] Copying artifact[jar:com.sun.xml.bind:jaxb-impl:2.1.3] to[lib/jaxb-impl-2.1.3.jar]
[INFO] Copying artifact[jar:org.hibernate:hibernate-annotations:3.4.0.GA] to[lib/hibernate-annotations-3.4.0.GA.jar]
[INFO] Copying artifact[jar:org.hibernate:ejb3-persistence:1.0.2.GA] to[lib/ejb3-persistence-1.0.2.GA.jar]
[INFO]
 Copying 
artifact[jar:org.hibernate:hibernate-commons-annotations:3.1.0.GA] 
to[lib/hibernate-commons-annotations-3.1.0.GA.jar]
[INFO] Copying artifact[jar:org.hibernate:hibernate-core:3.3.0.SP1] to[lib/hibernate-core-3.3.0.SP1.jar]
[INFO] Copying artifact[jar:antlr:antlr:2.7.6] to[lib/antlr-2.7.6.jar]
[INFO] Copying artifact[jar:dom4j:dom4j:1.6.1] to[lib/dom4j-1.6.1.jar]
[INFO] Copying artifact[jar:xml-apis:xml-apis:1.0.b2] to[lib/xml-apis-1.0.b2.jar]
[INFO] Copying artifact[jar:org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.1_spec:1.0.0.Final]
 to[lib/jboss-interceptors-api_1.1_spec-1.0.0.Final.jar]
[INFO] Copying artifact[jar:org.ovirt.engine.core:engine-tools-common:3.1.0] to[lib/engine-tools-common-3.1.0.jar]
[INFO] Copying artifact[jar:commons-beanutils:commons-beanutils:1.8.2] to[lib/commons-beanutils-1.8.2.jar]
[INFO] Copying artifact[jar:org.apache.mina:mina-core:2.0.1] to[lib/mina-core-2.0.1.jar]
[INFO] Copying artifact[jar:org.apache.sshd:sshd-core:0.7.0] to[lib/sshd-core-0.7.0.jar]
[INFO] Copying artifact[jar:org.apache.commons:commons-compress:1.3] to[lib/commons-compress-1.3.jar]
[INFO] Copying artifact[jar:commons-lang:commons-lang:2.4] to[lib/commons-lang-2.4.jar]
[INFO] Copying artifact[jar:org.apache.xmlrpc:xmlrpc-client:3.1.3] to[lib/xmlrpc-client-3.1.3.jar]
[INFO] Copying artifact[jar:org.apache.xmlrpc:xmlrpc-common:3.1.3] to[lib/xmlrpc-common-3.1.3.jar]
[INFO] Copying artifact[jar:org.apache.ws.commons.util:ws-commons-util:1.0.2]
 to[lib/ws-commons-util-1.0.2.jar]
[INFO] Copying artifact[jar:org.springframework:spring-jdbc:3.1.1.RELEASE] to[lib/spring-jdbc-3.1.1.RELEASE.jar]
[INFO] Copying artifact[jar:org.springframework:spring-tx:3.1.1.RELEASE] to[lib/spring-tx-3.1.1.RELEASE.jar]
[INFO] Copying artifact[jar:org.springframework.ldap:spring-ldap-core:1.3.1.RELEASE] to[lib/spring-ldap-core-1.3.1.RELEASE.jar]
[INFO] Copying artifact[jar:commons-httpclient:commons-httpclient:3.1] to[lib/commons-httpclient-3.1.jar]
[INFO] Copying artifact[jar:commons-collections:commons-collections:3.1] to[lib/commons-collections-3.1.jar]
[INFO] Copying artifact[jar:org.quartz-scheduler:quartz:2.1.2] to[lib/quartz-2.1.2.jar]
[INFO] Copying artifact[jar:c3p0:c3p0:0.9.1.1] to[lib/c3p0-0.9.1.1.jar]
[INFO] Copying artifact[jar:org.ovirt.engine.core:searchbackend:3.1.0] to[lib/searchbackend-3.1.0.jar]
[INFO] Copying artifact[jar:org.springframework:spring-core:3.1.1.RELEASE]
 to[lib/spring-core-3.1.1.RELEASE.jar]
[INFO] Copying artifact[jar:org.springframework:spring-asm:3.1.1.RELEASE] to[lib/spring-asm-3.1.1.RELEASE.jar]
[INFO] Copying artifact[jar:org.springframework:spring-beans:3.1.1.RELEASE] to[lib/spring-beans-3.1.1.RELEASE.jar]
[INFO] Copying artifact[jar:org.springframework:spring-context:3.1.1.RELEASE] to[lib/spring-context-3.1.1.RELEASE.jar]
[INFO] Copying artifact[jar:org.springframework:spring-aop:3.1.1.RELEASE] to[lib/spring-aop-3.1.1.RELEASE.jar]
[INFO] Copying artifact[jar:aopalliance:aopalliance:1.0] to[lib/aopalliance-1.0.jar]
[INFO] Copying artifact[jar:org.springframework:spring-expression:3.1.1.RELEASE] to[lib/spring-expression-3.1.1.RELEASE.jar]
[INFO] Copy ear sources to /home/satimis/ovirt-engine/ear/target/engine
[WARNING] resourcesDir is deprecated. Please use the earSourceDirectory property instead.
[INFO] Copy ear resources to
 /home/satimis/ovirt-engine/ear/target/engine
[INFO] Including custom manifest file[/home/satimis/ovirt-engine/ear/target/engine/META-INF/MANIFEST.MF]
[INFO] Building jar: /home/satimis/ovirt-engine/ear/target/engine.ear
[INFO]
[INFO] --- maven-dependency-plugin:2.1:copy (copy-quartz-jar) @ engine-server-ear ---
[INFO] Configured Artifact: org.quartz-scheduler:quartz:2.1.2:jar
[INFO] Copying quartz-2.1.2.jar to /home/satimis/ovirt-engine/ear/target/quartz/quartz-2.1.2.jar
[INFO]
[INFO] --- maven-antrun-plugin:1.3:run (deploy) @ engine-server-ear ---
[INFO] Executing tasks
???? [echo] *** Copying updated files from target/engine/ to /usr/share/jboss-as/standalone/deployments/engine.ear/...
???? [copy] Copying 1168 files to /usr/share/jboss-as/standalone/deployments/engine.ear
????
 [copy] Copying
 
/home/satimis/ovirt-engine/ear/target/engine/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class
 to 
/usr/share/jboss-as/standalone/deployments/engine.ear/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 15.761s
[INFO] Finished at: Wed Nov 14 14:34:56 HKT 2012
[INFO] Final Memory: 16M/295M
[INFO] ------------------------------------------------------------------------
[ERROR]
 Failed to execute goal 
org.apache.maven.plugins:maven-antrun-plugin:1.3:run (deploy) on project
 engine-server-ear: An Ant BuildException has occured: Failed to copy 
/home/satimis/ovirt-engine/ear/target/engine/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class
 to
 
/usr/share/jboss-as/standalone/deployments/engine.ear/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class
 due to java.io.FileNotFoundException 
/usr/share/jboss-as/standalone/deployments/engine.ear/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class
 (No such file or directory) -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException


PluginExecutionException
https://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
.....
You should report this problem to the maintainer of the plugin.


Please help.? How to fix
 this problem and continue?

TIA

B.R.
Stephen L




>________________________________
> From: Juan Hernandez <jhernand at redhat.com>
>To: Stephen Liu <satimis at yahoo.com> 
>Cc: "engine-devel at ovirt.org" <engine-devel at ovirt.org> 
>Sent: Wednesday, November 14, 2012 6:02 PM
>Subject: Re: [Engine-devel] Building oVirt from source
> 
>On 11/13/2012 05:20 PM, Stephen Liu wrote:
>> Hi all,
>> 
>> Have another round to build oVirt from source following;
>> 
>> Building Engine Draft
>> http://wiki.ovirt.org/wiki/Building_Engine_Draft
>> 
>> OS - Fedora 17 desktop 64bit, fresh and clean installed.
>> 
>> Not much problem encountered up to "Installing JBoss AS" except follows:
>> 
>> 1)
>> Maven personal settings
>> ==================
>> 
>> $ mkdir $HOME/.m2
>> $ wget -O $HOME/.m2/settings.xml
>> http://wiki.ovirt.org/w/images/1/18/Settings.xml.png
>> 
>> (it should read "http://wiki.ovirt.org/w/images/1/18/Settings.xml.png")
>>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^^^^ (not www)
>> 
>> 2)
>> Check that the application server starts correctly:
>> 
>> $ cd $JBOSS_HOME/bin
>> $ ./standalone.sh -b 0.0.0.0
>> ===================================================
>> 
>>?  JBoss Bootstrap Environment
>> 
>>?  JBOSS_HOME: /home/satimis/jboss-as
>> 
>>?  JAVA: java
>> 
>>?  JAVA_OPTS:? -server -XX:+UseCompressedOops -XX:+TieredCompilation
>> -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true
>> -Dorg.jboss.resolver.warning=true
>> -Dsun.rmi.dgc.client.gcInterval=3600000
>> -Dsun.rmi.dgc.server.gcInterval=3600000
>> -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=tr
>> ....
>> .....
>> 
>> 22:14:38,217 INFO? [org.jboss.as] (Controller Boot Thread) JBAS015874:
>> JBoss AS 7.1.1.Final "Brontes" started in 6662ms - Started 133 of 208
>> services (74 services are passive or on-demand)
>> 
>> 
>> It hung here;
>> 
>> Press [Ctrl] + c
>> it continued to display:
>> 
>> 19:49,653 INFO? [org.jboss.as.osgi] (MSC service thread 1-3) JBAS011942:
>> Stopping OSGi Framework
>> 22:19:49,701 INFO? [org.jboss.as.logging] JBAS011503: Restored bootstrap
>> log handlers
>> 22:19:49,726 INFO? [org.apache.coyote.http11.Http11Protocol] Pausing
>> Coyote HTTP/1.1 on http--0.0.0.0-8080
>> 22:19:49,727 INFO? [org.apache.coyote.http11.Http11Protocol] Stopping
>> Coyote HTTP/1.1 on http--0.0.0.0-8080
>> 22:19:49,729 INFO? [com.arjuna.ats.jbossatx] ARJUNA032018: Destroying
>> TransactionManagerService
>> 22:19:49,730 INFO? [com.arjuna.ats.jbossatx] ARJUNA032014: Stopping
>> transaction recovery manager
>> 22:19:49,753 INFO? [org.jboss.as] JBAS015950: JBoss AS 7.1.1.Final
>> "Brontes" stopped in 111ms
>> 
>> Is it normal?? Without problem?
>
>That is normal, when you start the application server from the command
>line with standalone.sh it keeps attached to your terminal until you
>stop it with Ctrl+C.
>
>-- 
>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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121114/a5cc4652/attachment.html>

From jhernand at redhat.com  Wed Nov 14 13:51:18 2012
From: jhernand at redhat.com (Juan Hernandez)
Date: Wed, 14 Nov 2012 14:51:18 +0100
Subject: [Engine-devel] Proposal to add Allon Mureinik as maintainer to
 engine core
In-Reply-To: <50A31A19.7040602@redhat.com>
References: <50A31A19.7040602@redhat.com>
Message-ID: <50A3A1D6.3070105@redhat.com>

On 11/14/2012 05:12 AM, Itamar Heim wrote:
> Allon has worked on oVirt for the past 10 months.
> With 534 patches ranging from cleanups, to complex features like user 
> level api and storage live migration. In addition, Allon has been 
> instrumental in the number of patch reviews he has done.
> 
> I'd like to propose Allon as a maintainer of engine core.

+1

-- 
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 satimis at yahoo.com  Wed Nov 14 10:18:03 2012
From: satimis at yahoo.com (Stephen Liu)
Date: Wed, 14 Nov 2012 02:18:03 -0800 (PST)
Subject: [Engine-devel] Building oVirt from source
In-Reply-To: <310628282.9363428.1352882176738.JavaMail.root@redhat.com>
References: <1352881556.51991.YahooMailNeo@web125101.mail.ne1.yahoo.com>
	<310628282.9363428.1352882176738.JavaMail.root@redhat.com>
Message-ID: <1352888283.25478.YahooMailNeo@web125101.mail.ne1.yahoo.com>

Hi Laszlo,

# find / -name engine.ear
find: `/run/user/satimis/gvfs': Permission denied
/home/satimis/ovirt-engine/ear/target/engine.ear

NOT;
/usr/share/jboss-as/standalone/deployments/engine.ear/

# find / -name jboss-as
find: `/run/user/satimis/gvfs': Permission denied
/home/satimis/jboss-as


B.R.
Stephen L






>________________________________
> From: Laszlo Hornyak <lhornyak at redhat.com>
>To: Stephen Liu <satimis at yahoo.com> 
>Cc: engine-devel at ovirt.org 
>Sent: Wednesday, November 14, 2012 4:36 PM
>Subject: Re: [Engine-devel] Building oVirt from source
> 
>Hi,
>
>We may have some infrastructure problems. Looks like gerrit is dead as well :(
>Does this directory exist?
>/usr/share/jboss-as/standalone/deployments/engine.ear/
>
>
>----- Original Message -----
>> From: "Stephen Liu" <satimis at yahoo.com>
>> To: "Laszlo Hornyak" <lhornyak at redhat.com>
>> Cc: engine-devel at ovirt.org
>> Sent: Wednesday, November 14, 2012 9:25:56 AM
>> Subject: Re: [Engine-devel] Building oVirt from source
>> 
>> 
>> 
>> Hi,
>> 
>> I have sent another email to the list under the subject: "Deploy
>> error again". But it never came to the list:
>> 
>> Subject : Deploy error again
>> 
>> Failure:-
>> 
>> $ mvn clean install -Pdep,setup
>> /usr/lib/jvm/java
>> [INFO] Scanning for projects...
>> [WARNING]
>> [WARNING] Some problems were encountered while building the effective
>> model for org.ovirt.engine:engine-server-ear:ear:3.1.0
>> [WARNING] 'build.plugins.plugin.version' for
>> org.apache.maven.plugins:maven-ear-plugin is missing. @ line 154,
>> column 15
>> [WARNING] 'distributionManagement.repository.id' must not be 'local',
>> this identifier is reserved for the local repository, using it for
>> other repositories will corrupt your repository metadata. @ line 18,
>> column 11
>> [WARNING]
>> [WARNING] It is highly recommended to fix these problems because they
>> threaten the stability of your build.
>> [WARNING]
>> [WARNING] For this reason, future Maven versions might no longer
>> support building such malformed projects.
>> [WARNING]
>> [INFO]
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Building oVirt Server EAR 3.1.0
>> [INFO]
>> ------------------------------------------------------------------------
>> Downloading:
>> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-antrun-plugin/1.3/maven-antrun-plugin-1.3.pom
>> Downloaded:
>> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-antrun-plugin/1.3/maven-antrun-plugin-1.3.pom
>> (5 KB at 46.7 KB/sec)
>> Downloading:
>> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-antrun-plugin/1.3/maven-antrun-plugin-1.3.jar
>> Downloaded:
>> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-antrun-plugin/1.3/maven-antrun-plugin-1.3.jar
>> (24 KB at 255.8 KB/sec)
>> [INFO]
>> [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @
>> engine-server-ear ---
>> [INFO] Deleting /home/satimis/ovirt-engine/ear/target
>> [INFO]
>> [INFO] --- maven-antrun-plugin:1.3:run (undeploy) @ engine-server-ear
>> ---
>> Downloading:
>> http://repo1.maven.org/maven2/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.pom
>> Downloaded:
>> http://repo1.maven.org/maven2/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.pom
>> (3 KB at 77.6 KB/sec)
>> Downloading:
>> http://repo1.maven.org/maven2/org/apache/ant/ant-parent/1.7.1/ant-parent-1.7.1.pom
>> Downloaded:
>> http://repo1.maven.org/maven2/org/apache/ant/ant-parent/1.7.1/ant-parent-1.7.1.pom
>> (5 KB at 137.9 KB/sec)
>> Downloading:
>> http://repo1.maven.org/maven2/org/apache/ant/ant/1.7.1/ant-1.7.1.pom
>> Downloaded:
>> http://repo1.maven.org/maven2/org/apache/ant/ant/1.7.1/ant-1.7.1.pom
>> (10 KB at 232.4 KB/sec)
>> Downloading:
>> http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/1.5.6/plexus-utils-1.5.6.jar
>> Downloading:
>> http://repo1.maven.org/maven2/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.jar
>> Downloading:
>> http://repo1.maven.org/maven2/org/apache/ant/ant/1.7.1/ant-1.7.1.jar
>> Downloaded:
>> http://repo1.maven.org/maven2/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.jar
>> (12 KB at 79.1 KB/sec)
>> Downloaded:
>> http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/1.5.6/plexus-utils-1.5.6.jar
>> (245 KB at 226.5 KB/sec)
>> Downloaded:
>> http://repo1.maven.org/maven2/org/apache/ant/ant/1.7.1/ant-1.7.1.jar
>> (1292 KB at 384.3 KB/sec)
>> [INFO] Executing tasks
>> [echo] *** Deleting
>> /usr/share/jboss-as/standalone/deployments/engine.ear/...
>> [INFO] Executed tasks
>> [INFO]
>> [INFO] --- maven-ear-plugin:2.6:generate-application-xml
>> (default-generate-application-xml) @ engine-server-ear ---
>> [INFO] Generating application.xml
>> [INFO]
>> [INFO] --- maven-resources-plugin:2.4.3:resources (default-resources)
>> @ engine-server-ear ---
>> [INFO] Using 'UTF-8' encoding to copy filtered resources.
>> [INFO] skip non existing resourceDirectory
>> /home/satimis/ovirt-engine/ear/src/main/java
>> [INFO] Copying 1 resource
>> [INFO]
>> [INFO] --- maven-ear-plugin:2.6:ear (default-ear) @ engine-server-ear
>> ---
>> [INFO] Copying artifact[jar:org.ovirt.engine.core:common:3.1.0]
>> to[lib/engine-common.jar]
>> [INFO] Copying artifact[jar:org.ovirt.engine.core:compat:3.1.0]
>> to[lib/engine-compat.jar]
>> [INFO] Copying artifact[jar:org.ovirt.engine.core:dal:3.1.0]
>> to[lib/engine-dal.jar]
>> [INFO] Copying artifact[jar:org.ovirt.engine.core:utils:3.1.0]
>> to[lib/engine-utils.jar]
>> [INFO] Copying
>> artifact[jar:org.ovirt.engine.core:engineencryptutils:3.1.0]
>> to[lib/engine-encryptutils.jar]
>> [INFO] Copying artifact[jar:org.ovirt.engine.core:vdsbroker:3.1.0]
>> to[lib/engine-vdsbroker.jar]
>> [INFO] Copying artifact[war:org.ovirt.engine.core:root-war:3.1.0]
>> to[root.war] (unpacked)
>> [INFO] Copying artifact[war:org.ovirt.engine.ui:rmw-war:3.1.0]
>> to[ovirtengineweb.war] (unpacked)
>> [INFO] Copying
>> artifact[war:org.ovirt.engine.api:restapi-webapp:3.1.0]
>> to[restapi.war] (unpacked)
>> [INFO] Copying artifact[war:org.ovirt.engine.ui:userportal:3.1.0]
>> to[userportal.war] (unpacked)
>> [INFO] Copying artifact[war:org.ovirt.engine.ui:webadmin:3.1.0]
>> to[webadmin.war] (unpacked)
>> [INFO] Copying artifact[ejb:org.ovirt.engine.ui:genericapi:3.1.0]
>> to[engine-genericapi.jar] (unpacked)
>> [INFO] Copying artifact[ejb:org.ovirt.engine.core:scheduler:3.1.0]
>> to[engine-scheduler.jar] (unpacked)
>> [INFO] Copying artifact[ejb:org.ovirt.engine.core:bll:3.1.0]
>> to[engine-bll.jar] (unpacked)
>> [INFO] Copying artifact[jar:commons-codec:commons-codec:1.4]
>> to[lib/commons-codec-1.4.jar]
>> [INFO] Copying
>> artifact[jar:org.hibernate:hibernate-validator:4.0.2.GA]
>> to[lib/hibernate-validator-4.0.2.GA.jar]
>> [INFO] Copying artifact[jar:javax.validation:validation-api:1.0.0.GA]
>> to[lib/validation-api-1.0.0.GA.jar]
>> [INFO] Copying artifact[jar:org.slf4j:slf4j-api:1.5.6]
>> to[lib/slf4j-api-1.5.6.jar]
>> [INFO] Copying artifact[jar:javax.xml.bind:jaxb-api:2.1]
>> to[lib/jaxb-api-2.1.jar]
>> [INFO] Copying artifact[jar:javax.xml.stream:stax-api:1.0-2]
>> to[lib/stax-api-1.0-2.jar]
>> [INFO] Copying artifact[jar:javax.activation:activation:1.1]
>> to[lib/activation-1.1.jar]
>> [INFO] Copying artifact[jar:com.sun.xml.bind:jaxb-impl:2.1.3]
>> to[lib/jaxb-impl-2.1.3.jar]
>> [INFO] Copying
>> artifact[jar:org.hibernate:hibernate-annotations:3.4.0.GA]
>> to[lib/hibernate-annotations-3.4.0.GA.jar]
>> [INFO] Copying artifact[jar:org.hibernate:ejb3-persistence:1.0.2.GA]
>> to[lib/ejb3-persistence-1.0.2.GA.jar]
>> [INFO] Copying
>> artifact[jar:org.hibernate:hibernate-commons-annotations:3.1.0.GA]
>> to[lib/hibernate-commons-annotations-3.1.0.GA.jar]
>> [INFO] Copying artifact[jar:org.hibernate:hibernate-core:3.3.0.SP1]
>> to[lib/hibernate-core-3.3.0.SP1.jar]
>> [INFO] Copying artifact[jar:antlr:antlr:2.7.6]
>> to[lib/antlr-2.7.6.jar]
>> [INFO] Copying artifact[jar:dom4j:dom4j:1.6.1]
>> to[lib/dom4j-1.6.1.jar]
>> [INFO] Copying artifact[jar:xml-apis:xml-apis:1.0.b2]
>> to[lib/xml-apis-1.0.b2.jar]
>> [INFO] Copying
>> artifact[jar:org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.1_spec:1.0.0.Final]
>> to[lib/jboss-interceptors-api_1.1_spec-1.0.0.Final.jar]
>> [INFO] Copying
>> artifact[jar:org.ovirt.engine.core:engine-tools-common:3.1.0]
>> to[lib/engine-tools-common-3.1.0.jar]
>> [INFO] Copying
>> artifact[jar:commons-beanutils:commons-beanutils:1.8.2]
>> to[lib/commons-beanutils-1.8.2.jar]
>> [INFO] Copying artifact[jar:org.apache.mina:mina-core:2.0.1]
>> to[lib/mina-core-2.0.1.jar]
>> [INFO] Copying artifact[jar:org.apache.sshd:sshd-core:0.7.0]
>> to[lib/sshd-core-0.7.0.jar]
>> [INFO] Copying artifact[jar:org.apache.commons:commons-compress:1.3]
>> to[lib/commons-compress-1.3.jar]
>> [INFO] Copying artifact[jar:commons-lang:commons-lang:2.4]
>> to[lib/commons-lang-2.4.jar]
>> [INFO] Copying artifact[jar:org.apache.xmlrpc:xmlrpc-client:3.1.3]
>> to[lib/xmlrpc-client-3.1.3.jar]
>> [INFO] Copying artifact[jar:org.apache.xmlrpc:xmlrpc-common:3.1.3]
>> to[lib/xmlrpc-common-3.1.3.jar]
>> [INFO] Copying
>> artifact[jar:org.apache.ws.commons.util:ws-commons-util:1.0.2]
>> to[lib/ws-commons-util-1.0.2.jar]
>> [INFO] Copying
>> artifact[jar:org.springframework:spring-jdbc:3.1.1.RELEASE]
>> to[lib/spring-jdbc-3.1.1.RELEASE.jar]
>> [INFO] Copying
>> artifact[jar:org.springframework:spring-tx:3.1.1.RELEASE]
>> to[lib/spring-tx-3.1.1.RELEASE.jar]
>> [INFO] Copying
>> artifact[jar:org.springframework.ldap:spring-ldap-core:1.3.1.RELEASE]
>> to[lib/spring-ldap-core-1.3.1.RELEASE.jar]
>> [INFO] Copying
>> artifact[jar:commons-httpclient:commons-httpclient:3.1]
>> to[lib/commons-httpclient-3.1.jar]
>> [INFO] Copying
>> artifact[jar:commons-collections:commons-collections:3.1]
>> to[lib/commons-collections-3.1.jar]
>> [INFO] Copying artifact[jar:org.quartz-scheduler:quartz:2.1.2]
>> to[lib/quartz-2.1.2.jar]
>> [INFO] Copying artifact[jar:c3p0:c3p0:0.9.1.1]
>> to[lib/c3p0-0.9.1.1.jar]
>> [INFO] Copying
>> artifact[jar:org.ovirt.engine.core:searchbackend:3.1.0]
>> to[lib/searchbackend-3.1.0.jar]
>> [INFO] Copying
>> artifact[jar:org.springframework:spring-core:3.1.1.RELEASE]
>> to[lib/spring-core-3.1.1.RELEASE.jar]
>> [INFO] Copying
>> artifact[jar:org.springframework:spring-asm:3.1.1.RELEASE]
>> to[lib/spring-asm-3.1.1.RELEASE.jar]
>> [INFO] Copying
>> artifact[jar:org.springframework:spring-beans:3.1.1.RELEASE]
>> to[lib/spring-beans-3.1.1.RELEASE.jar]
>> [INFO] Copying
>> artifact[jar:org.springframework:spring-context:3.1.1.RELEASE]
>> to[lib/spring-context-3.1.1.RELEASE.jar]
>> [INFO] Copying
>> artifact[jar:org.springframework:spring-aop:3.1.1.RELEASE]
>> to[lib/spring-aop-3.1.1.RELEASE.jar]
>> [INFO] Copying artifact[jar:aopalliance:aopalliance:1.0]
>> to[lib/aopalliance-1.0.jar]
>> [INFO] Copying
>> artifact[jar:org.springframework:spring-expression:3.1.1.RELEASE]
>> to[lib/spring-expression-3.1.1.RELEASE.jar]
>> [INFO] Copy ear sources to
>> /home/satimis/ovirt-engine/ear/target/engine
>> [WARNING] resourcesDir is deprecated. Please use the
>> earSourceDirectory property instead.
>> [INFO] Copy ear resources to
>> /home/satimis/ovirt-engine/ear/target/engine
>> [INFO] Including custom manifest
>> file[/home/satimis/ovirt-engine/ear/target/engine/META-INF/MANIFEST.MF]
>> [INFO] Building jar: /home/satimis/ovirt-engine/ear/target/engine.ear
>> [INFO]
>> [INFO] --- maven-dependency-plugin:2.1:copy (copy-quartz-jar) @
>> engine-server-ear ---
>> [INFO] Configured Artifact: org.quartz-scheduler:quartz:2.1.2:jar
>> [INFO] Copying quartz-2.1.2.jar to
>> /home/satimis/ovirt-engine/ear/target/quartz/quartz-2.1.2.jar
>> [INFO]
>> [INFO] --- maven-antrun-plugin:1.3:run (deploy) @ engine-server-ear
>> ---
>> [INFO] Executing tasks
>> [echo] *** Copying updated files from target/engine/ to
>> /usr/share/jboss-as/standalone/deployments/engine.ear/...
>> [copy] Copying 1168 files to
>> /usr/share/jboss-as/standalone/deployments/engine.ear
>> [copy] Copying
>> /home/satimis/ovirt-engine/ear/target/engine/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class
>> to
>> /usr/share/jboss-as/standalone/deployments/engine.ear/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] BUILD FAILURE
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Total time: 15.761s
>> [INFO] Finished at: Wed Nov 14 14:34:56 HKT 2012
>> [INFO] Final Memory: 16M/295M
>> [INFO]
>> ------------------------------------------------------------------------
>> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-antrun-plugin:1.3:run (deploy) on
>> project engine-server-ear: An Ant BuildException has occured: Failed
>> to copy
>> /home/satimis/ovirt-engine/ear/target/engine/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class
>> to
>> /usr/share/jboss-as/standalone/deployments/engine.ear/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class
>> due to java.io.FileNotFoundException
>> /usr/share/jboss-as/standalone/deployments/engine.ear/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class
>> (No such file or directory) -> [Help 1]
>> [ERROR]
>> [ERROR] To see the full stack trace of the errors, re-run Maven with
>> the -e switch.
>> [ERROR] Re-run Maven using the -X switch to enable full debug
>> logging.
>> [ERROR]
>> [ERROR] For more information about the errors and possible solutions,
>> please read the following articles:
>> [ERROR] [Help 1]
>> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
>> 
>> 
>> PluginExecutionException
>> https://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
>> .....
>> You should report this problem to the maintainer of the plugin.
>> 
>> 
>> Please help. How to fix this problem and continue?
>> 
>> TIA
>> 
>> B.R.
>> Stephen L
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> From: Laszlo Hornyak <lhornyak at redhat.com>
>> To: Stephen Liu <satimis at yahoo.com>
>> Cc: engine-devel at ovirt.org
>> Sent: Wednesday, November 14, 2012 3:43 PM
>> Subject: Re: [Engine-devel] Building oVirt from source
>> 
>> 
>> 
>> ----- Original Message -----
>> > From: "Stephen Liu" < satimis at yahoo.com >
>> > To: engine-devel at ovirt.org
>> > Sent: Tuesday, November 13, 2012 5:20:46 PM
>> > Subject: [Engine-devel] Building oVirt from source
>> > 
>> > 
>> > 
>> > 
>> > Hi all,
>> > 
>> > Have another round to build oVirt from source following;
>> > 
>> > Building Engine Draft
>> > http://wiki.ovirt.org/wiki/Building_Engine_Draft
>> > 
>> > OS - Fedora 17 desktop 64bit, fresh and clean installed.
>> > 
>> > Not much problem encountered up to "Installing JBoss AS" except
>> > follows:
>> > 
>> > 1)
>> > Maven personal settings
>> > ==================
>> > 
>> > $ mkdir $HOME/.m2
>> > $ wget -O $HOME/.m2/settings.xml
>> > http://wiki.ovirt.org/w/images/1/18/Settings.xml.png
>> > 
>> > (it should read
>> > " http://wiki.ovirt.org/w/images/1/18/Settings.xml.png ")
>> > ^^^^ (not www)
>> > 
>> > 2)
>> > Check that the application server starts correctly:
>> > 
>> > $ cd $JBOSS_HOME/bin
>> > $ ./standalone.sh -b 0.0.0.0
>> > ===================================================
>> > 
>> > JBoss Bootstrap Environment
>> > 
>> > JBOSS_HOME: /home/satimis/jboss-as
>> > 
>> > JAVA: java
>> > 
>> > JAVA_OPTS: -server -XX:+UseCompressedOops -XX:+TieredCompilation
>> > -Xms64m -Xmx512m -XX:MaxPermSize=256m
>> > -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true
>> > -Dsun.rmi.dgc.client.gcInterval=3600000
>> > -Dsun.rmi.dgc.server.gcInterval=3600000
>> > -Djboss.modules.system.pkgs=org.jboss.byteman
>> > -Djava.awt.headless=tr
>> > ....
>> > .....
>> > 
>> > 22:14:38,217 INFO [org.jboss.as] (Controller Boot Thread)
>> > JBAS015874:
>> > JBoss AS 7.1.1.Final "Brontes" started in 6662ms - Started 133 of
>> > 208 services (74 services are passive or on-demand)
>> 
>> So your jboss is started at this point and should e listening on 8080
>> for http connections. Is ovirt running?
>> If not you should check if it is there in
>> standalone/deployments/engine.ear
>> Also, see if engine.ear.deployed exists. touch engine.dodeploy to
>> kick jboss and deploy it.
>> 
>> > 
>> > 
>> > It hung here;
>> > 
>> > Press [Ctrl] + c
>> > it continued to display:
>> > 
>> > 19:49,653 INFO [org.jboss.as.osgi] (MSC service thread 1-3)
>> > JBAS011942: Stopping OSGi Framework
>> > 22:19:49,701 INFO [org.jboss.as.logging] JBAS011503: Restored
>> > bootstrap log handlers
>> > 22:19:49,726 INFO [org.apache.coyote.http11.Http11Protocol] Pausing
>> > Coyote HTTP/1.1 on http--0.0.0.0-8080
>> > 22:19:49,727 INFO [org.apache.coyote.http11.Http11Protocol]
>> > Stopping
>> > Coyote HTTP/1.1 on http--0.0.0.0-8080
>> > 22:19:49,729 INFO [com.arjuna.ats.jbossatx] ARJUNA032018:
>> > Destroying
>> > TransactionManagerService
>> > 22:19:49,730 INFO [com.arjuna.ats.jbossatx] ARJUNA032014: Stopping
>> > transaction recovery manager
>> > 22:19:49,753 INFO [org.jboss.as] JBAS015950: JBoss AS 7.1.1.Final
>> > "Brontes" stopped in 111ms
>> > 
>> > Is it normal? Without problem?
>> > 
>> > Thanks
>> > 
>> > B.R.
>> > Stephen L
>> > _______________________________________________
>> > Engine-devel mailing list
>> > Engine-devel at ovirt.org
>> > http://lists.ovirt.org/mailman/listinfo/engine-devel
>> > 
>> 
>> 
>> 
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121114/12f678b1/attachment.html>

From derez at redhat.com  Wed Nov 14 14:00:22 2012
From: derez at redhat.com (Daniel Erez)
Date: Wed, 14 Nov 2012 09:00:22 -0500 (EST)
Subject: [Engine-devel] Proposal to add Allon Mureinik as maintainer
	to	engine core
In-Reply-To: <50A31A19.7040602@redhat.com>
Message-ID: <439468570.7503412.1352901622764.JavaMail.root@redhat.com>

+1

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Wednesday, November 14, 2012 6:12:09 AM
> Subject: [Engine-devel] Proposal to add Allon Mureinik as maintainer to	engine core
> 
> Allon has worked on oVirt for the past 10 months.
> With 534 patches ranging from cleanups, to complex features like user
> level api and storage live migration. In addition, Allon has been
> instrumental in the number of patch reviews he has done.
> 
> I'd like to propose Allon as a maintainer of engine core.
> 
> Thanks,
>     Itamar
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From satimis at yahoo.com  Wed Nov 14 06:56:29 2012
From: satimis at yahoo.com (Stephen Liu)
Date: Tue, 13 Nov 2012 22:56:29 -0800 (PST)
Subject: [Engine-devel] Deploy error again
Message-ID: <1352876189.81457.YahooMailNeo@web125101.mail.ne1.yahoo.com>

$ mvn clean install -Pdep,setup
/usr/lib/jvm/java
[INFO] Scanning for projects...
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for org.ovirt.engine:engine-server-ear:ear:3.1.0
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-ear-plugin is missing. @ line 154, column 15
[WARNING] 'distributionManagement.repository.id' must not be 'local', this identifier is reserved for the local repository, using it for other repositories will corrupt your repository metadata. @ line 18, column 11
[WARNING] 
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING] 
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING] 
[INFO]???????????????????????????????????????????????????????????????????????? 
[INFO] ------------------------------------------------------------------------
[INFO] Building oVirt Server EAR 3.1.0
[INFO] ------------------------------------------------------------------------
Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-antrun-plugin/1.3/maven-antrun-plugin-1.3.pom
Downloaded: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-antrun-plugin/1.3/maven-antrun-plugin-1.3.pom (5 KB at 46.7 KB/sec)
Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-antrun-plugin/1.3/maven-antrun-plugin-1.3.jar
Downloaded: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-antrun-plugin/1.3/maven-antrun-plugin-1.3.jar (24 KB at 255.8 KB/sec)
[INFO] 
[INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ engine-server-ear ---
[INFO] Deleting /home/satimis/ovirt-engine/ear/target
[INFO] 
[INFO] --- maven-antrun-plugin:1.3:run (undeploy) @ engine-server-ear ---
Downloading: http://repo1.maven.org/maven2/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.pom
Downloaded: http://repo1.maven.org/maven2/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.pom (3 KB at 77.6 KB/sec)
Downloading: http://repo1.maven.org/maven2/org/apache/ant/ant-parent/1.7.1/ant-parent-1.7.1.pom
Downloaded: http://repo1.maven.org/maven2/org/apache/ant/ant-parent/1.7.1/ant-parent-1.7.1.pom (5 KB at 137.9 KB/sec)
Downloading: http://repo1.maven.org/maven2/org/apache/ant/ant/1.7.1/ant-1.7.1.pom
Downloaded: http://repo1.maven.org/maven2/org/apache/ant/ant/1.7.1/ant-1.7.1.pom (10 KB at 232.4 KB/sec)
Downloading: http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/1.5.6/plexus-utils-1.5.6.jar
Downloading: http://repo1.maven.org/maven2/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.jar
Downloading: http://repo1.maven.org/maven2/org/apache/ant/ant/1.7.1/ant-1.7.1.jar
Downloaded: http://repo1.maven.org/maven2/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.jar (12 KB at 79.1 KB/sec)
Downloaded: http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/1.5.6/plexus-utils-1.5.6.jar (245 KB at 226.5 KB/sec)
Downloaded: http://repo1.maven.org/maven2/org/apache/ant/ant/1.7.1/ant-1.7.1.jar (1292 KB at 384.3 KB/sec)
[INFO] Executing tasks
???? [echo] *** Deleting /usr/share/jboss-as/standalone/deployments/engine.ear/...
[INFO] Executed tasks
[INFO] 
[INFO] --- maven-ear-plugin:2.6:generate-application-xml (default-generate-application-xml) @ engine-server-ear ---
[INFO] Generating application.xml
[INFO] 
[INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ engine-server-ear ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /home/satimis/ovirt-engine/ear/src/main/java
[INFO] Copying 1 resource
[INFO] 
[INFO] --- maven-ear-plugin:2.6:ear (default-ear) @ engine-server-ear ---
[INFO] Copying artifact[jar:org.ovirt.engine.core:common:3.1.0] to[lib/engine-common.jar]
[INFO] Copying artifact[jar:org.ovirt.engine.core:compat:3.1.0] to[lib/engine-compat.jar]
[INFO] Copying artifact[jar:org.ovirt.engine.core:dal:3.1.0] to[lib/engine-dal.jar]
[INFO] Copying artifact[jar:org.ovirt.engine.core:utils:3.1.0] to[lib/engine-utils.jar]
[INFO] Copying artifact[jar:org.ovirt.engine.core:engineencryptutils:3.1.0] to[lib/engine-encryptutils.jar]
[INFO] Copying artifact[jar:org.ovirt.engine.core:vdsbroker:3.1.0] to[lib/engine-vdsbroker.jar]
[INFO] Copying artifact[war:org.ovirt.engine.core:root-war:3.1.0] to[root.war] (unpacked)
[INFO] Copying artifact[war:org.ovirt.engine.ui:rmw-war:3.1.0] to[ovirtengineweb.war] (unpacked)
[INFO] Copying artifact[war:org.ovirt.engine.api:restapi-webapp:3.1.0] to[restapi.war] (unpacked)
[INFO] Copying artifact[war:org.ovirt.engine.ui:userportal:3.1.0] to[userportal.war] (unpacked)
[INFO] Copying artifact[war:org.ovirt.engine.ui:webadmin:3.1.0] to[webadmin.war] (unpacked)
[INFO] Copying artifact[ejb:org.ovirt.engine.ui:genericapi:3.1.0] to[engine-genericapi.jar] (unpacked)
[INFO] Copying artifact[ejb:org.ovirt.engine.core:scheduler:3.1.0] to[engine-scheduler.jar] (unpacked)
[INFO] Copying artifact[ejb:org.ovirt.engine.core:bll:3.1.0] to[engine-bll.jar] (unpacked)
[INFO] Copying artifact[jar:commons-codec:commons-codec:1.4] to[lib/commons-codec-1.4.jar]
[INFO] Copying artifact[jar:org.hibernate:hibernate-validator:4.0.2.GA] to[lib/hibernate-validator-4.0.2.GA.jar]
[INFO] Copying artifact[jar:javax.validation:validation-api:1.0.0.GA] to[lib/validation-api-1.0.0.GA.jar]
[INFO] Copying artifact[jar:org.slf4j:slf4j-api:1.5.6] to[lib/slf4j-api-1.5.6.jar]
[INFO] Copying artifact[jar:javax.xml.bind:jaxb-api:2.1] to[lib/jaxb-api-2.1.jar]
[INFO] Copying artifact[jar:javax.xml.stream:stax-api:1.0-2] to[lib/stax-api-1.0-2.jar]
[INFO] Copying artifact[jar:javax.activation:activation:1.1] to[lib/activation-1.1.jar]
[INFO] Copying artifact[jar:com.sun.xml.bind:jaxb-impl:2.1.3] to[lib/jaxb-impl-2.1.3.jar]
[INFO] Copying artifact[jar:org.hibernate:hibernate-annotations:3.4.0.GA] to[lib/hibernate-annotations-3.4.0.GA.jar]
[INFO] Copying artifact[jar:org.hibernate:ejb3-persistence:1.0.2.GA] to[lib/ejb3-persistence-1.0.2.GA.jar]
[INFO] Copying artifact[jar:org.hibernate:hibernate-commons-annotations:3.1.0.GA] to[lib/hibernate-commons-annotations-3.1.0.GA.jar]
[INFO] Copying artifact[jar:org.hibernate:hibernate-core:3.3.0.SP1] to[lib/hibernate-core-3.3.0.SP1.jar]
[INFO] Copying artifact[jar:antlr:antlr:2.7.6] to[lib/antlr-2.7.6.jar]
[INFO] Copying artifact[jar:dom4j:dom4j:1.6.1] to[lib/dom4j-1.6.1.jar]
[INFO] Copying artifact[jar:xml-apis:xml-apis:1.0.b2] to[lib/xml-apis-1.0.b2.jar]
[INFO] Copying artifact[jar:org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.1_spec:1.0.0.Final] to[lib/jboss-interceptors-api_1.1_spec-1.0.0.Final.jar]
[INFO] Copying artifact[jar:org.ovirt.engine.core:engine-tools-common:3.1.0] to[lib/engine-tools-common-3.1.0.jar]
[INFO] Copying artifact[jar:commons-beanutils:commons-beanutils:1.8.2] to[lib/commons-beanutils-1.8.2.jar]
[INFO] Copying artifact[jar:org.apache.mina:mina-core:2.0.1] to[lib/mina-core-2.0.1.jar]
[INFO] Copying artifact[jar:org.apache.sshd:sshd-core:0.7.0] to[lib/sshd-core-0.7.0.jar]
[INFO] Copying artifact[jar:org.apache.commons:commons-compress:1.3] to[lib/commons-compress-1.3.jar]
[INFO] Copying artifact[jar:commons-lang:commons-lang:2.4] to[lib/commons-lang-2.4.jar]
[INFO] Copying artifact[jar:org.apache.xmlrpc:xmlrpc-client:3.1.3] to[lib/xmlrpc-client-3.1.3.jar]
[INFO] Copying artifact[jar:org.apache.xmlrpc:xmlrpc-common:3.1.3] to[lib/xmlrpc-common-3.1.3.jar]
[INFO] Copying artifact[jar:org.apache.ws.commons.util:ws-commons-util:1.0.2] to[lib/ws-commons-util-1.0.2.jar]
[INFO] Copying artifact[jar:org.springframework:spring-jdbc:3.1.1.RELEASE] to[lib/spring-jdbc-3.1.1.RELEASE.jar]
[INFO] Copying artifact[jar:org.springframework:spring-tx:3.1.1.RELEASE] to[lib/spring-tx-3.1.1.RELEASE.jar]
[INFO] Copying artifact[jar:org.springframework.ldap:spring-ldap-core:1.3.1.RELEASE] to[lib/spring-ldap-core-1.3.1.RELEASE.jar]
[INFO] Copying artifact[jar:commons-httpclient:commons-httpclient:3.1] to[lib/commons-httpclient-3.1.jar]
[INFO] Copying artifact[jar:commons-collections:commons-collections:3.1] to[lib/commons-collections-3.1.jar]
[INFO] Copying artifact[jar:org.quartz-scheduler:quartz:2.1.2] to[lib/quartz-2.1.2.jar]
[INFO] Copying artifact[jar:c3p0:c3p0:0.9.1.1] to[lib/c3p0-0.9.1.1.jar]
[INFO] Copying artifact[jar:org.ovirt.engine.core:searchbackend:3.1.0] to[lib/searchbackend-3.1.0.jar]
[INFO] Copying artifact[jar:org.springframework:spring-core:3.1.1.RELEASE] to[lib/spring-core-3.1.1.RELEASE.jar]
[INFO] Copying artifact[jar:org.springframework:spring-asm:3.1.1.RELEASE] to[lib/spring-asm-3.1.1.RELEASE.jar]
[INFO] Copying artifact[jar:org.springframework:spring-beans:3.1.1.RELEASE] to[lib/spring-beans-3.1.1.RELEASE.jar]
[INFO] Copying artifact[jar:org.springframework:spring-context:3.1.1.RELEASE] to[lib/spring-context-3.1.1.RELEASE.jar]
[INFO] Copying artifact[jar:org.springframework:spring-aop:3.1.1.RELEASE] to[lib/spring-aop-3.1.1.RELEASE.jar]
[INFO] Copying artifact[jar:aopalliance:aopalliance:1.0] to[lib/aopalliance-1.0.jar]
[INFO] Copying artifact[jar:org.springframework:spring-expression:3.1.1.RELEASE] to[lib/spring-expression-3.1.1.RELEASE.jar]
[INFO] Copy ear sources to /home/satimis/ovirt-engine/ear/target/engine
[WARNING] resourcesDir is deprecated. Please use the earSourceDirectory property instead.
[INFO] Copy ear resources to /home/satimis/ovirt-engine/ear/target/engine
[INFO] Including custom manifest file[/home/satimis/ovirt-engine/ear/target/engine/META-INF/MANIFEST.MF]
[INFO] Building jar: /home/satimis/ovirt-engine/ear/target/engine.ear
[INFO] 
[INFO] --- maven-dependency-plugin:2.1:copy (copy-quartz-jar) @ engine-server-ear ---
[INFO] Configured Artifact: org.quartz-scheduler:quartz:2.1.2:jar
[INFO] Copying quartz-2.1.2.jar to /home/satimis/ovirt-engine/ear/target/quartz/quartz-2.1.2.jar
[INFO] 
[INFO] --- maven-antrun-plugin:1.3:run (deploy) @ engine-server-ear ---
[INFO] Executing tasks
???? [echo] *** Copying updated files from target/engine/ to /usr/share/jboss-as/standalone/deployments/engine.ear/...
???? [copy] Copying 1168 files to /usr/share/jboss-as/standalone/deployments/engine.ear
???? [copy] Copying /home/satimis/ovirt-engine/ear/target/engine/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class to /usr/share/jboss-as/standalone/deployments/engine.ear/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 15.761s
[INFO] Finished at: Wed Nov 14 14:34:56 HKT 2012
[INFO] Final Memory: 16M/295M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.3:run (deploy) on project engine-server-ear: An Ant BuildException has occured: Failed to copy /home/satimis/ovirt-engine/ear/target/engine/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class to /usr/share/jboss-as/standalone/deployments/engine.ear/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class due to java.io.FileNotFoundException /usr/share/jboss-as/standalone/deployments/engine.ear/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class (No such file or directory) -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException


PluginExecutionException
https://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
.....
You should report this problem to the maintainer of the plugin.



Please help.? How to fix this problem and continue?

TIA

B.R.
Stephen L
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121113/fd274f9c/attachment.html>

From satimis at yahoo.com  Wed Nov 14 10:34:28 2012
From: satimis at yahoo.com (Stephen Liu)
Date: Wed, 14 Nov 2012 02:34:28 -0800 (PST)
Subject: [Engine-devel] Building oVirt from source
In-Reply-To: <50A37116.1040102@redhat.com>
References: <1352823646.4124.YahooMailNeo@web125104.mail.ne1.yahoo.com>
	<50A36C2C.5030602@redhat.com>
	<1352887836.22748.YahooMailNeo@web125102.mail.ne1.yahoo.com>
	<50A37116.1040102@redhat.com>
Message-ID: <1352889268.47516.YahooMailNeo@web125104.mail.ne1.yahoo.com>

Hi,

# find / -name jboss-as
find: `/run/user/satimis/gvfs': Permission denied
/home/satimis/jboss-as

jbozz-as is NOT on /usr/share/jboss-as


Stephen L





>________________________________
> From: Juan Hernandez <jhernand at redhat.com>
>To: Stephen Liu <satimis at yahoo.com> 
>Cc: "engine-devel at ovirt.org" <engine-devel at ovirt.org> 
>Sent: Wednesday, November 14, 2012 6:23 PM
>Subject: Re: [Engine-devel] Building oVirt from source
> 
>On 11/14/2012 11:10 AM, Stephen Liu wrote:
>> 
>> Hi Juan,
>> 
>> I have sent another email to the list under the subject: "Deploy error
>> again".? But it never came to the list.? Is the server in problem?
>> 
>> Subject : Deploy error again
>
>I think you are having problems with the permissions in the
>/usr/share/jboss-as directory. Make sure that you have the following
>content in your $HOME/.m2/settings.xml file:
>
><settings
>? xmlns="http://maven.apache.org/POM/4.0.0"
>? xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>? xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>http://maven.apache.org/xsd/settings-1.0.0.xsd">
>
>? <activeProfiles>
>? ? <activeProfile>oVirtEnvSettings</activeProfile>
>? </activeProfiles>
>
>? <profiles>
>? ? <profile>
>? ? ? <id>oVirtEnvSettings</id>
>? ? ? <properties>
>? ? ? ? <jbossHome>/home/satimis/jboss-as</jbossHome>
>? ? ? </properties>
>? ? </profile>
>? </profiles>
>
></settings>
>
>Pay special attention to the "jbossHome" property, it should be the
>directory where you have the application server installed, and you need
>to have permissions to write to it. Currently you are using
>/usr/share/jboss-as, and I guess you don't have permissions to write
>there. Install the application server to /home/staimis/jboss-as and use
>that instead.
>
>-- 
>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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121114/d1910a3b/attachment.html>

From lhornyak at redhat.com  Wed Nov 14 14:44:24 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Wed, 14 Nov 2012 09:44:24 -0500 (EST)
Subject: [Engine-devel] ovirt blogs
In-Reply-To: <1231988093.9358826.1352879620797.JavaMail.root@redhat.com>
Message-ID: <1830171686.9494920.1352904264879.JavaMail.root@redhat.com>

Hi,

I have collected some ovirt-related blogs here: http://wiki.ovirt.org/wiki/Ovirt_blogs

Feel free to add yours, or send me directly and I will add it to the list.

Thx,
Laszlo


From satimis at yahoo.com  Wed Nov 14 11:09:05 2012
From: satimis at yahoo.com (Stephen Liu)
Date: Wed, 14 Nov 2012 03:09:05 -0800 (PST)
Subject: [Engine-devel] Building oVirt from source
In-Reply-To: <50A37420.7090400@redhat.com>
References: <1352823646.4124.YahooMailNeo@web125104.mail.ne1.yahoo.com>
	<50A36C2C.5030602@redhat.com>
	<1352887836.22748.YahooMailNeo@web125102.mail.ne1.yahoo.com>
	<50A37116.1040102@redhat.com>
	<1352889268.47516.YahooMailNeo@web125104.mail.ne1.yahoo.com>
	<50A37420.7090400@redhat.com>
Message-ID: <1352891345.11371.YahooMailNeo@web125106.mail.ne1.yahoo.com>



Hi all,

$ sudo find / -name .m2
find: `/run/user/satimis/gvfs': Permission denied
/home/satimis/.m2

$ sudo ls -ald /home/satimis/.m2
drwxrwxr-x. 3 satimis satimis 4096 Nov 14 14:12 /home/satimis/.m2


$ cat $HOME/.m2/settings.xml
<settings xmlns="http://maven.apache.org/POM/4.0.0";
????????? xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
????????? xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd";>

<!--**************************** PROFILES ****************************-->

??????? <activeProfiles>
??????????????????????? <activeProfile>oVirtEnvSettings</activeProfile>
??????? </activeProfiles>

??????? <profiles>
??????? ??? <profile>
??????? ??? ??? <id>oVirtEnvSettings</id>
??? ??????????????? <properties>
??????? ??? ??????? ??? <jbossHome>/usr/share/jboss-as</jbossHome>
??????????????? ??? ??????? <JAVA_HOME>/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/bin/java</JAVA_HOME>
??? ??????????????? </properties>
??????? ??? </profile>
???????? </profiles>
</settings>

This file is on /home/satimis/.m2/

$ locate settings.xml
/home/satimis/.m2/settings.xml
/usr/share/maven/conf/settings.xml
/usr/share/mime/application/x-cisco-vpn-settings.xml

There are 2 settings.xml files

I attend the later file on /usr/share/maven/conf/settings.xml to this email

B.R.
Stephen L




>________________________________
> From: Juan Hernandez <jhernand at redhat.com>
>To: Stephen Liu <satimis at yahoo.com> 
>Cc: "engine-devel at ovirt.org" <engine-devel at ovirt.org> 
>Sent: Wednesday, November 14, 2012 6:36 PM
>Subject: Re: [Engine-devel] Building oVirt from source
> 
>On 11/14/2012 11:34 AM, Stephen Liu wrote:
>> # find / -name jboss-as
>> find: `/run/user/satimis/gvfs': Permission denied
>> /home/satimis/jboss-as
>> 
>> jbozz-as is NOT on /usr/share/jboss-as
>
>Then you need to fix your $HOME/.m2/settings.xml file, the jbossHome
>property must contain the directory where you have installed the
>application server.
>
>>? ???------------------------------------------------------------------------
>>? ???*From:* Juan Hernandez <jhernand at redhat.com>
>>? ???*To:* Stephen Liu <satimis at yahoo.com>
>>? ???*Cc:* "engine-devel at ovirt.org" <engine-devel at ovirt.org>
>>? ???*Sent:* Wednesday, November 14, 2012 6:23 PM
>>? ???*Subject:* Re: [Engine-devel] Building oVirt from source
>> 
>>? ???On 11/14/2012 11:10 AM, Stephen Liu wrote:
>>? ???>
>>? ???> Hi Juan,
>>? ???>
>>? ???> I have sent another email to the list under the subject: "Deploy error
>>? ???> again".? But it never came to the list.? Is the server in problem?
>>? ???>
>>? ???> Subject : Deploy error again
>> 
>>? ???I think you are having problems with the permissions in the
>>? ???/usr/share/jboss-as directory. Make sure that you have the following
>>? ???content in your $HOME/.m2/settings.xml file:
>> 
>>? ???<settings
>>? ? ???xmlns="http://maven.apache.org/POM/4.0.0";
>>? ? ???xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>>? ? ???xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>>? ? http://maven.apache.org/xsd/settings-1.0.0.xsd";>
>> 
>>? ? ???<activeProfiles>
>>? ? ? ???<activeProfile>oVirtEnvSettings</activeProfile>
>>? ? ???</activeProfiles>
>> 
>>? ? ???<profiles>
>>? ? ? ???<profile>
>>? ? ? ? ???<id>oVirtEnvSettings</id>
>>? ? ? ? ???<properties>
>>? ? ? ? ? ???<jbossHome>/home/satimis/jboss-as</jbossHome>
>>? ? ? ? ???</properties>
>>? ? ? ???</profile>
>>? ? ???</profiles>
>> 
>>? ???</settings>
>> 
>>? ???Pay special attention to the "jbossHome" property, it should be the
>>? ???directory where you have the application server installed, and you need
>>? ???to have permissions to write to it. Currently you are using
>>? ???/usr/share/jboss-as, and I guess you don't have permissions to write
>>? ???there. Install the application server to /home/staimis/jboss-as and use
>>? ???that instead.
>> 
>>? ???-- 
>>? ???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.
>> 
>> 
>
>
>-- 
>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.
>
>
>????????????????????????????? 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121114/23617cc2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: settings.xml
Type: application/octet-stream
Size: 10224 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121114/23617cc2/attachment.obj>

From Christopher.Morrissey at netapp.com  Wed Nov 14 14:53:41 2012
From: Christopher.Morrissey at netapp.com (Morrissey, Christopher)
Date: Wed, 14 Nov 2012 14:53:41 +0000
Subject: [Engine-devel] Unable to view the storage domains - SQL error
In-Reply-To: <594204690.9425857.1352890911109.JavaMail.root@redhat.com>
References: <1533070984.31325703.1352862137082.JavaMail.root@redhat.com>
	<594204690.9425857.1352890911109.JavaMail.root@redhat.com>
Message-ID: <D290AD8432118048947689BA3AE8A9B3EBB8B6@SACEXCMBX04-PRD.hq.netapp.com>

Thanks for the advice. I rebuild my DB and it seems to be working now. I'll make sure to do that whenever pulling down new code in the future.

-Chris


-----Original Message-----
From: Laszlo Hornyak [mailto:lhornyak at redhat.com] 
Sent: Wednesday, November 14, 2012 6:02 AM
To: Yair Zaslavsky; Morrissey, Christopher
Cc: engine-devel at ovirt.org
Subject: Re: [Engine-devel] Unable to view the storage domains - SQL error

hi,

The search queries generate these statements. It looks like something replaced the underscores with spaces in the view names, and that is not good for SQL. But the backend should not do this, maybe only restapi replaces something in the erromessages?
Possibly the db upgrade failed somewhere and it left the schema without views?


----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> To: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, November 14, 2012 4:02:17 AM
> Subject: Re: [Engine-devel] Unable to view the storage domains - SQL 
> error
> 
> 
> 
> Hi Christopher,
> In general - as a developer at engine project, I would recommend to 
> run the upgrade script on a frequent basis.
> What troubles me with the query you sent (maybe some problematic copy 
> paste issue?) are the following issues:
> a. storage domains for search - not sure what this is b. storage 
> domains with hosts view - I guess you have some underline issue at the 
> copy paste.
> 
> 
> I would appreciate if you attach engine.log (or a part of it that 
> reflects the error you encountered)
> 
> 
> Kind regards,
> Yair
> 
> 
> 
> 
> 
> 
> From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
> To: engine-devel at ovirt.org
> Sent: Wednesday, November 14, 2012 12:10:14 AM
> Subject: [Engine-devel] Unable to view the storage domains - SQL error
> 
> 
> 
> 
> Hi All,
> 
> 
> 
> I?m getting an error when trying to view the storage domains using the 
> REST API:
> 
> 
> 
> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> 
> <fault>
> 
> <reason>Operation Failed</reason>
> 
> <detail>statementcallback; bad sql grammar [select * from (select * 
> from storage domains for search where ( id in (select storage domains 
> with hosts view.id from storage domains with hosts view )) order by 
> storage name asc ) as t1 offset (1 -1) limit 100]; nested exception is 
> org.postgresql.util.psqlexception: error: relation "storage domains 
> for search" does not exist position: 30</detail>
> 
> </fault>
> 
> 
> 
> Also, through the web admin console, when viewing the storage domains 
> the list never loads.
> 
> 
> 
> Did something change in the DB recently such that I would need to 
> rebuild it?
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -Chris
> 
> 
> 
> Chris Morrissey
> 
> Software Engineer
> 
> NetApp Inc.
> 
> 919.476.4428
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 

From berrange at redhat.com  Wed Nov 14 15:07:15 2012
From: berrange at redhat.com (Daniel P. Berrange)
Date: Wed, 14 Nov 2012 15:07:15 +0000
Subject: [Engine-devel] ovirt blogs
In-Reply-To: <1830171686.9494920.1352904264879.JavaMail.root@redhat.com>
References: <1231988093.9358826.1352879620797.JavaMail.root@redhat.com>
	<1830171686.9494920.1352904264879.JavaMail.root@redhat.com>
Message-ID: <20121114150714.GK3713@redhat.com>

On Wed, Nov 14, 2012 at 09:44:24AM -0500, Laszlo Hornyak wrote:
> Hi,
> 
> I have collected some ovirt-related blogs here: http://wiki.ovirt.org/wiki/Ovirt_blogs
> 
> Feel free to add yours, or send me directly and I will add it to the list.

Sounds like the project needs to have a planet blog aggregator to
collate people's blogs....


Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|


From ewoud+ovirt at kohlvanwijngaarden.nl  Wed Nov 14 15:29:07 2012
From: ewoud+ovirt at kohlvanwijngaarden.nl (Ewoud Kohl van Wijngaarden)
Date: Wed, 14 Nov 2012 16:29:07 +0100
Subject: [Engine-devel] ovirt blogs
In-Reply-To: <20121114150714.GK3713@redhat.com>
References: <1231988093.9358826.1352879620797.JavaMail.root@redhat.com>
	<1830171686.9494920.1352904264879.JavaMail.root@redhat.com>
	<20121114150714.GK3713@redhat.com>
Message-ID: <20121114152907.GJ2094@bogey.xentower.nl>

On Wed, Nov 14, 2012 at 03:07:15PM +0000, Daniel P. Berrange wrote:
> On Wed, Nov 14, 2012 at 09:44:24AM -0500, Laszlo Hornyak wrote:
> > Hi,
> > 
> > I have collected some ovirt-related blogs here: http://wiki.ovirt.org/wiki/Ovirt_blogs
> > 
> > Feel free to add yours, or send me directly and I will add it to the list.
> 
> Sounds like the project needs to have a planet blog aggregator to
> collate people's blogs....

I do have http://planet-ovirt.ekohl.nl/ where I aggregate them, but it's
a very minimal configuration. Since I only read it through RSS that's OK
for me. Config is available on http://planet-ovirt.ekohl.nl/planet.conf
and it's running planet-venus (http://www.intertwingly.net/code/venus/)
from debian squeeze.


From ykaul at redhat.com  Wed Nov 14 15:34:54 2012
From: ykaul at redhat.com (Yaniv Kaul)
Date: Wed, 14 Nov 2012 17:34:54 +0200
Subject: [Engine-devel] Network Wiring
In-Reply-To: <999476552.1216069.1352818012177.JavaMail.root@redhat.com>
References: <999476552.1216069.1352818012177.JavaMail.root@redhat.com>
Message-ID: <50A3BA1E.30707@redhat.com>

On 11/13/2012 04:46 PM, Alona Kaplan wrote:
> Hi all,
>
> Please review the wiki and add your comments.
>
> http://wiki.ovirt.org/wiki/Feature/NetworkWiring
>
>
> Thanks,
> Alona.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel

The wording is wrong.
You PLUG/UNPLUG a cable.
You REMOVE/INSERT a card.

unwired means wireless.

Missing from the design is what actually happening. I assume you change 
the link state. It might be worth while to just use 'link state: 
up/down'. Anyone can understand that.
Y.




From satimis at yahoo.com  Wed Nov 14 08:25:56 2012
From: satimis at yahoo.com (Stephen Liu)
Date: Wed, 14 Nov 2012 00:25:56 -0800 (PST)
Subject: [Engine-devel] Building oVirt from source
In-Reply-To: <1544042310.9356324.1352879008391.JavaMail.root@redhat.com>
References: <1352823646.4124.YahooMailNeo@web125104.mail.ne1.yahoo.com>
	<1544042310.9356324.1352879008391.JavaMail.root@redhat.com>
Message-ID: <1352881556.51991.YahooMailNeo@web125101.mail.ne1.yahoo.com>

Hi,

I have sent another email to the list under the subject: "Deploy error again".? But it never came to the list:

Subject : Deploy error again

Failure:-

$ mvn clean install -Pdep,setup
/usr/lib/jvm/java
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for org.ovirt.engine:engine-server-ear:ear:3.1.0
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-ear-plugin is missing. @ line 154, column 15
[WARNING] 'distributionManagement.repository.id' must not be 'local', this identifier is reserved for the local repository, using it for other repositories will corrupt your repository metadata. @ line 18, column 11
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING]
[INFO]??????????????????????????????????????????????????????????????????????? 
[INFO] ------------------------------------------------------------------------
[INFO] Building oVirt Server EAR 3.1.0
[INFO] ------------------------------------------------------------------------
Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-antrun-plugin/1.3/maven-antrun-plugin-1.3.pom
Downloaded: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-antrun-plugin/1.3/maven-antrun-plugin-1.3.pom (5 KB at 46.7 KB/sec)
Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-antrun-plugin/1.3/maven-antrun-plugin-1.3.jar
Downloaded: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-antrun-plugin/1.3/maven-antrun-plugin-1.3.jar (24 KB at 255.8 KB/sec)
[INFO]
[INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ engine-server-ear ---
[INFO] Deleting /home/satimis/ovirt-engine/ear/target
[INFO]
[INFO] --- maven-antrun-plugin:1.3:run (undeploy) @ engine-server-ear ---
Downloading: http://repo1.maven.org/maven2/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.pom
Downloaded: http://repo1.maven.org/maven2/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.pom (3 KB at 77.6 KB/sec)
Downloading: http://repo1.maven.org/maven2/org/apache/ant/ant-parent/1.7.1/ant-parent-1.7.1.pom
Downloaded: http://repo1.maven.org/maven2/org/apache/ant/ant-parent/1.7.1/ant-parent-1.7.1.pom (5 KB at 137.9 KB/sec)
Downloading: http://repo1.maven.org/maven2/org/apache/ant/ant/1.7.1/ant-1.7.1.pom
Downloaded: http://repo1.maven.org/maven2/org/apache/ant/ant/1.7.1/ant-1.7.1.pom (10 KB at 232.4 KB/sec)
Downloading: http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/1.5.6/plexus-utils-1.5.6.jar
Downloading: http://repo1.maven.org/maven2/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.jar
Downloading: http://repo1.maven.org/maven2/org/apache/ant/ant/1.7.1/ant-1.7.1.jar
Downloaded: http://repo1.maven.org/maven2/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.jar (12 KB at 79.1 KB/sec)
Downloaded: http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/1.5.6/plexus-utils-1.5.6.jar (245 KB at 226.5 KB/sec)
Downloaded: http://repo1.maven.org/maven2/org/apache/ant/ant/1.7.1/ant-1.7.1.jar (1292 KB at 384.3 KB/sec)
[INFO] Executing tasks
???? [echo] *** Deleting /usr/share/jboss-as/standalone/deployments/engine.ear/...
[INFO] Executed tasks
[INFO]
[INFO] --- maven-ear-plugin:2.6:generate-application-xml (default-generate-application-xml) @ engine-server-ear ---
[INFO] Generating application.xml
[INFO]
[INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ engine-server-ear ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /home/satimis/ovirt-engine/ear/src/main/java
[INFO] Copying 1 resource
[INFO]
[INFO] --- maven-ear-plugin:2.6:ear (default-ear) @ engine-server-ear ---
[INFO] Copying artifact[jar:org.ovirt.engine.core:common:3.1.0] to[lib/engine-common.jar]
[INFO] Copying artifact[jar:org.ovirt.engine.core:compat:3.1.0] to[lib/engine-compat.jar]
[INFO] Copying artifact[jar:org.ovirt.engine.core:dal:3.1.0] to[lib/engine-dal.jar]
[INFO] Copying artifact[jar:org.ovirt.engine.core:utils:3.1.0] to[lib/engine-utils.jar]
[INFO] Copying artifact[jar:org.ovirt.engine.core:engineencryptutils:3.1.0] to[lib/engine-encryptutils.jar]
[INFO] Copying artifact[jar:org.ovirt.engine.core:vdsbroker:3.1.0] to[lib/engine-vdsbroker.jar]
[INFO] Copying artifact[war:org.ovirt.engine.core:root-war:3.1.0] to[root.war] (unpacked)
[INFO] Copying artifact[war:org.ovirt.engine.ui:rmw-war:3.1.0] to[ovirtengineweb.war] (unpacked)
[INFO] Copying artifact[war:org.ovirt.engine.api:restapi-webapp:3.1.0] to[restapi.war] (unpacked)
[INFO] Copying artifact[war:org.ovirt.engine.ui:userportal:3.1.0] to[userportal.war] (unpacked)
[INFO] Copying artifact[war:org.ovirt.engine.ui:webadmin:3.1.0] to[webadmin.war] (unpacked)
[INFO] Copying artifact[ejb:org.ovirt.engine.ui:genericapi:3.1.0] to[engine-genericapi.jar] (unpacked)
[INFO] Copying artifact[ejb:org.ovirt.engine.core:scheduler:3.1.0] to[engine-scheduler.jar] (unpacked)
[INFO] Copying artifact[ejb:org.ovirt.engine.core:bll:3.1.0] to[engine-bll.jar] (unpacked)
[INFO] Copying artifact[jar:commons-codec:commons-codec:1.4] to[lib/commons-codec-1.4.jar]
[INFO] Copying artifact[jar:org.hibernate:hibernate-validator:4.0.2.GA] to[lib/hibernate-validator-4.0.2.GA.jar]
[INFO] Copying artifact[jar:javax.validation:validation-api:1.0.0.GA] to[lib/validation-api-1.0.0.GA.jar]
[INFO] Copying artifact[jar:org.slf4j:slf4j-api:1.5.6] to[lib/slf4j-api-1.5.6.jar]
[INFO] Copying artifact[jar:javax.xml.bind:jaxb-api:2.1] to[lib/jaxb-api-2.1.jar]
[INFO] Copying artifact[jar:javax.xml.stream:stax-api:1.0-2] to[lib/stax-api-1.0-2.jar]
[INFO] Copying artifact[jar:javax.activation:activation:1.1] to[lib/activation-1.1.jar]
[INFO] Copying artifact[jar:com.sun.xml.bind:jaxb-impl:2.1.3] to[lib/jaxb-impl-2.1.3.jar]
[INFO] Copying artifact[jar:org.hibernate:hibernate-annotations:3.4.0.GA] to[lib/hibernate-annotations-3.4.0.GA.jar]
[INFO] Copying artifact[jar:org.hibernate:ejb3-persistence:1.0.2.GA] to[lib/ejb3-persistence-1.0.2.GA.jar]
[INFO] Copying artifact[jar:org.hibernate:hibernate-commons-annotations:3.1.0.GA] to[lib/hibernate-commons-annotations-3.1.0.GA.jar]
[INFO] Copying artifact[jar:org.hibernate:hibernate-core:3.3.0.SP1] to[lib/hibernate-core-3.3.0.SP1.jar]
[INFO] Copying artifact[jar:antlr:antlr:2.7.6] to[lib/antlr-2.7.6.jar]
[INFO] Copying artifact[jar:dom4j:dom4j:1.6.1] to[lib/dom4j-1.6.1.jar]
[INFO] Copying artifact[jar:xml-apis:xml-apis:1.0.b2] to[lib/xml-apis-1.0.b2.jar]
[INFO] Copying artifact[jar:org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.1_spec:1.0.0.Final] to[lib/jboss-interceptors-api_1.1_spec-1.0.0.Final.jar]
[INFO] Copying artifact[jar:org.ovirt.engine.core:engine-tools-common:3.1.0] to[lib/engine-tools-common-3.1.0.jar]
[INFO] Copying artifact[jar:commons-beanutils:commons-beanutils:1.8.2] to[lib/commons-beanutils-1.8.2.jar]
[INFO] Copying artifact[jar:org.apache.mina:mina-core:2.0.1] to[lib/mina-core-2.0.1.jar]
[INFO] Copying artifact[jar:org.apache.sshd:sshd-core:0.7.0] to[lib/sshd-core-0.7.0.jar]
[INFO] Copying artifact[jar:org.apache.commons:commons-compress:1.3] to[lib/commons-compress-1.3.jar]
[INFO] Copying artifact[jar:commons-lang:commons-lang:2.4] to[lib/commons-lang-2.4.jar]
[INFO] Copying artifact[jar:org.apache.xmlrpc:xmlrpc-client:3.1.3] to[lib/xmlrpc-client-3.1.3.jar]
[INFO] Copying artifact[jar:org.apache.xmlrpc:xmlrpc-common:3.1.3] to[lib/xmlrpc-common-3.1.3.jar]
[INFO] Copying artifact[jar:org.apache.ws.commons.util:ws-commons-util:1.0.2] to[lib/ws-commons-util-1.0.2.jar]
[INFO] Copying artifact[jar:org.springframework:spring-jdbc:3.1.1.RELEASE] to[lib/spring-jdbc-3.1.1.RELEASE.jar]
[INFO] Copying artifact[jar:org.springframework:spring-tx:3.1.1.RELEASE] to[lib/spring-tx-3.1.1.RELEASE.jar]
[INFO] Copying artifact[jar:org.springframework.ldap:spring-ldap-core:1.3.1.RELEASE] to[lib/spring-ldap-core-1.3.1.RELEASE.jar]
[INFO] Copying artifact[jar:commons-httpclient:commons-httpclient:3.1] to[lib/commons-httpclient-3.1.jar]
[INFO] Copying artifact[jar:commons-collections:commons-collections:3.1] to[lib/commons-collections-3.1.jar]
[INFO] Copying artifact[jar:org.quartz-scheduler:quartz:2.1.2] to[lib/quartz-2.1.2.jar]
[INFO] Copying artifact[jar:c3p0:c3p0:0.9.1.1] to[lib/c3p0-0.9.1.1.jar]
[INFO] Copying artifact[jar:org.ovirt.engine.core:searchbackend:3.1.0] to[lib/searchbackend-3.1.0.jar]
[INFO] Copying artifact[jar:org.springframework:spring-core:3.1.1.RELEASE] to[lib/spring-core-3.1.1.RELEASE.jar]
[INFO] Copying artifact[jar:org.springframework:spring-asm:3.1.1.RELEASE] to[lib/spring-asm-3.1.1.RELEASE.jar]
[INFO] Copying artifact[jar:org.springframework:spring-beans:3.1.1.RELEASE] to[lib/spring-beans-3.1.1.RELEASE.jar]
[INFO] Copying artifact[jar:org.springframework:spring-context:3.1.1.RELEASE] to[lib/spring-context-3.1.1.RELEASE.jar]
[INFO] Copying artifact[jar:org.springframework:spring-aop:3.1.1.RELEASE] to[lib/spring-aop-3.1.1.RELEASE.jar]
[INFO] Copying artifact[jar:aopalliance:aopalliance:1.0] to[lib/aopalliance-1.0.jar]
[INFO] Copying artifact[jar:org.springframework:spring-expression:3.1.1.RELEASE] to[lib/spring-expression-3.1.1.RELEASE.jar]
[INFO] Copy ear sources to /home/satimis/ovirt-engine/ear/target/engine
[WARNING] resourcesDir is deprecated. Please use the earSourceDirectory property instead.
[INFO] Copy ear resources to /home/satimis/ovirt-engine/ear/target/engine
[INFO] Including custom manifest file[/home/satimis/ovirt-engine/ear/target/engine/META-INF/MANIFEST.MF]
[INFO] Building jar: /home/satimis/ovirt-engine/ear/target/engine.ear
[INFO]
[INFO] --- maven-dependency-plugin:2.1:copy (copy-quartz-jar) @ engine-server-ear ---
[INFO] Configured Artifact: org.quartz-scheduler:quartz:2.1.2:jar
[INFO] Copying quartz-2.1.2.jar to /home/satimis/ovirt-engine/ear/target/quartz/quartz-2.1.2.jar
[INFO]
[INFO] --- maven-antrun-plugin:1.3:run (deploy) @ engine-server-ear ---
[INFO] Executing tasks
???? [echo] *** Copying updated files from target/engine/ to /usr/share/jboss-as/standalone/deployments/engine.ear/...
???? [copy] Copying 1168 files to /usr/share/jboss-as/standalone/deployments/engine.ear
???? [copy] Copying /home/satimis/ovirt-engine/ear/target/engine/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class to /usr/share/jboss-as/standalone/deployments/engine.ear/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 15.761s
[INFO] Finished at: Wed Nov 14 14:34:56 HKT 2012
[INFO] Final Memory: 16M/295M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.3:run (deploy) on project engine-server-ear: An Ant BuildException has occured: Failed to copy /home/satimis/ovirt-engine/ear/target/engine/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class to /usr/share/jboss-as/standalone/deployments/engine.ear/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class due to java.io.FileNotFoundException /usr/share/jboss-as/standalone/deployments/engine.ear/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class (No such file or directory) -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException


PluginExecutionException
https://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
.....
You should report this problem to the maintainer of the plugin.


Please help.? How to fix this problem and continue?

TIA

B.R.
Stephen L




>________________________________
> From: Laszlo Hornyak <lhornyak at redhat.com>
>To: Stephen Liu <satimis at yahoo.com> 
>Cc: engine-devel at ovirt.org 
>Sent: Wednesday, November 14, 2012 3:43 PM
>Subject: Re: [Engine-devel] Building oVirt from source
> 
>
>
>----- Original Message -----
>> From: "Stephen Liu" <satimis at yahoo.com>
>> To: engine-devel at ovirt.org
>> Sent: Tuesday, November 13, 2012 5:20:46 PM
>> Subject: [Engine-devel] Building oVirt from source
>> 
>> 
>> 
>> 
>> Hi all,
>> 
>> Have another round to build oVirt from source following;
>> 
>> Building Engine Draft
>> http://wiki.ovirt.org/wiki/Building_Engine_Draft
>> 
>> OS - Fedora 17 desktop 64bit, fresh and clean installed.
>> 
>> Not much problem encountered up to "Installing JBoss AS" except
>> follows:
>> 
>> 1)
>> Maven personal settings
>> ==================
>> 
>> $ mkdir $HOME/.m2
>> $ wget -O $HOME/.m2/settings.xml
>> http://wiki.ovirt.org/w/images/1/18/Settings.xml.png
>> 
>> (it should read
>> "http://wiki.ovirt.org/w/images/1/18/Settings.xml.png")
>> ^^^^ (not www)
>> 
>> 2)
>> Check that the application server starts correctly:
>> 
>> $ cd $JBOSS_HOME/bin
>> $ ./standalone.sh -b 0.0.0.0
>> ===================================================
>> 
>> JBoss Bootstrap Environment
>> 
>> JBOSS_HOME: /home/satimis/jboss-as
>> 
>> JAVA: java
>> 
>> JAVA_OPTS: -server -XX:+UseCompressedOops -XX:+TieredCompilation
>> -Xms64m -Xmx512m -XX:MaxPermSize=256m
>> -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true
>> -Dsun.rmi.dgc.client.gcInterval=3600000
>> -Dsun.rmi.dgc.server.gcInterval=3600000
>> -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=tr
>> ....
>> .....
>> 
>> 22:14:38,217 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874:
>> JBoss AS 7.1.1.Final "Brontes" started in 6662ms - Started 133 of
>> 208 services (74 services are passive or on-demand)
>
>So your jboss is started at this point and should e listening on 8080 for http connections. Is ovirt running?
>If not you should check if it is there in standalone/deployments/engine.ear
>Also, see if engine.ear.deployed exists. touch engine.dodeploy to kick jboss and deploy it.
>
>> 
>> 
>> It hung here;
>> 
>> Press [Ctrl] + c
>> it continued to display:
>> 
>> 19:49,653 INFO [org.jboss.as.osgi] (MSC service thread 1-3)
>> JBAS011942: Stopping OSGi Framework
>> 22:19:49,701 INFO [org.jboss.as.logging] JBAS011503: Restored
>> bootstrap log handlers
>> 22:19:49,726 INFO [org.apache.coyote.http11.Http11Protocol] Pausing
>> Coyote HTTP/1.1 on http--0.0.0.0-8080
>> 22:19:49,727 INFO [org.apache.coyote.http11.Http11Protocol] Stopping
>> Coyote HTTP/1.1 on http--0.0.0.0-8080
>> 22:19:49,729 INFO [com.arjuna.ats.jbossatx] ARJUNA032018: Destroying
>> TransactionManagerService
>> 22:19:49,730 INFO [com.arjuna.ats.jbossatx] ARJUNA032014: Stopping
>> transaction recovery manager
>> 22:19:49,753 INFO [org.jboss.as] JBAS015950: JBoss AS 7.1.1.Final
>> "Brontes" stopped in 111ms
>> 
>> Is it normal? Without problem?
>> 
>> Thanks
>> 
>> B.R.
>> Stephen L
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>> 
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121114/a3dc92cf/attachment.html>

From iheim at redhat.com  Wed Nov 14 16:31:39 2012
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 14 Nov 2012 18:31:39 +0200
Subject: [Engine-devel] Building oVirt from source
In-Reply-To: <1352900414.97967.YahooMailNeo@web125102.mail.ne1.yahoo.com>
References: <1352823646.4124.YahooMailNeo@web125104.mail.ne1.yahoo.com>
	<50A36C2C.5030602@redhat.com>
	<1352887836.22748.YahooMailNeo@web125102.mail.ne1.yahoo.com>
	<50A37116.1040102@redhat.com>
	<1352889268.47516.YahooMailNeo@web125104.mail.ne1.yahoo.com>
	<50A37420.7090400@redhat.com>
	<1352891345.11371.YahooMailNeo@web125106.mail.ne1.yahoo.com>
	<50A37DCC.40100@redhat.com>
	<1352900414.97967.YahooMailNeo@web125102.mail.ne1.yahoo.com>
Message-ID: <50A3C76B.1010806@redhat.com>

On 11/14/2012 03:40 PM, Stephen Liu wrote:
>
>
> ----- Original Message -----
>> From: Juan Hernandez <jhernand at redhat.com>
>> To: Stephen Liu <satimis at yahoo.com>
>> Cc: Laszlo Hornyak <lhornyak at redhat.com>; "engine-devel at ovirt.org" <engine-devel at ovirt.org>
>> Sent: Wednesday, November 14, 2012 7:17 PM
>> Subject: Re: [Engine-devel] Building oVirt from source
>>
>> On 11/14/2012 12:09 PM, Stephen Liu wrote:
>>>
>>>   Hi all,
>>>
>>>   $ sudo find / -name .m2
>>>   find: `/run/user/satimis/gvfs': Permission denied
>>>   /home/satimis/.m2
>>>
>>>   $ sudo ls -ald /home/satimis/.m2
>>>   drwxrwxr-x. 3 satimis satimis 4096 Nov 14 14:12 /home/satimis/.m2
>>>
>>>
>>>   $ cat $HOME/.m2/settings.xml
>>>   <settings xmlns="http://maven.apache.org/POM/4.0.0"
>>>   <http://maven.apache.org/POM/4.0.0%22>;
>>>             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>   <http://www.w3.org/2001/XMLSchema-instance%22>;
>>>             xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>>>   http://maven.apache.org/xsd/settings-1.0.0.xsd"
>>>   <http://maven.apache.org/xsd/settings-1.0.0.xsd%22>;>
>>>
>>>   <!--**************************** PROFILES
>> ****************************-->
>>>
>>>           <activeProfiles>
>>>
>> <activeProfile>oVirtEnvSettings</activeProfile>
>>>           </activeProfiles>
>>>
>>>           <profiles>
>>>               <profile>
>>>                   <id>oVirtEnvSettings</id>
>>>                       <properties>
>>>
>> <jbossHome>/usr/share/jboss-as</jbossHome>
>>>
>>>
>> <JAVA_HOME>/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/bin/java</JAVA_HOME>
>>>                       </properties>
>>>               </profile>
>>>            </profiles>
>>>   </settings>
>>
>> This ^ (/home/satimis/.m2/settings.xml) is the file that you need to
>> change, and you need to change the "jbossHome" property so that it
>> contains the directory where you actually have the application server
>> installed.
>>
>> Please remove or fix the JAVA_HOME property as well, as it is not needed
>> and pointing a location that doesn't exist in Fedora 17.
>
>
> Whether to run:-
>
> # mv /home/satimis/jboss-as /usr/share/
> # rm -rf /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64
> # service jboss-as restart
>
> #> ps ax | grep java (to check jboss running)
>
> Then run again;
> $> cd $OVIRT_HOME/ear
> $> mvn clean install -Pdep,setup
>
> followed by;
> Deploying engine-config & engine-manage-domains
>
> $> cd $OVIRT_HOME
> $> make create_dirs
> $> make install_tools
> $> make install_config
>
> etc.
>

is there any reason to not use jboss in rpm form, and have our default 
files for developers assume paths based on jboss rpm?


From jhernand at redhat.com  Wed Nov 14 16:43:03 2012
From: jhernand at redhat.com (Juan Hernandez)
Date: Wed, 14 Nov 2012 17:43:03 +0100
Subject: [Engine-devel] Building oVirt from source
In-Reply-To: <50A3C76B.1010806@redhat.com>
References: <1352823646.4124.YahooMailNeo@web125104.mail.ne1.yahoo.com>
	<50A36C2C.5030602@redhat.com>
	<1352887836.22748.YahooMailNeo@web125102.mail.ne1.yahoo.com>
	<50A37116.1040102@redhat.com>
	<1352889268.47516.YahooMailNeo@web125104.mail.ne1.yahoo.com>
	<50A37420.7090400@redhat.com>
	<1352891345.11371.YahooMailNeo@web125106.mail.ne1.yahoo.com>
	<50A37DCC.40100@redhat.com>
	<1352900414.97967.YahooMailNeo@web125102.mail.ne1.yahoo.com>
	<50A3C76B.1010806@redhat.com>
Message-ID: <50A3CA17.6040605@redhat.com>

On 11/14/2012 05:31 PM, Itamar Heim wrote:
> On 11/14/2012 03:40 PM, Stephen Liu wrote:
>>
>>
>> ----- Original Message -----
>>> From: Juan Hernandez <jhernand at redhat.com>
>>> To: Stephen Liu <satimis at yahoo.com>
>>> Cc: Laszlo Hornyak <lhornyak at redhat.com>; "engine-devel at ovirt.org" <engine-devel at ovirt.org>
>>> Sent: Wednesday, November 14, 2012 7:17 PM
>>> Subject: Re: [Engine-devel] Building oVirt from source
>>>
>>> On 11/14/2012 12:09 PM, Stephen Liu wrote:
>>>>
>>>>   Hi all,
>>>>
>>>>   $ sudo find / -name .m2
>>>>   find: `/run/user/satimis/gvfs': Permission denied
>>>>   /home/satimis/.m2
>>>>
>>>>   $ sudo ls -ald /home/satimis/.m2
>>>>   drwxrwxr-x. 3 satimis satimis 4096 Nov 14 14:12 /home/satimis/.m2
>>>>
>>>>
>>>>   $ cat $HOME/.m2/settings.xml
>>>>   <settings xmlns="http://maven.apache.org/POM/4.0.0"
>>>>   <http://maven.apache.org/POM/4.0.0%22>;
>>>>             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>>   <http://www.w3.org/2001/XMLSchema-instance%22>;
>>>>             xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>>>>   http://maven.apache.org/xsd/settings-1.0.0.xsd"
>>>>   <http://maven.apache.org/xsd/settings-1.0.0.xsd%22>;>
>>>>
>>>>   <!--**************************** PROFILES
>>> ****************************-->
>>>>
>>>>           <activeProfiles>
>>>>
>>> <activeProfile>oVirtEnvSettings</activeProfile>
>>>>           </activeProfiles>
>>>>
>>>>           <profiles>
>>>>               <profile>
>>>>                   <id>oVirtEnvSettings</id>
>>>>                       <properties>
>>>>
>>> <jbossHome>/usr/share/jboss-as</jbossHome>
>>>>
>>>>
>>> <JAVA_HOME>/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/bin/java</JAVA_HOME>
>>>>                       </properties>
>>>>               </profile>
>>>>            </profiles>
>>>>   </settings>
>>>
>>> This ^ (/home/satimis/.m2/settings.xml) is the file that you need to
>>> change, and you need to change the "jbossHome" property so that it
>>> contains the directory where you actually have the application server
>>> installed.
>>>
>>> Please remove or fix the JAVA_HOME property as well, as it is not needed
>>> and pointing a location that doesn't exist in Fedora 17.
>>
>>
>> Whether to run:-
>>
>> # mv /home/satimis/jboss-as /usr/share/
>> # rm -rf /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64
>> # service jboss-as restart
>>
>> #> ps ax | grep java (to check jboss running)
>>
>> Then run again;
>> $> cd $OVIRT_HOME/ear
>> $> mvn clean install -Pdep,setup
>>
>> followed by;
>> Deploying engine-config & engine-manage-domains
>>
>> $> cd $OVIRT_HOME
>> $> make create_dirs
>> $> make install_tools
>> $> make install_config
>>
>> etc.
>>
> 
> is there any reason to not use jboss in rpm form, and have our default 
> files for developers assume paths based on jboss rpm?

The reason is that the jboss rpm installs the files in
/usr/share/jboss-as, owned by the root:jboss-as, so a non privileged
user will not have permission to write to those directories.

Stephen, what I suggested you to do is to leave the installation of the
application server in the /home/satimis/jboss-as directory and then
modify the /home/satimis/.m2/settings.xml file. It should read as follows:

<settings
  xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">

  <activeProfiles>
    <activeProfile>oVirt</activeProfile>
  </activeProfiles>

  <profiles>
    <profile>
      <id>oVirt</id>
      <properties>
        <jbossHome>/home/satimis/jboss-as</jbossHome>
      </properties>
    </profile>
  </profiles>

</settings>

Also you don't need to start the jboss-as service, as ovirt doesn't use
it. In a development environment you just go to
/home/satimis/jboss-as/bin and run standalone.sh.

Also make sure that you own the /home/satimis/jboss-as directory:

sudo chown --recursive satimis:satimis /home/satimis/jboss-as

Let me insist that if the build runs correctly what you will have is an
environment that you can use for development, it is not suitable or
designed for using ovirt. If what you want to do is test ovirt from the
user point of view then I strongly recommend that you use the prebuilt RPMs.

-- 
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 medievalist at gmail.com  Wed Nov 14 17:01:58 2012
From: medievalist at gmail.com (Charlie)
Date: Wed, 14 Nov 2012 12:01:58 -0500
Subject: [Engine-devel] Managing permissions on network
In-Reply-To: <50A31DE5.2070201@redhat.com>
References: <50991728.8070702@redhat.com> <50A20B7D.8000401@redhat.com>
	<50A224AD.60205@redhat.com> <50A248E8.10504@redhat.com>
	<50A24D1E.8070906@redhat.com> <50A24DA1.2030909@redhat.com>
	<50A280E4.5010000@redhat.com> <50A28F15.8010603@redhat.com>
	<CAJb3uA5jPnV8thwpDY46dnBby_PS4C3+MiLs9KQAXM+na3tJLw@mail.gmail.com>
	<50A31DE5.2070201@redhat.com>
Message-ID: <CAJb3uA6MJ=ewofVmeV3mRqao9xVJ3pgpXseMxD1tjAC=10MbvA@mail.gmail.com>

> On 11/13/2012 09:57 PM, Charlie wrote:
>>
>> Will any of these groups and/or permissions be drawn from LDAP?
>>
>> Frankly, system admins are not looking for yet another console to
>> manage permissions.

On Tue, Nov 13, 2012 at 11:28 PM, Itamar Heim <iheim at redhat.com> wrote:

> all users/groups come from LDAP.
> you just need to give permissions to these groups/users in ovirt.
> is that what you meant?

Yes, mostly.  :)

As long as you can give permissions to a set of LDAP groups (call them
oVirtSysAdmin, oVirtUser, oVirtNetAdmin, or whatever) and after that
never touch permissions again, that's perfect.

That way an HR employee or junior sysadmin can assign users to these
groups during user account creation, and you won't have to give
somebody in HR the ability to define permissions in oVirt, or tie up a
highly skilled admin with routine user account maintenance.

--Charlie


>
>>
>> --Charlie
>>
>>
>> On Tue, Nov 13, 2012 at 1:19 PM, Itamar Heim <iheim at redhat.com> wrote:
>>>
>>> On 11/13/2012 07:18 PM, Livnat Peer wrote:
>>>>
>>>>
>>>> On 13/11/12 15:39, Itamar Heim wrote:
>>>>>
>>>>>
>>>>> On 11/13/2012 03:37 PM, Livnat Peer wrote:
>>>>>>
>>>>>>
>>>>>> On 13/11/12 15:19, Itamar Heim wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 11/13/2012 12:45 PM, Livnat Peer wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Interesting point, I think that if a user has permission to create a
>>>>>>>> VM
>>>>>>>> from a specific template we should give him permission to use the
>>>>>>>> template networks on this VM implicitly upon the VM creation.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> having a permission to a template does not mean a permission to the
>>>>>>> default network of that VM, especially as we'll use templates more as
>>>>>>> instance types.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Another alternative is to require permission on the network as well as
>>>>>> the template.
>>>>>> I must say I don't really like it, although I agree with your comment,
>>>>>> we require too many operations for enabling a user to create a VM from
>>>>>> template (permission on the template, quota on the storage,
>>>>>> permissions
>>>>>> on the network, next we'll require a PHD ;)).
>>>>>>
>>>>>> Anyone has a better idea?
>>>>>
>>>>>
>>>>>
>>>>> I assume most networks would be given either to 'everyone' or groups of
>>>>> users, not per user (and if the network is per user/tenant, then it
>>>>> must
>>>>> be done per user.
>>>>
>>>>
>>>>
>>>> Which reminds that I wanted to propose adding a property on a network
>>>> which is called public.
>>>> It's just a UI feature to give a NetworkUser on this network to
>>>> 'everyone'. It makes making a network public easier for the user.
>>>>
>>>> In addition during upgrade we should make all existing networks public
>>>> networks and not allocate specific permissions for users on networks.
>>>>
>>>> In addition it also means a user is given permission on a network and
>>>> then he can use it for any VM he owns. Isn't that problematic? We can't
>>>> limit a user to use a network on a specific VM.
>>>
>>>
>>>
>>> I think that's fine.
>>> don't let user edit that vm if you don't trust them.
>>>
>>>
>>>>
>>>>> i may not remember correctly, but i thought when giving quota to user
>>>>> we
>>>>> also give some permissions with it (on cluster and storage)?
>>>>
>>>>
>>>>
>>>> I am not sure what is the current implementation as it changed a lot,
>>>> but last I tracked we checked for either quota or permissions we did not
>>>> give implicit permissions when creating a quota.
>>>>
>>>
>>> gilad/doron?
>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>
>


From iheim at redhat.com  Wed Nov 14 17:02:41 2012
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 14 Nov 2012 19:02:41 +0200
Subject: [Engine-devel] Managing permissions on network
In-Reply-To: <CAJb3uA6MJ=ewofVmeV3mRqao9xVJ3pgpXseMxD1tjAC=10MbvA@mail.gmail.com>
References: <50991728.8070702@redhat.com> <50A20B7D.8000401@redhat.com>
	<50A224AD.60205@redhat.com> <50A248E8.10504@redhat.com>
	<50A24D1E.8070906@redhat.com> <50A24DA1.2030909@redhat.com>
	<50A280E4.5010000@redhat.com> <50A28F15.8010603@redhat.com>
	<CAJb3uA5jPnV8thwpDY46dnBby_PS4C3+MiLs9KQAXM+na3tJLw@mail.gmail.com>
	<50A31DE5.2070201@redhat.com>
	<CAJb3uA6MJ=ewofVmeV3mRqao9xVJ3pgpXseMxD1tjAC=10MbvA@mail.gmail.com>
Message-ID: <50A3CEB1.5020106@redhat.com>

On 11/14/2012 07:01 PM, Charlie wrote:
>> On 11/13/2012 09:57 PM, Charlie wrote:
>>>
>>> Will any of these groups and/or permissions be drawn from LDAP?
>>>
>>> Frankly, system admins are not looking for yet another console to
>>> manage permissions.
>
> On Tue, Nov 13, 2012 at 11:28 PM, Itamar Heim <iheim at redhat.com> wrote:
>
>> all users/groups come from LDAP.
>> you just need to give permissions to these groups/users in ovirt.
>> is that what you meant?
>
> Yes, mostly.  :)
>
> As long as you can give permissions to a set of LDAP groups (call them
> oVirtSysAdmin, oVirtUser, oVirtNetAdmin, or whatever) and after that
> never touch permissions again, that's perfect.
>
> That way an HR employee or junior sysadmin can assign users to these
> groups during user account creation, and you won't have to give
> somebody in HR the ability to define permissions in oVirt, or tie up a
> highly skilled admin with routine user account maintenance.

ok, that's exactly how oVirt works.


From simon at redhat.com  Wed Nov 14 17:11:33 2012
From: simon at redhat.com (Simon Grinberg)
Date: Wed, 14 Nov 2012 12:11:33 -0500 (EST)
Subject: [Engine-devel] Network Wiring
In-Reply-To: <50A3BA1E.30707@redhat.com>
Message-ID: <30606508.421.1352913088077.JavaMail.javamailuser@localhost>



----- Original Message -----
> From: "Yaniv Kaul" <ykaul at redhat.com>
> To: "Alona Kaplan" <alkaplan at redhat.com>
> Cc: engine-devel at ovirt.org, "Simon Grinberg" <sgrinber at redhat.com>, rhevm-qe-network at redhat.com
> Sent: Wednesday, November 14, 2012 5:34:54 PM
> Subject: Re: [Engine-devel] Network Wiring
> 
> On 11/13/2012 04:46 PM, Alona Kaplan wrote:
> > Hi all,
> >
> > Please review the wiki and add your comments.
> >
> > http://wiki.ovirt.org/wiki/Feature/NetworkWiring
> >
> >
> > Thanks,
> > Alona.
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> The wording is wrong.
> You PLUG/UNPLUG a cable.
> You REMOVE/INSERT a card.
> 
> unwired means wireless.
> 
> Missing from the design is what actually happening. I assume you
> change
> the link state. It might be worth while to just use 'link state:
> up/down'. Anyone can understand that.

You are right, however how do we avoid confusing with libvirt terminology having REMOVE/INSERT as hot-plug/unplug?

However indeed wiring may still be changed to link state - need not confuse though with internal OS terminology of interface up/down.
maybe on/off


> Y.
> 
> 
> 


From simon at redhat.com  Wed Nov 14 19:12:07 2012
From: simon at redhat.com (Simon Grinberg)
Date: Wed, 14 Nov 2012 14:12:07 -0500 (EST)
Subject: [Engine-devel] Network Wiring
In-Reply-To: <50A2A5AA.9050302@redhat.com>
Message-ID: <31593663.534.1352920325997.JavaMail.javamailuser@localhost>



----- Original Message -----
> From: "Moti Asayag" <masayag at redhat.com>
> To: "Simon Grinberg" <simon at redhat.com>
> Cc: rhevm-qe-network at redhat.com, engine-devel at ovirt.org
> Sent: Tuesday, November 13, 2012 9:55:22 PM
> Subject: Re: [Engine-devel] Network Wiring
> 
> On 11/13/2012 07:58 PM, Simon Grinberg wrote:
> > From the summary:
> > "...It supports the following actions without unplugging the Vnic,
> > and it maintains the device address of the Vnic ...."
> > 
> > But in the dialogue section:
> > "If the Vnic is plugged there should be a message on top of the
> > dialog "Please notice, changing Type or MAC will cause unplugging
> > and plugging the Vnic"
> > 
> > Looking at the detailed design indeed any change indeed goes
> > through plug/unplug.
> > Please correct me if I got the above wrong.
> 
> Changing the network (rewiring network) is done using new API with
> VDSM,
> updateVmInteface.
> 
> Therefore plug/unplug won't be executed for any of:
> 1. Changing the network to other network or disconnecting/unwiring
> it).
> 2. Update the name of the VM (db only).
> 
> Other changes to VM properties (i.e. MAC address, driver type) will
> require the plug/unplug. Same goes to any explicit 'unplug' command.
> 
> > 
> > To support real live rewire == "Move a card from one network to
> > another"
> > The sequence should be for wired-plugged card:
> > - Unwire
> > - Change network
> > - Rewire
> > 
> > I would argue that we should actually force the user to perform
> > these steps, but we can do it in one go.
> 
> The intention is to use the new API VDSM.libvirtVm.updateVmInteface
> for
> performing the network rewire in a single command.

What does it do? I could not find updateVmInteface in vdsm git. 
Where is this defined? 

It's critical. 

- You can change the interface directly by moving the VM from one network to another 
- You can do that but toggle the ling state so the VM will be aware. 

Which if these two?
If you do only the first then it's not the common use case. In most cases you must toggle the link status to the VM.
This will cause:
1. Speed negotiation + arp request that also informs the switched about the change  
2. In case it's DHCP (which most likely the case for guests) it will trigger new DHCP request. 

If you don't baaad things will happen :) 

> 
> > 
> > Any other state may change network freely.
> > 
> > To change name - it's just DB, so any state goes
> > 
> > To change type or MAC address (= property), must go through unplug
> > regardless to the wired state
> > So:
> > - Unplug
> > - Change property
> > - Plug
> > 
> > Again should probably ask the user to do these 3 steps so he'll
> > know what he is doing, but we can do it for him with proper
> > warning.
> > 
> > I also wander I do we have to drop the PCI address in the persisted
> > table in this case - loosing the PCI location is redundant and
> > will cause a move to another eth0 number in the guest. On the
> > other hand changing of MAC may break network scripts anyhow - so I
> > don't have a strong argument to keep it.
> > 
> > 
> > Another issue:
> > If the nic is there to be use by a hook, then you probably want to
> > allow 'none' network.
> > This may also be useful when allowing to purge a network while it
> > is connected to VMs: unwire on all nics and connect to the none
> > network.
> > 
> > 
> > Overall, looking great, and I like the wired vs unplugged that
> > emulate real behavior.
> > 
> > Regards,
> > Simon
> > 
> > 
> >  
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > ----- Original Message -----
> >> From: "Alona Kaplan" <alkaplan at redhat.com>
> >> To: engine-devel at ovirt.org, "Simon Grinberg"
> >> <sgrinber at redhat.com>, rhevm-qe-network at redhat.com
> >> Sent: Tuesday, November 13, 2012 4:46:52 PM
> >> Subject: Network Wiring
> >>
> >> Hi all,
> >>
> >> Please review the wiki and add your comments.
> >>
> >> http://wiki.ovirt.org/wiki/Feature/NetworkWiring
> >>
> >>
> >> Thanks,
> >> Alona.
> >>
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From gpadgett at redhat.com  Wed Nov 14 19:41:43 2012
From: gpadgett at redhat.com (Greg Padgett)
Date: Wed, 14 Nov 2012 14:41:43 -0500
Subject: [Engine-devel] Deploy error again
In-Reply-To: <1352876189.81457.YahooMailNeo@web125101.mail.ne1.yahoo.com>
References: <1352876189.81457.YahooMailNeo@web125101.mail.ne1.yahoo.com>
Message-ID: <50A3F3F7.8000607@redhat.com>

On 11/14/2012 01:56 AM, Stephen Liu wrote:
> $ mvn clean install -Pdep,setup
> /usr/lib/jvm/java
> [INFO] Scanning for projects...
> [WARNING]
> [WARNING] Some problems were encountered while building the effective
> model for org.ovirt.engine:engine-server-ear:ear:3.1.0
> [WARNING] 'build.plugins.plugin.version' for
> org.apache.maven.plugins:maven-ear-plugin is missing. @ line 154, column 15
> [WARNING] 'distributionManagement.repository.id' must not be 'local', this
> identifier is reserved for the local repository, using it for other
> repositories will corrupt your repository metadata. @ line 18, column 11
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.
> [WARNING]
> [INFO]
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Building oVirt Server EAR 3.1.0
> [INFO]
> ------------------------------------------------------------------------
> Downloading:
> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-antrun-plugin/1.3/maven-antrun-plugin-1.3.pom
> Downloaded:
> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-antrun-plugin/1.3/maven-antrun-plugin-1.3.pom
> (5 KB at 46.7 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-antrun-plugin/1.3/maven-antrun-plugin-1.3.jar
> Downloaded:
> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-antrun-plugin/1.3/maven-antrun-plugin-1.3.jar
> (24 KB at 255.8 KB/sec)
> [INFO]
> [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @
> engine-server-ear ---
> [INFO] Deleting /home/satimis/ovirt-engine/ear/target
> [INFO]
> [INFO] --- maven-antrun-plugin:1.3:run (undeploy) @ engine-server-ear ---
> Downloading:
> http://repo1.maven.org/maven2/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.pom
> Downloaded:
> http://repo1.maven.org/maven2/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.pom
> (3 KB at 77.6 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/org/apache/ant/ant-parent/1.7.1/ant-parent-1.7.1.pom
> Downloaded:
> http://repo1.maven.org/maven2/org/apache/ant/ant-parent/1.7.1/ant-parent-1.7.1.pom
> (5 KB at 137.9 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/org/apache/ant/ant/1.7.1/ant-1.7.1.pom
> Downloaded:
> http://repo1.maven.org/maven2/org/apache/ant/ant/1.7.1/ant-1.7.1.pom (10
> KB at 232.4 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/1.5.6/plexus-utils-1.5.6.jar
> Downloading:
> http://repo1.maven.org/maven2/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.jar
> Downloading:
> http://repo1.maven.org/maven2/org/apache/ant/ant/1.7.1/ant-1.7.1.jar
> Downloaded:
> http://repo1.maven.org/maven2/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.jar
> (12 KB at 79.1 KB/sec)
> Downloaded:
> http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/1.5.6/plexus-utils-1.5.6.jar
> (245 KB at 226.5 KB/sec)
> Downloaded:
> http://repo1.maven.org/maven2/org/apache/ant/ant/1.7.1/ant-1.7.1.jar (1292
> KB at 384.3 KB/sec)
> [INFO] Executing tasks
>       [echo] *** Deleting
> /usr/share/jboss-as/standalone/deployments/engine.ear/...
> [INFO] Executed tasks
> [INFO]
> [INFO] --- maven-ear-plugin:2.6:generate-application-xml
> (default-generate-application-xml) @ engine-server-ear ---
> [INFO] Generating application.xml
> [INFO]
> [INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @
> engine-server-ear ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> /home/satimis/ovirt-engine/ear/src/main/java
> [INFO] Copying 1 resource
> [INFO]
> [INFO] --- maven-ear-plugin:2.6:ear (default-ear) @ engine-server-ear ---
> [INFO] Copying artifact[jar:org.ovirt.engine.core:common:3.1.0]
> to[lib/engine-common.jar]
> [INFO] Copying artifact[jar:org.ovirt.engine.core:compat:3.1.0]
> to[lib/engine-compat.jar]
> [INFO] Copying artifact[jar:org.ovirt.engine.core:dal:3.1.0]
> to[lib/engine-dal.jar]
> [INFO] Copying artifact[jar:org.ovirt.engine.core:utils:3.1.0]
> to[lib/engine-utils.jar]
> [INFO] Copying
> artifact[jar:org.ovirt.engine.core:engineencryptutils:3.1.0]
> to[lib/engine-encryptutils.jar]
> [INFO] Copying artifact[jar:org.ovirt.engine.core:vdsbroker:3.1.0]
> to[lib/engine-vdsbroker.jar]
> [INFO] Copying artifact[war:org.ovirt.engine.core:root-war:3.1.0]
> to[root.war] (unpacked)
> [INFO] Copying artifact[war:org.ovirt.engine.ui:rmw-war:3.1.0]
> to[ovirtengineweb.war] (unpacked)
> [INFO] Copying artifact[war:org.ovirt.engine.api:restapi-webapp:3.1.0]
> to[restapi.war] (unpacked)
> [INFO] Copying artifact[war:org.ovirt.engine.ui:userportal:3.1.0]
> to[userportal.war] (unpacked)
> [INFO] Copying artifact[war:org.ovirt.engine.ui:webadmin:3.1.0]
> to[webadmin.war] (unpacked)
> [INFO] Copying artifact[ejb:org.ovirt.engine.ui:genericapi:3.1.0]
> to[engine-genericapi.jar] (unpacked)
> [INFO] Copying artifact[ejb:org.ovirt.engine.core:scheduler:3.1.0]
> to[engine-scheduler.jar] (unpacked)
> [INFO] Copying artifact[ejb:org.ovirt.engine.core:bll:3.1.0]
> to[engine-bll.jar] (unpacked)
> [INFO] Copying artifact[jar:commons-codec:commons-codec:1.4]
> to[lib/commons-codec-1.4.jar]
> [INFO] Copying artifact[jar:org.hibernate:hibernate-validator:4.0.2.GA]
> to[lib/hibernate-validator-4.0.2.GA.jar]
> [INFO] Copying artifact[jar:javax.validation:validation-api:1.0.0.GA]
> to[lib/validation-api-1.0.0.GA.jar]
> [INFO] Copying artifact[jar:org.slf4j:slf4j-api:1.5.6]
> to[lib/slf4j-api-1.5.6.jar]
> [INFO] Copying artifact[jar:javax.xml.bind:jaxb-api:2.1]
> to[lib/jaxb-api-2.1.jar]
> [INFO] Copying artifact[jar:javax.xml.stream:stax-api:1.0-2]
> to[lib/stax-api-1.0-2.jar]
> [INFO] Copying artifact[jar:javax.activation:activation:1.1]
> to[lib/activation-1.1.jar]
> [INFO] Copying artifact[jar:com.sun.xml.bind:jaxb-impl:2.1.3]
> to[lib/jaxb-impl-2.1.3.jar]
> [INFO] Copying artifact[jar:org.hibernate:hibernate-annotations:3.4.0.GA]
> to[lib/hibernate-annotations-3.4.0.GA.jar]
> [INFO] Copying artifact[jar:org.hibernate:ejb3-persistence:1.0.2.GA]
> to[lib/ejb3-persistence-1.0.2.GA.jar]
> [INFO] Copying
> artifact[jar:org.hibernate:hibernate-commons-annotations:3.1.0.GA]
> to[lib/hibernate-commons-annotations-3.1.0.GA.jar]
> [INFO] Copying artifact[jar:org.hibernate:hibernate-core:3.3.0.SP1]
> to[lib/hibernate-core-3.3.0.SP1.jar]
> [INFO] Copying artifact[jar:antlr:antlr:2.7.6] to[lib/antlr-2.7.6.jar]
> [INFO] Copying artifact[jar:dom4j:dom4j:1.6.1] to[lib/dom4j-1.6.1.jar]
> [INFO] Copying artifact[jar:xml-apis:xml-apis:1.0.b2]
> to[lib/xml-apis-1.0.b2.jar]
> [INFO] Copying
> artifact[jar:org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.1_spec:1.0.0.Final]
> to[lib/jboss-interceptors-api_1.1_spec-1.0.0.Final.jar]
> [INFO] Copying
> artifact[jar:org.ovirt.engine.core:engine-tools-common:3.1.0]
> to[lib/engine-tools-common-3.1.0.jar]
> [INFO] Copying artifact[jar:commons-beanutils:commons-beanutils:1.8.2]
> to[lib/commons-beanutils-1.8.2.jar]
> [INFO] Copying artifact[jar:org.apache.mina:mina-core:2.0.1]
> to[lib/mina-core-2.0.1.jar]
> [INFO] Copying artifact[jar:org.apache.sshd:sshd-core:0.7.0]
> to[lib/sshd-core-0.7.0.jar]
> [INFO] Copying artifact[jar:org.apache.commons:commons-compress:1.3]
> to[lib/commons-compress-1.3.jar]
> [INFO] Copying artifact[jar:commons-lang:commons-lang:2.4]
> to[lib/commons-lang-2.4.jar]
> [INFO] Copying artifact[jar:org.apache.xmlrpc:xmlrpc-client:3.1.3]
> to[lib/xmlrpc-client-3.1.3.jar]
> [INFO] Copying artifact[jar:org.apache.xmlrpc:xmlrpc-common:3.1.3]
> to[lib/xmlrpc-common-3.1.3.jar]
> [INFO] Copying
> artifact[jar:org.apache.ws.commons.util:ws-commons-util:1.0.2]
> to[lib/ws-commons-util-1.0.2.jar]
> [INFO] Copying artifact[jar:org.springframework:spring-jdbc:3.1.1.RELEASE]
> to[lib/spring-jdbc-3.1.1.RELEASE.jar]
> [INFO] Copying artifact[jar:org.springframework:spring-tx:3.1.1.RELEASE]
> to[lib/spring-tx-3.1.1.RELEASE.jar]
> [INFO] Copying
> artifact[jar:org.springframework.ldap:spring-ldap-core:1.3.1.RELEASE]
> to[lib/spring-ldap-core-1.3.1.RELEASE.jar]
> [INFO] Copying artifact[jar:commons-httpclient:commons-httpclient:3.1]
> to[lib/commons-httpclient-3.1.jar]
> [INFO] Copying artifact[jar:commons-collections:commons-collections:3.1]
> to[lib/commons-collections-3.1.jar]
> [INFO] Copying artifact[jar:org.quartz-scheduler:quartz:2.1.2]
> to[lib/quartz-2.1.2.jar]
> [INFO] Copying artifact[jar:c3p0:c3p0:0.9.1.1] to[lib/c3p0-0.9.1.1.jar]
> [INFO] Copying artifact[jar:org.ovirt.engine.core:searchbackend:3.1.0]
> to[lib/searchbackend-3.1.0.jar]
> [INFO] Copying artifact[jar:org.springframework:spring-core:3.1.1.RELEASE]
> to[lib/spring-core-3.1.1.RELEASE.jar]
> [INFO] Copying artifact[jar:org.springframework:spring-asm:3.1.1.RELEASE]
> to[lib/spring-asm-3.1.1.RELEASE.jar]
> [INFO] Copying
> artifact[jar:org.springframework:spring-beans:3.1.1.RELEASE]
> to[lib/spring-beans-3.1.1.RELEASE.jar]
> [INFO] Copying
> artifact[jar:org.springframework:spring-context:3.1.1.RELEASE]
> to[lib/spring-context-3.1.1.RELEASE.jar]
> [INFO] Copying artifact[jar:org.springframework:spring-aop:3.1.1.RELEASE]
> to[lib/spring-aop-3.1.1.RELEASE.jar]
> [INFO] Copying artifact[jar:aopalliance:aopalliance:1.0]
> to[lib/aopalliance-1.0.jar]
> [INFO] Copying
> artifact[jar:org.springframework:spring-expression:3.1.1.RELEASE]
> to[lib/spring-expression-3.1.1.RELEASE.jar]
> [INFO] Copy ear sources to /home/satimis/ovirt-engine/ear/target/engine
> [WARNING] resourcesDir is deprecated. Please use the earSourceDirectory
> property instead.
> [INFO] Copy ear resources to /home/satimis/ovirt-engine/ear/target/engine
> [INFO] Including custom manifest
> file[/home/satimis/ovirt-engine/ear/target/engine/META-INF/MANIFEST.MF]
> [INFO] Building jar: /home/satimis/ovirt-engine/ear/target/engine.ear
> [INFO]
> [INFO] --- maven-dependency-plugin:2.1:copy (copy-quartz-jar) @
> engine-server-ear ---
> [INFO] Configured Artifact: org.quartz-scheduler:quartz:2.1.2:jar
> [INFO] Copying quartz-2.1.2.jar to
> /home/satimis/ovirt-engine/ear/target/quartz/quartz-2.1.2.jar
> [INFO]
> [INFO] --- maven-antrun-plugin:1.3:run (deploy) @ engine-server-ear ---
> [INFO] Executing tasks
>       [echo] *** Copying updated files from target/engine/ to
> /usr/share/jboss-as/standalone/deployments/engine.ear/...
>       [copy] Copying 1168 files to
> /usr/share/jboss-as/standalone/deployments/engine.ear
>       [copy] Copying
> /home/satimis/ovirt-engine/ear/target/engine/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class
> to
> /usr/share/jboss-as/standalone/deployments/engine.ear/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 15.761s
> [INFO] Finished at: Wed Nov 14 14:34:56 HKT 2012
> [INFO] Final Memory: 16M/295M
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-antrun-plugin:1.3:run (deploy) on project
> engine-server-ear: An Ant BuildException has occured: Failed to copy
> /home/satimis/ovirt-engine/ear/target/engine/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class
> to
> /usr/share/jboss-as/standalone/deployments/engine.ear/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class
> due to java.io.FileNotFoundException
> /usr/share/jboss-as/standalone/deployments/engine.ear/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class
> (No such file or directory) -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the
> -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
>
>
> PluginExecutionException
> https://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
> .....
> You should report this problem to the maintainer of the plugin.
>
>
> Please help.  How to fix this problem and continue?
>
> TIA
>
> B.R.
> Stephen L
>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>

Hi Stephen,

I'd check 2 things first:

1) do permissions/ownership of /usr/share/jboss-as/standalone/deployments 
allow writing?  See [1].
2) did the build (before you tried deployment) complete successfully?

HTH,
Greg

[1] http://wiki.ovirt.org/wiki/Building_oVirt_engine#Installing_JBoss_AS


From gpadgett at redhat.com  Wed Nov 14 19:53:38 2012
From: gpadgett at redhat.com (Greg Padgett)
Date: Wed, 14 Nov 2012 14:53:38 -0500
Subject: [Engine-devel] Deploy error again
In-Reply-To: <50A3F3F7.8000607@redhat.com>
References: <1352876189.81457.YahooMailNeo@web125101.mail.ne1.yahoo.com>
	<50A3F3F7.8000607@redhat.com>
Message-ID: <50A3F6C2.4010706@redhat.com>

On 11/14/2012 02:41 PM, Greg Padgett wrote:
> On 11/14/2012 01:56 AM, Stephen Liu wrote:
>> $ mvn clean install -Pdep,setup
>> /usr/lib/jvm/java
>> [INFO] Scanning for projects...
>> [WARNING]
>> [WARNING] Some problems were encountered while building the effective
>> model for org.ovirt.engine:engine-server-ear:ear:3.1.0
>> [WARNING] 'build.plugins.plugin.version' for
>> org.apache.maven.plugins:maven-ear-plugin is missing. @ line 154, column 15
>> [WARNING] 'distributionManagement.repository.id' must not be 'local', this
>> identifier is reserved for the local repository, using it for other
>> repositories will corrupt your repository metadata. @ line 18, column 11
>> [WARNING]
>> [WARNING] It is highly recommended to fix these problems because they
>> threaten the stability of your build.
>> [WARNING]
>> [WARNING] For this reason, future Maven versions might no longer support
>> building such malformed projects.
>> [WARNING]
>> [INFO]
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Building oVirt Server EAR 3.1.0
>> [INFO]
>> ------------------------------------------------------------------------
>> Downloading:
>> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-antrun-plugin/1.3/maven-antrun-plugin-1.3.pom
>>
>> Downloaded:
>> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-antrun-plugin/1.3/maven-antrun-plugin-1.3.pom
>>
>> (5 KB at 46.7 KB/sec)
>> Downloading:
>> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-antrun-plugin/1.3/maven-antrun-plugin-1.3.jar
>>
>> Downloaded:
>> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-antrun-plugin/1.3/maven-antrun-plugin-1.3.jar
>>
>> (24 KB at 255.8 KB/sec)
>> [INFO]
>> [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @
>> engine-server-ear ---
>> [INFO] Deleting /home/satimis/ovirt-engine/ear/target
>> [INFO]
>> [INFO] --- maven-antrun-plugin:1.3:run (undeploy) @ engine-server-ear ---
>> Downloading:
>> http://repo1.maven.org/maven2/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.pom
>>
>> Downloaded:
>> http://repo1.maven.org/maven2/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.pom
>>
>> (3 KB at 77.6 KB/sec)
>> Downloading:
>> http://repo1.maven.org/maven2/org/apache/ant/ant-parent/1.7.1/ant-parent-1.7.1.pom
>>
>> Downloaded:
>> http://repo1.maven.org/maven2/org/apache/ant/ant-parent/1.7.1/ant-parent-1.7.1.pom
>>
>> (5 KB at 137.9 KB/sec)
>> Downloading:
>> http://repo1.maven.org/maven2/org/apache/ant/ant/1.7.1/ant-1.7.1.pom
>> Downloaded:
>> http://repo1.maven.org/maven2/org/apache/ant/ant/1.7.1/ant-1.7.1.pom (10
>> KB at 232.4 KB/sec)
>> Downloading:
>> http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/1.5.6/plexus-utils-1.5.6.jar
>>
>> Downloading:
>> http://repo1.maven.org/maven2/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.jar
>>
>> Downloading:
>> http://repo1.maven.org/maven2/org/apache/ant/ant/1.7.1/ant-1.7.1.jar
>> Downloaded:
>> http://repo1.maven.org/maven2/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.jar
>>
>> (12 KB at 79.1 KB/sec)
>> Downloaded:
>> http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/1.5.6/plexus-utils-1.5.6.jar
>>
>> (245 KB at 226.5 KB/sec)
>> Downloaded:
>> http://repo1.maven.org/maven2/org/apache/ant/ant/1.7.1/ant-1.7.1.jar (1292
>> KB at 384.3 KB/sec)
>> [INFO] Executing tasks
>>       [echo] *** Deleting
>> /usr/share/jboss-as/standalone/deployments/engine.ear/...
>> [INFO] Executed tasks
>> [INFO]
>> [INFO] --- maven-ear-plugin:2.6:generate-application-xml
>> (default-generate-application-xml) @ engine-server-ear ---
>> [INFO] Generating application.xml
>> [INFO]
>> [INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @
>> engine-server-ear ---
>> [INFO] Using 'UTF-8' encoding to copy filtered resources.
>> [INFO] skip non existing resourceDirectory
>> /home/satimis/ovirt-engine/ear/src/main/java
>> [INFO] Copying 1 resource
>> [INFO]
>> [INFO] --- maven-ear-plugin:2.6:ear (default-ear) @ engine-server-ear ---
>> [INFO] Copying artifact[jar:org.ovirt.engine.core:common:3.1.0]
>> to[lib/engine-common.jar]
>> [INFO] Copying artifact[jar:org.ovirt.engine.core:compat:3.1.0]
>> to[lib/engine-compat.jar]
>> [INFO] Copying artifact[jar:org.ovirt.engine.core:dal:3.1.0]
>> to[lib/engine-dal.jar]
>> [INFO] Copying artifact[jar:org.ovirt.engine.core:utils:3.1.0]
>> to[lib/engine-utils.jar]
>> [INFO] Copying
>> artifact[jar:org.ovirt.engine.core:engineencryptutils:3.1.0]
>> to[lib/engine-encryptutils.jar]
>> [INFO] Copying artifact[jar:org.ovirt.engine.core:vdsbroker:3.1.0]
>> to[lib/engine-vdsbroker.jar]
>> [INFO] Copying artifact[war:org.ovirt.engine.core:root-war:3.1.0]
>> to[root.war] (unpacked)
>> [INFO] Copying artifact[war:org.ovirt.engine.ui:rmw-war:3.1.0]
>> to[ovirtengineweb.war] (unpacked)
>> [INFO] Copying artifact[war:org.ovirt.engine.api:restapi-webapp:3.1.0]
>> to[restapi.war] (unpacked)
>> [INFO] Copying artifact[war:org.ovirt.engine.ui:userportal:3.1.0]
>> to[userportal.war] (unpacked)
>> [INFO] Copying artifact[war:org.ovirt.engine.ui:webadmin:3.1.0]
>> to[webadmin.war] (unpacked)
>> [INFO] Copying artifact[ejb:org.ovirt.engine.ui:genericapi:3.1.0]
>> to[engine-genericapi.jar] (unpacked)
>> [INFO] Copying artifact[ejb:org.ovirt.engine.core:scheduler:3.1.0]
>> to[engine-scheduler.jar] (unpacked)
>> [INFO] Copying artifact[ejb:org.ovirt.engine.core:bll:3.1.0]
>> to[engine-bll.jar] (unpacked)
>> [INFO] Copying artifact[jar:commons-codec:commons-codec:1.4]
>> to[lib/commons-codec-1.4.jar]
>> [INFO] Copying artifact[jar:org.hibernate:hibernate-validator:4.0.2.GA]
>> to[lib/hibernate-validator-4.0.2.GA.jar]
>> [INFO] Copying artifact[jar:javax.validation:validation-api:1.0.0.GA]
>> to[lib/validation-api-1.0.0.GA.jar]
>> [INFO] Copying artifact[jar:org.slf4j:slf4j-api:1.5.6]
>> to[lib/slf4j-api-1.5.6.jar]
>> [INFO] Copying artifact[jar:javax.xml.bind:jaxb-api:2.1]
>> to[lib/jaxb-api-2.1.jar]
>> [INFO] Copying artifact[jar:javax.xml.stream:stax-api:1.0-2]
>> to[lib/stax-api-1.0-2.jar]
>> [INFO] Copying artifact[jar:javax.activation:activation:1.1]
>> to[lib/activation-1.1.jar]
>> [INFO] Copying artifact[jar:com.sun.xml.bind:jaxb-impl:2.1.3]
>> to[lib/jaxb-impl-2.1.3.jar]
>> [INFO] Copying artifact[jar:org.hibernate:hibernate-annotations:3.4.0.GA]
>> to[lib/hibernate-annotations-3.4.0.GA.jar]
>> [INFO] Copying artifact[jar:org.hibernate:ejb3-persistence:1.0.2.GA]
>> to[lib/ejb3-persistence-1.0.2.GA.jar]
>> [INFO] Copying
>> artifact[jar:org.hibernate:hibernate-commons-annotations:3.1.0.GA]
>> to[lib/hibernate-commons-annotations-3.1.0.GA.jar]
>> [INFO] Copying artifact[jar:org.hibernate:hibernate-core:3.3.0.SP1]
>> to[lib/hibernate-core-3.3.0.SP1.jar]
>> [INFO] Copying artifact[jar:antlr:antlr:2.7.6] to[lib/antlr-2.7.6.jar]
>> [INFO] Copying artifact[jar:dom4j:dom4j:1.6.1] to[lib/dom4j-1.6.1.jar]
>> [INFO] Copying artifact[jar:xml-apis:xml-apis:1.0.b2]
>> to[lib/xml-apis-1.0.b2.jar]
>> [INFO] Copying
>> artifact[jar:org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.1_spec:1.0.0.Final]
>>
>> to[lib/jboss-interceptors-api_1.1_spec-1.0.0.Final.jar]
>> [INFO] Copying
>> artifact[jar:org.ovirt.engine.core:engine-tools-common:3.1.0]
>> to[lib/engine-tools-common-3.1.0.jar]
>> [INFO] Copying artifact[jar:commons-beanutils:commons-beanutils:1.8.2]
>> to[lib/commons-beanutils-1.8.2.jar]
>> [INFO] Copying artifact[jar:org.apache.mina:mina-core:2.0.1]
>> to[lib/mina-core-2.0.1.jar]
>> [INFO] Copying artifact[jar:org.apache.sshd:sshd-core:0.7.0]
>> to[lib/sshd-core-0.7.0.jar]
>> [INFO] Copying artifact[jar:org.apache.commons:commons-compress:1.3]
>> to[lib/commons-compress-1.3.jar]
>> [INFO] Copying artifact[jar:commons-lang:commons-lang:2.4]
>> to[lib/commons-lang-2.4.jar]
>> [INFO] Copying artifact[jar:org.apache.xmlrpc:xmlrpc-client:3.1.3]
>> to[lib/xmlrpc-client-3.1.3.jar]
>> [INFO] Copying artifact[jar:org.apache.xmlrpc:xmlrpc-common:3.1.3]
>> to[lib/xmlrpc-common-3.1.3.jar]
>> [INFO] Copying
>> artifact[jar:org.apache.ws.commons.util:ws-commons-util:1.0.2]
>> to[lib/ws-commons-util-1.0.2.jar]
>> [INFO] Copying artifact[jar:org.springframework:spring-jdbc:3.1.1.RELEASE]
>> to[lib/spring-jdbc-3.1.1.RELEASE.jar]
>> [INFO] Copying artifact[jar:org.springframework:spring-tx:3.1.1.RELEASE]
>> to[lib/spring-tx-3.1.1.RELEASE.jar]
>> [INFO] Copying
>> artifact[jar:org.springframework.ldap:spring-ldap-core:1.3.1.RELEASE]
>> to[lib/spring-ldap-core-1.3.1.RELEASE.jar]
>> [INFO] Copying artifact[jar:commons-httpclient:commons-httpclient:3.1]
>> to[lib/commons-httpclient-3.1.jar]
>> [INFO] Copying artifact[jar:commons-collections:commons-collections:3.1]
>> to[lib/commons-collections-3.1.jar]
>> [INFO] Copying artifact[jar:org.quartz-scheduler:quartz:2.1.2]
>> to[lib/quartz-2.1.2.jar]
>> [INFO] Copying artifact[jar:c3p0:c3p0:0.9.1.1] to[lib/c3p0-0.9.1.1.jar]
>> [INFO] Copying artifact[jar:org.ovirt.engine.core:searchbackend:3.1.0]
>> to[lib/searchbackend-3.1.0.jar]
>> [INFO] Copying artifact[jar:org.springframework:spring-core:3.1.1.RELEASE]
>> to[lib/spring-core-3.1.1.RELEASE.jar]
>> [INFO] Copying artifact[jar:org.springframework:spring-asm:3.1.1.RELEASE]
>> to[lib/spring-asm-3.1.1.RELEASE.jar]
>> [INFO] Copying
>> artifact[jar:org.springframework:spring-beans:3.1.1.RELEASE]
>> to[lib/spring-beans-3.1.1.RELEASE.jar]
>> [INFO] Copying
>> artifact[jar:org.springframework:spring-context:3.1.1.RELEASE]
>> to[lib/spring-context-3.1.1.RELEASE.jar]
>> [INFO] Copying artifact[jar:org.springframework:spring-aop:3.1.1.RELEASE]
>> to[lib/spring-aop-3.1.1.RELEASE.jar]
>> [INFO] Copying artifact[jar:aopalliance:aopalliance:1.0]
>> to[lib/aopalliance-1.0.jar]
>> [INFO] Copying
>> artifact[jar:org.springframework:spring-expression:3.1.1.RELEASE]
>> to[lib/spring-expression-3.1.1.RELEASE.jar]
>> [INFO] Copy ear sources to /home/satimis/ovirt-engine/ear/target/engine
>> [WARNING] resourcesDir is deprecated. Please use the earSourceDirectory
>> property instead.
>> [INFO] Copy ear resources to /home/satimis/ovirt-engine/ear/target/engine
>> [INFO] Including custom manifest
>> file[/home/satimis/ovirt-engine/ear/target/engine/META-INF/MANIFEST.MF]
>> [INFO] Building jar: /home/satimis/ovirt-engine/ear/target/engine.ear
>> [INFO]
>> [INFO] --- maven-dependency-plugin:2.1:copy (copy-quartz-jar) @
>> engine-server-ear ---
>> [INFO] Configured Artifact: org.quartz-scheduler:quartz:2.1.2:jar
>> [INFO] Copying quartz-2.1.2.jar to
>> /home/satimis/ovirt-engine/ear/target/quartz/quartz-2.1.2.jar
>> [INFO]
>> [INFO] --- maven-antrun-plugin:1.3:run (deploy) @ engine-server-ear ---
>> [INFO] Executing tasks
>>       [echo] *** Copying updated files from target/engine/ to
>> /usr/share/jboss-as/standalone/deployments/engine.ear/...
>>       [copy] Copying 1168 files to
>> /usr/share/jboss-as/standalone/deployments/engine.ear
>>       [copy] Copying
>> /home/satimis/ovirt-engine/ear/target/engine/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class
>>
>> to
>> /usr/share/jboss-as/standalone/deployments/engine.ear/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class
>>
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] BUILD FAILURE
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Total time: 15.761s
>> [INFO] Finished at: Wed Nov 14 14:34:56 HKT 2012
>> [INFO] Final Memory: 16M/295M
>> [INFO]
>> ------------------------------------------------------------------------
>> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-antrun-plugin:1.3:run (deploy) on project
>> engine-server-ear: An Ant BuildException has occured: Failed to copy
>> /home/satimis/ovirt-engine/ear/target/engine/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class
>>
>> to
>> /usr/share/jboss-as/standalone/deployments/engine.ear/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class
>>
>> due to java.io.FileNotFoundException
>> /usr/share/jboss-as/standalone/deployments/engine.ear/engine-bll.jar/org/ovirt/engine/core/bll/VmCountVdsLoadBalancingAlgorithm$1.class
>>
>> (No such file or directory) -> [Help 1]
>> [ERROR]
>> [ERROR] To see the full stack trace of the errors, re-run Maven with the
>> -e switch.
>> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>> [ERROR]
>> [ERROR] For more information about the errors and possible solutions,
>> please read the following articles:
>> [ERROR] [Help 1]
>> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
>>
>>
>> PluginExecutionException
>> https://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
>> .....
>> You should report this problem to the maintainer of the plugin.
>>
>>
>> Please help.  How to fix this problem and continue?
>>
>> TIA
>>
>> B.R.
>> Stephen L
>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>
> Hi Stephen,
>
> I'd check 2 things first:
>
> 1) do permissions/ownership of /usr/share/jboss-as/standalone/deployments
> allow writing?  See [1].
> 2) did the build (before you tried deployment) complete successfully?
>
> HTH,
> Greg
>
> [1] http://wiki.ovirt.org/wiki/Building_oVirt_engine#Installing_JBoss_AS
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel

I just saw the other threads and some confusion due to mailing list 
issues, sorry for the noise.

Greg


From abaron at redhat.com  Thu Nov 15 00:22:02 2012
From: abaron at redhat.com (Ayal Baron)
Date: Wed, 14 Nov 2012 19:22:02 -0500 (EST)
Subject: [Engine-devel] Proposal to add Allon Mureinik as
	maintainer	to	engine core
In-Reply-To: <439468570.7503412.1352901622764.JavaMail.root@redhat.com>
Message-ID: <369018205.10731815.1352938922478.JavaMail.root@redhat.com>

+1
Well deserved.


----- Original Message -----
> +1
> 
> ----- Original Message -----
> > From: "Itamar Heim" <iheim at redhat.com>
> > To: engine-devel at ovirt.org
> > Sent: Wednesday, November 14, 2012 6:12:09 AM
> > Subject: [Engine-devel] Proposal to add Allon Mureinik as
> > maintainer to	engine core
> > 
> > Allon has worked on oVirt for the past 10 months.
> > With 534 patches ranging from cleanups, to complex features like
> > user
> > level api and storage live migration. In addition, Allon has been
> > instrumental in the number of patch reviews he has done.
> > 
> > I'd like to propose Allon as a maintainer of engine core.
> > 
> > Thanks,
> >     Itamar
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From iheim at redhat.com  Thu Nov 15 03:19:06 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 15 Nov 2012 05:19:06 +0200
Subject: [Engine-devel] Proposal to add Allon Mureinik as maintainer to
 engine core
In-Reply-To: <50A31A19.7040602@redhat.com>
References: <50A31A19.7040602@redhat.com>
Message-ID: <50A45F2A.5010203@redhat.com>

On 11/14/2012 06:12 AM, Itamar Heim wrote:
> Allon has worked on oVirt for the past 10 months.
> With 534 patches ranging from cleanups, to complex features like user
> level api and storage live migration. In addition, Allon has been
> instrumental in the number of patch reviews he has done.
>
> I'd like to propose Allon as a maintainer of engine core.

per the resounding +1 (even if somewhat delayed by mail server issues), 
and no objections, added Allon as maintainer of engine core.
dave - can you please take care of updating the web site?

thanks,
    Itamar



From iheim at redhat.com  Thu Nov 15 03:57:43 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 15 Nov 2012 05:57:43 +0200
Subject: [Engine-devel] Network Wiring
In-Reply-To: <999476552.1216069.1352818012177.JavaMail.root@redhat.com>
References: <999476552.1216069.1352818012177.JavaMail.root@redhat.com>
Message-ID: <50A46837.5040201@redhat.com>

On 11/13/2012 04:46 PM, Alona Kaplan wrote:
> Hi all,
>
> Please review the wiki and add your comments.
>
> http://wiki.ovirt.org/wiki/Feature/NetworkWiring

 >     Dialog
 >
 >         If the VM status is 'UP'
 >
 >             If the Vnic is plugged there should be a message on top 
of the dialog "Please notice, changing Type or MAC will cause unplugging 
and plugging the Vnic".
 >             Port Mirroring - If the Vnic is plugged and the Vnic is 
set for port mirroring - "network", "type", "mac" and "port mirroring" 
fields in the dialog will be disabled.

can user change the type if port mirroring isn't enabled? doesn't this 
require unplug/plug back?
I assume all validations are at engine side to cover rest api as well?

 > REST API
 >
 > NIC properties:
 >
 > Changes:
 >
 >     Adding new properties under VM NIC:
 >
 >         plugged
 >         wired
 >
 >     Deprecating the active property under VM NIC
 >     Deprecating activate/deactivate actions
 >     Plug/unplug and wire/unwire on a vnic, will be done via PUT 
action on the VM NIC
 >         /api/vms/xxx/nics/yyy/
 >

that's a lot of deprecation - you can mark them as deprecated, but they 
still need to work over a period of time for backward compatibility, so 
please explain what they will show/how they behave until they are 
deprecated.

 > There is no reason to have dedicated actions for plug/unplug or 
wire/unwire. The original reason for having them was that edit VM nic 
while the VM was up used to be blocked and now we'll enable doing these 
actions.

actually, some users may not want to make these config changes while the 
VM is live, just to make them for the next boot. how will that work?

i agree with other comments that 'wired' is a bit confusing.
s/wired-unwired/connected-disconnected/?


From iheim at redhat.com  Thu Nov 15 04:10:21 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 15 Nov 2012 06:10:21 +0200
Subject: [Engine-devel] SPICE IP override
In-Reply-To: <509F73BE.4020301@redhat.com>
References: <1197121097.6204891.1352278334446.JavaMail.root@redhat.com>
	<509F73BE.4020301@redhat.com>
Message-ID: <50A46B2D.9040501@redhat.com>

On 11/11/2012 11:45 AM, Yaniv Kaul wrote:
> On 11/07/2012 10:52 AM, Simon Grinberg wrote:
>>
>> ----- Original Message -----
>>> From: "Michal Skrivanek"<michal.skrivanek at redhat.com>
>>> To:engine-devel at ovirt.org
>>> Sent: Tuesday, November 6, 2012 10:39:58 PM
>>> Subject: [Engine-devel] SPICE IP override
>>>
>>> Hi all,
>>> On behalf of Tomas - please check out the proposal for enhancing our
>>> SPICE integration to allow to return a custom IP/FQDN instead of the
>>> host IP address.
>>> http://wiki.ovirt.org/wiki/Features/Display_Address_Override
>>> All comments are welcome...
>> My 2 cents,
>>
>> This works under the assumption that all the users are either outside of the organization or inside.
>> But think of some of the following scenarios based on a topology where users in the main office are inside the corporate network while users on remote offices / WAN are on a detached different network on the other side of the NAT / public firewall :
>>
>> With current 'per host override' proposal:
>> 1. Admin from the main office won't be able to access the VM console
>> 2. No Mixed environment, meaning that you have to have designated clusters for remote offices users vs main office users - otherwise connectivity to the console is determined based on scheduler decision, or may break by live migration.
>> 3. Based on #2, If I'm a user travelling between offices I'll have to ask the admin to turn off my VM and move it to internal cluster before I can reconnect
>>
>> My suggestion is to covert this to 'alternative' IP/FQDN sending the spice client both internal fqdn/ip and the alternative. The spice client should detect which is available of the two and auto-connect.
>>
>> This requires enhancement of the spice client, but still solves all the issues raised above (actually it solves about 90% of the use cases I've heard about in the past).
>>
>> Another alternative is for the engine to 'guess' or 'elect' which to use, alternative or main, based on the IP of the client - meaning admin provides the client ranges for providing internal host address vs alternative - but this is more complicated compared for the previous suggestion
>>
>> Thoughts?
>
> Lets not re-invent the wheel. This problem has been pondered before and
> solved[1], for all scenarios:
> internal clients connecting to internal resources;
> internal clients connecting to external resources, without the need for
> any intermediate assistance
> external clients connecting to internal resources, with the need for
> intermediate assistance.
> VPN clients connecting to internal resources, with or without an
> internal IP.
>
> Any other solution you'll try to come up with will bring you back to
> this standard, well known (along with its faults) method.
>
> The browser client will use PAC to determine how to connect to the hosts
> and will deliver this to the client. It's also a good path towards real
> proxy support for Spice.
> (Regardless, we still need to deal with the Spice protocol's migration
> command of course).
>
>
> [1] http://en.wikipedia.org/wiki/Proxy_auto-config

so instead of a spice proxy fqdn field, we should just allow user to 
specify a pac file which resides under something like 
/etc/ovirt/engine/pac...?


From acathrow at redhat.com  Thu Nov 15 04:13:49 2012
From: acathrow at redhat.com (Andrew Cathrow)
Date: Wed, 14 Nov 2012 23:13:49 -0500 (EST)
Subject: [Engine-devel] SPICE IP override
In-Reply-To: <50A46B2D.9040501@redhat.com>
Message-ID: <412665735.26660875.1352952829658.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Yaniv Kaul" <ykaul at redhat.com>
> Cc: "Simon Grinberg" <simon at redhat.com>, engine-devel at ovirt.org
> Sent: Wednesday, November 14, 2012 11:10:21 PM
> Subject: Re: [Engine-devel] SPICE IP override
> 
> On 11/11/2012 11:45 AM, Yaniv Kaul wrote:
> > On 11/07/2012 10:52 AM, Simon Grinberg wrote:
> >>
> >> ----- Original Message -----
> >>> From: "Michal Skrivanek"<michal.skrivanek at redhat.com>
> >>> To:engine-devel at ovirt.org
> >>> Sent: Tuesday, November 6, 2012 10:39:58 PM
> >>> Subject: [Engine-devel] SPICE IP override
> >>>
> >>> Hi all,
> >>> On behalf of Tomas - please check out the proposal for enhancing
> >>> our
> >>> SPICE integration to allow to return a custom IP/FQDN instead of
> >>> the
> >>> host IP address.
> >>> http://wiki.ovirt.org/wiki/Features/Display_Address_Override
> >>> All comments are welcome...
> >> My 2 cents,
> >>
> >> This works under the assumption that all the users are either
> >> outside of the organization or inside.
> >> But think of some of the following scenarios based on a topology
> >> where users in the main office are inside the corporate network
> >> while users on remote offices / WAN are on a detached different
> >> network on the other side of the NAT / public firewall :
> >>
> >> With current 'per host override' proposal:
> >> 1. Admin from the main office won't be able to access the VM
> >> console
> >> 2. No Mixed environment, meaning that you have to have designated
> >> clusters for remote offices users vs main office users -
> >> otherwise connectivity to the console is determined based on
> >> scheduler decision, or may break by live migration.
> >> 3. Based on #2, If I'm a user travelling between offices I'll have
> >> to ask the admin to turn off my VM and move it to internal
> >> cluster before I can reconnect
> >>
> >> My suggestion is to covert this to 'alternative' IP/FQDN sending
> >> the spice client both internal fqdn/ip and the alternative. The
> >> spice client should detect which is available of the two and
> >> auto-connect.
> >>
> >> This requires enhancement of the spice client, but still solves
> >> all the issues raised above (actually it solves about 90% of the
> >> use cases I've heard about in the past).
> >>
> >> Another alternative is for the engine to 'guess' or 'elect' which
> >> to use, alternative or main, based on the IP of the client -
> >> meaning admin provides the client ranges for providing internal
> >> host address vs alternative - but this is more complicated
> >> compared for the previous suggestion
> >>
> >> Thoughts?
> >
> > Lets not re-invent the wheel. This problem has been pondered before
> > and
> > solved[1], for all scenarios:
> > internal clients connecting to internal resources;
> > internal clients connecting to external resources, without the need
> > for
> > any intermediate assistance
> > external clients connecting to internal resources, with the need
> > for
> > intermediate assistance.
> > VPN clients connecting to internal resources, with or without an
> > internal IP.
> >
> > Any other solution you'll try to come up with will bring you back
> > to
> > this standard, well known (along with its faults) method.
> >
> > The browser client will use PAC to determine how to connect to the
> > hosts
> > and will deliver this to the client. It's also a good path towards
> > real
> > proxy support for Spice.
> > (Regardless, we still need to deal with the Spice protocol's
> > migration
> > command of course).
> >
> >
> > [1] http://en.wikipedia.org/wiki/Proxy_auto-config
> 
> so instead of a spice proxy fqdn field, we should just allow user to
> specify a pac file which resides under something like
> /etc/ovirt/engine/pac...?

Doesn't this presume that the user allows a single site to set his proxy settings, which seems rather insecure?

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


From ykaul at redhat.com  Thu Nov 15 06:33:33 2012
From: ykaul at redhat.com (Yaniv Kaul)
Date: Thu, 15 Nov 2012 08:33:33 +0200
Subject: [Engine-devel] SPICE IP override
In-Reply-To: <50A46B2D.9040501@redhat.com>
References: <1197121097.6204891.1352278334446.JavaMail.root@redhat.com>
	<509F73BE.4020301@redhat.com> <50A46B2D.9040501@redhat.com>
Message-ID: <50A48CBD.1080400@redhat.com>

On 11/15/2012 06:10 AM, Itamar Heim wrote:
> On 11/11/2012 11:45 AM, Yaniv Kaul wrote:
>> On 11/07/2012 10:52 AM, Simon Grinberg wrote:
>>>
>>> ----- Original Message -----
>>>> From: "Michal Skrivanek"<michal.skrivanek at redhat.com>
>>>> To:engine-devel at ovirt.org
>>>> Sent: Tuesday, November 6, 2012 10:39:58 PM
>>>> Subject: [Engine-devel] SPICE IP override
>>>>
>>>> Hi all,
>>>> On behalf of Tomas - please check out the proposal for enhancing our
>>>> SPICE integration to allow to return a custom IP/FQDN instead of the
>>>> host IP address.
>>>> http://wiki.ovirt.org/wiki/Features/Display_Address_Override
>>>> All comments are welcome...
>>> My 2 cents,
>>>
>>> This works under the assumption that all the users are either 
>>> outside of the organization or inside.
>>> But think of some of the following scenarios based on a topology 
>>> where users in the main office are inside the corporate network 
>>> while users on remote offices / WAN are on a detached different 
>>> network on the other side of the NAT / public firewall :
>>>
>>> With current 'per host override' proposal:
>>> 1. Admin from the main office won't be able to access the VM console
>>> 2. No Mixed environment, meaning that you have to have designated 
>>> clusters for remote offices users vs main office users - otherwise 
>>> connectivity to the console is determined based on scheduler 
>>> decision, or may break by live migration.
>>> 3. Based on #2, If I'm a user travelling between offices I'll have 
>>> to ask the admin to turn off my VM and move it to internal cluster 
>>> before I can reconnect
>>>
>>> My suggestion is to covert this to 'alternative' IP/FQDN sending the 
>>> spice client both internal fqdn/ip and the alternative. The spice 
>>> client should detect which is available of the two and auto-connect.
>>>
>>> This requires enhancement of the spice client, but still solves all 
>>> the issues raised above (actually it solves about 90% of the use 
>>> cases I've heard about in the past).
>>>
>>> Another alternative is for the engine to 'guess' or 'elect' which to 
>>> use, alternative or main, based on the IP of the client - meaning 
>>> admin provides the client ranges for providing internal host address 
>>> vs alternative - but this is more complicated compared for the 
>>> previous suggestion
>>>
>>> Thoughts?
>>
>> Lets not re-invent the wheel. This problem has been pondered before and
>> solved[1], for all scenarios:
>> internal clients connecting to internal resources;
>> internal clients connecting to external resources, without the need for
>> any intermediate assistance
>> external clients connecting to internal resources, with the need for
>> intermediate assistance.
>> VPN clients connecting to internal resources, with or without an
>> internal IP.
>>
>> Any other solution you'll try to come up with will bring you back to
>> this standard, well known (along with its faults) method.
>>
>> The browser client will use PAC to determine how to connect to the hosts
>> and will deliver this to the client. It's also a good path towards real
>> proxy support for Spice.
>> (Regardless, we still need to deal with the Spice protocol's migration
>> command of course).
>>
>>
>> [1] http://en.wikipedia.org/wiki/Proxy_auto-config
>
> so instead of a spice proxy fqdn field, we should just allow user to 
> specify a pac file which resides under something like 
> /etc/ovirt/engine/pac...?

I would actually encourage the customers to use their own corporate PAC 
and add the information to it.
Y.



From ykaul at redhat.com  Thu Nov 15 06:34:19 2012
From: ykaul at redhat.com (Yaniv Kaul)
Date: Thu, 15 Nov 2012 08:34:19 +0200
Subject: [Engine-devel] SPICE IP override
In-Reply-To: <412665735.26660875.1352952829658.JavaMail.root@redhat.com>
References: <412665735.26660875.1352952829658.JavaMail.root@redhat.com>
Message-ID: <50A48CEB.9000005@redhat.com>

On 11/15/2012 06:13 AM, Andrew Cathrow wrote:
>
> ----- Original Message -----
>> From: "Itamar Heim" <iheim at redhat.com>
>> To: "Yaniv Kaul" <ykaul at redhat.com>
>> Cc: "Simon Grinberg" <simon at redhat.com>, engine-devel at ovirt.org
>> Sent: Wednesday, November 14, 2012 11:10:21 PM
>> Subject: Re: [Engine-devel] SPICE IP override
>>
>> On 11/11/2012 11:45 AM, Yaniv Kaul wrote:
>>> On 11/07/2012 10:52 AM, Simon Grinberg wrote:
>>>> ----- Original Message -----
>>>>> From: "Michal Skrivanek"<michal.skrivanek at redhat.com>
>>>>> To:engine-devel at ovirt.org
>>>>> Sent: Tuesday, November 6, 2012 10:39:58 PM
>>>>> Subject: [Engine-devel] SPICE IP override
>>>>>
>>>>> Hi all,
>>>>> On behalf of Tomas - please check out the proposal for enhancing
>>>>> our
>>>>> SPICE integration to allow to return a custom IP/FQDN instead of
>>>>> the
>>>>> host IP address.
>>>>> http://wiki.ovirt.org/wiki/Features/Display_Address_Override
>>>>> All comments are welcome...
>>>> My 2 cents,
>>>>
>>>> This works under the assumption that all the users are either
>>>> outside of the organization or inside.
>>>> But think of some of the following scenarios based on a topology
>>>> where users in the main office are inside the corporate network
>>>> while users on remote offices / WAN are on a detached different
>>>> network on the other side of the NAT / public firewall :
>>>>
>>>> With current 'per host override' proposal:
>>>> 1. Admin from the main office won't be able to access the VM
>>>> console
>>>> 2. No Mixed environment, meaning that you have to have designated
>>>> clusters for remote offices users vs main office users -
>>>> otherwise connectivity to the console is determined based on
>>>> scheduler decision, or may break by live migration.
>>>> 3. Based on #2, If I'm a user travelling between offices I'll have
>>>> to ask the admin to turn off my VM and move it to internal
>>>> cluster before I can reconnect
>>>>
>>>> My suggestion is to covert this to 'alternative' IP/FQDN sending
>>>> the spice client both internal fqdn/ip and the alternative. The
>>>> spice client should detect which is available of the two and
>>>> auto-connect.
>>>>
>>>> This requires enhancement of the spice client, but still solves
>>>> all the issues raised above (actually it solves about 90% of the
>>>> use cases I've heard about in the past).
>>>>
>>>> Another alternative is for the engine to 'guess' or 'elect' which
>>>> to use, alternative or main, based on the IP of the client -
>>>> meaning admin provides the client ranges for providing internal
>>>> host address vs alternative - but this is more complicated
>>>> compared for the previous suggestion
>>>>
>>>> Thoughts?
>>> Lets not re-invent the wheel. This problem has been pondered before
>>> and
>>> solved[1], for all scenarios:
>>> internal clients connecting to internal resources;
>>> internal clients connecting to external resources, without the need
>>> for
>>> any intermediate assistance
>>> external clients connecting to internal resources, with the need
>>> for
>>> intermediate assistance.
>>> VPN clients connecting to internal resources, with or without an
>>> internal IP.
>>>
>>> Any other solution you'll try to come up with will bring you back
>>> to
>>> this standard, well known (along with its faults) method.
>>>
>>> The browser client will use PAC to determine how to connect to the
>>> hosts
>>> and will deliver this to the client. It's also a good path towards
>>> real
>>> proxy support for Spice.
>>> (Regardless, we still need to deal with the Spice protocol's
>>> migration
>>> command of course).
>>>
>>>
>>> [1] http://en.wikipedia.org/wiki/Proxy_auto-config
>> so instead of a spice proxy fqdn field, we should just allow user to
>> specify a pac file which resides under something like
>> /etc/ovirt/engine/pac...?
> Doesn't this presume that the user allows a single site to set his proxy settings, which seems rather insecure?

The PAC is retrieved via HTTPS, so it's supposedly secure.
In a corporate environment you have your company's PAC anyway.
Y.

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



From iheim at redhat.com  Thu Nov 15 06:58:45 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 15 Nov 2012 08:58:45 +0200
Subject: [Engine-devel] SPICE IP override
In-Reply-To: <50A48CBD.1080400@redhat.com>
References: <1197121097.6204891.1352278334446.JavaMail.root@redhat.com>
	<509F73BE.4020301@redhat.com> <50A46B2D.9040501@redhat.com>
	<50A48CBD.1080400@redhat.com>
Message-ID: <50A492A5.4060809@redhat.com>

On 11/15/2012 08:33 AM, Yaniv Kaul wrote:
> On 11/15/2012 06:10 AM, Itamar Heim wrote:
>> On 11/11/2012 11:45 AM, Yaniv Kaul wrote:
>>> On 11/07/2012 10:52 AM, Simon Grinberg wrote:
>>>>
>>>> ----- Original Message -----
>>>>> From: "Michal Skrivanek"<michal.skrivanek at redhat.com>
>>>>> To:engine-devel at ovirt.org
>>>>> Sent: Tuesday, November 6, 2012 10:39:58 PM
>>>>> Subject: [Engine-devel] SPICE IP override
>>>>>
>>>>> Hi all,
>>>>> On behalf of Tomas - please check out the proposal for enhancing our
>>>>> SPICE integration to allow to return a custom IP/FQDN instead of the
>>>>> host IP address.
>>>>> http://wiki.ovirt.org/wiki/Features/Display_Address_Override
>>>>> All comments are welcome...
>>>> My 2 cents,
>>>>
>>>> This works under the assumption that all the users are either
>>>> outside of the organization or inside.
>>>> But think of some of the following scenarios based on a topology
>>>> where users in the main office are inside the corporate network
>>>> while users on remote offices / WAN are on a detached different
>>>> network on the other side of the NAT / public firewall :
>>>>
>>>> With current 'per host override' proposal:
>>>> 1. Admin from the main office won't be able to access the VM console
>>>> 2. No Mixed environment, meaning that you have to have designated
>>>> clusters for remote offices users vs main office users - otherwise
>>>> connectivity to the console is determined based on scheduler
>>>> decision, or may break by live migration.
>>>> 3. Based on #2, If I'm a user travelling between offices I'll have
>>>> to ask the admin to turn off my VM and move it to internal cluster
>>>> before I can reconnect
>>>>
>>>> My suggestion is to covert this to 'alternative' IP/FQDN sending the
>>>> spice client both internal fqdn/ip and the alternative. The spice
>>>> client should detect which is available of the two and auto-connect.
>>>>
>>>> This requires enhancement of the spice client, but still solves all
>>>> the issues raised above (actually it solves about 90% of the use
>>>> cases I've heard about in the past).
>>>>
>>>> Another alternative is for the engine to 'guess' or 'elect' which to
>>>> use, alternative or main, based on the IP of the client - meaning
>>>> admin provides the client ranges for providing internal host address
>>>> vs alternative - but this is more complicated compared for the
>>>> previous suggestion
>>>>
>>>> Thoughts?
>>>
>>> Lets not re-invent the wheel. This problem has been pondered before and
>>> solved[1], for all scenarios:
>>> internal clients connecting to internal resources;
>>> internal clients connecting to external resources, without the need for
>>> any intermediate assistance
>>> external clients connecting to internal resources, with the need for
>>> intermediate assistance.
>>> VPN clients connecting to internal resources, with or without an
>>> internal IP.
>>>
>>> Any other solution you'll try to come up with will bring you back to
>>> this standard, well known (along with its faults) method.
>>>
>>> The browser client will use PAC to determine how to connect to the hosts
>>> and will deliver this to the client. It's also a good path towards real
>>> proxy support for Spice.
>>> (Regardless, we still need to deal with the Spice protocol's migration
>>> command of course).
>>>
>>>
>>> [1] http://en.wikipedia.org/wiki/Proxy_auto-config
>>
>> so instead of a spice proxy fqdn field, we should just allow user to
>> specify a pac file which resides under something like
>> /etc/ovirt/engine/pac...?
>
> I would actually encourage the customers to use their own corporate PAC
> and add the information to it.

so you are suggesting that there is no need at all to deal with proxy 
definition/configuration at ovirt engine/user portal level?




From ykaul at redhat.com  Thu Nov 15 07:06:24 2012
From: ykaul at redhat.com (Yaniv Kaul)
Date: Thu, 15 Nov 2012 02:06:24 -0500 (EST)
Subject: [Engine-devel] SPICE IP override
In-Reply-To: <50A492A5.4060809@redhat.com>
Message-ID: <1102502848.10802488.1352963184183.JavaMail.root@redhat.com>

----- Original Message -----
> On 11/15/2012 08:33 AM, Yaniv Kaul wrote:
> > On 11/15/2012 06:10 AM, Itamar Heim wrote:
> >> On 11/11/2012 11:45 AM, Yaniv Kaul wrote:
> >>> On 11/07/2012 10:52 AM, Simon Grinberg wrote:
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Michal Skrivanek"<michal.skrivanek at redhat.com>
> >>>>> To:engine-devel at ovirt.org
> >>>>> Sent: Tuesday, November 6, 2012 10:39:58 PM
> >>>>> Subject: [Engine-devel] SPICE IP override
> >>>>>
> >>>>> Hi all,
> >>>>> On behalf of Tomas - please check out the proposal for
> >>>>> enhancing our
> >>>>> SPICE integration to allow to return a custom IP/FQDN instead
> >>>>> of the
> >>>>> host IP address.
> >>>>> http://wiki.ovirt.org/wiki/Features/Display_Address_Override
> >>>>> All comments are welcome...
> >>>> My 2 cents,
> >>>>
> >>>> This works under the assumption that all the users are either
> >>>> outside of the organization or inside.
> >>>> But think of some of the following scenarios based on a topology
> >>>> where users in the main office are inside the corporate network
> >>>> while users on remote offices / WAN are on a detached different
> >>>> network on the other side of the NAT / public firewall :
> >>>>
> >>>> With current 'per host override' proposal:
> >>>> 1. Admin from the main office won't be able to access the VM
> >>>> console
> >>>> 2. No Mixed environment, meaning that you have to have
> >>>> designated
> >>>> clusters for remote offices users vs main office users -
> >>>> otherwise
> >>>> connectivity to the console is determined based on scheduler
> >>>> decision, or may break by live migration.
> >>>> 3. Based on #2, If I'm a user travelling between offices I'll
> >>>> have
> >>>> to ask the admin to turn off my VM and move it to internal
> >>>> cluster
> >>>> before I can reconnect
> >>>>
> >>>> My suggestion is to covert this to 'alternative' IP/FQDN sending
> >>>> the
> >>>> spice client both internal fqdn/ip and the alternative. The
> >>>> spice
> >>>> client should detect which is available of the two and
> >>>> auto-connect.
> >>>>
> >>>> This requires enhancement of the spice client, but still solves
> >>>> all
> >>>> the issues raised above (actually it solves about 90% of the use
> >>>> cases I've heard about in the past).
> >>>>
> >>>> Another alternative is for the engine to 'guess' or 'elect'
> >>>> which to
> >>>> use, alternative or main, based on the IP of the client -
> >>>> meaning
> >>>> admin provides the client ranges for providing internal host
> >>>> address
> >>>> vs alternative - but this is more complicated compared for the
> >>>> previous suggestion
> >>>>
> >>>> Thoughts?
> >>>
> >>> Lets not re-invent the wheel. This problem has been pondered
> >>> before and
> >>> solved[1], for all scenarios:
> >>> internal clients connecting to internal resources;
> >>> internal clients connecting to external resources, without the
> >>> need for
> >>> any intermediate assistance
> >>> external clients connecting to internal resources, with the need
> >>> for
> >>> intermediate assistance.
> >>> VPN clients connecting to internal resources, with or without an
> >>> internal IP.
> >>>
> >>> Any other solution you'll try to come up with will bring you back
> >>> to
> >>> this standard, well known (along with its faults) method.
> >>>
> >>> The browser client will use PAC to determine how to connect to
> >>> the hosts
> >>> and will deliver this to the client. It's also a good path
> >>> towards real
> >>> proxy support for Spice.
> >>> (Regardless, we still need to deal with the Spice protocol's
> >>> migration
> >>> command of course).
> >>>
> >>>
> >>> [1] http://en.wikipedia.org/wiki/Proxy_auto-config
> >>
> >> so instead of a spice proxy fqdn field, we should just allow user
> >> to
> >> specify a pac file which resides under something like
> >> /etc/ovirt/engine/pac...?
> >
> > I would actually encourage the customers to use their own corporate
> > PAC
> > and add the information to it.
> 
> so you are suggesting that there is no need at all to deal with proxy
> definition/configuration at ovirt engine/user portal level?

I expect the admin/user portal to send the result of the PAC processing to the Spice client.
I don't think the Spice client should execute the PAC (it's a Javascript...).
Y.

> 
> 
> 


From mpastern at redhat.com  Thu Nov 15 07:36:02 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Thu, 15 Nov 2012 09:36:02 +0200
Subject: [Engine-devel] Network Wiring
In-Reply-To: <50A46837.5040201@redhat.com>
References: <999476552.1216069.1352818012177.JavaMail.root@redhat.com>
	<50A46837.5040201@redhat.com>
Message-ID: <50A49B62.4050409@redhat.com>

On 11/15/2012 05:57 AM, Itamar Heim wrote:
> On 11/13/2012 04:46 PM, Alona Kaplan wrote:
>> Hi all,
>>
>> Please review the wiki and add your comments.
>>
>> http://wiki.ovirt.org/wiki/Feature/NetworkWiring
> 
>>     Dialog
>>
>>         If the VM status is 'UP'
>>
>>             If the Vnic is plugged there should be a message on top of the dialog "Please notice, changing Type or MAC will cause unplugging and plugging the Vnic".
>>             Port Mirroring - If the Vnic is plugged and the Vnic is set for port mirroring - "network", "type", "mac" and "port mirroring" fields in the dialog will be
> disabled.
> 
> can user change the type if port mirroring isn't enabled? doesn't this require unplug/plug back?
> I assume all validations are at engine side to cover rest api as well?
> 
>> REST API
>>
>> NIC properties:
>>
>> Changes:
>>
>>     Adding new properties under VM NIC:
>>
>>         plugged
>>         wired
>>
>>     Deprecating the active property under VM NIC
>>     Deprecating activate/deactivate actions
>>     Plug/unplug and wire/unwire on a vnic, will be done via PUT action on the VM NIC
>>         /api/vms/xxx/nics/yyy/
>>
> 
> that's a lot of deprecation - you can mark them as deprecated, but they still need to work over a period of time for backward compatibility, so please explain what they
> will show/how they behave until they are deprecated.
> 
>> There is no reason to have dedicated actions for plug/unplug or wire/unwire. The original reason for having them was that edit VM nic while the VM was up used to be
> blocked and now we'll enable doing these actions.
> 
> actually, some users may not want to make these config changes while the VM is live, just to make them for the next boot. how will that work?
> 
> i agree with other comments that 'wired' is a bit confusing.
> s/wired-unwired/connected-disconnected/?

NX users may confuse between connected to vm or connected to the switch (despite of <plugged>),
as they used to <link>=up|down<link/>

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From iheim at redhat.com  Thu Nov 15 07:35:02 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 15 Nov 2012 09:35:02 +0200
Subject: [Engine-devel] SPICE IP override
In-Reply-To: <1102502848.10802488.1352963184183.JavaMail.root@redhat.com>
References: <1102502848.10802488.1352963184183.JavaMail.root@redhat.com>
Message-ID: <50A49B26.7000600@redhat.com>

On 11/15/2012 09:06 AM, Yaniv Kaul wrote:
> ----- Original Message -----
>> On 11/15/2012 08:33 AM, Yaniv Kaul wrote:
>>> On 11/15/2012 06:10 AM, Itamar Heim wrote:
>>>> On 11/11/2012 11:45 AM, Yaniv Kaul wrote:
>>>>> On 11/07/2012 10:52 AM, Simon Grinberg wrote:
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Michal Skrivanek"<michal.skrivanek at redhat.com>
>>>>>>> To:engine-devel at ovirt.org
>>>>>>> Sent: Tuesday, November 6, 2012 10:39:58 PM
>>>>>>> Subject: [Engine-devel] SPICE IP override
>>>>>>>
>>>>>>> Hi all,
>>>>>>> On behalf of Tomas - please check out the proposal for
>>>>>>> enhancing our
>>>>>>> SPICE integration to allow to return a custom IP/FQDN instead
>>>>>>> of the
>>>>>>> host IP address.
>>>>>>> http://wiki.ovirt.org/wiki/Features/Display_Address_Override
>>>>>>> All comments are welcome...
>>>>>> My 2 cents,
>>>>>>
>>>>>> This works under the assumption that all the users are either
>>>>>> outside of the organization or inside.
>>>>>> But think of some of the following scenarios based on a topology
>>>>>> where users in the main office are inside the corporate network
>>>>>> while users on remote offices / WAN are on a detached different
>>>>>> network on the other side of the NAT / public firewall :
>>>>>>
>>>>>> With current 'per host override' proposal:
>>>>>> 1. Admin from the main office won't be able to access the VM
>>>>>> console
>>>>>> 2. No Mixed environment, meaning that you have to have
>>>>>> designated
>>>>>> clusters for remote offices users vs main office users -
>>>>>> otherwise
>>>>>> connectivity to the console is determined based on scheduler
>>>>>> decision, or may break by live migration.
>>>>>> 3. Based on #2, If I'm a user travelling between offices I'll
>>>>>> have
>>>>>> to ask the admin to turn off my VM and move it to internal
>>>>>> cluster
>>>>>> before I can reconnect
>>>>>>
>>>>>> My suggestion is to covert this to 'alternative' IP/FQDN sending
>>>>>> the
>>>>>> spice client both internal fqdn/ip and the alternative. The
>>>>>> spice
>>>>>> client should detect which is available of the two and
>>>>>> auto-connect.
>>>>>>
>>>>>> This requires enhancement of the spice client, but still solves
>>>>>> all
>>>>>> the issues raised above (actually it solves about 90% of the use
>>>>>> cases I've heard about in the past).
>>>>>>
>>>>>> Another alternative is for the engine to 'guess' or 'elect'
>>>>>> which to
>>>>>> use, alternative or main, based on the IP of the client -
>>>>>> meaning
>>>>>> admin provides the client ranges for providing internal host
>>>>>> address
>>>>>> vs alternative - but this is more complicated compared for the
>>>>>> previous suggestion
>>>>>>
>>>>>> Thoughts?
>>>>>
>>>>> Lets not re-invent the wheel. This problem has been pondered
>>>>> before and
>>>>> solved[1], for all scenarios:
>>>>> internal clients connecting to internal resources;
>>>>> internal clients connecting to external resources, without the
>>>>> need for
>>>>> any intermediate assistance
>>>>> external clients connecting to internal resources, with the need
>>>>> for
>>>>> intermediate assistance.
>>>>> VPN clients connecting to internal resources, with or without an
>>>>> internal IP.
>>>>>
>>>>> Any other solution you'll try to come up with will bring you back
>>>>> to
>>>>> this standard, well known (along with its faults) method.
>>>>>
>>>>> The browser client will use PAC to determine how to connect to
>>>>> the hosts
>>>>> and will deliver this to the client. It's also a good path
>>>>> towards real
>>>>> proxy support for Spice.
>>>>> (Regardless, we still need to deal with the Spice protocol's
>>>>> migration
>>>>> command of course).
>>>>>
>>>>>
>>>>> [1] http://en.wikipedia.org/wiki/Proxy_auto-config
>>>>
>>>> so instead of a spice proxy fqdn field, we should just allow user
>>>> to
>>>> specify a pac file which resides under something like
>>>> /etc/ovirt/engine/pac...?
>>>
>>> I would actually encourage the customers to use their own corporate
>>> PAC
>>> and add the information to it.
>>
>> so you are suggesting that there is no need at all to deal with proxy
>> definition/configuration at ovirt engine/user portal level?
>
> I expect the admin/user portal to send the result of the PAC processing to the Spice client.
> I don't think the Spice client should execute the PAC (it's a Javascript...).

ok, so no engine, but just client side support for PAC?


From lpeer at redhat.com  Thu Nov 15 07:44:28 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Thu, 15 Nov 2012 09:44:28 +0200
Subject: [Engine-devel] Managing permissions on network
In-Reply-To: <2005776138.8788245.1352880676972.JavaMail.root@redhat.com>
References: <2005776138.8788245.1352880676972.JavaMail.root@redhat.com>
Message-ID: <50A49D5C.1020007@redhat.com>

On 14/11/12 10:11, Antoni Segura Puimedon wrote:
> 
> 
> ----- Original Message -----
>> From: "Itamar Heim" <iheim at redhat.com>
>> To: "Charlie" <medievalist at gmail.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Wednesday, November 14, 2012 5:28:21 AM
>> Subject: Re: [Engine-devel] Managing permissions on network
>>
>> On 11/13/2012 09:57 PM, Charlie wrote:
>>> Will any of these groups and/or permissions be drawn from LDAP?
>>>
>>> Frankly, system admins are not looking for yet another console to
>>> manage permissions.
>>
>> all users/groups come from LDAP.
>> you just need to give permissions to these groups/users in ovirt.
>> is that what you meant?
> 
> Would it be possible to somehow allow the admins to set permissions
> on the LDAP console?
> 

The integration with LDAP is on the level of managing users and groups
not the oVirt permissions themselves.
The reason for that is that permission = User + Role + Object
A user is given some Role on an Object, for example, admin1 is given the
role of clusterAdmin on clusterA, we can't set such permission in LDAP
as the objects themselves (Clusters, VMs, etc.) do not exist in LDAP.

Thanks, Livnat





From ykaul at redhat.com  Thu Nov 15 08:07:02 2012
From: ykaul at redhat.com (Yaniv Kaul)
Date: Thu, 15 Nov 2012 10:07:02 +0200
Subject: [Engine-devel] SPICE IP override
In-Reply-To: <50A49B26.7000600@redhat.com>
References: <1102502848.10802488.1352963184183.JavaMail.root@redhat.com>
	<50A49B26.7000600@redhat.com>
Message-ID: <50A4A2A6.1000600@redhat.com>

On 11/15/2012 09:35 AM, Itamar Heim wrote:
> On 11/15/2012 09:06 AM, Yaniv Kaul wrote:
>> ----- Original Message -----
>>> On 11/15/2012 08:33 AM, Yaniv Kaul wrote:
>>>> On 11/15/2012 06:10 AM, Itamar Heim wrote:
>>>>> On 11/11/2012 11:45 AM, Yaniv Kaul wrote:
>>>>>> On 11/07/2012 10:52 AM, Simon Grinberg wrote:
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Michal Skrivanek"<michal.skrivanek at redhat.com>
>>>>>>>> To:engine-devel at ovirt.org
>>>>>>>> Sent: Tuesday, November 6, 2012 10:39:58 PM
>>>>>>>> Subject: [Engine-devel] SPICE IP override
>>>>>>>>
>>>>>>>> Hi all,
>>>>>>>> On behalf of Tomas - please check out the proposal for
>>>>>>>> enhancing our
>>>>>>>> SPICE integration to allow to return a custom IP/FQDN instead
>>>>>>>> of the
>>>>>>>> host IP address.
>>>>>>>> http://wiki.ovirt.org/wiki/Features/Display_Address_Override
>>>>>>>> All comments are welcome...
>>>>>>> My 2 cents,
>>>>>>>
>>>>>>> This works under the assumption that all the users are either
>>>>>>> outside of the organization or inside.
>>>>>>> But think of some of the following scenarios based on a topology
>>>>>>> where users in the main office are inside the corporate network
>>>>>>> while users on remote offices / WAN are on a detached different
>>>>>>> network on the other side of the NAT / public firewall :
>>>>>>>
>>>>>>> With current 'per host override' proposal:
>>>>>>> 1. Admin from the main office won't be able to access the VM
>>>>>>> console
>>>>>>> 2. No Mixed environment, meaning that you have to have
>>>>>>> designated
>>>>>>> clusters for remote offices users vs main office users -
>>>>>>> otherwise
>>>>>>> connectivity to the console is determined based on scheduler
>>>>>>> decision, or may break by live migration.
>>>>>>> 3. Based on #2, If I'm a user travelling between offices I'll
>>>>>>> have
>>>>>>> to ask the admin to turn off my VM and move it to internal
>>>>>>> cluster
>>>>>>> before I can reconnect
>>>>>>>
>>>>>>> My suggestion is to covert this to 'alternative' IP/FQDN sending
>>>>>>> the
>>>>>>> spice client both internal fqdn/ip and the alternative. The
>>>>>>> spice
>>>>>>> client should detect which is available of the two and
>>>>>>> auto-connect.
>>>>>>>
>>>>>>> This requires enhancement of the spice client, but still solves
>>>>>>> all
>>>>>>> the issues raised above (actually it solves about 90% of the use
>>>>>>> cases I've heard about in the past).
>>>>>>>
>>>>>>> Another alternative is for the engine to 'guess' or 'elect'
>>>>>>> which to
>>>>>>> use, alternative or main, based on the IP of the client -
>>>>>>> meaning
>>>>>>> admin provides the client ranges for providing internal host
>>>>>>> address
>>>>>>> vs alternative - but this is more complicated compared for the
>>>>>>> previous suggestion
>>>>>>>
>>>>>>> Thoughts?
>>>>>>
>>>>>> Lets not re-invent the wheel. This problem has been pondered
>>>>>> before and
>>>>>> solved[1], for all scenarios:
>>>>>> internal clients connecting to internal resources;
>>>>>> internal clients connecting to external resources, without the
>>>>>> need for
>>>>>> any intermediate assistance
>>>>>> external clients connecting to internal resources, with the need
>>>>>> for
>>>>>> intermediate assistance.
>>>>>> VPN clients connecting to internal resources, with or without an
>>>>>> internal IP.
>>>>>>
>>>>>> Any other solution you'll try to come up with will bring you back
>>>>>> to
>>>>>> this standard, well known (along with its faults) method.
>>>>>>
>>>>>> The browser client will use PAC to determine how to connect to
>>>>>> the hosts
>>>>>> and will deliver this to the client. It's also a good path
>>>>>> towards real
>>>>>> proxy support for Spice.
>>>>>> (Regardless, we still need to deal with the Spice protocol's
>>>>>> migration
>>>>>> command of course).
>>>>>>
>>>>>>
>>>>>> [1] http://en.wikipedia.org/wiki/Proxy_auto-config
>>>>>
>>>>> so instead of a spice proxy fqdn field, we should just allow user
>>>>> to
>>>>> specify a pac file which resides under something like
>>>>> /etc/ovirt/engine/pac...?
>>>>
>>>> I would actually encourage the customers to use their own corporate
>>>> PAC
>>>> and add the information to it.
>>>
>>> so you are suggesting that there is no need at all to deal with proxy
>>> definition/configuration at ovirt engine/user portal level?
>>
>> I expect the admin/user portal to send the result of the PAC 
>> processing to the Spice client.
>> I don't think the Spice client should execute the PAC (it's a 
>> Javascript...).
>
> ok, so no engine, but just client side support for PAC?

Exactly.
And of course, Spice protocol changes, without which all this effort is 
nice, but incomplete.
Y.




From simon at redhat.com  Thu Nov 15 08:33:23 2012
From: simon at redhat.com (Simon Grinberg)
Date: Thu, 15 Nov 2012 03:33:23 -0500 (EST)
Subject: [Engine-devel] SPICE IP override
In-Reply-To: <50A4A2A6.1000600@redhat.com>
Message-ID: <22051317.715.1352968396937.JavaMail.javamailuser@localhost>



----- Original Message -----
> From: "Yaniv Kaul" <ykaul at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: "Simon Grinberg" <simon at redhat.com>, engine-devel at ovirt.org
> Sent: Thursday, November 15, 2012 10:07:02 AM
> Subject: Re: [Engine-devel] SPICE IP override
> 
> On 11/15/2012 09:35 AM, Itamar Heim wrote:
> > On 11/15/2012 09:06 AM, Yaniv Kaul wrote:
> >> ----- Original Message -----
> >>> On 11/15/2012 08:33 AM, Yaniv Kaul wrote:
> >>>> On 11/15/2012 06:10 AM, Itamar Heim wrote:
> >>>>> On 11/11/2012 11:45 AM, Yaniv Kaul wrote:
> >>>>>> On 11/07/2012 10:52 AM, Simon Grinberg wrote:
> >>>>>>>
> >>>>>>> ----- Original Message -----
> >>>>>>>> From: "Michal Skrivanek"<michal.skrivanek at redhat.com>
> >>>>>>>> To:engine-devel at ovirt.org
> >>>>>>>> Sent: Tuesday, November 6, 2012 10:39:58 PM
> >>>>>>>> Subject: [Engine-devel] SPICE IP override
> >>>>>>>>
> >>>>>>>> Hi all,
> >>>>>>>> On behalf of Tomas - please check out the proposal for
> >>>>>>>> enhancing our
> >>>>>>>> SPICE integration to allow to return a custom IP/FQDN
> >>>>>>>> instead
> >>>>>>>> of the
> >>>>>>>> host IP address.
> >>>>>>>> http://wiki.ovirt.org/wiki/Features/Display_Address_Override
> >>>>>>>> All comments are welcome...
> >>>>>>> My 2 cents,
> >>>>>>>
> >>>>>>> This works under the assumption that all the users are either
> >>>>>>> outside of the organization or inside.
> >>>>>>> But think of some of the following scenarios based on a
> >>>>>>> topology
> >>>>>>> where users in the main office are inside the corporate
> >>>>>>> network
> >>>>>>> while users on remote offices / WAN are on a detached
> >>>>>>> different
> >>>>>>> network on the other side of the NAT / public firewall :
> >>>>>>>
> >>>>>>> With current 'per host override' proposal:
> >>>>>>> 1. Admin from the main office won't be able to access the VM
> >>>>>>> console
> >>>>>>> 2. No Mixed environment, meaning that you have to have
> >>>>>>> designated
> >>>>>>> clusters for remote offices users vs main office users -
> >>>>>>> otherwise
> >>>>>>> connectivity to the console is determined based on scheduler
> >>>>>>> decision, or may break by live migration.
> >>>>>>> 3. Based on #2, If I'm a user travelling between offices I'll
> >>>>>>> have
> >>>>>>> to ask the admin to turn off my VM and move it to internal
> >>>>>>> cluster
> >>>>>>> before I can reconnect
> >>>>>>>
> >>>>>>> My suggestion is to covert this to 'alternative' IP/FQDN
> >>>>>>> sending
> >>>>>>> the
> >>>>>>> spice client both internal fqdn/ip and the alternative. The
> >>>>>>> spice
> >>>>>>> client should detect which is available of the two and
> >>>>>>> auto-connect.
> >>>>>>>
> >>>>>>> This requires enhancement of the spice client, but still
> >>>>>>> solves
> >>>>>>> all
> >>>>>>> the issues raised above (actually it solves about 90% of the
> >>>>>>> use
> >>>>>>> cases I've heard about in the past).
> >>>>>>>
> >>>>>>> Another alternative is for the engine to 'guess' or 'elect'
> >>>>>>> which to
> >>>>>>> use, alternative or main, based on the IP of the client -
> >>>>>>> meaning
> >>>>>>> admin provides the client ranges for providing internal host
> >>>>>>> address
> >>>>>>> vs alternative - but this is more complicated compared for
> >>>>>>> the
> >>>>>>> previous suggestion
> >>>>>>>
> >>>>>>> Thoughts?
> >>>>>>
> >>>>>> Lets not re-invent the wheel. This problem has been pondered
> >>>>>> before and
> >>>>>> solved[1], for all scenarios:
> >>>>>> internal clients connecting to internal resources;
> >>>>>> internal clients connecting to external resources, without the
> >>>>>> need for
> >>>>>> any intermediate assistance
> >>>>>> external clients connecting to internal resources, with the
> >>>>>> need
> >>>>>> for
> >>>>>> intermediate assistance.
> >>>>>> VPN clients connecting to internal resources, with or without
> >>>>>> an
> >>>>>> internal IP.
> >>>>>>
> >>>>>> Any other solution you'll try to come up with will bring you
> >>>>>> back
> >>>>>> to
> >>>>>> this standard, well known (along with its faults) method.
> >>>>>>
> >>>>>> The browser client will use PAC to determine how to connect to
> >>>>>> the hosts
> >>>>>> and will deliver this to the client. It's also a good path
> >>>>>> towards real
> >>>>>> proxy support for Spice.
> >>>>>> (Regardless, we still need to deal with the Spice protocol's
> >>>>>> migration
> >>>>>> command of course).
> >>>>>>
> >>>>>>
> >>>>>> [1] http://en.wikipedia.org/wiki/Proxy_auto-config
> >>>>>
> >>>>> so instead of a spice proxy fqdn field, we should just allow
> >>>>> user
> >>>>> to
> >>>>> specify a pac file which resides under something like
> >>>>> /etc/ovirt/engine/pac...?
> >>>>
> >>>> I would actually encourage the customers to use their own
> >>>> corporate
> >>>> PAC
> >>>> and add the information to it.
> >>>
> >>> so you are suggesting that there is no need at all to deal with
> >>> proxy
> >>> definition/configuration at ovirt engine/user portal level?
> >>
> >> I expect the admin/user portal to send the result of the PAC
> >> processing to the Spice client.
> >> I don't think the Spice client should execute the PAC (it's a
> >> Javascript...).

And live migration? 
I don't completely understand how you can avoid executing the PAC file if the destination host is provided by Qemu (client_migrate_info) unless I'm confusing with something else and it is the web client that delivers this info on migration.

P.S., 
If it is Qemu, then I don't see the current feature page accounting for that - IE, the hosts should also be informed on this override IP 



> >
> > ok, so no engine, but just client side support for PAC?
> 
> Exactly.
> And of course, Spice protocol changes, without which all this effort
> is
> nice, but incomplete.
> Y.
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From ykaul at redhat.com  Thu Nov 15 08:42:19 2012
From: ykaul at redhat.com (Yaniv Kaul)
Date: Thu, 15 Nov 2012 10:42:19 +0200
Subject: [Engine-devel] SPICE IP override
In-Reply-To: <22051317.715.1352968396937.JavaMail.javamailuser@localhost>
References: <22051317.715.1352968396937.JavaMail.javamailuser@localhost>
Message-ID: <50A4AAEB.6040207@redhat.com>

On 11/15/2012 10:33 AM, Simon Grinberg wrote:
>
> ----- Original Message -----
>> From: "Yaniv Kaul" <ykaul at redhat.com>
>> To: "Itamar Heim" <iheim at redhat.com>
>> Cc: "Simon Grinberg" <simon at redhat.com>, engine-devel at ovirt.org
>> Sent: Thursday, November 15, 2012 10:07:02 AM
>> Subject: Re: [Engine-devel] SPICE IP override
>>
>> On 11/15/2012 09:35 AM, Itamar Heim wrote:
>>> On 11/15/2012 09:06 AM, Yaniv Kaul wrote:
>>>> ----- Original Message -----
>>>>> On 11/15/2012 08:33 AM, Yaniv Kaul wrote:
>>>>>> On 11/15/2012 06:10 AM, Itamar Heim wrote:
>>>>>>> On 11/11/2012 11:45 AM, Yaniv Kaul wrote:
>>>>>>>> On 11/07/2012 10:52 AM, Simon Grinberg wrote:
>>>>>>>>> ----- Original Message -----
>>>>>>>>>> From: "Michal Skrivanek"<michal.skrivanek at redhat.com>
>>>>>>>>>> To:engine-devel at ovirt.org
>>>>>>>>>> Sent: Tuesday, November 6, 2012 10:39:58 PM
>>>>>>>>>> Subject: [Engine-devel] SPICE IP override
>>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>> On behalf of Tomas - please check out the proposal for
>>>>>>>>>> enhancing our
>>>>>>>>>> SPICE integration to allow to return a custom IP/FQDN
>>>>>>>>>> instead
>>>>>>>>>> of the
>>>>>>>>>> host IP address.
>>>>>>>>>> http://wiki.ovirt.org/wiki/Features/Display_Address_Override
>>>>>>>>>> All comments are welcome...
>>>>>>>>> My 2 cents,
>>>>>>>>>
>>>>>>>>> This works under the assumption that all the users are either
>>>>>>>>> outside of the organization or inside.
>>>>>>>>> But think of some of the following scenarios based on a
>>>>>>>>> topology
>>>>>>>>> where users in the main office are inside the corporate
>>>>>>>>> network
>>>>>>>>> while users on remote offices / WAN are on a detached
>>>>>>>>> different
>>>>>>>>> network on the other side of the NAT / public firewall :
>>>>>>>>>
>>>>>>>>> With current 'per host override' proposal:
>>>>>>>>> 1. Admin from the main office won't be able to access the VM
>>>>>>>>> console
>>>>>>>>> 2. No Mixed environment, meaning that you have to have
>>>>>>>>> designated
>>>>>>>>> clusters for remote offices users vs main office users -
>>>>>>>>> otherwise
>>>>>>>>> connectivity to the console is determined based on scheduler
>>>>>>>>> decision, or may break by live migration.
>>>>>>>>> 3. Based on #2, If I'm a user travelling between offices I'll
>>>>>>>>> have
>>>>>>>>> to ask the admin to turn off my VM and move it to internal
>>>>>>>>> cluster
>>>>>>>>> before I can reconnect
>>>>>>>>>
>>>>>>>>> My suggestion is to covert this to 'alternative' IP/FQDN
>>>>>>>>> sending
>>>>>>>>> the
>>>>>>>>> spice client both internal fqdn/ip and the alternative. The
>>>>>>>>> spice
>>>>>>>>> client should detect which is available of the two and
>>>>>>>>> auto-connect.
>>>>>>>>>
>>>>>>>>> This requires enhancement of the spice client, but still
>>>>>>>>> solves
>>>>>>>>> all
>>>>>>>>> the issues raised above (actually it solves about 90% of the
>>>>>>>>> use
>>>>>>>>> cases I've heard about in the past).
>>>>>>>>>
>>>>>>>>> Another alternative is for the engine to 'guess' or 'elect'
>>>>>>>>> which to
>>>>>>>>> use, alternative or main, based on the IP of the client -
>>>>>>>>> meaning
>>>>>>>>> admin provides the client ranges for providing internal host
>>>>>>>>> address
>>>>>>>>> vs alternative - but this is more complicated compared for
>>>>>>>>> the
>>>>>>>>> previous suggestion
>>>>>>>>>
>>>>>>>>> Thoughts?
>>>>>>>> Lets not re-invent the wheel. This problem has been pondered
>>>>>>>> before and
>>>>>>>> solved[1], for all scenarios:
>>>>>>>> internal clients connecting to internal resources;
>>>>>>>> internal clients connecting to external resources, without the
>>>>>>>> need for
>>>>>>>> any intermediate assistance
>>>>>>>> external clients connecting to internal resources, with the
>>>>>>>> need
>>>>>>>> for
>>>>>>>> intermediate assistance.
>>>>>>>> VPN clients connecting to internal resources, with or without
>>>>>>>> an
>>>>>>>> internal IP.
>>>>>>>>
>>>>>>>> Any other solution you'll try to come up with will bring you
>>>>>>>> back
>>>>>>>> to
>>>>>>>> this standard, well known (along with its faults) method.
>>>>>>>>
>>>>>>>> The browser client will use PAC to determine how to connect to
>>>>>>>> the hosts
>>>>>>>> and will deliver this to the client. It's also a good path
>>>>>>>> towards real
>>>>>>>> proxy support for Spice.
>>>>>>>> (Regardless, we still need to deal with the Spice protocol's
>>>>>>>> migration
>>>>>>>> command of course).
>>>>>>>>
>>>>>>>>
>>>>>>>> [1] http://en.wikipedia.org/wiki/Proxy_auto-config
>>>>>>> so instead of a spice proxy fqdn field, we should just allow
>>>>>>> user
>>>>>>> to
>>>>>>> specify a pac file which resides under something like
>>>>>>> /etc/ovirt/engine/pac...?
>>>>>> I would actually encourage the customers to use their own
>>>>>> corporate
>>>>>> PAC
>>>>>> and add the information to it.
>>>>> so you are suggesting that there is no need at all to deal with
>>>>> proxy
>>>>> definition/configuration at ovirt engine/user portal level?
>>>> I expect the admin/user portal to send the result of the PAC
>>>> processing to the Spice client.
>>>> I don't think the Spice client should execute the PAC (it's a
>>>> Javascript...).
> And live migration?

Read my email: "And of course, Spice protocol changes"

> I don't completely understand how you can avoid executing the PAC file if the destination host is provided by Qemu (client_migrate_info) unless I'm confusing with something else and it is the web client that delivers this info on migration.

I'm not against executing the PAC. It just requires a javascript engine, 
which is a bit of an overkill for Spice client to start working with, no?
I'm aware there is a critical gap with the Spice protocol, but all I'm 
saying is that any other idea you'll come up with to get the topology 
right is going to be a rewrite of the PAC idea. You will need to define 
the topology, and you'll need to lookup your current location against 
it. This is what PAC does.

A Spice proxy would probably be able to solve the Spice protocol issue, 
as we expect the proxy to handle the host hand-over when migration 
happens, I reckon.

>
> P.S.,
> If it is Qemu, then I don't see the current feature page accounting for that - IE, the hosts should also be informed on this override IP

Why? A host is rarely aware it is behind NAT. If it's because of the 
protocol issue, the protocol has to be changed.
Y.

>
>
>
>>> ok, so no engine, but just client side support for PAC?
>> Exactly.
>> And of course, Spice protocol changes, without which all this effort
>> is
>> nice, but incomplete.
>> Y.
>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>



From simon at redhat.com  Thu Nov 15 08:52:51 2012
From: simon at redhat.com (Simon Grinberg)
Date: Thu, 15 Nov 2012 03:52:51 -0500 (EST)
Subject: [Engine-devel] SPICE IP override
In-Reply-To: <50A4AAEB.6040207@redhat.com>
Message-ID: <22047465.761.1352969566431.JavaMail.javamailuser@localhost>



----- Original Message -----
> From: "Yaniv Kaul" <ykaul at redhat.com>
> To: "Simon Grinberg" <simon at redhat.com>
> Cc: engine-devel at ovirt.org, "Itamar Heim" <iheim at redhat.com>
> Sent: Thursday, November 15, 2012 10:42:19 AM
> Subject: Re: [Engine-devel] SPICE IP override
> 
> On 11/15/2012 10:33 AM, Simon Grinberg wrote:
> >
> > ----- Original Message -----
> >> From: "Yaniv Kaul" <ykaul at redhat.com>
> >> To: "Itamar Heim" <iheim at redhat.com>
> >> Cc: "Simon Grinberg" <simon at redhat.com>, engine-devel at ovirt.org
> >> Sent: Thursday, November 15, 2012 10:07:02 AM
> >> Subject: Re: [Engine-devel] SPICE IP override
> >>
> >> On 11/15/2012 09:35 AM, Itamar Heim wrote:
> >>> On 11/15/2012 09:06 AM, Yaniv Kaul wrote:
> >>>> ----- Original Message -----
> >>>>> On 11/15/2012 08:33 AM, Yaniv Kaul wrote:
> >>>>>> On 11/15/2012 06:10 AM, Itamar Heim wrote:
> >>>>>>> On 11/11/2012 11:45 AM, Yaniv Kaul wrote:
> >>>>>>>> On 11/07/2012 10:52 AM, Simon Grinberg wrote:
> >>>>>>>>> ----- Original Message -----
> >>>>>>>>>> From: "Michal Skrivanek"<michal.skrivanek at redhat.com>
> >>>>>>>>>> To:engine-devel at ovirt.org
> >>>>>>>>>> Sent: Tuesday, November 6, 2012 10:39:58 PM
> >>>>>>>>>> Subject: [Engine-devel] SPICE IP override
> >>>>>>>>>>
> >>>>>>>>>> Hi all,
> >>>>>>>>>> On behalf of Tomas - please check out the proposal for
> >>>>>>>>>> enhancing our
> >>>>>>>>>> SPICE integration to allow to return a custom IP/FQDN
> >>>>>>>>>> instead
> >>>>>>>>>> of the
> >>>>>>>>>> host IP address.
> >>>>>>>>>> http://wiki.ovirt.org/wiki/Features/Display_Address_Override
> >>>>>>>>>> All comments are welcome...
> >>>>>>>>> My 2 cents,
> >>>>>>>>>
> >>>>>>>>> This works under the assumption that all the users are
> >>>>>>>>> either
> >>>>>>>>> outside of the organization or inside.
> >>>>>>>>> But think of some of the following scenarios based on a
> >>>>>>>>> topology
> >>>>>>>>> where users in the main office are inside the corporate
> >>>>>>>>> network
> >>>>>>>>> while users on remote offices / WAN are on a detached
> >>>>>>>>> different
> >>>>>>>>> network on the other side of the NAT / public firewall :
> >>>>>>>>>
> >>>>>>>>> With current 'per host override' proposal:
> >>>>>>>>> 1. Admin from the main office won't be able to access the
> >>>>>>>>> VM
> >>>>>>>>> console
> >>>>>>>>> 2. No Mixed environment, meaning that you have to have
> >>>>>>>>> designated
> >>>>>>>>> clusters for remote offices users vs main office users -
> >>>>>>>>> otherwise
> >>>>>>>>> connectivity to the console is determined based on
> >>>>>>>>> scheduler
> >>>>>>>>> decision, or may break by live migration.
> >>>>>>>>> 3. Based on #2, If I'm a user travelling between offices
> >>>>>>>>> I'll
> >>>>>>>>> have
> >>>>>>>>> to ask the admin to turn off my VM and move it to internal
> >>>>>>>>> cluster
> >>>>>>>>> before I can reconnect
> >>>>>>>>>
> >>>>>>>>> My suggestion is to covert this to 'alternative' IP/FQDN
> >>>>>>>>> sending
> >>>>>>>>> the
> >>>>>>>>> spice client both internal fqdn/ip and the alternative. The
> >>>>>>>>> spice
> >>>>>>>>> client should detect which is available of the two and
> >>>>>>>>> auto-connect.
> >>>>>>>>>
> >>>>>>>>> This requires enhancement of the spice client, but still
> >>>>>>>>> solves
> >>>>>>>>> all
> >>>>>>>>> the issues raised above (actually it solves about 90% of
> >>>>>>>>> the
> >>>>>>>>> use
> >>>>>>>>> cases I've heard about in the past).
> >>>>>>>>>
> >>>>>>>>> Another alternative is for the engine to 'guess' or 'elect'
> >>>>>>>>> which to
> >>>>>>>>> use, alternative or main, based on the IP of the client -
> >>>>>>>>> meaning
> >>>>>>>>> admin provides the client ranges for providing internal
> >>>>>>>>> host
> >>>>>>>>> address
> >>>>>>>>> vs alternative - but this is more complicated compared for
> >>>>>>>>> the
> >>>>>>>>> previous suggestion
> >>>>>>>>>
> >>>>>>>>> Thoughts?
> >>>>>>>> Lets not re-invent the wheel. This problem has been pondered
> >>>>>>>> before and
> >>>>>>>> solved[1], for all scenarios:
> >>>>>>>> internal clients connecting to internal resources;
> >>>>>>>> internal clients connecting to external resources, without
> >>>>>>>> the
> >>>>>>>> need for
> >>>>>>>> any intermediate assistance
> >>>>>>>> external clients connecting to internal resources, with the
> >>>>>>>> need
> >>>>>>>> for
> >>>>>>>> intermediate assistance.
> >>>>>>>> VPN clients connecting to internal resources, with or
> >>>>>>>> without
> >>>>>>>> an
> >>>>>>>> internal IP.
> >>>>>>>>
> >>>>>>>> Any other solution you'll try to come up with will bring you
> >>>>>>>> back
> >>>>>>>> to
> >>>>>>>> this standard, well known (along with its faults) method.
> >>>>>>>>
> >>>>>>>> The browser client will use PAC to determine how to connect
> >>>>>>>> to
> >>>>>>>> the hosts
> >>>>>>>> and will deliver this to the client. It's also a good path
> >>>>>>>> towards real
> >>>>>>>> proxy support for Spice.
> >>>>>>>> (Regardless, we still need to deal with the Spice protocol's
> >>>>>>>> migration
> >>>>>>>> command of course).
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> [1] http://en.wikipedia.org/wiki/Proxy_auto-config
> >>>>>>> so instead of a spice proxy fqdn field, we should just allow
> >>>>>>> user
> >>>>>>> to
> >>>>>>> specify a pac file which resides under something like
> >>>>>>> /etc/ovirt/engine/pac...?
> >>>>>> I would actually encourage the customers to use their own
> >>>>>> corporate
> >>>>>> PAC
> >>>>>> and add the information to it.
> >>>>> so you are suggesting that there is no need at all to deal with
> >>>>> proxy
> >>>>> definition/configuration at ovirt engine/user portal level?
> >>>> I expect the admin/user portal to send the result of the PAC
> >>>> processing to the Spice client.
> >>>> I don't think the Spice client should execute the PAC (it's a
> >>>> Javascript...).
> > And live migration?
> 
> Read my email: "And of course, Spice protocol changes"
> 
> > I don't completely understand how you can avoid executing the PAC
> > file if the destination host is provided by Qemu
> > (client_migrate_info) unless I'm confusing with something else and
> > it is the web client that delivers this info on migration.
> 
> I'm not against executing the PAC. It just requires a javascript
> engine,
> which is a bit of an overkill for Spice client to start working with,
> no?
> I'm aware there is a critical gap with the Spice protocol, but all
> I'm
> saying is that any other idea you'll come up with to get the topology
> right is going to be a rewrite of the PAC idea. You will need to
> define
> the topology, and you'll need to lookup your current location against
> it. This is what PAC does.
> 
> A Spice proxy would probably be able to solve the Spice protocol
> issue,
> as we expect the proxy to handle the host hand-over when migration
> happens, I reckon.
> 
> >
> > P.S.,
> > If it is Qemu, then I don't see the current feature page accounting
> > for that - IE, the hosts should also be informed on this override
> > IP
> 
> Why? A host is rarely aware it is behind NAT. If it's because of the
> protocol issue, the protocol has to be changed.

I'm referring to the current feature page as is (taking out the rest of the discussion): 
It lacks solution for migration:
1. You have host A, and B, both with overridden IP set
2. On initial connect the browser provides the connection details using host A 'override IP' settings
3. VM Migrates from A to B
4. Now it's Qemu providing the destination connection details - it will provide the internal IP of host B

Connection breaks !!!

Again, unless I'm missing something and live migration destination is provided by the web client/engine to the spice client (somehow)


> Y.
> 
> >
> >
> >
> >>> ok, so no engine, but just client side support for PAC?
> >> Exactly.
> >> And of course, Spice protocol changes, without which all this
> >> effort
> >> is
> >> nice, but incomplete.
> >> Y.
> >>
> >>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> 
> 


From amureini at redhat.com  Thu Nov 15 09:14:00 2012
From: amureini at redhat.com (Allon Mureinik)
Date: Thu, 15 Nov 2012 04:14:00 -0500 (EST)
Subject: [Engine-devel] Proposal to add Allon Mureinik as maintainer to
 engine core
In-Reply-To: <50A45F2A.5010203@redhat.com>
Message-ID: <12909260.1019763.1352970840744.JavaMail.root@redhat.com>

Thanks for the vote of confidence!

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Thursday, November 15, 2012 5:19:06 AM
> Subject: Re: [Engine-devel] Proposal to add Allon Mureinik as maintainer to engine core
> 
> On 11/14/2012 06:12 AM, Itamar Heim wrote:
> > Allon has worked on oVirt for the past 10 months.
> > With 534 patches ranging from cleanups, to complex features like
> > user
> > level api and storage live migration. In addition, Allon has been
> > instrumental in the number of patch reviews he has done.
> >
> > I'd like to propose Allon as a maintainer of engine core.
> 
> per the resounding +1 (even if somewhat delayed by mail server
> issues),
> and no objections, added Allon as maintainer of engine core.
> dave - can you please take care of updating the web site?
> 
> thanks,
>     Itamar
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From djasa at redhat.com  Thu Nov 15 09:44:42 2012
From: djasa at redhat.com (David =?UTF-8?Q?Ja=C5=A1a?=)
Date: Thu, 15 Nov 2012 10:44:42 +0100
Subject: [Engine-devel] SPICE IP override
In-Reply-To: <22047465.761.1352969566431.JavaMail.javamailuser@localhost>
References: <22047465.761.1352969566431.JavaMail.javamailuser@localhost>
Message-ID: <1352972682.12065.276.camel@dhcp-29-7.brq.redhat.com>

Simon Grinberg p??e v ?t 15. 11. 2012 v 03:52 -0500:
> 
> ----- Original Message -----
> > From: "Yaniv Kaul" <ykaul at redhat.com>
> > To: "Simon Grinberg" <simon at redhat.com>
> > Cc: engine-devel at ovirt.org, "Itamar Heim" <iheim at redhat.com>
> > Sent: Thursday, November 15, 2012 10:42:19 AM
> > Subject: Re: [Engine-devel] SPICE IP override
> > 
> > On 11/15/2012 10:33 AM, Simon Grinberg wrote:
> > >
> > > ----- Original Message -----
> > >> From: "Yaniv Kaul" <ykaul at redhat.com>
> > >> To: "Itamar Heim" <iheim at redhat.com>
> > >> Cc: "Simon Grinberg" <simon at redhat.com>, engine-devel at ovirt.org
> > >> Sent: Thursday, November 15, 2012 10:07:02 AM
> > >> Subject: Re: [Engine-devel] SPICE IP override
> > >>
> > >> On 11/15/2012 09:35 AM, Itamar Heim wrote:
> > >>> On 11/15/2012 09:06 AM, Yaniv Kaul wrote:
> > >>>> ----- Original Message -----
> > >>>>> On 11/15/2012 08:33 AM, Yaniv Kaul wrote:
> > >>>>>> On 11/15/2012 06:10 AM, Itamar Heim wrote:
> > >>>>>>> On 11/11/2012 11:45 AM, Yaniv Kaul wrote:
> > >>>>>>>> On 11/07/2012 10:52 AM, Simon Grinberg wrote:
> > >>>>>>>>> ----- Original Message -----
> > >>>>>>>>>> From: "Michal Skrivanek"<michal.skrivanek at redhat.com>
> > >>>>>>>>>> To:engine-devel at ovirt.org
> > >>>>>>>>>> Sent: Tuesday, November 6, 2012 10:39:58 PM
> > >>>>>>>>>> Subject: [Engine-devel] SPICE IP override
> > >>>>>>>>>>
> > >>>>>>>>>> Hi all,
> > >>>>>>>>>> On behalf of Tomas - please check out the proposal for
> > >>>>>>>>>> enhancing our
> > >>>>>>>>>> SPICE integration to allow to return a custom IP/FQDN
> > >>>>>>>>>> instead
> > >>>>>>>>>> of the
> > >>>>>>>>>> host IP address.
> > >>>>>>>>>> http://wiki.ovirt.org/wiki/Features/Display_Address_Override
> > >>>>>>>>>> All comments are welcome...
> > >>>>>>>>> My 2 cents,
> > >>>>>>>>>
> > >>>>>>>>> This works under the assumption that all the users are
> > >>>>>>>>> either
> > >>>>>>>>> outside of the organization or inside.
> > >>>>>>>>> But think of some of the following scenarios based on a
> > >>>>>>>>> topology
> > >>>>>>>>> where users in the main office are inside the corporate
> > >>>>>>>>> network
> > >>>>>>>>> while users on remote offices / WAN are on a detached
> > >>>>>>>>> different
> > >>>>>>>>> network on the other side of the NAT / public firewall :
> > >>>>>>>>>
> > >>>>>>>>> With current 'per host override' proposal:
> > >>>>>>>>> 1. Admin from the main office won't be able to access the
> > >>>>>>>>> VM
> > >>>>>>>>> console
> > >>>>>>>>> 2. No Mixed environment, meaning that you have to have
> > >>>>>>>>> designated
> > >>>>>>>>> clusters for remote offices users vs main office users -
> > >>>>>>>>> otherwise
> > >>>>>>>>> connectivity to the console is determined based on
> > >>>>>>>>> scheduler
> > >>>>>>>>> decision, or may break by live migration.
> > >>>>>>>>> 3. Based on #2, If I'm a user travelling between offices
> > >>>>>>>>> I'll
> > >>>>>>>>> have
> > >>>>>>>>> to ask the admin to turn off my VM and move it to internal
> > >>>>>>>>> cluster
> > >>>>>>>>> before I can reconnect
> > >>>>>>>>>
> > >>>>>>>>> My suggestion is to covert this to 'alternative' IP/FQDN
> > >>>>>>>>> sending
> > >>>>>>>>> the
> > >>>>>>>>> spice client both internal fqdn/ip and the alternative. The
> > >>>>>>>>> spice
> > >>>>>>>>> client should detect which is available of the two and
> > >>>>>>>>> auto-connect.
> > >>>>>>>>>
> > >>>>>>>>> This requires enhancement of the spice client, but still
> > >>>>>>>>> solves
> > >>>>>>>>> all
> > >>>>>>>>> the issues raised above (actually it solves about 90% of
> > >>>>>>>>> the
> > >>>>>>>>> use
> > >>>>>>>>> cases I've heard about in the past).
> > >>>>>>>>>
> > >>>>>>>>> Another alternative is for the engine to 'guess' or 'elect'
> > >>>>>>>>> which to
> > >>>>>>>>> use, alternative or main, based on the IP of the client -
> > >>>>>>>>> meaning
> > >>>>>>>>> admin provides the client ranges for providing internal
> > >>>>>>>>> host
> > >>>>>>>>> address
> > >>>>>>>>> vs alternative - but this is more complicated compared for
> > >>>>>>>>> the
> > >>>>>>>>> previous suggestion
> > >>>>>>>>>
> > >>>>>>>>> Thoughts?
> > >>>>>>>> Lets not re-invent the wheel. This problem has been pondered
> > >>>>>>>> before and
> > >>>>>>>> solved[1], for all scenarios:
> > >>>>>>>> internal clients connecting to internal resources;
> > >>>>>>>> internal clients connecting to external resources, without
> > >>>>>>>> the
> > >>>>>>>> need for
> > >>>>>>>> any intermediate assistance
> > >>>>>>>> external clients connecting to internal resources, with the
> > >>>>>>>> need
> > >>>>>>>> for
> > >>>>>>>> intermediate assistance.
> > >>>>>>>> VPN clients connecting to internal resources, with or
> > >>>>>>>> without
> > >>>>>>>> an
> > >>>>>>>> internal IP.
> > >>>>>>>>
> > >>>>>>>> Any other solution you'll try to come up with will bring you
> > >>>>>>>> back
> > >>>>>>>> to
> > >>>>>>>> this standard, well known (along with its faults) method.
> > >>>>>>>>
> > >>>>>>>> The browser client will use PAC to determine how to connect
> > >>>>>>>> to
> > >>>>>>>> the hosts
> > >>>>>>>> and will deliver this to the client. It's also a good path
> > >>>>>>>> towards real
> > >>>>>>>> proxy support for Spice.
> > >>>>>>>> (Regardless, we still need to deal with the Spice protocol's
> > >>>>>>>> migration
> > >>>>>>>> command of course).
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> [1] http://en.wikipedia.org/wiki/Proxy_auto-config
> > >>>>>>> so instead of a spice proxy fqdn field, we should just allow
> > >>>>>>> user
> > >>>>>>> to
> > >>>>>>> specify a pac file which resides under something like
> > >>>>>>> /etc/ovirt/engine/pac...?
> > >>>>>> I would actually encourage the customers to use their own
> > >>>>>> corporate
> > >>>>>> PAC
> > >>>>>> and add the information to it.
> > >>>>> so you are suggesting that there is no need at all to deal with
> > >>>>> proxy
> > >>>>> definition/configuration at ovirt engine/user portal level?
> > >>>> I expect the admin/user portal to send the result of the PAC
> > >>>> processing to the Spice client.
> > >>>> I don't think the Spice client should execute the PAC (it's a
> > >>>> Javascript...).
> > > And live migration?
> > 
> > Read my email: "And of course, Spice protocol changes"
> > 
> > > I don't completely understand how you can avoid executing the PAC
> > > file if the destination host is provided by Qemu
> > > (client_migrate_info) unless I'm confusing with something else and
> > > it is the web client that delivers this info on migration.
> > 
> > I'm not against executing the PAC. It just requires a javascript
> > engine,
> > which is a bit of an overkill for Spice client to start working with,
> > no?
> > I'm aware there is a critical gap with the Spice protocol, but all
> > I'm
> > saying is that any other idea you'll come up with to get the topology
> > right is going to be a rewrite of the PAC idea. You will need to
> > define
> > the topology, and you'll need to lookup your current location against
> > it. This is what PAC does.
> > 
> > A Spice proxy would probably be able to solve the Spice protocol
> > issue,
> > as we expect the proxy to handle the host hand-over when migration
> > happens, I reckon.
> > 
> > >
> > > P.S.,
> > > If it is Qemu, then I don't see the current feature page accounting
> > > for that - IE, the hosts should also be informed on this override
> > > IP
> > 
> > Why? A host is rarely aware it is behind NAT. If it's because of the
> > protocol issue, the protocol has to be changed.
> 
> I'm referring to the current feature page as is (taking out the rest of the discussion): 
> It lacks solution for migration:
> 1. You have host A, and B, both with overridden IP set
> 2. On initial connect the browser provides the connection details using host A 'override IP' settings
> 3. VM Migrates from A to B
> 4. Now it's Qemu providing the destination connection details - it will provide the internal IP of host B
> 
> Connection breaks !!!
> 
> Again, unless I'm missing something and live migration destination is provided by the web client/engine to the spice client (somehow)

It is not and your concern is 100% valid.

CCing spice-devel.

David

> 
> 
> > Y.
> > 
> > >
> > >
> > >
> > >>> ok, so no engine, but just client side support for PAC?
> > >> Exactly.
> > >> And of course, Spice protocol changes, without which all this
> > >> effort
> > >> is
> > >> nice, but incomplete.
> > >> Y.
> > >>
> > >>
> > >> _______________________________________________
> > >> Engine-devel mailing list
> > >> Engine-devel at ovirt.org
> > >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >>
> > 
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel

-- 

David Ja?a, RHCE

SPICE QE based in Brno
GPG Key:     22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24





From lpeer at redhat.com  Thu Nov 15 11:13:42 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Thu, 15 Nov 2012 13:13:42 +0200
Subject: [Engine-devel] Network Wiring
In-Reply-To: <50A46837.5040201@redhat.com>
References: <999476552.1216069.1352818012177.JavaMail.root@redhat.com>
	<50A46837.5040201@redhat.com>
Message-ID: <50A4CE66.9020304@redhat.com>

On 15/11/12 05:57, Itamar Heim wrote:
> On 11/13/2012 04:46 PM, Alona Kaplan wrote:
>> Hi all,
>>
>> Please review the wiki and add your comments.
>>
>> http://wiki.ovirt.org/wiki/Feature/NetworkWiring
> 
>>     Dialog
>>
>>         If the VM status is 'UP'
>>
>>             If the Vnic is plugged there should be a message on top of
> the dialog "Please notice, changing Type or MAC will cause unplugging
> and plugging the Vnic".
>>             Port Mirroring - If the Vnic is plugged and the Vnic is
> set for port mirroring - "network", "type", "mac" and "port mirroring"
> fields in the dialog will be disabled.
> 
> can user change the type if port mirroring isn't enabled? doesn't this
> require unplug/plug back?

It does (see the first message written in the paragraph you copied, "if
changing type or MAC unplug and plug of the device is performed.") and
that's the action the engine will trigger.

> I assume all validations are at engine side to cover rest api as well?
> 

of course

>> REST API
>>
>> NIC properties:
>>
>> Changes:
>>
>>     Adding new properties under VM NIC:
>>
>>         plugged
>>         wired
>>
>>     Deprecating the active property under VM NIC
>>     Deprecating activate/deactivate actions
>>     Plug/unplug and wire/unwire on a vnic, will be done via PUT action
> on the VM NIC
>>         /api/vms/xxx/nics/yyy/
>>
> 
> that's a lot of deprecation - you can mark them as deprecated, but they
> still need to work over a period of time for backward compatibility, so
> please explain what they will show/how they behave until they are
> deprecated.

Same as today, they will perform plug and unplug , in the API you'll be
able to plug/unplug in two ways the deprecated one (use action) or via
edit vNic. the active property will be there as well, it will show the
same value a the plugged property.

> 
>> There is no reason to have dedicated actions for plug/unplug or
> wire/unwire. The original reason for having them was that edit VM nic
> while the VM was up used to be blocked and now we'll enable doing these
> actions.
> 
> actually, some users may not want to make these config changes while the
> VM is live, just to make them for the next boot. how will that work?

Well as long as we don't have separation for configuration and running
configuration it won't work. (same as changing the CPU or memory for
next VM run)

> 
> i agree with other comments that 'wired' is a bit confusing.
> s/wired-unwired/connected-disconnected/?
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From danken at redhat.com  Thu Nov 15 12:29:35 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Thu, 15 Nov 2012 14:29:35 +0200
Subject: [Engine-devel] Network Wiring
In-Reply-To: <31593663.534.1352920325997.JavaMail.javamailuser@localhost>
References: <50A2A5AA.9050302@redhat.com>
	<31593663.534.1352920325997.JavaMail.javamailuser@localhost>
Message-ID: <20121115122935.GS28591@redhat.com>

On Wed, Nov 14, 2012 at 02:12:07PM -0500, Simon Grinberg wrote:
> > 
> > The intention is to use the new API VDSM.libvirtVm.updateVmInteface
> > for
> > performing the network rewire in a single command.
> 
> What does it do? I could not find updateVmInteface in vdsm git. 
> Where is this defined? 
> 
> It's critical. 
> 
> - You can change the interface directly by moving the VM from one network to another 
> - You can do that but toggle the ling state so the VM will be aware. 
> 
> Which if these two?
> If you do only the first then it's not the common use case. In most cases you must toggle the link status to the VM.
> This will cause:
> 1. Speed negotiation + arp request that also informs the switched about the change  
> 2. In case it's DHCP (which most likely the case for guests) it will trigger new DHCP request. 
> 
> If you don't baaad things will happen :) 

I think that baaaaad things are going to happen anyway. In "baaaaad
things", I mean "stuff that require guest intervension".

The guest may be moved from one subnet into another one, maybe on
different VLAN or physical LAN. We can not expect that the applications
running on it will be happy about these changes. A similar case appears
if we rewire the network while the VM is down (or hibernated). When the
VM is restarted, it is going to use mismatching IP addresses.

You are right that it may make sense to request an new IP address after
the rewiring, however, a little test I just did on my desktop showed that
dhclient does not initiate a new request just because the carrier
dropped for few seconds. So we should try harder if we want to refresh
dhcp after rewiring: I think that it would be cool to have a guest agent verb
that does it.

Dan.


From iheim at redhat.com  Thu Nov 15 12:33:36 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 15 Nov 2012 14:33:36 +0200
Subject: [Engine-devel] Network Wiring
In-Reply-To: <20121115122935.GS28591@redhat.com>
References: <50A2A5AA.9050302@redhat.com>
	<31593663.534.1352920325997.JavaMail.javamailuser@localhost>
	<20121115122935.GS28591@redhat.com>
Message-ID: <50A4E120.2040009@redhat.com>

On 11/15/2012 02:29 PM, Dan Kenigsberg wrote:
> On Wed, Nov 14, 2012 at 02:12:07PM -0500, Simon Grinberg wrote:
>>>
>>> The intention is to use the new API VDSM.libvirtVm.updateVmInteface
>>> for
>>> performing the network rewire in a single command.
>>
>> What does it do? I could not find updateVmInteface in vdsm git.
>> Where is this defined?
>>
>> It's critical.
>>
>> - You can change the interface directly by moving the VM from one network to another
>> - You can do that but toggle the ling state so the VM will be aware.
>>
>> Which if these two?
>> If you do only the first then it's not the common use case. In most cases you must toggle the link status to the VM.
>> This will cause:
>> 1. Speed negotiation + arp request that also informs the switched about the change
>> 2. In case it's DHCP (which most likely the case for guests) it will trigger new DHCP request.
>>
>> If you don't baaad things will happen :)
>
> I think that baaaaad things are going to happen anyway. In "baaaaad
> things", I mean "stuff that require guest intervension".
>
> The guest may be moved from one subnet into another one, maybe on
> different VLAN or physical LAN. We can not expect that the applications
> running on it will be happy about these changes. A similar case appears
> if we rewire the network while the VM is down (or hibernated). When the
> VM is restarted, it is going to use mismatching IP addresses.
>
> You are right that it may make sense to request an new IP address after
> the rewiring, however, a little test I just did on my desktop showed that
> dhclient does not initiate a new request just because the carrier
> dropped for few seconds. So we should try harder if we want to refresh
> dhcp after rewiring: I think that it would be cool to have a guest agent verb
> that does it.

shouldn't this simulate a link disconnect/connect event to the OS?


From ykaul at redhat.com  Thu Nov 15 12:43:23 2012
From: ykaul at redhat.com (Yaniv Kaul)
Date: Thu, 15 Nov 2012 14:43:23 +0200
Subject: [Engine-devel] Network Wiring
In-Reply-To: <50A4E120.2040009@redhat.com>
References: <50A2A5AA.9050302@redhat.com>
	<31593663.534.1352920325997.JavaMail.javamailuser@localhost>
	<20121115122935.GS28591@redhat.com> <50A4E120.2040009@redhat.com>
Message-ID: <50A4E36B.9070200@redhat.com>

On 11/15/2012 02:33 PM, Itamar Heim wrote:
> On 11/15/2012 02:29 PM, Dan Kenigsberg wrote:
>> On Wed, Nov 14, 2012 at 02:12:07PM -0500, Simon Grinberg wrote:
>>>>
>>>> The intention is to use the new API VDSM.libvirtVm.updateVmInteface
>>>> for
>>>> performing the network rewire in a single command.
>>>
>>> What does it do? I could not find updateVmInteface in vdsm git.
>>> Where is this defined?
>>>
>>> It's critical.
>>>
>>> - You can change the interface directly by moving the VM from one 
>>> network to another
>>> - You can do that but toggle the ling state so the VM will be aware.
>>>
>>> Which if these two?
>>> If you do only the first then it's not the common use case. In most 
>>> cases you must toggle the link status to the VM.
>>> This will cause:
>>> 1. Speed negotiation + arp request that also informs the switched 
>>> about the change
>>> 2. In case it's DHCP (which most likely the case for guests) it will 
>>> trigger new DHCP request.
>>>
>>> If you don't baaad things will happen :)
>>
>> I think that baaaaad things are going to happen anyway. In "baaaaad
>> things", I mean "stuff that require guest intervension".
>>
>> The guest may be moved from one subnet into another one, maybe on
>> different VLAN or physical LAN. We can not expect that the applications
>> running on it will be happy about these changes. A similar case appears
>> if we rewire the network while the VM is down (or hibernated). When the
>> VM is restarted, it is going to use mismatching IP addresses.
>>
>> You are right that it may make sense to request an new IP address after
>> the rewiring, however, a little test I just did on my desktop showed 
>> that
>> dhclient does not initiate a new request just because the carrier
>> dropped for few seconds. So we should try harder if we want to refresh
>> dhcp after rewiring: I think that it would be cool to have a guest 
>> agent verb
>> that does it.

Blame your OS if it doesn't do media sensing at all (or correctly).

>
> shouldn't this simulate a link disconnect/connect event to the OS?

I sincerely hope it does.
Y.

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



From alkaplan at redhat.com  Thu Nov 15 13:32:01 2012
From: alkaplan at redhat.com (Alona Kaplan)
Date: Thu, 15 Nov 2012 08:32:01 -0500 (EST)
Subject: [Engine-devel] Network Wiring
In-Reply-To: <31593663.534.1352920325997.JavaMail.javamailuser@localhost>
Message-ID: <451565761.2397369.1352986320991.JavaMail.root@redhat.com>


> > On 11/13/2012 07:58 PM, Simon Grinberg wrote:
> > > From the summary:
> > > "...It supports the following actions without unplugging the
> > > Vnic,
> > > and it maintains the device address of the Vnic ...."
> > > 
> > > But in the dialogue section:
> > > "If the Vnic is plugged there should be a message on top of the
> > > dialog "Please notice, changing Type or MAC will cause unplugging
> > > and plugging the Vnic"
> > > 
> > > Looking at the detailed design indeed any change indeed goes
> > > through plug/unplug.
> > > Please correct me if I got the above wrong.
> > 
> > Changing the network (rewiring network) is done using new API with
> > VDSM,
> > updateVmInteface.
> > 
> > Therefore plug/unplug won't be executed for any of:
> > 1. Changing the network to other network or disconnecting/unwiring
> > it).
> > 2. Update the name of the VM (db only).
> > 
> > Other changes to VM properties (i.e. MAC address, driver type) will
> > require the plug/unplug. Same goes to any explicit 'unplug'
> > command.
> > 
> > > 
> > > To support real live rewire == "Move a card from one network to
> > > another"
> > > The sequence should be for wired-plugged card:
> > > - Unwire
> > > - Change network
> > > - Rewire
> > > 
> > > I would argue that we should actually force the user to perform
> > > these steps, but we can do it in one go.
> > 
> > The intention is to use the new API VDSM.libvirtVm.updateVmInteface
> > for
> > performing the network rewire in a single command.
> 
> What does it do? I could not find updateVmInteface in vdsm git.
> Where is this defined?
The wiki was updated, you can find it there.
http://wiki.ovirt.org/wiki/Feature/DetailedNetworkWiring#VDSM_API
> 
> It's critical.
> 
> - You can change the interface directly by moving the VM from one
> network to another
> - You can do that but toggle the ling state so the VM will be aware.
> 
> Which if these two?
> If you do only the first then it's not the common use case. In most
> cases you must toggle the link status to the VM.
> This will cause:
> 1. Speed negotiation + arp request that also informs the switched
> about the change
> 2. In case it's DHCP (which most likely the case for guests) it will
> trigger new DHCP request.
> 
> If you don't baaad things will happen :)
> 
> > 
> > > 
> > > Any other state may change network freely.
> > > 
> > > To change name - it's just DB, so any state goes
> > > 
> > > To change type or MAC address (= property), must go through
> > > unplug
> > > regardless to the wired state
> > > So:
> > > - Unplug
> > > - Change property
> > > - Plug
> > > 
> > > Again should probably ask the user to do these 3 steps so he'll
> > > know what he is doing, but we can do it for him with proper
> > > warning.
> > > 
> > > I also wander I do we have to drop the PCI address in the
> > > persisted
> > > table in this case - loosing the PCI location is redundant and
> > > will cause a move to another eth0 number in the guest. On the
> > > other hand changing of MAC may break network scripts anyhow - so
> > > I
> > > don't have a strong argument to keep it.
> > > 
> > > 
> > > Another issue:
> > > If the nic is there to be use by a hook, then you probably want
> > > to
> > > allow 'none' network.
> > > This may also be useful when allowing to purge a network while it
> > > is connected to VMs: unwire on all nics and connect to the none
> > > network.
> > > 
> > > 
> > > Overall, looking great, and I like the wired vs unplugged that
> > > emulate real behavior.
> > > 
> > > Regards,
> > > Simon
> > > 
> > > 
> > >  
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > >> From: "Alona Kaplan" <alkaplan at redhat.com>
> > >> To: engine-devel at ovirt.org, "Simon Grinberg"
> > >> <sgrinber at redhat.com>, rhevm-qe-network at redhat.com
> > >> Sent: Tuesday, November 13, 2012 4:46:52 PM
> > >> Subject: Network Wiring
> > >>
> > >> Hi all,
> > >>
> > >> Please review the wiki and add your comments.
> > >>
> > >> http://wiki.ovirt.org/wiki/Feature/NetworkWiring
> > >>
> > >>
> > >> Thanks,
> > >> Alona.
> > >>
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From danken at redhat.com  Thu Nov 15 13:36:02 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Thu, 15 Nov 2012 15:36:02 +0200
Subject: [Engine-devel] Network Wiring
In-Reply-To: <50A4E36B.9070200@redhat.com>
References: <50A2A5AA.9050302@redhat.com>
	<31593663.534.1352920325997.JavaMail.javamailuser@localhost>
	<20121115122935.GS28591@redhat.com> <50A4E120.2040009@redhat.com>
	<50A4E36B.9070200@redhat.com>
Message-ID: <20121115133602.GU28591@redhat.com>

On Thu, Nov 15, 2012 at 02:43:23PM +0200, Yaniv Kaul wrote:
> On 11/15/2012 02:33 PM, Itamar Heim wrote:
> >On 11/15/2012 02:29 PM, Dan Kenigsberg wrote:
> >>On Wed, Nov 14, 2012 at 02:12:07PM -0500, Simon Grinberg wrote:
> >>>>
> >>>>The intention is to use the new API VDSM.libvirtVm.updateVmInteface
> >>>>for
> >>>>performing the network rewire in a single command.
> >>>
> >>>What does it do? I could not find updateVmInteface in vdsm git.
> >>>Where is this defined?
> >>>
> >>>It's critical.
> >>>
> >>>- You can change the interface directly by moving the VM from
> >>>one network to another
> >>>- You can do that but toggle the ling state so the VM will be aware.
> >>>
> >>>Which if these two?
> >>>If you do only the first then it's not the common use case. In
> >>>most cases you must toggle the link status to the VM.
> >>>This will cause:
> >>>1. Speed negotiation + arp request that also informs the
> >>>switched about the change
> >>>2. In case it's DHCP (which most likely the case for guests)
> >>>it will trigger new DHCP request.
> >>>
> >>>If you don't baaad things will happen :)
> >>
> >>I think that baaaaad things are going to happen anyway. In "baaaaad
> >>things", I mean "stuff that require guest intervension".
> >>
> >>The guest may be moved from one subnet into another one, maybe on
> >>different VLAN or physical LAN. We can not expect that the applications
> >>running on it will be happy about these changes. A similar case appears
> >>if we rewire the network while the VM is down (or hibernated). When the
> >>VM is restarted, it is going to use mismatching IP addresses.
> >>
> >>You are right that it may make sense to request an new IP address after
> >>the rewiring, however, a little test I just did on my desktop
> >>showed that
> >>dhclient does not initiate a new request just because the carrier
> >>dropped for few seconds. So we should try harder if we want to refresh
> >>dhcp after rewiring: I think that it would be cool to have a
> >>guest agent verb
> >>that does it.
> 
> Blame your OS if it doesn't do media sensing at all (or correctly).

Media is sensed:

Nov 15 14:15:46 kernel: [3379655.213183] e1000e: eth0 NIC Link is Down
Nov 15 14:15:52 kernel: [3379661.265946] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: None
Nov 15 14:15:52 kernel: [3379661.265951] e1000e 0000:00:19.0: eth0: 10/100 speed: disabling TSO

but dhcp does not cancel its leases due to this. And I would not expect it to:
my dhcp server could change without carrier loss (e.g. vlan change on my
nearest switch, or dhcp reconfiguration)

> 
> >
> >shouldn't this simulate a link disconnect/connect event to the OS?
> 
> I sincerely hope it does.

Itamar, what is "this"? Setting link state to down does just that.

I was suggesting a guest agent verb that clears all pending dhcp leases after
the guest is connected again.

Dan.


From vszocs at redhat.com  Thu Nov 15 16:11:00 2012
From: vszocs at redhat.com (Vojtech Szocs)
Date: Thu, 15 Nov 2012 11:11:00 -0500 (EST)
Subject: [Engine-devel] UI Plugins: PoC patch revision 7 is here
In-Reply-To: <1396547715.6200193.1352990806918.JavaMail.root@redhat.com>
Message-ID: <1864939634.6244400.1352995860558.JavaMail.root@redhat.com>

Hi guys, 

the latest revisi on of UI Plugins proof-of-c on cept patch is now available for you to experiment with. I've split revision 7 changes apart from revision 6 to make it easier to review new features that were added into revision 7. 

You can download and apply UI Plugins patches from oVirt Gerrit code review system: 

    1. revision 6 - http://gerrit.ovirt.org/#/c/8120/ 
    2. revision 7 - http://gerrit.ovirt.org/#/c/9250/ 

Please read on to learn what's new in this revisi on . If you have any comments, questi on s or ideas, please let me know! 



Engine REST API integration 

UiInit is not the only event handler function anymore! :) 

UI plugin infrastructure now integrates with Engine REST API by acquiring new REST API session [1] upon successful user authentication. 

REST API session ID is provided to plugins via RestApiSessionAcquired event handler function. For example: 

api.register({ 
RestApiSessionAcquired: function(sessionId) { 
// Do something with newly acquired session ID 
} 
}); 

Note that UiInit function is still the first function to be invoked on the given plugin. Plugins can therefore expect RestApiSessionAcquired function to be called shortly after UiInit function. 

For now, UI plugin infrastructure guarantees that acquired Engine REST API session will be valid while the user stays authenticated in WebAdmin. This is done by keeping REST API session alive via periodic heartbeats (HTTP requests) in the background. This also means that it's safe to store and use REST API session ID until RestApiSessionAcquired function is called again with new value. In future, we might consider dropping this kind of guarantee to avoid the keep-alive heartbeat, and use some kind of "is session valid" query to determine if the REST API session is still valid. 

After the user signs out of WebAdmin, Engine REST API session will be closed, as per [1]. After signing in again, the process of acquiring new REST API session and calling RestApiSessionAcquired function repeats with new session ID value. 

Engine REST API integration also works seamlessly with auto login - if the user is already logged in on the backend, running WebAdmin in new window (tab) will take him directly to the main (authenticated) section of the application. In this case, UI plugin infrastructure remembers the currently valid REST API session ID using HTML5 local storage (or cookie if the browser doesn't support it). 



New API function: showDialog 

It's now possible to open custom dialogs using showDialog function. For example: 

api.register({ 
UiInit: function() { 
api.addMainTabActionButton('Host', 'Show Test Dialog', { 
onClick: function() { 
api.showDialog('Test Dialog', 'http://www.ovirt.org/', 600, 400); 
} 
}); 
} 
}); 

The signature of showDialog function is following: 


showDialog (title, contentUrl, width, height) 

For now, dialogs are shown using window.open API (non-modal browser popups ). This will be changed in future, providing close integration with GWTP / WebAdmin dialog infrastructure. 



New API function: setMainTabContentUrl 

It's now possible to update content URL of the given custom main tab using setMainTabContentUrl function. For example: 

api.register({ 
UiInit: function() { 
// Use 'about:blank' URL to display empty content 
api.addMainTab('Custom Tab', 'custom-tab', 'about:blank'); 
}, 
RestApiSessionAcquired: function(sessionId) { 
var url = 'http://www.ovirt.org/?s=' + encodeURIComponent(sessionId); 
api.setMainTabContentUrl('custom-tab', url); 
} 
}); 

In the above example, we first add an empty custom main tab. We do this in UiInit event handler function because we know that it's the best place for one-time UI initialization :) As soon as we receive REST API session ID, we update the URL of the custom main tab. This is just an example how REST API session ID can be sent over to your server as part of main tab content URL. 

The signature of setMainTabContentUrl function is following: 


setMainTabContentUrl(historyToken, contentUrl) 

Note that historyToken essentially identifies the custom main tab. 



That's it for now, let me know what you think! 

Regards, 
Vojtech 


[1] http://wiki.ovirt.org/wiki/Features/RESTSessionManagement 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121115/42ea4add/attachment.html>

From masayag at redhat.com  Thu Nov 15 17:01:46 2012
From: masayag at redhat.com (Moti Asayag)
Date: Thu, 15 Nov 2012 19:01:46 +0200
Subject: [Engine-devel] Managing permissions on network
In-Reply-To: <50991728.8070702@redhat.com>
References: <50991728.8070702@redhat.com>
Message-ID: <50A51FFA.1010206@redhat.com>

To recap so far:

1. User may see only the networks he has a permission on.
2. User API: Only permitted networks are shown to the user. A user will
be capable to view the network element attached to its vnic, only if he
has permission on that network, else it will see its id (same as storage
domain id appears under disk element which attached to a vm).
3. On upgrade: 'everyone' will get 'VmNetworkUser' role on all of the
networks on the system.
4. On the dialog of creating new network there will be an option to
grant 'everyone' permissions of the created network with 'VmNetworkUser'
role (same as on 'make template' dialog).
5. Since there is no granularity of permission of network for the scope
of a specific VM, If a user is 'VmNetworkUser' on a network, he may
attach it to any VM he has a permission on (permission to edit the VM).
6. 'Create a VM from Template' and 'Create a VM from Snapshot/Clone VM'
requires permissions on the vnics' networks. This will save the need to
grant an automatic permissions for the vnics' networks. An alternative
would be the opposite: Leave the current required permissions as is and
grant permissions to the users for the networks of the created VM.

Once we'll reach into a conclusion, I'll update the wiki accordingly.

Thanks,
Moti

On 11/06/2012 03:56 PM, Livnat Peer wrote:
> Hi All,
> 
> This is a proposal for handling network permissions in oVirt.
> 
> In this proposal we took the more permissive approach as we find it
> simple and a good starting point, we also think a more restrict approach
> makes the configuration of a network cumbersome for ovirt administrators.
> 
> Inputs are welcomed as always...
> 
> Here is an overview of the approach, for more detailed description
> please read the wiki page:
> http://wiki.ovirt.org/wiki/Feature/NetworkPermissions
> 
> ---------------------------------------------------------------------------
> Admin
> ======
> 
> -> For creating a network in a data center you need to be a Superuser or
> a DCAdmin or a networkAdmin on the DC.
> 
> -> After creating the network you can manipulate the network if you are
> a DCAdmin or a networkAdmin on the relevant network (or the whole DC).
> 
> -> For attaching the network to cluster you need to be a networkAdmin on
> the network (no requirement to have permission on the cluster)
> 
> -> Cluster administrator can not attach/detach a network from the
> cluster, the motivation for this is that as long as the network is not
> attached to the cluster it is not part of the cluster resources thus can
> not be managed by the cluster administrator.
> In addition once a network is attached to a cluster the cluster
> administrator can change the network from required to non-required for
> controlling the impact of the network within the cluster.
> 
> -> For setting a network on the host you need to be host administrator
> on the host and you don't need to be network administrator.
> This implies that if you are a host administrator you can add/remove all
> the cluster networks from your host without the need for network related
> permissions (this is the permissive approach).
> 
> User
> ====
> 
> -> For attaching a network to a Vnic in the VM you need to have the role
> of VmNetworkUser on the network and vmAdmin on the VM.
> 
> -> In user portal - the list of shown network for a user will include
> only the list of networks the user is allowed to attach to its vnics
> (instead of all cluster's networks).
> 
> Port-mirroring
> ===============
> 
> ->  For configuring in the VM port mirroring you need to have the role
> of VmAdvancedNetworkUser on the network and vmAdmin on the VM.
> VmAdvancedNetworkUser includes the VmNetworkUser actions in addition to
> port mirroring.
> 
> 
> 
> 
> For all DB upgrade information and new roles/action groups please review
> the wiki.
> 
> Thanks,
> Livnat & Moti
> 



From simon at redhat.com  Thu Nov 15 19:29:28 2012
From: simon at redhat.com (Simon Grinberg)
Date: Thu, 15 Nov 2012 14:29:28 -0500 (EST)
Subject: [Engine-devel] Network Wiring
In-Reply-To: <20121115133602.GU28591@redhat.com>
Message-ID: <14442727.1142.1353007764232.JavaMail.javamailuser@localhost>



----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Yaniv Kaul" <ykaul at redhat.com>
> Cc: "Simon Grinberg" <simon at redhat.com>, engine-devel at ovirt.org
> Sent: Thursday, November 15, 2012 3:36:02 PM
> Subject: Re: [Engine-devel] Network Wiring
> 
> On Thu, Nov 15, 2012 at 02:43:23PM +0200, Yaniv Kaul wrote:
> > On 11/15/2012 02:33 PM, Itamar Heim wrote:
> > >On 11/15/2012 02:29 PM, Dan Kenigsberg wrote:
> > >>On Wed, Nov 14, 2012 at 02:12:07PM -0500, Simon Grinberg wrote:
> > >>>>
> > >>>>The intention is to use the new API
> > >>>>VDSM.libvirtVm.updateVmInteface
> > >>>>for
> > >>>>performing the network rewire in a single command.
> > >>>
> > >>>What does it do? I could not find updateVmInteface in vdsm git.
> > >>>Where is this defined?
> > >>>
> > >>>It's critical.
> > >>>
> > >>>- You can change the interface directly by moving the VM from
> > >>>one network to another
> > >>>- You can do that but toggle the ling state so the VM will be
> > >>>aware.
> > >>>
> > >>>Which if these two?
> > >>>If you do only the first then it's not the common use case. In
> > >>>most cases you must toggle the link status to the VM.
> > >>>This will cause:
> > >>>1. Speed negotiation + arp request that also informs the
> > >>>switched about the change
> > >>>2. In case it's DHCP (which most likely the case for guests)
> > >>>it will trigger new DHCP request.
> > >>>
> > >>>If you don't baaad things will happen :)
> > >>
> > >>I think that baaaaad things are going to happen anyway. In
> > >>"baaaaad
> > >>things", I mean "stuff that require guest intervension".
> > >>
> > >>The guest may be moved from one subnet into another one, maybe on
> > >>different VLAN or physical LAN. We can not expect that the
> > >>applications
> > >>running on it will be happy about these changes. A similar case
> > >>appears
> > >>if we rewire the network while the VM is down (or hibernated).
> > >>When the
> > >>VM is restarted, it is going to use mismatching IP addresses.
> > >>
> > >>You are right that it may make sense to request an new IP address
> > >>after
> > >>the rewiring, however, a little test I just did on my desktop
> > >>showed that
> > >>dhclient does not initiate a new request just because the carrier
> > >>dropped for few seconds. So we should try harder if we want to
> > >>refresh
> > >>dhcp after rewiring: I think that it would be cool to have a
> > >>guest agent verb
> > >>that does it.
> > 
> > Blame your OS if it doesn't do media sensing at all (or correctly).
> 
> Media is sensed:
> 
> Nov 15 14:15:46 kernel: [3379655.213183] e1000e: eth0 NIC Link is
> Down
> Nov 15 14:15:52 kernel: [3379661.265946] e1000e: eth0 NIC Link is Up
> 100 Mbps Full Duplex, Flow Control: None
> Nov 15 14:15:52 kernel: [3379661.265951] e1000e 0000:00:19.0: eth0:
> 10/100 speed: disabling TSO

If you go trough link state toggle then I think it should be enough.

You are right, lot's of things get go wrong when you move a VM from network to network, but at least we did inform the OS, and the switches in the new network will now know there is a new MAC, the rest will have to wait until (and if) will support guest IP stetting. 


> 
> but dhcp does not cancel its leases due to this. And I would not
> expect it to:
> my dhcp server could change without carrier loss (e.g. vlan change on
> my
> nearest switch, or dhcp reconfiguration)
> 
> > 
> > >
> > >shouldn't this simulate a link disconnect/connect event to the OS?
> > 
> > I sincerely hope it does.
> 
> Itamar, what is "this"? Setting link state to down does just that.
> 
> I was suggesting a guest agent verb that clears all pending dhcp
> leases after
> the guest is connected again.
> 
> Dan.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From simon at redhat.com  Thu Nov 15 20:04:45 2012
From: simon at redhat.com (Simon Grinberg)
Date: Thu, 15 Nov 2012 15:04:45 -0500 (EST)
Subject: [Engine-devel] Network Wiring
In-Reply-To: <50A49B62.4050409@redhat.com>
Message-ID: <4890264.1209.1353009880602.JavaMail.javamailuser@localhost>


> 
> NX users may confuse between connected to vm or connected to the
> switch (despite of <plugged>),
> as they used to <link>=up|down<link/>
> 

Yap, no convergence on terminology yet, right?

I think we need to keep the plugged/unplugged not to confuse libvirt users
however let's do wired/un-wired = link-up / link-down it's understood by everyone and Michael pointed out

What about allowing a nic with the no-network? Did not see discussion on this.
It is useful as an interim state when changing networks or if the nic is there to be use by a hook. This may also be useful when allowing to purge a network while it is connected to VMs: Link-Down on all nics and connect to the empty/no network. (Yes I know, it's not par of the feature, but you know someone will ask for it soon :))

The coupling between vNIC and LN should break - for this feature (that I hate to call it wired) and for future to come.  

Simon.


From danken at redhat.com  Thu Nov 15 21:29:22 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Thu, 15 Nov 2012 23:29:22 +0200
Subject: [Engine-devel] Network Wiring
In-Reply-To: <4890264.1209.1353009880602.JavaMail.javamailuser@localhost>
References: <50A49B62.4050409@redhat.com>
	<4890264.1209.1353009880602.JavaMail.javamailuser@localhost>
Message-ID: <20121115212922.GA23109@redhat.com>

On Thu, Nov 15, 2012 at 03:04:45PM -0500, Simon Grinberg wrote:
> 
> > 
> > NX users may confuse between connected to vm or connected to the
> > switch (despite of <plugged>),
> > as they used to <link>=up|down<link/>
> > 
> 
> Yap, no convergence on terminology yet, right?
> 
> I think we need to keep the plugged/unplugged not to confuse libvirt users

Yes, with real iron nics (and hard drives), the term
"hotplug" is widely understood as "shove a new device into a running
machine". So I see no reason to change anything.
But I do not see how this is related to libvirt (which does not have an
API call named *plug*). 

> however let's do wired/un-wired = link-up / link-down it's understood by everyone and Michael pointed out

I'm fine with that.

> 
> What about allowing a nic with the no-network? Did not see discussion on this.

> It is useful as an interim state when changing networks or if the nic
> is there to be use by a hook. This may also be useful when allowing to
> purge a network while it is connected to VMs: Link-Down on all nics
> and connect to the empty/no network. (Yes I know, it's not par of the
> feature, but you know someone will ask for it soon :))

It should not be hard to implement; In
http://wiki.ovirt.org/wiki/Feature/DetailedNetworkWiring#New_API I suggest passing
no 'network' element to mean "connected to nothing".

> 
> The coupling between vNIC and LN should break - for this feature (that I hate to call it wired) and for future to come.  
> 
> Simon.


From emesika at redhat.com  Fri Nov 16 01:06:35 2012
From: emesika at redhat.com (Eli Mesika)
Date: Thu, 15 Nov 2012 20:06:35 -0500 (EST)
Subject: [Engine-devel] [Design for 3.2 RFE] Host Power Management Multiple
	Agent Support
In-Reply-To: <62953741.11119992.1353027917338.JavaMail.root@redhat.com>
Message-ID: <2102642826.11120241.1353027995152.JavaMail.root@redhat.com>


Requirements: http://wiki.ovirt.org/wiki/Features/HostPMMultipleAgents
DR          : http://wiki.ovirt.org/wiki/Features/Design/DetailedHostPMMultipleAgents


From iheim at redhat.com  Fri Nov 16 07:34:25 2012
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 16 Nov 2012 09:34:25 +0200
Subject: [Engine-devel] Managing permissions on network
In-Reply-To: <50A51FFA.1010206@redhat.com>
References: <50991728.8070702@redhat.com> <50A51FFA.1010206@redhat.com>
Message-ID: <50A5EC81.5020208@redhat.com>

On 11/15/2012 07:01 PM, Moti Asayag wrote:
> To recap so far:
>
> 1. User may see only the networks he has a permission on.
> 2. User API: Only permitted networks are shown to the user. A user will
> be capable to view the network element attached to its vnic, only if he
> has permission on that network, else it will see its id (same as storage
> domain id appears under disk element which attached to a vm).

I think a user should be able to see network for networks associated to 
their VMs, regardless of permissions to the attach the network to other vms.
it doesn't mean they need to see all details (like statistics, which are 
not part of the user level api)
I'm pretty sure storage, cluster and dc follow the same concept in user 
level api.

> 3. On upgrade: 'everyone' will get 'VmNetworkUser' role on all of the
> networks on the system.
> 4. On the dialog of creating new network there will be an option to
> grant 'everyone' permissions of the created network with 'VmNetworkUser'
> role (same as on 'make template' dialog).
> 5. Since there is no granularity of permission of network for the scope
> of a specific VM, If a user is 'VmNetworkUser' on a network, he may
> attach it to any VM he has a permission on (permission to edit the VM).
> 6. 'Create a VM from Template' and 'Create a VM from Snapshot/Clone VM'
> requires permissions on the vnics' networks. This will save the need to
> grant an automatic permissions for the vnics' networks. An alternative
> would be the opposite: Leave the current required permissions as is and
> grant permissions to the users for the networks of the created VM.
>
> Once we'll reach into a conclusion, I'll update the wiki accordingly.
>
> Thanks,
> Moti
>
> On 11/06/2012 03:56 PM, Livnat Peer wrote:
>> Hi All,
>>
>> This is a proposal for handling network permissions in oVirt.
>>
>> In this proposal we took the more permissive approach as we find it
>> simple and a good starting point, we also think a more restrict approach
>> makes the configuration of a network cumbersome for ovirt administrators.
>>
>> Inputs are welcomed as always...
>>
>> Here is an overview of the approach, for more detailed description
>> please read the wiki page:
>> http://wiki.ovirt.org/wiki/Feature/NetworkPermissions
>>
>> ---------------------------------------------------------------------------
>> Admin
>> ======
>>
>> -> For creating a network in a data center you need to be a Superuser or
>> a DCAdmin or a networkAdmin on the DC.
>>
>> -> After creating the network you can manipulate the network if you are
>> a DCAdmin or a networkAdmin on the relevant network (or the whole DC).
>>
>> -> For attaching the network to cluster you need to be a networkAdmin on
>> the network (no requirement to have permission on the cluster)
>>
>> -> Cluster administrator can not attach/detach a network from the
>> cluster, the motivation for this is that as long as the network is not
>> attached to the cluster it is not part of the cluster resources thus can
>> not be managed by the cluster administrator.
>> In addition once a network is attached to a cluster the cluster
>> administrator can change the network from required to non-required for
>> controlling the impact of the network within the cluster.
>>
>> -> For setting a network on the host you need to be host administrator
>> on the host and you don't need to be network administrator.
>> This implies that if you are a host administrator you can add/remove all
>> the cluster networks from your host without the need for network related
>> permissions (this is the permissive approach).
>>
>> User
>> ====
>>
>> -> For attaching a network to a Vnic in the VM you need to have the role
>> of VmNetworkUser on the network and vmAdmin on the VM.
>>
>> -> In user portal - the list of shown network for a user will include
>> only the list of networks the user is allowed to attach to its vnics
>> (instead of all cluster's networks).
>>
>> Port-mirroring
>> ===============
>>
>> ->  For configuring in the VM port mirroring you need to have the role
>> of VmAdvancedNetworkUser on the network and vmAdmin on the VM.
>> VmAdvancedNetworkUser includes the VmNetworkUser actions in addition to
>> port mirroring.
>>
>>
>>
>>
>> For all DB upgrade information and new roles/action groups please review
>> the wiki.
>>
>> Thanks,
>> Livnat & Moti
>>
>




From masayag at redhat.com  Fri Nov 16 08:22:31 2012
From: masayag at redhat.com (Moti Asayag)
Date: Fri, 16 Nov 2012 10:22:31 +0200
Subject: [Engine-devel] Managing permissions on network
In-Reply-To: <50A5EC81.5020208@redhat.com>
References: <50991728.8070702@redhat.com> <50A51FFA.1010206@redhat.com>
	<50A5EC81.5020208@redhat.com>
Message-ID: <50A5F7C7.6020701@redhat.com>

On 11/16/2012 09:34 AM, Itamar Heim wrote:
> On 11/15/2012 07:01 PM, Moti Asayag wrote:
>> To recap so far:
>>
>> 1. User may see only the networks he has a permission on.
>> 2. User API: Only permitted networks are shown to the user. A user will
>> be capable to view the network element attached to its vnic, only if he
>> has permission on that network, else it will see its id (same as storage
>> domain id appears under disk element which attached to a vm).
> 
> I think a user should be able to see network for networks associated to
> their VMs, regardless of permissions to the attach the network to other
> vms.
> it doesn't mean they need to see all details (like statistics, which are
> not part of the user level api)
> I'm pretty sure storage, cluster and dc follow the same concept in user
> level api.
> 

Could you elaborate the importance from user perspective for the network
implementation details? why the user should be concerned with MTU, Vlan
and other network properties? Wouldn't the cloud-provider prefer to
encapsulate this information from the end-user ?

>> 3. On upgrade: 'everyone' will get 'VmNetworkUser' role on all of the
>> networks on the system.
>> 4. On the dialog of creating new network there will be an option to
>> grant 'everyone' permissions of the created network with 'VmNetworkUser'
>> role (same as on 'make template' dialog).
>> 5. Since there is no granularity of permission of network for the scope
>> of a specific VM, If a user is 'VmNetworkUser' on a network, he may
>> attach it to any VM he has a permission on (permission to edit the VM).
>> 6. 'Create a VM from Template' and 'Create a VM from Snapshot/Clone VM'
>> requires permissions on the vnics' networks. This will save the need to
>> grant an automatic permissions for the vnics' networks. An alternative
>> would be the opposite: Leave the current required permissions as is and
>> grant permissions to the users for the networks of the created VM.
>>
>> Once we'll reach into a conclusion, I'll update the wiki accordingly.
>>
>> Thanks,
>> Moti
>>
>> On 11/06/2012 03:56 PM, Livnat Peer wrote:
>>> Hi All,
>>>
>>> This is a proposal for handling network permissions in oVirt.
>>>
>>> In this proposal we took the more permissive approach as we find it
>>> simple and a good starting point, we also think a more restrict approach
>>> makes the configuration of a network cumbersome for ovirt
>>> administrators.
>>>
>>> Inputs are welcomed as always...
>>>
>>> Here is an overview of the approach, for more detailed description
>>> please read the wiki page:
>>> http://wiki.ovirt.org/wiki/Feature/NetworkPermissions
>>>
>>> ---------------------------------------------------------------------------
>>>
>>> Admin
>>> ======
>>>
>>> -> For creating a network in a data center you need to be a Superuser or
>>> a DCAdmin or a networkAdmin on the DC.
>>>
>>> -> After creating the network you can manipulate the network if you are
>>> a DCAdmin or a networkAdmin on the relevant network (or the whole DC).
>>>
>>> -> For attaching the network to cluster you need to be a networkAdmin on
>>> the network (no requirement to have permission on the cluster)
>>>
>>> -> Cluster administrator can not attach/detach a network from the
>>> cluster, the motivation for this is that as long as the network is not
>>> attached to the cluster it is not part of the cluster resources thus can
>>> not be managed by the cluster administrator.
>>> In addition once a network is attached to a cluster the cluster
>>> administrator can change the network from required to non-required for
>>> controlling the impact of the network within the cluster.
>>>
>>> -> For setting a network on the host you need to be host administrator
>>> on the host and you don't need to be network administrator.
>>> This implies that if you are a host administrator you can add/remove all
>>> the cluster networks from your host without the need for network related
>>> permissions (this is the permissive approach).
>>>
>>> User
>>> ====
>>>
>>> -> For attaching a network to a Vnic in the VM you need to have the role
>>> of VmNetworkUser on the network and vmAdmin on the VM.
>>>
>>> -> In user portal - the list of shown network for a user will include
>>> only the list of networks the user is allowed to attach to its vnics
>>> (instead of all cluster's networks).
>>>
>>> Port-mirroring
>>> ===============
>>>
>>> ->  For configuring in the VM port mirroring you need to have the role
>>> of VmAdvancedNetworkUser on the network and vmAdmin on the VM.
>>> VmAdvancedNetworkUser includes the VmNetworkUser actions in addition to
>>> port mirroring.
>>>
>>>
>>>
>>>
>>> For all DB upgrade information and new roles/action groups please review
>>> the wiki.
>>>
>>> Thanks,
>>> Livnat & Moti
>>>
>>
> 
> 



From iheim at redhat.com  Fri Nov 16 10:06:49 2012
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 16 Nov 2012 12:06:49 +0200
Subject: [Engine-devel] Managing permissions on network
In-Reply-To: <50A5F7C7.6020701@redhat.com>
References: <50991728.8070702@redhat.com> <50A51FFA.1010206@redhat.com>
	<50A5EC81.5020208@redhat.com> <50A5F7C7.6020701@redhat.com>
Message-ID: <50A61039.505@redhat.com>

On 11/16/2012 10:22 AM, Moti Asayag wrote:
> On 11/16/2012 09:34 AM, Itamar Heim wrote:
>> On 11/15/2012 07:01 PM, Moti Asayag wrote:
>>> To recap so far:
>>>
>>> 1. User may see only the networks he has a permission on.
>>> 2. User API: Only permitted networks are shown to the user. A user will
>>> be capable to view the network element attached to its vnic, only if he
>>> has permission on that network, else it will see its id (same as storage
>>> domain id appears under disk element which attached to a vm).
>>
>> I think a user should be able to see network for networks associated to
>> their VMs, regardless of permissions to the attach the network to other
>> vms.
>> it doesn't mean they need to see all details (like statistics, which are
>> not part of the user level api)
>> I'm pretty sure storage, cluster and dc follow the same concept in user
>> level api.
>>
>
> Could you elaborate the importance from user perspective for the network
> implementation details? why the user should be concerned with MTU, Vlan
> and other network properties? Wouldn't the cloud-provider prefer to
> encapsulate this information from the end-user ?

i do agree not all fields are relevant to user, and iirc, we have a 
mechanism to filter out such fields.
is the MTU of the logical network a secret? user will get it from the 
vnic anyway, right?
logical network name is also something user may need to know (what is 
user going to see in the power user portal when standing on a VM which 
has a vnic with a network they don't have a permission for? the uuid 
instead of the network name?
tomorrow will let user create virtual networks. you need to decide which 
fields they can and cannot set (vlan they cannot set. not sure if we 
should or shouldn't hide it. i'm guessing both use cases will have merit 
actually).


>
>>> 3. On upgrade: 'everyone' will get 'VmNetworkUser' role on all of the
>>> networks on the system.
>>> 4. On the dialog of creating new network there will be an option to
>>> grant 'everyone' permissions of the created network with 'VmNetworkUser'
>>> role (same as on 'make template' dialog).
>>> 5. Since there is no granularity of permission of network for the scope
>>> of a specific VM, If a user is 'VmNetworkUser' on a network, he may
>>> attach it to any VM he has a permission on (permission to edit the VM).
>>> 6. 'Create a VM from Template' and 'Create a VM from Snapshot/Clone VM'
>>> requires permissions on the vnics' networks. This will save the need to
>>> grant an automatic permissions for the vnics' networks. An alternative
>>> would be the opposite: Leave the current required permissions as is and
>>> grant permissions to the users for the networks of the created VM.
>>>
>>> Once we'll reach into a conclusion, I'll update the wiki accordingly.
>>>
>>> Thanks,
>>> Moti
>>>
>>> On 11/06/2012 03:56 PM, Livnat Peer wrote:
>>>> Hi All,
>>>>
>>>> This is a proposal for handling network permissions in oVirt.
>>>>
>>>> In this proposal we took the more permissive approach as we find it
>>>> simple and a good starting point, we also think a more restrict approach
>>>> makes the configuration of a network cumbersome for ovirt
>>>> administrators.
>>>>
>>>> Inputs are welcomed as always...
>>>>
>>>> Here is an overview of the approach, for more detailed description
>>>> please read the wiki page:
>>>> http://wiki.ovirt.org/wiki/Feature/NetworkPermissions
>>>>
>>>> ---------------------------------------------------------------------------
>>>>
>>>> Admin
>>>> ======
>>>>
>>>> -> For creating a network in a data center you need to be a Superuser or
>>>> a DCAdmin or a networkAdmin on the DC.
>>>>
>>>> -> After creating the network you can manipulate the network if you are
>>>> a DCAdmin or a networkAdmin on the relevant network (or the whole DC).
>>>>
>>>> -> For attaching the network to cluster you need to be a networkAdmin on
>>>> the network (no requirement to have permission on the cluster)
>>>>
>>>> -> Cluster administrator can not attach/detach a network from the
>>>> cluster, the motivation for this is that as long as the network is not
>>>> attached to the cluster it is not part of the cluster resources thus can
>>>> not be managed by the cluster administrator.
>>>> In addition once a network is attached to a cluster the cluster
>>>> administrator can change the network from required to non-required for
>>>> controlling the impact of the network within the cluster.
>>>>
>>>> -> For setting a network on the host you need to be host administrator
>>>> on the host and you don't need to be network administrator.
>>>> This implies that if you are a host administrator you can add/remove all
>>>> the cluster networks from your host without the need for network related
>>>> permissions (this is the permissive approach).
>>>>
>>>> User
>>>> ====
>>>>
>>>> -> For attaching a network to a Vnic in the VM you need to have the role
>>>> of VmNetworkUser on the network and vmAdmin on the VM.
>>>>
>>>> -> In user portal - the list of shown network for a user will include
>>>> only the list of networks the user is allowed to attach to its vnics
>>>> (instead of all cluster's networks).
>>>>
>>>> Port-mirroring
>>>> ===============
>>>>
>>>> ->  For configuring in the VM port mirroring you need to have the role
>>>> of VmAdvancedNetworkUser on the network and vmAdmin on the VM.
>>>> VmAdvancedNetworkUser includes the VmNetworkUser actions in addition to
>>>> port mirroring.
>>>>
>>>>
>>>>
>>>>
>>>> For all DB upgrade information and new roles/action groups please review
>>>> the wiki.
>>>>
>>>> Thanks,
>>>> Livnat & Moti
>>>>
>>>
>>
>>
>




From satimis at yahoo.com  Fri Nov 16 11:12:43 2012
From: satimis at yahoo.com (Stephen Liu)
Date: Fri, 16 Nov 2012 03:12:43 -0800 (PST)
Subject: [Engine-devel] Building oVirt from source
In-Reply-To: <50A3CA17.6040605@redhat.com>
References: <1352823646.4124.YahooMailNeo@web125104.mail.ne1.yahoo.com>
	<50A36C2C.5030602@redhat.com>
	<1352887836.22748.YahooMailNeo@web125102.mail.ne1.yahoo.com>
	<50A37116.1040102@redhat.com>
	<1352889268.47516.YahooMailNeo@web125104.mail.ne1.yahoo.com>
	<50A37420.7090400@redhat.com>
	<1352891345.11371.YahooMailNeo@web125106.mail.ne1.yahoo.com>
	<50A37DCC.40100@redhat.com>
	<1352900414.97967.YahooMailNeo@web125102.mail.ne1.yahoo.com>
	<50A3C76B.1010806@redhat.com> <50A3CA17.6040605@redhat.com>
Message-ID: <1353064363.47972.YahooMailNeo@web125103.mail.ne1.yahoo.com>



----- Original Message -----

> From: Juan Hernandez <jhernand at redhat.com>
> To: Itamar Heim <iheim at redhat.com>; Stephen Liu <satimis at yahoo.com>
> Cc: "engine-devel at ovirt.org" <engine-devel at ovirt.org>
> Sent: Thursday, November 15, 2012 12:43 AM
> Subject: Re: [Engine-devel] Building oVirt from source
>
?-? snip -

> The reason is that the jboss rpm installs the files in
> /usr/share/jboss-as, owned by the root:jboss-as, so a non privileged
> user will not have permission to write to those directories.
> 
> Stephen, what I suggested you to do is to leave the installation of the
> application server in the /home/satimis/jboss-as directory and then
> modify the /home/satimis/.m2/settings.xml file. It should read as follows:
> 
> <settings
> ? xmlns="http://maven.apache.org/POM/4.0.0"
> ? xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> ? xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd">
> 
> ? <activeProfiles>
> ? ? <activeProfile>oVirt</activeProfile>
> ? </activeProfiles>
> 
> ? <profiles>
> ? ? <profile>
> ? ? ? <id>oVirt</id>
> ? ? ? <properties>
> ? ? ? ? <jbossHome>/home/satimis/jboss-as</jbossHome>
> ? ? ? </properties>
> ? ? </profile>
> ? </profiles>
> 
> </settings>
> 
> Also you don't need to start the jboss-as service, as ovirt doesn't use
> it. In a development environment you just go to
> /home/satimis/jboss-as/bin and run standalone.sh.
> 
> Also make sure that you own the /home/satimis/jboss-as directory:
> 
> sudo chown --recursive satimis:satimis /home/satimis/jboss-as


Hi Juan,

Thanks for your advice.

Performed following steps:

$ sudo gedit /home/satimis/.m2/settings.xml
change;
<jbossHome>/usr/share/jboss-as</jbossHome>
to
<jbossHome>/home/satimis/jboss-as</jbossHome>


$ sudo chown -R satimis:satimis /home/satimis/jboss-as


I have to re-run following commands;

$> git clone git://gerrit.ovirt.org/ovirt-engine
$> export OVIRT_HOME=$PWD/ovirt-engine
$> cd $OVIRT_HOME/backend/manager/dbscripts
#> ./create_db_devel.sh -u postgres


Build
=====
$> cd $OVIRT_HOME
$> mvn clean install
....
.....
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 7:36.078s
[INFO] Finished at: Fri Nov 16 18:22:13 HKT 2012
[INFO] Final Memory: 137M/593M
[INFO] ------------------------------------------------------------------------

There are "test run" failure messages.? Because the text scrolling moving too fast I can't take them down.? Where is the log of "Build"?


Deploy 
======
$> cd $OVIRT_HOME/ear
$> mvn clean install -Pdep,setup
....
....
[INFO] Executed tasks
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 14.909s
[INFO] Finished at: Fri Nov 16 18:26:49 HKT 2012
[INFO] Final Memory: 13M/246M
[INFO] ------------------------------------------------------------------------


Re-run following command as mentioned in the "Instruction" :
$ mvn clean install -Pdep
....
....
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 13.236s
[INFO] Finished at: Fri Nov 16 18:29:08 HKT 2012
[INFO] Final Memory: 13M/246M
[INFO] ------------------------------------------------------------------------


Testing 
======

# ./standalone.sh -b 0.0.0.0
-bash: ./standalone.sh: No such file or directory

# ls | grep standalone.sh
no output

# locate standalone.sh
/home/satimis/jboss-as/bin/standalone.sh
/home/satimis/jboss-as/bin/init.d/jboss-as-standalone.sh

It is very strange!? It is there!


I have to run following command to get it;
# cd /home/satimis/jboss-as/bin/
# ls | grep standalone.sh
standalone.sh

Then it is there.


# ./standalone.sh -b 0.0.0.0
....
....
2012-11-16 18:45:51,728 INFO? [org.jboss.as] (MSC service thread 1-4) JBAS015951: Admin console listening on http://127.0.0.1:9990
2012-11-16 18:45:51,732 INFO? [org.jboss.as] (MSC service thread 1-4) JBAS015874: JBoss AS 7.1.1.Final "Brontes" started in 11328ms - Started 536 of 627 services (90 services are passive or on-demand)
2012-11-16 18:45:51,752 INFO? [org.ovirt.engine.core.bll.InitBackendServicesOnStartupBean] (pool-10-thread-1) MacPoolManager finished: 11/16/12 6:45 PM
2012-11-16 18:45:51,853 INFO? [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018559: Deployed "engine.ear"

It hung here.? I have to press [Ctrl]+c to exit

Neither I found the "Welcome" page.


# hostname
fedora17
# hostname -f
fedora17


On browser I can't start api

http://fedora17:8080/api nor webadmin

Any mistake did I make?


> Let me insist that if the build runs correctly what you will have is an
> environment that you can use for development, it is not suitable or
> designed for using ovirt. If what you want to do is test ovirt from the
> user point of view then I strongly recommend that you use the prebuilt RPMs.

I have another hard drive testing the prebuilt RPMs.? Thanks

B.R.
Stephen L



From jhernand at redhat.com  Fri Nov 16 11:23:43 2012
From: jhernand at redhat.com (Juan Hernandez)
Date: Fri, 16 Nov 2012 12:23:43 +0100
Subject: [Engine-devel] Building oVirt from source
In-Reply-To: <1353064363.47972.YahooMailNeo@web125103.mail.ne1.yahoo.com>
References: <1352823646.4124.YahooMailNeo@web125104.mail.ne1.yahoo.com>
	<50A36C2C.5030602@redhat.com>
	<1352887836.22748.YahooMailNeo@web125102.mail.ne1.yahoo.com>
	<50A37116.1040102@redhat.com>
	<1352889268.47516.YahooMailNeo@web125104.mail.ne1.yahoo.com>
	<50A37420.7090400@redhat.com>
	<1352891345.11371.YahooMailNeo@web125106.mail.ne1.yahoo.com>
	<50A37DCC.40100@redhat.com>
	<1352900414.97967.YahooMailNeo@web125102.mail.ne1.yahoo.com>
	<50A3C76B.1010806@redhat.com> <50A3CA17.6040605@redhat.com>
	<1353064363.47972.YahooMailNeo@web125103.mail.ne1.yahoo.com>
Message-ID: <50A6223F.5040300@redhat.com>

On 11/16/2012 12:12 PM, Stephen Liu wrote:
> 
> 
> ----- Original Message -----
> 
>> From: Juan Hernandez <jhernand at redhat.com>
>> To: Itamar Heim <iheim at redhat.com>; Stephen Liu <satimis at yahoo.com>
>> Cc: "engine-devel at ovirt.org" <engine-devel at ovirt.org>
>> Sent: Thursday, November 15, 2012 12:43 AM
>> Subject: Re: [Engine-devel] Building oVirt from source
>>
>  -  snip -
> 
>> The reason is that the jboss rpm installs the files in
>> /usr/share/jboss-as, owned by the root:jboss-as, so a non privileged
>> user will not have permission to write to those directories.
>>
>> Stephen, what I suggested you to do is to leave the installation of the
>> application server in the /home/satimis/jboss-as directory and then
>> modify the /home/satimis/.m2/settings.xml file. It should read as follows:
>>
>> <settings
>>   xmlns="http://maven.apache.org/POM/4.0.0"
>>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>> http://maven.apache.org/xsd/settings-1.0.0.xsd">
>>
>>   <activeProfiles>
>>     <activeProfile>oVirt</activeProfile>
>>   </activeProfiles>
>>
>>   <profiles>
>>     <profile>
>>       <id>oVirt</id>
>>       <properties>
>>         <jbossHome>/home/satimis/jboss-as</jbossHome>
>>       </properties>
>>     </profile>
>>   </profiles>
>>
>> </settings>
>>
>> Also you don't need to start the jboss-as service, as ovirt doesn't use
>> it. In a development environment you just go to
>> /home/satimis/jboss-as/bin and run standalone.sh.
>>
>> Also make sure that you own the /home/satimis/jboss-as directory:
>>
>> sudo chown --recursive satimis:satimis /home/satimis/jboss-as
> 
> 
> Hi Juan,
> 
> Thanks for your advice.
> 
> Performed following steps:
> 
> $ sudo gedit /home/satimis/.m2/settings.xml
> change;
> <jbossHome>/usr/share/jboss-as</jbossHome>
> to
> <jbossHome>/home/satimis/jboss-as</jbossHome>
> 
> 
> $ sudo chown -R satimis:satimis /home/satimis/jboss-as
> 
> 
> I have to re-run following commands;
> 
> $> git clone git://gerrit.ovirt.org/ovirt-engine
> $> export OVIRT_HOME=$PWD/ovirt-engine
> $> cd $OVIRT_HOME/backend/manager/dbscripts
> #> ./create_db_devel.sh -u postgres
> 
> 
> Build
> =====
> $> cd $OVIRT_HOME
> $> mvn clean install
> ....
> .....
> [INFO] BUILD SUCCESS
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 7:36.078s
> [INFO] Finished at: Fri Nov 16 18:22:13 HKT 2012
> [INFO] Final Memory: 137M/593M
> [INFO] ------------------------------------------------------------------------
> 
> There are "test run" failure messages.  Because the text scrolling moving too fast I can't take them down.  Where is the log of "Build"?

There is no such build log. If you want a log you need to redirect the
build command to a file, something like this:

mvn clean install > build.log

The fact that you see the "BUILD SUCCESS" message means that everything
worked, included the tests, otherwise it would have failed.

> Deploy 
> ======
> $> cd $OVIRT_HOME/ear
> $> mvn clean install -Pdep,setup
> ....
> ....
> [INFO] Executed tasks
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD SUCCESS
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 14.909s
> [INFO] Finished at: Fri Nov 16 18:26:49 HKT 2012
> [INFO] Final Memory: 13M/246M
> [INFO] ------------------------------------------------------------------------
> 
> 
> Re-run following command as mentioned in the "Instruction" :
> $ mvn clean install -Pdep
> ....
> ....
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD SUCCESS
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 13.236s
> [INFO] Finished at: Fri Nov 16 18:29:08 HKT 2012
> [INFO] Final Memory: 13M/246M
> [INFO] ------------------------------------------------------------------------

Good, you have it deployed now!

> Testing 
> ======
> 
> # ./standalone.sh -b 0.0.0.0
> -bash: ./standalone.sh: No such file or directory
> 
> # ls | grep standalone.sh
> no output
> 
> # locate standalone.sh
> /home/satimis/jboss-as/bin/standalone.sh
> /home/satimis/jboss-as/bin/init.d/jboss-as-standalone.sh
> 
> It is very strange!  It is there!
> 
> 
> I have to run following command to get it;
> # cd /home/satimis/jboss-as/bin/
> # ls | grep standalone.sh
> standalone.sh
> 
> Then it is there.
> 
> 
> # ./standalone.sh -b 0.0.0.0
> ....
> ....
> 2012-11-16 18:45:51,728 INFO  [org.jboss.as] (MSC service thread 1-4) JBAS015951: Admin console listening on http://127.0.0.1:9990
> 2012-11-16 18:45:51,732 INFO  [org.jboss.as] (MSC service thread 1-4) JBAS015874: JBoss AS 7.1.1.Final "Brontes" started in 11328ms - Started 536 of 627 services (90 services are passive or on-demand)
> 2012-11-16 18:45:51,752 INFO  [org.ovirt.engine.core.bll.InitBackendServicesOnStartupBean] (pool-10-thread-1) MacPoolManager finished: 11/16/12 6:45 PM
> 2012-11-16 18:45:51,853 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018559: Deployed "engine.ear"
> 
> It hung here.  I have to press [Ctrl]+c to exit

That worked just fine, you have to keep the application server running
and go to another terminal windows if you want to run any other thing,
don't press Ctrl+C as that will stop the application server.

By the way, I see the # prompt in the commands that you are using. I
guess that means that you are using the root user to run the application
server. You shouldn't, it is better if you use an unprivileged user. If
you use root it will create log and temporary files owned by root and
then you will not be able to modify or remove them with your normal user.

> Neither I found the "Welcome" page.
> 
> 
> # hostname
> fedora17
> # hostname -f
> fedora17
> 
> 
> On browser I can't start api
> 
> http://fedora17:8080/api nor webadmin
> 
> Any mistake did I make?

The port number used by the engine is 8700, not 8080. We changed that
some time ago to avoid conflicts with the default port used by JBoss. So
you have to go to the following URL:

http://fedora17:8700

That should give you the welcome page. If you want to go to the API
directly then use the following:

http://fedora17:8700/api

>> Let me insist that if the build runs correctly what you will have is an
>> environment that you can use for development, it is not suitable or
>> designed for using ovirt. If what you want to do is test ovirt from the
>> user point of view then I strongly recommend that you use the prebuilt RPMs.
> 
> I have another hard drive testing the prebuilt RPMs.  Thanks 


-- 
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 iheim at redhat.com  Fri Nov 16 15:33:23 2012
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 16 Nov 2012 17:33:23 +0200
Subject: [Engine-devel] UI Plugins: PoC patch revision 7 is here
In-Reply-To: <1864939634.6244400.1352995860558.JavaMail.root@redhat.com>
References: <1864939634.6244400.1352995860558.JavaMail.root@redhat.com>
Message-ID: <50A65CC3.80600@redhat.com>

On 11/15/2012 06:11 PM, Vojtech Szocs wrote:
> Hi guys,
>
> the latest revision of UI Plugins proof-of-concept patch is now
> available for you to experiment with. I've split revision 7 changes
> apart from revision 6 to make it easier to review new features that were
> added into revision 7.
>
> You can download and apply UI Plugins patches from oVirt Gerrit code
> review system:
>
>  1. revision 6 - http://gerrit.ovirt.org/#/c/8120/
>  2. revision 7 - http://gerrit.ovirt.org/#/c/9250/
>
> Please read on to learn what's new in this revision. If you have any
> comments, questions or ideas, please let me know!
>
> ------------------------------------------------------------------------
>
> *Engine REST API integration*
>
> /UiInit/ is not the only event handler function anymore! :)
>
> UI plugin infrastructure now integrates with Engine REST API by
> acquiring new REST API session [1] upon successful user authentication.
>
> REST API session ID is provided to plugins via RestApiSessionAcquired
> event handler function. For example:
>
> api.register({
>    RestApiSessionAcquired: function(sessionId) {
>      // Do something with newly acquired session ID
>    }
> });
>
> Note that UiInit function is still the first function to be invoked on
> the given plugin. Plugins can therefore expect RestApiSessionAcquired
> function to be called shortly after UiInit function.
>
> For now, UI plugin infrastructure guarantees that acquired Engine REST
> API session will be valid while the user stays authenticated in
> WebAdmin. This is done by keeping REST API session alive via periodic
> heartbeats (HTTP requests) in the background. This also means that it's
> safe to store and use REST API session ID until RestApiSessionAcquired
> function is called again with new value. In future, we might consider
> dropping this kind of guarantee to avoid the keep-alive heartbeat, and
> use some kind of "is session valid" query to determine if the REST API
> session is still valid.
>
> After the user signs out of WebAdmin, Engine REST API session will be
> closed, as per [1]. After signing in again, the process of acquiring new
> REST API session and calling RestApiSessionAcquired function repeats
> with new session ID value.
>
> Engine REST API integration also works seamlessly with auto login - if
> the user is already logged in on the backend, running WebAdmin in new
> window (tab) will take him directly to the main (authenticated) section
> of the application. In this case, UI plugin infrastructure remembers the
> currently valid REST API session ID using HTML5 local storage (or cookie
> if the browser doesn't support it).
>
> ------------------------------------------------------------------------
>
> New API function: showDialog
>
> It's now possible to open custom dialogs using showDialog function. For
> example:
>
> api.register({
>    UiInit: function() {
>      api.addMainTabActionButton('Host', 'Show Test Dialog', {
>        onClick: function() {
>          api.showDialog('Test Dialog', 'http://www.ovirt.org/', 600, 400);
>        }
>      });
>    }
> });
>
> The signature of showDialog function is following:
>
> showDialog(title, contentUrl, width, height)
>
> For now, dialogs are shown using window.open API (non-modal browser
> popups). This will be changed in future, providing close integration
> with GWTP / WebAdmin dialog infrastructure.
>
> ------------------------------------------------------------------------
>
> New API function: setMainTabContentUrl
>
> It's now possible to update content URL of the given custom main tab
> using setMainTabContentUrl function. For example:
>
> api.register({
>    UiInit: function() {
>      // Use 'about:blank' URL to display empty content
>      api.addMainTab('Custom Tab', 'custom-tab', 'about:blank');
>    },
>    RestApiSessionAcquired: function(sessionId) {
>      var url = 'http://www.ovirt.org/?s=' + encodeURIComponent(sessionId);
>      api.setMainTabContentUrl('custom-tab', url);
>    }
> });
>
> In the above example, we first add an empty custom main tab. We do this
> in UiInit event handler function because we know that it's the best
> place for one-time UI initialization :) As soon as we receive REST API
> session ID, we update the URL of the custom main tab. This is just an
> example how REST API session ID can be sent over to your server as part
> of main tab content URL.
>
> The signature of setMainTabContentUrl function is following:
>
> setMainTabContentUrl(historyToken, contentUrl)
>
> Note that historyToken essentially identifies the custom main tab.
>
> ------------------------------------------------------------------------
>
> That's it for now, let me know what you think!
>
> Regards,
> Vojtech
>
>
> [1] http://wiki.ovirt.org/wiki/Features/RESTSessionManagement
>
>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>

is there a clear list of all APIs supported now?




From lhornyak at redhat.com  Fri Nov 16 15:53:44 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Fri, 16 Nov 2012 10:53:44 -0500 (EST)
Subject: [Engine-devel] vm priority
In-Reply-To: <1096775203.10546601.1353081093822.JavaMail.root@redhat.com>
Message-ID: <2021206952.10547905.1353081224944.JavaMail.root@redhat.com>

hi,

Vm + Vmstatic have a property 'priority'. Does anyone know where on the UI can one set this? Is this something only the rest api supports?

Thx,
Laszlo


From iheim at redhat.com  Fri Nov 16 16:01:31 2012
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 16 Nov 2012 18:01:31 +0200
Subject: [Engine-devel] vm priority
In-Reply-To: <2021206952.10547905.1353081224944.JavaMail.root@redhat.com>
References: <2021206952.10547905.1353081224944.JavaMail.root@redhat.com>
Message-ID: <50A6635B.5080003@redhat.com>

On 11/16/2012 05:53 PM, Laszlo Hornyak wrote:
> hi,
>
> Vm + Vmstatic have a property 'priority'. Does anyone know where on the UI can one set this? Is this something only the rest api supports?
>
> Thx,
> Laszlo
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>

not HA priority?



From vszocs at redhat.com  Fri Nov 16 16:08:30 2012
From: vszocs at redhat.com (Vojtech Szocs)
Date: Fri, 16 Nov 2012 11:08:30 -0500 (EST)
Subject: [Engine-devel] UI Plugins: PoC patch revision 7 is here
In-Reply-To: <50A65CC3.80600@redhat.com>
Message-ID: <2095133340.6626150.1353082110131.JavaMail.root@redhat.com>

> is there a clear list of all APIs supported now?

Not yet, unfortunately, this should be part of "for plugin developers" wiki that is planned to be written in upcoming weeks.

Vojtech


----- Original Message -----
From: "Itamar Heim" <iheim at redhat.com>
To: "Vojtech Szocs" <vszocs at redhat.com>
Cc: "engine-devel" <engine-devel at ovirt.org>
Sent: Friday, November 16, 2012 4:33:23 PM
Subject: Re: [Engine-devel] UI Plugins: PoC patch revision 7 is here

On 11/15/2012 06:11 PM, Vojtech Szocs wrote:
> Hi guys,
>
> the latest revision of UI Plugins proof-of-concept patch is now
> available for you to experiment with. I've split revision 7 changes
> apart from revision 6 to make it easier to review new features that were
> added into revision 7.
>
> You can download and apply UI Plugins patches from oVirt Gerrit code
> review system:
>
>  1. revision 6 - http://gerrit.ovirt.org/#/c/8120/
>  2. revision 7 - http://gerrit.ovirt.org/#/c/9250/
>
> Please read on to learn what's new in this revision. If you have any
> comments, questions or ideas, please let me know!
>
> ------------------------------------------------------------------------
>
> *Engine REST API integration*
>
> /UiInit/ is not the only event handler function anymore! :)
>
> UI plugin infrastructure now integrates with Engine REST API by
> acquiring new REST API session [1] upon successful user authentication.
>
> REST API session ID is provided to plugins via RestApiSessionAcquired
> event handler function. For example:
>
> api.register({
>    RestApiSessionAcquired: function(sessionId) {
>      // Do something with newly acquired session ID
>    }
> });
>
> Note that UiInit function is still the first function to be invoked on
> the given plugin. Plugins can therefore expect RestApiSessionAcquired
> function to be called shortly after UiInit function.
>
> For now, UI plugin infrastructure guarantees that acquired Engine REST
> API session will be valid while the user stays authenticated in
> WebAdmin. This is done by keeping REST API session alive via periodic
> heartbeats (HTTP requests) in the background. This also means that it's
> safe to store and use REST API session ID until RestApiSessionAcquired
> function is called again with new value. In future, we might consider
> dropping this kind of guarantee to avoid the keep-alive heartbeat, and
> use some kind of "is session valid" query to determine if the REST API
> session is still valid.
>
> After the user signs out of WebAdmin, Engine REST API session will be
> closed, as per [1]. After signing in again, the process of acquiring new
> REST API session and calling RestApiSessionAcquired function repeats
> with new session ID value.
>
> Engine REST API integration also works seamlessly with auto login - if
> the user is already logged in on the backend, running WebAdmin in new
> window (tab) will take him directly to the main (authenticated) section
> of the application. In this case, UI plugin infrastructure remembers the
> currently valid REST API session ID using HTML5 local storage (or cookie
> if the browser doesn't support it).
>
> ------------------------------------------------------------------------
>
> New API function: showDialog
>
> It's now possible to open custom dialogs using showDialog function. For
> example:
>
> api.register({
>    UiInit: function() {
>      api.addMainTabActionButton('Host', 'Show Test Dialog', {
>        onClick: function() {
>          api.showDialog('Test Dialog', 'http://www.ovirt.org/', 600, 400);
>        }
>      });
>    }
> });
>
> The signature of showDialog function is following:
>
> showDialog(title, contentUrl, width, height)
>
> For now, dialogs are shown using window.open API (non-modal browser
> popups). This will be changed in future, providing close integration
> with GWTP / WebAdmin dialog infrastructure.
>
> ------------------------------------------------------------------------
>
> New API function: setMainTabContentUrl
>
> It's now possible to update content URL of the given custom main tab
> using setMainTabContentUrl function. For example:
>
> api.register({
>    UiInit: function() {
>      // Use 'about:blank' URL to display empty content
>      api.addMainTab('Custom Tab', 'custom-tab', 'about:blank');
>    },
>    RestApiSessionAcquired: function(sessionId) {
>      var url = 'http://www.ovirt.org/?s=' + encodeURIComponent(sessionId);
>      api.setMainTabContentUrl('custom-tab', url);
>    }
> });
>
> In the above example, we first add an empty custom main tab. We do this
> in UiInit event handler function because we know that it's the best
> place for one-time UI initialization :) As soon as we receive REST API
> session ID, we update the URL of the custom main tab. This is just an
> example how REST API session ID can be sent over to your server as part
> of main tab content URL.
>
> The signature of setMainTabContentUrl function is following:
>
> setMainTabContentUrl(historyToken, contentUrl)
>
> Note that historyToken essentially identifies the custom main tab.
>
> ------------------------------------------------------------------------
>
> That's it for now, let me know what you think!
>
> Regards,
> Vojtech
>
>
> [1] http://wiki.ovirt.org/wiki/Features/RESTSessionManagement
>
>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>

is there a clear list of all APIs supported now?




From lhornyak at redhat.com  Fri Nov 16 16:16:08 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Fri, 16 Nov 2012 11:16:08 -0500 (EST)
Subject: [Engine-devel] vm priority
In-Reply-To: <50A6635B.5080003@redhat.com>
Message-ID: <392027847.10561138.1353082568255.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Friday, November 16, 2012 5:01:31 PM
> Subject: Re: [Engine-devel] vm priority
> 
> On 11/16/2012 05:53 PM, Laszlo Hornyak wrote:
> > hi,
> >
> > Vm + Vmstatic have a property 'priority'. Does anyone know where on
> > the UI can one set this? Is this something only the rest api
> > supports?
> >
> > Thx,
> > Laszlo
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 
> not HA priority?
> 
> 

It is called just 'priority' but indeed it is used in HA logic through VmsComparer, and also at migration.



From iheim at redhat.com  Fri Nov 16 16:24:52 2012
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 16 Nov 2012 18:24:52 +0200
Subject: [Engine-devel] UI Plugins: PoC patch revision 7 is here
In-Reply-To: <2095133340.6626150.1353082110131.JavaMail.root@redhat.com>
References: <2095133340.6626150.1353082110131.JavaMail.root@redhat.com>
Message-ID: <50A668D4.9000007@redhat.com>

On 11/16/2012 06:08 PM, Vojtech Szocs wrote:
>> is there a clear list of all APIs supported now?
>
> Not yet, unfortunately, this should be part of "for plugin developers" wiki that is planned to be written in upcoming weeks.

i just wanted to review how we solved not using internal entities as 
part of the API


From iheim at redhat.com  Fri Nov 16 16:35:37 2012
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 16 Nov 2012 18:35:37 +0200
Subject: [Engine-devel] [Design for 3.2 RFE] Host Power Management
 Multiple Agent Support
In-Reply-To: <2102642826.11120241.1353027995152.JavaMail.root@redhat.com>
References: <2102642826.11120241.1353027995152.JavaMail.root@redhat.com>
Message-ID: <50A66B59.2040106@redhat.com>

On 11/16/2012 03:06 AM, Eli Mesika wrote:
>
> Requirements: http://wiki.ovirt.org/wiki/Features/HostPMMultipleAgents
> DR          : http://wiki.ovirt.org/wiki/Features/Design/DetailedHostPMMultipleAgents
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>

Lon - thoughts on this?



From lhh at redhat.com  Fri Nov 16 17:42:12 2012
From: lhh at redhat.com (Lon Hohberger)
Date: Fri, 16 Nov 2012 12:42:12 -0500
Subject: [Engine-devel] [Design for 3.2 RFE] Host Power Management
 Multiple Agent Support
In-Reply-To: <50A66B59.2040106@redhat.com>
References: <2102642826.11120241.1353027995152.JavaMail.root@redhat.com>
	<50A66B59.2040106@redhat.com>
Message-ID: <50A67AF4.3060301@redhat.com>

On 11/16/2012 11:35 AM, Itamar Heim wrote:
> On 11/16/2012 03:06 AM, Eli Mesika wrote:
>>
>> Requirements: http://wiki.ovirt.org/wiki/Features/HostPMMultipleAgents
>> DR          :
>> http://wiki.ovirt.org/wiki/Features/Design/DetailedHostPMMultipleAgents
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> 
> Lon - thoughts on this?
> 


Looks the first thing that jumps out is that it looks like you can have:

   - do this one off action && do this one off action
   - do this one off action || do this one off action

So, try device A, and if this fails, try device B - or, if it's really
two ports on device A (but two calls), both must succeed.

One thing I wonder is whether these use cases are covered.

1) With WTI units and similar, many have two independent power rails.
This means that if someone trips over one of the power cables going to
the power switch unit, the host will still have power.

   A || (B && B')
   ^     ^    ^
   |     +----+---- WTI dual-rail remote power switch
   |                (two ports used - one on each power rail)
   |
   +--------------- iLO / IPMI / etc.

2) More common with the smaller APC units is that most have a single
power supply rail.  For power redundancy, it's not recommended to ever
plug both power supplies in to the same single-rail APC unit.

   A || (B && C)
   ^     ^    ^
   |     |    +---- APC device 2 port 1
   |     +--------- APC device 1 port 1
   +--------------- iLO / IPMI / etc.

E.g. try the iLO device first, but if that fails, you need to cut off
both power supplies (then on).  This is presumably less harsh to the
machines.  I also would not /necessarily/ limit things to two power
supplies, but I think two power supplies is the 99% use case.

I'll keep looking.

-- Lon


From emesika at redhat.com  Sat Nov 17 21:14:13 2012
From: emesika at redhat.com (Eli Mesika)
Date: Sat, 17 Nov 2012 16:14:13 -0500 (EST)
Subject: [Engine-devel] [Design for 3.2 RFE] Host Power Management
 Multiple Agent Support
In-Reply-To: <50A67AF4.3060301@redhat.com>
Message-ID: <2139386414.11571733.1353186853544.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Lon Hohberger" <lhh at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: "Eli Mesika" <emesika at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Friday, November 16, 2012 7:42:12 PM
> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Host Power Management Multiple Agent Support
> 
> On 11/16/2012 11:35 AM, Itamar Heim wrote:
> > On 11/16/2012 03:06 AM, Eli Mesika wrote:
> >>
> >> Requirements:
> >> http://wiki.ovirt.org/wiki/Features/HostPMMultipleAgents
> >> DR          :
> >> http://wiki.ovirt.org/wiki/Features/Design/DetailedHostPMMultipleAgents
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> > 
> > Lon - thoughts on this?
> > 
> 
> 
> Looks the first thing that jumps out is that it looks like you can
> have:
> 
>    - do this one off action && do this one off action
>    - do this one off action || do this one off action
> 
> So, try device A, and if this fails, try device B - or, if it's
> really
> two ports on device A (but two calls), both must succeed.
> 
> One thing I wonder is whether these use cases are covered.
> 
> 1) With WTI units and similar, many have two independent power rails.
> This means that if someone trips over one of the power cables going
> to
> the power switch unit, the host will still have power.
> 
>    A || (B && B')
>    ^     ^    ^
>    |     +----+---- WTI dual-rail remote power switch
>    |                (two ports used - one on each power rail)
>    |
>    +--------------- iLO / IPMI / etc.
> 
> 2) More common with the smaller APC units is that most have a single
> power supply rail.  For power redundancy, it's not recommended to
> ever
> plug both power supplies in to the same single-rail APC unit.
> 
>    A || (B && C)
>    ^     ^    ^
>    |     |    +---- APC device 2 port 1
>    |     +--------- APC device 1 port 1
>    +--------------- iLO / IPMI / etc.
> 
> E.g. try the iLO device first, but if that fails, you need to cut off
> both power supplies (then on).  This is presumably less harsh to the
> machines.  I also would not /necessarily/ limit things to two power
> supplies, but I think two power supplies is the 99% use case.
> 
> I'll keep looking.

Thanks Lon
I had added those questions in the Feature Talk page : http://wiki.ovirt.org/wiki/Talk:HostPMMultipleAgents
I will discuss those cases with Simon tomorrow and try to answer those questions 

> 
> -- Lon
> 


From alkaplan at redhat.com  Sun Nov 18 10:01:30 2012
From: alkaplan at redhat.com (Alona Kaplan)
Date: Sun, 18 Nov 2012 05:01:30 -0500 (EST)
Subject: [Engine-devel] Network Wiring
In-Reply-To: <20121115212922.GA23109@redhat.com>
Message-ID: <1741338378.3435590.1353232890332.JavaMail.root@redhat.com>


> > > NX users may confuse between connected to vm or connected to the
> > > switch (despite of <plugged>),
> > > as they used to <link>=up|down<link/>
> > > 
> > 
> > Yap, no convergence on terminology yet, right?
> > 
> > I think we need to keep the plugged/unplugged not to confuse
> > libvirt users
> 
> Yes, with real iron nics (and hard drives), the term
> "hotplug" is widely understood as "shove a new device into a running
> machine". So I see no reason to change anything.
> But I do not see how this is related to libvirt (which does not have
> an
> API call named *plug*).
> 
> > however let's do wired/un-wired = link-up / link-down it's
> > understood by everyone and Michael pointed out
> 
> I'm fine with that.
I"ve updated the wiki with the term "link state" instead of "wired/unwired".
> 
> > 
> > What about allowing a nic with the no-network? Did not see
> > discussion on this.
> 
> > It is useful as an interim state when changing networks or if the
> > nic
> > is there to be use by a hook. This may also be useful when allowing
> > to
> > purge a network while it is connected to VMs: Link-Down on all nics
> > and connect to the empty/no network. (Yes I know, it's not par of
> > the
> > feature, but you know someone will ask for it soon :))
> 
> It should not be hard to implement; In
> http://wiki.ovirt.org/wiki/Feature/DetailedNetworkWiring#New_API I
> suggest passing
> no 'network' element to mean "connected to nothing".
>
I don't really understand why changing the link state to down is not enough?
What is the added value of connecting "unwired" nic to a none network?
> > 
> > The coupling between vNIC and LN should break - for this feature
> > (that I hate to call it wired) and for future to come.
> > 
> > Simon.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From danken at redhat.com  Sun Nov 18 11:12:05 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Sun, 18 Nov 2012 13:12:05 +0200
Subject: [Engine-devel] Network Wiring
In-Reply-To: <1741338378.3435590.1353232890332.JavaMail.root@redhat.com>
References: <20121115212922.GA23109@redhat.com>
	<1741338378.3435590.1353232890332.JavaMail.root@redhat.com>
Message-ID: <20121118111205.GC4457@redhat.com>

On Sun, Nov 18, 2012 at 05:01:30AM -0500, Alona Kaplan wrote:
> 

<snip>

> > > purge a network while it is connected to VMs: Link-Down on all nics
> > > and connect to the empty/no network. (Yes I know, it's not par of
> > > the
> > > feature, but you know someone will ask for it soon :))
> > 
> > It should not be hard to implement; In
> > http://wiki.ovirt.org/wiki/Feature/DetailedNetworkWiring#New_API I
> > suggest passing
> > no 'network' element to mean "connected to nothing".
> >
> I don't really understand why changing the link state to down is not enough?
> What is the added value of connecting "unwired" nic to a none network?

It is not a big deal of a difference, but the semantics of having no
network is clear: you can run the VM if networks are missing, you can
remove a network when the VM is running. When a VM is associated to a
network, but its link state is down, the "right" semantics is more
vague.


From simon at redhat.com  Sun Nov 18 11:28:01 2012
From: simon at redhat.com (Simon Grinberg)
Date: Sun, 18 Nov 2012 06:28:01 -0500 (EST)
Subject: [Engine-devel] Network Wiring
In-Reply-To: <20121118111205.GC4457@redhat.com>
Message-ID: <30854051.160.1353238078184.JavaMail.javamailuser@localhost>



----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Alona Kaplan" <alkaplan at redhat.com>
> Cc: "Simon Grinberg" <simon at redhat.com>, engine-devel at ovirt.org
> Sent: Sunday, November 18, 2012 1:12:05 PM
> Subject: Re: [Engine-devel] Network Wiring
> 
> On Sun, Nov 18, 2012 at 05:01:30AM -0500, Alona Kaplan wrote:
> > 
> 
> <snip>
> 
> > > > purge a network while it is connected to VMs: Link-Down on all
> > > > nics
> > > > and connect to the empty/no network. (Yes I know, it's not par
> > > > of
> > > > the
> > > > feature, but you know someone will ask for it soon :))
> > > 
> > > It should not be hard to implement; In
> > > http://wiki.ovirt.org/wiki/Feature/DetailedNetworkWiring#New_API
> > > I
> > > suggest passing
> > > no 'network' element to mean "connected to nothing".
> > >
> > I don't really understand why changing the link state to down is
> > not enough?
> > What is the added value of connecting "unwired" nic to a none
> > network?
> 
> It is not a big deal of a difference, but the semantics of having no
> network is clear: you can run the VM if networks are missing, you can
> remove a network when the VM is running. When a VM is associated to a
> network, but its link state is down, the "right" semantics is more
> vague.

Indeed :)

Plus consider the use case of hooks providing the networking - they still need the engine to assign the MAC and type (like the CISCO hook).
If you force a logical network on each nic, it means you have to invent a dummy LN and define it as non-required and set the global config to allow VMs to run on hosts that do not have this networks - Too messy. Though sometimes desirable since the network name may be a hint to the hook, there are cases it's not.  

-> No LN means this VM can run on any host! with implicit assumption that someone else takes care of connecting it to the proper network.

Note that in this case you may still want the network with link state up and be allowed to bring the link up/down so it's for sure not the case as 'unwired/link down but connected to arbitrary network'  



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


From dfediuck at redhat.com  Sun Nov 18 13:00:48 2012
From: dfediuck at redhat.com (Doron Fediuck)
Date: Sun, 18 Nov 2012 08:00:48 -0500 (EST)
Subject: [Engine-devel] MOM [DR for 3.2] Host Power Management
	Proxy	Preferences
In-Reply-To: <887538074.10095557.1352823507006.JavaMail.root@redhat.com>
Message-ID: <1398810083.27830933.1353243648167.JavaMail.root@redhat.com>

----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, November 13, 2012 6:18:27 PM
> Subject: [Engine-devel] MOM [DR for 3.2] Host Power Management Proxy	Preferences
> 
> Hi
> 
> DR MOM : http://wiki.ovirt.org/wiki/Talk:HostPMProxyPreferences
> 
> Requirements Page :
> http://wiki.ovirt.org/wiki/Features/HostPMProxyPreferences
> DR                :
> http://wiki.ovirt.org/wiki/Features/Design/DetailedHostPMProxyPreferences
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 

Eli,
MOM is an ovirt project: http://wiki.ovirt.org/wiki/Project_Proposal_-_MOM

Can you please re-phrase the relevant strings?


From mpastern at redhat.com  Sun Nov 18 14:00:47 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 18 Nov 2012 16:00:47 +0200
Subject: [Engine-devel] ovirt-sdk 3.2.0.4 released
Message-ID: <50A8EA0F.5050708@redhat.com>


For more details see [1].

[1] http://wiki.ovirt.org/wiki/SDK#Change_Log

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From mpastern at redhat.com  Sun Nov 18 14:01:03 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 18 Nov 2012 16:01:03 +0200
Subject: [Engine-devel] ovirt-cli 3.2.0.7 released
Message-ID: <50A8EA1F.700@redhat.com>


For more details see [1].

[1] http://wiki.ovirt.org/wiki/CLI#Change_Log

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From alkaplan at redhat.com  Sun Nov 18 15:06:06 2012
From: alkaplan at redhat.com (Alona Kaplan)
Date: Sun, 18 Nov 2012 10:06:06 -0500 (EST)
Subject: [Engine-devel] Network Wiring
In-Reply-To: <30854051.160.1353238078184.JavaMail.javamailuser@localhost>
Message-ID: <508971465.3443029.1353251166091.JavaMail.root@redhat.com>


> > <snip>
> > 
> > > > > purge a network while it is connected to VMs: Link-Down on
> > > > > all
> > > > > nics
> > > > > and connect to the empty/no network. (Yes I know, it's not
> > > > > par
> > > > > of
> > > > > the
> > > > > feature, but you know someone will ask for it soon :))
> > > > 
> > > > It should not be hard to implement; In
> > > > http://wiki.ovirt.org/wiki/Feature/DetailedNetworkWiring#New_API
> > > > I
> > > > suggest passing
> > > > no 'network' element to mean "connected to nothing".
> > > >
> > > I don't really understand why changing the link state to down is
> > > not enough?
> > > What is the added value of connecting "unwired" nic to a none
> > > network?
> > 
> > It is not a big deal of a difference, but the semantics of having
> > no
> > network is clear: you can run the VM if networks are missing, you
> > can
> > remove a network when the VM is running. When a VM is associated to
> > a
> > network, but its link state is down, the "right" semantics is more
> > vague.
> 
> Indeed :)
> 
> Plus consider the use case of hooks providing the networking - they
> still need the engine to assign the MAC and type (like the CISCO
> hook).
> If you force a logical network on each nic, it means you have to
> invent a dummy LN and define it as non-required and set the global
> config to allow VMs to run on hosts that do not have this networks -
> Too messy. Though sometimes desirable since the network name may be
> a hint to the hook, there are cases it's not.
> 
> -> No LN means this VM can run on any host! with implicit assumption
> that someone else takes care of connecting it to the proper network.
> 
> Note that in this case you may still want the network with link state
> up and be allowed to bring the link up/down so it's for sure not the
> case as 'unwired/link down but connected to arbitrary network'
> 

I"ve added "none" network option to the wiki.
Any more comments? Do we have green light to start working on the feature?


From laravot at redhat.com  Mon Nov 19 09:36:01 2012
From: laravot at redhat.com (Liron Aravot)
Date: Mon, 19 Nov 2012 04:36:01 -0500 (EST)
Subject: [Engine-devel]  OvfAutoUpdater
In-Reply-To: <30854051.160.1353238078184.JavaMail.javamailuser@localhost>
Message-ID: <398148180.324976.1353317761303.JavaMail.root@redhat.com>

http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater

Hi all, i'll be glad if you could review the wiki page of OvfAutoUpdater, if you have any suggestions or ideas please let me know.

http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater

short preview from the wiki:
vm/template configurations (including disks info) are stored on the master storage domain for backup purposes, import/export and also to provide the abillity to run VMs without having a running engine/db. Currently ovf update is done synchronously when performing various operations on vms/templates - update, save, adding/removing a disk, etc. What's more, currently updating the ovf (updateVM vdsm call) is usually done within a transcation.

The idea behined OvfAutoUpdater is to perform batch ovf update operations that aggregate all outstanding updates per data center. These updates will be done in specifed time intervals which will reduce XML-RPC calls and will enable the removal of this syncronous vdsm call from all over the code. 

Thanks, 
Liron Aravot.


From laravot at redhat.com  Mon Nov 19 12:03:57 2012
From: laravot at redhat.com (Liron Aravot)
Date: Mon, 19 Nov 2012 07:03:57 -0500 (EST)
Subject: [Engine-devel] [Engine-Devel] OvfDataUpdater
Message-ID: <1204799899.347113.1353326637629.JavaMail.root@redhat.com>

starting a new discussion thread.

----- Original Message -----
> From: "Mike Kolesnik" <mkolesni at redhat.com>
> To: "Liron Aravot" <laravot at redhat.com>
> Sent: Monday, November 19, 2012 12:42:10 PM
> Subject: Re: [Engine-devel]  OvfAutoUpdater
> 
> I think 'version' is a more standard term for the column names.
> 
> Also in:  4. If succesfull - for each vm update the ovf_generation to
> equal the db_generation.
> I think you mean that the update should be to the entity version you
> initially selected.
> 
> Regards,
> Mike
> 
> ----- Original Message -----
> > http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater
> > 
> > Hi all, i'll be glad if you could review the wiki page of
> > OvfAutoUpdater, if you have any suggestions or ideas please let me
> > know.
> > 
> > http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater
> > 
> > short preview from the wiki:
> > vm/template configurations (including disks info) are stored on the
> > master storage domain for backup purposes, import/export and also
> > to
> > provide the abillity to run VMs without having a running engine/db.
> > Currently ovf update is done synchronously when performing various
> > operations on vms/templates - update, save, adding/removing a disk,
> > etc. What's more, currently updating the ovf (updateVM vdsm call)
> > is
> > usually done within a transcation.
> > 
> > The idea behined OvfAutoUpdater is to perform batch ovf update
> > operations that aggregate all outstanding updates per data center.
> > These updates will be done in specifed time intervals which will
> > reduce XML-RPC calls and will enable the removal of this syncronous
> > vdsm call from all over the code.
> > 
> > Thanks,
> > Liron Aravot.
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 


From vszocs at redhat.com  Mon Nov 19 12:07:16 2012
From: vszocs at redhat.com (Vojtech Szocs)
Date: Mon, 19 Nov 2012 07:07:16 -0500 (EST)
Subject: [Engine-devel] UI Plugins: PoC patch revision 7 is here
In-Reply-To: <50A668D4.9000007@redhat.com>
Message-ID: <57477608.7268460.1353326836299.JavaMail.root@redhat.com>

Hi Itamar,

UI plugin infrastructure translates internal business entities into JSON-like representations and passes those representations to UI plugins. (Internal entities are NOT exposed to UI plugins directly.)

Currently, all entities supported by UI plugin infrastructure (as per org.ovirt.engine.ui.webadmin.plugin.entity.EntityType) are transformed into following representation:

{ entityId: "[BusinessEntityGuidAsString]" }

For example, a VM entity with entity ID "vm123" will translate to:

{ entityId: "vm123" }

Translation is currently based on org.ovirt.engine.core.common.businessentities.BusinessEntity interface, like so: "BusinessEntity<? extends NGuid>" (we expect ID type parameter to be NGuid-compatible). However, I've found that there are some entities (like Pool - org.ovirt.engine.core.common.businessentities.vm_pools) that don't implement BusinessEntity interface.

Quick question to backend folks - IIRC all entities extend org.ovirt.engine.core.common.businessentities.IVdcQueryable, but not all entities implement org.ovirt.engine.core.common.businessentities.BusinessEntity interface. What is the precise relation between IVdcQueryable and BusinessEntity?

As for UI plugins, currently all entities get translated to above mentioned basic JSON-like representation. You can see the relevant code in org.ovirt.engine.ui.webadmin.plugin.entity.BaseEntity.from() static method. There's a TODO that says "make this class [BaseEntity] abstract and create specific entity for each EntityType" - this means we are planning to extend the above mentioned basic JSON-like representation for different entity types.

For example, for a VM entity we might do:

{ entityId: "[BusinessEntityGuidAsString]", osType: "[VmOsType]" }

Vojtech


----- Original Message -----
From: "Itamar Heim" <iheim at redhat.com>
To: "Vojtech Szocs" <vszocs at redhat.com>
Cc: "engine-devel" <engine-devel at ovirt.org>
Sent: Friday, November 16, 2012 5:24:52 PM
Subject: Re: [Engine-devel] UI Plugins: PoC patch revision 7 is here

On 11/16/2012 06:08 PM, Vojtech Szocs wrote:
>> is there a clear list of all APIs supported now?
>
> Not yet, unfortunately, this should be part of "for plugin developers" wiki that is planned to be written in upcoming weeks.

i just wanted to review how we solved not using internal entities as 
part of the API


From emesika at redhat.com  Mon Nov 19 12:24:09 2012
From: emesika at redhat.com (Eli Mesika)
Date: Mon, 19 Nov 2012 07:24:09 -0500 (EST)
Subject: [Engine-devel] Design review summary for 3.2 - adding support for
	External Events
Message-ID: <1316996516.11916636.1353327849211.JavaMail.root@redhat.com>

Discussion : http://wiki.ovirt.org/wiki/Talk:ExternalEvents
Updated Design : http://wiki.ovirt.org/wiki/Features/Design/DetailedExternalEvents#Future_directions


From mkublin at redhat.com  Mon Nov 19 12:41:53 2012
From: mkublin at redhat.com (Michael Kublin)
Date: Mon, 19 Nov 2012 07:41:53 -0500 (EST)
Subject: [Engine-devel] [Engine-Devel] OvfDataUpdater
In-Reply-To: <1204799899.347113.1353326637629.JavaMail.root@redhat.com>
Message-ID: <1932344772.11077934.1353328913440.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Liron Aravot" <laravot at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Monday, November 19, 2012 2:03:57 PM
> Subject: [Engine-devel] [Engine-Devel] OvfDataUpdater
> 
> starting a new discussion thread.
> 
> ----- Original Message -----
> > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > To: "Liron Aravot" <laravot at redhat.com>
> > Sent: Monday, November 19, 2012 12:42:10 PM
> > Subject: Re: [Engine-devel]  OvfAutoUpdater
> > 
> > I think 'version' is a more standard term for the column names.
> > 
> > Also in:  4. If succesfull - for each vm update the ovf_generation
> > to
> > equal the db_generation.
> > I think you mean that the update should be to the entity version
> > you
> > initially selected.
> > 
1. I think should be version = version +1;
2. Now the quartz is automatic process, updateVmInSpm it is spm operation -it means it can trigger a reconstruct
and spm election. 
3. How your solution is handling a case of hotPlug/hotUnplug/remove/add of vm disks. vm_static is not usually updated.
4. Reconstruct/Recovery - updateVmInSpm should be called on all vms, no matter if they were updated.

> > Regards,
> > Mike
> > 
> > ----- Original Message -----
> > > http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater
> > > 
> > > Hi all, i'll be glad if you could review the wiki page of
> > > OvfAutoUpdater, if you have any suggestions or ideas please let
> > > me
> > > know.
> > > 
> > > http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater
> > > 
> > > short preview from the wiki:
> > > vm/template configurations (including disks info) are stored on
> > > the
> > > master storage domain for backup purposes, import/export and also
> > > to
> > > provide the abillity to run VMs without having a running
> > > engine/db.
> > > Currently ovf update is done synchronously when performing
> > > various
> > > operations on vms/templates - update, save, adding/removing a
> > > disk,
> > > etc. What's more, currently updating the ovf (updateVM vdsm call)
> > > is
> > > usually done within a transcation.
> > > 
> > > The idea behined OvfAutoUpdater is to perform batch ovf update
> > > operations that aggregate all outstanding updates per data
> > > center.
> > > These updates will be done in specifed time intervals which will
> > > reduce XML-RPC calls and will enable the removal of this
> > > syncronous
> > > vdsm call from all over the code.
> > > 
> > > Thanks,
> > > Liron Aravot.
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From mkolesni at redhat.com  Mon Nov 19 12:44:56 2012
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Mon, 19 Nov 2012 07:44:56 -0500 (EST)
Subject: [Engine-devel] [Engine-Devel] OvfDataUpdater
In-Reply-To: <1932344772.11077934.1353328913440.JavaMail.root@redhat.com>
Message-ID: <837075679.11084061.1353329096837.JavaMail.root@redhat.com>

> 
> 
> ----- Original Message -----
> > From: "Liron Aravot" <laravot at redhat.com>
> > To: engine-devel at ovirt.org
> > Sent: Monday, November 19, 2012 2:03:57 PM
> > Subject: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > 
> > starting a new discussion thread.
> > 
> > ----- Original Message -----
> > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > To: "Liron Aravot" <laravot at redhat.com>
> > > Sent: Monday, November 19, 2012 12:42:10 PM
> > > Subject: Re: [Engine-devel]  OvfAutoUpdater
> > > 
> > > I think 'version' is a more standard term for the column names.
> > > 
> > > Also in:  4. If succesfull - for each vm update the
> > > ovf_generation
> > > to
> > > equal the db_generation.
> > > I think you mean that the update should be to the entity version
> > > you
> > > initially selected.
> > > 
> 1. I think should be version = version +1;
> 2. Now the quartz is automatic process, updateVmInSpm it is spm
> operation -it means it can trigger a reconstruct
> and spm election.
> 3. How your solution is handling a case of
> hotPlug/hotUnplug/remove/add of vm disks. vm_static is not usually
> updated.

Also consider snapshots & vNICs which affect the VM state.

> 4. Reconstruct/Recovery - updateVmInSpm should be called on all vms,
> no matter if they were updated.
> 
> > > Regards,
> > > Mike
> > > 
> > > ----- Original Message -----
> > > > http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater
> > > > 
> > > > Hi all, i'll be glad if you could review the wiki page of
> > > > OvfAutoUpdater, if you have any suggestions or ideas please let
> > > > me
> > > > know.
> > > > 
> > > > http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater
> > > > 
> > > > short preview from the wiki:
> > > > vm/template configurations (including disks info) are stored on
> > > > the
> > > > master storage domain for backup purposes, import/export and
> > > > also
> > > > to
> > > > provide the abillity to run VMs without having a running
> > > > engine/db.
> > > > Currently ovf update is done synchronously when performing
> > > > various
> > > > operations on vms/templates - update, save, adding/removing a
> > > > disk,
> > > > etc. What's more, currently updating the ovf (updateVM vdsm
> > > > call)
> > > > is
> > > > usually done within a transcation.
> > > > 
> > > > The idea behined OvfAutoUpdater is to perform batch ovf update
> > > > operations that aggregate all outstanding updates per data
> > > > center.
> > > > These updates will be done in specifed time intervals which
> > > > will
> > > > reduce XML-RPC calls and will enable the removal of this
> > > > syncronous
> > > > vdsm call from all over the code.
> > > > 
> > > > Thanks,
> > > > Liron Aravot.
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > 
> > > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From laravot at redhat.com  Mon Nov 19 12:52:56 2012
From: laravot at redhat.com (Liron Aravot)
Date: Mon, 19 Nov 2012 07:52:56 -0500 (EST)
Subject: [Engine-devel] [Engine-Devel] OvfDataUpdater
In-Reply-To: <837075679.11084061.1353329096837.JavaMail.root@redhat.com>
Message-ID: <2063236613.353421.1353329576965.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Mike Kolesnik" <mkolesni at redhat.com>
> To: "Liron Aravot" <laravot at redhat.com>
> Cc: engine-devel at ovirt.org, "Michael Kublin" <mkublin at redhat.com>
> Sent: Monday, November 19, 2012 2:44:56 PM
> Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> 
> > 
> > 
> > ----- Original Message -----
> > > From: "Liron Aravot" <laravot at redhat.com>
> > > To: engine-devel at ovirt.org
> > > Sent: Monday, November 19, 2012 2:03:57 PM
> > > Subject: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > > 
> > > starting a new discussion thread.
> > > 
> > > ----- Original Message -----
> > > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > To: "Liron Aravot" <laravot at redhat.com>
> > > > Sent: Monday, November 19, 2012 12:42:10 PM
> > > > Subject: Re: [Engine-devel]  OvfAutoUpdater
> > > > 
> > > > I think 'version' is a more standard term for the column names.
> > > > 
> > > > Also in:  4. If succesfull - for each vm update the
> > > > ovf_generation
> > > > to
> > > > equal the db_generation.
> > > > I think you mean that the update should be to the entity
> > > > version
> > > > you
> > > > initially selected.
> > > > 
> > 1. I think should be version = version +1;
the version will be the db_generation that was loaded when we loaded the vm/template.
for example - if the vm/template was updated twice between OvfUpdater runs, we will need to increment twice - so incrementing by one will cause another unneeded ovf update for that vm.
> > 2. Now the quartz is automatic process, updateVmInSpm it is spm
> > operation -it means it can trigger a reconstruct
> > and spm election.
2. updateVmInSpm command would be changed so it won't trigger failover, will add that to the wiki.
> > 3. How your solution is handling a case of
> > hotPlug/hotUnplug/remove/add of vm disks. vm_static is not usually
> > updated.
Whenever will be a command that locks a vm/template, you will have an option during the unlock to specify if the version need to be incremented, you'll be able to increment it also yourself.
The HotUnPlug command does lock the vm and during endSuccesfully attempt to update the vm in spm, so it will increment the db_version/generation instead.
> 
> Also consider snapshots & vNICs which affect the VM state.
Whatever affect the vm state and triggers updateVmInSpm today will continue to, it can be added to flows which don't do that today.
> 
> > 4. Reconstruct/Recovery - updateVmInSpm should be called on all
> > vms,
> > no matter if they were updated.

Ofcourse, it's being taken care of.
> > 
> > > > Regards,
> > > > Mike
> > > > 
> > > > ----- Original Message -----
> > > > > http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater
> > > > > 
> > > > > Hi all, i'll be glad if you could review the wiki page of
> > > > > OvfAutoUpdater, if you have any suggestions or ideas please
> > > > > let
> > > > > me
> > > > > know.
> > > > > 
> > > > > http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater
> > > > > 
> > > > > short preview from the wiki:
> > > > > vm/template configurations (including disks info) are stored
> > > > > on
> > > > > the
> > > > > master storage domain for backup purposes, import/export and
> > > > > also
> > > > > to
> > > > > provide the abillity to run VMs without having a running
> > > > > engine/db.
> > > > > Currently ovf update is done synchronously when performing
> > > > > various
> > > > > operations on vms/templates - update, save, adding/removing a
> > > > > disk,
> > > > > etc. What's more, currently updating the ovf (updateVM vdsm
> > > > > call)
> > > > > is
> > > > > usually done within a transcation.
> > > > > 
> > > > > The idea behined OvfAutoUpdater is to perform batch ovf
> > > > > update
> > > > > operations that aggregate all outstanding updates per data
> > > > > center.
> > > > > These updates will be done in specifed time intervals which
> > > > > will
> > > > > reduce XML-RPC calls and will enable the removal of this
> > > > > syncronous
> > > > > vdsm call from all over the code.
> > > > > 
> > > > > Thanks,
> > > > > Liron Aravot.
> > > > > _______________________________________________
> > > > > Engine-devel mailing list
> > > > > Engine-devel at ovirt.org
> > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > 
> > > > 
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 


From mkublin at redhat.com  Mon Nov 19 13:03:23 2012
From: mkublin at redhat.com (Michael Kublin)
Date: Mon, 19 Nov 2012 08:03:23 -0500 (EST)
Subject: [Engine-devel] [Engine-Devel] OvfDataUpdater
In-Reply-To: <2063236613.353421.1353329576965.JavaMail.root@redhat.com>
Message-ID: <226042103.11108816.1353330203642.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Liron Aravot" <laravot at redhat.com>
> To: "Mike Kolesnik" <mkolesni at redhat.com>
> Cc: engine-devel at ovirt.org, "Michael Kublin" <mkublin at redhat.com>
> Sent: Monday, November 19, 2012 2:52:56 PM
> Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> 
> 
> 
> ----- Original Message -----
> > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > To: "Liron Aravot" <laravot at redhat.com>
> > Cc: engine-devel at ovirt.org, "Michael Kublin" <mkublin at redhat.com>
> > Sent: Monday, November 19, 2012 2:44:56 PM
> > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Liron Aravot" <laravot at redhat.com>
> > > > To: engine-devel at ovirt.org
> > > > Sent: Monday, November 19, 2012 2:03:57 PM
> > > > Subject: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > > > 
> > > > starting a new discussion thread.
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > To: "Liron Aravot" <laravot at redhat.com>
> > > > > Sent: Monday, November 19, 2012 12:42:10 PM
> > > > > Subject: Re: [Engine-devel]  OvfAutoUpdater
> > > > > 
> > > > > I think 'version' is a more standard term for the column
> > > > > names.
> > > > > 
> > > > > Also in:  4. If succesfull - for each vm update the
> > > > > ovf_generation
> > > > > to
> > > > > equal the db_generation.
> > > > > I think you mean that the update should be to the entity
> > > > > version
> > > > > you
> > > > > initially selected.
> > > > > 
> > > 1. I think should be version = version +1;
> the version will be the db_generation that was loaded when we loaded
> the vm/template.
> for example - if the vm/template was updated twice between OvfUpdater
> runs, we will need to increment twice - so incrementing by one will
> cause another unneeded ovf update for that vm.
I am talking about ovfVersion or how you called it.
> > > 2. Now the quartz is automatic process, updateVmInSpm it is spm
> > > operation -it means it can trigger a reconstruct
> > > and spm election.
> 2. updateVmInSpm command would be changed so it won't trigger
> failover, will add that to the wiki.
> > > 3. How your solution is handling a case of
> > > hotPlug/hotUnplug/remove/add of vm disks. vm_static is not
> > > usually
> > > updated.
> Whenever will be a command that locks a vm/template, you will have an
> option during the unlock to specify if the version need to be
> incremented, you'll be able to increment it also yourself.
> The HotUnPlug command does lock the vm and during endSuccesfully
> attempt to update the vm in spm, so it will increment the
> db_version/generation instead.
> > 
addDisk, removeDisk, hotPlug/unPlug not locking a vm.
Also, as far as I know LockVm/UnLockVm it is operation on vm_dynamic and not 
vm_static.

> > Also consider snapshots & vNICs which affect the VM state.
> Whatever affect the vm state and triggers updateVmInSpm today will
> continue to, it can be added to flows which don't do that today.
> > 
> > > 4. Reconstruct/Recovery - updateVmInSpm should be called on all
> > > vms,
> > > no matter if they were updated.
> 
> Ofcourse, it's being taken care of.
How?
> > > 
> > > > > Regards,
> > > > > Mike
> > > > > 
> > > > > ----- Original Message -----
> > > > > > http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater
> > > > > > 
> > > > > > Hi all, i'll be glad if you could review the wiki page of
> > > > > > OvfAutoUpdater, if you have any suggestions or ideas please
> > > > > > let
> > > > > > me
> > > > > > know.
> > > > > > 
> > > > > > http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater
> > > > > > 
> > > > > > short preview from the wiki:
> > > > > > vm/template configurations (including disks info) are
> > > > > > stored
> > > > > > on
> > > > > > the
> > > > > > master storage domain for backup purposes, import/export
> > > > > > and
> > > > > > also
> > > > > > to
> > > > > > provide the abillity to run VMs without having a running
> > > > > > engine/db.
> > > > > > Currently ovf update is done synchronously when performing
> > > > > > various
> > > > > > operations on vms/templates - update, save, adding/removing
> > > > > > a
> > > > > > disk,
> > > > > > etc. What's more, currently updating the ovf (updateVM vdsm
> > > > > > call)
> > > > > > is
> > > > > > usually done within a transcation.
> > > > > > 
> > > > > > The idea behined OvfAutoUpdater is to perform batch ovf
> > > > > > update
> > > > > > operations that aggregate all outstanding updates per data
> > > > > > center.
> > > > > > These updates will be done in specifed time intervals which
> > > > > > will
> > > > > > reduce XML-RPC calls and will enable the removal of this
> > > > > > syncronous
> > > > > > vdsm call from all over the code.
> > > > > > 
> > > > > > Thanks,
> > > > > > Liron Aravot.
> > > > > > _______________________________________________
> > > > > > Engine-devel mailing list
> > > > > > Engine-devel at ovirt.org
> > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > 
> > > > > 
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > 
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > 
> 


From laravot at redhat.com  Mon Nov 19 13:17:04 2012
From: laravot at redhat.com (Liron Aravot)
Date: Mon, 19 Nov 2012 08:17:04 -0500 (EST)
Subject: [Engine-devel] [Engine-Devel] OvfDataUpdater
In-Reply-To: <226042103.11108816.1353330203642.JavaMail.root@redhat.com>
Message-ID: <1697244586.357264.1353331024359.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Kublin" <mkublin at redhat.com>
> To: "Liron Aravot" <laravot at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Monday, November 19, 2012 3:03:23 PM
> Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> 
> 
> 
> ----- Original Message -----
> > From: "Liron Aravot" <laravot at redhat.com>
> > To: "Mike Kolesnik" <mkolesni at redhat.com>
> > Cc: engine-devel at ovirt.org, "Michael Kublin" <mkublin at redhat.com>
> > Sent: Monday, November 19, 2012 2:52:56 PM
> > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > To: "Liron Aravot" <laravot at redhat.com>
> > > Cc: engine-devel at ovirt.org, "Michael Kublin" <mkublin at redhat.com>
> > > Sent: Monday, November 19, 2012 2:44:56 PM
> > > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Liron Aravot" <laravot at redhat.com>
> > > > > To: engine-devel at ovirt.org
> > > > > Sent: Monday, November 19, 2012 2:03:57 PM
> > > > > Subject: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > > > > 
> > > > > starting a new discussion thread.
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > > To: "Liron Aravot" <laravot at redhat.com>
> > > > > > Sent: Monday, November 19, 2012 12:42:10 PM
> > > > > > Subject: Re: [Engine-devel]  OvfAutoUpdater
> > > > > > 
> > > > > > I think 'version' is a more standard term for the column
> > > > > > names.
> > > > > > 
> > > > > > Also in:  4. If succesfull - for each vm update the
> > > > > > ovf_generation
> > > > > > to
> > > > > > equal the db_generation.
> > > > > > I think you mean that the update should be to the entity
> > > > > > version
> > > > > > you
> > > > > > initially selected.
> > > > > > 
> > > > 1. I think should be version = version +1;
> > the version will be the db_generation that was loaded when we
> > loaded
> > the vm/template.
> > for example - if the vm/template was updated twice between
> > OvfUpdater
> > runs, we will need to increment twice - so incrementing by one will
> > cause another unneeded ovf update for that vm.
> I am talking about ovfVersion or how you called it.
me too,
if we update the vm three times between OvfAutoUpdater runs , we will have the following values in the loaded vm for example:
db_generation 8
ovf_generation 5

when we perform the ovf update , ovf_generation should be set to 8 and not to 6, as version '8' is the version that we wrote the ovf metadata of.
> > > > 2. Now the quartz is automatic process, updateVmInSpm it is spm
> > > > operation -it means it can trigger a reconstruct
> > > > and spm election.
> > 2. updateVmInSpm command would be changed so it won't trigger
> > failover, will add that to the wiki.
> > > > 3. How your solution is handling a case of
> > > > hotPlug/hotUnplug/remove/add of vm disks. vm_static is not
> > > > usually
> > > > updated.
> > Whenever will be a command that locks a vm/template, you will have
> > an
> > option during the unlock to specify if the version need to be
> > incremented, you'll be able to increment it also yourself.
> > The HotUnPlug command does lock the vm and during endSuccesfully
> > attempt to update the vm in spm, so it will increment the
> > db_version/generation instead.
> > > 
> addDisk, removeDisk, hotPlug/unPlug not locking a vm.
> Also, as far as I know LockVm/UnLockVm it is operation on vm_dynamic
> and not
> vm_static.

hotplug acquires memory lock on the vm and has no async tasks if I recall correctly.
adddisk acquires shared lock on the vm which is problematic with today flow as well - as you have a race during updateVmInSpm, it should be fixed regardless of the OvfAutoUpdater.
> 
> > > Also consider snapshots & vNICs which affect the VM state.
> > Whatever affect the vm state and triggers updateVmInSpm today will
> > continue to, it can be added to flows which don't do that today.
> > > 
> > > > 4. Reconstruct/Recovery - updateVmInSpm should be called on all
> > > > vms,
> > > > no matter if they were updated.
> > 
> > Ofcourse, it's being taken care of.
> How?
we don't have ovf's of the vms when we reconstruct as we don't have master domain - so we should set the ovf_generation of the vms to be 0 - which will cause ovfautoupdater to copy the vm metadata.

a performance improvement may be introduced later on in case of wrong master version, but that's not related to the ovfautoupdater.
> > > > 
> > > > > > Regards,
> > > > > > Mike
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater
> > > > > > > 
> > > > > > > Hi all, i'll be glad if you could review the wiki page of
> > > > > > > OvfAutoUpdater, if you have any suggestions or ideas
> > > > > > > please
> > > > > > > let
> > > > > > > me
> > > > > > > know.
> > > > > > > 
> > > > > > > http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater
> > > > > > > 
> > > > > > > short preview from the wiki:
> > > > > > > vm/template configurations (including disks info) are
> > > > > > > stored
> > > > > > > on
> > > > > > > the
> > > > > > > master storage domain for backup purposes, import/export
> > > > > > > and
> > > > > > > also
> > > > > > > to
> > > > > > > provide the abillity to run VMs without having a running
> > > > > > > engine/db.
> > > > > > > Currently ovf update is done synchronously when
> > > > > > > performing
> > > > > > > various
> > > > > > > operations on vms/templates - update, save,
> > > > > > > adding/removing
> > > > > > > a
> > > > > > > disk,
> > > > > > > etc. What's more, currently updating the ovf (updateVM
> > > > > > > vdsm
> > > > > > > call)
> > > > > > > is
> > > > > > > usually done within a transcation.
> > > > > > > 
> > > > > > > The idea behined OvfAutoUpdater is to perform batch ovf
> > > > > > > update
> > > > > > > operations that aggregate all outstanding updates per
> > > > > > > data
> > > > > > > center.
> > > > > > > These updates will be done in specifed time intervals
> > > > > > > which
> > > > > > > will
> > > > > > > reduce XML-RPC calls and will enable the removal of this
> > > > > > > syncronous
> > > > > > > vdsm call from all over the code.
> > > > > > > 
> > > > > > > Thanks,
> > > > > > > Liron Aravot.
> > > > > > > _______________________________________________
> > > > > > > Engine-devel mailing list
> > > > > > > Engine-devel at ovirt.org
> > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > 
> > > > > > 
> > > > > _______________________________________________
> > > > > Engine-devel mailing list
> > > > > Engine-devel at ovirt.org
> > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > 
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > 
> > > 
> > 
> 


From mkublin at redhat.com  Mon Nov 19 13:28:06 2012
From: mkublin at redhat.com (Michael Kublin)
Date: Mon, 19 Nov 2012 08:28:06 -0500 (EST)
Subject: [Engine-devel] [Engine-Devel] OvfDataUpdater
In-Reply-To: <1697244586.357264.1353331024359.JavaMail.root@redhat.com>
Message-ID: <1173287158.11137716.1353331686451.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Liron Aravot" <laravot at redhat.com>
> To: "Michael Kublin" <mkublin at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Monday, November 19, 2012 3:17:04 PM
> Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> 
> 
> 
> ----- Original Message -----
> > From: "Michael Kublin" <mkublin at redhat.com>
> > To: "Liron Aravot" <laravot at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Monday, November 19, 2012 3:03:23 PM
> > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Liron Aravot" <laravot at redhat.com>
> > > To: "Mike Kolesnik" <mkolesni at redhat.com>
> > > Cc: engine-devel at ovirt.org, "Michael Kublin" <mkublin at redhat.com>
> > > Sent: Monday, November 19, 2012 2:52:56 PM
> > > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > To: "Liron Aravot" <laravot at redhat.com>
> > > > Cc: engine-devel at ovirt.org, "Michael Kublin"
> > > > <mkublin at redhat.com>
> > > > Sent: Monday, November 19, 2012 2:44:56 PM
> > > > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Liron Aravot" <laravot at redhat.com>
> > > > > > To: engine-devel at ovirt.org
> > > > > > Sent: Monday, November 19, 2012 2:03:57 PM
> > > > > > Subject: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > > > > > 
> > > > > > starting a new discussion thread.
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > > > To: "Liron Aravot" <laravot at redhat.com>
> > > > > > > Sent: Monday, November 19, 2012 12:42:10 PM
> > > > > > > Subject: Re: [Engine-devel]  OvfAutoUpdater
> > > > > > > 
> > > > > > > I think 'version' is a more standard term for the column
> > > > > > > names.
> > > > > > > 
> > > > > > > Also in:  4. If succesfull - for each vm update the
> > > > > > > ovf_generation
> > > > > > > to
> > > > > > > equal the db_generation.
> > > > > > > I think you mean that the update should be to the entity
> > > > > > > version
> > > > > > > you
> > > > > > > initially selected.
> > > > > > > 
> > > > > 1. I think should be version = version +1;
> > > the version will be the db_generation that was loaded when we
> > > loaded
> > > the vm/template.
> > > for example - if the vm/template was updated twice between
> > > OvfUpdater
> > > runs, we will need to increment twice - so incrementing by one
> > > will
> > > cause another unneeded ovf update for that vm.
> > I am talking about ovfVersion or how you called it.
> me too,
> if we update the vm three times between OvfAutoUpdater runs , we will
> have the following values in the loaded vm for example:
> db_generation 8
> ovf_generation 5
> 
> when we perform the ovf update , ovf_generation should be set to 8
> and not to 6, as version '8' is the version that we wrote the ovf
> metadata of.
These should be written in wiki, with remarks that values which were retrieved 
from DB together.
> > > > > 2. Now the quartz is automatic process, updateVmInSpm it is
> > > > > spm
> > > > > operation -it means it can trigger a reconstruct
> > > > > and spm election.
> > > 2. updateVmInSpm command would be changed so it won't trigger
> > > failover, will add that to the wiki.
> > > > > 3. How your solution is handling a case of
> > > > > hotPlug/hotUnplug/remove/add of vm disks. vm_static is not
> > > > > usually
> > > > > updated.
> > > Whenever will be a command that locks a vm/template, you will
> > > have
> > > an
> > > option during the unlock to specify if the version need to be
> > > incremented, you'll be able to increment it also yourself.
> > > The HotUnPlug command does lock the vm and during endSuccesfully
> > > attempt to update the vm in spm, so it will increment the
> > > db_version/generation instead.
> > > > 
> > addDisk, removeDisk, hotPlug/unPlug not locking a vm.
> > Also, as far as I know LockVm/UnLockVm it is operation on
> > vm_dynamic
> > and not
> > vm_static.
> 
> hotplug acquires memory lock on the vm and has no async tasks if I
> recall correctly.
Yes, correct and what? These what I said, vm_static is not updated.  
> adddisk acquires shared lock on the vm which is problematic with
> today flow as well - as you have a race during updateVmInSpm, it
> should be fixed regardless of the OvfAutoUpdater.
It is not answer on my question. How ovf will be updated? How you understand 
that ovf of vm should be updated?
> > 
> > > > Also consider snapshots & vNICs which affect the VM state.
> > > Whatever affect the vm state and triggers updateVmInSpm today
> > > will
> > > continue to, it can be added to flows which don't do that today.
> > > > 
> > > > > 4. Reconstruct/Recovery - updateVmInSpm should be called on
> > > > > all
> > > > > vms,
> > > > > no matter if they were updated.
> > > 
> > > Ofcourse, it's being taken care of.
> > How?
> we don't have ovf's of the vms when we reconstruct as we don't have
> master domain - so we should set the ovf_generation of the vms to be
> 0 - which will cause ovfautoupdater to copy the vm metadata.
I did not understand that statement and how it is related.
> a performance improvement may be introduced later on in case of wrong
> master version, but that's not related to the ovfautoupdater. 
I don't understand connection to performance.
Now you are replacing a calls to VmCommand.updateVmInSpm() one of them it
is at reconstruct flow, and you should handle it also and add it to wiki.
> > > > > 
> > > > > > > Regards,
> > > > > > > Mike
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater
> > > > > > > > 
> > > > > > > > Hi all, i'll be glad if you could review the wiki page
> > > > > > > > of
> > > > > > > > OvfAutoUpdater, if you have any suggestions or ideas
> > > > > > > > please
> > > > > > > > let
> > > > > > > > me
> > > > > > > > know.
> > > > > > > > 
> > > > > > > > http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater
> > > > > > > > 
> > > > > > > > short preview from the wiki:
> > > > > > > > vm/template configurations (including disks info) are
> > > > > > > > stored
> > > > > > > > on
> > > > > > > > the
> > > > > > > > master storage domain for backup purposes,
> > > > > > > > import/export
> > > > > > > > and
> > > > > > > > also
> > > > > > > > to
> > > > > > > > provide the abillity to run VMs without having a
> > > > > > > > running
> > > > > > > > engine/db.
> > > > > > > > Currently ovf update is done synchronously when
> > > > > > > > performing
> > > > > > > > various
> > > > > > > > operations on vms/templates - update, save,
> > > > > > > > adding/removing
> > > > > > > > a
> > > > > > > > disk,
> > > > > > > > etc. What's more, currently updating the ovf (updateVM
> > > > > > > > vdsm
> > > > > > > > call)
> > > > > > > > is
> > > > > > > > usually done within a transcation.
> > > > > > > > 
> > > > > > > > The idea behined OvfAutoUpdater is to perform batch ovf
> > > > > > > > update
> > > > > > > > operations that aggregate all outstanding updates per
> > > > > > > > data
> > > > > > > > center.
> > > > > > > > These updates will be done in specifed time intervals
> > > > > > > > which
> > > > > > > > will
> > > > > > > > reduce XML-RPC calls and will enable the removal of
> > > > > > > > this
> > > > > > > > syncronous
> > > > > > > > vdsm call from all over the code.
> > > > > > > > 
> > > > > > > > Thanks,
> > > > > > > > Liron Aravot.
> > > > > > > > _______________________________________________
> > > > > > > > Engine-devel mailing list
> > > > > > > > Engine-devel at ovirt.org
> > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > 
> > > > > > > 
> > > > > > _______________________________________________
> > > > > > Engine-devel mailing list
> > > > > > Engine-devel at ovirt.org
> > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > 
> > > > > _______________________________________________
> > > > > Engine-devel mailing list
> > > > > Engine-devel at ovirt.org
> > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > 
> > > > 
> > > 
> > 
> 


From laravot at redhat.com  Mon Nov 19 13:34:11 2012
From: laravot at redhat.com (Liron Aravot)
Date: Mon, 19 Nov 2012 08:34:11 -0500 (EST)
Subject: [Engine-devel] [Engine-Devel] OvfDataUpdater
In-Reply-To: <1173287158.11137716.1353331686451.JavaMail.root@redhat.com>
Message-ID: <1186564003.361332.1353332051329.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Kublin" <mkublin at redhat.com>
> To: "Liron Aravot" <laravot at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Monday, November 19, 2012 3:28:06 PM
> Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> 
> 
> 
> ----- Original Message -----
> > From: "Liron Aravot" <laravot at redhat.com>
> > To: "Michael Kublin" <mkublin at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Monday, November 19, 2012 3:17:04 PM
> > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Michael Kublin" <mkublin at redhat.com>
> > > To: "Liron Aravot" <laravot at redhat.com>
> > > Cc: engine-devel at ovirt.org
> > > Sent: Monday, November 19, 2012 3:03:23 PM
> > > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Liron Aravot" <laravot at redhat.com>
> > > > To: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > Cc: engine-devel at ovirt.org, "Michael Kublin"
> > > > <mkublin at redhat.com>
> > > > Sent: Monday, November 19, 2012 2:52:56 PM
> > > > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > To: "Liron Aravot" <laravot at redhat.com>
> > > > > Cc: engine-devel at ovirt.org, "Michael Kublin"
> > > > > <mkublin at redhat.com>
> > > > > Sent: Monday, November 19, 2012 2:44:56 PM
> > > > > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Liron Aravot" <laravot at redhat.com>
> > > > > > > To: engine-devel at ovirt.org
> > > > > > > Sent: Monday, November 19, 2012 2:03:57 PM
> > > > > > > Subject: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > > > > > > 
> > > > > > > starting a new discussion thread.
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > > > > To: "Liron Aravot" <laravot at redhat.com>
> > > > > > > > Sent: Monday, November 19, 2012 12:42:10 PM
> > > > > > > > Subject: Re: [Engine-devel]  OvfAutoUpdater
> > > > > > > > 
> > > > > > > > I think 'version' is a more standard term for the
> > > > > > > > column
> > > > > > > > names.
> > > > > > > > 
> > > > > > > > Also in:  4. If succesfull - for each vm update the
> > > > > > > > ovf_generation
> > > > > > > > to
> > > > > > > > equal the db_generation.
> > > > > > > > I think you mean that the update should be to the
> > > > > > > > entity
> > > > > > > > version
> > > > > > > > you
> > > > > > > > initially selected.
> > > > > > > > 
> > > > > > 1. I think should be version = version +1;
> > > > the version will be the db_generation that was loaded when we
> > > > loaded
> > > > the vm/template.
> > > > for example - if the vm/template was updated twice between
> > > > OvfUpdater
> > > > runs, we will need to increment twice - so incrementing by one
> > > > will
> > > > cause another unneeded ovf update for that vm.
> > > I am talking about ovfVersion or how you called it.
> > me too,
> > if we update the vm three times between OvfAutoUpdater runs , we
> > will
> > have the following values in the loaded vm for example:
> > db_generation 8
> > ovf_generation 5
> > 
> > when we perform the ovf update , ovf_generation should be set to 8
> > and not to 6, as version '8' is the version that we wrote the ovf
> > metadata of.
> These should be written in wiki, with remarks that values which were
> retrieved
> from DB together.
> > > > > > 2. Now the quartz is automatic process, updateVmInSpm it is
> > > > > > spm
> > > > > > operation -it means it can trigger a reconstruct
> > > > > > and spm election.
> > > > 2. updateVmInSpm command would be changed so it won't trigger
> > > > failover, will add that to the wiki.
> > > > > > 3. How your solution is handling a case of
> > > > > > hotPlug/hotUnplug/remove/add of vm disks. vm_static is not
> > > > > > usually
> > > > > > updated.
> > > > Whenever will be a command that locks a vm/template, you will
> > > > have
> > > > an
> > > > option during the unlock to specify if the version need to be
> > > > incremented, you'll be able to increment it also yourself.
> > > > The HotUnPlug command does lock the vm and during
> > > > endSuccesfully
> > > > attempt to update the vm in spm, so it will increment the
> > > > db_version/generation instead.
> > > > > 
> > > addDisk, removeDisk, hotPlug/unPlug not locking a vm.
> > > Also, as far as I know LockVm/UnLockVm it is operation on
> > > vm_dynamic
> > > and not
> > > vm_static.
> > 
> > hotplug acquires memory lock on the vm and has no async tasks if I
> > recall correctly.
> Yes, correct and what? These what I said, vm_static is not updated.
you will just call the dao method for incrementing the db_generation, you don't have to perform vm_static update.
> > adddisk acquires shared lock on the vm which is problematic with
> > today flow as well - as you have a race during updateVmInSpm, it
> > should be fixed regardless of the OvfAutoUpdater.
> It is not answer on my question. How ovf will be updated? How you
> understand
> that ovf of vm should be updated?

the ovf will be updated when you increment the db_generation value instead of calling updateVmInSpm().
you will be able to do that from the dao directly when you want, or when you unlock a vm/template.
when you will update the db_generation, the vm/template would be picked up by OvfUpdater as it's db_generation is different than its ovf_generation.

> > > 
> > > > > Also consider snapshots & vNICs which affect the VM state.
> > > > Whatever affect the vm state and triggers updateVmInSpm today
> > > > will
> > > > continue to, it can be added to flows which don't do that
> > > > today.
> > > > > 
> > > > > > 4. Reconstruct/Recovery - updateVmInSpm should be called on
> > > > > > all
> > > > > > vms,
> > > > > > no matter if they were updated.
> > > > 
> > > > Ofcourse, it's being taken care of.
> > > How?
> > we don't have ovf's of the vms when we reconstruct as we don't have
> > master domain - so we should set the ovf_generation of the vms to
> > be
> > 0 - which will cause ovfautoupdater to copy the vm metadata.
> I did not understand that statement and how it is related.
OvfAutoUpdater will get those vms for update as db_generation is different than ovf_generation.
> > a performance improvement may be introduced later on in case of
> > wrong
> > master version, but that's not related to the ovfautoupdater.
> I don't understand connection to performance.
> Now you are replacing a calls to VmCommand.updateVmInSpm() one of
> them it
> is at reconstruct flow, and you should handle it also and add it to
> wiki.
answered below, OvfAutoUpdater will get those vms for update as db_generation is different than ovf_generation. 
> > > > > > 
> > > > > > > > Regards,
> > > > > > > > Mike
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater
> > > > > > > > > 
> > > > > > > > > Hi all, i'll be glad if you could review the wiki
> > > > > > > > > page
> > > > > > > > > of
> > > > > > > > > OvfAutoUpdater, if you have any suggestions or ideas
> > > > > > > > > please
> > > > > > > > > let
> > > > > > > > > me
> > > > > > > > > know.
> > > > > > > > > 
> > > > > > > > > http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater
> > > > > > > > > 
> > > > > > > > > short preview from the wiki:
> > > > > > > > > vm/template configurations (including disks info) are
> > > > > > > > > stored
> > > > > > > > > on
> > > > > > > > > the
> > > > > > > > > master storage domain for backup purposes,
> > > > > > > > > import/export
> > > > > > > > > and
> > > > > > > > > also
> > > > > > > > > to
> > > > > > > > > provide the abillity to run VMs without having a
> > > > > > > > > running
> > > > > > > > > engine/db.
> > > > > > > > > Currently ovf update is done synchronously when
> > > > > > > > > performing
> > > > > > > > > various
> > > > > > > > > operations on vms/templates - update, save,
> > > > > > > > > adding/removing
> > > > > > > > > a
> > > > > > > > > disk,
> > > > > > > > > etc. What's more, currently updating the ovf
> > > > > > > > > (updateVM
> > > > > > > > > vdsm
> > > > > > > > > call)
> > > > > > > > > is
> > > > > > > > > usually done within a transcation.
> > > > > > > > > 
> > > > > > > > > The idea behined OvfAutoUpdater is to perform batch
> > > > > > > > > ovf
> > > > > > > > > update
> > > > > > > > > operations that aggregate all outstanding updates per
> > > > > > > > > data
> > > > > > > > > center.
> > > > > > > > > These updates will be done in specifed time intervals
> > > > > > > > > which
> > > > > > > > > will
> > > > > > > > > reduce XML-RPC calls and will enable the removal of
> > > > > > > > > this
> > > > > > > > > syncronous
> > > > > > > > > vdsm call from all over the code.
> > > > > > > > > 
> > > > > > > > > Thanks,
> > > > > > > > > Liron Aravot.
> > > > > > > > > _______________________________________________
> > > > > > > > > Engine-devel mailing list
> > > > > > > > > Engine-devel at ovirt.org
> > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > > 
> > > > > > > > 
> > > > > > > _______________________________________________
> > > > > > > Engine-devel mailing list
> > > > > > > Engine-devel at ovirt.org
> > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > 
> > > > > > _______________________________________________
> > > > > > Engine-devel mailing list
> > > > > > Engine-devel at ovirt.org
> > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 


From yzaslavs at redhat.com  Mon Nov 19 13:38:51 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Mon, 19 Nov 2012 15:38:51 +0200
Subject: [Engine-devel] [Engine-Devel] OvfDataUpdater
In-Reply-To: <1186564003.361332.1353332051329.JavaMail.root@redhat.com>
References: <1186564003.361332.1353332051329.JavaMail.root@redhat.com>
Message-ID: <50AA366B.2030505@redhat.com>



On 11/19/2012 03:34 PM, Liron Aravot wrote:
>
>
> ----- Original Message -----
>> From: "Michael Kublin" <mkublin at redhat.com>
>> To: "Liron Aravot" <laravot at redhat.com>
>> Cc: engine-devel at ovirt.org
>> Sent: Monday, November 19, 2012 3:28:06 PM
>> Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
>>
>>
>>
>> ----- Original Message -----
>>> From: "Liron Aravot" <laravot at redhat.com>
>>> To: "Michael Kublin" <mkublin at redhat.com>
>>> Cc: engine-devel at ovirt.org
>>> Sent: Monday, November 19, 2012 3:17:04 PM
>>> Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Michael Kublin" <mkublin at redhat.com>
>>>> To: "Liron Aravot" <laravot at redhat.com>
>>>> Cc: engine-devel at ovirt.org
>>>> Sent: Monday, November 19, 2012 3:03:23 PM
>>>> Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Liron Aravot" <laravot at redhat.com>
>>>>> To: "Mike Kolesnik" <mkolesni at redhat.com>
>>>>> Cc: engine-devel at ovirt.org, "Michael Kublin"
>>>>> <mkublin at redhat.com>
>>>>> Sent: Monday, November 19, 2012 2:52:56 PM
>>>>> Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
>>>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Mike Kolesnik" <mkolesni at redhat.com>
>>>>>> To: "Liron Aravot" <laravot at redhat.com>
>>>>>> Cc: engine-devel at ovirt.org, "Michael Kublin"
>>>>>> <mkublin at redhat.com>
>>>>>> Sent: Monday, November 19, 2012 2:44:56 PM
>>>>>> Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Liron Aravot" <laravot at redhat.com>
>>>>>>>> To: engine-devel at ovirt.org
>>>>>>>> Sent: Monday, November 19, 2012 2:03:57 PM
>>>>>>>> Subject: [Engine-devel] [Engine-Devel] OvfDataUpdater
>>>>>>>>
>>>>>>>> starting a new discussion thread.
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Mike Kolesnik" <mkolesni at redhat.com>
>>>>>>>>> To: "Liron Aravot" <laravot at redhat.com>
>>>>>>>>> Sent: Monday, November 19, 2012 12:42:10 PM
>>>>>>>>> Subject: Re: [Engine-devel]  OvfAutoUpdater
>>>>>>>>>
>>>>>>>>> I think 'version' is a more standard term for the
>>>>>>>>> column
>>>>>>>>> names.
>>>>>>>>>
>>>>>>>>> Also in:  4. If succesfull - for each vm update the
>>>>>>>>> ovf_generation
>>>>>>>>> to
>>>>>>>>> equal the db_generation.
>>>>>>>>> I think you mean that the update should be to the
>>>>>>>>> entity
>>>>>>>>> version
>>>>>>>>> you
>>>>>>>>> initially selected.
>>>>>>>>>
>>>>>>> 1. I think should be version = version +1;
>>>>> the version will be the db_generation that was loaded when we
>>>>> loaded
>>>>> the vm/template.
>>>>> for example - if the vm/template was updated twice between
>>>>> OvfUpdater
>>>>> runs, we will need to increment twice - so incrementing by one
>>>>> will
>>>>> cause another unneeded ovf update for that vm.
>>>> I am talking about ovfVersion or how you called it.
>>> me too,
>>> if we update the vm three times between OvfAutoUpdater runs , we
>>> will
>>> have the following values in the loaded vm for example:
>>> db_generation 8
>>> ovf_generation 5
>>>
>>> when we perform the ovf update , ovf_generation should be set to 8
>>> and not to 6, as version '8' is the version that we wrote the ovf
>>> metadata of.
>> These should be written in wiki, with remarks that values which were
>> retrieved
>> from DB together.
>>>>>>> 2. Now the quartz is automatic process, updateVmInSpm it is
>>>>>>> spm
>>>>>>> operation -it means it can trigger a reconstruct
>>>>>>> and spm election.
>>>>> 2. updateVmInSpm command would be changed so it won't trigger
>>>>> failover, will add that to the wiki.
>>>>>>> 3. How your solution is handling a case of
>>>>>>> hotPlug/hotUnplug/remove/add of vm disks. vm_static is not
>>>>>>> usually
>>>>>>> updated.
>>>>> Whenever will be a command that locks a vm/template, you will
>>>>> have
>>>>> an
>>>>> option during the unlock to specify if the version need to be
>>>>> incremented, you'll be able to increment it also yourself.
>>>>> The HotUnPlug command does lock the vm and during
>>>>> endSuccesfully
>>>>> attempt to update the vm in spm, so it will increment the
>>>>> db_version/generation instead.
>>>>>>
>>>> addDisk, removeDisk, hotPlug/unPlug not locking a vm.
>>>> Also, as far as I know LockVm/UnLockVm it is operation on
>>>> vm_dynamic
>>>> and not
>>>> vm_static.
>>>
>>> hotplug acquires memory lock on the vm and has no async tasks if I
>>> recall correctly.
>> Yes, correct and what? These what I said, vm_static is not updated.
> you will just call the dao method for incrementing the db_generation, you don't have to perform vm_static update.
>>> adddisk acquires shared lock on the vm which is problematic with
>>> today flow as well - as you have a race during updateVmInSpm, it
>>> should be fixed regardless of the OvfAutoUpdater.
>> It is not answer on my question. How ovf will be updated? How you
>> understand
>> that ovf of vm should be updated?
>
> the ovf will be updated when you increment the db_generation value instead of calling updateVmInSpm().
> you will be able to do that from the dao directly when you want, or when you unlock a vm/template.
> when you will update the db_generation, the vm/template would be picked up by OvfUpdater as it's db_generation is different than its ovf_generation.
>
>>>>
>>>>>> Also consider snapshots & vNICs which affect the VM state.
>>>>> Whatever affect the vm state and triggers updateVmInSpm today
>>>>> will
>>>>> continue to, it can be added to flows which don't do that
>>>>> today.
>>>>>>
>>>>>>> 4. Reconstruct/Recovery - updateVmInSpm should be called on
>>>>>>> all
>>>>>>> vms,
>>>>>>> no matter if they were updated.
>>>>>
>>>>> Ofcourse, it's being taken care of.
>>>> How?
>>> we don't have ovf's of the vms when we reconstruct as we don't have
>>> master domain - so we should set the ovf_generation of the vms to
>>> be
>>> 0 - which will cause ovfautoupdater to copy the vm metadata.
>> I did not understand that statement and how it is related.
> OvfAutoUpdater will get those vms for update as db_generation is different than ovf_generation.
>>> a performance improvement may be introduced later on in case of
>>> wrong
>>> master version, but that's not related to the ovfautoupdater.
>> I don't understand connection to performance.
>> Now you are replacing a calls to VmCommand.updateVmInSpm() one of
>> them it
>> is at reconstruct flow, and you should handle it also and add it to
>> wiki.
> answered below, OvfAutoUpdater will get those vms for update as db_generation is different than ovf_generation.
>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Mike
>>>>>>>>>
>>>>>>>>> ----- Original Message -----
>>>>>>>>>> http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater
>>>>>>>>>>
>>>>>>>>>> Hi all, i'll be glad if you could review the wiki
>>>>>>>>>> page
>>>>>>>>>> of
>>>>>>>>>> OvfAutoUpdater, if you have any suggestions or ideas
>>>>>>>>>> please
>>>>>>>>>> let
>>>>>>>>>> me
>>>>>>>>>> know.
>>>>>>>>>>
>>>>>>>>>> http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater
>>>>>>>>>>
>>>>>>>>>> short preview from the wiki:
>>>>>>>>>> vm/template configurations (including disks info) are
>>>>>>>>>> stored
>>>>>>>>>> on
>>>>>>>>>> the
>>>>>>>>>> master storage domain for backup purposes,
>>>>>>>>>> import/export
>>>>>>>>>> and
>>>>>>>>>> also
>>>>>>>>>> to
>>>>>>>>>> provide the abillity to run VMs without having a
>>>>>>>>>> running
>>>>>>>>>> engine/db.
>>>>>>>>>> Currently ovf update is done synchronously when
>>>>>>>>>> performing
>>>>>>>>>> various
>>>>>>>>>> operations on vms/templates - update, save,
>>>>>>>>>> adding/removing
>>>>>>>>>> a
>>>>>>>>>> disk,
>>>>>>>>>> etc. What's more, currently updating the ovf
>>>>>>>>>> (updateVM
>>>>>>>>>> vdsm
>>>>>>>>>> call)
>>>>>>>>>> is
>>>>>>>>>> usually done within a transcation.
>>>>>>>>>>
>>>>>>>>>> The idea behined OvfAutoUpdater is to perform batch
>>>>>>>>>> ovf
>>>>>>>>>> update
>>>>>>>>>> operations that aggregate all outstanding updates per
>>>>>>>>>> data
>>>>>>>>>> center.
>>>>>>>>>> These updates will be done in specifed time intervals
>>>>>>>>>> which
>>>>>>>>>> will
>>>>>>>>>> reduce XML-RPC calls and will enable the removal of
>>>>>>>>>> this
>>>>>>>>>> syncronous
>>>>>>>>>> vdsm call from all over the code.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Liron Aravot.

Are you going to expose the config value via engine-config?

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


From yzaslavs at redhat.com  Mon Nov 19 13:44:12 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Mon, 19 Nov 2012 15:44:12 +0200
Subject: [Engine-devel] [Engine-Devel] OvfDataUpdater
In-Reply-To: <50AA366B.2030505@redhat.com>
References: <1186564003.361332.1353332051329.JavaMail.root@redhat.com>
	<50AA366B.2030505@redhat.com>
Message-ID: <50AA37AC.1030805@redhat.com>



On 11/19/2012 03:38 PM, Yair Zaslavsky wrote:
>
>
> On 11/19/2012 03:34 PM, Liron Aravot wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Michael Kublin" <mkublin at redhat.com>
>>> To: "Liron Aravot" <laravot at redhat.com>
>>> Cc: engine-devel at ovirt.org
>>> Sent: Monday, November 19, 2012 3:28:06 PM
>>> Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Liron Aravot" <laravot at redhat.com>
>>>> To: "Michael Kublin" <mkublin at redhat.com>
>>>> Cc: engine-devel at ovirt.org
>>>> Sent: Monday, November 19, 2012 3:17:04 PM
>>>> Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Michael Kublin" <mkublin at redhat.com>
>>>>> To: "Liron Aravot" <laravot at redhat.com>
>>>>> Cc: engine-devel at ovirt.org
>>>>> Sent: Monday, November 19, 2012 3:03:23 PM
>>>>> Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
>>>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Liron Aravot" <laravot at redhat.com>
>>>>>> To: "Mike Kolesnik" <mkolesni at redhat.com>
>>>>>> Cc: engine-devel at ovirt.org, "Michael Kublin"
>>>>>> <mkublin at redhat.com>
>>>>>> Sent: Monday, November 19, 2012 2:52:56 PM
>>>>>> Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Mike Kolesnik" <mkolesni at redhat.com>
>>>>>>> To: "Liron Aravot" <laravot at redhat.com>
>>>>>>> Cc: engine-devel at ovirt.org, "Michael Kublin"
>>>>>>> <mkublin at redhat.com>
>>>>>>> Sent: Monday, November 19, 2012 2:44:56 PM
>>>>>>> Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Liron Aravot" <laravot at redhat.com>
>>>>>>>>> To: engine-devel at ovirt.org
>>>>>>>>> Sent: Monday, November 19, 2012 2:03:57 PM
>>>>>>>>> Subject: [Engine-devel] [Engine-Devel] OvfDataUpdater
>>>>>>>>>
>>>>>>>>> starting a new discussion thread.
>>>>>>>>>
>>>>>>>>> ----- Original Message -----
>>>>>>>>>> From: "Mike Kolesnik" <mkolesni at redhat.com>
>>>>>>>>>> To: "Liron Aravot" <laravot at redhat.com>
>>>>>>>>>> Sent: Monday, November 19, 2012 12:42:10 PM
>>>>>>>>>> Subject: Re: [Engine-devel]  OvfAutoUpdater
>>>>>>>>>>
>>>>>>>>>> I think 'version' is a more standard term for the
>>>>>>>>>> column
>>>>>>>>>> names.
>>>>>>>>>>
>>>>>>>>>> Also in:  4. If succesfull - for each vm update the
>>>>>>>>>> ovf_generation
>>>>>>>>>> to
>>>>>>>>>> equal the db_generation.
>>>>>>>>>> I think you mean that the update should be to the
>>>>>>>>>> entity
>>>>>>>>>> version
>>>>>>>>>> you
>>>>>>>>>> initially selected.
>>>>>>>>>>
>>>>>>>> 1. I think should be version = version +1;
>>>>>> the version will be the db_generation that was loaded when we
>>>>>> loaded
>>>>>> the vm/template.
>>>>>> for example - if the vm/template was updated twice between
>>>>>> OvfUpdater
>>>>>> runs, we will need to increment twice - so incrementing by one
>>>>>> will
>>>>>> cause another unneeded ovf update for that vm.
>>>>> I am talking about ovfVersion or how you called it.
>>>> me too,
>>>> if we update the vm three times between OvfAutoUpdater runs , we
>>>> will
>>>> have the following values in the loaded vm for example:
>>>> db_generation 8
>>>> ovf_generation 5
>>>>
>>>> when we perform the ovf update , ovf_generation should be set to 8
>>>> and not to 6, as version '8' is the version that we wrote the ovf
>>>> metadata of.
>>> These should be written in wiki, with remarks that values which were
>>> retrieved
>>> from DB together.
>>>>>>>> 2. Now the quartz is automatic process, updateVmInSpm it is
>>>>>>>> spm
>>>>>>>> operation -it means it can trigger a reconstruct
>>>>>>>> and spm election.
>>>>>> 2. updateVmInSpm command would be changed so it won't trigger
>>>>>> failover, will add that to the wiki.
>>>>>>>> 3. How your solution is handling a case of
>>>>>>>> hotPlug/hotUnplug/remove/add of vm disks. vm_static is not
>>>>>>>> usually
>>>>>>>> updated.
>>>>>> Whenever will be a command that locks a vm/template, you will
>>>>>> have
>>>>>> an
>>>>>> option during the unlock to specify if the version need to be
>>>>>> incremented, you'll be able to increment it also yourself.
>>>>>> The HotUnPlug command does lock the vm and during
>>>>>> endSuccesfully
>>>>>> attempt to update the vm in spm, so it will increment the
>>>>>> db_version/generation instead.
>>>>>>>
>>>>> addDisk, removeDisk, hotPlug/unPlug not locking a vm.
>>>>> Also, as far as I know LockVm/UnLockVm it is operation on
>>>>> vm_dynamic
>>>>> and not
>>>>> vm_static.
>>>>
>>>> hotplug acquires memory lock on the vm and has no async tasks if I
>>>> recall correctly.
>>> Yes, correct and what? These what I said, vm_static is not updated.
>> you will just call the dao method for incrementing the db_generation,
>> you don't have to perform vm_static update.
>>>> adddisk acquires shared lock on the vm which is problematic with
>>>> today flow as well - as you have a race during updateVmInSpm, it
>>>> should be fixed regardless of the OvfAutoUpdater.
>>> It is not answer on my question. How ovf will be updated? How you
>>> understand
>>> that ovf of vm should be updated?
>>
>> the ovf will be updated when you increment the db_generation value
>> instead of calling updateVmInSpm().
>> you will be able to do that from the dao directly when you want, or
>> when you unlock a vm/template.
>> when you will update the db_generation, the vm/template would be
>> picked up by OvfUpdater as it's db_generation is different than its
>> ovf_generation.
>>
>>>>>
>>>>>>> Also consider snapshots & vNICs which affect the VM state.
>>>>>> Whatever affect the vm state and triggers updateVmInSpm today
>>>>>> will
>>>>>> continue to, it can be added to flows which don't do that
>>>>>> today.
>>>>>>>
>>>>>>>> 4. Reconstruct/Recovery - updateVmInSpm should be called on
>>>>>>>> all
>>>>>>>> vms,
>>>>>>>> no matter if they were updated.
>>>>>>
>>>>>> Ofcourse, it's being taken care of.
>>>>> How?
>>>> we don't have ovf's of the vms when we reconstruct as we don't have
>>>> master domain - so we should set the ovf_generation of the vms to
>>>> be
>>>> 0 - which will cause ovfautoupdater to copy the vm metadata.
>>> I did not understand that statement and how it is related.
>> OvfAutoUpdater will get those vms for update as db_generation is
>> different than ovf_generation.
>>>> a performance improvement may be introduced later on in case of
>>>> wrong
>>>> master version, but that's not related to the ovfautoupdater.
>>> I don't understand connection to performance.
>>> Now you are replacing a calls to VmCommand.updateVmInSpm() one of
>>> them it
>>> is at reconstruct flow, and you should handle it also and add it to
>>> wiki.
>> answered below, OvfAutoUpdater will get those vms for update as
>> db_generation is different than ovf_generation.
>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Mike
>>>>>>>>>>
>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>> http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater
>>>>>>>>>>>
>>>>>>>>>>> Hi all, i'll be glad if you could review the wiki
>>>>>>>>>>> page
>>>>>>>>>>> of
>>>>>>>>>>> OvfAutoUpdater, if you have any suggestions or ideas
>>>>>>>>>>> please
>>>>>>>>>>> let
>>>>>>>>>>> me
>>>>>>>>>>> know.
>>>>>>>>>>>
>>>>>>>>>>> http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater
>>>>>>>>>>>
>>>>>>>>>>> short preview from the wiki:
>>>>>>>>>>> vm/template configurations (including disks info) are
>>>>>>>>>>> stored
>>>>>>>>>>> on
>>>>>>>>>>> the
>>>>>>>>>>> master storage domain for backup purposes,
>>>>>>>>>>> import/export
>>>>>>>>>>> and
>>>>>>>>>>> also
>>>>>>>>>>> to
>>>>>>>>>>> provide the abillity to run VMs without having a
>>>>>>>>>>> running
>>>>>>>>>>> engine/db.
>>>>>>>>>>> Currently ovf update is done synchronously when
>>>>>>>>>>> performing
>>>>>>>>>>> various
>>>>>>>>>>> operations on vms/templates - update, save,
>>>>>>>>>>> adding/removing
>>>>>>>>>>> a
>>>>>>>>>>> disk,
>>>>>>>>>>> etc. What's more, currently updating the ovf
>>>>>>>>>>> (updateVM
>>>>>>>>>>> vdsm
>>>>>>>>>>> call)
>>>>>>>>>>> is
>>>>>>>>>>> usually done within a transcation.
>>>>>>>>>>>
>>>>>>>>>>> The idea behined OvfAutoUpdater is to perform batch
>>>>>>>>>>> ovf
>>>>>>>>>>> update
>>>>>>>>>>> operations that aggregate all outstanding updates per
>>>>>>>>>>> data
>>>>>>>>>>> center.
>>>>>>>>>>> These updates will be done in specifed time intervals
>>>>>>>>>>> which
>>>>>>>>>>> will
>>>>>>>>>>> reduce XML-RPC calls and will enable the removal of
>>>>>>>>>>> this
>>>>>>>>>>> syncronous
>>>>>>>>>>> vdsm call from all over the code.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Liron Aravot.
>
> Are you going to expose the config value via engine-config?

Another question -

Not sure i understand the part of

basically a corner case which we can take in order to avoid using locks 
which will affect the whole system and will prevent user initiated 
operations.

What do you mean with "we can take" - do you mean that we can live with 
that?
Why do we want to do that?

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


From mkublin at redhat.com  Mon Nov 19 13:44:41 2012
From: mkublin at redhat.com (Michael Kublin)
Date: Mon, 19 Nov 2012 08:44:41 -0500 (EST)
Subject: [Engine-devel] [Engine-Devel] OvfDataUpdater
In-Reply-To: <1186564003.361332.1353332051329.JavaMail.root@redhat.com>
Message-ID: <1583063962.11158672.1353332681090.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Liron Aravot" <laravot at redhat.com>
> To: "Michael Kublin" <mkublin at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Monday, November 19, 2012 3:34:11 PM
> Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> 
> 
> 
> ----- Original Message -----
> > From: "Michael Kublin" <mkublin at redhat.com>
> > To: "Liron Aravot" <laravot at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Monday, November 19, 2012 3:28:06 PM
> > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Liron Aravot" <laravot at redhat.com>
> > > To: "Michael Kublin" <mkublin at redhat.com>
> > > Cc: engine-devel at ovirt.org
> > > Sent: Monday, November 19, 2012 3:17:04 PM
> > > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Michael Kublin" <mkublin at redhat.com>
> > > > To: "Liron Aravot" <laravot at redhat.com>
> > > > Cc: engine-devel at ovirt.org
> > > > Sent: Monday, November 19, 2012 3:03:23 PM
> > > > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Liron Aravot" <laravot at redhat.com>
> > > > > To: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > Cc: engine-devel at ovirt.org, "Michael Kublin"
> > > > > <mkublin at redhat.com>
> > > > > Sent: Monday, November 19, 2012 2:52:56 PM
> > > > > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > > To: "Liron Aravot" <laravot at redhat.com>
> > > > > > Cc: engine-devel at ovirt.org, "Michael Kublin"
> > > > > > <mkublin at redhat.com>
> > > > > > Sent: Monday, November 19, 2012 2:44:56 PM
> > > > > > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Liron Aravot" <laravot at redhat.com>
> > > > > > > > To: engine-devel at ovirt.org
> > > > > > > > Sent: Monday, November 19, 2012 2:03:57 PM
> > > > > > > > Subject: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > > > > > > > 
> > > > > > > > starting a new discussion thread.
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > > > > > To: "Liron Aravot" <laravot at redhat.com>
> > > > > > > > > Sent: Monday, November 19, 2012 12:42:10 PM
> > > > > > > > > Subject: Re: [Engine-devel]  OvfAutoUpdater
> > > > > > > > > 
> > > > > > > > > I think 'version' is a more standard term for the
> > > > > > > > > column
> > > > > > > > > names.
> > > > > > > > > 
> > > > > > > > > Also in:  4. If succesfull - for each vm update the
> > > > > > > > > ovf_generation
> > > > > > > > > to
> > > > > > > > > equal the db_generation.
> > > > > > > > > I think you mean that the update should be to the
> > > > > > > > > entity
> > > > > > > > > version
> > > > > > > > > you
> > > > > > > > > initially selected.
> > > > > > > > > 
> > > > > > > 1. I think should be version = version +1;
> > > > > the version will be the db_generation that was loaded when we
> > > > > loaded
> > > > > the vm/template.
> > > > > for example - if the vm/template was updated twice between
> > > > > OvfUpdater
> > > > > runs, we will need to increment twice - so incrementing by
> > > > > one
> > > > > will
> > > > > cause another unneeded ovf update for that vm.
> > > > I am talking about ovfVersion or how you called it.
> > > me too,
> > > if we update the vm three times between OvfAutoUpdater runs , we
> > > will
> > > have the following values in the loaded vm for example:
> > > db_generation 8
> > > ovf_generation 5
> > > 
> > > when we perform the ovf update , ovf_generation should be set to
> > > 8
> > > and not to 6, as version '8' is the version that we wrote the ovf
> > > metadata of.
> > These should be written in wiki, with remarks that values which
> > were
> > retrieved
> > from DB together.
> > > > > > > 2. Now the quartz is automatic process, updateVmInSpm it
> > > > > > > is
> > > > > > > spm
> > > > > > > operation -it means it can trigger a reconstruct
> > > > > > > and spm election.
> > > > > 2. updateVmInSpm command would be changed so it won't trigger
> > > > > failover, will add that to the wiki.
> > > > > > > 3. How your solution is handling a case of
> > > > > > > hotPlug/hotUnplug/remove/add of vm disks. vm_static is
> > > > > > > not
> > > > > > > usually
> > > > > > > updated.
> > > > > Whenever will be a command that locks a vm/template, you will
> > > > > have
> > > > > an
> > > > > option during the unlock to specify if the version need to be
> > > > > incremented, you'll be able to increment it also yourself.
> > > > > The HotUnPlug command does lock the vm and during
> > > > > endSuccesfully
> > > > > attempt to update the vm in spm, so it will increment the
> > > > > db_version/generation instead.
> > > > > > 
> > > > addDisk, removeDisk, hotPlug/unPlug not locking a vm.
> > > > Also, as far as I know LockVm/UnLockVm it is operation on
> > > > vm_dynamic
> > > > and not
> > > > vm_static.
> > > 
> > > hotplug acquires memory lock on the vm and has no async tasks if
> > > I
> > > recall correctly.
> > Yes, correct and what? These what I said, vm_static is not updated.
> you will just call the dao method for incrementing the db_generation,
> you don't have to perform vm_static update.
> > > adddisk acquires shared lock on the vm which is problematic with
> > > today flow as well - as you have a race during updateVmInSpm, it
> > > should be fixed regardless of the OvfAutoUpdater.
> > It is not answer on my question. How ovf will be updated? How you
> > understand
> > that ovf of vm should be updated?
> 
> the ovf will be updated when you increment the db_generation value
> instead of calling updateVmInSpm().
> you will be able to do that from the dao directly when you want, or
> when you unlock a vm/template.
> when you will update the db_generation, the vm/template would be
> picked up by OvfUpdater as it's db_generation is different than its
> ovf_generation.
1. Update of ovfs is not related to locks and it should not be, I don't understand why
you link them.
2. Races - your automatic process and couple of add disk commands. You will miss update
of ovf.
3. Also when you will add increase of generation it is not clear from your design
> > > > 
> > > > > > Also consider snapshots & vNICs which affect the VM state.
> > > > > Whatever affect the vm state and triggers updateVmInSpm today
> > > > > will
> > > > > continue to, it can be added to flows which don't do that
> > > > > today.
> > > > > > 
> > > > > > > 4. Reconstruct/Recovery - updateVmInSpm should be called
> > > > > > > on
> > > > > > > all
> > > > > > > vms,
> > > > > > > no matter if they were updated.
> > > > > 
> > > > > Ofcourse, it's being taken care of.
> > > > How?
> > > we don't have ovf's of the vms when we reconstruct as we don't
> > > have
> > > master domain - so we should set the ovf_generation of the vms to
> > > be
> > > 0 - which will cause ovfautoupdater to copy the vm metadata.
> > I did not understand that statement and how it is related.
> OvfAutoUpdater will get those vms for update as db_generation is
> different than ovf_generation.
> > > a performance improvement may be introduced later on in case of
> > > wrong
> > > master version, but that's not related to the ovfautoupdater.
> > I don't understand connection to performance.
> > Now you are replacing a calls to VmCommand.updateVmInSpm() one of
> > them it
> > is at reconstruct flow, and you should handle it also and add it to
> > wiki.
> answered below, OvfAutoUpdater will get those vms for update as
At reconstruct all vms are updated. So it is not related to generation.
How you handle these case?
> db_generation is different than ovf_generation.
> > > > > > > 
> > > > > > > > > Regards,
> > > > > > > > > Mike
> > > > > > > > > 
> > > > > > > > > ----- Original Message -----
> > > > > > > > > > http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater
> > > > > > > > > > 
> > > > > > > > > > Hi all, i'll be glad if you could review the wiki
> > > > > > > > > > page
> > > > > > > > > > of
> > > > > > > > > > OvfAutoUpdater, if you have any suggestions or
> > > > > > > > > > ideas
> > > > > > > > > > please
> > > > > > > > > > let
> > > > > > > > > > me
> > > > > > > > > > know.
> > > > > > > > > > 
> > > > > > > > > > http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater
> > > > > > > > > > 
> > > > > > > > > > short preview from the wiki:
> > > > > > > > > > vm/template configurations (including disks info)
> > > > > > > > > > are
> > > > > > > > > > stored
> > > > > > > > > > on
> > > > > > > > > > the
> > > > > > > > > > master storage domain for backup purposes,
> > > > > > > > > > import/export
> > > > > > > > > > and
> > > > > > > > > > also
> > > > > > > > > > to
> > > > > > > > > > provide the abillity to run VMs without having a
> > > > > > > > > > running
> > > > > > > > > > engine/db.
> > > > > > > > > > Currently ovf update is done synchronously when
> > > > > > > > > > performing
> > > > > > > > > > various
> > > > > > > > > > operations on vms/templates - update, save,
> > > > > > > > > > adding/removing
> > > > > > > > > > a
> > > > > > > > > > disk,
> > > > > > > > > > etc. What's more, currently updating the ovf
> > > > > > > > > > (updateVM
> > > > > > > > > > vdsm
> > > > > > > > > > call)
> > > > > > > > > > is
> > > > > > > > > > usually done within a transcation.
> > > > > > > > > > 
> > > > > > > > > > The idea behined OvfAutoUpdater is to perform batch
> > > > > > > > > > ovf
> > > > > > > > > > update
> > > > > > > > > > operations that aggregate all outstanding updates
> > > > > > > > > > per
> > > > > > > > > > data
> > > > > > > > > > center.
> > > > > > > > > > These updates will be done in specifed time
> > > > > > > > > > intervals
> > > > > > > > > > which
> > > > > > > > > > will
> > > > > > > > > > reduce XML-RPC calls and will enable the removal of
> > > > > > > > > > this
> > > > > > > > > > syncronous
> > > > > > > > > > vdsm call from all over the code.
> > > > > > > > > > 
> > > > > > > > > > Thanks,
> > > > > > > > > > Liron Aravot.
> > > > > > > > > > _______________________________________________
> > > > > > > > > > Engine-devel mailing list
> > > > > > > > > > Engine-devel at ovirt.org
> > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > _______________________________________________
> > > > > > > > Engine-devel mailing list
> > > > > > > > Engine-devel at ovirt.org
> > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > 
> > > > > > > _______________________________________________
> > > > > > > Engine-devel mailing list
> > > > > > > Engine-devel at ovirt.org
> > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 


From laravot at redhat.com  Mon Nov 19 13:58:55 2012
From: laravot at redhat.com (Liron Aravot)
Date: Mon, 19 Nov 2012 08:58:55 -0500 (EST)
Subject: [Engine-devel] [Engine-Devel] OvfDataUpdater
In-Reply-To: <1583063962.11158672.1353332681090.JavaMail.root@redhat.com>
Message-ID: <561519766.368763.1353333535864.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Kublin" <mkublin at redhat.com>
> To: "Liron Aravot" <laravot at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Monday, November 19, 2012 3:44:41 PM
> Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> 
> 
> 
> ----- Original Message -----
> > From: "Liron Aravot" <laravot at redhat.com>
> > To: "Michael Kublin" <mkublin at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Monday, November 19, 2012 3:34:11 PM
> > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Michael Kublin" <mkublin at redhat.com>
> > > To: "Liron Aravot" <laravot at redhat.com>
> > > Cc: engine-devel at ovirt.org
> > > Sent: Monday, November 19, 2012 3:28:06 PM
> > > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Liron Aravot" <laravot at redhat.com>
> > > > To: "Michael Kublin" <mkublin at redhat.com>
> > > > Cc: engine-devel at ovirt.org
> > > > Sent: Monday, November 19, 2012 3:17:04 PM
> > > > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Michael Kublin" <mkublin at redhat.com>
> > > > > To: "Liron Aravot" <laravot at redhat.com>
> > > > > Cc: engine-devel at ovirt.org
> > > > > Sent: Monday, November 19, 2012 3:03:23 PM
> > > > > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Liron Aravot" <laravot at redhat.com>
> > > > > > To: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > > Cc: engine-devel at ovirt.org, "Michael Kublin"
> > > > > > <mkublin at redhat.com>
> > > > > > Sent: Monday, November 19, 2012 2:52:56 PM
> > > > > > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > > > To: "Liron Aravot" <laravot at redhat.com>
> > > > > > > Cc: engine-devel at ovirt.org, "Michael Kublin"
> > > > > > > <mkublin at redhat.com>
> > > > > > > Sent: Monday, November 19, 2012 2:44:56 PM
> > > > > > > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Liron Aravot" <laravot at redhat.com>
> > > > > > > > > To: engine-devel at ovirt.org
> > > > > > > > > Sent: Monday, November 19, 2012 2:03:57 PM
> > > > > > > > > Subject: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > > > > > > > > 
> > > > > > > > > starting a new discussion thread.
> > > > > > > > > 
> > > > > > > > > ----- Original Message -----
> > > > > > > > > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > > > > > > To: "Liron Aravot" <laravot at redhat.com>
> > > > > > > > > > Sent: Monday, November 19, 2012 12:42:10 PM
> > > > > > > > > > Subject: Re: [Engine-devel]  OvfAutoUpdater
> > > > > > > > > > 
> > > > > > > > > > I think 'version' is a more standard term for the
> > > > > > > > > > column
> > > > > > > > > > names.
> > > > > > > > > > 
> > > > > > > > > > Also in:  4. If succesfull - for each vm update the
> > > > > > > > > > ovf_generation
> > > > > > > > > > to
> > > > > > > > > > equal the db_generation.
> > > > > > > > > > I think you mean that the update should be to the
> > > > > > > > > > entity
> > > > > > > > > > version
> > > > > > > > > > you
> > > > > > > > > > initially selected.
> > > > > > > > > > 
> > > > > > > > 1. I think should be version = version +1;
> > > > > > the version will be the db_generation that was loaded when
> > > > > > we
> > > > > > loaded
> > > > > > the vm/template.
> > > > > > for example - if the vm/template was updated twice between
> > > > > > OvfUpdater
> > > > > > runs, we will need to increment twice - so incrementing by
> > > > > > one
> > > > > > will
> > > > > > cause another unneeded ovf update for that vm.
> > > > > I am talking about ovfVersion or how you called it.
> > > > me too,
> > > > if we update the vm three times between OvfAutoUpdater runs ,
> > > > we
> > > > will
> > > > have the following values in the loaded vm for example:
> > > > db_generation 8
> > > > ovf_generation 5
> > > > 
> > > > when we perform the ovf update , ovf_generation should be set
> > > > to
> > > > 8
> > > > and not to 6, as version '8' is the version that we wrote the
> > > > ovf
> > > > metadata of.
> > > These should be written in wiki, with remarks that values which
> > > were
> > > retrieved
> > > from DB together.
> > > > > > > > 2. Now the quartz is automatic process, updateVmInSpm
> > > > > > > > it
> > > > > > > > is
> > > > > > > > spm
> > > > > > > > operation -it means it can trigger a reconstruct
> > > > > > > > and spm election.
> > > > > > 2. updateVmInSpm command would be changed so it won't
> > > > > > trigger
> > > > > > failover, will add that to the wiki.
> > > > > > > > 3. How your solution is handling a case of
> > > > > > > > hotPlug/hotUnplug/remove/add of vm disks. vm_static is
> > > > > > > > not
> > > > > > > > usually
> > > > > > > > updated.
> > > > > > Whenever will be a command that locks a vm/template, you
> > > > > > will
> > > > > > have
> > > > > > an
> > > > > > option during the unlock to specify if the version need to
> > > > > > be
> > > > > > incremented, you'll be able to increment it also yourself.
> > > > > > The HotUnPlug command does lock the vm and during
> > > > > > endSuccesfully
> > > > > > attempt to update the vm in spm, so it will increment the
> > > > > > db_version/generation instead.
> > > > > > > 
> > > > > addDisk, removeDisk, hotPlug/unPlug not locking a vm.
> > > > > Also, as far as I know LockVm/UnLockVm it is operation on
> > > > > vm_dynamic
> > > > > and not
> > > > > vm_static.
> > > > 
> > > > hotplug acquires memory lock on the vm and has no async tasks
> > > > if
> > > > I
> > > > recall correctly.
> > > Yes, correct and what? These what I said, vm_static is not
> > > updated.
> > you will just call the dao method for incrementing the
> > db_generation,
> > you don't have to perform vm_static update.
> > > > adddisk acquires shared lock on the vm which is problematic
> > > > with
> > > > today flow as well - as you have a race during updateVmInSpm,
> > > > it
> > > > should be fixed regardless of the OvfAutoUpdater.
> > > It is not answer on my question. How ovf will be updated? How you
> > > understand
> > > that ovf of vm should be updated?
> > 
> > the ovf will be updated when you increment the db_generation value
> > instead of calling updateVmInSpm().
> > you will be able to do that from the dao directly when you want, or
> > when you unlock a vm/template.
> > when you will update the db_generation, the vm/template would be
> > picked up by OvfUpdater as it's db_generation is different than its
> > ovf_generation.
> 1. Update of ovfs is not related to locks and it should not be, I
> don't understand why
> you link them.
> 2. Races - your automatic process and couple of add disk commands.
> You will miss update
> of ovf.
> 3. Also when you will add increase of generation it is not clear from
> your design

1+2 The OvfAutoUpdater is not related and doesn't acquire any locks.

as of today, if you call updateVmInSpm without performing the operations with lock on the vm you'll have a race - for example, in addDisk (shared calls, two updateVmInSpm might be executed in the same time and you can't know with with ovf you'll end).

therefore, when updating the ovf_generation you should have a lock somewhere otherwise you might miss updates because of races.
if today updatevminspm is called without locks and have races, it needs to be fixed unrelated to it.

3. you will increase the generation whenever you made updateVmInSpm.
> > > > > 
> > > > > > > Also consider snapshots & vNICs which affect the VM
> > > > > > > state.
> > > > > > Whatever affect the vm state and triggers updateVmInSpm
> > > > > > today
> > > > > > will
> > > > > > continue to, it can be added to flows which don't do that
> > > > > > today.
> > > > > > > 
> > > > > > > > 4. Reconstruct/Recovery - updateVmInSpm should be
> > > > > > > > called
> > > > > > > > on
> > > > > > > > all
> > > > > > > > vms,
> > > > > > > > no matter if they were updated.
> > > > > > 
> > > > > > Ofcourse, it's being taken care of.
> > > > > How?
> > > > we don't have ovf's of the vms when we reconstruct as we don't
> > > > have
> > > > master domain - so we should set the ovf_generation of the vms
> > > > to
> > > > be
> > > > 0 - which will cause ovfautoupdater to copy the vm metadata.
> > > I did not understand that statement and how it is related.
> > OvfAutoUpdater will get those vms for update as db_generation is
> > different than ovf_generation.
> > > > a performance improvement may be introduced later on in case of
> > > > wrong
> > > > master version, but that's not related to the ovfautoupdater.
> > > I don't understand connection to performance.
> > > Now you are replacing a calls to VmCommand.updateVmInSpm() one of
> > > them it
> > > is at reconstruct flow, and you should handle it also and add it
> > > to
> > > wiki.
> > answered below, OvfAutoUpdater will get those vms for update as
> At reconstruct all vms are updated. So it is not related to
> generation.
> How you handle these case?

when doing reconstruct, the ovf_generation of all vms is set to 0 as we don't have them on the master domain.
ovfupdater will get this vms for update as ovf_generation < db_generation, will copy the vm ovf and set db_genertion to ovf_generation.

> > db_generation is different than ovf_generation.
> > > > > > > > 
> > > > > > > > > > Regards,
> > > > > > > > > > Mike
> > > > > > > > > > 
> > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater
> > > > > > > > > > > 
> > > > > > > > > > > Hi all, i'll be glad if you could review the wiki
> > > > > > > > > > > page
> > > > > > > > > > > of
> > > > > > > > > > > OvfAutoUpdater, if you have any suggestions or
> > > > > > > > > > > ideas
> > > > > > > > > > > please
> > > > > > > > > > > let
> > > > > > > > > > > me
> > > > > > > > > > > know.
> > > > > > > > > > > 
> > > > > > > > > > > http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater
> > > > > > > > > > > 
> > > > > > > > > > > short preview from the wiki:
> > > > > > > > > > > vm/template configurations (including disks info)
> > > > > > > > > > > are
> > > > > > > > > > > stored
> > > > > > > > > > > on
> > > > > > > > > > > the
> > > > > > > > > > > master storage domain for backup purposes,
> > > > > > > > > > > import/export
> > > > > > > > > > > and
> > > > > > > > > > > also
> > > > > > > > > > > to
> > > > > > > > > > > provide the abillity to run VMs without having a
> > > > > > > > > > > running
> > > > > > > > > > > engine/db.
> > > > > > > > > > > Currently ovf update is done synchronously when
> > > > > > > > > > > performing
> > > > > > > > > > > various
> > > > > > > > > > > operations on vms/templates - update, save,
> > > > > > > > > > > adding/removing
> > > > > > > > > > > a
> > > > > > > > > > > disk,
> > > > > > > > > > > etc. What's more, currently updating the ovf
> > > > > > > > > > > (updateVM
> > > > > > > > > > > vdsm
> > > > > > > > > > > call)
> > > > > > > > > > > is
> > > > > > > > > > > usually done within a transcation.
> > > > > > > > > > > 
> > > > > > > > > > > The idea behined OvfAutoUpdater is to perform
> > > > > > > > > > > batch
> > > > > > > > > > > ovf
> > > > > > > > > > > update
> > > > > > > > > > > operations that aggregate all outstanding updates
> > > > > > > > > > > per
> > > > > > > > > > > data
> > > > > > > > > > > center.
> > > > > > > > > > > These updates will be done in specifed time
> > > > > > > > > > > intervals
> > > > > > > > > > > which
> > > > > > > > > > > will
> > > > > > > > > > > reduce XML-RPC calls and will enable the removal
> > > > > > > > > > > of
> > > > > > > > > > > this
> > > > > > > > > > > syncronous
> > > > > > > > > > > vdsm call from all over the code.
> > > > > > > > > > > 
> > > > > > > > > > > Thanks,
> > > > > > > > > > > Liron Aravot.
> > > > > > > > > > > _______________________________________________
> > > > > > > > > > > Engine-devel mailing list
> > > > > > > > > > > Engine-devel at ovirt.org
> > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > _______________________________________________
> > > > > > > > > Engine-devel mailing list
> > > > > > > > > Engine-devel at ovirt.org
> > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > > 
> > > > > > > > _______________________________________________
> > > > > > > > Engine-devel mailing list
> > > > > > > > Engine-devel at ovirt.org
> > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 


From justin at dynam.ac  Mon Nov 19 13:59:43 2012
From: justin at dynam.ac (=?utf-8?Q?Justin_Hammond?=)
Date: Mon, 19 Nov 2012 13:59:43 +0000
Subject: [Engine-devel] Atlassian Crowd Support for Ovirt
Message-ID: <zarafa.50aa3b4f.1ca0.741618210ffe7b52@Snoopy>

Hi All,

I've just uploaded to Gerrit a patch that adds atlassian crowd authentication support to oVirt.(http://gerrit.ovirt.org/9324)

?
All the nitty gritty details are in the commit message, but basically this adds a new authentication domain, and when selected sends the authentication request off to a crowd server.

?
We have been using this patch on 3.1 for a while, and I thought its overdue to see if you guys are interested in taking this upstream?

?
There are two areas that I know could use improvements:

1) caching the results from the crowd server, so we don't query for every API request etc.

2) adding proper memberOf support so groups work correctly.

?
Please let me know if you guys are interested in this, and please be gentle on your reviews - I? not a Java Programmer by any means, and probably brought too many C++ traits over here... :)

?
Thanks

?
Justin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121119/9a0eb41c/attachment.html>

From vszocs at redhat.com  Mon Nov 19 14:29:24 2012
From: vszocs at redhat.com (Vojtech Szocs)
Date: Mon, 19 Nov 2012 09:29:24 -0500 (EST)
Subject: [Engine-devel] UI plugins crash course (for plugin developers)
In-Reply-To: <288289482.7271048.1353327709415.JavaMail.root@redhat.com>
Message-ID: <415793932.7311099.1353335364366.JavaMail.root@redhat.com>

Hi guys,

Oved asked me how to get started with writing UI plugins, and I thought I'd post a quick "crash course" for writing simple UI plugin here.


Level 1 - Plugin basics
=======================

1. Sync with upstream git repository and apply recent UI plugin patches (rev.6 and rev.7)
$ cd <OVIRT_HOME>
$ git fetch && git rebase origin
$ git fetch git://gerrit.ovirt.org/ovirt-engine refs/changes/20/8120/4 && git checkout FETCH_HEAD
$ git fetch git://gerrit.ovirt.org/ovirt-engine refs/changes/50/9250/2 && git checkout FETCH_HEAD

2. Verify your default (machine-specific) Engine configuration - do this if /usr/share/ovirt-engine/conf doesn't exist yet:
$ mkdir -p /usr/share/ovirt-engine/conf
$ cp <OVIRT_HOME>/backend/manager/conf/engine.conf.defaults /usr/share/ovirt-engine/conf/engine.conf.defaults

3. Create plugin descriptor
$ mkdir /usr/share/ovirt-engine/ui-plugins
$ vim /usr/share/ovirt-engine/ui-plugins/hello-ui-world.json

[hello-world.json]
{
  "name": "HelloWorldPlugin",
  "url": "/webadmin/webadmin/plugin/HelloWorldPlugin/start.html",
  "resourcePath": "hello-world-files"
}
[/hello-ui-world.json]

4. Create plugin host page
$ mkdir /usr/share/ovirt-engine/ui-plugins/hello-world-files
$ vim /usr/share/ovirt-engine/ui-plugins/hello-world-files/start.html

[start.html]
<!DOCTYPE html><html><head>
<script type='text/javascript'>
  var api = parent.pluginApi('HelloWorldPlugin');
  api.register({
    UiInit: function() {
      window.alert('Hello World!');
    }
  });
  api.ready();
</script>
</head><body></body></html>
[/start.html]

5. See plugin in action by logging into WebAdmin, you should see following message in Engine log:
... Reading UI plugin descriptor [/usr/share/ovirt-engine/ui-plugins/hello-ui-world.json]


Level 2 - Using plugin API
==========================

6. Add custom main tab that shows content of the given URL

[start.html]
...
api.register({
  UiInit: function() {
    api.addMainTab('Test Tab', 'test-tab', 'http://www.example.com/');
  }
});
...
[/start.html]

7. Update main tab content URL

[start.html]
...
# Anywhere within event handler function code (e.g. UiInit)
api.setMainTabContentUrl('test-tab', 'http://www.another-example.com/');
...
[/start.html]

8. Add custom context-sensitive button to existing main tab

[start.html]
...
api.register({
  UiInit: function() {
    api.addMainTabActionButton('Host', 'Do something with selected host', {
      onClick: function() {
        # arguments[0] is the first selected item
        var hostId = arguments[0].entityId;
        window.alert('Host ID ' + hostId);
      },
      isEnabled: function() {
        # This button is enabled only on single item selection
        return arguments.length == 1;
      }
    });
  }
});
...
[/start.html]

9. Show custom dialog that shows content of the given URL

[start.html]
...
# Anywhere within event handler function code (e.g. UiInit)
api.showDialog('Test Dialog', 'http://www.example.com/', 600, 400);
...
[/start.html]


Level 3 - REST API integration
==============================

10. Get notified upon acquiring new Engine REST API session

[start.html]
...
api.register({
  RestApiSessionAcquired: function(sessionId) {
    window.alert('REST API session ID ' + sessionId);
  }
});
...
[/start.html]


Regards,
Vojtech


From lhh at redhat.com  Mon Nov 19 14:37:17 2012
From: lhh at redhat.com (Lon Hohberger)
Date: Mon, 19 Nov 2012 09:37:17 -0500
Subject: [Engine-devel] [Design for 3.2 RFE] Host Power Management
 Multiple Agent Support
In-Reply-To: <2139386414.11571733.1353186853544.JavaMail.root@redhat.com>
References: <2139386414.11571733.1353186853544.JavaMail.root@redhat.com>
Message-ID: <50AA441D.3070201@redhat.com>

On 11/17/2012 04:14 PM, Eli Mesika wrote:

>> I'll keep looking.
> 
> Thanks Lon
> I had added those questions in the Feature Talk page : http://wiki.ovirt.org/wiki/Talk:HostPMMultipleAgents
> I will discuss those cases with Simon tomorrow and try to answer those questions 
> 

Hi,

Procedural question - is it preferred that I write comments here, or on
the wiki page?

-- Lon



From mkublin at redhat.com  Mon Nov 19 14:48:19 2012
From: mkublin at redhat.com (Michael Kublin)
Date: Mon, 19 Nov 2012 09:48:19 -0500 (EST)
Subject: [Engine-devel] [Engine-Devel] OvfDataUpdater
In-Reply-To: <561519766.368763.1353333535864.JavaMail.root@redhat.com>
Message-ID: <1005670444.11302897.1353336499066.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Liron Aravot" <laravot at redhat.com>
> To: "Michael Kublin" <mkublin at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Monday, November 19, 2012 3:58:55 PM
> Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> 
> 
> 
> ----- Original Message -----
> > From: "Michael Kublin" <mkublin at redhat.com>
> > To: "Liron Aravot" <laravot at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Monday, November 19, 2012 3:44:41 PM
> > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Liron Aravot" <laravot at redhat.com>
> > > To: "Michael Kublin" <mkublin at redhat.com>
> > > Cc: engine-devel at ovirt.org
> > > Sent: Monday, November 19, 2012 3:34:11 PM
> > > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Michael Kublin" <mkublin at redhat.com>
> > > > To: "Liron Aravot" <laravot at redhat.com>
> > > > Cc: engine-devel at ovirt.org
> > > > Sent: Monday, November 19, 2012 3:28:06 PM
> > > > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Liron Aravot" <laravot at redhat.com>
> > > > > To: "Michael Kublin" <mkublin at redhat.com>
> > > > > Cc: engine-devel at ovirt.org
> > > > > Sent: Monday, November 19, 2012 3:17:04 PM
> > > > > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Michael Kublin" <mkublin at redhat.com>
> > > > > > To: "Liron Aravot" <laravot at redhat.com>
> > > > > > Cc: engine-devel at ovirt.org
> > > > > > Sent: Monday, November 19, 2012 3:03:23 PM
> > > > > > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Liron Aravot" <laravot at redhat.com>
> > > > > > > To: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > > > Cc: engine-devel at ovirt.org, "Michael Kublin"
> > > > > > > <mkublin at redhat.com>
> > > > > > > Sent: Monday, November 19, 2012 2:52:56 PM
> > > > > > > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > > > > To: "Liron Aravot" <laravot at redhat.com>
> > > > > > > > Cc: engine-devel at ovirt.org, "Michael Kublin"
> > > > > > > > <mkublin at redhat.com>
> > > > > > > > Sent: Monday, November 19, 2012 2:44:56 PM
> > > > > > > > Subject: Re: [Engine-devel] [Engine-Devel]
> > > > > > > > OvfDataUpdater
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > ----- Original Message -----
> > > > > > > > > > From: "Liron Aravot" <laravot at redhat.com>
> > > > > > > > > > To: engine-devel at ovirt.org
> > > > > > > > > > Sent: Monday, November 19, 2012 2:03:57 PM
> > > > > > > > > > Subject: [Engine-devel] [Engine-Devel]
> > > > > > > > > > OvfDataUpdater
> > > > > > > > > > 
> > > > > > > > > > starting a new discussion thread.
> > > > > > > > > > 
> > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > > > > > > > To: "Liron Aravot" <laravot at redhat.com>
> > > > > > > > > > > Sent: Monday, November 19, 2012 12:42:10 PM
> > > > > > > > > > > Subject: Re: [Engine-devel]  OvfAutoUpdater
> > > > > > > > > > > 
> > > > > > > > > > > I think 'version' is a more standard term for the
> > > > > > > > > > > column
> > > > > > > > > > > names.
> > > > > > > > > > > 
> > > > > > > > > > > Also in:  4. If succesfull - for each vm update
> > > > > > > > > > > the
> > > > > > > > > > > ovf_generation
> > > > > > > > > > > to
> > > > > > > > > > > equal the db_generation.
> > > > > > > > > > > I think you mean that the update should be to the
> > > > > > > > > > > entity
> > > > > > > > > > > version
> > > > > > > > > > > you
> > > > > > > > > > > initially selected.
> > > > > > > > > > > 
> > > > > > > > > 1. I think should be version = version +1;
> > > > > > > the version will be the db_generation that was loaded
> > > > > > > when
> > > > > > > we
> > > > > > > loaded
> > > > > > > the vm/template.
> > > > > > > for example - if the vm/template was updated twice
> > > > > > > between
> > > > > > > OvfUpdater
> > > > > > > runs, we will need to increment twice - so incrementing
> > > > > > > by
> > > > > > > one
> > > > > > > will
> > > > > > > cause another unneeded ovf update for that vm.
> > > > > > I am talking about ovfVersion or how you called it.
> > > > > me too,
> > > > > if we update the vm three times between OvfAutoUpdater runs ,
> > > > > we
> > > > > will
> > > > > have the following values in the loaded vm for example:
> > > > > db_generation 8
> > > > > ovf_generation 5
> > > > > 
> > > > > when we perform the ovf update , ovf_generation should be set
> > > > > to
> > > > > 8
> > > > > and not to 6, as version '8' is the version that we wrote the
> > > > > ovf
> > > > > metadata of.
> > > > These should be written in wiki, with remarks that values which
> > > > were
> > > > retrieved
> > > > from DB together.
> > > > > > > > > 2. Now the quartz is automatic process, updateVmInSpm
> > > > > > > > > it
> > > > > > > > > is
> > > > > > > > > spm
> > > > > > > > > operation -it means it can trigger a reconstruct
> > > > > > > > > and spm election.
> > > > > > > 2. updateVmInSpm command would be changed so it won't
> > > > > > > trigger
> > > > > > > failover, will add that to the wiki.
> > > > > > > > > 3. How your solution is handling a case of
> > > > > > > > > hotPlug/hotUnplug/remove/add of vm disks. vm_static
> > > > > > > > > is
> > > > > > > > > not
> > > > > > > > > usually
> > > > > > > > > updated.
> > > > > > > Whenever will be a command that locks a vm/template, you
> > > > > > > will
> > > > > > > have
> > > > > > > an
> > > > > > > option during the unlock to specify if the version need
> > > > > > > to
> > > > > > > be
> > > > > > > incremented, you'll be able to increment it also
> > > > > > > yourself.
> > > > > > > The HotUnPlug command does lock the vm and during
> > > > > > > endSuccesfully
> > > > > > > attempt to update the vm in spm, so it will increment the
> > > > > > > db_version/generation instead.
> > > > > > > > 
> > > > > > addDisk, removeDisk, hotPlug/unPlug not locking a vm.
> > > > > > Also, as far as I know LockVm/UnLockVm it is operation on
> > > > > > vm_dynamic
> > > > > > and not
> > > > > > vm_static.
> > > > > 
> > > > > hotplug acquires memory lock on the vm and has no async tasks
> > > > > if
> > > > > I
> > > > > recall correctly.
> > > > Yes, correct and what? These what I said, vm_static is not
> > > > updated.
> > > you will just call the dao method for incrementing the
> > > db_generation,
> > > you don't have to perform vm_static update.
> > > > > adddisk acquires shared lock on the vm which is problematic
> > > > > with
> > > > > today flow as well - as you have a race during updateVmInSpm,
> > > > > it
> > > > > should be fixed regardless of the OvfAutoUpdater.
> > > > It is not answer on my question. How ovf will be updated? How
> > > > you
> > > > understand
> > > > that ovf of vm should be updated?
> > > 
> > > the ovf will be updated when you increment the db_generation
> > > value
> > > instead of calling updateVmInSpm().
> > > you will be able to do that from the dao directly when you want,
> > > or
> > > when you unlock a vm/template.
> > > when you will update the db_generation, the vm/template would be
> > > picked up by OvfUpdater as it's db_generation is different than
> > > its
> > > ovf_generation.
> > 1. Update of ovfs is not related to locks and it should not be, I
> > don't understand why
> > you link them.
> > 2. Races - your automatic process and couple of add disk commands.
> > You will miss update
> > of ovf.
> > 3. Also when you will add increase of generation it is not clear
> > from
> > your design
> 
> 1+2 The OvfAutoUpdater is not related and doesn't acquire any locks.
> 
> as of today, if you call updateVmInSpm without performing the
> operations with lock on the vm you'll have a race - for example, in
Liron, updateVmInSpm is called at endSuccessfully, you can not build on locks,
especially on in memory locks.
> addDisk (shared calls, two updateVmInSpm might be executed in the
> same time and you can't know with with ovf you'll end).
> 
> therefore, when updating the ovf_generation you should have a lock
> somewhere otherwise you might miss updates because of races.
> if today updatevminspm is called without locks and have races, it
> needs to be fixed unrelated to it.
Liron, you should fix these. These is a new development, it should fix 
all known bugs and problems and not introduce a new ones

> 3. you will increase the generation whenever you made updateVmInSpm.
> > > > > > 
> > > > > > > > Also consider snapshots & vNICs which affect the VM
> > > > > > > > state.
> > > > > > > Whatever affect the vm state and triggers updateVmInSpm
> > > > > > > today
> > > > > > > will
> > > > > > > continue to, it can be added to flows which don't do that
> > > > > > > today.
> > > > > > > > 
> > > > > > > > > 4. Reconstruct/Recovery - updateVmInSpm should be
> > > > > > > > > called
> > > > > > > > > on
> > > > > > > > > all
> > > > > > > > > vms,
> > > > > > > > > no matter if they were updated.
> > > > > > > 
> > > > > > > Ofcourse, it's being taken care of.
> > > > > > How?
> > > > > we don't have ovf's of the vms when we reconstruct as we
> > > > > don't
> > > > > have
> > > > > master domain - so we should set the ovf_generation of the
> > > > > vms
> > > > > to
> > > > > be
> > > > > 0 - which will cause ovfautoupdater to copy the vm metadata.
> > > > I did not understand that statement and how it is related.
> > > OvfAutoUpdater will get those vms for update as db_generation is
> > > different than ovf_generation.
> > > > > a performance improvement may be introduced later on in case
> > > > > of
> > > > > wrong
> > > > > master version, but that's not related to the ovfautoupdater.
> > > > I don't understand connection to performance.
> > > > Now you are replacing a calls to VmCommand.updateVmInSpm() one
> > > > of
> > > > them it
> > > > is at reconstruct flow, and you should handle it also and add
> > > > it
> > > > to
> > > > wiki.
> > > answered below, OvfAutoUpdater will get those vms for update as
> > At reconstruct all vms are updated. So it is not related to
> > generation.
> > How you handle these case?
> 
> when doing reconstruct, the ovf_generation of all vms is set to 0 as
> we don't have them on the master domain.
> ovfupdater will get this vms for update as ovf_generation <
> db_generation, will copy the vm ovf and set db_genertion to
> ovf_generation.
> 
> > > db_generation is different than ovf_generation.
> > > > > > > > > 
> > > > > > > > > > > Regards,
> > > > > > > > > > > Mike
> > > > > > > > > > > 
> > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater
> > > > > > > > > > > > 
> > > > > > > > > > > > Hi all, i'll be glad if you could review the
> > > > > > > > > > > > wiki
> > > > > > > > > > > > page
> > > > > > > > > > > > of
> > > > > > > > > > > > OvfAutoUpdater, if you have any suggestions or
> > > > > > > > > > > > ideas
> > > > > > > > > > > > please
> > > > > > > > > > > > let
> > > > > > > > > > > > me
> > > > > > > > > > > > know.
> > > > > > > > > > > > 
> > > > > > > > > > > > http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater
> > > > > > > > > > > > 
> > > > > > > > > > > > short preview from the wiki:
> > > > > > > > > > > > vm/template configurations (including disks
> > > > > > > > > > > > info)
> > > > > > > > > > > > are
> > > > > > > > > > > > stored
> > > > > > > > > > > > on
> > > > > > > > > > > > the
> > > > > > > > > > > > master storage domain for backup purposes,
> > > > > > > > > > > > import/export
> > > > > > > > > > > > and
> > > > > > > > > > > > also
> > > > > > > > > > > > to
> > > > > > > > > > > > provide the abillity to run VMs without having
> > > > > > > > > > > > a
> > > > > > > > > > > > running
> > > > > > > > > > > > engine/db.
> > > > > > > > > > > > Currently ovf update is done synchronously when
> > > > > > > > > > > > performing
> > > > > > > > > > > > various
> > > > > > > > > > > > operations on vms/templates - update, save,
> > > > > > > > > > > > adding/removing
> > > > > > > > > > > > a
> > > > > > > > > > > > disk,
> > > > > > > > > > > > etc. What's more, currently updating the ovf
> > > > > > > > > > > > (updateVM
> > > > > > > > > > > > vdsm
> > > > > > > > > > > > call)
> > > > > > > > > > > > is
> > > > > > > > > > > > usually done within a transcation.
> > > > > > > > > > > > 
> > > > > > > > > > > > The idea behined OvfAutoUpdater is to perform
> > > > > > > > > > > > batch
> > > > > > > > > > > > ovf
> > > > > > > > > > > > update
> > > > > > > > > > > > operations that aggregate all outstanding
> > > > > > > > > > > > updates
> > > > > > > > > > > > per
> > > > > > > > > > > > data
> > > > > > > > > > > > center.
> > > > > > > > > > > > These updates will be done in specifed time
> > > > > > > > > > > > intervals
> > > > > > > > > > > > which
> > > > > > > > > > > > will
> > > > > > > > > > > > reduce XML-RPC calls and will enable the
> > > > > > > > > > > > removal
> > > > > > > > > > > > of
> > > > > > > > > > > > this
> > > > > > > > > > > > syncronous
> > > > > > > > > > > > vdsm call from all over the code.
> > > > > > > > > > > > 
> > > > > > > > > > > > Thanks,
> > > > > > > > > > > > Liron Aravot.
> > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > Engine-devel mailing list
> > > > > > > > > > > > Engine-devel at ovirt.org
> > > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > _______________________________________________
> > > > > > > > > > Engine-devel mailing list
> > > > > > > > > > Engine-devel at ovirt.org
> > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > > > 
> > > > > > > > > _______________________________________________
> > > > > > > > > Engine-devel mailing list
> > > > > > > > > Engine-devel at ovirt.org
> > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 


From vszocs at redhat.com  Mon Nov 19 14:49:38 2012
From: vszocs at redhat.com (Vojtech Szocs)
Date: Mon, 19 Nov 2012 09:49:38 -0500 (EST)
Subject: [Engine-devel] UI plugins crash course part two (for plugin
	developers)
In-Reply-To: <415793932.7311099.1353335364366.JavaMail.root@redhat.com>
Message-ID: <670870582.7319531.1353336578842.JavaMail.root@redhat.com>

Hi guys,

this is a follow-up on the quick "crash course" for writing simple UI plugin.

Before we proceed, please keep in mind that:
- api.register() must be called exactly once, subsequent calls "overwrite" previous ones
- api.register() must be called before api.ready(), otherwise your plugin will not work
- you don't have to define all supported event handler functions in api.register(), just the ones your plugin is interested in (e.g. UiInit)


Level 4 - Let's make things configurable
========================================

1. Specify default plugin configuration (optional)
$ vim /usr/share/ovirt-engine/ui-plugins/hello-ui-world.json

[hello-ui-world.json]
...
  "config": { "testLink": "http://www.example.com/" }
...
[/hello-ui-world.json]

2. Override default plugin configuration (optional)
$ mkdir -p /etc/ovirt-engine/ui-plugins
$ vim /etc/ovirt-engine/ui-plugins/hello-ui-world-config.json

[hello-ui-world-config.json]
{
  "config": { "testLink": "http://www.another-example.com/" }
}
[/hello-ui-world-config.json]

3. Use plugin configuration that has been merged together
$ vim /usr/share/ovirt-engine/ui-plugins/hello-world-files/start.html

[start.html]
...
# Anywhere within event handler function code (e.g. UiInit)
var conf = api.configObject();
api.showDialog('Test Dialog', conf.testLink, 600, 400);
...
[/start.html]


Regards,
Vojtech



From Christopher.Morrissey at netapp.com  Mon Nov 19 14:50:34 2012
From: Christopher.Morrissey at netapp.com (Morrissey, Christopher)
Date: Mon, 19 Nov 2012 14:50:34 +0000
Subject: [Engine-devel] Design review summary for 3.2 - adding support
 for	External Events
In-Reply-To: <1316996516.11916636.1353327849211.JavaMail.root@redhat.com>
References: <1316996516.11916636.1353327849211.JavaMail.root@redhat.com>
Message-ID: <D290AD8432118048947689BA3AE8A9B3EBCA1D@SACEXCMBX04-PRD.hq.netapp.com>

Hi Eli,

I've perused the design and it looks very good for the purpose of adding events to the log as back end tasks on the NetApp VSC are started and complete.

I do have one question. As part of the new UI plugin framework that Vojtech is working on he added the capability to retrieve a session ID that will be used outside of the oVirt engine to invoke REST API calls. I'm assuming this session would have the same role as the user that is currently logged in. 

According to the event log design, only the Super user will have permissions to add events by default. This would mean that if anyone other than the super user is logged in and performing any tasks through the NetApp plugin, the server side of the VSC will likely not be able to log events. This could be confusing for users as sometimes they see events showing up giving them information on the task progress and sometimes they don't depending on the role logged in.

Would it make sense to allow all roles to log events by default? I'm not sure what security problems would arise given that it is just a log and they would be tagged as external events.

-Chris


-----Original Message-----
From: engine-devel-bounces at ovirt.org [mailto:engine-devel-bounces at ovirt.org] On Behalf Of Eli Mesika
Sent: Monday, November 19, 2012 7:24 AM
To: engine-devel
Subject: [Engine-devel] Design review summary for 3.2 - adding support for External Events

Discussion : http://wiki.ovirt.org/wiki/Talk:ExternalEvents
Updated Design : http://wiki.ovirt.org/wiki/Features/Design/DetailedExternalEvents#Future_directions
_______________________________________________
Engine-devel mailing list
Engine-devel at ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel


From vszocs at redhat.com  Mon Nov 19 14:58:10 2012
From: vszocs at redhat.com (Vojtech Szocs)
Date: Mon, 19 Nov 2012 09:58:10 -0500 (EST)
Subject: [Engine-devel] Design review summary for 3.2 - adding support
 for	External Events
In-Reply-To: <D290AD8432118048947689BA3AE8A9B3EBCA1D@SACEXCMBX04-PRD.hq.netapp.com>
Message-ID: <1250840940.7324447.1353337090389.JavaMail.root@redhat.com>

Hi Chris,

> As part of the new UI plugin framework that Vojtech is working on he added the capability to retrieve a session ID that will be used outside of the oVirt engine to invoke REST API calls. I'm assuming this session would have the same role as the user that is currently logged in.

This is correct. UI plugin infrastructure acquires Engine REST API session using credentials of the user that logs into WebAdmin UI.

Vojtech


----- Original Message -----
From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
To: "Eli Mesika" <emesika at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
Sent: Monday, November 19, 2012 3:50:34 PM
Subject: Re: [Engine-devel] Design review summary for 3.2 - adding support for	External Events

Hi Eli,

I've perused the design and it looks very good for the purpose of adding events to the log as back end tasks on the NetApp VSC are started and complete.

I do have one question. As part of the new UI plugin framework that Vojtech is working on he added the capability to retrieve a session ID that will be used outside of the oVirt engine to invoke REST API calls. I'm assuming this session would have the same role as the user that is currently logged in. 

According to the event log design, only the Super user will have permissions to add events by default. This would mean that if anyone other than the super user is logged in and performing any tasks through the NetApp plugin, the server side of the VSC will likely not be able to log events. This could be confusing for users as sometimes they see events showing up giving them information on the task progress and sometimes they don't depending on the role logged in.

Would it make sense to allow all roles to log events by default? I'm not sure what security problems would arise given that it is just a log and they would be tagged as external events.

-Chris


-----Original Message-----
From: engine-devel-bounces at ovirt.org [mailto:engine-devel-bounces at ovirt.org] On Behalf Of Eli Mesika
Sent: Monday, November 19, 2012 7:24 AM
To: engine-devel
Subject: [Engine-devel] Design review summary for 3.2 - adding support for External Events

Discussion : http://wiki.ovirt.org/wiki/Talk:ExternalEvents
Updated Design : http://wiki.ovirt.org/wiki/Features/Design/DetailedExternalEvents#Future_directions
_______________________________________________
Engine-devel mailing list
Engine-devel at ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel at ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel


From laravot at redhat.com  Mon Nov 19 15:16:27 2012
From: laravot at redhat.com (Liron Aravot)
Date: Mon, 19 Nov 2012 10:16:27 -0500 (EST)
Subject: [Engine-devel] [Engine-Devel] OvfDataUpdater
In-Reply-To: <1005670444.11302897.1353336499066.JavaMail.root@redhat.com>
Message-ID: <592391294.414711.1353338187483.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Kublin" <mkublin at redhat.com>
> To: "Liron Aravot" <laravot at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Monday, November 19, 2012 4:48:19 PM
> Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> 
> 
> 
> ----- Original Message -----
> > From: "Liron Aravot" <laravot at redhat.com>
> > To: "Michael Kublin" <mkublin at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Monday, November 19, 2012 3:58:55 PM
> > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Michael Kublin" <mkublin at redhat.com>
> > > To: "Liron Aravot" <laravot at redhat.com>
> > > Cc: engine-devel at ovirt.org
> > > Sent: Monday, November 19, 2012 3:44:41 PM
> > > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Liron Aravot" <laravot at redhat.com>
> > > > To: "Michael Kublin" <mkublin at redhat.com>
> > > > Cc: engine-devel at ovirt.org
> > > > Sent: Monday, November 19, 2012 3:34:11 PM
> > > > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Michael Kublin" <mkublin at redhat.com>
> > > > > To: "Liron Aravot" <laravot at redhat.com>
> > > > > Cc: engine-devel at ovirt.org
> > > > > Sent: Monday, November 19, 2012 3:28:06 PM
> > > > > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Liron Aravot" <laravot at redhat.com>
> > > > > > To: "Michael Kublin" <mkublin at redhat.com>
> > > > > > Cc: engine-devel at ovirt.org
> > > > > > Sent: Monday, November 19, 2012 3:17:04 PM
> > > > > > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Michael Kublin" <mkublin at redhat.com>
> > > > > > > To: "Liron Aravot" <laravot at redhat.com>
> > > > > > > Cc: engine-devel at ovirt.org
> > > > > > > Sent: Monday, November 19, 2012 3:03:23 PM
> > > > > > > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Liron Aravot" <laravot at redhat.com>
> > > > > > > > To: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > > > > Cc: engine-devel at ovirt.org, "Michael Kublin"
> > > > > > > > <mkublin at redhat.com>
> > > > > > > > Sent: Monday, November 19, 2012 2:52:56 PM
> > > > > > > > Subject: Re: [Engine-devel] [Engine-Devel]
> > > > > > > > OvfDataUpdater
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > > > > > To: "Liron Aravot" <laravot at redhat.com>
> > > > > > > > > Cc: engine-devel at ovirt.org, "Michael Kublin"
> > > > > > > > > <mkublin at redhat.com>
> > > > > > > > > Sent: Monday, November 19, 2012 2:44:56 PM
> > > > > > > > > Subject: Re: [Engine-devel] [Engine-Devel]
> > > > > > > > > OvfDataUpdater
> > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > From: "Liron Aravot" <laravot at redhat.com>
> > > > > > > > > > > To: engine-devel at ovirt.org
> > > > > > > > > > > Sent: Monday, November 19, 2012 2:03:57 PM
> > > > > > > > > > > Subject: [Engine-devel] [Engine-Devel]
> > > > > > > > > > > OvfDataUpdater
> > > > > > > > > > > 
> > > > > > > > > > > starting a new discussion thread.
> > > > > > > > > > > 
> > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > > > > > > > > To: "Liron Aravot" <laravot at redhat.com>
> > > > > > > > > > > > Sent: Monday, November 19, 2012 12:42:10 PM
> > > > > > > > > > > > Subject: Re: [Engine-devel]  OvfAutoUpdater
> > > > > > > > > > > > 
> > > > > > > > > > > > I think 'version' is a more standard term for
> > > > > > > > > > > > the
> > > > > > > > > > > > column
> > > > > > > > > > > > names.
> > > > > > > > > > > > 
> > > > > > > > > > > > Also in:  4. If succesfull - for each vm update
> > > > > > > > > > > > the
> > > > > > > > > > > > ovf_generation
> > > > > > > > > > > > to
> > > > > > > > > > > > equal the db_generation.
> > > > > > > > > > > > I think you mean that the update should be to
> > > > > > > > > > > > the
> > > > > > > > > > > > entity
> > > > > > > > > > > > version
> > > > > > > > > > > > you
> > > > > > > > > > > > initially selected.
> > > > > > > > > > > > 
> > > > > > > > > > 1. I think should be version = version +1;
> > > > > > > > the version will be the db_generation that was loaded
> > > > > > > > when
> > > > > > > > we
> > > > > > > > loaded
> > > > > > > > the vm/template.
> > > > > > > > for example - if the vm/template was updated twice
> > > > > > > > between
> > > > > > > > OvfUpdater
> > > > > > > > runs, we will need to increment twice - so incrementing
> > > > > > > > by
> > > > > > > > one
> > > > > > > > will
> > > > > > > > cause another unneeded ovf update for that vm.
> > > > > > > I am talking about ovfVersion or how you called it.
> > > > > > me too,
> > > > > > if we update the vm three times between OvfAutoUpdater runs
> > > > > > ,
> > > > > > we
> > > > > > will
> > > > > > have the following values in the loaded vm for example:
> > > > > > db_generation 8
> > > > > > ovf_generation 5
> > > > > > 
> > > > > > when we perform the ovf update , ovf_generation should be
> > > > > > set
> > > > > > to
> > > > > > 8
> > > > > > and not to 6, as version '8' is the version that we wrote
> > > > > > the
> > > > > > ovf
> > > > > > metadata of.
> > > > > These should be written in wiki, with remarks that values
> > > > > which
> > > > > were
> > > > > retrieved
> > > > > from DB together.
> > > > > > > > > > 2. Now the quartz is automatic process,
> > > > > > > > > > updateVmInSpm
> > > > > > > > > > it
> > > > > > > > > > is
> > > > > > > > > > spm
> > > > > > > > > > operation -it means it can trigger a reconstruct
> > > > > > > > > > and spm election.
> > > > > > > > 2. updateVmInSpm command would be changed so it won't
> > > > > > > > trigger
> > > > > > > > failover, will add that to the wiki.
> > > > > > > > > > 3. How your solution is handling a case of
> > > > > > > > > > hotPlug/hotUnplug/remove/add of vm disks. vm_static
> > > > > > > > > > is
> > > > > > > > > > not
> > > > > > > > > > usually
> > > > > > > > > > updated.
> > > > > > > > Whenever will be a command that locks a vm/template,
> > > > > > > > you
> > > > > > > > will
> > > > > > > > have
> > > > > > > > an
> > > > > > > > option during the unlock to specify if the version need
> > > > > > > > to
> > > > > > > > be
> > > > > > > > incremented, you'll be able to increment it also
> > > > > > > > yourself.
> > > > > > > > The HotUnPlug command does lock the vm and during
> > > > > > > > endSuccesfully
> > > > > > > > attempt to update the vm in spm, so it will increment
> > > > > > > > the
> > > > > > > > db_version/generation instead.
> > > > > > > > > 
> > > > > > > addDisk, removeDisk, hotPlug/unPlug not locking a vm.
> > > > > > > Also, as far as I know LockVm/UnLockVm it is operation on
> > > > > > > vm_dynamic
> > > > > > > and not
> > > > > > > vm_static.
> > > > > > 
> > > > > > hotplug acquires memory lock on the vm and has no async
> > > > > > tasks
> > > > > > if
> > > > > > I
> > > > > > recall correctly.
> > > > > Yes, correct and what? These what I said, vm_static is not
> > > > > updated.
> > > > you will just call the dao method for incrementing the
> > > > db_generation,
> > > > you don't have to perform vm_static update.
> > > > > > adddisk acquires shared lock on the vm which is problematic
> > > > > > with
> > > > > > today flow as well - as you have a race during
> > > > > > updateVmInSpm,
> > > > > > it
> > > > > > should be fixed regardless of the OvfAutoUpdater.
> > > > > It is not answer on my question. How ovf will be updated? How
> > > > > you
> > > > > understand
> > > > > that ovf of vm should be updated?
> > > > 
> > > > the ovf will be updated when you increment the db_generation
> > > > value
> > > > instead of calling updateVmInSpm().
> > > > you will be able to do that from the dao directly when you
> > > > want,
> > > > or
> > > > when you unlock a vm/template.
> > > > when you will update the db_generation, the vm/template would
> > > > be
> > > > picked up by OvfUpdater as it's db_generation is different than
> > > > its
> > > > ovf_generation.
> > > 1. Update of ovfs is not related to locks and it should not be, I
> > > don't understand why
> > > you link them.
> > > 2. Races - your automatic process and couple of add disk
> > > commands.

As of today - there is a race.
ovfautoupdater won't introduce nor keep that race as we should have automatic db exclusive row lock when we perform this update, correct me if i'm wrong.

> > > You will miss update
> > > of ovf.
> > > 3. Also when you will add increase of generation it is not clear
> > > from
> > > your design
> > 
> > 1+2 The OvfAutoUpdater is not related and doesn't acquire any
> > locks.
> > 
> > as of today, if you call updateVmInSpm without performing the
> > operations with lock on the vm you'll have a race - for example, in
> Liron, updateVmInSpm is called at endSuccessfully, you can not build
> on locks,
> especially on in memory locks.
> > addDisk (shared calls, two updateVmInSpm might be executed in the
> > same time and you can't know with with ovf you'll end).
> > 
> > therefore, when updating the ovf_generation you should have a lock
> > somewhere otherwise you might miss updates because of races.
> > if today updatevminspm is called without locks and have races, it
> > needs to be fixed unrelated to it.
> Liron, you should fix these. These is a new development, it should
> fix
> all known bugs and problems and not introduce a new ones

answered below, 
As of today - there is a race.
ovfautoupdater won't introduce nor keep that race as we should have automatic db exclusive row lock when we perform this update, correct me if i'm wrong.

> 
> > 3. you will increase the generation whenever you made
> > updateVmInSpm.
> > > > > > > 
> > > > > > > > > Also consider snapshots & vNICs which affect the VM
> > > > > > > > > state.
> > > > > > > > Whatever affect the vm state and triggers updateVmInSpm
> > > > > > > > today
> > > > > > > > will
> > > > > > > > continue to, it can be added to flows which don't do
> > > > > > > > that
> > > > > > > > today.
> > > > > > > > > 
> > > > > > > > > > 4. Reconstruct/Recovery - updateVmInSpm should be
> > > > > > > > > > called
> > > > > > > > > > on
> > > > > > > > > > all
> > > > > > > > > > vms,
> > > > > > > > > > no matter if they were updated.
> > > > > > > > 
> > > > > > > > Ofcourse, it's being taken care of.
> > > > > > > How?
> > > > > > we don't have ovf's of the vms when we reconstruct as we
> > > > > > don't
> > > > > > have
> > > > > > master domain - so we should set the ovf_generation of the
> > > > > > vms
> > > > > > to
> > > > > > be
> > > > > > 0 - which will cause ovfautoupdater to copy the vm
> > > > > > metadata.
> > > > > I did not understand that statement and how it is related.
> > > > OvfAutoUpdater will get those vms for update as db_generation
> > > > is
> > > > different than ovf_generation.
> > > > > > a performance improvement may be introduced later on in
> > > > > > case
> > > > > > of
> > > > > > wrong
> > > > > > master version, but that's not related to the
> > > > > > ovfautoupdater.
> > > > > I don't understand connection to performance.
> > > > > Now you are replacing a calls to VmCommand.updateVmInSpm()
> > > > > one
> > > > > of
> > > > > them it
> > > > > is at reconstruct flow, and you should handle it also and add
> > > > > it
> > > > > to
> > > > > wiki.
> > > > answered below, OvfAutoUpdater will get those vms for update as
> > > At reconstruct all vms are updated. So it is not related to
> > > generation.
> > > How you handle these case?
> > 
> > when doing reconstruct, the ovf_generation of all vms is set to 0
> > as
> > we don't have them on the master domain.
> > ovfupdater will get this vms for update as ovf_generation <
> > db_generation, will copy the vm ovf and set db_genertion to
> > ovf_generation.
> > 
> > > > db_generation is different than ovf_generation.
> > > > > > > > > > 
> > > > > > > > > > > > Regards,
> > > > > > > > > > > > Mike
> > > > > > > > > > > > 
> > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Hi all, i'll be glad if you could review the
> > > > > > > > > > > > > wiki
> > > > > > > > > > > > > page
> > > > > > > > > > > > > of
> > > > > > > > > > > > > OvfAutoUpdater, if you have any suggestions
> > > > > > > > > > > > > or
> > > > > > > > > > > > > ideas
> > > > > > > > > > > > > please
> > > > > > > > > > > > > let
> > > > > > > > > > > > > me
> > > > > > > > > > > > > know.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater
> > > > > > > > > > > > > 
> > > > > > > > > > > > > short preview from the wiki:
> > > > > > > > > > > > > vm/template configurations (including disks
> > > > > > > > > > > > > info)
> > > > > > > > > > > > > are
> > > > > > > > > > > > > stored
> > > > > > > > > > > > > on
> > > > > > > > > > > > > the
> > > > > > > > > > > > > master storage domain for backup purposes,
> > > > > > > > > > > > > import/export
> > > > > > > > > > > > > and
> > > > > > > > > > > > > also
> > > > > > > > > > > > > to
> > > > > > > > > > > > > provide the abillity to run VMs without
> > > > > > > > > > > > > having
> > > > > > > > > > > > > a
> > > > > > > > > > > > > running
> > > > > > > > > > > > > engine/db.
> > > > > > > > > > > > > Currently ovf update is done synchronously
> > > > > > > > > > > > > when
> > > > > > > > > > > > > performing
> > > > > > > > > > > > > various
> > > > > > > > > > > > > operations on vms/templates - update, save,
> > > > > > > > > > > > > adding/removing
> > > > > > > > > > > > > a
> > > > > > > > > > > > > disk,
> > > > > > > > > > > > > etc. What's more, currently updating the ovf
> > > > > > > > > > > > > (updateVM
> > > > > > > > > > > > > vdsm
> > > > > > > > > > > > > call)
> > > > > > > > > > > > > is
> > > > > > > > > > > > > usually done within a transcation.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > The idea behined OvfAutoUpdater is to perform
> > > > > > > > > > > > > batch
> > > > > > > > > > > > > ovf
> > > > > > > > > > > > > update
> > > > > > > > > > > > > operations that aggregate all outstanding
> > > > > > > > > > > > > updates
> > > > > > > > > > > > > per
> > > > > > > > > > > > > data
> > > > > > > > > > > > > center.
> > > > > > > > > > > > > These updates will be done in specifed time
> > > > > > > > > > > > > intervals
> > > > > > > > > > > > > which
> > > > > > > > > > > > > will
> > > > > > > > > > > > > reduce XML-RPC calls and will enable the
> > > > > > > > > > > > > removal
> > > > > > > > > > > > > of
> > > > > > > > > > > > > this
> > > > > > > > > > > > > syncronous
> > > > > > > > > > > > > vdsm call from all over the code.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > Liron Aravot.
> > > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > > Engine-devel mailing list
> > > > > > > > > > > > > Engine-devel at ovirt.org
> > > > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > _______________________________________________
> > > > > > > > > > > Engine-devel mailing list
> > > > > > > > > > > Engine-devel at ovirt.org
> > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > > > > 
> > > > > > > > > > _______________________________________________
> > > > > > > > > > Engine-devel mailing list
> > > > > > > > > > Engine-devel at ovirt.org
> > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 


From iheim at redhat.com  Mon Nov 19 15:54:07 2012
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 19 Nov 2012 17:54:07 +0200
Subject: [Engine-devel] [Design for 3.2 RFE] Host Power Management
 Multiple Agent Support
In-Reply-To: <50AA441D.3070201@redhat.com>
References: <2139386414.11571733.1353186853544.JavaMail.root@redhat.com>
	<50AA441D.3070201@redhat.com>
Message-ID: <50AA561F.5080502@redhat.com>

On 11/19/2012 04:37 PM, Lon Hohberger wrote:
> On 11/17/2012 04:14 PM, Eli Mesika wrote:
>
>>> I'll keep looking.
>>
>> Thanks Lon
>> I had added those questions in the Feature Talk page : http://wiki.ovirt.org/wiki/Talk:HostPMMultipleAgents
>> I will discuss those cases with Simon tomorrow and try to answer those questions
>>
>
> Hi,
>
> Procedural question - is it preferred that I write comments here, or on
> the wiki page?

not sure about others, but i find it easier to track comments on email 
before the conclusion is updated to a wiki




From Chris.Frantz at hp.com  Mon Nov 19 16:03:37 2012
From: Chris.Frantz at hp.com (Frantz, Chris)
Date: Mon, 19 Nov 2012 16:03:37 +0000
Subject: [Engine-devel] Design review summary for 3.2 - adding support
 for	External Events
In-Reply-To: <1316996516.11916636.1353327849211.JavaMail.root@redhat.com>
References: <1316996516.11916636.1353327849211.JavaMail.root@redhat.com>
Message-ID: <A24D665DC3ECC245A2EA0D9A958F80B631C1A4A8@G4W3215.americas.hpqcorp.net>

Eli,

I've reviewed the Detailed Design for External Events.  Overall, the design looks good, but I have a few questions:

1. Can I provide additional data with the event:

AuditLogSeverity = EXTERNAL_EVENT_WARNING
Message = "Enclosure RACK15ENC3: Fan in bay 5 failed"
Vendor = "HP"
CustomEventId = 12345
DataCenterId = "Houston" (I assume this is really the UUID of the data center)
ExtraData = { "enclosure": "RACK15ENC3", "bay": 5, "partnum": "412140-B21", "spare": "413996-001", "model": "Active Cool 200 Fan", "zone": 2}

2. What is the meaning of this statement on the DetailedDesign page:

External Events can not use application variables, therefore no '$' expressions should appear in the Event/Alert free message text

Does this mean the Message has to be fixed text with no substitution variables?  Can I do this:

Message = "Enclosure {ExtraData.enclosure}: Fan in bay {ExtraData.bay} failed.  Replace with {ExtraData.spare}."

3. Considering that the Event has a number of IDs associated with it (UserId, DataCenterId, HostId, VmId, etc), does that mean an event can be associated with multiple entities at once?  "Host X in Cluster Y in Datacenter Z has exceeded the critical temperature threshold.  Shutting down."

How will this be expanded in the future as oVirt Engine becomes aware of more types of entities (enclosures, rack managers, advanced networking switches/fabrics)?  Is it be possible for an event to be associated with multiple hosts?

To return to the fan failure scenario above, if a fan in an enclosure fails, all of the hosts in that fan's fanzone will be effected.

Thanks,
--Chris



From laravot at redhat.com  Mon Nov 19 18:39:06 2012
From: laravot at redhat.com (Liron Aravot)
Date: Mon, 19 Nov 2012 13:39:06 -0500 (EST)
Subject: [Engine-devel] [Engine-Devel] OvfDataUpdater
In-Reply-To: <592391294.414711.1353338187483.JavaMail.root@redhat.com>
Message-ID: <1337223504.462749.1353350346260.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Liron Aravot" <laravot at redhat.com>
> To: "Michael Kublin" <mkublin at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Monday, November 19, 2012 5:16:27 PM
> Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> 
> 
> 
> ----- Original Message -----
> > From: "Michael Kublin" <mkublin at redhat.com>
> > To: "Liron Aravot" <laravot at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Monday, November 19, 2012 4:48:19 PM
> > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Liron Aravot" <laravot at redhat.com>
> > > To: "Michael Kublin" <mkublin at redhat.com>
> > > Cc: engine-devel at ovirt.org
> > > Sent: Monday, November 19, 2012 3:58:55 PM
> > > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Michael Kublin" <mkublin at redhat.com>
> > > > To: "Liron Aravot" <laravot at redhat.com>
> > > > Cc: engine-devel at ovirt.org
> > > > Sent: Monday, November 19, 2012 3:44:41 PM
> > > > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Liron Aravot" <laravot at redhat.com>
> > > > > To: "Michael Kublin" <mkublin at redhat.com>
> > > > > Cc: engine-devel at ovirt.org
> > > > > Sent: Monday, November 19, 2012 3:34:11 PM
> > > > > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Michael Kublin" <mkublin at redhat.com>
> > > > > > To: "Liron Aravot" <laravot at redhat.com>
> > > > > > Cc: engine-devel at ovirt.org
> > > > > > Sent: Monday, November 19, 2012 3:28:06 PM
> > > > > > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Liron Aravot" <laravot at redhat.com>
> > > > > > > To: "Michael Kublin" <mkublin at redhat.com>
> > > > > > > Cc: engine-devel at ovirt.org
> > > > > > > Sent: Monday, November 19, 2012 3:17:04 PM
> > > > > > > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Michael Kublin" <mkublin at redhat.com>
> > > > > > > > To: "Liron Aravot" <laravot at redhat.com>
> > > > > > > > Cc: engine-devel at ovirt.org
> > > > > > > > Sent: Monday, November 19, 2012 3:03:23 PM
> > > > > > > > Subject: Re: [Engine-devel] [Engine-Devel]
> > > > > > > > OvfDataUpdater
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Liron Aravot" <laravot at redhat.com>
> > > > > > > > > To: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > > > > > Cc: engine-devel at ovirt.org, "Michael Kublin"
> > > > > > > > > <mkublin at redhat.com>
> > > > > > > > > Sent: Monday, November 19, 2012 2:52:56 PM
> > > > > > > > > Subject: Re: [Engine-devel] [Engine-Devel]
> > > > > > > > > OvfDataUpdater
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > ----- Original Message -----
> > > > > > > > > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > > > > > > To: "Liron Aravot" <laravot at redhat.com>
> > > > > > > > > > Cc: engine-devel at ovirt.org, "Michael Kublin"
> > > > > > > > > > <mkublin at redhat.com>
> > > > > > > > > > Sent: Monday, November 19, 2012 2:44:56 PM
> > > > > > > > > > Subject: Re: [Engine-devel] [Engine-Devel]
> > > > > > > > > > OvfDataUpdater
> > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > From: "Liron Aravot" <laravot at redhat.com>
> > > > > > > > > > > > To: engine-devel at ovirt.org
> > > > > > > > > > > > Sent: Monday, November 19, 2012 2:03:57 PM
> > > > > > > > > > > > Subject: [Engine-devel] [Engine-Devel]
> > > > > > > > > > > > OvfDataUpdater
> > > > > > > > > > > > 
> > > > > > > > > > > > starting a new discussion thread.
> > > > > > > > > > > > 
> > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > > > > > > > > > To: "Liron Aravot" <laravot at redhat.com>
> > > > > > > > > > > > > Sent: Monday, November 19, 2012 12:42:10 PM
> > > > > > > > > > > > > Subject: Re: [Engine-devel]  OvfAutoUpdater
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I think 'version' is a more standard term for
> > > > > > > > > > > > > the
> > > > > > > > > > > > > column
> > > > > > > > > > > > > names.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Also in:  4. If succesfull - for each vm
> > > > > > > > > > > > > update
> > > > > > > > > > > > > the
> > > > > > > > > > > > > ovf_generation
> > > > > > > > > > > > > to
> > > > > > > > > > > > > equal the db_generation.
> > > > > > > > > > > > > I think you mean that the update should be to
> > > > > > > > > > > > > the
> > > > > > > > > > > > > entity
> > > > > > > > > > > > > version
> > > > > > > > > > > > > you
> > > > > > > > > > > > > initially selected.
> > > > > > > > > > > > > 
> > > > > > > > > > > 1. I think should be version = version +1;
> > > > > > > > > the version will be the db_generation that was loaded
> > > > > > > > > when
> > > > > > > > > we
> > > > > > > > > loaded
> > > > > > > > > the vm/template.
> > > > > > > > > for example - if the vm/template was updated twice
> > > > > > > > > between
> > > > > > > > > OvfUpdater
> > > > > > > > > runs, we will need to increment twice - so
> > > > > > > > > incrementing
> > > > > > > > > by
> > > > > > > > > one
> > > > > > > > > will
> > > > > > > > > cause another unneeded ovf update for that vm.
> > > > > > > > I am talking about ovfVersion or how you called it.
> > > > > > > me too,
> > > > > > > if we update the vm three times between OvfAutoUpdater
> > > > > > > runs
> > > > > > > ,
> > > > > > > we
> > > > > > > will
> > > > > > > have the following values in the loaded vm for example:
> > > > > > > db_generation 8
> > > > > > > ovf_generation 5
> > > > > > > 
> > > > > > > when we perform the ovf update , ovf_generation should be
> > > > > > > set
> > > > > > > to
> > > > > > > 8
> > > > > > > and not to 6, as version '8' is the version that we wrote
> > > > > > > the
> > > > > > > ovf
> > > > > > > metadata of.
> > > > > > These should be written in wiki, with remarks that values
> > > > > > which
> > > > > > were
> > > > > > retrieved
> > > > > > from DB together.
> > > > > > > > > > > 2. Now the quartz is automatic process,
> > > > > > > > > > > updateVmInSpm
> > > > > > > > > > > it
> > > > > > > > > > > is
> > > > > > > > > > > spm
> > > > > > > > > > > operation -it means it can trigger a reconstruct
> > > > > > > > > > > and spm election.
> > > > > > > > > 2. updateVmInSpm command would be changed so it won't
> > > > > > > > > trigger
> > > > > > > > > failover, will add that to the wiki.
> > > > > > > > > > > 3. How your solution is handling a case of
> > > > > > > > > > > hotPlug/hotUnplug/remove/add of vm disks.
> > > > > > > > > > > vm_static
> > > > > > > > > > > is
> > > > > > > > > > > not
> > > > > > > > > > > usually
> > > > > > > > > > > updated.
> > > > > > > > > Whenever will be a command that locks a vm/template,
> > > > > > > > > you
> > > > > > > > > will
> > > > > > > > > have
> > > > > > > > > an
> > > > > > > > > option during the unlock to specify if the version
> > > > > > > > > need
> > > > > > > > > to
> > > > > > > > > be
> > > > > > > > > incremented, you'll be able to increment it also
> > > > > > > > > yourself.
> > > > > > > > > The HotUnPlug command does lock the vm and during
> > > > > > > > > endSuccesfully
> > > > > > > > > attempt to update the vm in spm, so it will increment
> > > > > > > > > the
> > > > > > > > > db_version/generation instead.
> > > > > > > > > > 
> > > > > > > > addDisk, removeDisk, hotPlug/unPlug not locking a vm.
> > > > > > > > Also, as far as I know LockVm/UnLockVm it is operation
> > > > > > > > on
> > > > > > > > vm_dynamic
> > > > > > > > and not
> > > > > > > > vm_static.
> > > > > > > 
> > > > > > > hotplug acquires memory lock on the vm and has no async
> > > > > > > tasks
> > > > > > > if
> > > > > > > I
> > > > > > > recall correctly.
> > > > > > Yes, correct and what? These what I said, vm_static is not
> > > > > > updated.
> > > > > you will just call the dao method for incrementing the
> > > > > db_generation,
> > > > > you don't have to perform vm_static update.
> > > > > > > adddisk acquires shared lock on the vm which is
> > > > > > > problematic
> > > > > > > with
> > > > > > > today flow as well - as you have a race during
> > > > > > > updateVmInSpm,
> > > > > > > it
> > > > > > > should be fixed regardless of the OvfAutoUpdater.
> > > > > > It is not answer on my question. How ovf will be updated?
> > > > > > How
> > > > > > you
> > > > > > understand
> > > > > > that ovf of vm should be updated?
> > > > > 
> > > > > the ovf will be updated when you increment the db_generation
> > > > > value
> > > > > instead of calling updateVmInSpm().
> > > > > you will be able to do that from the dao directly when you
> > > > > want,
> > > > > or
> > > > > when you unlock a vm/template.
> > > > > when you will update the db_generation, the vm/template would
> > > > > be
> > > > > picked up by OvfUpdater as it's db_generation is different
> > > > > than
> > > > > its
> > > > > ovf_generation.
> > > > 1. Update of ovfs is not related to locks and it should not be,
> > > > I
> > > > don't understand why
> > > > you link them.
> > > > 2. Races - your automatic process and couple of add disk
> > > > commands.
> 
Sorry, part of my response was cutted by mistake, adding it
As of today - there is a race.
After adding ovfautoupdater , you won't update the ovf for vm which is locked or has a locked disk (written in the wiki). 
ovfautoupdater won't introduce nor keep that race as we should have
 db exclusive row lock when we perform this update so even if we had context switch and we later returned to the update process, we will run the update again as we don't send the db_generation value from the engine, but only incrementing in the db. correct
me if i'm wrong.
> 
> > > > You will miss update
> > > > of ovf.
> > > > 3. Also when you will add increase of generation it is not
> > > > clear
> > > > from
> > > > your design
> > > 
> > > 1+2 The OvfAutoUpdater is not related and doesn't acquire any
> > > locks.
> > > 
> > > as of today, if you call updateVmInSpm without performing the
> > > operations with lock on the vm you'll have a race - for example,
> > > in
> > Liron, updateVmInSpm is called at endSuccessfully, you can not
> > build
> > on locks,
> > especially on in memory locks.
> > > addDisk (shared calls, two updateVmInSpm might be executed in the
> > > same time and you can't know with with ovf you'll end).
> > > 
> > > therefore, when updating the ovf_generation you should have a
> > > lock
> > > somewhere otherwise you might miss updates because of races.
> > > if today updatevminspm is called without locks and have races, it
> > > needs to be fixed unrelated to it.
> > Liron, you should fix these. These is a new development, it should
> > fix
> > all known bugs and problems and not introduce a new ones
> 
> answered below,
> As of today - there is a race.
> ovfautoupdater won't introduce nor keep that race as we should have
> automatic db exclusive row lock when we perform this update, correct
> me if i'm wrong.
> 
> > 
> > > 3. you will increase the generation whenever you made
> > > updateVmInSpm.
> > > > > > > > 
> > > > > > > > > > Also consider snapshots & vNICs which affect the VM
> > > > > > > > > > state.
> > > > > > > > > Whatever affect the vm state and triggers
> > > > > > > > > updateVmInSpm
> > > > > > > > > today
> > > > > > > > > will
> > > > > > > > > continue to, it can be added to flows which don't do
> > > > > > > > > that
> > > > > > > > > today.
> > > > > > > > > > 
> > > > > > > > > > > 4. Reconstruct/Recovery - updateVmInSpm should be
> > > > > > > > > > > called
> > > > > > > > > > > on
> > > > > > > > > > > all
> > > > > > > > > > > vms,
> > > > > > > > > > > no matter if they were updated.
> > > > > > > > > 
> > > > > > > > > Ofcourse, it's being taken care of.
> > > > > > > > How?
> > > > > > > we don't have ovf's of the vms when we reconstruct as we
> > > > > > > don't
> > > > > > > have
> > > > > > > master domain - so we should set the ovf_generation of
> > > > > > > the
> > > > > > > vms
> > > > > > > to
> > > > > > > be
> > > > > > > 0 - which will cause ovfautoupdater to copy the vm
> > > > > > > metadata.
> > > > > > I did not understand that statement and how it is related.
> > > > > OvfAutoUpdater will get those vms for update as db_generation
> > > > > is
> > > > > different than ovf_generation.
> > > > > > > a performance improvement may be introduced later on in
> > > > > > > case
> > > > > > > of
> > > > > > > wrong
> > > > > > > master version, but that's not related to the
> > > > > > > ovfautoupdater.
> > > > > > I don't understand connection to performance.
> > > > > > Now you are replacing a calls to VmCommand.updateVmInSpm()
> > > > > > one
> > > > > > of
> > > > > > them it
> > > > > > is at reconstruct flow, and you should handle it also and
> > > > > > add
> > > > > > it
> > > > > > to
> > > > > > wiki.
> > > > > answered below, OvfAutoUpdater will get those vms for update
> > > > > as
> > > > At reconstruct all vms are updated. So it is not related to
> > > > generation.
> > > > How you handle these case?
> > > 
> > > when doing reconstruct, the ovf_generation of all vms is set to 0
> > > as
> > > we don't have them on the master domain.
> > > ovfupdater will get this vms for update as ovf_generation <
> > > db_generation, will copy the vm ovf and set db_genertion to
> > > ovf_generation.
> > > 
> > > > > db_generation is different than ovf_generation.
> > > > > > > > > > > 
> > > > > > > > > > > > > Regards,
> > > > > > > > > > > > > Mike
> > > > > > > > > > > > > 
> > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Hi all, i'll be glad if you could review
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > wiki
> > > > > > > > > > > > > > page
> > > > > > > > > > > > > > of
> > > > > > > > > > > > > > OvfAutoUpdater, if you have any suggestions
> > > > > > > > > > > > > > or
> > > > > > > > > > > > > > ideas
> > > > > > > > > > > > > > please
> > > > > > > > > > > > > > let
> > > > > > > > > > > > > > me
> > > > > > > > > > > > > > know.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > short preview from the wiki:
> > > > > > > > > > > > > > vm/template configurations (including disks
> > > > > > > > > > > > > > info)
> > > > > > > > > > > > > > are
> > > > > > > > > > > > > > stored
> > > > > > > > > > > > > > on
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > master storage domain for backup purposes,
> > > > > > > > > > > > > > import/export
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > also
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > provide the abillity to run VMs without
> > > > > > > > > > > > > > having
> > > > > > > > > > > > > > a
> > > > > > > > > > > > > > running
> > > > > > > > > > > > > > engine/db.
> > > > > > > > > > > > > > Currently ovf update is done synchronously
> > > > > > > > > > > > > > when
> > > > > > > > > > > > > > performing
> > > > > > > > > > > > > > various
> > > > > > > > > > > > > > operations on vms/templates - update, save,
> > > > > > > > > > > > > > adding/removing
> > > > > > > > > > > > > > a
> > > > > > > > > > > > > > disk,
> > > > > > > > > > > > > > etc. What's more, currently updating the
> > > > > > > > > > > > > > ovf
> > > > > > > > > > > > > > (updateVM
> > > > > > > > > > > > > > vdsm
> > > > > > > > > > > > > > call)
> > > > > > > > > > > > > > is
> > > > > > > > > > > > > > usually done within a transcation.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > The idea behined OvfAutoUpdater is to
> > > > > > > > > > > > > > perform
> > > > > > > > > > > > > > batch
> > > > > > > > > > > > > > ovf
> > > > > > > > > > > > > > update
> > > > > > > > > > > > > > operations that aggregate all outstanding
> > > > > > > > > > > > > > updates
> > > > > > > > > > > > > > per
> > > > > > > > > > > > > > data
> > > > > > > > > > > > > > center.
> > > > > > > > > > > > > > These updates will be done in specifed time
> > > > > > > > > > > > > > intervals
> > > > > > > > > > > > > > which
> > > > > > > > > > > > > > will
> > > > > > > > > > > > > > reduce XML-RPC calls and will enable the
> > > > > > > > > > > > > > removal
> > > > > > > > > > > > > > of
> > > > > > > > > > > > > > this
> > > > > > > > > > > > > > syncronous
> > > > > > > > > > > > > > vdsm call from all over the code.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > Liron Aravot.
> > > > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > > > Engine-devel mailing list
> > > > > > > > > > > > > > Engine-devel at ovirt.org
> > > > > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > Engine-devel mailing list
> > > > > > > > > > > > Engine-devel at ovirt.org
> > > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > > > > > 
> > > > > > > > > > > _______________________________________________
> > > > > > > > > > > Engine-devel mailing list
> > > > > > > > > > > Engine-devel at ovirt.org
> > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From emesika at redhat.com  Mon Nov 19 21:09:32 2012
From: emesika at redhat.com (Eli Mesika)
Date: Mon, 19 Nov 2012 16:09:32 -0500 (EST)
Subject: [Engine-devel] Design review summary for 3.2 - adding support
 for	External Events
In-Reply-To: <D290AD8432118048947689BA3AE8A9B3EBCA1D@SACEXCMBX04-PRD.hq.netapp.com>
Message-ID: <655371690.12140101.1353359372942.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
> To: "Eli Mesika" <emesika at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, November 19, 2012 4:50:34 PM
> Subject: RE: [Engine-devel] Design review summary for 3.2 - adding support for	External Events
> 
> Hi Eli,
> 
> I've perused the design and it looks very good for the purpose of
> adding events to the log as back end tasks on the NetApp VSC are
> started and complete.
> 
> I do have one question. As part of the new UI plugin framework that
> Vojtech is working on he added the capability to retrieve a session
> ID that will be used outside of the oVirt engine to invoke REST API
> calls. I'm assuming this session would have the same role as the
> user that is currently logged in.
> 
> According to the event log design, only the Super user will have
> permissions to add events by default. This would mean that if anyone
> other than the super user is logged in and performing any tasks
> through the NetApp plugin, the server side of the VSC will likely
> not be able to log events. This could be confusing for users as
> sometimes they see events showing up giving them information on the
> task progress and sometimes they don't depending on the role logged
> in.
> 
> Would it make sense to allow all roles to log events by default? I'm
> not sure what security problems would arise given that it is just a
> log and they would be tagged as external events.

Hi Christopher, our security model implies a black-list, so, I don;t think this is possible
But still, a super-user can of course give the permission to add new events to all Roles in the system and you will have the same result.
Does that make sense ?

> 
> -Chris
> 
> 
> -----Original Message-----
> From: engine-devel-bounces at ovirt.org
> [mailto:engine-devel-bounces at ovirt.org] On Behalf Of Eli Mesika
> Sent: Monday, November 19, 2012 7:24 AM
> To: engine-devel
> Subject: [Engine-devel] Design review summary for 3.2 - adding
> support for External Events
> 
> Discussion : http://wiki.ovirt.org/wiki/Talk:ExternalEvents
> Updated Design :
> http://wiki.ovirt.org/wiki/Features/Design/DetailedExternalEvents#Future_directions
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From lpeer at redhat.com  Mon Nov 19 21:22:06 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Mon, 19 Nov 2012 23:22:06 +0200
Subject: [Engine-devel] Managing permissions on network
In-Reply-To: <50A61039.505@redhat.com>
References: <50991728.8070702@redhat.com> <50A51FFA.1010206@redhat.com>
	<50A5EC81.5020208@redhat.com> <50A5F7C7.6020701@redhat.com>
	<50A61039.505@redhat.com>
Message-ID: <50AAA2FE.9080402@redhat.com>

On 16/11/12 12:06, Itamar Heim wrote:
> On 11/16/2012 10:22 AM, Moti Asayag wrote:
>> On 11/16/2012 09:34 AM, Itamar Heim wrote:
>>> On 11/15/2012 07:01 PM, Moti Asayag wrote:
>>>> To recap so far:
>>>>
>>>> 1. User may see only the networks he has a permission on.
>>>> 2. User API: Only permitted networks are shown to the user. A user will
>>>> be capable to view the network element attached to its vnic, only if he
>>>> has permission on that network, else it will see its id (same as
>>>> storage
>>>> domain id appears under disk element which attached to a vm).
>>>
>>> I think a user should be able to see network for networks associated to
>>> their VMs, regardless of permissions to the attach the network to other
>>> vms.
>>> it doesn't mean they need to see all details (like statistics, which are
>>> not part of the user level api)
>>> I'm pretty sure storage, cluster and dc follow the same concept in user
>>> level api.
>>>
>>
>> Could you elaborate the importance from user perspective for the network
>> implementation details? why the user should be concerned with MTU, Vlan
>> and other network properties? Wouldn't the cloud-provider prefer to
>> encapsulate this information from the end-user ?
> 
> i do agree not all fields are relevant to user, and iirc, we have a
> mechanism to filter out such fields.
> is the MTU of the logical network a secret? user will get it from the
> vnic anyway, right?
> logical network name is also something user may need to know (what is
> user going to see in the power user portal when standing on a VM which
> has a vnic with a network they don't have a permission for? the uuid
> instead of the network name?
> tomorrow will let user create virtual networks. you need to decide which
> fields they can and cannot set (vlan they cannot set. not sure if we
> should or shouldn't hide it. i'm guessing both use cases will have merit
> actually).
> 
> 

With the above approach, what will the user see if he go to the network
main collection (/api/networks) in the user API?

Today you don't get any network info in the user API (I think - need to
make sure), with the approach Moti suggested you see all the networks
you have permissions on, but with the approach you suggested it seems
like the user will be able to see all networks, for those he has
permissions on he'll get all the details and for those he has no
permissions he'll get limited amount of info like (name, description,
MTU, usage). Do we want the user to be aware of all the networks defined
in our DC?

Livnat

>>
>>>> 3. On upgrade: 'everyone' will get 'VmNetworkUser' role on all of the
>>>> networks on the system.
>>>> 4. On the dialog of creating new network there will be an option to
>>>> grant 'everyone' permissions of the created network with
>>>> 'VmNetworkUser'
>>>> role (same as on 'make template' dialog).
>>>> 5. Since there is no granularity of permission of network for the scope
>>>> of a specific VM, If a user is 'VmNetworkUser' on a network, he may
>>>> attach it to any VM he has a permission on (permission to edit the VM).
>>>> 6. 'Create a VM from Template' and 'Create a VM from Snapshot/Clone VM'
>>>> requires permissions on the vnics' networks. This will save the need to
>>>> grant an automatic permissions for the vnics' networks. An alternative
>>>> would be the opposite: Leave the current required permissions as is and
>>>> grant permissions to the users for the networks of the created VM.
>>>>
>>>> Once we'll reach into a conclusion, I'll update the wiki accordingly.
>>>>
>>>> Thanks,
>>>> Moti
>>>>
>>>> On 11/06/2012 03:56 PM, Livnat Peer wrote:
>>>>> Hi All,
>>>>>
>>>>> This is a proposal for handling network permissions in oVirt.
>>>>>
>>>>> In this proposal we took the more permissive approach as we find it
>>>>> simple and a good starting point, we also think a more restrict
>>>>> approach
>>>>> makes the configuration of a network cumbersome for ovirt
>>>>> administrators.
>>>>>
>>>>> Inputs are welcomed as always...
>>>>>
>>>>> Here is an overview of the approach, for more detailed description
>>>>> please read the wiki page:
>>>>> http://wiki.ovirt.org/wiki/Feature/NetworkPermissions
>>>>>
>>>>> ---------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> Admin
>>>>> ======
>>>>>
>>>>> -> For creating a network in a data center you need to be a
>>>>> Superuser or
>>>>> a DCAdmin or a networkAdmin on the DC.
>>>>>
>>>>> -> After creating the network you can manipulate the network if you
>>>>> are
>>>>> a DCAdmin or a networkAdmin on the relevant network (or the whole DC).
>>>>>
>>>>> -> For attaching the network to cluster you need to be a
>>>>> networkAdmin on
>>>>> the network (no requirement to have permission on the cluster)
>>>>>
>>>>> -> Cluster administrator can not attach/detach a network from the
>>>>> cluster, the motivation for this is that as long as the network is not
>>>>> attached to the cluster it is not part of the cluster resources
>>>>> thus can
>>>>> not be managed by the cluster administrator.
>>>>> In addition once a network is attached to a cluster the cluster
>>>>> administrator can change the network from required to non-required for
>>>>> controlling the impact of the network within the cluster.
>>>>>
>>>>> -> For setting a network on the host you need to be host administrator
>>>>> on the host and you don't need to be network administrator.
>>>>> This implies that if you are a host administrator you can
>>>>> add/remove all
>>>>> the cluster networks from your host without the need for network
>>>>> related
>>>>> permissions (this is the permissive approach).
>>>>>
>>>>> User
>>>>> ====
>>>>>
>>>>> -> For attaching a network to a Vnic in the VM you need to have the
>>>>> role
>>>>> of VmNetworkUser on the network and vmAdmin on the VM.
>>>>>
>>>>> -> In user portal - the list of shown network for a user will include
>>>>> only the list of networks the user is allowed to attach to its vnics
>>>>> (instead of all cluster's networks).
>>>>>
>>>>> Port-mirroring
>>>>> ===============
>>>>>
>>>>> ->  For configuring in the VM port mirroring you need to have the role
>>>>> of VmAdvancedNetworkUser on the network and vmAdmin on the VM.
>>>>> VmAdvancedNetworkUser includes the VmNetworkUser actions in
>>>>> addition to
>>>>> port mirroring.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> For all DB upgrade information and new roles/action groups please
>>>>> review
>>>>> the wiki.
>>>>>
>>>>> Thanks,
>>>>> Livnat & Moti
>>>>>
>>>>
>>>
>>>
>>
> 
> 



From iheim at redhat.com  Mon Nov 19 21:24:12 2012
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 19 Nov 2012 23:24:12 +0200
Subject: [Engine-devel] Managing permissions on network
In-Reply-To: <50AAA2FE.9080402@redhat.com>
References: <50991728.8070702@redhat.com> <50A51FFA.1010206@redhat.com>
	<50A5EC81.5020208@redhat.com> <50A5F7C7.6020701@redhat.com>
	<50A61039.505@redhat.com> <50AAA2FE.9080402@redhat.com>
Message-ID: <50AAA37C.6090903@redhat.com>

On 11/19/2012 11:22 PM, Livnat Peer wrote:
> On 16/11/12 12:06, Itamar Heim wrote:
>> On 11/16/2012 10:22 AM, Moti Asayag wrote:
>>> On 11/16/2012 09:34 AM, Itamar Heim wrote:
>>>> On 11/15/2012 07:01 PM, Moti Asayag wrote:
>>>>> To recap so far:
>>>>>
>>>>> 1. User may see only the networks he has a permission on.
>>>>> 2. User API: Only permitted networks are shown to the user. A user will
>>>>> be capable to view the network element attached to its vnic, only if he
>>>>> has permission on that network, else it will see its id (same as
>>>>> storage
>>>>> domain id appears under disk element which attached to a vm).
>>>>
>>>> I think a user should be able to see network for networks associated to
>>>> their VMs, regardless of permissions to the attach the network to other
>>>> vms.
>>>> it doesn't mean they need to see all details (like statistics, which are
>>>> not part of the user level api)
>>>> I'm pretty sure storage, cluster and dc follow the same concept in user
>>>> level api.
>>>>
>>>
>>> Could you elaborate the importance from user perspective for the network
>>> implementation details? why the user should be concerned with MTU, Vlan
>>> and other network properties? Wouldn't the cloud-provider prefer to
>>> encapsulate this information from the end-user ?
>>
>> i do agree not all fields are relevant to user, and iirc, we have a
>> mechanism to filter out such fields.
>> is the MTU of the logical network a secret? user will get it from the
>> vnic anyway, right?
>> logical network name is also something user may need to know (what is
>> user going to see in the power user portal when standing on a VM which
>> has a vnic with a network they don't have a permission for? the uuid
>> instead of the network name?
>> tomorrow will let user create virtual networks. you need to decide which
>> fields they can and cannot set (vlan they cannot set. not sure if we
>> should or shouldn't hide it. i'm guessing both use cases will have merit
>> actually).
>>
>>
>
> With the above approach, what will the user see if he go to the network
> main collection (/api/networks) in the user API?
>
> Today you don't get any network info in the user API (I think - need to
> make sure), with the approach Moti suggested you see all the networks
> you have permissions on, but with the approach you suggested it seems
> like the user will be able to see all networks, for those he has
> permissions on he'll get all the details and for those he has no
> permissions he'll get limited amount of info like (name, description,
> MTU, usage). Do we want the user to be aware of all the networks defined
> in our DC?

user always gets same level of details on entities they see today.
according to the approach i'm suggesting, user will see all networks 
they can see either via direct permissions, or because they are used by 
entities they have permissions to.

>
> Livnat
>
>>>
>>>>> 3. On upgrade: 'everyone' will get 'VmNetworkUser' role on all of the
>>>>> networks on the system.
>>>>> 4. On the dialog of creating new network there will be an option to
>>>>> grant 'everyone' permissions of the created network with
>>>>> 'VmNetworkUser'
>>>>> role (same as on 'make template' dialog).
>>>>> 5. Since there is no granularity of permission of network for the scope
>>>>> of a specific VM, If a user is 'VmNetworkUser' on a network, he may
>>>>> attach it to any VM he has a permission on (permission to edit the VM).
>>>>> 6. 'Create a VM from Template' and 'Create a VM from Snapshot/Clone VM'
>>>>> requires permissions on the vnics' networks. This will save the need to
>>>>> grant an automatic permissions for the vnics' networks. An alternative
>>>>> would be the opposite: Leave the current required permissions as is and
>>>>> grant permissions to the users for the networks of the created VM.
>>>>>
>>>>> Once we'll reach into a conclusion, I'll update the wiki accordingly.
>>>>>
>>>>> Thanks,
>>>>> Moti
>>>>>
>>>>> On 11/06/2012 03:56 PM, Livnat Peer wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> This is a proposal for handling network permissions in oVirt.
>>>>>>
>>>>>> In this proposal we took the more permissive approach as we find it
>>>>>> simple and a good starting point, we also think a more restrict
>>>>>> approach
>>>>>> makes the configuration of a network cumbersome for ovirt
>>>>>> administrators.
>>>>>>
>>>>>> Inputs are welcomed as always...
>>>>>>
>>>>>> Here is an overview of the approach, for more detailed description
>>>>>> please read the wiki page:
>>>>>> http://wiki.ovirt.org/wiki/Feature/NetworkPermissions
>>>>>>
>>>>>> ---------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>> Admin
>>>>>> ======
>>>>>>
>>>>>> -> For creating a network in a data center you need to be a
>>>>>> Superuser or
>>>>>> a DCAdmin or a networkAdmin on the DC.
>>>>>>
>>>>>> -> After creating the network you can manipulate the network if you
>>>>>> are
>>>>>> a DCAdmin or a networkAdmin on the relevant network (or the whole DC).
>>>>>>
>>>>>> -> For attaching the network to cluster you need to be a
>>>>>> networkAdmin on
>>>>>> the network (no requirement to have permission on the cluster)
>>>>>>
>>>>>> -> Cluster administrator can not attach/detach a network from the
>>>>>> cluster, the motivation for this is that as long as the network is not
>>>>>> attached to the cluster it is not part of the cluster resources
>>>>>> thus can
>>>>>> not be managed by the cluster administrator.
>>>>>> In addition once a network is attached to a cluster the cluster
>>>>>> administrator can change the network from required to non-required for
>>>>>> controlling the impact of the network within the cluster.
>>>>>>
>>>>>> -> For setting a network on the host you need to be host administrator
>>>>>> on the host and you don't need to be network administrator.
>>>>>> This implies that if you are a host administrator you can
>>>>>> add/remove all
>>>>>> the cluster networks from your host without the need for network
>>>>>> related
>>>>>> permissions (this is the permissive approach).
>>>>>>
>>>>>> User
>>>>>> ====
>>>>>>
>>>>>> -> For attaching a network to a Vnic in the VM you need to have the
>>>>>> role
>>>>>> of VmNetworkUser on the network and vmAdmin on the VM.
>>>>>>
>>>>>> -> In user portal - the list of shown network for a user will include
>>>>>> only the list of networks the user is allowed to attach to its vnics
>>>>>> (instead of all cluster's networks).
>>>>>>
>>>>>> Port-mirroring
>>>>>> ===============
>>>>>>
>>>>>> ->  For configuring in the VM port mirroring you need to have the role
>>>>>> of VmAdvancedNetworkUser on the network and vmAdmin on the VM.
>>>>>> VmAdvancedNetworkUser includes the VmNetworkUser actions in
>>>>>> addition to
>>>>>> port mirroring.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> For all DB upgrade information and new roles/action groups please
>>>>>> review
>>>>>> the wiki.
>>>>>>
>>>>>> Thanks,
>>>>>> Livnat & Moti
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>




From emesika at redhat.com  Mon Nov 19 21:39:53 2012
From: emesika at redhat.com (Eli Mesika)
Date: Mon, 19 Nov 2012 16:39:53 -0500 (EST)
Subject: [Engine-devel] Design review summary for 3.2 - adding support
 for	External Events
In-Reply-To: <A24D665DC3ECC245A2EA0D9A958F80B631C1A4A8@G4W3215.americas.hpqcorp.net>
Message-ID: <2170247.12148316.1353361193869.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Chris Frantz" <Chris.Frantz at hp.com>
> To: "Eli Mesika" <emesika at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, November 19, 2012 6:03:37 PM
> Subject: RE: [Engine-devel] Design review summary for 3.2 - adding support for	External Events
> 
> Eli,
> 
> I've reviewed the Detailed Design for External Events.  Overall, the
> design looks good, but I have a few questions:

Hi Chris
Please see my answers below

> 
> 1. Can I provide additional data with the event:
> 
> AuditLogSeverity = EXTERNAL_EVENT_WARNING
> Message = "Enclosure RACK15ENC3: Fan in bay 5 failed"
> Vendor = "HP"
> CustomEventId = 12345
> DataCenterId = "Houston" (I assume this is really the UUID of the
> data center)
> ExtraData = { "enclosure": "RACK15ENC3", "bay": 5, "partnum":
> "412140-B21", "spare": "413996-001", "model": "Active Cool 200 Fan",
> "zone": 2}

I have added a CustomData field to the design to support that.(please see updated design page)

> 
> 2. What is the meaning of this statement on the DetailedDesign page:
> 
> External Events can not use application variables, therefore no '$'
> expressions should appear in the Event/Alert free message text
> 
> Does this mean the Message has to be fixed text with no substitution
> variables?  Can I do this:
> 
> Message = "Enclosure {ExtraData.enclosure}: Fan in bay
> {ExtraData.bay} failed.  Replace with {ExtraData.spare}."

We are using ${variable name} in messages to automatically substitute values to variables that appears in the message text.
In order to prevent confusion between application variable substitution and external events variable substitution we offer that external events will use a different pattern, the sample you have attached above will perfectly work.
This is just a suggestion, not an enforcement, since the Audit Log mechanism will leave variables in the text that failed variable substitution as is, so if the text has a ${myvar} inside the text, it will not be touched.
In any case, it is the plug-in responsibility to build and parse those variables while the engine will store the whole message as plain text.


> 
> 3. Considering that the Event has a number of IDs associated with it
> (UserId, DataCenterId, HostId, VmId, etc), does that mean an event
> can be associated with multiple entities at once?  "Host X in
> Cluster Y in Datacenter Z has exceeded the critical temperature
> threshold.  Shutting down."

Sure, you just have to set all relevant IDs when you add the event.

> 
> How will this be expanded in the future as oVirt Engine becomes aware
> of more types of entities (enclosures, rack managers, advanced
> networking switches/fabrics)?

When new entities will be added to the system, we will expand the Audit Log mechanism to support those events.
A good example of that is Gluster, that once added , has gluster_volume_id and gluster_volume_name in audit_log table and its own events.

> Is it be possible for an event to be associated with multiple hosts?

Currently not, but you can still invoke the same event on multiple entities

> 
> To return to the fan failure scenario above, if a fan in an enclosure
> fails, all of the hosts in that fan's fanzone will be effected.

I think that even for this scenario, you still look at it as a Host event, you probably expect that when you are selecting the Host in the UI, you will see this event, so, even if the event was on a collection of Hosts , its still technically a loop that adds the same event for the hosts in that fan's fanzone.
Does that make sense ?

> 
> Thanks,
> --Chris
> 
> 


From emesika at redhat.com  Mon Nov 19 21:48:52 2012
From: emesika at redhat.com (Eli Mesika)
Date: Mon, 19 Nov 2012 16:48:52 -0500 (EST)
Subject: [Engine-devel] [Design for 3.2 RFE] Host Power Management
 Multiple Agent Support
In-Reply-To: <50AA561F.5080502@redhat.com>
Message-ID: <1534525503.12149794.1353361732467.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Lon Hohberger" <lhh at redhat.com>
> Cc: "Eli Mesika" <emesika at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, November 19, 2012 5:54:07 PM
> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Host Power Management Multiple Agent Support
> 
> On 11/19/2012 04:37 PM, Lon Hohberger wrote:
> > On 11/17/2012 04:14 PM, Eli Mesika wrote:
> >
> >>> I'll keep looking.
> >>
> >> Thanks Lon
> >> I had added those questions in the Feature Talk page :
> >> http://wiki.ovirt.org/wiki/Talk:HostPMMultipleAgents
> >> I will discuss those cases with Simon tomorrow and try to answer
> >> those questions
> >>
> >
> > Hi,
> >
> > Procedural question - is it preferred that I write comments here,
> > or on
> > the wiki page?
> 
> not sure about others, but i find it easier to track comments on
> email
> before the conclusion is updated to a wiki

Have no problem with that, lets use the email and I will put the summary on the wiki
> 
> 
> 


From lpeer at redhat.com  Mon Nov 19 22:01:50 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Tue, 20 Nov 2012 00:01:50 +0200
Subject: [Engine-devel] Managing permissions on network
In-Reply-To: <50AAA37C.6090903@redhat.com>
References: <50991728.8070702@redhat.com> <50A51FFA.1010206@redhat.com>
	<50A5EC81.5020208@redhat.com> <50A5F7C7.6020701@redhat.com>
	<50A61039.505@redhat.com> <50AAA2FE.9080402@redhat.com>
	<50AAA37C.6090903@redhat.com>
Message-ID: <50AAAC4E.2000308@redhat.com>

On 19/11/12 23:24, Itamar Heim wrote:
> On 11/19/2012 11:22 PM, Livnat Peer wrote:
>> On 16/11/12 12:06, Itamar Heim wrote:
>>> On 11/16/2012 10:22 AM, Moti Asayag wrote:
>>>> On 11/16/2012 09:34 AM, Itamar Heim wrote:
>>>>> On 11/15/2012 07:01 PM, Moti Asayag wrote:
>>>>>> To recap so far:
>>>>>>
>>>>>> 1. User may see only the networks he has a permission on.
>>>>>> 2. User API: Only permitted networks are shown to the user. A user
>>>>>> will
>>>>>> be capable to view the network element attached to its vnic, only
>>>>>> if he
>>>>>> has permission on that network, else it will see its id (same as
>>>>>> storage
>>>>>> domain id appears under disk element which attached to a vm).
>>>>>
>>>>> I think a user should be able to see network for networks
>>>>> associated to
>>>>> their VMs, regardless of permissions to the attach the network to
>>>>> other
>>>>> vms.
>>>>> it doesn't mean they need to see all details (like statistics,
>>>>> which are
>>>>> not part of the user level api)
>>>>> I'm pretty sure storage, cluster and dc follow the same concept in
>>>>> user
>>>>> level api.
>>>>>
>>>>
>>>> Could you elaborate the importance from user perspective for the
>>>> network
>>>> implementation details? why the user should be concerned with MTU, Vlan
>>>> and other network properties? Wouldn't the cloud-provider prefer to
>>>> encapsulate this information from the end-user ?
>>>
>>> i do agree not all fields are relevant to user, and iirc, we have a
>>> mechanism to filter out such fields.
>>> is the MTU of the logical network a secret? user will get it from the
>>> vnic anyway, right?
>>> logical network name is also something user may need to know (what is
>>> user going to see in the power user portal when standing on a VM which
>>> has a vnic with a network they don't have a permission for? the uuid
>>> instead of the network name?
>>> tomorrow will let user create virtual networks. you need to decide which
>>> fields they can and cannot set (vlan they cannot set. not sure if we
>>> should or shouldn't hide it. i'm guessing both use cases will have merit
>>> actually).
>>>
>>>
>>
>> With the above approach, what will the user see if he go to the network
>> main collection (/api/networks) in the user API?
>>
>> Today you don't get any network info in the user API (I think - need to
>> make sure), with the approach Moti suggested you see all the networks
>> you have permissions on, but with the approach you suggested it seems
>> like the user will be able to see all networks, for those he has
>> permissions on he'll get all the details and for those he has no
>> permissions he'll get limited amount of info like (name, description,
>> MTU, usage). Do we want the user to be aware of all the networks defined
>> in our DC?
> 
> user always gets same level of details on entities they see today.
> according to the approach i'm suggesting, user will see all networks
> they can see either via direct permissions, or because they are used by
> entities they have permissions to.
> 

I guess the question is how do we define indirect permissions for networks.
* Obviously if a user has a permission on a VM or a template then he has
indirect permission on the networks attached to these entities.

what about cluster and DC -
* If a user has a userVMManager role on the cluster/DC - he should be
able to see all networks attached to a VM/tempalte in the cluster/DC? or
all networks attached to the cluster/ in the DC?




>>
>> Livnat
>>
>>>>
>>>>>> 3. On upgrade: 'everyone' will get 'VmNetworkUser' role on all of the
>>>>>> networks on the system.
>>>>>> 4. On the dialog of creating new network there will be an option to
>>>>>> grant 'everyone' permissions of the created network with
>>>>>> 'VmNetworkUser'
>>>>>> role (same as on 'make template' dialog).
>>>>>> 5. Since there is no granularity of permission of network for the
>>>>>> scope
>>>>>> of a specific VM, If a user is 'VmNetworkUser' on a network, he may
>>>>>> attach it to any VM he has a permission on (permission to edit the
>>>>>> VM).
>>>>>> 6. 'Create a VM from Template' and 'Create a VM from
>>>>>> Snapshot/Clone VM'
>>>>>> requires permissions on the vnics' networks. This will save the
>>>>>> need to
>>>>>> grant an automatic permissions for the vnics' networks. An
>>>>>> alternative
>>>>>> would be the opposite: Leave the current required permissions as
>>>>>> is and
>>>>>> grant permissions to the users for the networks of the created VM.
>>>>>>
>>>>>> Once we'll reach into a conclusion, I'll update the wiki accordingly.
>>>>>>
>>>>>> Thanks,
>>>>>> Moti
>>>>>>
>>>>>> On 11/06/2012 03:56 PM, Livnat Peer wrote:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> This is a proposal for handling network permissions in oVirt.
>>>>>>>
>>>>>>> In this proposal we took the more permissive approach as we find it
>>>>>>> simple and a good starting point, we also think a more restrict
>>>>>>> approach
>>>>>>> makes the configuration of a network cumbersome for ovirt
>>>>>>> administrators.
>>>>>>>
>>>>>>> Inputs are welcomed as always...
>>>>>>>
>>>>>>> Here is an overview of the approach, for more detailed description
>>>>>>> please read the wiki page:
>>>>>>> http://wiki.ovirt.org/wiki/Feature/NetworkPermissions
>>>>>>>
>>>>>>> ---------------------------------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Admin
>>>>>>> ======
>>>>>>>
>>>>>>> -> For creating a network in a data center you need to be a
>>>>>>> Superuser or
>>>>>>> a DCAdmin or a networkAdmin on the DC.
>>>>>>>
>>>>>>> -> After creating the network you can manipulate the network if you
>>>>>>> are
>>>>>>> a DCAdmin or a networkAdmin on the relevant network (or the whole
>>>>>>> DC).
>>>>>>>
>>>>>>> -> For attaching the network to cluster you need to be a
>>>>>>> networkAdmin on
>>>>>>> the network (no requirement to have permission on the cluster)
>>>>>>>
>>>>>>> -> Cluster administrator can not attach/detach a network from the
>>>>>>> cluster, the motivation for this is that as long as the network
>>>>>>> is not
>>>>>>> attached to the cluster it is not part of the cluster resources
>>>>>>> thus can
>>>>>>> not be managed by the cluster administrator.
>>>>>>> In addition once a network is attached to a cluster the cluster
>>>>>>> administrator can change the network from required to
>>>>>>> non-required for
>>>>>>> controlling the impact of the network within the cluster.
>>>>>>>
>>>>>>> -> For setting a network on the host you need to be host
>>>>>>> administrator
>>>>>>> on the host and you don't need to be network administrator.
>>>>>>> This implies that if you are a host administrator you can
>>>>>>> add/remove all
>>>>>>> the cluster networks from your host without the need for network
>>>>>>> related
>>>>>>> permissions (this is the permissive approach).
>>>>>>>
>>>>>>> User
>>>>>>> ====
>>>>>>>
>>>>>>> -> For attaching a network to a Vnic in the VM you need to have the
>>>>>>> role
>>>>>>> of VmNetworkUser on the network and vmAdmin on the VM.
>>>>>>>
>>>>>>> -> In user portal - the list of shown network for a user will
>>>>>>> include
>>>>>>> only the list of networks the user is allowed to attach to its vnics
>>>>>>> (instead of all cluster's networks).
>>>>>>>
>>>>>>> Port-mirroring
>>>>>>> ===============
>>>>>>>
>>>>>>> ->  For configuring in the VM port mirroring you need to have the
>>>>>>> role
>>>>>>> of VmAdvancedNetworkUser on the network and vmAdmin on the VM.
>>>>>>> VmAdvancedNetworkUser includes the VmNetworkUser actions in
>>>>>>> addition to
>>>>>>> port mirroring.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> For all DB upgrade information and new roles/action groups please
>>>>>>> review
>>>>>>> the wiki.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Livnat & Moti
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
> 
> 



From iheim at redhat.com  Mon Nov 19 22:11:49 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 20 Nov 2012 00:11:49 +0200
Subject: [Engine-devel] Managing permissions on network
In-Reply-To: <50AAAC4E.2000308@redhat.com>
References: <50991728.8070702@redhat.com> <50A51FFA.1010206@redhat.com>
	<50A5EC81.5020208@redhat.com> <50A5F7C7.6020701@redhat.com>
	<50A61039.505@redhat.com> <50AAA2FE.9080402@redhat.com>
	<50AAA37C.6090903@redhat.com> <50AAAC4E.2000308@redhat.com>
Message-ID: <50AAAEA5.3030709@redhat.com>

On 11/20/2012 12:01 AM, Livnat Peer wrote:
> On 19/11/12 23:24, Itamar Heim wrote:
>> On 11/19/2012 11:22 PM, Livnat Peer wrote:
>>> On 16/11/12 12:06, Itamar Heim wrote:
>>>> On 11/16/2012 10:22 AM, Moti Asayag wrote:
>>>>> On 11/16/2012 09:34 AM, Itamar Heim wrote:
>>>>>> On 11/15/2012 07:01 PM, Moti Asayag wrote:
>>>>>>> To recap so far:
>>>>>>>
>>>>>>> 1. User may see only the networks he has a permission on.
>>>>>>> 2. User API: Only permitted networks are shown to the user. A user
>>>>>>> will
>>>>>>> be capable to view the network element attached to its vnic, only
>>>>>>> if he
>>>>>>> has permission on that network, else it will see its id (same as
>>>>>>> storage
>>>>>>> domain id appears under disk element which attached to a vm).
>>>>>>
>>>>>> I think a user should be able to see network for networks
>>>>>> associated to
>>>>>> their VMs, regardless of permissions to the attach the network to
>>>>>> other
>>>>>> vms.
>>>>>> it doesn't mean they need to see all details (like statistics,
>>>>>> which are
>>>>>> not part of the user level api)
>>>>>> I'm pretty sure storage, cluster and dc follow the same concept in
>>>>>> user
>>>>>> level api.
>>>>>>
>>>>>
>>>>> Could you elaborate the importance from user perspective for the
>>>>> network
>>>>> implementation details? why the user should be concerned with MTU, Vlan
>>>>> and other network properties? Wouldn't the cloud-provider prefer to
>>>>> encapsulate this information from the end-user ?
>>>>
>>>> i do agree not all fields are relevant to user, and iirc, we have a
>>>> mechanism to filter out such fields.
>>>> is the MTU of the logical network a secret? user will get it from the
>>>> vnic anyway, right?
>>>> logical network name is also something user may need to know (what is
>>>> user going to see in the power user portal when standing on a VM which
>>>> has a vnic with a network they don't have a permission for? the uuid
>>>> instead of the network name?
>>>> tomorrow will let user create virtual networks. you need to decide which
>>>> fields they can and cannot set (vlan they cannot set. not sure if we
>>>> should or shouldn't hide it. i'm guessing both use cases will have merit
>>>> actually).
>>>>
>>>>
>>>
>>> With the above approach, what will the user see if he go to the network
>>> main collection (/api/networks) in the user API?
>>>
>>> Today you don't get any network info in the user API (I think - need to
>>> make sure), with the approach Moti suggested you see all the networks
>>> you have permissions on, but with the approach you suggested it seems
>>> like the user will be able to see all networks, for those he has
>>> permissions on he'll get all the details and for those he has no
>>> permissions he'll get limited amount of info like (name, description,
>>> MTU, usage). Do we want the user to be aware of all the networks defined
>>> in our DC?
>>
>> user always gets same level of details on entities they see today.
>> according to the approach i'm suggesting, user will see all networks
>> they can see either via direct permissions, or because they are used by
>> entities they have permissions to.
>>
>
> I guess the question is how do we define indirect permissions for networks.
> * Obviously if a user has a permission on a VM or a template then he has
> indirect permission on the networks attached to these entities.
>
> what about cluster and DC -
> * If a user has a userVMManager role on the cluster/DC - he should be
> able to see all networks attached to a VM/tempalte in the cluster/DC? or
> all networks attached to the cluster/ in the DC?

UserVmManager role on the cluster or DC implies permissions to all 
vms/templates in them...

>
>
>
>
>>>
>>> Livnat
>>>
>>>>>
>>>>>>> 3. On upgrade: 'everyone' will get 'VmNetworkUser' role on all of the
>>>>>>> networks on the system.
>>>>>>> 4. On the dialog of creating new network there will be an option to
>>>>>>> grant 'everyone' permissions of the created network with
>>>>>>> 'VmNetworkUser'
>>>>>>> role (same as on 'make template' dialog).
>>>>>>> 5. Since there is no granularity of permission of network for the
>>>>>>> scope
>>>>>>> of a specific VM, If a user is 'VmNetworkUser' on a network, he may
>>>>>>> attach it to any VM he has a permission on (permission to edit the
>>>>>>> VM).
>>>>>>> 6. 'Create a VM from Template' and 'Create a VM from
>>>>>>> Snapshot/Clone VM'
>>>>>>> requires permissions on the vnics' networks. This will save the
>>>>>>> need to
>>>>>>> grant an automatic permissions for the vnics' networks. An
>>>>>>> alternative
>>>>>>> would be the opposite: Leave the current required permissions as
>>>>>>> is and
>>>>>>> grant permissions to the users for the networks of the created VM.
>>>>>>>
>>>>>>> Once we'll reach into a conclusion, I'll update the wiki accordingly.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Moti
>>>>>>>
>>>>>>> On 11/06/2012 03:56 PM, Livnat Peer wrote:
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> This is a proposal for handling network permissions in oVirt.
>>>>>>>>
>>>>>>>> In this proposal we took the more permissive approach as we find it
>>>>>>>> simple and a good starting point, we also think a more restrict
>>>>>>>> approach
>>>>>>>> makes the configuration of a network cumbersome for ovirt
>>>>>>>> administrators.
>>>>>>>>
>>>>>>>> Inputs are welcomed as always...
>>>>>>>>
>>>>>>>> Here is an overview of the approach, for more detailed description
>>>>>>>> please read the wiki page:
>>>>>>>> http://wiki.ovirt.org/wiki/Feature/NetworkPermissions
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Admin
>>>>>>>> ======
>>>>>>>>
>>>>>>>> -> For creating a network in a data center you need to be a
>>>>>>>> Superuser or
>>>>>>>> a DCAdmin or a networkAdmin on the DC.
>>>>>>>>
>>>>>>>> -> After creating the network you can manipulate the network if you
>>>>>>>> are
>>>>>>>> a DCAdmin or a networkAdmin on the relevant network (or the whole
>>>>>>>> DC).
>>>>>>>>
>>>>>>>> -> For attaching the network to cluster you need to be a
>>>>>>>> networkAdmin on
>>>>>>>> the network (no requirement to have permission on the cluster)
>>>>>>>>
>>>>>>>> -> Cluster administrator can not attach/detach a network from the
>>>>>>>> cluster, the motivation for this is that as long as the network
>>>>>>>> is not
>>>>>>>> attached to the cluster it is not part of the cluster resources
>>>>>>>> thus can
>>>>>>>> not be managed by the cluster administrator.
>>>>>>>> In addition once a network is attached to a cluster the cluster
>>>>>>>> administrator can change the network from required to
>>>>>>>> non-required for
>>>>>>>> controlling the impact of the network within the cluster.
>>>>>>>>
>>>>>>>> -> For setting a network on the host you need to be host
>>>>>>>> administrator
>>>>>>>> on the host and you don't need to be network administrator.
>>>>>>>> This implies that if you are a host administrator you can
>>>>>>>> add/remove all
>>>>>>>> the cluster networks from your host without the need for network
>>>>>>>> related
>>>>>>>> permissions (this is the permissive approach).
>>>>>>>>
>>>>>>>> User
>>>>>>>> ====
>>>>>>>>
>>>>>>>> -> For attaching a network to a Vnic in the VM you need to have the
>>>>>>>> role
>>>>>>>> of VmNetworkUser on the network and vmAdmin on the VM.
>>>>>>>>
>>>>>>>> -> In user portal - the list of shown network for a user will
>>>>>>>> include
>>>>>>>> only the list of networks the user is allowed to attach to its vnics
>>>>>>>> (instead of all cluster's networks).
>>>>>>>>
>>>>>>>> Port-mirroring
>>>>>>>> ===============
>>>>>>>>
>>>>>>>> ->  For configuring in the VM port mirroring you need to have the
>>>>>>>> role
>>>>>>>> of VmAdvancedNetworkUser on the network and vmAdmin on the VM.
>>>>>>>> VmAdvancedNetworkUser includes the VmNetworkUser actions in
>>>>>>>> addition to
>>>>>>>> port mirroring.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> For all DB upgrade information and new roles/action groups please
>>>>>>>> review
>>>>>>>> the wiki.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Livnat & Moti
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>




From iheim at redhat.com  Mon Nov 19 22:13:40 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 20 Nov 2012 00:13:40 +0200
Subject: [Engine-devel] UI Plugins: PoC patch revision 7 is here
In-Reply-To: <57477608.7268460.1353326836299.JavaMail.root@redhat.com>
References: <57477608.7268460.1353326836299.JavaMail.root@redhat.com>
Message-ID: <50AAAF14.5040300@redhat.com>

On 11/19/2012 02:07 PM, Vojtech Szocs wrote:
> Hi Itamar,
>
> UI plugin infrastructure translates internal business entities into JSON-like representations and passes those representations to UI plugins. (Internal entities are NOT exposed to UI plugins directly.)
>
> Currently, all entities supported by UI plugin infrastructure (as per org.ovirt.engine.ui.webadmin.plugin.entity.EntityType) are transformed into following representation:
>
> { entityId: "[BusinessEntityGuidAsString]" }
>
> For example, a VM entity with entity ID "vm123" will translate to:
>
> { entityId: "vm123" }
>
> Translation is currently based on org.ovirt.engine.core.common.businessentities.BusinessEntity interface, like so: "BusinessEntity<? extends NGuid>" (we expect ID type parameter to be NGuid-compatible). However, I've found that there are some entities (like Pool - org.ovirt.engine.core.common.businessentities.vm_pools) that don't implement BusinessEntity interface.

ok, so we only pass the ID for now. good.

>
> Quick question to backend folks - IIRC all entities extend org.ovirt.engine.core.common.businessentities.IVdcQueryable, but not all entities implement org.ovirt.engine.core.common.businessentities.BusinessEntity interface. What is the precise relation between IVdcQueryable and BusinessEntity?
>
> As for UI plugins, currently all entities get translated to above mentioned basic JSON-like representation. You can see the relevant code in org.ovirt.engine.ui.webadmin.plugin.entity.BaseEntity.from() static method. There's a TODO that says "make this class [BaseEntity] abstract and create specific entity for each EntityType" - this means we are planning to extend the above mentioned basic JSON-like representation for different entity types.
>
> For example, for a VM entity we might do:
>
> { entityId: "[BusinessEntityGuidAsString]", osType: "[VmOsType]" }

just make sure the entity matches the REST API entity.
(which probably means entityId should be changed to id?)

>
> Vojtech
>
>
> ----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Vojtech Szocs" <vszocs at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Friday, November 16, 2012 5:24:52 PM
> Subject: Re: [Engine-devel] UI Plugins: PoC patch revision 7 is here
>
> On 11/16/2012 06:08 PM, Vojtech Szocs wrote:
>>> is there a clear list of all APIs supported now?
>>
>> Not yet, unfortunately, this should be part of "for plugin developers" wiki that is planned to be written in upcoming weeks.
>
> i just wanted to review how we solved not using internal entities as
> part of the API
>




From emesika at redhat.com  Tue Nov 20 04:16:05 2012
From: emesika at redhat.com (Eli Mesika)
Date: Mon, 19 Nov 2012 23:16:05 -0500 (EST)
Subject: [Engine-devel] Design review summary for 3.2 - adding support
 for	External Events
In-Reply-To: <655371690.12140101.1353359372942.JavaMail.root@redhat.com>
Message-ID: <648646156.12237730.1353384965957.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, November 19, 2012 11:09:32 PM
> Subject: Re: [Engine-devel] Design review summary for 3.2 - adding support for	External Events
> 
> 
> 
> ----- Original Message -----
> > From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
> > To: "Eli Mesika" <emesika at redhat.com>, "engine-devel"
> > <engine-devel at ovirt.org>
> > Sent: Monday, November 19, 2012 4:50:34 PM
> > Subject: RE: [Engine-devel] Design review summary for 3.2 - adding
> > support for	External Events
> > 
> > Hi Eli,
> > 
> > I've perused the design and it looks very good for the purpose of
> > adding events to the log as back end tasks on the NetApp VSC are
> > started and complete.
> > 
> > I do have one question. As part of the new UI plugin framework that
> > Vojtech is working on he added the capability to retrieve a session
> > ID that will be used outside of the oVirt engine to invoke REST API
> > calls. I'm assuming this session would have the same role as the
> > user that is currently logged in.
> > 
> > According to the event log design, only the Super user will have
> > permissions to add events by default. This would mean that if
> > anyone
> > other than the super user is logged in and performing any tasks
> > through the NetApp plugin, the server side of the VSC will likely
> > not be able to log events. This could be confusing for users as
> > sometimes they see events showing up giving them information on the
> > task progress and sometimes they don't depending on the role logged
> > in.
> > 
> > Would it make sense to allow all roles to log events by default?
> > I'm
> > not sure what security problems would arise given that it is just a
> > log and they would be tagged as external events.
> 
> Hi Christopher, our security model implies a black-list, 

oops, I meant white-list of course ....

so, I don;t
> think this is possible
> But still, a super-user can of course give the permission to add new
> events to all Roles in the system and you will have the same result.
> Does that make sense ?
> 
> > 
> > -Chris
> > 
> > 
> > -----Original Message-----
> > From: engine-devel-bounces at ovirt.org
> > [mailto:engine-devel-bounces at ovirt.org] On Behalf Of Eli Mesika
> > Sent: Monday, November 19, 2012 7:24 AM
> > To: engine-devel
> > Subject: [Engine-devel] Design review summary for 3.2 - adding
> > support for External Events
> > 
> > Discussion : http://wiki.ovirt.org/wiki/Talk:ExternalEvents
> > Updated Design :
> > http://wiki.ovirt.org/wiki/Features/Design/DetailedExternalEvents#Future_directions
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From lpeer at redhat.com  Tue Nov 20 06:57:20 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Tue, 20 Nov 2012 08:57:20 +0200
Subject: [Engine-devel] Network Wiring
In-Reply-To: <508971465.3443029.1353251166091.JavaMail.root@redhat.com>
References: <508971465.3443029.1353251166091.JavaMail.root@redhat.com>
Message-ID: <50AB29D0.60002@redhat.com>

On 18/11/12 17:06, Alona Kaplan wrote:
> 
>>> <snip>
>>>
>>>>>> purge a network while it is connected to VMs: Link-Down on
>>>>>> all
>>>>>> nics
>>>>>> and connect to the empty/no network. (Yes I know, it's not
>>>>>> par
>>>>>> of
>>>>>> the
>>>>>> feature, but you know someone will ask for it soon :))
>>>>>
>>>>> It should not be hard to implement; In
>>>>> http://wiki.ovirt.org/wiki/Feature/DetailedNetworkWiring#New_API
>>>>> I
>>>>> suggest passing
>>>>> no 'network' element to mean "connected to nothing".
>>>>>
>>>> I don't really understand why changing the link state to down is
>>>> not enough?
>>>> What is the added value of connecting "unwired" nic to a none
>>>> network?
>>>
>>> It is not a big deal of a difference, but the semantics of having
>>> no
>>> network is clear: you can run the VM if networks are missing, you
>>> can
>>> remove a network when the VM is running. When a VM is associated to
>>> a
>>> network, but its link state is down, the "right" semantics is more
>>> vague.
>>
>> Indeed :)
>>
>> Plus consider the use case of hooks providing the networking - they
>> still need the engine to assign the MAC and type (like the CISCO
>> hook).
>> If you force a logical network on each nic, it means you have to
>> invent a dummy LN and define it as non-required and set the global
>> config to allow VMs to run on hosts that do not have this networks -
>> Too messy. Though sometimes desirable since the network name may be
>> a hint to the hook, there are cases it's not.
>>
>> -> No LN means this VM can run on any host! with implicit assumption
>> that someone else takes care of connecting it to the proper network.
>>
>> Note that in this case you may still want the network with link state
>> up and be allowed to bring the link up/down so it's for sure not the
>> case as 'unwired/link down but connected to arbitrary network'
>>
> 
> I"ve added "none" network option to the wiki.
> Any more comments? Do we have green light to start working on the feature?

+1 for the high level design naming and behavior.

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



From lpeer at redhat.com  Tue Nov 20 07:40:13 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Tue, 20 Nov 2012 09:40:13 +0200
Subject: [Engine-devel] network wiring DD questions/comments
Message-ID: <50AB33DD.8070606@redhat.com>

Hi Alona,
I reviewed the DD of wired/unwired and I have a few questions/comments -

1. update vnic while the VM is running should be limited to cluster 3.2
(except for plug/unplug)

2. RunVM - why do we need to pass the  'linkState' property to VDSM? I
think that if the link is down we should pass none as the network and if
the link is up we should pass the network name, like we did so far. the
link-state is internal implementation detail in the engine.

3. looking on the VDSM API -
* why do we need 'type' ?
* why do we need 'device'?
* why do we need 'alias'?
* As I wrote I think we don't need 'linkState'

4. I am missing the error handling description when the user performs -
Update Vnic while changing the type for example. What is the behavior if
we succeed to unplug but not plug after that, etc.

5. Updated APIs section -This section is based on the fact that we pass
linkstate to vdsm which is not needed IMO, so if we change that this
section should be updated accordingly.

6. The EVENT section is empty, what events should be issued to audit log?
I think we should have an even for update vnic and if plug/unplug is
required a second event should be issued.

7. why does link state is varchar in DB? you expect to support other
option in addition to up/Down (which can be represented by 1 bit), maybe
n/a status?

8. About the open issues-

* About deprecation of ActivateDeactivateVmNic command  - I think that
we should remove this command from the backend to avoid duplicate flows
and bugs etc. for Backwards compatibility we should update the clients
to use the new UpdateVmNetworkInterface. the down side for that is we
have to make the can do action validation more complicated (according to
cluster level etc.)

* If we remove ActivateDeactivateVmNic there is no need to rename it ;)


Thanks, Livnat


From mkublin at redhat.com  Tue Nov 20 07:50:55 2012
From: mkublin at redhat.com (Michael Kublin)
Date: Tue, 20 Nov 2012 02:50:55 -0500 (EST)
Subject: [Engine-devel] [Engine-Devel] OvfDataUpdater
In-Reply-To: <1337223504.462749.1353350346260.JavaMail.root@redhat.com>
Message-ID: <488955558.12624435.1353397855739.JavaMail.root@redhat.com>


> > > > > > > > > > > > > 
> > > > > > > > > > > > > starting a new discussion thread.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > > > > > > > > > > To: "Liron Aravot" <laravot at redhat.com>
> > > > > > > > > > > > > > Sent: Monday, November 19, 2012 12:42:10 PM
> > > > > > > > > > > > > > Subject: Re: [Engine-devel]  OvfAutoUpdater
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > I think 'version' is a more standard term
> > > > > > > > > > > > > > for
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > column
> > > > > > > > > > > > > > names.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Also in:  4. If succesfull - for each vm
> > > > > > > > > > > > > > update
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > ovf_generation
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > equal the db_generation.
> > > > > > > > > > > > > > I think you mean that the update should be
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > entity
> > > > > > > > > > > > > > version
> > > > > > > > > > > > > > you
> > > > > > > > > > > > > > initially selected.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > 1. I think should be version = version +1;
> > > > > > > > > > the version will be the db_generation that was
> > > > > > > > > > loaded
> > > > > > > > > > when
> > > > > > > > > > we
> > > > > > > > > > loaded
> > > > > > > > > > the vm/template.
> > > > > > > > > > for example - if the vm/template was updated twice
> > > > > > > > > > between
> > > > > > > > > > OvfUpdater
> > > > > > > > > > runs, we will need to increment twice - so
> > > > > > > > > > incrementing
> > > > > > > > > > by
> > > > > > > > > > one
> > > > > > > > > > will
> > > > > > > > > > cause another unneeded ovf update for that vm.
> > > > > > > > > I am talking about ovfVersion or how you called it.
> > > > > > > > me too,
> > > > > > > > if we update the vm three times between OvfAutoUpdater
> > > > > > > > runs
> > > > > > > > ,
> > > > > > > > we
> > > > > > > > will
> > > > > > > > have the following values in the loaded vm for example:
> > > > > > > > db_generation 8
> > > > > > > > ovf_generation 5
> > > > > > > > 
> > > > > > > > when we perform the ovf update , ovf_generation should
> > > > > > > > be
> > > > > > > > set
> > > > > > > > to
> > > > > > > > 8
> > > > > > > > and not to 6, as version '8' is the version that we
> > > > > > > > wrote
> > > > > > > > the
> > > > > > > > ovf
> > > > > > > > metadata of.
> > > > > > > These should be written in wiki, with remarks that values
> > > > > > > which
> > > > > > > were
> > > > > > > retrieved
> > > > > > > from DB together.
> > > > > > > > > > > > 2. Now the quartz is automatic process,
> > > > > > > > > > > > updateVmInSpm
> > > > > > > > > > > > it
> > > > > > > > > > > > is
> > > > > > > > > > > > spm
> > > > > > > > > > > > operation -it means it can trigger a
> > > > > > > > > > > > reconstruct
> > > > > > > > > > > > and spm election.
> > > > > > > > > > 2. updateVmInSpm command would be changed so it
> > > > > > > > > > won't
> > > > > > > > > > trigger
> > > > > > > > > > failover, will add that to the wiki.
> > > > > > > > > > > > 3. How your solution is handling a case of
> > > > > > > > > > > > hotPlug/hotUnplug/remove/add of vm disks.
> > > > > > > > > > > > vm_static
> > > > > > > > > > > > is
> > > > > > > > > > > > not
> > > > > > > > > > > > usually
> > > > > > > > > > > > updated.
> > > > > > > > > > Whenever will be a command that locks a
> > > > > > > > > > vm/template,
> > > > > > > > > > you
> > > > > > > > > > will
> > > > > > > > > > have
> > > > > > > > > > an
> > > > > > > > > > option during the unlock to specify if the version
> > > > > > > > > > need
> > > > > > > > > > to
> > > > > > > > > > be
> > > > > > > > > > incremented, you'll be able to increment it also
> > > > > > > > > > yourself.
> > > > > > > > > > The HotUnPlug command does lock the vm and during
> > > > > > > > > > endSuccesfully
> > > > > > > > > > attempt to update the vm in spm, so it will
> > > > > > > > > > increment
> > > > > > > > > > the
> > > > > > > > > > db_version/generation instead.
> > > > > > > > > > > 
> > > > > > > > > addDisk, removeDisk, hotPlug/unPlug not locking a vm.
> > > > > > > > > Also, as far as I know LockVm/UnLockVm it is
> > > > > > > > > operation
> > > > > > > > > on
> > > > > > > > > vm_dynamic
> > > > > > > > > and not
> > > > > > > > > vm_static.
> > > > > > > > 
> > > > > > > > hotplug acquires memory lock on the vm and has no async
> > > > > > > > tasks
> > > > > > > > if
> > > > > > > > I
> > > > > > > > recall correctly.
> > > > > > > Yes, correct and what? These what I said, vm_static is
> > > > > > > not
> > > > > > > updated.
> > > > > > you will just call the dao method for incrementing the
> > > > > > db_generation,
> > > > > > you don't have to perform vm_static update.
> > > > > > > > adddisk acquires shared lock on the vm which is
> > > > > > > > problematic
> > > > > > > > with
> > > > > > > > today flow as well - as you have a race during
> > > > > > > > updateVmInSpm,
> > > > > > > > it
> > > > > > > > should be fixed regardless of the OvfAutoUpdater.
> > > > > > > It is not answer on my question. How ovf will be updated?
> > > > > > > How
> > > > > > > you
> > > > > > > understand
> > > > > > > that ovf of vm should be updated?
> > > > > > 
> > > > > > the ovf will be updated when you increment the
> > > > > > db_generation
> > > > > > value
> > > > > > instead of calling updateVmInSpm().
> > > > > > you will be able to do that from the dao directly when you
> > > > > > want,
> > > > > > or
> > > > > > when you unlock a vm/template.
> > > > > > when you will update the db_generation, the vm/template
> > > > > > would
> > > > > > be
> > > > > > picked up by OvfUpdater as it's db_generation is different
> > > > > > than
> > > > > > its
> > > > > > ovf_generation.
> > > > > 1. Update of ovfs is not related to locks and it should not
> > > > > be,
> > > > > I
> > > > > don't understand why
> > > > > you link them.
> > > > > 2. Races - your automatic process and couple of add disk
> > > > > commands.
> > 
> Sorry, part of my response was cutted by mistake, adding it
> As of today - there is a race.
> After adding ovfautoupdater , you won't update the ovf for vm which
> is locked or has a locked disk (written in the wiki).
Vm/disk can be moved to locked after your query, at attach/hot plug 
the state of vm will not change.
Also I still don't understand why you need check a status of disk/vm.
If some process is running on vm, ovf will be update after 5 minutes.
> ovfautoupdater won't introduce nor keep that race as we should have
>  db exclusive row lock when we perform this update so even if we had
>  context switch and we later returned to the update process, we will
>  run the update again as we don't send the db_generation value from
>  the engine, but only incrementing in the db. correct
> me if i'm wrong.
Yes, you are wrong. I don't understand why you are talking about a locks at DB,
actually why you are talking about any lock, how it is related?
The race is two operation that you are doing.
1. Reset all ovf_generation to 0 because of reconstruct
2. ovf updater is updating ovf_generation to value that he kept in memory.
At that case you will miss update of ovfs after reconstruct. 

Now, why the generation field is added to vm_static table, these field is not related
to static information of vm.
Now, your implementation is to add a lot of updates to vm_static table, it will cause
to refreshes of vms view - these will stuck all flows related to vm, especially after
reconstruct flow or some mass operation on vm. Why I need these?

Now, general regards design - what you are trying to implement it is very similar to
event queue. I think these can be done in another more simple and more performance efficient
way. 

> > 
> > > > > You will miss update
> > > > > of ovf.
> > > > > 3. Also when you will add increase of generation it is not
> > > > > clear
> > > > > from
> > > > > your design
> > > > 
> > > > 1+2 The OvfAutoUpdater is not related and doesn't acquire any
> > > > locks.
> > > > 
> > > > as of today, if you call updateVmInSpm without performing the
> > > > operations with lock on the vm you'll have a race - for
> > > > example,
> > > > in
> > > Liron, updateVmInSpm is called at endSuccessfully, you can not
> > > build
> > > on locks,
> > > especially on in memory locks.
> > > > addDisk (shared calls, two updateVmInSpm might be executed in
> > > > the
> > > > same time and you can't know with with ovf you'll end).
> > > > 
> > > > therefore, when updating the ovf_generation you should have a
> > > > lock
> > > > somewhere otherwise you might miss updates because of races.
> > > > if today updatevminspm is called without locks and have races,
> > > > it
> > > > needs to be fixed unrelated to it.
> > > Liron, you should fix these. These is a new development, it
> > > should
> > > fix
> > > all known bugs and problems and not introduce a new ones
> > 
> > answered below,
> > As of today - there is a race.
> > ovfautoupdater won't introduce nor keep that race as we should have
> > automatic db exclusive row lock when we perform this update,
> > correct
> > me if i'm wrong.
> > 
> > > 
> > > > 3. you will increase the generation whenever you made
> > > > updateVmInSpm.
> > > > > > > > > 
> > > > > > > > > > > Also consider snapshots & vNICs which affect the
> > > > > > > > > > > VM
> > > > > > > > > > > state.
> > > > > > > > > > Whatever affect the vm state and triggers
> > > > > > > > > > updateVmInSpm
> > > > > > > > > > today
> > > > > > > > > > will
> > > > > > > > > > continue to, it can be added to flows which don't
> > > > > > > > > > do
> > > > > > > > > > that
> > > > > > > > > > today.
> > > > > > > > > > > 
> > > > > > > > > > > > 4. Reconstruct/Recovery - updateVmInSpm should
> > > > > > > > > > > > be
> > > > > > > > > > > > called
> > > > > > > > > > > > on
> > > > > > > > > > > > all
> > > > > > > > > > > > vms,
> > > > > > > > > > > > no matter if they were updated.
> > > > > > > > > > 
> > > > > > > > > > Ofcourse, it's being taken care of.
> > > > > > > > > How?
> > > > > > > > we don't have ovf's of the vms when we reconstruct as
> > > > > > > > we
> > > > > > > > don't
> > > > > > > > have
> > > > > > > > master domain - so we should set the ovf_generation of
> > > > > > > > the
> > > > > > > > vms
> > > > > > > > to
> > > > > > > > be
> > > > > > > > 0 - which will cause ovfautoupdater to copy the vm
> > > > > > > > metadata.
> > > > > > > I did not understand that statement and how it is
> > > > > > > related.
> > > > > > OvfAutoUpdater will get those vms for update as
> > > > > > db_generation
> > > > > > is
> > > > > > different than ovf_generation.
> > > > > > > > a performance improvement may be introduced later on in
> > > > > > > > case
> > > > > > > > of
> > > > > > > > wrong
> > > > > > > > master version, but that's not related to the
> > > > > > > > ovfautoupdater.
> > > > > > > I don't understand connection to performance.
> > > > > > > Now you are replacing a calls to
> > > > > > > VmCommand.updateVmInSpm()
> > > > > > > one
> > > > > > > of
> > > > > > > them it
> > > > > > > is at reconstruct flow, and you should handle it also and
> > > > > > > add
> > > > > > > it
> > > > > > > to
> > > > > > > wiki.
> > > > > > answered below, OvfAutoUpdater will get those vms for
> > > > > > update
> > > > > > as
> > > > > At reconstruct all vms are updated. So it is not related to
> > > > > generation.
> > > > > How you handle these case?
> > > > 
> > > > when doing reconstruct, the ovf_generation of all vms is set to
> > > > 0
> > > > as
> > > > we don't have them on the master domain.
> > > > ovfupdater will get this vms for update as ovf_generation <
> > > > db_generation, will copy the vm ovf and set db_genertion to
> > > > ovf_generation.
> > > > 
> > > > > > db_generation is different than ovf_generation.
> > > > > > > > > > > > 
> > > > > > > > > > > > > > Regards,
> > > > > > > > > > > > > > Mike
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > > http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Hi all, i'll be glad if you could review
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > wiki
> > > > > > > > > > > > > > > page
> > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > OvfAutoUpdater, if you have any
> > > > > > > > > > > > > > > suggestions
> > > > > > > > > > > > > > > or
> > > > > > > > > > > > > > > ideas
> > > > > > > > > > > > > > > please
> > > > > > > > > > > > > > > let
> > > > > > > > > > > > > > > me
> > > > > > > > > > > > > > > know.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > short preview from the wiki:
> > > > > > > > > > > > > > > vm/template configurations (including
> > > > > > > > > > > > > > > disks
> > > > > > > > > > > > > > > info)
> > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > stored
> > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > master storage domain for backup
> > > > > > > > > > > > > > > purposes,
> > > > > > > > > > > > > > > import/export
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > also
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > provide the abillity to run VMs without
> > > > > > > > > > > > > > > having
> > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > running
> > > > > > > > > > > > > > > engine/db.
> > > > > > > > > > > > > > > Currently ovf update is done
> > > > > > > > > > > > > > > synchronously
> > > > > > > > > > > > > > > when
> > > > > > > > > > > > > > > performing
> > > > > > > > > > > > > > > various
> > > > > > > > > > > > > > > operations on vms/templates - update,
> > > > > > > > > > > > > > > save,
> > > > > > > > > > > > > > > adding/removing
> > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > disk,
> > > > > > > > > > > > > > > etc. What's more, currently updating the
> > > > > > > > > > > > > > > ovf
> > > > > > > > > > > > > > > (updateVM
> > > > > > > > > > > > > > > vdsm
> > > > > > > > > > > > > > > call)
> > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > usually done within a transcation.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > The idea behined OvfAutoUpdater is to
> > > > > > > > > > > > > > > perform
> > > > > > > > > > > > > > > batch
> > > > > > > > > > > > > > > ovf
> > > > > > > > > > > > > > > update
> > > > > > > > > > > > > > > operations that aggregate all outstanding
> > > > > > > > > > > > > > > updates
> > > > > > > > > > > > > > > per
> > > > > > > > > > > > > > > data
> > > > > > > > > > > > > > > center.
> > > > > > > > > > > > > > > These updates will be done in specifed
> > > > > > > > > > > > > > > time
> > > > > > > > > > > > > > > intervals
> > > > > > > > > > > > > > > which
> > > > > > > > > > > > > > > will
> > > > > > > > > > > > > > > reduce XML-RPC calls and will enable the
> > > > > > > > > > > > > > > removal
> > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > this
> > > > > > > > > > > > > > > syncronous
> > > > > > > > > > > > > > > vdsm call from all over the code.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > Liron Aravot.
> > > > > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > > > > Engine-devel mailing list
> > > > > > > > > > > > > > > Engine-devel at ovirt.org
> > > > > > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > > Engine-devel mailing list
> > > > > > > > > > > > > Engine-devel at ovirt.org
> > > > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > > > > > > 
> > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > Engine-devel mailing list
> > > > > > > > > > > > Engine-devel at ovirt.org
> > > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 


From mpastern at redhat.com  Tue Nov 20 08:48:27 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Tue, 20 Nov 2012 10:48:27 +0200
Subject: [Engine-devel] UI Plugins: PoC patch revision 7 is here
In-Reply-To: <50AAAF14.5040300@redhat.com>
References: <57477608.7268460.1353326836299.JavaMail.root@redhat.com>
	<50AAAF14.5040300@redhat.com>
Message-ID: <50AB43DB.5010005@redhat.com>

On 11/20/2012 12:13 AM, Itamar Heim wrote:
> On 11/19/2012 02:07 PM, Vojtech Szocs wrote:
>> Hi Itamar,
>>
>> UI plugin infrastructure translates internal business entities into JSON-like representations and passes those representations to UI plugins. (Internal entities are NOT
>> exposed to UI plugins directly.)
>>
>> Currently, all entities supported by UI plugin infrastructure (as per org.ovirt.engine.ui.webadmin.plugin.entity.EntityType) are transformed into following representation:
>>
>> { entityId: "[BusinessEntityGuidAsString]" }
>>
>> For example, a VM entity with entity ID "vm123" will translate to:
>>
>> { entityId: "vm123" }
>>
>> Translation is currently based on org.ovirt.engine.core.common.businessentities.BusinessEntity interface, like so: "BusinessEntity<? extends NGuid>" (we expect ID type
>> parameter to be NGuid-compatible). However, I've found that there are some entities (like Pool - org.ovirt.engine.core.common.businessentities.vm_pools) that don't
>> implement BusinessEntity interface.
> 
> ok, so we only pass the ID for now. good.
> 
>>
>> Quick question to backend folks - IIRC all entities extend org.ovirt.engine.core.common.businessentities.IVdcQueryable, but not all entities implement
>> org.ovirt.engine.core.common.businessentities.BusinessEntity interface. What is the precise relation between IVdcQueryable and BusinessEntity?
>>
>> As for UI plugins, currently all entities get translated to above mentioned basic JSON-like representation. You can see the relevant code in
>> org.ovirt.engine.ui.webadmin.plugin.entity.BaseEntity.from() static method. There's a TODO that says "make this class [BaseEntity] abstract and create specific entity for
>> each EntityType" - this means we are planning to extend the above mentioned basic JSON-like representation for different entity types.
>>
>> For example, for a VM entity we might do:
>>
>> { entityId: "[BusinessEntityGuidAsString]", osType: "[VmOsType]" }
> 
> just make sure the entity matches the REST API entity.
> (which probably means entityId should be changed to id?)

if we plan moving UI on top of API, you should be:

1. importing restapi-types project
2. writing intermediate layer to translate BE entities to API's using #1
3. using public entities from #2

this way your future migration to API (instead of native BE) will be much
more easier.

> 
>>
>> Vojtech
>>
>>
>> ----- Original Message -----
>> From: "Itamar Heim" <iheim at redhat.com>
>> To: "Vojtech Szocs" <vszocs at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Friday, November 16, 2012 5:24:52 PM
>> Subject: Re: [Engine-devel] UI Plugins: PoC patch revision 7 is here
>>
>> On 11/16/2012 06:08 PM, Vojtech Szocs wrote:
>>>> is there a clear list of all APIs supported now?
>>>
>>> Not yet, unfortunately, this should be part of "for plugin developers" wiki that is planned to be written in upcoming weeks.
>>
>> i just wanted to review how we solved not using internal entities as
>> part of the API
>>
> 
> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From eedri at redhat.com  Tue Nov 20 10:10:29 2012
From: eedri at redhat.com (Eyal Edri)
Date: Tue, 20 Nov 2012 05:10:29 -0500 (EST)
Subject: [Engine-devel] [Jenkins] outage
Message-ID: <1516992304.3191483.1353406229213.JavaMail.root@redhat.com>

fyi,

due to an outage and network issues jenkins.ovirt.org was restarted.

failing jobs should now return to normal state.

Eyal Edri.
oVirt Infra Team


From vszocs at redhat.com  Tue Nov 20 10:57:57 2012
From: vszocs at redhat.com (Vojtech Szocs)
Date: Tue, 20 Nov 2012 05:57:57 -0500 (EST)
Subject: [Engine-devel] UI Plugins: PoC patch revision 7 is here
In-Reply-To: <50AB43DB.5010005@redhat.com>
Message-ID: <850257615.7738611.1353409077008.JavaMail.root@redhat.com>

Hi Michael,

> if we plan moving UI on top of API, you should be:
>
> 1. importing restapi-types project
> 2. writing intermediate layer to translate BE entities to API's using #1
> 3. using public entities from #2
>
> this way your future migration to API (instead of native BE) will be much
> more easier.

Indeed, this is very useful for GWT RPC -> REST API transition in general, many thanks for pointing this out, Michael. As you suggest, we can use restapi-types mappers to translate between internal entities and API types.

Our first iteration could be:
a1, rewrite UiCommon (UI business logic) layer to work with API types
a2, write adapter (e.g. modify Frontend class) between UiCommon using API types and Generic API (GWT RPC) using internal entities

Our second iteration could be:
b1, remove adapter from step a2, drop Generic API (GWT RPC) usage
b2, write API type <-> JSON mapper, possibly using some existing framework
b3, write RPC layer that talks REST API with Engine

However, in order to use REST API types on client (GWT), we need their source code. restapi-interface-definition uses Maven JAXB plugin to generate API types from XSD schema (src/main/resources/api.xsd). On client, we need restapi-definition-<version>-sources.jar that includes those generated API types (target/generated-sources/xjc).

As for UI plugins (short term), we can just use restapi-types mappers and implement step b2, (API type -> JSON mapper).

Thanks,
Vojtech


----- Original Message -----
From: "Michael Pasternak" <mpastern at redhat.com>
To: "Vojtech Szocs" <vszocs at redhat.com>
Cc: "Itamar Heim" <iheim at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
Sent: Tuesday, November 20, 2012 9:48:27 AM
Subject: Re: [Engine-devel] UI Plugins: PoC patch revision 7 is here

On 11/20/2012 12:13 AM, Itamar Heim wrote:
> On 11/19/2012 02:07 PM, Vojtech Szocs wrote:
>> Hi Itamar,
>>
>> UI plugin infrastructure translates internal business entities into JSON-like representations and passes those representations to UI plugins. (Internal entities are NOT
>> exposed to UI plugins directly.)
>>
>> Currently, all entities supported by UI plugin infrastructure (as per org.ovirt.engine.ui.webadmin.plugin.entity.EntityType) are transformed into following representation:
>>
>> { entityId: "[BusinessEntityGuidAsString]" }
>>
>> For example, a VM entity with entity ID "vm123" will translate to:
>>
>> { entityId: "vm123" }
>>
>> Translation is currently based on org.ovirt.engine.core.common.businessentities.BusinessEntity interface, like so: "BusinessEntity<? extends NGuid>" (we expect ID type
>> parameter to be NGuid-compatible). However, I've found that there are some entities (like Pool - org.ovirt.engine.core.common.businessentities.vm_pools) that don't
>> implement BusinessEntity interface.
> 
> ok, so we only pass the ID for now. good.
> 
>>
>> Quick question to backend folks - IIRC all entities extend org.ovirt.engine.core.common.businessentities.IVdcQueryable, but not all entities implement
>> org.ovirt.engine.core.common.businessentities.BusinessEntity interface. What is the precise relation between IVdcQueryable and BusinessEntity?
>>
>> As for UI plugins, currently all entities get translated to above mentioned basic JSON-like representation. You can see the relevant code in
>> org.ovirt.engine.ui.webadmin.plugin.entity.BaseEntity.from() static method. There's a TODO that says "make this class [BaseEntity] abstract and create specific entity for
>> each EntityType" - this means we are planning to extend the above mentioned basic JSON-like representation for different entity types.
>>
>> For example, for a VM entity we might do:
>>
>> { entityId: "[BusinessEntityGuidAsString]", osType: "[VmOsType]" }
> 
> just make sure the entity matches the REST API entity.
> (which probably means entityId should be changed to id?)

if we plan moving UI on top of API, you should be:

1. importing restapi-types project
2. writing intermediate layer to translate BE entities to API's using #1
3. using public entities from #2

this way your future migration to API (instead of native BE) will be much
more easier.

> 
>>
>> Vojtech
>>
>>
>> ----- Original Message -----
>> From: "Itamar Heim" <iheim at redhat.com>
>> To: "Vojtech Szocs" <vszocs at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Friday, November 16, 2012 5:24:52 PM
>> Subject: Re: [Engine-devel] UI Plugins: PoC patch revision 7 is here
>>
>> On 11/16/2012 06:08 PM, Vojtech Szocs wrote:
>>>> is there a clear list of all APIs supported now?
>>>
>>> Not yet, unfortunately, this should be part of "for plugin developers" wiki that is planned to be written in upcoming weeks.
>>
>> i just wanted to review how we solved not using internal entities as
>> part of the API
>>
> 
> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From vszocs at redhat.com  Tue Nov 20 11:04:07 2012
From: vszocs at redhat.com (Vojtech Szocs)
Date: Tue, 20 Nov 2012 06:04:07 -0500 (EST)
Subject: [Engine-devel] UI Plugins: PoC patch revision 7 is here
In-Reply-To: <850257615.7738611.1353409077008.JavaMail.root@redhat.com>
Message-ID: <1026946452.7739700.1353409447906.JavaMail.root@redhat.com>

> b2, write API type <-> JSON mapper, possibly using some existing framework

Just realized that we can use GWT AutoBean framework which is part of GWT SDK itself (it's commonly used by RequestFactory RPC mechanism): http://code.google.com/p/google-web-toolkit/wiki/AutoBean

Vojtech


----- Original Message -----
From: "Vojtech Szocs" <vszocs at redhat.com>
To: "Michael Pasternak" <mpastern at redhat.com>
Cc: "engine-devel" <engine-devel at ovirt.org>
Sent: Tuesday, November 20, 2012 11:57:57 AM
Subject: Re: [Engine-devel] UI Plugins: PoC patch revision 7 is here

Hi Michael,

> if we plan moving UI on top of API, you should be:
>
> 1. importing restapi-types project
> 2. writing intermediate layer to translate BE entities to API's using #1
> 3. using public entities from #2
>
> this way your future migration to API (instead of native BE) will be much
> more easier.

Indeed, this is very useful for GWT RPC -> REST API transition in general, many thanks for pointing this out, Michael. As you suggest, we can use restapi-types mappers to translate between internal entities and API types.

Our first iteration could be:
a1, rewrite UiCommon (UI business logic) layer to work with API types
a2, write adapter (e.g. modify Frontend class) between UiCommon using API types and Generic API (GWT RPC) using internal entities

Our second iteration could be:
b1, remove adapter from step a2, drop Generic API (GWT RPC) usage
b2, write API type <-> JSON mapper, possibly using some existing framework
b3, write RPC layer that talks REST API with Engine

However, in order to use REST API types on client (GWT), we need their source code. restapi-interface-definition uses Maven JAXB plugin to generate API types from XSD schema (src/main/resources/api.xsd). On client, we need restapi-definition-<version>-sources.jar that includes those generated API types (target/generated-sources/xjc).

As for UI plugins (short term), we can just use restapi-types mappers and implement step b2, (API type -> JSON mapper).

Thanks,
Vojtech


----- Original Message -----
From: "Michael Pasternak" <mpastern at redhat.com>
To: "Vojtech Szocs" <vszocs at redhat.com>
Cc: "Itamar Heim" <iheim at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
Sent: Tuesday, November 20, 2012 9:48:27 AM
Subject: Re: [Engine-devel] UI Plugins: PoC patch revision 7 is here

On 11/20/2012 12:13 AM, Itamar Heim wrote:
> On 11/19/2012 02:07 PM, Vojtech Szocs wrote:
>> Hi Itamar,
>>
>> UI plugin infrastructure translates internal business entities into JSON-like representations and passes those representations to UI plugins. (Internal entities are NOT
>> exposed to UI plugins directly.)
>>
>> Currently, all entities supported by UI plugin infrastructure (as per org.ovirt.engine.ui.webadmin.plugin.entity.EntityType) are transformed into following representation:
>>
>> { entityId: "[BusinessEntityGuidAsString]" }
>>
>> For example, a VM entity with entity ID "vm123" will translate to:
>>
>> { entityId: "vm123" }
>>
>> Translation is currently based on org.ovirt.engine.core.common.businessentities.BusinessEntity interface, like so: "BusinessEntity<? extends NGuid>" (we expect ID type
>> parameter to be NGuid-compatible). However, I've found that there are some entities (like Pool - org.ovirt.engine.core.common.businessentities.vm_pools) that don't
>> implement BusinessEntity interface.
> 
> ok, so we only pass the ID for now. good.
> 
>>
>> Quick question to backend folks - IIRC all entities extend org.ovirt.engine.core.common.businessentities.IVdcQueryable, but not all entities implement
>> org.ovirt.engine.core.common.businessentities.BusinessEntity interface. What is the precise relation between IVdcQueryable and BusinessEntity?
>>
>> As for UI plugins, currently all entities get translated to above mentioned basic JSON-like representation. You can see the relevant code in
>> org.ovirt.engine.ui.webadmin.plugin.entity.BaseEntity.from() static method. There's a TODO that says "make this class [BaseEntity] abstract and create specific entity for
>> each EntityType" - this means we are planning to extend the above mentioned basic JSON-like representation for different entity types.
>>
>> For example, for a VM entity we might do:
>>
>> { entityId: "[BusinessEntityGuidAsString]", osType: "[VmOsType]" }
> 
> just make sure the entity matches the REST API entity.
> (which probably means entityId should be changed to id?)

if we plan moving UI on top of API, you should be:

1. importing restapi-types project
2. writing intermediate layer to translate BE entities to API's using #1
3. using public entities from #2

this way your future migration to API (instead of native BE) will be much
more easier.

> 
>>
>> Vojtech
>>
>>
>> ----- Original Message -----
>> From: "Itamar Heim" <iheim at redhat.com>
>> To: "Vojtech Szocs" <vszocs at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Friday, November 16, 2012 5:24:52 PM
>> Subject: Re: [Engine-devel] UI Plugins: PoC patch revision 7 is here
>>
>> On 11/16/2012 06:08 PM, Vojtech Szocs wrote:
>>>> is there a clear list of all APIs supported now?
>>>
>>> Not yet, unfortunately, this should be part of "for plugin developers" wiki that is planned to be written in upcoming weeks.
>>
>> i just wanted to review how we solved not using internal entities as
>> part of the API
>>
> 
> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D
_______________________________________________
Engine-devel mailing list
Engine-devel at ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel


From simon at redhat.com  Tue Nov 20 11:12:37 2012
From: simon at redhat.com (Simon Grinberg)
Date: Tue, 20 Nov 2012 06:12:37 -0500 (EST)
Subject: [Engine-devel] Network Wiring
In-Reply-To: <50AB29D0.60002@redhat.com>
Message-ID: <12800199.1314.1353409951932.JavaMail.javamailuser@localhost>



----- Original Message -----
> From: "Livnat Peer" <lpeer at redhat.com>
> To: "Alona Kaplan" <alkaplan at redhat.com>
> Cc: "Simon Grinberg" <simon at redhat.com>, engine-devel at ovirt.org
> Sent: Tuesday, November 20, 2012 8:57:20 AM
> Subject: Re: [Engine-devel] Network Wiring
> 
> On 18/11/12 17:06, Alona Kaplan wrote:
> > 
> >>> <snip>
> >>>
> >>>>>> purge a network while it is connected to VMs: Link-Down on
> >>>>>> all
> >>>>>> nics
> >>>>>> and connect to the empty/no network. (Yes I know, it's not
> >>>>>> par
> >>>>>> of
> >>>>>> the
> >>>>>> feature, but you know someone will ask for it soon :))
> >>>>>
> >>>>> It should not be hard to implement; In
> >>>>> http://wiki.ovirt.org/wiki/Feature/DetailedNetworkWiring#New_API
> >>>>> I
> >>>>> suggest passing
> >>>>> no 'network' element to mean "connected to nothing".
> >>>>>
> >>>> I don't really understand why changing the link state to down is
> >>>> not enough?
> >>>> What is the added value of connecting "unwired" nic to a none
> >>>> network?
> >>>
> >>> It is not a big deal of a difference, but the semantics of having
> >>> no
> >>> network is clear: you can run the VM if networks are missing, you
> >>> can
> >>> remove a network when the VM is running. When a VM is associated
> >>> to
> >>> a
> >>> network, but its link state is down, the "right" semantics is
> >>> more
> >>> vague.
> >>
> >> Indeed :)
> >>
> >> Plus consider the use case of hooks providing the networking -
> >> they
> >> still need the engine to assign the MAC and type (like the CISCO
> >> hook).
> >> If you force a logical network on each nic, it means you have to
> >> invent a dummy LN and define it as non-required and set the global
> >> config to allow VMs to run on hosts that do not have this networks
> >> -
> >> Too messy. Though sometimes desirable since the network name may
> >> be
> >> a hint to the hook, there are cases it's not.
> >>
> >> -> No LN means this VM can run on any host! with implicit
> >> assumption
> >> that someone else takes care of connecting it to the proper
> >> network.
> >>
> >> Note that in this case you may still want the network with link
> >> state
> >> up and be allowed to bring the link up/down so it's for sure not
> >> the
> >> case as 'unwired/link down but connected to arbitrary network'
> >>
> > 
> > I"ve added "none" network option to the wiki.
> > Any more comments? Do we have green light to start working on the
> > feature?
> 
> +1 for the high level design naming and behavior.

+1 as well, I think we've converged here. 

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


From masayag at redhat.com  Tue Nov 20 12:36:01 2012
From: masayag at redhat.com (Moti Asayag)
Date: Tue, 20 Nov 2012 14:36:01 +0200
Subject: [Engine-devel] network wiring DD questions/comments
In-Reply-To: <50AB33DD.8070606@redhat.com>
References: <50AB33DD.8070606@redhat.com>
Message-ID: <50AB7931.6080203@redhat.com>

Few more (here and inline):

1. Add can-do-action for network name with name 'none'. This is not must
- if we change none with N/A in the network drop-down list.

2. In "plugged --> plugged" - updateVmInteface should be replaced with
updateVmDevice.


On 11/20/2012 09:40 AM, Livnat Peer wrote:
> Hi Alona,
> I reviewed the DD of wired/unwired and I have a few questions/comments -
> 
> 1. update vnic while the VM is running should be limited to cluster 3.2
> (except for plug/unplug)
> 
> 2. RunVM - why do we need to pass the  'linkState' property to VDSM? I
> think that if the link is down we should pass none as the network and if
> the link is up we should pass the network name, like we did so far. the
> link-state is internal implementation detail in the engine.

Isn't there any consideration from current 3.2 VDSM versions built from
source ? I agree that stable/formal VDSM which supports 3.2 should be
capable of handling empty network name. If decided to pass the linkState
- it must be sent with a default value (true), same goes for createVM.

> 
> 3. looking on the VDSM API -
> * why do we need 'type' ?
> * why do we need 'device'?
> * why do we need 'alias'?
> * As I wrote I think we don't need 'linkState'
> 
> 4. I am missing the error handling description when the user performs -
> Update Vnic while changing the type for example. What is the behavior if
> we succeed to unplug but not plug after that, etc.
> 
> 5. Updated APIs section -This section is based on the fact that we pass
> linkstate to vdsm which is not needed IMO, so if we change that this
> section should be updated accordingly.
> 
> 6. The EVENT section is empty, what events should be issued to audit log?
> I think we should have an even for update vnic and if plug/unplug is
> required a second event should be issued.

If we keep using internally the ActivateDeactivateVmNic command by the
UpdateVmNic command - each command should create the relevant event-log.

> 
> 7. why does link state is varchar in DB? you expect to support other
> option in addition to up/Down (which can be represented by 1 bit), maybe
> n/a status?

+1

> 
> 8. About the open issues-
> 
> * About deprecation of ActivateDeactivateVmNic command  - I think that
> we should remove this command from the backend to avoid duplicate flows
> and bugs etc. for Backwards compatibility we should update the clients
> to use the new UpdateVmNetworkInterface. the down side for that is we
> have to make the can do action validation more complicated (according to
> cluster level etc.)

It will make the command execution more complex as well - since the
ActivateDeactivateVmNic command is non-transactive - so the internal
implementation should be copied to certain flows of the
UpdateVmNetworkInterface (which involves VDSM calls).

In any case - UpdateVmNetworkInterface should be marked as non-transactive.

> 
> * If we remove ActivateDeactivateVmNic there is no need to rename it ;)
> 

In case we decide to keep ActivateDeactivateVmNic  - according to the
design changes it will pass also the linkState to VDSM, therefore i
won't modify its name, as it performs wire/unwire in addition to
plug/unplug.


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



From gang.wei at intel.com  Tue Nov 20 13:06:09 2012
From: gang.wei at intel.com (Wei, Gang)
Date: Tue, 20 Nov 2012 13:06:09 +0000
Subject: [Engine-devel] Trusted Compute Pools
Message-ID: <D0B11485C64D4B47B66902F8A4E901BE3FCDA2@SHSMSX101.ccr.corp.intel.com>

Hi,

I am an engineer working in Intel Open Source Technology Center, interested
in integrating Intel initiated OpenAttestation(OAT) project
(https://github.com/OpenAttestation/OpenAttestation.git) into oVirt to
provide a way for Administrator to deploy VMs on trusted hosts hardened with
H/W-based security features, such as Intel TXT.

I made a draft feature page for this:
http://wiki.ovirt.org/wiki/Trusted_compute_pools

My draft idea is to provide trust_level requirement while doing vm creation
like below:

curl -v -u "vdcadmin at qa.lab.tlv.redhat.com"
    -H "Content-type: application/xml"
    -d '<vm><name>my_new_vm</name>
<cluster id="99408929-82cf-4dc7-a532-9d998063fa95" />
<template id="00000000-0000-0000-0000-000000000000"/>
<trust_level>trusted</trust_level></vm>'
    'http://10.35.1.1/rhevm-api/vms'

Then oVirt Engine should query attestation server built with OAT via RESTful
API to get all trusted hosts and select one to create the VM.

Attestation server performs host verification through following steps:
1. Hosts boot with Intel TXT technology enabled
2. The hosts' BIOS, hypervisor and OS are measured
3. These measured data is sent to Attestation server when challenged by
attestation server
4. Attestation server verifies those measurements against good/known
database to determine hosts' trustworthiness

Hosts need to be installed with OAT host agent to report host integrity to
attestation server.

By far, I am still in process of getting familiar with oVirt code and not
get solid idea yet on how the oVirt Engine should be modified to support
this feature.

Any kind of comments or suggestions will be highly appreciated.

Thanks
Gang (Jimmy) Wei
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 8586 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121120/cd801282/attachment.p7s>

From Christopher.Morrissey at netapp.com  Tue Nov 20 14:07:58 2012
From: Christopher.Morrissey at netapp.com (Morrissey, Christopher)
Date: Tue, 20 Nov 2012 14:07:58 +0000
Subject: [Engine-devel] Design review summary for 3.2 - adding support
 for	External Events
In-Reply-To: <648646156.12237730.1353384965957.JavaMail.root@redhat.com>
References: <655371690.12140101.1353359372942.JavaMail.root@redhat.com>
	<648646156.12237730.1353384965957.JavaMail.root@redhat.com>
Message-ID: <D290AD8432118048947689BA3AE8A9B3EBCE94@SACEXCMBX04-PRD.hq.netapp.com>



-Chris


> -----Original Message-----
> From: Eli Mesika [mailto:emesika at redhat.com]
> Sent: Monday, November 19, 2012 11:16 PM
> To: Morrissey, Christopher
> Cc: engine-devel
> Subject: Re: [Engine-devel] Design review summary for 3.2 - adding support
> for External Events
> 
> 
> 
> ----- Original Message -----
> > From: "Eli Mesika" <emesika at redhat.com>
> > To: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Monday, November 19, 2012 11:09:32 PM
> > Subject: Re: [Engine-devel] Design review summary for 3.2 - adding
> support for	External Events
> >
> >
> >
> > ----- Original Message -----
> > > From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
> > > To: "Eli Mesika" <emesika at redhat.com>, "engine-devel"
> > > <engine-devel at ovirt.org>
> > > Sent: Monday, November 19, 2012 4:50:34 PM
> > > Subject: RE: [Engine-devel] Design review summary for 3.2 - adding
> > > support for	External Events
> > >
> > > Hi Eli,
> > >
> > > I've perused the design and it looks very good for the purpose of
> > > adding events to the log as back end tasks on the NetApp VSC are
> > > started and complete.
> > >
> > > I do have one question. As part of the new UI plugin framework that
> > > Vojtech is working on he added the capability to retrieve a session
> > > ID that will be used outside of the oVirt engine to invoke REST API
> > > calls. I'm assuming this session would have the same role as the
> > > user that is currently logged in.
> > >
> > > According to the event log design, only the Super user will have
> > > permissions to add events by default. This would mean that if anyone
> > > other than the super user is logged in and performing any tasks
> > > through the NetApp plugin, the server side of the VSC will likely
> > > not be able to log events. This could be confusing for users as
> > > sometimes they see events showing up giving them information on the
> > > task progress and sometimes they don't depending on the role logged
> > > in.
> > >
> > > Would it make sense to allow all roles to log events by default?
> > > I'm
> > > not sure what security problems would arise given that it is just a
> > > log and they would be tagged as external events.
> >
> > Hi Christopher, our security model implies a black-list,
> 
> oops, I meant white-list of course ....
> 

That's what I figured. :)

> so, I don;t
> > think this is possible
> > But still, a super-user can of course give the permission to add new
> > events to all Roles in the system and you will have the same result.
> > Does that make sense ?
> >

That does make sense. We'll likely just try to use the API to log events when starting a task and if we receive an error we can bubble that up to the user letting them know that they need to either get the right permission or accept that they won't get messages in the oVirt log while the task completes.

> > >
> > > -Chris
> > >
> > >
> > > -----Original Message-----
> > > From: engine-devel-bounces at ovirt.org
> > > [mailto:engine-devel-bounces at ovirt.org] On Behalf Of Eli Mesika
> > > Sent: Monday, November 19, 2012 7:24 AM
> > > To: engine-devel
> > > Subject: [Engine-devel] Design review summary for 3.2 - adding
> > > support for External Events
> > >
> > > Discussion : http://wiki.ovirt.org/wiki/Talk:ExternalEvents
> > > Updated Design :
> > > http://wiki.ovirt.org/wiki/Features/Design/DetailedExternalEvents#Fu
> > > ture_directions
> _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >

From Christopher.Morrissey at netapp.com  Tue Nov 20 14:18:26 2012
From: Christopher.Morrissey at netapp.com (Morrissey, Christopher)
Date: Tue, 20 Nov 2012 14:18:26 +0000
Subject: [Engine-devel] Registering an existing disk or VM through the REST
	API
Message-ID: <D290AD8432118048947689BA3AE8A9B3EBCEB7@SACEXCMBX04-PRD.hq.netapp.com>

Hi All,

As many of you know, we're working on adding a plugin to oVirt for NetApp storage controllers. The plugin will allow users to add a new storage domain and rapidly clone VMs using the native ONTAP APIs. Our plan is to do this outside of oVirt in a separate engine and then register the new storage domain or cloned VMs through the REST API.

I've been going through the oVirt code and I'm not able to find a way to register an existing VM or disk through the REST API. Am I missing something or is this functionality that needs to be added? As part of the cloning process we can generate new UUIDs for the cloned disks and images, but I don't see a way to get them recognized by oVirt.

This functionality is very important to moving forward on our plugin and I can certainly help add this capability if needed.

-Chris

Chris Morrissey
Software Engineer
NetApp Inc.
919.476.4428

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121120/ee03d6e8/attachment.html>

From iheim at redhat.com  Tue Nov 20 14:26:37 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 20 Nov 2012 16:26:37 +0200
Subject: [Engine-devel] Registering an existing disk or VM through the
 REST API
In-Reply-To: <D290AD8432118048947689BA3AE8A9B3EBCEB7@SACEXCMBX04-PRD.hq.netapp.com>
References: <D290AD8432118048947689BA3AE8A9B3EBCEB7@SACEXCMBX04-PRD.hq.netapp.com>
Message-ID: <50AB931D.3020602@redhat.com>

On 11/20/2012 04:18 PM, Morrissey, Christopher wrote:
> Hi All,
>
> As many of you know, we?re working on adding a plugin to oVirt for
> NetApp storage controllers. The plugin will allow users to add a new
> storage domain and rapidly clone VMs using the native ONTAP APIs. Our
> plan is to do this outside of oVirt in a separate engine and then
> register the new storage domain or cloned VMs through the REST API.
>
> I?ve been going through the oVirt code and I?m not able to find a way to
> register an existing VM or disk through the REST API. Am I missing
> something or is this functionality that needs to be added? As part of
> the cloning process we can generate new UUIDs for the cloned disks and
> images, but I don?t see a way to get them recognized by oVirt.
>
> This functionality is very important to moving forward on our plugin and
> I can certainly help add this capability if needed.

missing today, but i thought this is what domain scan was about?
http://wiki.ovirt.org/wiki/Features/Domain_Scan
http://gerrit.ovirt.org/#/c/8219/1

>
> -Chris
>
> *Chris Morrissey*
>
> Software Engineer
>
> NetApp Inc.
>
> 919.476.4428
>
>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>




From Christopher.Morrissey at netapp.com  Tue Nov 20 14:32:31 2012
From: Christopher.Morrissey at netapp.com (Morrissey, Christopher)
Date: Tue, 20 Nov 2012 14:32:31 +0000
Subject: [Engine-devel] Registering an existing disk or VM through the
 REST API
In-Reply-To: <50AB931D.3020602@redhat.com>
References: <D290AD8432118048947689BA3AE8A9B3EBCEB7@SACEXCMBX04-PRD.hq.netapp.com>
	<50AB931D.3020602@redhat.com>
Message-ID: <D290AD8432118048947689BA3AE8A9B3EBCF0A@SACEXCMBX04-PRD.hq.netapp.com>


> -----Original Message-----
> From: Itamar Heim [mailto:iheim at redhat.com]
> Sent: Tuesday, November 20, 2012 9:27 AM
> To: Morrissey, Christopher
> Cc: engine-devel at ovirt.org; Ayal Baron; Hopper, Ricky
> Subject: Re: [Engine-devel] Registering an existing disk or VM through the
> REST API
> 
> On 11/20/2012 04:18 PM, Morrissey, Christopher wrote:
> > Hi All,
> >
> > As many of you know, we're working on adding a plugin to oVirt for
> > NetApp storage controllers. The plugin will allow users to add a new
> > storage domain and rapidly clone VMs using the native ONTAP APIs. Our
> > plan is to do this outside of oVirt in a separate engine and then
> > register the new storage domain or cloned VMs through the REST API.
> >
> > I've been going through the oVirt code and I'm not able to find a way
> > to register an existing VM or disk through the REST API. Am I missing
> > something or is this functionality that needs to be added? As part of
> > the cloning process we can generate new UUIDs for the cloned disks and
> > images, but I don't see a way to get them recognized by oVirt.
> >
> > This functionality is very important to moving forward on our plugin
> > and I can certainly help add this capability if needed.
> 
> missing today, but i thought this is what domain scan was about?
> http://wiki.ovirt.org/wiki/Features/Domain_Scan
> http://gerrit.ovirt.org/#/c/8219/1
> 

I had thought that as well, although the domain scanning functionality that was submitted was just querying for new disks and not actually registering them. I'm admittedly still a bit new to this and wanted to make sure I wasn't missing something.

I'll be working on the functionality to get the newly found disks actually registered with oVirt over the next week and get it submitted to gerrit as soon as possible.

> >
> > -Chris
> >
> > *Chris Morrissey*
> >
> > Software Engineer
> >
> > NetApp Inc.
> >
> > 919.476.4428
> >
> >
> >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 



From smizrahi at redhat.com  Tue Nov 20 15:06:07 2012
From: smizrahi at redhat.com (Saggi Mizrahi)
Date: Tue, 20 Nov 2012 10:06:07 -0500 (EST)
Subject: [Engine-devel] Registering an existing disk or VM through the
 REST	API
In-Reply-To: <D290AD8432118048947689BA3AE8A9B3EBCEB7@SACEXCMBX04-PRD.hq.netapp.com>
Message-ID: <437011899.7810104.1353423967283.JavaMail.root@redhat.com>

Please don't use the REST API it's being deprecated
http://gerrit.ovirt.org/#/c/7754/

We are in a transition to a stable supported API.
Until then please use the XML-RPC API which thought not supported is the more stable of the two.

----- Original Message -----
> From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
> To: engine-devel at ovirt.org
> Sent: Tuesday, November 20, 2012 9:18:26 AM
> Subject: [Engine-devel] Registering an existing disk or VM through the REST	API
> 
> 
> 
> 
> 
> Hi All,
> 
> 
> 
> As many of you know, we?re working on adding a plugin to oVirt for
> NetApp storage controllers. The plugin will allow users to add a new
> storage domain and rapidly clone VMs using the native ONTAP APIs.
> Our plan is to do this outside of oVirt in a separate engine and
> then register the new storage domain or cloned VMs through the REST
> API.
> 
> 
> 
> I?ve been going through the oVirt code and I?m not able to find a way
> to register an existing VM or disk through the REST API. Am I
> missing something or is this functionality that needs to be added?
> As part of the cloning process we can generate new UUIDs for the
> cloned disks and images, but I don?t see a way to get them
> recognized by oVirt.
> 
> 
> 
> This functionality is very important to moving forward on our plugin
> and I can certainly help add this capability if needed.
> 
> 
> 
> -Chris
> 
> 
> 
> Chris Morrissey
> 
> Software Engineer
> 
> NetApp Inc.
> 
> 919.476.4428
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>


From alkaplan at redhat.com  Tue Nov 20 15:06:48 2012
From: alkaplan at redhat.com (Alona Kaplan)
Date: Tue, 20 Nov 2012 10:06:48 -0500 (EST)
Subject: [Engine-devel] network wiring DD questions/comments
In-Reply-To: <1882991872.5215014.1353421797073.JavaMail.root@redhat.com>
Message-ID: <1276173010.5274285.1353424008008.JavaMail.root@redhat.com>


> Hi,
> 
> I"ve added my answers as inline comments.
> 
> Thanks,
> Alona.
> 
> > Hi Alona,
> > I reviewed the DD of wired/unwired and I have a few
> > questions/comments -
> > 
> > 1. update vnic while the VM is running should be limited to cluster
> > 3.2
> > (except for plug/unplug)
> I"ve updated the detailed wiki-
> 1. On Add- there will be a canDoAction error if the user will try to
> change the network to "none" on 3.1 or less.
> I don't think the "none" should be removed from the combo. The user
> won't understand why sometimes he has "none" and sometimes not.
> 2. On Update- there are two problematic cases with 3.1 or less-
>  2.1 The user changes the network to "none" - should behave as add.
>  2.2 The vnic is plugged (before and after the update) and the only
>  change is the network.
>      In this case an "UpdateDevice" verb should be sent to vdsm, so
>      if it is 3.1 or less the backend should throw a canDoAction. (I
>      updated the wiki we this scenario)
>      But, if mac address, type or plug were updated- we are sending
>      plug/unplug to the vdsm. So the update can be done although for
>      3.1.
>      We talked about disabling all the fields (except "plug/unplug")
>      in the dialog if the nic is plugged and rollback the ui if the
>      user change from plugged to unplugged and then to plugged
>      again.
>      I don't think it is right. Because if the user wants just to
>      update the mac for example, we should allow it even if the nic
>      is plugged.
>      I think the canDoAction is enough.
>  2.3 I think for 3.0 or less, the update button should be disabled if
>  the vm is not down. (Updated the wiki).
> > 
> > 2. RunVM - why do we need to pass the  'linkState' property to
> > VDSM?
> > I
> > think that if the link is down we should pass none as the network
> > and
> > if
> > the link is up we should pass the network name, like we did so far.
> > the
> > link-state is internal implementation detail in the engine.
> > 
> I will talk to Simon. If he is ok with it, I will remove the link
> state from the feature.
> 
> > 3. looking on the VDSM API -
> > * why do we need 'type' ?
> Danken wanted UpdateDevice to be a common api for updating all the
> devices. By the type the vdsm decides which device is updated.
> > * why do we need 'device'?
> You are right, it should be removed. (I updated the wiki)
> > * why do we need 'alias'?
> We don't send the mac. This is the "unique id" of the nic.
> The libvirt sets a unique alias for each device(disk, interface...),
> so it can be used as the identifier of the device.
> > * As I wrote I think we don't need 'linkState'
> > 
> > 4. I am missing the error handling description when the user
> > performs
> > -
> > Update Vnic while changing the type for example. What is the
> > behavior
> > if
> > we succeed to unplug but not plug after that, etc.
> > 
> When changing the type we are internally using the plug/unplug
> actions.
> If the unplug succeeds and the plug fails- the backend/ui will get an
> error from the plug action.
> At the end of such situation the vnic will be unplugged.
> I"m not sure what we should do with the type- store the new type or
> rollback to the old value in the db?
> 
> > 5. Updated APIs section -This section is based on the fact that we
> > pass
> > linkstate to vdsm which is not needed IMO, so if we change that
> > this
> > section should be updated accordingly.
> > 
> > 6. The EVENT section is empty, what events should be issued to
> > audit
> > log?
> > I think we should have an even for update vnic and if plug/unplug
> > is
> > required a second event should be issued.
> We already have events for update_vnic failure-
> NETWORK_UPDATE_VM_INTERFACE_FAILED and success-
> NETWORK_UPDATE_VM_INTERFACE.
> And as we use the old plug/unplug actions we don't have to add new
> events to the audit log.
> I don't think we have to add extra code to the events.
> 
> > 
> > 7. why does link state is varchar in DB? you expect to support
> > other
> > option in addition to up/Down (which can be represented by 1 bit),
> > maybe
> > n/a status?
> You are right, should be boolean. (Updated the wiki).
> (If Simon will agree to remove the link state from the feature, will
> be removed...)
> > 
> > 8. About the open issues-
> > 
> > * About deprecation of ActivateDeactivateVmNic command  - I think
> > that
> > we should remove this command from the backend to avoid duplicate
> > flows
> > and bugs etc. for Backwards compatibility we should update the
> > clients
> > to use the new UpdateVmNetworkInterface. the down side for that is
> > we
> > have to make the can do action validation more complicated
> > (according
> > to
> > cluster level etc.)
> > 
> > * If we remove ActivateDeactivateVmNic there is no need to rename
> > it
> > ;)
> We use it internally.
> Also we have to keep it exposed for backward compatibility with Rest
> API.
> I"m not sure it should be renamed...
> > 
> > 
> > Thanks, Livnat
> > 
> 


From George.Costea at netapp.com  Tue Nov 20 15:09:26 2012
From: George.Costea at netapp.com (Costea, George)
Date: Tue, 20 Nov 2012 15:09:26 +0000
Subject: [Engine-devel] Registering an existing disk or VM through the
 REST	API
In-Reply-To: <437011899.7810104.1353423967283.JavaMail.root@redhat.com>
References: <D290AD8432118048947689BA3AE8A9B3EBCEB7@SACEXCMBX04-PRD.hq.netapp.com>
	<437011899.7810104.1353423967283.JavaMail.root@redhat.com>
Message-ID: <6C8AC8C50E170C4E9B44D47B39B24A4809F1BA65@SACEXCMBX04-PRD.hq.netapp.com>

Where can we browse the XML-RPC API?  We would like to verify it has what we need.

-----Original Message-----
From: engine-devel-bounces at ovirt.org [mailto:engine-devel-bounces at ovirt.org] On Behalf Of Saggi Mizrahi
Sent: Tuesday, November 20, 2012 10:06 AM
To: Morrissey, Christopher
Cc: engine-devel at ovirt.org
Subject: Re: [Engine-devel] Registering an existing disk or VM through the REST API

Please don't use the REST API it's being deprecated http://gerrit.ovirt.org/#/c/7754/

We are in a transition to a stable supported API.
Until then please use the XML-RPC API which thought not supported is the more stable of the two.

----- Original Message -----
> From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
> To: engine-devel at ovirt.org
> Sent: Tuesday, November 20, 2012 9:18:26 AM
> Subject: [Engine-devel] Registering an existing disk or VM through the REST	API
> 
> 
> 
> 
> 
> Hi All,
> 
> 
> 
> As many of you know, we?re working on adding a plugin to oVirt for 
> NetApp storage controllers. The plugin will allow users to add a new 
> storage domain and rapidly clone VMs using the native ONTAP APIs.
> Our plan is to do this outside of oVirt in a separate engine and then 
> register the new storage domain or cloned VMs through the REST API.
> 
> 
> 
> I?ve been going through the oVirt code and I?m not able to find a way 
> to register an existing VM or disk through the REST API. Am I missing 
> something or is this functionality that needs to be added?
> As part of the cloning process we can generate new UUIDs for the 
> cloned disks and images, but I don?t see a way to get them recognized 
> by oVirt.
> 
> 
> 
> This functionality is very important to moving forward on our plugin 
> and I can certainly help add this capability if needed.
> 
> 
> 
> -Chris
> 
> 
> 
> Chris Morrissey
> 
> Software Engineer
> 
> NetApp Inc.
> 
> 919.476.4428
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
_______________________________________________
Engine-devel mailing list
Engine-devel at ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

From alkaplan at redhat.com  Tue Nov 20 15:09:43 2012
From: alkaplan at redhat.com (Alona Kaplan)
Date: Tue, 20 Nov 2012 10:09:43 -0500 (EST)
Subject: [Engine-devel] network wiring DD questions/comments
In-Reply-To: <50AB7931.6080203@redhat.com>
Message-ID: <1032474675.5276875.1353424183730.JavaMail.root@redhat.com>


> Few more (here and inline):
> 
> 1. Add can-do-action for network name with name 'none'. This is not
> must
> - if we change none with N/A in the network drop-down list.
> 
Instead of "none" there will be an empty cell, to avoid confusion if a network name "none" will be added  (I"ve updated the wiki).
But still, the canDoAction have to be modified to support null network.
> 2. In "plugged --> plugged" - updateVmInteface should be replaced
> with
> updateVmDevice.
done.
> 
> 
> On 11/20/2012 09:40 AM, Livnat Peer wrote:
> > Hi Alona,
> > I reviewed the DD of wired/unwired and I have a few
> > questions/comments -
> > 
> > 1. update vnic while the VM is running should be limited to cluster
> > 3.2
> > (except for plug/unplug)
> > 
> > 2. RunVM - why do we need to pass the  'linkState' property to
> > VDSM? I
> > think that if the link is down we should pass none as the network
> > and if
> > the link is up we should pass the network name, like we did so far.
> > the
> > link-state is internal implementation detail in the engine.
> 
> Isn't there any consideration from current 3.2 VDSM versions built
> from
> source ? I agree that stable/formal VDSM which supports 3.2 should be
> capable of handling empty network name. If decided to pass the
> linkState
> - it must be sent with a default value (true), same goes for
> createVM.
> 
> > 
> > 3. looking on the VDSM API -
> > * why do we need 'type' ?
> > * why do we need 'device'?
> > * why do we need 'alias'?
> > * As I wrote I think we don't need 'linkState'
> > 
> > 4. I am missing the error handling description when the user
> > performs -
> > Update Vnic while changing the type for example. What is the
> > behavior if
> > we succeed to unplug but not plug after that, etc.
> > 
> > 5. Updated APIs section -This section is based on the fact that we
> > pass
> > linkstate to vdsm which is not needed IMO, so if we change that
> > this
> > section should be updated accordingly.
> > 
> > 6. The EVENT section is empty, what events should be issued to
> > audit log?
> > I think we should have an even for update vnic and if plug/unplug
> > is
> > required a second event should be issued.
> 
> If we keep using internally the ActivateDeactivateVmNic command by
> the
> UpdateVmNic command - each command should create the relevant
> event-log.
> 
> > 
> > 7. why does link state is varchar in DB? you expect to support
> > other
> > option in addition to up/Down (which can be represented by 1 bit),
> > maybe
> > n/a status?
> 
> +1
> 
> > 
> > 8. About the open issues-
> > 
> > * About deprecation of ActivateDeactivateVmNic command  - I think
> > that
> > we should remove this command from the backend to avoid duplicate
> > flows
> > and bugs etc. for Backwards compatibility we should update the
> > clients
> > to use the new UpdateVmNetworkInterface. the down side for that is
> > we
> > have to make the can do action validation more complicated
> > (according to
> > cluster level etc.)
> 
> It will make the command execution more complex as well - since the
> ActivateDeactivateVmNic command is non-transactive - so the internal
> implementation should be copied to certain flows of the
> UpdateVmNetworkInterface (which involves VDSM calls).
> 
> In any case - UpdateVmNetworkInterface should be marked as
> non-transactive.
> 
> > 
> > * If we remove ActivateDeactivateVmNic there is no need to rename
> > it ;)
> > 
> 
> In case we decide to keep ActivateDeactivateVmNic  - according to the
> design changes it will pass also the linkState to VDSM, therefore i
> won't modify its name, as it performs wire/unwire in addition to
> plug/unplug.
> 
> 
> > 
> > Thanks, Livnat
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 
> 


From lpeer at redhat.com  Tue Nov 20 15:59:54 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Tue, 20 Nov 2012 17:59:54 +0200
Subject: [Engine-devel] network wiring DD questions/comments
In-Reply-To: <1276173010.5274285.1353424008008.JavaMail.root@redhat.com>
References: <1276173010.5274285.1353424008008.JavaMail.root@redhat.com>
Message-ID: <50ABA8FA.5010206@redhat.com>

On 20/11/12 17:06, Alona Kaplan wrote:
> 
>> Hi,
>>
>> I"ve added my answers as inline comments.
>>
>> Thanks,
>> Alona.
>>
>>> Hi Alona,
>>> I reviewed the DD of wired/unwired and I have a few
>>> questions/comments -
>>>
>>> 1. update vnic while the VM is running should be limited to cluster
>>> 3.2
>>> (except for plug/unplug)
>> I"ve updated the detailed wiki-
>> 1. On Add- there will be a canDoAction error if the user will try to
>> change the network to "none" on 3.1 or less.
>> I don't think the "none" should be removed from the combo. The user
>> won't understand why sometimes he has "none" and sometimes not.
>> 2. On Update- there are two problematic cases with 3.1 or less-
>>  2.1 The user changes the network to "none" - should behave as add.
>>  2.2 The vnic is plugged (before and after the update) and the only
>>  change is the network.
>>      In this case an "UpdateDevice" verb should be sent to vdsm, so
>>      if it is 3.1 or less the backend should throw a canDoAction. (I
>>      updated the wiki we this scenario)
>>      But, if mac address, type or plug were updated- we are sending
>>      plug/unplug to the vdsm. So the update can be done although for
>>      3.1.
>>      We talked about disabling all the fields (except "plug/unplug")
>>      in the dialog if the nic is plugged and rollback the ui if the
>>      user change from plugged to unplugged and then to plugged
>>      again.
>>      I don't think it is right. Because if the user wants just to
>>      update the mac for example, we should allow it even if the nic
>>      is plugged.
>>      I think the canDoAction is enough.

true, we can enable changing the MAC and the type in 3.1.
I think the UI should reflect better what the user can or can't do.
leaving it only to the canDoAction is not good enough.

How about in 3.1 -

If the device is originally unplugged
 - everything is enabled.

If the device is originally plugged
 - everything is disabled except for
	* changing to unplugged
	* changing the type
	* changing the MAC address.
If the user changes to unplugged he can edit all fields,
If the user changes to plugged (back) then we reset everything except
for MAC and type.

It's not too complicated if you keep the original plugged value and
evaluate what should be done on any change from plugged to unplugged and
vice versa.


>>  2.3 I think for 3.0 or less, the update button should be disabled if
>>  the vm is not down. (Updated the wiki).

There is a request t see the details of the NIC

>>>
>>> 2. RunVM - why do we need to pass the  'linkState' property to
>>> VDSM?
>>> I
>>> think that if the link is down we should pass none as the network
>>> and
>>> if
>>> the link is up we should pass the network name, like we did so far.
>>> the
>>> link-state is internal implementation detail in the engine.
>>>
>> I will talk to Simon. If he is ok with it, I will remove the link
>> state from the feature.
>>
>>> 3. looking on the VDSM API -
>>> * why do we need 'type' ?
>> Danken wanted UpdateDevice to be a common api for updating all the
>> devices. By the type the vdsm decides which device is updated.
>>> * why do we need 'device'?
>> You are right, it should be removed. (I updated the wiki)
>>> * why do we need 'alias'?
>> We don't send the mac. This is the "unique id" of the nic.
>> The libvirt sets a unique alias for each device(disk, interface...),
>> so it can be used as the identifier of the device.
>>> * As I wrote I think we don't need 'linkState'
>>>
>>> 4. I am missing the error handling description when the user
>>> performs
>>> -
>>> Update Vnic while changing the type for example. What is the
>>> behavior
>>> if
>>> we succeed to unplug but not plug after that, etc.
>>>
>> When changing the type we are internally using the plug/unplug
>> actions.
>> If the unplug succeeds and the plug fails- the backend/ui will get an
>> error from the plug action.
>> At the end of such situation the vnic will be unplugged.
>> I"m not sure what we should do with the type- store the new type or
>> rollback to the old value in the db?

I agree it should stay unplugged, I would not perform roll back of the
type, MAC or any other field if the user will give it another try and
succeed the configuration would be as he wanted it to be.
IMO there is no right answer to that, I can think of use cases where
roll back is the right behavior from the user POV and I can also think
of scenarios where not rolling back is good for the user...


>>
>>> 5. Updated APIs section -This section is based on the fact that we
>>> pass
>>> linkstate to vdsm which is not needed IMO, so if we change that
>>> this
>>> section should be updated accordingly.
>>>
>>> 6. The EVENT section is empty, what events should be issued to
>>> audit
>>> log?
>>> I think we should have an even for update vnic and if plug/unplug
>>> is
>>> required a second event should be issued.
>> We already have events for update_vnic failure-
>> NETWORK_UPDATE_VM_INTERFACE_FAILED and success-
>> NETWORK_UPDATE_VM_INTERFACE.
>> And as we use the old plug/unplug actions we don't have to add new
>> events to the audit log.
>> I don't think we have to add extra code to the events.
>>

Great, adding this info to the wiki is useful for fully understanding
the feature, users know what to expect (although it did not change).

>>>
>>> 7. why does link state is varchar in DB? you expect to support
>>> other
>>> option in addition to up/Down (which can be represented by 1 bit),
>>> maybe
>>> n/a status?
>> You are right, should be boolean. (Updated the wiki).
>> (If Simon will agree to remove the link state from the feature, will
>> be removed...)
>>>
>>> 8. About the open issues-
>>>
>>> * About deprecation of ActivateDeactivateVmNic command  - I think
>>> that
>>> we should remove this command from the backend to avoid duplicate
>>> flows
>>> and bugs etc. for Backwards compatibility we should update the
>>> clients
>>> to use the new UpdateVmNetworkInterface. the down side for that is
>>> we
>>> have to make the can do action validation more complicated
>>> (according
>>> to
>>> cluster level etc.)
>>>
>>> * If we remove ActivateDeactivateVmNic there is no need to rename
>>> it
>>> ;)
>> We use it internally.
>> Also we have to keep it exposed for backward compatibility with Rest
>> API.
>> I"m not sure it should be renamed...

I agree we can use it internally but the API should not use it.

>>>
>>>
>>> Thanks, Livnat
>>>
>>



From lhornyak at redhat.com  Tue Nov 20 16:20:14 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Tue, 20 Nov 2012 11:20:14 -0500 (EST)
Subject: [Engine-devel] Trusted Compute Pools
In-Reply-To: <D0B11485C64D4B47B66902F8A4E901BE3FCDA2@SHSMSX101.ccr.corp.intel.com>
Message-ID: <211734567.11864474.1353428414476.JavaMail.root@redhat.com>

Hi,

Interesting technology. Some questions:
- There will be 1 and only one attestation server installed per ovirt instance or per trusted pool?
- Could engine cache the data it received from the attestation server, or does it have to query each time a trusted VM needs to be started?

Thank you,
Laszlo

----- Original Message -----
> From: "Gang Wei" <gang.wei at intel.com>
> To: engine-devel at ovirt.org
> Sent: Tuesday, November 20, 2012 2:06:09 PM
> Subject: [Engine-devel] Trusted Compute Pools
> 
> Hi,
> 
> I am an engineer working in Intel Open Source Technology Center,
> interested
> in integrating Intel initiated OpenAttestation(OAT) project
> (https://github.com/OpenAttestation/OpenAttestation.git) into oVirt
> to
> provide a way for Administrator to deploy VMs on trusted hosts
> hardened with
> H/W-based security features, such as Intel TXT.
> 
> I made a draft feature page for this:
> http://wiki.ovirt.org/wiki/Trusted_compute_pools
> 
> My draft idea is to provide trust_level requirement while doing vm
> creation
> like below:
> 
> curl -v -u "vdcadmin at qa.lab.tlv.redhat.com"
>     -H "Content-type: application/xml"
>     -d '<vm><name>my_new_vm</name>
> <cluster id="99408929-82cf-4dc7-a532-9d998063fa95" />
> <template id="00000000-0000-0000-0000-000000000000"/>
> <trust_level>trusted</trust_level></vm>'
>     'http://10.35.1.1/rhevm-api/vms'
> 
> Then oVirt Engine should query attestation server built with OAT via
> RESTful
> API to get all trusted hosts and select one to create the VM.
> 
> Attestation server performs host verification through following
> steps:
> 1. Hosts boot with Intel TXT technology enabled
> 2. The hosts' BIOS, hypervisor and OS are measured
> 3. These measured data is sent to Attestation server when challenged
> by
> attestation server
> 4. Attestation server verifies those measurements against good/known
> database to determine hosts' trustworthiness
> 
> Hosts need to be installed with OAT host agent to report host
> integrity to
> attestation server.
> 
> By far, I am still in process of getting familiar with oVirt code and
> not
> get solid idea yet on how the oVirt Engine should be modified to
> support
> this feature.
> 
> Any kind of comments or suggestions will be highly appreciated.
> 
> Thanks
> Gang (Jimmy) Wei
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From iheim at redhat.com  Tue Nov 20 19:06:40 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 20 Nov 2012 21:06:40 +0200
Subject: [Engine-devel] Registering an existing disk or VM through the
 REST	API
In-Reply-To: <437011899.7810104.1353423967283.JavaMail.root@redhat.com>
References: <437011899.7810104.1353423967283.JavaMail.root@redhat.com>
Message-ID: <50ABD4C0.9060300@redhat.com>

On 11/20/2012 05:06 PM, Saggi Mizrahi wrote:
> Please don't use the REST API it's being deprecated
> http://gerrit.ovirt.org/#/c/7754/
>
> We are in a transition to a stable supported API.
> Until then please use the XML-RPC API which thought not supported is the more stable of the two.

Saggie is talking about the vdsm rest api.
Chris, I'm pretty sure you are planning to add it to the Engine REST 
API, to allow consuming this verb via an engine UI plugin?


>
> ----- Original Message -----
>> From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
>> To: engine-devel at ovirt.org
>> Sent: Tuesday, November 20, 2012 9:18:26 AM
>> Subject: [Engine-devel] Registering an existing disk or VM through the REST	API
>>
>>
>>
>>
>>
>> Hi All,
>>
>>
>>
>> As many of you know, we?re working on adding a plugin to oVirt for
>> NetApp storage controllers. The plugin will allow users to add a new
>> storage domain and rapidly clone VMs using the native ONTAP APIs.
>> Our plan is to do this outside of oVirt in a separate engine and
>> then register the new storage domain or cloned VMs through the REST
>> API.
>>
>>
>>
>> I?ve been going through the oVirt code and I?m not able to find a way
>> to register an existing VM or disk through the REST API. Am I
>> missing something or is this functionality that needs to be added?
>> As part of the cloning process we can generate new UUIDs for the
>> cloned disks and images, but I don?t see a way to get them
>> recognized by oVirt.
>>
>>
>>
>> This functionality is very important to moving forward on our plugin
>> and I can certainly help add this capability if needed.
>>
>>
>>
>> -Chris
>>
>>
>>
>> Chris Morrissey
>>
>> Software Engineer
>>
>> NetApp Inc.
>>
>> 919.476.4428
>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>




From Christopher.Morrissey at netapp.com  Tue Nov 20 19:09:15 2012
From: Christopher.Morrissey at netapp.com (Morrissey, Christopher)
Date: Tue, 20 Nov 2012 19:09:15 +0000
Subject: [Engine-devel] Registering an existing disk or VM through the
 REST	API
In-Reply-To: <50ABD4C0.9060300@redhat.com>
References: <437011899.7810104.1353423967283.JavaMail.root@redhat.com>
	<50ABD4C0.9060300@redhat.com>
Message-ID: <D290AD8432118048947689BA3AE8A9B3EBD1D3@SACEXCMBX04-PRD.hq.netapp.com>


> -----Original Message-----
> From: Itamar Heim [mailto:iheim at redhat.com]
> Sent: Tuesday, November 20, 2012 2:07 PM
> To: Saggi Mizrahi
> Cc: Morrissey, Christopher; engine-devel at ovirt.org
> Subject: Re: [Engine-devel] Registering an existing disk or VM through the
> REST API
> 
> On 11/20/2012 05:06 PM, Saggi Mizrahi wrote:
> > Please don't use the REST API it's being deprecated
> > http://gerrit.ovirt.org/#/c/7754/
> >
> > We are in a transition to a stable supported API.
> > Until then please use the XML-RPC API which thought not supported is the
> more stable of the two.
> 
> Saggie is talking about the vdsm rest api.
> Chris, I'm pretty sure you are planning to add it to the Engine REST API, to
> allow consuming this verb via an engine UI plugin?
> 

Yes, Itamar. George and I were very confused for a while, but as I looked at the patch pointed to above it appears there is a separate REST API for VDSM. So, just to be clear is there any separate XML RPC API for the Engine or REST is all there is and no plans to change in the future?

> 
> >
> > ----- Original Message -----
> >> From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
> >> To: engine-devel at ovirt.org
> >> Sent: Tuesday, November 20, 2012 9:18:26 AM
> >> Subject: [Engine-devel] Registering an existing disk or VM through the
> REST	API
> >>
> >>
> >>
> >>
> >>
> >> Hi All,
> >>
> >>
> >>
> >> As many of you know, we?re working on adding a plugin to oVirt for
> >> NetApp storage controllers. The plugin will allow users to add a new
> >> storage domain and rapidly clone VMs using the native ONTAP APIs.
> >> Our plan is to do this outside of oVirt in a separate engine and
> >> then register the new storage domain or cloned VMs through the REST
> >> API.
> >>
> >>
> >>
> >> I?ve been going through the oVirt code and I?m not able to find a way
> >> to register an existing VM or disk through the REST API. Am I
> >> missing something or is this functionality that needs to be added?
> >> As part of the cloning process we can generate new UUIDs for the
> >> cloned disks and images, but I don?t see a way to get them
> >> recognized by oVirt.
> >>
> >>
> >>
> >> This functionality is very important to moving forward on our plugin
> >> and I can certainly help add this capability if needed.
> >>
> >>
> >>
> >> -Chris
> >>
> >>
> >>
> >> Chris Morrissey
> >>
> >> Software Engineer
> >>
> >> NetApp Inc.
> >>
> >> 919.476.4428
> >>
> >>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 


From iheim at redhat.com  Tue Nov 20 19:14:23 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 20 Nov 2012 21:14:23 +0200
Subject: [Engine-devel] Registering an existing disk or VM through the
 REST	API
In-Reply-To: <D290AD8432118048947689BA3AE8A9B3EBD1D3@SACEXCMBX04-PRD.hq.netapp.com>
References: <437011899.7810104.1353423967283.JavaMail.root@redhat.com>
	<50ABD4C0.9060300@redhat.com>
	<D290AD8432118048947689BA3AE8A9B3EBD1D3@SACEXCMBX04-PRD.hq.netapp.com>
Message-ID: <50ABD68F.1070606@redhat.com>

On 11/20/2012 09:09 PM, Morrissey, Christopher wrote:
>
>> -----Original Message-----
>> From: Itamar Heim [mailto:iheim at redhat.com]
>> Sent: Tuesday, November 20, 2012 2:07 PM
>> To: Saggi Mizrahi
>> Cc: Morrissey, Christopher; engine-devel at ovirt.org
>> Subject: Re: [Engine-devel] Registering an existing disk or VM through the
>> REST API
>>
>> On 11/20/2012 05:06 PM, Saggi Mizrahi wrote:
>>> Please don't use the REST API it's being deprecated
>>> http://gerrit.ovirt.org/#/c/7754/
>>>
>>> We are in a transition to a stable supported API.
>>> Until then please use the XML-RPC API which thought not supported is the
>> more stable of the two.
>>
>> Saggie is talking about the vdsm rest api.
>> Chris, I'm pretty sure you are planning to add it to the Engine REST API, to
>> allow consuming this verb via an engine UI plugin?
>>
>
> Yes, Itamar. George and I were very confused for a while, but as I looked at the patch pointed to above it appears there is a separate REST API for VDSM. So, just to be clear is there any separate XML RPC API for the Engine or REST is all there is and no plans to change in the future?

Engine communicates with VDSM today via XML-RPC.
there was work to move VDSM to a newer API, based on REST.
this was abandoned, and focus is moving to JSON messages based API instead.
(you'd be using this api when your engine side patch will be calling the 
VDSM method for domain scan, but the xml-rpc part of it is probably 
abstracted in the engine from you).

in any case, this is *all* engine-vdsm side, and unrelated to the Engine 
REST API, which there are no plans to deprecate.


>
>>
>>>
>>> ----- Original Message -----
>>>> From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
>>>> To: engine-devel at ovirt.org
>>>> Sent: Tuesday, November 20, 2012 9:18:26 AM
>>>> Subject: [Engine-devel] Registering an existing disk or VM through the
>> REST	API
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Hi All,
>>>>
>>>>
>>>>
>>>> As many of you know, we?re working on adding a plugin to oVirt for
>>>> NetApp storage controllers. The plugin will allow users to add a new
>>>> storage domain and rapidly clone VMs using the native ONTAP APIs.
>>>> Our plan is to do this outside of oVirt in a separate engine and
>>>> then register the new storage domain or cloned VMs through the REST
>>>> API.
>>>>
>>>>
>>>>
>>>> I?ve been going through the oVirt code and I?m not able to find a way
>>>> to register an existing VM or disk through the REST API. Am I
>>>> missing something or is this functionality that needs to be added?
>>>> As part of the cloning process we can generate new UUIDs for the
>>>> cloned disks and images, but I don?t see a way to get them
>>>> recognized by oVirt.
>>>>
>>>>
>>>>
>>>> This functionality is very important to moving forward on our plugin
>>>> and I can certainly help add this capability if needed.
>>>>
>>>>
>>>>
>>>> -Chris
>>>>
>>>>
>>>>
>>>> Chris Morrissey
>>>>
>>>> Software Engineer
>>>>
>>>> NetApp Inc.
>>>>
>>>> 919.476.4428
>>>>
>>>>
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>>
>




From lhh at redhat.com  Tue Nov 20 20:35:40 2012
From: lhh at redhat.com (Lon Hohberger)
Date: Tue, 20 Nov 2012 15:35:40 -0500
Subject: [Engine-devel] [Design for 3.2 RFE] Host Power Management
 Multiple Agent Support
In-Reply-To: <1534525503.12149794.1353361732467.JavaMail.root@redhat.com>
References: <1534525503.12149794.1353361732467.JavaMail.root@redhat.com>
Message-ID: <50ABE99C.5090106@redhat.com>

On 11/19/2012 04:48 PM, Eli Mesika wrote:
> 
> 
> ----- Original Message -----
>> From: "Itamar Heim" <iheim at redhat.com>
>> To: "Lon Hohberger" <lhh at redhat.com>
>> Cc: "Eli Mesika" <emesika at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
>> Sent: Monday, November 19, 2012 5:54:07 PM
>> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Host Power Management Multiple Agent Support
>>
>> On 11/19/2012 04:37 PM, Lon Hohberger wrote:
>>> On 11/17/2012 04:14 PM, Eli Mesika wrote:
>>>
>>>>> I'll keep looking.
>>>>
>>>> Thanks Lon
>>>> I had added those questions in the Feature Talk page :
>>>> http://wiki.ovirt.org/wiki/Talk:HostPMMultipleAgents
>>>> I will discuss those cases with Simon tomorrow and try to answer
>>>> those questions
>>>>
>>>
>>> Hi,
>>>
>>> Procedural question - is it preferred that I write comments here,
>>> or on
>>> the wiki page?
>>
>> not sure about others, but i find it easier to track comments on
>> email
>> before the conclusion is updated to a wiki
> 
> Have no problem with that, lets use the email and I will put the summary on the wiki

Sure.  I read the response on the wiki.  It sounds like for now, the
level of flexibility I described isn't desired.

The deployments involving remote power with dual power supplies will be
covered adequately by this (e.g. if you turn on 'concurrent').  The
solution is simple enough.



-- Lon



From gang.wei at intel.com  Wed Nov 21 03:24:58 2012
From: gang.wei at intel.com (Wei, Gang)
Date: Wed, 21 Nov 2012 03:24:58 +0000
Subject: [Engine-devel] Trusted Compute Pools
In-Reply-To: <211734567.11864474.1353428414476.JavaMail.root@redhat.com>
References: <D0B11485C64D4B47B66902F8A4E901BE3FCDA2@SHSMSX101.ccr.corp.intel.com>
	<211734567.11864474.1353428414476.JavaMail.root@redhat.com>
Message-ID: <D0B11485C64D4B47B66902F8A4E901BE3FF167@SHSMSX101.ccr.corp.intel.com>

Great to see interests.

Laszlo Hornyak wrote on 2012-11-21:
> Hi,
>
> Interesting technology. Some questions:
> - There will be 1 and only one attestation server installed per ovirt 
> instance or
> per trusted pool?

By far, I expect 1 and only one attestation server installed per ovirt 
instance. Maybe different ovirt instances can also shall attestation server, 
if all hosts under differenct ovirt instances are accessible by the 
attestation server and are able to access the attestation server.

> - Could engine cache the data it received from the attestation server, or 
> does it
> have to query each time a trusted VM needs to be started?

The basic case is query each time a trusted VM needs to be started, the 
advance case is engine cache the data with some practical cache invalidation 
timing/policy.

The cache feature might also be able to be implemented inside the attestation 
server.

Thanks
Jimmy

>
> Thank you,
> Laszlo
>
> ----- Original Message -----
>> From: "Gang Wei" <gang.wei at intel.com>
>> To: engine-devel at ovirt.org
>> Sent: Tuesday, November 20, 2012 2:06:09 PM
>> Subject: [Engine-devel] Trusted Compute Pools
>>
>> Hi,
>>
>> I am an engineer working in Intel Open Source Technology Center,
>> interested
>> in integrating Intel initiated OpenAttestation(OAT) project
>> (https://github.com/OpenAttestation/OpenAttestation.git) into oVirt
>> to
>> provide a way for Administrator to deploy VMs on trusted hosts
>> hardened with
>> H/W-based security features, such as Intel TXT.
>>
>> I made a draft feature page for this:
>> http://wiki.ovirt.org/wiki/Trusted_compute_pools
>>
>> My draft idea is to provide trust_level requirement while doing vm
>> creation
>> like below:
>>
>> curl -v -u "vdcadmin at qa.lab.tlv.redhat.com"
>>     -H "Content-type: application/xml"
>>     -d '<vm><name>my_new_vm</name>
>> <cluster id="99408929-82cf-4dc7-a532-9d998063fa95" />
>> <template id="00000000-0000-0000-0000-000000000000"/>
>> <trust_level>trusted</trust_level></vm>'
>>     'http://10.35.1.1/rhevm-api/vms'
>> Then oVirt Engine should query attestation server built with OAT via
>> RESTful
>> API to get all trusted hosts and select one to create the VM.
>>
>> Attestation server performs host verification through following
>> steps:
>> 1. Hosts boot with Intel TXT technology enabled
>> 2. The hosts' BIOS, hypervisor and OS are measured
>> 3. These measured data is sent to Attestation server when challenged
>> by
>> attestation server
>> 4. Attestation server verifies those measurements against good/known
>> database to determine hosts' trustworthiness
>>
>> Hosts need to be installed with OAT host agent to report host
>> integrity to
>> attestation server.
>>
>> By far, I am still in process of getting familiar with oVirt code and
>> not
>> get solid idea yet on how the oVirt Engine should be modified to
>> support
>> this feature.
>>
>> Any kind of comments or suggestions will be highly appreciated.
>>
>> Thanks
>> Gang (Jimmy) Wei
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 8586 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121121/c4c2fc61/attachment.p7s>

From mpastern at redhat.com  Wed Nov 21 11:05:06 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Wed, 21 Nov 2012 13:05:06 +0200
Subject: [Engine-devel] ovirt-sdk 3.2.0.5 released
Message-ID: <50ACB562.5040705@redhat.com>


For more details see [1].

[1] http://wiki.ovirt.org/wiki/SDK#Change_Log


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From dfediuck at redhat.com  Wed Nov 21 12:45:00 2012
From: dfediuck at redhat.com (Doron Fediuck)
Date: Wed, 21 Nov 2012 07:45:00 -0500 (EST)
Subject: [Engine-devel] ovirt-sdk 3.2.0.5 released
In-Reply-To: <50ACB562.5040705@redhat.com>
Message-ID: <1942864931.29342888.1353501900464.JavaMail.root@redhat.com>

Change log hides here: http://wiki.ovirt.org/wiki/Sdk-changelog

----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Cc: users at ovirt.org, "Romil Gupta" <romilgupta19 at gmail.com>
> Sent: Wednesday, November 21, 2012 1:05:06 PM
> Subject: [Engine-devel] ovirt-sdk 3.2.0.5 released
> 
> 
> For more details see [1].
> 
> [1] http://wiki.ovirt.org/wiki/SDK#Change_Log
> 
> 
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From dneary at redhat.com  Wed Nov 21 13:57:20 2012
From: dneary at redhat.com (Dave Neary)
Date: Wed, 21 Nov 2012 14:57:20 +0100
Subject: [Engine-devel] UI plugins crash course part two (for plugin
	developers)
In-Reply-To: <670870582.7319531.1353336578842.JavaMail.root@redhat.com>
References: <670870582.7319531.1353336578842.JavaMail.root@redhat.com>
Message-ID: <50ACDDC0.3000604@redhat.com>

Hi Vojtech,

This is great!

Would you be interested in writing this up as a tutorial series (working 
through a real-life example) for publication on the oVirt website? I 
think it's the kind of article which would be very useful in promoting 
the plug-in API.

Cheers,
Dave.

On 11/19/2012 03:49 PM, Vojtech Szocs wrote:
> Hi guys,
>
> this is a follow-up on the quick "crash course" for writing simple UI plugin.
>
> Before we proceed, please keep in mind that:
> - api.register() must be called exactly once, subsequent calls "overwrite" previous ones
> - api.register() must be called before api.ready(), otherwise your plugin will not work
> - you don't have to define all supported event handler functions in api.register(), just the ones your plugin is interested in (e.g. UiInit)
>
>
> Level 4 - Let's make things configurable
> ========================================
>
> 1. Specify default plugin configuration (optional)
> $ vim /usr/share/ovirt-engine/ui-plugins/hello-ui-world.json
>
> [hello-ui-world.json]
> ...
>    "config": { "testLink": "http://www.example.com/" }
> ...
> [/hello-ui-world.json]
>
> 2. Override default plugin configuration (optional)
> $ mkdir -p /etc/ovirt-engine/ui-plugins
> $ vim /etc/ovirt-engine/ui-plugins/hello-ui-world-config.json
>
> [hello-ui-world-config.json]
> {
>    "config": { "testLink": "http://www.another-example.com/" }
> }
> [/hello-ui-world-config.json]
>
> 3. Use plugin configuration that has been merged together
> $ vim /usr/share/ovirt-engine/ui-plugins/hello-world-files/start.html
>
> [start.html]
> ...
> # Anywhere within event handler function code (e.g. UiInit)
> var conf = api.configObject();
> api.showDialog('Test Dialog', conf.testLink, 600, 400);
> ...
> [/start.html]
>
>
> Regards,
> Vojtech
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>

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


From satimis at yahoo.com  Wed Nov 21 14:20:51 2012
From: satimis at yahoo.com (Stephen Liu)
Date: Wed, 21 Nov 2012 06:20:51 -0800 (PST)
Subject: [Engine-devel] Testing failed
Message-ID: <1353507651.18217.YahooMailNeo@web125106.mail.ne1.yahoo.com>

Hi all

Fedora 17 64bit

# cd /home/satimis/jboss-as/bin
# ./standalone.sh -b 0.0.0.0
......
......
./standalone.sh: line 178:? 2121 Aborted???????????????? (core dumped) "java" -D"[Standalone]" -server -XX:+UseCompressedOops -XX:+TieredCompilation -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -Djboss.server.default.config=standalone.xml "-Dorg.jboss.boot.log.file=/home/satimis/jboss-as/standalone/log/boot.log" "-Dlogging.configuration=file:/home/satimis/jboss-as/standalone/configuration/logging.properties" -jar "/home/satimis/jboss-as/jboss-modules.jar" -mp "/home/satimis/jboss-as/modules" -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -Djboss.home.dir="/home/satimis/jboss-as" -b 0.0.0.0

Pls help


Re running:-

http://<server name>:<port>/api

server name?  Is it the hostname of Fedora17?

# hostname
fedora17


TIA

B.R
Stephen L



From yzaslavs at redhat.com  Wed Nov 21 14:53:49 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Wed, 21 Nov 2012 16:53:49 +0200
Subject: [Engine-devel] Testing failed
In-Reply-To: <1353507651.18217.YahooMailNeo@web125106.mail.ne1.yahoo.com>
References: <1353507651.18217.YahooMailNeo@web125106.mail.ne1.yahoo.com>
Message-ID: <50ACEAFD.4080905@redhat.com>



On 11/21/2012 04:20 PM, Stephen Liu wrote:
> Hi all
>
> Fedora 17 64bit
>
> # cd /home/satimis/jboss-as/bin
> # ./standalone.sh -b 0.0.0.0
> ......
> ......
> ./standalone.sh: line 178:  2121 Aborted                 (core dumped) "java" -D"[Standalone]" -server -XX:+UseCompressedOops -XX:+TieredCompilation -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -Djboss.server.default.config=standalone.xml "-Dorg.jboss.boot.log.file=/home/satimis/jboss-as/standalone/log/boot.log" "-Dlogging.configuration=file:/home/satimis/jboss-as/standalone/configuration/logging.properties" -jar "/home/satimis/jboss-as/jboss-modules.jar" -mp "/home/satimis/jboss-as/modules" -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -Djboss.home.dir="/home/satimis/jboss-as" -b 0.0.0.0
>
> Pls help
>
>
> Re running:-
>
> http://<server name>:<port>/api
>
> server name?  Is it the hostname of Fedora17?

Hi,

The hostname of the server that runs the Jboss AS
>
> # hostname
> fedora17
>
>
> TIA
>
> B.R
> Stephen L
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>


From masayag at redhat.com  Wed Nov 21 17:36:58 2012
From: masayag at redhat.com (Moti Asayag)
Date: Wed, 21 Nov 2012 19:36:58 +0200
Subject: [Engine-devel] Report  vNic Implementation Details
Message-ID: <50AD113A.6030800@redhat.com>

Hi all,

This is a proposal for reporting the vNic implementation details as
reported by the guest agent per each vNic.

Please review the wiki and add your comments.

http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation

Thanks,
Moti


From acathrow at redhat.com  Wed Nov 21 20:53:23 2012
From: acathrow at redhat.com (Andrew Cathrow)
Date: Wed, 21 Nov 2012 15:53:23 -0500 (EST)
Subject: [Engine-devel] Report  vNic Implementation Details
In-Reply-To: <50AD113A.6030800@redhat.com>
Message-ID: <1050167732.29778605.1353531203790.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Moti Asayag" <masayag at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Wednesday, November 21, 2012 12:36:58 PM
> Subject: [Engine-devel] Report  vNic Implementation Details
> 
> Hi all,
> 
> This is a proposal for reporting the vNic implementation details as
> reported by the guest agent per each vNic.
> 
> Please review the wiki and add your comments.


While we're making the change is there anything else we'd want to report - MTU, MAC (since a user might try to override), etc ?



> 
> http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
> 
> Thanks,
> Moti
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From jhernand at redhat.com  Wed Nov 21 21:55:45 2012
From: jhernand at redhat.com (Juan Hernandez)
Date: Wed, 21 Nov 2012 22:55:45 +0100
Subject: [Engine-devel] Testing failed
In-Reply-To: <1353507651.18217.YahooMailNeo@web125106.mail.ne1.yahoo.com>
References: <1353507651.18217.YahooMailNeo@web125106.mail.ne1.yahoo.com>
Message-ID: <50AD4DE1.3030202@redhat.com>

On 11/21/2012 03:20 PM, Stephen Liu wrote:
> Hi all
> 
> Fedora 17 64bit
> 
> # cd /home/satimis/jboss-as/bin
> # ./standalone.sh -b 0.0.0.0
> ......
> ......
> ./standalone.sh: line 178:  2121 Aborted                 (core dumped) "java" -D"[Standalone]" -server -XX:+UseCompressedOops -XX:+TieredCompilation -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -Djboss.server.default.config=standalone.xml "-Dorg.jboss.boot.log.file=/home/satimis/jboss-as/standalone/log/boot.log" "-Dlogging.configuration=file:/home/satimis/jboss-as/standalone/configuration/logging.properties" -jar "/home/satimis/jboss-as/jboss-modules.jar" -mp "/home/satimis/jboss-as/modules" -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -Djboss.home.dir="/home/satimis/jboss-as" -b 0.0.0.0

That is a really severe problem, it means that your Java Virtual Machine
really crashed, probably due to a bug in the JVM itself, very unusual.

Is this something that you reproduce easily? Is that all what you get as
output? Don't you get something like this:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f84b36f85fe, pid=30284, tid=140208179570432
#
# JRE version: 7.0_09
# Java VM: OpenJDK 64-Bit Server VM (23.2-b09 mixed mode linux-amd64
compressed oops)
# Problematic frame:

Or maybe a "hs_err_pid*.log" file?

The information there could be useful to find cause of the problem.

> 
> Pls help
> 
> 
> Re running:-
> 
> http://<server name>:<port>/api
> 
> server name?  Is it the hostname of Fedora17?
> 
> # hostname
> fedora17


-- 
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 jhernand at redhat.com  Wed Nov 21 22:01:02 2012
From: jhernand at redhat.com (Juan Hernandez)
Date: Wed, 21 Nov 2012 23:01:02 +0100
Subject: [Engine-devel] Testing failed
In-Reply-To: <50AD4DE1.3030202@redhat.com>
References: <1353507651.18217.YahooMailNeo@web125106.mail.ne1.yahoo.com>
	<50AD4DE1.3030202@redhat.com>
Message-ID: <50AD4F1E.9030305@redhat.com>

On 11/21/2012 10:55 PM, Juan Hernandez wrote:
> On 11/21/2012 03:20 PM, Stephen Liu wrote:
>> Hi all
>>
>> Fedora 17 64bit
>>
>> # cd /home/satimis/jboss-as/bin
>> # ./standalone.sh -b 0.0.0.0

By the way, I see here the # prompt. Does that mean that you are running
the application server with the root user? That is very bad idea.
Shouldn't make your JVM crash, but better avoid it, use your satimis
user instead.

If you already ran with root some of the files will probably have been
created with root as owner, so you will probably need to fix them:

sudo chown --recursive satimis:satimis /home/satimis/jboss-as

-- 
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 iheim at redhat.com  Wed Nov 21 22:02:35 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 22 Nov 2012 00:02:35 +0200
Subject: [Engine-devel] Report  vNic Implementation Details
In-Reply-To: <1050167732.29778605.1353531203790.JavaMail.root@redhat.com>
References: <1050167732.29778605.1353531203790.JavaMail.root@redhat.com>
Message-ID: <50AD4F7B.3000407@redhat.com>

On 11/21/2012 10:53 PM, Andrew Cathrow wrote:
>
>
> ----- Original Message -----
>> From: "Moti Asayag" <masayag at redhat.com>
>> To: engine-devel at ovirt.org
>> Sent: Wednesday, November 21, 2012 12:36:58 PM
>> Subject: [Engine-devel] Report  vNic Implementation Details
>>
>> Hi all,
>>
>> This is a proposal for reporting the vNic implementation details as
>> reported by the guest agent per each vNic.
>>
>> Please review the wiki and add your comments.
>
>
> While we're making the change is there anything else we'd want to report - MTU, MAC (since a user might try to override), etc ?
>>
>> http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation

iirc, the fact ip addresses appear under guest info in the api and not 
under the vnic was a modeling decision.
for example, what if guest is using a bridge, or a bond (yes, sounds 
unlikely, but the point is it may be incorrect to assume ip-vnic relation.
michael - do you remember the details of that discussion?



From iheim at redhat.com  Wed Nov 21 23:06:11 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 22 Nov 2012 01:06:11 +0200
Subject: [Engine-devel] Atlassian Crowd Support for Ovirt
In-Reply-To: <zarafa.50aa3b4f.1ca0.741618210ffe7b52@Snoopy>
References: <zarafa.50aa3b4f.1ca0.741618210ffe7b52@Snoopy>
Message-ID: <50AD5E63.5000603@redhat.com>

On 11/19/2012 03:59 PM, Justin Hammond wrote:
> Hi All,
>
> I've just uploaded to Gerrit a patch that adds atlassian crowd
> authentication support to oVirt.(http://gerrit.ovirt.org/9324)
>
> All the nitty gritty details are in the commit message, but basically
> this adds a new authentication domain, and when selected sends the
> authentication request off to a crowd server.
>
> We have been using this patch on 3.1 for a while, and I thought its
> overdue to see if you guys are interested in taking this upstream?
>
> There are two areas that I know could use improvements:
>
> 1) caching the results from the crowd server, so we don't query for
> every API request etc.
>
> 2) adding proper memberOf support so groups work correctly.
>
> Please let me know if you guys are interested in this, and please be
> gentle on your reviews - I? not a Java Programmer by any means, and
> probably brought too many C++ traits over here... :)
>

i thought worth mentioning to anyone seeing this thread that there is an 
active discussion on the patch.
main non technical issue is trying to understand which license the crowd 
library would be under.


From satimis at yahoo.com  Thu Nov 22 02:27:28 2012
From: satimis at yahoo.com (Stephen Liu)
Date: Wed, 21 Nov 2012 18:27:28 -0800 (PST)
Subject: [Engine-devel] Testing failed
In-Reply-To: <50AD4F1E.9030305@redhat.com>
References: <1353507651.18217.YahooMailNeo@web125106.mail.ne1.yahoo.com>
	<50AD4DE1.3030202@redhat.com> <50AD4F1E.9030305@redhat.com>
Message-ID: <1353551248.14680.YahooMailNeo@web125104.mail.ne1.yahoo.com>





----- Original Message -----
> From: Juan Hernandez <jhernand at redhat.com>
> To: Stephen Liu <satimis at yahoo.com>
> Cc: "engine-devel at ovirt.org" <engine-devel at ovirt.org>
> Sent: Thursday, November 22, 2012 6:01 AM
> Subject: Re: [Engine-devel] Testing failed

- snip -

>>>  # cd /home/satimis/jboss-as/bin
>>>  # ./standalone.sh -b 0.0.0.0
> 
> By the way, I see here the # prompt. Does that mean that you are running
> the application server with the root user? That is very bad idea.
> Shouldn't make your JVM crash, but better avoid it, use your satimis
> user instead.

I was following the steps on "Testing" on
http://wiki.ovirt.org/wiki/Building_Engine_Draft#Testing

Besides, 
#> cd $JBOSS_HOME/bin> 
never brought me to "jboss-as" directory.? I have to running the command on full path;

#> cd /home/satimis/jboss-as

> If you already ran with root some of the files will probably have been
> created with root as owner, so you will probably need to fix them:
> 
> sudo chown --recursive satimis:satimis /home/satimis/jboss-as

The directory is already owned by satimis:satimis including all files on that directory

$ ls -ald /home/satimis/jboss-as
drwxrwxr-x. 11 satimis satimis 4096 Nov 16 17:57 /home/satimis/jboss-as

$ ls -al /home/satimis/jboss-as/
total 260616
drwxrwxr-x. 11 satimis satimis????? 4096 Nov 16 17:57 .
drwx------. 30 satimis satimis????? 4096 Nov 22 10:15 ..
drwxr-xr-x.? 3 satimis satimis????? 4096 Mar 10? 2012 appclient
drwxr-xr-x.? 5 satimis satimis????? 4096 Nov 21 22:07 bin
drwxr-xr-x.? 4 satimis satimis????? 4096 Mar 10? 2012 bundles
-rw-r--r--.? 1 satimis satimis????? 2451 Mar 10? 2012 copyright.txt
drwxr-xr-x.? 4 satimis satimis????? 4096 Mar 10? 2012 docs
drwxr-xr-x.? 5 satimis satimis????? 4096 Mar 10? 2012 domain
drwxr-xr-x. 10 satimis satimis????? 4096 Nov 16 17:57 jboss-as-7.1.1.Final
-rw-rw-r--.? 1 satimis satimis 133255203 Mar 10? 2012 jboss-as-7.1.1.Final.zip
-rw-rw-r--.? 1 satimis satimis 133255203 Mar 10? 2012 jboss-as-7.1.1.Final.zip.1
-rw-r--r--.? 1 satimis satimis??? 266549 Mar 10? 2012 jboss-modules.jar
-rw-r--r--.? 1 satimis satimis???? 26530 Mar 10? 2012 LICENSE.txt
drwxr-xr-x. 13 satimis satimis????? 4096 Mar 10? 2012 modules
-rw-r--r--.? 1 satimis satimis????? 2421 Mar 10? 2012 README.txt
drwxr-xr-x.? 8 satimis satimis????? 4096 Nov 14 15:04 standalone
drwxr-xr-x.? 2 satimis satimis????? 4096 Mar 10? 2012 welcome-content


B.R.
Stephen L



> -- 
> 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 iheim at redhat.com  Thu Nov 22 06:35:56 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 22 Nov 2012 08:35:56 +0200
Subject: [Engine-devel] Design review summary for 3.2 - adding support
 for	External Events
In-Reply-To: <D290AD8432118048947689BA3AE8A9B3EBCE94@SACEXCMBX04-PRD.hq.netapp.com>
References: <655371690.12140101.1353359372942.JavaMail.root@redhat.com>
	<648646156.12237730.1353384965957.JavaMail.root@redhat.com>
	<D290AD8432118048947689BA3AE8A9B3EBCE94@SACEXCMBX04-PRD.hq.netapp.com>
Message-ID: <50ADC7CC.1070901@redhat.com>

On 11/20/2012 04:07 PM, Morrissey, Christopher wrote:
...

>>>> Hi Eli,
>>>>
>>>> I've perused the design and it looks very good for the purpose of
>>>> adding events to the log as back end tasks on the NetApp VSC are
>>>> started and complete.
>>>>
>>>> I do have one question. As part of the new UI plugin framework that
>>>> Vojtech is working on he added the capability to retrieve a session
>>>> ID that will be used outside of the oVirt engine to invoke REST API
>>>> calls. I'm assuming this session would have the same role as the
>>>> user that is currently logged in.
>>>>
>>>> According to the event log design, only the Super user will have
>>>> permissions to add events by default. This would mean that if anyone
>>>> other than the super user is logged in and performing any tasks
>>>> through the NetApp plugin, the server side of the VSC will likely
>>>> not be able to log events. This could be confusing for users as
>>>> sometimes they see events showing up giving them information on the
>>>> task progress and sometimes they don't depending on the role logged
>>>> in.
>>>>
>>>> Would it make sense to allow all roles to log events by default?
>>>> I'm
>>>> not sure what security problems would arise given that it is just a
>>>> log and they would be tagged as external events.
>>>
>>> Hi Christopher, our security model implies a black-list,
>>
>> oops, I meant white-list of course ....
>>
>
> That's what I figured. :)
>
>> so, I don;t
>>> think this is possible
>>> But still, a super-user can of course give the permission to add new
>>> events to all Roles in the system and you will have the same result.
>>> Does that make sense ?
>>>
>
> That does make sense. We'll likely just try to use the API to log events when starting a task and if we receive an error we can bubble that up to the user letting them know that they need to either get the right permission or accept that they won't get messages in the oVirt log while the task completes.

Eli - not that the design includes checking for permissions on objects, 
why wouldn't we add this permission (ActionGroup) to other admin roles 
as well?
this is only for admin roles, not user roles. what's the risk in 
allowing admins to inject external events?


From lpeer at redhat.com  Thu Nov 22 07:48:19 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Thu, 22 Nov 2012 09:48:19 +0200
Subject: [Engine-devel] Report  vNic Implementation Details
In-Reply-To: <1050167732.29778605.1353531203790.JavaMail.root@redhat.com>
References: <1050167732.29778605.1353531203790.JavaMail.root@redhat.com>
Message-ID: <50ADD8C3.9060807@redhat.com>

On 21/11/12 22:53, Andrew Cathrow wrote:
> 
> 
> ----- Original Message -----
>> From: "Moti Asayag" <masayag at redhat.com>
>> To: engine-devel at ovirt.org
>> Sent: Wednesday, November 21, 2012 12:36:58 PM
>> Subject: [Engine-devel] Report  vNic Implementation Details
>>
>> Hi all,
>>
>> This is a proposal for reporting the vNic implementation details as
>> reported by the guest agent per each vNic.
>>
>> Please review the wiki and add your comments.
> 
> 
> While we're making the change is there anything else we'd want to report - MTU, MAC (since a user might try to override), etc ?
> 

About the MAC address - the engine uses the MAC address to correlate
between the guest-agent report and the VNICs defined in the engine. If
the GA reports a MAC that the engine does not recognize the engine can
not associate it with a VNIC.
What the engine can do is to issue a warning to the audit log in case
such a mismatch is recognized, Is that good enough?


About MTU - It is not being reported by the guest agent ATM (while IPv4
IPv6 and MAC are), If we'd like to have it I can open RFE for the GA to
report additional fields.

Livnat


> 
> 
>>
>> http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
>>
>> Thanks,
>> Moti
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 



From lpeer at redhat.com  Thu Nov 22 07:55:43 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Thu, 22 Nov 2012 09:55:43 +0200
Subject: [Engine-devel] Report  vNic Implementation Details
In-Reply-To: <50AD4F7B.3000407@redhat.com>
References: <1050167732.29778605.1353531203790.JavaMail.root@redhat.com>
	<50AD4F7B.3000407@redhat.com>
Message-ID: <50ADDA7F.70506@redhat.com>

On 22/11/12 00:02, Itamar Heim wrote:
> On 11/21/2012 10:53 PM, Andrew Cathrow wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Moti Asayag" <masayag at redhat.com>
>>> To: engine-devel at ovirt.org
>>> Sent: Wednesday, November 21, 2012 12:36:58 PM
>>> Subject: [Engine-devel] Report  vNic Implementation Details
>>>
>>> Hi all,
>>>
>>> This is a proposal for reporting the vNic implementation details as
>>> reported by the guest agent per each vNic.
>>>
>>> Please review the wiki and add your comments.
>>
>>
>> While we're making the change is there anything else we'd want to
>> report - MTU, MAC (since a user might try to override), etc ?
>>>
>>> http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
> 
> iirc, the fact ip addresses appear under guest info in the api and not
> under the vnic was a modeling decision.
> for example, what if guest is using a bridge, or a bond (yes, sounds
> unlikely, but the point is it may be incorrect to assume ip-vnic relation.
> michael - do you remember the details of that discussion?

I'd love to know what drove this modeling decision.
The use case above is not a typical use case.
We know we won't be able to present the guest internal network
configuration accurately in some scenarios but if we cover 90% of the
use cases correctly I think we should not let perfect be the enemy of
(very) good ;)

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



From satimis at yahoo.com  Thu Nov 22 10:58:53 2012
From: satimis at yahoo.com (Stephen Liu)
Date: Thu, 22 Nov 2012 02:58:53 -0800 (PST)
Subject: [Engine-devel] Testing failed
In-Reply-To: <50ACEAFD.4080905@redhat.com>
References: <1353507651.18217.YahooMailNeo@web125106.mail.ne1.yahoo.com>
	<50ACEAFD.4080905@redhat.com>
Message-ID: <1353581933.49895.YahooMailNeo@web125105.mail.ne1.yahoo.com>

----- Original Message -----

> From: Yair Zaslavsky <yzaslavs at redhat.com>
> To: Stephen Liu <satimis at yahoo.com>
> Cc: "engine-devel at ovirt.org" <engine-devel at ovirt.org>
> Sent: Wednesday, November 21, 2012 10:53 PM
> Subject: Re: [Engine-devel] Testing failed

- snip -

>>  Re running:-
>> 
>>  http://<server name>:<port>/api
>> 
>>  server name?? Is it the hostname of Fedora17?
> 
> Hi,
> 
> The hostname of the server that runs the Jboss AS

Hi,

Could you please explain in more detail?

Jboss AS is running on Fedora.? On the latter's terminal running;

$ hostname
fedora17

$ hostname -f
fedora17

I suppose "fedora17" is the hostname of the server where Jboss AS is now running.

Thanks

B.R.
Stephen L



From emesika at redhat.com  Thu Nov 22 11:20:46 2012
From: emesika at redhat.com (Eli Mesika)
Date: Thu, 22 Nov 2012 06:20:46 -0500 (EST)
Subject: [Engine-devel] Design review summary for 3.2 - Host Power
 Management Multiple Agent Support
Message-ID: <982772266.13431306.1353583246034.JavaMail.root@redhat.com>

http://wiki.ovirt.org/wiki/Talk:HostPMMultipleAgents

Regards

Eli Mesika


From danken at redhat.com  Thu Nov 22 11:59:22 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Thu, 22 Nov 2012 13:59:22 +0200
Subject: [Engine-devel] Report  vNic Implementation Details
In-Reply-To: <50ADDA7F.70506@redhat.com>
References: <1050167732.29778605.1353531203790.JavaMail.root@redhat.com>
	<50AD4F7B.3000407@redhat.com> <50ADDA7F.70506@redhat.com>
Message-ID: <20121122115921.GJ4557@redhat.com>

On Thu, Nov 22, 2012 at 09:55:43AM +0200, Livnat Peer wrote:
> On 22/11/12 00:02, Itamar Heim wrote:
> > On 11/21/2012 10:53 PM, Andrew Cathrow wrote:
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Moti Asayag" <masayag at redhat.com>
> >>> To: engine-devel at ovirt.org
> >>> Sent: Wednesday, November 21, 2012 12:36:58 PM
> >>> Subject: [Engine-devel] Report  vNic Implementation Details
> >>>
> >>> Hi all,
> >>>
> >>> This is a proposal for reporting the vNic implementation details as
> >>> reported by the guest agent per each vNic.
> >>>
> >>> Please review the wiki and add your comments.
> >>
> >>
> >> While we're making the change is there anything else we'd want to
> >> report - MTU, MAC (since a user might try to override), etc ?
> >>>
> >>> http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
> > 
> > iirc, the fact ip addresses appear under guest info in the api and not
> > under the vnic was a modeling decision.
> > for example, what if guest is using a bridge, or a bond (yes, sounds
> > unlikely, but the point is it may be incorrect to assume ip-vnic relation.
> > michael - do you remember the details of that discussion?
> 
> I'd love to know what drove this modeling decision.
> The use case above is not a typical use case.
> We know we won't be able to present the guest internal network
> configuration accurately in some scenarios but if we cover 90% of the
> use cases correctly I think we should not let perfect be the enemy of
> (very) good ;)

We do not support this yet, but once we have nested virtualization, it
won't be that odd to have a bridge or bond in the guest. I know that we
already have users with in-guest vlan devices.

I think that the api should accomodate these configurations - even if we
do not report them right away. The guest agent already reports (some) of
the information:

> The Guest Agent reports the vNic details:
> 
>     IP addresses (both IPv4 and IPv6).
>     vNic internal name 

Actually, the guest agent reports all in-guest network device. vNics (and bonds
and vlans) included.
> 
> The retrieved information by the Guest Agent should be reported to the ovirt-engine and to be viewed by its client
> Today only the IPv4 addresses are reported to the User, kept on VM level. This feature will maintain the information on vNic level.

I think we should report the information on the vNic level only when we
can. If we have a vlan device, which we do not know how tie to a
specific vNic, we'd better report its IP address on the VM level.

It might be worthwhile to note that we should (try to) correlate Engine
idea of a vNic with the guest agent report, according to the mac address.
The guest can try to fool us by changing the mac address, but that's
true for every bit of info coming from the agent.

Dan.


From danken at redhat.com  Thu Nov 22 12:05:33 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Thu, 22 Nov 2012 14:05:33 +0200
Subject: [Engine-devel] Report  vNic Implementation Details
In-Reply-To: <50ADD8C3.9060807@redhat.com>
References: <1050167732.29778605.1353531203790.JavaMail.root@redhat.com>
	<50ADD8C3.9060807@redhat.com>
Message-ID: <20121122120533.GK4557@redhat.com>

On Thu, Nov 22, 2012 at 09:48:19AM +0200, Livnat Peer wrote:
> On 21/11/12 22:53, Andrew Cathrow wrote:
> > 
> > 
> > ----- Original Message -----
> >> From: "Moti Asayag" <masayag at redhat.com>
> >> To: engine-devel at ovirt.org
> >> Sent: Wednesday, November 21, 2012 12:36:58 PM
> >> Subject: [Engine-devel] Report  vNic Implementation Details
> >>
> >> Hi all,
> >>
> >> This is a proposal for reporting the vNic implementation details as
> >> reported by the guest agent per each vNic.
> >>
> >> Please review the wiki and add your comments.
> > 
> > 
> > While we're making the change is there anything else we'd want to report - MTU, MAC (since a user might try to override), etc ?
> > 
> 
> About the MAC address - the engine uses the MAC address to correlate
> between the guest-agent report and the VNICs defined in the engine. If
> the GA reports a MAC that the engine does not recognize the engine can
> not associate it with a VNIC.
> What the engine can do is to issue a warning to the audit log in case
> such a mismatch is recognized, Is that good enough?

Oops, I've been scooped...
The guest may also report devices with unknown MAC (bridge, vlan, dummy,
etc...), which is not a reason for alarm.
If the configured MAC is completely missing, a warning seems valid.

>
> About MTU - It is not being reported by the guest agent ATM (while IPv4
> IPv6 and MAC are), If we'd like to have it I can open RFE for the GA to
> report additional fields.


From eedri at redhat.com  Thu Nov 22 14:16:37 2012
From: eedri at redhat.com (Eyal Edri)
Date: Thu, 22 Nov 2012 09:16:37 -0500 (EST)
Subject: [Engine-devel] Proposal of Alon bar-lev as oVirt jenkins power user
In-Reply-To: <649061191.4513905.1353593615217.JavaMail.root@redhat.com>
Message-ID: <1673165523.4516436.1353593797929.JavaMail.root@redhat.com>

Hi,

To continue our new tradition of delegating power users for various oVirt sub project management in jenkins,

I want to propose Alon bar-lev as power user for oVirt jenkins.
Alon is well known within the oVirt community, and been contributing it in the past months.

Alon has contributed code to many oVirt projects including massive re-factoring of the bootstrap process and
numerous patches on other oVirt projects, Latest projects are otopi and ovirt-host-deploy.

He is very technical with previous knowledge of Jenkins.

as a power user he will be to:

1. create/update new jobs in jenkins.ovirt.org
2. run/trigger builds
3. run manual gerrit trigger jobs.


i vote +1.

please vote confidence with +1 or -1 for not.

thanks,

Eyal Edri.


From vfeenstr at redhat.com  Thu Nov 22 15:32:02 2012
From: vfeenstr at redhat.com (Vinzenz Feenstra)
Date: Thu, 22 Nov 2012 16:32:02 +0100
Subject: [Engine-devel] Report  vNic Implementation Details
In-Reply-To: <50ADD8C3.9060807@redhat.com>
References: <1050167732.29778605.1353531203790.JavaMail.root@redhat.com>
	<50ADD8C3.9060807@redhat.com>
Message-ID: <50AE4572.9060203@redhat.com>

On 11/22/2012 08:48 AM, Livnat Peer wrote:
> On 21/11/12 22:53, Andrew Cathrow wrote:
>>
>> ----- Original Message -----
>>> From: "Moti Asayag" <masayag at redhat.com>
>>> To: engine-devel at ovirt.org
>>> Sent: Wednesday, November 21, 2012 12:36:58 PM
>>> Subject: [Engine-devel] Report  vNic Implementation Details
>>>
>>> Hi all,
>>>
>>> This is a proposal for reporting the vNic implementation details as
>>> reported by the guest agent per each vNic.
>>>
>>> Please review the wiki and add your comments.
>>
>> While we're making the change is there anything else we'd want to report - MTU, MAC (since a user might try to override), etc ?
>>
> About the MAC address - the engine uses the MAC address to correlate
> between the guest-agent report and the VNICs defined in the engine. If
> the GA reports a MAC that the engine does not recognize the engine can
> not associate it with a VNIC.
> What the engine can do is to issue a warning to the audit log in case
> such a mismatch is recognized, Is that good enough?
>
>
> About MTU - It is not being reported by the guest agent ATM (while IPv4
> IPv6 and MAC are), If we'd like to have it I can open RFE for the GA to
> report additional fields.
Well if there are changes needed for the GA, please let me know soon, if 
it should make it into 3.2.
Thanks.
>
> Livnat
>
>
>>
>>> http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
>>>
>>> Thanks,
>>> Moti
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel


-- 
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com



From ykaul at redhat.com  Thu Nov 22 15:36:39 2012
From: ykaul at redhat.com (Yaniv Kaul)
Date: Thu, 22 Nov 2012 17:36:39 +0200
Subject: [Engine-devel] Report  vNic Implementation Details
In-Reply-To: <1050167732.29778605.1353531203790.JavaMail.root@redhat.com>
References: <1050167732.29778605.1353531203790.JavaMail.root@redhat.com>
Message-ID: <50AE4687.4000902@redhat.com>

On 11/21/2012 10:53 PM, Andrew Cathrow wrote:
>
> ----- Original Message -----
>> From: "Moti Asayag" <masayag at redhat.com>
>> To: engine-devel at ovirt.org
>> Sent: Wednesday, November 21, 2012 12:36:58 PM
>> Subject: [Engine-devel] Report  vNic Implementation Details
>>
>> Hi all,
>>
>> This is a proposal for reporting the vNic implementation details as
>> reported by the guest agent per each vNic.
>>
>> Please review the wiki and add your comments.
>
> While we're making the change is there anything else we'd want to report - MTU, MAC (since a user might try to override), etc ?

Do we support change of MAC from within the VM? Is it even working?
Y.


>
>
>
>> http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
>>
>> Thanks,
>> Moti
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From acathrow at redhat.com  Thu Nov 22 15:38:48 2012
From: acathrow at redhat.com (Andrew Cathrow)
Date: Thu, 22 Nov 2012 10:38:48 -0500 (EST)
Subject: [Engine-devel] Report  vNic Implementation Details
In-Reply-To: <50AE4687.4000902@redhat.com>
Message-ID: <1306347951.30055751.1353598728111.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Yaniv Kaul" <ykaul at redhat.com>
> To: "Andrew Cathrow" <acathrow at redhat.com>
> Cc: "Moti Asayag" <masayag at redhat.com>, "Simon Grinberg" <simon at redhat.com>, engine-devel at ovirt.org
> Sent: Thursday, November 22, 2012 10:36:39 AM
> Subject: Re: [Engine-devel] Report  vNic Implementation Details
> 
> On 11/21/2012 10:53 PM, Andrew Cathrow wrote:
> >
> > ----- Original Message -----
> >> From: "Moti Asayag" <masayag at redhat.com>
> >> To: engine-devel at ovirt.org
> >> Sent: Wednesday, November 21, 2012 12:36:58 PM
> >> Subject: [Engine-devel] Report  vNic Implementation Details
> >>
> >> Hi all,
> >>
> >> This is a proposal for reporting the vNic implementation details
> >> as
> >> reported by the guest agent per each vNic.
> >>
> >> Please review the wiki and add your comments.
> >
> > While we're making the change is there anything else we'd want to
> > report - MTU, MAC (since a user might try to override), etc ?
> 
> Do we support change of MAC from within the VM? Is it even working?
> Y.

Obviously they shouldn't change it but I can certainly imagine the case where it's tried.
Either way - it's good to report as much as we can even if it's not in the UI but in the api.


> 


> 
> >
> >
> >
> >> http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
> >>
> >> Thanks,
> >> Moti
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 


From masayag at redhat.com  Thu Nov 22 15:39:53 2012
From: masayag at redhat.com (Moti Asayag)
Date: Thu, 22 Nov 2012 17:39:53 +0200
Subject: [Engine-devel] Report  vNic Implementation Details
In-Reply-To: <50AE4687.4000902@redhat.com>
References: <1050167732.29778605.1353531203790.JavaMail.root@redhat.com>
	<50AE4687.4000902@redhat.com>
Message-ID: <50AE4749.6010207@redhat.com>

On 11/22/2012 05:36 PM, Yaniv Kaul wrote:
> On 11/21/2012 10:53 PM, Andrew Cathrow wrote:
>>
>> ----- Original Message -----
>>> From: "Moti Asayag" <masayag at redhat.com>
>>> To: engine-devel at ovirt.org
>>> Sent: Wednesday, November 21, 2012 12:36:58 PM
>>> Subject: [Engine-devel] Report  vNic Implementation Details
>>>
>>> Hi all,
>>>
>>> This is a proposal for reporting the vNic implementation details as
>>> reported by the guest agent per each vNic.
>>>
>>> Please review the wiki and add your comments.
>>
>> While we're making the change is there anything else we'd want to
>> report - MTU, MAC (since a user might try to override), etc ?
> 
> Do we support change of MAC from within the VM? Is it even working?
> Y.
> 

Shouldn't work if the nwfilter rules are enabled (which are by default)

> 
>>
>>
>>
>>> http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
>>>
>>> Thanks,
>>> Moti
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 



From emesika at redhat.com  Thu Nov 22 16:22:56 2012
From: emesika at redhat.com (Eli Mesika)
Date: Thu, 22 Nov 2012 11:22:56 -0500 (EST)
Subject: [Engine-devel] Proposal of Alon bar-lev as oVirt jenkins power
	user
In-Reply-To: <1673165523.4516436.1353593797929.JavaMail.root@redhat.com>
Message-ID: <476978787.13531731.1353601376834.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Eyal Edri" <eedri at redhat.com>
> To: "infra" <infra at ovirt.org>
> Cc: engine-devel at ovirt.org
> Sent: Thursday, November 22, 2012 4:16:37 PM
> Subject: Proposal of Alon bar-lev as oVirt jenkins power user
> 
> Hi,
> 
> To continue our new tradition of delegating power users for various
> oVirt sub project management in jenkins,
> 
> I want to propose Alon bar-lev as power user for oVirt jenkins.
> Alon is well known within the oVirt community, and been contributing
> it in the past months.
> 
> Alon has contributed code to many oVirt projects including massive
> re-factoring of the bootstrap process and
> numerous patches on other oVirt projects, Latest projects are otopi
> and ovirt-host-deploy.
> 
> He is very technical with previous knowledge of Jenkins.
> 
> as a power user he will be to:
> 
> 1. create/update new jobs in jenkins.ovirt.org
> 2. run/trigger builds
> 3. run manual gerrit trigger jobs.
> 
> 
> i vote +1.
> 
> please vote confidence with +1 or -1 for not.
+1
> 
> thanks,
> 
> Eyal Edri.
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
> 


From vszocs at redhat.com  Thu Nov 22 16:53:26 2012
From: vszocs at redhat.com (Vojtech Szocs)
Date: Thu, 22 Nov 2012 11:53:26 -0500 (EST)
Subject: [Engine-devel] UI plugins crash course part two (for
	plugin	developers)
In-Reply-To: <50ACDDC0.3000604@redhat.com>
Message-ID: <515215285.8800865.1353603206945.JavaMail.root@redhat.com>

Hi Dave,

this is excellent idea! It's definitely easier (and more fun) for others to follow "crash course" tutorials than just reading wiki docs :)

(I've used the "Level" metaphor to give readers the feeling that they're progressing from beginner to advanced topics, as they make their way through UI plugin development.)

I can certainly dedicate some time to writing such tutorial series. What would be the best way to start?

Regards,
Vojtech


----- Original Message -----
From: "Dave Neary" <dneary at redhat.com>
To: engine-devel at ovirt.org
Sent: Wednesday, November 21, 2012 2:57:20 PM
Subject: Re: [Engine-devel] UI plugins crash course part two (for plugin	developers)

Hi Vojtech,

This is great!

Would you be interested in writing this up as a tutorial series (working 
through a real-life example) for publication on the oVirt website? I 
think it's the kind of article which would be very useful in promoting 
the plug-in API.

Cheers,
Dave.

On 11/19/2012 03:49 PM, Vojtech Szocs wrote:
> Hi guys,
>
> this is a follow-up on the quick "crash course" for writing simple UI plugin.
>
> Before we proceed, please keep in mind that:
> - api.register() must be called exactly once, subsequent calls "overwrite" previous ones
> - api.register() must be called before api.ready(), otherwise your plugin will not work
> - you don't have to define all supported event handler functions in api.register(), just the ones your plugin is interested in (e.g. UiInit)
>
>
> Level 4 - Let's make things configurable
> ========================================
>
> 1. Specify default plugin configuration (optional)
> $ vim /usr/share/ovirt-engine/ui-plugins/hello-ui-world.json
>
> [hello-ui-world.json]
> ...
>    "config": { "testLink": "http://www.example.com/" }
> ...
> [/hello-ui-world.json]
>
> 2. Override default plugin configuration (optional)
> $ mkdir -p /etc/ovirt-engine/ui-plugins
> $ vim /etc/ovirt-engine/ui-plugins/hello-ui-world-config.json
>
> [hello-ui-world-config.json]
> {
>    "config": { "testLink": "http://www.another-example.com/" }
> }
> [/hello-ui-world-config.json]
>
> 3. Use plugin configuration that has been merged together
> $ vim /usr/share/ovirt-engine/ui-plugins/hello-world-files/start.html
>
> [start.html]
> ...
> # Anywhere within event handler function code (e.g. UiInit)
> var conf = api.configObject();
> api.showDialog('Test Dialog', conf.testLink, 600, 400);
> ...
> [/start.html]
>
>
> Regards,
> Vojtech
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>

-- 
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
_______________________________________________
Engine-devel mailing list
Engine-devel at ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel


From mgoldboi at redhat.com  Thu Nov 22 17:22:03 2012
From: mgoldboi at redhat.com (Moran Goldboim)
Date: Thu, 22 Nov 2012 19:22:03 +0200
Subject: [Engine-devel] Proposal of Alon bar-lev as oVirt jenkins power
	user
In-Reply-To: <1673165523.4516436.1353593797929.JavaMail.root@redhat.com>
References: <1673165523.4516436.1353593797929.JavaMail.root@redhat.com>
Message-ID: <50AE5F3B.1000308@redhat.com>

On 11/22/2012 04:16 PM, Eyal Edri wrote:
> Hi,
>
> To continue our new tradition of delegating power users for various oVirt sub project management in jenkins,
>
> I want to propose Alon bar-lev as power user for oVirt jenkins.
> Alon is well known within the oVirt community, and been contributing it in the past months.
>
> Alon has contributed code to many oVirt projects including massive re-factoring of the bootstrap process and
> numerous patches on other oVirt projects, Latest projects are otopi and ovirt-host-deploy.
>
> He is very technical with previous knowledge of Jenkins.
>
> as a power user he will be to:
>
> 1. create/update new jobs in jenkins.ovirt.org
> 2. run/trigger builds
> 3. run manual gerrit trigger jobs.
>
>
> i vote +1.
>
> please vote confidence with +1 or -1 for not.
>
> thanks,
>
> Eyal Edri.
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
i++


From simon at redhat.com  Thu Nov 22 18:40:07 2012
From: simon at redhat.com (Simon Grinberg)
Date: Thu, 22 Nov 2012 13:40:07 -0500 (EST)
Subject: [Engine-devel] Report  vNic Implementation Details
In-Reply-To: <50AE4749.6010207@redhat.com>
Message-ID: <29065531.665.1353609603432.JavaMail.javamailuser@localhost>

Back to the original question:

What is most inconvenient for many users is:
1. The name we provide while creating the VNIC differs from the one in the guest
2. No correlation between IP and NIC

The current page covers for this but indeed as raised here does not cover what happens if this information is not easy to retrieve due to non strait forward configurations.

What I suggest is,

For the short term: 
- Agent to report the MACs, IPs and interface names if can be found, engine to match these to the existing and show
Name In Engine| Name in guest | MAC | IP  etc like the current feature page, but...

- If a match could not be found then just report Name in Engine N/A and then the rest and keep it in dynamic only table. 
This is useful for NICs created by hooks, advanced topology that we can't support ATM etc. 

*The above does require the agent to at least match MAC to IP. 


Long term: The agent to report a topology the same as vdsm does (use same code at least for Linux guests?) and present it similar to what we present in the host tab. In most cases this will collapse to the short term.

MTU, is good to have in any of the two if we can get it. 

More?


 

----- Original Message -----
> From: "Moti Asayag" <masayag at redhat.com>
> To: "Yaniv Kaul" <ykaul at redhat.com>
> Cc: "Simon Grinberg" <simon at redhat.com>, engine-devel at ovirt.org
> Sent: Thursday, November 22, 2012 5:39:53 PM
> Subject: Re: [Engine-devel] Report  vNic Implementation Details
> 
> On 11/22/2012 05:36 PM, Yaniv Kaul wrote:
> > On 11/21/2012 10:53 PM, Andrew Cathrow wrote:
> >>
> >> ----- Original Message -----
> >>> From: "Moti Asayag" <masayag at redhat.com>
> >>> To: engine-devel at ovirt.org
> >>> Sent: Wednesday, November 21, 2012 12:36:58 PM
> >>> Subject: [Engine-devel] Report  vNic Implementation Details
> >>>
> >>> Hi all,
> >>>
> >>> This is a proposal for reporting the vNic implementation details
> >>> as
> >>> reported by the guest agent per each vNic.
> >>>
> >>> Please review the wiki and add your comments.
> >>
> >> While we're making the change is there anything else we'd want to
> >> report - MTU, MAC (since a user might try to override), etc ?
> > 
> > Do we support change of MAC from within the VM? Is it even working?
> > Y.
> > 
> 
> Shouldn't work if the nwfilter rules are enabled (which are by
> default)
> 
> > 
> >>
> >>
> >>
> >>> http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
> >>>
> >>> Thanks,
> >>> Moti
> >>> _______________________________________________
> >>> Engine-devel mailing list
> >>> Engine-devel at ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From iheim at redhat.com  Thu Nov 22 21:16:00 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 22 Nov 2012 23:16:00 +0200
Subject: [Engine-devel] Report  vNic Implementation Details
In-Reply-To: <50AE4749.6010207@redhat.com>
References: <1050167732.29778605.1353531203790.JavaMail.root@redhat.com>
	<50AE4687.4000902@redhat.com> <50AE4749.6010207@redhat.com>
Message-ID: <50AE9610.20805@redhat.com>

On 11/22/2012 05:39 PM, Moti Asayag wrote:
> On 11/22/2012 05:36 PM, Yaniv Kaul wrote:
>> On 11/21/2012 10:53 PM, Andrew Cathrow wrote:
>>>
>>> ----- Original Message -----
>>>> From: "Moti Asayag" <masayag at redhat.com>
>>>> To: engine-devel at ovirt.org
>>>> Sent: Wednesday, November 21, 2012 12:36:58 PM
>>>> Subject: [Engine-devel] Report  vNic Implementation Details
>>>>
>>>> Hi all,
>>>>
>>>> This is a proposal for reporting the vNic implementation details as
>>>> reported by the guest agent per each vNic.
>>>>
>>>> Please review the wiki and add your comments.
>>>
>>> While we're making the change is there anything else we'd want to
>>> report - MTU, MAC (since a user might try to override), etc ?
>>
>> Do we support change of MAC from within the VM? Is it even working?
>> Y.
>>
>
> Shouldn't work if the nwfilter rules are enabled (which are by default)

true, but not relevant in this discussion, as changing mac means no 
external traffic.
doesn't mean it is not what the guest reports via the guest agent.
so guest can report ip per mac from guest agent regardless of vnic mac 
address.


From iheim at redhat.com  Thu Nov 22 21:18:48 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 22 Nov 2012 23:18:48 +0200
Subject: [Engine-devel] Report  vNic Implementation Details
In-Reply-To: <29065531.665.1353609603432.JavaMail.javamailuser@localhost>
References: <29065531.665.1353609603432.JavaMail.javamailuser@localhost>
Message-ID: <50AE96B8.4090001@redhat.com>

On 11/22/2012 08:40 PM, Simon Grinberg wrote:
> Back to the original question:
>
> What is most inconvenient for many users is:
> 1. The name we provide while creating the VNIC differs from the one in the guest
> 2. No correlation between IP and NIC
>
> The current page covers for this but indeed as raised here does not cover what happens if this information is not easy to retrieve due to non strait forward configurations.
>
> What I suggest is,
>
> For the short term:
> - Agent to report the MACs, IPs and interface names if can be found, engine to match these to the existing and show
> Name In Engine| Name in guest | MAC | IP  etc like the current feature page, but...
>
> - If a match could not be found then just report Name in Engine N/A and then the rest and keep it in dynamic only table.
> This is useful for NICs created by hooks, advanced topology that we can't support ATM etc.
>
> *The above does require the agent to at least match MAC to IP.
>
>
> Long term: The agent to report a topology the same as vdsm does (use same code at least for Linux guests?) and present it similar to what we present in the host tab. In most cases this will collapse to the short term.
>
> MTU, is good to have in any of the two if we can get it.
>
> More?

I don't think the guest agent ip information should be correlated to the 
vnic engine information at rest api level.
the vm (and vnic) api provides the authoritative configuration 
information of the guest as defined in the engine.
I don't think we should 'taint' it with untrusted data from the guest.
it would make sense to place there IPs configured/allocated by engine 
when we deal with ip allocation though.

i.e., the guest info element in the rest api provides good separation 
between engine level data, and guest agent data.


From iheim at redhat.com  Thu Nov 22 21:19:33 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 22 Nov 2012 23:19:33 +0200
Subject: [Engine-devel] Proposal of Alon bar-lev as oVirt jenkins power
	user
In-Reply-To: <1673165523.4516436.1353593797929.JavaMail.root@redhat.com>
References: <1673165523.4516436.1353593797929.JavaMail.root@redhat.com>
Message-ID: <50AE96E5.3000102@redhat.com>

On 11/22/2012 04:16 PM, Eyal Edri wrote:
> Hi,
>
> To continue our new tradition of delegating power users for various oVirt sub project management in jenkins,
>
> I want to propose Alon bar-lev as power user for oVirt jenkins.
> Alon is well known within the oVirt community, and been contributing it in the past months.
>
> Alon has contributed code to many oVirt projects including massive re-factoring of the bootstrap process and
> numerous patches on other oVirt projects, Latest projects are otopi and ovirt-host-deploy.
>
> He is very technical with previous knowledge of Jenkins.
>
> as a power user he will be to:
>
> 1. create/update new jobs in jenkins.ovirt.org
> 2. run/trigger builds
> 3. run manual gerrit trigger jobs.
>
>
> i vote +1.
>
> please vote confidence with +1 or -1 for not.
>
> thanks,
>
> Eyal Edri.
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>

+1



From emesika at redhat.com  Thu Nov 22 23:10:28 2012
From: emesika at redhat.com (Eli Mesika)
Date: Thu, 22 Nov 2012 18:10:28 -0500 (EST)
Subject: [Engine-devel] Design review summary for 3.2 - adding support
 for	External Events
In-Reply-To: <50ADC7CC.1070901@redhat.com>
Message-ID: <238107443.13593992.1353625828580.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
> Cc: "Eli Mesika" <emesika at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Thursday, November 22, 2012 8:35:56 AM
> Subject: Re: [Engine-devel] Design review summary for 3.2 - adding support for	External Events
> 
> On 11/20/2012 04:07 PM, Morrissey, Christopher wrote:
> ...
> 
> >>>> Hi Eli,
> >>>>
> >>>> I've perused the design and it looks very good for the purpose
> >>>> of
> >>>> adding events to the log as back end tasks on the NetApp VSC are
> >>>> started and complete.
> >>>>
> >>>> I do have one question. As part of the new UI plugin framework
> >>>> that
> >>>> Vojtech is working on he added the capability to retrieve a
> >>>> session
> >>>> ID that will be used outside of the oVirt engine to invoke REST
> >>>> API
> >>>> calls. I'm assuming this session would have the same role as the
> >>>> user that is currently logged in.
> >>>>
> >>>> According to the event log design, only the Super user will have
> >>>> permissions to add events by default. This would mean that if
> >>>> anyone
> >>>> other than the super user is logged in and performing any tasks
> >>>> through the NetApp plugin, the server side of the VSC will
> >>>> likely
> >>>> not be able to log events. This could be confusing for users as
> >>>> sometimes they see events showing up giving them information on
> >>>> the
> >>>> task progress and sometimes they don't depending on the role
> >>>> logged
> >>>> in.
> >>>>
> >>>> Would it make sense to allow all roles to log events by default?
> >>>> I'm
> >>>> not sure what security problems would arise given that it is
> >>>> just a
> >>>> log and they would be tagged as external events.
> >>>
> >>> Hi Christopher, our security model implies a black-list,
> >>
> >> oops, I meant white-list of course ....
> >>
> >
> > That's what I figured. :)
> >
> >> so, I don;t
> >>> think this is possible
> >>> But still, a super-user can of course give the permission to add
> >>> new
> >>> events to all Roles in the system and you will have the same
> >>> result.
> >>> Does that make sense ?
> >>>
> >
> > That does make sense. We'll likely just try to use the API to log
> > events when starting a task and if we receive an error we can
> > bubble that up to the user letting them know that they need to
> > either get the right permission or accept that they won't get
> > messages in the oVirt log while the task completes.
> 
> Eli - not that the design includes checking for permissions on
> objects,
> why wouldn't we add this permission (ActionGroup) to other admin
> roles
> as well?

You mean in DB upgrade , right ?

> this is only for admin roles, not user roles. what's the risk in
> allowing admins to inject external events?

IIUC , you are right , no risk

> 


From iheim at redhat.com  Fri Nov 23 06:38:34 2012
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 23 Nov 2012 08:38:34 +0200
Subject: [Engine-devel] Design review summary for 3.2 - adding support
 for	External Events
In-Reply-To: <238107443.13593992.1353625828580.JavaMail.root@redhat.com>
References: <238107443.13593992.1353625828580.JavaMail.root@redhat.com>
Message-ID: <50AF19EA.9070801@redhat.com>

On 11/23/2012 01:10 AM, Eli Mesika wrote:
>
>
> ----- Original Message -----
>> From: "Itamar Heim" <iheim at redhat.com>
>> To: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
>> Cc: "Eli Mesika" <emesika at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
>> Sent: Thursday, November 22, 2012 8:35:56 AM
>> Subject: Re: [Engine-devel] Design review summary for 3.2 - adding support for	External Events
>>
>> On 11/20/2012 04:07 PM, Morrissey, Christopher wrote:
>> ...
>>
>>>>>> Hi Eli,
>>>>>>
>>>>>> I've perused the design and it looks very good for the purpose
>>>>>> of
>>>>>> adding events to the log as back end tasks on the NetApp VSC are
>>>>>> started and complete.
>>>>>>
>>>>>> I do have one question. As part of the new UI plugin framework
>>>>>> that
>>>>>> Vojtech is working on he added the capability to retrieve a
>>>>>> session
>>>>>> ID that will be used outside of the oVirt engine to invoke REST
>>>>>> API
>>>>>> calls. I'm assuming this session would have the same role as the
>>>>>> user that is currently logged in.
>>>>>>
>>>>>> According to the event log design, only the Super user will have
>>>>>> permissions to add events by default. This would mean that if
>>>>>> anyone
>>>>>> other than the super user is logged in and performing any tasks
>>>>>> through the NetApp plugin, the server side of the VSC will
>>>>>> likely
>>>>>> not be able to log events. This could be confusing for users as
>>>>>> sometimes they see events showing up giving them information on
>>>>>> the
>>>>>> task progress and sometimes they don't depending on the role
>>>>>> logged
>>>>>> in.
>>>>>>
>>>>>> Would it make sense to allow all roles to log events by default?
>>>>>> I'm
>>>>>> not sure what security problems would arise given that it is
>>>>>> just a
>>>>>> log and they would be tagged as external events.
>>>>>
>>>>> Hi Christopher, our security model implies a black-list,
>>>>
>>>> oops, I meant white-list of course ....
>>>>
>>>
>>> That's what I figured. :)
>>>
>>>> so, I don;t
>>>>> think this is possible
>>>>> But still, a super-user can of course give the permission to add
>>>>> new
>>>>> events to all Roles in the system and you will have the same
>>>>> result.
>>>>> Does that make sense ?
>>>>>
>>>
>>> That does make sense. We'll likely just try to use the API to log
>>> events when starting a task and if we receive an error we can
>>> bubble that up to the user letting them know that they need to
>>> either get the right permission or accept that they won't get
>>> messages in the oVirt log while the task completes.
>>
>> Eli - not that the design includes checking for permissions on
>> objects,
>> why wouldn't we add this permission (ActionGroup) to other admin
>> roles
>> as well?
>
> You mean in DB upgrade , right ?

well, in design, but then yes, as part of upgrade to fix the relevant 
pre-defined roles

>
>> this is only for admin roles, not user roles. what's the risk in
>> allowing admins to inject external events?
>
> IIUC , you are right , no risk
>
>>




From lpeer at redhat.com  Fri Nov 23 07:02:09 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Fri, 23 Nov 2012 09:02:09 +0200
Subject: [Engine-devel] Report  vNic Implementation Details
In-Reply-To: <20121122115921.GJ4557@redhat.com>
References: <1050167732.29778605.1353531203790.JavaMail.root@redhat.com>
	<50AD4F7B.3000407@redhat.com> <50ADDA7F.70506@redhat.com>
	<20121122115921.GJ4557@redhat.com>
Message-ID: <50AF1F71.40009@redhat.com>

On 22/11/12 13:59, Dan Kenigsberg wrote:
> On Thu, Nov 22, 2012 at 09:55:43AM +0200, Livnat Peer wrote:
>> On 22/11/12 00:02, Itamar Heim wrote:
>>> On 11/21/2012 10:53 PM, Andrew Cathrow wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Moti Asayag" <masayag at redhat.com>
>>>>> To: engine-devel at ovirt.org
>>>>> Sent: Wednesday, November 21, 2012 12:36:58 PM
>>>>> Subject: [Engine-devel] Report  vNic Implementation Details
>>>>>
>>>>> Hi all,
>>>>>
>>>>> This is a proposal for reporting the vNic implementation details as
>>>>> reported by the guest agent per each vNic.
>>>>>
>>>>> Please review the wiki and add your comments.
>>>>
>>>>
>>>> While we're making the change is there anything else we'd want to
>>>> report - MTU, MAC (since a user might try to override), etc ?
>>>>>
>>>>> http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
>>>
>>> iirc, the fact ip addresses appear under guest info in the api and not
>>> under the vnic was a modeling decision.
>>> for example, what if guest is using a bridge, or a bond (yes, sounds
>>> unlikely, but the point is it may be incorrect to assume ip-vnic relation.
>>> michael - do you remember the details of that discussion?
>>
>> I'd love to know what drove this modeling decision.
>> The use case above is not a typical use case.
>> We know we won't be able to present the guest internal network
>> configuration accurately in some scenarios but if we cover 90% of the
>> use cases correctly I think we should not let perfect be the enemy of
>> (very) good ;)
> 
> We do not support this yet, but once we have nested virtualization, it
> won't be that odd to have a bridge or bond in the guest. I know that we
> already have users with in-guest vlan devices.
> 

The fact that it's not odd does not mean it is common.., which was the
point I was trying to make.
I agree that we should be able to accommodate such info, not sure that
it is required at this point.


> I think that the api should accomodate these configurations - even if we
> do not report them right away. The guest agent already reports (some) of
> the information:
> 

Which API are you referring to? if you are talking about VDSM-Engine API
we do not change it, only use what is already reported by the GA. I
don't think we should change the API for future support...

>> The Guest Agent reports the vNic details:
>>
>>     IP addresses (both IPv4 and IPv6).
>>     vNic internal name 
> 
> Actually, the guest agent reports all in-guest network device. vNics (and bonds
> and vlans) included.

true, but AFAIU we won't be able to build the networking topology of the
guest from this report. For example if the guest agent reports a bridge
it does not say to which interface it is connected to etc.


>>
>> The retrieved information by the Guest Agent should be reported to the ovirt-engine and to be viewed by its client
>> Today only the IPv4 addresses are reported to the User, kept on VM level. This feature will maintain the information on vNic level.
> 
> I think we should report the information on the vNic level only when we
> can. If we have a vlan device, which we do not know how tie to a
> specific vNic, we'd better report its IP address on the VM level.

If I understand you correctly you are suggesting to keep the IP address
property also on the VM level and for devices with reported IP-address
which the engine can not correlate to a VNIC hold it on this VM-level
property.

My concern is that in the UI we are currently displaying in the main
greed the VM IP and on the network sub-tab the IP per vNIC.
If we choose to hold the IP addresses the engine does not correlate on
the VM level they become the more visible addresses for the users which
I am not sure is what we want.

What I suggest is to add a property to VM that says network devices and
hold the GA report as a 'blob'. we can display this info in the API on
the VM level and in the UI maybe display it on the general sub-tab or
add a dialog on the network subtab.


> 
> It might be worthwhile to note that we should (try to) correlate Engine
> idea of a vNic with the guest agent report, according to the mac address.
> The guest can try to fool us by changing the mac address, but that's
> true for every bit of info coming from the agent.
> 
> Dan.
> 



From dneary at redhat.com  Fri Nov 23 07:37:24 2012
From: dneary at redhat.com (Dave Neary)
Date: Fri, 23 Nov 2012 08:37:24 +0100
Subject: [Engine-devel] UI plugins crash course part two (for plugin
	developers)
In-Reply-To: <515215285.8800865.1353603206945.JavaMail.root@redhat.com>
References: <515215285.8800865.1353603206945.JavaMail.root@redhat.com>
Message-ID: <50AF27B4.8030707@redhat.com>

Hi,

On 11/22/2012 05:53 PM, Vojtech Szocs wrote:
> this is excellent idea! It's definitely easier (and more fun) for others to follow "crash course" tutorials than just reading wiki docs :)

I think so too.

> (I've used the "Level" metaphor to give readers the feeling that they're progressing from beginner to advanced topics, as they make their way through UI plugin development.)

I noticed! And I like it :-)

> I can certainly dedicate some time to writing such tutorial series. What would be the best way to start?

with Level 1, I suppose...

One thing I would like is to have something you can do to validate that 
you've understood a level before you move on (like the bad guy that you 
have to beat to complete levels in video games). It could be something 
as straightforward as a "Compilation successful" message, or a "Test 
passed" on a unit test, or a screenshot of "here's what you should have 
now" - something to let the reader know when they're only a little off 
the path, and how to get back onto it.

I think that the wiki or website could be fine - it's just a web page 
after all - what's important is the promotion of the series in the right 
places, and making it look nice, and like a series of articles rather 
than one big wiki page.

Thanks again! It looks great so far.

Cheers,
Dave.

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


From simon at redhat.com  Fri Nov 23 17:04:34 2012
From: simon at redhat.com (Simon Grinberg)
Date: Fri, 23 Nov 2012 12:04:34 -0500 (EST)
Subject: [Engine-devel] Report  vNic Implementation Details
In-Reply-To: <50AE96B8.4090001@redhat.com>
Message-ID: <28032978.845.1353690271059.JavaMail.javamailuser@localhost>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Simon Grinberg" <simon at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Thursday, November 22, 2012 11:18:48 PM
> Subject: Re: [Engine-devel] Report  vNic Implementation Details
> 
> On 11/22/2012 08:40 PM, Simon Grinberg wrote:
> > Back to the original question:
> >
> > What is most inconvenient for many users is:
> > 1. The name we provide while creating the VNIC differs from the one
> > in the guest
> > 2. No correlation between IP and NIC
> >
> > The current page covers for this but indeed as raised here does not
> > cover what happens if this information is not easy to retrieve due
> > to non strait forward configurations.
> >
> > What I suggest is,
> >
> > For the short term:
> > - Agent to report the MACs, IPs and interface names if can be
> > found, engine to match these to the existing and show
> > Name In Engine| Name in guest | MAC | IP  etc like the current
> > feature page, but...
> >
> > - If a match could not be found then just report Name in Engine N/A
> > and then the rest and keep it in dynamic only table.
> > This is useful for NICs created by hooks, advanced topology that we
> > can't support ATM etc.
> >
> > *The above does require the agent to at least match MAC to IP.
> >
> >
> > Long term: The agent to report a topology the same as vdsm does
> > (use same code at least for Linux guests?) and present it similar
> > to what we present in the host tab. In most cases this will
> > collapse to the short term.
> >
> > MTU, is good to have in any of the two if we can get it.
> >
> > More?
> 
> I don't think the guest agent ip information should be correlated to
> the
> vnic engine information at rest api level.
> the vm (and vnic) api provides the authoritative configuration
> information of the guest as defined in the engine.
> I don't think we should 'taint' it with untrusted data from the
> guest.
> it would make sense to place there IPs configured/allocated by engine
> when we deal with ip allocation though.
 
Agree that there should be a clear distinction between guest data and configuration. 
Never the less you need to report the guest data and correlate where you can to the configuration.

Where and how you present this correlation is a different matter and should be discussed.    

> 
> i.e., the guest info element in the rest api provides good separation
> between engine level data, and guest agent data.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From satimis at yahoo.com  Fri Nov 23 17:23:09 2012
From: satimis at yahoo.com (Stephen Liu)
Date: Fri, 23 Nov 2012 09:23:09 -0800 (PST)
Subject: [Engine-devel] Testing failed
In-Reply-To: <50AD4DE1.3030202@redhat.com>
References: <1353507651.18217.YahooMailNeo@web125106.mail.ne1.yahoo.com>
	<50AD4DE1.3030202@redhat.com>
Message-ID: <1353691389.50610.YahooMailNeo@web125102.mail.ne1.yahoo.com>



----- Original Message -----

> From: Juan Hernandez <jhernand at redhat.com>
> To: Stephen Liu <satimis at yahoo.com>
> Cc: "engine-devel at ovirt.org" <engine-devel at ovirt.org>
> Sent: Thursday, November 22, 2012 5:55 AM
> Subject: Re: [Engine-devel] Testing failed
> 
> On 11/21/2012 03:20 PM, Stephen Liu wrote:
>>  Hi all
>> 
>>  Fedora 17 64bit
>> 
>>  # cd /home/satimis/jboss-as/bin
>>  # ./standalone.sh -b 0.0.0.0
>>  ......
>>  ......
>>  ./standalone.sh: line 178:? 2121 Aborted? ? ? ? ? ? ? ?  (core dumped) 
> "java" -D"[Standalone]" -server -XX:+UseCompressedOops 
> -XX:+TieredCompilation -Xms64m -Xmx512m -XX:MaxPermSize=256m 
> -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true 
> -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 
> -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true 
> -Djboss.server.default.config=standalone.xml 
> "-Dorg.jboss.boot.log.file=/home/satimis/jboss-as/standalone/log/boot.log" 
> "-Dlogging.configuration=file:/home/satimis/jboss-as/standalone/configuration/logging.properties" 
> -jar "/home/satimis/jboss-as/jboss-modules.jar" -mp 
> "/home/satimis/jboss-as/modules" -jaxpmodule javax.xml.jaxp-provider 
> org.jboss.as.standalone -Djboss.home.dir="/home/satimis/jboss-as" -b 
> 0.0.0.0
> 
> That is a really severe problem, it means that your Java Virtual Machine
> really crashed, probably due to a bug in the JVM itself, very unusual.
> 
> Is this something that you reproduce easily? Is that all what you get as
> output? Don't you get something like this:


Re-performed following steps;

$ cd $JBOSS_HOME/bin
$ ./standalone.sh -b 0.0.0.0
bash: ./standalone.sh: No such file or directory

It is quite strange:"?

$ sudo find / -name standalone.sh
find: `/run/user/satimis/gvfs': Permission denied
/home/satimis/jboss-as/jboss-as-7.1.1.Final/bin/standalone.sh
/home/satimis/jboss-as/bin/standalone.sh

The file is there.

I have to enter the full path then it works.

$ cd /home/satimis/jboss-as/bin
$ ./standalone.sh -b 0.0.0.0

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

? JBoss Bootstrap Environment

? JBOSS_HOME: /home/satimis/jboss-as

? JAVA: java

? JAVA_OPTS:? -server -XX:+UseCompressedOops -XX:+TieredCompilation -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -Djboss.server.default.config=standalone.xml

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

01:06:53,441 INFO? [org.jboss.modules] JBoss Modules version 1.1.1.GA
01:06:53,917 INFO? [org.jboss.msc] JBoss MSC version 1.0.2.GA
....
....
2012-11-24 00:46:01,350 INFO? [org.ovirt.engine.core.bll.InitBackendServicesOnStartupBean] (pool-10-thread-1) MacPoolManager finished: 11/24/12 12:46 AM
2012-11-24 00:46:01,462 INFO? [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018559: Deployed "engine.ear"

(hanging waiting for something?)

Pressing [Ctrl]+c
.....
....
01:08:02,790 INFO? [com.arjuna.ats.jbossatx] ARJUNA032014: Stopping transaction recovery manager
01:08:02,821 INFO? [org.jboss.as.server.deployment] JBAS015877: Stopped deployment engine-scheduler.jar in 309ms
01:08:02,828 INFO? [org.jboss.as.server.deployment] JBAS015877: Stopped deployment engine-genericapi.jar in 338ms
01:08:02,833 INFO? [org.jboss.as.server.deployment] JBAS015877: Stopped deployment ovirtengineweb.war in 346ms
01:08:02,840 INFO? [org.jboss.as.server.deployment] JBAS015877: Stopped deployment root.war in 351ms
01:08:02,845 INFO? [org.jboss.as.server.deployment] JBAS015877: Stopped deployment engine-bll.jar in 358ms
01:08:02,849 INFO? [org.jboss.as.server.deployment] JBAS015877: Stopped deployment userportal.war in 365ms
01:08:02,848 INFO? [org.jboss.as.server.deployment] JBAS015877: Stopped deployment webadmin.war in 360ms
01:08:02,866 INFO? [org.jboss.as.server.deployment] JBAS015877: Stopped deployment restapi.war in 438ms
01:08:02,932 INFO? [org.jboss.as.server.deployment] JBAS015877: Stopped deployment engine.ear in 445ms
01:08:02,942 INFO? [org.jboss.as] JBAS015950: JBoss AS 7.1.1.Final "Brontes" stopped in 455ms
[satimis at fedora17 bin]$ 


$ wget -O - \
> --debug \
> --auth-no-challenge \
> --http-user=admin at internal \
> --http-password='letmein!' \
> head='Accept: application/xml' \
> http://fadora17:8700/api/
Setting --auth-no-challenge (authnochallenge) to 1
Setting --http-user (httpuser) to admin at internal
Setting --http-password (httppassword) to letmein!
DEBUG output created by Wget 1.13.4 on linux-gnu.

URI encoding = `UTF-8'
--2012-11-24 00:54:13--? ftp://head=accept/%20application/xml
?????????? => `-'
Resolving head=accept (head=accept)... failed: Name or service not known.
wget: unable to resolve host address `head=accept'
URI encoding = `UTF-8'
--2012-11-24 00:54:13--? http://fadora17:8700/api/
Auth-without-challenge set, sending Basic credentials.
Resolving fadora17 (fadora17)... failed: Name or service not known.
wget: unable to resolve host address `fadora17'

I have no idea of the server name of jboss nor the password.? During its installation there were no requests for such information.? Because it is running on Fedora I suppose it to be Fadora hostname.

$ hostname
fedora17

$ hostname -f
fedora17

Neither can I browse it on browser with;
http://fadora17:8700/api


B.R.
Stephen L



> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #? SIGSEGV (0xb) at pc=0x00007f84b36f85fe, pid=30284, tid=140208179570432
> #
> # JRE version: 7.0_09
> # Java VM: OpenJDK 64-Bit Server VM (23.2-b09 mixed mode linux-amd64
> compressed oops)
> # Problematic frame:
> 
> Or maybe a "hs_err_pid*.log" file?
> 
> The information there could be useful to find cause of the problem.
> 
>> 
>>  Pls help
>> 
>> 
>>  Re running:-
>> 
>>  http://<server name>:<port>/api
>> 
>>  server name?? Is it the hostname of Fedora17?
>> 
>>  # hostname
>>  fedora17
> 
> 
> -- 
> 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 simon at redhat.com  Fri Nov 23 17:34:42 2012
From: simon at redhat.com (Simon Grinberg)
Date: Fri, 23 Nov 2012 12:34:42 -0500 (EST)
Subject: [Engine-devel] Report  vNic Implementation Details
In-Reply-To: <50AF1F71.40009@redhat.com>
Message-ID: <27537568.949.1353692081028.JavaMail.javamailuser@localhost>



----- Original Message -----
> From: "Livnat Peer" <lpeer at redhat.com>
> To: "Dan Kenigsberg" <danken at redhat.com>
> Cc: "Itamar Heim" <iheim at redhat.com>, "Simon Grinberg" <simon at redhat.com>, engine-devel at ovirt.org
> Sent: Friday, November 23, 2012 9:02:09 AM
> Subject: Re: [Engine-devel] Report  vNic Implementation Details
> 
> On 22/11/12 13:59, Dan Kenigsberg wrote:
> > On Thu, Nov 22, 2012 at 09:55:43AM +0200, Livnat Peer wrote:
> >> On 22/11/12 00:02, Itamar Heim wrote:
> >>> On 11/21/2012 10:53 PM, Andrew Cathrow wrote:
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Moti Asayag" <masayag at redhat.com>
> >>>>> To: engine-devel at ovirt.org
> >>>>> Sent: Wednesday, November 21, 2012 12:36:58 PM
> >>>>> Subject: [Engine-devel] Report  vNic Implementation Details
> >>>>>
> >>>>> Hi all,
> >>>>>
> >>>>> This is a proposal for reporting the vNic implementation
> >>>>> details as
> >>>>> reported by the guest agent per each vNic.
> >>>>>
> >>>>> Please review the wiki and add your comments.
> >>>>
> >>>>
> >>>> While we're making the change is there anything else we'd want
> >>>> to
> >>>> report - MTU, MAC (since a user might try to override), etc ?
> >>>>>
> >>>>> http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
> >>>
> >>> iirc, the fact ip addresses appear under guest info in the api
> >>> and not
> >>> under the vnic was a modeling decision.
> >>> for example, what if guest is using a bridge, or a bond (yes,
> >>> sounds
> >>> unlikely, but the point is it may be incorrect to assume ip-vnic
> >>> relation.
> >>> michael - do you remember the details of that discussion?
> >>
> >> I'd love to know what drove this modeling decision.
> >> The use case above is not a typical use case.
> >> We know we won't be able to present the guest internal network
> >> configuration accurately in some scenarios but if we cover 90% of
> >> the
> >> use cases correctly I think we should not let perfect be the enemy
> >> of
> >> (very) good ;)
> > 
> > We do not support this yet, but once we have nested virtualization,
> > it
> > won't be that odd to have a bridge or bond in the guest. I know
> > that we
> > already have users with in-guest vlan devices.
> > 
> 
> The fact that it's not odd does not mean it is common.., which was
> the
> point I was trying to make.
> I agree that we should be able to accommodate such info, not sure
> that
> it is required at this point.


At this point what you need to make sure is that if it does exit you do not crash due to unexpected data. 
Don't forget that using a hook you may create nested virtualization today. 
 
> 
> 
> > I think that the api should accomodate these configurations - even
> > if we
> > do not report them right away. The guest agent already reports
> > (some) of
> > the information:
> > 
> 
> Which API are you referring to? if you are talking about VDSM-Engine
> API
> we do not change it, only use what is already reported by the GA. I
> don't think we should change the API for future support...
> 
> >> The Guest Agent reports the vNic details:
> >>
> >>     IP addresses (both IPv4 and IPv6).
> >>     vNic internal name
> > 
> > Actually, the guest agent reports all in-guest network device.
> > vNics (and bonds
> > and vlans) included.
> 
> true, but AFAIU we won't be able to build the networking topology of
> the
> guest from this report. For example if the guest agent reports a
> bridge
> it does not say to which interface it is connected to etc.

Actually in most cased it does since by default the bridge will get the interface IP. 
Well not that accurate, the bridge gets the lowest IP the of all the devices it is connected to, however there was a fix in libvirt some time back to make sure the external interface IP will be the one the bride gets by providing the tap/tun devices connected to the bridge a MAC address starting with 'FE'

> 
> 
> >>
> >> The retrieved information by the Guest Agent should be reported to
> >> the ovirt-engine and to be viewed by its client
> >> Today only the IPv4 addresses are reported to the User, kept on VM
> >> level. This feature will maintain the information on vNic level.
> > 
> > I think we should report the information on the vNic level only
> > when we
> > can. If we have a vlan device, which we do not know how tie to a
> > specific vNic, we'd better report its IP address on the VM level.
> 
> If I understand you correctly you are suggesting to keep the IP
> address
> property also on the VM level and for devices with reported
> IP-address
> which the engine can not correlate to a VNIC hold it on this VM-level
> property.
> 
> My concern is that in the UI we are currently displaying in the main
> greed the VM IP and on the network sub-tab the IP per vNIC.
> If we choose to hold the IP addresses the engine does not correlate
> on
> the VM level they become the more visible addresses for the users
> which
> I am not sure is what we want.
> 
> What I suggest is to add a property to VM that says network devices
> and
> hold the GA report as a 'blob'. we can display this info in the API
> on
> the VM level and in the UI maybe display it on the general sub-tab or
> add a dialog on the network subtab.

I think you should display it as correlated as possible - since I agree with you that the common case is an IP set directly on the VNIC, it means in most cases you'll present the right info in the right place. let's not allow 10% of the cases block us then doing the right thing for the other 90. 

Try to correlate based on MAC and present the internal name and IP as the guest info on the same line with the Defined nic (In API they can (and should as Itamar noted) be separated and probably held as a blob per your suggestion.

Now your problematic scenarios:
1. You have a single VLAN, bridge etc -> It translates to many entries with the same MAC but only one has IP -> collapse all to 'Select to present the one that has IP'. 
2. You have a MAC that does not match -> Present this as a guest only device (IE new line - instead of name say guest only), let the user see and correlate if he wants - it is his network, if he did crazy things it's his problem) 
3. Multiple bridges and Vlans -> Collect all IPs per MAC and collapse, then present as above 

>From the 3 above I expect only the first to be found ATM and even that is rare.

In the future we can work on what I've suggested in a previous email on this thread, present a guest network topology same as you do for the host. 
 

> 
> 
> > 
> > It might be worthwhile to note that we should (try to) correlate
> > Engine
> > idea of a vNic with the guest agent report, according to the mac
> > address.
> > The guest can try to fool us by changing the mac address, but
> > that's
> > true for every bit of info coming from the agent.
> > 
> > Dan.
> > 
> 
> 


From emesika at redhat.com  Sat Nov 24 21:31:16 2012
From: emesika at redhat.com (Eli Mesika)
Date: Sat, 24 Nov 2012 16:31:16 -0500 (EST)
Subject: [Engine-devel] Design review summary for 3.2 - adding support
 for	External Events
In-Reply-To: <50AF19EA.9070801@redhat.com>
Message-ID: <1846109123.14120666.1353792676829.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
> Sent: Friday, November 23, 2012 8:38:34 AM
> Subject: Re: [Engine-devel] Design review summary for 3.2 - adding support for	External Events
> 
> On 11/23/2012 01:10 AM, Eli Mesika wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Itamar Heim" <iheim at redhat.com>
> >> To: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
> >> Cc: "Eli Mesika" <emesika at redhat.com>, "engine-devel"
> >> <engine-devel at ovirt.org>
> >> Sent: Thursday, November 22, 2012 8:35:56 AM
> >> Subject: Re: [Engine-devel] Design review summary for 3.2 - adding
> >> support for	External Events
> >>
> >> On 11/20/2012 04:07 PM, Morrissey, Christopher wrote:
> >> ...
> >>
> >>>>>> Hi Eli,
> >>>>>>
> >>>>>> I've perused the design and it looks very good for the purpose
> >>>>>> of
> >>>>>> adding events to the log as back end tasks on the NetApp VSC
> >>>>>> are
> >>>>>> started and complete.
> >>>>>>
> >>>>>> I do have one question. As part of the new UI plugin framework
> >>>>>> that
> >>>>>> Vojtech is working on he added the capability to retrieve a
> >>>>>> session
> >>>>>> ID that will be used outside of the oVirt engine to invoke
> >>>>>> REST
> >>>>>> API
> >>>>>> calls. I'm assuming this session would have the same role as
> >>>>>> the
> >>>>>> user that is currently logged in.
> >>>>>>
> >>>>>> According to the event log design, only the Super user will
> >>>>>> have
> >>>>>> permissions to add events by default. This would mean that if
> >>>>>> anyone
> >>>>>> other than the super user is logged in and performing any
> >>>>>> tasks
> >>>>>> through the NetApp plugin, the server side of the VSC will
> >>>>>> likely
> >>>>>> not be able to log events. This could be confusing for users
> >>>>>> as
> >>>>>> sometimes they see events showing up giving them information
> >>>>>> on
> >>>>>> the
> >>>>>> task progress and sometimes they don't depending on the role
> >>>>>> logged
> >>>>>> in.
> >>>>>>
> >>>>>> Would it make sense to allow all roles to log events by
> >>>>>> default?
> >>>>>> I'm
> >>>>>> not sure what security problems would arise given that it is
> >>>>>> just a
> >>>>>> log and they would be tagged as external events.
> >>>>>
> >>>>> Hi Christopher, our security model implies a black-list,
> >>>>
> >>>> oops, I meant white-list of course ....
> >>>>
> >>>
> >>> That's what I figured. :)
> >>>
> >>>> so, I don;t
> >>>>> think this is possible
> >>>>> But still, a super-user can of course give the permission to
> >>>>> add
> >>>>> new
> >>>>> events to all Roles in the system and you will have the same
> >>>>> result.
> >>>>> Does that make sense ?
> >>>>>
> >>>
> >>> That does make sense. We'll likely just try to use the API to log
> >>> events when starting a task and if we receive an error we can
> >>> bubble that up to the user letting them know that they need to
> >>> either get the right permission or accept that they won't get
> >>> messages in the oVirt log while the task completes.
> >>
> >> Eli - not that the design includes checking for permissions on
> >> objects,
> >> why wouldn't we add this permission (ActionGroup) to other admin
> >> roles
> >> as well?
> >
> > You mean in DB upgrade , right ?
> 
> well, in design, but then yes, as part of upgrade to fix the relevant
> pre-defined roles

Added to the install/upgrade section of feature detailed design
http://wiki.ovirt.org/wiki/Features/Design/DetailedExternalEvents#Installation.2FUpgrade

> 
> >
> >> this is only for admin roles, not user roles. what's the risk in
> >> allowing admins to inject external events?
> >
> > IIUC , you are right , no risk
> >
> >>
> 
> 
> 


From danken at redhat.com  Sun Nov 25 06:11:22 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Sun, 25 Nov 2012 08:11:22 +0200
Subject: [Engine-devel] Report  vNic Implementation Details
In-Reply-To: <50AF1F71.40009@redhat.com>
References: <1050167732.29778605.1353531203790.JavaMail.root@redhat.com>
	<50AD4F7B.3000407@redhat.com> <50ADDA7F.70506@redhat.com>
	<20121122115921.GJ4557@redhat.com> <50AF1F71.40009@redhat.com>
Message-ID: <20121125061122.GA23608@redhat.com>

On Fri, Nov 23, 2012 at 09:02:09AM +0200, Livnat Peer wrote:
> On 22/11/12 13:59, Dan Kenigsberg wrote:
> > On Thu, Nov 22, 2012 at 09:55:43AM +0200, Livnat Peer wrote:
> >> On 22/11/12 00:02, Itamar Heim wrote:
> >>> On 11/21/2012 10:53 PM, Andrew Cathrow wrote:
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Moti Asayag" <masayag at redhat.com>
> >>>>> To: engine-devel at ovirt.org
> >>>>> Sent: Wednesday, November 21, 2012 12:36:58 PM
> >>>>> Subject: [Engine-devel] Report  vNic Implementation Details
> >>>>>
> >>>>> Hi all,
> >>>>>
> >>>>> This is a proposal for reporting the vNic implementation details as
> >>>>> reported by the guest agent per each vNic.
> >>>>>
> >>>>> Please review the wiki and add your comments.
> >>>>
> >>>>
> >>>> While we're making the change is there anything else we'd want to
> >>>> report - MTU, MAC (since a user might try to override), etc ?
> >>>>>
> >>>>> http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
> >>>
> >>> iirc, the fact ip addresses appear under guest info in the api and not
> >>> under the vnic was a modeling decision.
> >>> for example, what if guest is using a bridge, or a bond (yes, sounds
> >>> unlikely, but the point is it may be incorrect to assume ip-vnic relation.
> >>> michael - do you remember the details of that discussion?
> >>
> >> I'd love to know what drove this modeling decision.
> >> The use case above is not a typical use case.
> >> We know we won't be able to present the guest internal network
> >> configuration accurately in some scenarios but if we cover 90% of the
> >> use cases correctly I think we should not let perfect be the enemy of
> >> (very) good ;)
> > 
> > We do not support this yet, but once we have nested virtualization, it
> > won't be that odd to have a bridge or bond in the guest. I know that we
> > already have users with in-guest vlan devices.
> > 
> 
> The fact that it's not odd does not mean it is common.., which was the
> point I was trying to make.
> I agree that we should be able to accommodate such info, not sure that
> it is required at this point.
> 
> 
> > I think that the api should accomodate these configurations - even if we
> > do not report them right away. The guest agent already reports (some) of
> > the information:
> > 
> 
> Which API are you referring to? if you are talking about VDSM-Engine API
> we do not change it, only use what is already reported by the GA. I
> don't think we should change the API for future support...

I was refering to the Engine API. Now that we are designing how guest IP
addresses are to be reported, we should think how to accomodate IP
addresses on non-nic devices.

I believe that the Engine API should replicate the guest agent API: give
a list of guest network devices, each one with its ethernet/ipv4/6
addresses.

I am less sure how we should correlate this information with the VNICs
defined on the VM. If we do not want to "taint" the VNIC with this dubious information, we can leave this correlation (based on MAC address) to UI or user script.

Dan.


From lpeer at redhat.com  Sun Nov 25 07:10:18 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Sun, 25 Nov 2012 09:10:18 +0200
Subject: [Engine-devel] Report  vNic Implementation Details
In-Reply-To: <20121125061122.GA23608@redhat.com>
References: <1050167732.29778605.1353531203790.JavaMail.root@redhat.com>
	<50AD4F7B.3000407@redhat.com> <50ADDA7F.70506@redhat.com>
	<20121122115921.GJ4557@redhat.com> <50AF1F71.40009@redhat.com>
	<20121125061122.GA23608@redhat.com>
Message-ID: <50B1C45A.3060600@redhat.com>

On 25/11/12 08:11, Dan Kenigsberg wrote:
> On Fri, Nov 23, 2012 at 09:02:09AM +0200, Livnat Peer wrote:
>> On 22/11/12 13:59, Dan Kenigsberg wrote:
>>> On Thu, Nov 22, 2012 at 09:55:43AM +0200, Livnat Peer wrote:
>>>> On 22/11/12 00:02, Itamar Heim wrote:
>>>>> On 11/21/2012 10:53 PM, Andrew Cathrow wrote:
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Moti Asayag" <masayag at redhat.com>
>>>>>>> To: engine-devel at ovirt.org
>>>>>>> Sent: Wednesday, November 21, 2012 12:36:58 PM
>>>>>>> Subject: [Engine-devel] Report  vNic Implementation Details
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> This is a proposal for reporting the vNic implementation details as
>>>>>>> reported by the guest agent per each vNic.
>>>>>>>
>>>>>>> Please review the wiki and add your comments.
>>>>>>
>>>>>>
>>>>>> While we're making the change is there anything else we'd want to
>>>>>> report - MTU, MAC (since a user might try to override), etc ?
>>>>>>>
>>>>>>> http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
>>>>>
>>>>> iirc, the fact ip addresses appear under guest info in the api and not
>>>>> under the vnic was a modeling decision.
>>>>> for example, what if guest is using a bridge, or a bond (yes, sounds
>>>>> unlikely, but the point is it may be incorrect to assume ip-vnic relation.
>>>>> michael - do you remember the details of that discussion?
>>>>
>>>> I'd love to know what drove this modeling decision.
>>>> The use case above is not a typical use case.
>>>> We know we won't be able to present the guest internal network
>>>> configuration accurately in some scenarios but if we cover 90% of the
>>>> use cases correctly I think we should not let perfect be the enemy of
>>>> (very) good ;)
>>>
>>> We do not support this yet, but once we have nested virtualization, it
>>> won't be that odd to have a bridge or bond in the guest. I know that we
>>> already have users with in-guest vlan devices.
>>>
>>
>> The fact that it's not odd does not mean it is common.., which was the
>> point I was trying to make.
>> I agree that we should be able to accommodate such info, not sure that
>> it is required at this point.
>>
>>
>>> I think that the api should accomodate these configurations - even if we
>>> do not report them right away. The guest agent already reports (some) of
>>> the information:
>>>
>>
>> Which API are you referring to? if you are talking about VDSM-Engine API
>> we do not change it, only use what is already reported by the GA. I
>> don't think we should change the API for future support...
> 
> I was refering to the Engine API. Now that we are designing how guest IP
> addresses are to be reported, we should think how to accomodate IP
> addresses on non-nic devices.
> 

Currently the engine do not expose guest-network-devices other than
vNICs which were defined in the engine from the first place.

I suggested adding a blob (at VM level) to present the
network-devices-data reported by the guest agent.
So far I did not see on the users list any request for such info, so
maybe we can hold this addition back a little to see what requests our
users have for this.


> I believe that the Engine API should replicate the guest agent API: give
> a list of guest network devices, each one with its ethernet/ipv4/6
> addresses.
> 
> I am less sure how we should correlate this information with the VNICs
> defined on the VM. If we do not want to "taint" the VNIC with this dubious information, we can leave this correlation (based on MAC address) to UI or user script.
> 
> Dan.
> 



From lpeer at redhat.com  Sun Nov 25 07:27:12 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Sun, 25 Nov 2012 09:27:12 +0200
Subject: [Engine-devel] Report  vNic Implementation Details
In-Reply-To: <29065531.665.1353609603432.JavaMail.javamailuser@localhost>
References: <29065531.665.1353609603432.JavaMail.javamailuser@localhost>
Message-ID: <50B1C850.7060200@redhat.com>

On 22/11/12 20:40, Simon Grinberg wrote:
> Back to the original question:
> 
> What is most inconvenient for many users is:
> 1. The name we provide while creating the VNIC differs from the one in the guest
> 2. No correlation between IP and NIC
> 
> The current page covers for this but indeed as raised here does not cover what happens if this information is not easy to retrieve due to non strait forward configurations.
> 
> What I suggest is,
> 
> For the short term: 
> - Agent to report the MACs, IPs and interface names if can be found, engine to match these to the existing and show
> Name In Engine| Name in guest | MAC | IP  etc like the current feature page, but...
> 

I think we are all in agreement on the current proposal.
It also seems like you have ideas for enhancing the current proposal so
if you can write a detailed feature page with what you have in mind all
the way from the guest agent report to the REST API modeling we'll be
happy to discuss this as well.


> - If a match could not be found then just report Name in Engine N/A and then the rest and keep it in dynamic only table. 
> This is useful for NICs created by hooks, advanced topology that we can't support ATM etc. 
> 
> *The above does require the agent to at least match MAC to IP. 
> 
> 
> Long term: The agent to report a topology the same as vdsm does (use same code at least for Linux guests?) and present it similar to what we present in the host tab. In most cases this will collapse to the short term.
> 
> MTU, is good to have in any of the two if we can get it. 
> 
> More?
> 
> 
>  
> 
> ----- Original Message -----
>> From: "Moti Asayag" <masayag at redhat.com>
>> To: "Yaniv Kaul" <ykaul at redhat.com>
>> Cc: "Simon Grinberg" <simon at redhat.com>, engine-devel at ovirt.org
>> Sent: Thursday, November 22, 2012 5:39:53 PM
>> Subject: Re: [Engine-devel] Report  vNic Implementation Details
>>
>> On 11/22/2012 05:36 PM, Yaniv Kaul wrote:
>>> On 11/21/2012 10:53 PM, Andrew Cathrow wrote:
>>>>
>>>> ----- Original Message -----
>>>>> From: "Moti Asayag" <masayag at redhat.com>
>>>>> To: engine-devel at ovirt.org
>>>>> Sent: Wednesday, November 21, 2012 12:36:58 PM
>>>>> Subject: [Engine-devel] Report  vNic Implementation Details
>>>>>
>>>>> Hi all,
>>>>>
>>>>> This is a proposal for reporting the vNic implementation details
>>>>> as
>>>>> reported by the guest agent per each vNic.
>>>>>
>>>>> Please review the wiki and add your comments.
>>>>
>>>> While we're making the change is there anything else we'd want to
>>>> report - MTU, MAC (since a user might try to override), etc ?
>>>
>>> Do we support change of MAC from within the VM? Is it even working?
>>> Y.
>>>
>>
>> Shouldn't work if the nwfilter rules are enabled (which are by
>> default)
>>
>>>
>>>>
>>>>
>>>>
>>>>> http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
>>>>>
>>>>> Thanks,
>>>>> Moti
>>>>> _______________________________________________
>>>>> Engine-devel mailing list
>>>>> Engine-devel at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 



From mpastern at redhat.com  Sun Nov 25 08:18:26 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 25 Nov 2012 10:18:26 +0200
Subject: [Engine-devel] Report  vNic Implementation Details
In-Reply-To: <50AD4F7B.3000407@redhat.com>
References: <1050167732.29778605.1353531203790.JavaMail.root@redhat.com>
	<50AD4F7B.3000407@redhat.com>
Message-ID: <50B1D452.6090304@redhat.com>

On 11/22/2012 12:02 AM, Itamar Heim wrote:
> On 11/21/2012 10:53 PM, Andrew Cathrow wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Moti Asayag" <masayag at redhat.com>
>>> To: engine-devel at ovirt.org
>>> Sent: Wednesday, November 21, 2012 12:36:58 PM
>>> Subject: [Engine-devel] Report  vNic Implementation Details
>>>
>>> Hi all,
>>>
>>> This is a proposal for reporting the vNic implementation details as
>>> reported by the guest agent per each vNic.
>>>
>>> Please review the wiki and add your comments.
>>
>>
>> While we're making the change is there anything else we'd want to report - MTU, MAC (since a user might try to override), etc ?
>>>
>>> http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
> 
> iirc, the fact ip addresses appear under guest info in the api and not under the vnic was a modeling decision.
> for example, what if guest is using a bridge, or a bond (yes, sounds unlikely, but the point is it may be incorrect to assume ip-vnic relation.
> michael - do you remember the details of that discussion?
> 

indeed, unfortunately i can't recall exact discussion nor can find this thread in ML,
but afair this was the argument.

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From mpastern at redhat.com  Sun Nov 25 08:27:59 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 25 Nov 2012 10:27:59 +0200
Subject: [Engine-devel] UI Plugins: PoC patch revision 7 is here
In-Reply-To: <850257615.7738611.1353409077008.JavaMail.root@redhat.com>
References: <850257615.7738611.1353409077008.JavaMail.root@redhat.com>
Message-ID: <50B1D68F.9070505@redhat.com>

On 11/20/2012 12:57 PM, Vojtech Szocs wrote:
> Hi Michael,
> 
>> if we plan moving UI on top of API, you should be:
>>
>> 1. importing restapi-types project
>> 2. writing intermediate layer to translate BE entities to API's using #1
>> 3. using public entities from #2
>>
>> this way your future migration to API (instead of native BE) will be much
>> more easier.
> 
> Indeed, this is very useful for GWT RPC -> REST API transition in general, many thanks for pointing this out, Michael. As you suggest, we can use restapi-types mappers to translate between internal entities and API types.
> 
> Our first iteration could be:
> a1, rewrite UiCommon (UI business logic) layer to work with API types
> a2, write adapter (e.g. modify Frontend class) between UiCommon using API types and Generic API (GWT RPC) using internal entities

does this mean converting three times?

> 
> Our second iteration could be:
> b1, remove adapter from step a2, drop Generic API (GWT RPC) usage
> b2, write API type <-> JSON mapper, possibly using some existing framework

do you mean talking with api in JSON?

> b3, write RPC layer that talks REST API with Engine
> 
> However, in order to use REST API types on client (GWT), we need their source code. restapi-interface-definition uses Maven JAXB plugin to generate API types from XSD schema (src/main/resources/api.xsd). On client, we need restapi-definition-<version>-sources.jar that includes those generated API types (target/generated-sources/xjc).

> 
> As for UI plugins (short term), we can just use restapi-types mappers and implement step b2, (API type -> JSON mapper).
> 
> Thanks,
> Vojtech
> 
> 
> ----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "Vojtech Szocs" <vszocs at redhat.com>
> Cc: "Itamar Heim" <iheim at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, November 20, 2012 9:48:27 AM
> Subject: Re: [Engine-devel] UI Plugins: PoC patch revision 7 is here
> 
> On 11/20/2012 12:13 AM, Itamar Heim wrote:
>> On 11/19/2012 02:07 PM, Vojtech Szocs wrote:
>>> Hi Itamar,
>>>
>>> UI plugin infrastructure translates internal business entities into JSON-like representations and passes those representations to UI plugins. (Internal entities are NOT
>>> exposed to UI plugins directly.)
>>>
>>> Currently, all entities supported by UI plugin infrastructure (as per org.ovirt.engine.ui.webadmin.plugin.entity.EntityType) are transformed into following representation:
>>>
>>> { entityId: "[BusinessEntityGuidAsString]" }
>>>
>>> For example, a VM entity with entity ID "vm123" will translate to:
>>>
>>> { entityId: "vm123" }
>>>
>>> Translation is currently based on org.ovirt.engine.core.common.businessentities.BusinessEntity interface, like so: "BusinessEntity<? extends NGuid>" (we expect ID type
>>> parameter to be NGuid-compatible). However, I've found that there are some entities (like Pool - org.ovirt.engine.core.common.businessentities.vm_pools) that don't
>>> implement BusinessEntity interface.
>>
>> ok, so we only pass the ID for now. good.
>>
>>>
>>> Quick question to backend folks - IIRC all entities extend org.ovirt.engine.core.common.businessentities.IVdcQueryable, but not all entities implement
>>> org.ovirt.engine.core.common.businessentities.BusinessEntity interface. What is the precise relation between IVdcQueryable and BusinessEntity?
>>>
>>> As for UI plugins, currently all entities get translated to above mentioned basic JSON-like representation. You can see the relevant code in
>>> org.ovirt.engine.ui.webadmin.plugin.entity.BaseEntity.from() static method. There's a TODO that says "make this class [BaseEntity] abstract and create specific entity for
>>> each EntityType" - this means we are planning to extend the above mentioned basic JSON-like representation for different entity types.
>>>
>>> For example, for a VM entity we might do:
>>>
>>> { entityId: "[BusinessEntityGuidAsString]", osType: "[VmOsType]" }
>>
>> just make sure the entity matches the REST API entity.
>> (which probably means entityId should be changed to id?)
> 
> if we plan moving UI on top of API, you should be:
> 
> 1. importing restapi-types project
> 2. writing intermediate layer to translate BE entities to API's using #1
> 3. using public entities from #2
> 
> this way your future migration to API (instead of native BE) will be much
> more easier.
> 
>>
>>>
>>> Vojtech
>>>
>>>
>>> ----- Original Message -----
>>> From: "Itamar Heim" <iheim at redhat.com>
>>> To: "Vojtech Szocs" <vszocs at redhat.com>
>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>> Sent: Friday, November 16, 2012 5:24:52 PM
>>> Subject: Re: [Engine-devel] UI Plugins: PoC patch revision 7 is here
>>>
>>> On 11/16/2012 06:08 PM, Vojtech Szocs wrote:
>>>>> is there a clear list of all APIs supported now?
>>>>
>>>> Not yet, unfortunately, this should be part of "for plugin developers" wiki that is planned to be written in upcoming weeks.
>>>
>>> i just wanted to review how we solved not using internal entities as
>>> part of the API
>>>
>>
>>
> 
> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From amureini at redhat.com  Sun Nov 25 11:25:52 2012
From: amureini at redhat.com (Allon Mureinik)
Date: Sun, 25 Nov 2012 06:25:52 -0500 (EST)
Subject: [Engine-devel] Mocking EJB resources
Message-ID: <1326362727.5214458.1353842752975.JavaMail.root@redhat.com>

Hi guys,

Many of our classes use EJBUtils to access JBoss' resources/beans, such as TransactionManager, Schedular, LockingManager, etc.
This is all fine and well, but it's a bit of a pain when testing those classes.

Earlier today I merged a patch (thanks Laszlo, Michael K., Yair and Alissa for their comments!) that allows a streamlined, easier way of doing this, instead of having to muck around with mock objects (or mock around with muck objects, for that matter).

The details can be found in the following wiki page:
http://wiki.ovirt.org/wiki/MockEJBStrategyRule


Enjoy,
Allon


From amureini at redhat.com  Sun Nov 25 11:34:46 2012
From: amureini at redhat.com (Allon Mureinik)
Date: Sun, 25 Nov 2012 06:34:46 -0500 (EST)
Subject: [Engine-devel] Proposal of Alon bar-lev as oVirt jenkins power
 user
In-Reply-To: <1673165523.4516436.1353593797929.JavaMail.root@redhat.com>
Message-ID: <32228724.5214601.1353843286311.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Eyal Edri" <eedri at redhat.com>
> To: "infra" <infra at ovirt.org>
> Cc: engine-devel at ovirt.org
> Sent: Thursday, November 22, 2012 4:16:37 PM
> Subject: [Engine-devel] Proposal of Alon bar-lev as oVirt jenkins power user
> 
> Hi,
> 
> To continue our new tradition of delegating power users for various
> oVirt sub project management in jenkins,
> 
> I want to propose Alon bar-lev as power user for oVirt jenkins.
> Alon is well known within the oVirt community, and been contributing
> it in the past months.
> 
> Alon has contributed code to many oVirt projects including massive
> re-factoring of the bootstrap process and
> numerous patches on other oVirt projects, Latest projects are otopi
> and ovirt-host-deploy.
> 
> He is very technical with previous knowledge of Jenkins.
> 
> as a power user he will be to:
> 
> 1. create/update new jobs in jenkins.ovirt.org
> 2. run/trigger builds
> 3. run manual gerrit trigger jobs.
> 
> 
> i vote +1.
> 
> please vote confidence with +1 or -1 for not.
> 
> thanks,
> 
> Eyal Edri.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
Eyal, could you please specify who this vote is open to?
(for instance, when voting for new maintainers, only maintainers votes count)

If my vote does count - +1, definitely.


From ilvovsky at redhat.com  Sun Nov 25 11:44:29 2012
From: ilvovsky at redhat.com (Igor Lvovsky)
Date: Sun, 25 Nov 2012 06:44:29 -0500 (EST)
Subject: [Engine-devel] Proposal of Alon bar-lev as oVirt jenkins power
 user
In-Reply-To: <1673165523.4516436.1353593797929.JavaMail.root@redhat.com>
Message-ID: <2039154580.14178706.1353843869528.JavaMail.root@redhat.com>

+1

----- Original Message -----
> From: "Eyal Edri" <eedri at redhat.com>
> To: "infra" <infra at ovirt.org>
> Cc: engine-devel at ovirt.org
> Sent: Thursday, November 22, 2012 4:16:37 PM
> Subject: [Engine-devel] Proposal of Alon bar-lev as oVirt jenkins power user
> 
> Hi,
> 
> To continue our new tradition of delegating power users for various
> oVirt sub project management in jenkins,
> 
> I want to propose Alon bar-lev as power user for oVirt jenkins.
> Alon is well known within the oVirt community, and been contributing
> it in the past months.
> 
> Alon has contributed code to many oVirt projects including massive
> re-factoring of the bootstrap process and
> numerous patches on other oVirt projects, Latest projects are otopi
> and ovirt-host-deploy.
> 
> He is very technical with previous knowledge of Jenkins.
> 
> as a power user he will be to:
> 
> 1. create/update new jobs in jenkins.ovirt.org
> 2. run/trigger builds
> 3. run manual gerrit trigger jobs.
> 
> 
> i vote +1.
> 
> please vote confidence with +1 or -1 for not.
> 
> thanks,
> 
> Eyal Edri.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From eedri at redhat.com  Sun Nov 25 11:58:43 2012
From: eedri at redhat.com (Eyal Edri)
Date: Sun, 25 Nov 2012 06:58:43 -0500 (EST)
Subject: [Engine-devel] Proposal of Alon bar-lev as oVirt jenkins power
 user
In-Reply-To: <2039154580.14178706.1353843869528.JavaMail.root@redhat.com>
Message-ID: <1845242888.5230184.1353844723592.JavaMail.root@redhat.com>

OK,

seems like only +1 and no -1.

approved alon as power user.

alon, you can start creating your jobs,
if you have any questions, please direct them to infra at ovirt.org.

i will send you the initial credentials off the list.

enjoy :)

eyal.

----- Original Message -----
> From: "Igor Lvovsky" <ilvovsky at redhat.com>
> To: "Eyal Edri" <eedri at redhat.com>
> Cc: engine-devel at ovirt.org, "infra" <infra at ovirt.org>
> Sent: Sunday, November 25, 2012 1:44:29 PM
> Subject: Re: [Engine-devel] Proposal of Alon bar-lev as oVirt jenkins power user
> 
> +1
> 
> ----- Original Message -----
> > From: "Eyal Edri" <eedri at redhat.com>
> > To: "infra" <infra at ovirt.org>
> > Cc: engine-devel at ovirt.org
> > Sent: Thursday, November 22, 2012 4:16:37 PM
> > Subject: [Engine-devel] Proposal of Alon bar-lev as oVirt jenkins
> > power user
> > 
> > Hi,
> > 
> > To continue our new tradition of delegating power users for various
> > oVirt sub project management in jenkins,
> > 
> > I want to propose Alon bar-lev as power user for oVirt jenkins.
> > Alon is well known within the oVirt community, and been
> > contributing
> > it in the past months.
> > 
> > Alon has contributed code to many oVirt projects including massive
> > re-factoring of the bootstrap process and
> > numerous patches on other oVirt projects, Latest projects are otopi
> > and ovirt-host-deploy.
> > 
> > He is very technical with previous knowledge of Jenkins.
> > 
> > as a power user he will be to:
> > 
> > 1. create/update new jobs in jenkins.ovirt.org
> > 2. run/trigger builds
> > 3. run manual gerrit trigger jobs.
> > 
> > 
> > i vote +1.
> > 
> > please vote confidence with +1 or -1 for not.
> > 
> > thanks,
> > 
> > Eyal Edri.
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 


From lpeer at redhat.com  Sun Nov 25 12:56:38 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Sun, 25 Nov 2012 14:56:38 +0200
Subject: [Engine-devel] Report  vNic Implementation Details
In-Reply-To: <50AE96B8.4090001@redhat.com>
References: <29065531.665.1353609603432.JavaMail.javamailuser@localhost>
	<50AE96B8.4090001@redhat.com>
Message-ID: <50B21586.6030601@redhat.com>

On 22/11/12 23:18, Itamar Heim wrote:
> On 11/22/2012 08:40 PM, Simon Grinberg wrote:
>> Back to the original question:
>>
>> What is most inconvenient for many users is:
>> 1. The name we provide while creating the VNIC differs from the one in
>> the guest
>> 2. No correlation between IP and NIC
>>
>> The current page covers for this but indeed as raised here does not
>> cover what happens if this information is not easy to retrieve due to
>> non strait forward configurations.
>>
>> What I suggest is,
>>
>> For the short term:
>> - Agent to report the MACs, IPs and interface names if can be found,
>> engine to match these to the existing and show
>> Name In Engine| Name in guest | MAC | IP  etc like the current feature
>> page, but...
>>
>> - If a match could not be found then just report Name in Engine N/A
>> and then the rest and keep it in dynamic only table.
>> This is useful for NICs created by hooks, advanced topology that we
>> can't support ATM etc.
>>
>> *The above does require the agent to at least match MAC to IP.
>>
>>
>> Long term: The agent to report a topology the same as vdsm does (use
>> same code at least for Linux guests?) and present it similar to what
>> we present in the host tab. In most cases this will collapse to the
>> short term.
>>
>> MTU, is good to have in any of the two if we can get it.
>>
>> More?
> 
> I don't think the guest agent ip information should be correlated to the
> vnic engine information at rest api level.
> the vm (and vnic) api provides the authoritative configuration
> information of the guest as defined in the engine.
> I don't think we should 'taint' it with untrusted data from the guest.
> it would make sense to place there IPs configured/allocated by engine
> when we deal with ip allocation though.
> 


I was too quick to say we have an agreement...

The comment above seems to give more emphasis on the segregation between
data collected via the GA and data configured via the engine.

In the API we have today the following modeling: per VM entity we hold
GuestInfo entity and there we hold a list of IP addresses.

Are you suggesting to keep this approach and not report anything on the
vNIC level at this point (until we'll be able to configure IP addresses
via the engine)?
Or add GuestInfo element under /api/vms/{vm:id}/nics/{nic:id}/ which
should be additional to the one on the VM level (as we discussed before
the correlation between VNIC and GA reported data is not always possible)

Also what you have in mind for the UI?




> i.e., the guest info element in the rest api provides good separation
> between engine level data, and guest agent data.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From iheim at redhat.com  Sun Nov 25 13:00:25 2012
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 25 Nov 2012 15:00:25 +0200
Subject: [Engine-devel] Report  vNic Implementation Details
In-Reply-To: <50B21586.6030601@redhat.com>
References: <29065531.665.1353609603432.JavaMail.javamailuser@localhost>
	<50AE96B8.4090001@redhat.com> <50B21586.6030601@redhat.com>
Message-ID: <50B21669.7050207@redhat.com>

On 11/25/2012 02:56 PM, Livnat Peer wrote:
> On 22/11/12 23:18, Itamar Heim wrote:
>> On 11/22/2012 08:40 PM, Simon Grinberg wrote:
>>> Back to the original question:
>>>
>>> What is most inconvenient for many users is:
>>> 1. The name we provide while creating the VNIC differs from the one in
>>> the guest
>>> 2. No correlation between IP and NIC
>>>
>>> The current page covers for this but indeed as raised here does not
>>> cover what happens if this information is not easy to retrieve due to
>>> non strait forward configurations.
>>>
>>> What I suggest is,
>>>
>>> For the short term:
>>> - Agent to report the MACs, IPs and interface names if can be found,
>>> engine to match these to the existing and show
>>> Name In Engine| Name in guest | MAC | IP  etc like the current feature
>>> page, but...
>>>
>>> - If a match could not be found then just report Name in Engine N/A
>>> and then the rest and keep it in dynamic only table.
>>> This is useful for NICs created by hooks, advanced topology that we
>>> can't support ATM etc.
>>>
>>> *The above does require the agent to at least match MAC to IP.
>>>
>>>
>>> Long term: The agent to report a topology the same as vdsm does (use
>>> same code at least for Linux guests?) and present it similar to what
>>> we present in the host tab. In most cases this will collapse to the
>>> short term.
>>>
>>> MTU, is good to have in any of the two if we can get it.
>>>
>>> More?
>>
>> I don't think the guest agent ip information should be correlated to the
>> vnic engine information at rest api level.
>> the vm (and vnic) api provides the authoritative configuration
>> information of the guest as defined in the engine.
>> I don't think we should 'taint' it with untrusted data from the guest.
>> it would make sense to place there IPs configured/allocated by engine
>> when we deal with ip allocation though.
>>
>
>
> I was too quick to say we have an agreement...
>
> The comment above seems to give more emphasis on the segregation between
> data collected via the GA and data configured via the engine.
>
> In the API we have today the following modeling: per VM entity we hold
> GuestInfo entity and there we hold a list of IP addresses.
>
> Are you suggesting to keep this approach and not report anything on the
> vNIC level at this point (until we'll be able to configure IP addresses
> via the engine)?

yes.

> Or add GuestInfo element under /api/vms/{vm:id}/nics/{nic:id}/ which
> should be additional to the one on the VM level (as we discussed before
> the correlation between VNIC and GA reported data is not always possible)

i didn't think about reporting guest info at vnic level, only at vm 
level. it could be a valid option, but since some network information 
doesn't correlate to vnic's, i think a more natural modeling at vm level 
may be easier.

>
> Also what you have in mind for the UI?

at ui level i do think/agree it would make sense to show the ip per vnic 
if the correlation between the two is clean and direct (based on mac 
address i assume).
you do need to make sure "bad data" won't break the ui though.

>
>
>
>
>> i.e., the guest info element in the rest api provides good separation
>> between engine level data, and guest agent data.
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>




From lpeer at redhat.com  Sun Nov 25 13:21:28 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Sun, 25 Nov 2012 15:21:28 +0200
Subject: [Engine-devel] Report  vNic Implementation Details
In-Reply-To: <50B21669.7050207@redhat.com>
References: <29065531.665.1353609603432.JavaMail.javamailuser@localhost>
	<50AE96B8.4090001@redhat.com> <50B21586.6030601@redhat.com>
	<50B21669.7050207@redhat.com>
Message-ID: <50B21B58.8070600@redhat.com>

On 25/11/12 15:00, Itamar Heim wrote:
> On 11/25/2012 02:56 PM, Livnat Peer wrote:
>> On 22/11/12 23:18, Itamar Heim wrote:
>>> On 11/22/2012 08:40 PM, Simon Grinberg wrote:
>>>> Back to the original question:
>>>>
>>>> What is most inconvenient for many users is:
>>>> 1. The name we provide while creating the VNIC differs from the one in
>>>> the guest
>>>> 2. No correlation between IP and NIC
>>>>
>>>> The current page covers for this but indeed as raised here does not
>>>> cover what happens if this information is not easy to retrieve due to
>>>> non strait forward configurations.
>>>>
>>>> What I suggest is,
>>>>
>>>> For the short term:
>>>> - Agent to report the MACs, IPs and interface names if can be found,
>>>> engine to match these to the existing and show
>>>> Name In Engine| Name in guest | MAC | IP  etc like the current feature
>>>> page, but...
>>>>
>>>> - If a match could not be found then just report Name in Engine N/A
>>>> and then the rest and keep it in dynamic only table.
>>>> This is useful for NICs created by hooks, advanced topology that we
>>>> can't support ATM etc.
>>>>
>>>> *The above does require the agent to at least match MAC to IP.
>>>>
>>>>
>>>> Long term: The agent to report a topology the same as vdsm does (use
>>>> same code at least for Linux guests?) and present it similar to what
>>>> we present in the host tab. In most cases this will collapse to the
>>>> short term.
>>>>
>>>> MTU, is good to have in any of the two if we can get it.
>>>>
>>>> More?
>>>
>>> I don't think the guest agent ip information should be correlated to the
>>> vnic engine information at rest api level.
>>> the vm (and vnic) api provides the authoritative configuration
>>> information of the guest as defined in the engine.
>>> I don't think we should 'taint' it with untrusted data from the guest.
>>> it would make sense to place there IPs configured/allocated by engine
>>> when we deal with ip allocation though.
>>>
>>
>>
>> I was too quick to say we have an agreement...
>>
>> The comment above seems to give more emphasis on the segregation between
>> data collected via the GA and data configured via the engine.
>>
>> In the API we have today the following modeling: per VM entity we hold
>> GuestInfo entity and there we hold a list of IP addresses.
>>
>> Are you suggesting to keep this approach and not report anything on the
>> vNIC level at this point (until we'll be able to configure IP addresses
>> via the engine)?
> 
> yes.
> 
>> Or add GuestInfo element under /api/vms/{vm:id}/nics/{nic:id}/ which
>> should be additional to the one on the VM level (as we discussed before
>> the correlation between VNIC and GA reported data is not always possible)
> 
> i didn't think about reporting guest info at vnic level, only at vm
> level. it could be a valid option, but since some network information
> doesn't correlate to vnic's, i think a more natural modeling at vm level
> may be easier.
> 
>>
>> Also what you have in mind for the UI?
> 
> at ui level i do think/agree it would make sense to show the ip per vnic
> if the correlation between the two is clean and direct (based on mac
> address i assume).
> you do need to make sure "bad data" won't break the ui though.

I'm not sure I agree with the differentiation you are doing between UI
and API in this case.

If we think the IP address field per vNIC should display info configured
via the engine and not untrusted data (reported via the guest agent)
then we should keep this approach in the UI as well.

I agree that in some cases the API can model data differently, or enable
more complicated actions, but this is not the case, here we have the
same data modeled differently which can cause confusion with users.

I think that we should keep the separation in the UI as well and add GA
sub-tab in VM and there have a field network devices with the data given
by the GA. no correlation (between engine configured vNICs and GA
report) at this point, when we'll have the ip address configuration via
the engine we'll present per vNIC the address.



> 
>>
>>
>>
>>
>>> i.e., the guest info element in the rest api provides good separation
>>> between engine level data, and guest agent data.
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> 
> 



From danken at redhat.com  Sun Nov 25 13:58:07 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Sun, 25 Nov 2012 15:58:07 +0200
Subject: [Engine-devel] Report  vNic Implementation Details
In-Reply-To: <50B21B58.8070600@redhat.com>
References: <29065531.665.1353609603432.JavaMail.javamailuser@localhost>
	<50AE96B8.4090001@redhat.com> <50B21586.6030601@redhat.com>
	<50B21669.7050207@redhat.com> <50B21B58.8070600@redhat.com>
Message-ID: <20121125135807.GB3593@redhat.com>

On Sun, Nov 25, 2012 at 03:21:28PM +0200, Livnat Peer wrote:
> On 25/11/12 15:00, Itamar Heim wrote:
> > On 11/25/2012 02:56 PM, Livnat Peer wrote:
> >> On 22/11/12 23:18, Itamar Heim wrote:
> >>> On 11/22/2012 08:40 PM, Simon Grinberg wrote:
> >>>> Back to the original question:
> >>>>
> >>>> What is most inconvenient for many users is:
> >>>> 1. The name we provide while creating the VNIC differs from the one in
> >>>> the guest
> >>>> 2. No correlation between IP and NIC
> >>>>
> >>>> The current page covers for this but indeed as raised here does not
> >>>> cover what happens if this information is not easy to retrieve due to
> >>>> non strait forward configurations.
> >>>>
> >>>> What I suggest is,
> >>>>
> >>>> For the short term:
> >>>> - Agent to report the MACs, IPs and interface names if can be found,
> >>>> engine to match these to the existing and show
> >>>> Name In Engine| Name in guest | MAC | IP  etc like the current feature
> >>>> page, but...
> >>>>
> >>>> - If a match could not be found then just report Name in Engine N/A
> >>>> and then the rest and keep it in dynamic only table.
> >>>> This is useful for NICs created by hooks, advanced topology that we
> >>>> can't support ATM etc.
> >>>>
> >>>> *The above does require the agent to at least match MAC to IP.
> >>>>
> >>>>
> >>>> Long term: The agent to report a topology the same as vdsm does (use
> >>>> same code at least for Linux guests?) and present it similar to what
> >>>> we present in the host tab. In most cases this will collapse to the
> >>>> short term.
> >>>>
> >>>> MTU, is good to have in any of the two if we can get it.
> >>>>
> >>>> More?
> >>>
> >>> I don't think the guest agent ip information should be correlated to the
> >>> vnic engine information at rest api level.
> >>> the vm (and vnic) api provides the authoritative configuration
> >>> information of the guest as defined in the engine.
> >>> I don't think we should 'taint' it with untrusted data from the guest.
> >>> it would make sense to place there IPs configured/allocated by engine
> >>> when we deal with ip allocation though.
> >>>
> >>
> >>
> >> I was too quick to say we have an agreement...
> >>
> >> The comment above seems to give more emphasis on the segregation between
> >> data collected via the GA and data configured via the engine.
> >>
> >> In the API we have today the following modeling: per VM entity we hold
> >> GuestInfo entity and there we hold a list of IP addresses.
> >>
> >> Are you suggesting to keep this approach and not report anything on the
> >> vNIC level at this point (until we'll be able to configure IP addresses
> >> via the engine)?
> > 
> > yes.
> > 
> >> Or add GuestInfo element under /api/vms/{vm:id}/nics/{nic:id}/ which
> >> should be additional to the one on the VM level (as we discussed before
> >> the correlation between VNIC and GA reported data is not always possible)
> > 
> > i didn't think about reporting guest info at vnic level, only at vm
> > level. it could be a valid option, but since some network information
> > doesn't correlate to vnic's, i think a more natural modeling at vm level
> > may be easier.
> > 
> >>
> >> Also what you have in mind for the UI?
> > 
> > at ui level i do think/agree it would make sense to show the ip per vnic
> > if the correlation between the two is clean and direct (based on mac
> > address i assume).
> > you do need to make sure "bad data" won't break the ui though.
> 
> I'm not sure I agree with the differentiation you are doing between UI
> and API in this case.
> 
> If we think the IP address field per vNIC should display info configured
> via the engine and not untrusted data (reported via the guest agent)
> then we should keep this approach in the UI as well.
> 
> I agree that in some cases the API can model data differently, or enable
> more complicated actions, but this is not the case, here we have the
> same data modeled differently which can cause confusion with users.

Yeah, it's a bit unfair to the UI users: it's like saying "we do not
want to get API users confused by an evil guest agent, but we allow this
to happen to those in the UI".
> 
> I think that we should keep the separation in the UI as well and add GA
> sub-tab in VM and there have a field network devices with the data given
> by the GA. no correlation (between engine configured vNICs and GA
> report) at this point, when we'll have the ip address configuration via
> the engine we'll present per vNIC the address.

Still, the reasonable UI user is less likely to correlate
Engine-configured mac addresses to GA-reported ones. So presenting the
naive correlation between the two has a benefit.

Dan.


From lpeer at redhat.com  Sun Nov 25 16:02:17 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Sun, 25 Nov 2012 18:02:17 +0200
Subject: [Engine-devel] Report  vNic Implementation Details
In-Reply-To: <20121125135807.GB3593@redhat.com>
References: <29065531.665.1353609603432.JavaMail.javamailuser@localhost>
	<50AE96B8.4090001@redhat.com> <50B21586.6030601@redhat.com>
	<50B21669.7050207@redhat.com> <50B21B58.8070600@redhat.com>
	<20121125135807.GB3593@redhat.com>
Message-ID: <50B24109.5060401@redhat.com>

On 25/11/12 15:58, Dan Kenigsberg wrote:
> On Sun, Nov 25, 2012 at 03:21:28PM +0200, Livnat Peer wrote:
>> On 25/11/12 15:00, Itamar Heim wrote:
>>> On 11/25/2012 02:56 PM, Livnat Peer wrote:
>>>> On 22/11/12 23:18, Itamar Heim wrote:
>>>>> On 11/22/2012 08:40 PM, Simon Grinberg wrote:
>>>>>> Back to the original question:
>>>>>>
>>>>>> What is most inconvenient for many users is:
>>>>>> 1. The name we provide while creating the VNIC differs from the one in
>>>>>> the guest
>>>>>> 2. No correlation between IP and NIC
>>>>>>
>>>>>> The current page covers for this but indeed as raised here does not
>>>>>> cover what happens if this information is not easy to retrieve due to
>>>>>> non strait forward configurations.
>>>>>>
>>>>>> What I suggest is,
>>>>>>
>>>>>> For the short term:
>>>>>> - Agent to report the MACs, IPs and interface names if can be found,
>>>>>> engine to match these to the existing and show
>>>>>> Name In Engine| Name in guest | MAC | IP  etc like the current feature
>>>>>> page, but...
>>>>>>
>>>>>> - If a match could not be found then just report Name in Engine N/A
>>>>>> and then the rest and keep it in dynamic only table.
>>>>>> This is useful for NICs created by hooks, advanced topology that we
>>>>>> can't support ATM etc.
>>>>>>
>>>>>> *The above does require the agent to at least match MAC to IP.
>>>>>>
>>>>>>
>>>>>> Long term: The agent to report a topology the same as vdsm does (use
>>>>>> same code at least for Linux guests?) and present it similar to what
>>>>>> we present in the host tab. In most cases this will collapse to the
>>>>>> short term.
>>>>>>
>>>>>> MTU, is good to have in any of the two if we can get it.
>>>>>>
>>>>>> More?
>>>>>
>>>>> I don't think the guest agent ip information should be correlated to the
>>>>> vnic engine information at rest api level.
>>>>> the vm (and vnic) api provides the authoritative configuration
>>>>> information of the guest as defined in the engine.
>>>>> I don't think we should 'taint' it with untrusted data from the guest.
>>>>> it would make sense to place there IPs configured/allocated by engine
>>>>> when we deal with ip allocation though.
>>>>>
>>>>
>>>>
>>>> I was too quick to say we have an agreement...
>>>>
>>>> The comment above seems to give more emphasis on the segregation between
>>>> data collected via the GA and data configured via the engine.
>>>>
>>>> In the API we have today the following modeling: per VM entity we hold
>>>> GuestInfo entity and there we hold a list of IP addresses.
>>>>
>>>> Are you suggesting to keep this approach and not report anything on the
>>>> vNIC level at this point (until we'll be able to configure IP addresses
>>>> via the engine)?
>>>
>>> yes.
>>>
>>>> Or add GuestInfo element under /api/vms/{vm:id}/nics/{nic:id}/ which
>>>> should be additional to the one on the VM level (as we discussed before
>>>> the correlation between VNIC and GA reported data is not always possible)
>>>
>>> i didn't think about reporting guest info at vnic level, only at vm
>>> level. it could be a valid option, but since some network information
>>> doesn't correlate to vnic's, i think a more natural modeling at vm level
>>> may be easier.
>>>
>>>>
>>>> Also what you have in mind for the UI?
>>>
>>> at ui level i do think/agree it would make sense to show the ip per vnic
>>> if the correlation between the two is clean and direct (based on mac
>>> address i assume).
>>> you do need to make sure "bad data" won't break the ui though.
>>
>> I'm not sure I agree with the differentiation you are doing between UI
>> and API in this case.
>>
>> If we think the IP address field per vNIC should display info configured
>> via the engine and not untrusted data (reported via the guest agent)
>> then we should keep this approach in the UI as well.
>>
>> I agree that in some cases the API can model data differently, or enable
>> more complicated actions, but this is not the case, here we have the
>> same data modeled differently which can cause confusion with users.
> 
> Yeah, it's a bit unfair to the UI users: it's like saying "we do not
> want to get API users confused by an evil guest agent, but we allow this
> to happen to those in the UI".
>>
>> I think that we should keep the separation in the UI as well and add GA
>> sub-tab in VM and there have a field network devices with the data given
>> by the GA. no correlation (between engine configured vNICs and GA
>> report) at this point, when we'll have the ip address configuration via
>> the engine we'll present per vNIC the address.
> 
> Still, the reasonable UI user is less likely to correlate
> Engine-configured mac addresses to GA-reported ones. So presenting the
> naive correlation between the two has a benefit.

I think it can be confusing for users who use both API and UI.
Also if I have to explain that later on the users list I don't see a
good reason or logic behind this that I can use.
I think we should keep it aligned (UI-API).


> 
> Dan.
> 



From abonas at redhat.com  Mon Nov 26 09:15:14 2012
From: abonas at redhat.com (Alissa Bonas)
Date: Mon, 26 Nov 2012 04:15:14 -0500 (EST)
Subject: [Engine-devel] maven settings.xml in building ovirt engine wiki
In-Reply-To: <715201371.6793980.1353920885975.JavaMail.root@redhat.com>
Message-ID: <1007139143.6796345.1353921314570.JavaMail.root@redhat.com>

Hi,

In this wiki http://wiki.ovirt.org/wiki/Building_oVirt_engine

The suggested maven settings.xml contains hardcoded paths to jboss_home and java_home.
IMHO it's better to use environment variables to take the above settings from there, instead of managing those settings twice in 2 different places.

The current settings look like this (note that java path is incorrect anyway, including /bin/java)

 <jbossHome>/usr/share/jboss-as</jbossHome>
 <JAVA_HOME>/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.0.x86_64/bin/java</JAVA_HOME>

How about changing settings.xml to something like:

  <jbossHome>${env.JBOSS_HOME}</jbossHome>
  <JAVA_HOME>${env.JAVA_HOME}</JAVA_HOME>


Does anyone see a problem with the suggested approach?

Thanks

Alissa



From alonbl at redhat.com  Mon Nov 26 09:18:57 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Mon, 26 Nov 2012 04:18:57 -0500 (EST)
Subject: [Engine-devel] maven settings.xml in building ovirt engine wiki
In-Reply-To: <1007139143.6796345.1353921314570.JavaMail.root@redhat.com>
Message-ID: <1686367332.1388894.1353921537535.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alissa Bonas" <abonas at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Monday, November 26, 2012 11:15:14 AM
> Subject: [Engine-devel] maven settings.xml in building ovirt engine wiki
> 
> Hi,
> 
> In this wiki http://wiki.ovirt.org/wiki/Building_oVirt_engine
> 
> The suggested maven settings.xml contains hardcoded paths to
> jboss_home and java_home.
> IMHO it's better to use environment variables to take the above
> settings from there, instead of managing those settings twice in 2
> different places.
> 
> The current settings look like this (note that java path is incorrect
> anyway, including /bin/java)
> 
>  <jbossHome>/usr/share/jboss-as</jbossHome>
>  <JAVA_HOME>/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.0.x86_64/bin/java</JAVA_HOME>
> 
> How about changing settings.xml to something like:
> 
>   <jbossHome>${env.JBOSS_HOME}</jbossHome>
>   <JAVA_HOME>${env.JAVA_HOME}</JAVA_HOME>
> 
> 
> Does anyone see a problem with the suggested approach?

Well, I did not use this either... just pass -DjbossHome=... to maven.

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


From lhornyak at redhat.com  Mon Nov 26 16:52:52 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Mon, 26 Nov 2012 11:52:52 -0500 (EST)
Subject: [Engine-devel] maven settings.xml in building ovirt engine wiki
In-Reply-To: <1007139143.6796345.1353921314570.JavaMail.root@redhat.com>
Message-ID: <110546079.728955.1353948772248.JavaMail.root@redhat.com>

Hi,

That too could work, but once it already needs to be in the settings.xml, why would you want another configuration file (like .bashrc)?

----- Original Message -----
> From: "Alissa Bonas" <abonas at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Monday, November 26, 2012 10:15:14 AM
> Subject: [Engine-devel] maven settings.xml in building ovirt engine wiki
> 
> Hi,
> 
> In this wiki http://wiki.ovirt.org/wiki/Building_oVirt_engine
> 
> The suggested maven settings.xml contains hardcoded paths to
> jboss_home and java_home.
> IMHO it's better to use environment variables to take the above
> settings from there, instead of managing those settings twice in 2
> different places.
> 
> The current settings look like this (note that java path is incorrect
> anyway, including /bin/java)
> 
>  <jbossHome>/usr/share/jboss-as</jbossHome>
>  <JAVA_HOME>/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.0.x86_64/bin/java</JAVA_HOME>
> 
> How about changing settings.xml to something like:
> 
>   <jbossHome>${env.JBOSS_HOME}</jbossHome>
>   <JAVA_HOME>${env.JAVA_HOME}</JAVA_HOME>
> 
> 
> Does anyone see a problem with the suggested approach?
> 
> Thanks
> 
> Alissa
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From lijiangsheng1 at gmail.com  Tue Nov 27 03:38:59 2012
From: lijiangsheng1 at gmail.com (=?GB2312?B?ysrZ7g==?=)
Date: Tue, 27 Nov 2012 11:38:59 +0800
Subject: [Engine-devel] Engine-devel Digest, Vol 14, Issue 70
In-Reply-To: <mailman.9.1353949208.28294.engine-devel@ovirt.org>
References: <mailman.9.1353949208.28294.engine-devel@ovirt.org>
Message-ID: <CANNDdqM5k8ahZuqpykAvA+C9QV_KFFKVbNsyYg_2KGL2O=_L4Q@mail.gmail.com>

agreed,
I think before configure setting.xml , developer/builder must config
~/.bash_profile. add blow lines:

JAVA_HOME=/usrs/path
JBOSS_HOME=/jboss7/path
export JAVA_HOME
export JBOSS_HOME


.....


2012/11/27 <engine-devel-request at ovirt.org>

> Send Engine-devel mailing list submissions to
>         engine-devel at ovirt.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.ovirt.org/mailman/listinfo/engine-devel
> or, via email, send a message with subject or body 'help' to
>         engine-devel-request at ovirt.org
>
> You can reach the person managing the list at
>         engine-devel-owner at ovirt.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Engine-devel digest..."
>
>
> Today's Topics:
>
>    1. maven settings.xml in building ovirt engine wiki (Alissa Bonas)
>    2. Re: maven settings.xml in building ovirt engine wiki
>       (Alon Bar-Lev)
>    3. Re: maven settings.xml in building ovirt engine wiki
>       (Laszlo Hornyak)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 26 Nov 2012 04:15:14 -0500 (EST)
> From: Alissa Bonas <abonas at redhat.com>
> To: engine-devel at ovirt.org
> Subject: [Engine-devel] maven settings.xml in building ovirt engine
>         wiki
> Message-ID:
>         <1007139143.6796345.1353921314570.JavaMail.root at redhat.com>
> Content-Type: text/plain; charset=utf-8
>
> Hi,
>
> In this wiki http://wiki.ovirt.org/wiki/Building_oVirt_engine
>
> The suggested maven settings.xml contains hardcoded paths to jboss_home
> and java_home.
> IMHO it's better to use environment variables to take the above settings
> from there, instead of managing those settings twice in 2 different places.
>
> The current settings look like this (note that java path is incorrect
> anyway, including /bin/java)
>
>  <jbossHome>/usr/share/jboss-as</jbossHome>
>
>  <JAVA_HOME>/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.0.x86_64/bin/java</JAVA_HOME>
>
> How about changing settings.xml to something like:
>
>   <jbossHome>${env.JBOSS_HOME}</jbossHome>
>   <JAVA_HOME>${env.JAVA_HOME}</JAVA_HOME>
>
>
> Does anyone see a problem with the suggested approach?
>
> Thanks
>
> Alissa
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 26 Nov 2012 04:18:57 -0500 (EST)
> From: Alon Bar-Lev <alonbl at redhat.com>
> To: Alissa Bonas <abonas at redhat.com>
> Cc: engine-devel at ovirt.org
> Subject: Re: [Engine-devel] maven settings.xml in building ovirt
>         engine wiki
> Message-ID:
>         <1686367332.1388894.1353921537535.JavaMail.root at redhat.com>
> Content-Type: text/plain; charset=utf-8
>
>
>
> ----- Original Message -----
> > From: "Alissa Bonas" <abonas at redhat.com>
> > To: engine-devel at ovirt.org
> > Sent: Monday, November 26, 2012 11:15:14 AM
> > Subject: [Engine-devel] maven settings.xml in building ovirt engine wiki
> >
> > Hi,
> >
> > In this wiki http://wiki.ovirt.org/wiki/Building_oVirt_engine
> >
> > The suggested maven settings.xml contains hardcoded paths to
> > jboss_home and java_home.
> > IMHO it's better to use environment variables to take the above
> > settings from there, instead of managing those settings twice in 2
> > different places.
> >
> > The current settings look like this (note that java path is incorrect
> > anyway, including /bin/java)
> >
> >  <jbossHome>/usr/share/jboss-as</jbossHome>
> >
>  <JAVA_HOME>/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.0.x86_64/bin/java</JAVA_HOME>
> >
> > How about changing settings.xml to something like:
> >
> >   <jbossHome>${env.JBOSS_HOME}</jbossHome>
> >   <JAVA_HOME>${env.JAVA_HOME}</JAVA_HOME>
> >
> >
> > Does anyone see a problem with the suggested approach?
>
> Well, I did not use this either... just pass -DjbossHome=... to maven.
>
> >
> > Thanks
> >
> > Alissa
> >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 26 Nov 2012 11:52:52 -0500 (EST)
> From: Laszlo Hornyak <lhornyak at redhat.com>
> To: Alissa Bonas <abonas at redhat.com>
> Cc: engine-devel at ovirt.org
> Subject: Re: [Engine-devel] maven settings.xml in building ovirt
>         engine wiki
> Message-ID: <110546079.728955.1353948772248.JavaMail.root at redhat.com>
> Content-Type: text/plain; charset=utf-8
>
> Hi,
>
> That too could work, but once it already needs to be in the settings.xml,
> why would you want another configuration file (like .bashrc)?
>
> ----- Original Message -----
> > From: "Alissa Bonas" <abonas at redhat.com>
> > To: engine-devel at ovirt.org
> > Sent: Monday, November 26, 2012 10:15:14 AM
> > Subject: [Engine-devel] maven settings.xml in building ovirt engine wiki
> >
> > Hi,
> >
> > In this wiki http://wiki.ovirt.org/wiki/Building_oVirt_engine
> >
> > The suggested maven settings.xml contains hardcoded paths to
> > jboss_home and java_home.
> > IMHO it's better to use environment variables to take the above
> > settings from there, instead of managing those settings twice in 2
> > different places.
> >
> > The current settings look like this (note that java path is incorrect
> > anyway, including /bin/java)
> >
> >  <jbossHome>/usr/share/jboss-as</jbossHome>
> >
>  <JAVA_HOME>/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.0.x86_64/bin/java</JAVA_HOME>
> >
> > How about changing settings.xml to something like:
> >
> >   <jbossHome>${env.JBOSS_HOME}</jbossHome>
> >   <JAVA_HOME>${env.JAVA_HOME}</JAVA_HOME>
> >
> >
> > Does anyone see a problem with the suggested approach?
> >
> > Thanks
> >
> > Alissa
> >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
>
>
> ------------------------------
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
>
> End of Engine-devel Digest, Vol 14, Issue 70
> ********************************************
>



-- 
????????????
                        --???
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121127/2f1aabee/attachment.html>

From omasad at redhat.com  Tue Nov 27 07:10:48 2012
From: omasad at redhat.com (Ofri Masad)
Date: Tue, 27 Nov 2012 02:10:48 -0500 (EST)
Subject: [Engine-devel] maven settings.xml in building ovirt engine wiki
In-Reply-To: <110546079.728955.1353948772248.JavaMail.root@redhat.com>
Message-ID: <739151932.1653649.1354000248658.JavaMail.root@redhat.com>

Hi,

I can't seem to find it, but i think there was a wiki page about working with multiple environments (Upstream/Downstream/ZStream...)

Currently I'm using soft links to the setting.xml and .m2 repo. That way i can jump safely and quickly between environments.
The paths are hard codded in the xml but i have few xml files ponting to different jdk and jboss.
 

----- Original Message -----
From: "Laszlo Hornyak" <lhornyak at redhat.com>
To: "Alissa Bonas" <abonas at redhat.com>
Cc: engine-devel at ovirt.org
Sent: Monday, November 26, 2012 6:52:52 PM
Subject: Re: [Engine-devel] maven settings.xml in building ovirt engine wiki

Hi,

That too could work, but once it already needs to be in the settings.xml, why would you want another configuration file (like .bashrc)?

----- Original Message -----
> From: "Alissa Bonas" <abonas at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Monday, November 26, 2012 10:15:14 AM
> Subject: [Engine-devel] maven settings.xml in building ovirt engine wiki
> 
> Hi,
> 
> In this wiki http://wiki.ovirt.org/wiki/Building_oVirt_engine
> 
> The suggested maven settings.xml contains hardcoded paths to
> jboss_home and java_home.
> IMHO it's better to use environment variables to take the above
> settings from there, instead of managing those settings twice in 2
> different places.
> 
> The current settings look like this (note that java path is incorrect
> anyway, including /bin/java)
> 
>  <jbossHome>/usr/share/jboss-as</jbossHome>
>  <JAVA_HOME>/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.0.x86_64/bin/java</JAVA_HOME>
> 
> How about changing settings.xml to something like:
> 
>   <jbossHome>${env.JBOSS_HOME}</jbossHome>
>   <JAVA_HOME>${env.JAVA_HOME}</JAVA_HOME>
> 
> 
> Does anyone see a problem with the suggested approach?
> 
> Thanks
> 
> Alissa
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
_______________________________________________
Engine-devel mailing list
Engine-devel at ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel


From nslomian at redhat.com  Tue Nov 27 07:27:54 2012
From: nslomian at redhat.com (Noam Slomianko)
Date: Tue, 27 Nov 2012 02:27:54 -0500 (EST)
Subject: [Engine-devel] maven settings.xml in building ovirt engine wiki
In-Reply-To: <739151932.1653649.1354000248658.JavaMail.root@redhat.com>
Message-ID: <2003207823.7578885.1354001274886.JavaMail.root@redhat.com>

The Intranet is a black hole... documents can only go in never to be found again.
I needed to go back 3 months in my browsing history to find this, because why should it be found with keywords like upstream or downstream :P

https://home.corp.redhat.com/wiki/working-downstream-and-upstream-parallel

Have fun,
Noam.

----- Original Message -----
From: "Ofri Masad" <omasad at redhat.com>
To: "Laszlo Hornyak" <lhornyak at redhat.com>, "Noam Slomianko" <nslomian at redhat.com>
Cc: engine-devel at ovirt.org, "Alissa Bonas" <abonas at redhat.com>
Sent: Tuesday, November 27, 2012 9:10:48 AM
Subject: Re: [Engine-devel] maven settings.xml in building ovirt engine wiki

Hi,

I can't seem to find it, but i think there was a wiki page about working with multiple environments (Upstream/Downstream/ZStream...)

Currently I'm using soft links to the setting.xml and .m2 repo. That way i can jump safely and quickly between environments.
The paths are hard codded in the xml but i have few xml files ponting to different jdk and jboss.
 

----- Original Message -----
From: "Laszlo Hornyak" <lhornyak at redhat.com>
To: "Alissa Bonas" <abonas at redhat.com>
Cc: engine-devel at ovirt.org
Sent: Monday, November 26, 2012 6:52:52 PM
Subject: Re: [Engine-devel] maven settings.xml in building ovirt engine wiki

Hi,

That too could work, but once it already needs to be in the settings.xml, why would you want another configuration file (like .bashrc)?

----- Original Message -----
> From: "Alissa Bonas" <abonas at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Monday, November 26, 2012 10:15:14 AM
> Subject: [Engine-devel] maven settings.xml in building ovirt engine wiki
> 
> Hi,
> 
> In this wiki http://wiki.ovirt.org/wiki/Building_oVirt_engine
> 
> The suggested maven settings.xml contains hardcoded paths to
> jboss_home and java_home.
> IMHO it's better to use environment variables to take the above
> settings from there, instead of managing those settings twice in 2
> different places.
> 
> The current settings look like this (note that java path is incorrect
> anyway, including /bin/java)
> 
>  <jbossHome>/usr/share/jboss-as</jbossHome>
>  <JAVA_HOME>/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.0.x86_64/bin/java</JAVA_HOME>
> 
> How about changing settings.xml to something like:
> 
>   <jbossHome>${env.JBOSS_HOME}</jbossHome>
>   <JAVA_HOME>${env.JAVA_HOME}</JAVA_HOME>
> 
> 
> Does anyone see a problem with the suggested approach?
> 
> Thanks
> 
> Alissa
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
_______________________________________________
Engine-devel mailing list
Engine-devel at ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel


From abonas at redhat.com  Tue Nov 27 08:33:53 2012
From: abonas at redhat.com (Alissa Bonas)
Date: Tue, 27 Nov 2012 03:33:53 -0500 (EST)
Subject: [Engine-devel] maven settings.xml in building ovirt engine wiki
In-Reply-To: <110546079.728955.1353948772248.JavaMail.root@redhat.com>
Message-ID: <343453643.7593404.1354005233359.JavaMail.root@redhat.com>

settings.xml is consumed by maven only, while other programs such as IDE, Jboss, etc consume environment variables set in other ways such as .bashrc. 
Thus we need them both - and this is why I think it's better to re-use the configuration from .bashrc in settings.xml.

----- Original Message -----
From: "Laszlo Hornyak" <lhornyak at redhat.com>
To: "Alissa Bonas" <abonas at redhat.com>
Cc: engine-devel at ovirt.org
Sent: Monday, November 26, 2012 6:52:52 PM
Subject: Re: [Engine-devel] maven settings.xml in building ovirt engine wiki

Hi,

That too could work, but once it already needs to be in the settings.xml, why would you want another configuration file (like .bashrc)?

----- Original Message -----
> From: "Alissa Bonas" <abonas at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Monday, November 26, 2012 10:15:14 AM
> Subject: [Engine-devel] maven settings.xml in building ovirt engine wiki
> 
> Hi,
> 
> In this wiki http://wiki.ovirt.org/wiki/Building_oVirt_engine
> 
> The suggested maven settings.xml contains hardcoded paths to
> jboss_home and java_home.
> IMHO it's better to use environment variables to take the above
> settings from there, instead of managing those settings twice in 2
> different places.
> 
> The current settings look like this (note that java path is incorrect
> anyway, including /bin/java)
> 
>  <jbossHome>/usr/share/jboss-as</jbossHome>
>  <JAVA_HOME>/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.0.x86_64/bin/java</JAVA_HOME>
> 
> How about changing settings.xml to something like:
> 
>   <jbossHome>${env.JBOSS_HOME}</jbossHome>
>   <JAVA_HOME>${env.JAVA_HOME}</JAVA_HOME>
> 
> 
> Does anyone see a problem with the suggested approach?
> 
> Thanks
> 
> Alissa
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From nslomian at redhat.com  Tue Nov 27 08:36:25 2012
From: nslomian at redhat.com (Noam Slomianko)
Date: Tue, 27 Nov 2012 03:36:25 -0500 (EST)
Subject: [Engine-devel] maven settings.xml in building ovirt engine wiki
In-Reply-To: <2003207823.7578885.1354001274886.JavaMail.root@redhat.com>
Message-ID: <234523159.7593905.1354005385474.JavaMail.root@redhat.com>

Oh, sorry.
Didnt notice it was sent to an ovit mailing list :D

so, my solution is:

create two different files (containing at least):

<settings xmlns="http://maven.apache.org/POM/4.0.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                              http://maven.apache.org/xsd/settings-1.0.0.xsd">

<!--**************************** PROFILES ****************************-->

        <localRepository>{maven_home}/{repository}</localRepository>

        <activeProfiles>
                        <activeProfile>oVirtEnvSettings</activeProfile>
        </activeProfiles>

        <profiles>
                <profile>
                        <id>oVirtEnvSettings</id>
                        <properties>
                                <jbossHome>{jboss location}</jbossHome>
                                <JAVA_HOME>{java location}</JAVA_HOME>
                                <gwt.userAgent>gecko1_8</gwt.userAgent>
                        </properties>
                </profile>
         </profiles>
</settings> 

Between the two file you change:
 - {jboss location}, self explanatory
 - {java location}, only if they are of a different version
 - {repository}, so you dont get conflicting packages
Of course they shouldn't be called Settings.xml


And then add a change script so its easy to switch via a soft link, mine is:
if [ $1 = "up" ]
then
        rm ~/.m2/settings.xml
        ln -s ~/.m2/settingsUp.xml ~/.m2/settings.xml
        echo "changed jboss to upstream (1.7)"
else
        rm ~/.m2/settings.xml
        ln -s ~/.m2/settingsDown.xml ~/.m2/settings.xml
        echo "changed jboss to downstream (1.6)"
fi




----- Original Message -----
From: "Noam Slomianko" <nslomian at redhat.com>
To: "Ofri Masad" <omasad at redhat.com>
Cc: engine-devel at ovirt.org, "Alissa Bonas" <abonas at redhat.com>, "Laszlo Hornyak" <lhornyak at redhat.com>
Sent: Tuesday, November 27, 2012 9:27:54 AM
Subject: Re: [Engine-devel] maven settings.xml in building ovirt engine wiki

The Intranet is a black hole... documents can only go in never to be found again.
I needed to go back 3 months in my browsing history to find this, because why should it be found with keywords like upstream or downstream :P

https://home.corp.redhat.com/wiki/working-downstream-and-upstream-parallel

Have fun,
Noam.

----- Original Message -----
From: "Ofri Masad" <omasad at redhat.com>
To: "Laszlo Hornyak" <lhornyak at redhat.com>, "Noam Slomianko" <nslomian at redhat.com>
Cc: engine-devel at ovirt.org, "Alissa Bonas" <abonas at redhat.com>
Sent: Tuesday, November 27, 2012 9:10:48 AM
Subject: Re: [Engine-devel] maven settings.xml in building ovirt engine wiki

Hi,

I can't seem to find it, but i think there was a wiki page about working with multiple environments (Upstream/Downstream/ZStream...)

Currently I'm using soft links to the setting.xml and .m2 repo. That way i can jump safely and quickly between environments.
The paths are hard codded in the xml but i have few xml files ponting to different jdk and jboss.
 

----- Original Message -----
From: "Laszlo Hornyak" <lhornyak at redhat.com>
To: "Alissa Bonas" <abonas at redhat.com>
Cc: engine-devel at ovirt.org
Sent: Monday, November 26, 2012 6:52:52 PM
Subject: Re: [Engine-devel] maven settings.xml in building ovirt engine wiki

Hi,

That too could work, but once it already needs to be in the settings.xml, why would you want another configuration file (like .bashrc)?

----- Original Message -----
> From: "Alissa Bonas" <abonas at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Monday, November 26, 2012 10:15:14 AM
> Subject: [Engine-devel] maven settings.xml in building ovirt engine wiki
> 
> Hi,
> 
> In this wiki http://wiki.ovirt.org/wiki/Building_oVirt_engine
> 
> The suggested maven settings.xml contains hardcoded paths to
> jboss_home and java_home.
> IMHO it's better to use environment variables to take the above
> settings from there, instead of managing those settings twice in 2
> different places.
> 
> The current settings look like this (note that java path is incorrect
> anyway, including /bin/java)
> 
>  <jbossHome>/usr/share/jboss-as</jbossHome>
>  <JAVA_HOME>/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.0.x86_64/bin/java</JAVA_HOME>
> 
> How about changing settings.xml to something like:
> 
>   <jbossHome>${env.JBOSS_HOME}</jbossHome>
>   <JAVA_HOME>${env.JAVA_HOME}</JAVA_HOME>
> 
> 
> Does anyone see a problem with the suggested approach?
> 
> Thanks
> 
> Alissa
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
_______________________________________________
Engine-devel mailing list
Engine-devel at ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel


From sanjal at redhat.com  Tue Nov 27 09:07:11 2012
From: sanjal at redhat.com (Shireesh Anjal)
Date: Tue, 27 Nov 2012 14:37:11 +0530
Subject: [Engine-devel] maven settings.xml in building ovirt engine wiki
In-Reply-To: <234523159.7593905.1354005385474.JavaMail.root@redhat.com>
References: <234523159.7593905.1354005385474.JavaMail.root@redhat.com>
Message-ID: <50B482BF.5000306@redhat.com>

On Tuesday 27 November 2012 02:06 PM, Noam Slomianko wrote:
> Oh, sorry.
> Didnt notice it was sent to an ovit mailing list :D
>
> so, my solution is:
>
> create two different files (containing at least):
>
> <settings xmlns="http://maven.apache.org/POM/4.0.0"
>            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>            xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>                                http://maven.apache.org/xsd/settings-1.0.0.xsd">
>
> <!--**************************** PROFILES ****************************-->
>
>          <localRepository>{maven_home}/{repository}</localRepository>
>
>          <activeProfiles>
>                          <activeProfile>oVirtEnvSettings</activeProfile>
>          </activeProfiles>
>
>          <profiles>
>                  <profile>
>                          <id>oVirtEnvSettings</id>
>                          <properties>
>                                  <jbossHome>{jboss location}</jbossHome>
>                                  <JAVA_HOME>{java location}</JAVA_HOME>
>                                  <gwt.userAgent>gecko1_8</gwt.userAgent>
>                          </properties>
>                  </profile>
>           </profiles>
> </settings>
>
> Between the two file you change:
>   - {jboss location}, self explanatory
>   - {java location}, only if they are of a different version
>   - {repository}, so you dont get conflicting packages
> Of course they shouldn't be called Settings.xml
>
>
> And then add a change script so its easy to switch via a soft link, mine is:
> if [ $1 = "up" ]
> then
>          rm ~/.m2/settings.xml
>          ln -s ~/.m2/settingsUp.xml ~/.m2/settings.xml
>          echo "changed jboss to upstream (1.7)"
> else
>          rm ~/.m2/settings.xml
>          ln -s ~/.m2/settingsDown.xml ~/.m2/settings.xml
>          echo "changed jboss to downstream (1.6)"
> fi

Another trick is to use the --settings option of maven e.g.

mvn --settings ~/.m2/settingsUp.xml clean install -Pdep

>
>
>
> ----- Original Message -----
> From: "Noam Slomianko" <nslomian at redhat.com>
> To: "Ofri Masad" <omasad at redhat.com>
> Cc: engine-devel at ovirt.org, "Alissa Bonas" <abonas at redhat.com>, "Laszlo Hornyak" <lhornyak at redhat.com>
> Sent: Tuesday, November 27, 2012 9:27:54 AM
> Subject: Re: [Engine-devel] maven settings.xml in building ovirt engine wiki
>
> The Intranet is a black hole... documents can only go in never to be found again.
> I needed to go back 3 months in my browsing history to find this, because why should it be found with keywords like upstream or downstream :P
>
> https://home.corp.redhat.com/wiki/working-downstream-and-upstream-parallel
>
> Have fun,
> Noam.
>
> ----- Original Message -----
> From: "Ofri Masad" <omasad at redhat.com>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>, "Noam Slomianko" <nslomian at redhat.com>
> Cc: engine-devel at ovirt.org, "Alissa Bonas" <abonas at redhat.com>
> Sent: Tuesday, November 27, 2012 9:10:48 AM
> Subject: Re: [Engine-devel] maven settings.xml in building ovirt engine wiki
>
> Hi,
>
> I can't seem to find it, but i think there was a wiki page about working with multiple environments (Upstream/Downstream/ZStream...)
>
> Currently I'm using soft links to the setting.xml and .m2 repo. That way i can jump safely and quickly between environments.
> The paths are hard codded in the xml but i have few xml files ponting to different jdk and jboss.
>   
>
> ----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "Alissa Bonas" <abonas at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Monday, November 26, 2012 6:52:52 PM
> Subject: Re: [Engine-devel] maven settings.xml in building ovirt engine wiki
>
> Hi,
>
> That too could work, but once it already needs to be in the settings.xml, why would you want another configuration file (like .bashrc)?
>
> ----- Original Message -----
>> From: "Alissa Bonas" <abonas at redhat.com>
>> To: engine-devel at ovirt.org
>> Sent: Monday, November 26, 2012 10:15:14 AM
>> Subject: [Engine-devel] maven settings.xml in building ovirt engine wiki
>>
>> Hi,
>>
>> In this wiki http://wiki.ovirt.org/wiki/Building_oVirt_engine
>>
>> The suggested maven settings.xml contains hardcoded paths to
>> jboss_home and java_home.
>> IMHO it's better to use environment variables to take the above
>> settings from there, instead of managing those settings twice in 2
>> different places.
>>
>> The current settings look like this (note that java path is incorrect
>> anyway, including /bin/java)
>>
>>   <jbossHome>/usr/share/jboss-as</jbossHome>
>>   <JAVA_HOME>/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.0.x86_64/bin/java</JAVA_HOME>
>>
>> How about changing settings.xml to something like:
>>
>>    <jbossHome>${env.JBOSS_HOME}</jbossHome>
>>    <JAVA_HOME>${env.JAVA_HOME}</JAVA_HOME>
>>
>>
>> Does anyone see a problem with the suggested approach?
>>
>> Thanks
>>
>> Alissa
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From amureini at redhat.com  Tue Nov 27 15:32:35 2012
From: amureini at redhat.com (Allon Mureinik)
Date: Tue, 27 Nov 2012 10:32:35 -0500 (EST)
Subject: [Engine-devel] maven settings.xml in building ovirt engine wiki
In-Reply-To: <50B482BF.5000306@redhat.com>
Message-ID: <993311130.6669979.1354030355846.JavaMail.root@redhat.com>

Form my understanding, the issue was not maintaining multiple settings.xml file, it was the fact that oVirt's wiki suggests a settings.xml file with /a hard coded path/, which many potential community members will not have, simply because they installed Java and/or JBoss in a different location.

Since in order to run JBoss properly you should already have $JBOSS_HOME and $JAVA_HOME defined, the suggestion here was to reuse those values in settings.xml too.

----- Original Message -----
> From: "Shireesh Anjal" <sanjal at redhat.com>
> To: "Noam Slomianko" <nslomian at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Tuesday, November 27, 2012 11:07:11 AM
> Subject: Re: [Engine-devel] maven settings.xml in building ovirt engine wiki
> 
> On Tuesday 27 November 2012 02:06 PM, Noam Slomianko wrote:
> > Oh, sorry.
> > Didnt notice it was sent to an ovit mailing list :D
> >
> > so, my solution is:
> >
> > create two different files (containing at least):
> >
> > <settings xmlns="http://maven.apache.org/POM/4.0.0"
> >            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> >            xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> >                                http://maven.apache.org/xsd/settings-1.0.0.xsd">
> >
> > <!--**************************** PROFILES
> > ****************************-->
> >
> >          <localRepository>{maven_home}/{repository}</localRepository>
> >
> >          <activeProfiles>
> >                          <activeProfile>oVirtEnvSettings</activeProfile>
> >          </activeProfiles>
> >
> >          <profiles>
> >                  <profile>
> >                          <id>oVirtEnvSettings</id>
> >                          <properties>
> >                                  <jbossHome>{jboss
> >                                  location}</jbossHome>
> >                                  <JAVA_HOME>{java
> >                                  location}</JAVA_HOME>
> >                                  <gwt.userAgent>gecko1_8</gwt.userAgent>
> >                          </properties>
> >                  </profile>
> >           </profiles>
> > </settings>
> >
> > Between the two file you change:
> >   - {jboss location}, self explanatory
> >   - {java location}, only if they are of a different version
> >   - {repository}, so you dont get conflicting packages
> > Of course they shouldn't be called Settings.xml
> >
> >
> > And then add a change script so its easy to switch via a soft link,
> > mine is:
> > if [ $1 = "up" ]
> > then
> >          rm ~/.m2/settings.xml
> >          ln -s ~/.m2/settingsUp.xml ~/.m2/settings.xml
> >          echo "changed jboss to upstream (1.7)"
> > else
> >          rm ~/.m2/settings.xml
> >          ln -s ~/.m2/settingsDown.xml ~/.m2/settings.xml
> >          echo "changed jboss to downstream (1.6)"
> > fi
> 
> Another trick is to use the --settings option of maven e.g.
> 
> mvn --settings ~/.m2/settingsUp.xml clean install -Pdep
> 
> >
> >
> >
> > ----- Original Message -----
> > From: "Noam Slomianko" <nslomian at redhat.com>
> > To: "Ofri Masad" <omasad at redhat.com>
> > Cc: engine-devel at ovirt.org, "Alissa Bonas" <abonas at redhat.com>,
> > "Laszlo Hornyak" <lhornyak at redhat.com>
> > Sent: Tuesday, November 27, 2012 9:27:54 AM
> > Subject: Re: [Engine-devel] maven settings.xml in building ovirt
> > engine wiki
> >
> > The Intranet is a black hole... documents can only go in never to
> > be found again.
> > I needed to go back 3 months in my browsing history to find this,
> > because why should it be found with keywords like upstream or
> > downstream :P
> >
> > https://home.corp.redhat.com/wiki/working-downstream-and-upstream-parallel
> >
> > Have fun,
> > Noam.
> >
> > ----- Original Message -----
> > From: "Ofri Masad" <omasad at redhat.com>
> > To: "Laszlo Hornyak" <lhornyak at redhat.com>, "Noam Slomianko"
> > <nslomian at redhat.com>
> > Cc: engine-devel at ovirt.org, "Alissa Bonas" <abonas at redhat.com>
> > Sent: Tuesday, November 27, 2012 9:10:48 AM
> > Subject: Re: [Engine-devel] maven settings.xml in building ovirt
> > engine wiki
> >
> > Hi,
> >
> > I can't seem to find it, but i think there was a wiki page about
> > working with multiple environments
> > (Upstream/Downstream/ZStream...)
> >
> > Currently I'm using soft links to the setting.xml and .m2 repo.
> > That way i can jump safely and quickly between environments.
> > The paths are hard codded in the xml but i have few xml files
> > ponting to different jdk and jboss.
> >   
> >
> > ----- Original Message -----
> > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > To: "Alissa Bonas" <abonas at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Monday, November 26, 2012 6:52:52 PM
> > Subject: Re: [Engine-devel] maven settings.xml in building ovirt
> > engine wiki
> >
> > Hi,
> >
> > That too could work, but once it already needs to be in the
> > settings.xml, why would you want another configuration file (like
> > .bashrc)?
> >
> > ----- Original Message -----
> >> From: "Alissa Bonas" <abonas at redhat.com>
> >> To: engine-devel at ovirt.org
> >> Sent: Monday, November 26, 2012 10:15:14 AM
> >> Subject: [Engine-devel] maven settings.xml in building ovirt
> >> engine wiki
> >>
> >> Hi,
> >>
> >> In this wiki http://wiki.ovirt.org/wiki/Building_oVirt_engine
> >>
> >> The suggested maven settings.xml contains hardcoded paths to
> >> jboss_home and java_home.
> >> IMHO it's better to use environment variables to take the above
> >> settings from there, instead of managing those settings twice in 2
> >> different places.
> >>
> >> The current settings look like this (note that java path is
> >> incorrect
> >> anyway, including /bin/java)
> >>
> >>   <jbossHome>/usr/share/jboss-as</jbossHome>
> >>   <JAVA_HOME>/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.0.x86_64/bin/java</JAVA_HOME>
> >>
> >> How about changing settings.xml to something like:
> >>
> >>    <jbossHome>${env.JBOSS_HOME}</jbossHome>
> >>    <JAVA_HOME>${env.JAVA_HOME}</JAVA_HOME>
> >>
> >>
> >> Does anyone see a problem with the suggested approach?
> >>
> >> Thanks
> >>
> >> Alissa
> >>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From masayag at redhat.com  Tue Nov 27 21:10:34 2012
From: masayag at redhat.com (Moti Asayag)
Date: Tue, 27 Nov 2012 23:10:34 +0200
Subject: [Engine-devel] maven settings.xml in building ovirt engine wiki
In-Reply-To: <1007139143.6796345.1353921314570.JavaMail.root@redhat.com>
References: <1007139143.6796345.1353921314570.JavaMail.root@redhat.com>
Message-ID: <50B52C4A.2040501@redhat.com>

On 11/26/2012 11:15 AM, Alissa Bonas wrote:
> Hi,
> 
> In this wiki http://wiki.ovirt.org/wiki/Building_oVirt_engine
> 
> The suggested maven settings.xml contains hardcoded paths to jboss_home and java_home.
> IMHO it's better to use environment variables to take the above settings from there, instead of managing those settings twice in 2 different places.
> 
> The current settings look like this (note that java path is incorrect anyway, including /bin/java)
> 
>  <jbossHome>/usr/share/jboss-as</jbossHome>
>  <JAVA_HOME>/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.0.x86_64/bin/java</JAVA_HOME>
> 
> How about changing settings.xml to something like:
> 
>   <jbossHome>${env.JBOSS_HOME}</jbossHome>
>   <JAVA_HOME>${env.JAVA_HOME}</JAVA_HOME>
> 
> 
> Does anyone see a problem with the suggested approach?

Note that settings.xml isn't shifted with ovirt-engine, nor stored on
ovirt-engine git repository. Therefore there is no real method to
control its content expect updating the wiki page.

In any case - I'm in favour of updating the wiki according to your
suggestion.

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



From awinter at redhat.com  Tue Nov 27 23:24:57 2012
From: awinter at redhat.com (Amihay Winter)
Date: Tue, 27 Nov 2012 18:24:57 -0500 (EST)
Subject: [Engine-devel]  Report  vNic Implementation Details - Review
In-Reply-To: <50B1CCC6.4010900@redhat.com>
Message-ID: <260955981.23774334.1354058697904.JavaMail.root@redhat.com>


-------- Original Message -------- 
Subject: 	[Engine-devel] Report vNic Implementation Details 
Date: 	Wed, 21 Nov 2012 19:36:58 +0200 
From: 	Moti Asayag <masayag at redhat.com> 
To: 	engine-devel at ovirt.org <engine-devel at ovirt.org> 

Hi all,

This is a proposal for reporting the vNic implementation details as
reported by the guest agent per each vNic.

Please review the wiki and add your comments. http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation Thanks,

*****************
Does the design handle other properties other than increasing the address scope from 64 to 128 bits? 
I mean properties like (1) stateless address auto-configuration, (2) Multicast, (3) support bigger Jumboframes, (4) disable the broadcast feature that is being used in IPv4, (5) IPSec - and so on...
Amihay Winter.
*****************

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




From lpeer at redhat.com  Wed Nov 28 07:14:33 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Wed, 28 Nov 2012 09:14:33 +0200
Subject: [Engine-devel] ovirt network monthly sync meeting - Agenda
Message-ID: <50B5B9D9.4040000@redhat.com>

Hi All,
We have a scheduled sync meeting on oVirt network today.
We did not set an agenda for this meeting yet so I'll postpone it for
next week.

Please respond to this note with agenda items.  If there are
no agenda items by December 5th, I'll cancel the call.


Thanks, Livnat


From lpeer at redhat.com  Wed Nov 28 07:14:46 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Wed, 28 Nov 2012 02:14:46 -0500 (EST)
Subject: [Engine-devel] ovirt network
Message-ID: <670387070.869419.1354086886755.JavaMail.root@redhat.com>

A single instance of the following meeting has been modified:

Subject: ovirt network  
Organiser: "Livnat Peer" <lpeer at redhat.com> 

Time: Wednesday, 5 December, 2012, 4:00:00 PM - 5:00:00 PM GMT +02:00 Jerusalem [MODIFIED]
 
Invitees: engine-devel at ovirt.org; vdsm-devel at lists.fedorahosted.org; GARGYA at de.ibm.com; dyasny at redhat.com; simon at redhat.com; mkolesni at redhat.com; atal at redhat.com; ilvovsky at redhat.com; dfediuck at redhat.com; pradipta.banerjee at gmail.com; gkotton at redhat.com ... 


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

Hi All, 
As discussed previously on the list, I am adding a monthly discussion on Networking in oVirt. 
In this meeting we'll discuss general status of networking and features that we're missing. 

Thanks, Livnat 


Bridge ID: 972506565679 
Dial-in information: 
Reservationless-Plus Toll Free Dial-In Number (US & Canada): (800) 451-8679 
Reservationless-Plus International Dial-In Number: (212) 729-5016 
Conference code: 8425973915 

Global Access Numbers Local: 
Australia, Sydney Dial-In #: 0289852326 
Austria, Vienna Dial-In #: 012534978196 
Belgium, Brussels Dial-In #: 027920405 
China Dial-In #: 4006205013 
Denmark, Copenhagen Dial-In #: 32729215 
Finland, Helsinki Dial-In #: 0923194436 
France, Paris Dial-In #: 0170377140 
Germany, Berlin Dial-In #: 030300190579 
Ireland, Dublin Dial-In #: 014367793 
Italy, Milan Dial-In #: 0236269529 
Netherlands, Amsterdam Dial-In #: 0207975872 
Norway, Oslo Dial-In #: 21033188 
Singapore Dial-In #: 64840858 
Spain, Barcelona Dial-In #: 935452328 
Sweden, Stockholm Dial-In #: 0850513770 
Switzerland, Geneva Dial-In #: 0225927881 
United Kingdom Dial-In #: 02078970515 
United Kingdom Dial-In #: 08445790676 
United Kingdom, LocalCall Dial-In #: 08445790678 
United States Dial-In #: 2127295016 


Global Access Numbers Tollfree: 
Argentina Dial-In #: 8004441016 
Australia Dial-In #: 1800337169 
Austria Dial-In #: 0800005898 
Bahamas Dial-In #: 18002054776 
Bahrain Dial-In #: 80004377 
Belgium Dial-In #: 080048325 
Brazil Dial-In #: 08008921002 
Bulgaria Dial-In #: 008001100236 
Chile Dial-In #: 800370228 
Colombia Dial-In #: 018009134033 
Costa Rica Dial-In #: 08000131048 
Cyprus Dial-In #: 80095297 
Czech Republic Dial-In #: 800700318 
Denmark Dial-In #: 80887114 
Dominican Republic Dial-In #: 18887512313 
Estonia Dial-In #: 8000100232 
Finland Dial-In #: 0800117116 
France Dial-In #: 0805632867 
Germany Dial-In #: 8006647541 
Greece Dial-In #: 00800127562 
Hong Kong Dial-In #: 800930349 
Hungary Dial-In #: 0680016796 
Iceland Dial-In #: 8008967 
India Dial-In #: 0008006501533 
Indonesia Dial-In #: 0018030179162 
Ireland Dial-In #: 1800932401 
Israel Dial-In #: 1809462557 
Italy Dial-In #: 800985897 
Jamaica Dial-In #: 18002050328 
Japan Dial-In #: 0120934453 
Korea (South) Dial-In #: 007986517393 
Latvia Dial-In #: 80003339 
Lithuania Dial-In #: 880030479 
Luxembourg Dial-In #: 80026595 
Malaysia Dial-In #: 1800814451 
Mexico Dial-In #: 0018664590915 
New Zealand Dial-In #: 0800888167 
Norway Dial-In #: 80012994 
Panama Dial-In #: 008002269184 
Philippines Dial-In #: 180011100991 
Poland Dial-In #: 008001210187 
Portugal Dial-In #: 800814625 
Russian Federation Dial-In #: 81080028341012 
Saint Kitts and Nevis Dial-In #: 18002059252 
Singapore Dial-In #: 8006162235 
Slovak Republic Dial-In #: 0800001441 
South Africa Dial-In #: 0800981148 
Spain Dial-In #: 800300524 
Sweden Dial-In #: 200896860 
Switzerland Dial-In #: 800650077 
Taiwan Dial-In #: 00801127141 
Thailand Dial-In #: 001800656966 
Trinidad and Tobago Dial-In #: 18002024615 
United Arab Emirates Dial-In #: 8000650591 
United Kingdom Dial-In #: 08006948057 
United States Dial-In #: 8004518679 
Uruguay Dial-In #: 00040190315 
Venezuela Dial-In #: 08001627182 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121128/de803ccc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meeting.ics
Type: text/calendar
Size: 11056 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121128/de803ccc/attachment.ics>

From amureini at redhat.com  Wed Nov 28 08:05:18 2012
From: amureini at redhat.com (Allon Mureinik)
Date: Wed, 28 Nov 2012 03:05:18 -0500 (EST)
Subject: [Engine-devel] Shipping settings.xml in oVirt engine's git repo
 (was RE: maven settings.xml in building ovirt engine wiki)
In-Reply-To: <50B52C4A.2040501@redhat.com>
Message-ID: <2125858346.7067971.1354089918174.JavaMail.root@redhat.com>

<snipped>
> Note that settings.xml isn't shifted with ovirt-engine, nor stored on
> ovirt-engine git repository. Therefore there is no real method to
> control its content expect updating the wiki page.

Spinning off from the previous discussion - we can't really control the contents of settings.xml, but perhaps we can make them easier to get.

Today, the flow is like this:
1. git clone - depends on gerrit.ovirt.org
2. wget settings.xml - depends on wiki.ovirt.org

Suppose we ship settings.xml inside the configuration folder of ovirt (next to engine-code-format.xml and engine-commit-template.txt).
Then you'll have to do:
1. git clone - depends on gerrit.ovirt.org
2. cp $OVIRT_GIT/config/settings.xml ~/.m2/

This may a bit simpler, and at the very least, when we update our code (e.g., to assume java7, *hint*), we can make all the changes in a single commit, and not have to update the code and then upload a file to the wiki.

Comments? Feedback?


-Allon


From alonbl at redhat.com  Wed Nov 28 08:14:02 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Wed, 28 Nov 2012 03:14:02 -0500 (EST)
Subject: [Engine-devel] Shipping settings.xml in oVirt engine's git repo
 (was RE: maven settings.xml in building ovirt engine wiki)
In-Reply-To: <2125858346.7067971.1354089918174.JavaMail.root@redhat.com>
Message-ID: <1750442714.1923331.1354090442850.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Allon Mureinik" <amureini at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Wednesday, November 28, 2012 10:05:18 AM
> Subject: [Engine-devel] Shipping settings.xml in oVirt engine's git repo (was RE: maven settings.xml in building
> ovirt engine wiki)
> 
> <snipped>
> > Note that settings.xml isn't shifted with ovirt-engine, nor stored
> > on
> > ovirt-engine git repository. Therefore there is no real method to
> > control its content expect updating the wiki page.
> 
> Spinning off from the previous discussion - we can't really control
> the contents of settings.xml, but perhaps we can make them easier to
> get.
> 
> Today, the flow is like this:
> 1. git clone - depends on gerrit.ovirt.org
> 2. wget settings.xml - depends on wiki.ovirt.org
> 
> Suppose we ship settings.xml inside the configuration folder of ovirt
> (next to engine-code-format.xml and engine-commit-template.txt).
> Then you'll have to do:
> 1. git clone - depends on gerrit.ovirt.org
> 2. cp $OVIRT_GIT/config/settings.xml ~/.m2/
> 
> This may a bit simpler, and at the very least, when we update our
> code (e.g., to assume java7, *hint*), we can make all the changes in
> a single commit, and not have to update the code and then upload a
> file to the wiki.
> 
> Comments? Feedback?

First thing... I don't like changing global state of a machine only because we require some setting...

So copying <ANYTHING> to ~/.m2 is completely wrong in my opinion.

There is -gs parameter for maven to specify alternate settings file, I strongly recommend people use it.

Also, as far as I understand we only need some attributes defined... It is simple to use:

$ export MAVEN_OPTS="-Dwhatever=value -Dwhatever=value"

Before executing eclipse or make...

We can also integrate the environment variables idea into the maven build, instead of using properties use environment variables... then before executing build we:

$ export JBOSS_HOME=
$ export OVIRT_JDK_HOME= (optional)

If anyone prefers/chooses to use settings.xml he can create his own...

So there are so many options, the last option is to use settings.xml in my opinion... not that I against adding this template, but I first suggest we consider removing its usage completely.... :)

Regards,
Alon

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


From masayag at redhat.com  Wed Nov 28 08:38:28 2012
From: masayag at redhat.com (Moti Asayag)
Date: Wed, 28 Nov 2012 10:38:28 +0200
Subject: [Engine-devel] Shipping settings.xml in oVirt engine's git repo
 (was RE: maven settings.xml in building ovirt engine wiki)
In-Reply-To: <2125858346.7067971.1354089918174.JavaMail.root@redhat.com>
References: <2125858346.7067971.1354089918174.JavaMail.root@redhat.com>
Message-ID: <50B5CD84.9070903@redhat.com>

On 11/28/2012 10:05 AM, Allon Mureinik wrote:
> <snipped>
>> Note that settings.xml isn't shifted with ovirt-engine, nor stored on
>> ovirt-engine git repository. Therefore there is no real method to
>> control its content expect updating the wiki page.
> 
> Spinning off from the previous discussion - we can't really control the contents of settings.xml, but perhaps we can make them easier to get.
> 
> Today, the flow is like this:
> 1. git clone - depends on gerrit.ovirt.org
> 2. wget settings.xml - depends on wiki.ovirt.org
> 
> Suppose we ship settings.xml inside the configuration folder of ovirt (next to engine-code-format.xml and engine-commit-template.txt).
> Then you'll have to do:
> 1. git clone - depends on gerrit.ovirt.org
> 2. cp $OVIRT_GIT/config/settings.xml ~/.m2/

I don't think we should override an already existed shared configuration
file.

> 
> This may a bit simpler, and at the very least, when we update our code (e.g., to assume java7, *hint*), we can make all the changes in a single commit, and not have to update the code and then upload a file to the wiki.
> 
> Comments? Feedback?
> 
> 
> -Allon
> 



From amureini at redhat.com  Wed Nov 28 08:50:57 2012
From: amureini at redhat.com (Allon Mureinik)
Date: Wed, 28 Nov 2012 03:50:57 -0500 (EST)
Subject: [Engine-devel] Shipping settings.xml in oVirt engine's git repo
 (was RE: maven settings.xml in building ovirt engine wiki)
In-Reply-To: <1750442714.1923331.1354090442850.JavaMail.root@redhat.com>
Message-ID: <168159614.7093451.1354092657228.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Allon Mureinik" <amureini at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, November 28, 2012 10:14:02 AM
> Subject: Re: [Engine-devel] Shipping settings.xml in oVirt engine's git repo (was RE: maven settings.xml in building
> ovirt engine wiki)
> 
> 
> 
> ----- Original Message -----
> > From: "Allon Mureinik" <amureini at redhat.com>
> > To: engine-devel at ovirt.org
> > Sent: Wednesday, November 28, 2012 10:05:18 AM
> > Subject: [Engine-devel] Shipping settings.xml in oVirt engine's git
> > repo (was RE: maven settings.xml in building
> > ovirt engine wiki)
> > 
> > <snipped>
> > > Note that settings.xml isn't shifted with ovirt-engine, nor
> > > stored
> > > on
> > > ovirt-engine git repository. Therefore there is no real method to
> > > control its content expect updating the wiki page.
> > 
> > Spinning off from the previous discussion - we can't really control
> > the contents of settings.xml, but perhaps we can make them easier
> > to
> > get.
> > 
> > Today, the flow is like this:
> > 1. git clone - depends on gerrit.ovirt.org
> > 2. wget settings.xml - depends on wiki.ovirt.org
> > 
> > Suppose we ship settings.xml inside the configuration folder of
> > ovirt
> > (next to engine-code-format.xml and engine-commit-template.txt).
> > Then you'll have to do:
> > 1. git clone - depends on gerrit.ovirt.org
> > 2. cp $OVIRT_GIT/config/settings.xml ~/.m2/
> > 
> > This may a bit simpler, and at the very least, when we update our
> > code (e.g., to assume java7, *hint*), we can make all the changes
> > in
> > a single commit, and not have to update the code and then upload a
> > file to the wiki.
> > 
> > Comments? Feedback?
> 
> First thing... I don't like changing global state of a machine only
> because we require some setting...
> 
> So copying <ANYTHING> to ~/.m2 is completely wrong in my opinion.
> 
> There is -gs parameter for maven to specify alternate settings file,
> I strongly recommend people use it.
> 
> Also, as far as I understand we only need some attributes defined...
> It is simple to use:
> 
> $ export MAVEN_OPTS="-Dwhatever=value -Dwhatever=value"
> 
> Before executing eclipse or make...
> 
> We can also integrate the environment variables idea into the maven
> build, instead of using properties use environment variables... then
> before executing build we:
> 
> $ export JBOSS_HOME=
> $ export OVIRT_JDK_HOME= (optional)
> 
> If anyone prefers/chooses to use settings.xml he can create his
> own...
> 
> So there are so many options, the last option is to use settings.xml
> in my opinion... not that I against adding this template, but I
> first suggest we consider removing its usage completely.... :)
> 
> Regards,
> Alon
> 
> > 
> > 
> > -Allon

I'll rephrase.
/today/ we provide an example of settings.xml in "Building the oVirt Engine" wiki page.
People who understand maven will not overwrite their settings.xml with it, and people who don't have a comfortable quick start.

I propose to supply this /exmaple/ in a more accessible place $OVIRT_GIT/config.
People who didn't overwrite their existing .m2 file still won't, and people who did have an easier way of doing it.


From iheim at redhat.com  Wed Nov 28 08:55:47 2012
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 28 Nov 2012 03:55:47 -0500
Subject: [Engine-devel] Shipping settings.xml in oVirt engine's git repo
 (was RE: maven settings.xml in building ovirt engine wiki)
In-Reply-To: <168159614.7093451.1354092657228.JavaMail.root@redhat.com>
References: <168159614.7093451.1354092657228.JavaMail.root@redhat.com>
Message-ID: <50B5D193.2070003@redhat.com>

On 11/28/2012 03:50 AM, Allon Mureinik wrote:
>
>
> ----- Original Message -----
>> From: "Alon Bar-Lev" <alonbl at redhat.com>
>> To: "Allon Mureinik" <amureini at redhat.com>
>> Cc: engine-devel at ovirt.org
>> Sent: Wednesday, November 28, 2012 10:14:02 AM
>> Subject: Re: [Engine-devel] Shipping settings.xml in oVirt engine's git repo (was RE: maven settings.xml in building
>> ovirt engine wiki)
>>
>>
>>
>> ----- Original Message -----
>>> From: "Allon Mureinik" <amureini at redhat.com>
>>> To: engine-devel at ovirt.org
>>> Sent: Wednesday, November 28, 2012 10:05:18 AM
>>> Subject: [Engine-devel] Shipping settings.xml in oVirt engine's git
>>> repo (was RE: maven settings.xml in building
>>> ovirt engine wiki)
>>>
>>> <snipped>
>>>> Note that settings.xml isn't shifted with ovirt-engine, nor
>>>> stored
>>>> on
>>>> ovirt-engine git repository. Therefore there is no real method to
>>>> control its content expect updating the wiki page.
>>>
>>> Spinning off from the previous discussion - we can't really control
>>> the contents of settings.xml, but perhaps we can make them easier
>>> to
>>> get.
>>>
>>> Today, the flow is like this:
>>> 1. git clone - depends on gerrit.ovirt.org
>>> 2. wget settings.xml - depends on wiki.ovirt.org
>>>
>>> Suppose we ship settings.xml inside the configuration folder of
>>> ovirt
>>> (next to engine-code-format.xml and engine-commit-template.txt).
>>> Then you'll have to do:
>>> 1. git clone - depends on gerrit.ovirt.org
>>> 2. cp $OVIRT_GIT/config/settings.xml ~/.m2/
>>>
>>> This may a bit simpler, and at the very least, when we update our
>>> code (e.g., to assume java7, *hint*), we can make all the changes
>>> in
>>> a single commit, and not have to update the code and then upload a
>>> file to the wiki.
>>>
>>> Comments? Feedback?
>>
>> First thing... I don't like changing global state of a machine only
>> because we require some setting...
>>
>> So copying <ANYTHING> to ~/.m2 is completely wrong in my opinion.
>>
>> There is -gs parameter for maven to specify alternate settings file,
>> I strongly recommend people use it.
>>
>> Also, as far as I understand we only need some attributes defined...
>> It is simple to use:
>>
>> $ export MAVEN_OPTS="-Dwhatever=value -Dwhatever=value"
>>
>> Before executing eclipse or make...
>>
>> We can also integrate the environment variables idea into the maven
>> build, instead of using properties use environment variables... then
>> before executing build we:
>>
>> $ export JBOSS_HOME=
>> $ export OVIRT_JDK_HOME= (optional)
>>
>> If anyone prefers/chooses to use settings.xml he can create his
>> own...
>>
>> So there are so many options, the last option is to use settings.xml
>> in my opinion... not that I against adding this template, but I
>> first suggest we consider removing its usage completely.... :)
>>
>> Regards,
>> Alon
>>
>>>
>>>
>>> -Allon
>
> I'll rephrase.
> /today/ we provide an example of settings.xml in "Building the oVirt Engine" wiki page.
> People who understand maven will not overwrite their settings.xml with it, and people who don't have a comfortable quick start.
>
> I propose to supply this /exmaple/ in a more accessible place $OVIRT_GIT/config.
> People who didn't overwrite their existing .m2 file still won't, and people who did have an easier way of doing it.

i agree having the sample in the git will make it simpler, and we must 
make it simpler (juan is working on cleaning up the 'setup devel' flow).

for simplicity, please lets also assume the would be developer also 
isn't intimate with eclipse/jboss, so default in the file should work 
with someone doing:
yum install eclipse jbossas

Thanks,
    Itamar


From iheim at redhat.com  Wed Nov 28 08:56:30 2012
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 28 Nov 2012 03:56:30 -0500
Subject: [Engine-devel] Shipping settings.xml in oVirt engine's git repo
 (was RE: maven settings.xml in building ovirt engine wiki)
In-Reply-To: <50B5CD84.9070903@redhat.com>
References: <2125858346.7067971.1354089918174.JavaMail.root@redhat.com>
	<50B5CD84.9070903@redhat.com>
Message-ID: <50B5D1BE.9090202@redhat.com>

On 11/28/2012 03:38 AM, Moti Asayag wrote:
> On 11/28/2012 10:05 AM, Allon Mureinik wrote:
>> <snipped>
>>> Note that settings.xml isn't shifted with ovirt-engine, nor stored on
>>> ovirt-engine git repository. Therefore there is no real method to
>>> control its content expect updating the wiki page.
>>
>> Spinning off from the previous discussion - we can't really control the contents of settings.xml, but perhaps we can make them easier to get.
>>
>> Today, the flow is like this:
>> 1. git clone - depends on gerrit.ovirt.org
>> 2. wget settings.xml - depends on wiki.ovirt.org
>>
>> Suppose we ship settings.xml inside the configuration folder of ovirt (next to engine-code-format.xml and engine-commit-template.txt).
>> Then you'll have to do:
>> 1. git clone - depends on gerrit.ovirt.org
>> 2. cp $OVIRT_GIT/config/settings.xml ~/.m2/
>
> I don't think we should override an already existed shared configuration
> file.

user doesn't have to do this, and we can also suggest they run mvn with 
this file as an mvn option instead of copying it to default location.


From jhernand at redhat.com  Wed Nov 28 09:54:02 2012
From: jhernand at redhat.com (Juan Hernandez)
Date: Wed, 28 Nov 2012 10:54:02 +0100
Subject: [Engine-devel] Shipping settings.xml in oVirt engine's git repo
 (was RE: maven settings.xml in building ovirt engine wiki)
In-Reply-To: <50B5D193.2070003@redhat.com>
References: <168159614.7093451.1354092657228.JavaMail.root@redhat.com>
	<50B5D193.2070003@redhat.com>
Message-ID: <50B5DF3A.8070103@redhat.com>

On 11/28/2012 09:55 AM, Itamar Heim wrote:
> On 11/28/2012 03:50 AM, Allon Mureinik wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
>>> To: "Allon Mureinik" <amureini at redhat.com>
>>> Cc: engine-devel at ovirt.org
>>> Sent: Wednesday, November 28, 2012 10:14:02 AM
>>> Subject: Re: [Engine-devel] Shipping settings.xml in oVirt engine's git repo (was RE: maven settings.xml in building
>>> ovirt engine wiki)
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Allon Mureinik" <amureini at redhat.com>
>>>> To: engine-devel at ovirt.org
>>>> Sent: Wednesday, November 28, 2012 10:05:18 AM
>>>> Subject: [Engine-devel] Shipping settings.xml in oVirt engine's git
>>>> repo (was RE: maven settings.xml in building
>>>> ovirt engine wiki)
>>>>
>>>> <snipped>
>>>>> Note that settings.xml isn't shifted with ovirt-engine, nor
>>>>> stored
>>>>> on
>>>>> ovirt-engine git repository. Therefore there is no real method to
>>>>> control its content expect updating the wiki page.
>>>>
>>>> Spinning off from the previous discussion - we can't really control
>>>> the contents of settings.xml, but perhaps we can make them easier
>>>> to
>>>> get.
>>>>
>>>> Today, the flow is like this:
>>>> 1. git clone - depends on gerrit.ovirt.org
>>>> 2. wget settings.xml - depends on wiki.ovirt.org
>>>>
>>>> Suppose we ship settings.xml inside the configuration folder of
>>>> ovirt
>>>> (next to engine-code-format.xml and engine-commit-template.txt).
>>>> Then you'll have to do:
>>>> 1. git clone - depends on gerrit.ovirt.org
>>>> 2. cp $OVIRT_GIT/config/settings.xml ~/.m2/
>>>>
>>>> This may a bit simpler, and at the very least, when we update our
>>>> code (e.g., to assume java7, *hint*), we can make all the changes
>>>> in
>>>> a single commit, and not have to update the code and then upload a
>>>> file to the wiki.
>>>>
>>>> Comments? Feedback?
>>>
>>> First thing... I don't like changing global state of a machine only
>>> because we require some setting...
>>>
>>> So copying <ANYTHING> to ~/.m2 is completely wrong in my opinion.
>>>
>>> There is -gs parameter for maven to specify alternate settings file,
>>> I strongly recommend people use it.
>>>
>>> Also, as far as I understand we only need some attributes defined...
>>> It is simple to use:
>>>
>>> $ export MAVEN_OPTS="-Dwhatever=value -Dwhatever=value"
>>>
>>> Before executing eclipse or make...
>>>
>>> We can also integrate the environment variables idea into the maven
>>> build, instead of using properties use environment variables... then
>>> before executing build we:
>>>
>>> $ export JBOSS_HOME=
>>> $ export OVIRT_JDK_HOME= (optional)
>>>
>>> If anyone prefers/chooses to use settings.xml he can create his
>>> own...
>>>
>>> So there are so many options, the last option is to use settings.xml
>>> in my opinion... not that I against adding this template, but I
>>> first suggest we consider removing its usage completely.... :)
>>>
>>> Regards,
>>> Alon
>>>
>>>>
>>>>
>>>> -Allon
>>
>> I'll rephrase.
>> /today/ we provide an example of settings.xml in "Building the oVirt Engine" wiki page.
>> People who understand maven will not overwrite their settings.xml with it, and people who don't have a comfortable quick start.
>>
>> I propose to supply this /exmaple/ in a more accessible place $OVIRT_GIT/config.
>> People who didn't overwrite their existing .m2 file still won't, and people who did have an easier way of doing it.
> 
> i agree having the sample in the git will make it simpler, and we must 
> make it simpler (juan is working on cleaning up the 'setup devel' flow).

I am not against having that example in the git repository. But I don't
see how that is going to make life easier for newcomers. We will have to
instruct them (in the wiki) how to find the file instead of instructing
them how to create it, not much difference.

> 
> for simplicity, please lets also assume the would be developer also 
> isn't intimate with eclipse/jboss, so default in the file should work 
> with someone doing:
> yum install eclipse jbossas
> 

Unfortunately using "yum install jbossas" is not an option currently, as
that requires the developer to use root, which causes a lot of trouble.
We have to instruct new developers to download the JBoss .zip file and
uncompress it somewhere, easiest is the developer's home directory. This
has the advantage that it also works in distributions that haven't
packaged JBoss yet.

Using "yum install eclipse" also has its drawbacks, as the version of
eclipse in Fedora doesn't include the maven plugin.

-- 
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 iheim at redhat.com  Wed Nov 28 11:57:48 2012
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 28 Nov 2012 06:57:48 -0500
Subject: [Engine-devel] Shipping settings.xml in oVirt engine's git repo
 (was RE: maven settings.xml in building ovirt engine wiki)
In-Reply-To: <50B5DF3A.8070103@redhat.com>
References: <168159614.7093451.1354092657228.JavaMail.root@redhat.com>
	<50B5D193.2070003@redhat.com> <50B5DF3A.8070103@redhat.com>
Message-ID: <50B5FC3C.6010302@redhat.com>

On 11/28/2012 04:54 AM, Juan Hernandez wrote:
> On 11/28/2012 09:55 AM, Itamar Heim wrote:
>> On 11/28/2012 03:50 AM, Allon Mureinik wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
>>>> To: "Allon Mureinik" <amureini at redhat.com>
>>>> Cc: engine-devel at ovirt.org
>>>> Sent: Wednesday, November 28, 2012 10:14:02 AM
>>>> Subject: Re: [Engine-devel] Shipping settings.xml in oVirt engine's git repo (was RE: maven settings.xml in building
>>>> ovirt engine wiki)
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Allon Mureinik" <amureini at redhat.com>
>>>>> To: engine-devel at ovirt.org
>>>>> Sent: Wednesday, November 28, 2012 10:05:18 AM
>>>>> Subject: [Engine-devel] Shipping settings.xml in oVirt engine's git
>>>>> repo (was RE: maven settings.xml in building
>>>>> ovirt engine wiki)
>>>>>
>>>>> <snipped>
>>>>>> Note that settings.xml isn't shifted with ovirt-engine, nor
>>>>>> stored
>>>>>> on
>>>>>> ovirt-engine git repository. Therefore there is no real method to
>>>>>> control its content expect updating the wiki page.
>>>>>
>>>>> Spinning off from the previous discussion - we can't really control
>>>>> the contents of settings.xml, but perhaps we can make them easier
>>>>> to
>>>>> get.
>>>>>
>>>>> Today, the flow is like this:
>>>>> 1. git clone - depends on gerrit.ovirt.org
>>>>> 2. wget settings.xml - depends on wiki.ovirt.org
>>>>>
>>>>> Suppose we ship settings.xml inside the configuration folder of
>>>>> ovirt
>>>>> (next to engine-code-format.xml and engine-commit-template.txt).
>>>>> Then you'll have to do:
>>>>> 1. git clone - depends on gerrit.ovirt.org
>>>>> 2. cp $OVIRT_GIT/config/settings.xml ~/.m2/
>>>>>
>>>>> This may a bit simpler, and at the very least, when we update our
>>>>> code (e.g., to assume java7, *hint*), we can make all the changes
>>>>> in
>>>>> a single commit, and not have to update the code and then upload a
>>>>> file to the wiki.
>>>>>
>>>>> Comments? Feedback?
>>>>
>>>> First thing... I don't like changing global state of a machine only
>>>> because we require some setting...
>>>>
>>>> So copying <ANYTHING> to ~/.m2 is completely wrong in my opinion.
>>>>
>>>> There is -gs parameter for maven to specify alternate settings file,
>>>> I strongly recommend people use it.
>>>>
>>>> Also, as far as I understand we only need some attributes defined...
>>>> It is simple to use:
>>>>
>>>> $ export MAVEN_OPTS="-Dwhatever=value -Dwhatever=value"
>>>>
>>>> Before executing eclipse or make...
>>>>
>>>> We can also integrate the environment variables idea into the maven
>>>> build, instead of using properties use environment variables... then
>>>> before executing build we:
>>>>
>>>> $ export JBOSS_HOME=
>>>> $ export OVIRT_JDK_HOME= (optional)
>>>>
>>>> If anyone prefers/chooses to use settings.xml he can create his
>>>> own...
>>>>
>>>> So there are so many options, the last option is to use settings.xml
>>>> in my opinion... not that I against adding this template, but I
>>>> first suggest we consider removing its usage completely.... :)
>>>>
>>>> Regards,
>>>> Alon
>>>>
>>>>>
>>>>>
>>>>> -Allon
>>>
>>> I'll rephrase.
>>> /today/ we provide an example of settings.xml in "Building the oVirt Engine" wiki page.
>>> People who understand maven will not overwrite their settings.xml with it, and people who don't have a comfortable quick start.
>>>
>>> I propose to supply this /exmaple/ in a more accessible place $OVIRT_GIT/config.
>>> People who didn't overwrite their existing .m2 file still won't, and people who did have an easier way of doing it.
>>
>> i agree having the sample in the git will make it simpler, and we must
>> make it simpler (juan is working on cleaning up the 'setup devel' flow).
>
> I am not against having that example in the git repository. But I don't
> see how that is going to make life easier for newcomers. We will have to
> instruct them (in the wiki) how to find the file instead of instructing
> them how to create it, not much difference.

if we tell them to:
yum install X Y Z
git clone ...
cd ovirt-engine
mvn clean install --settings settings.xml

it should just work, unless i am missing something?

>
>>
>> for simplicity, please lets also assume the would be developer also
>> isn't intimate with eclipse/jboss, so default in the file should work
>> with someone doing:
>> yum install eclipse jbossas
>>
>
> Unfortunately using "yum install jbossas" is not an option currently, as
> that requires the developer to use root, which causes a lot of trouble.

any way to solve this?

> We have to instruct new developers to download the JBoss .zip file and
> uncompress it somewhere, easiest is the developer's home directory. This
> has the advantage that it also works in distributions that haven't
> packaged JBoss yet.
>
> Using "yum install eclipse" also has its drawbacks, as the version of
> eclipse in Fedora doesn't include the maven plugin.
>

isn't the maven plugin just another rpm?


From jhernand at redhat.com  Wed Nov 28 12:32:56 2012
From: jhernand at redhat.com (Juan Hernandez)
Date: Wed, 28 Nov 2012 13:32:56 +0100
Subject: [Engine-devel] Shipping settings.xml in oVirt engine's git repo
 (was RE: maven settings.xml in building ovirt engine wiki)
In-Reply-To: <50B5FC3C.6010302@redhat.com>
References: <168159614.7093451.1354092657228.JavaMail.root@redhat.com>
	<50B5D193.2070003@redhat.com> <50B5DF3A.8070103@redhat.com>
	<50B5FC3C.6010302@redhat.com>
Message-ID: <50B60478.4000707@redhat.com>

On 11/28/2012 12:57 PM, Itamar Heim wrote:
> On 11/28/2012 04:54 AM, Juan Hernandez wrote:
>> On 11/28/2012 09:55 AM, Itamar Heim wrote:
>>> On 11/28/2012 03:50 AM, Allon Mureinik wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
>>>>> To: "Allon Mureinik" <amureini at redhat.com>
>>>>> Cc: engine-devel at ovirt.org
>>>>> Sent: Wednesday, November 28, 2012 10:14:02 AM
>>>>> Subject: Re: [Engine-devel] Shipping settings.xml in oVirt engine's git repo (was RE: maven settings.xml in building
>>>>> ovirt engine wiki)
>>>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Allon Mureinik" <amureini at redhat.com>
>>>>>> To: engine-devel at ovirt.org
>>>>>> Sent: Wednesday, November 28, 2012 10:05:18 AM
>>>>>> Subject: [Engine-devel] Shipping settings.xml in oVirt engine's git
>>>>>> repo (was RE: maven settings.xml in building
>>>>>> ovirt engine wiki)
>>>>>>
>>>>>> <snipped>
>>>>>>> Note that settings.xml isn't shifted with ovirt-engine, nor
>>>>>>> stored
>>>>>>> on
>>>>>>> ovirt-engine git repository. Therefore there is no real method to
>>>>>>> control its content expect updating the wiki page.
>>>>>>
>>>>>> Spinning off from the previous discussion - we can't really control
>>>>>> the contents of settings.xml, but perhaps we can make them easier
>>>>>> to
>>>>>> get.
>>>>>>
>>>>>> Today, the flow is like this:
>>>>>> 1. git clone - depends on gerrit.ovirt.org
>>>>>> 2. wget settings.xml - depends on wiki.ovirt.org
>>>>>>
>>>>>> Suppose we ship settings.xml inside the configuration folder of
>>>>>> ovirt
>>>>>> (next to engine-code-format.xml and engine-commit-template.txt).
>>>>>> Then you'll have to do:
>>>>>> 1. git clone - depends on gerrit.ovirt.org
>>>>>> 2. cp $OVIRT_GIT/config/settings.xml ~/.m2/
>>>>>>
>>>>>> This may a bit simpler, and at the very least, when we update our
>>>>>> code (e.g., to assume java7, *hint*), we can make all the changes
>>>>>> in
>>>>>> a single commit, and not have to update the code and then upload a
>>>>>> file to the wiki.
>>>>>>
>>>>>> Comments? Feedback?
>>>>>
>>>>> First thing... I don't like changing global state of a machine only
>>>>> because we require some setting...
>>>>>
>>>>> So copying <ANYTHING> to ~/.m2 is completely wrong in my opinion.
>>>>>
>>>>> There is -gs parameter for maven to specify alternate settings file,
>>>>> I strongly recommend people use it.
>>>>>
>>>>> Also, as far as I understand we only need some attributes defined...
>>>>> It is simple to use:
>>>>>
>>>>> $ export MAVEN_OPTS="-Dwhatever=value -Dwhatever=value"
>>>>>
>>>>> Before executing eclipse or make...
>>>>>
>>>>> We can also integrate the environment variables idea into the maven
>>>>> build, instead of using properties use environment variables... then
>>>>> before executing build we:
>>>>>
>>>>> $ export JBOSS_HOME=
>>>>> $ export OVIRT_JDK_HOME= (optional)
>>>>>
>>>>> If anyone prefers/chooses to use settings.xml he can create his
>>>>> own...
>>>>>
>>>>> So there are so many options, the last option is to use settings.xml
>>>>> in my opinion... not that I against adding this template, but I
>>>>> first suggest we consider removing its usage completely.... :)
>>>>>
>>>>> Regards,
>>>>> Alon
>>>>>
>>>>>>
>>>>>>
>>>>>> -Allon
>>>>
>>>> I'll rephrase.
>>>> /today/ we provide an example of settings.xml in "Building the oVirt Engine" wiki page.
>>>> People who understand maven will not overwrite their settings.xml with it, and people who don't have a comfortable quick start.
>>>>
>>>> I propose to supply this /exmaple/ in a more accessible place $OVIRT_GIT/config.
>>>> People who didn't overwrite their existing .m2 file still won't, and people who did have an easier way of doing it.
>>>
>>> i agree having the sample in the git will make it simpler, and we must
>>> make it simpler (juan is working on cleaning up the 'setup devel' flow).
>>
>> I am not against having that example in the git repository. But I don't
>> see how that is going to make life easier for newcomers. We will have to
>> instruct them (in the wiki) how to find the file instead of instructing
>> them how to create it, not much difference.
> 
> if we tell them to:
> yum install X Y Z
> git clone ...
> cd ovirt-engine
> mvn clean install --settings settings.xml
> 
> it should just work, unless i am missing something?

Yes, should work, but then we need to include this "--settings
$HOME/ovirt-engine/settings.xml" in all the example commands in the
wiki. It doesn't make things simpler.

> 
>>
>>>
>>> for simplicity, please lets also assume the would be developer also
>>> isn't intimate with eclipse/jboss, so default in the file should work
>>> with someone doing:
>>> yum install eclipse jbossas
>>>
>>
>> Unfortunately using "yum install jbossas" is not an option currently, as
>> that requires the developer to use root, which causes a lot of trouble.
> 
> any way to solve this?

The easy solution is to use the .zip distribution, which works in any
distribution.

For the future, in my opinion, we should move towards a model where the
development environment is much more similar to the production
environment than what we have now. The build system should be able to
install the complete engine to a directory under the developer home
directory, with the same file system structure that we use in production
environments. Then the developer should be able to start/stop the engine
(and tools) using the same scripts that we use in production
environments. These scripts don't need write access to the jboss-as
installation directories, so as a side effect they solve this problem.

> 
>> We have to instruct new developers to download the JBoss .zip file and
>> uncompress it somewhere, easiest is the developer's home directory. This
>> has the advantage that it also works in distributions that haven't
>> packaged JBoss yet.
>>
>> Using "yum install eclipse" also has its drawbacks, as the version of
>> eclipse in Fedora doesn't include the maven plugin.
>>
> 
> isn't the maven plugin just another rpm?
> 

No, the maven plugin is not yet packaged for fedora:

https://bugzilla.redhat.com/814245

It can be installed manually as described in the wiki, and then it
should work (it doesn't in Fedora 18 as far as I can tell).

I would rather suggest using a lighter alternative, like including
working .project and .classpath files in the repository (I can foresee a
lot of people cursing me for proposing this) or generating them using
the maven eclipse plugin (see [1], don't confuse it with m2e [2]).

[1] http://maven.apache.org/plugins/maven-eclipse-plugin
[2] http://eclipse.org/m2e

-- 
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  Wed Nov 28 13:59:10 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Wed, 28 Nov 2012 08:59:10 -0500 (EST)
Subject: [Engine-devel] [ATTENTION] vdsm-bootstrap/host deployment (pre-3.2)
In-Reply-To: <1545092194.1964552.1354107476575.JavaMail.root@redhat.com>
Message-ID: <1188249362.1975762.1354111150201.JavaMail.root@redhat.com>

Hello All,

Preparing to ovirt-engine 3.2 the entire "vdsm-bootstrap" bootstrap was re-written from scratch into more pluggable and flexible implementation, available at git master and nightly snapshots.

As far as packaging is concerned there are now two more dependencies to ovirt-engine:

 * otopi -- oVirt Task Oriented Pluggable Installer/Implementation
 * ovirt-host-deploy -- oVirt host deploy tool

These packages replace the legacy vdsm-bootstrap package that was distributed with vdsm.

Git repositories are available at at[1][2].
Documentation is available at Git repositories - README*.
Builds are available at usual place[3].
Bugzilla components will be available shortly.
Change log is attached.

There is no change in the way the engine is performing the host deployment process in term of user experience, other than event log messages during deployment were improved.

The log of the deployment is fetched from host and stored at engine machine at /var/log/ovirt-engine/host-deploy, on host it is at /tmp/ovirt-host-deploy*.log and deleted when fetched to engine.

Among other features, the ovir-host-deploy package can be installed manually on host and executed to prepare host for installation, in future we may be able to add host to engine without performing the deployment process, for now it will be usable for integration tests.

The internals are completely different, instead of having 3 different bootstrap sequences:
 1. host install
 2. ovirt-node install
 3. ovirt-node approve

We now have single sequence which is common to host and node installation or re-installation, end result is much simpler implementation.

Please report any issues even minor issues, so we can stabilize it for 3.2 release.

Best Regards,
Alon Bar-Lev.

[1] http://gerrit.ovirt.org/gitweb?p=otopi.git;a=tree
[2] http://gerrit.ovirt.org/gitweb?p=ovirt-host-deploy.git;a=tree
[3] http://www.ovirt.org/releases/nightly/rpm/Fedora/17/noarch/

---

Change Log

 * offline packager feature.

 * tuned is installed with virtual-host profile.

 * initial implementation based on otpoi.

 * implementation is based on legacy vdsm-bootstrap pacakge functionality.

 * legacy-removed: legacy VDSM (<3.0) config upgrade.

 * legacy-removed: change machine width core file
  # echo /var/lib/vdsm/core > /proc/sys/kernel/core_pattern

 * legacy-removed: kernel version test, package dependency is sufficient.

 * legacy-removed: do not add kernel parameter processor.max_cstate=1
   warn if not have constant_tsc
   https://bugzilla.redhat.com/show_bug.cgi?id=770153

 * legacy-change: io elevator scheduler set in kernel command-line
   use either udev rule in vdsm package or tuned.

 * legacy-change: vdsm libvirt reconfigure
   vdsm is reconfigured with file based trigger instead unsupported systemd
   init.d parameter.

 * legacy-change: distribution checks are simpler based on Python platform,
   minimum:
   - rhel-6.2
   - fedora-17

 * legacy-change: minimum vdsm version is taken from engine not hard coded.

 * legacy-change: pki is now using m2crypto to generate certificate request
   and parse certificates.

 * legacy-change: use iproute2 instead of python ethtool to avoid another
   dependency for host name validation.

 * legacy-change: use iproute2 instead of reading /proc/net/route for route
   information and interface information.

 * legacy-change: do not use vdsm.netinfo for vlan and bonding as it requires
   /usr/share/vdsm modules, and it is trivial anyway.

 * legacy-change: use vdsm-store-net-config script to commit network config
   instead of internal duplicate implementation.

 * legacy-change: /etc/vdsm/vdsm.conf is overridden unless VDSM/configOverride
   environment is set to True

 * legacy-change: /etc/vdsm/vdsm.conf is not read of fake_qemu.
   set VDSM/checkVirtHardware environment to False to avoid hardware detection.

 * legacy-change: following gluster packages not installed:
   - glusterfs-rdma
   - glusterfs-geo-replication


From danken at redhat.com  Wed Nov 28 14:41:04 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Wed, 28 Nov 2012 16:41:04 +0200
Subject: [Engine-devel] [vdsm] [ATTENTION] vdsm-bootstrap/host
	deployment (pre-3.2)
In-Reply-To: <1188249362.1975762.1354111150201.JavaMail.root@redhat.com>
References: <1545092194.1964552.1354107476575.JavaMail.root@redhat.com>
	<1188249362.1975762.1354111150201.JavaMail.root@redhat.com>
Message-ID: <20121128144104.GV5083@redhat.com>

On Wed, Nov 28, 2012 at 08:59:10AM -0500, Alon Bar-Lev wrote:
> Hello All,
> 
> Preparing to ovirt-engine 3.2 the entire "vdsm-bootstrap" bootstrap
> was re-written from scratch into more pluggable and flexible
> implementation, available at git master and nightly snapshots.
> 
> As far as packaging is concerned there are now two more dependencies to ovirt-engine:
> 
>  * otopi -- oVirt Task Oriented Pluggable Installer/Implementation
>  * ovirt-host-deploy -- oVirt host deploy tool
> 
> These packages replace the legacy vdsm-bootstrap package that was
> distributed with vdsm.

Hurray!

I suspect that a `git-rm vds_bootstrap/*` is pending?

> 
> Git repositories are available at at[1][2].
> Documentation is available at Git repositories - README*.
> Builds are available at usual place[3].
> Bugzilla components will be available shortly.

Are there requests to add the components to Fedora (18, EPEL6)?
I think we should add these requests as blockers for Bug 881006 -
Tracker: oVirt 3.2 release.

> Change log is attached.
> 
> There is no change in the way the engine is performing the host
> deployment process in term of user experience, other than event log
> messages during deployment were improved.
> 
> The log of the deployment is fetched from host and stored at engine
> machine at /var/log/ovirt-engine/host-deploy, on host it is at
> /tmp/ovirt-host-deploy*.log and deleted when fetched to engine.
> 
> Among other features, the ovir-host-deploy package can be installed
> manually on host and executed to prepare host for installation, in
> future we may be able to add host to engine without performing the
> deployment process, for now it will be usable for integration tests.
> 
> The internals are completely different, instead of having 3 different
> bootstrap sequences:
>  1. host install
>  2. ovirt-node install
>  3. ovirt-node approve
> 
> We now have single sequence which is common to host and node
> installation or re-installation, end result is much simpler
> implementation.
> 
> Please report any issues even minor issues, so we can stabilize it for
> 3.2 release.
> 
> Best Regards,
> Alon Bar-Lev.
> 
> [1] http://gerrit.ovirt.org/gitweb?p=otopi.git;a=tree
> [2] http://gerrit.ovirt.org/gitweb?p=ovirt-host-deploy.git;a=tree
> [3] http://www.ovirt.org/releases/nightly/rpm/Fedora/17/noarch/
> 
> ---
> 
> Change Log
> 
>  * offline packager feature.
> 
>  * tuned is installed with virtual-host profile.

I never understood why this is an installer step, and not part of vdsmd
start up

>  * initial implementation based on otpoi.
> 
>  * implementation is based on legacy vdsm-bootstrap pacakge functionality.
> 
>  * legacy-removed: legacy VDSM (<3.0) config upgrade.
> 
>  * legacy-removed: change machine width core file
>   # echo /var/lib/vdsm/core > /proc/sys/kernel/core_pattern

Yeah, qemu-kvm and libvirtd are much more stable than in the old days,
but wouldn't we want to keep a means to collect the corpses of dead
processes from hypervisors? It has helped us nail down nasty bugs, even
in Python.

> 
>  * legacy-removed: kernel version test, package dependency is sufficient.
> 
>  * legacy-removed: do not add kernel parameter processor.max_cstate=1
>    warn if not have constant_tsc
>    https://bugzilla.redhat.com/show_bug.cgi?id=770153
> 
>  * legacy-change: io elevator scheduler set in kernel command-line
>    use either udev rule in vdsm package or tuned.
> 
>  * legacy-change: vdsm libvirt reconfigure
>    vdsm is reconfigured with file based trigger instead unsupported systemd
>    init.d parameter.
> 
>  * legacy-change: distribution checks are simpler based on Python platform,
>    minimum:
>    - rhel-6.2
>    - fedora-17
> 
>  * legacy-change: minimum vdsm version is taken from engine not hard coded.
> 
>  * legacy-change: pki is now using m2crypto to generate certificate request
>    and parse certificates.
> 
>  * legacy-change: use iproute2 instead of python ethtool to avoid another
>    dependency for host name validation.
> 
>  * legacy-change: use iproute2 instead of reading /proc/net/route for route
>    information and interface information.
> 
>  * legacy-change: do not use vdsm.netinfo for vlan and bonding as it requires
>    /usr/share/vdsm modules, and it is trivial anyway.
> 
>  * legacy-change: use vdsm-store-net-config script to commit network config
>    instead of internal duplicate implementation.
> 
>  * legacy-change: /etc/vdsm/vdsm.conf is overridden unless VDSM/configOverride
>    environment is set to True

I'm a bit confused by the negation: I'd expect VDSM/configOverride=True
to mean "override /etc/vdsm/vdsm.conf".

> 
>  * legacy-change: /etc/vdsm/vdsm.conf is not read of fake_qemu.
>    set VDSM/checkVirtHardware environment to False to avoid hardware detection.
> 
>  * legacy-change: following gluster packages not installed:
>    - glusterfs-rdma
>    - glusterfs-geo-replication


Alon, thanks for your tremendous work on this. I cannot wait to have it
up and running in the release.

Dan.


From alonbl at redhat.com  Wed Nov 28 14:45:17 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Wed, 28 Nov 2012 09:45:17 -0500 (EST)
Subject: [Engine-devel] [vdsm] [ATTENTION] vdsm-bootstrap/host
	deployment (pre-3.2)
In-Reply-To: <20121128144104.GV5083@redhat.com>
Message-ID: <469209898.1995297.1354113917831.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "VDSM Project Development" <vdsm-devel at lists.fedorahosted.org>, "engine-devel" <engine-devel at ovirt.org>, "users"
> <users at ovirt.org>
> Sent: Wednesday, November 28, 2012 4:41:04 PM
> Subject: Re: [vdsm] [ATTENTION] vdsm-bootstrap/host deployment (pre-3.2)
> 
> On Wed, Nov 28, 2012 at 08:59:10AM -0500, Alon Bar-Lev wrote:
> > Hello All,
> > 
> > Preparing to ovirt-engine 3.2 the entire "vdsm-bootstrap" bootstrap
> > was re-written from scratch into more pluggable and flexible
> > implementation, available at git master and nightly snapshots.
> > 
> > As far as packaging is concerned there are now two more
> > dependencies to ovirt-engine:
> > 
> >  * otopi -- oVirt Task Oriented Pluggable Installer/Implementation
> >  * ovirt-host-deploy -- oVirt host deploy tool
> > 
> > These packages replace the legacy vdsm-bootstrap package that was
> > distributed with vdsm.
> 
> Hurray!
> 
> I suspect that a `git-rm vds_bootstrap/*` is pending?

No... we need it as compatibility with older engines...
We keep minimum changes there for legacy, until end-of-life.

> 
> > 
> > Git repositories are available at at[1][2].
> > Documentation is available at Git repositories - README*.
> > Builds are available at usual place[3].
> > Bugzilla components will be available shortly.
> 
> Are there requests to add the components to Fedora (18, EPEL6)?
> I think we should add these requests as blockers for Bug 881006 -
> Tracker: oVirt 3.2 release.

Yes, I am on this one.

> 
> > Change log is attached.
> > 
> > There is no change in the way the engine is performing the host
> > deployment process in term of user experience, other than event log
> > messages during deployment were improved.
> > 
> > The log of the deployment is fetched from host and stored at engine
> > machine at /var/log/ovirt-engine/host-deploy, on host it is at
> > /tmp/ovirt-host-deploy*.log and deleted when fetched to engine.
> > 
> > Among other features, the ovir-host-deploy package can be installed
> > manually on host and executed to prepare host for installation, in
> > future we may be able to add host to engine without performing the
> > deployment process, for now it will be usable for integration
> > tests.
> > 
> > The internals are completely different, instead of having 3
> > different
> > bootstrap sequences:
> >  1. host install
> >  2. ovirt-node install
> >  3. ovirt-node approve
> > 
> > We now have single sequence which is common to host and node
> > installation or re-installation, end result is much simpler
> > implementation.
> > 
> > Please report any issues even minor issues, so we can stabilize it
> > for
> > 3.2 release.
> > 
> > Best Regards,
> > Alon Bar-Lev.
> > 
> > [1] http://gerrit.ovirt.org/gitweb?p=otopi.git;a=tree
> > [2] http://gerrit.ovirt.org/gitweb?p=ovirt-host-deploy.git;a=tree
> > [3] http://www.ovirt.org/releases/nightly/rpm/Fedora/17/noarch/
> > 
> > ---
> > 
> > Change Log
> > 
> >  * offline packager feature.
> > 
> >  * tuned is installed with virtual-host profile.
> 
> I never understood why this is an installer step, and not part of
> vdsmd
> start up

There may be several method to tune a machine.
Why VDSM should depend on specific one?

> 
> >  * initial implementation based on otpoi.
> > 
> >  * implementation is based on legacy vdsm-bootstrap pacakge
> >  functionality.
> > 
> >  * legacy-removed: legacy VDSM (<3.0) config upgrade.
> > 
> >  * legacy-removed: change machine width core file
> >   # echo /var/lib/vdsm/core > /proc/sys/kernel/core_pattern
> 
> Yeah, qemu-kvm and libvirtd are much more stable than in the old
> days,
> but wouldn't we want to keep a means to collect the corpses of dead
> processes from hypervisors? It has helped us nail down nasty bugs,
> even
> in Python.

It does not mean it should be at /var/lib/vdsm ... :)

> 
> > 
> >  * legacy-removed: kernel version test, package dependency is
> >  sufficient.
> > 
> >  * legacy-removed: do not add kernel parameter
> >  processor.max_cstate=1
> >    warn if not have constant_tsc
> >    https://bugzilla.redhat.com/show_bug.cgi?id=770153
> > 
> >  * legacy-change: io elevator scheduler set in kernel command-line
> >    use either udev rule in vdsm package or tuned.
> > 
> >  * legacy-change: vdsm libvirt reconfigure
> >    vdsm is reconfigured with file based trigger instead unsupported
> >    systemd
> >    init.d parameter.
> > 
> >  * legacy-change: distribution checks are simpler based on Python
> >  platform,
> >    minimum:
> >    - rhel-6.2
> >    - fedora-17
> > 
> >  * legacy-change: minimum vdsm version is taken from engine not
> >  hard coded.
> > 
> >  * legacy-change: pki is now using m2crypto to generate certificate
> >  request
> >    and parse certificates.
> > 
> >  * legacy-change: use iproute2 instead of python ethtool to avoid
> >  another
> >    dependency for host name validation.
> > 
> >  * legacy-change: use iproute2 instead of reading /proc/net/route
> >  for route
> >    information and interface information.
> > 
> >  * legacy-change: do not use vdsm.netinfo for vlan and bonding as
> >  it requires
> >    /usr/share/vdsm modules, and it is trivial anyway.
> > 
> >  * legacy-change: use vdsm-store-net-config script to commit
> >  network config
> >    instead of internal duplicate implementation.
> > 
> >  * legacy-change: /etc/vdsm/vdsm.conf is overridden unless
> >  VDSM/configOverride
> >    environment is set to True
> 
> I'm a bit confused by the negation: I'd expect
> VDSM/configOverride=True
> to mean "override /etc/vdsm/vdsm.conf".

Sorry!
It should be False.

> 
> > 
> >  * legacy-change: /etc/vdsm/vdsm.conf is not read of fake_qemu.
> >    set VDSM/checkVirtHardware environment to False to avoid
> >    hardware detection.
> > 
> >  * legacy-change: following gluster packages not installed:
> >    - glusterfs-rdma
> >    - glusterfs-geo-replication
> 
> 
> Alon, thanks for your tremendous work on this. I cannot wait to have
> it
> up and running in the release.

Thank you!
I truly hope that from this point we can only make it better.

Alon.


From jhernand at redhat.com  Wed Nov 28 17:15:34 2012
From: jhernand at redhat.com (Juan Hernandez)
Date: Wed, 28 Nov 2012 18:15:34 +0100
Subject: [Engine-devel] Shipping settings.xml in oVirt engine's git repo
 (was RE: maven settings.xml in building ovirt engine wiki)
In-Reply-To: <50B60478.4000707@redhat.com>
References: <168159614.7093451.1354092657228.JavaMail.root@redhat.com>
	<50B5D193.2070003@redhat.com> <50B5DF3A.8070103@redhat.com>
	<50B5FC3C.6010302@redhat.com> <50B60478.4000707@redhat.com>
Message-ID: <50B646B6.3010404@redhat.com>

On 11/28/2012 01:32 PM, Juan Hernandez wrote:
> On 11/28/2012 12:57 PM, Itamar Heim wrote:
>> On 11/28/2012 04:54 AM, Juan Hernandez wrote:
>>> On 11/28/2012 09:55 AM, Itamar Heim wrote:
>>>> On 11/28/2012 03:50 AM, Allon Mureinik wrote:
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
>>>>>> To: "Allon Mureinik" <amureini at redhat.com>
>>>>>> Cc: engine-devel at ovirt.org
>>>>>> Sent: Wednesday, November 28, 2012 10:14:02 AM
>>>>>> Subject: Re: [Engine-devel] Shipping settings.xml in oVirt engine's git repo (was RE: maven settings.xml in building
>>>>>> ovirt engine wiki)
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Allon Mureinik" <amureini at redhat.com>
>>>>>>> To: engine-devel at ovirt.org
>>>>>>> Sent: Wednesday, November 28, 2012 10:05:18 AM
>>>>>>> Subject: [Engine-devel] Shipping settings.xml in oVirt engine's git
>>>>>>> repo (was RE: maven settings.xml in building
>>>>>>> ovirt engine wiki)
>>>>>>>
>>>>>>> <snipped>
>>>>>>>> Note that settings.xml isn't shifted with ovirt-engine, nor
>>>>>>>> stored
>>>>>>>> on
>>>>>>>> ovirt-engine git repository. Therefore there is no real method to
>>>>>>>> control its content expect updating the wiki page.
>>>>>>>
>>>>>>> Spinning off from the previous discussion - we can't really control
>>>>>>> the contents of settings.xml, but perhaps we can make them easier
>>>>>>> to
>>>>>>> get.
>>>>>>>
>>>>>>> Today, the flow is like this:
>>>>>>> 1. git clone - depends on gerrit.ovirt.org
>>>>>>> 2. wget settings.xml - depends on wiki.ovirt.org
>>>>>>>
>>>>>>> Suppose we ship settings.xml inside the configuration folder of
>>>>>>> ovirt
>>>>>>> (next to engine-code-format.xml and engine-commit-template.txt).
>>>>>>> Then you'll have to do:
>>>>>>> 1. git clone - depends on gerrit.ovirt.org
>>>>>>> 2. cp $OVIRT_GIT/config/settings.xml ~/.m2/
>>>>>>>
>>>>>>> This may a bit simpler, and at the very least, when we update our
>>>>>>> code (e.g., to assume java7, *hint*), we can make all the changes
>>>>>>> in
>>>>>>> a single commit, and not have to update the code and then upload a
>>>>>>> file to the wiki.
>>>>>>>
>>>>>>> Comments? Feedback?
>>>>>>
>>>>>> First thing... I don't like changing global state of a machine only
>>>>>> because we require some setting...
>>>>>>
>>>>>> So copying <ANYTHING> to ~/.m2 is completely wrong in my opinion.
>>>>>>
>>>>>> There is -gs parameter for maven to specify alternate settings file,
>>>>>> I strongly recommend people use it.
>>>>>>
>>>>>> Also, as far as I understand we only need some attributes defined...
>>>>>> It is simple to use:
>>>>>>
>>>>>> $ export MAVEN_OPTS="-Dwhatever=value -Dwhatever=value"
>>>>>>
>>>>>> Before executing eclipse or make...
>>>>>>
>>>>>> We can also integrate the environment variables idea into the maven
>>>>>> build, instead of using properties use environment variables... then
>>>>>> before executing build we:
>>>>>>
>>>>>> $ export JBOSS_HOME=
>>>>>> $ export OVIRT_JDK_HOME= (optional)
>>>>>>
>>>>>> If anyone prefers/chooses to use settings.xml he can create his
>>>>>> own...
>>>>>>
>>>>>> So there are so many options, the last option is to use settings.xml
>>>>>> in my opinion... not that I against adding this template, but I
>>>>>> first suggest we consider removing its usage completely.... :)
>>>>>>
>>>>>> Regards,
>>>>>> Alon
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -Allon
>>>>>
>>>>> I'll rephrase.
>>>>> /today/ we provide an example of settings.xml in "Building the oVirt Engine" wiki page.
>>>>> People who understand maven will not overwrite their settings.xml with it, and people who don't have a comfortable quick start.
>>>>>
>>>>> I propose to supply this /exmaple/ in a more accessible place $OVIRT_GIT/config.
>>>>> People who didn't overwrite their existing .m2 file still won't, and people who did have an easier way of doing it.
>>>>
>>>> i agree having the sample in the git will make it simpler, and we must
>>>> make it simpler (juan is working on cleaning up the 'setup devel' flow).
>>>
>>> I am not against having that example in the git repository. But I don't
>>> see how that is going to make life easier for newcomers. We will have to
>>> instruct them (in the wiki) how to find the file instead of instructing
>>> them how to create it, not much difference.
>>
>> if we tell them to:
>> yum install X Y Z
>> git clone ...
>> cd ovirt-engine
>> mvn clean install --settings settings.xml
>>
>> it should just work, unless i am missing something?
> 
> Yes, should work, but then we need to include this "--settings
> $HOME/ovirt-engine/settings.xml" in all the example commands in the
> wiki. It doesn't make things simpler.
> 
>>
>>>
>>>>
>>>> for simplicity, please lets also assume the would be developer also
>>>> isn't intimate with eclipse/jboss, so default in the file should work
>>>> with someone doing:
>>>> yum install eclipse jbossas
>>>>
>>>
>>> Unfortunately using "yum install jbossas" is not an option currently, as
>>> that requires the developer to use root, which causes a lot of trouble.
>>
>> any way to solve this?
> 
> The easy solution is to use the .zip distribution, which works in any
> distribution.
> 
> For the future, in my opinion, we should move towards a model where the
> development environment is much more similar to the production
> environment than what we have now. The build system should be able to
> install the complete engine to a directory under the developer home
> directory, with the same file system structure that we use in production
> environments. Then the developer should be able to start/stop the engine
> (and tools) using the same scripts that we use in production
> environments. These scripts don't need write access to the jboss-as
> installation directories, so as a side effect they solve this problem.
> 
>>
>>> We have to instruct new developers to download the JBoss .zip file and
>>> uncompress it somewhere, easiest is the developer's home directory. This
>>> has the advantage that it also works in distributions that haven't
>>> packaged JBoss yet.
>>>
>>> Using "yum install eclipse" also has its drawbacks, as the version of
>>> eclipse in Fedora doesn't include the maven plugin.
>>>
>>
>> isn't the maven plugin just another rpm?
>>
> 
> No, the maven plugin is not yet packaged for fedora:
> 
> https://bugzilla.redhat.com/814245
> 
> It can be installed manually as described in the wiki, and then it
> should work (it doesn't in Fedora 18 as far as I can tell).
> 
> I would rather suggest using a lighter alternative, like including
> working .project and .classpath files in the repository (I can foresee a
> lot of people cursing me for proposing this) or generating them using
> the maven eclipse plugin (see [1], don't confuse it with m2e [2]).
> 
> [1] http://maven.apache.org/plugins/maven-eclipse-plugin
> [2] http://eclipse.org/m2e
> 

I just submitted a change to add a new eclipse.py script that creates
the Eclipse project files automatically:

http://gerrit.ovirt.org/9556

If this is accepted I can update the wiki add instructions on how to use it.

Of course those that prefer it can continue using m2e, this is just a
lighter and simpler alternative, specially for environments where m2e is
not available out of the box.

-- 
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 iheim at redhat.com  Wed Nov 28 18:13:51 2012
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 28 Nov 2012 13:13:51 -0500
Subject: [Engine-devel] Shipping settings.xml in oVirt engine's git repo
 (was RE: maven settings.xml in building ovirt engine wiki)
In-Reply-To: <50B646B6.3010404@redhat.com>
References: <168159614.7093451.1354092657228.JavaMail.root@redhat.com>
	<50B5D193.2070003@redhat.com> <50B5DF3A.8070103@redhat.com>
	<50B5FC3C.6010302@redhat.com> <50B60478.4000707@redhat.com>
	<50B646B6.3010404@redhat.com>
Message-ID: <50B6545F.6090900@redhat.com>

On 11/28/2012 12:15 PM, Juan Hernandez wrote:
> On 11/28/2012 01:32 PM, Juan Hernandez wrote:
>> On 11/28/2012 12:57 PM, Itamar Heim wrote:
>>> On 11/28/2012 04:54 AM, Juan Hernandez wrote:
>>>> On 11/28/2012 09:55 AM, Itamar Heim wrote:
>>>>> On 11/28/2012 03:50 AM, Allon Mureinik wrote:
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
>>>>>>> To: "Allon Mureinik" <amureini at redhat.com>
>>>>>>> Cc: engine-devel at ovirt.org
>>>>>>> Sent: Wednesday, November 28, 2012 10:14:02 AM
>>>>>>> Subject: Re: [Engine-devel] Shipping settings.xml in oVirt engine's git repo (was RE: maven settings.xml in building
>>>>>>> ovirt engine wiki)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Allon Mureinik" <amureini at redhat.com>
>>>>>>>> To: engine-devel at ovirt.org
>>>>>>>> Sent: Wednesday, November 28, 2012 10:05:18 AM
>>>>>>>> Subject: [Engine-devel] Shipping settings.xml in oVirt engine's git
>>>>>>>> repo (was RE: maven settings.xml in building
>>>>>>>> ovirt engine wiki)
>>>>>>>>
>>>>>>>> <snipped>
>>>>>>>>> Note that settings.xml isn't shifted with ovirt-engine, nor
>>>>>>>>> stored
>>>>>>>>> on
>>>>>>>>> ovirt-engine git repository. Therefore there is no real method to
>>>>>>>>> control its content expect updating the wiki page.
>>>>>>>>
>>>>>>>> Spinning off from the previous discussion - we can't really control
>>>>>>>> the contents of settings.xml, but perhaps we can make them easier
>>>>>>>> to
>>>>>>>> get.
>>>>>>>>
>>>>>>>> Today, the flow is like this:
>>>>>>>> 1. git clone - depends on gerrit.ovirt.org
>>>>>>>> 2. wget settings.xml - depends on wiki.ovirt.org
>>>>>>>>
>>>>>>>> Suppose we ship settings.xml inside the configuration folder of
>>>>>>>> ovirt
>>>>>>>> (next to engine-code-format.xml and engine-commit-template.txt).
>>>>>>>> Then you'll have to do:
>>>>>>>> 1. git clone - depends on gerrit.ovirt.org
>>>>>>>> 2. cp $OVIRT_GIT/config/settings.xml ~/.m2/
>>>>>>>>
>>>>>>>> This may a bit simpler, and at the very least, when we update our
>>>>>>>> code (e.g., to assume java7, *hint*), we can make all the changes
>>>>>>>> in
>>>>>>>> a single commit, and not have to update the code and then upload a
>>>>>>>> file to the wiki.
>>>>>>>>
>>>>>>>> Comments? Feedback?
>>>>>>>
>>>>>>> First thing... I don't like changing global state of a machine only
>>>>>>> because we require some setting...
>>>>>>>
>>>>>>> So copying <ANYTHING> to ~/.m2 is completely wrong in my opinion.
>>>>>>>
>>>>>>> There is -gs parameter for maven to specify alternate settings file,
>>>>>>> I strongly recommend people use it.
>>>>>>>
>>>>>>> Also, as far as I understand we only need some attributes defined...
>>>>>>> It is simple to use:
>>>>>>>
>>>>>>> $ export MAVEN_OPTS="-Dwhatever=value -Dwhatever=value"
>>>>>>>
>>>>>>> Before executing eclipse or make...
>>>>>>>
>>>>>>> We can also integrate the environment variables idea into the maven
>>>>>>> build, instead of using properties use environment variables... then
>>>>>>> before executing build we:
>>>>>>>
>>>>>>> $ export JBOSS_HOME=
>>>>>>> $ export OVIRT_JDK_HOME= (optional)
>>>>>>>
>>>>>>> If anyone prefers/chooses to use settings.xml he can create his
>>>>>>> own...
>>>>>>>
>>>>>>> So there are so many options, the last option is to use settings.xml
>>>>>>> in my opinion... not that I against adding this template, but I
>>>>>>> first suggest we consider removing its usage completely.... :)
>>>>>>>
>>>>>>> Regards,
>>>>>>> Alon
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -Allon
>>>>>>
>>>>>> I'll rephrase.
>>>>>> /today/ we provide an example of settings.xml in "Building the oVirt Engine" wiki page.
>>>>>> People who understand maven will not overwrite their settings.xml with it, and people who don't have a comfortable quick start.
>>>>>>
>>>>>> I propose to supply this /exmaple/ in a more accessible place $OVIRT_GIT/config.
>>>>>> People who didn't overwrite their existing .m2 file still won't, and people who did have an easier way of doing it.
>>>>>
>>>>> i agree having the sample in the git will make it simpler, and we must
>>>>> make it simpler (juan is working on cleaning up the 'setup devel' flow).
>>>>
>>>> I am not against having that example in the git repository. But I don't
>>>> see how that is going to make life easier for newcomers. We will have to
>>>> instruct them (in the wiki) how to find the file instead of instructing
>>>> them how to create it, not much difference.
>>>
>>> if we tell them to:
>>> yum install X Y Z
>>> git clone ...
>>> cd ovirt-engine
>>> mvn clean install --settings settings.xml
>>>
>>> it should just work, unless i am missing something?
>>
>> Yes, should work, but then we need to include this "--settings
>> $HOME/ovirt-engine/settings.xml" in all the example commands in the
>> wiki. It doesn't make things simpler.
>>
>>>
>>>>
>>>>>
>>>>> for simplicity, please lets also assume the would be developer also
>>>>> isn't intimate with eclipse/jboss, so default in the file should work
>>>>> with someone doing:
>>>>> yum install eclipse jbossas
>>>>>
>>>>
>>>> Unfortunately using "yum install jbossas" is not an option currently, as
>>>> that requires the developer to use root, which causes a lot of trouble.
>>>
>>> any way to solve this?
>>
>> The easy solution is to use the .zip distribution, which works in any
>> distribution.
>>
>> For the future, in my opinion, we should move towards a model where the
>> development environment is much more similar to the production
>> environment than what we have now. The build system should be able to
>> install the complete engine to a directory under the developer home
>> directory, with the same file system structure that we use in production
>> environments. Then the developer should be able to start/stop the engine
>> (and tools) using the same scripts that we use in production
>> environments. These scripts don't need write access to the jboss-as
>> installation directories, so as a side effect they solve this problem.
>>
>>>
>>>> We have to instruct new developers to download the JBoss .zip file and
>>>> uncompress it somewhere, easiest is the developer's home directory. This
>>>> has the advantage that it also works in distributions that haven't
>>>> packaged JBoss yet.
>>>>
>>>> Using "yum install eclipse" also has its drawbacks, as the version of
>>>> eclipse in Fedora doesn't include the maven plugin.
>>>>
>>>
>>> isn't the maven plugin just another rpm?
>>>
>>
>> No, the maven plugin is not yet packaged for fedora:
>>
>> https://bugzilla.redhat.com/814245
>>
>> It can be installed manually as described in the wiki, and then it
>> should work (it doesn't in Fedora 18 as far as I can tell).
>>
>> I would rather suggest using a lighter alternative, like including
>> working .project and .classpath files in the repository (I can foresee a
>> lot of people cursing me for proposing this) or generating them using
>> the maven eclipse plugin (see [1], don't confuse it with m2e [2]).
>>
>> [1] http://maven.apache.org/plugins/maven-eclipse-plugin
>> [2] http://eclipse.org/m2e
>>
>
> I just submitted a change to add a new eclipse.py script that creates
> the Eclipse project files automatically:
>
> http://gerrit.ovirt.org/9556
>
> If this is accepted I can update the wiki add instructions on how to use it.
>
> Of course those that prefer it can continue using m2e, this is just a
> lighter and simpler alternative, specially for environments where m2e is
> not available out of the box.
>

I'm pretty sure i saw some negative feelings about eclipse project files 
vs. using m2e.
do we know what the gap the m2e plugin has to get into fedora?



From danken at redhat.com  Wed Nov 28 19:48:41 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Wed, 28 Nov 2012 21:48:41 +0200
Subject: [Engine-devel] [vdsm] [ATTENTION] vdsm-bootstrap/host
	deployment (pre-3.2)
In-Reply-To: <469209898.1995297.1354113917831.JavaMail.root@redhat.com>
References: <20121128144104.GV5083@redhat.com>
	<469209898.1995297.1354113917831.JavaMail.root@redhat.com>
Message-ID: <20121128194841.GA9825@redhat.com>

On Wed, Nov 28, 2012 at 09:45:17AM -0500, Alon Bar-Lev wrote:
> 
> > On Wed, Nov 28, 2012 at 08:59:10AM -0500, Alon Bar-Lev wrote:
> > > Hello All,
> > > 
> > > Preparing to ovirt-engine 3.2 the entire "vdsm-bootstrap" bootstrap
> > > was re-written from scratch into more pluggable and flexible
> > > implementation, available at git master and nightly snapshots.
> > > 
> > > As far as packaging is concerned there are now two more
> > > dependencies to ovirt-engine:
> > > 
> > >  * otopi -- oVirt Task Oriented Pluggable Installer/Implementation
> > >  * ovirt-host-deploy -- oVirt host deploy tool
> > > 
> > > These packages replace the legacy vdsm-bootstrap package that was
> > > distributed with vdsm.
> > 
> > Hurray!
> > 
> > I suspect that a `git-rm vds_bootstrap/*` is pending?
> 
> No... we need it as compatibility with older engines...
> We keep minimum changes there for legacy, until end-of-life.

Is there an EoL statement for oVirt-3.1?
We can make sure that oVirt-3.2's vdsm installs properly with
ovirt-3.1's vdsm-bootstrap, or even require that Engine must be upgraded
to ovirt-3.2 before upgrading any of the hosts. Is it too harsh to our
vast install base?  users at ovirt.org, please chime in!

> 
> > 
> > > 
> > > Git repositories are available at at[1][2].
> > > Documentation is available at Git repositories - README*.
> > > Builds are available at usual place[3].
> > > Bugzilla components will be available shortly.
> > 
> > Are there requests to add the components to Fedora (18, EPEL6)?
> > I think we should add these requests as blockers for Bug 881006 -
> > Tracker: oVirt 3.2 release.
> 
> Yes, I am on this one.
> 
> > 
> > > Change log is attached.
> > > 
> > > There is no change in the way the engine is performing the host
> > > deployment process in term of user experience, other than event log
> > > messages during deployment were improved.
> > > 
> > > The log of the deployment is fetched from host and stored at engine
> > > machine at /var/log/ovirt-engine/host-deploy, on host it is at
> > > /tmp/ovirt-host-deploy*.log and deleted when fetched to engine.
> > > 
> > > Among other features, the ovir-host-deploy package can be installed
> > > manually on host and executed to prepare host for installation, in
> > > future we may be able to add host to engine without performing the
> > > deployment process, for now it will be usable for integration
> > > tests.
> > > 
> > > The internals are completely different, instead of having 3
> > > different
> > > bootstrap sequences:
> > >  1. host install
> > >  2. ovirt-node install
> > >  3. ovirt-node approve
> > > 
> > > We now have single sequence which is common to host and node
> > > installation or re-installation, end result is much simpler
> > > implementation.
> > > 
> > > Please report any issues even minor issues, so we can stabilize it
> > > for
> > > 3.2 release.
> > > 
> > > Best Regards,
> > > Alon Bar-Lev.
> > > 
> > > [1] http://gerrit.ovirt.org/gitweb?p=otopi.git;a=tree
> > > [2] http://gerrit.ovirt.org/gitweb?p=ovirt-host-deploy.git;a=tree
> > > [3] http://www.ovirt.org/releases/nightly/rpm/Fedora/17/noarch/
> > > 
> > > ---
> > > 
> > > Change Log
> > > 
> > >  * offline packager feature.
> > > 
> > >  * tuned is installed with virtual-host profile.
> > 
> > I never understood why this is an installer step, and not part of
> > vdsmd
> > start up
> 
> There may be several method to tune a machine.
> Why VDSM should depend on specific one?

Maybe because I tend to install vdsm using `yum`, and would like it to
do The Right Thing to make the host an oVirt node. I suspect that if ovirt-host-deploy
proves to be easy to use, I could follow my `yum install vdsm` with
`ovirt-host-deploy`.

> 
> > 
> > >  * initial implementation based on otpoi.
> > > 
> > >  * implementation is based on legacy vdsm-bootstrap pacakge
> > >  functionality.
> > > 
> > >  * legacy-removed: legacy VDSM (<3.0) config upgrade.
> > > 
> > >  * legacy-removed: change machine width core file
> > >   # echo /var/lib/vdsm/core > /proc/sys/kernel/core_pattern
> > 
> > Yeah, qemu-kvm and libvirtd are much more stable than in the old
> > days,
> > but wouldn't we want to keep a means to collect the corpses of dead
> > processes from hypervisors? It has helped us nail down nasty bugs,
> > even
> > in Python.
> 
> It does not mean it should be at /var/lib/vdsm ... :)

I don't get the joke :-(. If you mind the location, we can think of
somewhere else to put the core dumps. Would it be hard to reinstate a
parallel feature in otopi?


> > 
> > 
> > Alon, thanks for your tremendous work on this. I cannot wait to have
> > it
> > up and running in the release.
> 
> Thank you!
> I truly hope that from this point we can only make it better.

Do you mean that we've reached rock bottom? ;-)


From alonbl at redhat.com  Wed Nov 28 19:57:17 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Wed, 28 Nov 2012 14:57:17 -0500 (EST)
Subject: [Engine-devel] [vdsm] [ATTENTION] vdsm-bootstrap/host
	deployment (pre-3.2)
In-Reply-To: <20121128194841.GA9825@redhat.com>
Message-ID: <1353178752.2107016.1354132637936.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "VDSM Project Development" <vdsm-devel at lists.fedorahosted.org>, "engine-devel" <engine-devel at ovirt.org>, "users"
> <users at ovirt.org>
> Sent: Wednesday, November 28, 2012 9:48:41 PM
> Subject: Re: [vdsm] [ATTENTION] vdsm-bootstrap/host deployment (pre-3.2)
> 
> On Wed, Nov 28, 2012 at 09:45:17AM -0500, Alon Bar-Lev wrote:
> > 
> > > On Wed, Nov 28, 2012 at 08:59:10AM -0500, Alon Bar-Lev wrote:
> > > > Hello All,
> > > > 
> > > > Preparing to ovirt-engine 3.2 the entire "vdsm-bootstrap"
> > > > bootstrap
> > > > was re-written from scratch into more pluggable and flexible
> > > > implementation, available at git master and nightly snapshots.
> > > > 
> > > > As far as packaging is concerned there are now two more
> > > > dependencies to ovirt-engine:
> > > > 
> > > >  * otopi -- oVirt Task Oriented Pluggable
> > > >  Installer/Implementation
> > > >  * ovirt-host-deploy -- oVirt host deploy tool
> > > > 
> > > > These packages replace the legacy vdsm-bootstrap package that
> > > > was
> > > > distributed with vdsm.
> > > 
> > > Hurray!
> > > 
> > > I suspect that a `git-rm vds_bootstrap/*` is pending?
> > 
> > No... we need it as compatibility with older engines...
> > We keep minimum changes there for legacy, until end-of-life.
> 
> Is there an EoL statement for oVirt-3.1?
> We can make sure that oVirt-3.2's vdsm installs properly with
> ovirt-3.1's vdsm-bootstrap, or even require that Engine must be
> upgraded
> to ovirt-3.2 before upgrading any of the hosts. Is it too harsh to
> our
> vast install base?  users at ovirt.org, please chime in!
>

I tried to find such, but the more I dig I find that we need to support old legacy.

> > 
> > > 
> > > > 
> > > > Git repositories are available at at[1][2].
> > > > Documentation is available at Git repositories - README*.
> > > > Builds are available at usual place[3].
> > > > Bugzilla components will be available shortly.
> > > 
> > > Are there requests to add the components to Fedora (18, EPEL6)?
> > > I think we should add these requests as blockers for Bug 881006 -
> > > Tracker: oVirt 3.2 release.
> > 
> > Yes, I am on this one.
> > 
> > > 
> > > > Change log is attached.
> > > > 
> > > > There is no change in the way the engine is performing the host
> > > > deployment process in term of user experience, other than event
> > > > log
> > > > messages during deployment were improved.
> > > > 
> > > > The log of the deployment is fetched from host and stored at
> > > > engine
> > > > machine at /var/log/ovirt-engine/host-deploy, on host it is at
> > > > /tmp/ovirt-host-deploy*.log and deleted when fetched to engine.
> > > > 
> > > > Among other features, the ovir-host-deploy package can be
> > > > installed
> > > > manually on host and executed to prepare host for installation,
> > > > in
> > > > future we may be able to add host to engine without performing
> > > > the
> > > > deployment process, for now it will be usable for integration
> > > > tests.
> > > > 
> > > > The internals are completely different, instead of having 3
> > > > different
> > > > bootstrap sequences:
> > > >  1. host install
> > > >  2. ovirt-node install
> > > >  3. ovirt-node approve
> > > > 
> > > > We now have single sequence which is common to host and node
> > > > installation or re-installation, end result is much simpler
> > > > implementation.
> > > > 
> > > > Please report any issues even minor issues, so we can stabilize
> > > > it
> > > > for
> > > > 3.2 release.
> > > > 
> > > > Best Regards,
> > > > Alon Bar-Lev.
> > > > 
> > > > [1] http://gerrit.ovirt.org/gitweb?p=otopi.git;a=tree
> > > > [2]
> > > > http://gerrit.ovirt.org/gitweb?p=ovirt-host-deploy.git;a=tree
> > > > [3] http://www.ovirt.org/releases/nightly/rpm/Fedora/17/noarch/
> > > > 
> > > > ---
> > > > 
> > > > Change Log
> > > > 
> > > >  * offline packager feature.
> > > > 
> > > >  * tuned is installed with virtual-host profile.
> > > 
> > > I never understood why this is an installer step, and not part of
> > > vdsmd
> > > start up
> > 
> > There may be several method to tune a machine.
> > Why VDSM should depend on specific one?
> 
> Maybe because I tend to install vdsm using `yum`, and would like it
> to
> do The Right Thing to make the host an oVirt node. I suspect that if
> ovirt-host-deploy
> proves to be easy to use, I could follow my `yum install vdsm` with
> `ovirt-host-deploy`.

I will be glad if you try it out.

> 
> > 
> > > 
> > > >  * initial implementation based on otpoi.
> > > > 
> > > >  * implementation is based on legacy vdsm-bootstrap pacakge
> > > >  functionality.
> > > > 
> > > >  * legacy-removed: legacy VDSM (<3.0) config upgrade.
> > > > 
> > > >  * legacy-removed: change machine width core file
> > > >   # echo /var/lib/vdsm/core > /proc/sys/kernel/core_pattern
> > > 
> > > Yeah, qemu-kvm and libvirtd are much more stable than in the old
> > > days,
> > > but wouldn't we want to keep a means to collect the corpses of
> > > dead
> > > processes from hypervisors? It has helped us nail down nasty
> > > bugs,
> > > even
> > > in Python.
> > 
> > It does not mean it should be at /var/lib/vdsm ... :)
> 
> I don't get the joke :-(. If you mind the location, we can think of
> somewhere else to put the core dumps. Would it be hard to reinstate a
> parallel feature in otopi?

I usually do not make any jokes...
A global system setting should not go into package specific location.
Usually core dumps are off by default, I like this approach as unattended system may fast consume all disk space because of dumps.
If sysadmin manually enables dumps, he may do this at a location of his own choice.
If we want to automatically enable dumps I guess it should go to /var/lib/core or similar.

> 
> > > 
> > > 
> > > Alon, thanks for your tremendous work on this. I cannot wait to
> > > have
> > > it
> > > up and running in the release.
> > 
> > Thank you!
> > I truly hope that from this point we can only make it better.
> 
> Do you mean that we've reached rock bottom? ;-)

No, that now I have some infrastructure that I can use to provide solutions.

Regards,
Alon


From danken at redhat.com  Wed Nov 28 20:39:42 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Wed, 28 Nov 2012 22:39:42 +0200
Subject: [Engine-devel] [vdsm] [ATTENTION] vdsm-bootstrap/host
	deployment (pre-3.2)
In-Reply-To: <1353178752.2107016.1354132637936.JavaMail.root@redhat.com>
References: <20121128194841.GA9825@redhat.com>
	<1353178752.2107016.1354132637936.JavaMail.root@redhat.com>
Message-ID: <20121128203942.GE9825@redhat.com>

On Wed, Nov 28, 2012 at 02:57:17PM -0500, Alon Bar-Lev wrote:
> 
> > > No... we need it as compatibility with older engines...
> > > We keep minimum changes there for legacy, until end-of-life.
> > 
> > Is there an EoL statement for oVirt-3.1?
> > We can make sure that oVirt-3.2's vdsm installs properly with
> > ovirt-3.1's vdsm-bootstrap, or even require that Engine must be
> > upgraded
> > to ovirt-3.2 before upgrading any of the hosts. Is it too harsh to
> > our
> > vast install base?  users at ovirt.org, please chime in!
> >
> 
> I tried to find such, but the more I dig I find that we need to support old legacy.

Why, exactly? Fedora gives no such guarntees (heck, I'm stuck with an
unupgradable F16). Should we be any better than our (currently single)
platform?

> > > > > 
> > > > >  * legacy-removed: change machine width core file
> > > > >   # echo /var/lib/vdsm/core > /proc/sys/kernel/core_pattern
> > > > 
> > > > Yeah, qemu-kvm and libvirtd are much more stable than in the old
> > > > days,
> > > > but wouldn't we want to keep a means to collect the corpses of
> > > > dead
> > > > processes from hypervisors? It has helped us nail down nasty
> > > > bugs,
> > > > even
> > > > in Python.
> > > 
> > > It does not mean it should be at /var/lib/vdsm ... :)
> > 
> > I don't get the joke :-(. If you mind the location, we can think of
> > somewhere else to put the core dumps. Would it be hard to reinstate a
> > parallel feature in otopi?
> 
> I usually do not make any jokes...
> A global system setting should not go into package specific location.
> Usually core dumps are off by default, I like this approach as unattended system may fast consume all disk space because of dumps.

If a host fills up with dumps so quickly, it's a sign that it should not
be used for production, and that someone should look into the cores.
(P.S. we have a logrotate rule for them in vdsm)

> If sysadmin manually enables dumps, he may do this at a location of his own choice.

Note that we've just swapped hats: you're arguing for letting a local
admin log in and mess with system configuration, and I'm for keeping a
centralized feature for storing and collecting core dumps.

> If we want to automatically enable dumps I guess it should go to /var/lib/core or similar.




From alonbl at redhat.com  Wed Nov 28 20:45:28 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Wed, 28 Nov 2012 15:45:28 -0500 (EST)
Subject: [Engine-devel] [vdsm] [ATTENTION] vdsm-bootstrap/host
	deployment (pre-3.2)
In-Reply-To: <20121128203942.GE9825@redhat.com>
Message-ID: <598638595.2117367.1354135528311.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "VDSM Project Development" <vdsm-devel at lists.fedorahosted.org>, "engine-devel" <engine-devel at ovirt.org>, "users"
> <users at ovirt.org>
> Sent: Wednesday, November 28, 2012 10:39:42 PM
> Subject: Re: [vdsm] [ATTENTION] vdsm-bootstrap/host deployment (pre-3.2)
> 
> On Wed, Nov 28, 2012 at 02:57:17PM -0500, Alon Bar-Lev wrote:
> > 
> > > > No... we need it as compatibility with older engines...
> > > > We keep minimum changes there for legacy, until end-of-life.
> > > 
> > > Is there an EoL statement for oVirt-3.1?
> > > We can make sure that oVirt-3.2's vdsm installs properly with
> > > ovirt-3.1's vdsm-bootstrap, or even require that Engine must be
> > > upgraded
> > > to ovirt-3.2 before upgrading any of the hosts. Is it too harsh
> > > to
> > > our
> > > vast install base?  users at ovirt.org, please chime in!
> > >
> > 
> > I tried to find such, but the more I dig I find that we need to
> > support old legacy.
> 
> Why, exactly? Fedora gives no such guarntees (heck, I'm stuck with an
> unupgradable F16). Should we be any better than our (currently
> single)
> platform?

We should start and detach from specific distro procedures.

> 
> > > > > > 
> > > > > >  * legacy-removed: change machine width core file
> > > > > >   # echo /var/lib/vdsm/core > /proc/sys/kernel/core_pattern
> > > > > 
> > > > > Yeah, qemu-kvm and libvirtd are much more stable than in the
> > > > > old
> > > > > days,
> > > > > but wouldn't we want to keep a means to collect the corpses
> > > > > of
> > > > > dead
> > > > > processes from hypervisors? It has helped us nail down nasty
> > > > > bugs,
> > > > > even
> > > > > in Python.
> > > > 
> > > > It does not mean it should be at /var/lib/vdsm ... :)
> > > 
> > > I don't get the joke :-(. If you mind the location, we can think
> > > of
> > > somewhere else to put the core dumps. Would it be hard to
> > > reinstate a
> > > parallel feature in otopi?
> > 
> > I usually do not make any jokes...
> > A global system setting should not go into package specific
> > location.
> > Usually core dumps are off by default, I like this approach as
> > unattended system may fast consume all disk space because of
> > dumps.
> 
> If a host fills up with dumps so quickly, it's a sign that it should
> not
> be used for production, and that someone should look into the cores.
> (P.S. we have a logrotate rule for them in vdsm)

There should be a vdsm-debug-aids (or similar) to perform such changes.
Again, I don't think vdsm should (by default) modify any system width parameter such as this.
But I will happy to hear more views.

> 
> > If sysadmin manually enables dumps, he may do this at a location of
> > his own choice.
> 
> Note that we've just swapped hats: you're arguing for letting a local
> admin log in and mess with system configuration, and I'm for keeping
> a
> centralized feature for storing and collecting core dumps.

As problems like crashes are investigated per case and reproduction scenario.
But again, I may be wrong and we should have VDSM API command to start/stop storing dumps and manage this via its master...

> 
> > If we want to automatically enable dumps I guess it should go to
> > /var/lib/core or similar.
>


From ryanh at us.ibm.com  Wed Nov 28 21:22:59 2012
From: ryanh at us.ibm.com (Ryan Harper)
Date: Wed, 28 Nov 2012 15:22:59 -0600
Subject: [Engine-devel] [vdsm] [ATTENTION] vdsm-bootstrap/host
 deployment (pre-3.2)
In-Reply-To: <598638595.2117367.1354135528311.JavaMail.root@redhat.com>
References: <20121128203942.GE9825@redhat.com>
	<598638595.2117367.1354135528311.JavaMail.root@redhat.com>
Message-ID: <20121128212259.GP10470@frylock.phx.austin.ibm.com>

* Alon Bar-Lev <alonbl at redhat.com> [2012-11-28 14:47]:
> 
> 
> ----- Original Message -----
> > From: "Dan Kenigsberg" <danken at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "VDSM Project Development" <vdsm-devel at lists.fedorahosted.org>, "engine-devel" <engine-devel at ovirt.org>, "users"
> > <users at ovirt.org>
> > Sent: Wednesday, November 28, 2012 10:39:42 PM
> > Subject: Re: [vdsm] [ATTENTION] vdsm-bootstrap/host deployment (pre-3.2)
> > 
> > On Wed, Nov 28, 2012 at 02:57:17PM -0500, Alon Bar-Lev wrote:
> > > 
> > > > > No... we need it as compatibility with older engines...
> > > > > We keep minimum changes there for legacy, until end-of-life.
> > > > 
> > > > Is there an EoL statement for oVirt-3.1?
> > > > We can make sure that oVirt-3.2's vdsm installs properly with
> > > > ovirt-3.1's vdsm-bootstrap, or even require that Engine must be
> > > > upgraded
> > > > to ovirt-3.2 before upgrading any of the hosts. Is it too harsh
> > > > to
> > > > our
> > > > vast install base?  users at ovirt.org, please chime in!
> > > >
> > > 
> > > I tried to find such, but the more I dig I find that we need to
> > > support old legacy.
> > 
> > Why, exactly? Fedora gives no such guarntees (heck, I'm stuck with an
> > unupgradable F16). Should we be any better than our (currently
> > single)
> > platform?
> 
> We should start and detach from specific distro procedures.
> 
> > 
> > > > > > > 
> > > > > > >  * legacy-removed: change machine width core file
> > > > > > >   # echo /var/lib/vdsm/core > /proc/sys/kernel/core_pattern
> > > > > > 
> > > > > > Yeah, qemu-kvm and libvirtd are much more stable than in the
> > > > > > old
> > > > > > days,
> > > > > > but wouldn't we want to keep a means to collect the corpses
> > > > > > of
> > > > > > dead
> > > > > > processes from hypervisors? It has helped us nail down nasty
> > > > > > bugs,
> > > > > > even
> > > > > > in Python.
> > > > > 
> > > > > It does not mean it should be at /var/lib/vdsm ... :)
> > > > 
> > > > I don't get the joke :-(. If you mind the location, we can think
> > > > of
> > > > somewhere else to put the core dumps. Would it be hard to
> > > > reinstate a
> > > > parallel feature in otopi?
> > > 
> > > I usually do not make any jokes...
> > > A global system setting should not go into package specific
> > > location.
> > > Usually core dumps are off by default, I like this approach as
> > > unattended system may fast consume all disk space because of
> > > dumps.
> > 
> > If a host fills up with dumps so quickly, it's a sign that it should
> > not
> > be used for production, and that someone should look into the cores.
> > (P.S. we have a logrotate rule for them in vdsm)
> 
> There should be a vdsm-debug-aids (or similar) to perform such changes.
> Again, I don't think vdsm should (by default) modify any system width parameter such as this.
> But I will happy to hear more views.
> 
> > 
> > > If sysadmin manually enables dumps, he may do this at a location of
> > > his own choice.
> > 
> > Note that we've just swapped hats: you're arguing for letting a local
> > admin log in and mess with system configuration, and I'm for keeping
> > a
> > centralized feature for storing and collecting core dumps.
> 
> As problems like crashes are investigated per case and reproduction scenario.
> But again, I may be wrong and we should have VDSM API command to
> start/stop storing dumps and manage this via its master...

I very much like this idea.  There was a thread a while back
discussing[1] the this very idea; I was looking for a way to enable
'debugging' mode as well as a way to programatically collect debugging
info (which could include host stats, guest stats, logs and any core
files).

Certainly in such a scenario, being able to enable/disable varous
features of a debugging mode could include whether to enable core dumps
as well as where to save them on the host.


1. http://comments.gmane.org/gmane.comp.emulators.ovirt.vdsm.devel/1387


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



From agl at us.ibm.com  Wed Nov 28 21:29:35 2012
From: agl at us.ibm.com (Adam Litke)
Date: Wed, 28 Nov 2012 15:29:35 -0600
Subject: [Engine-devel] [vdsm] [ATTENTION] vdsm-bootstrap/host
	deployment (pre-3.2)
In-Reply-To: <598638595.2117367.1354135528311.JavaMail.root@redhat.com>
References: <20121128203942.GE9825@redhat.com>
	<598638595.2117367.1354135528311.JavaMail.root@redhat.com>
Message-ID: <20121128212935.GN13692@aglitke>

On Wed, Nov 28, 2012 at 03:45:28PM -0500, Alon Bar-Lev wrote:
> 
> 
> ----- Original Message -----
> > From: "Dan Kenigsberg" <danken at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "VDSM Project Development" <vdsm-devel at lists.fedorahosted.org>, "engine-devel" <engine-devel at ovirt.org>, "users"
> > <users at ovirt.org>
> > Sent: Wednesday, November 28, 2012 10:39:42 PM
> > Subject: Re: [vdsm] [ATTENTION] vdsm-bootstrap/host deployment (pre-3.2)
> > 
> > On Wed, Nov 28, 2012 at 02:57:17PM -0500, Alon Bar-Lev wrote:
> > > 
> > > > > No... we need it as compatibility with older engines...
> > > > > We keep minimum changes there for legacy, until end-of-life.
> > > > 
> > > > Is there an EoL statement for oVirt-3.1?
> > > > We can make sure that oVirt-3.2's vdsm installs properly with
> > > > ovirt-3.1's vdsm-bootstrap, or even require that Engine must be
> > > > upgraded
> > > > to ovirt-3.2 before upgrading any of the hosts. Is it too harsh
> > > > to
> > > > our
> > > > vast install base?  users at ovirt.org, please chime in!
> > > >
> > > 
> > > I tried to find such, but the more I dig I find that we need to
> > > support old legacy.
> > 
> > Why, exactly? Fedora gives no such guarntees (heck, I'm stuck with an
> > unupgradable F16). Should we be any better than our (currently
> > single)
> > platform?
> 
> We should start and detach from specific distro procedures.
> 
> > 
> > > > > > > 
> > > > > > >  * legacy-removed: change machine width core file
> > > > > > >   # echo /var/lib/vdsm/core > /proc/sys/kernel/core_pattern
> > > > > > 
> > > > > > Yeah, qemu-kvm and libvirtd are much more stable than in the
> > > > > > old
> > > > > > days,
> > > > > > but wouldn't we want to keep a means to collect the corpses
> > > > > > of
> > > > > > dead
> > > > > > processes from hypervisors? It has helped us nail down nasty
> > > > > > bugs,
> > > > > > even
> > > > > > in Python.
> > > > > 
> > > > > It does not mean it should be at /var/lib/vdsm ... :)
> > > > 
> > > > I don't get the joke :-(. If you mind the location, we can think
> > > > of
> > > > somewhere else to put the core dumps. Would it be hard to
> > > > reinstate a
> > > > parallel feature in otopi?
> > > 
> > > I usually do not make any jokes...
> > > A global system setting should not go into package specific
> > > location.
> > > Usually core dumps are off by default, I like this approach as
> > > unattended system may fast consume all disk space because of
> > > dumps.
> > 
> > If a host fills up with dumps so quickly, it's a sign that it should
> > not
> > be used for production, and that someone should look into the cores.
> > (P.S. we have a logrotate rule for them in vdsm)
> 
> There should be a vdsm-debug-aids (or similar) to perform such changes.
> Again, I don't think vdsm should (by default) modify any system width parameter such as this.
> But I will happy to hear more views.

I agree with your statement above that a single package should not override a
global system setting.  We should really work to remove as many of these from
vdsm as we possibly can.  It will help to make vdsm a much safer/well-behaved
package.

> 
> > 
> > > If sysadmin manually enables dumps, he may do this at a location of
> > > his own choice.
> > 
> > Note that we've just swapped hats: you're arguing for letting a local
> > admin log in and mess with system configuration, and I'm for keeping
> > a
> > centralized feature for storing and collecting core dumps.
> 
> As problems like crashes are investigated per case and reproduction scenario.
> But again, I may be wrong and we should have VDSM API command to start/stop storing dumps and manage this via its master...

-- 
Adam Litke <agl at us.ibm.com>
IBM Linux Technology Center



From rnori at redhat.com  Wed Nov 28 23:55:50 2012
From: rnori at redhat.com (Ravi Nori)
Date: Wed, 28 Nov 2012 18:55:50 -0500
Subject: [Engine-devel] Error running virt-v2v on Fedora 17
Message-ID: <50B6A486.3050307@redhat.com>

I am getting an error when converting a QEMU/KVM VM to run on ovirt.

I am running everything on fedora 17 and virt-v2v version is 0.8.8 from 
rpm virt-v2v-0.8.8-1.fc17.x86_64

How would I resolve this error?

Thanks

Ravi

virt-v2v -o rhev -os vdsm.rnori.com:/export --network ovirtmgmt v2Fed
v2vFed.img: 100% 
[==========================================================================================================]D 
0h03m38s
Use of uninitialized value $grub_conf in string eq at 
/usr/share/perl5/vendor_perl/Sys/VirtConvert/Converter/RedHat.pm line 220.
Use of uninitialized value $grub_conf in string eq at 
/usr/share/perl5/vendor_perl/Sys/VirtConvert/Converter/RedHat.pm line 220.
Use of uninitialized value in subroutine entry at 
/usr/share/perl5/vendor_perl/Sys/VirtConvert/GuestfsHandle.pm line 200.
Use of uninitialized value $grub_conf in concatenation (.) or string at 
/usr/share/perl5/vendor_perl/Sys/VirtConvert/Converter/RedHat.pm line 580.
Use of uninitialized value $grub_conf in concatenation (.) or string at 
/usr/share/perl5/vendor_perl/Sys/VirtConvert/Converter/RedHat.pm line 651.
Use of uninitialized value $grub_conf in concatenation (.) or string at 
/usr/share/perl5/vendor_perl/Sys/VirtConvert/Converter/RedHat.pm line 501.
Use of uninitialized value $grub_conf in concatenation (.) or string at 
/usr/share/perl5/vendor_perl/Sys/VirtConvert/Converter/RedHat.pm line 513.
virtio configured, but no virtio kernel found at 
/usr/share/perl5/vendor_perl/Sys/VirtConvert/Converter/RedHat.pm line 790.



From iheim at redhat.com  Thu Nov 29 00:33:50 2012
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 28 Nov 2012 19:33:50 -0500
Subject: [Engine-devel] Error running virt-v2v on Fedora 17
In-Reply-To: <50B6A486.3050307@redhat.com>
References: <50B6A486.3050307@redhat.com>
Message-ID: <50B6AD6E.60702@redhat.com>

On 11/28/2012 06:55 PM, Ravi Nori wrote:
> I am getting an error when converting a QEMU/KVM VM to run on ovirt.
>
> I am running everything on fedora 17 and virt-v2v version is 0.8.8 from
> rpm virt-v2v-0.8.8-1.fc17.x86_64
>
> How would I resolve this error?
>
> Thanks
>
> Ravi
>
> virt-v2v -o rhev -os vdsm.rnori.com:/export --network ovirtmgmt v2Fed
> v2vFed.img: 100%
> [==========================================================================================================]D
> 0h03m38s
> Use of uninitialized value $grub_conf in string eq at
> /usr/share/perl5/vendor_perl/Sys/VirtConvert/Converter/RedHat.pm line 220.
> Use of uninitialized value $grub_conf in string eq at
> /usr/share/perl5/vendor_perl/Sys/VirtConvert/Converter/RedHat.pm line 220.
> Use of uninitialized value in subroutine entry at
> /usr/share/perl5/vendor_perl/Sys/VirtConvert/GuestfsHandle.pm line 200.
> Use of uninitialized value $grub_conf in concatenation (.) or string at
> /usr/share/perl5/vendor_perl/Sys/VirtConvert/Converter/RedHat.pm line 580.
> Use of uninitialized value $grub_conf in concatenation (.) or string at
> /usr/share/perl5/vendor_perl/Sys/VirtConvert/Converter/RedHat.pm line 651.
> Use of uninitialized value $grub_conf in concatenation (.) or string at
> /usr/share/perl5/vendor_perl/Sys/VirtConvert/Converter/RedHat.pm line 501.
> Use of uninitialized value $grub_conf in concatenation (.) or string at
> /usr/share/perl5/vendor_perl/Sys/VirtConvert/Converter/RedHat.pm line 513.
> virtio configured, but no virtio kernel found at
> /usr/share/perl5/vendor_perl/Sys/VirtConvert/Converter/RedHat.pm line 790.
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel

cc-ing matt



From danken at redhat.com  Thu Nov 29 08:00:12 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Thu, 29 Nov 2012 10:00:12 +0200
Subject: [Engine-devel] [vdsm] [ATTENTION] vdsm-bootstrap/host
	deployment (pre-3.2)
In-Reply-To: <20121128212935.GN13692@aglitke>
References: <20121128203942.GE9825@redhat.com>
	<598638595.2117367.1354135528311.JavaMail.root@redhat.com>
	<20121128212935.GN13692@aglitke>
Message-ID: <20121129080012.GW5083@redhat.com>

On Wed, Nov 28, 2012 at 03:29:35PM -0600, Adam Litke wrote:
> On Wed, Nov 28, 2012 at 03:45:28PM -0500, Alon Bar-Lev wrote:
> > 
> > 
> > ----- Original Message -----
> > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > Cc: "VDSM Project Development" <vdsm-devel at lists.fedorahosted.org>, "engine-devel" <engine-devel at ovirt.org>, "users"
> > > <users at ovirt.org>
> > > Sent: Wednesday, November 28, 2012 10:39:42 PM
> > > Subject: Re: [vdsm] [ATTENTION] vdsm-bootstrap/host deployment (pre-3.2)
> > > 
> > > On Wed, Nov 28, 2012 at 02:57:17PM -0500, Alon Bar-Lev wrote:
> > > > 
> > > > > > No... we need it as compatibility with older engines...
> > > > > > We keep minimum changes there for legacy, until end-of-life.
> > > > > 
> > > > > Is there an EoL statement for oVirt-3.1?
> > > > > We can make sure that oVirt-3.2's vdsm installs properly with
> > > > > ovirt-3.1's vdsm-bootstrap, or even require that Engine must be
> > > > > upgraded
> > > > > to ovirt-3.2 before upgrading any of the hosts. Is it too harsh
> > > > > to
> > > > > our
> > > > > vast install base?  users at ovirt.org, please chime in!
> > > > >
> > > > 
> > > > I tried to find such, but the more I dig I find that we need to
> > > > support old legacy.
> > > 
> > > Why, exactly? Fedora gives no such guarntees (heck, I'm stuck with an
> > > unupgradable F16). Should we be any better than our (currently
> > > single)
> > > platform?
> > 
> > We should start and detach from specific distro procedures.
> > 
> > > 
> > > > > > > > 
> > > > > > > >  * legacy-removed: change machine width core file
> > > > > > > >   # echo /var/lib/vdsm/core > /proc/sys/kernel/core_pattern
> > > > > > > 
> > > > > > > Yeah, qemu-kvm and libvirtd are much more stable than in the
> > > > > > > old
> > > > > > > days,
> > > > > > > but wouldn't we want to keep a means to collect the corpses
> > > > > > > of
> > > > > > > dead
> > > > > > > processes from hypervisors? It has helped us nail down nasty
> > > > > > > bugs,
> > > > > > > even
> > > > > > > in Python.
> > > > > > 
> > > > > > It does not mean it should be at /var/lib/vdsm ... :)
> > > > > 
> > > > > I don't get the joke :-(. If you mind the location, we can think
> > > > > of
> > > > > somewhere else to put the core dumps. Would it be hard to
> > > > > reinstate a
> > > > > parallel feature in otopi?
> > > > 
> > > > I usually do not make any jokes...
> > > > A global system setting should not go into package specific
> > > > location.
> > > > Usually core dumps are off by default, I like this approach as
> > > > unattended system may fast consume all disk space because of
> > > > dumps.
> > > 
> > > If a host fills up with dumps so quickly, it's a sign that it should
> > > not
> > > be used for production, and that someone should look into the cores.
> > > (P.S. we have a logrotate rule for them in vdsm)
> > 
> > There should be a vdsm-debug-aids (or similar) to perform such changes.
> > Again, I don't think vdsm should (by default) modify any system width parameter such as this.
> > But I will happy to hear more views.
> 
> I agree with your statement above that a single package should not override a
> global system setting.  We should really work to remove as many of these from
> vdsm as we possibly can.  It will help to make vdsm a much safer/well-behaved
> package.

I'm fine with dropping these from vdsm, but I think they are good for
ovirt - we would like to (be able to) enfornce policy on our nodes.

If configuring core dumps is removed from vdsm, it should go somewhere
else, or our log-collector users would miss their beloved dumps.

Dan.


From jhernand at redhat.com  Thu Nov 29 08:19:31 2012
From: jhernand at redhat.com (Juan Hernandez)
Date: Thu, 29 Nov 2012 09:19:31 +0100
Subject: [Engine-devel] Shipping settings.xml in oVirt engine's git repo
 (was RE: maven settings.xml in building ovirt engine wiki)
In-Reply-To: <50B6545F.6090900@redhat.com>
References: <168159614.7093451.1354092657228.JavaMail.root@redhat.com>
	<50B5D193.2070003@redhat.com> <50B5DF3A.8070103@redhat.com>
	<50B5FC3C.6010302@redhat.com> <50B60478.4000707@redhat.com>
	<50B646B6.3010404@redhat.com> <50B6545F.6090900@redhat.com>
Message-ID: <50B71A93.5050003@redhat.com>

On 11/28/2012 07:13 PM, Itamar Heim wrote:
> On 11/28/2012 12:15 PM, Juan Hernandez wrote:
>> On 11/28/2012 01:32 PM, Juan Hernandez wrote:
>>> On 11/28/2012 12:57 PM, Itamar Heim wrote:
>>>> On 11/28/2012 04:54 AM, Juan Hernandez wrote:
>>>>> On 11/28/2012 09:55 AM, Itamar Heim wrote:
>>>>>> On 11/28/2012 03:50 AM, Allon Mureinik wrote:
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
>>>>>>>> To: "Allon Mureinik" <amureini at redhat.com>
>>>>>>>> Cc: engine-devel at ovirt.org
>>>>>>>> Sent: Wednesday, November 28, 2012 10:14:02 AM
>>>>>>>> Subject: Re: [Engine-devel] Shipping settings.xml in oVirt engine's git repo (was RE: maven settings.xml in building
>>>>>>>> ovirt engine wiki)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Allon Mureinik" <amureini at redhat.com>
>>>>>>>>> To: engine-devel at ovirt.org
>>>>>>>>> Sent: Wednesday, November 28, 2012 10:05:18 AM
>>>>>>>>> Subject: [Engine-devel] Shipping settings.xml in oVirt engine's git
>>>>>>>>> repo (was RE: maven settings.xml in building
>>>>>>>>> ovirt engine wiki)
>>>>>>>>>
>>>>>>>>> <snipped>
>>>>>>>>>> Note that settings.xml isn't shifted with ovirt-engine, nor
>>>>>>>>>> stored
>>>>>>>>>> on
>>>>>>>>>> ovirt-engine git repository. Therefore there is no real method to
>>>>>>>>>> control its content expect updating the wiki page.
>>>>>>>>>
>>>>>>>>> Spinning off from the previous discussion - we can't really control
>>>>>>>>> the contents of settings.xml, but perhaps we can make them easier
>>>>>>>>> to
>>>>>>>>> get.
>>>>>>>>>
>>>>>>>>> Today, the flow is like this:
>>>>>>>>> 1. git clone - depends on gerrit.ovirt.org
>>>>>>>>> 2. wget settings.xml - depends on wiki.ovirt.org
>>>>>>>>>
>>>>>>>>> Suppose we ship settings.xml inside the configuration folder of
>>>>>>>>> ovirt
>>>>>>>>> (next to engine-code-format.xml and engine-commit-template.txt).
>>>>>>>>> Then you'll have to do:
>>>>>>>>> 1. git clone - depends on gerrit.ovirt.org
>>>>>>>>> 2. cp $OVIRT_GIT/config/settings.xml ~/.m2/
>>>>>>>>>
>>>>>>>>> This may a bit simpler, and at the very least, when we update our
>>>>>>>>> code (e.g., to assume java7, *hint*), we can make all the changes
>>>>>>>>> in
>>>>>>>>> a single commit, and not have to update the code and then upload a
>>>>>>>>> file to the wiki.
>>>>>>>>>
>>>>>>>>> Comments? Feedback?
>>>>>>>>
>>>>>>>> First thing... I don't like changing global state of a machine only
>>>>>>>> because we require some setting...
>>>>>>>>
>>>>>>>> So copying <ANYTHING> to ~/.m2 is completely wrong in my opinion.
>>>>>>>>
>>>>>>>> There is -gs parameter for maven to specify alternate settings file,
>>>>>>>> I strongly recommend people use it.
>>>>>>>>
>>>>>>>> Also, as far as I understand we only need some attributes defined...
>>>>>>>> It is simple to use:
>>>>>>>>
>>>>>>>> $ export MAVEN_OPTS="-Dwhatever=value -Dwhatever=value"
>>>>>>>>
>>>>>>>> Before executing eclipse or make...
>>>>>>>>
>>>>>>>> We can also integrate the environment variables idea into the maven
>>>>>>>> build, instead of using properties use environment variables... then
>>>>>>>> before executing build we:
>>>>>>>>
>>>>>>>> $ export JBOSS_HOME=
>>>>>>>> $ export OVIRT_JDK_HOME= (optional)
>>>>>>>>
>>>>>>>> If anyone prefers/chooses to use settings.xml he can create his
>>>>>>>> own...
>>>>>>>>
>>>>>>>> So there are so many options, the last option is to use settings.xml
>>>>>>>> in my opinion... not that I against adding this template, but I
>>>>>>>> first suggest we consider removing its usage completely.... :)
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Alon
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -Allon
>>>>>>>
>>>>>>> I'll rephrase.
>>>>>>> /today/ we provide an example of settings.xml in "Building the oVirt Engine" wiki page.
>>>>>>> People who understand maven will not overwrite their settings.xml with it, and people who don't have a comfortable quick start.
>>>>>>>
>>>>>>> I propose to supply this /exmaple/ in a more accessible place $OVIRT_GIT/config.
>>>>>>> People who didn't overwrite their existing .m2 file still won't, and people who did have an easier way of doing it.
>>>>>>
>>>>>> i agree having the sample in the git will make it simpler, and we must
>>>>>> make it simpler (juan is working on cleaning up the 'setup devel' flow).
>>>>>
>>>>> I am not against having that example in the git repository. But I don't
>>>>> see how that is going to make life easier for newcomers. We will have to
>>>>> instruct them (in the wiki) how to find the file instead of instructing
>>>>> them how to create it, not much difference.
>>>>
>>>> if we tell them to:
>>>> yum install X Y Z
>>>> git clone ...
>>>> cd ovirt-engine
>>>> mvn clean install --settings settings.xml
>>>>
>>>> it should just work, unless i am missing something?
>>>
>>> Yes, should work, but then we need to include this "--settings
>>> $HOME/ovirt-engine/settings.xml" in all the example commands in the
>>> wiki. It doesn't make things simpler.
>>>
>>>>
>>>>>
>>>>>>
>>>>>> for simplicity, please lets also assume the would be developer also
>>>>>> isn't intimate with eclipse/jboss, so default in the file should work
>>>>>> with someone doing:
>>>>>> yum install eclipse jbossas
>>>>>>
>>>>>
>>>>> Unfortunately using "yum install jbossas" is not an option currently, as
>>>>> that requires the developer to use root, which causes a lot of trouble.
>>>>
>>>> any way to solve this?
>>>
>>> The easy solution is to use the .zip distribution, which works in any
>>> distribution.
>>>
>>> For the future, in my opinion, we should move towards a model where the
>>> development environment is much more similar to the production
>>> environment than what we have now. The build system should be able to
>>> install the complete engine to a directory under the developer home
>>> directory, with the same file system structure that we use in production
>>> environments. Then the developer should be able to start/stop the engine
>>> (and tools) using the same scripts that we use in production
>>> environments. These scripts don't need write access to the jboss-as
>>> installation directories, so as a side effect they solve this problem.
>>>
>>>>
>>>>> We have to instruct new developers to download the JBoss .zip file and
>>>>> uncompress it somewhere, easiest is the developer's home directory. This
>>>>> has the advantage that it also works in distributions that haven't
>>>>> packaged JBoss yet.
>>>>>
>>>>> Using "yum install eclipse" also has its drawbacks, as the version of
>>>>> eclipse in Fedora doesn't include the maven plugin.
>>>>>
>>>>
>>>> isn't the maven plugin just another rpm?
>>>>
>>>
>>> No, the maven plugin is not yet packaged for fedora:
>>>
>>> https://bugzilla.redhat.com/814245
>>>
>>> It can be installed manually as described in the wiki, and then it
>>> should work (it doesn't in Fedora 18 as far as I can tell).
>>>
>>> I would rather suggest using a lighter alternative, like including
>>> working .project and .classpath files in the repository (I can foresee a
>>> lot of people cursing me for proposing this) or generating them using
>>> the maven eclipse plugin (see [1], don't confuse it with m2e [2]).
>>>
>>> [1] http://maven.apache.org/plugins/maven-eclipse-plugin
>>> [2] http://eclipse.org/m2e
>>>
>>
>> I just submitted a change to add a new eclipse.py script that creates
>> the Eclipse project files automatically:
>>
>> http://gerrit.ovirt.org/9556
>>
>> If this is accepted I can update the wiki add instructions on how to use it.
>>
>> Of course those that prefer it can continue using m2e, this is just a
>> lighter and simpler alternative, specially for environments where m2e is
>> not available out of the box.
>>
> 
> I'm pretty sure i saw some negative feelings about eclipse project files 
> vs. using m2e.
> do we know what the gap the m2e plugin has to get into fedora?
> 

The gap is that it needs someone willing to package it.

-- 
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 iheim at redhat.com  Thu Nov 29 09:16:02 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 29 Nov 2012 04:16:02 -0500
Subject: [Engine-devel] Shipping settings.xml in oVirt engine's git repo
 (was RE: maven settings.xml in building ovirt engine wiki)
In-Reply-To: <50B71A93.5050003@redhat.com>
References: <168159614.7093451.1354092657228.JavaMail.root@redhat.com>
	<50B5D193.2070003@redhat.com> <50B5DF3A.8070103@redhat.com>
	<50B5FC3C.6010302@redhat.com> <50B60478.4000707@redhat.com>
	<50B646B6.3010404@redhat.com> <50B6545F.6090900@redhat.com>
	<50B71A93.5050003@redhat.com>
Message-ID: <50B727D2.4090805@redhat.com>

On 11/29/2012 03:19 AM, Juan Hernandez wrote:
> On 11/28/2012 07:13 PM, Itamar Heim wrote:
>> On 11/28/2012 12:15 PM, Juan Hernandez wrote:
>>> On 11/28/2012 01:32 PM, Juan Hernandez wrote:
>>>> On 11/28/2012 12:57 PM, Itamar Heim wrote:
>>>>> On 11/28/2012 04:54 AM, Juan Hernandez wrote:
>>>>>> On 11/28/2012 09:55 AM, Itamar Heim wrote:
>>>>>>> On 11/28/2012 03:50 AM, Allon Mureinik wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
>>>>>>>>> To: "Allon Mureinik" <amureini at redhat.com>
>>>>>>>>> Cc: engine-devel at ovirt.org
>>>>>>>>> Sent: Wednesday, November 28, 2012 10:14:02 AM
>>>>>>>>> Subject: Re: [Engine-devel] Shipping settings.xml in oVirt engine's git repo (was RE: maven settings.xml in building
>>>>>>>>> ovirt engine wiki)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ----- Original Message -----
>>>>>>>>>> From: "Allon Mureinik" <amureini at redhat.com>
>>>>>>>>>> To: engine-devel at ovirt.org
>>>>>>>>>> Sent: Wednesday, November 28, 2012 10:05:18 AM
>>>>>>>>>> Subject: [Engine-devel] Shipping settings.xml in oVirt engine's git
>>>>>>>>>> repo (was RE: maven settings.xml in building
>>>>>>>>>> ovirt engine wiki)
>>>>>>>>>>
>>>>>>>>>> <snipped>
>>>>>>>>>>> Note that settings.xml isn't shifted with ovirt-engine, nor
>>>>>>>>>>> stored
>>>>>>>>>>> on
>>>>>>>>>>> ovirt-engine git repository. Therefore there is no real method to
>>>>>>>>>>> control its content expect updating the wiki page.
>>>>>>>>>>
>>>>>>>>>> Spinning off from the previous discussion - we can't really control
>>>>>>>>>> the contents of settings.xml, but perhaps we can make them easier
>>>>>>>>>> to
>>>>>>>>>> get.
>>>>>>>>>>
>>>>>>>>>> Today, the flow is like this:
>>>>>>>>>> 1. git clone - depends on gerrit.ovirt.org
>>>>>>>>>> 2. wget settings.xml - depends on wiki.ovirt.org
>>>>>>>>>>
>>>>>>>>>> Suppose we ship settings.xml inside the configuration folder of
>>>>>>>>>> ovirt
>>>>>>>>>> (next to engine-code-format.xml and engine-commit-template.txt).
>>>>>>>>>> Then you'll have to do:
>>>>>>>>>> 1. git clone - depends on gerrit.ovirt.org
>>>>>>>>>> 2. cp $OVIRT_GIT/config/settings.xml ~/.m2/
>>>>>>>>>>
>>>>>>>>>> This may a bit simpler, and at the very least, when we update our
>>>>>>>>>> code (e.g., to assume java7, *hint*), we can make all the changes
>>>>>>>>>> in
>>>>>>>>>> a single commit, and not have to update the code and then upload a
>>>>>>>>>> file to the wiki.
>>>>>>>>>>
>>>>>>>>>> Comments? Feedback?
>>>>>>>>>
>>>>>>>>> First thing... I don't like changing global state of a machine only
>>>>>>>>> because we require some setting...
>>>>>>>>>
>>>>>>>>> So copying <ANYTHING> to ~/.m2 is completely wrong in my opinion.
>>>>>>>>>
>>>>>>>>> There is -gs parameter for maven to specify alternate settings file,
>>>>>>>>> I strongly recommend people use it.
>>>>>>>>>
>>>>>>>>> Also, as far as I understand we only need some attributes defined...
>>>>>>>>> It is simple to use:
>>>>>>>>>
>>>>>>>>> $ export MAVEN_OPTS="-Dwhatever=value -Dwhatever=value"
>>>>>>>>>
>>>>>>>>> Before executing eclipse or make...
>>>>>>>>>
>>>>>>>>> We can also integrate the environment variables idea into the maven
>>>>>>>>> build, instead of using properties use environment variables... then
>>>>>>>>> before executing build we:
>>>>>>>>>
>>>>>>>>> $ export JBOSS_HOME=
>>>>>>>>> $ export OVIRT_JDK_HOME= (optional)
>>>>>>>>>
>>>>>>>>> If anyone prefers/chooses to use settings.xml he can create his
>>>>>>>>> own...
>>>>>>>>>
>>>>>>>>> So there are so many options, the last option is to use settings.xml
>>>>>>>>> in my opinion... not that I against adding this template, but I
>>>>>>>>> first suggest we consider removing its usage completely.... :)
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Alon
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -Allon
>>>>>>>>
>>>>>>>> I'll rephrase.
>>>>>>>> /today/ we provide an example of settings.xml in "Building the oVirt Engine" wiki page.
>>>>>>>> People who understand maven will not overwrite their settings.xml with it, and people who don't have a comfortable quick start.
>>>>>>>>
>>>>>>>> I propose to supply this /exmaple/ in a more accessible place $OVIRT_GIT/config.
>>>>>>>> People who didn't overwrite their existing .m2 file still won't, and people who did have an easier way of doing it.
>>>>>>>
>>>>>>> i agree having the sample in the git will make it simpler, and we must
>>>>>>> make it simpler (juan is working on cleaning up the 'setup devel' flow).
>>>>>>
>>>>>> I am not against having that example in the git repository. But I don't
>>>>>> see how that is going to make life easier for newcomers. We will have to
>>>>>> instruct them (in the wiki) how to find the file instead of instructing
>>>>>> them how to create it, not much difference.
>>>>>
>>>>> if we tell them to:
>>>>> yum install X Y Z
>>>>> git clone ...
>>>>> cd ovirt-engine
>>>>> mvn clean install --settings settings.xml
>>>>>
>>>>> it should just work, unless i am missing something?
>>>>
>>>> Yes, should work, but then we need to include this "--settings
>>>> $HOME/ovirt-engine/settings.xml" in all the example commands in the
>>>> wiki. It doesn't make things simpler.
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>> for simplicity, please lets also assume the would be developer also
>>>>>>> isn't intimate with eclipse/jboss, so default in the file should work
>>>>>>> with someone doing:
>>>>>>> yum install eclipse jbossas
>>>>>>>
>>>>>>
>>>>>> Unfortunately using "yum install jbossas" is not an option currently, as
>>>>>> that requires the developer to use root, which causes a lot of trouble.
>>>>>
>>>>> any way to solve this?
>>>>
>>>> The easy solution is to use the .zip distribution, which works in any
>>>> distribution.
>>>>
>>>> For the future, in my opinion, we should move towards a model where the
>>>> development environment is much more similar to the production
>>>> environment than what we have now. The build system should be able to
>>>> install the complete engine to a directory under the developer home
>>>> directory, with the same file system structure that we use in production
>>>> environments. Then the developer should be able to start/stop the engine
>>>> (and tools) using the same scripts that we use in production
>>>> environments. These scripts don't need write access to the jboss-as
>>>> installation directories, so as a side effect they solve this problem.
>>>>
>>>>>
>>>>>> We have to instruct new developers to download the JBoss .zip file and
>>>>>> uncompress it somewhere, easiest is the developer's home directory. This
>>>>>> has the advantage that it also works in distributions that haven't
>>>>>> packaged JBoss yet.
>>>>>>
>>>>>> Using "yum install eclipse" also has its drawbacks, as the version of
>>>>>> eclipse in Fedora doesn't include the maven plugin.
>>>>>>
>>>>>
>>>>> isn't the maven plugin just another rpm?
>>>>>
>>>>
>>>> No, the maven plugin is not yet packaged for fedora:
>>>>
>>>> https://bugzilla.redhat.com/814245
>>>>
>>>> It can be installed manually as described in the wiki, and then it
>>>> should work (it doesn't in Fedora 18 as far as I can tell).
>>>>
>>>> I would rather suggest using a lighter alternative, like including
>>>> working .project and .classpath files in the repository (I can foresee a
>>>> lot of people cursing me for proposing this) or generating them using
>>>> the maven eclipse plugin (see [1], don't confuse it with m2e [2]).
>>>>
>>>> [1] http://maven.apache.org/plugins/maven-eclipse-plugin
>>>> [2] http://eclipse.org/m2e
>>>>
>>>
>>> I just submitted a change to add a new eclipse.py script that creates
>>> the Eclipse project files automatically:
>>>
>>> http://gerrit.ovirt.org/9556
>>>
>>> If this is accepted I can update the wiki add instructions on how to use it.
>>>
>>> Of course those that prefer it can continue using m2e, this is just a
>>> lighter and simpler alternative, specially for environments where m2e is
>>> not available out of the box.
>>>
>>
>> I'm pretty sure i saw some negative feelings about eclipse project files
>> vs. using m2e.
>> do we know what the gap the m2e plugin has to get into fedora?
>>
>
> The gap is that it needs someone willing to package it.
>

doesn't it only need a reviewer (hopefully the packager is still willing 
to push this from his side)
Bug 847160 - Review Request: eclipse-m2e-core - Maven integration for 
Eclipse

(we can also consider hosting it as an interim in ovirt repo)


From jhernand at redhat.com  Thu Nov 29 09:29:00 2012
From: jhernand at redhat.com (Juan Hernandez)
Date: Thu, 29 Nov 2012 10:29:00 +0100
Subject: [Engine-devel] Shipping settings.xml in oVirt engine's git repo
 (was RE: maven settings.xml in building ovirt engine wiki)
In-Reply-To: <50B727D2.4090805@redhat.com>
References: <168159614.7093451.1354092657228.JavaMail.root@redhat.com>
	<50B5D193.2070003@redhat.com> <50B5DF3A.8070103@redhat.com>
	<50B5FC3C.6010302@redhat.com> <50B60478.4000707@redhat.com>
	<50B646B6.3010404@redhat.com> <50B6545F.6090900@redhat.com>
	<50B71A93.5050003@redhat.com> <50B727D2.4090805@redhat.com>
Message-ID: <50B72ADC.80304@redhat.com>

On 11/29/2012 10:16 AM, Itamar Heim wrote:
> On 11/29/2012 03:19 AM, Juan Hernandez wrote:
>> On 11/28/2012 07:13 PM, Itamar Heim wrote:
>>> On 11/28/2012 12:15 PM, Juan Hernandez wrote:
>>>> On 11/28/2012 01:32 PM, Juan Hernandez wrote:
>>>>> On 11/28/2012 12:57 PM, Itamar Heim wrote:
>>>>>> On 11/28/2012 04:54 AM, Juan Hernandez wrote:
>>>>>>> On 11/28/2012 09:55 AM, Itamar Heim wrote:
>>>>>>>> On 11/28/2012 03:50 AM, Allon Mureinik wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ----- Original Message -----
>>>>>>>>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
>>>>>>>>>> To: "Allon Mureinik" <amureini at redhat.com>
>>>>>>>>>> Cc: engine-devel at ovirt.org
>>>>>>>>>> Sent: Wednesday, November 28, 2012 10:14:02 AM
>>>>>>>>>> Subject: Re: [Engine-devel] Shipping settings.xml in oVirt engine's git repo (was RE: maven settings.xml in building
>>>>>>>>>> ovirt engine wiki)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>> From: "Allon Mureinik" <amureini at redhat.com>
>>>>>>>>>>> To: engine-devel at ovirt.org
>>>>>>>>>>> Sent: Wednesday, November 28, 2012 10:05:18 AM
>>>>>>>>>>> Subject: [Engine-devel] Shipping settings.xml in oVirt engine's git
>>>>>>>>>>> repo (was RE: maven settings.xml in building
>>>>>>>>>>> ovirt engine wiki)
>>>>>>>>>>>
>>>>>>>>>>> <snipped>
>>>>>>>>>>>> Note that settings.xml isn't shifted with ovirt-engine, nor
>>>>>>>>>>>> stored
>>>>>>>>>>>> on
>>>>>>>>>>>> ovirt-engine git repository. Therefore there is no real method to
>>>>>>>>>>>> control its content expect updating the wiki page.
>>>>>>>>>>>
>>>>>>>>>>> Spinning off from the previous discussion - we can't really control
>>>>>>>>>>> the contents of settings.xml, but perhaps we can make them easier
>>>>>>>>>>> to
>>>>>>>>>>> get.
>>>>>>>>>>>
>>>>>>>>>>> Today, the flow is like this:
>>>>>>>>>>> 1. git clone - depends on gerrit.ovirt.org
>>>>>>>>>>> 2. wget settings.xml - depends on wiki.ovirt.org
>>>>>>>>>>>
>>>>>>>>>>> Suppose we ship settings.xml inside the configuration folder of
>>>>>>>>>>> ovirt
>>>>>>>>>>> (next to engine-code-format.xml and engine-commit-template.txt).
>>>>>>>>>>> Then you'll have to do:
>>>>>>>>>>> 1. git clone - depends on gerrit.ovirt.org
>>>>>>>>>>> 2. cp $OVIRT_GIT/config/settings.xml ~/.m2/
>>>>>>>>>>>
>>>>>>>>>>> This may a bit simpler, and at the very least, when we update our
>>>>>>>>>>> code (e.g., to assume java7, *hint*), we can make all the changes
>>>>>>>>>>> in
>>>>>>>>>>> a single commit, and not have to update the code and then upload a
>>>>>>>>>>> file to the wiki.
>>>>>>>>>>>
>>>>>>>>>>> Comments? Feedback?
>>>>>>>>>>
>>>>>>>>>> First thing... I don't like changing global state of a machine only
>>>>>>>>>> because we require some setting...
>>>>>>>>>>
>>>>>>>>>> So copying <ANYTHING> to ~/.m2 is completely wrong in my opinion.
>>>>>>>>>>
>>>>>>>>>> There is -gs parameter for maven to specify alternate settings file,
>>>>>>>>>> I strongly recommend people use it.
>>>>>>>>>>
>>>>>>>>>> Also, as far as I understand we only need some attributes defined...
>>>>>>>>>> It is simple to use:
>>>>>>>>>>
>>>>>>>>>> $ export MAVEN_OPTS="-Dwhatever=value -Dwhatever=value"
>>>>>>>>>>
>>>>>>>>>> Before executing eclipse or make...
>>>>>>>>>>
>>>>>>>>>> We can also integrate the environment variables idea into the maven
>>>>>>>>>> build, instead of using properties use environment variables... then
>>>>>>>>>> before executing build we:
>>>>>>>>>>
>>>>>>>>>> $ export JBOSS_HOME=
>>>>>>>>>> $ export OVIRT_JDK_HOME= (optional)
>>>>>>>>>>
>>>>>>>>>> If anyone prefers/chooses to use settings.xml he can create his
>>>>>>>>>> own...
>>>>>>>>>>
>>>>>>>>>> So there are so many options, the last option is to use settings.xml
>>>>>>>>>> in my opinion... not that I against adding this template, but I
>>>>>>>>>> first suggest we consider removing its usage completely.... :)
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Alon
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -Allon
>>>>>>>>>
>>>>>>>>> I'll rephrase.
>>>>>>>>> /today/ we provide an example of settings.xml in "Building the oVirt Engine" wiki page.
>>>>>>>>> People who understand maven will not overwrite their settings.xml with it, and people who don't have a comfortable quick start.
>>>>>>>>>
>>>>>>>>> I propose to supply this /exmaple/ in a more accessible place $OVIRT_GIT/config.
>>>>>>>>> People who didn't overwrite their existing .m2 file still won't, and people who did have an easier way of doing it.
>>>>>>>>
>>>>>>>> i agree having the sample in the git will make it simpler, and we must
>>>>>>>> make it simpler (juan is working on cleaning up the 'setup devel' flow).
>>>>>>>
>>>>>>> I am not against having that example in the git repository. But I don't
>>>>>>> see how that is going to make life easier for newcomers. We will have to
>>>>>>> instruct them (in the wiki) how to find the file instead of instructing
>>>>>>> them how to create it, not much difference.
>>>>>>
>>>>>> if we tell them to:
>>>>>> yum install X Y Z
>>>>>> git clone ...
>>>>>> cd ovirt-engine
>>>>>> mvn clean install --settings settings.xml
>>>>>>
>>>>>> it should just work, unless i am missing something?
>>>>>
>>>>> Yes, should work, but then we need to include this "--settings
>>>>> $HOME/ovirt-engine/settings.xml" in all the example commands in the
>>>>> wiki. It doesn't make things simpler.
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> for simplicity, please lets also assume the would be developer also
>>>>>>>> isn't intimate with eclipse/jboss, so default in the file should work
>>>>>>>> with someone doing:
>>>>>>>> yum install eclipse jbossas
>>>>>>>>
>>>>>>>
>>>>>>> Unfortunately using "yum install jbossas" is not an option currently, as
>>>>>>> that requires the developer to use root, which causes a lot of trouble.
>>>>>>
>>>>>> any way to solve this?
>>>>>
>>>>> The easy solution is to use the .zip distribution, which works in any
>>>>> distribution.
>>>>>
>>>>> For the future, in my opinion, we should move towards a model where the
>>>>> development environment is much more similar to the production
>>>>> environment than what we have now. The build system should be able to
>>>>> install the complete engine to a directory under the developer home
>>>>> directory, with the same file system structure that we use in production
>>>>> environments. Then the developer should be able to start/stop the engine
>>>>> (and tools) using the same scripts that we use in production
>>>>> environments. These scripts don't need write access to the jboss-as
>>>>> installation directories, so as a side effect they solve this problem.
>>>>>
>>>>>>
>>>>>>> We have to instruct new developers to download the JBoss .zip file and
>>>>>>> uncompress it somewhere, easiest is the developer's home directory. This
>>>>>>> has the advantage that it also works in distributions that haven't
>>>>>>> packaged JBoss yet.
>>>>>>>
>>>>>>> Using "yum install eclipse" also has its drawbacks, as the version of
>>>>>>> eclipse in Fedora doesn't include the maven plugin.
>>>>>>>
>>>>>>
>>>>>> isn't the maven plugin just another rpm?
>>>>>>
>>>>>
>>>>> No, the maven plugin is not yet packaged for fedora:
>>>>>
>>>>> https://bugzilla.redhat.com/814245
>>>>>
>>>>> It can be installed manually as described in the wiki, and then it
>>>>> should work (it doesn't in Fedora 18 as far as I can tell).
>>>>>
>>>>> I would rather suggest using a lighter alternative, like including
>>>>> working .project and .classpath files in the repository (I can foresee a
>>>>> lot of people cursing me for proposing this) or generating them using
>>>>> the maven eclipse plugin (see [1], don't confuse it with m2e [2]).
>>>>>
>>>>> [1] http://maven.apache.org/plugins/maven-eclipse-plugin
>>>>> [2] http://eclipse.org/m2e
>>>>>
>>>>
>>>> I just submitted a change to add a new eclipse.py script that creates
>>>> the Eclipse project files automatically:
>>>>
>>>> http://gerrit.ovirt.org/9556
>>>>
>>>> If this is accepted I can update the wiki add instructions on how to use it.
>>>>
>>>> Of course those that prefer it can continue using m2e, this is just a
>>>> lighter and simpler alternative, specially for environments where m2e is
>>>> not available out of the box.
>>>>
>>>
>>> I'm pretty sure i saw some negative feelings about eclipse project files
>>> vs. using m2e.
>>> do we know what the gap the m2e plugin has to get into fedora?
>>>
>>
>> The gap is that it needs someone willing to package it.
>>
> 
> doesn't it only need a reviewer (hopefully the packager is still willing 
> to push this from his side)
> Bug 847160 - Review Request: eclipse-m2e-core - Maven integration for 
> Eclipse

It is not ready for review, as far as I can tell, it needs more work
from the packager, and looks like the current packager lost interest in
the package.

> (we can also consider hosting it as an interim in ovirt repo)

I think that is not worth, users can just install it from the
corresponding Eclipse repositories.

-- 
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 iheim at redhat.com  Thu Nov 29 09:29:56 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 29 Nov 2012 04:29:56 -0500
Subject: [Engine-devel] Shipping settings.xml in oVirt engine's git repo
 (was RE: maven settings.xml in building ovirt engine wiki)
In-Reply-To: <50B72ADC.80304@redhat.com>
References: <168159614.7093451.1354092657228.JavaMail.root@redhat.com>
	<50B5D193.2070003@redhat.com> <50B5DF3A.8070103@redhat.com>
	<50B5FC3C.6010302@redhat.com> <50B60478.4000707@redhat.com>
	<50B646B6.3010404@redhat.com> <50B6545F.6090900@redhat.com>
	<50B71A93.5050003@redhat.com> <50B727D2.4090805@redhat.com>
	<50B72ADC.80304@redhat.com>
Message-ID: <50B72B14.2070706@redhat.com>

On 11/29/2012 04:29 AM, Juan Hernandez wrote:
> On 11/29/2012 10:16 AM, Itamar Heim wrote:
>> On 11/29/2012 03:19 AM, Juan Hernandez wrote:
>>> On 11/28/2012 07:13 PM, Itamar Heim wrote:
>>>> On 11/28/2012 12:15 PM, Juan Hernandez wrote:
>>>>> On 11/28/2012 01:32 PM, Juan Hernandez wrote:
>>>>>> On 11/28/2012 12:57 PM, Itamar Heim wrote:
>>>>>>> On 11/28/2012 04:54 AM, Juan Hernandez wrote:
>>>>>>>> On 11/28/2012 09:55 AM, Itamar Heim wrote:
>>>>>>>>> On 11/28/2012 03:50 AM, Allon Mureinik wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
>>>>>>>>>>> To: "Allon Mureinik" <amureini at redhat.com>
>>>>>>>>>>> Cc: engine-devel at ovirt.org
>>>>>>>>>>> Sent: Wednesday, November 28, 2012 10:14:02 AM
>>>>>>>>>>> Subject: Re: [Engine-devel] Shipping settings.xml in oVirt engine's git repo (was RE: maven settings.xml in building
>>>>>>>>>>> ovirt engine wiki)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>>> From: "Allon Mureinik" <amureini at redhat.com>
>>>>>>>>>>>> To: engine-devel at ovirt.org
>>>>>>>>>>>> Sent: Wednesday, November 28, 2012 10:05:18 AM
>>>>>>>>>>>> Subject: [Engine-devel] Shipping settings.xml in oVirt engine's git
>>>>>>>>>>>> repo (was RE: maven settings.xml in building
>>>>>>>>>>>> ovirt engine wiki)
>>>>>>>>>>>>
>>>>>>>>>>>> <snipped>
>>>>>>>>>>>>> Note that settings.xml isn't shifted with ovirt-engine, nor
>>>>>>>>>>>>> stored
>>>>>>>>>>>>> on
>>>>>>>>>>>>> ovirt-engine git repository. Therefore there is no real method to
>>>>>>>>>>>>> control its content expect updating the wiki page.
>>>>>>>>>>>>
>>>>>>>>>>>> Spinning off from the previous discussion - we can't really control
>>>>>>>>>>>> the contents of settings.xml, but perhaps we can make them easier
>>>>>>>>>>>> to
>>>>>>>>>>>> get.
>>>>>>>>>>>>
>>>>>>>>>>>> Today, the flow is like this:
>>>>>>>>>>>> 1. git clone - depends on gerrit.ovirt.org
>>>>>>>>>>>> 2. wget settings.xml - depends on wiki.ovirt.org
>>>>>>>>>>>>
>>>>>>>>>>>> Suppose we ship settings.xml inside the configuration folder of
>>>>>>>>>>>> ovirt
>>>>>>>>>>>> (next to engine-code-format.xml and engine-commit-template.txt).
>>>>>>>>>>>> Then you'll have to do:
>>>>>>>>>>>> 1. git clone - depends on gerrit.ovirt.org
>>>>>>>>>>>> 2. cp $OVIRT_GIT/config/settings.xml ~/.m2/
>>>>>>>>>>>>
>>>>>>>>>>>> This may a bit simpler, and at the very least, when we update our
>>>>>>>>>>>> code (e.g., to assume java7, *hint*), we can make all the changes
>>>>>>>>>>>> in
>>>>>>>>>>>> a single commit, and not have to update the code and then upload a
>>>>>>>>>>>> file to the wiki.
>>>>>>>>>>>>
>>>>>>>>>>>> Comments? Feedback?
>>>>>>>>>>>
>>>>>>>>>>> First thing... I don't like changing global state of a machine only
>>>>>>>>>>> because we require some setting...
>>>>>>>>>>>
>>>>>>>>>>> So copying <ANYTHING> to ~/.m2 is completely wrong in my opinion.
>>>>>>>>>>>
>>>>>>>>>>> There is -gs parameter for maven to specify alternate settings file,
>>>>>>>>>>> I strongly recommend people use it.
>>>>>>>>>>>
>>>>>>>>>>> Also, as far as I understand we only need some attributes defined...
>>>>>>>>>>> It is simple to use:
>>>>>>>>>>>
>>>>>>>>>>> $ export MAVEN_OPTS="-Dwhatever=value -Dwhatever=value"
>>>>>>>>>>>
>>>>>>>>>>> Before executing eclipse or make...
>>>>>>>>>>>
>>>>>>>>>>> We can also integrate the environment variables idea into the maven
>>>>>>>>>>> build, instead of using properties use environment variables... then
>>>>>>>>>>> before executing build we:
>>>>>>>>>>>
>>>>>>>>>>> $ export JBOSS_HOME=
>>>>>>>>>>> $ export OVIRT_JDK_HOME= (optional)
>>>>>>>>>>>
>>>>>>>>>>> If anyone prefers/chooses to use settings.xml he can create his
>>>>>>>>>>> own...
>>>>>>>>>>>
>>>>>>>>>>> So there are so many options, the last option is to use settings.xml
>>>>>>>>>>> in my opinion... not that I against adding this template, but I
>>>>>>>>>>> first suggest we consider removing its usage completely.... :)
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Alon
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -Allon
>>>>>>>>>>
>>>>>>>>>> I'll rephrase.
>>>>>>>>>> /today/ we provide an example of settings.xml in "Building the oVirt Engine" wiki page.
>>>>>>>>>> People who understand maven will not overwrite their settings.xml with it, and people who don't have a comfortable quick start.
>>>>>>>>>>
>>>>>>>>>> I propose to supply this /exmaple/ in a more accessible place $OVIRT_GIT/config.
>>>>>>>>>> People who didn't overwrite their existing .m2 file still won't, and people who did have an easier way of doing it.
>>>>>>>>>
>>>>>>>>> i agree having the sample in the git will make it simpler, and we must
>>>>>>>>> make it simpler (juan is working on cleaning up the 'setup devel' flow).
>>>>>>>>
>>>>>>>> I am not against having that example in the git repository. But I don't
>>>>>>>> see how that is going to make life easier for newcomers. We will have to
>>>>>>>> instruct them (in the wiki) how to find the file instead of instructing
>>>>>>>> them how to create it, not much difference.
>>>>>>>
>>>>>>> if we tell them to:
>>>>>>> yum install X Y Z
>>>>>>> git clone ...
>>>>>>> cd ovirt-engine
>>>>>>> mvn clean install --settings settings.xml
>>>>>>>
>>>>>>> it should just work, unless i am missing something?
>>>>>>
>>>>>> Yes, should work, but then we need to include this "--settings
>>>>>> $HOME/ovirt-engine/settings.xml" in all the example commands in the
>>>>>> wiki. It doesn't make things simpler.
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> for simplicity, please lets also assume the would be developer also
>>>>>>>>> isn't intimate with eclipse/jboss, so default in the file should work
>>>>>>>>> with someone doing:
>>>>>>>>> yum install eclipse jbossas
>>>>>>>>>
>>>>>>>>
>>>>>>>> Unfortunately using "yum install jbossas" is not an option currently, as
>>>>>>>> that requires the developer to use root, which causes a lot of trouble.
>>>>>>>
>>>>>>> any way to solve this?
>>>>>>
>>>>>> The easy solution is to use the .zip distribution, which works in any
>>>>>> distribution.
>>>>>>
>>>>>> For the future, in my opinion, we should move towards a model where the
>>>>>> development environment is much more similar to the production
>>>>>> environment than what we have now. The build system should be able to
>>>>>> install the complete engine to a directory under the developer home
>>>>>> directory, with the same file system structure that we use in production
>>>>>> environments. Then the developer should be able to start/stop the engine
>>>>>> (and tools) using the same scripts that we use in production
>>>>>> environments. These scripts don't need write access to the jboss-as
>>>>>> installation directories, so as a side effect they solve this problem.
>>>>>>
>>>>>>>
>>>>>>>> We have to instruct new developers to download the JBoss .zip file and
>>>>>>>> uncompress it somewhere, easiest is the developer's home directory. This
>>>>>>>> has the advantage that it also works in distributions that haven't
>>>>>>>> packaged JBoss yet.
>>>>>>>>
>>>>>>>> Using "yum install eclipse" also has its drawbacks, as the version of
>>>>>>>> eclipse in Fedora doesn't include the maven plugin.
>>>>>>>>
>>>>>>>
>>>>>>> isn't the maven plugin just another rpm?
>>>>>>>
>>>>>>
>>>>>> No, the maven plugin is not yet packaged for fedora:
>>>>>>
>>>>>> https://bugzilla.redhat.com/814245
>>>>>>
>>>>>> It can be installed manually as described in the wiki, and then it
>>>>>> should work (it doesn't in Fedora 18 as far as I can tell).
>>>>>>
>>>>>> I would rather suggest using a lighter alternative, like including
>>>>>> working .project and .classpath files in the repository (I can foresee a
>>>>>> lot of people cursing me for proposing this) or generating them using
>>>>>> the maven eclipse plugin (see [1], don't confuse it with m2e [2]).
>>>>>>
>>>>>> [1] http://maven.apache.org/plugins/maven-eclipse-plugin
>>>>>> [2] http://eclipse.org/m2e
>>>>>>
>>>>>
>>>>> I just submitted a change to add a new eclipse.py script that creates
>>>>> the Eclipse project files automatically:
>>>>>
>>>>> http://gerrit.ovirt.org/9556
>>>>>
>>>>> If this is accepted I can update the wiki add instructions on how to use it.
>>>>>
>>>>> Of course those that prefer it can continue using m2e, this is just a
>>>>> lighter and simpler alternative, specially for environments where m2e is
>>>>> not available out of the box.
>>>>>
>>>>
>>>> I'm pretty sure i saw some negative feelings about eclipse project files
>>>> vs. using m2e.
>>>> do we know what the gap the m2e plugin has to get into fedora?
>>>>
>>>
>>> The gap is that it needs someone willing to package it.
>>>
>>
>> doesn't it only need a reviewer (hopefully the packager is still willing
>> to push this from his side)
>> Bug 847160 - Review Request: eclipse-m2e-core - Maven integration for
>> Eclipse
>
> It is not ready for review, as far as I can tell, it needs more work
> from the packager, and looks like the current packager lost interest in
> the package.
>
>> (we can also consider hosting it as an interim in ovirt repo)
>
> I think that is not worth, users can just install it from the
> corresponding Eclipse repositories.
>

lets see the final result and see who many steps it has, then revisit if 
neccesary



From agl at us.ibm.com  Thu Nov 29 14:56:13 2012
From: agl at us.ibm.com (Adam Litke)
Date: Thu, 29 Nov 2012 08:56:13 -0600
Subject: [Engine-devel] [vdsm] [ATTENTION] vdsm-bootstrap/host
	deployment (pre-3.2)
In-Reply-To: <20121129080012.GW5083@redhat.com>
References: <20121128203942.GE9825@redhat.com>
	<598638595.2117367.1354135528311.JavaMail.root@redhat.com>
	<20121128212935.GN13692@aglitke> <20121129080012.GW5083@redhat.com>
Message-ID: <20121129145613.GP13692@aglitke>

On Thu, Nov 29, 2012 at 10:00:12AM +0200, Dan Kenigsberg wrote:
> On Wed, Nov 28, 2012 at 03:29:35PM -0600, Adam Litke wrote:
> > On Wed, Nov 28, 2012 at 03:45:28PM -0500, Alon Bar-Lev wrote:
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > Cc: "VDSM Project Development" <vdsm-devel at lists.fedorahosted.org>, "engine-devel" <engine-devel at ovirt.org>, "users"
> > > > <users at ovirt.org>
> > > > Sent: Wednesday, November 28, 2012 10:39:42 PM
> > > > Subject: Re: [vdsm] [ATTENTION] vdsm-bootstrap/host deployment (pre-3.2)
> > > > 
> > > > On Wed, Nov 28, 2012 at 02:57:17PM -0500, Alon Bar-Lev wrote:
> > > > > 
> > > > > > > No... we need it as compatibility with older engines...
> > > > > > > We keep minimum changes there for legacy, until end-of-life.
> > > > > > 
> > > > > > Is there an EoL statement for oVirt-3.1?
> > > > > > We can make sure that oVirt-3.2's vdsm installs properly with
> > > > > > ovirt-3.1's vdsm-bootstrap, or even require that Engine must be
> > > > > > upgraded
> > > > > > to ovirt-3.2 before upgrading any of the hosts. Is it too harsh
> > > > > > to
> > > > > > our
> > > > > > vast install base?  users at ovirt.org, please chime in!
> > > > > >
> > > > > 
> > > > > I tried to find such, but the more I dig I find that we need to
> > > > > support old legacy.
> > > > 
> > > > Why, exactly? Fedora gives no such guarntees (heck, I'm stuck with an
> > > > unupgradable F16). Should we be any better than our (currently
> > > > single)
> > > > platform?
> > > 
> > > We should start and detach from specific distro procedures.
> > > 
> > > > 
> > > > > > > > > 
> > > > > > > > >  * legacy-removed: change machine width core file
> > > > > > > > >   # echo /var/lib/vdsm/core > /proc/sys/kernel/core_pattern
> > > > > > > > 
> > > > > > > > Yeah, qemu-kvm and libvirtd are much more stable than in the
> > > > > > > > old
> > > > > > > > days,
> > > > > > > > but wouldn't we want to keep a means to collect the corpses
> > > > > > > > of
> > > > > > > > dead
> > > > > > > > processes from hypervisors? It has helped us nail down nasty
> > > > > > > > bugs,
> > > > > > > > even
> > > > > > > > in Python.
> > > > > > > 
> > > > > > > It does not mean it should be at /var/lib/vdsm ... :)
> > > > > > 
> > > > > > I don't get the joke :-(. If you mind the location, we can think
> > > > > > of
> > > > > > somewhere else to put the core dumps. Would it be hard to
> > > > > > reinstate a
> > > > > > parallel feature in otopi?
> > > > > 
> > > > > I usually do not make any jokes...
> > > > > A global system setting should not go into package specific
> > > > > location.
> > > > > Usually core dumps are off by default, I like this approach as
> > > > > unattended system may fast consume all disk space because of
> > > > > dumps.
> > > > 
> > > > If a host fills up with dumps so quickly, it's a sign that it should
> > > > not
> > > > be used for production, and that someone should look into the cores.
> > > > (P.S. we have a logrotate rule for them in vdsm)
> > > 
> > > There should be a vdsm-debug-aids (or similar) to perform such changes.
> > > Again, I don't think vdsm should (by default) modify any system width parameter such as this.
> > > But I will happy to hear more views.
> > 
> > I agree with your statement above that a single package should not override a
> > global system setting.  We should really work to remove as many of these from
> > vdsm as we possibly can.  It will help to make vdsm a much safer/well-behaved
> > package.
> 
> I'm fine with dropping these from vdsm, but I think they are good for
> ovirt - we would like to (be able to) enfornce policy on our nodes.
> 
> If configuring core dumps is removed from vdsm, it should go somewhere
> else, or our log-collector users would miss their beloved dumps.

Yes, I agree.  From my point of view the plan was to do the following:

1. Remove unnecessary system configuration changes.  This includes things like
Royce's supervdsm startup process patch (and accompanying sudo->supervdsm
conversions) which allows us to remove some of the sudo configuration.

2. Isolate the remaining tweaks into vdsm-tool.

3. Provide a service/program that can be run to configure a system to work in an
ovirt-engine controlled cluster.

Doing this allows vdsm to be safely installed on any system as a basic
prerequisite for other software.

-- 
Adam Litke <agl at us.ibm.com>
IBM Linux Technology Center



From agl at us.ibm.com  Thu Nov 29 17:19:06 2012
From: agl at us.ibm.com (Adam Litke)
Date: Thu, 29 Nov 2012 11:19:06 -0600
Subject: [Engine-devel] RFD: API: Identifying vdsm objects in the next-gen
	API
Message-ID: <20121129171906.GR13692@aglitke>

Today in vdsm, every object (StoragePool, StorageDomain, VM, Volume, etc) is
identified by a single UUID.  On the surface, it seems like this is enough info
to properly identify a resource but in practice it's not.  For example, when you
look at the API's dealing with Volumes, almost all of them require an sdUUID,
spUUID, and imgUUID in order to provide proper context for the operation.

Needing to provide these extra UUIDs is a burden on the API user because knowing
which values to pass requires internal knowledge of the API.  For example, the
spUUID parameter is almost always just the connected storage pool.  Since we
know there can currently be only one connected pool, the value is known.

I would like to move away from needing to understand all of these relationships
from the end user perspective by encapsulating the extra context into new object
identifier types as follows:

StoragePoolIdentifier:
    { 'storagepoolID': 'UUID' }
StorageDomainIdentifier:
    { 'storagepoolID*': 'UUID', 'storagedomainID': 'UUID' }
ImageIdentifier:
    { 'storagepoolID*': 'UUID', 'storagedomainID': 'UUID', 'imageID': 'UUID' }
VolumeIdentifier:
    { 'storagepoolID*': 'UUID', 'storagedomainID': 'UUID',
      'imageID': 'UUID', 'volumeID': 'UUID' }
TaskIdentifier:
    { 'taskID': 'UUID' }
VMIdentifier:
    { 'vmID': 'UUID' }

In the new API, anytime a reference to an object is required, one of the above
structures must be passed in place of today's single UUID.  In many cases, this
will allow us to reduce the number of parameters to the function since the
needed contextual parameters (spUUID, etc) will be part of the object's
identifier.  Similarly, any time the API returns an object reference it would
return a *Identifier instead of a bare UUID.

These identifier types are basically opaque blobs to the API users and are only
ever generated by vdsm itself.  Because of this, we can change the internal
structure of the identifier to require new information or (before freezing the
API) remove fields that no longer make sense.

I would greatly appreciate your comments on this proposal.  If it seems
reasonable, I will revamp the current schema to make the necessary changes and
provide the Bridge patch functions to convert between the current implementation
and the new schema.

--- sample schema patch ---

commit 48f6b0f0a111dd0b372d211a4e566ce87f375cee
Author: Adam Litke <agl at us.ibm.com>
Date:   Tue Nov 27 14:14:06 2012 -0600

    schema: Introduce class identifier types
    
    When calling API methods that belong to a particular class, a class instance
    must be indicated by passing a set of identifiers in the request.  The location
    of these parameters within the request is: 'params' -> '__obj__'.  Since this
    set of identifiers must be used together to correctly instantiate an object, it
    makes sense to define these as proper types within the API.  Then, functions
    that return an object (or list of objects) can refer to the correct type.
    
    Signed-off-by: Adam Litke <agl at us.ibm.com>

diff --git a/vdsm_api/vdsmapi-schema.json b/vdsm_api/vdsmapi-schema.json
index 0418e6e..7e2e851 100644
--- a/vdsm_api/vdsmapi-schema.json
+++ b/vdsm_api/vdsmapi-schema.json
@@ -937,7 +937,7 @@
 # Since: 4.10.0
 ##
 {'command': {'class': 'Host', 'name': 'getConnectedStoragePools'},
- 'returns': ['StoragePool']}
+ 'returns': ['StoragePoolIdentifier']}
 
 ##
 # @BlockDeviceType:
@@ -1572,7 +1572,7 @@
 {'command': {'class': 'Host', 'name': 'getStorageDomains'},
  'data': {'*storagepoolID': 'UUID', '*domainClass': 'StorageDomainImageClass',
           '*storageType': 'StorageDomainType', '*remotePath': 'str'},
- 'returns': ['StorageDomain']}
+ 'returns': ['StorageDomainIdentifier']}
 
 ##
 # @Host.getStorageRepoStats:
@@ -2406,7 +2406,7 @@
 ##
 {'command': {'class': 'Host', 'name': 'getVMList'},
  'data': {'*vmList': ['UUID']},
- 'returns': ['VM']}
+ 'returns': ['VMIdentifier']}
 
 ##
 # @Host.ping:
@@ -2744,10 +2744,11 @@
  'returns': 'ConnectionRefMap'}
 
 ## Category: @ISCSIConnection ##################################################
+
 ##
-# @ISCSIConnection:
+# @ISCSIConnectionIdentifier:
 #
-# ISCSIConnection API object.
+# Identifier for an ISCSIConnection object.
 #
 # @host:      A fully-qualified domain name (FQDN) or IP address
 #
@@ -2757,11 +2758,21 @@
 #
 # @password:  #optional The password associated with the given username
 #
-# Since: 4.10.0
+# Since: 4.10.1
+##
+{'type': 'ISCSIConnectionIdentifier',
+ 'data': {'host': 'str', 'port': 'int', '*user': 'str', '*password': 'str'}}
+
+##
+# @ISCSIConnection:
+#
+# ISCSIConnection API object.
+#
+# @ident:  The object identifier
+#
+# Since: 4.10.1
 ##
-{'class': 'ISCSIConnection',
- 'data': {'host': 'str', 'port': 'int', '*user': 'str',
-          '*password': 'str'}}
+{'class': 'ISCSIConnection', 'ident': 'ISCSIConnectionIdentifier'}
 
 ##
 # @ISCSIConnection.discoverSendTargets:
@@ -2777,10 +2788,11 @@
  'returns': ['str']}
 
 ## Category: @Image ############################################################
+
 ##
-# @Image:
+# @ImageIdentifier:
 #
-# Image API object.
+# Identifier for an Image object.
 #
 # @imageID:          The UUID of the Image
 #
@@ -2788,13 +2800,24 @@
 #
 # @storagedomainID:  The UUID of the Storage Domain associated with the Image
 #
-# Since: 4.10.0
+# Since: 4.10.1
 ##
-{'class': 'Image',
+{'type': 'ImageIdentifier',
  'data': {'imageID': 'UUID', 'storagepoolID': 'UUID',
           'storagedomainID': 'UUID'}}
 
 ##
+# @Image:
+#
+# Image API object.
+#
+# @ident:  The object identifier
+#
+# Since: 4.10.1
+##
+{'class': 'Image', 'ident': 'ImageIdentifier'}
+
+##
 # @Image.delete:
 #
 # Delete the Image and all of its Volumes.
@@ -2843,7 +2866,7 @@
 # Since: 4.10.0
 ##
 {'command': {'class': 'Image', 'name': 'getVolumes'},
- 'returns': ['Volume']}
+ 'returns': ['VolumeIdentifier']}
 
 ##
 # @Image.mergeSnapshots:
@@ -2905,17 +2928,26 @@
 
 ## Category: @LVMVolumeGroup ###################################################
 ##
+# @LVMVolumeGroupIdentifier:
+#
+# An identifier for a LVMVolumeGroup object.
+#
+# @lvmvolumegroupID:  The volume group UUID
+#
+# Since: 4.10.1
+##
+{'type': 'LVMVolumeGroupIdentifier', 'data': {'lvmvolumegroupID': 'UUID'}}
+
+##
 # @LVMVolumeGroup:
 #
 # LVMVolumeGroup API object.
 #
-# @lvmvolumegroupID:  #optional Associate this object with an existing LVM
-#                     Volume Group
+# @ident:  The object identifier
 #
-# Since: 4.10.0
+# Since: 4.10.1
 ##
-{'class': 'LVMVolumeGroup',
- 'data': {'lvmvolumegroupID': 'UUID'}}
+{'class': 'LVMVolumeGroup', 'ident': 'LVMVolumeGroupIdentifier'}
 
 ##
 # @LVMVolumeGroup.create:
@@ -2964,21 +2996,32 @@
 
 ## Category: @StorageDomain ####################################################
 ##
-# @StorageDomain:
+# @StorageDomainIdentifier:
 #
-# StorageDomain API object.
+# An identifier for a StorageDomain object.
 #
 # @storagedomainID:  Associate this object with a new or existing Storage Domain
 #
 # @storagepoolID:    #optional The Storage Pool UUID if this Storage Domain is
 #                    attached
 #
-# Since: 4.10.0
+# Since: 4.10.1
 ##
-{'class': 'StorageDomain',
+{'type': 'StorageDomainIdentifier',
  'data': {'storagedomainID': 'UUID', 'storagepoolID': 'UUID'}}
 
 ##
+# @StorageDomain:
+#
+# StorageDomain API object.
+#
+# @ident:  The object identifier
+#
+# Since: 4.10.1
+##
+{'class': 'StorageDomain', 'ident': 'StorageDomainIdentifier'}
+
+##
 # @StorageDomain.activate:
 #
 # Activate an attached but inactive Storage Domain.
@@ -3184,7 +3227,7 @@
 # Since: 4.10.0
 ##
 {'command': {'class': 'StorageDomain', 'name': 'getImages'},
- 'returns': ['Image']}
+ 'returns': ['ImageIdentifier']}
 
 ##
 # @StorageDomainRole:
@@ -3295,7 +3338,7 @@
 ##
 {'command': {'class': 'StorageDomain', 'name': 'getVolumes'},
  'data': {'imageID': 'UUID'},
- 'returns': ['Volume']}
+ 'returns': ['VolumeIdentifier']}
 
 ##
 # @StorageDomain.setDescription:
@@ -3355,15 +3398,26 @@
 
 ## Category: @StoragePool ######################################################
 ##
+# @StoragePoolIdentifier:
+#
+# An identifier for a StoragePool object.
+#
+# @storagepoolID:  Associate this object with a new or existing Storage Pool
+#
+# Since: 4.10.1
+##
+{'type': 'StoragePoolIdentifier', 'data': {'storagepoolID': 'UUID'}}
+
+##
 # @StoragePool:
 #
 # StoragePool API object.
 #
-# @storagepoolID:  Associate this object with a new or existing Storage Pool
+# @ident:  The object identifier
 #
-# Since: 4.10.0
+# Since: 4.10.1
 ##
-{'class': 'StoragePool', 'data': {'storagepoolID': 'UUID'}}
+{'class': 'StoragePool', 'ident': 'StoragePoolIdentifier'}
 
 ##
 # @StoragePool.connect:
@@ -3629,7 +3683,7 @@
 ##
 {'command': {'class': 'StoragePool', 'name': 'getDomainsContainingImage'},
  'data': {'imageID': 'UUID', '*onlyDataDomains': 'bool'},
- 'returns': ['StorageDomain']}
+ 'returns': ['StorageDomainIdentifier']}
 
 ##
 # @StoragePool.getIsoList:
@@ -4058,15 +4112,27 @@
 
 ## Category: @Task #############################################################
 ##
+# @TaskIdentifier:
+#
+# An identifier for a Task object.
+#
+# @taskID:  The task UUID
+#
+# Since: 4.10.1
+##
+{'type': 'TaskIdentifier', 'data': {'taskID': 'UUID'}}
+
+
+##
 # @Task:
 #
 # Task API object.
 #
-# @taskID:  Associate this object with an existing Task
+# @ident:  The object identifier
 #
-# Since: 4.10.0
+# Since: 4.10.1
 ##
-{'class': 'Task', 'data': {'taskID': 'UUID'}}
+{'class': 'Task', 'ident': 'TaskIdentifier'}
 
 ##
 # @Task.clear:
@@ -4123,15 +4189,26 @@
 
 ## Category: @VM ###############################################################
 ##
+# @VMIdentifier:
+#
+# An identifier for a VM object.
+#
+# @vmID:  The task UUID
+#
+# Since: 4.10.1
+##
+{'type': 'VMIdentifier', 'data': {'vmID': 'UUID'}}
+
+##
 # @VM:
 #
 # VM API object.
 #
-# @vmID:  Associate this object with an existing VM
+# @ident:  The object identifier
 #
-# Since: 4.10.0
+# Since: 4.10.1
 ##
-{'class': 'VM', 'data': {'vmID': 'UUID'}}
+{'class': 'VM', 'ident': 'VMIdentifier'}
 
 ##
 # @DriveSpecVolume:
@@ -5161,9 +5238,9 @@
 
 ## Category: @Volume ###########################################################
 ##
-# @Volume:
+# @VolumeIdentifier:
 #
-# Volume API object.
+# An identifier for a Volume object.
 #
 # @volumeID:         The UUID of the Volume
 #
@@ -5173,13 +5250,24 @@
 #
 # @imageID:          The Image associated with @UUID
 #
-# Since: 4.10.0
+# Since: 4.10.1
 ##
-{'class': 'Volume',
+{'type': 'VolumeIdentifier',
  'data': {'volumeID': 'UUID', 'storagepoolID': 'UUID',
           'storagedomainID': 'UUID', 'imageID': 'UUID'}}
 
 ##
+# @Volume:
+#
+# Volume API object.
+#
+# @ident:  The object identifier
+#
+# Since: 4.10.1
+##
+{'class': 'Volume', 'ident': 'VolumeIdentifier'}
+
+##
 # @VolumeRole:
 #
 # An enumeration of Volume Roles.

-- 
Adam Litke <agl at us.ibm.com>
IBM Linux Technology Center



From smizrahi at redhat.com  Thu Nov 29 19:16:42 2012
From: smizrahi at redhat.com (Saggi Mizrahi)
Date: Thu, 29 Nov 2012 14:16:42 -0500 (EST)
Subject: [Engine-devel] RFD: API: Identifying vdsm objects in the
	next-gen API
In-Reply-To: <20121129171906.GR13692@aglitke>
Message-ID: <2098263695.11846029.1354216602663.JavaMail.root@redhat.com>

This is all only valid for the current storage API
the new one doesn't have pools or volumes. Only domains and images.
Also, images and domains are more loosely coupled and make this method problematic.

That being said, if we do choose to make the current storage API officially supported I do agree that it looks a bit simpler but for the price of forcing the user to construct these objects before sending the request. I know for a fact that the engine will just create these objects on the fly because they use their own objects to group things logically. This means adding more work instead of removing it.
Most clients will do that anyway as they will use their own DAL to store these relationships. 

----- Original Message -----
> From: "Adam Litke" <agl at us.ibm.com>
> To: vdsm-devel at lists.fedorahosted.org
> Cc: engine-devel at linode01.ovirt.org, "Dan Kenigsberg" <danken at redhat.com>, "Federico Simoncelli"
> <fsimonce at redhat.com>, "Saggi Mizrahi" <smizrahi at redhat.com>, "Ayal Baron" <abaron at redhat.com>
> Sent: Thursday, November 29, 2012 12:19:06 PM
> Subject: RFD: API: Identifying vdsm objects in the next-gen API
> 
> Today in vdsm, every object (StoragePool, StorageDomain, VM, Volume,
> etc) is
> identified by a single UUID.  On the surface, it seems like this is
> enough info
> to properly identify a resource but in practice it's not.  For
> example, when you
> look at the API's dealing with Volumes, almost all of them require an
> sdUUID,
> spUUID, and imgUUID in order to provide proper context for the
> operation.
> 
> Needing to provide these extra UUIDs is a burden on the API user
> because knowing
> which values to pass requires internal knowledge of the API.  For
> example, the
> spUUID parameter is almost always just the connected storage pool.
>  Since we
> know there can currently be only one connected pool, the value is
> known.
> 
> I would like to move away from needing to understand all of these
> relationships
> from the end user perspective by encapsulating the extra context into
> new object
> identifier types as follows:
> 
> StoragePoolIdentifier:
>     { 'storagepoolID': 'UUID' }
> StorageDomainIdentifier:
>     { 'storagepoolID*': 'UUID', 'storagedomainID': 'UUID' }
> ImageIdentifier:
>     { 'storagepoolID*': 'UUID', 'storagedomainID': 'UUID', 'imageID':
>     'UUID' }
> VolumeIdentifier:
>     { 'storagepoolID*': 'UUID', 'storagedomainID': 'UUID',
>       'imageID': 'UUID', 'volumeID': 'UUID' }
> TaskIdentifier:
>     { 'taskID': 'UUID' }
> VMIdentifier:
>     { 'vmID': 'UUID' }
> 
> In the new API, anytime a reference to an object is required, one of
> the above
> structures must be passed in place of today's single UUID.  In many
> cases, this
> will allow us to reduce the number of parameters to the function
> since the
> needed contextual parameters (spUUID, etc) will be part of the
> object's
> identifier.  Similarly, any time the API returns an object reference
> it would
> return a *Identifier instead of a bare UUID.
> 
> These identifier types are basically opaque blobs to the API users
> and are only
> ever generated by vdsm itself.  Because of this, we can change the
> internal
> structure of the identifier to require new information or (before
> freezing the
> API) remove fields that no longer make sense.
> 
> I would greatly appreciate your comments on this proposal.  If it
> seems
> reasonable, I will revamp the current schema to make the necessary
> changes and
> provide the Bridge patch functions to convert between the current
> implementation
> and the new schema.
> 
> --- sample schema patch ---
> 
> commit 48f6b0f0a111dd0b372d211a4e566ce87f375cee
> Author: Adam Litke <agl at us.ibm.com>
> Date:   Tue Nov 27 14:14:06 2012 -0600
> 
>     schema: Introduce class identifier types
>     
>     When calling API methods that belong to a particular class, a
>     class instance
>     must be indicated by passing a set of identifiers in the request.
>      The location
>     of these parameters within the request is: 'params' -> '__obj__'.
>      Since this
>     set of identifiers must be used together to correctly instantiate
>     an object, it
>     makes sense to define these as proper types within the API.
>      Then, functions
>     that return an object (or list of objects) can refer to the
>     correct type.
>     
>     Signed-off-by: Adam Litke <agl at us.ibm.com>
> 
> diff --git a/vdsm_api/vdsmapi-schema.json
> b/vdsm_api/vdsmapi-schema.json
> index 0418e6e..7e2e851 100644
> --- a/vdsm_api/vdsmapi-schema.json
> +++ b/vdsm_api/vdsmapi-schema.json
> @@ -937,7 +937,7 @@
>  # Since: 4.10.0
>  ##
>  {'command': {'class': 'Host', 'name': 'getConnectedStoragePools'},
> - 'returns': ['StoragePool']}
> + 'returns': ['StoragePoolIdentifier']}
>  
>  ##
>  # @BlockDeviceType:
> @@ -1572,7 +1572,7 @@
>  {'command': {'class': 'Host', 'name': 'getStorageDomains'},
>   'data': {'*storagepoolID': 'UUID', '*domainClass':
>   'StorageDomainImageClass',
>            '*storageType': 'StorageDomainType', '*remotePath':
>            'str'},
> - 'returns': ['StorageDomain']}
> + 'returns': ['StorageDomainIdentifier']}
>  
>  ##
>  # @Host.getStorageRepoStats:
> @@ -2406,7 +2406,7 @@
>  ##
>  {'command': {'class': 'Host', 'name': 'getVMList'},
>   'data': {'*vmList': ['UUID']},
> - 'returns': ['VM']}
> + 'returns': ['VMIdentifier']}
>  
>  ##
>  # @Host.ping:
> @@ -2744,10 +2744,11 @@
>   'returns': 'ConnectionRefMap'}
>  
>  ## Category: @ISCSIConnection
>  ##################################################
> +
>  ##
> -# @ISCSIConnection:
> +# @ISCSIConnectionIdentifier:
>  #
> -# ISCSIConnection API object.
> +# Identifier for an ISCSIConnection object.
>  #
>  # @host:      A fully-qualified domain name (FQDN) or IP address
>  #
> @@ -2757,11 +2758,21 @@
>  #
>  # @password:  #optional The password associated with the given
>  username
>  #
> -# Since: 4.10.0
> +# Since: 4.10.1
> +##
> +{'type': 'ISCSIConnectionIdentifier',
> + 'data': {'host': 'str', 'port': 'int', '*user': 'str', '*password':
> 'str'}}
> +
> +##
> +# @ISCSIConnection:
> +#
> +# ISCSIConnection API object.
> +#
> +# @ident:  The object identifier
> +#
> +# Since: 4.10.1
>  ##
> -{'class': 'ISCSIConnection',
> - 'data': {'host': 'str', 'port': 'int', '*user': 'str',
> -          '*password': 'str'}}
> +{'class': 'ISCSIConnection', 'ident': 'ISCSIConnectionIdentifier'}
>  
>  ##
>  # @ISCSIConnection.discoverSendTargets:
> @@ -2777,10 +2788,11 @@
>   'returns': ['str']}
>  
>  ## Category: @Image
>  ############################################################
> +
>  ##
> -# @Image:
> +# @ImageIdentifier:
>  #
> -# Image API object.
> +# Identifier for an Image object.
>  #
>  # @imageID:          The UUID of the Image
>  #
> @@ -2788,13 +2800,24 @@
>  #
>  # @storagedomainID:  The UUID of the Storage Domain associated with
>  the Image
>  #
> -# Since: 4.10.0
> +# Since: 4.10.1
>  ##
> -{'class': 'Image',
> +{'type': 'ImageIdentifier',
>   'data': {'imageID': 'UUID', 'storagepoolID': 'UUID',
>            'storagedomainID': 'UUID'}}
>  
>  ##
> +# @Image:
> +#
> +# Image API object.
> +#
> +# @ident:  The object identifier
> +#
> +# Since: 4.10.1
> +##
> +{'class': 'Image', 'ident': 'ImageIdentifier'}
> +
> +##
>  # @Image.delete:
>  #
>  # Delete the Image and all of its Volumes.
> @@ -2843,7 +2866,7 @@
>  # Since: 4.10.0
>  ##
>  {'command': {'class': 'Image', 'name': 'getVolumes'},
> - 'returns': ['Volume']}
> + 'returns': ['VolumeIdentifier']}
>  
>  ##
>  # @Image.mergeSnapshots:
> @@ -2905,17 +2928,26 @@
>  
>  ## Category: @LVMVolumeGroup
>  ###################################################
>  ##
> +# @LVMVolumeGroupIdentifier:
> +#
> +# An identifier for a LVMVolumeGroup object.
> +#
> +# @lvmvolumegroupID:  The volume group UUID
> +#
> +# Since: 4.10.1
> +##
> +{'type': 'LVMVolumeGroupIdentifier', 'data': {'lvmvolumegroupID':
> 'UUID'}}
> +
> +##
>  # @LVMVolumeGroup:
>  #
>  # LVMVolumeGroup API object.
>  #
> -# @lvmvolumegroupID:  #optional Associate this object with an
> existing LVM
> -#                     Volume Group
> +# @ident:  The object identifier
>  #
> -# Since: 4.10.0
> +# Since: 4.10.1
>  ##
> -{'class': 'LVMVolumeGroup',
> - 'data': {'lvmvolumegroupID': 'UUID'}}
> +{'class': 'LVMVolumeGroup', 'ident': 'LVMVolumeGroupIdentifier'}
>  
>  ##
>  # @LVMVolumeGroup.create:
> @@ -2964,21 +2996,32 @@
>  
>  ## Category: @StorageDomain
>  ####################################################
>  ##
> -# @StorageDomain:
> +# @StorageDomainIdentifier:
>  #
> -# StorageDomain API object.
> +# An identifier for a StorageDomain object.
>  #
>  # @storagedomainID:  Associate this object with a new or existing
>  Storage Domain
>  #
>  # @storagepoolID:    #optional The Storage Pool UUID if this Storage
>  Domain is
>  #                    attached
>  #
> -# Since: 4.10.0
> +# Since: 4.10.1
>  ##
> -{'class': 'StorageDomain',
> +{'type': 'StorageDomainIdentifier',
>   'data': {'storagedomainID': 'UUID', 'storagepoolID': 'UUID'}}
>  
>  ##
> +# @StorageDomain:
> +#
> +# StorageDomain API object.
> +#
> +# @ident:  The object identifier
> +#
> +# Since: 4.10.1
> +##
> +{'class': 'StorageDomain', 'ident': 'StorageDomainIdentifier'}
> +
> +##
>  # @StorageDomain.activate:
>  #
>  # Activate an attached but inactive Storage Domain.
> @@ -3184,7 +3227,7 @@
>  # Since: 4.10.0
>  ##
>  {'command': {'class': 'StorageDomain', 'name': 'getImages'},
> - 'returns': ['Image']}
> + 'returns': ['ImageIdentifier']}
>  
>  ##
>  # @StorageDomainRole:
> @@ -3295,7 +3338,7 @@
>  ##
>  {'command': {'class': 'StorageDomain', 'name': 'getVolumes'},
>   'data': {'imageID': 'UUID'},
> - 'returns': ['Volume']}
> + 'returns': ['VolumeIdentifier']}
>  
>  ##
>  # @StorageDomain.setDescription:
> @@ -3355,15 +3398,26 @@
>  
>  ## Category: @StoragePool
>  ######################################################
>  ##
> +# @StoragePoolIdentifier:
> +#
> +# An identifier for a StoragePool object.
> +#
> +# @storagepoolID:  Associate this object with a new or existing
> Storage Pool
> +#
> +# Since: 4.10.1
> +##
> +{'type': 'StoragePoolIdentifier', 'data': {'storagepoolID': 'UUID'}}
> +
> +##
>  # @StoragePool:
>  #
>  # StoragePool API object.
>  #
> -# @storagepoolID:  Associate this object with a new or existing
> Storage Pool
> +# @ident:  The object identifier
>  #
> -# Since: 4.10.0
> +# Since: 4.10.1
>  ##
> -{'class': 'StoragePool', 'data': {'storagepoolID': 'UUID'}}
> +{'class': 'StoragePool', 'ident': 'StoragePoolIdentifier'}
>  
>  ##
>  # @StoragePool.connect:
> @@ -3629,7 +3683,7 @@
>  ##
>  {'command': {'class': 'StoragePool', 'name':
>  'getDomainsContainingImage'},
>   'data': {'imageID': 'UUID', '*onlyDataDomains': 'bool'},
> - 'returns': ['StorageDomain']}
> + 'returns': ['StorageDomainIdentifier']}
>  
>  ##
>  # @StoragePool.getIsoList:
> @@ -4058,15 +4112,27 @@
>  
>  ## Category: @Task
>  #############################################################
>  ##
> +# @TaskIdentifier:
> +#
> +# An identifier for a Task object.
> +#
> +# @taskID:  The task UUID
> +#
> +# Since: 4.10.1
> +##
> +{'type': 'TaskIdentifier', 'data': {'taskID': 'UUID'}}
> +
> +
> +##
>  # @Task:
>  #
>  # Task API object.
>  #
> -# @taskID:  Associate this object with an existing Task
> +# @ident:  The object identifier
>  #
> -# Since: 4.10.0
> +# Since: 4.10.1
>  ##
> -{'class': 'Task', 'data': {'taskID': 'UUID'}}
> +{'class': 'Task', 'ident': 'TaskIdentifier'}
>  
>  ##
>  # @Task.clear:
> @@ -4123,15 +4189,26 @@
>  
>  ## Category: @VM
>  ###############################################################
>  ##
> +# @VMIdentifier:
> +#
> +# An identifier for a VM object.
> +#
> +# @vmID:  The task UUID
> +#
> +# Since: 4.10.1
> +##
> +{'type': 'VMIdentifier', 'data': {'vmID': 'UUID'}}
> +
> +##
>  # @VM:
>  #
>  # VM API object.
>  #
> -# @vmID:  Associate this object with an existing VM
> +# @ident:  The object identifier
>  #
> -# Since: 4.10.0
> +# Since: 4.10.1
>  ##
> -{'class': 'VM', 'data': {'vmID': 'UUID'}}
> +{'class': 'VM', 'ident': 'VMIdentifier'}
>  
>  ##
>  # @DriveSpecVolume:
> @@ -5161,9 +5238,9 @@
>  
>  ## Category: @Volume
>  ###########################################################
>  ##
> -# @Volume:
> +# @VolumeIdentifier:
>  #
> -# Volume API object.
> +# An identifier for a Volume object.
>  #
>  # @volumeID:         The UUID of the Volume
>  #
> @@ -5173,13 +5250,24 @@
>  #
>  # @imageID:          The Image associated with @UUID
>  #
> -# Since: 4.10.0
> +# Since: 4.10.1
>  ##
> -{'class': 'Volume',
> +{'type': 'VolumeIdentifier',
>   'data': {'volumeID': 'UUID', 'storagepoolID': 'UUID',
>            'storagedomainID': 'UUID', 'imageID': 'UUID'}}
>  
>  ##
> +# @Volume:
> +#
> +# Volume API object.
> +#
> +# @ident:  The object identifier
> +#
> +# Since: 4.10.1
> +##
> +{'class': 'Volume', 'ident': 'VolumeIdentifier'}
> +
> +##
>  # @VolumeRole:
>  #
>  # An enumeration of Volume Roles.
> 
> --
> Adam Litke <agl at us.ibm.com>
> IBM Linux Technology Center
> 
> 


From damon at damtek.com  Thu Nov 29 20:12:36 2012
From: damon at damtek.com (Damon Chesser)
Date: Thu, 29 Nov 2012 15:12:36 -0500
Subject: [Engine-devel] unsuscribe
Message-ID: <50B7C1B4.1020800@damtek.com>


-- 
Damon L. Chesser
damon at damtek.com
http://www.linkedin.com/in/dchesser




From emesika at redhat.com  Thu Nov 29 21:11:56 2012
From: emesika at redhat.com (Eli Mesika)
Date: Thu, 29 Nov 2012 16:11:56 -0500 (EST)
Subject: [Engine-devel] Design review summary for 3.2 - adding support
 for External Events
In-Reply-To: <1846109123.14120666.1353792676829.JavaMail.root@redhat.com>
Message-ID: <1652353217.16442236.1354223516335.JavaMail.root@redhat.com>

Hi

please note that this section 
http://wiki.ovirt.org/wiki/Features/Design/DetailedExternalEvents#Permissions
was changed and approved by PM (Miki)



From agl at us.ibm.com  Thu Nov 29 21:18:40 2012
From: agl at us.ibm.com (Adam Litke)
Date: Thu, 29 Nov 2012 15:18:40 -0600
Subject: [Engine-devel] RFD: API: Identifying vdsm objects in the
	next-gen API
In-Reply-To: <2098263695.11846029.1354216602663.JavaMail.root@redhat.com>
References: <20121129171906.GR13692@aglitke>
	<2098263695.11846029.1354216602663.JavaMail.root@redhat.com>
Message-ID: <20121129211840.GA4798@aglitke>

On Thu, Nov 29, 2012 at 02:16:42PM -0500, Saggi Mizrahi wrote:
> This is all only valid for the current storage API the new one doesn't have
> pools or volumes. Only domains and images.  Also, images and domains are more
> loosely coupled and make this method problematic.

I am looking for an incremental way to bridge the differences.  It's been 2
years and we still don't have the revamped storage API so I am planning on what
we have being around for awhile :)  I think that defining object identifiers as
opaque structured types is also future proof.  In the future an Image-ng object
we can drop 'storagepoolID' from the identifier and, if it makes sense, remove
the hard association with a storageDomain as well.  The point behind this
refactoring is to give us the option of coupling multiple UUID's (or other data)
to form a single, opaque identifier.

> That being said, if we do choose to make the current storage API officially
> supported I do agree that it looks a bit simpler but for the price of forcing
> the user to construct these objects before sending the request. I know for a
> fact that the engine will just create these objects on the fly because they
> use their own objects to group things logically. This means adding more work
> instead of removing it.  Most clients will do that anyway as they will use
> their own DAL to store these relationships. 
> 

Thanks for bringing up some of these points.  All deserve attention so I will
address each one individually:

The current API does not yet make an official statement of support for anything.
I want to model the current storage API so that the node level API can have the
same level of functionality as is currently supported.  I am all for removing
deprecated functions and redesigning in-place for a reasonable amount of time
going forward.  In a perfect world, libvdsm-1.0 would release with no mention of
storage pools at all.

If properly designed, the end-user (including engine) would never be
constructing these objects itself.  Object identifiers are essentially opaque
structures.  In order to make this possible, we need to make sure that the API
provides all of the functions needed to lookup objects.  So far these are:

StoragePool:	Host.getConnectedStoragePools
StorageDomain:	Host.getStorageDomains
Image:		StorageDomain.getImages
Volume:		StorageDomain.getVolumes / Image.getVolumes
VM:		Host.getVMList
Task:		Host.getAllTasks

All of the above would return object identifiers.

The other case is for creation of new resources.  In that case, the create
method needs to move to the owning object.  The key example is VM.create which
should move to Host.createVM.  Functions such as Host.createVM could still
accept a vmUUID (because I assume engine does want the ability to set this
explicitly).  However, they should be changed to return either a TaskIdentifier
(if the creation is asynchronous) or a *Identifier (eg. VmIdentifier) if the
object was created synchronously.

All told, I think the net is less work for clients.  They will no longer need to
model the object associations and relationships because the API will take care
of that automatically.

> ----- Original Message -----
> > From: "Adam Litke" <agl at us.ibm.com>
> > To: vdsm-devel at lists.fedorahosted.org
> > Cc: engine-devel at linode01.ovirt.org, "Dan Kenigsberg" <danken at redhat.com>, "Federico Simoncelli"
> > <fsimonce at redhat.com>, "Saggi Mizrahi" <smizrahi at redhat.com>, "Ayal Baron" <abaron at redhat.com>
> > Sent: Thursday, November 29, 2012 12:19:06 PM
> > Subject: RFD: API: Identifying vdsm objects in the next-gen API
> > 
> > Today in vdsm, every object (StoragePool, StorageDomain, VM, Volume,
> > etc) is
> > identified by a single UUID.  On the surface, it seems like this is
> > enough info
> > to properly identify a resource but in practice it's not.  For
> > example, when you
> > look at the API's dealing with Volumes, almost all of them require an
> > sdUUID,
> > spUUID, and imgUUID in order to provide proper context for the
> > operation.
> > 
> > Needing to provide these extra UUIDs is a burden on the API user
> > because knowing
> > which values to pass requires internal knowledge of the API.  For
> > example, the
> > spUUID parameter is almost always just the connected storage pool.
> >  Since we
> > know there can currently be only one connected pool, the value is
> > known.
> > 
> > I would like to move away from needing to understand all of these
> > relationships
> > from the end user perspective by encapsulating the extra context into
> > new object
> > identifier types as follows:
> > 
> > StoragePoolIdentifier:
> >     { 'storagepoolID': 'UUID' }
> > StorageDomainIdentifier:
> >     { 'storagepoolID*': 'UUID', 'storagedomainID': 'UUID' }
> > ImageIdentifier:
> >     { 'storagepoolID*': 'UUID', 'storagedomainID': 'UUID', 'imageID':
> >     'UUID' }
> > VolumeIdentifier:
> >     { 'storagepoolID*': 'UUID', 'storagedomainID': 'UUID',
> >       'imageID': 'UUID', 'volumeID': 'UUID' }
> > TaskIdentifier:
> >     { 'taskID': 'UUID' }
> > VMIdentifier:
> >     { 'vmID': 'UUID' }
> > 
> > In the new API, anytime a reference to an object is required, one of
> > the above
> > structures must be passed in place of today's single UUID.  In many
> > cases, this
> > will allow us to reduce the number of parameters to the function
> > since the
> > needed contextual parameters (spUUID, etc) will be part of the
> > object's
> > identifier.  Similarly, any time the API returns an object reference
> > it would
> > return a *Identifier instead of a bare UUID.
> > 
> > These identifier types are basically opaque blobs to the API users
> > and are only
> > ever generated by vdsm itself.  Because of this, we can change the
> > internal
> > structure of the identifier to require new information or (before
> > freezing the
> > API) remove fields that no longer make sense.
> > 
> > I would greatly appreciate your comments on this proposal.  If it
> > seems
> > reasonable, I will revamp the current schema to make the necessary
> > changes and
> > provide the Bridge patch functions to convert between the current
> > implementation
> > and the new schema.
> > 
> > --- sample schema patch ---
> > 
> > commit 48f6b0f0a111dd0b372d211a4e566ce87f375cee
> > Author: Adam Litke <agl at us.ibm.com>
> > Date:   Tue Nov 27 14:14:06 2012 -0600
> > 
> >     schema: Introduce class identifier types
> >     
> >     When calling API methods that belong to a particular class, a
> >     class instance
> >     must be indicated by passing a set of identifiers in the request.
> >      The location
> >     of these parameters within the request is: 'params' -> '__obj__'.
> >      Since this
> >     set of identifiers must be used together to correctly instantiate
> >     an object, it
> >     makes sense to define these as proper types within the API.
> >      Then, functions
> >     that return an object (or list of objects) can refer to the
> >     correct type.
> >     
> >     Signed-off-by: Adam Litke <agl at us.ibm.com>
> > 
> > diff --git a/vdsm_api/vdsmapi-schema.json
> > b/vdsm_api/vdsmapi-schema.json
> > index 0418e6e..7e2e851 100644
> > --- a/vdsm_api/vdsmapi-schema.json
> > +++ b/vdsm_api/vdsmapi-schema.json
> > @@ -937,7 +937,7 @@
> >  # Since: 4.10.0
> >  ##
> >  {'command': {'class': 'Host', 'name': 'getConnectedStoragePools'},
> > - 'returns': ['StoragePool']}
> > + 'returns': ['StoragePoolIdentifier']}
> >  
> >  ##
> >  # @BlockDeviceType:
> > @@ -1572,7 +1572,7 @@
> >  {'command': {'class': 'Host', 'name': 'getStorageDomains'},
> >   'data': {'*storagepoolID': 'UUID', '*domainClass':
> >   'StorageDomainImageClass',
> >            '*storageType': 'StorageDomainType', '*remotePath':
> >            'str'},
> > - 'returns': ['StorageDomain']}
> > + 'returns': ['StorageDomainIdentifier']}
> >  
> >  ##
> >  # @Host.getStorageRepoStats:
> > @@ -2406,7 +2406,7 @@
> >  ##
> >  {'command': {'class': 'Host', 'name': 'getVMList'},
> >   'data': {'*vmList': ['UUID']},
> > - 'returns': ['VM']}
> > + 'returns': ['VMIdentifier']}
> >  
> >  ##
> >  # @Host.ping:
> > @@ -2744,10 +2744,11 @@
> >   'returns': 'ConnectionRefMap'}
> >  
> >  ## Category: @ISCSIConnection
> >  ##################################################
> > +
> >  ##
> > -# @ISCSIConnection:
> > +# @ISCSIConnectionIdentifier:
> >  #
> > -# ISCSIConnection API object.
> > +# Identifier for an ISCSIConnection object.
> >  #
> >  # @host:      A fully-qualified domain name (FQDN) or IP address
> >  #
> > @@ -2757,11 +2758,21 @@
> >  #
> >  # @password:  #optional The password associated with the given
> >  username
> >  #
> > -# Since: 4.10.0
> > +# Since: 4.10.1
> > +##
> > +{'type': 'ISCSIConnectionIdentifier',
> > + 'data': {'host': 'str', 'port': 'int', '*user': 'str', '*password':
> > 'str'}}
> > +
> > +##
> > +# @ISCSIConnection:
> > +#
> > +# ISCSIConnection API object.
> > +#
> > +# @ident:  The object identifier
> > +#
> > +# Since: 4.10.1
> >  ##
> > -{'class': 'ISCSIConnection',
> > - 'data': {'host': 'str', 'port': 'int', '*user': 'str',
> > -          '*password': 'str'}}
> > +{'class': 'ISCSIConnection', 'ident': 'ISCSIConnectionIdentifier'}
> >  
> >  ##
> >  # @ISCSIConnection.discoverSendTargets:
> > @@ -2777,10 +2788,11 @@
> >   'returns': ['str']}
> >  
> >  ## Category: @Image
> >  ############################################################
> > +
> >  ##
> > -# @Image:
> > +# @ImageIdentifier:
> >  #
> > -# Image API object.
> > +# Identifier for an Image object.
> >  #
> >  # @imageID:          The UUID of the Image
> >  #
> > @@ -2788,13 +2800,24 @@
> >  #
> >  # @storagedomainID:  The UUID of the Storage Domain associated with
> >  the Image
> >  #
> > -# Since: 4.10.0
> > +# Since: 4.10.1
> >  ##
> > -{'class': 'Image',
> > +{'type': 'ImageIdentifier',
> >   'data': {'imageID': 'UUID', 'storagepoolID': 'UUID',
> >            'storagedomainID': 'UUID'}}
> >  
> >  ##
> > +# @Image:
> > +#
> > +# Image API object.
> > +#
> > +# @ident:  The object identifier
> > +#
> > +# Since: 4.10.1
> > +##
> > +{'class': 'Image', 'ident': 'ImageIdentifier'}
> > +
> > +##
> >  # @Image.delete:
> >  #
> >  # Delete the Image and all of its Volumes.
> > @@ -2843,7 +2866,7 @@
> >  # Since: 4.10.0
> >  ##
> >  {'command': {'class': 'Image', 'name': 'getVolumes'},
> > - 'returns': ['Volume']}
> > + 'returns': ['VolumeIdentifier']}
> >  
> >  ##
> >  # @Image.mergeSnapshots:
> > @@ -2905,17 +2928,26 @@
> >  
> >  ## Category: @LVMVolumeGroup
> >  ###################################################
> >  ##
> > +# @LVMVolumeGroupIdentifier:
> > +#
> > +# An identifier for a LVMVolumeGroup object.
> > +#
> > +# @lvmvolumegroupID:  The volume group UUID
> > +#
> > +# Since: 4.10.1
> > +##
> > +{'type': 'LVMVolumeGroupIdentifier', 'data': {'lvmvolumegroupID':
> > 'UUID'}}
> > +
> > +##
> >  # @LVMVolumeGroup:
> >  #
> >  # LVMVolumeGroup API object.
> >  #
> > -# @lvmvolumegroupID:  #optional Associate this object with an
> > existing LVM
> > -#                     Volume Group
> > +# @ident:  The object identifier
> >  #
> > -# Since: 4.10.0
> > +# Since: 4.10.1
> >  ##
> > -{'class': 'LVMVolumeGroup',
> > - 'data': {'lvmvolumegroupID': 'UUID'}}
> > +{'class': 'LVMVolumeGroup', 'ident': 'LVMVolumeGroupIdentifier'}
> >  
> >  ##
> >  # @LVMVolumeGroup.create:
> > @@ -2964,21 +2996,32 @@
> >  
> >  ## Category: @StorageDomain
> >  ####################################################
> >  ##
> > -# @StorageDomain:
> > +# @StorageDomainIdentifier:
> >  #
> > -# StorageDomain API object.
> > +# An identifier for a StorageDomain object.
> >  #
> >  # @storagedomainID:  Associate this object with a new or existing
> >  Storage Domain
> >  #
> >  # @storagepoolID:    #optional The Storage Pool UUID if this Storage
> >  Domain is
> >  #                    attached
> >  #
> > -# Since: 4.10.0
> > +# Since: 4.10.1
> >  ##
> > -{'class': 'StorageDomain',
> > +{'type': 'StorageDomainIdentifier',
> >   'data': {'storagedomainID': 'UUID', 'storagepoolID': 'UUID'}}
> >  
> >  ##
> > +# @StorageDomain:
> > +#
> > +# StorageDomain API object.
> > +#
> > +# @ident:  The object identifier
> > +#
> > +# Since: 4.10.1
> > +##
> > +{'class': 'StorageDomain', 'ident': 'StorageDomainIdentifier'}
> > +
> > +##
> >  # @StorageDomain.activate:
> >  #
> >  # Activate an attached but inactive Storage Domain.
> > @@ -3184,7 +3227,7 @@
> >  # Since: 4.10.0
> >  ##
> >  {'command': {'class': 'StorageDomain', 'name': 'getImages'},
> > - 'returns': ['Image']}
> > + 'returns': ['ImageIdentifier']}
> >  
> >  ##
> >  # @StorageDomainRole:
> > @@ -3295,7 +3338,7 @@
> >  ##
> >  {'command': {'class': 'StorageDomain', 'name': 'getVolumes'},
> >   'data': {'imageID': 'UUID'},
> > - 'returns': ['Volume']}
> > + 'returns': ['VolumeIdentifier']}
> >  
> >  ##
> >  # @StorageDomain.setDescription:
> > @@ -3355,15 +3398,26 @@
> >  
> >  ## Category: @StoragePool
> >  ######################################################
> >  ##
> > +# @StoragePoolIdentifier:
> > +#
> > +# An identifier for a StoragePool object.
> > +#
> > +# @storagepoolID:  Associate this object with a new or existing
> > Storage Pool
> > +#
> > +# Since: 4.10.1
> > +##
> > +{'type': 'StoragePoolIdentifier', 'data': {'storagepoolID': 'UUID'}}
> > +
> > +##
> >  # @StoragePool:
> >  #
> >  # StoragePool API object.
> >  #
> > -# @storagepoolID:  Associate this object with a new or existing
> > Storage Pool
> > +# @ident:  The object identifier
> >  #
> > -# Since: 4.10.0
> > +# Since: 4.10.1
> >  ##
> > -{'class': 'StoragePool', 'data': {'storagepoolID': 'UUID'}}
> > +{'class': 'StoragePool', 'ident': 'StoragePoolIdentifier'}
> >  
> >  ##
> >  # @StoragePool.connect:
> > @@ -3629,7 +3683,7 @@
> >  ##
> >  {'command': {'class': 'StoragePool', 'name':
> >  'getDomainsContainingImage'},
> >   'data': {'imageID': 'UUID', '*onlyDataDomains': 'bool'},
> > - 'returns': ['StorageDomain']}
> > + 'returns': ['StorageDomainIdentifier']}
> >  
> >  ##
> >  # @StoragePool.getIsoList:
> > @@ -4058,15 +4112,27 @@
> >  
> >  ## Category: @Task
> >  #############################################################
> >  ##
> > +# @TaskIdentifier:
> > +#
> > +# An identifier for a Task object.
> > +#
> > +# @taskID:  The task UUID
> > +#
> > +# Since: 4.10.1
> > +##
> > +{'type': 'TaskIdentifier', 'data': {'taskID': 'UUID'}}
> > +
> > +
> > +##
> >  # @Task:
> >  #
> >  # Task API object.
> >  #
> > -# @taskID:  Associate this object with an existing Task
> > +# @ident:  The object identifier
> >  #
> > -# Since: 4.10.0
> > +# Since: 4.10.1
> >  ##
> > -{'class': 'Task', 'data': {'taskID': 'UUID'}}
> > +{'class': 'Task', 'ident': 'TaskIdentifier'}
> >  
> >  ##
> >  # @Task.clear:
> > @@ -4123,15 +4189,26 @@
> >  
> >  ## Category: @VM
> >  ###############################################################
> >  ##
> > +# @VMIdentifier:
> > +#
> > +# An identifier for a VM object.
> > +#
> > +# @vmID:  The task UUID
> > +#
> > +# Since: 4.10.1
> > +##
> > +{'type': 'VMIdentifier', 'data': {'vmID': 'UUID'}}
> > +
> > +##
> >  # @VM:
> >  #
> >  # VM API object.
> >  #
> > -# @vmID:  Associate this object with an existing VM
> > +# @ident:  The object identifier
> >  #
> > -# Since: 4.10.0
> > +# Since: 4.10.1
> >  ##
> > -{'class': 'VM', 'data': {'vmID': 'UUID'}}
> > +{'class': 'VM', 'ident': 'VMIdentifier'}
> >  
> >  ##
> >  # @DriveSpecVolume:
> > @@ -5161,9 +5238,9 @@
> >  
> >  ## Category: @Volume
> >  ###########################################################
> >  ##
> > -# @Volume:
> > +# @VolumeIdentifier:
> >  #
> > -# Volume API object.
> > +# An identifier for a Volume object.
> >  #
> >  # @volumeID:         The UUID of the Volume
> >  #
> > @@ -5173,13 +5250,24 @@
> >  #
> >  # @imageID:          The Image associated with @UUID
> >  #
> > -# Since: 4.10.0
> > +# Since: 4.10.1
> >  ##
> > -{'class': 'Volume',
> > +{'type': 'VolumeIdentifier',
> >   'data': {'volumeID': 'UUID', 'storagepoolID': 'UUID',
> >            'storagedomainID': 'UUID', 'imageID': 'UUID'}}
> >  
> >  ##
> > +# @Volume:
> > +#
> > +# Volume API object.
> > +#
> > +# @ident:  The object identifier
> > +#
> > +# Since: 4.10.1
> > +##
> > +{'class': 'Volume', 'ident': 'VolumeIdentifier'}
> > +
> > +##
> >  # @VolumeRole:
> >  #
> >  # An enumeration of Volume Roles.
> > 
> > --
> > Adam Litke <agl at us.ibm.com>
> > IBM Linux Technology Center
> > 
> > 
> 

-- 
Adam Litke <agl at us.ibm.com>
IBM Linux Technology Center



From smizrahi at redhat.com  Thu Nov 29 21:52:14 2012
From: smizrahi at redhat.com (Saggi Mizrahi)
Date: Thu, 29 Nov 2012 16:52:14 -0500 (EST)
Subject: [Engine-devel] RFD: API: Identifying vdsm objects in the
	next-gen API
In-Reply-To: <20121129211840.GA4798@aglitke>
Message-ID: <1105630071.11948174.1354225934560.JavaMail.root@redhat.com>

They are not future proof as the paradigm is completely different.
Storage domain IDs are not static any more (and are not guaranteed to be unique or the same across the cluster.
Image IDs represent the ID of the projected data and not the actual unique path.
Just as an example, to run a VM you give a list of domains that might contain the needed images in the chain and the image ID of the tip.
The paradigm is changed to and most calls get non synchronous number of images and domains.
Further more, the APIs themselves are completely different. So future proofing is not really an issue.

As to making the current API a bit simpler. As I said, making them opaque is problematic as currently the engine is responsible for creating the IDs.
Further more, some calls require you to play with these (making a template instead of a snapshot).
Also, the full chain and topology needs to be completely visible to the engine.

These things, as you said, are problematic. But this is the way things are today.

As for task IDs.
Currently task IDs are only used for storage and they get persisted to disk. This is WRONG and is not the case with the new storage API.
Because we moved to an asynchronous message based protocol (json-rpc over TCP\AMQP) there is no need to generate a task ID. it is built in to json-rpc.
json-rpc specifies that the IDs have to be unique for a client as long as the request is still active.
This is good enough as internally we can have a verb for a client to query it's own running tasks and a verb to query other host tasks by mangling in the client before the ID.
Because the protocol is asynchronous all calls are asynchronous by nature well.
Tasks will no longer be persisted or expected to be persisted. It's the callers responsibility to query the state and see if the operation succeeded or failed if the caller or VDSM died in the middle of the call. The current "cleanTask()" system can't be used when more then one client is using VDSM and will not be used for anything other then legacy storage.

AFAIK Apart from storage all objects IDs are constructed with a single ID, name or alias. VMs, storageConnections, network interfaces. So it's not a real issue.
I agree that in the future we should keep the idiom of pass configuration once, name it, and keep using the name to reference the object.

----- Original Message -----
> From: "Adam Litke" <agl at us.ibm.com>
> To: "Saggi Mizrahi" <smizrahi at redhat.com>
> Cc: engine-devel at linode01.ovirt.org, "Dan Kenigsberg" <danken at redhat.com>, "Federico Simoncelli"
> <fsimonce at redhat.com>, "Ayal Baron" <abaron at redhat.com>, vdsm-devel at lists.fedorahosted.org
> Sent: Thursday, November 29, 2012 4:18:40 PM
> Subject: Re: RFD: API: Identifying vdsm objects in the next-gen API
> 
> On Thu, Nov 29, 2012 at 02:16:42PM -0500, Saggi Mizrahi wrote:
> > This is all only valid for the current storage API the new one
> > doesn't have
> > pools or volumes. Only domains and images.  Also, images and
> > domains are more
> > loosely coupled and make this method problematic.
> 
> I am looking for an incremental way to bridge the differences.  It's
> been 2
> years and we still don't have the revamped storage API so I am
> planning on what
> we have being around for awhile :)  I think that defining object
> identifiers as
> opaque structured types is also future proof.  In the future an
> Image-ng object
> we can drop 'storagepoolID' from the identifier and, if it makes
> sense, remove
> the hard association with a storageDomain as well.  The point behind
> this
> refactoring is to give us the option of coupling multiple UUID's (or
> other data)
> to form a single, opaque identifier.
> 
> > That being said, if we do choose to make the current storage API
> > officially
> > supported I do agree that it looks a bit simpler but for the price
> > of forcing
> > the user to construct these objects before sending the request. I
> > know for a
> > fact that the engine will just create these objects on the fly
> > because they
> > use their own objects to group things logically. This means adding
> > more work
> > instead of removing it.  Most clients will do that anyway as they
> > will use
> > their own DAL to store these relationships.
> > 
> 
> Thanks for bringing up some of these points.  All deserve attention
> so I will
> address each one individually:
> 
> The current API does not yet make an official statement of support
> for anything.
> I want to model the current storage API so that the node level API
> can have the
> same level of functionality as is currently supported.  I am all for
> removing
> deprecated functions and redesigning in-place for a reasonable amount
> of time
> going forward.  In a perfect world, libvdsm-1.0 would release with no
> mention of
> storage pools at all.
> 
> If properly designed, the end-user (including engine) would never be
> constructing these objects itself.  Object identifiers are
> essentially opaque
> structures.  In order to make this possible, we need to make sure
> that the API
> provides all of the functions needed to lookup objects.  So far these
> are:
> 
> StoragePool:	Host.getConnectedStoragePools
> StorageDomain:	Host.getStorageDomains
> Image:		StorageDomain.getImages
> Volume:		StorageDomain.getVolumes / Image.getVolumes
> VM:		Host.getVMList
> Task:		Host.getAllTasks
> 
> All of the above would return object identifiers.
> 
> The other case is for creation of new resources.  In that case, the
> create
> method needs to move to the owning object.  The key example is
> VM.create which
> should move to Host.createVM.  Functions such as Host.createVM could
> still
> accept a vmUUID (because I assume engine does want the ability to set
> this
> explicitly).  However, they should be changed to return either a
> TaskIdentifier
> (if the creation is asynchronous) or a *Identifier (eg. VmIdentifier)
> if the
> object was created synchronously.
> 
> All told, I think the net is less work for clients.  They will no
> longer need to
> model the object associations and relationships because the API will
> take care
> of that automatically.
> 
> > ----- Original Message -----
> > > From: "Adam Litke" <agl at us.ibm.com>
> > > To: vdsm-devel at lists.fedorahosted.org
> > > Cc: engine-devel at linode01.ovirt.org, "Dan Kenigsberg"
> > > <danken at redhat.com>, "Federico Simoncelli"
> > > <fsimonce at redhat.com>, "Saggi Mizrahi" <smizrahi at redhat.com>,
> > > "Ayal Baron" <abaron at redhat.com>
> > > Sent: Thursday, November 29, 2012 12:19:06 PM
> > > Subject: RFD: API: Identifying vdsm objects in the next-gen API
> > > 
> > > Today in vdsm, every object (StoragePool, StorageDomain, VM,
> > > Volume,
> > > etc) is
> > > identified by a single UUID.  On the surface, it seems like this
> > > is
> > > enough info
> > > to properly identify a resource but in practice it's not.  For
> > > example, when you
> > > look at the API's dealing with Volumes, almost all of them
> > > require an
> > > sdUUID,
> > > spUUID, and imgUUID in order to provide proper context for the
> > > operation.
> > > 
> > > Needing to provide these extra UUIDs is a burden on the API user
> > > because knowing
> > > which values to pass requires internal knowledge of the API.  For
> > > example, the
> > > spUUID parameter is almost always just the connected storage
> > > pool.
> > >  Since we
> > > know there can currently be only one connected pool, the value is
> > > known.
> > > 
> > > I would like to move away from needing to understand all of these
> > > relationships
> > > from the end user perspective by encapsulating the extra context
> > > into
> > > new object
> > > identifier types as follows:
> > > 
> > > StoragePoolIdentifier:
> > >     { 'storagepoolID': 'UUID' }
> > > StorageDomainIdentifier:
> > >     { 'storagepoolID*': 'UUID', 'storagedomainID': 'UUID' }
> > > ImageIdentifier:
> > >     { 'storagepoolID*': 'UUID', 'storagedomainID': 'UUID',
> > >     'imageID':
> > >     'UUID' }
> > > VolumeIdentifier:
> > >     { 'storagepoolID*': 'UUID', 'storagedomainID': 'UUID',
> > >       'imageID': 'UUID', 'volumeID': 'UUID' }
> > > TaskIdentifier:
> > >     { 'taskID': 'UUID' }
> > > VMIdentifier:
> > >     { 'vmID': 'UUID' }
> > > 
> > > In the new API, anytime a reference to an object is required, one
> > > of
> > > the above
> > > structures must be passed in place of today's single UUID.  In
> > > many
> > > cases, this
> > > will allow us to reduce the number of parameters to the function
> > > since the
> > > needed contextual parameters (spUUID, etc) will be part of the
> > > object's
> > > identifier.  Similarly, any time the API returns an object
> > > reference
> > > it would
> > > return a *Identifier instead of a bare UUID.
> > > 
> > > These identifier types are basically opaque blobs to the API
> > > users
> > > and are only
> > > ever generated by vdsm itself.  Because of this, we can change
> > > the
> > > internal
> > > structure of the identifier to require new information or (before
> > > freezing the
> > > API) remove fields that no longer make sense.
> > > 
> > > I would greatly appreciate your comments on this proposal.  If it
> > > seems
> > > reasonable, I will revamp the current schema to make the
> > > necessary
> > > changes and
> > > provide the Bridge patch functions to convert between the current
> > > implementation
> > > and the new schema.
> > > 
> > > --- sample schema patch ---
> > > 
> > > commit 48f6b0f0a111dd0b372d211a4e566ce87f375cee
> > > Author: Adam Litke <agl at us.ibm.com>
> > > Date:   Tue Nov 27 14:14:06 2012 -0600
> > > 
> > >     schema: Introduce class identifier types
> > >     
> > >     When calling API methods that belong to a particular class, a
> > >     class instance
> > >     must be indicated by passing a set of identifiers in the
> > >     request.
> > >      The location
> > >     of these parameters within the request is: 'params' ->
> > >     '__obj__'.
> > >      Since this
> > >     set of identifiers must be used together to correctly
> > >     instantiate
> > >     an object, it
> > >     makes sense to define these as proper types within the API.
> > >      Then, functions
> > >     that return an object (or list of objects) can refer to the
> > >     correct type.
> > >     
> > >     Signed-off-by: Adam Litke <agl at us.ibm.com>
> > > 
> > > diff --git a/vdsm_api/vdsmapi-schema.json
> > > b/vdsm_api/vdsmapi-schema.json
> > > index 0418e6e..7e2e851 100644
> > > --- a/vdsm_api/vdsmapi-schema.json
> > > +++ b/vdsm_api/vdsmapi-schema.json
> > > @@ -937,7 +937,7 @@
> > >  # Since: 4.10.0
> > >  ##
> > >  {'command': {'class': 'Host', 'name':
> > >  'getConnectedStoragePools'},
> > > - 'returns': ['StoragePool']}
> > > + 'returns': ['StoragePoolIdentifier']}
> > >  
> > >  ##
> > >  # @BlockDeviceType:
> > > @@ -1572,7 +1572,7 @@
> > >  {'command': {'class': 'Host', 'name': 'getStorageDomains'},
> > >   'data': {'*storagepoolID': 'UUID', '*domainClass':
> > >   'StorageDomainImageClass',
> > >            '*storageType': 'StorageDomainType', '*remotePath':
> > >            'str'},
> > > - 'returns': ['StorageDomain']}
> > > + 'returns': ['StorageDomainIdentifier']}
> > >  
> > >  ##
> > >  # @Host.getStorageRepoStats:
> > > @@ -2406,7 +2406,7 @@
> > >  ##
> > >  {'command': {'class': 'Host', 'name': 'getVMList'},
> > >   'data': {'*vmList': ['UUID']},
> > > - 'returns': ['VM']}
> > > + 'returns': ['VMIdentifier']}
> > >  
> > >  ##
> > >  # @Host.ping:
> > > @@ -2744,10 +2744,11 @@
> > >   'returns': 'ConnectionRefMap'}
> > >  
> > >  ## Category: @ISCSIConnection
> > >  ##################################################
> > > +
> > >  ##
> > > -# @ISCSIConnection:
> > > +# @ISCSIConnectionIdentifier:
> > >  #
> > > -# ISCSIConnection API object.
> > > +# Identifier for an ISCSIConnection object.
> > >  #
> > >  # @host:      A fully-qualified domain name (FQDN) or IP address
> > >  #
> > > @@ -2757,11 +2758,21 @@
> > >  #
> > >  # @password:  #optional The password associated with the given
> > >  username
> > >  #
> > > -# Since: 4.10.0
> > > +# Since: 4.10.1
> > > +##
> > > +{'type': 'ISCSIConnectionIdentifier',
> > > + 'data': {'host': 'str', 'port': 'int', '*user': 'str',
> > > '*password':
> > > 'str'}}
> > > +
> > > +##
> > > +# @ISCSIConnection:
> > > +#
> > > +# ISCSIConnection API object.
> > > +#
> > > +# @ident:  The object identifier
> > > +#
> > > +# Since: 4.10.1
> > >  ##
> > > -{'class': 'ISCSIConnection',
> > > - 'data': {'host': 'str', 'port': 'int', '*user': 'str',
> > > -          '*password': 'str'}}
> > > +{'class': 'ISCSIConnection', 'ident':
> > > 'ISCSIConnectionIdentifier'}
> > >  
> > >  ##
> > >  # @ISCSIConnection.discoverSendTargets:
> > > @@ -2777,10 +2788,11 @@
> > >   'returns': ['str']}
> > >  
> > >  ## Category: @Image
> > >  ############################################################
> > > +
> > >  ##
> > > -# @Image:
> > > +# @ImageIdentifier:
> > >  #
> > > -# Image API object.
> > > +# Identifier for an Image object.
> > >  #
> > >  # @imageID:          The UUID of the Image
> > >  #
> > > @@ -2788,13 +2800,24 @@
> > >  #
> > >  # @storagedomainID:  The UUID of the Storage Domain associated
> > >  with
> > >  the Image
> > >  #
> > > -# Since: 4.10.0
> > > +# Since: 4.10.1
> > >  ##
> > > -{'class': 'Image',
> > > +{'type': 'ImageIdentifier',
> > >   'data': {'imageID': 'UUID', 'storagepoolID': 'UUID',
> > >            'storagedomainID': 'UUID'}}
> > >  
> > >  ##
> > > +# @Image:
> > > +#
> > > +# Image API object.
> > > +#
> > > +# @ident:  The object identifier
> > > +#
> > > +# Since: 4.10.1
> > > +##
> > > +{'class': 'Image', 'ident': 'ImageIdentifier'}
> > > +
> > > +##
> > >  # @Image.delete:
> > >  #
> > >  # Delete the Image and all of its Volumes.
> > > @@ -2843,7 +2866,7 @@
> > >  # Since: 4.10.0
> > >  ##
> > >  {'command': {'class': 'Image', 'name': 'getVolumes'},
> > > - 'returns': ['Volume']}
> > > + 'returns': ['VolumeIdentifier']}
> > >  
> > >  ##
> > >  # @Image.mergeSnapshots:
> > > @@ -2905,17 +2928,26 @@
> > >  
> > >  ## Category: @LVMVolumeGroup
> > >  ###################################################
> > >  ##
> > > +# @LVMVolumeGroupIdentifier:
> > > +#
> > > +# An identifier for a LVMVolumeGroup object.
> > > +#
> > > +# @lvmvolumegroupID:  The volume group UUID
> > > +#
> > > +# Since: 4.10.1
> > > +##
> > > +{'type': 'LVMVolumeGroupIdentifier', 'data':
> > > {'lvmvolumegroupID':
> > > 'UUID'}}
> > > +
> > > +##
> > >  # @LVMVolumeGroup:
> > >  #
> > >  # LVMVolumeGroup API object.
> > >  #
> > > -# @lvmvolumegroupID:  #optional Associate this object with an
> > > existing LVM
> > > -#                     Volume Group
> > > +# @ident:  The object identifier
> > >  #
> > > -# Since: 4.10.0
> > > +# Since: 4.10.1
> > >  ##
> > > -{'class': 'LVMVolumeGroup',
> > > - 'data': {'lvmvolumegroupID': 'UUID'}}
> > > +{'class': 'LVMVolumeGroup', 'ident': 'LVMVolumeGroupIdentifier'}
> > >  
> > >  ##
> > >  # @LVMVolumeGroup.create:
> > > @@ -2964,21 +2996,32 @@
> > >  
> > >  ## Category: @StorageDomain
> > >  ####################################################
> > >  ##
> > > -# @StorageDomain:
> > > +# @StorageDomainIdentifier:
> > >  #
> > > -# StorageDomain API object.
> > > +# An identifier for a StorageDomain object.
> > >  #
> > >  # @storagedomainID:  Associate this object with a new or
> > >  existing
> > >  Storage Domain
> > >  #
> > >  # @storagepoolID:    #optional The Storage Pool UUID if this
> > >  Storage
> > >  Domain is
> > >  #                    attached
> > >  #
> > > -# Since: 4.10.0
> > > +# Since: 4.10.1
> > >  ##
> > > -{'class': 'StorageDomain',
> > > +{'type': 'StorageDomainIdentifier',
> > >   'data': {'storagedomainID': 'UUID', 'storagepoolID': 'UUID'}}
> > >  
> > >  ##
> > > +# @StorageDomain:
> > > +#
> > > +# StorageDomain API object.
> > > +#
> > > +# @ident:  The object identifier
> > > +#
> > > +# Since: 4.10.1
> > > +##
> > > +{'class': 'StorageDomain', 'ident': 'StorageDomainIdentifier'}
> > > +
> > > +##
> > >  # @StorageDomain.activate:
> > >  #
> > >  # Activate an attached but inactive Storage Domain.
> > > @@ -3184,7 +3227,7 @@
> > >  # Since: 4.10.0
> > >  ##
> > >  {'command': {'class': 'StorageDomain', 'name': 'getImages'},
> > > - 'returns': ['Image']}
> > > + 'returns': ['ImageIdentifier']}
> > >  
> > >  ##
> > >  # @StorageDomainRole:
> > > @@ -3295,7 +3338,7 @@
> > >  ##
> > >  {'command': {'class': 'StorageDomain', 'name': 'getVolumes'},
> > >   'data': {'imageID': 'UUID'},
> > > - 'returns': ['Volume']}
> > > + 'returns': ['VolumeIdentifier']}
> > >  
> > >  ##
> > >  # @StorageDomain.setDescription:
> > > @@ -3355,15 +3398,26 @@
> > >  
> > >  ## Category: @StoragePool
> > >  ######################################################
> > >  ##
> > > +# @StoragePoolIdentifier:
> > > +#
> > > +# An identifier for a StoragePool object.
> > > +#
> > > +# @storagepoolID:  Associate this object with a new or existing
> > > Storage Pool
> > > +#
> > > +# Since: 4.10.1
> > > +##
> > > +{'type': 'StoragePoolIdentifier', 'data': {'storagepoolID':
> > > 'UUID'}}
> > > +
> > > +##
> > >  # @StoragePool:
> > >  #
> > >  # StoragePool API object.
> > >  #
> > > -# @storagepoolID:  Associate this object with a new or existing
> > > Storage Pool
> > > +# @ident:  The object identifier
> > >  #
> > > -# Since: 4.10.0
> > > +# Since: 4.10.1
> > >  ##
> > > -{'class': 'StoragePool', 'data': {'storagepoolID': 'UUID'}}
> > > +{'class': 'StoragePool', 'ident': 'StoragePoolIdentifier'}
> > >  
> > >  ##
> > >  # @StoragePool.connect:
> > > @@ -3629,7 +3683,7 @@
> > >  ##
> > >  {'command': {'class': 'StoragePool', 'name':
> > >  'getDomainsContainingImage'},
> > >   'data': {'imageID': 'UUID', '*onlyDataDomains': 'bool'},
> > > - 'returns': ['StorageDomain']}
> > > + 'returns': ['StorageDomainIdentifier']}
> > >  
> > >  ##
> > >  # @StoragePool.getIsoList:
> > > @@ -4058,15 +4112,27 @@
> > >  
> > >  ## Category: @Task
> > >  #############################################################
> > >  ##
> > > +# @TaskIdentifier:
> > > +#
> > > +# An identifier for a Task object.
> > > +#
> > > +# @taskID:  The task UUID
> > > +#
> > > +# Since: 4.10.1
> > > +##
> > > +{'type': 'TaskIdentifier', 'data': {'taskID': 'UUID'}}
> > > +
> > > +
> > > +##
> > >  # @Task:
> > >  #
> > >  # Task API object.
> > >  #
> > > -# @taskID:  Associate this object with an existing Task
> > > +# @ident:  The object identifier
> > >  #
> > > -# Since: 4.10.0
> > > +# Since: 4.10.1
> > >  ##
> > > -{'class': 'Task', 'data': {'taskID': 'UUID'}}
> > > +{'class': 'Task', 'ident': 'TaskIdentifier'}
> > >  
> > >  ##
> > >  # @Task.clear:
> > > @@ -4123,15 +4189,26 @@
> > >  
> > >  ## Category: @VM
> > >  ###############################################################
> > >  ##
> > > +# @VMIdentifier:
> > > +#
> > > +# An identifier for a VM object.
> > > +#
> > > +# @vmID:  The task UUID
> > > +#
> > > +# Since: 4.10.1
> > > +##
> > > +{'type': 'VMIdentifier', 'data': {'vmID': 'UUID'}}
> > > +
> > > +##
> > >  # @VM:
> > >  #
> > >  # VM API object.
> > >  #
> > > -# @vmID:  Associate this object with an existing VM
> > > +# @ident:  The object identifier
> > >  #
> > > -# Since: 4.10.0
> > > +# Since: 4.10.1
> > >  ##
> > > -{'class': 'VM', 'data': {'vmID': 'UUID'}}
> > > +{'class': 'VM', 'ident': 'VMIdentifier'}
> > >  
> > >  ##
> > >  # @DriveSpecVolume:
> > > @@ -5161,9 +5238,9 @@
> > >  
> > >  ## Category: @Volume
> > >  ###########################################################
> > >  ##
> > > -# @Volume:
> > > +# @VolumeIdentifier:
> > >  #
> > > -# Volume API object.
> > > +# An identifier for a Volume object.
> > >  #
> > >  # @volumeID:         The UUID of the Volume
> > >  #
> > > @@ -5173,13 +5250,24 @@
> > >  #
> > >  # @imageID:          The Image associated with @UUID
> > >  #
> > > -# Since: 4.10.0
> > > +# Since: 4.10.1
> > >  ##
> > > -{'class': 'Volume',
> > > +{'type': 'VolumeIdentifier',
> > >   'data': {'volumeID': 'UUID', 'storagepoolID': 'UUID',
> > >            'storagedomainID': 'UUID', 'imageID': 'UUID'}}
> > >  
> > >  ##
> > > +# @Volume:
> > > +#
> > > +# Volume API object.
> > > +#
> > > +# @ident:  The object identifier
> > > +#
> > > +# Since: 4.10.1
> > > +##
> > > +{'class': 'Volume', 'ident': 'VolumeIdentifier'}
> > > +
> > > +##
> > >  # @VolumeRole:
> > >  #
> > >  # An enumeration of Volume Roles.
> > > 
> > > --
> > > Adam Litke <agl at us.ibm.com>
> > > IBM Linux Technology Center
> > > 
> > > 
> > 
> 
> --
> Adam Litke <agl at us.ibm.com>
> IBM Linux Technology Center
> 
> 


From agl at us.ibm.com  Thu Nov 29 22:22:43 2012
From: agl at us.ibm.com (Adam Litke)
Date: Thu, 29 Nov 2012 16:22:43 -0600
Subject: [Engine-devel] RFD: API: Identifying vdsm objects in the
	next-gen API
In-Reply-To: <1105630071.11948174.1354225934560.JavaMail.root@redhat.com>
References: <20121129211840.GA4798@aglitke>
	<1105630071.11948174.1354225934560.JavaMail.root@redhat.com>
Message-ID: <20121129222243.GB4798@aglitke>

On Thu, Nov 29, 2012 at 04:52:14PM -0500, Saggi Mizrahi wrote:
> They are not future proof as the paradigm is completely different.  Storage
> domain IDs are not static any more (and are not guaranteed to be unique or the
> same across the cluster.  Image IDs represent the ID of the projected data and
> not the actual unique path.  Just as an example, to run a VM you give a list
> of domains that might contain the needed images in the chain and the image ID
> of the tip.  The paradigm is changed to and most calls get non synchronous
> number of images and domains.  Further more, the APIs themselves are
> completely different. So future proofing is not really an issue.

I don't understand this at all.  Perhaps we could all use some education on the
architecture of the planned architectural changes.  If I can pass an arbitrary
list of domainIDs that _might_ contain the data, why wouldn't I just pass all
of them every time?  In that case, why are they even required since vdsm would
have to search anyway?

> As to making the current API a bit simpler. As I said, making them opaque is
> problematic as currently the engine is responsible for creating the IDs.

As I mentioned in my last post, engine still can specify the ID's when the
object is first created.  From that point forward the ID never changes so it can
be baked into the identifier.

> Further more, some calls require you to play with these (making a template
> instead of a snapshot).  Also, the full chain and topology needs to be
> completely visible to the engine.

Please provide a specific example of how you play with the IDs.  I can guess
where you are going, but I don't want to divert the thread.

> These things, as you said, are problematic. But this is the way things are
> today.

We are changing them.

> As for task IDs.  Currently task IDs are only used for storage and they get
> persisted to disk. This is WRONG and is not the case with the new storage API.
> Because we moved to an asynchronous message based protocol (json-rpc over
> TCP\AMQP) there is no need to generate a task ID. it is built in to json-rpc.
> json-rpc specifies that the IDs have to be unique for a client as long as the
> request is still active.  This is good enough as internally we can have a verb
> for a client to query it's own running tasks and a verb to query other host
> tasks by mangling in the client before the ID.  Because the protocol is

So this would rely on the client keeping the connection open and as soon as it
disconnects it would lose the ability to query tasks from before the connection
went down?  I don't know if it's a good idea to conflate message ID's with task
ID's.  While the protocol can operate asynchronously, some calls have
synchronous semantics and others have asynchronous semantics.  I would expect
sync calls to return their data immediately and async calls to return
immediately with either: an error code, or an 'operation started' message and
associated ID for querying the status of the operation.

> asynchronous all calls are asynchronous by nature well.  Tasks will no longer
> be persisted or expected to be persisted. It's the callers responsibility to
> query the state and see if the operation succeeded or failed if the caller or
> VDSM died in the middle of the call. The current "cleanTask()" system can't be
> used when more then one client is using VDSM and will not be used for anything
> other then legacy storage.

I agree about not persisting tasks in the future.  Although I think finished
tasks should remain in memory for some time so they can be queried by a client
who must reconnect.

> AFAIK Apart from storage all objects IDs are constructed with a single ID,
> name or alias. VMs, storageConnections, network interfaces. So it's not a real
> issue.  I agree that in the future we should keep the idiom of pass
> configuration once, name it, and keep using the name to reference the object.

Yes, storage is the major problem here.

> ----- Original Message -----
> > From: "Adam Litke" <agl at us.ibm.com>
> > To: "Saggi Mizrahi" <smizrahi at redhat.com>
> > Cc: engine-devel at linode01.ovirt.org, "Dan Kenigsberg" <danken at redhat.com>, "Federico Simoncelli"
> > <fsimonce at redhat.com>, "Ayal Baron" <abaron at redhat.com>, vdsm-devel at lists.fedorahosted.org
> > Sent: Thursday, November 29, 2012 4:18:40 PM
> > Subject: Re: RFD: API: Identifying vdsm objects in the next-gen API
> > 
> > On Thu, Nov 29, 2012 at 02:16:42PM -0500, Saggi Mizrahi wrote:
> > > This is all only valid for the current storage API the new one
> > > doesn't have
> > > pools or volumes. Only domains and images.  Also, images and
> > > domains are more
> > > loosely coupled and make this method problematic.
> > 
> > I am looking for an incremental way to bridge the differences.  It's
> > been 2
> > years and we still don't have the revamped storage API so I am
> > planning on what
> > we have being around for awhile :)  I think that defining object
> > identifiers as
> > opaque structured types is also future proof.  In the future an
> > Image-ng object
> > we can drop 'storagepoolID' from the identifier and, if it makes
> > sense, remove
> > the hard association with a storageDomain as well.  The point behind
> > this
> > refactoring is to give us the option of coupling multiple UUID's (or
> > other data)
> > to form a single, opaque identifier.
> > 
> > > That being said, if we do choose to make the current storage API
> > > officially
> > > supported I do agree that it looks a bit simpler but for the price
> > > of forcing
> > > the user to construct these objects before sending the request. I
> > > know for a
> > > fact that the engine will just create these objects on the fly
> > > because they
> > > use their own objects to group things logically. This means adding
> > > more work
> > > instead of removing it.  Most clients will do that anyway as they
> > > will use
> > > their own DAL to store these relationships.
> > > 
> > 
> > Thanks for bringing up some of these points.  All deserve attention
> > so I will
> > address each one individually:
> > 
> > The current API does not yet make an official statement of support
> > for anything.
> > I want to model the current storage API so that the node level API
> > can have the
> > same level of functionality as is currently supported.  I am all for
> > removing
> > deprecated functions and redesigning in-place for a reasonable amount
> > of time
> > going forward.  In a perfect world, libvdsm-1.0 would release with no
> > mention of
> > storage pools at all.
> > 
> > If properly designed, the end-user (including engine) would never be
> > constructing these objects itself.  Object identifiers are
> > essentially opaque
> > structures.  In order to make this possible, we need to make sure
> > that the API
> > provides all of the functions needed to lookup objects.  So far these
> > are:
> > 
> > StoragePool:	Host.getConnectedStoragePools
> > StorageDomain:	Host.getStorageDomains
> > Image:		StorageDomain.getImages
> > Volume:		StorageDomain.getVolumes / Image.getVolumes
> > VM:		Host.getVMList
> > Task:		Host.getAllTasks
> > 
> > All of the above would return object identifiers.
> > 
> > The other case is for creation of new resources.  In that case, the
> > create
> > method needs to move to the owning object.  The key example is
> > VM.create which
> > should move to Host.createVM.  Functions such as Host.createVM could
> > still
> > accept a vmUUID (because I assume engine does want the ability to set
> > this
> > explicitly).  However, they should be changed to return either a
> > TaskIdentifier
> > (if the creation is asynchronous) or a *Identifier (eg. VmIdentifier)
> > if the
> > object was created synchronously.
> > 
> > All told, I think the net is less work for clients.  They will no
> > longer need to
> > model the object associations and relationships because the API will
> > take care
> > of that automatically.
> > 
> > > ----- Original Message -----
> > > > From: "Adam Litke" <agl at us.ibm.com>
> > > > To: vdsm-devel at lists.fedorahosted.org
> > > > Cc: engine-devel at linode01.ovirt.org, "Dan Kenigsberg"
> > > > <danken at redhat.com>, "Federico Simoncelli"
> > > > <fsimonce at redhat.com>, "Saggi Mizrahi" <smizrahi at redhat.com>,
> > > > "Ayal Baron" <abaron at redhat.com>
> > > > Sent: Thursday, November 29, 2012 12:19:06 PM
> > > > Subject: RFD: API: Identifying vdsm objects in the next-gen API
> > > > 
> > > > Today in vdsm, every object (StoragePool, StorageDomain, VM,
> > > > Volume,
> > > > etc) is
> > > > identified by a single UUID.  On the surface, it seems like this
> > > > is
> > > > enough info
> > > > to properly identify a resource but in practice it's not.  For
> > > > example, when you
> > > > look at the API's dealing with Volumes, almost all of them
> > > > require an
> > > > sdUUID,
> > > > spUUID, and imgUUID in order to provide proper context for the
> > > > operation.
> > > > 
> > > > Needing to provide these extra UUIDs is a burden on the API user
> > > > because knowing
> > > > which values to pass requires internal knowledge of the API.  For
> > > > example, the
> > > > spUUID parameter is almost always just the connected storage
> > > > pool.
> > > >  Since we
> > > > know there can currently be only one connected pool, the value is
> > > > known.
> > > > 
> > > > I would like to move away from needing to understand all of these
> > > > relationships
> > > > from the end user perspective by encapsulating the extra context
> > > > into
> > > > new object
> > > > identifier types as follows:
> > > > 
> > > > StoragePoolIdentifier:
> > > >     { 'storagepoolID': 'UUID' }
> > > > StorageDomainIdentifier:
> > > >     { 'storagepoolID*': 'UUID', 'storagedomainID': 'UUID' }
> > > > ImageIdentifier:
> > > >     { 'storagepoolID*': 'UUID', 'storagedomainID': 'UUID',
> > > >     'imageID':
> > > >     'UUID' }
> > > > VolumeIdentifier:
> > > >     { 'storagepoolID*': 'UUID', 'storagedomainID': 'UUID',
> > > >       'imageID': 'UUID', 'volumeID': 'UUID' }
> > > > TaskIdentifier:
> > > >     { 'taskID': 'UUID' }
> > > > VMIdentifier:
> > > >     { 'vmID': 'UUID' }
> > > > 
> > > > In the new API, anytime a reference to an object is required, one
> > > > of
> > > > the above
> > > > structures must be passed in place of today's single UUID.  In
> > > > many
> > > > cases, this
> > > > will allow us to reduce the number of parameters to the function
> > > > since the
> > > > needed contextual parameters (spUUID, etc) will be part of the
> > > > object's
> > > > identifier.  Similarly, any time the API returns an object
> > > > reference
> > > > it would
> > > > return a *Identifier instead of a bare UUID.
> > > > 
> > > > These identifier types are basically opaque blobs to the API
> > > > users
> > > > and are only
> > > > ever generated by vdsm itself.  Because of this, we can change
> > > > the
> > > > internal
> > > > structure of the identifier to require new information or (before
> > > > freezing the
> > > > API) remove fields that no longer make sense.
> > > > 
> > > > I would greatly appreciate your comments on this proposal.  If it
> > > > seems
> > > > reasonable, I will revamp the current schema to make the
> > > > necessary
> > > > changes and
> > > > provide the Bridge patch functions to convert between the current
> > > > implementation
> > > > and the new schema.
> > > > 
> > > > --- sample schema patch ---
> > > > 
> > > > commit 48f6b0f0a111dd0b372d211a4e566ce87f375cee
> > > > Author: Adam Litke <agl at us.ibm.com>
> > > > Date:   Tue Nov 27 14:14:06 2012 -0600
> > > > 
> > > >     schema: Introduce class identifier types
> > > >     
> > > >     When calling API methods that belong to a particular class, a
> > > >     class instance
> > > >     must be indicated by passing a set of identifiers in the
> > > >     request.
> > > >      The location
> > > >     of these parameters within the request is: 'params' ->
> > > >     '__obj__'.
> > > >      Since this
> > > >     set of identifiers must be used together to correctly
> > > >     instantiate
> > > >     an object, it
> > > >     makes sense to define these as proper types within the API.
> > > >      Then, functions
> > > >     that return an object (or list of objects) can refer to the
> > > >     correct type.
> > > >     
> > > >     Signed-off-by: Adam Litke <agl at us.ibm.com>
> > > > 
> > > > diff --git a/vdsm_api/vdsmapi-schema.json
> > > > b/vdsm_api/vdsmapi-schema.json
> > > > index 0418e6e..7e2e851 100644
> > > > --- a/vdsm_api/vdsmapi-schema.json
> > > > +++ b/vdsm_api/vdsmapi-schema.json
> > > > @@ -937,7 +937,7 @@
> > > >  # Since: 4.10.0
> > > >  ##
> > > >  {'command': {'class': 'Host', 'name':
> > > >  'getConnectedStoragePools'},
> > > > - 'returns': ['StoragePool']}
> > > > + 'returns': ['StoragePoolIdentifier']}
> > > >  
> > > >  ##
> > > >  # @BlockDeviceType:
> > > > @@ -1572,7 +1572,7 @@
> > > >  {'command': {'class': 'Host', 'name': 'getStorageDomains'},
> > > >   'data': {'*storagepoolID': 'UUID', '*domainClass':
> > > >   'StorageDomainImageClass',
> > > >            '*storageType': 'StorageDomainType', '*remotePath':
> > > >            'str'},
> > > > - 'returns': ['StorageDomain']}
> > > > + 'returns': ['StorageDomainIdentifier']}
> > > >  
> > > >  ##
> > > >  # @Host.getStorageRepoStats:
> > > > @@ -2406,7 +2406,7 @@
> > > >  ##
> > > >  {'command': {'class': 'Host', 'name': 'getVMList'},
> > > >   'data': {'*vmList': ['UUID']},
> > > > - 'returns': ['VM']}
> > > > + 'returns': ['VMIdentifier']}
> > > >  
> > > >  ##
> > > >  # @Host.ping:
> > > > @@ -2744,10 +2744,11 @@
> > > >   'returns': 'ConnectionRefMap'}
> > > >  
> > > >  ## Category: @ISCSIConnection
> > > >  ##################################################
> > > > +
> > > >  ##
> > > > -# @ISCSIConnection:
> > > > +# @ISCSIConnectionIdentifier:
> > > >  #
> > > > -# ISCSIConnection API object.
> > > > +# Identifier for an ISCSIConnection object.
> > > >  #
> > > >  # @host:      A fully-qualified domain name (FQDN) or IP address
> > > >  #
> > > > @@ -2757,11 +2758,21 @@
> > > >  #
> > > >  # @password:  #optional The password associated with the given
> > > >  username
> > > >  #
> > > > -# Since: 4.10.0
> > > > +# Since: 4.10.1
> > > > +##
> > > > +{'type': 'ISCSIConnectionIdentifier',
> > > > + 'data': {'host': 'str', 'port': 'int', '*user': 'str',
> > > > '*password':
> > > > 'str'}}
> > > > +
> > > > +##
> > > > +# @ISCSIConnection:
> > > > +#
> > > > +# ISCSIConnection API object.
> > > > +#
> > > > +# @ident:  The object identifier
> > > > +#
> > > > +# Since: 4.10.1
> > > >  ##
> > > > -{'class': 'ISCSIConnection',
> > > > - 'data': {'host': 'str', 'port': 'int', '*user': 'str',
> > > > -          '*password': 'str'}}
> > > > +{'class': 'ISCSIConnection', 'ident':
> > > > 'ISCSIConnectionIdentifier'}
> > > >  
> > > >  ##
> > > >  # @ISCSIConnection.discoverSendTargets:
> > > > @@ -2777,10 +2788,11 @@
> > > >   'returns': ['str']}
> > > >  
> > > >  ## Category: @Image
> > > >  ############################################################
> > > > +
> > > >  ##
> > > > -# @Image:
> > > > +# @ImageIdentifier:
> > > >  #
> > > > -# Image API object.
> > > > +# Identifier for an Image object.
> > > >  #
> > > >  # @imageID:          The UUID of the Image
> > > >  #
> > > > @@ -2788,13 +2800,24 @@
> > > >  #
> > > >  # @storagedomainID:  The UUID of the Storage Domain associated
> > > >  with
> > > >  the Image
> > > >  #
> > > > -# Since: 4.10.0
> > > > +# Since: 4.10.1
> > > >  ##
> > > > -{'class': 'Image',
> > > > +{'type': 'ImageIdentifier',
> > > >   'data': {'imageID': 'UUID', 'storagepoolID': 'UUID',
> > > >            'storagedomainID': 'UUID'}}
> > > >  
> > > >  ##
> > > > +# @Image:
> > > > +#
> > > > +# Image API object.
> > > > +#
> > > > +# @ident:  The object identifier
> > > > +#
> > > > +# Since: 4.10.1
> > > > +##
> > > > +{'class': 'Image', 'ident': 'ImageIdentifier'}
> > > > +
> > > > +##
> > > >  # @Image.delete:
> > > >  #
> > > >  # Delete the Image and all of its Volumes.
> > > > @@ -2843,7 +2866,7 @@
> > > >  # Since: 4.10.0
> > > >  ##
> > > >  {'command': {'class': 'Image', 'name': 'getVolumes'},
> > > > - 'returns': ['Volume']}
> > > > + 'returns': ['VolumeIdentifier']}
> > > >  
> > > >  ##
> > > >  # @Image.mergeSnapshots:
> > > > @@ -2905,17 +2928,26 @@
> > > >  
> > > >  ## Category: @LVMVolumeGroup
> > > >  ###################################################
> > > >  ##
> > > > +# @LVMVolumeGroupIdentifier:
> > > > +#
> > > > +# An identifier for a LVMVolumeGroup object.
> > > > +#
> > > > +# @lvmvolumegroupID:  The volume group UUID
> > > > +#
> > > > +# Since: 4.10.1
> > > > +##
> > > > +{'type': 'LVMVolumeGroupIdentifier', 'data':
> > > > {'lvmvolumegroupID':
> > > > 'UUID'}}
> > > > +
> > > > +##
> > > >  # @LVMVolumeGroup:
> > > >  #
> > > >  # LVMVolumeGroup API object.
> > > >  #
> > > > -# @lvmvolumegroupID:  #optional Associate this object with an
> > > > existing LVM
> > > > -#                     Volume Group
> > > > +# @ident:  The object identifier
> > > >  #
> > > > -# Since: 4.10.0
> > > > +# Since: 4.10.1
> > > >  ##
> > > > -{'class': 'LVMVolumeGroup',
> > > > - 'data': {'lvmvolumegroupID': 'UUID'}}
> > > > +{'class': 'LVMVolumeGroup', 'ident': 'LVMVolumeGroupIdentifier'}
> > > >  
> > > >  ##
> > > >  # @LVMVolumeGroup.create:
> > > > @@ -2964,21 +2996,32 @@
> > > >  
> > > >  ## Category: @StorageDomain
> > > >  ####################################################
> > > >  ##
> > > > -# @StorageDomain:
> > > > +# @StorageDomainIdentifier:
> > > >  #
> > > > -# StorageDomain API object.
> > > > +# An identifier for a StorageDomain object.
> > > >  #
> > > >  # @storagedomainID:  Associate this object with a new or
> > > >  existing
> > > >  Storage Domain
> > > >  #
> > > >  # @storagepoolID:    #optional The Storage Pool UUID if this
> > > >  Storage
> > > >  Domain is
> > > >  #                    attached
> > > >  #
> > > > -# Since: 4.10.0
> > > > +# Since: 4.10.1
> > > >  ##
> > > > -{'class': 'StorageDomain',
> > > > +{'type': 'StorageDomainIdentifier',
> > > >   'data': {'storagedomainID': 'UUID', 'storagepoolID': 'UUID'}}
> > > >  
> > > >  ##
> > > > +# @StorageDomain:
> > > > +#
> > > > +# StorageDomain API object.
> > > > +#
> > > > +# @ident:  The object identifier
> > > > +#
> > > > +# Since: 4.10.1
> > > > +##
> > > > +{'class': 'StorageDomain', 'ident': 'StorageDomainIdentifier'}
> > > > +
> > > > +##
> > > >  # @StorageDomain.activate:
> > > >  #
> > > >  # Activate an attached but inactive Storage Domain.
> > > > @@ -3184,7 +3227,7 @@
> > > >  # Since: 4.10.0
> > > >  ##
> > > >  {'command': {'class': 'StorageDomain', 'name': 'getImages'},
> > > > - 'returns': ['Image']}
> > > > + 'returns': ['ImageIdentifier']}
> > > >  
> > > >  ##
> > > >  # @StorageDomainRole:
> > > > @@ -3295,7 +3338,7 @@
> > > >  ##
> > > >  {'command': {'class': 'StorageDomain', 'name': 'getVolumes'},
> > > >   'data': {'imageID': 'UUID'},
> > > > - 'returns': ['Volume']}
> > > > + 'returns': ['VolumeIdentifier']}
> > > >  
> > > >  ##
> > > >  # @StorageDomain.setDescription:
> > > > @@ -3355,15 +3398,26 @@
> > > >  
> > > >  ## Category: @StoragePool
> > > >  ######################################################
> > > >  ##
> > > > +# @StoragePoolIdentifier:
> > > > +#
> > > > +# An identifier for a StoragePool object.
> > > > +#
> > > > +# @storagepoolID:  Associate this object with a new or existing
> > > > Storage Pool
> > > > +#
> > > > +# Since: 4.10.1
> > > > +##
> > > > +{'type': 'StoragePoolIdentifier', 'data': {'storagepoolID':
> > > > 'UUID'}}
> > > > +
> > > > +##
> > > >  # @StoragePool:
> > > >  #
> > > >  # StoragePool API object.
> > > >  #
> > > > -# @storagepoolID:  Associate this object with a new or existing
> > > > Storage Pool
> > > > +# @ident:  The object identifier
> > > >  #
> > > > -# Since: 4.10.0
> > > > +# Since: 4.10.1
> > > >  ##
> > > > -{'class': 'StoragePool', 'data': {'storagepoolID': 'UUID'}}
> > > > +{'class': 'StoragePool', 'ident': 'StoragePoolIdentifier'}
> > > >  
> > > >  ##
> > > >  # @StoragePool.connect:
> > > > @@ -3629,7 +3683,7 @@
> > > >  ##
> > > >  {'command': {'class': 'StoragePool', 'name':
> > > >  'getDomainsContainingImage'},
> > > >   'data': {'imageID': 'UUID', '*onlyDataDomains': 'bool'},
> > > > - 'returns': ['StorageDomain']}
> > > > + 'returns': ['StorageDomainIdentifier']}
> > > >  
> > > >  ##
> > > >  # @StoragePool.getIsoList:
> > > > @@ -4058,15 +4112,27 @@
> > > >  
> > > >  ## Category: @Task
> > > >  #############################################################
> > > >  ##
> > > > +# @TaskIdentifier:
> > > > +#
> > > > +# An identifier for a Task object.
> > > > +#
> > > > +# @taskID:  The task UUID
> > > > +#
> > > > +# Since: 4.10.1
> > > > +##
> > > > +{'type': 'TaskIdentifier', 'data': {'taskID': 'UUID'}}
> > > > +
> > > > +
> > > > +##
> > > >  # @Task:
> > > >  #
> > > >  # Task API object.
> > > >  #
> > > > -# @taskID:  Associate this object with an existing Task
> > > > +# @ident:  The object identifier
> > > >  #
> > > > -# Since: 4.10.0
> > > > +# Since: 4.10.1
> > > >  ##
> > > > -{'class': 'Task', 'data': {'taskID': 'UUID'}}
> > > > +{'class': 'Task', 'ident': 'TaskIdentifier'}
> > > >  
> > > >  ##
> > > >  # @Task.clear:
> > > > @@ -4123,15 +4189,26 @@
> > > >  
> > > >  ## Category: @VM
> > > >  ###############################################################
> > > >  ##
> > > > +# @VMIdentifier:
> > > > +#
> > > > +# An identifier for a VM object.
> > > > +#
> > > > +# @vmID:  The task UUID
> > > > +#
> > > > +# Since: 4.10.1
> > > > +##
> > > > +{'type': 'VMIdentifier', 'data': {'vmID': 'UUID'}}
> > > > +
> > > > +##
> > > >  # @VM:
> > > >  #
> > > >  # VM API object.
> > > >  #
> > > > -# @vmID:  Associate this object with an existing VM
> > > > +# @ident:  The object identifier
> > > >  #
> > > > -# Since: 4.10.0
> > > > +# Since: 4.10.1
> > > >  ##
> > > > -{'class': 'VM', 'data': {'vmID': 'UUID'}}
> > > > +{'class': 'VM', 'ident': 'VMIdentifier'}
> > > >  
> > > >  ##
> > > >  # @DriveSpecVolume:
> > > > @@ -5161,9 +5238,9 @@
> > > >  
> > > >  ## Category: @Volume
> > > >  ###########################################################
> > > >  ##
> > > > -# @Volume:
> > > > +# @VolumeIdentifier:
> > > >  #
> > > > -# Volume API object.
> > > > +# An identifier for a Volume object.
> > > >  #
> > > >  # @volumeID:         The UUID of the Volume
> > > >  #
> > > > @@ -5173,13 +5250,24 @@
> > > >  #
> > > >  # @imageID:          The Image associated with @UUID
> > > >  #
> > > > -# Since: 4.10.0
> > > > +# Since: 4.10.1
> > > >  ##
> > > > -{'class': 'Volume',
> > > > +{'type': 'VolumeIdentifier',
> > > >   'data': {'volumeID': 'UUID', 'storagepoolID': 'UUID',
> > > >            'storagedomainID': 'UUID', 'imageID': 'UUID'}}
> > > >  
> > > >  ##
> > > > +# @Volume:
> > > > +#
> > > > +# Volume API object.
> > > > +#
> > > > +# @ident:  The object identifier
> > > > +#
> > > > +# Since: 4.10.1
> > > > +##
> > > > +{'class': 'Volume', 'ident': 'VolumeIdentifier'}
> > > > +
> > > > +##
> > > >  # @VolumeRole:
> > > >  #
> > > >  # An enumeration of Volume Roles.
> > > > 
> > > > --
> > > > Adam Litke <agl at us.ibm.com>
> > > > IBM Linux Technology Center
> > > > 
> > > > 
> > > 
> > 
> > --
> > Adam Litke <agl at us.ibm.com>
> > IBM Linux Technology Center
> > 
> > 
> 

-- 
Adam Litke <agl at us.ibm.com>
IBM Linux Technology Center



From smizrahi at redhat.com  Thu Nov 29 22:59:09 2012
From: smizrahi at redhat.com (Saggi Mizrahi)
Date: Thu, 29 Nov 2012 17:59:09 -0500 (EST)
Subject: [Engine-devel] RFD: API: Identifying vdsm objects in the
	next-gen API
In-Reply-To: <20121129222243.GB4798@aglitke>
Message-ID: <1990527255.11981218.1354229949253.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Adam Litke" <agl at us.ibm.com>
> To: "Saggi Mizrahi" <smizrahi at redhat.com>
> Cc: engine-devel at linode01.ovirt.org, "Dan Kenigsberg" <danken at redhat.com>, "Federico Simoncelli"
> <fsimonce at redhat.com>, "Ayal Baron" <abaron at redhat.com>, vdsm-devel at lists.fedorahosted.org
> Sent: Thursday, November 29, 2012 5:22:43 PM
> Subject: Re: RFD: API: Identifying vdsm objects in the next-gen API
> 
> On Thu, Nov 29, 2012 at 04:52:14PM -0500, Saggi Mizrahi wrote:
> > They are not future proof as the paradigm is completely different.
> >  Storage
> > domain IDs are not static any more (and are not guaranteed to be
> > unique or the
> > same across the cluster.  Image IDs represent the ID of the
> > projected data and
> > not the actual unique path.  Just as an example, to run a VM you
> > give a list
> > of domains that might contain the needed images in the chain and
> > the image ID
> > of the tip.  The paradigm is changed to and most calls get non
> > synchronous
> > number of images and domains.  Further more, the APIs themselves
> > are
> > completely different. So future proofing is not really an issue.
> 
> I don't understand this at all.  Perhaps we could all use some
> education on the
> architecture of the planned architectural changes.  If I can pass an
> arbitrary
> list of domainIDs that _might_ contain the data, why wouldn't I just
> pass all
> of them every time?  In that case, why are they even required since
> vdsm would
> have to search anyway?
It's for optimization mostly, the engine usually has a good idea of where stuff are, having it give hints to VDSM can speed up the search process.
also, then engines knows how transient some storage pieces are. If you have a domain that is only there for backup or "owned" by another manager sharing the host, you don't want you VMs using the disks that are on that storage effectively preventing it from being removed (though we do have plans to have qemu switch base snapshots at runtime for just that).
> 
> > As to making the current API a bit simpler. As I said, making them
> > opaque is
> > problematic as currently the engine is responsible for creating the
> > IDs.
> 
> As I mentioned in my last post, engine still can specify the ID's
> when the
> object is first created.  From that point forward the ID never
> changes so it can
> be baked into the identifier.
Where will this identifier be persisted?
> 
> > Further more, some calls require you to play with these (making a
> > template
> > instead of a snapshot).  Also, the full chain and topology needs to
> > be
> > completely visible to the engine.
> 
> Please provide a specific example of how you play with the IDs.  I
> can guess
> where you are going, but I don't want to divert the thread.
The relationship between volumes and images is deceptive at the moment.
IMG is the chain and volume is a member, IMGUUID is only used to for verification and to detect when we hit a template going up the chain.
When you do operation on images assumptions are being guaranteed about the resulting IDs. When you copy an image, you assume to know all the new IDs as they remain the same.
With your method I can't tell what the new "opaque" result is going to be.
Preview mode (another abomination being deprecated) relies on the disconnect between imgUUID and volUUID.
Live migration currently moves a lot of the responsibility to the engine.
> 
> > These things, as you said, are problematic. But this is the way
> > things are
> > today.
> 
> We are changing them.
Any intermediary step is needlessly problematic for existing clients.
Work is already in progress for fixing the API properly, making some calls a bit nicer isn't an excuse to start making more compatibility code in the engine.
> 
> > As for task IDs.  Currently task IDs are only used for storage and
> > they get
> > persisted to disk. This is WRONG and is not the case with the new
> > storage API.
> > Because we moved to an asynchronous message based protocol
> > (json-rpc over
> > TCP\AMQP) there is no need to generate a task ID. it is built in to
> > json-rpc.
> > json-rpc specifies that the IDs have to be unique for a client as
> > long as the
> > request is still active.  This is good enough as internally we can
> > have a verb
> > for a client to query it's own running tasks and a verb to query
> > other host
> > tasks by mangling in the client before the ID.  Because the
> > protocol is
> 
> So this would rely on the client keeping the connection open and as
> soon as it
> disconnects it would lose the ability to query tasks from before the
> connection
> went down?  I don't know if it's a good idea to conflate message ID's
> with task
> ID's.  While the protocol can operate asynchronously, some calls have
> synchronous semantics and others have asynchronous semantics.  I
> would expect
> sync calls to return their data immediately and async calls to return
> immediately with either: an error code, or an 'operation started'
> message and
> associated ID for querying the status of the operation.
Upon reflection I agree that having the request ID unique per client is problematic and we need to make sure they are unique per host at every point in time.
> 
> > asynchronous all calls are asynchronous by nature well.  Tasks will
> > no longer
> > be persisted or expected to be persisted. It's the callers
> > responsibility to
> > query the state and see if the operation succeeded or failed if the
> > caller or
> > VDSM died in the middle of the call. The current "cleanTask()"
> > system can't be
> > used when more then one client is using VDSM and will not be used
> > for anything
> > other then legacy storage.
> 
> I agree about not persisting tasks in the future.  Although I think
> finished
> tasks should remain in memory for some time so they can be queried by
> a client
> who must reconnect.
I am completely against keeping the task for a nominal amount of time, it just makes another flow.
You need to have code that makes up in case you missed that window any way then just have one recovery code path, when VDSM looses you task or you lose VDSM recover immediately.
Also, because task IDs can be reused once they expire assuming that the task you encountered is the same task you originally sent is problematic.

If you expect intermittent connections use the AMQP backend (which will support broker-less p2p communication as well)
> 
> > AFAIK Apart from storage all objects IDs are constructed with a
> > single ID,
> > name or alias. VMs, storageConnections, network interfaces. So it's
> > not a real
> > issue.  I agree that in the future we should keep the idiom of pass
> > configuration once, name it, and keep using the name to reference
> > the object.
> 
> Yes, storage is the major problem here.
And, as I said, changing the API is problematic for migration of current users.
> 
> > ----- Original Message -----
> > > From: "Adam Litke" <agl at us.ibm.com>
> > > To: "Saggi Mizrahi" <smizrahi at redhat.com>
> > > Cc: engine-devel at linode01.ovirt.org, "Dan Kenigsberg"
> > > <danken at redhat.com>, "Federico Simoncelli"
> > > <fsimonce at redhat.com>, "Ayal Baron" <abaron at redhat.com>,
> > > vdsm-devel at lists.fedorahosted.org
> > > Sent: Thursday, November 29, 2012 4:18:40 PM
> > > Subject: Re: RFD: API: Identifying vdsm objects in the next-gen
> > > API
> > > 
> > > On Thu, Nov 29, 2012 at 02:16:42PM -0500, Saggi Mizrahi wrote:
> > > > This is all only valid for the current storage API the new one
> > > > doesn't have
> > > > pools or volumes. Only domains and images.  Also, images and
> > > > domains are more
> > > > loosely coupled and make this method problematic.
> > > 
> > > I am looking for an incremental way to bridge the differences.
> > >  It's
> > > been 2
> > > years and we still don't have the revamped storage API so I am
> > > planning on what
> > > we have being around for awhile :)  I think that defining object
> > > identifiers as
> > > opaque structured types is also future proof.  In the future an
> > > Image-ng object
> > > we can drop 'storagepoolID' from the identifier and, if it makes
> > > sense, remove
> > > the hard association with a storageDomain as well.  The point
> > > behind
> > > this
> > > refactoring is to give us the option of coupling multiple UUID's
> > > (or
> > > other data)
> > > to form a single, opaque identifier.
> > > 
> > > > That being said, if we do choose to make the current storage
> > > > API
> > > > officially
> > > > supported I do agree that it looks a bit simpler but for the
> > > > price
> > > > of forcing
> > > > the user to construct these objects before sending the request.
> > > > I
> > > > know for a
> > > > fact that the engine will just create these objects on the fly
> > > > because they
> > > > use their own objects to group things logically. This means
> > > > adding
> > > > more work
> > > > instead of removing it.  Most clients will do that anyway as
> > > > they
> > > > will use
> > > > their own DAL to store these relationships.
> > > > 
> > > 
> > > Thanks for bringing up some of these points.  All deserve
> > > attention
> > > so I will
> > > address each one individually:
> > > 
> > > The current API does not yet make an official statement of
> > > support
> > > for anything.
> > > I want to model the current storage API so that the node level
> > > API
> > > can have the
> > > same level of functionality as is currently supported.  I am all
> > > for
> > > removing
> > > deprecated functions and redesigning in-place for a reasonable
> > > amount
> > > of time
> > > going forward.  In a perfect world, libvdsm-1.0 would release
> > > with no
> > > mention of
> > > storage pools at all.
> > > 
> > > If properly designed, the end-user (including engine) would never
> > > be
> > > constructing these objects itself.  Object identifiers are
> > > essentially opaque
> > > structures.  In order to make this possible, we need to make sure
> > > that the API
> > > provides all of the functions needed to lookup objects.  So far
> > > these
> > > are:
> > > 
> > > StoragePool:	Host.getConnectedStoragePools
> > > StorageDomain:	Host.getStorageDomains
> > > Image:		StorageDomain.getImages
> > > Volume:		StorageDomain.getVolumes / Image.getVolumes
> > > VM:		Host.getVMList
> > > Task:		Host.getAllTasks
> > > 
> > > All of the above would return object identifiers.
> > > 
> > > The other case is for creation of new resources.  In that case,
> > > the
> > > create
> > > method needs to move to the owning object.  The key example is
> > > VM.create which
> > > should move to Host.createVM.  Functions such as Host.createVM
> > > could
> > > still
> > > accept a vmUUID (because I assume engine does want the ability to
> > > set
> > > this
> > > explicitly).  However, they should be changed to return either a
> > > TaskIdentifier
> > > (if the creation is asynchronous) or a *Identifier (eg.
> > > VmIdentifier)
> > > if the
> > > object was created synchronously.
> > > 
> > > All told, I think the net is less work for clients.  They will no
> > > longer need to
> > > model the object associations and relationships because the API
> > > will
> > > take care
> > > of that automatically.
> > > 
> > > > ----- Original Message -----
> > > > > From: "Adam Litke" <agl at us.ibm.com>
> > > > > To: vdsm-devel at lists.fedorahosted.org
> > > > > Cc: engine-devel at linode01.ovirt.org, "Dan Kenigsberg"
> > > > > <danken at redhat.com>, "Federico Simoncelli"
> > > > > <fsimonce at redhat.com>, "Saggi Mizrahi" <smizrahi at redhat.com>,
> > > > > "Ayal Baron" <abaron at redhat.com>
> > > > > Sent: Thursday, November 29, 2012 12:19:06 PM
> > > > > Subject: RFD: API: Identifying vdsm objects in the next-gen
> > > > > API
> > > > > 
> > > > > Today in vdsm, every object (StoragePool, StorageDomain, VM,
> > > > > Volume,
> > > > > etc) is
> > > > > identified by a single UUID.  On the surface, it seems like
> > > > > this
> > > > > is
> > > > > enough info
> > > > > to properly identify a resource but in practice it's not.
> > > > >  For
> > > > > example, when you
> > > > > look at the API's dealing with Volumes, almost all of them
> > > > > require an
> > > > > sdUUID,
> > > > > spUUID, and imgUUID in order to provide proper context for
> > > > > the
> > > > > operation.
> > > > > 
> > > > > Needing to provide these extra UUIDs is a burden on the API
> > > > > user
> > > > > because knowing
> > > > > which values to pass requires internal knowledge of the API.
> > > > >  For
> > > > > example, the
> > > > > spUUID parameter is almost always just the connected storage
> > > > > pool.
> > > > >  Since we
> > > > > know there can currently be only one connected pool, the
> > > > > value is
> > > > > known.
> > > > > 
> > > > > I would like to move away from needing to understand all of
> > > > > these
> > > > > relationships
> > > > > from the end user perspective by encapsulating the extra
> > > > > context
> > > > > into
> > > > > new object
> > > > > identifier types as follows:
> > > > > 
> > > > > StoragePoolIdentifier:
> > > > >     { 'storagepoolID': 'UUID' }
> > > > > StorageDomainIdentifier:
> > > > >     { 'storagepoolID*': 'UUID', 'storagedomainID': 'UUID' }
> > > > > ImageIdentifier:
> > > > >     { 'storagepoolID*': 'UUID', 'storagedomainID': 'UUID',
> > > > >     'imageID':
> > > > >     'UUID' }
> > > > > VolumeIdentifier:
> > > > >     { 'storagepoolID*': 'UUID', 'storagedomainID': 'UUID',
> > > > >       'imageID': 'UUID', 'volumeID': 'UUID' }
> > > > > TaskIdentifier:
> > > > >     { 'taskID': 'UUID' }
> > > > > VMIdentifier:
> > > > >     { 'vmID': 'UUID' }
> > > > > 
> > > > > In the new API, anytime a reference to an object is required,
> > > > > one
> > > > > of
> > > > > the above
> > > > > structures must be passed in place of today's single UUID.
> > > > >  In
> > > > > many
> > > > > cases, this
> > > > > will allow us to reduce the number of parameters to the
> > > > > function
> > > > > since the
> > > > > needed contextual parameters (spUUID, etc) will be part of
> > > > > the
> > > > > object's
> > > > > identifier.  Similarly, any time the API returns an object
> > > > > reference
> > > > > it would
> > > > > return a *Identifier instead of a bare UUID.
> > > > > 
> > > > > These identifier types are basically opaque blobs to the API
> > > > > users
> > > > > and are only
> > > > > ever generated by vdsm itself.  Because of this, we can
> > > > > change
> > > > > the
> > > > > internal
> > > > > structure of the identifier to require new information or
> > > > > (before
> > > > > freezing the
> > > > > API) remove fields that no longer make sense.
> > > > > 
> > > > > I would greatly appreciate your comments on this proposal.
> > > > >  If it
> > > > > seems
> > > > > reasonable, I will revamp the current schema to make the
> > > > > necessary
> > > > > changes and
> > > > > provide the Bridge patch functions to convert between the
> > > > > current
> > > > > implementation
> > > > > and the new schema.
> > > > > 
> > > > > --- sample schema patch ---
> > > > > 
> > > > > commit 48f6b0f0a111dd0b372d211a4e566ce87f375cee
> > > > > Author: Adam Litke <agl at us.ibm.com>
> > > > > Date:   Tue Nov 27 14:14:06 2012 -0600
> > > > > 
> > > > >     schema: Introduce class identifier types
> > > > >     
> > > > >     When calling API methods that belong to a particular
> > > > >     class, a
> > > > >     class instance
> > > > >     must be indicated by passing a set of identifiers in the
> > > > >     request.
> > > > >      The location
> > > > >     of these parameters within the request is: 'params' ->
> > > > >     '__obj__'.
> > > > >      Since this
> > > > >     set of identifiers must be used together to correctly
> > > > >     instantiate
> > > > >     an object, it
> > > > >     makes sense to define these as proper types within the
> > > > >     API.
> > > > >      Then, functions
> > > > >     that return an object (or list of objects) can refer to
> > > > >     the
> > > > >     correct type.
> > > > >     
> > > > >     Signed-off-by: Adam Litke <agl at us.ibm.com>
> > > > > 
> > > > > diff --git a/vdsm_api/vdsmapi-schema.json
> > > > > b/vdsm_api/vdsmapi-schema.json
> > > > > index 0418e6e..7e2e851 100644
> > > > > --- a/vdsm_api/vdsmapi-schema.json
> > > > > +++ b/vdsm_api/vdsmapi-schema.json
> > > > > @@ -937,7 +937,7 @@
> > > > >  # Since: 4.10.0
> > > > >  ##
> > > > >  {'command': {'class': 'Host', 'name':
> > > > >  'getConnectedStoragePools'},
> > > > > - 'returns': ['StoragePool']}
> > > > > + 'returns': ['StoragePoolIdentifier']}
> > > > >  
> > > > >  ##
> > > > >  # @BlockDeviceType:
> > > > > @@ -1572,7 +1572,7 @@
> > > > >  {'command': {'class': 'Host', 'name': 'getStorageDomains'},
> > > > >   'data': {'*storagepoolID': 'UUID', '*domainClass':
> > > > >   'StorageDomainImageClass',
> > > > >            '*storageType': 'StorageDomainType',
> > > > >            '*remotePath':
> > > > >            'str'},
> > > > > - 'returns': ['StorageDomain']}
> > > > > + 'returns': ['StorageDomainIdentifier']}
> > > > >  
> > > > >  ##
> > > > >  # @Host.getStorageRepoStats:
> > > > > @@ -2406,7 +2406,7 @@
> > > > >  ##
> > > > >  {'command': {'class': 'Host', 'name': 'getVMList'},
> > > > >   'data': {'*vmList': ['UUID']},
> > > > > - 'returns': ['VM']}
> > > > > + 'returns': ['VMIdentifier']}
> > > > >  
> > > > >  ##
> > > > >  # @Host.ping:
> > > > > @@ -2744,10 +2744,11 @@
> > > > >   'returns': 'ConnectionRefMap'}
> > > > >  
> > > > >  ## Category: @ISCSIConnection
> > > > >  ##################################################
> > > > > +
> > > > >  ##
> > > > > -# @ISCSIConnection:
> > > > > +# @ISCSIConnectionIdentifier:
> > > > >  #
> > > > > -# ISCSIConnection API object.
> > > > > +# Identifier for an ISCSIConnection object.
> > > > >  #
> > > > >  # @host:      A fully-qualified domain name (FQDN) or IP
> > > > >  address
> > > > >  #
> > > > > @@ -2757,11 +2758,21 @@
> > > > >  #
> > > > >  # @password:  #optional The password associated with the
> > > > >  given
> > > > >  username
> > > > >  #
> > > > > -# Since: 4.10.0
> > > > > +# Since: 4.10.1
> > > > > +##
> > > > > +{'type': 'ISCSIConnectionIdentifier',
> > > > > + 'data': {'host': 'str', 'port': 'int', '*user': 'str',
> > > > > '*password':
> > > > > 'str'}}
> > > > > +
> > > > > +##
> > > > > +# @ISCSIConnection:
> > > > > +#
> > > > > +# ISCSIConnection API object.
> > > > > +#
> > > > > +# @ident:  The object identifier
> > > > > +#
> > > > > +# Since: 4.10.1
> > > > >  ##
> > > > > -{'class': 'ISCSIConnection',
> > > > > - 'data': {'host': 'str', 'port': 'int', '*user': 'str',
> > > > > -          '*password': 'str'}}
> > > > > +{'class': 'ISCSIConnection', 'ident':
> > > > > 'ISCSIConnectionIdentifier'}
> > > > >  
> > > > >  ##
> > > > >  # @ISCSIConnection.discoverSendTargets:
> > > > > @@ -2777,10 +2788,11 @@
> > > > >   'returns': ['str']}
> > > > >  
> > > > >  ## Category: @Image
> > > > >  ############################################################
> > > > > +
> > > > >  ##
> > > > > -# @Image:
> > > > > +# @ImageIdentifier:
> > > > >  #
> > > > > -# Image API object.
> > > > > +# Identifier for an Image object.
> > > > >  #
> > > > >  # @imageID:          The UUID of the Image
> > > > >  #
> > > > > @@ -2788,13 +2800,24 @@
> > > > >  #
> > > > >  # @storagedomainID:  The UUID of the Storage Domain
> > > > >  associated
> > > > >  with
> > > > >  the Image
> > > > >  #
> > > > > -# Since: 4.10.0
> > > > > +# Since: 4.10.1
> > > > >  ##
> > > > > -{'class': 'Image',
> > > > > +{'type': 'ImageIdentifier',
> > > > >   'data': {'imageID': 'UUID', 'storagepoolID': 'UUID',
> > > > >            'storagedomainID': 'UUID'}}
> > > > >  
> > > > >  ##
> > > > > +# @Image:
> > > > > +#
> > > > > +# Image API object.
> > > > > +#
> > > > > +# @ident:  The object identifier
> > > > > +#
> > > > > +# Since: 4.10.1
> > > > > +##
> > > > > +{'class': 'Image', 'ident': 'ImageIdentifier'}
> > > > > +
> > > > > +##
> > > > >  # @Image.delete:
> > > > >  #
> > > > >  # Delete the Image and all of its Volumes.
> > > > > @@ -2843,7 +2866,7 @@
> > > > >  # Since: 4.10.0
> > > > >  ##
> > > > >  {'command': {'class': 'Image', 'name': 'getVolumes'},
> > > > > - 'returns': ['Volume']}
> > > > > + 'returns': ['VolumeIdentifier']}
> > > > >  
> > > > >  ##
> > > > >  # @Image.mergeSnapshots:
> > > > > @@ -2905,17 +2928,26 @@
> > > > >  
> > > > >  ## Category: @LVMVolumeGroup
> > > > >  ###################################################
> > > > >  ##
> > > > > +# @LVMVolumeGroupIdentifier:
> > > > > +#
> > > > > +# An identifier for a LVMVolumeGroup object.
> > > > > +#
> > > > > +# @lvmvolumegroupID:  The volume group UUID
> > > > > +#
> > > > > +# Since: 4.10.1
> > > > > +##
> > > > > +{'type': 'LVMVolumeGroupIdentifier', 'data':
> > > > > {'lvmvolumegroupID':
> > > > > 'UUID'}}
> > > > > +
> > > > > +##
> > > > >  # @LVMVolumeGroup:
> > > > >  #
> > > > >  # LVMVolumeGroup API object.
> > > > >  #
> > > > > -# @lvmvolumegroupID:  #optional Associate this object with
> > > > > an
> > > > > existing LVM
> > > > > -#                     Volume Group
> > > > > +# @ident:  The object identifier
> > > > >  #
> > > > > -# Since: 4.10.0
> > > > > +# Since: 4.10.1
> > > > >  ##
> > > > > -{'class': 'LVMVolumeGroup',
> > > > > - 'data': {'lvmvolumegroupID': 'UUID'}}
> > > > > +{'class': 'LVMVolumeGroup', 'ident':
> > > > > 'LVMVolumeGroupIdentifier'}
> > > > >  
> > > > >  ##
> > > > >  # @LVMVolumeGroup.create:
> > > > > @@ -2964,21 +2996,32 @@
> > > > >  
> > > > >  ## Category: @StorageDomain
> > > > >  ####################################################
> > > > >  ##
> > > > > -# @StorageDomain:
> > > > > +# @StorageDomainIdentifier:
> > > > >  #
> > > > > -# StorageDomain API object.
> > > > > +# An identifier for a StorageDomain object.
> > > > >  #
> > > > >  # @storagedomainID:  Associate this object with a new or
> > > > >  existing
> > > > >  Storage Domain
> > > > >  #
> > > > >  # @storagepoolID:    #optional The Storage Pool UUID if this
> > > > >  Storage
> > > > >  Domain is
> > > > >  #                    attached
> > > > >  #
> > > > > -# Since: 4.10.0
> > > > > +# Since: 4.10.1
> > > > >  ##
> > > > > -{'class': 'StorageDomain',
> > > > > +{'type': 'StorageDomainIdentifier',
> > > > >   'data': {'storagedomainID': 'UUID', 'storagepoolID':
> > > > >   'UUID'}}
> > > > >  
> > > > >  ##
> > > > > +# @StorageDomain:
> > > > > +#
> > > > > +# StorageDomain API object.
> > > > > +#
> > > > > +# @ident:  The object identifier
> > > > > +#
> > > > > +# Since: 4.10.1
> > > > > +##
> > > > > +{'class': 'StorageDomain', 'ident':
> > > > > 'StorageDomainIdentifier'}
> > > > > +
> > > > > +##
> > > > >  # @StorageDomain.activate:
> > > > >  #
> > > > >  # Activate an attached but inactive Storage Domain.
> > > > > @@ -3184,7 +3227,7 @@
> > > > >  # Since: 4.10.0
> > > > >  ##
> > > > >  {'command': {'class': 'StorageDomain', 'name': 'getImages'},
> > > > > - 'returns': ['Image']}
> > > > > + 'returns': ['ImageIdentifier']}
> > > > >  
> > > > >  ##
> > > > >  # @StorageDomainRole:
> > > > > @@ -3295,7 +3338,7 @@
> > > > >  ##
> > > > >  {'command': {'class': 'StorageDomain', 'name':
> > > > >  'getVolumes'},
> > > > >   'data': {'imageID': 'UUID'},
> > > > > - 'returns': ['Volume']}
> > > > > + 'returns': ['VolumeIdentifier']}
> > > > >  
> > > > >  ##
> > > > >  # @StorageDomain.setDescription:
> > > > > @@ -3355,15 +3398,26 @@
> > > > >  
> > > > >  ## Category: @StoragePool
> > > > >  ######################################################
> > > > >  ##
> > > > > +# @StoragePoolIdentifier:
> > > > > +#
> > > > > +# An identifier for a StoragePool object.
> > > > > +#
> > > > > +# @storagepoolID:  Associate this object with a new or
> > > > > existing
> > > > > Storage Pool
> > > > > +#
> > > > > +# Since: 4.10.1
> > > > > +##
> > > > > +{'type': 'StoragePoolIdentifier', 'data': {'storagepoolID':
> > > > > 'UUID'}}
> > > > > +
> > > > > +##
> > > > >  # @StoragePool:
> > > > >  #
> > > > >  # StoragePool API object.
> > > > >  #
> > > > > -# @storagepoolID:  Associate this object with a new or
> > > > > existing
> > > > > Storage Pool
> > > > > +# @ident:  The object identifier
> > > > >  #
> > > > > -# Since: 4.10.0
> > > > > +# Since: 4.10.1
> > > > >  ##
> > > > > -{'class': 'StoragePool', 'data': {'storagepoolID': 'UUID'}}
> > > > > +{'class': 'StoragePool', 'ident': 'StoragePoolIdentifier'}
> > > > >  
> > > > >  ##
> > > > >  # @StoragePool.connect:
> > > > > @@ -3629,7 +3683,7 @@
> > > > >  ##
> > > > >  {'command': {'class': 'StoragePool', 'name':
> > > > >  'getDomainsContainingImage'},
> > > > >   'data': {'imageID': 'UUID', '*onlyDataDomains': 'bool'},
> > > > > - 'returns': ['StorageDomain']}
> > > > > + 'returns': ['StorageDomainIdentifier']}
> > > > >  
> > > > >  ##
> > > > >  # @StoragePool.getIsoList:
> > > > > @@ -4058,15 +4112,27 @@
> > > > >  
> > > > >  ## Category: @Task
> > > > >  #############################################################
> > > > >  ##
> > > > > +# @TaskIdentifier:
> > > > > +#
> > > > > +# An identifier for a Task object.
> > > > > +#
> > > > > +# @taskID:  The task UUID
> > > > > +#
> > > > > +# Since: 4.10.1
> > > > > +##
> > > > > +{'type': 'TaskIdentifier', 'data': {'taskID': 'UUID'}}
> > > > > +
> > > > > +
> > > > > +##
> > > > >  # @Task:
> > > > >  #
> > > > >  # Task API object.
> > > > >  #
> > > > > -# @taskID:  Associate this object with an existing Task
> > > > > +# @ident:  The object identifier
> > > > >  #
> > > > > -# Since: 4.10.0
> > > > > +# Since: 4.10.1
> > > > >  ##
> > > > > -{'class': 'Task', 'data': {'taskID': 'UUID'}}
> > > > > +{'class': 'Task', 'ident': 'TaskIdentifier'}
> > > > >  
> > > > >  ##
> > > > >  # @Task.clear:
> > > > > @@ -4123,15 +4189,26 @@
> > > > >  
> > > > >  ## Category: @VM
> > > > >  ###############################################################
> > > > >  ##
> > > > > +# @VMIdentifier:
> > > > > +#
> > > > > +# An identifier for a VM object.
> > > > > +#
> > > > > +# @vmID:  The task UUID
> > > > > +#
> > > > > +# Since: 4.10.1
> > > > > +##
> > > > > +{'type': 'VMIdentifier', 'data': {'vmID': 'UUID'}}
> > > > > +
> > > > > +##
> > > > >  # @VM:
> > > > >  #
> > > > >  # VM API object.
> > > > >  #
> > > > > -# @vmID:  Associate this object with an existing VM
> > > > > +# @ident:  The object identifier
> > > > >  #
> > > > > -# Since: 4.10.0
> > > > > +# Since: 4.10.1
> > > > >  ##
> > > > > -{'class': 'VM', 'data': {'vmID': 'UUID'}}
> > > > > +{'class': 'VM', 'ident': 'VMIdentifier'}
> > > > >  
> > > > >  ##
> > > > >  # @DriveSpecVolume:
> > > > > @@ -5161,9 +5238,9 @@
> > > > >  
> > > > >  ## Category: @Volume
> > > > >  ###########################################################
> > > > >  ##
> > > > > -# @Volume:
> > > > > +# @VolumeIdentifier:
> > > > >  #
> > > > > -# Volume API object.
> > > > > +# An identifier for a Volume object.
> > > > >  #
> > > > >  # @volumeID:         The UUID of the Volume
> > > > >  #
> > > > > @@ -5173,13 +5250,24 @@
> > > > >  #
> > > > >  # @imageID:          The Image associated with @UUID
> > > > >  #
> > > > > -# Since: 4.10.0
> > > > > +# Since: 4.10.1
> > > > >  ##
> > > > > -{'class': 'Volume',
> > > > > +{'type': 'VolumeIdentifier',
> > > > >   'data': {'volumeID': 'UUID', 'storagepoolID': 'UUID',
> > > > >            'storagedomainID': 'UUID', 'imageID': 'UUID'}}
> > > > >  
> > > > >  ##
> > > > > +# @Volume:
> > > > > +#
> > > > > +# Volume API object.
> > > > > +#
> > > > > +# @ident:  The object identifier
> > > > > +#
> > > > > +# Since: 4.10.1
> > > > > +##
> > > > > +{'class': 'Volume', 'ident': 'VolumeIdentifier'}
> > > > > +
> > > > > +##
> > > > >  # @VolumeRole:
> > > > >  #
> > > > >  # An enumeration of Volume Roles.
> > > > > 
> > > > > --
> > > > > Adam Litke <agl at us.ibm.com>
> > > > > IBM Linux Technology Center
> > > > > 
> > > > > 
> > > > 
> > > 
> > > --
> > > Adam Litke <agl at us.ibm.com>
> > > IBM Linux Technology Center
> > > 
> > > 
> > 
> 
> --
> Adam Litke <agl at us.ibm.com>
> IBM Linux Technology Center
> 
> 


From iheim at redhat.com  Fri Nov 30 10:57:09 2012
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 30 Nov 2012 05:57:09 -0500
Subject: [Engine-devel] Trusted Compute Pools
In-Reply-To: <D0B11485C64D4B47B66902F8A4E901BE3FCDA2@SHSMSX101.ccr.corp.intel.com>
References: <D0B11485C64D4B47B66902F8A4E901BE3FCDA2@SHSMSX101.ccr.corp.intel.com>
Message-ID: <50B89105.4010006@redhat.com>

On 11/20/2012 08:06 AM, Wei, Gang wrote:
> Hi,
>
> I am an engineer working in Intel Open Source Technology Center, interested
> in integrating Intel initiated OpenAttestation(OAT) project
> (https://github.com/OpenAttestation/OpenAttestation.git) into oVirt to
> provide a way for Administrator to deploy VMs on trusted hosts hardened with
> H/W-based security features, such as Intel TXT.
>
> I made a draft feature page for this:
> http://wiki.ovirt.org/wiki/Trusted_compute_pools
>
> My draft idea is to provide trust_level requirement while doing vm creation
> like below:
>
> curl -v -u "vdcadmin at qa.lab.tlv.redhat.com"
>      -H "Content-type: application/xml"
>      -d '<vm><name>my_new_vm</name>
> <cluster id="99408929-82cf-4dc7-a532-9d998063fa95" />
> <template id="00000000-0000-0000-0000-000000000000"/>
> <trust_level>trusted</trust_level></vm>'
>      'http://10.35.1.1/rhevm-api/vms'
>
> Then oVirt Engine should query attestation server built with OAT via RESTful
> API to get all trusted hosts and select one to create the VM.
>
> Attestation server performs host verification through following steps:
> 1. Hosts boot with Intel TXT technology enabled
> 2. The hosts' BIOS, hypervisor and OS are measured

a feature page on collecting bios info was just posted, please review it 
for your needs:
http://wiki.ovirt.org/wiki/Features/Design/HostBiosInfo

> 3. These measured data is sent to Attestation server when challenged by
> attestation server

does this has to be live or can be cached?

> 4. Attestation server verifies those measurements against good/known
> database to determine hosts' trustworthiness

btw, you can do a uiplugin which adds a subtab or a field to an existing 
subtab so when standing on an intel host, user would see attestation 
status of the host from the attestation service.

>
> Hosts need to be installed with OAT host agent to report host integrity to
> attestation server.

iiuc, this has nothing to do with vdsm, so this would be a plugin to the 
new ovirt-host-deploy host bootstrap script to install this rpm on hosts?

>
> By far, I am still in process of getting familiar with oVirt code and not
> get solid idea yet on how the oVirt Engine should be modified to support
> this feature.
>
> Any kind of comments or suggestions will be highly appreciated.

several questions (apologies if covered in the feature page, i'm offline)

1. is the attestation server open source and intended to be
    packaged/deployed together with engine, or assumption is it is an
    external service engine only needs to integrate with?
    same question on anything needed to be deployed on host side.

2. depending on first question - amount of configuration needed for
    secure communication with the attestation service.

3. I see two main approaches to implementing such a feature in engine
    (regardless of the bundling/packaging/deployment aspects mentioned
    above)

a. fully integrated
- adding a field to vm scheme with this field.
- adding a set of config options for attestation service url and
   authentication info
- adding to RunVm command a method to check attestation aspects.

b. pluggable
- this would be somewhat like the custom hooks in vdsm
- you would add a custom property to vm for this field (no need for db 
scheme change, just a config change for this custom property. if the 
plugin is packaged with ovirt, it could be a predefined one, so user 
does not need to do anything. if the plugin is optional, then the plugin 
will configure this config key as well at deployment.
- you can use a uiplugin to make this custom property appear as a main 
field in the vm dialog, but i think a custom property can be a good 
enough start. we have feature which are only implemented as custom 
properties (i.e., advanced options).
- you will add an engine plugin to do the check (engine plugins do not 
exist yet).

more notes/thoughts:
- Gilad is looking into making the scheduler pluggable and will send his 
thoughts on this. this means you could extend the scheduler with the 
check you want to do.
- you can add a cluster level policy on allowed values for this field at 
vm level, this should also be possible via cluster level custom 
properties and plugins (when we'll have them).
- should engine call attestation service for each host each time, or can 
just load a cache every X minutes for all hosts?

since there are several options for the final approach, i suggest you 
start with a POC based on the simplest option and check it is working, 
then hopefully the other tangents will converge or will revisit the best 
solution.

a POC patch would be a branch in your repo or the gerrit, flagged as WIP 
(work in progress) so it can be reviewed/commented/tested, but not 
merged till we revisit best approach for the feature (which may be to 
merge it and enhance at a later time as well, pending the other factors)

the POC should allow you to have a working solution based on private 
builds from the branch to test the integration.

for a POC patch i suggest:
1. use vm custom level property as simpler for first phase then changing 
the db scheme.
2. use bare minimum engine config support for service 
location/authentication.
3. assume no plugins and just add the code to the relevant part in RunVM 
which filters the relevant hosts:

relevant logic is in this class:
./backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/VdsSelector.java

the getVdsToRunOn[1] method has a loop to filter irrelevant hosts, then 
to choose the best host.
sounds like you need to add a hostValidator which will call the class 
actually communicating with the attestation service (or hopefully, will 
check against the cache this class maintains).

hope this makes things a bit more clearer on the available options.

Thanks,
    Itamar

[1] private Guid getVdsToRunOn(Iterable<VDS> vdss, boolean isMigrate) {
         StringBuilder sb = new StringBuilder();
         final List<VDS> readyToRun = new ArrayList<VDS>();
         for (VDS curVds : vdss) {
             if (validateHostIsReadyToRun(curVds, sb, isMigrate) == 
ValidationResult.VALID) {
                 readyToRun.add(curVds);
             }
         }
...
     }


From iheim at redhat.com  Fri Nov 30 11:28:51 2012
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 30 Nov 2012 13:28:51 +0200
Subject: [Engine-devel] Proposal to add Shireesh Anjal as maintainer to
	engine-gluster
Message-ID: <50B89873.8030404@redhat.com>

Shireesh has been working on the engine gluster support for the past 
year, covering patches and leading reviews of the various engine gluster 
patches.

I'd like to propose a new sub-component of the engine for the gluster 
module, adding shireesh as its maintainer.

Thanks,
    Itamar