From alourie at redhat.com  Sun Apr  1 09:09:07 2012
From: alourie at redhat.com (Alex Lourie)
Date: Sun, 01 Apr 2012 05:09:07 -0400 (EDT)
Subject: [Engine-devel] Please review: All In One Feature page
In-Reply-To: <58134886-dd2e-4ae3-bca1-bb9c1ba23847@zmail12.collab.prod.int.phx2.redhat.com>
Message-ID: <5e18cd82-6d9e-4dc3-b2e4-874053a3b8d7@zmail12.collab.prod.int.phx2.redhat.com>

Hi All

I've written a new wiki page [1] for a feature we've developed, called All in One. This allows configuring VDSM on the same host with rhevm (ovirt) automatically during setup.

Please review and provide feedback :-)

Thanks

[1] http://www.ovirt.org/wiki/Feature/AllInOne


From dfediuck at redhat.com  Sun Apr  1 09:44:07 2012
From: dfediuck at redhat.com (Doron Fediuck)
Date: Sun, 01 Apr 2012 12:44:07 +0300
Subject: [Engine-devel] Reloadable Configuration - Wiki Page
In-Reply-To: <3570b600-90ed-4f30-9ea9-a9818449dadf@zmail16.collab.prod.int.phx2.redhat.com>
References: <3570b600-90ed-4f30-9ea9-a9818449dadf@zmail16.collab.prod.int.phx2.redhat.com>
Message-ID: <4F782367.7080008@redhat.com>

Indeed you're taking it sideways.
We have a concept we can improve, and this can be done in 2 ways;
1. Stop the press, break current implementation and re-write it to support instances.
2. Handle reload to help current users, and set (1) as an RFE for 3.2.

I'm not sure how long the engine can wait to stabilize after (1) or several iterations
of it. So gradually working toward it (such as 2 suggests) may be more user friendly.
Does it makes sense?


On 31/03/12 00:50, Saggi Mizrahi wrote:
> I'm sorry if I'm moving the conversation sideways a bit but I was ill for a few days and missed out on all the fun :).
> The whole debate about permissions is a causing my spidy sense to tingle.
> 
> My main question is, What are the options you actually want to make as engine configuration?
> At least from my experience with VDSM 99% of the configuration options we have shouldn't be VDSM configuration but instance attributes.
> 
> To illustrate, the interval where you check liveness of hosts is not actually an Engine setting but a cluster or a host attribute. It should be set using the UI and the permissions to set it should be related to general permission on the object.
> The interval in which to check for storage liveness is a data center setting, not an Engine setting as well.
> 
> In general most options in a system are tied to object instances. The only things that I can think of that are actual Engine configurations are DB location, memory settings of the JVM and other technical details that should be accessible and set by the local root user only. This is also why I thought it shouldn't be in the DB, because if it's in the DB it's actually shared between installation and it's like sharing apache's "max thread num" setting between hosts with different capabilities.
> 
> Technical limitations like not being able to update quartz tasks once they've been initiated should be circumvented or abstracted but not designed around. 
> 
> ----- Original Message -----
>> From: "Doron Fediuck" <dfediuck at redhat.com>
>> To: "Itamar Heim" <iheim at redhat.com>
>> Cc: engine-devel at ovirt.org
>> Sent: Thursday, March 29, 2012 8:42:05 AM
>> Subject: Re: [Engine-devel] Reloadable Configuration - Wiki Page
>>
>> On 29/03/12 12:13, Itamar Heim wrote:
>>> On 03/29/2012 11:59 AM, Doron Fediuck wrote:
>>>> On 29/03/12 10:54, Itamar Heim wrote:
>>>>> On 03/29/2012 10:05 AM, Muli Salem wrote:
>>>>>> Thanks for the comments, I updated the wiki page accordingly:
>>>>>> http://www.ovirt.org/wiki/Features/ReloadableConfiguration
>>>>>>
>>>>>> 1. Instead of the new DB column is_reloadable -->   Annotation
>>>>>> to ConfigValues.
>>>>>> 2. Found a way to update the Quartz jobs, at least basic issues
>>>>>> such as interval size.
>>>>>> 3. The values will be reloaded upon admin's decision to do so -
>>>>>> with a new command in the engine-config CLI, since that is
>>>>>> where admins make the changes.
>>>>>
>>>>> just wondering - how will the CLI do this at the technical level
>>>>> (via REST API? signal to service, etc.)?
>>>>
>>>> Basically we need a script using the REST sdk to trigger
>>>> re-configuration
>>>> This script will need the engine's IP so it'll know where to find
>>>> it.
>>>> The thing is, REST also needs the admin's user and password to
>>>> run...
>>>>
>>>> We can get it in 2 options:
>>>>
>>>> 1. Store Admin's user+pass in the engine's conf file.
>>>> 2. Use engine-config to fetch the credentials.
>>>>
>>>> Once we have credentials, we can use it with a new script to
>>>> trigger configuration reload.
>>>> We can also incorporate this script into engine-config so admin
>>>> won't need to know another
>>>> script, and simply use a 'reload' verb.
>>>>
>>>> I'm not keen on storing the credentials in a conf' file, but
>>>> (unfortunately) it wouldn't
>>>> be a first time. Any better alternative is welcome (just as
>>>> patches ;-).
>>>
>>> true.
>>>
>>>>
>>>> A simple alternative to the whole credentials and IP need,
>>>> is a simple periodic reload, as suggested initially.
>>>
>>>
>> Any thoughts on this?
>>
>>>
>>>>
>>>> /d
>>>
>>> isn't there some way to send a process signal or something like
>>> that (not allowing remote access, but i think it uses the db
>>> crednetials from a local file anyway, and i don't think running
>>> config remotely is a must)
>>>
>> Simply signaling a process such as "kill TRAP PID" is problematic
>> since:
>> - The engine core is a web-app on top of JBoss, how do we know which
>> pid to trigger?
>> - What happens if JBoss isn't running / using nohup / ... ?
>>
>>> other options:
>>> 1. require user to provide user/password (kind of funny for running
>>> manage-domains utility, but possible
>> This will make service xxx reload pointless, unless we decide to drop
>> it and reduce to a simple
>> script (embedded or not in the config utility).
>>
>>> 2. use a way on the host to send a signal (change a file, process
>>> signal, etc.)
>> Great. This means we need to poll a folder or similar (DB)... sounds
>> familiar?
>> See above the periodic reload. We can do it better if we look for a
>> key in the DB
>> (enableReconfigure=true), to avoid reloading in the middle of an
>> update process
>> of several keys. We still need to be careful from concurrency, but I
>> have solutions
>> for this as well (do not allow updates to vdc_options until the key
>> becomes false again,
>> also set it to false on initial boot).
>>
>>>
>> 3. Write a simple public reload servlet (maybe limit to local host
>> only?), which
>> we can call using simple curl http://xxx/reload?
>>  
>> As I see it now,
>> I'd go for one of the following (in this order)-
>> 2: periodically poll DB, reload only when allowed.
>> 3: local servlet.
>>
>> Thoughts?
>> Better solutions?
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>



From iheim at redhat.com  Sun Apr  1 13:26:57 2012
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 01 Apr 2012 16:26:57 +0300
Subject: [Engine-devel] Please review: All In One Feature page
In-Reply-To: <5e18cd82-6d9e-4dc3-b2e4-874053a3b8d7@zmail12.collab.prod.int.phx2.redhat.com>
References: <5e18cd82-6d9e-4dc3-b2e4-874053a3b8d7@zmail12.collab.prod.int.phx2.redhat.com>
Message-ID: <4F7857A1.5040801@redhat.com>

On 04/01/2012 12:09 PM, Alex Lourie wrote:
> Hi All
>
> I've written a new wiki page [1] for a feature we've developed, called All in One. This allows configuring VDSM on the same host with rhevm (ovirt) automatically during setup.
>

1. "Plugin will wait to allow JBoss to start correctly. This is done 
because other steps involve using REST API (with ovirtsdk), which 
requires JBoss to be up. "

how are you planning to perform this check?

2. "Plugin will create a local host and add it to host list."
worth mentioning bootstrapping code was changed to allow to not reboot a 
host for this.

3. "The plugin works by providing parameters, group and sequences and 
adding them into the Controller object (the main object of the setup 
flow), which will invoke appropriate logic during the setup operation. "

nice - I like it is modular code.



From ovedo at redhat.com  Sun Apr  1 16:01:17 2012
From: ovedo at redhat.com (Oved Ourfalli)
Date: Sun, 01 Apr 2012 12:01:17 -0400 (EDT)
Subject: [Engine-devel] Please review: All In One Feature page
In-Reply-To: <4F7857A1.5040801@redhat.com>
Message-ID: <c654b439-1f8b-4ed2-af38-35a2256a05ae@zmail02.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Alex Lourie" <alourie at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Sunday, April 1, 2012 4:26:57 PM
> Subject: Re: [Engine-devel] Please review: All In One Feature page
> 
> On 04/01/2012 12:09 PM, Alex Lourie wrote:
> > Hi All
> >
> > I've written a new wiki page [1] for a feature we've developed,
> > called All in One. This allows configuring VDSM on the same host
> > with rhevm (ovirt) automatically during setup.
> >
> 
> 1. "Plugin will wait to allow JBoss to start correctly. This is done
> because other steps involve using REST API (with ovirtsdk), which
> requires JBoss to be up. "
> 
> how are you planning to perform this check?
> 
> 2. "Plugin will create a local host and add it to host list."
> worth mentioning bootstrapping code was changed to allow to not
> reboot a
> host for this.
> 
> 3. "The plugin works by providing parameters, group and sequences and
> adding them into the Controller object (the main object of the setup
> flow), which will invoke appropriate logic during the setup
> operation. "
> 
> nice - I like it is modular code.
Sounds indeed modular. Not really familiar with the architecture of the setup process today, so I have a one question:
How easy will it be in the future to write a plugin that performs different actions?

I'm asking because of the gluster integration. They might also want such a "all in one" feature, and in their case the CPU type is irrelevant, some of the steps are similar, and some other steps will have to be performed, such as format partition, create bricks, volumes and etc.

We should think about this today, as they might need this tomorrow :-)

Thank you,
Oved

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


From ykaul at redhat.com  Sun Apr  1 16:14:08 2012
From: ykaul at redhat.com (Yaniv Kaul)
Date: Sun, 01 Apr 2012 19:14:08 +0300
Subject: [Engine-devel] Please review: All In One Feature page
In-Reply-To: <5e18cd82-6d9e-4dc3-b2e4-874053a3b8d7@zmail12.collab.prod.int.phx2.redhat.com>
References: <5e18cd82-6d9e-4dc3-b2e4-874053a3b8d7@zmail12.collab.prod.int.phx2.redhat.com>
Message-ID: <4F787ED0.6030203@redhat.com>

On 04/01/2012 12:09 PM, Alex Lourie wrote:
> Hi All
>
> I've written a new wiki page [1] for a feature we've developed, called All in One. This allows configuring VDSM on the same host with rhevm (ovirt) automatically during setup.
>
> Please review and provide feedback :-)

- If the code is in code review, it's worth linking to relevant gerrit link.
- How is this supported with silent installation?
- What limitations, if any, exist in an all-in-one installation (for 
example, fencing).

Y.

>
> Thanks
>
> [1] http://www.ovirt.org/wiki/Feature/AllInOne
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From alourie at redhat.com  Sun Apr  1 19:21:21 2012
From: alourie at redhat.com (Alex Lourie)
Date: Sun, 01 Apr 2012 22:21:21 +0300
Subject: [Engine-devel] Fwd: Re:  Please review: All In One Feature page
In-Reply-To: <4F78AA51.8070603@redhat.com>
References: <4F78AA51.8070603@redhat.com>
Message-ID: <4F78AAB1.2020207@redhat.com>


On 04/01/2012 04:26 PM, Itamar Heim wrote:
>  On 04/01/2012 12:09 PM, Alex Lourie wrote:
>>  Hi All
>>
>>  I've written a new wiki page [1] for a feature we've developed,
>>  called All in One. This allows configuring VDSM on the same host with
>>  rhevm (ovirt) automatically during setup.
>>
>
>  1. "Plugin will wait to allow JBoss to start correctly. This is done
>  because other steps involve using REST API (with ovirtsdk), which
>  requires JBoss to be up. "
>
>  how are you planning to perform this check?
>

Currently we do not check for it. The following operations will fail
though if it is not up.

>  2. "Plugin will create a local host and add it to host list."
>  worth mentioning bootstrapping code was changed to allow to not reboot
>  a host for this.
>
Sure, I'll add a note.

>  3. "The plugin works by providing parameters, group and sequences and
>  adding them into the Controller object (the main object of the setup
>  flow), which will invoke appropriate logic during the setup operation. "
>
>  nice - I like it is modular code.
>


-- 
Alex Lourie.




From alourie at redhat.com  Sun Apr  1 19:22:55 2012
From: alourie at redhat.com (Alex Lourie)
Date: Sun, 01 Apr 2012 22:22:55 +0300
Subject: [Engine-devel] Please review: All In One Feature page
In-Reply-To: <c654b439-1f8b-4ed2-af38-35a2256a05ae@zmail02.collab.prod.int.phx2.redhat.com>
References: <c654b439-1f8b-4ed2-af38-35a2256a05ae@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <4F78AB0F.8060405@redhat.com>

On 04/01/2012 07:01 PM, Oved Ourfalli wrote:
>
> ----- Original Message -----
>> From: "Itamar Heim"<iheim at redhat.com>
>> To: "Alex Lourie"<alourie at redhat.com>
>> Cc: engine-devel at ovirt.org
>> Sent: Sunday, April 1, 2012 4:26:57 PM
>> Subject: Re: [Engine-devel] Please review: All In One Feature page
>>
>> On 04/01/2012 12:09 PM, Alex Lourie wrote:
>>> Hi All
>>>
>>> I've written a new wiki page [1] for a feature we've developed,
>>> called All in One. This allows configuring VDSM on the same host
>>> with rhevm (ovirt) automatically during setup.
>>>
>> 1. "Plugin will wait to allow JBoss to start correctly. This is done
>> because other steps involve using REST API (with ovirtsdk), which
>> requires JBoss to be up. "
>>
>> how are you planning to perform this check?
>>
>> 2. "Plugin will create a local host and add it to host list."
>> worth mentioning bootstrapping code was changed to allow to not
>> reboot a
>> host for this.
>>
>> 3. "The plugin works by providing parameters, group and sequences and
>> adding them into the Controller object (the main object of the setup
>> flow), which will invoke appropriate logic during the setup
>> operation. "
>>
>> nice - I like it is modular code.
> Sounds indeed modular. Not really familiar with the architecture of the setup process today, so I have a one question:
> How easy will it be in the future to write a plugin that performs different actions?

It's quite modular and it's very easy to create another plugin.

> I'm asking because of the gluster integration. They might also want such a "all in one" feature, and in their case the CPU type is irrelevant, some of the steps are similar, and some other steps will have to be performed, such as format partition, create bricks, volumes and etc.
>
> We should think about this today, as they might need this tomorrow :-)
>
> Thank you,
> Oved
>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>


-- 
Alex Lourie.



From alourie at redhat.com  Sun Apr  1 21:02:32 2012
From: alourie at redhat.com (Alex Lourie)
Date: Mon, 02 Apr 2012 00:02:32 +0300
Subject: [Engine-devel] Please review: All In One Feature page
In-Reply-To: <4F787ED0.6030203@redhat.com>
References: <5e18cd82-6d9e-4dc3-b2e4-874053a3b8d7@zmail12.collab.prod.int.phx2.redhat.com>
	<4F787ED0.6030203@redhat.com>
Message-ID: <4F78C268.5030705@redhat.com>

On 04/01/2012 07:14 PM, Yaniv Kaul wrote:
> On 04/01/2012 12:09 PM, Alex Lourie wrote:
>> Hi All
>>
>> I've written a new wiki page [1] for a feature we've developed, 
>> called All in One. This allows configuring VDSM on the same host with 
>> rhevm (ovirt) automatically during setup.
>>
>> Please review and provide feedback :-)
>
> - If the code is in code review, it's worth linking to relevant gerrit 
> link.
http://gerrit.ovirt.org/#change,2221
> - How is this supported with silent installation?
Fully. You'll have to create a new answer file, but with that it will 
work fine.
> - What limitations, if any, exist in an all-in-one installation (for 
> example, fencing).
>

Not that I know of, maybe Ofer/Barak would know?
> Y.
>
>>
>> Thanks
>>
>> [1] http://www.ovirt.org/wiki/Feature/AllInOne
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>


-- 
Alex Lourie.

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

From iheim at redhat.com  Sun Apr  1 22:43:01 2012
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 02 Apr 2012 01:43:01 +0300
Subject: [Engine-devel] Fwd: Re: Please review: All In One Feature page
In-Reply-To: <4F78AAB1.2020207@redhat.com>
References: <4F78AA51.8070603@redhat.com> <4F78AAB1.2020207@redhat.com>
Message-ID: <4F78D9F5.1090202@redhat.com>

On 04/01/2012 10:21 PM, Alex Lourie wrote:
>
> On 04/01/2012 04:26 PM, Itamar Heim wrote:
>> On 04/01/2012 12:09 PM, Alex Lourie wrote:
>>> Hi All
>>>
>>> I've written a new wiki page [1] for a feature we've developed,
>>> called All in One. This allows configuring VDSM on the same host with
>>> rhevm (ovirt) automatically during setup.
>>>
>>
>> 1. "Plugin will wait to allow JBoss to start correctly. This is done
>> because other steps involve using REST API (with ovirtsdk), which
>> requires JBoss to be up. "
>>
>> how are you planning to perform this check?
>>
>
> Currently we do not check for it. The following operations will fail
> though if it is not up.

the engine has a health check servlet. I suggets you poll it till you 
get HTTP 200 to determine it is up.


From iheim at redhat.com  Sun Apr  1 23:03:49 2012
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 02 Apr 2012 02:03:49 +0300
Subject: [Engine-devel] Please review: All In One Feature page
In-Reply-To: <4F78C268.5030705@redhat.com>
References: <5e18cd82-6d9e-4dc3-b2e4-874053a3b8d7@zmail12.collab.prod.int.phx2.redhat.com>
	<4F787ED0.6030203@redhat.com> <4F78C268.5030705@redhat.com>
Message-ID: <4F78DED5.7090205@redhat.com>

On 04/02/2012 12:02 AM, Alex Lourie wrote:
> On 04/01/2012 07:14 PM, Yaniv Kaul wrote:
>> On 04/01/2012 12:09 PM, Alex Lourie wrote:
>>> Hi All
>>>
>>> I've written a new wiki page [1] for a feature we've developed,
>>> called All in One. This allows configuring VDSM on the same host with
>>> rhevm (ovirt) automatically during setup.
>>>
>>> Please review and provide feedback :-)
>>
>> - If the code is in code review, it's worth linking to relevant gerrit
>> link.
> http://gerrit.ovirt.org/#change,2221
>> - How is this supported with silent installation?
> Fully. You'll have to create a new answer file, but with that it will
> work fine.
>> - What limitations, if any, exist in an all-in-one installation (for
>> example, fencing).
>>
>
> Not that I know of, maybe Ofer/Barak would know?

from the description in the wiki, it will by default create a local 
storage DC/cluster and configure the host in it. fencing is not relevant 
for local storage, as they can currently have only a single host per DC.


From iheim at redhat.com  Sun Apr  1 23:12:51 2012
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 02 Apr 2012 02:12:51 +0300
Subject: [Engine-devel] Reloadable Configuration - Wiki Page
In-Reply-To: <3570b600-90ed-4f30-9ea9-a9818449dadf@zmail16.collab.prod.int.phx2.redhat.com>
References: <3570b600-90ed-4f30-9ea9-a9818449dadf@zmail16.collab.prod.int.phx2.redhat.com>
Message-ID: <4F78E0F3.1070000@redhat.com>

On 03/31/2012 12:50 AM, Saggi Mizrahi wrote:
> I'm sorry if I'm moving the conversation sideways a bit but I was ill for a few days and missed out on all the fun :).
> The whole debate about permissions is a causing my spidy sense to tingle.
>
> My main question is, What are the options you actually want to make as engine configuration?
> At least from my experience with VDSM 99% of the configuration options we have shouldn't be VDSM configuration but instance attributes.

I don't think we should start by making every config variable at 
instance level.
the config table allows system level defaults, which are easy to 
handle/manage.
where there is sufficient need to create an instance level tweak, it is 
usually done with due consideration to making it a feature, which is 
usually a lengthier process.

>
> To illustrate, the interval where you check liveness of hosts is not actually an Engine setting but a cluster or a host attribute. It should be set using the UI and the permissions to set it should be related to general permission on the object.
> The interval in which to check for storage liveness is a data center setting, not an Engine setting as well.

true, but apparently so far there wasn't a need to tweak it at DC or 
cluster level, and engine level was good enough.
best is sometimes enemy of good.
and adding a lot of configurable options at entity level doesn't 
necessarily make things simpler for admins to understand.

so i agree some options should be at instance level, but only when there 
is a good enough reason to do so.

>
> In general most options in a system are tied to object instances. The only things that I can think of that are actual Engine configurations are DB location, memory settings of the JVM and other technical details that should be accessible and set by the local root user only. This is also why I thought it shouldn't be in the DB, because if it's in the DB it's actually shared between installation and it's like sharing apache's "max thread num" setting between hosts with different capabilities.
>
> Technical limitations like not being able to update quartz tasks once they've been initiated should be circumvented or abstracted but not designed around.
>
> ----- Original Message -----
>> From: "Doron Fediuck"<dfediuck at redhat.com>
>> To: "Itamar Heim"<iheim at redhat.com>
>> Cc: engine-devel at ovirt.org
>> Sent: Thursday, March 29, 2012 8:42:05 AM
>> Subject: Re: [Engine-devel] Reloadable Configuration - Wiki Page
>>
>> On 29/03/12 12:13, Itamar Heim wrote:
>>> On 03/29/2012 11:59 AM, Doron Fediuck wrote:
>>>> On 29/03/12 10:54, Itamar Heim wrote:
>>>>> On 03/29/2012 10:05 AM, Muli Salem wrote:
>>>>>> Thanks for the comments, I updated the wiki page accordingly:
>>>>>> http://www.ovirt.org/wiki/Features/ReloadableConfiguration
>>>>>>
>>>>>> 1. Instead of the new DB column is_reloadable -->    Annotation
>>>>>> to ConfigValues.
>>>>>> 2. Found a way to update the Quartz jobs, at least basic issues
>>>>>> such as interval size.
>>>>>> 3. The values will be reloaded upon admin's decision to do so -
>>>>>> with a new command in the engine-config CLI, since that is
>>>>>> where admins make the changes.
>>>>>
>>>>> just wondering - how will the CLI do this at the technical level
>>>>> (via REST API? signal to service, etc.)?
>>>>
>>>> Basically we need a script using the REST sdk to trigger
>>>> re-configuration
>>>> This script will need the engine's IP so it'll know where to find
>>>> it.
>>>> The thing is, REST also needs the admin's user and password to
>>>> run...
>>>>
>>>> We can get it in 2 options:
>>>>
>>>> 1. Store Admin's user+pass in the engine's conf file.
>>>> 2. Use engine-config to fetch the credentials.
>>>>
>>>> Once we have credentials, we can use it with a new script to
>>>> trigger configuration reload.
>>>> We can also incorporate this script into engine-config so admin
>>>> won't need to know another
>>>> script, and simply use a 'reload' verb.
>>>>
>>>> I'm not keen on storing the credentials in a conf' file, but
>>>> (unfortunately) it wouldn't
>>>> be a first time. Any better alternative is welcome (just as
>>>> patches ;-).
>>>
>>> true.
>>>
>>>>
>>>> A simple alternative to the whole credentials and IP need,
>>>> is a simple periodic reload, as suggested initially.
>>>
>>>
>> Any thoughts on this?
>>
>>>
>>>>
>>>> /d
>>>
>>> isn't there some way to send a process signal or something like
>>> that (not allowing remote access, but i think it uses the db
>>> crednetials from a local file anyway, and i don't think running
>>> config remotely is a must)
>>>
>> Simply signaling a process such as "kill TRAP PID" is problematic
>> since:
>> - The engine core is a web-app on top of JBoss, how do we know which
>> pid to trigger?
>> - What happens if JBoss isn't running / using nohup / ... ?
>>
>>> other options:
>>> 1. require user to provide user/password (kind of funny for running
>>> manage-domains utility, but possible
>> This will make service xxx reload pointless, unless we decide to drop
>> it and reduce to a simple
>> script (embedded or not in the config utility).
>>
>>> 2. use a way on the host to send a signal (change a file, process
>>> signal, etc.)
>> Great. This means we need to poll a folder or similar (DB)... sounds
>> familiar?
>> See above the periodic reload. We can do it better if we look for a
>> key in the DB
>> (enableReconfigure=true), to avoid reloading in the middle of an
>> update process
>> of several keys. We still need to be careful from concurrency, but I
>> have solutions
>> for this as well (do not allow updates to vdc_options until the key
>> becomes false again,
>> also set it to false on initial boot).
>>
>>>
>> 3. Write a simple public reload servlet (maybe limit to local host
>> only?), which
>> we can call using simple curl http://xxx/reload?
>>
>> As I see it now,
>> I'd go for one of the following (in this order)-
>> 2: periodically poll DB, reload only when allowed.
>> 3: local servlet.
>>
>> Thoughts?
>> Better solutions?
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>



From lhornyak at redhat.com  Mon Apr  2 06:17:19 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Mon, 02 Apr 2012 02:17:19 -0400 (EDT)
Subject: [Engine-devel] advanced nfs options in vdsm
In-Reply-To: <b24b591b-ba41-45e3-831c-d44f5210df38@zmail16.collab.prod.int.phx2.redhat.com>
Message-ID: <83e52b82-b02a-4451-8cee-8e073055ba36@zmail01.collab.prod.int.phx2.redhat.com>


Yep, I got the link from aglitke on the vdsm irc and I copy-pasted it to the wiki page.

----- Original Message -----
> From: "Saggi Mizrahi" <smizrahi at redhat.com>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Friday, March 30, 2012 9:10:19 PM
> Subject: Re: advanced nfs options in vdsm
> 
> The gerrit issue is linked in the wiki. It has all the information on
> when it was merged.
> 
> ----- Original Message -----
> > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > To: "Saggi Mizrahi" <smizrahi at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Wednesday, March 28, 2012 1:27:47 PM
> > Subject: advanced nfs options in vdsm
> > 
> > Hi Saggi,
> > 
> > The wiki page of the Advanced NFS options says that the changes
> > needed in vdsm are already done
> > http://www.ovirt.org/wiki/Features/AdvancedNfsOptions
> > Which VDSM release has this feature built in? Also, could you send
> > me
> > what changes have been done on vdsm?
> > 
> > Thank you,
> > Laszlo
> > 
> 


From ykaul at redhat.com  Mon Apr  2 07:00:16 2012
From: ykaul at redhat.com (Yaniv Kaul)
Date: Mon, 02 Apr 2012 10:00:16 +0300
Subject: [Engine-devel] Please review: All In One Feature page
In-Reply-To: <4F78C268.5030705@redhat.com>
References: <5e18cd82-6d9e-4dc3-b2e4-874053a3b8d7@zmail12.collab.prod.int.phx2.redhat.com>
	<4F787ED0.6030203@redhat.com> <4F78C268.5030705@redhat.com>
Message-ID: <4F794E80.1080703@redhat.com>

On 04/02/2012 12:02 AM, Alex Lourie wrote:
> On 04/01/2012 07:14 PM, Yaniv Kaul wrote:
>> On 04/01/2012 12:09 PM, Alex Lourie wrote:
>>> Hi All
>>>
>>> I've written a new wiki page [1] for a feature we've developed, 
>>> called All in One. This allows configuring VDSM on the same host 
>>> with rhevm (ovirt) automatically during setup.
>>>
>>> Please review and provide feedback :-)
>>
>> - If the code is in code review, it's worth linking to relevant 
>> gerrit link.
> http://gerrit.ovirt.org/#change,2221

Link in the wiki, next to 'Currently in code review'.



>> - How is this supported with silent installation?
> Fully. You'll have to create a new answer file, but with that it will 
> work fine.

Any new item that we need to add to the answer file?
Y.

>> - What limitations, if any, exist in an all-in-one installation (for 
>> example, fencing).
>>
>
> Not that I know of, maybe Ofer/Barak would know?
>> Y.
>>
>>>
>>> Thanks
>>>
>>> [1] http://www.ovirt.org/wiki/Feature/AllInOne
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>
>
> -- 
> Alex Lourie.

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

From ItzikB at mellanox.com  Mon Apr  2 07:45:38 2012
From: ItzikB at mellanox.com (Itzik Brown)
Date: Mon, 2 Apr 2012 07:45:38 +0000
Subject: [Engine-devel] Problem with detachment of host interface using
 ovirt-sdk
In-Reply-To: <4F6EC05A.9010209@redhat.com>
References: <4488206DC085244C886DBC9E7038B68918D382CE@MTRDAG01.mtl.com>,
	<4F6EC05A.9010209@redhat.com>
Message-ID: <4488206DC085244C886DBC9E7038B6892516DF3B@mtrdag02.mtl.com>

Hi,

I tried using ovirt-sdk against  ovirt-engine-3.0.0_0001-1.6.
I still get the same result:

10:29:26,554 WARN  [org.jboss.resteasy.core.SynchronousDispatcher] (http--0.0.0.0-8080-4) failed to execute: org.ovirt.engine.api.restapi.resource.BaseBackendResource$WebFaultException
        at org.ovirt.engine.api.restapi.resource.BaseBackendResource.handleError(BaseBackendResource.java:207) [restapi-jaxrs-3.0.0-0001.jar:]
        at org.ovirt.engine.api.restapi.resource.BaseBackendResource.handleError(BaseBackendResource.java:183) [restapi-jaxrs-3.0.0-0001.jar:]
        at org.ovirt.engine.api.restapi.resource.BackendHostNicsResource.lookupNetwork(BackendHostNicsResource.java:242) [restapi-jaxrs-3.0.0-0001.jar:]
        at org.ovirt.engine.api.restapi.resource.BackendHostNicResource.doAttachAction(BackendHostNicResource.java:56) [restapi-jaxrs-3.0.0-0001.jar:]
        at org.ovirt.engine.api.restapi.resource.BackendHostNicResource.detach(BackendHostNicResource.java:75) [restapi-jaxrs-3.0.0-0001.jar:]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_24]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.6.0_24]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.6.0_24]
        at java.lang.reflect.Method.invoke(Method.java:616) [:1.6.0_24]

Please advise,
Itzik

________________________________
From: engine-devel-bounces at ovirt.org [engine-devel-bounces at ovirt.org] on behalf of Roy Golan [rgolan at redhat.com]
Sent: Sunday, March 25, 2012 8:51 AM
To: engine-devel at ovirt.org
Subject: Re: [Engine-devel] Problem with detachment of host interface using ovirt-sdk

On 03/22/2012 10:43 AM, Itzik Brown wrote:
Hi,

I'm using ovirt-sdk to attach and detach a network to a host's Interface.
Once the network is attached to the interface I try to detach the network from the interface using the following steps:

1.Detach the network from the cluster through the GUI.
2.Remove the network from the datacenter through the GUI.
3.Detach the network from the host's interface using the SDK:

nic = api.hosts.get(name=host).nics.get(name=if_name)
net = params.Network(name=net_name)
act = params.Action(network=net)
nic.detach(act)
api.hosts.get(name=host).commitnetconfig()

Then I get the error:
http://pastebin.com/3Md07huE

The same flow using the GUI works fine.

Network removal from the Datacenter is a trigger for me to run the detachment operation therefore I use this flow.

I use the following components:

rhevm-3.0.2_0001-2
ovirt-sdk (Using the latest from git repository)

Please advise how to proceed.

Thanks,
Itzik



This body part will be downloaded on demand.

Ovirt-sdk and rhevm don't comply (ovirt-sdk is based on the upstream version of rhevm)

Use the REST api instead:

curl -X POST user at domain:password -H "Content-Type: application/xml" -d@/path/to/file.xml https://rhevm:8843/api/hosts/{host-id}/nics/{nic-id}/detach

file.xml:

<action>
  <host_nic>
    <name>eth0</name>
  </host_nic>
</action>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20120402/61432b8f/attachment.html>

From agl at us.ibm.com  Mon Apr  2 13:20:58 2012
From: agl at us.ibm.com (Adam Litke)
Date: Mon, 2 Apr 2012 08:20:58 -0500
Subject: [Engine-devel] Backing up the DB
Message-ID: <20120402132058.GG11957@aglitke.ibm.com>

Hi all,

I have a working development environment for ovirt-engine and I want to verify
someone else's gerrit change.  Is there a documented proceedure for backing up
the engine db so that, after checking out the new code and updating the db
schema, I can revert to my old code and DB (schema and data).  Thanks!

-- 
Adam Litke <agl at us.ibm.com>
IBM Linux Technology Center



From lhornyak at redhat.com  Mon Apr  2 13:37:12 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Mon, 02 Apr 2012 09:37:12 -0400 (EDT)
Subject: [Engine-devel] Backing up the DB
In-Reply-To: <20120402132058.GG11957@aglitke.ibm.com>
Message-ID: <df8b51ad-96ea-4cdf-8865-a80cdd5940b4@zmail01.collab.prod.int.phx2.redhat.com>

Hi Adam,

----- Original Message -----
> From: "Adam Litke" <agl at us.ibm.com>
> To: engine-devel at ovirt.org
> Sent: Monday, April 2, 2012 3:20:58 PM
> Subject: [Engine-devel] Backing up the DB
> 
> Hi all,
> 
> I have a working development environment for ovirt-engine and I want
> to verify
> someone else's gerrit change.  Is there a documented proceedure for
> backing up

Not really documented, but at least I do this frequently
You have to expect some problems as the hosts still have the old state, so I would recommend to
- disable both ssl and host install http://www.ovirt.org/wiki/OVirt_-_disable_SSL_in_VDSM
- you may also need to restart your hosts to flush the state (mounts, VM's, etc) the engine pushed it to after db restore
And then you can just use the usual postgresql utilities.

> the engine db so that, after checking out the new code and updating
> the db
> schema, I can revert to my old code and DB (schema and data).
>  Thanks!
> 
> --
> Adam Litke <agl at us.ibm.com>
> IBM Linux Technology Center
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From dougsland at redhat.com  Mon Apr  2 15:19:23 2012
From: dougsland at redhat.com (Douglas Landgraf)
Date: Mon, 02 Apr 2012 11:19:23 -0400
Subject: [Engine-devel] Backing up the DB
In-Reply-To: <20120402132058.GG11957@aglitke.ibm.com>
References: <20120402132058.GG11957@aglitke.ibm.com>
Message-ID: <4F79C37B.3070707@redhat.com>

Hi,

On 04/02/2012 09:20 AM, Adam Litke wrote:
> Hi all,
>
> I have a working development environment for ovirt-engine and I want to verify
> someone else's gerrit change.  Is there a documented proceedure for backing up
> the engine db so that, after checking out the new code and updating the db
> schema, I can revert to my old code and DB (schema and data).  Thanks!
>
Usually I use this tool to backup/restore db:
https://github.com/dougsland/misc-rhev/blob/master/rhevm-db-tool.py

However, since it's "rhevm" db tool.. need manually change the db name 
to "engine",
I will rename it to engine-db-tool and update the code to 'engine' soon..

-- 
Cheers
Douglas

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

From smizrahi at redhat.com  Mon Apr  2 14:36:21 2012
From: smizrahi at redhat.com (Saggi Mizrahi)
Date: Mon, 02 Apr 2012 10:36:21 -0400 (EDT)
Subject: [Engine-devel] Reloadable Configuration - Wiki Page
In-Reply-To: <4F78E0F3.1070000@redhat.com>
Message-ID: <c4302eca-85f0-42b0-864b-4d7d57263287@zmail16.collab.prod.int.phx2.redhat.com>

I'll try and sum up while rebutting as I get confused when mail threads become to long.

Your points as I understand them:
1. Moving the configuration to the instance level instead of system level is harder to implement.
[A] You are right when you talk about existing codebase, the question is will future configuration be written directly as instance configuration or will we continue abusing the system configuration until it's integrated in.

2. Using the config for system level defaults.
[A] Defaults are values that we as developers recommend for options. Letting the user change the defaults is actually letting the user set the value. If you are talking about configuration having a configuration hierarchy. Engine is not a parent objects to pin the hierarchy to as it's not an actual actor in the BL.

3. No need to set until there is an instance level tweak is required.
[A] If you set up the configuration hierarchy properly you could have the attribute getters recognize this hierarchy and only have a setter (and the proper db scheme) written when instance level tweaking is required. This way you remove the complexity but keep object relation correctness.


My opinion is usually that doing things properly might look like a lot of work now but in the long run you save more time. Further more, you can hide the fact that you are doing things wrong when you lack the time to actually do things properly. VDSM for instance hides global configuration accesses in instance getters and constructors. So even though the configuration is in the wrong place it is modeled in correctly and as we slowly move things the rest of the code isn't (for the most part) doing things like accessing objects configuration directly and other such atrocities.

In more practical terms, you could have settings per class\service instead of per instance and later you can actually use this as the basis for a configuration hierarchy. IMO This will be easier to model into the current authentication model, and integrate in. Always remember that one of the pillars of OOP is encapsulation, so even if you decide to keep all the values in one table, it will be smart to still define who owns what values in code instead of having a ConfigurationManager singleton and have everyone access it directly. But again, I'm not as versed in the Engine code as you all are and this might be more complicated than it looks to an outsider.

In broader strokes, my personal preference is to have an idea of how you want the configuration to work *ideally* and then start to take concessions due to resource limitations. Instead of just deciding to hack something in and worry about things later. 

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Saggi Mizrahi" <smizrahi at redhat.com>
> Cc: "Doron Fediuck" <dfediuck at redhat.com>, engine-devel at ovirt.org
> Sent: Sunday, April 1, 2012 7:12:51 PM
> Subject: Re: [Engine-devel] Reloadable Configuration - Wiki Page
> 
> On 03/31/2012 12:50 AM, Saggi Mizrahi wrote:
> > I'm sorry if I'm moving the conversation sideways a bit but I was
> > ill for a few days and missed out on all the fun :).
> > The whole debate about permissions is a causing my spidy sense to
> > tingle.
> >
> > My main question is, What are the options you actually want to make
> > as engine configuration?
> > At least from my experience with VDSM 99% of the configuration
> > options we have shouldn't be VDSM configuration but instance
> > attributes.
> 
> I don't think we should start by making every config variable at
> instance level.
> the config table allows system level defaults, which are easy to
> handle/manage.
> where there is sufficient need to create an instance level tweak, it
> is
> usually done with due consideration to making it a feature, which is
> usually a lengthier process.
> 
> >
> > To illustrate, the interval where you check liveness of hosts is
> > not actually an Engine setting but a cluster or a host attribute.
> > It should be set using the UI and the permissions to set it should
> > be related to general permission on the object.
> > The interval in which to check for storage liveness is a data
> > center setting, not an Engine setting as well.
> 
> true, but apparently so far there wasn't a need to tweak it at DC or
> cluster level, and engine level was good enough.
> best is sometimes enemy of good.
> and adding a lot of configurable options at entity level doesn't
> necessarily make things simpler for admins to understand.
> 
> so i agree some options should be at instance level, but only when
> there
> is a good enough reason to do so.
> 
> >
> > In general most options in a system are tied to object instances.
> > The only things that I can think of that are actual Engine
> > configurations are DB location, memory settings of the JVM and
> > other technical details that should be accessible and set by the
> > local root user only. This is also why I thought it shouldn't be
> > in the DB, because if it's in the DB it's actually shared between
> > installation and it's like sharing apache's "max thread num"
> > setting between hosts with different capabilities.
> >
> > Technical limitations like not being able to update quartz tasks
> > once they've been initiated should be circumvented or abstracted
> > but not designed around.
> >
> > ----- Original Message -----
> >> From: "Doron Fediuck"<dfediuck at redhat.com>
> >> To: "Itamar Heim"<iheim at redhat.com>
> >> Cc: engine-devel at ovirt.org
> >> Sent: Thursday, March 29, 2012 8:42:05 AM
> >> Subject: Re: [Engine-devel] Reloadable Configuration - Wiki Page
> >>
> >> On 29/03/12 12:13, Itamar Heim wrote:
> >>> On 03/29/2012 11:59 AM, Doron Fediuck wrote:
> >>>> On 29/03/12 10:54, Itamar Heim wrote:
> >>>>> On 03/29/2012 10:05 AM, Muli Salem wrote:
> >>>>>> Thanks for the comments, I updated the wiki page accordingly:
> >>>>>> http://www.ovirt.org/wiki/Features/ReloadableConfiguration
> >>>>>>
> >>>>>> 1. Instead of the new DB column is_reloadable -->
> >>>>>>    Annotation
> >>>>>> to ConfigValues.
> >>>>>> 2. Found a way to update the Quartz jobs, at least basic
> >>>>>> issues
> >>>>>> such as interval size.
> >>>>>> 3. The values will be reloaded upon admin's decision to do so
> >>>>>> -
> >>>>>> with a new command in the engine-config CLI, since that is
> >>>>>> where admins make the changes.
> >>>>>
> >>>>> just wondering - how will the CLI do this at the technical
> >>>>> level
> >>>>> (via REST API? signal to service, etc.)?
> >>>>
> >>>> Basically we need a script using the REST sdk to trigger
> >>>> re-configuration
> >>>> This script will need the engine's IP so it'll know where to
> >>>> find
> >>>> it.
> >>>> The thing is, REST also needs the admin's user and password to
> >>>> run...
> >>>>
> >>>> We can get it in 2 options:
> >>>>
> >>>> 1. Store Admin's user+pass in the engine's conf file.
> >>>> 2. Use engine-config to fetch the credentials.
> >>>>
> >>>> Once we have credentials, we can use it with a new script to
> >>>> trigger configuration reload.
> >>>> We can also incorporate this script into engine-config so admin
> >>>> won't need to know another
> >>>> script, and simply use a 'reload' verb.
> >>>>
> >>>> I'm not keen on storing the credentials in a conf' file, but
> >>>> (unfortunately) it wouldn't
> >>>> be a first time. Any better alternative is welcome (just as
> >>>> patches ;-).
> >>>
> >>> true.
> >>>
> >>>>
> >>>> A simple alternative to the whole credentials and IP need,
> >>>> is a simple periodic reload, as suggested initially.
> >>>
> >>>
> >> Any thoughts on this?
> >>
> >>>
> >>>>
> >>>> /d
> >>>
> >>> isn't there some way to send a process signal or something like
> >>> that (not allowing remote access, but i think it uses the db
> >>> crednetials from a local file anyway, and i don't think running
> >>> config remotely is a must)
> >>>
> >> Simply signaling a process such as "kill TRAP PID" is problematic
> >> since:
> >> - The engine core is a web-app on top of JBoss, how do we know
> >> which
> >> pid to trigger?
> >> - What happens if JBoss isn't running / using nohup / ... ?
> >>
> >>> other options:
> >>> 1. require user to provide user/password (kind of funny for
> >>> running
> >>> manage-domains utility, but possible
> >> This will make service xxx reload pointless, unless we decide to
> >> drop
> >> it and reduce to a simple
> >> script (embedded or not in the config utility).
> >>
> >>> 2. use a way on the host to send a signal (change a file, process
> >>> signal, etc.)
> >> Great. This means we need to poll a folder or similar (DB)...
> >> sounds
> >> familiar?
> >> See above the periodic reload. We can do it better if we look for
> >> a
> >> key in the DB
> >> (enableReconfigure=true), to avoid reloading in the middle of an
> >> update process
> >> of several keys. We still need to be careful from concurrency, but
> >> I
> >> have solutions
> >> for this as well (do not allow updates to vdc_options until the
> >> key
> >> becomes false again,
> >> also set it to false on initial boot).
> >>
> >>>
> >> 3. Write a simple public reload servlet (maybe limit to local host
> >> only?), which
> >> we can call using simple curl http://xxx/reload?
> >>
> >> As I see it now,
> >> I'd go for one of the following (in this order)-
> >> 2: periodically poll DB, reload only when allowed.
> >> 3: local servlet.
> >>
> >> Thoughts?
> >> Better solutions?
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> 
> 


From tjelinek at redhat.com  Tue Apr  3 07:17:26 2012
From: tjelinek at redhat.com (Tomas Jelinek)
Date: Tue, 03 Apr 2012 03:17:26 -0400 (EDT)
Subject: [Engine-devel] Storage Domain level 3
In-Reply-To: <d4e1d28d-7214-424b-871b-3cd76aa8bbdf@zmail16.collab.prod.int.phx2.redhat.com>
Message-ID: <b141c8a2-421b-477f-91ac-ee9e6c110b76@zmail16.collab.prod.int.phx2.redhat.com>

Hi all,

this is about supporting of I18N (https://bugzilla.redhat.com/show_bug.cgi?id=786448).
 
The VDSM already supports it, but only for storage domain level 3.

>From Dan Kenigsberg's mail:
"I hope ovirt-Engine learns to do storage domain upgrade, and uses level
3, so that this feature can be used."

So, how is it with supporting this in the engine?

Thank you,
Tomas


From iheim at redhat.com  Tue Apr  3 09:02:37 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 03 Apr 2012 12:02:37 +0300
Subject: [Engine-devel] Storage Domain level 3
In-Reply-To: <b141c8a2-421b-477f-91ac-ee9e6c110b76@zmail16.collab.prod.int.phx2.redhat.com>
References: <b141c8a2-421b-477f-91ac-ee9e6c110b76@zmail16.collab.prod.int.phx2.redhat.com>
Message-ID: <4F7ABCAD.20602@redhat.com>

On 04/03/2012 10:17 AM, Tomas Jelinek wrote:
> Hi all,
>
> this is about supporting of I18N (https://bugzilla.redhat.com/show_bug.cgi?id=786448).

a better URL to cover this would be the wiki:
http://www.ovirt.org/wiki/Features/I18N

>
> The VDSM already supports it, but only for storage domain level 3.
>
>  From Dan Kenigsberg's mail:
> "I hope ovirt-Engine learns to do storage domain upgrade, and uses level
> 3, so that this feature can be used."
>
> So, how is it with supporting this in the engine?
>
> Thank you,
> Tomas
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From emesika at redhat.com  Tue Apr  3 09:05:19 2012
From: emesika at redhat.com (Eli Mesika)
Date: Tue, 03 Apr 2012 05:05:19 -0400 (EDT)
Subject: [Engine-devel] Backing up the DB
In-Reply-To: <4F79C37B.3070707@redhat.com>
Message-ID: <fc5cc959-9f11-4f5d-b986-33bc6f54c1e7@zmail13.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Douglas Landgraf" <dougsland at redhat.com>
> To: "Adam Litke" <agl at us.ibm.com>
> Cc: engine-devel at ovirt.org, "Douglas Landgraf" <dlandgra at redhat.com>
> Sent: Monday, April 2, 2012 6:19:23 PM
> Subject: Re: [Engine-devel] Backing up the DB
> 
> 
> Hi,
> 
> On 04/02/2012 09:20 AM, Adam Litke wrote:
> 
> Hi all,
> 
> I have a working development environment for ovirt-engine and I want
> to verify
> someone else's gerrit change.  Is there a documented proceedure for
> backing up
> the engine db so that, after checking out the new code and updating
> the db
> schema, I can revert to my old code and DB (schema and data).

You can use pg_dump for backup and psql for restore :

backup:
pg_dump -C -E UTF8  --column-inserts --disable-dollar-quoting  --disable-triggers -U postgres --format=p -f <backupfile>  <dbname>

restore:
psql -U postgres -f <backupfile>  template1



>  Thanks! Usually I use this tool to backup/restore db:
> https://github.com/dougsland/misc-rhev/blob/master/rhevm-db-tool.py
> 
> However, since it's "rhevm" db tool.. need manually change the db
> name to "engine",
> I will rename it to engine-db-tool and update the code to 'engine'
> soon..
> 
> --
> Cheers
> Douglas
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From lpeer at redhat.com  Tue Apr  3 09:10:57 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Tue, 03 Apr 2012 12:10:57 +0300
Subject: [Engine-devel] Backing up the DB
In-Reply-To: <fc5cc959-9f11-4f5d-b986-33bc6f54c1e7@zmail13.collab.prod.int.phx2.redhat.com>
References: <fc5cc959-9f11-4f5d-b986-33bc6f54c1e7@zmail13.collab.prod.int.phx2.redhat.com>
Message-ID: <4F7ABEA1.6030409@redhat.com>

On 03/04/12 12:05, Eli Mesika wrote:
> 
> 
> ----- Original Message -----
>> From: "Douglas Landgraf" <dougsland at redhat.com>
>> To: "Adam Litke" <agl at us.ibm.com>
>> Cc: engine-devel at ovirt.org, "Douglas Landgraf" <dlandgra at redhat.com>
>> Sent: Monday, April 2, 2012 6:19:23 PM
>> Subject: Re: [Engine-devel] Backing up the DB
>>
>>
>> Hi,
>>
>> On 04/02/2012 09:20 AM, Adam Litke wrote:
>>
>> Hi all,
>>
>> I have a working development environment for ovirt-engine and I want
>> to verify
>> someone else's gerrit change.  Is there a documented proceedure for
>> backing up
>> the engine db so that, after checking out the new code and updating
>> the db
>> schema, I can revert to my old code and DB (schema and data).
> 
> You can use pg_dump for backup and psql for restore :
> 
> backup:
> pg_dump -C -E UTF8  --column-inserts --disable-dollar-quoting  --disable-triggers -U postgres --format=p -f <backupfile>  <dbname>
> 
> restore:
> psql -U postgres -f <backupfile>  template1
> 
> 

Eli,
Can we have a script for backup and restore DB in the repo?

I see we have backup_db.sql any use of it?

Thanks, Livnat

> 
>>  Thanks! Usually I use this tool to backup/restore db:
>> https://github.com/dougsland/misc-rhev/blob/master/rhevm-db-tool.py
>>
>> However, since it's "rhevm" db tool.. need manually change the db
>> name to "engine",
>> I will rename it to engine-db-tool and update the code to 'engine'
>> soon..
>>
>> --
>> Cheers
>> Douglas
>> _______________________________________________
>> 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  Tue Apr  3 15:10:44 2012
From: dfediuck at redhat.com (Doron Fediuck)
Date: Tue, 03 Apr 2012 18:10:44 +0300
Subject: [Engine-devel] Please review: All In One Feature page
In-Reply-To: <5e18cd82-6d9e-4dc3-b2e4-874053a3b8d7@zmail12.collab.prod.int.phx2.redhat.com>
References: <5e18cd82-6d9e-4dc3-b2e4-874053a3b8d7@zmail12.collab.prod.int.phx2.redhat.com>
Message-ID: <4F7B12F4.5020805@redhat.com>

On 01/04/12 12:09, Alex Lourie wrote:
> Hi All
> 
> I've written a new wiki page [1] for a feature we've developed, called All in One. This allows configuring VDSM on the same host with rhevm (ovirt) automatically during setup.
> 
> Please review and provide feedback :-)
> 
> Thanks
> 
> [1] http://www.ovirt.org/wiki/Feature/AllInOne
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel

One thing I noticed is that you plan to install engine-core,
and then add the host using REST (sdk). Please note that
prior to starting JBoss you need to create the ovirtmgmt
bridge. If it doesn't exist when you add the host, then
it'll be created and network may be corrupted, especially
with JBoss up & running over it.


From dougsland at redhat.com  Tue Apr  3 20:10:46 2012
From: dougsland at redhat.com (Douglas Landgraf)
Date: Tue, 03 Apr 2012 16:10:46 -0400
Subject: [Engine-devel] Backing up the DB
In-Reply-To: <4F7ABEA1.6030409@redhat.com>
References: <fc5cc959-9f11-4f5d-b986-33bc6f54c1e7@zmail13.collab.prod.int.phx2.redhat.com>
	<4F7ABEA1.6030409@redhat.com>
Message-ID: <4F7B5946.7010108@redhat.com>

On 04/03/2012 05:10 AM, Livnat Peer wrote:
> On 03/04/12 12:05, Eli Mesika wrote:
>>
>> ----- Original Message -----
>>> From: "Douglas Landgraf"<dougsland at redhat.com>
>>> To: "Adam Litke"<agl at us.ibm.com>
>>> Cc: engine-devel at ovirt.org, "Douglas Landgraf"<dlandgra at redhat.com>
>>> Sent: Monday, April 2, 2012 6:19:23 PM
>>> Subject: Re: [Engine-devel] Backing up the DB
>>>
>>>
>>> Hi,
>>>
>>> On 04/02/2012 09:20 AM, Adam Litke wrote:
>>>
>>> Hi all,
>>>
>>> I have a working development environment for ovirt-engine and I want
>>> to verify
>>> someone else's gerrit change.  Is there a documented proceedure for
>>> backing up
>>> the engine db so that, after checking out the new code and updating
>>> the db
>>> schema, I can revert to my old code and DB (schema and data).
>> You can use pg_dump for backup and psql for restore :
>>
>> backup:
>> pg_dump -C -E UTF8  --column-inserts --disable-dollar-quoting  --disable-triggers -U postgres --format=p -f<backupfile>   <dbname>
>>
>> restore:
>> psql -U postgres -f<backupfile>   template1
>>
>>
> Eli,
> Can we have a script for backup and restore DB in the repo?
>
> I see we have backup_db.sql any use of it?
>
If you guys are interested, I have updated the tool to work with 
systemctl/enginedb and tested under Fedora 16:

Here my use:

# mkdir /engine-backup-db
# chmod +x engine-db-tool.py

backup manually
=============
  ./engine-db-tool.py --backup --path=/engine-db-backup
Stopping jboss-as service...
Backuping database: 
/engine-db-backup/dump_RHEVDB_BACKUP_2012-04-03-15:05.sql
Starting jboss-as service...
Done


restore manually
=============
# ./engine-db-tool.py --restore 
--path=/engine-db-backup/dump_RHEVDB_BACKUP_2012-04-03-15:05.sql
Stopping jboss-as service...
Restoring database: 
/engine-db-backup/dump_RHEVDB_BACKUP_2012-04-03-15:05.sql
Starting jboss-as service...
Done


Crontab
=======
# crontab -e  (adding to my crontab user)

# Every day 18:00 backup db
00 18 * * * /path-to/engine-db-tool.py --backup --path=/engine-backup-db


Download: 
https://raw.github.com/dougsland/misc-rhev/master/engine-db-tool.py

Thanks!

-- 
Cheers
Douglas

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

From agl at us.ibm.com  Tue Apr  3 22:03:26 2012
From: agl at us.ibm.com (Adam Litke)
Date: Tue, 3 Apr 2012 17:03:26 -0500
Subject: [Engine-devel] VDSM REST API
Message-ID: <20120403220326.GC10117@aglitke>

Hi all,

At the oVirt Workshop in Beijing I learned about how the ovirt-shell dynamically
discovers: the collections, resource schemas, and allowed actions based on an
RSDL file and API xsd schema.  I am working on a REST API for vdsm and would
like to make my API compatible with the ovirt-engine api such that the same
ovirt-shell program could work with either the engine api or the vdsm api.

There are many differences between ovirt-engine and vdsm (namely that one is
implemented in Java and the other in Python).  I think the easiest way to test
whether this is possible is to try and create a new, minimalist REST service with
python Cherrypy.  Such a service would have a root URL with no collections or
actions.  From my understanding I will need to write the following files:

/api	    - A basic XML representation of the API root resource
/api?schema - An xsd that describes the simple API
/api?rsdl   - An rsdl (XML file) that describes the available links

for /api, I want to start with something dead-simple:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<api>
  <messages>
    <message id='foo' href='bar'>
      Hello from vdsm!
    </message>
  </messages>
</api>

Once I can use ovirt-shell to list messages and show messages I will be happy to
build on it.  Can anyone help me figure out the minimal xsd and rsdl that would
be needed for such an API to be consumable by ovirt-shell?  Thanks for your
help!

-- 
Adam Litke <agl at us.ibm.com>
IBM Linux Technology Center



From yzaslavs at redhat.com  Wed Apr  4 06:16:15 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Wed, 04 Apr 2012 09:16:15 +0300
Subject: [Engine-devel] Backing up the DB
In-Reply-To: <4F7B5946.7010108@redhat.com>
References: <fc5cc959-9f11-4f5d-b986-33bc6f54c1e7@zmail13.collab.prod.int.phx2.redhat.com>	<4F7ABEA1.6030409@redhat.com>
	<4F7B5946.7010108@redhat.com>
Message-ID: <4F7BE72F.4000204@redhat.com>

On 04/03/2012 11:10 PM, Douglas Landgraf wrote:
> On 04/03/2012 05:10 AM, Livnat Peer wrote:
>> On 03/04/12 12:05, Eli Mesika wrote:

Eli - maybe we can take the script of Douglas and add it to the git repo?

>>>
>>> ----- Original Message -----
>>>> From: "Douglas Landgraf" <dougsland at redhat.com>
>>>> To: "Adam Litke" <agl at us.ibm.com>
>>>> Cc: engine-devel at ovirt.org, "Douglas Landgraf" <dlandgra at redhat.com>
>>>> Sent: Monday, April 2, 2012 6:19:23 PM
>>>> Subject: Re: [Engine-devel] Backing up the DB
>>>>
>>>>
>>>> Hi,
>>>>
>>>> On 04/02/2012 09:20 AM, Adam Litke wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I have a working development environment for ovirt-engine and I want
>>>> to verify
>>>> someone else's gerrit change.  Is there a documented proceedure for
>>>> backing up
>>>> the engine db so that, after checking out the new code and updating
>>>> the db
>>>> schema, I can revert to my old code and DB (schema and data).
>>> You can use pg_dump for backup and psql for restore :
>>>
>>> backup:
>>> pg_dump -C -E UTF8  --column-inserts --disable-dollar-quoting  --disable-triggers -U postgres --format=p -f <backupfile>  <dbname>
>>>
>>> restore:
>>> psql -U postgres -f <backupfile>  template1
>>>
>>>
>> Eli,
>> Can we have a script for backup and restore DB in the repo?
>>
>> I see we have backup_db.sql any use of it?
>>
> If you guys are interested, I have updated the tool to work with
> systemctl/enginedb and tested under Fedora 16:
> 
> Here my use:
> 
> # mkdir /engine-backup-db
> # chmod +x engine-db-tool.py
> 
> backup manually
> =============
>  ./engine-db-tool.py --backup --path=/engine-db-backup
> Stopping jboss-as service...
> Backuping database:
> /engine-db-backup/dump_RHEVDB_BACKUP_2012-04-03-15:05.sql
> Starting jboss-as service...
> Done
> 
> 
> restore manually
> =============
> # ./engine-db-tool.py --restore
> --path=/engine-db-backup/dump_RHEVDB_BACKUP_2012-04-03-15:05.sql
> Stopping jboss-as service...
> Restoring database:
> /engine-db-backup/dump_RHEVDB_BACKUP_2012-04-03-15:05.sql
> Starting jboss-as service...
> Done
> 
> 
> Crontab
> =======
> # crontab -e  (adding to my crontab user)
> 
> # Every day 18:00 backup db
> 00 18 * * * /path-to/engine-db-tool.py --backup --path=/engine-backup-db
> 
> 
> Download:
> https://raw.github.com/dougsland/misc-rhev/master/engine-db-tool.py
> 
> Thanks!
> 
> -- 
> Cheers
> Douglas
> 
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From yzaslavs at redhat.com  Wed Apr  4 06:18:00 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Wed, 04 Apr 2012 09:18:00 +0300
Subject: [Engine-devel] Backing up the DB
In-Reply-To: <4F7BE72F.4000204@redhat.com>
References: <fc5cc959-9f11-4f5d-b986-33bc6f54c1e7@zmail13.collab.prod.int.phx2.redhat.com>	<4F7ABEA1.6030409@redhat.com>	<4F7B5946.7010108@redhat.com>
	<4F7BE72F.4000204@redhat.com>
Message-ID: <4F7BE798.8090705@redhat.com>

On 04/04/2012 09:16 AM, Yair Zaslavsky wrote:
> On 04/03/2012 11:10 PM, Douglas Landgraf wrote:
>> On 04/03/2012 05:10 AM, Livnat Peer wrote:
>>> On 03/04/12 12:05, Eli Mesika wrote:
> 
> Eli - maybe we can take the script of Douglas and add it to the git repo?
Actually, I'll correct myself - I think we should produce a bash version
of it. What do you think?

> 
>>>>
>>>> ----- Original Message -----
>>>>> From: "Douglas Landgraf" <dougsland at redhat.com>
>>>>> To: "Adam Litke" <agl at us.ibm.com>
>>>>> Cc: engine-devel at ovirt.org, "Douglas Landgraf" <dlandgra at redhat.com>
>>>>> Sent: Monday, April 2, 2012 6:19:23 PM
>>>>> Subject: Re: [Engine-devel] Backing up the DB
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> On 04/02/2012 09:20 AM, Adam Litke wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I have a working development environment for ovirt-engine and I want
>>>>> to verify
>>>>> someone else's gerrit change.  Is there a documented proceedure for
>>>>> backing up
>>>>> the engine db so that, after checking out the new code and updating
>>>>> the db
>>>>> schema, I can revert to my old code and DB (schema and data).
>>>> You can use pg_dump for backup and psql for restore :
>>>>
>>>> backup:
>>>> pg_dump -C -E UTF8  --column-inserts --disable-dollar-quoting  --disable-triggers -U postgres --format=p -f <backupfile>  <dbname>
>>>>
>>>> restore:
>>>> psql -U postgres -f <backupfile>  template1
>>>>
>>>>
>>> Eli,
>>> Can we have a script for backup and restore DB in the repo?
>>>
>>> I see we have backup_db.sql any use of it?
>>>
>> If you guys are interested, I have updated the tool to work with
>> systemctl/enginedb and tested under Fedora 16:
>>
>> Here my use:
>>
>> # mkdir /engine-backup-db
>> # chmod +x engine-db-tool.py
>>
>> backup manually
>> =============
>>  ./engine-db-tool.py --backup --path=/engine-db-backup
>> Stopping jboss-as service...
>> Backuping database:
>> /engine-db-backup/dump_RHEVDB_BACKUP_2012-04-03-15:05.sql
>> Starting jboss-as service...
>> Done
>>
>>
>> restore manually
>> =============
>> # ./engine-db-tool.py --restore
>> --path=/engine-db-backup/dump_RHEVDB_BACKUP_2012-04-03-15:05.sql
>> Stopping jboss-as service...
>> Restoring database:
>> /engine-db-backup/dump_RHEVDB_BACKUP_2012-04-03-15:05.sql
>> Starting jboss-as service...
>> Done
>>
>>
>> Crontab
>> =======
>> # crontab -e  (adding to my crontab user)
>>
>> # Every day 18:00 backup db
>> 00 18 * * * /path-to/engine-db-tool.py --backup --path=/engine-backup-db
>>
>>
>> Download:
>> https://raw.github.com/dougsland/misc-rhev/master/engine-db-tool.py
>>
>> Thanks!
>>
>> -- 
>> Cheers
>> Douglas
>>
>>
>>
>> _______________________________________________
>> 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 Apr  4 06:54:46 2012
From: eedri at redhat.com (Eyal Edri)
Date: Wed, 04 Apr 2012 02:54:46 -0400 (EDT)
Subject: [Engine-devel] [Jenkins] Warning - the following commits inserted 2
	new HIGH priority bugs into into engine code
In-Reply-To: <80e5a292-81a7-45fa-8e01-ccddbaf8dbdd@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <1c5e2b63-a538-4f04-95c4-e1aa1df8a226@zmail17.collab.prod.int.phx2.redhat.com>


core: Ovirt-engin-backend: Run Once does not send Attach CD/Floppy (detail / gitweb)
webadmin: Changing a call at webamin from UpdateVmDiskCommand to HotPlug/HotUnPlugCommand (detail / gitweb)
core : Changes for required error messages in order to supposrt a new commands (detail / gitweb)
core : Introducing HotPlug and HotUnplug commands (detail / gitweb)


url: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/491/

Both in class: VmInfoBuilder.java

http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/491/findbugsResult/new/HIGH/?

Please check,

Eyal Edri
oVirt Infra Team


From alourie at redhat.com  Wed Apr  4 08:00:18 2012
From: alourie at redhat.com (Alex Lourie)
Date: Wed, 04 Apr 2012 11:00:18 +0300
Subject: [Engine-devel] Please review: All In One Feature page
In-Reply-To: <4F7B12F4.5020805@redhat.com>
References: <5e18cd82-6d9e-4dc3-b2e4-874053a3b8d7@zmail12.collab.prod.int.phx2.redhat.com>
	<4F7B12F4.5020805@redhat.com>
Message-ID: <4F7BFF92.3010004@redhat.com>

On Tue 03 Apr 2012 06:10:44 PM IDT, Doron Fediuck wrote:
> On 01/04/12 12:09, Alex Lourie wrote:
>> Hi All
>>
>> I've written a new wiki page [1] for a feature we've developed, called All in One. This allows configuring VDSM on the same host with rhevm (ovirt) automatically during setup.
>>
>> Please review and provide feedback :-)
>>
>> Thanks
>>
>> [1] http://www.ovirt.org/wiki/Feature/AllInOne
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
> One thing I noticed is that you plan to install engine-core,
> and then add the host using REST (sdk). Please note that
> prior to starting JBoss you need to create the ovirtmgmt
> bridge. If it doesn't exist when you add the host, then
> it'll be created and network may be corrupted, especially
> with JBoss up&  running over it.

As far as I've seen in testing, the creation of the bridge was working 
fine. And why would it be different between automatic and manual 
creation of the host?

--
Alex Lourie.


From dfediuck at redhat.com  Wed Apr  4 11:10:59 2012
From: dfediuck at redhat.com (Doron Fediuck)
Date: Wed, 04 Apr 2012 14:10:59 +0300
Subject: [Engine-devel] Please review: All In One Feature page
In-Reply-To: <4F7BFF92.3010004@redhat.com>
References: <5e18cd82-6d9e-4dc3-b2e4-874053a3b8d7@zmail12.collab.prod.int.phx2.redhat.com>
	<4F7B12F4.5020805@redhat.com> <4F7BFF92.3010004@redhat.com>
Message-ID: <4F7C2C43.8070606@redhat.com>

So far, no one created a bridge under JBoss' legs while
it's up & running. Bridge creation happens on hosts and
not in the engine-core machine. So up until now we had
JBoss up & running in his machine, and when it installed
a new host, a script would run on that new host to change
networking for the new bridge to be created. During this time
JBoss is monitoring the process from a (safe) distance.

Now, an web-app running on top of JBoss (you may know
it as engine-core) is doing network changes while the
app-server (JBoss...) is running and listens to 0.0.0.0
and maybe locally as well to specific ports. In this
situation network changes should happen only if you /know/
it's safe, or even better- do it /before/ starting JBoss.
So when JBoss starts network should be stable.

On 04/04/12 11:00, Alex Lourie wrote:
> On Tue 03 Apr 2012 06:10:44 PM IDT, Doron Fediuck wrote:
>> On 01/04/12 12:09, Alex Lourie wrote:
>>> Hi All
>>>
>>> I've written a new wiki page [1] for a feature we've developed, called All in One. This allows configuring VDSM on the same host with rhevm (ovirt) automatically during setup.
>>>
>>> Please review and provide feedback :-)
>>>
>>> Thanks
>>>
>>> [1] http://www.ovirt.org/wiki/Feature/AllInOne
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>> One thing I noticed is that you plan to install engine-core,
>> and then add the host using REST (sdk). Please note that
>> prior to starting JBoss you need to create the ovirtmgmt
>> bridge. If it doesn't exist when you add the host, then
>> it'll be created and network may be corrupted, especially
>> with JBoss up&  running over it.
> 
> As far as I've seen in testing, the creation of the bridge was working fine. And why would it be different between automatic and manual creation of the host?
> 
> -- 
> Alex Lourie.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel


-- 

/d

Why doesn't DOS ever say "EXCELLENT command or filename!"


From dfediuck at redhat.com  Wed Apr  4 11:47:44 2012
From: dfediuck at redhat.com (Doron Fediuck)
Date: Wed, 04 Apr 2012 14:47:44 +0300
Subject: [Engine-devel] VDSM REST API
In-Reply-To: <20120403220326.GC10117@aglitke>
References: <20120403220326.GC10117@aglitke>
Message-ID: <4F7C34E0.70003@redhat.com>

Hi Adam,
Just adding vdsm devel list, so vdsm folks 
will be apart of this thread.

On 04/04/12 01:03, Adam Litke wrote:
> Hi all,
> 
> At the oVirt Workshop in Beijing I learned about how the ovirt-shell dynamically
> discovers: the collections, resource schemas, and allowed actions based on an
> RSDL file and API xsd schema.  I am working on a REST API for vdsm and would
> like to make my API compatible with the ovirt-engine api such that the same
> ovirt-shell program could work with either the engine api or the vdsm api.
> 
> There are many differences between ovirt-engine and vdsm (namely that one is
> implemented in Java and the other in Python).  I think the easiest way to test
> whether this is possible is to try and create a new, minimalist REST service with
> python Cherrypy.  Such a service would have a root URL with no collections or
> actions.  From my understanding I will need to write the following files:
> 
> /api	    - A basic XML representation of the API root resource
> /api?schema - An xsd that describes the simple API
> /api?rsdl   - An rsdl (XML file) that describes the available links
> 
> for /api, I want to start with something dead-simple:
> 
> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> <api>
>   <messages>
>     <message id='foo' href='bar'>
>       Hello from vdsm!
>     </message>
>   </messages>
> </api>
> 
> Once I can use ovirt-shell to list messages and show messages I will be happy to
> build on it.  Can anyone help me figure out the minimal xsd and rsdl that would
> be needed for such an API to be consumable by ovirt-shell?  Thanks for your
> help!
> 


-- 

/d

Why doesn't DOS ever say "EXCELLENT command or filename!"


From dougsland at redhat.com  Wed Apr  4 13:07:06 2012
From: dougsland at redhat.com (Douglas Landgraf)
Date: Wed, 04 Apr 2012 09:07:06 -0400
Subject: [Engine-devel] Backing up the DB
In-Reply-To: <4F7BE798.8090705@redhat.com>
References: <fc5cc959-9f11-4f5d-b986-33bc6f54c1e7@zmail13.collab.prod.int.phx2.redhat.com>	<4F7ABEA1.6030409@redhat.com>	<4F7B5946.7010108@redhat.com>
	<4F7BE72F.4000204@redhat.com> <4F7BE798.8090705@redhat.com>
Message-ID: <4F7C477A.4060301@redhat.com>

On 04/04/2012 02:18 AM, Yair Zaslavsky wrote:
> On 04/04/2012 09:16 AM, Yair Zaslavsky wrote:
>> On 04/03/2012 11:10 PM, Douglas Landgraf wrote:
>>> On 04/03/2012 05:10 AM, Livnat Peer wrote:
>>>> On 03/04/12 12:05, Eli Mesika wrote:
>> Eli - maybe we can take the script of Douglas and add it to the git repo?
> Actually, I'll correct myself - I think we should produce a bash version
> of it. What do you think?
IMHO, it's not required to convert to bash since we have others oVirt 
tools already in python.
Anyway, I have documented all steps here (with or without tool):
http://ovirt.org/w/index.php?title=Backup_engine_db

Would be nice to have such tool available when we install a ovirt engine 
system.

Thanks!

-- 
Cheers
Douglas

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

From oschreib at redhat.com  Thu Apr  5 08:27:50 2012
From: oschreib at redhat.com (Ofer Schreiber)
Date: Thu, 05 Apr 2012 04:27:50 -0400 (EDT)
Subject: [Engine-devel] Backing up the DB
In-Reply-To: <4F7C477A.4060301@redhat.com>
Message-ID: <8e265a23-419d-417e-9a11-a7547f9f6c91@zmail14.collab.prod.int.phx2.redhat.com>

We already have the backup code in python - under engine-cleanup 
What about using the same code-base? 
or adding --backup-db-only to engine-cleaup? 

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

> On 04/04/2012 02:18 AM, Yair Zaslavsky wrote:
> > On 04/04/2012 09:16 AM, Yair Zaslavsky wrote:
> 
> > > On 04/03/2012 11:10 PM, Douglas Landgraf wrote:
> > 
> 
> > > > On 04/03/2012 05:10 AM, Livnat Peer wrote:
> > > 
> > 
> 
> > > > > On 03/04/12 12:05, Eli Mesika wrote:
> > > > 
> > > 
> > 
> 
> > > Eli - maybe we can take the script of Douglas and add it to the
> > > git
> > > repo?
> > 
> 
> > Actually, I'll correct myself - I think we should produce a bash
> > version
> 
> > of it. What do you think?
> 
> IMHO, it's not required to convert to bash since we have others oVirt
> tools already in python.
> Anyway, I have documented all steps here (with or without tool):
> http://ovirt.org/w/index.php?title=Backup_engine_db

> Would be nice to have such tool available when we install a ovirt
> engine system.

> Thanks!
> --
> Cheers
> Douglas
> _______________________________________________
> 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/20120405/9b690829/attachment.html>

From ryanh at us.ibm.com  Thu Apr  5 15:27:19 2012
From: ryanh at us.ibm.com (Ryan Harper)
Date: Thu, 5 Apr 2012 10:27:19 -0500
Subject: [Engine-devel] qemu machine type / datacenter machine version
Message-ID: <20120405152719.GB25807@us.ibm.com>

I was playing around with ovirt-engine datacenter definitions and I
seems that the capatibility version in the gui controls the qemu machine
type specified (3.0 -> pc-0.14).  I was wondering where that's
configured setup.

I grepped through my deployed system and saw a hit here:

[root at f16-engine ovirt-engine]# rpm -qf /usr/share/ovirt-engine 
ovirt-engine-3.0.0_0001-1.2.fc16.x86_64
[root at f16-engine ovirt-engine]# grep -nri "pc-0.14" *
db-backups/tmprN1EDt.sql:12119:INSERT INTO vdc_options (option_id, option_name, option_value, version) VALUES (236, 'EmulatedMachine', 'pc-0.14', '3.0');
db-backups/tmpj4XRCI.sql:12138:INSERT INTO vdc_options (option_id, option_name, option_value, version) VALUES (236, 'EmulatedMachine', 'pc-0.14', '3.0');
dbscripts/upgrade/03_00_0530_update_EmulatedMachine_config_to_pc.sql:2:select fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0');
dbscripts/create_db.sh.log:7571:select fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0');
dbscripts/create_db.sh.log:25529:select fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0');
dbscripts/create_db.sh.log:43487:select fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0');

Is there any way to define different compatibiilty versions or edit that?  If I've got a new end-point running qemu-kvm that doesn't have pc-0.14 defined (Say RHEL6.x) the machines won't lauch when you specific -M pc-0.14.

Thoughts?


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



From iheim at redhat.com  Thu Apr  5 17:14:26 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 05 Apr 2012 20:14:26 +0300
Subject: [Engine-devel] qemu machine type / datacenter machine version
In-Reply-To: <20120405152719.GB25807@us.ibm.com>
References: <20120405152719.GB25807@us.ibm.com>
Message-ID: <4F7DD2F2.303@redhat.com>

On 04/05/2012 06:27 PM, Ryan Harper wrote:
> I was playing around with ovirt-engine datacenter definitions and I
> seems that the capatibility version in the gui controls the qemu machine
> type specified (3.0 ->  pc-0.14).  I was wondering where that's
> configured setup.
>
> I grepped through my deployed system and saw a hit here:
>
> [root at f16-engine ovirt-engine]# rpm -qf /usr/share/ovirt-engine
> ovirt-engine-3.0.0_0001-1.2.fc16.x86_64
> [root at f16-engine ovirt-engine]# grep -nri "pc-0.14" *
> db-backups/tmprN1EDt.sql:12119:INSERT INTO vdc_options (option_id, option_name, option_value, version) VALUES (236, 'EmulatedMachine', 'pc-0.14', '3.0');
> db-backups/tmpj4XRCI.sql:12138:INSERT INTO vdc_options (option_id, option_name, option_value, version) VALUES (236, 'EmulatedMachine', 'pc-0.14', '3.0');
> dbscripts/upgrade/03_00_0530_update_EmulatedMachine_config_to_pc.sql:2:select fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0');
> dbscripts/create_db.sh.log:7571:select fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0');
> dbscripts/create_db.sh.log:25529:select fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0');
> dbscripts/create_db.sh.log:43487:select fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0');
>
> Is there any way to define different compatibiilty versions or edit that?  If I've got a new end-point running qemu-kvm that doesn't have pc-0.14 defined (Say RHEL6.x) the machines won't lauch when you specific -M pc-0.14.
>
> Thoughts?
>
>



check this and reply to it:
http://lists.ovirt.org/pipermail/users/2012-March/001439.html


From dougsland at redhat.com  Thu Apr  5 19:57:15 2012
From: dougsland at redhat.com (Douglas Landgraf)
Date: Thu, 05 Apr 2012 15:57:15 -0400
Subject: [Engine-devel] Backing up the DB
In-Reply-To: <8e265a23-419d-417e-9a11-a7547f9f6c91@zmail14.collab.prod.int.phx2.redhat.com>
References: <8e265a23-419d-417e-9a11-a7547f9f6c91@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <4F7DF91B.1020006@redhat.com>

Hi,

On 04/05/2012 04:27 AM, Ofer Schreiber wrote:
> We already have the backup code in python - under engine-cleanup
> What about using the same code-base?
> or adding --backup-db-only to engine-cleaup?

 From my point of view, it's ok. If we are going to use engine-cleanup, 
let's keep in mind the restore mode too.
For while, I will use engine-db-tool that's already ready.

-- 
Cheers
Douglas

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

From dlaor at redhat.com  Thu Apr  5 21:43:23 2012
From: dlaor at redhat.com (Dor Laor)
Date: Fri, 06 Apr 2012 00:43:23 +0300
Subject: [Engine-devel] qemu machine type / datacenter machine version
In-Reply-To: <4F7DD2F2.303@redhat.com>
References: <20120405152719.GB25807@us.ibm.com> <4F7DD2F2.303@redhat.com>
Message-ID: <4F7E11FB.9080403@redhat.com>

On 04/05/2012 08:14 PM, Itamar Heim wrote:
> On 04/05/2012 06:27 PM, Ryan Harper wrote:
>> I was playing around with ovirt-engine datacenter definitions and I
>> seems that the capatibility version in the gui controls the qemu machine
>> type specified (3.0 -> pc-0.14). I was wondering where that's
>> configured setup.
>>
>> I grepped through my deployed system and saw a hit here:
>>
>> [root at f16-engine ovirt-engine]# rpm -qf /usr/share/ovirt-engine
>> ovirt-engine-3.0.0_0001-1.2.fc16.x86_64
>> [root at f16-engine ovirt-engine]# grep -nri "pc-0.14" *
>> db-backups/tmprN1EDt.sql:12119:INSERT INTO vdc_options (option_id,
>> option_name, option_value, version) VALUES (236, 'EmulatedMachine',
>> 'pc-0.14', '3.0');
>> db-backups/tmpj4XRCI.sql:12138:INSERT INTO vdc_options (option_id,
>> option_name, option_value, version) VALUES (236, 'EmulatedMachine',
>> 'pc-0.14', '3.0');
>> dbscripts/upgrade/03_00_0530_update_EmulatedMachine_config_to_pc.sql:2:select
>> fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0');
>> dbscripts/create_db.sh.log:7571:select
>> fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0');
>> dbscripts/create_db.sh.log:25529:select
>> fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0');
>> dbscripts/create_db.sh.log:43487:select
>> fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0');
>>
>> Is there any way to define different compatibiilty versions or edit
>> that? If I've got a new end-point running qemu-kvm that doesn't have
>> pc-0.14 defined (Say RHEL6.x) the machines won't lauch when you
>> specific -M pc-0.14.
>>
>> Thoughts?
>>
>>
>
>
>
> check this and reply to it:
> http://lists.ovirt.org/pipermail/users/2012-March/001439.html

Since the topic was brought up, I have a long going request that oVirt 
will enable users to run multiple machine type versions on the same host 
(using the same qemu binary but providing a different -M compatibility 
level per VM).

Is that on the roadmap?

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



From emesika at redhat.com  Fri Apr  6 01:51:56 2012
From: emesika at redhat.com (Eli Mesika)
Date: Thu, 05 Apr 2012 21:51:56 -0400 (EDT)
Subject: [Engine-devel] Backing up the DB
In-Reply-To: <4F7DF91B.1020006@redhat.com>
Message-ID: <7f8d5819-fdcf-45e2-a14d-ee37eecee2da@zmail13.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Douglas Landgraf" <dougsland at redhat.com>
> To: "Ofer Schreiber" <oschreib at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Thursday, April 5, 2012 10:57:15 PM
> Subject: Re: [Engine-devel] Backing up the DB
> 
> 
> Hi,
> 
> On 04/05/2012 04:27 AM, Ofer Schreiber wrote:
> 
> 
> We already have the backup code in python - under engine-cleanup
> What about using the same code-base?
> or adding --backup-db-only to engine-cleaup?

I think that we should do simple bash wrapper scripts for backup/restore that calls pg_dump/pg_restore , put those scripts in dbscripts where all db stuff is located and print a message that other options are available using the original pg_dump/pg_restore 


> 
> From my point of view, it's ok. If we are going to use
> engine-cleanup, let's keep in mind the restore mode too.
> For while, I will use engine-db-tool that's already ready.
> 
> --
> Cheers
> Douglas
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From iheim at redhat.com  Fri Apr  6 03:00:58 2012
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 06 Apr 2012 06:00:58 +0300
Subject: [Engine-devel] qemu machine type / datacenter machine version
In-Reply-To: <4F7E11FB.9080403@redhat.com>
References: <20120405152719.GB25807@us.ibm.com> <4F7DD2F2.303@redhat.com>
	<4F7E11FB.9080403@redhat.com>
Message-ID: <4F7E5C6A.7030904@redhat.com>

On 04/06/2012 12:43 AM, Dor Laor wrote:
> On 04/05/2012 08:14 PM, Itamar Heim wrote:
>> On 04/05/2012 06:27 PM, Ryan Harper wrote:
>>> I was playing around with ovirt-engine datacenter definitions and I
>>> seems that the capatibility version in the gui controls the qemu machine
>>> type specified (3.0 -> pc-0.14). I was wondering where that's
>>> configured setup.
>>>
>>> I grepped through my deployed system and saw a hit here:
>>>
>>> [root at f16-engine ovirt-engine]# rpm -qf /usr/share/ovirt-engine
>>> ovirt-engine-3.0.0_0001-1.2.fc16.x86_64
>>> [root at f16-engine ovirt-engine]# grep -nri "pc-0.14" *
>>> db-backups/tmprN1EDt.sql:12119:INSERT INTO vdc_options (option_id,
>>> option_name, option_value, version) VALUES (236, 'EmulatedMachine',
>>> 'pc-0.14', '3.0');
>>> db-backups/tmpj4XRCI.sql:12138:INSERT INTO vdc_options (option_id,
>>> option_name, option_value, version) VALUES (236, 'EmulatedMachine',
>>> 'pc-0.14', '3.0');
>>> dbscripts/upgrade/03_00_0530_update_EmulatedMachine_config_to_pc.sql:2:select
>>>
>>> fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0');
>>> dbscripts/create_db.sh.log:7571:select
>>> fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0');
>>> dbscripts/create_db.sh.log:25529:select
>>> fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0');
>>> dbscripts/create_db.sh.log:43487:select
>>> fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0');
>>>
>>> Is there any way to define different compatibiilty versions or edit
>>> that? If I've got a new end-point running qemu-kvm that doesn't have
>>> pc-0.14 defined (Say RHEL6.x) the machines won't lauch when you
>>> specific -M pc-0.14.
>>>
>>> Thoughts?
>>>
>>>
>>
>>
>>
>> check this and reply to it:
>> http://lists.ovirt.org/pipermail/users/2012-March/001439.html
>
> Since the topic was brought up, I have a long going request that oVirt
> will enable users to run multiple machine type versions on the same host
> (using the same qemu binary but providing a different -M compatibility
> level per VM).
>
> Is that on the roadmap?

I assume once will start with cluster level enumeration/monitoring first 
which is the bug which i asked to open around this thread.
then look at per vm level (I'm guessing best way to make this easy to 
manage at per-vm level would be to use 'cluster default' for most vm's)
I understand choosing cpu model per vm may (mainly for -cpu best) also 
be desirable in some cases.


From mpastern at redhat.com  Fri Apr  6 09:17:58 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Fri, 06 Apr 2012 12:17:58 +0300
Subject: [Engine-devel] VDSM REST API
In-Reply-To: <20120403220326.GC10117@aglitke>
References: <20120403220326.GC10117@aglitke>
Message-ID: <4F7EB4C6.1060402@redhat.com>


Hey Adam,

to make it work you need two things:

1. xsd schema
2. RSDL

then you will be able to generate SDK which is the key
to shell.

1. xsd schema, basically this is a /standard/ for
restful application to have it, so consuming application
will be able to generate bindings to your api in different
languages, in ovirt-sdk i'm using generateDS to generate python
bindings from our schema,

of course since your api written in python, you can bypass
this, but i still strongly recommend you exposing xsd schema,
and as about format - nothing special. just should compile with lxml

2. RSDL - i'm in a middle of writing spec for it, but in general
you can see RSDL structure in our xsd schema and can easlly figure out
how to use it (let me know if you have questions)

once you have these two, you can generate SDK, see src/codegen/README
in sdk repo, and after you'll have sdk, all is left is to point it from
cli, and as you mentioned cli will dynamically discover it at runtime.


On 04/04/2012 01:03 AM, Adam Litke wrote:
> Hi all,
> 
> At the oVirt Workshop in Beijing I learned about how the ovirt-shell dynamically
> discovers: the collections, resource schemas, and allowed actions based on an
> RSDL file and API xsd schema.  I am working on a REST API for vdsm and would
> like to make my API compatible with the ovirt-engine api such that the same
> ovirt-shell program could work with either the engine api or the vdsm api.
> 
> There are many differences between ovirt-engine and vdsm (namely that one is
> implemented in Java and the other in Python).  I think the easiest way to test
> whether this is possible is to try and create a new, minimalist REST service with
> python Cherrypy.  Such a service would have a root URL with no collections or
> actions.  From my understanding I will need to write the following files:
> 
> /api	    - A basic XML representation of the API root resource
> /api?schema - An xsd that describes the simple API
> /api?rsdl   - An rsdl (XML file) that describes the available links
> 
> for /api, I want to start with something dead-simple:
> 
> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> <api>
>   <messages>
>     <message id='foo' href='bar'>
>       Hello from vdsm!
>     </message>
>   </messages>
> </api>
> 
> Once I can use ovirt-shell to list messages and show messages I will be happy to
> build on it.  Can anyone help me figure out the minimal xsd and rsdl that would
> be needed for such an API to be consumable by ovirt-shell?  Thanks for your
> help!
> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From acathrow at redhat.com  Fri Apr  6 09:50:36 2012
From: acathrow at redhat.com (Andrew Cathrow)
Date: Fri, 06 Apr 2012 05:50:36 -0400 (EDT)
Subject: [Engine-devel] qemu machine type / datacenter machine version
Message-ID: <na35qs6t371hpychuaebwqe7.1333699997595@email.android.com>

It is only configured in the database today.
A good short term solution would be exposing this in the engine-config tool to save users having to hack the database, and potentially set this during setup.
But long term we need to incorporate the notion of per VM config versions, right now we take the config version from the cluster, which isn't the best approach. We need to merge the two concepts - host/cluster capabilities and VM config version.


Itamar Heim <iheim at redhat.com> wrote:

On 04/05/2012 06:27 PM, Ryan Harper wrote:
> I was playing around with ovirt-engine datacenter definitions and I
> seems that the capatibility version in the gui controls the qemu machine
> type specified (3.0 ->  pc-0.14).  I was wondering where that's
> configured setup.
>
> I grepped through my deployed system and saw a hit here:
>
> [root at f16-engine ovirt-engine]# rpm -qf /usr/share/ovirt-engine
> ovirt-engine-3.0.0_0001-1.2.fc16.x86_64
> [root at f16-engine ovirt-engine]# grep -nri "pc-0.14" *
> db-backups/tmprN1EDt.sql:12119:INSERT INTO vdc_options (option_id, option_name, option_value, version) VALUES (236, 'EmulatedMachine', 'pc-0.14', '3.0');
> db-backups/tmpj4XRCI.sql:12138:INSERT INTO vdc_options (option_id, option_name, option_value, version) VALUES (236, 'EmulatedMachine', 'pc-0.14', '3.0');
> dbscripts/upgrade/03_00_0530_update_EmulatedMachine_config_to_pc.sql:2:select fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0');
> dbscripts/create_db.sh.log:7571:select fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0');
> dbscripts/create_db.sh.log:25529:select fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0');
> dbscripts/create_db.sh.log:43487:select fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0');
>
> Is there any way to define different compatibiilty versions or edit that?  If I've got a new end-point running qemu-kvm that doesn't have pc-0.14 defined (Say RHEL6.x) the machines won't lauch when you specific -M pc-0.14.
>
> Thoughts?
>
>



check this and reply to it:
http://lists.ovirt.org/pipermail/users/2012-March/001439.html
_______________________________________________
Engine-devel mailing list
Engine-devel at ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel


From djasa at redhat.com  Fri Apr  6 14:28:02 2012
From: djasa at redhat.com (David =?UTF-8?Q?Ja=C5=A1a?=)
Date: Fri, 06 Apr 2012 16:28:02 +0200
Subject: [Engine-devel] Purpose of Attached Inactive/Maintenance state of
	export domain?
Message-ID: <1333722482.18597.7.camel@dhcp-29-7.brq.redhat.com>

Hi,

As I'm using export domain to shove VMs and templates betweend RHEV
setups pretty often lately, I'm wondering about $SUBJ. What is it good
for? Is it just for situation when main Data storage domain goes down?

If so, I'll probably file a RFE to be able to get the domain from
Unattached to Active state and vice versa via single click as having to
wait half minute before I can do a successive click is quite a big
annoyance.

David

-- 

David Ja?a, RHCE

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





From ryanh at us.ibm.com  Fri Apr  6 14:58:09 2012
From: ryanh at us.ibm.com (Ryan Harper)
Date: Fri, 6 Apr 2012 09:58:09 -0500
Subject: [Engine-devel] upstream/downstream compat
Message-ID: <20120406145809.GL25807@us.ibm.com>

I've submitted some changes to start some of the work of removing the
RHEV/RHEVM names throughout the vdsm code.  In one of the patches,
there's a good discussion on compatibility with downstream[1]
And I wanted to continue that on the mailing list so we could have more
eyes; it's not clear to me if everyone is able to see/participate in an
inline thread to just one of my patches.

To the point; as we look at moving toward an upstream vdsm which may be
used stand-alone; ie, it may or may not having ovirt-engine/RHEVM
driving actions.  I'm interested in hearing details what our
requirements for compatibility are and which parts of the tree might be
affected.

I'd like to posit that downstream compat is the responsibility of the
distro versus the upstream community; though that's not a license to
make things difficult.  IMHO, this means we can do things that help
clean up the code or move the project in a particular direction without
having to always worry about what the package looks like in a particular
distro.  

The other aspect to compatibility I'd like to hear details/discussion on
the interfaces (explicit or implicit) between vdsm and ovirt-engine.
I rekindled a discussion[2] on at least one known issue around engine
including the qemu machine type in the database;  Any pointers to other
places would be helpful as I'm wrapping my head around the back and
forth between vdsm and engine.



1. http://gerrit.ovirt.org/#patch,unified,3287,1,vds_bootstrap/vds_bootstrap.py
2. http://lists.ovirt.org/pipermail/engine-devel/2012-April/001209.html

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



From yzaslavs at redhat.com  Sat Apr  7 08:49:14 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Sat, 07 Apr 2012 11:49:14 +0300
Subject: [Engine-devel] Backing up the DB
In-Reply-To: <7f8d5819-fdcf-45e2-a14d-ee37eecee2da@zmail13.collab.prod.int.phx2.redhat.com>
References: <7f8d5819-fdcf-45e2-a14d-ee37eecee2da@zmail13.collab.prod.int.phx2.redhat.com>
Message-ID: <4F7FFF8A.9040003@redhat.com>

On 04/06/2012 04:51 AM, Eli Mesika wrote:
> 
> 
> ----- Original Message -----
>> From: "Douglas Landgraf" <dougsland at redhat.com>
>> To: "Ofer Schreiber" <oschreib at redhat.com>
>> Cc: engine-devel at ovirt.org
>> Sent: Thursday, April 5, 2012 10:57:15 PM
>> Subject: Re: [Engine-devel] Backing up the DB
>>
>>
>> Hi,
>>
>> On 04/05/2012 04:27 AM, Ofer Schreiber wrote:
>>
>>
>> We already have the backup code in python - under engine-cleanup
>> What about using the same code-base?
>> or adding --backup-db-only to engine-cleaup?
> 
> I think that we should do simple bash wrapper scripts for backup/restore that calls pg_dump/pg_restore , put those scripts in dbscripts where all db stuff is located and print a message that other options are available using the original pg_dump/pg_restore 
+1 - the scripts should use the options for pg_dump as specified in the
script provided by Douglas (the py version)
> 
> 
>>
>> From my point of view, it's ok. If we are going to use
>> engine-cleanup, let's keep in mind the restore mode too.
>> For while, I will use engine-db-tool that's already ready.
>>
>> --
>> Cheers
>> Douglas
>> _______________________________________________
>> 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 lyarwood at redhat.com  Sat Apr  7 15:10:01 2012
From: lyarwood at redhat.com (Lee Yarwood)
Date: Sat, 07 Apr 2012 16:10:01 +0100
Subject: [Engine-devel] Is there a preferred workflow when adding additional
 error messages to VDSM _and_ Engine?
Message-ID: <4F8058C9.8010808@redhat.com>

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

Hello all,

I'm currently working on a patch to correct the logic used by vdsm when
reviewing the logical and physical block size of physical volumes [1].
Once/If this is approved I'd like to look into making the exceptions
thrown from vdsm and the errors displayed within engine more descriptive.

Before I start throwing patches into gerrit I was wondering *if* there
is a preferred workflow when adding additional exceptions and error
messages across both projects. For example, committing changes to vdsm
before engine, engine before vdsm or both at the same time.

I'm also wondering if there is a way to say that vdsm gerrit changeid x
relies on engine gerrit changeid y etc?

Thanks in advance,

Lee
- -- 

Lee Yarwood
Software Maintenance Engineer
Red Hat UK Ltd
200 Fowler Avenue IQ Farnborough, Farnborough, Hants GU14 7JP

Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt
Parson(USA), Charlie Peters (USA)

GPG fingerprint : A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672 2D76
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPgFjGAAoJELymbjP2ci12MScIANRBXgWPSjeSZvSM2+bZmDrD
FefJfxMcCQFtTqWYePXIxFgqeeRcFc57+6alExBRU2g9nKZJEIPn2vj640XSTGlt
n5T4ItED1IVydzuEXFOAvgaTmZfKzTQkxQWp8QgL6pC7cYgnp2nL7gkbkedx1JyI
gCgCGomrHeWP2++vUS8UjtCccZdTJiOiWqoH2sBCKgEVcmFMgvYREK6hTou4DHU4
DcpureWuLvM4HWUlyfl37eXQOmy66A7uHGp3xF5sykQZ9aozaiMFjSoCqQOEVqO6
jHRnsQB6FfF/xU+F/UQK5PKZOm7e+KvrMjhIDfR+/DX3t0rkrtc69gg2O6duy4o=
=vdud
-----END PGP SIGNATURE-----


From mkenneth at redhat.com  Sun Apr  8 06:50:20 2012
From: mkenneth at redhat.com (Miki Kenneth)
Date: Sun, 08 Apr 2012 02:50:20 -0400 (EDT)
Subject: [Engine-devel] qemu machine type / datacenter machine version
In-Reply-To: <na35qs6t371hpychuaebwqe7.1333699997595@email.android.com>
Message-ID: <83c25d38-ad2a-4928-93f1-504418159448@mkenneth.csb>



----- Original Message -----
> From: "Andrew Cathrow" <acathrow at redhat.com>
> To: engine-devel at ovirt.org, "Ryan Harper" <ryanh at us.ibm.com>
> Sent: Friday, April 6, 2012 12:50:36 PM
> Subject: Re: [Engine-devel] qemu machine type / datacenter machine version
> 
> It is only configured in the database today.
> A good short term solution would be exposing this in the
> engine-config tool to save users having to hack the database, and
> potentially set this during setup.
> But long term we need to incorporate the notion of per VM config
> versions, right now we take the config version from the cluster,
> which isn't the best approach. We need to merge the two concepts -
> host/cluster capabilities and VM config version.
and combined that with the "deployment profile" and "configuration profile" per VM
(as was mentioned at Foreman/Ovirt presentation)

> 
> 
> Itamar Heim <iheim at redhat.com> wrote:
> 
> On 04/05/2012 06:27 PM, Ryan Harper wrote:
> > I was playing around with ovirt-engine datacenter definitions and I
> > seems that the capatibility version in the gui controls the qemu
> > machine
> > type specified (3.0 ->  pc-0.14).  I was wondering where that's
> > configured setup.
> >
> > I grepped through my deployed system and saw a hit here:
> >
> > [root at f16-engine ovirt-engine]# rpm -qf /usr/share/ovirt-engine
> > ovirt-engine-3.0.0_0001-1.2.fc16.x86_64
> > [root at f16-engine ovirt-engine]# grep -nri "pc-0.14" *
> > db-backups/tmprN1EDt.sql:12119:INSERT INTO vdc_options (option_id,
> > option_name, option_value, version) VALUES (236,
> > 'EmulatedMachine', 'pc-0.14', '3.0');
> > db-backups/tmpj4XRCI.sql:12138:INSERT INTO vdc_options (option_id,
> > option_name, option_value, version) VALUES (236,
> > 'EmulatedMachine', 'pc-0.14', '3.0');
> > dbscripts/upgrade/03_00_0530_update_EmulatedMachine_config_to_pc.sql:2:select
> > fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0');
> > dbscripts/create_db.sh.log:7571:select
> > fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0');
> > dbscripts/create_db.sh.log:25529:select
> > fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0');
> > dbscripts/create_db.sh.log:43487:select
> > fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0');
> >
> > Is there any way to define different compatibiilty versions or edit
> > that?  If I've got a new end-point running qemu-kvm that doesn't
> > have pc-0.14 defined (Say RHEL6.x) the machines won't lauch when
> > you specific -M pc-0.14.
> >
> > Thoughts?
> >
> >
> 
> 
> 
> check this and reply to it:
> http://lists.ovirt.org/pipermail/users/2012-March/001439.html
> _______________________________________________
> 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  Sun Apr  8 09:03:20 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Sun, 08 Apr 2012 12:03:20 +0300
Subject: [Engine-devel] Purpose of Attached Inactive/Maintenance state
 of export domain?
In-Reply-To: <1333722482.18597.7.camel@dhcp-29-7.brq.redhat.com>
References: <1333722482.18597.7.camel@dhcp-29-7.brq.redhat.com>
Message-ID: <4F815458.5070109@redhat.com>

On 06/04/12 17:28, David Ja?a wrote:
> Hi,
> 
> As I'm using export domain to shove VMs and templates betweend RHEV
> setups pretty often lately, I'm wondering about $SUBJ. What is it good
> for? Is it just for situation when main Data storage domain goes down?
> 

Hi David,

- Attached Inactive export SD indicates that there is some problem with
this SD, we added a feature to auto recover from this state
(automatically activating the SD on a periodical basis)

- Attached maintenance means that the domain is going through some kind
of manual handling procedure and the system should not access this
domain, this state is initiate only upon user explicit request.


Having said the above there is no good reason, IMO, not to expose attach
and activate in a single command/UI action (I think we had RFE on this).
For example when working with floating disks (another new feature) you
can attach a disk to VM and activate it in a single command.


Livna



> If so, I'll probably file a RFE to be able to get the domain from
> Unattached to Active state and vice versa via single click as having to
> wait half minute before I can do a successive click is quite a big
> annoyance.
> 
> David
> 



From dlaor at redhat.com  Sun Apr  8 09:47:27 2012
From: dlaor at redhat.com (Dor Laor)
Date: Sun, 08 Apr 2012 12:47:27 +0300
Subject: [Engine-devel] qemu machine type / datacenter machine version
In-Reply-To: <4F7E5C6A.7030904@redhat.com>
References: <20120405152719.GB25807@us.ibm.com> <4F7DD2F2.303@redhat.com>
	<4F7E11FB.9080403@redhat.com> <4F7E5C6A.7030904@redhat.com>
Message-ID: <4F815EAF.9080205@redhat.com>

On 04/06/2012 06:00 AM, Itamar Heim wrote:
>>>
>>>
>>> check this and reply to it:
>>> http://lists.ovirt.org/pipermail/users/2012-March/001439.html
>>
>> Since the topic was brought up, I have a long going request that oVirt
>> will enable users to run multiple machine type versions on the same host
>> (using the same qemu binary but providing a different -M compatibility
>> level per VM).
>>
>> Is that on the roadmap?
>
> I assume once will start with cluster level enumeration/monitoring first
> which is the bug which i asked to open around this thread.
> then look at per vm level (I'm guessing best way to make this easy to
> manage at per-vm level would be to use 'cluster default' for most vm's)
> I understand choosing cpu model per vm may (mainly for -cpu best) also
> be desirable in some cases.

Cpu model is a VM property. Setting anything beyond the least common 
denominator of your set of hardware hosts, may restrict using some of 
the older hosts as expected.

btw: -cpu best is less flexible for non homogeneous set of hosts. Better 
use an explicit model for such environment. In theory the newest models 
should perform just as good as -best


From abaron at redhat.com  Sun Apr  8 14:10:32 2012
From: abaron at redhat.com (Ayal Baron)
Date: Sun, 08 Apr 2012 10:10:32 -0400 (EDT)
Subject: [Engine-devel] [vdsm] Is there a preferred workflow when adding
	additional error messages to VDSM _and_ Engine?
In-Reply-To: <4F8058C9.8010808@redhat.com>
Message-ID: <3cc5290e-2ea3-484f-9449-57eb58305155@zmail13.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello all,
> 
> I'm currently working on a patch to correct the logic used by vdsm
> when
> reviewing the logical and physical block size of physical volumes
> [1].
> Once/If this is approved I'd like to look into making the exceptions
> thrown from vdsm and the errors displayed within engine more
> descriptive.
> 
> Before I start throwing patches into gerrit I was wondering *if*
> there
> is a preferred workflow when adding additional exceptions and error
> messages across both projects. For example, committing changes to
> vdsm
> before engine, engine before vdsm or both at the same time.
> 
> I'm also wondering if there is a way to say that vdsm gerrit changeid
> x
> relies on engine gerrit changeid y etc?

Adding in engine does not rely on vdsm actually throwing the exception.
Adding in vdsm without corresponding code in engine would just mean that a generic message is displayed to user, so either way is ok as long as you make sure to submit both.
There is no need for a dependency between gerrits (and I'm not sure how that would work either, but I'm not aware of any such mechanism at the moment).

> 
> Thanks in advance,
> 
> Lee
> - --
> 
> Lee Yarwood
> Software Maintenance Engineer
> Red Hat UK Ltd
> 200 Fowler Avenue IQ Farnborough, Farnborough, Hants GU14 7JP
> 
> Registered in England and Wales under Company Registration No.
> 03798903
> Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt
> Parson(USA), Charlie Peters (USA)
> 
> GPG fingerprint : A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672 2D76
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iQEcBAEBAgAGBQJPgFjGAAoJELymbjP2ci12MScIANRBXgWPSjeSZvSM2+bZmDrD
> FefJfxMcCQFtTqWYePXIxFgqeeRcFc57+6alExBRU2g9nKZJEIPn2vj640XSTGlt
> n5T4ItED1IVydzuEXFOAvgaTmZfKzTQkxQWp8QgL6pC7cYgnp2nL7gkbkedx1JyI
> gCgCGomrHeWP2++vUS8UjtCccZdTJiOiWqoH2sBCKgEVcmFMgvYREK6hTou4DHU4
> DcpureWuLvM4HWUlyfl37eXQOmy66A7uHGp3xF5sykQZ9aozaiMFjSoCqQOEVqO6
> jHRnsQB6FfF/xU+F/UQK5PKZOm7e+KvrMjhIDfR+/DX3t0rkrtc69gg2O6duy4o=
> =vdud
> -----END PGP SIGNATURE-----
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/vdsm-devel
> 


From rgolan at redhat.com  Mon Apr  9 08:42:59 2012
From: rgolan at redhat.com (Roy Golan)
Date: Mon, 09 Apr 2012 11:42:59 +0300
Subject: [Engine-devel] deprecating auto-detection of Ldap provider types
Message-ID: <4F82A113.8040409@redhat.com>

auto-detection featured few bugs lately which convinced me that it must 
be deprecated/removed from
the code in favor of adding manual set of the provider type.

main reasons for that:
a. the provider is type is known by the user
b. identifying a provider by the rootDSE attributes is error-prone, not 
reliable etc... specially if the support matrix is growing
c. auto-detection logic is duplicated (and not shared) between the 
backend code and the manage-domains tool (nevermind the reasons now)

A manual set of the provider type requires a new configuration field for 
a domain and the
question is the upgrade path which may look like

* set the provider type to default Active Directory (because its more 
likely to be the provider type)
* things not working -  use the engine-manage-domains and choose the 
provider type.
* optionally - keep the auto-detection (of the tool only!)  if user 
wants to use it.

your suggestion and thoughts...

Thanks,
Roy





From yzaslavs at redhat.com  Mon Apr  9 08:50:53 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Mon, 09 Apr 2012 11:50:53 +0300
Subject: [Engine-devel] deprecating auto-detection of Ldap provider types
In-Reply-To: <4F82A113.8040409@redhat.com>
References: <4F82A113.8040409@redhat.com>
Message-ID: <4F82A2ED.4060509@redhat.com>

On 04/09/2012 11:42 AM, Roy Golan wrote:
> auto-detection featured few bugs lately which convinced me that it must
> be deprecated/removed from
> the code in favor of adding manual set of the provider type.
> 
> main reasons for that:
> a. the provider is type is known by the user
> b. identifying a provider by the rootDSE attributes is error-prone, not
> reliable etc... specially if the support matrix is growing
> c. auto-detection logic is duplicated (and not shared) between the
> backend code and the manage-domains tool (nevermind the reasons now)
> 
> A manual set of the provider type requires a new configuration field for
> a domain and the
> question is the upgrade path which may look like
> 
> * set the provider type to default Active Directory (because its more
> likely to be the provider type)
I think we should not have this assumption -for new environments ldap
provider type MUST be set via manage domains.

> * things not working -  use the engine-manage-domains and choose the
> provider type.
> * optionally - keep the auto-detection (of the tool only!)  if user
> wants to use it.
> 
> your suggestion and thoughts...
+1 in general about the idea.
We have to handle upgrades though (providing ldap provider type data in
DB in already-installed environments).
> 
> Thanks,
> Roy
> 
> 
> 



From lpeer at redhat.com  Mon Apr  9 09:11:55 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Mon, 09 Apr 2012 12:11:55 +0300
Subject: [Engine-devel] deprecating auto-detection of Ldap provider types
In-Reply-To: <4F82A113.8040409@redhat.com>
References: <4F82A113.8040409@redhat.com>
Message-ID: <4F82A7DB.7020304@redhat.com>

On 09/04/12 11:42, Roy Golan wrote:
> auto-detection featured few bugs lately which convinced me that it must
> be deprecated/removed from
> the code in favor of adding manual set of the provider type.
> 
> main reasons for that:
> a. the provider is type is known by the user
> b. identifying a provider by the rootDSE attributes is error-prone, not
> reliable etc... specially if the support matrix is growing
> c. auto-detection logic is duplicated (and not shared) between the
> backend code and the manage-domains tool (nevermind the reasons now)
> 

+1 for removing this 'feature'

> A manual set of the provider type requires a new configuration field for
> a domain and the
> question is the upgrade path which may look like
> 
> * set the provider type to default Active Directory (because its more
> likely to be the provider type)
> * things not working -  use the engine-manage-domains and choose the
> provider type.

> * optionally - keep the auto-detection (of the tool only!)  if user
> wants to use it.

I think we should require that the user specifies the provider type
(from now on), and enable editing this field of course.

Another upgrade proposal is to populate the provider type only upon the
first time we need to use this domain (and it is not populated) by using
the current 'auto-detect' mechanism.

By taking the above approach we don't break behavior for the user and we
enable manually fixing of the domain provider type (which is a bypass
for all current bugs in the auto-detect).


Livnat


> 
> your suggestion and thoughts...
> 
> Thanks,
> Roy
> 
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From danken at redhat.com  Mon Apr  9 09:21:19 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Mon, 9 Apr 2012 12:21:19 +0300
Subject: [Engine-devel] [vdsm] upstream/downstream compat
In-Reply-To: <20120406145809.GL25807@us.ibm.com>
References: <20120406145809.GL25807@us.ibm.com>
Message-ID: <20120409092118.GK31983@redhat.com>

On Fri, Apr 06, 2012 at 09:58:09AM -0500, Ryan Harper wrote:
> I've submitted some changes to start some of the work of removing the
> RHEV/RHEVM names throughout the vdsm code.  In one of the patches,
> there's a good discussion on compatibility with downstream[1]
> And I wanted to continue that on the mailing list so we could have more
> eyes; it's not clear to me if everyone is able to see/participate in an
> inline thread to just one of my patches.
> 
> To the point; as we look at moving toward an upstream vdsm which may be
> used stand-alone; ie, it may or may not having ovirt-engine/RHEVM
> driving actions.  I'm interested in hearing details what our
> requirements for compatibility are and which parts of the tree might be
> affected.
> 
> I'd like to posit that downstream compat is the responsibility of the
> distro versus the upstream community; though that's not a license to
> make things difficult.  IMHO, this means we can do things that help
> clean up the code or move the project in a particular direction without
> having to always worry about what the package looks like in a particular
> distro.  

Blissful upstream development is great for upstream maintainer (me), but
it leads to serious headaches for downstream maintainer with
considerable installed base (me). We have a lot of Fedoraisms and
RHELisms and RHEVisms in our code. Removing them is noble, probably
legally required, and I truly thank whomever cleans up the code. But
since there are so many of them, blind removal can add significant
burden on yours truly and his colleagues.

I would like to ask upstream to think twice before breaking downstream
compatibility. Downstream can always revert your patch, but let's make
it easier on them^Wus - have a configurable value, so that downstream
patch is a oneliner, for example. If an API must be broken, let's file a
bug on the adjacent component, so as not to surprise it.

So please, worry about how the package would look in particular distros
with considerable installed base. Discuss upgrade paths. Help make Vdsm
easily downstreamable.

> 
> The other aspect to compatibility I'd like to hear details/discussion on
> the interfaces (explicit or implicit) between vdsm and ovirt-engine.
> I rekindled a discussion[2] on at least one known issue around engine
> including the qemu machine type in the database;  Any pointers to other
> places would be helpful as I'm wrapping my head around the back and
> forth between vdsm and engine.
> 
> 
> 
> 1. http://gerrit.ovirt.org/#patch,unified,3287,1,vds_bootstrap/vds_bootstrap.py
> 2. http://lists.ovirt.org/pipermail/engine-devel/2012-April/001209.html
> 
> -- 
> Ryan Harper
> Software Engineer; Linux Technology Center
> IBM Corp., Austin, Tx
> ryanh at us.ibm.com


From ovedo at redhat.com  Mon Apr  9 09:23:31 2012
From: ovedo at redhat.com (Oved Ourfalli)
Date: Mon, 09 Apr 2012 05:23:31 -0400 (EDT)
Subject: [Engine-devel] deprecating auto-detection of Ldap provider types
In-Reply-To: <4F82A7DB.7020304@redhat.com>
Message-ID: <02703f83-8d68-4d37-ac32-99589be03461@zmail02.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Livnat Peer" <lpeer at redhat.com>
> To: "Roy Golan" <rgolan at redhat.com>
> Cc: "Oved Ourfalli" <ovedo at redhat.com>, engine-devel at ovirt.org
> Sent: Monday, April 9, 2012 12:11:55 PM
> Subject: Re: [Engine-devel] deprecating auto-detection of Ldap provider types
> 
> On 09/04/12 11:42, Roy Golan wrote:
> > auto-detection featured few bugs lately which convinced me that it
> > must
> > be deprecated/removed from
> > the code in favor of adding manual set of the provider type.
> > 
> > main reasons for that:
> > a. the provider is type is known by the user
> > b. identifying a provider by the rootDSE attributes is error-prone,
> > not
> > reliable etc... specially if the support matrix is growing
> > c. auto-detection logic is duplicated (and not shared) between the
> > backend code and the manage-domains tool (nevermind the reasons
> > now)
> > 
> 
> +1 for removing this 'feature'
> 
+1 for that as well.

> > A manual set of the provider type requires a new configuration
> > field for
> > a domain and the
> > question is the upgrade path which may look like
> > 
> > * set the provider type to default Active Directory (because its
> > more
> > likely to be the provider type)
> > * things not working -  use the engine-manage-domains and choose
> > the
> > provider type.
> 
> > * optionally - keep the auto-detection (of the tool only!)  if user
> > wants to use it.
> 
> I think we should require that the user specifies the provider type
> (from now on), and enable editing this field of course.
> 
> Another upgrade proposal is to populate the provider type only upon
> the
> first time we need to use this domain (and it is not populated) by
> using
> the current 'auto-detect' mechanism.
> 
> By taking the above approach we don't break behavior for the user and
> we
> enable manually fixing of the domain provider type (which is a bypass
> for all current bugs in the auto-detect).
> 
> 
> Livnat
> 
> 
> > 
> > your suggestion and thoughts...
> > 
> > Thanks,
> > Roy
> > 
> > 
> > 
> > _______________________________________________
> > 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  Mon Apr  9 11:42:24 2012
From: rgolan at redhat.com (Roy Golan)
Date: Mon, 09 Apr 2012 14:42:24 +0300
Subject: [Engine-devel] deprecating auto-detection of Ldap provider types
In-Reply-To: <4F82A7DB.7020304@redhat.com>
References: <4F82A113.8040409@redhat.com> <4F82A7DB.7020304@redhat.com>
Message-ID: <4F82CB20.5010607@redhat.com>

On 04/09/2012 12:11 PM, Livnat Peer wrote:
> On 09/04/12 11:42, Roy Golan wrote:
>> auto-detection featured few bugs lately which convinced me that it must
>> be deprecated/removed from
>> the code in favor of adding manual set of the provider type.
>>
>> main reasons for that:
>> a. the provider is type is known by the user
>> b. identifying a provider by the rootDSE attributes is error-prone, not
>> reliable etc... specially if the support matrix is growing
>> c. auto-detection logic is duplicated (and not shared) between the
>> backend code and the manage-domains tool (nevermind the reasons now)
>>
> +1 for removing this 'feature'
>
>> A manual set of the provider type requires a new configuration field for
>> a domain and the
>> question is the upgrade path which may look like
>>
>> * set the provider type to default Active Directory (because its more
>> likely to be the provider type)
>> * things not working -  use the engine-manage-domains and choose the
>> provider type.
>> * optionally - keep the auto-detection (of the tool only!)  if user
>> wants to use it.
> I think we should require that the user specifies the provider type
> (from now on), and enable editing this field of course.
>
> Another upgrade proposal is to populate the provider type only upon the
> first time we need to use this domain (and it is not populated) by using
> the current 'auto-detect' mechanism.
and remove it the next version?
this means the auto-detection code remains in the backend code.
I think its the best to remove it totally but If we want to keep this 
functionality I rather just leave it in manage-domains alone,although if 
its another step for the user.
>
> By taking the above approach we don't break behavior for the user and we
> enable manually fixing of the domain provider type (which is a bypass
> for all current bugs in the auto-detect).
>
>
> Livnat
>
>
>> your suggestion and thoughts...
>>
>> Thanks,
>> Roy
>>
>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel



From lpeer at redhat.com  Mon Apr  9 11:47:50 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Mon, 09 Apr 2012 14:47:50 +0300
Subject: [Engine-devel] deprecating auto-detection of Ldap provider types
In-Reply-To: <4F82CB20.5010607@redhat.com>
References: <4F82A113.8040409@redhat.com> <4F82A7DB.7020304@redhat.com>
	<4F82CB20.5010607@redhat.com>
Message-ID: <4F82CC66.3040908@redhat.com>

On 09/04/12 14:42, Roy Golan wrote:
> On 04/09/2012 12:11 PM, Livnat Peer wrote:
>> On 09/04/12 11:42, Roy Golan wrote:
>>> auto-detection featured few bugs lately which convinced me that it must
>>> be deprecated/removed from
>>> the code in favor of adding manual set of the provider type.
>>>
>>> main reasons for that:
>>> a. the provider is type is known by the user
>>> b. identifying a provider by the rootDSE attributes is error-prone, not
>>> reliable etc... specially if the support matrix is growing
>>> c. auto-detection logic is duplicated (and not shared) between the
>>> backend code and the manage-domains tool (nevermind the reasons now)
>>>
>> +1 for removing this 'feature'
>>
>>> A manual set of the provider type requires a new configuration field for
>>> a domain and the
>>> question is the upgrade path which may look like
>>>
>>> * set the provider type to default Active Directory (because its more
>>> likely to be the provider type)
>>> * things not working -  use the engine-manage-domains and choose the
>>> provider type.
>>> * optionally - keep the auto-detection (of the tool only!)  if user
>>> wants to use it.
>> I think we should require that the user specifies the provider type
>> (from now on), and enable editing this field of course.
>>
>> Another upgrade proposal is to populate the provider type only upon the
>> first time we need to use this domain (and it is not populated) by using
>> the current 'auto-detect' mechanism.
> and remove it the next version?

yes

> this means the auto-detection code remains in the backend code.

only until next version

> I think its the best to remove it totally but If we want to keep this
> functionality I rather just leave it in manage-domains alone,although if
> its another step for the user.

I don't *want* to keep it but unless we want to set it hard coded during
upgrade I don't see how can we remove it.

BTW if we have to leave it in I would say to remove it from the tool and
leave in the backend (you have to have it in the backend for transparent
upgrade)


>>
>> By taking the above approach we don't break behavior for the user and we
>> enable manually fixing of the domain provider type (which is a bypass
>> for all current bugs in the auto-detect).
>>
>>
>> Livnat
>>
>>
>>> your suggestion and thoughts...
>>>
>>> Thanks,
>>> Roy
>>>
>>>
>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 



From mkenneth at redhat.com  Mon Apr  9 12:12:30 2012
From: mkenneth at redhat.com (Miki Kenneth)
Date: Mon, 09 Apr 2012 08:12:30 -0400 (EDT)
Subject: [Engine-devel] deprecating auto-detection of Ldap provider types
In-Reply-To: <4F82CC66.3040908@redhat.com>
Message-ID: <a67b9bcd-0730-42ba-a719-d73186f605a8@mkenneth.csb>

Excuse my ignorance... but I would like to understand the "new" behavior on:
- clean install? POC?
- How do I change the provider, after installation?
- upgrade path.

Miki

----- Original Message -----
> From: "Livnat Peer" <lpeer at redhat.com>
> To: "Roy Golan" <rgolan at redhat.com>
> Cc: "Oved Ourfalli" <ovedo at redhat.com>, engine-devel at ovirt.org
> Sent: Monday, April 9, 2012 2:47:50 PM
> Subject: Re: [Engine-devel] deprecating auto-detection of Ldap provider types
> 
> On 09/04/12 14:42, Roy Golan wrote:
> > On 04/09/2012 12:11 PM, Livnat Peer wrote:
> >> On 09/04/12 11:42, Roy Golan wrote:
> >>> auto-detection featured few bugs lately which convinced me that
> >>> it must
> >>> be deprecated/removed from
> >>> the code in favor of adding manual set of the provider type.
> >>>
> >>> main reasons for that:
> >>> a. the provider is type is known by the user
> >>> b. identifying a provider by the rootDSE attributes is
> >>> error-prone, not
> >>> reliable etc... specially if the support matrix is growing
> >>> c. auto-detection logic is duplicated (and not shared) between
> >>> the
> >>> backend code and the manage-domains tool (nevermind the reasons
> >>> now)
> >>>
> >> +1 for removing this 'feature'
> >>
> >>> A manual set of the provider type requires a new configuration
> >>> field for
> >>> a domain and the
> >>> question is the upgrade path which may look like
> >>>
> >>> * set the provider type to default Active Directory (because its
> >>> more
> >>> likely to be the provider type)
> >>> * things not working -  use the engine-manage-domains and choose
> >>> the
> >>> provider type.
> >>> * optionally - keep the auto-detection (of the tool only!)  if
> >>> user
> >>> wants to use it.
> >> I think we should require that the user specifies the provider
> >> type
> >> (from now on), and enable editing this field of course.
> >>
> >> Another upgrade proposal is to populate the provider type only
> >> upon the
> >> first time we need to use this domain (and it is not populated) by
> >> using
> >> the current 'auto-detect' mechanism.
> > and remove it the next version?
> 
> yes
> 
> > this means the auto-detection code remains in the backend code.
> 
> only until next version
> 
> > I think its the best to remove it totally but If we want to keep
> > this
> > functionality I rather just leave it in manage-domains
> > alone,although if
> > its another step for the user.
> 
> I don't *want* to keep it but unless we want to set it hard coded
> during
> upgrade I don't see how can we remove it.
> 
> BTW if we have to leave it in I would say to remove it from the tool
> and
> leave in the backend (you have to have it in the backend for
> transparent
> upgrade)
> 
> 
> >>
> >> By taking the above approach we don't break behavior for the user
> >> and we
> >> enable manually fixing of the domain provider type (which is a
> >> bypass
> >> for all current bugs in the auto-detect).
> >>
> >>
> >> Livnat
> >>
> >>
> >>> your suggestion and thoughts...
> >>>
> >>> Thanks,
> >>> Roy
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> 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  Mon Apr  9 12:17:27 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Mon, 09 Apr 2012 15:17:27 +0300
Subject: [Engine-devel] Is there a preferred workflow when adding
 additional error messages to VDSM _and_ Engine?
In-Reply-To: <4F8058C9.8010808@redhat.com>
References: <4F8058C9.8010808@redhat.com>
Message-ID: <4F82D357.5070009@redhat.com>

On 07/04/12 18:10, Lee Yarwood wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello all,
> 
> I'm currently working on a patch to correct the logic used by vdsm when
> reviewing the logical and physical block size of physical volumes [1].
> Once/If this is approved I'd like to look into making the exceptions
> thrown from vdsm and the errors displayed within engine more descriptive.
> 
> Before I start throwing patches into gerrit I was wondering *if* there
> is a preferred workflow when adding additional exceptions and error
> messages across both projects. For example, committing changes to vdsm
> before engine, engine before vdsm or both at the same time.
> 

Hi Lee,
We had a Jenkins Job to give warning if there is a new error code in
VDSM that is not covered in the backend.

I see this job is disabled in ovirt Jenkins,

http://jenkins.ovirt.org/job/vdsm_verify_error_codes/

Eyal, any specific reason this is disabled?

Livnat


> I'm also wondering if there is a way to say that vdsm gerrit changeid x
> relies on engine gerrit changeid y etc?
> 
> Thanks in advance,
> 
> Lee
> - -- 
> 
> Lee Yarwood
> Software Maintenance Engineer
> Red Hat UK Ltd
> 200 Fowler Avenue IQ Farnborough, Farnborough, Hants GU14 7JP
> 
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt
> Parson(USA), Charlie Peters (USA)
> 
> GPG fingerprint : A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672 2D76
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iQEcBAEBAgAGBQJPgFjGAAoJELymbjP2ci12MScIANRBXgWPSjeSZvSM2+bZmDrD
> FefJfxMcCQFtTqWYePXIxFgqeeRcFc57+6alExBRU2g9nKZJEIPn2vj640XSTGlt
> n5T4ItED1IVydzuEXFOAvgaTmZfKzTQkxQWp8QgL6pC7cYgnp2nL7gkbkedx1JyI
> gCgCGomrHeWP2++vUS8UjtCccZdTJiOiWqoH2sBCKgEVcmFMgvYREK6hTou4DHU4
> DcpureWuLvM4HWUlyfl37eXQOmy66A7uHGp3xF5sykQZ9aozaiMFjSoCqQOEVqO6
> jHRnsQB6FfF/xU+F/UQK5PKZOm7e+KvrMjhIDfR+/DX3t0rkrtc69gg2O6duy4o=
> =vdud
> -----END PGP SIGNATURE-----
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From ryanh at us.ibm.com  Mon Apr  9 12:25:24 2012
From: ryanh at us.ibm.com (Ryan Harper)
Date: Mon, 9 Apr 2012 07:25:24 -0500
Subject: [Engine-devel] [vdsm] upstream/downstream compat
In-Reply-To: <20120409092118.GK31983@redhat.com>
References: <20120406145809.GL25807@us.ibm.com>
	<20120409092118.GK31983@redhat.com>
Message-ID: <20120409122524.GR25807@us.ibm.com>

* Dan Kenigsberg <danken at redhat.com> [2012-04-09 04:21]:
> On Fri, Apr 06, 2012 at 09:58:09AM -0500, Ryan Harper wrote:
> > I've submitted some changes to start some of the work of removing the
> > RHEV/RHEVM names throughout the vdsm code.  In one of the patches,
> > there's a good discussion on compatibility with downstream[1]
> > And I wanted to continue that on the mailing list so we could have more
> > eyes; it's not clear to me if everyone is able to see/participate in an
> > inline thread to just one of my patches.
> > 
> > To the point; as we look at moving toward an upstream vdsm which may be
> > used stand-alone; ie, it may or may not having ovirt-engine/RHEVM
> > driving actions.  I'm interested in hearing details what our
> > requirements for compatibility are and which parts of the tree might be
> > affected.
> > 
> > I'd like to posit that downstream compat is the responsibility of the
> > distro versus the upstream community; though that's not a license to
> > make things difficult.  IMHO, this means we can do things that help
> > clean up the code or move the project in a particular direction without
> > having to always worry about what the package looks like in a particular
> > distro.  
> 
> Blissful upstream development is great for upstream maintainer (me), but
> it leads to serious headaches for downstream maintainer with
> considerable installed base (me). We have a lot of Fedoraisms and
> RHELisms and RHEVisms in our code. Removing them is noble, probably
> legally required, and I truly thank whomever cleans up the code. But
> since there are so many of them, blind removal can add significant
> burden on yours truly and his colleagues.
> 
> I would like to ask upstream to think twice before breaking downstream
> compatibility. Downstream can always revert your patch, but let's make
> it easier on them^Wus - have a configurable value, so that downstream
> patch is a oneliner, for example. If an API must be broken, let's file a
> bug on the adjacent component, so as not to surprise it.
> 
> So please, worry about how the package would look in particular distros
> with considerable installed base. Discuss upgrade paths. Help make Vdsm
> easily downstreamable.

Indeed, I wasn't suggesting we just completely ignore downstream, and I
think since you're both upstream and downstream maintainer you have
valuable insight on how best to make these changes.  Looking forward to
hearing details on how best to make upstream progress while retaining
downstream compat!



> 
> > 
> > The other aspect to compatibility I'd like to hear details/discussion on
> > the interfaces (explicit or implicit) between vdsm and ovirt-engine.
> > I rekindled a discussion[2] on at least one known issue around engine
> > including the qemu machine type in the database;  Any pointers to other
> > places would be helpful as I'm wrapping my head around the back and
> > forth between vdsm and engine.
> > 
> > 
> > 
> > 1. http://gerrit.ovirt.org/#patch,unified,3287,1,vds_bootstrap/vds_bootstrap.py
> > 2. http://lists.ovirt.org/pipermail/engine-devel/2012-April/001209.html
> > 
> > -- 
> > Ryan Harper
> > Software Engineer; Linux Technology Center
> > IBM Corp., Austin, Tx
> > ryanh at us.ibm.com

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



From rgolan at redhat.com  Mon Apr  9 13:12:36 2012
From: rgolan at redhat.com (Roy Golan)
Date: Mon, 09 Apr 2012 16:12:36 +0300
Subject: [Engine-devel] deprecating auto-detection of Ldap provider types
In-Reply-To: <a67b9bcd-0730-42ba-a719-d73186f605a8@mkenneth.csb>
References: <a67b9bcd-0730-42ba-a719-d73186f605a8@mkenneth.csb>
Message-ID: <4F82E044.4080407@redhat.com>

On 04/09/2012 03:12 PM, Miki Kenneth wrote:
> Excuse my ignorance... but I would like to understand the "new" behavior on:
> - clean install? POC?
when using the mangage domains, specify which provider type you want 
along with the domain
> - How do I change the provider, after installation?
run manage domains, alternatively engine-config
> - upgrade path.
when the backend starts it will auto-detect and keep the value in the DB 
for next time (so auto-detecting once per domain)
adding more domains via manage-domains requires the user to set the 
provider type
>
> Miki
>
> ----- Original Message -----
>> From: "Livnat Peer"<lpeer at redhat.com>
>> To: "Roy Golan"<rgolan at redhat.com>
>> Cc: "Oved Ourfalli"<ovedo at redhat.com>, engine-devel at ovirt.org
>> Sent: Monday, April 9, 2012 2:47:50 PM
>> Subject: Re: [Engine-devel] deprecating auto-detection of Ldap provider types
>>
>> On 09/04/12 14:42, Roy Golan wrote:
>>> On 04/09/2012 12:11 PM, Livnat Peer wrote:
>>>> On 09/04/12 11:42, Roy Golan wrote:
>>>>> auto-detection featured few bugs lately which convinced me that
>>>>> it must
>>>>> be deprecated/removed from
>>>>> the code in favor of adding manual set of the provider type.
>>>>>
>>>>> main reasons for that:
>>>>> a. the provider is type is known by the user
>>>>> b. identifying a provider by the rootDSE attributes is
>>>>> error-prone, not
>>>>> reliable etc... specially if the support matrix is growing
>>>>> c. auto-detection logic is duplicated (and not shared) between
>>>>> the
>>>>> backend code and the manage-domains tool (nevermind the reasons
>>>>> now)
>>>>>
>>>> +1 for removing this 'feature'
>>>>
>>>>> A manual set of the provider type requires a new configuration
>>>>> field for
>>>>> a domain and the
>>>>> question is the upgrade path which may look like
>>>>>
>>>>> * set the provider type to default Active Directory (because its
>>>>> more
>>>>> likely to be the provider type)
>>>>> * things not working -  use the engine-manage-domains and choose
>>>>> the
>>>>> provider type.
>>>>> * optionally - keep the auto-detection (of the tool only!)  if
>>>>> user
>>>>> wants to use it.
>>>> I think we should require that the user specifies the provider
>>>> type
>>>> (from now on), and enable editing this field of course.
>>>>
>>>> Another upgrade proposal is to populate the provider type only
>>>> upon the
>>>> first time we need to use this domain (and it is not populated) by
>>>> using
>>>> the current 'auto-detect' mechanism.
>>> and remove it the next version?
>> yes
>>
>>> this means the auto-detection code remains in the backend code.
>> only until next version
>>
>>> I think its the best to remove it totally but If we want to keep
>>> this
>>> functionality I rather just leave it in manage-domains
>>> alone,although if
>>> its another step for the user.
>> I don't *want* to keep it but unless we want to set it hard coded
>> during
>> upgrade I don't see how can we remove it.
>>
>> BTW if we have to leave it in I would say to remove it from the tool
>> and
>> leave in the backend (you have to have it in the backend for
>> transparent
>> upgrade)
>>
>>
>>>> By taking the above approach we don't break behavior for the user
>>>> and we
>>>> enable manually fixing of the domain provider type (which is a
>>>> bypass
>>>> for all current bugs in the auto-detect).
>>>>
>>>>
>>>> Livnat
>>>>
>>>>
>>>>> your suggestion and thoughts...
>>>>>
>>>>> Thanks,
>>>>> Roy
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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 Dustin.Schoenbrun at netapp.com  Mon Apr  9 14:48:00 2012
From: Dustin.Schoenbrun at netapp.com (Schoenbrun, Dustin)
Date: Mon, 9 Apr 2012 14:48:00 +0000
Subject: [Engine-devel] Unable to Run 'make install-tools'
Message-ID: <0A1534657992624AACDCA570F1D3E2000D3CBA@SACEXCMBX03-PRD.hq.netapp.com>

Greetings,

I'm running into an issue at the "Deploying engine-config and engine-manage-domains" section of the "Building oVirt Engine" article on the wiki.  Building from the source using maven2 has completed successfully and I'm stuck on the series of commands listed below:

# cd $OVIRT_HOME
# make create_dirs
# make install_tools
# make install_config

My build fails on the 'make install-tools' command.  The output of the command is below:

[root at ovirt ovirt-engine]# make install_tools
*** Installing Common Tools
cp -f /root/ovirt-engine/rpmbuild/SOURCES/engine-tools-common-3.1.0-0001.jar /usr/share/java/
cp: cannot stat `/root/ovirt-engine/rpmbuild/SOURCES/engine-tools-common-3.1.0-0001.jar': No such file or directory
make: *** [install_tools] Error 1
[root at ovirt ovirt-engine]# pwd
/root/ovirt-engine
[root at ovirt ovirt-engine]# ls
backend    build-tools  deployment  frontend  Makefile   pom.xml
build_mvn  config       ear         LICENSE   packaging
[root at ovirt ovirt-engine]#

Any insight into how to proceed would be greatly appreciated.  Thanks!

--
Dustin Schoenbrun
Software Engineer
NetApp - Data Center Platforms
919-476-5919 (office)
dustin.schoenbrun at netapp.com

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

From oliel at redhat.com  Mon Apr  9 15:14:24 2012
From: oliel at redhat.com (Ori Liel)
Date: Mon, 09 Apr 2012 11:14:24 -0400 (EDT)
Subject: [Engine-devel] Floating Disks implementation in REST-API
In-Reply-To: <067bcf26-cb34-447a-a2ab-09b636059f8e@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <22dc9594-9420-4c67-b982-2ecd9a0c2403@zmail17.collab.prod.int.phx2.redhat.com>

The "Floating Disks" feature makes disks into stand-alone entities: a given disk may be attached to a VM (as all disks are today), or it may be not attached to any VM, which makes it a floating disk (http://www.ovirt.org/wiki/Features/FloatingDisk)

To implement attach/detach of disk to/from VM in REST-API, we intend to introduce two new actions: 

  POST .../api/vms/{vm:id}/disks/{disk:id}/attach
  POST .../api/vms/{vm:id}/disks/{disk:id}/detach

Since we try not to add new actions unless we have to, I want to explain why I believe that these actions are necessary. 
The other implementation would use existing add/remove flows:

  POST   .../api/vms/{vm:id}/disks               - if the disk was passed with an ID, attach it to this VM. If no id - create a new disk.
  DELETE .../api/vms/{vm:id}/disks/{disk:id}     - *ambiguity problem, need to add a flag*

We can't break existing API, so regular DELETE must remove the disk, as it does today. To detach a disk using DELETE we'd have to add a flag to the DETELE command. This is quite risky, because if the user forgets to pass this flag, the disk which he wanted to detach will actually be deleted. 

Theoretically, if we could break the API, the following modelling would resolve the ambiguity and perhaps be ideal:
- POST/DELETE disk in root context means create or delete it. 
- POST/DELETE disk in VM context means attach or detach it.
But we don't have the privilege of breaking the API. 

Considering all of the above - and the fact that attach/detach nics to/from host is also implemented using actions - I believe that the new actions are justifiable.

Any comments? 

Thanks, 

Ori




From mkolesni at redhat.com  Tue Apr 10 07:20:03 2012
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Tue, 10 Apr 2012 03:20:03 -0400 (EDT)
Subject: [Engine-devel] Is there a preferred workflow when adding
	additional error messages to VDSM _and_ Engine?
In-Reply-To: <4F82D357.5070009@redhat.com>
Message-ID: <9e6427cb-5cd9-4d0c-a984-5fb9bcfdcae9@zmail14.collab.prod.int.phx2.redhat.com>


> On 07/04/12 18:10, Lee Yarwood wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Hello all,
> > 
> > I'm currently working on a patch to correct the logic used by vdsm
> > when
> > reviewing the logical and physical block size of physical volumes
> > [1].
> > Once/If this is approved I'd like to look into making the
> > exceptions
> > thrown from vdsm and the errors displayed within engine more
> > descriptive.
> > 
> > Before I start throwing patches into gerrit I was wondering *if*
> > there
> > is a preferred workflow when adding additional exceptions and error
> > messages across both projects. For example, committing changes to
> > vdsm
> > before engine, engine before vdsm or both at the same time.

Hi,

There is a wiki describing how to add errors & their descriptions to the engine:
http://www.ovirt.org/wiki/Engine_Adding_Messages

The relevant parts there are the VdsmErrors related (the other type of error is the one you get for illegal actions/states/etc before any call to VDSM is made).

Hope you find it helpful.

Regards,
Mike

> > 
> 
> Hi Lee,
> We had a Jenkins Job to give warning if there is a new error code in
> VDSM that is not covered in the backend.
> 
> I see this job is disabled in ovirt Jenkins,
> 
> http://jenkins.ovirt.org/job/vdsm_verify_error_codes/
> 
> Eyal, any specific reason this is disabled?
> 
> Livnat
> 
> 
> > I'm also wondering if there is a way to say that vdsm gerrit
> > changeid x
> > relies on engine gerrit changeid y etc?
> > 
> > Thanks in advance,
> > 
> > Lee
> > - --
> > 
> > Lee Yarwood
> > Software Maintenance Engineer
> > Red Hat UK Ltd
> > 200 Fowler Avenue IQ Farnborough, Farnborough, Hants GU14 7JP
> > 
> > Registered in England and Wales under Company Registration No.
> > 03798903
> > Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt
> > Parson(USA), Charlie Peters (USA)
> > 
> > GPG fingerprint : A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672
> > 2D76
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.12 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> > 
> > iQEcBAEBAgAGBQJPgFjGAAoJELymbjP2ci12MScIANRBXgWPSjeSZvSM2+bZmDrD
> > FefJfxMcCQFtTqWYePXIxFgqeeRcFc57+6alExBRU2g9nKZJEIPn2vj640XSTGlt
> > n5T4ItED1IVydzuEXFOAvgaTmZfKzTQkxQWp8QgL6pC7cYgnp2nL7gkbkedx1JyI
> > gCgCGomrHeWP2++vUS8UjtCccZdTJiOiWqoH2sBCKgEVcmFMgvYREK6hTou4DHU4
> > DcpureWuLvM4HWUlyfl37eXQOmy66A7uHGp3xF5sykQZ9aozaiMFjSoCqQOEVqO6
> > jHRnsQB6FfF/xU+F/UQK5PKZOm7e+KvrMjhIDfR+/DX3t0rkrtc69gg2O6duy4o=
> > =vdud
> > -----END PGP SIGNATURE-----


From eglynn at redhat.com  Tue Apr 10 10:42:04 2012
From: eglynn at redhat.com (Eoghan Glynn)
Date: Tue, 10 Apr 2012 06:42:04 -0400 (EDT)
Subject: [Engine-devel] Floating Disks implementation in REST-API
In-Reply-To: <22dc9594-9420-4c67-b982-2ecd9a0c2403@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <87b17518-a58a-46a8-b73b-ec335cb59be0@zmail11.collab.prod.int.phx2.redhat.com>



> The "Floating Disks" feature makes disks into stand-alone entities: a
> given disk may be attached to a VM (as all disks are today), or it
> may be not attached to any VM, which makes it a floating disk
> (http://www.ovirt.org/wiki/Features/FloatingDisk)
> 
> To implement attach/detach of disk to/from VM in REST-API, we intend
> to introduce two new actions:
> 
>   POST .../api/vms/{vm:id}/disks/{disk:id}/attach
>   POST .../api/vms/{vm:id}/disks/{disk:id}/detach
> 
> Since we try not to add new actions unless we have to, I want to
> explain why I believe that these actions are necessary.
> The other implementation would use existing add/remove flows:
> 
>   POST   .../api/vms/{vm:id}/disks               - if the disk was
>   passed with an ID, attach it to this VM. If no id - create a new
>   disk.
>   DELETE .../api/vms/{vm:id}/disks/{disk:id}     - *ambiguity
>   problem, need to add a flag*
> 
> We can't break existing API, so regular DELETE must remove the disk,
> as it does today. To detach a disk using DELETE we'd have to add a
> flag to the DETELE command. This is quite risky, because if the user
> forgets to pass this flag, the disk which he wanted to detach will
> actually be deleted.
> 
> Theoretically, if we could break the API, the following modelling
> would resolve the ambiguity and perhaps be ideal:
> - POST/DELETE disk in root context means create or delete it.
> - POST/DELETE disk in VM context means attach or detach it.
> But we don't have the privilege of breaking the API.
> 
> Considering all of the above - and the fact that attach/detach nics
> to/from host is also implemented using actions - I believe that the
> new actions are justifiable.
> 
> Any comments?

Hi Ori,

I tend to agree that overloading the DELETE verb to either delete or detach
the disk is error-prone, and justifies the addition of new detach action 
in this case.

However, I'm wondering whether it would be better, if somewhat asymmetric,
to still avoid the attach action, e.g. instead use:

   POST /api/vms/{vm:id}/disks        
   <disk id="{disk:id}"/>                       => attach disk

   POST /api/vms/{vm:id}/disks/{disk:id}/detach => detach disk

The reasoning here would be that:

  POST /api/vms/{vm:id}/disks/{disk:id}/attach

would tend to break the sub-collection idiom in my mind (as the disk in question
is not yet part of the disks sub-collection of that VM, prior to the attachment
actually occuring).

Cheers,
Eoghan


From gjansen at redhat.com  Tue Apr 10 11:35:09 2012
From: gjansen at redhat.com (Geert Jansen)
Date: Tue, 10 Apr 2012 13:35:09 +0200
Subject: [Engine-devel] Floating Disks implementation in REST-API
In-Reply-To: <22dc9594-9420-4c67-b982-2ecd9a0c2403@zmail17.collab.prod.int.phx2.redhat.com>
References: <22dc9594-9420-4c67-b982-2ecd9a0c2403@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <4F841AED.7090407@redhat.com>



On 04/09/2012 05:14 PM, Ori Liel wrote:
> The "Floating Disks" feature makes disks into stand-alone entities: a given disk may be attached to a VM (as all disks are today), or it may be not attached to any VM, which makes it a floating disk (http://www.ovirt.org/wiki/Features/FloatingDisk)
>
> To implement attach/detach of disk to/from VM in REST-API, we intend to introduce two new actions:
>
>    POST .../api/vms/{vm:id}/disks/{disk:id}/attach
>    POST .../api/vms/{vm:id}/disks/{disk:id}/detach
>
> Since we try not to add new actions unless we have to, I want to explain why I believe that these actions are necessary.
> The other implementation would use existing add/remove flows:
>
>    POST   .../api/vms/{vm:id}/disks               - if the disk was passed with an ID, attach it to this VM. If no id - create a new disk.
>    DELETE .../api/vms/{vm:id}/disks/{disk:id}     - *ambiguity problem, need to add a flag*
>
> We can't break existing API, so regular DELETE must remove the disk, as it does today. To detach a disk using DELETE we'd have to add a flag to the DETELE command. This is quite risky, because if the user forgets to pass this flag, the disk which he wanted to detach will actually be deleted.
>
> Theoretically, if we could break the API, the following modelling would resolve the ambiguity and perhaps be ideal:
> - POST/DELETE disk in root context means create or delete it.
> - POST/DELETE disk in VM context means attach or detach it.
> But we don't have the privilege of breaking the API.
>
> Considering all of the above - and the fact that attach/detach nics to/from host is also implemented using actions - I believe that the new actions are justifiable.
>
> Any comments?

I assume that a floating disk can be attached to 0 VMs as well, right? 
So i would assume we get a top-level /disks collection correct?? And I 
assume that collection would only list floating disks?

In my view, backwards compatible DELETE semantics for a floating disk 
aren't that bad:

  DELETE /vms/{vm:id}/disks/{disk:id}

=> Accept a <detach>true|false</detach> argument.
=> Defaults to "false" for compatibility.

This means that DELETE will by default really DELETE any non-floating 
disk. That is compatibility with today. For safety, implement this:

=> When deleting a disk that is floating, fail unless <force> is also 
set to "true". And always fail if one of the other VMs is running 
(obviously).

To attach a disk and make it float, use POST and you and Eoghan described.

To detach a disk, use DELETE with <detach>true</detach>.

To delete a non-attached, floating disks, use:

  DELETE /disks/{disk:id}

To delete an attached, floating disk, use:

  DELETE /vm/{vm:id}/disks/{disk:id} with <force>true</force>; OR
  DELETE /disks/{disk:id}

To create a non-attached, floating, disk, use:

  POST /disks

Regards,
Geert


From jhernand at redhat.com  Tue Apr 10 11:54:51 2012
From: jhernand at redhat.com (Juan Hernandez)
Date: Tue, 10 Apr 2012 13:54:51 +0200
Subject: [Engine-devel] Issue with XML namespaces in engine-setup
Message-ID: <4F841F8B.8090008@redhat.com>

Hello,

The code that we use in engine-setup to modify JBoss AS XML
configuration files uses the following pattern:

datasourceStr = '''
    <datasource ...>
       ...
    </datasource>
'''

xmlObj.addNodes("//datasource:subsystem/datasource:datasources",
datasourceStr)

This looks correct but is in fact generating a incorrect XML document,
as the tags being added are not associated to a namespace. The resulting
XML file will be correct, but the temporary representation in memory is
not. This causes problems if you later, before writing out the modified
file, try to use xpath expressions matching the added nodes: there will
be no match.

I would suggest that we change the pattern to something like this:

datasourceStr = '''
  <any_dummy_tag xmlns="urn:jboss:domain:datasources:1.0">
    <datasource ...>
       ...
    </datasource>
  </any_dummy_tag>
'''
datasourceNodes = libxml2.parseDoc(datasourceStr).getRootElement().children

xmlObje.addNodes("//datasource:subsystem/datasource:datasources",
datasourceNodes)

This way both the representation in memory and the resulting file are
correct.

Le me know what you think.

Regards,
Juan Hernandez
-- 
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  Tue Apr 10 12:30:15 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Tue, 10 Apr 2012 15:30:15 +0300
Subject: [Engine-devel] Floating Disks implementation in REST-API
In-Reply-To: <4F841AED.7090407@redhat.com>
References: <22dc9594-9420-4c67-b982-2ecd9a0c2403@zmail17.collab.prod.int.phx2.redhat.com>
	<4F841AED.7090407@redhat.com>
Message-ID: <4F8427D7.60707@redhat.com>

On 10/04/12 14:35, Geert Jansen wrote:
> 
> 
> On 04/09/2012 05:14 PM, Ori Liel wrote:
>> The "Floating Disks" feature makes disks into stand-alone entities: a
>> given disk may be attached to a VM (as all disks are today), or it may
>> be not attached to any VM, which makes it a floating disk
>> (http://www.ovirt.org/wiki/Features/FloatingDisk)
>>
>> To implement attach/detach of disk to/from VM in REST-API, we intend
>> to introduce two new actions:
>>
>>    POST .../api/vms/{vm:id}/disks/{disk:id}/attach
>>    POST .../api/vms/{vm:id}/disks/{disk:id}/detach
>>
>> Since we try not to add new actions unless we have to, I want to
>> explain why I believe that these actions are necessary.
>> The other implementation would use existing add/remove flows:
>>
>>    POST   .../api/vms/{vm:id}/disks               - if the disk was
>> passed with an ID, attach it to this VM. If no id - create a new disk.
>>    DELETE .../api/vms/{vm:id}/disks/{disk:id}     - *ambiguity
>> problem, need to add a flag*
>>
>> We can't break existing API, so regular DELETE must remove the disk,
>> as it does today. To detach a disk using DELETE we'd have to add a
>> flag to the DETELE command. This is quite risky, because if the user
>> forgets to pass this flag, the disk which he wanted to detach will
>> actually be deleted.
>>
>> Theoretically, if we could break the API, the following modelling
>> would resolve the ambiguity and perhaps be ideal:
>> - POST/DELETE disk in root context means create or delete it.
>> - POST/DELETE disk in VM context means attach or detach it.
>> But we don't have the privilege of breaking the API.
>>
>> Considering all of the above - and the fact that attach/detach nics
>> to/from host is also implemented using actions - I believe that the
>> new actions are justifiable.
>>
>> Any comments?
> 
> I assume that a floating disk can be attached to 0 VMs as well, right?

floating == attached to 0 VMs

> So i would assume we get a top-level /disks collection correct?? 

Yes

> And I assume that collection would only list floating disks?

IMO the /disks collection includes all disks in the setup regardless if
they are floating or attached to VM/s

> 
> In my view, backwards compatible DELETE semantics for a floating disk
> aren't that bad:
> 
>  DELETE /vms/{vm:id}/disks/{disk:id}
> 
> => Accept a <detach>true|false</detach> argument.
> => Defaults to "false" for compatibility.
> 

I think that ideally :

Detach a disk from VM (becomes floating):
DELETE api/vms/{vm:id}/disks/{disk:id}

Delete a disk ('real' delete)"
DELETE api/disks/{disk:id}

I understand that it is changing the current API behavior, it means that
a user who deleted disks in 3.0 will end up only detaching them in 3.1,
is that something we can't 'live' with?

For attach, I would go with Eoghan approach:

POST /api/vms/{vm:id}/disks
   <disk id="{disk:id}"/>                       => attach disk



> This means that DELETE will by default really DELETE any non-floating
> disk. That is compatibility with today. For safety, implement this:
> 
> => When deleting a disk that is floating, fail unless <force> is also
> set to "true". And always fail if one of the other VMs is running
> (obviously).
> 
> To attach a disk and make it float, use POST and you and Eoghan described.
> 
> To detach a disk, use DELETE with <detach>true</detach>.
> 
> To delete a non-attached, floating disks, use:
> 
>  DELETE /disks/{disk:id}
> 
> To delete an attached, floating disk, use:
> 
>  DELETE /vm/{vm:id}/disks/{disk:id} with <force>true</force>; OR

^^ isn't that considered breaking the API? we require force flag for
deleting disk which we did not require before.

>  DELETE /disks/{disk:id}
> 
> To create a non-attached, floating, disk, use:
> 
>  POST /disks
> 
> Regards,
> Geert
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From eglynn at redhat.com  Tue Apr 10 12:44:09 2012
From: eglynn at redhat.com (Eoghan Glynn)
Date: Tue, 10 Apr 2012 08:44:09 -0400 (EDT)
Subject: [Engine-devel] Floating Disks implementation in REST-API
In-Reply-To: <4F841AED.7090407@redhat.com>
Message-ID: <986c9ea0-d27d-4ed0-9f53-3894500575f2@zmail11.collab.prod.int.phx2.redhat.com>


> In my view, backwards compatible DELETE semantics for a floating disk
> aren't that bad:
> 
>   DELETE /vms/{vm:id}/disks/{disk:id}
> 
> => Accept a <detach>true|false</detach> argument.
> => Defaults to "false" for compatibility.
> 
> This means that DELETE will by default really DELETE any non-floating
> disk. That is compatibility with today. For safety, implement this:
> 
> => When deleting a disk that is floating, fail unless <force> is also
> set to "true". And always fail if one of the other VMs is running
> (obviously).
> 
> To attach a disk and make it float, use POST and you and Eoghan
> described.
> 
> To detach a disk, use DELETE with <detach>true</detach>.
> 
> To delete a non-attached, floating disks, use:
> 
>   DELETE /disks/{disk:id}
> 
> To delete an attached, floating disk, use:
> 
>   DELETE /vm/{vm:id}/disks/{disk:id} with <force>true</force>; OR
>   DELETE /disks/{disk:id}


While keeping to the DELETE pattern for detach is attractive, the use
of two separate flags (detach and force), plus the requirement to
special-case deletion logic in the floating disk case, seems to outweigh
the benefit.

This scenario would seem to fit in with the critera we applied when
choosing actions over standard verbs in the first place - i.e. a case
where a standard verb leads to awkward, counter-intuitive or unnatural
usage. In this case, the client-side logic to select the force flag
and the error handling for an inadvertent DELETE-delete when a
DELETE-detach was intended (409 status, I guess?), would seem to me to
justify going the action route.

Just my 2 cents ...

Cheers,
Eoghan


From oschreib at redhat.com  Tue Apr 10 13:48:02 2012
From: oschreib at redhat.com (Ofer Schreiber)
Date: Tue, 10 Apr 2012 09:48:02 -0400 (EDT)
Subject: [Engine-devel] Unable to Run 'make install-tools'
In-Reply-To: <0A1534657992624AACDCA570F1D3E2000D3CBA@SACEXCMBX03-PRD.hq.netapp.com>
Message-ID: <0874149a-e5d2-4d53-af37-f7c676e675e5@zmail14.collab.prod.int.phx2.redhat.com>

As the Makefile isn't used very often, it need some changes. 
it seems that you need to run 'make pre_copy' before the `make install-x' 

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

> Greetings,

> I?m running into an issue at the ?Deploying engine-config and
> engine-manage-domains? section of the ?Building oVirt Engine?
> article on the wiki. Building from the source using maven2 has
> completed successfully and I?m stuck on the series of commands
> listed below:

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

> My build fails on the ?make install-tools? command. The output of the
> command is below:

> [root at ovirt ovirt-engine]# make install_tools
> *** Installing Common Tools
> cp -f
> /root/ovirt-engine/rpmbuild/SOURCES/engine-tools-common-3.1.0-0001.jar
> /usr/share/java/
> cp: cannot stat
> `/root/ovirt-engine/rpmbuild/SOURCES/engine-tools-common-3.1.0-0001.jar':
> No such file or directory
> make: *** [install_tools] Error 1
> [root at ovirt ovirt-engine]# pwd
> /root/ovirt-engine
> [root at ovirt ovirt-engine]# ls
> backend build-tools deployment frontend Makefile pom.xml
> build_mvn config ear LICENSE packaging
> [root at ovirt ovirt-engine]#

> Any insight into how to proceed would be greatly appreciated. Thanks!

> --
> Dustin Schoenbrun
> Software Engineer
> NetApp ? Data Center Platforms
> 919-476-5919 (office)
> dustin.schoenbrun at netapp.com

> _______________________________________________
> 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/20120410/f5e771db/attachment.html>

From ykaul at redhat.com  Tue Apr 10 14:14:27 2012
From: ykaul at redhat.com (Yaniv Kaul)
Date: Tue, 10 Apr 2012 17:14:27 +0300
Subject: [Engine-devel] VM Payload feature
In-Reply-To: <138723b0-43ed-4271-a4ef-1eaecf5807e4@zmail02.collab.prod.int.phx2.redhat.com>
References: <138723b0-43ed-4271-a4ef-1eaecf5807e4@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <4F844043.6060709@redhat.com>

On 01/18/2012 05:41 PM, Oved Ourfalli wrote:
> Hey all,
>
> Continuing the discussion about Aeolus instance data injection to a VM (http://lists.ovirt.org/pipermail/engine-devel/2012-January/000423.html) we propose a new VM Payload feature.
>
> The following wiki page contains a description page of the feature.
> http://www.ovirt.org/wiki/Features/VMPayload
>
> Please read and review.
> There are several approaches there, and we wish to head your opinions and thoughts about them.
>
> Once we agree on an approach, we will start designing.

If the approach has been agreed upon, where is the design Wiki?
Specifically, I'm missing GUI mock up and more importantly, API.
Y.

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



From oliel at redhat.com  Tue Apr 10 14:46:11 2012
From: oliel at redhat.com (Ori Liel)
Date: Tue, 10 Apr 2012 10:46:11 -0400 (EDT)
Subject: [Engine-devel] Floating Disks implementation in REST-API
In-Reply-To: <4F841AED.7090407@redhat.com>
Message-ID: <8c43bc6b-dbe6-4f4b-9b05-ccdd5c9fc0ec@zmail17.collab.prod.int.phx2.redhat.com>

>
>
>On 04/09/2012 05:14 PM, Ori Liel wrote:
>> The "Floating Disks" feature makes disks into stand-alone entities: a given disk may be attached to a VM (as all disks are today), or it may be not attached to any VM, which makes it a floating disk (http://www.ovirt.org/wiki/Features/FloatingDisk)
>>
>> To implement attach/detach of disk to/from VM in REST-API, we intend to introduce two new actions:
>>
>>    POST .../api/vms/{vm:id}/disks/{disk:id}/attach
>>    POST .../api/vms/{vm:id}/disks/{disk:id}/detach
>>
>> Since we try not to add new actions unless we have to, I want to explain why I believe that these actions are necessary.
>> The other implementation would use existing add/remove flows:
>>
>>    POST   .../api/vms/{vm:id}/disks               - if the disk was passed with an ID, attach it to this VM. If no id - create a new disk.
>>    DELETE .../api/vms/{vm:id}/disks/{disk:id}     - *ambiguity problem, need to add a flag*
>>
>> We can't break existing API, so regular DELETE must remove the disk, as it does today. To detach a disk using DELETE we'd have to add a flag to the DETELE command. This is quite risky, because if the user forgets to pass this flag, the disk which he wanted to detach will actually be deleted.
>>
>> Theoretically, if we could break the API, the following modelling would resolve the ambiguity and perhaps be ideal:
>> - POST/DELETE disk in root context means create or delete it.
>> - POST/DELETE disk in VM context means attach or detach it.
>> But we don't have the privilege of breaking the API.
>>
>> Considering all of the above - and the fact that attach/detach nics to/from host is also implemented using actions - I believe that the new actions are justifiable.
>>
>> Any comments?
>
>I assume that a floating disk can be attached to 0 VMs as well, right?
>So i would assume we get a top-level /disks collection correct?? And I
>assume that collection would only list floating disks?

Indeed, there will be a root collection. but I do not see a reason why this collection should only show floating disks. I tend to think it should show all disks in the system. Keep in mind that we're going towards Shared disks, meaning the same disk may be used by two VMs, so it makes sense to show such a disk in the root collection, along with the information of which VMs it's attached to. 

>
>In my view, backwards compatible DELETE semantics for a floating disk
>aren't that bad:
>
>  DELETE /vms/{vm:id}/disks/{disk:id}
>
>=> Accept a <detach>true|false</detach> argument.
>=> Defaults to "false" for compatibility.
>
>This means that DELETE will by default really DELETE any non-floating
>disk. That is compatibility with today. For safety, implement this:
>
>=> When deleting a disk that is floating, fail unless <force> is also
>set to "true". And always fail if one of the other VMs is running
>(obviously).
>

I Agree with Eoghan that the drawbacks outweigh the benefits in this case, 
for the reasons Eoghan said. 

>To attach a disk and make it float, use POST and you and Eoghan described.
>
>To detach a disk, use DELETE with <detach>true</detach>.
>
>To delete a non-attached, floating disks, use:
>
>  DELETE /disks/{disk:id}
>
>To delete an attached, floating disk, use:
>
>  DELETE /vm/{vm:id}/disks/{disk:id} with <force>true</force>; OR
>  DELETE /disks/{disk:id}
>
>To create a non-attached, floating, disk, use:
>
>  POST /disks

Worth mentioning that creation of disk that is attached to a VM is still possible by POST to /vms/{vm:id}/disks/ without supplying disk-Id. 

>
>Regards,
>Geert

Ori


From Dustin.Schoenbrun at netapp.com  Tue Apr 10 17:21:26 2012
From: Dustin.Schoenbrun at netapp.com (Schoenbrun, Dustin)
Date: Tue, 10 Apr 2012 17:21:26 +0000
Subject: [Engine-devel] Unable to Run 'make install-tools'
In-Reply-To: <0874149a-e5d2-4d53-af37-f7c676e675e5@zmail14.collab.prod.int.phx2.redhat.com>
References: <0A1534657992624AACDCA570F1D3E2000D3CBA@SACEXCMBX03-PRD.hq.netapp.com>
	<0874149a-e5d2-4d53-af37-f7c676e675e5@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <0A1534657992624AACDCA570F1D3E2000D7DE8@SACEXCMBX03-PRD.hq.netapp.com>

Hey Ofer,

The ?make pre_copy? didn?t work either, but adding the line ?mkdir ?p $(SOURCE_DIR)? after the ?echo $(SOURCE_DIR)? in the Makefile made it work!  Is there a way that I can contribute this back to the community?  Or, since the Makefile isn?t used often, is there something I should be using in its stead?  Thanks, Ofer!

-- Dustin

From: Ofer Schreiber [mailto:oschreib at redhat.com]
Sent: Tuesday, April 10, 2012 9:48 AM
To: Schoenbrun, Dustin
Cc: engine-devel at ovirt.org
Subject: Re: [Engine-devel] Unable to Run 'make install-tools'

As the Makefile isn't used very often, it need some changes.
it seems that you need to run 'make pre_copy' before the `make install-x'


________________________________
Greetings,

I?m running into an issue at the ?Deploying engine-config and engine-manage-domains? section of the ?Building oVirt Engine? article on the wiki.  Building from the source using maven2 has completed successfully and I?m stuck on the series of commands listed below:

# cd $OVIRT_HOME
# make create_dirs
# make install_tools
# make install_config

My build fails on the ?make install-tools? command.  The output of the command is below:

[root at ovirt ovirt-engine]# make install_tools
*** Installing Common Tools
cp -f /root/ovirt-engine/rpmbuild/SOURCES/engine-tools-common-3.1.0-0001.jar /usr/share/java/
cp: cannot stat `/root/ovirt-engine/rpmbuild/SOURCES/engine-tools-common-3.1.0-0001.jar': No such file or directory
make: *** [install_tools] Error 1
[root at ovirt ovirt-engine]# pwd
/root/ovirt-engine
[root at ovirt ovirt-engine]# ls
backend    build-tools  deployment  frontend  Makefile   pom.xml
build_mvn  config       ear         LICENSE   packaging
[root at ovirt ovirt-engine]#

Any insight into how to proceed would be greatly appreciated.  Thanks!

--
Dustin Schoenbrun
Software Engineer
NetApp ? Data Center Platforms
919-476-5919 (office)
dustin.schoenbrun at netapp.com<mailto:dustin.schoenbrun at netapp.com>


_______________________________________________
Engine-devel mailing list
Engine-devel at ovirt.org<mailto: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/20120410/350a983b/attachment.html>

From oschreib at redhat.com  Tue Apr 10 17:51:16 2012
From: oschreib at redhat.com (Ofer Schreiber)
Date: Tue, 10 Apr 2012 13:51:16 -0400 (EDT)
Subject: [Engine-devel] Unable to Run 'make install-tools'
In-Reply-To: <0A1534657992624AACDCA570F1D3E2000D7DE8@SACEXCMBX03-PRD.hq.netapp.com>
References: <0A1534657992624AACDCA570F1D3E2000D3CBA@SACEXCMBX03-PRD.hq.netapp.com>
	<0874149a-e5d2-4d53-af37-f7c676e675e5@zmail14.collab.prod.int.phx2.redhat.com>
	<0A1534657992624AACDCA570F1D3E2000D7DE8@SACEXCMBX03-PRD.hq.netapp.com>
Message-ID: <E471A5CD-D61E-47AB-9439-66D31D5BBFEA@redhat.com>

In order to send the patch, please follow instructions at http://www.ovirt.org/wiki/Working_with_oVirt_Gerrit and put me as a reviewer I'll be glad to review it. 

Since I don't know exactly what you're doing, its a bit hard for me to help you or tell you the right way to do it. 

Ofer

On 10 Apr 2012, at 20:21, "Schoenbrun, Dustin" <Dustin.Schoenbrun at netapp.com> wrote:

> Hey Ofer,
>  
> The ?make pre_copy? didn?t work either, but adding the line ?mkdir ?p $(SOURCE_DIR)? after the ?echo $(SOURCE_DIR)? in the Makefile made it work!  Is there a way that I can contribute this back to the community?   Or, since the Makefile isn?t used often, is there something I should be using in its stead?  Thanks, Ofer!
>  
> -- Dustin
>  
> From: Ofer Schreiber [mailto:oschreib at redhat.com] 
> Sent: Tuesday, April 10, 2012 9:48 AM
> To: Schoenbrun, Dustin
> Cc: engine-devel at ovirt.org
> Subject: Re: [Engine-devel] Unable to Run 'make install-tools'
>  
> As the Makefile isn't used very often, it need some changes.
> it seems that you need to run 'make pre_copy' before the `make install-x'
>  
>  
> Greetings,
>  
> I?m running into an issue at the ?Deploying engine-config and engine-manage-domains? section of the ?Building oVirt Engine? article on the wiki.  Building from the source using maven2 has completed successfully and I?m stuck on the series of commands listed below:
>  
> # cd $OVIRT_HOME
> # make create_dirs
> # make install_tools
> # make install_config
>  
> My build fails on the ?make install-tools? command.  The output of the command is below:
>  
> [root at ovirt ovirt-engine]# make install_tools
> *** Installing Common Tools
> cp -f /root/ovirt-engine/rpmbuild/SOURCES/engine-tools-common-3.1.0-0001.jar /usr/share/java/
> cp: cannot stat `/root/ovirt-engine/rpmbuild/SOURCES/engine-tools-common-3.1.0-0001.jar': No such file or directory
> make: *** [install_tools] Error 1
> [root at ovirt ovirt-engine]# pwd
> /root/ovirt-engine
> [root at ovirt ovirt-engine]# ls
> backend    build-tools  deployment  frontend  Makefile   pom.xml
> build_mvn  config       ear         LICENSE   packaging
> [root at ovirt ovirt-engine]#
>  
> Any insight into how to proceed would be greatly appreciated.  Thanks!
>  
> --
> Dustin Schoenbrun
> Software Engineer
> NetApp ? Data Center Platforms
> 919-476-5919 (office)
> dustin.schoenbrun at netapp.com
>  
> 
> _______________________________________________
> 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/20120410/5e381a63/attachment.html>

From Dustin.Schoenbrun at netapp.com  Tue Apr 10 17:57:51 2012
From: Dustin.Schoenbrun at netapp.com (Schoenbrun, Dustin)
Date: Tue, 10 Apr 2012 17:57:51 +0000
Subject: [Engine-devel] Unable to Run 'make install-tools'
In-Reply-To: <E471A5CD-D61E-47AB-9439-66D31D5BBFEA@redhat.com>
References: <0A1534657992624AACDCA570F1D3E2000D3CBA@SACEXCMBX03-PRD.hq.netapp.com>
	<0874149a-e5d2-4d53-af37-f7c676e675e5@zmail14.collab.prod.int.phx2.redhat.com>
	<0A1534657992624AACDCA570F1D3E2000D7DE8@SACEXCMBX03-PRD.hq.netapp.com>
	<E471A5CD-D61E-47AB-9439-66D31D5BBFEA@redhat.com>
Message-ID: <0A1534657992624AACDCA570F1D3E2000D7E96@SACEXCMBX03-PRD.hq.netapp.com>

Will do.  I?ll submit a patch here shortly.  Thanks for the help, Ofer!

-- Dustin

From: Ofer Schreiber [mailto:oschreib at redhat.com]
Sent: Tuesday, April 10, 2012 1:51 PM
To: Schoenbrun, Dustin
Cc: engine-devel at ovirt.org
Subject: Re: [Engine-devel] Unable to Run 'make install-tools'

In order to send the patch, please follow instructions at http://www.ovirt.org/wiki/Working_with_oVirt_Gerrit and put me as a reviewer I'll be glad to review it.

Since I don't know exactly what you're doing, its a bit hard for me to help you or tell you the right way to do it.

Ofer

On 10 Apr 2012, at 20:21, "Schoenbrun, Dustin" <Dustin.Schoenbrun at netapp.com<mailto:Dustin.Schoenbrun at netapp.com>> wrote:
Hey Ofer,

The ?make pre_copy? didn?t work either, but adding the line ?mkdir ?p $(SOURCE_DIR)? after the ?echo $(SOURCE_DIR)? in the Makefile made it work!  Is there a way that I can contribute this back to the community?  Or, since the Makefile isn?t used often, is there something I should be using in its stead?  Thanks, Ofer!

-- Dustin

From: Ofer Schreiber [mailto:oschreib at redhat.com]<mailto:[mailto:oschreib at redhat.com]>
Sent: Tuesday, April 10, 2012 9:48 AM
To: Schoenbrun, Dustin
Cc: engine-devel at ovirt.org<mailto:engine-devel at ovirt.org>
Subject: Re: [Engine-devel] Unable to Run 'make install-tools'

As the Makefile isn't used very often, it need some changes.
it seems that you need to run 'make pre_copy' before the `make install-x'


________________________________
Greetings,

I?m running into an issue at the ?Deploying engine-config and engine-manage-domains? section of the ?Building oVirt Engine? article on the wiki.  Building from the source using maven2 has completed successfully and I?m stuck on the series of commands listed below:

# cd $OVIRT_HOME
# make create_dirs
# make install_tools
# make install_config

My build fails on the ?make install-tools? command.  The output of the command is below:

[root at ovirt ovirt-engine]# make install_tools
*** Installing Common Tools
cp -f /root/ovirt-engine/rpmbuild/SOURCES/engine-tools-common-3.1.0-0001.jar /usr/share/java/
cp: cannot stat `/root/ovirt-engine/rpmbuild/SOURCES/engine-tools-common-3.1.0-0001.jar': No such file or directory
make: *** [install_tools] Error 1
[root at ovirt ovirt-engine]# pwd
/root/ovirt-engine
[root at ovirt ovirt-engine]# ls
backend    build-tools  deployment  frontend  Makefile   pom.xml
build_mvn  config       ear         LICENSE   packaging
[root at ovirt ovirt-engine]#

Any insight into how to proceed would be greatly appreciated.  Thanks!

--
Dustin Schoenbrun
Software Engineer
NetApp ? Data Center Platforms
919-476-5919 (office)
dustin.schoenbrun at netapp.com<mailto:dustin.schoenbrun at netapp.com>


_______________________________________________
Engine-devel mailing list
Engine-devel at ovirt.org<mailto: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/20120410/9ef0f581/attachment.html>

From ecohen at redhat.com  Tue Apr 10 19:27:15 2012
From: ecohen at redhat.com (Einav Cohen)
Date: Tue, 10 Apr 2012 15:27:15 -0400 (EDT)
Subject: [Engine-devel] "add permission to user" dialog - nothing shown by
	default
In-Reply-To: <e58f1eab-d047-422c-a9a7-2202ae03c2a8@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <79288bbf-eda3-491d-84c7-9d42cb04d2b3@zmail04.collab.prod.int.phx2.redhat.com>

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

When opening the "add permission to user" dialog, no user is shown in the grid by default; user has to enter something in the search text-box within the dialog (or leave it empty) and hit "Go"; only then the list of users is being filled (according to the search text-box contents).

This behavior is by design.

Do you think that this behavior should change? i.e. do you think that the users grid should be filled right after opening the dialog with a list of all users? 
Please consider the following:

- calling to the search query and rendering its results may take a while, so user may open the dialog, but will be able to do something only after waiting a while (when originally, all he intended to do was to search a very particular user, which would have taken a short time).

- we may have several domains, so grid will be filled with results of the first domain selected (which might not be the domain that the user intended to search originally), so this may be annoying.

Due to the reasons above, my personal take is that the current behavior is OK and shouldn't be changed (i.e. BZ should be closed).

Any comments?



From acathrow at redhat.com  Wed Apr 11 02:04:20 2012
From: acathrow at redhat.com (Andrew Cathrow)
Date: Tue, 10 Apr 2012 22:04:20 -0400 (EDT)
Subject: [Engine-devel] "add permission to user" dialog - nothing shown
	by default
In-Reply-To: <79288bbf-eda3-491d-84c7-9d42cb04d2b3@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <abbcc846-656c-4053-a980-fb37dad5f3a1@zmail07.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Einav Cohen" <ecohen at redhat.com>
> To: "Miki Kenneth" <mkenneth at redhat.com>, "Andrew Cathrow" <acathrow at redhat.com>, "Simon Grinberg"
> <sgrinber at redhat.com>
> Cc: "Avihai Shoham" <ashoham at redhat.com>, engine-devel at ovirt.org
> Sent: Tuesday, April 10, 2012 3:27:15 PM
> Subject: "add permission to user" dialog - nothing shown by default
> 
> [https://bugzilla.redhat.com/show_bug.cgi?id=810287]
> 
> When opening the "add permission to user" dialog, no user is shown in
> the grid by default; user has to enter something in the search
> text-box within the dialog (or leave it empty) and hit "Go"; only
> then the list of users is being filled (according to the search
> text-box contents).
> 
> This behavior is by design.
> 
> Do you think that this behavior should change? i.e. do you think that
> the users grid should be filled right after opening the dialog with
> a list of all users?
> Please consider the following:
> 
> - calling to the search query and rendering its results may take a
> while, so user may open the dialog, but will be able to do something
> only after waiting a while (when originally, all he intended to do
> was to search a very particular user, which would have taken a short
> time).
> 
> - we may have several domains, so grid will be filled with results of
> the first domain selected (which might not be the domain that the
> user intended to search originally), so this may be annoying.
> 
> Due to the reasons above, my personal take is that the current
> behavior is OK and shouldn't be changed (i.e. BZ should be closed).
> 
> Any comments?

Agree, I've commented and closed it.
> 
> 


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

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


Eyal Edri
oVirt Infra Team


From oschreib at redhat.com  Wed Apr 11 07:51:37 2012
From: oschreib at redhat.com (Ofer Schreiber)
Date: Wed, 11 Apr 2012 03:51:37 -0400 (EDT)
Subject: [Engine-devel] Issue with XML namespaces in engine-setup
In-Reply-To: <4F841F8B.8090008@redhat.com>
Message-ID: <1fb55ffa-288e-4dd0-863d-810f99481760@zmail14.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> Hello,
> 
> The code that we use in engine-setup to modify JBoss AS XML
> configuration files uses the following pattern:
> 
> datasourceStr = '''
>     <datasource ...>
>        ...
>     </datasource>
> '''
> 
> xmlObj.addNodes("//datasource:subsystem/datasource:datasources",
> datasourceStr)
> 
> This looks correct but is in fact generating a incorrect XML
> document,
> as the tags being added are not associated to a namespace. The
> resulting
> XML file will be correct, but the temporary representation in memory
> is
> not. This causes problems if you later, before writing out the
> modified
> file, try to use xpath expressions matching the added nodes: there
> will
> be no match.
> 
> I would suggest that we change the pattern to something like this:
> 
> datasourceStr = '''
>   <any_dummy_tag xmlns="urn:jboss:domain:datasources:1.0">
>     <datasource ...>
>        ...
>     </datasource>
>   </any_dummy_tag>
> '''
> datasourceNodes =
> libxml2.parseDoc(datasourceStr).getRootElement().children
> 
> xmlObje.addNodes("//datasource:subsystem/datasource:datasources",
> datasourceNodes)
> 
> This way both the representation in memory and the resulting file are
> correct.
> 
> Le me know what you think.

As long as it work, I have no problem with that, sounds the right thing to do.
btw- why would you want to use xpath on the "in memory" xml? (In your specific case I mean, not in general)

> 
> Regards,
> Juan Hernandez
> --
> 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  Wed Apr 11 07:57:29 2012
From: jhernand at redhat.com (Juan Hernandez)
Date: Wed, 11 Apr 2012 09:57:29 +0200
Subject: [Engine-devel] Issue with XML namespaces in engine-setup
In-Reply-To: <1fb55ffa-288e-4dd0-863d-810f99481760@zmail14.collab.prod.int.phx2.redhat.com>
References: <1fb55ffa-288e-4dd0-863d-810f99481760@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <4F853969.2050509@redhat.com>

On 04/11/2012 09:51 AM, Ofer Schreiber wrote:
> 
> 
> ----- Original Message -----
>> Hello,
>>
>> The code that we use in engine-setup to modify JBoss AS XML
>> configuration files uses the following pattern:
>>
>> datasourceStr = '''
>>     <datasource ...>
>>        ...
>>     </datasource>
>> '''
>>
>> xmlObj.addNodes("//datasource:subsystem/datasource:datasources",
>> datasourceStr)
>>
>> This looks correct but is in fact generating a incorrect XML
>> document,
>> as the tags being added are not associated to a namespace. The
>> resulting
>> XML file will be correct, but the temporary representation in memory
>> is
>> not. This causes problems if you later, before writing out the
>> modified
>> file, try to use xpath expressions matching the added nodes: there
>> will
>> be no match.
>>
>> I would suggest that we change the pattern to something like this:
>>
>> datasourceStr = '''
>>   <any_dummy_tag xmlns="urn:jboss:domain:datasources:1.0">
>>     <datasource ...>
>>        ...
>>     </datasource>
>>   </any_dummy_tag>
>> '''
>> datasourceNodes =
>> libxml2.parseDoc(datasourceStr).getRootElement().children
>>
>> xmlObje.addNodes("//datasource:subsystem/datasource:datasources",
>> datasourceNodes)
>>
>> This way both the representation in memory and the resulting file are
>> correct.
>>
>> Le me know what you think.
> 
> As long as it work, I have no problem with that, sounds the right thing to do.
> btw- why would you want to use xpath on the "in memory" xml? (In your specific case I mean, not in general)

The specific case is that in the Fedora 17 JBoss AS RPM the default
standaonle.xml file doesn't contain a <datasources> tag, so I wanted to
do something like this:

1. Check if the datasources tag is there, if not add it.
2. Add the new datasource tag, like we do now.

Step 2 fails: the xpath that we use in xmlObj.addNodes doesn't match the
datasources tag added in step 1 because the in memory XML is not using
the right namespace.

-- 
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 oliel at redhat.com  Wed Apr 11 08:32:51 2012
From: oliel at redhat.com (Ori Liel)
Date: Wed, 11 Apr 2012 04:32:51 -0400 (EDT)
Subject: [Engine-devel] Hot-plug of disks and nics
In-Reply-To: <33beba9e-adc4-4f8f-a685-3e2de398fc61@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <cbed3bf1-5bfe-475b-9b73-32956b852ee6@zmail17.collab.prod.int.phx2.redhat.com>

On the subject of activate/deactivate disks and nics ("hot-plug"), I'd like to hear opinions about the correct modelling. I see two possible options (I will use disks as an example, but the chosen modelling should be the same for nics and disks). 

Option 1 - update: 
=================
PUT
.../api/vms/{vm:id}/disks/{disk:id}
<disk>
  <activated>true</activated>
</disk>

Pros: 
-----
* RESTful, no need for new action

Cons: 
-----
* Inconsistent with other flows. We do not normally update status fields to perform actions. For example to run a VM, we do not update it's status to 'activated', we run an action (start). 
* Enables user to update disk properties AND activate/deactivate in the same operation. Updating certain disk properties is forbidden while the VM is up, but activating/deactivating the disk is allowed always. This requires business-logic in REST-API: if the user activates the disk and changes properties on it - REST-API must first change the properties and then activate the disk (if disk is activated first, update properties will fail). If, on the other hand, the user *deactivates* the disk and changes properties on it - REST-API must first deactivate the disk and then change the properties (changing properties while disk is still active will fail). This bug-prone logic is only necessary because when activate/deactivate is merged with update. 



Option 2 - action 
=================

.../api/vms/{vm:id}/disks/{disk:id}/attach

Pros:
----
* Less RESTful

Cons:
-----
* Consistent with other flows
* Does not have the drawback of the additional business-logic described above


Opinions? 

Thanks, 

Ori. 


From oliel at redhat.com  Wed Apr 11 08:34:32 2012
From: oliel at redhat.com (Ori Liel)
Date: Wed, 11 Apr 2012 04:34:32 -0400 (EDT)
Subject: [Engine-devel] Hot-plug of disks and nics
In-Reply-To: <cbed3bf1-5bfe-475b-9b73-32956b852ee6@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <b5ce7079-312b-4628-9255-c30f96a297a9@zmail17.collab.prod.int.phx2.redhat.com>

>
>
>----- Original Message -----
>From: "Ori Liel" <oliel at redhat.com>
>To: engine-devel at ovirt.org
>Cc: meyering at redhat.com, eglynn at redhat.com, gjansen at redhat.com, jhernand at redhat.com, "Einav Cohen" <ecohen at redhat.com>, "Roy Golan" <rgolan at redhat.com>, "Michael Kublin" <mkublin at redhat.com>
>Sent: Wednesday, April 11, 2012 11:32:51 AM
>Subject: Hot-plug of disks and nics
>
>On the subject of activate/deactivate disks and nics ("hot-plug"), I'd like to hear opinions about the correct modelling. I see two possible options (I will use disks as an example, but the chosen modelling should be the same for nics and disks). 
>
>Option 1 - update: 
>=================
>PUT
>.../api/vms/{vm:id}/disks/{disk:id}
><disk>
>  <activated>true</activated>
></disk>
>
>Pros: 
>-----
>* RESTful, no need for new action
>
>Cons: 
>-----
>* Inconsistent with other flows. We do not normally update status fields to perform actions. For example to run a VM, we do not update it's status to 'activated', we run an action (start). 
>* Enables user to update disk properties AND activate/deactivate in the same operation. Updating certain disk properties is forbidden while the VM is up, but activating/deactivating the disk is allowed always. This requires business-logic in REST-API: if the user activates the disk and changes properties on it - REST-API must first change the properties and then activate the disk (if disk is activated first, update properties will fail). If, on the other hand, the user *deactivates* the disk and changes properties on it - REST-API must first deactivate the disk and then change the properties (changing properties while disk is still active will fail). This bug-prone logic is only necessary because when activate/deactivate is merged with update. 
>
>
>
>Option 2 - action 
>=================
>
>.../api/vms/{vm:id}/disks/{disk:id}/attach

Minor correction, I meant .../api/vms/{vm:id}/disks/{disk:id}/activate 
(not .../attach)

>
>Pros:
>----
>* Less RESTful
>
>Cons:
>-----
>* Consistent with other flows
>* Does not have the drawback of the additional business-logic described above
>
>
>Opinions? 
>
>Thanks, 
>
>Ori. 


From abaron at redhat.com  Wed Apr 11 08:50:58 2012
From: abaron at redhat.com (Ayal Baron)
Date: Wed, 11 Apr 2012 04:50:58 -0400 (EDT)
Subject: [Engine-devel] Floating Disks implementation in REST-API
In-Reply-To: <4F8427D7.60707@redhat.com>
Message-ID: <03e10fcb-1fa7-4762-b5db-0eeb369f2de5@zmail13.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> On 10/04/12 14:35, Geert Jansen wrote:
> > 
> > 
> > On 04/09/2012 05:14 PM, Ori Liel wrote:
> >> The "Floating Disks" feature makes disks into stand-alone
> >> entities: a
> >> given disk may be attached to a VM (as all disks are today), or it
> >> may
> >> be not attached to any VM, which makes it a floating disk
> >> (http://www.ovirt.org/wiki/Features/FloatingDisk)
> >>
> >> To implement attach/detach of disk to/from VM in REST-API, we
> >> intend
> >> to introduce two new actions:
> >>
> >>    POST .../api/vms/{vm:id}/disks/{disk:id}/attach
> >>    POST .../api/vms/{vm:id}/disks/{disk:id}/detach
> >>
> >> Since we try not to add new actions unless we have to, I want to
> >> explain why I believe that these actions are necessary.
> >> The other implementation would use existing add/remove flows:
> >>
> >>    POST   .../api/vms/{vm:id}/disks               - if the disk
> >>    was
> >> passed with an ID, attach it to this VM. If no id - create a new
> >> disk.
> >>    DELETE .../api/vms/{vm:id}/disks/{disk:id}     - *ambiguity
> >> problem, need to add a flag*
> >>
> >> We can't break existing API, so regular DELETE must remove the
> >> disk,
> >> as it does today. To detach a disk using DELETE we'd have to add a
> >> flag to the DETELE command. This is quite risky, because if the
> >> user
> >> forgets to pass this flag, the disk which he wanted to detach will
> >> actually be deleted.
> >>
> >> Theoretically, if we could break the API, the following modelling
> >> would resolve the ambiguity and perhaps be ideal:
> >> - POST/DELETE disk in root context means create or delete it.
> >> - POST/DELETE disk in VM context means attach or detach it.
> >> But we don't have the privilege of breaking the API.
> >>
> >> Considering all of the above - and the fact that attach/detach
> >> nics
> >> to/from host is also implemented using actions - I believe that
> >> the
> >> new actions are justifiable.
> >>
> >> Any comments?
> > 
> > I assume that a floating disk can be attached to 0 VMs as well,
> > right?
> 
> floating == attached to 0 VMs
> 
> > So i would assume we get a top-level /disks collection correct??
> 
> Yes
> 
> > And I assume that collection would only list floating disks?
> 
> IMO the /disks collection includes all disks in the setup regardless
> if
> they are floating or attached to VM/s
> 
> > 
> > In my view, backwards compatible DELETE semantics for a floating
> > disk
> > aren't that bad:
> > 
> >  DELETE /vms/{vm:id}/disks/{disk:id}
> > 
> > => Accept a <detach>true|false</detach> argument.
> > => Defaults to "false" for compatibility.
> > 
> 
> I think that ideally :
> 
> Detach a disk from VM (becomes floating):
> DELETE api/vms/{vm:id}/disks/{disk:id}
> 
> Delete a disk ('real' delete)"
> DELETE api/disks/{disk:id}

Assuming this also works when the disk is attached to a VM then the above seems to me like the simplest and clearest path. i.e.
DELETE in VM context detaches
DELETE in DISKS context really deletes

POST in VM context attaches (and creates if does not yet exist)
POST in DISKS context creates floating.

Only thing is that to create and attach you post to VM but the complementary detach and delete is delete from disks (i.e. not symmetrical).

> 
> I understand that it is changing the current API behavior, it means
> that
> a user who deleted disks in 3.0 will end up only detaching them in
> 3.1,
> is that something we can't 'live' with?
> 
> For attach, I would go with Eoghan approach:
> 
> POST /api/vms/{vm:id}/disks
>    <disk id="{disk:id}"/>                       => attach disk
> 
> 
> 
> > This means that DELETE will by default really DELETE any
> > non-floating
> > disk. That is compatibility with today. For safety, implement this:
> > 
> > => When deleting a disk that is floating, fail unless <force> is
> > also
> > set to "true". And always fail if one of the other VMs is running
> > (obviously).
> > 
> > To attach a disk and make it float, use POST and you and Eoghan
> > described.
> > 
> > To detach a disk, use DELETE with <detach>true</detach>.
> > 
> > To delete a non-attached, floating disks, use:
> > 
> >  DELETE /disks/{disk:id}
> > 
> > To delete an attached, floating disk, use:
> > 
> >  DELETE /vm/{vm:id}/disks/{disk:id} with <force>true</force>; OR
> 
> ^^ isn't that considered breaking the API? we require force flag for
> deleting disk which we did not require before.
> 
> >  DELETE /disks/{disk:id}
> > 
> > To create a non-attached, floating, disk, use:
> > 
> >  POST /disks
> > 
> > Regards,
> > Geert
> > _______________________________________________
> > 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 eglynn at redhat.com  Wed Apr 11 09:02:37 2012
From: eglynn at redhat.com (Eoghan Glynn)
Date: Wed, 11 Apr 2012 05:02:37 -0400 (EDT)
Subject: [Engine-devel] Hot-plug of disks and nics
In-Reply-To: <cbed3bf1-5bfe-475b-9b73-32956b852ee6@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <42673a31-5f7b-4842-b32a-77aed4113cf9@zmail11.collab.prod.int.phx2.redhat.com>



> * Inconsistent with other flows. We do not normally update status
> fields to perform actions. For example to run a VM, we do not update
> it's status to 'activated', we run an action (start).

I think this point is the crux of the matter.

IMO the consistency between activation implemented as direct state
manipulation versus the state change occurring as a side-effect
of an action, would be a deal-breaker.

IIRC one of the reasons we avoided that kind of direct state
manipulation first time round is that it doesn't lend itself to
multi-state transitions, e.g. activation that traversed multiple
intermediate states, say:

  quiescent->pending->activating->activated

That example is a bit contrived and unrealistic, but in any case
the principal is that the client-visible state machine for a resource
may not necessarily transition directly from the initial to the terminal
state.

Also an action as opposed to a direct state manipulation makes it more
natural to express side-effects of the activation, and to implement 
in-progress status querying or cancelation.

For those reasons, I'm thinking that using actions consistently accross
the board is better than exposing an action in one case while allowing
a direct state manipulation in another.

So my vote would be for option #2.

Cheers,
Eoghan



From oliel at redhat.com  Wed Apr 11 09:06:23 2012
From: oliel at redhat.com (Ori Liel)
Date: Wed, 11 Apr 2012 05:06:23 -0400 (EDT)
Subject: [Engine-devel] Floating Disks implementation in REST-API
In-Reply-To: <87b17518-a58a-46a8-b73b-ec335cb59be0@zmail11.collab.prod.int.phx2.redhat.com>
Message-ID: <80a657f3-dc74-4b3d-a1e5-43fc84e8590d@zmail17.collab.prod.int.phx2.redhat.com>

>
>
>----- Original Message -----
>From: "Eoghan Glynn" <eglynn at redhat.com>
>To: "Ori Liel" <oliel at redhat.com>
>Cc: meyering at redhat.com, jhernand at redhat.com, "Geert Jansen" <gjansen at redhat.com>, "Einav Cohen" <ecohen at redhat.com>, "Michael Pasternak" <mpastern at redhat.com>, "Michael Kublin" <mkublin at redhat.com>, engine-devel at ovirt.org
>Sent: Tuesday, April 10, 2012 1:42:04 PM
>Subject: Re: Floating Disks implementation in REST-API
>
>
>
>> The "Floating Disks" feature makes disks into stand-alone entities: a
>> given disk may be attached to a VM (as all disks are today), or it
>> may be not attached to any VM, which makes it a floating disk
>> (http://www.ovirt.org/wiki/Features/FloatingDisk)
>> 
>> To implement attach/detach of disk to/from VM in REST-API, we intend
>> to introduce two new actions:
>> 
>>   POST .../api/vms/{vm:id}/disks/{disk:id}/attach
>>   POST .../api/vms/{vm:id}/disks/{disk:id}/detach
>> 
>> Since we try not to add new actions unless we have to, I want to
>> explain why I believe that these actions are necessary.
>> The other implementation would use existing add/remove flows:
>> 
>>   POST   .../api/vms/{vm:id}/disks               - if the disk was
>>   passed with an ID, attach it to this VM. If no id - create a new
>>   disk.
>>   DELETE .../api/vms/{vm:id}/disks/{disk:id}     - *ambiguity
>>   problem, need to add a flag*
>> 
>> We can't break existing API, so regular DELETE must remove the disk,
>> as it does today. To detach a disk using DELETE we'd have to add a
>> flag to the DETELE command. This is quite risky, because if the user
>> forgets to pass this flag, the disk which he wanted to detach will
>> actually be deleted.
>> 
>> Theoretically, if we could break the API, the following modelling
>> would resolve the ambiguity and perhaps be ideal:
>> - POST/DELETE disk in root context means create or delete it.
>> - POST/DELETE disk in VM context means attach or detach it.
>> But we don't have the privilege of breaking the API.
>> 
>> Considering all of the above - and the fact that attach/detach nics
>> to/from host is also implemented using actions - I believe that the
>> new actions are justifiable.
>> 
>> Any comments?
>
>Hi Ori,
>
>I tend to agree that overloading the DELETE verb to either delete or detach
>the disk is error-prone, and justifies the addition of new detach action 
>in this case.
>
>However, I'm wondering whether it would be better, if somewhat asymmetric,
>to still avoid the attach action, e.g. instead use:
>
>   POST /api/vms/{vm:id}/disks        
>   <disk id="{disk:id}"/>                       => attach disk
>
>   POST /api/vms/{vm:id}/disks/{disk:id}/detach => detach disk
>
>The reasoning here would be that:
>
>  POST /api/vms/{vm:id}/disks/{disk:id}/attach
>
>would tend to break the sub-collection idiom in my mind (as the disk in question
>is not yet part of the disks sub-collection of that VM, prior to the attachment
>actually occuring).

Eoghan, I agree with you; this is actually a crushing argument against 'attach' 
action, which I overlooked. But I dislike the asymmetry of detaching using an action, 
and attaching using POST. So I'm now actually advocating:

      POST /api/vms/{vm:id}/disks        
      <disk id="{disk:id}"/>                       => attach disk

      DELETE .../api/vms/{vm:id}/disks/{disk:id}
      <disk><detach>true</detach><disk>            => detach disk

If you can agree to this then Geert, you and myself would be aligned (right Geert?), 
and I can go forward with implementation.

Thanks, 

Ori. 

>
>Cheers,
>Eoghan


From jhernand at redhat.com  Wed Apr 11 09:25:01 2012
From: jhernand at redhat.com (Juan Hernandez)
Date: Wed, 11 Apr 2012 11:25:01 +0200
Subject: [Engine-devel] Problem with detachment of host interface using
 ovirt-sdk
In-Reply-To: <4488206DC085244C886DBC9E7038B6892516DF3B@mtrdag02.mtl.com>
References: <4488206DC085244C886DBC9E7038B68918D382CE@MTRDAG01.mtl.com>,
	<4F6EC05A.9010209@redhat.com>
	<4488206DC085244C886DBC9E7038B6892516DF3B@mtrdag02.mtl.com>
Message-ID: <4F854DED.2050900@redhat.com>

Itzik, can you provide the complete python script that is generating
that fault? I will try to reproduce it in my environment.

It will be also helpful to know the exact version of ovirt-engine-sdk
that you are using. If you cloned the git repository just tell me what
is the commit.

On 04/02/2012 09:45 AM, Itzik Brown wrote:
> Hi,
> 
> I tried using ovirt-sdk against  ovirt-engine-3.0.0_0001-1.6.
> I still get the same result:
> 
> 10:29:26,554 WARN  [org.jboss.resteasy.core.SynchronousDispatcher] (http--0.0.0.0-8080-4) failed to execute: org.ovirt.engine.api.restapi.resource.BaseBackendResource$WebFaultException
>         at org.ovirt.engine.api.restapi.resource.BaseBackendResource.handleError(BaseBackendResource.java:207) [restapi-jaxrs-3.0.0-0001.jar:]
>         at org.ovirt.engine.api.restapi.resource.BaseBackendResource.handleError(BaseBackendResource.java:183) [restapi-jaxrs-3.0.0-0001.jar:]
>         at org.ovirt.engine.api.restapi.resource.BackendHostNicsResource.lookupNetwork(BackendHostNicsResource.java:242) [restapi-jaxrs-3.0.0-0001.jar:]
>         at org.ovirt.engine.api.restapi.resource.BackendHostNicResource.doAttachAction(BackendHostNicResource.java:56) [restapi-jaxrs-3.0.0-0001.jar:]
>         at org.ovirt.engine.api.restapi.resource.BackendHostNicResource.detach(BackendHostNicResource.java:75) [restapi-jaxrs-3.0.0-0001.jar:]
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_24]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.6.0_24]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.6.0_24]
>         at java.lang.reflect.Method.invoke(Method.java:616) [:1.6.0_24]
> 
> Please advise,
> Itzik
> 
> ________________________________
> From: engine-devel-bounces at ovirt.org [engine-devel-bounces at ovirt.org] on behalf of Roy Golan [rgolan at redhat.com]
> Sent: Sunday, March 25, 2012 8:51 AM
> To: engine-devel at ovirt.org
> Subject: Re: [Engine-devel] Problem with detachment of host interface using ovirt-sdk
> 
> On 03/22/2012 10:43 AM, Itzik Brown wrote:
> Hi,
> 
> I'm using ovirt-sdk to attach and detach a network to a host's Interface.
> Once the network is attached to the interface I try to detach the network from the interface using the following steps:
> 
> 1.Detach the network from the cluster through the GUI.
> 2.Remove the network from the datacenter through the GUI.
> 3.Detach the network from the host's interface using the SDK:
> 
> nic = api.hosts.get(name=host).nics.get(name=if_name)
> net = params.Network(name=net_name)
> act = params.Action(network=net)
> nic.detach(act)
> api.hosts.get(name=host).commitnetconfig()
> 
> Then I get the error:
> http://pastebin.com/3Md07huE
> 
> The same flow using the GUI works fine.
> 
> Network removal from the Datacenter is a trigger for me to run the detachment operation therefore I use this flow.
> 
> I use the following components:
> 
> rhevm-3.0.2_0001-2
> ovirt-sdk (Using the latest from git repository)
> 
> Please advise how to proceed.
> 
> Thanks,
> Itzik
> 
> 
> 
> This body part will be downloaded on demand.
> 
> Ovirt-sdk and rhevm don't comply (ovirt-sdk is based on the upstream version of rhevm)
> 
> Use the REST api instead:
> 
> curl -X POST user at domain:password -H "Content-Type: application/xml" -d@/path/to/file.xml https://rhevm:8843/api/hosts/{host-id}/nics/{nic-id}/detach
> 
> file.xml:
> 
> <action>
>   <host_nic>
>     <name>eth0</name>
>   </host_nic>
> </action>
> 
> 
> 
> _______________________________________________
> 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 oliel at redhat.com  Wed Apr 11 10:32:15 2012
From: oliel at redhat.com (Ori Liel)
Date: Wed, 11 Apr 2012 06:32:15 -0400 (EDT)
Subject: [Engine-devel] Hot-plug of disks and nics
In-Reply-To: <874nsqk2pc.fsf@rho.meyering.net>
Message-ID: <7fb68382-00d2-4a87-9066-334a21558e93@zmail17.collab.prod.int.phx2.redhat.com>

>
>
>----- Original Message -----
>From: "Jim Meyering" <meyering at redhat.com>
>To: "Ori Liel" <oliel at redhat.com>
>Cc: engine-devel at ovirt.org, eglynn at redhat.com, gjansen at redhat.com, jhernand at redhat.com, "Einav Cohen" <ecohen at redhat.com>, "Roy Golan" <rgolan at redhat.com>, "Michael Kublin" <mkublin at redhat.com>
>Sent: Wednesday, April 11, 2012 1:00:47 PM
>Subject: Re: Hot-plug of disks and nics
>
>Ori Liel wrote:
>> On the subject of activate/deactivate disks and nics ("hot-plug"), I'd
>> like to hear opinions about the correct modelling. I see two possible
>> options (I will use disks as an example, but the chosen modelling
>> should be the same for nics and disks).
>>
>> Option 1 - update:
>> =================
>> PUT
>> .../api/vms/{vm:id}/disks/{disk:id}
>> <disk>
>>   <activated>true</activated>
>> </disk>
>>
>> Pros:
>> -----
>> * RESTful, no need for new action
>>
>> Cons:
>> -----
>> * Inconsistent with other flows. We do not normally update status
>> fields to perform actions. For example to run a VM, we do not update
>> it's status to 'activated', we run an action (start).
>> * Enables user to update disk properties AND activate/deactivate in
>> the same operation. Updating certain disk properties is forbidden
>> while the VM is up, but activating/deactivating the disk is allowed
>> always. This requires business-logic in REST-API: if the user
>> activates the disk and changes properties on it - REST-API must first
>> change the properties and then activate the disk (if disk is activated
>> first, update properties will fail). If, on the other hand, the user
>> *deactivates* the disk and changes properties on it - REST-API must
>> first deactivate the disk and then change the properties (changing
>> properties while disk is still active will fail). This bug-prone logic
>> is only necessary because when activate/deactivate is merged with
>> update.
>>
>>
>>
>> Option 2 - action
>> =================
>>
>> .../api/vms/{vm:id}/disks/{disk:id}/[activate]
>>
>> [Con]:
>> ----
>> * Less RESTful
>>
>> [Pros]:
>> -----
>> * Consistent with other flows
>> * Does not have the drawback of the additional business-logic described above
>
>I too prefer #2.
>IMHO, we need not be slaves to consistency or RESTfulness, but here,
>consistency wins hands down when strict conformance to REST guidelines
>evokes a paragraph worth of "Cons".

#2 it is then. Thanks Jim, Eoghan


From lpeer at redhat.com  Wed Apr 11 10:33:01 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Wed, 11 Apr 2012 13:33:01 +0300
Subject: [Engine-devel] ovirt core sync agenda
Message-ID: <4F855DDD.7010903@redhat.com>

Hi All,
We have nothing on the agenda for today.
If you have something you would like to discuss please reply to this
mail otherwise we'll cancel today's meeting.

Thanks, Livnat


From meyering at redhat.com  Wed Apr 11 10:00:47 2012
From: meyering at redhat.com (Jim Meyering)
Date: Wed, 11 Apr 2012 12:00:47 +0200
Subject: [Engine-devel] Hot-plug of disks and nics
In-Reply-To: <cbed3bf1-5bfe-475b-9b73-32956b852ee6@zmail17.collab.prod.int.phx2.redhat.com>
	(Ori Liel's message of "Wed, 11 Apr 2012 04:32:51 -0400 (EDT)")
References: <cbed3bf1-5bfe-475b-9b73-32956b852ee6@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <874nsqk2pc.fsf@rho.meyering.net>

Ori Liel wrote:
> On the subject of activate/deactivate disks and nics ("hot-plug"), I'd
> like to hear opinions about the correct modelling. I see two possible
> options (I will use disks as an example, but the chosen modelling
> should be the same for nics and disks).
>
> Option 1 - update:
> =================
> PUT
> .../api/vms/{vm:id}/disks/{disk:id}
> <disk>
>   <activated>true</activated>
> </disk>
>
> Pros:
> -----
> * RESTful, no need for new action
>
> Cons:
> -----
> * Inconsistent with other flows. We do not normally update status
> fields to perform actions. For example to run a VM, we do not update
> it's status to 'activated', we run an action (start).
> * Enables user to update disk properties AND activate/deactivate in
> the same operation. Updating certain disk properties is forbidden
> while the VM is up, but activating/deactivating the disk is allowed
> always. This requires business-logic in REST-API: if the user
> activates the disk and changes properties on it - REST-API must first
> change the properties and then activate the disk (if disk is activated
> first, update properties will fail). If, on the other hand, the user
> *deactivates* the disk and changes properties on it - REST-API must
> first deactivate the disk and then change the properties (changing
> properties while disk is still active will fail). This bug-prone logic
> is only necessary because when activate/deactivate is merged with
> update.
>
>
>
> Option 2 - action
> =================
>
> .../api/vms/{vm:id}/disks/{disk:id}/[activate]
>
> [Con]:
> ----
> * Less RESTful
>
> [Pros]:
> -----
> * Consistent with other flows
> * Does not have the drawback of the additional business-logic described above

I too prefer #2.
IMHO, we need not be slaves to consistency or RESTfulness, but here,
consistency wins hands down when strict conformance to REST guidelines
evokes a paragraph worth of "Cons".


From iheim at redhat.com  Wed Apr 11 12:53:56 2012
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 11 Apr 2012 15:53:56 +0300
Subject: [Engine-devel] Floating Disks implementation in REST-API
In-Reply-To: <03e10fcb-1fa7-4762-b5db-0eeb369f2de5@zmail13.collab.prod.int.phx2.redhat.com>
References: <03e10fcb-1fa7-4762-b5db-0eeb369f2de5@zmail13.collab.prod.int.phx2.redhat.com>
Message-ID: <4F857EE4.2040400@redhat.com>

On 04/11/2012 11:50 AM, Ayal Baron wrote:
>
>
> ----- Original Message -----
>> On 10/04/12 14:35, Geert Jansen wrote:
>>>
>>>
>>> On 04/09/2012 05:14 PM, Ori Liel wrote:
>>>> The "Floating Disks" feature makes disks into stand-alone
>>>> entities: a
>>>> given disk may be attached to a VM (as all disks are today), or it
>>>> may
>>>> be not attached to any VM, which makes it a floating disk
>>>> (http://www.ovirt.org/wiki/Features/FloatingDisk)
>>>>
>>>> To implement attach/detach of disk to/from VM in REST-API, we
>>>> intend
>>>> to introduce two new actions:
>>>>
>>>>     POST .../api/vms/{vm:id}/disks/{disk:id}/attach
>>>>     POST .../api/vms/{vm:id}/disks/{disk:id}/detach
>>>>
>>>> Since we try not to add new actions unless we have to, I want to
>>>> explain why I believe that these actions are necessary.
>>>> The other implementation would use existing add/remove flows:
>>>>
>>>>     POST   .../api/vms/{vm:id}/disks               - if the disk
>>>>     was
>>>> passed with an ID, attach it to this VM. If no id - create a new
>>>> disk.
>>>>     DELETE .../api/vms/{vm:id}/disks/{disk:id}     - *ambiguity
>>>> problem, need to add a flag*
>>>>
>>>> We can't break existing API, so regular DELETE must remove the
>>>> disk,
>>>> as it does today. To detach a disk using DELETE we'd have to add a
>>>> flag to the DETELE command. This is quite risky, because if the
>>>> user
>>>> forgets to pass this flag, the disk which he wanted to detach will
>>>> actually be deleted.
>>>>
>>>> Theoretically, if we could break the API, the following modelling
>>>> would resolve the ambiguity and perhaps be ideal:
>>>> - POST/DELETE disk in root context means create or delete it.
>>>> - POST/DELETE disk in VM context means attach or detach it.
>>>> But we don't have the privilege of breaking the API.
>>>>
>>>> Considering all of the above - and the fact that attach/detach
>>>> nics
>>>> to/from host is also implemented using actions - I believe that
>>>> the
>>>> new actions are justifiable.
>>>>
>>>> Any comments?
>>>
>>> I assume that a floating disk can be attached to 0 VMs as well,
>>> right?
>>
>> floating == attached to 0 VMs
>>
>>> So i would assume we get a top-level /disks collection correct??
>>
>> Yes
>>
>>> And I assume that collection would only list floating disks?
>>
>> IMO the /disks collection includes all disks in the setup regardless
>> if
>> they are floating or attached to VM/s
>>
>>>
>>> In my view, backwards compatible DELETE semantics for a floating
>>> disk
>>> aren't that bad:
>>>
>>>   DELETE /vms/{vm:id}/disks/{disk:id}
>>>
>>> =>  Accept a<detach>true|false</detach>  argument.
>>> =>  Defaults to "false" for compatibility.
>>>
>>
>> I think that ideally :
>>
>> Detach a disk from VM (becomes floating):
>> DELETE api/vms/{vm:id}/disks/{disk:id}
>>
>> Delete a disk ('real' delete)"
>> DELETE api/disks/{disk:id}
>
> Assuming this also works when the disk is attached to a VM then the above seems to me like the simplest and clearest path. i.e.
> DELETE in VM context detaches

this would break backward compatibility of the API, as today this 
deletes the disk as well.
geert - thoughts on this?

> DELETE in DISKS context really deletes
>
> POST in VM context attaches (and creates if does not yet exist)
> POST in DISKS context creates floating.
>
> Only thing is that to create and attach you post to VM but the complementary detach and delete is delete from disks (i.e. not symmetrical).
>
>>
>> I understand that it is changing the current API behavior, it means
>> that
>> a user who deleted disks in 3.0 will end up only detaching them in
>> 3.1,
>> is that something we can't 'live' with?
>>
>> For attach, I would go with Eoghan approach:
>>
>> POST /api/vms/{vm:id}/disks
>>     <disk id="{disk:id}"/>                        =>  attach disk
>>
>>
>>
>>> This means that DELETE will by default really DELETE any
>>> non-floating
>>> disk. That is compatibility with today. For safety, implement this:
>>>
>>> =>  When deleting a disk that is floating, fail unless<force>  is
>>> also
>>> set to "true". And always fail if one of the other VMs is running
>>> (obviously).
>>>
>>> To attach a disk and make it float, use POST and you and Eoghan
>>> described.
>>>
>>> To detach a disk, use DELETE with<detach>true</detach>.
>>>
>>> To delete a non-attached, floating disks, use:
>>>
>>>   DELETE /disks/{disk:id}
>>>
>>> To delete an attached, floating disk, use:
>>>
>>>   DELETE /vm/{vm:id}/disks/{disk:id} with<force>true</force>; OR
>>
>> ^^ isn't that considered breaking the API? we require force flag for
>> deleting disk which we did not require before.
>>
>>>   DELETE /disks/{disk:id}
>>>
>>> To create a non-attached, floating, disk, use:
>>>
>>>   POST /disks
>>>
>>> Regards,
>>> Geert
>>> _______________________________________________
>>> 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 ryanh at us.ibm.com  Wed Apr 11 13:07:51 2012
From: ryanh at us.ibm.com (Ryan Harper)
Date: Wed, 11 Apr 2012 08:07:51 -0500
Subject: [Engine-devel] ovirt core sync agenda
In-Reply-To: <4F855DDD.7010903@redhat.com>
References: <4F855DDD.7010903@redhat.com>
Message-ID: <20120411130751.GN5593@us.ibm.com>

* Livnat Peer <lpeer at redhat.com> [2012-04-11 05:33]:
> Hi All,
> We have nothing on the agenda for today.
> If you have something you would like to discuss please reply to this
> mail otherwise we'll cancel today's meeting.

Itamar suggested I bring up the discussion[1] on getting maintainer
agreement for DCO/Signed-off-by logged in the commits for each of the
projects.  It's been enabled on gerrit for vdsm and ovirt-node; I wanted
to get approvial for the ovirt-engine-* projects as well.

Thanks!

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


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

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



From gjansen at redhat.com  Wed Apr 11 14:25:21 2012
From: gjansen at redhat.com (Geert Jansen)
Date: Wed, 11 Apr 2012 16:25:21 +0200
Subject: [Engine-devel] Floating Disks implementation in REST-API
In-Reply-To: <8c43bc6b-dbe6-4f4b-9b05-ccdd5c9fc0ec@zmail17.collab.prod.int.phx2.redhat.com>
References: <8c43bc6b-dbe6-4f4b-9b05-ccdd5c9fc0ec@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <4F859451.9010400@redhat.com>


On 04/10/2012 04:46 PM, Ori Liel wrote:

>> I assume that a floating disk can be attached to 0 VMs as well, right?
>> So i would assume we get a top-level /disks collection correct?? And I
>> assume that collection would only list floating disks?
>
> Indeed, there will be a root collection. but I do not see a reason why this collection should only show floating disks. I tend to think it should show all disks in the system. Keep in mind that we're going towards Shared disks, meaning the same disk may be used by two VMs, so it makes sense to show such a disk in the root collection, along with the information of which VMs it's attached to.

My gut feeling tells me it's easier to work with if it's only floating 
disks. Because if the disk is not floating, your primary URL to work on 
the disk will be the one under /vms.

>>
>> In my view, backwards compatible DELETE semantics for a floating disk
>> aren't that bad:
>>
>>   DELETE /vms/{vm:id}/disks/{disk:id}
>>
>> =>  Accept a<detach>true|false</detach>  argument.
>> =>  Defaults to "false" for compatibility.
>>
>> This means that DELETE will by default really DELETE any non-floating
>> disk. That is compatibility with today. For safety, implement this:
>>
>> =>  When deleting a disk that is floating, fail unless<force>  is also
>> set to "true". And always fail if one of the other VMs is running
>> (obviously).
>>
>
> I Agree with Eoghan that the drawbacks outweigh the benefits in this case,
> for the reasons Eoghan said.

Sorry it took a while to get back. I had a feeling that i didn't like 
the approach, and had to figure out why.

You and Eoghan propose this to detach a disk:

    POST /api/vms/{vm:id}/disks/{disk:id}/detach => detach disk

The problem i have with this is that after the "detach" action, the disk 
is gone. In my view, it is not an expected outcome of an action to 
remove the entity it is working on, because POST is not expected to 
delete the URL it is working on. This assumption is implicit for example 
when we do actions asynchronously. The status monitor that we return is 
actually a URL under the resource itself.

Two other reasons are:

  * "detach" and "attach" for NICs: there was actually a BZ open to 
implement these with PUT and DELETE as well. We just didn't have time to 
do this. So in my view this is not a valid precendent.

  * Also  "detach" and "attach" for NICs do *not* remove the NIC object 
itself, but instead it detached the network from the NIC but leaves the 
NIC in place.

So in my view, the POST and DELETE option is the best one.

Regards,
Geert


From gjansen at redhat.com  Wed Apr 11 14:29:31 2012
From: gjansen at redhat.com (Geert Jansen)
Date: Wed, 11 Apr 2012 16:29:31 +0200
Subject: [Engine-devel] Floating Disks implementation in REST-API
In-Reply-To: <4F857EE4.2040400@redhat.com>
References: <03e10fcb-1fa7-4762-b5db-0eeb369f2de5@zmail13.collab.prod.int.phx2.redhat.com>
	<4F857EE4.2040400@redhat.com>
Message-ID: <4F85954B.1000300@redhat.com>



On 04/11/2012 02:53 PM, Itamar Heim wrote:
>>> Detach a disk from VM (becomes floating):
>>> DELETE api/vms/{vm:id}/disks/{disk:id}
>>>
>>> Delete a disk ('real' delete)"
>>> DELETE api/disks/{disk:id}
>>
>> Assuming this also works when the disk is attached to a VM then the
>> above seems to me like the simplest and clearest path. i.e.
>> DELETE in VM context detaches
>
> this would break backward compatibility of the API, as today this
> deletes the disk as well.
> geert - thoughts on this?

Yes, the way this is proposed by Ayal would be incompatible. The default 
semantics for a DELETE in a VM context has to be delete, not detach. But 
I don't see that as a problem. We can pass in a 
<detach>true|false</detach> parameter.

Arguably this also more closely aligns with how people will use the API. 
I expect that normally 99% of disks in an environment will be 
non-floating. Therefore a DELETE even in VM context should by default 
really delete the disk, instead of creating a floating disk.

Regards,
Geert


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

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

Happy holiday,

Ofer Schreiber
oVirt Release Manager

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


From gjansen at redhat.com  Wed Apr 11 14:38:34 2012
From: gjansen at redhat.com (Geert Jansen)
Date: Wed, 11 Apr 2012 16:38:34 +0200
Subject: [Engine-devel] Hot-plug of disks and nics
In-Reply-To: <42673a31-5f7b-4842-b32a-77aed4113cf9@zmail11.collab.prod.int.phx2.redhat.com>
References: <42673a31-5f7b-4842-b32a-77aed4113cf9@zmail11.collab.prod.int.phx2.redhat.com>
Message-ID: <4F85976A.8030106@redhat.com>



On 04/11/2012 11:02 AM, Eoghan Glynn wrote:
>
>
>> * Inconsistent with other flows. We do not normally update status
>> fields to perform actions. For example to run a VM, we do not update
>> it's status to 'activated', we run an action (start).
>
> I think this point is the crux of the matter.
>
> IMO the consistency between activation implemented as direct state
> manipulation versus the state change occurring as a side-effect
> of an action, would be a deal-breaker.
>
> IIRC one of the reasons we avoided that kind of direct state
> manipulation first time round is that it doesn't lend itself to
> multi-state transitions, e.g. activation that traversed multiple
> intermediate states, say:
>
>    quiescent->pending->activating->activated
>
> That example is a bit contrived and unrealistic, but in any case
> the principal is that the client-visible state machine for a resource
> may not necessarily transition directly from the initial to the terminal
> state.

Exactly. The target state is not always indicative of the exact state 
transition path. A simpler example is "power off" vs "shutdown". Both 
end up with a VM in the "down" state, but the two are actually quite 
different.

> Also an action as opposed to a direct state manipulation makes it more
> natural to express side-effects of the activation, and to implement
> in-progress status querying or cancelation.
>
> For those reasons, I'm thinking that using actions consistently accross
> the board is better than exposing an action in one case while allowing
> a direct state manipulation in another.
>
> So my vote would be for option #2.

One question though (probably to Ori): from the API that you propose, i 
assume that disk hotplug is implemented as a two stage process in the 
backend?

  - add the disk to a VM
  - activate it

Because if it's just a one stage process then that would change things. 
Then you'd probably want to activate it directly as part of the POST 
call that adds the disk.

As an action name i think "hotplug" and "unplug" are slightly more 
descriptive of what you actually mean. So my vote would go for those 
names instead.

Regards,
Geert


From veillard at redhat.com  Thu Apr 12 05:18:09 2012
From: veillard at redhat.com (Daniel Veillard)
Date: Thu, 12 Apr 2012 13:18:09 +0800
Subject: [Engine-devel] Issue with XML namespaces in engine-setup
In-Reply-To: <4F841F8B.8090008@redhat.com>
References: <4F841F8B.8090008@redhat.com>
Message-ID: <20120412051809.GA22623@redhat.com>

On Tue, Apr 10, 2012 at 01:54:51PM +0200, Juan Hernandez wrote:
> Hello,
> 
> The code that we use in engine-setup to modify JBoss AS XML
> configuration files uses the following pattern:
> 
> datasourceStr = '''
>     <datasource ...>
>        ...
>     </datasource>
> '''
> 
> xmlObj.addNodes("//datasource:subsystem/datasource:datasources",
> datasourceStr)
> 
> This looks correct but is in fact generating a incorrect XML document,
> as the tags being added are not associated to a namespace. The resulting
> XML file will be correct, but the temporary representation in memory is
> not. This causes problems if you later, before writing out the modified
> file, try to use xpath expressions matching the added nodes: there will
> be no match.
> 
> I would suggest that we change the pattern to something like this:
> 
> datasourceStr = '''
>   <any_dummy_tag xmlns="urn:jboss:domain:datasources:1.0">
>     <datasource ...>
>        ...
>     </datasource>
>   </any_dummy_tag>
> '''
> datasourceNodes = libxml2.parseDoc(datasourceStr).getRootElement().children
> 
> xmlObje.addNodes("//datasource:subsystem/datasource:datasources",
> datasourceNodes)
> 
> This way both the representation in memory and the resulting file are
> correct.
> 
> Le me know what you think.

  I think it's dangerous to move nodes from one document to another
especially if there is namespaces (I assume you're operating in an
environment on top of libxml2 as I saw a reference to it ;-)

  For libxml2 there is an API in C:
    http://xmlsoft.org/html/libxml-parser.html#xmlParseInNodeContext
which could do what you expect. Maybe there is a binding/wrapper
available you could use.

Also your "//datasource:subsystem/datasource:datasources" XPath query
could lead to multiple result nodes, I would suggest to pick the first
result only, I suppose you don't want to add the set of nodes to
multiple places

  xmlObje.addNodes("(//datasource:subsystem/datasource:datasources)[1]",
                   datasourceNodes)

 or something equivalent (unless addNodes() takes care to handle that
 properly ...)

Daniel

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


From sanjal at redhat.com  Thu Apr 12 06:35:25 2012
From: sanjal at redhat.com (Shireesh Anjal)
Date: Thu, 12 Apr 2012 12:05:25 +0530
Subject: [Engine-devel] Query regarding ValidationUtils#validateInputs
Message-ID: <4F8677AD.2090304@redhat.com>

Hi,

This is regarding the following validation method we have in 
ValidationUtils:

/public static <T extends VdcActionParametersBase> ArrayList<String> 
validateInputs(List<Class<?>> validationGroupList, T parameters);/

I there any particular reason for supporting the validations only on 
objects of classes derived from VdcActionParametersBase? I guess this 
was done because this method is primarily intended to validate the 
action parameters passed to a BLL action, using the validation 
annotations on the parameter class. However I think this method can be 
useful for general use as well. e.g. I cannot add a "@Valid" annotation 
on a "list" or a "map" in a parameter class. So I need to iterate over 
the list/map, and validate each element inside the loop. The validation 
inside the loop can also utilize the above method if the restriction 
"extends VdcActionParametersBase" is removed. This will allow me to do 
the following in the canDoAction method:

protected boolean canDoAction() {
...
     for(GlusterBrickEntity brick : 
getParameters().getGlusterVolume().getBricks()) {
         List<String> errors = 
ValidationUtils.validateInputs(getValidationGroups(), brick);
         if(errors != null) {
             for(String error : errors) {
                 addCanDoActionMessage(error);
             }
         }
     }
...
}

Regards,
Shireesh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20120412/bdaa0f0a/attachment.html>

From ofrenkel at redhat.com  Thu Apr 12 07:50:37 2012
From: ofrenkel at redhat.com (Omer Frenkel)
Date: Thu, 12 Apr 2012 03:50:37 -0400 (EDT)
Subject: [Engine-devel] Query regarding ValidationUtils#validateInputs
In-Reply-To: <4F8677AD.2090304@redhat.com>
Message-ID: <15a5329c-4579-4ef6-b1c8-be0b260e859b@zmail07.collab.prod.int.phx2.redhat.com>

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

> From: "Shireesh Anjal" <sanjal at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Thursday, April 12, 2012 9:35:25 AM
> Subject: [Engine-devel] Query regarding
> ValidationUtils#validateInputs

> Hi,

> This is regarding the following validation method we have in
> ValidationUtils:

> public static <T extends VdcActionParametersBase> ArrayList<String>
> validateInputs(List<Class<?>> validationGroupList, T parameters);

> I there any particular reason for supporting the validations only on
> objects of classes derived from VdcActionParametersBase? I guess
> this was done because this method is primarily intended to validate
> the action parameters passed to a BLL action, using the validation
> annotations on the parameter class. However I think this method can
> be useful for general use as well. e.g. I cannot add a "@Valid"
> annotation on a "list" or a "map" in a parameter class. So I need to
> iterate over the list/map, and validate each element inside the
> loop. The validation inside the loop can also utilize the above
> method if the restriction "extends VdcActionParametersBase" is
> removed. This will allow me to do the following in the canDoAction
> method:

> protected boolean canDoAction() {
> ...
> for(GlusterBrickEntity brick :
> getParameters().getGlusterVolume().getBricks()) {
> List<String> errors =
> ValidationUtils.validateInputs(getValidationGroups(), brick);
> if(errors != null) {
> for(String error : errors) {
> addCanDoActionMessage(error);
> }
> }
> }
> ...
> }

> Regards,
> Shireesh

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

i don't think there is a reason to restrict only for VdcActionParametersBase, roy what do you think? 

also you can use here 
getReturnValue().getCanDoActionMessages().addAll(errors); 
instead of going over on all errors. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20120412/38e3bc38/attachment.html>

From juan.hernandez at redhat.com  Fri Apr 13 17:59:32 2012
From: juan.hernandez at redhat.com (Juan Hernandez)
Date: Fri, 13 Apr 2012 19:59:32 +0200
Subject: [Engine-devel] Issue with XML namespaces in engine-setup
In-Reply-To: <20120412051809.GA22623@redhat.com>
References: <4F841F8B.8090008@redhat.com> <20120412051809.GA22623@redhat.com>
Message-ID: <4F886984.6080408@redhat.com>

On 04/12/2012 07:18 AM, Daniel Veillard wrote:
> On Tue, Apr 10, 2012 at 01:54:51PM +0200, Juan Hernandez wrote:
>> Hello,
>>
>> The code that we use in engine-setup to modify JBoss AS XML
>> configuration files uses the following pattern:
>>
>> datasourceStr = '''
>>     <datasource ...>
>>        ...
>>     </datasource>
>> '''
>>
>> xmlObj.addNodes("//datasource:subsystem/datasource:datasources",
>> datasourceStr)
>>
>> This looks correct but is in fact generating a incorrect XML document,
>> as the tags being added are not associated to a namespace. The resulting
>> XML file will be correct, but the temporary representation in memory is
>> not. This causes problems if you later, before writing out the modified
>> file, try to use xpath expressions matching the added nodes: there will
>> be no match.
>>
>> I would suggest that we change the pattern to something like this:
>>
>> datasourceStr = '''
>>   <any_dummy_tag xmlns="urn:jboss:domain:datasources:1.0">
>>     <datasource ...>
>>        ...
>>     </datasource>
>>   </any_dummy_tag>
>> '''
>> datasourceNodes = libxml2.parseDoc(datasourceStr).getRootElement().children
>>
>> xmlObje.addNodes("//datasource:subsystem/datasource:datasources",
>> datasourceNodes)
>>
>> This way both the representation in memory and the resulting file are
>> correct.
>>
>> Le me know what you think.
> 
>   I think it's dangerous to move nodes from one document to another
> especially if there is namespaces (I assume you're operating in an
> environment on top of libxml2 as I saw a reference to it ;-)
> 
>   For libxml2 there is an API in C:
>     http://xmlsoft.org/html/libxml-parser.html#xmlParseInNodeContext
> which could do what you expect. Maybe there is a binding/wrapper
> available you could use.

Thanks Daniel, that looks certainly better/easier than what I am
proposing. We use libxml2-python, but I can't locate that method there.
Do you know if it is possible to use it from python?

> Also your "//datasource:subsystem/datasource:datasources" XPath query
> could lead to multiple result nodes, I would suggest to pick the first
> result only, I suppose you don't want to add the set of nodes to
> multiple places
> 
>   xmlObje.addNodes("(//datasource:subsystem/datasource:datasources)[1]",
>                    datasourceNodes)
> 
>  or something equivalent (unless addNodes() takes care to handle that
>  properly ...)

Yes, the addNodes method takes care of that.



From veillard at redhat.com  Sat Apr 14 01:55:31 2012
From: veillard at redhat.com (Daniel Veillard)
Date: Sat, 14 Apr 2012 09:55:31 +0800
Subject: [Engine-devel] Issue with XML namespaces in engine-setup
In-Reply-To: <4F886984.6080408@redhat.com>
References: <4F841F8B.8090008@redhat.com> <20120412051809.GA22623@redhat.com>
	<4F886984.6080408@redhat.com>
Message-ID: <20120414015531.GF22623@redhat.com>

On Fri, Apr 13, 2012 at 07:59:32PM +0200, Juan Hernandez wrote:
> On 04/12/2012 07:18 AM, Daniel Veillard wrote:
> > On Tue, Apr 10, 2012 at 01:54:51PM +0200, Juan Hernandez wrote:
> >> Hello,
> >>
> >> The code that we use in engine-setup to modify JBoss AS XML
> >> configuration files uses the following pattern:
> >>
> >> datasourceStr = '''
> >>     <datasource ...>
> >>        ...
> >>     </datasource>
> >> '''
> >>
> >> xmlObj.addNodes("//datasource:subsystem/datasource:datasources",
> >> datasourceStr)
> >>
> >> This looks correct but is in fact generating a incorrect XML document,
> >> as the tags being added are not associated to a namespace. The resulting
> >> XML file will be correct, but the temporary representation in memory is
> >> not. This causes problems if you later, before writing out the modified
> >> file, try to use xpath expressions matching the added nodes: there will
> >> be no match.
> >>
> >> I would suggest that we change the pattern to something like this:
> >>
> >> datasourceStr = '''
> >>   <any_dummy_tag xmlns="urn:jboss:domain:datasources:1.0">
> >>     <datasource ...>
> >>        ...
> >>     </datasource>
> >>   </any_dummy_tag>
> >> '''
> >> datasourceNodes = libxml2.parseDoc(datasourceStr).getRootElement().children
> >>
> >> xmlObje.addNodes("//datasource:subsystem/datasource:datasources",
> >> datasourceNodes)
> >>
> >> This way both the representation in memory and the resulting file are
> >> correct.
> >>
> >> Le me know what you think.
> > 
> >   I think it's dangerous to move nodes from one document to another
> > especially if there is namespaces (I assume you're operating in an
> > environment on top of libxml2 as I saw a reference to it ;-)
> > 
> >   For libxml2 there is an API in C:
> >     http://xmlsoft.org/html/libxml-parser.html#xmlParseInNodeContext
> > which could do what you expect. Maybe there is a binding/wrapper
> > available you could use.
> 
> Thanks Daniel, that looks certainly better/easier than what I am
> proposing. We use libxml2-python, but I can't locate that method there.
> Do you know if it is possible to use it from python?

  Argh, right it's missing :-( the bindings could not be automatically
generated. I need to add this but before it's deployed it will take a
while, too bad that was the right way to do it :-\
  To get back to your original problem, I would suggest to correct
explicitely the namespaces on the nodes rather than move them from
an external document, this feel less risky.

  The lxml python bindings around libxml2 [1] try to avoid such issues
by making sure all documents share the same dictionary and control the
copy operations, but I don't know if Stefan Behnel managed to cover all
the cases

Daniel

[1] http://lxml.de/

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


From rgolan at redhat.com  Sun Apr 15 06:01:32 2012
From: rgolan at redhat.com (Roy Golan)
Date: Sun, 15 Apr 2012 09:01:32 +0300
Subject: [Engine-devel] Query regarding ValidationUtils#validateInputs
In-Reply-To: <15a5329c-4579-4ef6-b1c8-be0b260e859b@zmail07.collab.prod.int.phx2.redhat.com>
References: <15a5329c-4579-4ef6-b1c8-be0b260e859b@zmail07.collab.prod.int.phx2.redhat.com>
Message-ID: <4F8A643C.8060605@redhat.com>

On 04/12/2012 10:50 AM, Omer Frenkel wrote:
>
>
> ------------------------------------------------------------------------
>
>     *From: *"Shireesh Anjal" <sanjal at redhat.com>
>     *To: *engine-devel at ovirt.org
>     *Sent: *Thursday, April 12, 2012 9:35:25 AM
>     *Subject: *[Engine-devel] Query regarding
>     ValidationUtils#validateInputs
>
>     Hi,
>
>     This is regarding the following validation method we have in
>     ValidationUtils:
>
>     /public static <T extends VdcActionParametersBase>
>     ArrayList<String> validateInputs(List<Class<?>>
>     validationGroupList, T parameters);/
>
>     I there any particular reason for supporting the validations only
>     on objects of classes derived from VdcActionParametersBase? I
>     guess this was done because this method is primarily intended to
>     validate the action parameters passed to a BLL action, using the
>     validation annotations on the parameter class. However I think
>     this method can be useful for general use as well. e.g. I cannot
>     add a "@Valid" annotation on a "list" or a "map" in a parameter
>     class. So I need to iterate over the list/map, and validate each
>     element inside the loop. The validation inside the loop can also
>     utilize the above method if the restriction "extends
>     VdcActionParametersBase" is removed. This will allow me to do the
>     following in the canDoAction method:
>
>     protected boolean canDoAction() {
>     ...
>         for(GlusterBrickEntity brick :
>     getParameters().getGlusterVolume().getBricks()) {
>             List<String> errors =
>     ValidationUtils.validateInputs(getValidationGroups(), brick);
>             if(errors != null) {
>                 for(String error : errors) {
>                     addCanDoActionMessage(error);
>                 }
>             }
>         }
>     ...
>     }
>
>     Regards,
>     Shireesh
>
>     _______________________________________________
>     Engine-devel mailing list
>     Engine-devel at ovirt.org
>     http://lists.ovirt.org/mailman/listinfo/engine-devel
>
> i don't think there is a reason to restrict only for 
> VdcActionParametersBase, roy what do you think?
>
> also you can use here
> getReturnValue().getCanDoActionMessages().addAll(errors);
> instead of going over on all errors.

pls see SetupNetworksParameters.java for validating a list of network 
interfaces.

hibernate validator supports trivial object graphs and members that are 
arrays, list and java.util.map implementations.
If your code looks like that it should work. If you are using special 
validation groups please add them to your command with addValidationGroups.

this should work:

GlusterCommandParameters.java
  @Valid
  List<Bricks> bricks

  Bricks.java
  @NotNull
  Guid id
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20120415/22cacd32/attachment.html>

From ovedo at redhat.com  Sun Apr 15 11:06:02 2012
From: ovedo at redhat.com (Oved Ourfalli)
Date: Sun, 15 Apr 2012 07:06:02 -0400 (EDT)
Subject: [Engine-devel] REST session management
In-Reply-To: <af475644-5b07-430c-adfb-eebe2c5d638c@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <51803a19-ebfc-4f06-badf-963f1d302c81@zmail02.collab.prod.int.phx2.redhat.com>

Hey,

The following wiki page describes a new feature - supporting session management via the REST API:
http://www.ovirt.org/wiki/Features/RESTSessionManagement

Please review and comment.

Thank you,
Oved


From yzaslavs at redhat.com  Mon Apr 16 03:25:12 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Mon, 16 Apr 2012 06:25:12 +0300
Subject: [Engine-devel] Getting into memory allocation problems in git?
Message-ID: <4F8B9118.9050803@redhat.com>

Hi all,
I got a strange error while trying to fetch a patch from ovrit gerrit.
The error looked like this -


git fetch http://gerrit.ovirt.org/p/ovirt-engine refs/changes/41/3541/1
&& git checkout FETCH_HEAD
error: Could not resolve host: gerrit.ovirt.org; Cannot allocate memory
while accessing http://gerrit.ovirt.org/p/ovirt-engine/info/refs

fatal: HTTP request failed



Could not find anything interesting in google, and out of despair
started to pass on manual of git.
I then encountered git gc.
My java instincts told me to give it a shot (after all, garbage
collection sounds good), and it worked!
(Nothing helped before - not removing local branches, not trying to
perform this from various branches, etc...)


FYI

Yair


From gjansen at redhat.com  Mon Apr 16 07:26:18 2012
From: gjansen at redhat.com (Geert Jansen)
Date: Mon, 16 Apr 2012 09:26:18 +0200
Subject: [Engine-devel] REST session management
In-Reply-To: <51803a19-ebfc-4f06-badf-963f1d302c81@zmail02.collab.prod.int.phx2.redhat.com>
References: <51803a19-ebfc-4f06-badf-963f1d302c81@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <4F8BC99A.2020606@redhat.com>

Hi Oved,

+1 for this feature.

[[As a background to the others on the list, this feature is absolutely 
essential for certain types of ISV integration. Many ISVs need to mirror 
the RHEV inventory (i.e. all VMs, clusters, basically any object managed 
by RHEV) in realtime to their own database. The way they do this 
currently is by polling /api/events and look for changes. In order to be 
able to react to changes fast, they typically poll every 5 seconds. The 
query itself is very efficient, so it doesn't cause a whole lot of load 
on RHEV-M. But it floods the log with login/logout events. This 
persistent session feature is a solution for that.]]

Actually my vote would go for your variation #2:

    The client passes the "Prefer" header field on every request,
    besides the last one. When the server gets a request with a
    JSESSIONID, and without the "Prefer" header, it logs out the session.

It's mostly my gut feeling, but i would say it has these advantages:

1. It is more explicit, as on every request you confirm that you still 
want the authenticated session to be maintained.
2. It is also consistent with the default we have chosen of no 
persistent authentication.
3. It does not need a second header, so it is somewhat simpler.

Regards,
Geert

On 04/15/2012 01:06 PM, Oved Ourfalli wrote:
> Hey,
>
> The following wiki page describes a new feature - supporting session management via the REST API:
> http://www.ovirt.org/wiki/Features/RESTSessionManagement
>
> Please review and comment.
>
> Thank you,
> Oved

-- 
Geert Jansen
Sr. Product Marketing Manager, Red Hat Enterprise Virtualization

Red Hat S.r.L.           O: +39 095 916287
Via G. Fara 26           C: +39 348 1980079 (when in US: 415-623-0542)
Milan 20124, Italy       E: gjansen at redhat.com


From ovedo at redhat.com  Mon Apr 16 07:44:31 2012
From: ovedo at redhat.com (Oved Ourfalli)
Date: Mon, 16 Apr 2012 03:44:31 -0400 (EDT)
Subject: [Engine-devel] REST session management
In-Reply-To: <4F8BC99A.2020606@redhat.com>
Message-ID: <d18c817e-8fdc-4967-bcd6-fdce0313d04a@zmail02.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Geert Jansen" <gjansen at redhat.com>
> To: "Oved Ourfalli" <ovedo at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "Eoghan Glynn" <eglynn at redhat.com>
> Sent: Monday, April 16, 2012 10:26:18 AM
> Subject: Re: [Engine-devel] REST session management
> 
> Hi Oved,
> 
> +1 for this feature.
> 
> [[As a background to the others on the list, this feature is
> absolutely
> essential for certain types of ISV integration. Many ISVs need to
> mirror
> the RHEV inventory (i.e. all VMs, clusters, basically any object
> managed
> by RHEV) in realtime to their own database. The way they do this
> currently is by polling /api/events and look for changes. In order to
> be
> able to react to changes fast, they typically poll every 5 seconds.
> The
> query itself is very efficient, so it doesn't cause a whole lot of
> load
> on RHEV-M. But it floods the log with login/logout events. This
> persistent session feature is a solution for that.]]
> 
Thank you for the background. I'll add it to the wiki page.
 
> Actually my vote would go for your variation #2:
> 
>     The client passes the "Prefer" header field on every request,
>     besides the last one. When the server gets a request with a
>     JSESSIONID, and without the "Prefer" header, it logs out the
>     session.
> 
> It's mostly my gut feeling, but i would say it has these advantages:
> 
> 1. It is more explicit, as on every request you confirm that you
> still
> want the authenticated session to be maintained.
> 2. It is also consistent with the default we have chosen of no
> persistent authentication.
> 3. It does not need a second header, so it is somewhat simpler.
> 

I Agree on that, although I'm not sure whether it is really needed to release the session, rather then rely on timeout.
If we indeed need to provide a way to release the session then I agree this is the best alternative. But if we don't then it will make the API to the client more (but not very) complex in that manner.
The only doubt I have about that is that from reading on the new "Prefer" header, I got the feeling that it is more relevant on session negotiation, and less something you would pass on every request in the session, but I'm not sure about that.

> Regards,
> Geert
> 
> On 04/15/2012 01:06 PM, Oved Ourfalli wrote:
> > Hey,
> >
> > The following wiki page describes a new feature - supporting
> > session management via the REST API:
> > http://www.ovirt.org/wiki/Features/RESTSessionManagement
> >
> > Please review and comment.
> >
> > Thank you,
> > Oved
> 
> --
> Geert Jansen
> Sr. Product Marketing Manager, Red Hat Enterprise Virtualization
> 
> Red Hat S.r.L.           O: +39 095 916287
> Via G. Fara 26           C: +39 348 1980079 (when in US:
> 415-623-0542)
> Milan 20124, Italy       E: gjansen at redhat.com
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From mkenneth at redhat.com  Mon Apr 16 08:04:14 2012
From: mkenneth at redhat.com (Miki Kenneth)
Date: Mon, 16 Apr 2012 04:04:14 -0400 (EDT)
Subject: [Engine-devel] REST session management
In-Reply-To: <d18c817e-8fdc-4967-bcd6-fdce0313d04a@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <05eb7ea8-086d-4ab3-aac5-e261229ab29b@mkenneth.csb>



----- Original Message -----
> From: "Oved Ourfalli" <ovedo at redhat.com>
> To: "Geert Jansen" <gjansen at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "Eoghan Glynn" <eglynn at redhat.com>
> Sent: Monday, April 16, 2012 10:44:31 AM
> Subject: Re: [Engine-devel] REST session management
> 
> 
> 
> ----- Original Message -----
> > From: "Geert Jansen" <gjansen at redhat.com>
> > To: "Oved Ourfalli" <ovedo at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>, "Eoghan Glynn"
> > <eglynn at redhat.com>
> > Sent: Monday, April 16, 2012 10:26:18 AM
> > Subject: Re: [Engine-devel] REST session management
> > 
> > Hi Oved,
> > 
> > +1 for this feature.
> > 
> > [[As a background to the others on the list, this feature is
> > absolutely
> > essential for certain types of ISV integration. Many ISVs need to
> > mirror
> > the RHEV inventory (i.e. all VMs, clusters, basically any object
> > managed
> > by RHEV) in realtime to their own database. The way they do this
> > currently is by polling /api/events and look for changes. In order
> > to
> > be
> > able to react to changes fast, they typically poll every 5 seconds.
> > The
> > query itself is very efficient, so it doesn't cause a whole lot of
> > load
> > on RHEV-M. But it floods the log with login/logout events. This
> > persistent session feature is a solution for that.]]
> > 
> Thank you for the background. I'll add it to the wiki page.
>  
> > Actually my vote would go for your variation #2:
> > 
> >     The client passes the "Prefer" header field on every request,
> >     besides the last one. When the server gets a request with a
> >     JSESSIONID, and without the "Prefer" header, it logs out the
> >     session.
> > 
> > It's mostly my gut feeling, but i would say it has these
> > advantages:
> > 
> > 1. It is more explicit, as on every request you confirm that you
> > still
> > want the authenticated session to be maintained.
> > 2. It is also consistent with the default we have chosen of no
> > persistent authentication.
> > 3. It does not need a second header, so it is somewhat simpler.
> > 
> 
> I Agree on that, although I'm not sure whether it is really needed to
> release the session, rather then rely on timeout.
> If we indeed need to provide a way to release the session then I
> agree this is the best alternative. But if we don't then it will
> make the API to the client more (but not very) complex in that
> manner.
I would go for both - release mechanism (for proper handling) and timeout mechanism for garbage collection.
(refer to: http://blog.synopse.info/post/2011/05/24/How-to-implement-RESTful-authentication)

> The only doubt I have about that is that from reading on the new
> "Prefer" header, I got the feeling that it is more relevant on
> session negotiation, and less something you would pass on every
> request in the session, but I'm not sure about that.
> 
> > Regards,
> > Geert
> > 
> > On 04/15/2012 01:06 PM, Oved Ourfalli wrote:
> > > Hey,
> > >
> > > The following wiki page describes a new feature - supporting
> > > session management via the REST API:
> > > http://www.ovirt.org/wiki/Features/RESTSessionManagement
> > >
> > > Please review and comment.
> > >
> > > Thank you,
> > > Oved
> > 
> > --
> > Geert Jansen
> > Sr. Product Marketing Manager, Red Hat Enterprise Virtualization
> > 
> > Red Hat S.r.L.           O: +39 095 916287
> > Via G. Fara 26           C: +39 348 1980079 (when in US:
> > 415-623-0542)
> > Milan 20124, Italy       E: gjansen at redhat.com
> > _______________________________________________
> > 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 gjansen at redhat.com  Mon Apr 16 08:34:26 2012
From: gjansen at redhat.com (Geert Jansen)
Date: Mon, 16 Apr 2012 10:34:26 +0200
Subject: [Engine-devel] REST session management
In-Reply-To: <05eb7ea8-086d-4ab3-aac5-e261229ab29b@mkenneth.csb>
References: <05eb7ea8-086d-4ab3-aac5-e261229ab29b@mkenneth.csb>
Message-ID: <4F8BD992.5040007@redhat.com>


On 04/16/2012 10:04 AM, Miki Kenneth wrote:

>> I Agree on that, although I'm not sure whether it is really needed to
>> release the session, rather then rely on timeout.
>> If we indeed need to provide a way to release the session then I
>> agree this is the best alternative. But if we don't then it will
>> make the API to the client more (but not very) complex in that
>> manner.
 >
> I would go for both - release mechanism (for proper handling) and timeout mechanism for garbage collection.
> (refer to: http://blog.synopse.info/post/2011/05/24/How-to-implement-RESTful-authentication)

Agreed we need both. I think that for security purposes, it is important 
to have a "log out" function. That way, client applications can decide 
depending on their local security requirements whether or not it is 
acceptable to leave a session open.

Regards,
Geert


From ovedo at redhat.com  Mon Apr 16 08:44:27 2012
From: ovedo at redhat.com (Oved Ourfalli)
Date: Mon, 16 Apr 2012 04:44:27 -0400 (EDT)
Subject: [Engine-devel] REST session management
In-Reply-To: <4F8BD992.5040007@redhat.com>
Message-ID: <590d66ad-7eee-4637-8303-d4685fb13f4d@zmail02.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Geert Jansen" <gjansen at redhat.com>
> To: "Miki Kenneth" <mkenneth at redhat.com>
> Cc: "Oved Ourfalli" <ovedo at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "Eoghan Glynn" <eglynn at redhat.com>
> Sent: Monday, April 16, 2012 11:34:26 AM
> Subject: Re: [Engine-devel] REST session management
> 
> 
> On 04/16/2012 10:04 AM, Miki Kenneth wrote:
> 
> >> I Agree on that, although I'm not sure whether it is really needed
> >> to
> >> release the session, rather then rely on timeout.
> >> If we indeed need to provide a way to release the session then I
> >> agree this is the best alternative. But if we don't then it will
> >> make the API to the client more (but not very) complex in that
> >> manner.
>  >
> > I would go for both - release mechanism (for proper handling) and
> > timeout mechanism for garbage collection.
> > (refer to:
> > http://blog.synopse.info/post/2011/05/24/How-to-implement-RESTful-authentication)
> 
> Agreed we need both. I think that for security purposes, it is
> important
> to have a "log out" function. That way, client applications can
> decide
> depending on their local security requirements whether or not it is
> acceptable to leave a session open.
> 
So (unless someone objects) let's go for option #2 (using the Prefer header on each and every request, and release the session once it is not there).

Thank you,
Oved
> Regards,
> Geert
> 


From ykaul at redhat.com  Mon Apr 16 11:03:26 2012
From: ykaul at redhat.com (Yaniv Kaul)
Date: Mon, 16 Apr 2012 14:03:26 +0300
Subject: [Engine-devel] REST session management
In-Reply-To: <590d66ad-7eee-4637-8303-d4685fb13f4d@zmail02.collab.prod.int.phx2.redhat.com>
References: <590d66ad-7eee-4637-8303-d4685fb13f4d@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <4F8BFC7E.3050904@redhat.com>

On 04/16/2012 11:44 AM, Oved Ourfalli wrote:
>
> ----- Original Message -----
>> From: "Geert Jansen"<gjansen at redhat.com>
>> To: "Miki Kenneth"<mkenneth at redhat.com>
>> Cc: "Oved Ourfalli"<ovedo at redhat.com>, "engine-devel"<engine-devel at ovirt.org>, "Eoghan Glynn"<eglynn at redhat.com>
>> Sent: Monday, April 16, 2012 11:34:26 AM
>> Subject: Re: [Engine-devel] REST session management
>>
>>
>> On 04/16/2012 10:04 AM, Miki Kenneth wrote:
>>
>>>> I Agree on that, although I'm not sure whether it is really needed
>>>> to
>>>> release the session, rather then rely on timeout.
>>>> If we indeed need to provide a way to release the session then I
>>>> agree this is the best alternative. But if we don't then it will
>>>> make the API to the client more (but not very) complex in that
>>>> manner.
>>   >
>>> I would go for both - release mechanism (for proper handling) and
>>> timeout mechanism for garbage collection.
>>> (refer to:
>>> http://blog.synopse.info/post/2011/05/24/How-to-implement-RESTful-authentication)
>> Agreed we need both. I think that for security purposes, it is
>> important
>> to have a "log out" function. That way, client applications can
>> decide
>> depending on their local security requirements whether or not it is
>> acceptable to leave a session open.
>>
> So (unless someone objects) let's go for option #2 (using the Prefer header on each and every request, and release the session once it is not there).

My only objection is that you implement a draft spec and implement a 
header without even bothering to register it - or asking if there is 
such an identical-purposed header with a different name which may get 
registered / is already in use somewhere.
Y.

>
> Thank you,
> Oved
>> Regards,
>> Geert
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From ovedo at redhat.com  Mon Apr 16 11:46:29 2012
From: ovedo at redhat.com (Oved Ourfalli)
Date: Mon, 16 Apr 2012 07:46:29 -0400 (EDT)
Subject: [Engine-devel] REST session management
In-Reply-To: <4F8BFC7E.3050904@redhat.com>
Message-ID: <1c483cab-5beb-4cee-b370-991dd3139a12@zmail02.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Yaniv Kaul" <ykaul at redhat.com>
> To: "Oved Ourfalli" <ovedo at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "Eoghan Glynn" <eglynn at redhat.com>
> Sent: Monday, April 16, 2012 2:03:26 PM
> Subject: Re: [Engine-devel] REST session management
> 
> On 04/16/2012 11:44 AM, Oved Ourfalli wrote:
> >
> > ----- Original Message -----
> >> From: "Geert Jansen"<gjansen at redhat.com>
> >> To: "Miki Kenneth"<mkenneth at redhat.com>
> >> Cc: "Oved Ourfalli"<ovedo at redhat.com>,
> >> "engine-devel"<engine-devel at ovirt.org>, "Eoghan
> >> Glynn"<eglynn at redhat.com>
> >> Sent: Monday, April 16, 2012 11:34:26 AM
> >> Subject: Re: [Engine-devel] REST session management
> >>
> >>
> >> On 04/16/2012 10:04 AM, Miki Kenneth wrote:
> >>
> >>>> I Agree on that, although I'm not sure whether it is really
> >>>> needed
> >>>> to
> >>>> release the session, rather then rely on timeout.
> >>>> If we indeed need to provide a way to release the session then I
> >>>> agree this is the best alternative. But if we don't then it will
> >>>> make the API to the client more (but not very) complex in that
> >>>> manner.
> >>   >
> >>> I would go for both - release mechanism (for proper handling) and
> >>> timeout mechanism for garbage collection.
> >>> (refer to:
> >>> http://blog.synopse.info/post/2011/05/24/How-to-implement-RESTful-authentication)
> >> Agreed we need both. I think that for security purposes, it is
> >> important
> >> to have a "log out" function. That way, client applications can
> >> decide
> >> depending on their local security requirements whether or not it
> >> is
> >> acceptable to leave a session open.
> >>
> > So (unless someone objects) let's go for option #2 (using the
> > Prefer header on each and every request, and release the session
> > once it is not there).
> 
> My only objection is that you implement a draft spec and implement a
> header without even bothering to register it - or asking if there is
> such an identical-purposed header with a different name which may get
> registered / is already in use somewhere.
> Y.
> 
One of the reasons of posting to this mailing list is to try and get information on alternatives.
I already looked for similar headers, but I'll take another look to see if others exist.
Any idea where I can get an official answer for that?
Looked in http://www.iana.org/assignments/message-headers/perm-headers.html, but it was hard to find a more suitable header there.
We can have a dedicated header of our own in that matter, but better being standard.

BTW, from what I read the acceptance process is in its final stages, but I'm not too familiar with the process, so hard to say how much time will it take for it to be complete.

> >
> > Thank you,
> > Oved
> >> Regards,
> >> Geert
> >>
> > _______________________________________________
> > 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 gjansen at redhat.com  Mon Apr 16 12:31:43 2012
From: gjansen at redhat.com (Geert Jansen)
Date: Mon, 16 Apr 2012 14:31:43 +0200
Subject: [Engine-devel] REST session management
In-Reply-To: <4F8BFC7E.3050904@redhat.com>
References: <590d66ad-7eee-4637-8303-d4685fb13f4d@zmail02.collab.prod.int.phx2.redhat.com>
	<4F8BFC7E.3050904@redhat.com>
Message-ID: <4F8C112F.1060703@redhat.com>


On 04/16/2012 01:03 PM, Yaniv Kaul wrote:

>> So (unless someone objects) let's go for option #2 (using the Prefer
>> header on each and every request, and release the session once it is
>> not there).
>
> My only objection is that you implement a draft spec and implement a
> header without even bothering to register it - or asking if there is
> such an identical-purposed header with a different name which may get
> registered / is already in use somewhere.

This is somewhat of a red herring though.

HTTP Prefer was created exactly for the purpose of indicating a 
preference for a certain behavior of response. Have a look at section 
9.1.1 of the draft RFC for the initial preferences and you'll see the 
preferences that are already registered.

HTTP Prefer also defines a registration process for the possible values 
of this header. The process requires an email to preferences at ietf.org 
with a 14 day response time.

The alternative to HTTP Prefer would be creating a new header (as i am 
not aware of any other /approved/ header that fits the bill). This 
requires writing an RFC and get it approved, which would take much 
longer, and which would likely get the comment of "Why aren't you using 
Prefer".

Even if HTTP Prefer, for whatever reason, unexpectedly does not become a 
standard, i think in practice this does not impact us in any way.

Regards
Geert


From oliel at redhat.com  Mon Apr 16 12:33:27 2012
From: oliel at redhat.com (Ori Liel)
Date: Mon, 16 Apr 2012 08:33:27 -0400 (EDT)
Subject: [Engine-devel] Floating Disks implementation in REST-API
In-Reply-To: <4F859800.4000307@redhat.com>
Message-ID: <861e9232-ff09-47ba-8c69-3ed0013e6961@zmail17.collab.prod.int.phx2.redhat.com>

I'd like us to move forward with this. 

The option of using 'attach' action does not exist, because, as Eoghan observed, we would be executing an action on an entity which doesn't exist in the collection: (.../api/vms/{vm:id}/disks/???-no entity-???/attach)

There are two options left on the table; let's see if we can agree on one of them: 

1) 
        POST/api/vms/{vm:id}/disks
        <disk id="{disk:id}"/>                               =>  attach disk

        DELETE .../api/vms/{vm:id}/disks/{disk:id}
        <disk><detach>true</detach><disk>                    =>  detach disk

Pros: symmetrical
Cons: risky (if user wants to detach but forgot to give parameter, disk will be deleted). 

2) 

        POST/api/vms/{vm:id}/disks
        <disk id="{disk:id}"/>                               =>  attach disk

        DELETE .../api/vms/{vm:id}/disks/{disk:id}/detach    =>  detach disk

Pros: not dangerous
Cons: asymmetrical, attach done like add, but detach done using action. 


No solution is perfect but we need to decide. 

Thanks, 

Ori. 


From gjansen at redhat.com  Mon Apr 16 12:38:33 2012
From: gjansen at redhat.com (Geert Jansen)
Date: Mon, 16 Apr 2012 14:38:33 +0200
Subject: [Engine-devel] Floating Disks implementation in REST-API
In-Reply-To: <861e9232-ff09-47ba-8c69-3ed0013e6961@zmail17.collab.prod.int.phx2.redhat.com>
References: <861e9232-ff09-47ba-8c69-3ed0013e6961@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <4F8C12C9.30300@redhat.com>



On 04/16/2012 02:33 PM, Ori Liel wrote:
> I'd like us to move forward with this.
>
> The option of using 'attach' action does not exist, because, as Eoghan observed, we would be executing an action on an entity which doesn't exist in the collection: (.../api/vms/{vm:id}/disks/???-no entity-???/attach)
>
> There are two options left on the table; let's see if we can agree on one of them:
>
> 1)
>          POST/api/vms/{vm:id}/disks
>          <disk id="{disk:id}"/>                                =>   attach disk
>
>          DELETE .../api/vms/{vm:id}/disks/{disk:id}
>          <disk><detach>true</detach><disk>                     =>   detach disk
>
> Pros: symmetrical
> Cons: risky (if user wants to detach but forgot to give parameter, disk will be deleted).

My idea for that was to introduce <force>true|false</force> as well. 
Without force=true, we won't delete a disk if it's currently floating.

I think it makes it less risky. And it is still backwards compatible, as 
3.0 clients do not know how to create a floating disk, and therefore 
there is no risk that they are deleting one.

Regards,
Geert


>
> 2)
>
>          POST/api/vms/{vm:id}/disks
>          <disk id="{disk:id}"/>                                =>   attach disk
>
>          DELETE .../api/vms/{vm:id}/disks/{disk:id}/detach    =>   detach disk
>
> Pros: not dangerous
> Cons: asymmetrical, attach done like add, but detach done using action.
>
>
> No solution is perfect but we need to decide.
>
> Thanks,
>
> Ori.

-- 
Geert Jansen
Sr. Product Marketing Manager, Red Hat Enterprise Virtualization

Red Hat S.r.L.           O: +39 095 916287
Via G. Fara 26           C: +39 348 1980079 (when in US: 415-623-0542)
Milan 20124, Italy       E: gjansen at redhat.com


From acathrow at redhat.com  Mon Apr 16 12:39:42 2012
From: acathrow at redhat.com (Andrew Cathrow)
Date: Mon, 16 Apr 2012 08:39:42 -0400 (EDT)
Subject: [Engine-devel] Floating Disks implementation in REST-API
In-Reply-To: <861e9232-ff09-47ba-8c69-3ed0013e6961@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <19cb9b3b-da35-4f51-8531-2ad4c30424fa@zmail07.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Ori Liel" <oliel at redhat.com>
> To: engine-devel at ovirt.org
> Cc: "Eoghan Glynn" <eglynn at redhat.com>
> Sent: Monday, April 16, 2012 8:33:27 AM
> Subject: Re: [Engine-devel] Floating Disks implementation in REST-API
> 
> I'd like us to move forward with this.
> 
> The option of using 'attach' action does not exist, because, as
> Eoghan observed, we would be executing an action on an entity which
> doesn't exist in the collection: (.../api/vms/{vm:id}/disks/???-no
> entity-???/attach)
> 
> There are two options left on the table; let's see if we can agree on
> one of them:
> 
> 1)
>         POST/api/vms/{vm:id}/disks
>         <disk id="{disk:id}"/>                               =>
>          attach disk
> 
>         DELETE .../api/vms/{vm:id}/disks/{disk:id}
>         <disk><detach>true</detach><disk>                    =>
>          detach disk
> 
> Pros: symmetrical
> Cons: risky (if user wants to detach but forgot to give parameter,
> disk will be deleted).
> 
> 2)
> 
>         POST/api/vms/{vm:id}/disks
>         <disk id="{disk:id}"/>                               =>
>          attach disk
> 
>         DELETE .../api/vms/{vm:id}/disks/{disk:id}/detach    =>
>          detach disk
> 
> Pros: not dangerous
> Cons: asymmetrical, attach done like add, but detach done using
> action.
> 

Is there a 3rd option based on #1 where we just detach the disk rather than detaching and deleting?
That could be further extended by adding an optional delete flag


> 
> No solution is perfect but we need to decide.
> 
> Thanks,
> 
> Ori.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From gjansen at redhat.com  Mon Apr 16 12:42:28 2012
From: gjansen at redhat.com (Geert Jansen)
Date: Mon, 16 Apr 2012 14:42:28 +0200
Subject: [Engine-devel] Floating Disks implementation in REST-API
In-Reply-To: <19cb9b3b-da35-4f51-8531-2ad4c30424fa@zmail07.collab.prod.int.phx2.redhat.com>
References: <19cb9b3b-da35-4f51-8531-2ad4c30424fa@zmail07.collab.prod.int.phx2.redhat.com>
Message-ID: <4F8C13B4.8050908@redhat.com>


On 04/16/2012 02:39 PM, Andrew Cathrow wrote:

> Is there a 3rd option based on #1 where we just detach the disk rather than detaching and deleting?
> That could be further extended by adding an optional delete flag

This was discussed and the problem with that is that it's not backwards 
compatible. Current clients and ISV software expects to be able to 
DELETE a disk, and after that it expects that the disk is gone. If we 
change behavior so that DELETE becomes detach by default, then old 
clients when they DELETE without any flags will instead create a 
floating disk.

Regards,
Geert


From gjansen at redhat.com  Mon Apr 16 14:37:26 2012
From: gjansen at redhat.com (Geert Jansen)
Date: Mon, 16 Apr 2012 16:37:26 +0200
Subject: [Engine-devel] REST session management
In-Reply-To: <4F8C2E00.9010304@redhat.com>
References: <590d66ad-7eee-4637-8303-d4685fb13f4d@zmail02.collab.prod.int.phx2.redhat.com>
	<4F8BFC7E.3050904@redhat.com> <4F8C112F.1060703@redhat.com>
	<4F8C2E00.9010304@redhat.com>
Message-ID: <4F8C2EA6.8070104@redhat.com>


On 04/16/2012 04:34 PM, Yaniv Kaul wrote:

>> The alternative to HTTP Prefer would be creating a new header (as i am
>> not aware of any other /approved/ header that fits the bill). This
>> requires writing an RFC and get it approved, which would take much
>> longer, and which would likely get the comment of "Why aren't you
>> using Prefer".
>
> I'm more worried about "persistent-auth" than 'prefer'. We could always
> contact the draft author (jasnell at gmail.com) and ask for his opinion.

I can do this.

Regards,
Geert


From ykaul at redhat.com  Mon Apr 16 14:34:40 2012
From: ykaul at redhat.com (Yaniv Kaul)
Date: Mon, 16 Apr 2012 17:34:40 +0300
Subject: [Engine-devel] REST session management
In-Reply-To: <4F8C112F.1060703@redhat.com>
References: <590d66ad-7eee-4637-8303-d4685fb13f4d@zmail02.collab.prod.int.phx2.redhat.com>
	<4F8BFC7E.3050904@redhat.com> <4F8C112F.1060703@redhat.com>
Message-ID: <4F8C2E00.9010304@redhat.com>

On 04/16/2012 03:31 PM, Geert Jansen wrote:
>
> On 04/16/2012 01:03 PM, Yaniv Kaul wrote:
>
>>> So (unless someone objects) let's go for option #2 (using the Prefer
>>> header on each and every request, and release the session once it is
>>> not there).
>>
>> My only objection is that you implement a draft spec and implement a
>> header without even bothering to register it - or asking if there is
>> such an identical-purposed header with a different name which may get
>> registered / is already in use somewhere.
>
> This is somewhat of a red herring though.
>
> HTTP Prefer was created exactly for the purpose of indicating a 
> preference for a certain behavior of response. Have a look at section 
> 9.1.1 of the draft RFC for the initial preferences and you'll see the 
> preferences that are already registered.
>
> HTTP Prefer also defines a registration process for the possible 
> values of this header. The process requires an email to 
> preferences at ietf.org with a 14 day response time.
>
> The alternative to HTTP Prefer would be creating a new header (as i am 
> not aware of any other /approved/ header that fits the bill). This 
> requires writing an RFC and get it approved, which would take much 
> longer, and which would likely get the comment of "Why aren't you 
> using Prefer".

I'm more worried about "persistent-auth" than 'prefer'.  We could always 
contact the draft author (jasnell at gmail.com) and ask for his opinion.
Y.

>
> Even if HTTP Prefer, for whatever reason, unexpectedly does not become 
> a standard, i think in practice this does not impact us in any way.
>
> Regards
> Geert

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

From lpeer at redhat.com  Mon Apr 16 16:18:49 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Mon, 16 Apr 2012 19:18:49 +0300
Subject: [Engine-devel] [Users] Hey everyone how do we upgrade engine?
In-Reply-To: <4F885B59.3040709@redhat.com>
References: <CAOZfw6td5XZF5Y3V9KxZa+_qy_P=nY=DmiNo8mEy9NGnJ=NkAA@mail.gmail.com>
	<4F885B59.3040709@redhat.com>
Message-ID: <4F8C4669.6030108@redhat.com>

On 13/04/12 19:59, Itamar Heim wrote:
> On 04/13/2012 06:42 PM, Dominic Kaiser wrote:
>> I am running 3.0.0_0001-1.6.fc16 ovirt engine and has been great!  I
>> appreciate Red Hat and all the support from the community on this
>> project you all are awesome!
>>
>> I have not thought about it yet but was looking on the wiki and did not
>> see how to upgrade and reninstallengine.  What have been your
>> experiences doing this and is it worth it?  And how to do it?  Sorry if
>> it was posted somewhere else just let me know if there is info on this
>> already.
> 
> by running the engine-upgrade utility, though i suspect it will have to
> pass some testing/bug fixes for the second release before can be used
> (doing a test upgrade at that phase on your environment would help
> finding issues)
> 

We have one issue that we know of and we'll fix soon -
https://bugzilla.redhat.com/show_bug.cgi?id=790303

If you are interested you can track engine-devel at ovirt.org list for
updates on this in the upcoming week (or keep track of the bug status).

Livnat

>>
>> I have had the greatest experience moving from 2 esxiservers to ovirt.
>>   You guys and gals rock!
> thanks - nice to hear.
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users



From sanjal at redhat.com  Tue Apr 17 08:59:06 2012
From: sanjal at redhat.com (Shireesh Anjal)
Date: Tue, 17 Apr 2012 14:29:06 +0530
Subject: [Engine-devel] Query regarding ValidationUtils#validateInputs
In-Reply-To: <4F8A643C.8060605@redhat.com>
References: <15a5329c-4579-4ef6-b1c8-be0b260e859b@zmail07.collab.prod.int.phx2.redhat.com>
	<4F8A643C.8060605@redhat.com>
Message-ID: <4F8D30DA.8000609@redhat.com>

On Sunday 15 April 2012 11:31 AM, Roy Golan wrote:
> On 04/12/2012 10:50 AM, Omer Frenkel wrote:
>>
>>
>> ------------------------------------------------------------------------
>>
>>     *From: *"Shireesh Anjal" <sanjal at redhat.com>
>>     *To: *engine-devel at ovirt.org
>>     *Sent: *Thursday, April 12, 2012 9:35:25 AM
>>     *Subject: *[Engine-devel] Query regarding
>>     ValidationUtils#validateInputs
>>
>>     Hi,
>>
>>     This is regarding the following validation method we have in
>>     ValidationUtils:
>>
>>     /public static <T extends VdcActionParametersBase>
>>     ArrayList<String> validateInputs(List<Class<?>>
>>     validationGroupList, T parameters);/
>>
>>     I there any particular reason for supporting the validations only
>>     on objects of classes derived from VdcActionParametersBase? I
>>     guess this was done because this method is primarily intended to
>>     validate the action parameters passed to a BLL action, using the
>>     validation annotations on the parameter class. However I think
>>     this method can be useful for general use as well. e.g. I cannot
>>     add a "@Valid" annotation on a "list" or a "map" in a parameter
>>     class. So I need to iterate over the list/map, and validate each
>>     element inside the loop. The validation inside the loop can also
>>     utilize the above method if the restriction "extends
>>     VdcActionParametersBase" is removed. This will allow me to do the
>>     following in the canDoAction method:
>>
>>     protected boolean canDoAction() {
>>     ...
>>         for(GlusterBrickEntity brick :
>>     getParameters().getGlusterVolume().getBricks()) {
>>             List<String> errors =
>>     ValidationUtils.validateInputs(getValidationGroups(), brick);
>>             if(errors != null) {
>>                 for(String error : errors) {
>>                     addCanDoActionMessage(error);
>>                 }
>>             }
>>         }
>>     ...
>>     }
>>
>>     Regards,
>>     Shireesh
>>
>>     _______________________________________________
>>     Engine-devel mailing list
>>     Engine-devel at ovirt.org
>>     http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>> i don't think there is a reason to restrict only for 
>> VdcActionParametersBase, roy what do you think?
>>
>> also you can use here
>> getReturnValue().getCanDoActionMessages().addAll(errors);
>> instead of going over on all errors.
>
> pls see SetupNetworksParameters.java for validating a list of network 
> interfaces.
>
> hibernate validator supports trivial object graphs and members that 
> are arrays, list and java.util.map implementations.
> If your code looks like that it should work. If you are using special 
> validation groups please add them to your command with 
> addValidationGroups.
>
> this should work:
>
> GlusterCommandParameters.java
>  @Valid
>  List<Bricks> bricks
>
>  Bricks.java
>  @NotNull
>  Guid id

Thanks! I had tried adding @Valid annotation as suggested above, which 
had resulted in an exception from the validation engine, without any 
specific information about the problem, and I assumed that @Valid may 
not work on Lists. Digged deeper after reading your response, and found 
that the @Valid annotation resulted in a call to equals method on the 
entity, which had a bug, resulting in the exception. It all works well 
after fixing the bug.

>
>
> _______________________________________________
> 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/20120417/76f283d2/attachment.html>

From sanjal at redhat.com  Tue Apr 17 10:08:25 2012
From: sanjal at redhat.com (Shireesh Anjal)
Date: Tue, 17 Apr 2012 15:38:25 +0530
Subject: [Engine-devel] Storage Device Management in VDSM and oVirt
Message-ID: <4F8D4119.80901@redhat.com>

Hi all,

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

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

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

Comments / inputs welcome.

Thanks,
Shireesh


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

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

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

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

From oliel at redhat.com  Tue Apr 17 12:27:09 2012
From: oliel at redhat.com (Ori Liel)
Date: Tue, 17 Apr 2012 08:27:09 -0400 (EDT)
Subject: [Engine-devel] Floating Disks implementation in REST-API
In-Reply-To: <4F8C12C9.30300@redhat.com>
Message-ID: <7a869b4a-9a50-43c0-9c48-84c2f6667e8e@zmail17.collab.prod.int.phx2.redhat.com>

>
>
>On 04/16/2012 02:33 PM, Ori Liel wrote:
>> I'd like us to move forward with this.
>>
>> The option of using 'attach' action does not exist, because, as Eoghan observed, we would be executing an action on an entity which doesn't exist in the collection: (.../api/vms/{vm:id}/disks/???-no entity-???/attach)
>>
>> There are two options left on the table; let's see if we can agree on one of them:
>>
>> 1)
>>          POST/api/vms/{vm:id}/disks
>>          <disk id="{disk:id}"/>                                =>   attach disk
>>
>>          DELETE .../api/vms/{vm:id}/disks/{disk:id}
>>          <disk><detach>true</detach><disk>                     =>   detach disk
>>
>> Pros: symmetrical
>> Cons: risky (if user wants to detach but forgot to give parameter, disk will be deleted).
>
>My idea for that was to introduce <force>true|false</force> as well.
>Without force=true, we won't delete a disk if it's currently floating.
>

If the disk is floating it will only appear in root collection (...api/disks), and DELETE from 
there is non-ambiguous, as there's no option to detach - so I don't see how adding 'force' there 
helps us. 

In your previous mail you suggested the same thing for attached floating disk, so perhaps you meant
that here as well? (sorry for only responding now, by the way). But that does break API - for example, 
a simple script deleting all disks from a VM would fail because suddenly deleting requires 'force=true'. 


>I think it makes it less risky. And it is still backwards compatible, as
>3.0 clients do not know how to create a floating disk, and therefore
>there is no risk that they are deleting one.
>
>Regards,
>Geert
>
>
>>
>> 2)
>>
>>          POST/api/vms/{vm:id}/disks
>>          <disk id="{disk:id}"/>                                =>   attach disk
>>
>>          DELETE .../api/vms/{vm:id}/disks/{disk:id}/detach    =>   detach disk
>>
>> Pros: not dangerous
>> Cons: asymmetrical, attach done like add, but detach done using action.
>>
>>
>> No solution is perfect but we need to decide.
>>
>> Thanks,
>>
>> Ori.
>
>-- 
>Geert Jansen
>Sr. Product Marketing Manager, Red Hat Enterprise Virtualization
>
>Red Hat S.r.L.           O: +39 095 916287
>Via G. Fara 26           C: +39 348 1980079 (when in US: 415-623-0542)
>Milan 20124, Italy       E: gjansen at redhat.com


From gjansen at redhat.com  Tue Apr 17 12:50:17 2012
From: gjansen at redhat.com (Geert Jansen)
Date: Tue, 17 Apr 2012 14:50:17 +0200
Subject: [Engine-devel] Floating Disks implementation in REST-API
In-Reply-To: <7a869b4a-9a50-43c0-9c48-84c2f6667e8e@zmail17.collab.prod.int.phx2.redhat.com>
References: <7a869b4a-9a50-43c0-9c48-84c2f6667e8e@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <4F8D6709.1050007@redhat.com>


On 04/17/2012 02:27 PM, Ori Liel wrote:

>> My idea for that was to introduce<force>true|false</force>  as well.
>> Without force=true, we won't delete a disk if it's currently floating.
>>
>
> If the disk is floating it will only appear in root collection (...api/disks), and DELETE from
> there is non-ambiguous, as there's no option to detach - so I don't see how adding 'force' there
> helps us.

Floating disks should be both in the root context, and also in the VM 
context for each VM the floating disk is attached to, right? So floating 
disks would appear 1+N_attach times in the API, once in the root 
context, and once for each VM they are attached to.

Regarding the root context: you are right that DELETE in the root 
context is unambiguous, and therefore we don't need "detach" or "force" 
arguments there. And because in 3.0 we didn't have a disk collection in 
the root context, backwards compatibility isn't an issue here.

> In your previous mail you suggested the same thing for attached floating disk, so perhaps you meant
> that here as well? (sorry for only responding now, by the way). But that does break API - for example,
> a simple script deleting all disks from a VM would fail because suddenly deleting requires 'force=true'.

A 3.0 client does not know how to create a floating disk. So in my view, 
it does not need to know how to delete one.

Is your concern about the case where a 3.1 client creates a floating 
disk, and you would like a 3.0 client to be able to delete that. I think 
this is a too strong interpretation of backwards compatibility. So far 
all ISV software that integrates with us and does provisioning of VMs, 
both creates and deletes VMs. And properly written software will issue 
an error message when a disk DELETE fails. In the end there could be 
many other reasons why a disk DELETE can fail, right? We are adding one 
more reason a disk DELETE will fail, namely that the disk is floating.

Regards,
Geert


From oliel at redhat.com  Tue Apr 17 13:00:54 2012
From: oliel at redhat.com (Ori Liel)
Date: Tue, 17 Apr 2012 09:00:54 -0400 (EDT)
Subject: [Engine-devel] Floating Disks implementation in REST-API
In-Reply-To: <4F8D6709.1050007@redhat.com>
Message-ID: <4f5d6f2a-00d8-4b35-bb1f-76d5ea7910d4@zmail17.collab.prod.int.phx2.redhat.com>

>
>On 04/17/2012 02:27 PM, Ori Liel wrote:
>
>>> My idea for that was to introduce<force>true|false</force>  as well.
>>> Without force=true, we won't delete a disk if it's currently floating.
>>>
>>
>> If the disk is floating it will only appear in root collection (...api/disks), and DELETE from
>> there is non-ambiguous, as there's no option to detach - so I don't see how adding 'force' there
>> helps us.
>
>Floating disks should be both in the root context, and also in the VM
>context for each VM the floating disk is attached to, right? So floating
>disks would appear 1+N_attach times in the API, once in the root
>context, and once for each VM they are attached to.
>

IIUC a floating disk is not associated with the VM in any way, and should
not appear in that VM's collection of disks. There's a similar feature of 
activate/deactivate disk (http://www.ovirt.org/wiki/Features/HotPlug). 
A deactivated disk is still associated with the VM, and should appear in 
the VM's collection of disks. Perhaps this is the source of confusion. 

>Regarding the root context: you are right that DELETE in the root
>context is unambiguous, and therefore we don't need "detach" or "force"
>arguments there. And because in 3.0 we didn't have a disk collection in
>the root context, backwards compatibility isn't an issue here.
>

correct, root context is not a problem 

>> In your previous mail you suggested the same thing for attached floating disk, so perhaps you meant
>> that here as well? (sorry for only responding now, by the way). But that does break API - for example,
>> a simple script deleting all disks from a VM would fail because suddenly deleting requires 'force=true'.
>
>A 3.0 client does not know how to create a floating disk. So in my view,
>it does not need to know how to delete one.
>
>Is your concern about the case where a 3.1 client creates a floating
>disk, and you would like a 3.0 client to be able to delete that. I think
>this is a too strong interpretation of backwards compatibility. So far
>all ISV software that integrates with us and does provisioning of VMs,
>both creates and deletes VMs. And properly written software will issue
>an error message when a disk DELETE fails. In the end there could be
>many other reasons why a disk DELETE can fail, right? We are adding one
>more reason a disk DELETE will fail, namely that the disk is floating.
>
>Regards,
>Geert


From emesika at redhat.com  Tue Apr 17 13:02:13 2012
From: emesika at redhat.com (Eli Mesika)
Date: Tue, 17 Apr 2012 09:02:13 -0400 (EDT)
Subject: [Engine-devel] Postgres DB Upgrade Procedure wiki
In-Reply-To: <2b8119b8-e398-4a5f-9c8b-ba1599d4cb88@zmail13.collab.prod.int.phx2.redhat.com>
Message-ID: <b06f15d8-c8c0-4926-9d1c-47e8cc767303@zmail13.collab.prod.int.phx2.redhat.com>

Hi guys

This is an updated version of our Postgres DB Upgrade Procedure. Most of it is not new and main changes are in the new "Configuration changes" section

Please review and comment, we need this applied upstream ASAP

http://www.ovirt.org/wiki/Postgres-database-upgrade-procedure



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

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

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

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


From gjansen at redhat.com  Tue Apr 17 13:30:43 2012
From: gjansen at redhat.com (Geert Jansen)
Date: Tue, 17 Apr 2012 15:30:43 +0200
Subject: [Engine-devel] Floating Disks implementation in REST-API
In-Reply-To: <4f5d6f2a-00d8-4b35-bb1f-76d5ea7910d4@zmail17.collab.prod.int.phx2.redhat.com>
References: <4f5d6f2a-00d8-4b35-bb1f-76d5ea7910d4@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <4F8D7083.7080306@redhat.com>


>> Floating disks should be both in the root context, and also in the VM
>> context for each VM the floating disk is attached to, right? So floating
>> disks would appear 1+N_attach times in the API, once in the root
>> context, and once for each VM they are attached to.
>>
>
> IIUC a floating disk is not associated with the VM in any way, and should
> not appear in that VM's collection of disks. There's a similar feature of
> activate/deactivate disk (http://www.ovirt.org/wiki/Features/HotPlug).
> A deactivated disk is still associated with the VM, and should appear in
> the VM's collection of disks. Perhaps this is the source of confusion.

No that isn't it. I think have a bit of terminology mismatch. According to:

http://www.ovirt.org/wiki/Features/DetailedFloatingDisk

i think your use of the word floating is correct. I got confused as i 
thought that any disk could be floating, whether it was attached to 0 
VMs, 1 VM, or 2 or more VMs.

So before we go further, let's get things straight:

  - disk without any VMs => floating. It appears in the root context.
  - disk attached to 1 VM => normal state. It appears in the VM context.
  - disk attached to 2 VMs => shared disk. It appears in both VM contexts.

Is that correct?

Also can someone explain on how floating and shared disks are actually 
implemented in the BE? I imagine it's one of two ways:

  => The BE keep a global list of disks, each disk with zero or more 
references to a VM.
  => The BE keeps a special "floating" state independent of the number 
of VMs that it is attached to.

Thanks,
Geert


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

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

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

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

Mike

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




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

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

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

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



From oliel at redhat.com  Tue Apr 17 14:26:02 2012
From: oliel at redhat.com (Ori Liel)
Date: Tue, 17 Apr 2012 10:26:02 -0400 (EDT)
Subject: [Engine-devel] Floating Disks implementation in REST-API
In-Reply-To: <4F8D7083.7080306@redhat.com>
Message-ID: <2e740fda-a19f-4467-b2a0-a971092214b1@zmail17.collab.prod.int.phx2.redhat.com>

>
>>> Floating disks should be both in the root context, and also in the VM
>>> context for each VM the floating disk is attached to, right? So floating
>>> disks would appear 1+N_attach times in the API, once in the root
>>> context, and once for each VM they are attached to.
>>>
>>
>> IIUC a floating disk is not associated with the VM in any way, and should
>> not appear in that VM's collection of disks. There's a similar feature of
>> activate/deactivate disk (http://www.ovirt.org/wiki/Features/HotPlug).
>> A deactivated disk is still associated with the VM, and should appear in
>> the VM's collection of disks. Perhaps this is the source of confusion.
>
>No that isn't it. I think have a bit of terminology mismatch. According to:
>
>http://www.ovirt.org/wiki/Features/DetailedFloatingDisk
>
>i think your use of the word floating is correct. I got confused as i
>thought that any disk could be floating, whether it was attached to 0
>VMs, 1 VM, or 2 or more VMs.
>
>So before we go further, let's get things straight:
>
>  - disk without any VMs => floating. It appears in the root context.
>  - disk attached to 1 VM => normal state. It appears in the VM context.

I think this type of disk should be shown in both contexts. 

If a user is looking at http://{host:port}/disks, I think he intuitively 
expects to see all disks (attached or unattached). A disk will contain 
reference to the VMs which it is attached to, and thus:

- No VM-ids          -->    floating disk. 
- One VM-id          -->    regular disk.
- Multiple VM-ids    -->    shared disk. 

>  - disk attached to 2 VMs => shared disk. It appears in both VM contexts.
>
>Is that correct?
>
>Also can someone explain on how floating and shared disks are actually
>implemented in the BE? I imagine it's one of two ways:
>
>  => The BE keep a global list of disks, each disk with zero or more
>references to a VM.
>  => The BE keeps a special "floating" state independent of the number
>of VMs that it is attached to.
>
>Thanks,
>Geert


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

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

+1


From iheim at redhat.com  Tue Apr 17 14:32:49 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 17 Apr 2012 17:32:49 +0300
Subject: [Engine-devel] Floating Disks implementation in REST-API
In-Reply-To: <2e740fda-a19f-4467-b2a0-a971092214b1@zmail17.collab.prod.int.phx2.redhat.com>
References: <2e740fda-a19f-4467-b2a0-a971092214b1@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <4F8D7F11.8060900@redhat.com>

On 04/17/2012 05:26 PM, Ori Liel wrote:
>>
>>>> Floating disks should be both in the root context, and also in the VM
>>>> context for each VM the floating disk is attached to, right? So floating
>>>> disks would appear 1+N_attach times in the API, once in the root
>>>> context, and once for each VM they are attached to.
>>>>
>>>
>>> IIUC a floating disk is not associated with the VM in any way, and should
>>> not appear in that VM's collection of disks. There's a similar feature of
>>> activate/deactivate disk (http://www.ovirt.org/wiki/Features/HotPlug).
>>> A deactivated disk is still associated with the VM, and should appear in
>>> the VM's collection of disks. Perhaps this is the source of confusion.
>>
>> No that isn't it. I think have a bit of terminology mismatch. According to:
>>
>> http://www.ovirt.org/wiki/Features/DetailedFloatingDisk
>>
>> i think your use of the word floating is correct. I got confused as i
>> thought that any disk could be floating, whether it was attached to 0
>> VMs, 1 VM, or 2 or more VMs.
>>
>> So before we go further, let's get things straight:
>>
>>   - disk without any VMs =>  floating. It appears in the root context.
>>   - disk attached to 1 VM =>  normal state. It appears in the VM context.
>
> I think this type of disk should be shown in both contexts.
>
> If a user is looking at http://{host:port}/disks, I think he intuitively
> expects to see all disks (attached or unattached). A disk will contain
> reference to the VMs which it is attached to, and thus:
>
> - No VM-ids          -->     floating disk.
> - One VM-id          -->     regular disk.
> - Multiple VM-ids    -->     shared disk.

iirc, shared disk is a flag on the disk to allow it to be shared. 
doesn't mean it is shared yet, rather can be shared.

>
>>   - disk attached to 2 VMs =>  shared disk. It appears in both VM contexts.
>>
>> Is that correct?
>>
>> Also can someone explain on how floating and shared disks are actually
>> implemented in the BE? I imagine it's one of two ways:
>>
>>   =>  The BE keep a global list of disks, each disk with zero or more
>> references to a VM.
>>   =>  The BE keeps a special "floating" state independent of the number
>> of VMs that it is attached to.
>>
>> Thanks,
>> Geert
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From oliel at redhat.com  Tue Apr 17 14:53:07 2012
From: oliel at redhat.com (Ori Liel)
Date: Tue, 17 Apr 2012 10:53:07 -0400 (EDT)
Subject: [Engine-devel] Floating Disks implementation in REST-API
In-Reply-To: <4F8D7F11.8060900@redhat.com>
Message-ID: <e526cdc0-b391-49cd-9c4b-941b2f6b6574@zmail17.collab.prod.int.phx2.redhat.com>

>On 04/17/2012 05:26 PM, Ori Liel wrote:
>>>
>>>>> Floating disks should be both in the root context, and also in the VM
>>>>> context for each VM the floating disk is attached to, right? So floating
>>>>> disks would appear 1+N_attach times in the API, once in the root
>>>>> context, and once for each VM they are attached to.
>>>>>
>>>>
>>>> IIUC a floating disk is not associated with the VM in any way, and should
>>>> not appear in that VM's collection of disks. There's a similar feature of
>>>> activate/deactivate disk (http://www.ovirt.org/wiki/Features/HotPlug).
>>>> A deactivated disk is still associated with the VM, and should appear in
>>>> the VM's collection of disks. Perhaps this is the source of confusion.
>>>
>>> No that isn't it. I think have a bit of terminology mismatch. According to:
>>>
>>> http://www.ovirt.org/wiki/Features/DetailedFloatingDisk
>>>
>>> i think your use of the word floating is correct. I got confused as i
>>> thought that any disk could be floating, whether it was attached to 0
>>> VMs, 1 VM, or 2 or more VMs.
>>>
>>> So before we go further, let's get things straight:
>>>
>>>   - disk without any VMs =>  floating. It appears in the root context.
>>>   - disk attached to 1 VM =>  normal state. It appears in the VM context.
>>
>> I think this type of disk should be shown in both contexts.
>>
>> If a user is looking at http://{hostort}/disks, I think he intuitively
>> expects to see all disks (attached or unattached). A disk will contain
>> reference to the VMs which it is attached to, and thus:
>>
>> - No VM-ids          -->     floating disk.
>> - One VM-id          -->     regular disk.
>> - Multiple VM-ids    -->     shared disk.
>
>iirc, shared disk is a flag on the disk to allow it to be shared.
>doesn't mean it is shared yet, rather can be shared.

Right, but there's no contradiction: a disk can have 'shared' flag and 
also show the list of VMs it's attached to. The flag tells you if the
disk has the ability to be shared, while the list of VMs tells you which 
VMs are actually sharing the disk right now (if any at all)

>
>>
>>>   - disk attached to 2 VMs =>  shared disk. It appears in both VM contexts.
>>>
>>> Is that correct?
>>>
>>> Also can someone explain on how floating and shared disks are actually
>>> implemented in the BE? I imagine it's one of two ways:
>>>
>>>   =>  The BE keep a global list of disks, each disk with zero or more
>>> references to a VM.
>>>   =>  The BE keeps a special "floating" state independent of the number
>>> of VMs that it is attached to.
>>>
>>> Thanks,
>>> Geert
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>


From gjansen at redhat.com  Tue Apr 17 14:56:56 2012
From: gjansen at redhat.com (Geert Jansen)
Date: Tue, 17 Apr 2012 16:56:56 +0200
Subject: [Engine-devel] Floating Disks implementation in REST-API
In-Reply-To: <e526cdc0-b391-49cd-9c4b-941b2f6b6574@zmail17.collab.prod.int.phx2.redhat.com>
References: <e526cdc0-b391-49cd-9c4b-941b2f6b6574@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <4F8D84B8.5000406@redhat.com>


On 04/17/2012 04:53 PM, Ori Liel wrote:

>> iirc, shared disk is a flag on the disk to allow it to be shared.
>> doesn't mean it is shared yet, rather can be shared.
>
> Right, but there's no contradiction: a disk can have 'shared' flag and
> also show the list of VMs it's attached to. The flag tells you if the
> disk has the ability to be shared, while the list of VMs tells you which
> VMs are actually sharing the disk right now (if any at all)

If we can expose the "shared" flag though, i think the API gets more 
natural. We can then only show the shared disks in the root context.

Itamar, can we expose this flag, or do you consider this flag is 
internal to the BE?

Regards,


From iheim at redhat.com  Tue Apr 17 15:54:04 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 17 Apr 2012 18:54:04 +0300
Subject: [Engine-devel] Floating Disks implementation in REST-API
In-Reply-To: <4F8D84B8.5000406@redhat.com>
References: <e526cdc0-b391-49cd-9c4b-941b2f6b6574@zmail17.collab.prod.int.phx2.redhat.com>
	<4F8D84B8.5000406@redhat.com>
Message-ID: <4F8D921C.10702@redhat.com>

On 04/17/2012 05:56 PM, Geert Jansen wrote:
>
> On 04/17/2012 04:53 PM, Ori Liel wrote:
>
>>> iirc, shared disk is a flag on the disk to allow it to be shared.
>>> doesn't mean it is shared yet, rather can be shared.
>>
>> Right, but there's no contradiction: a disk can have 'shared' flag and
>> also show the list of VMs it's attached to. The flag tells you if the
>> disk has the ability to be shared, while the list of VMs tells you which
>> VMs are actually sharing the disk right now (if any at all)
>
> If we can expose the "shared" flag though, i think the API gets more
> natural. We can then only show the shared disks in the root context.
>
> Itamar, can we expose this flag, or do you consider this flag is
> internal to the BE?

we have to expose this flag for shared disk functionality. this is the 
only way via ui/api to flag the disk as shared (which only then allows 
attaching it to more than a single vm - this is explicit to avoid disk 
corruptions)


From gjansen at redhat.com  Tue Apr 17 16:31:18 2012
From: gjansen at redhat.com (Geert Jansen)
Date: Tue, 17 Apr 2012 18:31:18 +0200
Subject: [Engine-devel] Floating Disks implementation in REST-API
In-Reply-To: <4F8D921C.10702@redhat.com>
References: <e526cdc0-b391-49cd-9c4b-941b2f6b6574@zmail17.collab.prod.int.phx2.redhat.com>
	<4F8D84B8.5000406@redhat.com> <4F8D921C.10702@redhat.com>
Message-ID: <4F8D9AD6.6010602@redhat.com>


On 04/17/2012 05:54 PM, Itamar Heim wrote:

>> If we can expose the "shared" flag though, i think the API gets more
>> natural. We can then only show the shared disks in the root context.
>>
>> Itamar, can we expose this flag, or do you consider this flag is
>> internal to the BE?
>
> we have to expose this flag for shared disk functionality. this is the
> only way via ui/api to flag the disk as shared (which only then allows
> attaching it to more than a single vm - this is explicit to avoid disk
> corruptions)

OK, understood.

Which then begs the question - why we are trying to make the setting / 
unsetting of this flag implicit via the various POST and DELETE calls we 
were trying to model.

Maybe we ought to just allow a user to set the shared flag:

  PUT /api/vms/{vm:id}/disks/{disk:id}
  <disk>
   <shared>true|false</shared>
  </disk>

When a disk is shared:

  - The disks shows up in the root context /api/disks.
  - You can POST this disk to another VM, making it available to that VM.
  - Detach it from a VM using DELETE.

To delete a shared disk, you need to either:

  - Unshare it first. Then DELETE.
  - DELETE it from the root context.

Regards,
Geert


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

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

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

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

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

---
Ofer Schreiber
oVirt Release Manager


From lhornyak at redhat.com  Wed Apr 18 08:13:37 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Wed, 18 Apr 2012 04:13:37 -0400 (EDT)
Subject: [Engine-devel] java enum syntax trick
In-Reply-To: <ec5110a3-a383-4169-b91e-c1577f0c59d8@zmail01.collab.prod.int.phx2.redhat.com>
Message-ID: <11613aca-aa99-4171-aaab-e71daddbca65@zmail01.collab.prod.int.phx2.redhat.com>

Hi,

In java enums, you can leave a coma before the semicolon closing the names in the enum. e.g.

enum Foo {
 bar,
 baz, // <!-- last, still with a coma
 ; //and there is no more
}

I don't know if this fits in the code formating requirements, but maybe it could help us to waste less time on merging because you did not have to change the last line to add some more.

Laszlo


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

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

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

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

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

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

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

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

Regards,
Dan.


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

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

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

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

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

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

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

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

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

Regards,
Dan.


From gchaplik at redhat.com  Wed Apr 18 08:49:12 2012
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Wed, 18 Apr 2012 04:49:12 -0400 (EDT)
Subject: [Engine-devel] java enum syntax trick
In-Reply-To: <11613aca-aa99-4171-aaab-e71daddbca65@zmail01.collab.prod.int.phx2.redhat.com>
Message-ID: <1452f064-5ee2-420e-92fe-db5bf81fdadf@zmail14.collab.prod.int.phx2.redhat.com>

Great suggestion :) even gwt supports it
from now on, I will add it when changing an enum (and ask it when I'm reviewing).

Thanks, 
Gilad.

----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, April 18, 2012 11:13:37 AM
> Subject: [Engine-devel] java enum syntax trick
> 
> Hi,
> 
> In java enums, you can leave a coma before the semicolon closing the
> names in the enum. e.g.
> 
> enum Foo {
>  bar,
>  baz, // <!-- last, still with a coma
>  ; //and there is no more
> }
> 
> I don't know if this fits in the code formating requirements, but
> maybe it could help us to waste less time on merging because you did
> not have to change the last line to add some more.
> 
> Laszlo
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


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

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

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

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



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



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

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

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

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

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

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


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

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

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

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

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

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

Juan, thank you for the detailed answer.

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


Thanks, Livnat



From ecohen at redhat.com  Wed Apr 18 10:36:52 2012
From: ecohen at redhat.com (Einav Cohen)
Date: Wed, 18 Apr 2012 06:36:52 -0400 (EDT)
Subject: [Engine-devel] Floating Disks implementation in REST-API
In-Reply-To: <861e9232-ff09-47ba-8c69-3ed0013e6961@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <517ec83a-0c95-43d7-a320-26c45817ea9a@zmail04.collab.prod.int.phx2.redhat.com>

[Top Posting]

Let's try to concentrate on the subject of this thread (we can discuss shared disks in a separate thread):

- I agree with Ori: Disks root collection should have all disks, not only floating (shared?) disks. Disk is an important business entity, which "deserves" a full root collection of its own - I think it is more aligned with the existing api structure (VMs are shown both in the VMs root collection as well as under their Cluster/DC).

- Regarding possibilities 1 vs. 2 below: I prefer #1 (again - agreeing with Ori, IIRC): Although risky in a sense, at least existing users/scripts won't be harmed because of this, since the behavior is backward compatible. Regarding new users - they should know what they are doing, and they should always be careful when using DELETE, no matter from which context. It also "looks" better (more symmetrical, adding a new POST action is avoided).

Comments?


----- Original Message -----
> From: "Ori Liel" <oliel at redhat.com>
> To: engine-devel at ovirt.org
> Cc: "Eoghan Glynn" <eglynn at redhat.com>
> Sent: Monday, April 16, 2012 3:33:27 PM
> Subject: Re: [Engine-devel] Floating Disks implementation in REST-API
> 
> I'd like us to move forward with this.
> 
> The option of using 'attach' action does not exist, because, as
> Eoghan observed, we would be executing an action on an entity which
> doesn't exist in the collection: (.../api/vms/{vm:id}/disks/???-no
> entity-???/attach)
> 
> There are two options left on the table; let's see if we can agree on
> one of them:
> 
> 1)
>         POST/api/vms/{vm:id}/disks
>         <disk id="{disk:id}"/>                               =>
>          attach disk
> 
>         DELETE .../api/vms/{vm:id}/disks/{disk:id}
>         <disk><detach>true</detach><disk>                    =>
>          detach disk
> 
> Pros: symmetrical
> Cons: risky (if user wants to detach but forgot to give parameter,
> disk will be deleted).
> 
> 2)
> 
>         POST/api/vms/{vm:id}/disks
>         <disk id="{disk:id}"/>                               =>
>          attach disk
> 
>         DELETE .../api/vms/{vm:id}/disks/{disk:id}/detach    =>
>          detach disk
> 
> Pros: not dangerous
> Cons: asymmetrical, attach done like add, but detach done using
> action.
> 
> 
> No solution is perfect but we need to decide.
> 
> Thanks,
> 
> Ori.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 
> 


From lpeer at redhat.com  Wed Apr 18 10:38:23 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Wed, 18 Apr 2012 13:38:23 +0300
Subject: [Engine-devel] Floating Disks implementation in REST-API
In-Reply-To: <4F8D9AD6.6010602@redhat.com>
References: <e526cdc0-b391-49cd-9c4b-941b2f6b6574@zmail17.collab.prod.int.phx2.redhat.com>
	<4F8D84B8.5000406@redhat.com> <4F8D921C.10702@redhat.com>
	<4F8D9AD6.6010602@redhat.com>
Message-ID: <4F8E999F.5050907@redhat.com>

On 17/04/12 19:31, Geert Jansen wrote:
> 
> On 04/17/2012 05:54 PM, Itamar Heim wrote:
> 
>>> If we can expose the "shared" flag though, i think the API gets more
>>> natural. We can then only show the shared disks in the root context.
>>>
>>> Itamar, can we expose this flag, or do you consider this flag is
>>> internal to the BE?
>>
>> we have to expose this flag for shared disk functionality. this is the
>> only way via ui/api to flag the disk as shared (which only then allows
>> attaching it to more than a single vm - this is explicit to avoid disk
>> corruptions)
> 
> OK, understood.
> 
> Which then begs the question - why we are trying to make the setting /
> unsetting of this flag implicit via the various POST and DELETE calls we
> were trying to model.
> 
> Maybe we ought to just allow a user to set the shared flag:
> 
>  PUT /api/vms/{vm:id}/disks/{disk:id}
>  <disk>
>   <shared>true|false</shared>
>  </disk>
> 
> When a disk is shared:
> 
>  - The disks shows up in the root context /api/disks.
>  - You can POST this disk to another VM, making it available to that VM.
>  - Detach it from a VM using DELETE.
> 
> To delete a shared disk, you need to either:
> 
>  - Unshare it first. Then DELETE.
>  - DELETE it from the root context.
> 
> Regards,
> Geert

Hi Geert,

UIUC we are trying to model two backend commands:

- attach disk to VM
- detach disk from VM

If the disk property 'shareable' is checked it means the user can attach
the disk to more than one VM, but the question is how the user does that
(regardless if the disk is attached to other VMs or not).

My understanding is that the root disks collections includes all disks
in the setup (floating and attached) and the /api/vms/{vm:id}/disks/
includes all disks attached to the VM (can be disk that is attached to
more than this VM, or only to this VM).

Livnat





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



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

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

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

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

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

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

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

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

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


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

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

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

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


From lpeer at redhat.com  Wed Apr 18 11:09:18 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Wed, 18 Apr 2012 14:09:18 +0300
Subject: [Engine-devel] Floating Disks implementation in REST-API
In-Reply-To: <517ec83a-0c95-43d7-a320-26c45817ea9a@zmail04.collab.prod.int.phx2.redhat.com>
References: <517ec83a-0c95-43d7-a320-26c45817ea9a@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <4F8EA0DE.7040407@redhat.com>

On 18/04/12 13:36, Einav Cohen wrote:
> [Top Posting]
> 
> Let's try to concentrate on the subject of this thread (we can discuss shared disks in a separate thread):
> 
> - I agree with Ori: Disks root collection should have all disks, not only floating (shared?) disks. Disk is an important business entity, which "deserves" a full root collection of its own - I think it is more aligned with the existing api structure (VMs are shown both in the VMs root collection as well as under their Cluster/DC).


+1

> 
> - Regarding possibilities 1 vs. 2 below: I prefer #1 (again - agreeing with Ori, IIRC): Although risky in a sense, at least existing users/scripts won't be harmed because of this, since the behavior is backward compatible. Regarding new users - they should know what they are doing, and they should always be careful when using DELETE, no matter from which context. It also "looks" better (more symmetrical, adding a new POST action is avoided).
> 

I find option one confusing, I prefer #2.

Does anyone have an idea how to model detach and attach as PUT (update)
operation instead of DELETE(remove) and POST(add).

Pros: - we avoid confusing delete disk with detach disk
      - symmetrical (for attach detach)
Cons: - not sure we have this approach in other places in the API
      - is it confusing for the user?


Livnat

> Comments?
> 
> 
> ----- Original Message -----
>> From: "Ori Liel" <oliel at redhat.com>
>> To: engine-devel at ovirt.org
>> Cc: "Eoghan Glynn" <eglynn at redhat.com>
>> Sent: Monday, April 16, 2012 3:33:27 PM
>> Subject: Re: [Engine-devel] Floating Disks implementation in REST-API
>>
>> I'd like us to move forward with this.
>>
>> The option of using 'attach' action does not exist, because, as
>> Eoghan observed, we would be executing an action on an entity which
>> doesn't exist in the collection: (.../api/vms/{vm:id}/disks/???-no
>> entity-???/attach)
>>
>> There are two options left on the table; let's see if we can agree on
>> one of them:
>>
>> 1)
>>         POST/api/vms/{vm:id}/disks
>>         <disk id="{disk:id}"/>                               =>
>>          attach disk
>>
>>         DELETE .../api/vms/{vm:id}/disks/{disk:id}
>>         <disk><detach>true</detach><disk>                    =>
>>          detach disk
>>
>> Pros: symmetrical
>> Cons: risky (if user wants to detach but forgot to give parameter,
>> disk will be deleted).
>>
>> 2)
>>
>>         POST/api/vms/{vm:id}/disks
>>         <disk id="{disk:id}"/>                               =>
>>          attach disk
>>
>>         DELETE .../api/vms/{vm:id}/disks/{disk:id}/detach    =>
>>          detach disk
>>
>> Pros: not dangerous
>> Cons: asymmetrical, attach done like add, but detach done using
>> action.
>>
>>
>> No solution is perfect but we need to decide.
>>
>> Thanks,
>>
>> Ori.
>> _______________________________________________
>> 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 oschreib at redhat.com  Wed Apr 18 11:23:14 2012
From: oschreib at redhat.com (Ofer Schreiber)
Date: Wed, 18 Apr 2012 07:23:14 -0400 (EDT)
Subject: [Engine-devel] ovirt-engine deployment method
In-Reply-To: <4F8E950E.2040901@redhat.com>
Message-ID: <a40fb22a-7150-4a37-a565-61a7d76873f7@zmail14.collab.prod.int.phx2.redhat.com>



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

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


> 
> 
> Thanks, Livnat
> 
> 


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

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

nice :), added some comments myself.

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

Thanks for clarifying it.

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

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


Livnat



From oliel at redhat.com  Wed Apr 18 12:33:15 2012
From: oliel at redhat.com (Ori Liel)
Date: Wed, 18 Apr 2012 08:33:15 -0400 (EDT)
Subject: [Engine-devel] Floating Disks implementation in REST-API
In-Reply-To: <4F8EA0DE.7040407@redhat.com>
Message-ID: <57486588-4d5a-44dc-bb16-5990ebf8243e@zmail17.collab.prod.int.phx2.redhat.com>

>On 18/04/12 13:36, Einav Cohen wrote:
>> [Top Posting]
>>
>> Let's try to concentrate on the subject of this thread (we can discuss shared disks in a separate thread):
>>
>> - I agree with Ori: Disks root collection should have all disks, not only floating (shared?) disks. Disk is an important business entity, which "deserves" a full root collection of its own - I think it is more aligned with the existing api structure (VMs are shown both in the VMs root collection as well as under their Cluster/DC).
>
>
>+1
>
>>
>> - Regarding possibilities 1 vs. 2 below: I prefer #1 (again - agreeing with Ori, IIRC): Although risky in a sense, at least existing users/scripts won't be harmed because of this, since the behavior is backward compatible. Regarding new users - they should know what they are doing, and they should always be careful when using DELETE, no matter from which context. It also "looks" better (more symmetrical, adding a new POST action is avoided).
>>
>
>I find option one confusing, I prefer #2.
>
>Does anyone have an idea how to model detach and attach as PUT (update)
>operation instead of DELETE(remove) and POST(add).
>
>Pros: - we avoid confusing delete disk with detach disk
>      - symmetrical (for attach detach)
>Cons: - not sure we have this approach in other places in the API
>      - is it confusing for the user?
>
>
>Livnat
>

I'll try to describe your suggestion, if I understood it correctly. 

PUT is used for update. We could decide that user achieves attach/detach by an updating 
the entire disks collection: 

  PUT
  .../api/vms/{vm:id}/disks

The user must always pass all disks, and then:
 - If a disk, which is currently not attached to the VM, is passed - attach this disk.
 - if a disk, which is currently attached to the VM, is not passed - detach this disk. 


I'm against for two reasons: 
1) We currently don't have update on collection anywhere else (although technically it's possible)
2) It's quite confusing. Intuitively, the user has no of knowing that updating the collection 
(which he's not used to anyway) will result in attach/detach, and not in create/delete. 

Another possibility of using PUT is on the root collection of disks, 
  PUT
  .../api/disks
Updating the vm-ids of this disk. 

But I don't like this solution as well (opinions?)

If you had in mind a different way of using PUT, please explain it. 

>> Comments?
>>
>>
>> ----- Original Message -----
>>> From: "Ori Liel" <oliel at redhat.com>
>>> To: engine-devel at ovirt.org
>>> Cc: "Eoghan Glynn" <eglynn at redhat.com>
>>> Sent: Monday, April 16, 2012 3:33:27 PM
>>> Subject: Re: [Engine-devel] Floating Disks implementation in REST-API
>>>
>>> I'd like us to move forward with this.
>>>
>>> The option of using 'attach' action does not exist, because, as
>>> Eoghan observed, we would be executing an action on an entity which
>>> doesn't exist in the collection: (.../api/vms/{vm:id}/disks/???-no
>>> entity-???/attach)
>>>
>>> There are two options left on the table; let's see if we can agree on
>>> one of them:
>>>
>>> 1)
>>>         POST/api/vms/{vm:id}/disks
>>>         <disk id="{disk:id}"/>                               =>
>>>          attach disk
>>>
>>>         DELETE .../api/vms/{vm:id}/disks/{disk:id}
>>>         <disk><detach>true</detach><disk>                    =>
>>>          detach disk
>>>
>>> Pros: symmetrical
>>> Cons: risky (if user wants to detach but forgot to give parameter,
>>> disk will be deleted).
>>>
>>> 2)
>>>
>>>         POST/api/vms/{vm:id}/disks
>>>         <disk id="{disk:id}"/>                               =>
>>>          attach disk
>>>
>>>         DELETE .../api/vms/{vm:id}/disks/{disk:id}/detach    =>
>>>          detach disk
>>>
>>> Pros: not dangerous
>>> Cons: asymmetrical, attach done like add, but detach done using
>>> action.
>>>
>>>
>>> No solution is perfect but we need to decide.
>>>
>>> Thanks,
>>>
>>> Ori.
>>> _______________________________________________
>>> 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 Apr 18 12:54:58 2012
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 18 Apr 2012 15:54:58 +0300
Subject: [Engine-devel] Floating Disks implementation in REST-API
In-Reply-To: <517ec83a-0c95-43d7-a320-26c45817ea9a@zmail04.collab.prod.int.phx2.redhat.com>
References: <517ec83a-0c95-43d7-a320-26c45817ea9a@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <4F8EB9A2.4020403@redhat.com>

On 04/18/2012 01:36 PM, Einav Cohen wrote:
> [Top Posting]
>
> Let's try to concentrate on the subject of this thread (we can discuss shared disks in a separate thread):
>
> - I agree with Ori: Disks root collection should have all disks, not only floating (shared?) disks. Disk is an important business entity, which "deserves" a full root collection of its own - I think it is more aligned with the existing api structure (VMs are shown both in the VMs root collection as well as under their Cluster/DC).
>
> - Regarding possibilities 1 vs. 2 below: I prefer #1 (again - agreeing with Ori, IIRC): Although risky in a sense, at least existing users/scripts won't be harmed because of this, since the behavior is backward compatible. Regarding new users - they should know what they are doing, and they should always be careful when using DELETE, no matter from which context. It also "looks" better (more symmetrical, adding a new POST action is avoided).
>
> Comments?

I also like #1. maybe change the parameter name though from detach to 
something that explains the delete will only be from the VM 
("preserve=true", or some better name).

i.e., detach, like delete is "in the same direction" of removing something.
preserve implies this is in the other direction from the delete.

hope this makes sense

>
>
> ----- Original Message -----
>> From: "Ori Liel"<oliel at redhat.com>
>> To: engine-devel at ovirt.org
>> Cc: "Eoghan Glynn"<eglynn at redhat.com>
>> Sent: Monday, April 16, 2012 3:33:27 PM
>> Subject: Re: [Engine-devel] Floating Disks implementation in REST-API
>>
>> I'd like us to move forward with this.
>>
>> The option of using 'attach' action does not exist, because, as
>> Eoghan observed, we would be executing an action on an entity which
>> doesn't exist in the collection: (.../api/vms/{vm:id}/disks/???-no
>> entity-???/attach)
>>
>> There are two options left on the table; let's see if we can agree on
>> one of them:
>>
>> 1)
>>          POST/api/vms/{vm:id}/disks
>>          <disk id="{disk:id}"/>                                =>
>>           attach disk
>>
>>          DELETE .../api/vms/{vm:id}/disks/{disk:id}
>>          <disk><detach>true</detach><disk>                     =>
>>           detach disk
>>
>> Pros: symmetrical
>> Cons: risky (if user wants to detach but forgot to give parameter,
>> disk will be deleted).
>>
>> 2)
>>
>>          POST/api/vms/{vm:id}/disks
>>          <disk id="{disk:id}"/>                                =>
>>           attach disk
>>
>>          DELETE .../api/vms/{vm:id}/disks/{disk:id}/detach    =>
>>           detach disk
>>
>> Pros: not dangerous
>> Cons: asymmetrical, attach done like add, but detach done using
>> action.
>>
>>
>> No solution is perfect but we need to decide.
>>
>> Thanks,
>>
>> Ori.
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>>
>>



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

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

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


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



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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

/d

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


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

Hi!

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

Thank you,
Laszlo

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


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

Hi Laszlo,
Sure.

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

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

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

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

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

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


-- 

/d

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


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

Shireesh Anjal wrote:


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

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

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



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

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

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

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

These three examples are storage domain flavors..

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

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

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

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


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



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

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

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

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

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

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

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

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

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


From oliel at redhat.com  Thu Apr 19 07:57:31 2012
From: oliel at redhat.com (Ori Liel)
Date: Thu, 19 Apr 2012 03:57:31 -0400 (EDT)
Subject: [Engine-devel] Floating Disks implementation in REST-API
In-Reply-To: <4F8EB9A2.4020403@redhat.com>
Message-ID: <e76295f8-e11e-4209-a477-dd76d3dd2643@zmail17.collab.prod.int.phx2.redhat.com>

Current summary: 

There are four options for Floating-Disks modelling: 
two that were previously discussed, and two that were 
recently added by Livnat, using PUT. See full list of 
options below. 

Itamar, Geert, Einav & Ori are currently pro option #1
(if anyone changed his mind - please say so). 
Does anyone strongly prefer another option, or can we
move forward with option #1?

Thanks, 

Ori. 



1)
    POST
    /api/vms/{vm:id}/disks
    <disk id="{disk:id}"/>                      => attach disk

    DELETE
    /api/vms/{vm:id}/disks/{disk:id}
    <disk><detach>true</detach><disk>           => detach disk

2)

    POST
    /api/vms/{vm:id}/disks
    <disk id="{disk:id}"/>                      => attach disk

    DELETE
    /api/vms/{vm:id}/disks/{disk:id}/detach     => detach disk


3)  PUT
    /api/vms/{vm:id}/disks                  
    (update on the disks collection)            => attach + detach

4)  PUT
    /api/disks/{disk:id}
    (update on the vm-id's of disk)             => attach + detach



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

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

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

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

Here are the things to consider here;

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

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

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

/d

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


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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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


From eedri at redhat.com  Thu Apr 19 10:42:33 2012
From: eedri at redhat.com (Eyal Edri)
Date: Thu, 19 Apr 2012 06:42:33 -0400 (EDT)
Subject: [Engine-devel] [Jenkins] ovirt-engine fails due to last commit
In-Reply-To: <64bf0c67-1cab-4b2d-a256-f009f7871905@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <ce958aab-01d8-4c49-a87b-8ff8b5d46a85@zmail17.collab.prod.int.phx2.redhat.com>

commit  b9a6f23be188e2bf4d56f8b548db1b2536372385 - core: Add methods missing from PGHack (detail / gitweb)


Compilation Error:

Waiting for Jenkins to finish collecting data
mavenExecutionResult exceptions not empty
message : Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile) on project dal: Compilation failure
/home/jenkins/workspace/ovirt_engine/backend/manager/modules/dal/src/main/java/org/ovirt/engine/core/dal/dbbroker/PGHack.java:[68,19] cannot find symbol
symbol  : method getParentLogger()
location: interface javax.sql.DataSource

cause : Compilation failure
/home/jenkins/workspace/ovirt_engine/backend/manager/modules/dal/src/main/java/org/ovirt/engine/core/dal/dbbroker/PGHack.java:[68,19] cannot find symbol
symbol  : method getParentLogger()
location: interface javax.sql.DataSource

Stack trace : 
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile) on project dal: Compilation failure
/home/jenkins/workspace/ovirt_engine/backend/manager/modules/dal/src/main/java/org/ovirt/engine/core/dal/dbbroker/PGHack.java:[68,19] cannot find symbol
symbol  : method getParentLogger()
location: interface javax.sql.DataSource

	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
	at org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:616)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
	at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
	at hudson.maven.Maven3Builder.call(Maven3Builder.java:122)
	at hudson.maven.Maven3Builder.call(Maven3Builder.java:74)
	at hudson.remoting.UserRequest.perform(UserRequest.java:118)
	at hudson.remoting.UserRequest.perform(UserRequest.java:48)
	at hudson.remoting.Request$2.run(Request.java:287)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
	at java.lang.Thread.run(Thread.java:679)
Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation failure
/home/jenkins/workspace/ovirt_engine/backend/manager/modules/dal/src/main/java/org/ovirt/engine/core/dal/dbbroker/PGHack.java:[68,19] cannot find symbol
symbol  : method getParentLogger()
location: interface javax.sql.DataSource

	at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:656)
	at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:128)
	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
	... 27 more


From juan.hernandez at redhat.com  Thu Apr 19 10:44:39 2012
From: juan.hernandez at redhat.com (Juan Hernandez)
Date: Thu, 19 Apr 2012 12:44:39 +0200
Subject: [Engine-devel] [Jenkins] ovirt-engine fails due to last commit
In-Reply-To: <ce958aab-01d8-4c49-a87b-8ff8b5d46a85@zmail17.collab.prod.int.phx2.redhat.com>
References: <ce958aab-01d8-4c49-a87b-8ff8b5d46a85@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <4F8FEC97.1060509@redhat.com>

On 04/19/2012 12:42 PM, Eyal Edri wrote:
> commit  b9a6f23be188e2bf4d56f8b548db1b2536372385 - core: Add methods missing from PGHack (detail / gitweb)

That is my fault. I introduced a change for Java 7 that fails in Java 6.
The solution is to partially revert the commit:

http://gerrit.ovirt.org/3714

I apologize for the inconveniences.



From iheim at redhat.com  Thu Apr 19 11:36:23 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 19 Apr 2012 14:36:23 +0300
Subject: [Engine-devel] [Jenkins] ovirt-engine fails due to last commit
In-Reply-To: <4F8FEC97.1060509@redhat.com>
References: <ce958aab-01d8-4c49-a87b-8ff8b5d46a85@zmail17.collab.prod.int.phx2.redhat.com>
	<4F8FEC97.1060509@redhat.com>
Message-ID: <4F8FF8B7.7030906@redhat.com>

On 04/19/2012 01:44 PM, Juan Hernandez wrote:
> On 04/19/2012 12:42 PM, Eyal Edri wrote:
>> commit  b9a6f23be188e2bf4d56f8b548db1b2536372385 - core: Add methods missing from PGHack (detail / gitweb)
>
> That is my fault. I introduced a change for Java 7 that fails in Java 6.
> The solution is to partially revert the commit:
>
> http://gerrit.ovirt.org/3714

is there a way to have the code support both versions till we deprecate 
java 6 support?

>
> I apologize for the inconveniences.
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From juan.hernandez at redhat.com  Thu Apr 19 11:38:38 2012
From: juan.hernandez at redhat.com (Juan Hernandez)
Date: Thu, 19 Apr 2012 13:38:38 +0200
Subject: [Engine-devel] [Jenkins] ovirt-engine fails due to last commit
In-Reply-To: <4F8FF8B7.7030906@redhat.com>
References: <ce958aab-01d8-4c49-a87b-8ff8b5d46a85@zmail17.collab.prod.int.phx2.redhat.com>
	<4F8FEC97.1060509@redhat.com> <4F8FF8B7.7030906@redhat.com>
Message-ID: <4F8FF93E.4090600@redhat.com>

On 04/19/2012 01:36 PM, Itamar Heim wrote:
> On 04/19/2012 01:44 PM, Juan Hernandez wrote:
>> On 04/19/2012 12:42 PM, Eyal Edri wrote:
>>> commit  b9a6f23be188e2bf4d56f8b548db1b2536372385 - core: Add methods missing from PGHack (detail / gitweb)
>>
>> That is my fault. I introduced a change for Java 7 that fails in Java 6.
>> The solution is to partially revert the commit:
>>
>> http://gerrit.ovirt.org/3714
> 
> is there a way to have the code support both versions till we deprecate 
> java 6 support?

Yes, latest change works in Java 6 and Java 7.


From mkolesni at redhat.com  Thu Apr 19 11:56:21 2012
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Thu, 19 Apr 2012 07:56:21 -0400 (EDT)
Subject: [Engine-devel] [Jenkins] ovirt-engine fails due to last commit
In-Reply-To: <4F8FF93E.4090600@redhat.com>
Message-ID: <dc76d211-be88-4e54-b0b8-7bfcd83df216@zmail14.collab.prod.int.phx2.redhat.com>

> On 04/19/2012 01:36 PM, Itamar Heim wrote:
> > On 04/19/2012 01:44 PM, Juan Hernandez wrote:
> >> On 04/19/2012 12:42 PM, Eyal Edri wrote:
> >>> commit  b9a6f23be188e2bf4d56f8b548db1b2536372385 - core: Add
> >>> methods missing from PGHack (detail / gitweb)
> >>
> >> That is my fault. I introduced a change for Java 7 that fails in
> >> Java 6.
> >> The solution is to partially revert the commit:
> >>
> >> http://gerrit.ovirt.org/3714
> > 
> > is there a way to have the code support both versions till we
> > deprecate
> > java 6 support?
> 
> Yes, latest change works in Java 6 and Java 7.

Are we even using this class? I'm pretty sure that we aren't and it's garbage from the "move to postgres" days...
Eli - What do you think?


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

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

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

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

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

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

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

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


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

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

Again talking only about Fedora:

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

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

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

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

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

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

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

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

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

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



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

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

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

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

-- 

/d

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


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

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

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


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

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

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

/d

"Air conditioned environment - Do NOT open Windows!"


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

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

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


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

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


-- 

/d

"All computers wait at the same speed."


From oliel at redhat.com  Thu Apr 19 19:23:14 2012
From: oliel at redhat.com (Ori Liel)
Date: Thu, 19 Apr 2012 15:23:14 -0400 (EDT)
Subject: [Engine-devel] Floating Disks implementation in REST-API
In-Reply-To: <e76295f8-e11e-4209-a477-dd76d3dd2643@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <e298637d-76f1-411d-b470-bb655b42ba7d@zmail17.collab.prod.int.phx2.redhat.com>

In the interest of moving forward, let's agree that, since there 
seems to be an overwhelming majority for option 1 (see below), 
then if by the start of next week (i.e Monday, April 23) 
no one will object to option 1, I will start the implementation. 

Thanks,

Ori. 



>Current summary:
>
>There are four options for Floating-Disks modelling:
>two that were previously discussed, and two that were
>recently added by Livnat, using PUT. See full list of
>options below.
>
>Itamar, Geert, Einav & Ori are currently pro option #1
>(if anyone changed his mind - please say so).
>Does anyone strongly prefer another option, or can we
>move forward with option #1?
>
>Thanks,
>
>Ori.
>
>
>
>1)
>    POST
>    /api/vms/{vm:id}/disks
>    <disk id="{disk:id}"/>                      => attach disk
>
>    DELETE
>    /api/vms/{vm:id}/disks/{disk:id}
>    <disk><detach>true</detach><disk>           => detach disk
>
>2)
>
>    POST
>    /api/vms/{vm:id}/disks
>    <disk id="{disk:id}"/>                      => attach disk
>
>    DELETE
>    /api/vms/{vm:id}/disks/{disk:id}/detach     => detach disk
>
>
>3)  PUT
>    /api/vms/{vm:id}/disks                  
>    (update on the disks collection)            => attach + detach
>
>4)  PUT
>    /api/disks/{disk:id}
>    (update on the vm-id's of disk)             => attach + detach
>
>_______________________________________________
>Engine-devel mailing list
>Engine-devel at ovirt.org
>http://lists.ovirt.org/mailman/listinfo/engine-devel


From eedri at redhat.com  Thu Apr 19 19:28:59 2012
From: eedri at redhat.com (Eyal Edri)
Date: Thu, 19 Apr 2012 15:28:59 -0400 (EDT)
Subject: [Engine-devel] [Jenkins] unit test fails
In-Reply-To: <74c725be-1008-4108-a773-09f2f5a65c68@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <862539c7-80d3-4de3-a333-eb5f72fe8cce@zmail17.collab.prod.int.phx2.redhat.com>

fyi,

1 unit test fails after these commits: (lots of commits, since the Jenkins server was stuck during that time).

http://jenkins.ovirt.org/job/ovirt_engine_unit_tests/626/

the failed test:  org.ovirt.engine.core.utils.serialization.json.JsonObjectSerializerTest.testSerialize

Eyal Edri
oVirt Infra Team.


From juan.hernandez at redhat.com  Thu Apr 19 20:23:08 2012
From: juan.hernandez at redhat.com (Juan Hernandez)
Date: Thu, 19 Apr 2012 22:23:08 +0200
Subject: [Engine-devel] [Jenkins] unit test fails
In-Reply-To: <862539c7-80d3-4de3-a333-eb5f72fe8cce@zmail17.collab.prod.int.phx2.redhat.com>
References: <862539c7-80d3-4de3-a333-eb5f72fe8cce@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <4F90742C.5080707@redhat.com>

On 04/19/2012 09:28 PM, Eyal Edri wrote:
> fyi,
> 
> 1 unit test fails after these commits: (lots of commits, since the Jenkins server was stuck during that time).
> 
> http://jenkins.ovirt.org/job/ovirt_engine_unit_tests/626/
> 
> the failed test:  org.ovirt.engine.core.utils.serialization.json.JsonObjectSerializerTest.testSerialize

That test is serializing an object with Jackson and then manually, and
comparing the result. It is failing because it gets this two things:

Manually:

{"integer":1992604070,"object":["org.ovirt.engine.core.compat.Guid",{"uuid":"7d47be2e-bc38-4d97-8489-21fcb316d799"}],"string":"\\VS|6BfM/!","guid":["org.ovirt.engine.core.compat.Guid",{"uuid":"cb15e87b-2878-4dcf-86e6-e388a32ff228"}]}

Using Jackson:

{"integer":1992604070,"guid":["org.ovirt.engine.core.compat.Guid",{"uuid":"cb15e87b-2878-4dcf-86e6-e388a32ff228"}],"string":"\\VS|6BfM/!","object":["org.ovirt.engine.core.compat.Guid",{"uuid":"7d47be2e-bc38-4d97-8489-21fcb316d799"}]}

The only difference is the order of the fields. When generated manually
the order is the one defined in the code, but when using Jackson the
order depends on the internal ordering of the fields, and that can
change between Jackson versions (we just updated to 1.9.4) or even when
compiling with different compilers.

The @JsonPropertyOrder annotation can be used like this to force the order:

@JsonPropertyOrder({ "integer", "object", "string", "guid" })
public class JsonSerializablePojo implements Serializable {

I am proposing this change to add the annotation so that the test will pass:

http://gerrit.ovirt.org/3740


From yzaslavs at redhat.com  Thu Apr 19 16:34:34 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Thu, 19 Apr 2012 19:34:34 +0300
Subject: [Engine-devel] StorageHelperDirector "factory" and StorageType
Message-ID: <4F903E9A.7090707@redhat.com>

Hi all,
StorageHelperDirector.java implements a mechanism that creates instances
of classes implementing IStorageHelper based on String value of
StorageType enum.
Although the InitializeHelpers method has an "automated" mechanism for
creating the helpers, I think it causes some bad practice -
It creates a tight coupling between the StorageType values and the class
names of storage helpers, and a result of that, Java naming convention
is broken (we use upper case enum literals at StorageType which yield
class names such as LOCALFSStorageHelper.

I think that this mechanism is an overkill, and during addition of new
storage type, its easily to detect during development if one has
forgotten to add the helper to the factory (if done manually).

Thoughts about this issue are more than welcome

Yair


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


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

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



From emesika at redhat.com  Fri Apr 20 13:10:55 2012
From: emesika at redhat.com (Eli Mesika)
Date: Fri, 20 Apr 2012 09:10:55 -0400 (EDT)
Subject: [Engine-devel] oVirt database upgrade procedure moved
Message-ID: <7526c677-a355-4f61-a185-34f7aaea2382@zmail13.collab.prod.int.phx2.redhat.com>

New location

http://www.ovirt.org/wiki/OVirt-database-upgrade-procedure


From danken at redhat.com  Sat Apr 21 20:38:17 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Sat, 21 Apr 2012 23:38:17 +0300
Subject: [Engine-devel] [vdsm] upstream/downstream compat
In-Reply-To: <20120409122524.GR25807@us.ibm.com>
References: <20120406145809.GL25807@us.ibm.com>
	<20120409092118.GK31983@redhat.com>
	<20120409122524.GR25807@us.ibm.com>
Message-ID: <20120421203816.GE25825@redhat.com>

On Mon, Apr 09, 2012 at 07:25:24AM -0500, Ryan Harper wrote:
> * Dan Kenigsberg <danken at redhat.com> [2012-04-09 04:21]:
> > On Fri, Apr 06, 2012 at 09:58:09AM -0500, Ryan Harper wrote:
> > > I've submitted some changes to start some of the work of removing the
> > > RHEV/RHEVM names throughout the vdsm code.  In one of the patches,
> > > there's a good discussion on compatibility with downstream[1]
> > > And I wanted to continue that on the mailing list so we could have more
> > > eyes; it's not clear to me if everyone is able to see/participate in an
> > > inline thread to just one of my patches.
> > > 
> > > To the point; as we look at moving toward an upstream vdsm which may be
> > > used stand-alone; ie, it may or may not having ovirt-engine/RHEVM
> > > driving actions.  I'm interested in hearing details what our
> > > requirements for compatibility are and which parts of the tree might be
> > > affected.
> > > 
> > > I'd like to posit that downstream compat is the responsibility of the
> > > distro versus the upstream community; though that's not a license to
> > > make things difficult.  IMHO, this means we can do things that help
> > > clean up the code or move the project in a particular direction without
> > > having to always worry about what the package looks like in a particular
> > > distro.  
> > 
> > Blissful upstream development is great for upstream maintainer (me), but
> > it leads to serious headaches for downstream maintainer with
> > considerable installed base (me). We have a lot of Fedoraisms and
> > RHELisms and RHEVisms in our code. Removing them is noble, probably
> > legally required, and I truly thank whomever cleans up the code. But
> > since there are so many of them, blind removal can add significant
> > burden on yours truly and his colleagues.
> > 
> > I would like to ask upstream to think twice before breaking downstream
> > compatibility. Downstream can always revert your patch, but let's make
> > it easier on them^Wus - have a configurable value, so that downstream
> > patch is a oneliner, for example. If an API must be broken, let's file a
> > bug on the adjacent component, so as not to surprise it.
> > 
> > So please, worry about how the package would look in particular distros
> > with considerable installed base. Discuss upgrade paths. Help make Vdsm
> > easily downstreamable.
> 
> Indeed, I wasn't suggesting we just completely ignore downstream, and I
> think since you're both upstream and downstream maintainer you have
> valuable insight on how best to make these changes.  Looking forward to
> hearing details on how best to make upstream progress while retaining
> downstream compat!

I thought that I've provided some details, or more exactly, examples.
Essentially, any patch that strips off trademarks, would have to be
reverted downstream. I am asking (gently) to help make this reversal simple,
hopefully a one-liner in a config file (or configure.ac).

As a bad example look at vdsm_reg/engine.py. We replaced any visible
reference to "RHEV-M" with "oVirt Engine". Now we need a multiline patch
downstream to put it back. It would be much nicer to have a constant in
that module, say ENGINE_NAME. When such a patch is upstream, downstream
can touch only the constant's values.

I also prefer topical patches, not file-based. A patch removing
non-functional RHEV label can be pushed immediately. The famous
http://gerrit.ovirt.org/#patch,sidebyside,3287,1,vds_bootstrap/vds_bootstrap.py
combines both comment and an API change.

Regards,
Dan.


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

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

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

Regards,
Dor

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



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



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

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

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

I don't think this is the libstoragemgmt mandate.

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

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

setupStorage would use libstoragemgmt wherever appropriate of course.

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


From ovedo at redhat.com  Sun Apr 22 10:40:14 2012
From: ovedo at redhat.com (Oved Ourfalli)
Date: Sun, 22 Apr 2012 06:40:14 -0400 (EDT)
Subject: [Engine-devel] StorageHelperDirector "factory" and StorageType
In-Reply-To: <4F903E9A.7090707@redhat.com>
Message-ID: <f5412e42-1913-46bf-9cac-043d1818779c@zmail02.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Thursday, April 19, 2012 7:34:34 PM
> Subject: [Engine-devel] StorageHelperDirector "factory" and StorageType
> 
> Hi all,
> StorageHelperDirector.java implements a mechanism that creates
> instances
> of classes implementing IStorageHelper based on String value of
> StorageType enum.
> Although the InitializeHelpers method has an "automated" mechanism
> for
> creating the helpers, I think it causes some bad practice -
> It creates a tight coupling between the StorageType values and the
> class
> names of storage helpers, and a result of that, Java naming
> convention
> is broken (we use upper case enum literals at StorageType which yield
> class names such as LOCALFSStorageHelper.
> 
> I think that this mechanism is an overkill, and during addition of
> new
> storage type, its easily to detect during development if one has
> forgotten to add the helper to the factory (if done manually).
> 
> Thoughts about this issue are more than welcome
> 

I agree that it is an overkill, especially because we don't add new storage types very often, and even if we do the programmer who added it will probably find out about it one way or another (while testing he will see an exception, leading him to the correct place).

If it doesn't sound reasonable to others then there are other solutions (only if we really really have to....):
1. Have the Enum contain also a "class name" or "class prefix name" for that specific type, which will be used instead of the enum value. It can be useful in cases in which there are a few classes needed for this type (might not be relevant to the specific case you described, but might be useful in other cases).
2. Make a checklist in the Enum of places to touch when changing the enum - hopefully the programmer will read it, and do as he is told... Also, this checklist should be updated as well when new interfaces are added, and I don't see how we can automatically update this checklist :-)
3. Assuming there is a tester to the factory, we can add an assert that checks how many values are there in the enum. Once the enum is extended, the test will fail, and we will know that we need to check for related things (we can put a comment in the tester, specifying a "checklist"). - from my experience, in most cases it will end in the programmer doing everything needed, then failing on this test and fixing it (updating the number of values....)

Compile-time assertions are useful in such cases, but didn't find such an option in Java (perhaps we should move the engine to C++ ;-) ).

I'd go with option #1 (again... only if we really need to provide an "automatic factory").

Oved

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


From eedri at redhat.com  Mon Apr 23 09:20:45 2012
From: eedri at redhat.com (Eyal Edri)
Date: Mon, 23 Apr 2012 05:20:45 -0400 (EDT)
Subject: [Engine-devel] [Jenkins] ovirt engine unit tests fails
In-Reply-To: <de102ea1-bbeb-4a1a-9a69-89c651820a70@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <032ad1ea-ef22-4f06-9e97-54e0638002a0@zmail17.collab.prod.int.phx2.redhat.com>

fyi,

2 unit tests fails currently on ovirt-engine:

http://jenkins.ovirt.org/job/ovirt_engine_unit_tests/657/#showFailuresLink

org.ovirt.engine.core.bll.QueriesCommandBaseTest.testQueryCreation
org.ovirt.engine.core.bll.GetAllDisksByVmIdQueryTest.testExecuteQueryCommand


Please check,

Eyal.


From emesika at redhat.com  Mon Apr 23 09:48:42 2012
From: emesika at redhat.com (Eli Mesika)
Date: Mon, 23 Apr 2012 05:48:42 -0400 (EDT)
Subject: [Engine-devel] StorageHelperDirector "factory" and StorageType
In-Reply-To: <f5412e42-1913-46bf-9cac-043d1818779c@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <bfadec0e-73d6-47da-b2d1-5f856516b5a9@zmail13.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Oved Ourfalli" <ovedo at redhat.com>
> To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, April 22, 2012 1:40:14 PM
> Subject: Re: [Engine-devel] StorageHelperDirector "factory" and StorageType
> 
> 
> 
> ----- Original Message -----
> > From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Thursday, April 19, 2012 7:34:34 PM
> > Subject: [Engine-devel] StorageHelperDirector "factory" and
> > StorageType
> > 
> > Hi all,
> > StorageHelperDirector.java implements a mechanism that creates
> > instances
> > of classes implementing IStorageHelper based on String value of
> > StorageType enum.
> > Although the InitializeHelpers method has an "automated" mechanism
> > for
> > creating the helpers, I think it causes some bad practice -
> > It creates a tight coupling between the StorageType values and the
> > class
> > names of storage helpers, and a result of that, Java naming
> > convention
> > is broken (we use upper case enum literals at StorageType which
> > yield
> > class names such as LOCALFSStorageHelper.
> > 
> > I think that this mechanism is an overkill, and during addition of
> > new
> > storage type, its easily to detect during development if one has
> > forgotten to add the helper to the factory (if done manually).
> > 
> > Thoughts about this issue are more than welcome
> > 
> 
> I agree that it is an overkill, especially because we don't add new
> storage types very often, and even if we do the programmer who added
> it will probably find out about it one way or another (while testing
> he will see an exception, leading him to the correct place).
> 
> If it doesn't sound reasonable to others then there are other
> solutions (only if we really really have to....):
> 1. Have the Enum contain also a "class name" or "class prefix name"
> for that specific type, which will be used instead of the enum
> value. It can be useful in cases in which there are a few classes
> needed for this type (might not be relevant to the specific case you
> described, but might be useful in other cases).
+1 (if we must...)
> 2. Make a checklist in the Enum of places to touch when changing the
> enum - hopefully the programmer will read it, and do as he is
> told... Also, this checklist should be updated as well when new
> interfaces are added, and I don't see how we can automatically
> update this checklist :-)
> 3. Assuming there is a tester to the factory, we can add an assert
> that checks how many values are there in the enum. Once the enum is
> extended, the test will fail, and we will know that we need to check
> for related things (we can put a comment in the tester, specifying a
> "checklist"). - from my experience, in most cases it will end in the
> programmer doing everything needed, then failing on this test and
> fixing it (updating the number of values....)
> 
> Compile-time assertions are useful in such cases, but didn't find
> such an option in Java (perhaps we should move the engine to C++ ;-)
> ).
> 
> I'd go with option #1 (again... only if we really need to provide an
> "automatic factory").
> 
> Oved
> 
> > Yair
> > _______________________________________________
> > 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 deepakcs at linux.vnet.ibm.com  Mon Apr 23 11:28:52 2012
From: deepakcs at linux.vnet.ibm.com (Deepak C Shetty)
Date: Mon, 23 Apr 2012 16:58:52 +0530
Subject: [Engine-devel] [vdsm] Storage Device Management in VDSM and
	oVirt
In-Reply-To: <3a5c5eff-286d-46ab-9a72-8d0736f11aa0@zmail13.collab.prod.int.phx2.redhat.com>
References: <3a5c5eff-286d-46ab-9a72-8d0736f11aa0@zmail13.collab.prod.int.phx2.redhat.com>
Message-ID: <4F953CF4.80703@linux.vnet.ibm.com>

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

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

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

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

thanx,
deepak





From ryanh at us.ibm.com  Mon Apr 23 14:28:14 2012
From: ryanh at us.ibm.com (Ryan Harper)
Date: Mon, 23 Apr 2012 09:28:14 -0500
Subject: [Engine-devel] [vdsm] upstream/downstream compat
In-Reply-To: <20120421203816.GE25825@redhat.com>
References: <20120406145809.GL25807@us.ibm.com>
	<20120409092118.GK31983@redhat.com>
	<20120409122524.GR25807@us.ibm.com>
	<20120421203816.GE25825@redhat.com>
Message-ID: <20120423142814.GC30591@us.ibm.com>

* Dan Kenigsberg <danken at redhat.com> [2012-04-21 15:38]:
> On Mon, Apr 09, 2012 at 07:25:24AM -0500, Ryan Harper wrote:
> > * Dan Kenigsberg <danken at redhat.com> [2012-04-09 04:21]:
> > > On Fri, Apr 06, 2012 at 09:58:09AM -0500, Ryan Harper wrote:
> > > > I've submitted some changes to start some of the work of removing the
> > > > RHEV/RHEVM names throughout the vdsm code.  In one of the patches,
> > > > there's a good discussion on compatibility with downstream[1]
> > > > And I wanted to continue that on the mailing list so we could have more
> > > > eyes; it's not clear to me if everyone is able to see/participate in an
> > > > inline thread to just one of my patches.
> > > > 
> > > > To the point; as we look at moving toward an upstream vdsm which may be
> > > > used stand-alone; ie, it may or may not having ovirt-engine/RHEVM
> > > > driving actions.  I'm interested in hearing details what our
> > > > requirements for compatibility are and which parts of the tree might be
> > > > affected.
> > > > 
> > > > I'd like to posit that downstream compat is the responsibility of the
> > > > distro versus the upstream community; though that's not a license to
> > > > make things difficult.  IMHO, this means we can do things that help
> > > > clean up the code or move the project in a particular direction without
> > > > having to always worry about what the package looks like in a particular
> > > > distro.  
> > > 
> > > Blissful upstream development is great for upstream maintainer (me), but
> > > it leads to serious headaches for downstream maintainer with
> > > considerable installed base (me). We have a lot of Fedoraisms and
> > > RHELisms and RHEVisms in our code. Removing them is noble, probably
> > > legally required, and I truly thank whomever cleans up the code. But
> > > since there are so many of them, blind removal can add significant
> > > burden on yours truly and his colleagues.
> > > 
> > > I would like to ask upstream to think twice before breaking downstream
> > > compatibility. Downstream can always revert your patch, but let's make
> > > it easier on them^Wus - have a configurable value, so that downstream
> > > patch is a oneliner, for example. If an API must be broken, let's file a
> > > bug on the adjacent component, so as not to surprise it.
> > > 
> > > So please, worry about how the package would look in particular distros
> > > with considerable installed base. Discuss upgrade paths. Help make Vdsm
> > > easily downstreamable.
> > 
> > Indeed, I wasn't suggesting we just completely ignore downstream, and I
> > think since you're both upstream and downstream maintainer you have
> > valuable insight on how best to make these changes.  Looking forward to
> > hearing details on how best to make upstream progress while retaining
> > downstream compat!
> 
> I thought that I've provided some details, or more exactly, examples.
> Essentially, any patch that strips off trademarks, would have to be
> reverted downstream. I am asking (gently) to help make this reversal simple,
> hopefully a one-liner in a config file (or configure.ac).

OK

> 
> As a bad example look at vdsm_reg/engine.py. We replaced any visible
> reference to "RHEV-M" with "oVirt Engine". Now we need a multiline patch
> downstream to put it back. It would be much nicer to have a constant in
> that module, say ENGINE_NAME. When such a patch is upstream, downstream
> can touch only the constant's values.

It'll end up being case-by-case, as you've got RHEV, RHEVM and other
variants embedded in comments, constants and code; so it's not always
clear (to me) which items (save the comments) are related to the API
contract with RHEVM/engine.

Let's see how much we can get out of a top-level constant.


> 
> I also prefer topical patches, not file-based. A patch removing
> non-functional RHEV label can be pushed immediately. The famous
> http://gerrit.ovirt.org/#patch,sidebyside,3287,1,vds_bootstrap/vds_bootstrap.py
> combines both comment and an API change.

Sure, I was hoping to keep each of the patches small; and it wasn't
clear to me that the string emitted was part of the API.

I'm thinking I can to the following topical passes across the repo:

1. comments
2. variable names
3. emitted strings/values


> 
> Regards,
> Dan.

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



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

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

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

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

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

-Tony


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



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


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

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

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

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

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

Does that make sense?

> 
> thanx,
> deepak
> 
> 
> 
> 


From lpeer at redhat.com  Tue Apr 24 09:59:06 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Tue, 24 Apr 2012 12:59:06 +0300
Subject: [Engine-devel] bi-weekly status
Message-ID: <4F96796A.5070609@redhat.com>

Hi All,

It is memorial day in Israel tomorrow, so I am canceling tomorrow's
ovirt-engine-core meeting.

Please reply on the list if there is something that can't/shouldn't wait
for next meeting and I'll schedule a meeting for next week instead of
this one.

Thanks, Livnat


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

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

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


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

Agree to #2. Thinking deeper....

1) Provisioning Storage

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

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

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

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

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

     1a) Carve LUNs from external Storage array.

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

     1c) Use local host free disk space.

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

2) Setup Storage

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

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

3) Not sure if anymore steps needed ?


thanx,
deepak



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



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

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

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

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

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

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

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

> 
> 3) Not sure if anymore steps needed ?

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

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

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

> 
> 
> thanx,
> deepak
> 
> 


From iheim at redhat.com  Tue Apr 24 15:11:57 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 24 Apr 2012 18:11:57 +0300
Subject: [Engine-devel] signed-off-by in commit message
Message-ID: <4F96C2BD.90309@redhat.com>

per previous thread by Ryan Harper[1] and ovirt meeting today, starting 
may 1st gerrit policy will change for all projects to require 
signed-off-by in the commit message.

vdsm and ovirt-node already have this active

Thanks,
    Itamar

for more details:
http://kerneltrap.org/files/Jeremy/DCO.txt

[1]http://www.mail-archive.com/arch at ovirt.org/msg00273.html


From ryanh at us.ibm.com  Tue Apr 24 15:57:33 2012
From: ryanh at us.ibm.com (Ryan Harper)
Date: Tue, 24 Apr 2012 10:57:33 -0500
Subject: [Engine-devel] signed-off-by in commit message
In-Reply-To: <4F96C2BD.90309@redhat.com>
References: <4F96C2BD.90309@redhat.com>
Message-ID: <20120424155733.GA12753@us.ibm.com>

* Itamar Heim <iheim at redhat.com> [2012-04-24 10:22]:
> per previous thread by Ryan Harper[1] and ovirt meeting today, starting 
> may 1st gerrit policy will change for all projects to require 
> signed-off-by in the commit message.
> 
> vdsm and ovirt-node already have this active
> 
> Thanks,
>    Itamar

Thanks Itamar!


> 
> for more details:
> http://kerneltrap.org/files/Jeremy/DCO.txt
> 
> [1]http://www.mail-archive.com/arch at ovirt.org/msg00273.html
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel

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



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

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

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

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

This seems interesting.

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

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

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

thanx,
deepak



From Dustin.Schoenbrun at netapp.com  Thu Apr 26 19:24:17 2012
From: Dustin.Schoenbrun at netapp.com (Schoenbrun, Dustin)
Date: Thu, 26 Apr 2012 19:24:17 +0000
Subject: [Engine-devel] Disk Cloning When Creating a VM via a Template
Message-ID: <0A1534657992624AACDCA570F1D3E20003C29F05@SACEXCMBX03-PRD.hq.netapp.com>

Greetings,

I know that floating disks are coming in the next version of oVirt, but in the interim I want to know internally what the procedure is when a disk is cloned when creating a VM from a template.  I see the AddVmImages() method in the AddVmFromTemplateCommand.java file, but could someone walk me through exactly what is going on when the disk gets cloned?  Thanks!

-- Dustin

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

From shuming at linux.vnet.ibm.com  Fri Apr 27 16:48:20 2012
From: shuming at linux.vnet.ibm.com (Shu Ming)
Date: Sat, 28 Apr 2012 00:48:20 +0800
Subject: [Engine-devel] Updating ovirt engine from 3.0 to the 3.1.0 version
Message-ID: <4F9ACDD4.3080609@linux.vnet.ibm.com>

Hi,
   I built a set of ovirt engine RPM packages from near the latest ovirt 
engine source code.  However, when I try to access the engine server 
with URL "http://ovirt-engine-112:80", the browser displayed a blank 
page without http error returned.  Any clue about what is going on here? 
Why didn't the engine administrator home page be shown?


And the packages were also installed successfully in my target system, 
checked this by "rpm -q -a|grep engine".
  I) upgraded the packages to the 3.1

[root at ovirt-engine-112 ~]# rpm -q -a |grep engine
ovirt-engine-restapi-3.1.0_0001-1.8.fc16.x86_64
ovirt-engine-dbscripts-3.1.0_0001-1.8.fc16.x86_64
ovirt-engine-log-collector-3.0.0_0001-1.6.fc16.x86_64
ovirt-engine-genericapi-3.1.0_0001-1.8.fc16.x86_64
ovirt-engine-backend-3.1.0_0001-1.8.fc16.x86_64
ovirt-engine-setup-3.1.0_0001-1.8.fc16.x86_64
ovirt-engine-jbossas-1.2-2.fc16.x86_64
ovirt-engine-jboss-deps-3.1.0_0001-1.8.fc16.x86_64
ovirt-engine-config-3.1.0_0001-1.8.fc16.x86_64
ovirt-engine-3.1.0_0001-1.8.fc16.x86_64
ovirt-engine-webadmin-portal-3.1.0_0001-1.8.fc16.x86_64
ovirt-engine-userportal-3.1.0_0001-1.8.fc16.x86_64
ovirt-engine-tools-common-3.1.0_0001-1.8.fc16.x86_64
ovirt-engine-image-uploader-3.1.0_0001-1.8.fc16.x86_64
ovirt-engine-notification-service-3.1.0_0001-1.8.fc16.x86_64
ovirt-engine-iso-uploader-3.1.0_0001-1.8.fc16.x86_64
gtk2-engines-2.20.2-2.fc15.x86_64

Step II)
    Then I used "engine-setup" to setup the engine.  It seems that 
everything is ok, see the log below.

-------------
[root at ovirt-engine-112 ~]# engine-setup
Welcome to oVirt Engine setup utility
HTTP Port  [80] :
HTTPS Port  [443] :
Host fully qualified domain name, note that this name should be fully 
resolvable  [ovirt-engine-112] :
ERROR: domain is not a valid domain name
User input failed validation, do you still wish to use it? (yes|no): yes
Password for Administrator (admin at internal) :
Warning: Weak Password.
Confirm password :
Organization Name for the Certificate: cstl
The default storage type you will be using  ['NFS'| 'FC'| 'ISCSI']  [NFS] :
Enter DB type for installation ['remote'| 'local']  [local] :
Local database password :
Warning: Weak Password.
Confirm password :
Should the installer configure NFS share on this server to be used as an 
ISO Domain? ['yes'| 'no']  [yes] :
Mount point path: /iso-dom
ERROR: mount point already exists in /etc/exports
Mount point path: /iso-dom
Display name for the ISO Domain: iso-domains
Firewall ports need to be opened.
You can let the installer configure iptables automatically overriding 
the current configuration. The old configuration will be backed up.
Alternately you can configure the firewall later using an example 
iptables file found under /usr/share/ovirt-engine/conf/iptables.example
Configure iptables ? ['yes'| 'no']: yes

oVirt Engine will be installed using the following configuration:
=================================================================
http-port:                     80
https-port:                    443
host-fqdn:                     ovirt-engine-112
auth-pass:                     ********
org-name:                      cstl
default-dc-type:               NFS
db-remote-install:             local
db-local-pass:                 ********
nfs-mp:                        /iso-dom
iso-domain-name:               iso-domains
config-nfs:                    yes
override-iptables:             yes
Proceed with the configuration listed above? (yes|no): yes

Installing:
Configuring oVirt-engine...                              [ DONE ]
Creating CA...                                           [ DONE ]
Editing JBoss Configuration...                           [ DONE ]
Setting Database Configuration...                        [ DONE ]
Setting Database Security...                             [ DONE ]
Creating Database...                                     [ DONE ]
Updating the Default Data Center Storage Type...         [ DONE ]
Editing oVirt Engine Configuration...                    [ DONE ]
Editing Postgresql Configuration...                      [ DONE ]
Configuring the Default ISO Domain...                    [ DONE ]
Configuring Firewall (iptables)...                       [ DONE ]
Starting JBoss Service...                                [ DONE ]
Handling HTTPD...                                        [ DONE ]

  **** Installation completed successfully ******

      (Please allow oVirt Engine a few moments to start up.....)


Additional information:
  * SSL Certificate fingerprint: 
C6:01:83:93:4B:2C:2A:38:65:C8:49:C9:17:34:FE:4B:1C:10:D5:FF
  * SSH Public key fingerprint: 
69:8c:bd:05:43:17:0a:43:a3:cc:62:7e:f7:be:0c:42
  * A default ISO share has been created on this host.
    If IP based access restrictions are required, please edit /iso-dom 
entry in /etc/exports
  * The firewall has been updated, the old iptables configuration file 
was saved to 
/usr/share/ovirt-engine/conf/iptables.backup.011513-04282012_2225
  * The installation log file is available at: 
/var/log/ovirt-engine/engine-setup_2012_04_28_01_13_01.log
  * Please use the user "admin" and password specified in order to login 
into oVirt Engine
  * To configure additional users, first configure authentication 
domains using the 'engine-manage-domains' utility
  * To access oVirt Engine please go to the following URL: 
http://ovirt-engine-112:80
[root at ovirt-engine-112 ~]#


-- 
Shu Ming<shuming at linux.vnet.ibm.com>
IBM China Systems and Technology Laboratory




From snmishra at linux.vnet.ibm.com  Fri Apr 27 23:51:25 2012
From: snmishra at linux.vnet.ibm.com (Sharad Mishra)
Date: Fri, 27 Apr 2012 19:51:25 -0400
Subject: [Engine-devel] namingcontexts getting ignored.
Message-ID: <20120427195125.Horde.KZ2Zx5ir309PmzD90it3UQA@imap.linux.ibm.com>


Hi,

    I enter "getDefaultNamingContextFromNamingContexts()" with  
namingContexts set to -

namingcontexts: CN=SCHEMA, CN=LOCALHOST, CN=IBMPOLICIES, O=IBM.COM,  
O=DELETED.IBM.COM

    But this method only takes the first case "CN=SCHEMA" and ignores  
the rest. Actually I am interested in "O=IBM.COM".
    Is this working as designed or needs improvement?

-Sharad Mishra
IBM

public class RootDSEData {
     private String domainDN = null;
     private LdapProviderType ldapProviderType = null;
     private final static String RHDS_NAMING_CONTEXT = "o=netscaperoot";

     public static String  
getDefaultNamingContextFromNamingContexts(Attribute namingContexts) {
         for (int index = 0; index < namingContexts.size(); ++index) {
             String namingContext;
             try {
                 namingContext = (String) namingContexts.get(index);
             } catch (NamingException e) {
                 return null;
             }
             if (!RHDS_NAMING_CONTEXT.equalsIgnoreCase(namingContext)) {
                 return namingContext;
             }
         }
         return null;
     }



From ovedo at redhat.com  Sun Apr 29 06:49:07 2012
From: ovedo at redhat.com (Oved Ourfalli)
Date: Sun, 29 Apr 2012 02:49:07 -0400 (EDT)
Subject: [Engine-devel] namingcontexts getting ignored.
In-Reply-To: <20120427195125.Horde.KZ2Zx5ir309PmzD90it3UQA@imap.linux.ibm.com>
Message-ID: <dddf7d72-ddda-4f0a-9f6a-b1e426ade96b@zmail02.collab.prod.int.phx2.redhat.com>

Hey,

In case the namingContexts field contains more than one naming context, we have no way of knowing which one is the required one.
We take the first one. In active directory, for example (and as far as I understand in the newest free-ipa) you have a defaultNamingContext field, and if so we take it, and it contains only one naming context. 

As you see in the code below, we have a "special" treatment for RHDS, as it always contains "o=netscaperoot" in the namingContexts field (not necessary at the beginning of the list), so we filter it out.

It was enough for now, but I agree that if adding new LDAP providers, which usually have a more complex and unpredictable data in the namingContext field, then we would probably need to ask the user to specify the naming context for us, and if he didn't specify it then assume it is identical to the domain name.

Oved

----- Original Message -----
> From: "Sharad Mishra" <snmishra at linux.vnet.ibm.com>
> To: engine-devel at ovirt.org
> Sent: Saturday, April 28, 2012 2:51:25 AM
> Subject: [Engine-devel] namingcontexts getting ignored.
> 
> 
> Hi,
> 
>     I enter "getDefaultNamingContextFromNamingContexts()" with
> namingContexts set to -
> 
> namingcontexts: CN=SCHEMA, CN=LOCALHOST, CN=IBMPOLICIES, O=IBM.COM,
> O=DELETED.IBM.COM
> 
>     But this method only takes the first case "CN=SCHEMA" and ignores
> the rest. Actually I am interested in "O=IBM.COM".
>     Is this working as designed or needs improvement?
> 
> -Sharad Mishra
> IBM
> 
> public class RootDSEData {
>      private String domainDN = null;
>      private LdapProviderType ldapProviderType = null;
>      private final static String RHDS_NAMING_CONTEXT =
>      "o=netscaperoot";
> 
>      public static String
> getDefaultNamingContextFromNamingContexts(Attribute namingContexts) {
>          for (int index = 0; index < namingContexts.size(); ++index)
>          {
>              String namingContext;
>              try {
>                  namingContext = (String) namingContexts.get(index);
>              } catch (NamingException e) {
>                  return null;
>              }
>              if
>              (!RHDS_NAMING_CONTEXT.equalsIgnoreCase(namingContext))
>              {
>                  return namingContext;
>              }
>          }
>          return null;
>      }
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From yzaslavs at redhat.com  Sun Apr 29 08:02:00 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Sun, 29 Apr 2012 11:02:00 +0300
Subject: [Engine-devel] namingcontexts getting ignored.
In-Reply-To: <dddf7d72-ddda-4f0a-9f6a-b1e426ade96b@zmail02.collab.prod.int.phx2.redhat.com>
References: <dddf7d72-ddda-4f0a-9f6a-b1e426ade96b@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <4F9CF578.4000009@redhat.com>

On 04/29/2012 09:49 AM, Oved Ourfalli wrote:
> Hey,
> 
> In case the namingContexts field contains more than one naming context, we have no way of knowing which one is the required one.
> We take the first one. In active directory, for example (and as far as I understand in the newest free-ipa) you have a defaultNamingContext field, and if so we take it, and it contains only one naming context. 
> 
> As you see in the code below, we have a "special" treatment for RHDS, as it always contains "o=netscaperoot" in the namingContexts field (not necessary at the beginning of the list), so we filter it out.
> 
> It was enough for now, but I agree that if adding new LDAP providers, which usually have a more complex and unpredictable data in the namingContext field, then we would probably need to ask the user to specify the naming context for us, and if he didn't specify it then assume it is identical to the domain name.
> 
> Oved

Another idea -
Now that we provide the provider type in manage domains, maybe we should
add a logic for getting naming contexts based on the provider type.
Thoughts on this?


> 
> ----- Original Message -----
>> From: "Sharad Mishra" <snmishra at linux.vnet.ibm.com>
>> To: engine-devel at ovirt.org
>> Sent: Saturday, April 28, 2012 2:51:25 AM
>> Subject: [Engine-devel] namingcontexts getting ignored.
>>
>>
>> Hi,
>>
>>     I enter "getDefaultNamingContextFromNamingContexts()" with
>> namingContexts set to -
>>
>> namingcontexts: CN=SCHEMA, CN=LOCALHOST, CN=IBMPOLICIES, O=IBM.COM,
>> O=DELETED.IBM.COM
>>
>>     But this method only takes the first case "CN=SCHEMA" and ignores
>> the rest. Actually I am interested in "O=IBM.COM".
>>     Is this working as designed or needs improvement?
>>
>> -Sharad Mishra
>> IBM
>>
>> public class RootDSEData {
>>      private String domainDN = null;
>>      private LdapProviderType ldapProviderType = null;
>>      private final static String RHDS_NAMING_CONTEXT =
>>      "o=netscaperoot";
>>
>>      public static String
>> getDefaultNamingContextFromNamingContexts(Attribute namingContexts) {
>>          for (int index = 0; index < namingContexts.size(); ++index)
>>          {
>>              String namingContext;
>>              try {
>>                  namingContext = (String) namingContexts.get(index);
>>              } catch (NamingException e) {
>>                  return null;
>>              }
>>              if
>>              (!RHDS_NAMING_CONTEXT.equalsIgnoreCase(namingContext))
>>              {
>>                  return namingContext;
>>              }
>>          }
>>          return null;
>>      }
>>
>> _______________________________________________
>> 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 ovedo at redhat.com  Sun Apr 29 08:08:52 2012
From: ovedo at redhat.com (Oved Ourfalli)
Date: Sun, 29 Apr 2012 04:08:52 -0400 (EDT)
Subject: [Engine-devel] namingcontexts getting ignored.
In-Reply-To: <4F9CF578.4000009@redhat.com>
Message-ID: <810f9a4e-5e69-400b-8972-35a84bd7d29b@zmail02.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Sunday, April 29, 2012 11:02:00 AM
> Subject: Re: [Engine-devel] namingcontexts getting ignored.
> 
> On 04/29/2012 09:49 AM, Oved Ourfalli wrote:
> > Hey,
> > 
> > In case the namingContexts field contains more than one naming
> > context, we have no way of knowing which one is the required one.
> > We take the first one. In active directory, for example (and as far
> > as I understand in the newest free-ipa) you have a
> > defaultNamingContext field, and if so we take it, and it contains
> > only one naming context.
> > 
> > As you see in the code below, we have a "special" treatment for
> > RHDS, as it always contains "o=netscaperoot" in the namingContexts
> > field (not necessary at the beginning of the list), so we filter
> > it out.
> > 
> > It was enough for now, but I agree that if adding new LDAP
> > providers, which usually have a more complex and unpredictable
> > data in the namingContext field, then we would probably need to
> > ask the user to specify the naming context for us, and if he
> > didn't specify it then assume it is identical to the domain name.
> > 
> > Oved
> 
> Another idea -
> Now that we provide the provider type in manage domains, maybe we
> should
> add a logic for getting naming contexts based on the provider type.
> Thoughts on this?
> 
> 
That's pretty much what we do (although it is all in one method, so it should be extracted to an interface). But, it is assuming one can predict what will be in this field.
In IPA we now have the defaultNamingContext, so we can use it (like we do in AD). In RHDS we know what it contains, so we can deduce the naming context. Not sure about IBM- directory services. So, we might need to provide a configuration entry for that as well (same as we do with the provider type).



> > 
> > ----- Original Message -----
> >> From: "Sharad Mishra" <snmishra at linux.vnet.ibm.com>
> >> To: engine-devel at ovirt.org
> >> Sent: Saturday, April 28, 2012 2:51:25 AM
> >> Subject: [Engine-devel] namingcontexts getting ignored.
> >>
> >>
> >> Hi,
> >>
> >>     I enter "getDefaultNamingContextFromNamingContexts()" with
> >> namingContexts set to -
> >>
> >> namingcontexts: CN=SCHEMA, CN=LOCALHOST, CN=IBMPOLICIES,
> >> O=IBM.COM,
> >> O=DELETED.IBM.COM
> >>
> >>     But this method only takes the first case "CN=SCHEMA" and
> >>     ignores
> >> the rest. Actually I am interested in "O=IBM.COM".
> >>     Is this working as designed or needs improvement?
> >>
> >> -Sharad Mishra
> >> IBM
> >>
> >> public class RootDSEData {
> >>      private String domainDN = null;
> >>      private LdapProviderType ldapProviderType = null;
> >>      private final static String RHDS_NAMING_CONTEXT =
> >>      "o=netscaperoot";
> >>
> >>      public static String
> >> getDefaultNamingContextFromNamingContexts(Attribute
> >> namingContexts) {
> >>          for (int index = 0; index < namingContexts.size();
> >>          ++index)
> >>          {
> >>              String namingContext;
> >>              try {
> >>                  namingContext = (String)
> >>                  namingContexts.get(index);
> >>              } catch (NamingException e) {
> >>                  return null;
> >>              }
> >>              if
> >>              (!RHDS_NAMING_CONTEXT.equalsIgnoreCase(namingContext))
> >>              {
> >>                  return namingContext;
> >>              }
> >>          }
> >>          return null;
> >>      }
> >>
> >> _______________________________________________
> >> 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  Sun Apr 29 08:23:48 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Sun, 29 Apr 2012 11:23:48 +0300
Subject: [Engine-devel] namingcontexts getting ignored.
In-Reply-To: <810f9a4e-5e69-400b-8972-35a84bd7d29b@zmail02.collab.prod.int.phx2.redhat.com>
References: <810f9a4e-5e69-400b-8972-35a84bd7d29b@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <4F9CFA94.4050303@redhat.com>

On 04/29/2012 11:08 AM, Oved Ourfalli wrote:
> 
> 
> ----- Original Message -----
>> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
>> To: engine-devel at ovirt.org
>> Sent: Sunday, April 29, 2012 11:02:00 AM
>> Subject: Re: [Engine-devel] namingcontexts getting ignored.
>>
>> On 04/29/2012 09:49 AM, Oved Ourfalli wrote:
>>> Hey,
>>>
>>> In case the namingContexts field contains more than one naming
>>> context, we have no way of knowing which one is the required one.
>>> We take the first one. In active directory, for example (and as far
>>> as I understand in the newest free-ipa) you have a
>>> defaultNamingContext field, and if so we take it, and it contains
>>> only one naming context.
>>>
>>> As you see in the code below, we have a "special" treatment for
>>> RHDS, as it always contains "o=netscaperoot" in the namingContexts
>>> field (not necessary at the beginning of the list), so we filter
>>> it out.
>>>
>>> It was enough for now, but I agree that if adding new LDAP
>>> providers, which usually have a more complex and unpredictable
>>> data in the namingContext field, then we would probably need to
>>> ask the user to specify the naming context for us, and if he
>>> didn't specify it then assume it is identical to the domain name.
>>>
>>> Oved
>>
>> Another idea -
>> Now that we provide the provider type in manage domains, maybe we
>> should
>> add a logic for getting naming contexts based on the provider type.
>> Thoughts on this?
>>
>>
> That's pretty much what we do (although it is all in one method, so it should be extracted to an interface). But, it is assuming one can predict what will be in this field.
> In IPA we now have the defaultNamingContext, so we can use it (like we do in AD). In RHDS we know what it contains, so we can deduce the naming context. Not sure about IBM- directory services. So, we might need to provide a configuration entry for that as well (same as we do with the provider type).
What I mean - pass the providerType all the way from the ManageDomins
class to RootDSEData (need to check if this possible).
Then, based on the providerType , handle the naming contexts.
I'm sure Sharad can shed a light on what should be handled for Tivoli DS.
Btw, I'm not saying that providing a config entry is not a good idea,
what I'm saying is that we can use the provider type to provider better
handling (making namingContext an optional parameter, and in case not
provider, use logic based on provider type).


> 
> 
> 
>>>
>>> ----- Original Message -----
>>>> From: "Sharad Mishra" <snmishra at linux.vnet.ibm.com>
>>>> To: engine-devel at ovirt.org
>>>> Sent: Saturday, April 28, 2012 2:51:25 AM
>>>> Subject: [Engine-devel] namingcontexts getting ignored.
>>>>
>>>>
>>>> Hi,
>>>>
>>>>     I enter "getDefaultNamingContextFromNamingContexts()" with
>>>> namingContexts set to -
>>>>
>>>> namingcontexts: CN=SCHEMA, CN=LOCALHOST, CN=IBMPOLICIES,
>>>> O=IBM.COM,
>>>> O=DELETED.IBM.COM
>>>>
>>>>     But this method only takes the first case "CN=SCHEMA" and
>>>>     ignores
>>>> the rest. Actually I am interested in "O=IBM.COM".
>>>>     Is this working as designed or needs improvement?
>>>>
>>>> -Sharad Mishra
>>>> IBM
>>>>
>>>> public class RootDSEData {
>>>>      private String domainDN = null;
>>>>      private LdapProviderType ldapProviderType = null;
>>>>      private final static String RHDS_NAMING_CONTEXT =
>>>>      "o=netscaperoot";
>>>>
>>>>      public static String
>>>> getDefaultNamingContextFromNamingContexts(Attribute
>>>> namingContexts) {
>>>>          for (int index = 0; index < namingContexts.size();
>>>>          ++index)
>>>>          {
>>>>              String namingContext;
>>>>              try {
>>>>                  namingContext = (String)
>>>>                  namingContexts.get(index);
>>>>              } catch (NamingException e) {
>>>>                  return null;
>>>>              }
>>>>              if
>>>>              (!RHDS_NAMING_CONTEXT.equalsIgnoreCase(namingContext))
>>>>              {
>>>>                  return namingContext;
>>>>              }
>>>>          }
>>>>          return null;
>>>>      }
>>>>
>>>> _______________________________________________
>>>> 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 ItzikB at mellanox.com  Sun Apr 29 08:44:54 2012
From: ItzikB at mellanox.com (Itzik Brown)
Date: Sun, 29 Apr 2012 08:44:54 +0000
Subject: [Engine-devel] Problem with detachment of host interface using
 ovirt-sdk
Message-ID: <4488206DC085244C886DBC9E7038B6892517433E@mtrdag02.mtl.com>

Juan,

I used the repository git://gerrit.ovirt.org/ovirt-engine-sdk
Commit 3c721e60ab3af3ad07e1a20bc6fdbcdbc1344df0

The test script :

#!/usr/bin/python

import sys
from ovirtsdk.api import API
from ovirtsdk.xml import params

OVIRT_ENGINE_SERVER = 'server1'
OVIRT_ENGINE_PORT = '8080'
OVIRT_ENGINE_USER = 'admin at internal'
OVIRT_ENGINE_PASSWORD = 'password'

url = 'http://%s:%s' % (OVIRT_ENGINE_SERVER, OVIRT_ENGINE_PORT)
api = API(url = url, username = OVIRT_ENGINE_USER , password = OVIRT_ENGINE_PASSWORD)

host = 'host1'
if_name = 'eth4'
net_name = 'net1'
nic = api.hosts.get(name=host).nics.get(name=if_name)
net = params.Network(name=net_name)
act = params.Action(network=net)
nic.detach(act)
api.hosts.get(name=host).commitnetconfig()

Thanks,
Itzik


From lpeer at redhat.com  Sun Apr 29 09:40:50 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Sun, 29 Apr 2012 12:40:50 +0300
Subject: [Engine-devel] Disk Cloning When Creating a VM via a Template
In-Reply-To: <0A1534657992624AACDCA570F1D3E20003C29F05@SACEXCMBX03-PRD.hq.netapp.com>
References: <0A1534657992624AACDCA570F1D3E20003C29F05@SACEXCMBX03-PRD.hq.netapp.com>
Message-ID: <4F9D0CA2.6070006@redhat.com>

On 26/04/12 22:24, Schoenbrun, Dustin wrote:
> I know that floating disks are coming in the next version of oVirt, but
> in the interim I want to know internally what the procedure is when a
> disk is cloned when creating a VM from a template.
> 

Hi,

Today when creating a VM from template the user can choose the
provisioning method:
- It can be 'Thin' in which the engine is taking a snapshot of the
template disks (running AddVMCommand which executes
CreateSnapshotFromTemplateCommand)
- Or 'Clone' which results in cloning the template disks (executes
AddVmFromTemplateCommand which in turn executes
CreateCloneOfTemplateCommand)


Thanks, Livnat


From abaron at redhat.com  Sun Apr 29 10:24:34 2012
From: abaron at redhat.com (Ayal Baron)
Date: Sun, 29 Apr 2012 06:24:34 -0400 (EDT)
Subject: [Engine-devel] Disk Cloning When Creating a VM via a Template
In-Reply-To: <4F9D0CA2.6070006@redhat.com>
Message-ID: <4d827afc-97e6-48d6-9cf1-2c5a6e2e84d6@zmail13.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> On 26/04/12 22:24, Schoenbrun, Dustin wrote:
> > I know that floating disks are coming in the next version of oVirt,
> > but
> > in the interim I want to know internally what the procedure is when
> > a
> > disk is cloned when creating a VM from a template.

I'm not sure what floating disks have to do with it (it would be relevant for cloning a single disk, not cloning an entire VM).
For cloning a single disk I believe that floating disk is already available in master by the way.

> > 
> 
> Hi,
> 
> Today when creating a VM from template the user can choose the
> provisioning method:
> - It can be 'Thin' in which the engine is taking a snapshot of the
> template disks (running AddVMCommand which executes
> CreateSnapshotFromTemplateCommand)
> - Or 'Clone' which results in cloning the template disks (executes
> AddVmFromTemplateCommand which in turn executes
> CreateCloneOfTemplateCommand)

For createCloneOfTemplateCommand, other than the VM configuration being copied, the engine creates copies of all of the template images (calls moveImage in vdsm per Image).


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


From oschreib at redhat.com  Sun Apr 29 11:33:46 2012
From: oschreib at redhat.com (Ofer Schreiber)
Date: Sun, 29 Apr 2012 07:33:46 -0400 (EDT)
Subject: [Engine-devel] Updating ovirt engine from 3.0 to the 3.1.0
	version
In-Reply-To: <4F9ACDD4.3080609@linux.vnet.ibm.com>
Message-ID: <acdee83f-1465-4347-8c0b-e154d832df9a@zmail14.collab.prod.int.phx2.redhat.com>

I need more info about this:
1. It looks like a clean install (DB created from scratch). why do you call it an upgrade?
2. Do you see any error in JBoss/engine logs? (/var/log/jboss-as and /var/log/ovirt-engine usually)
3. Any error in the httpd log?
4. What happens if you stop iptables and access your server with :8080?

Thanks,
Ofer

----- Original Message -----
> Hi,
>    I built a set of ovirt engine RPM packages from near the latest
>    ovirt
> engine source code.  However, when I try to access the engine server
> with URL "http://ovirt-engine-112:80", the browser displayed a blank
> page without http error returned.  Any clue about what is going on
> here?
> Why didn't the engine administrator home page be shown?
> 
> 
> And the packages were also installed successfully in my target
> system,
> checked this by "rpm -q -a|grep engine".
>   I) upgraded the packages to the 3.1
> 
> [root at ovirt-engine-112 ~]# rpm -q -a |grep engine
> ovirt-engine-restapi-3.1.0_0001-1.8.fc16.x86_64
> ovirt-engine-dbscripts-3.1.0_0001-1.8.fc16.x86_64
> ovirt-engine-log-collector-3.0.0_0001-1.6.fc16.x86_64
> ovirt-engine-genericapi-3.1.0_0001-1.8.fc16.x86_64
> ovirt-engine-backend-3.1.0_0001-1.8.fc16.x86_64
> ovirt-engine-setup-3.1.0_0001-1.8.fc16.x86_64
> ovirt-engine-jbossas-1.2-2.fc16.x86_64
> ovirt-engine-jboss-deps-3.1.0_0001-1.8.fc16.x86_64
> ovirt-engine-config-3.1.0_0001-1.8.fc16.x86_64
> ovirt-engine-3.1.0_0001-1.8.fc16.x86_64
> ovirt-engine-webadmin-portal-3.1.0_0001-1.8.fc16.x86_64
> ovirt-engine-userportal-3.1.0_0001-1.8.fc16.x86_64
> ovirt-engine-tools-common-3.1.0_0001-1.8.fc16.x86_64
> ovirt-engine-image-uploader-3.1.0_0001-1.8.fc16.x86_64
> ovirt-engine-notification-service-3.1.0_0001-1.8.fc16.x86_64
> ovirt-engine-iso-uploader-3.1.0_0001-1.8.fc16.x86_64
> gtk2-engines-2.20.2-2.fc15.x86_64
> 
> Step II)
>     Then I used "engine-setup" to setup the engine.  It seems that
> everything is ok, see the log below.
> 
> -------------
> [root at ovirt-engine-112 ~]# engine-setup
> Welcome to oVirt Engine setup utility
> HTTP Port  [80] :
> HTTPS Port  [443] :
> Host fully qualified domain name, note that this name should be fully
> resolvable  [ovirt-engine-112] :
> ERROR: domain is not a valid domain name
> User input failed validation, do you still wish to use it? (yes|no):
> yes
> Password for Administrator (admin at internal) :
> Warning: Weak Password.
> Confirm password :
> Organization Name for the Certificate: cstl
> The default storage type you will be using  ['NFS'| 'FC'| 'ISCSI']
>  [NFS] :
> Enter DB type for installation ['remote'| 'local']  [local] :
> Local database password :
> Warning: Weak Password.
> Confirm password :
> Should the installer configure NFS share on this server to be used as
> an
> ISO Domain? ['yes'| 'no']  [yes] :
> Mount point path: /iso-dom
> ERROR: mount point already exists in /etc/exports
> Mount point path: /iso-dom
> Display name for the ISO Domain: iso-domains
> Firewall ports need to be opened.
> You can let the installer configure iptables automatically overriding
> the current configuration. The old configuration will be backed up.
> Alternately you can configure the firewall later using an example
> iptables file found under
> /usr/share/ovirt-engine/conf/iptables.example
> Configure iptables ? ['yes'| 'no']: yes
> 
> oVirt Engine will be installed using the following configuration:
> =================================================================
> http-port:                     80
> https-port:                    443
> host-fqdn:                     ovirt-engine-112
> auth-pass:                     ********
> org-name:                      cstl
> default-dc-type:               NFS
> db-remote-install:             local
> db-local-pass:                 ********
> nfs-mp:                        /iso-dom
> iso-domain-name:               iso-domains
> config-nfs:                    yes
> override-iptables:             yes
> Proceed with the configuration listed above? (yes|no): yes
> 
> Installing:
> Configuring oVirt-engine...                              [ DONE ]
> Creating CA...                                           [ DONE ]
> Editing JBoss Configuration...                           [ DONE ]
> Setting Database Configuration...                        [ DONE ]
> Setting Database Security...                             [ DONE ]
> Creating Database...                                     [ DONE ]
> Updating the Default Data Center Storage Type...         [ DONE ]
> Editing oVirt Engine Configuration...                    [ DONE ]
> Editing Postgresql Configuration...                      [ DONE ]
> Configuring the Default ISO Domain...                    [ DONE ]
> Configuring Firewall (iptables)...                       [ DONE ]
> Starting JBoss Service...                                [ DONE ]
> Handling HTTPD...                                        [ DONE ]
> 
>   **** Installation completed successfully ******
> 
>       (Please allow oVirt Engine a few moments to start up.....)
> 
> 
> Additional information:
>   * SSL Certificate fingerprint:
> C6:01:83:93:4B:2C:2A:38:65:C8:49:C9:17:34:FE:4B:1C:10:D5:FF
>   * SSH Public key fingerprint:
> 69:8c:bd:05:43:17:0a:43:a3:cc:62:7e:f7:be:0c:42
>   * A default ISO share has been created on this host.
>     If IP based access restrictions are required, please edit
>     /iso-dom
> entry in /etc/exports
>   * The firewall has been updated, the old iptables configuration
>   file
> was saved to
> /usr/share/ovirt-engine/conf/iptables.backup.011513-04282012_2225
>   * The installation log file is available at:
> /var/log/ovirt-engine/engine-setup_2012_04_28_01_13_01.log
>   * Please use the user "admin" and password specified in order to
>   login
> into oVirt Engine
>   * To configure additional users, first configure authentication
> domains using the 'engine-manage-domains' utility
>   * To access oVirt Engine please go to the following URL:
> http://ovirt-engine-112:80
> [root at ovirt-engine-112 ~]#
> 
> 
> --
> Shu Ming<shuming at linux.vnet.ibm.com>
> IBM China Systems and Technology Laboratory
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From lhornyak at redhat.com  Sun Apr 29 12:03:35 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Sun, 29 Apr 2012 08:03:35 -0400 (EDT)
Subject: [Engine-devel] +1 in gerrit
In-Reply-To: <f6c9ff6a-1b66-4458-aeb7-c621255297d0@zmail01.collab.prod.int.phx2.redhat.com>
Message-ID: <4a2d11ca-b9ce-46e7-92c4-b47e50f0ca36@zmail01.collab.prod.int.phx2.redhat.com>

Hi,

Just an idea for the gerrit reviews: if you review a patch and give "+1 Looks good to me, but someone else must approve", then please add someone as reviewer, who might be the right person. And then after a while the patch will get to someone who knows if the patch is good or not.

Laszlo


From emesika at redhat.com  Sun Apr 29 12:22:01 2012
From: emesika at redhat.com (Eli Mesika)
Date: Sun, 29 Apr 2012 08:22:01 -0400 (EDT)
Subject: [Engine-devel] +1 in gerrit
In-Reply-To: <4a2d11ca-b9ce-46e7-92c4-b47e50f0ca36@zmail01.collab.prod.int.phx2.redhat.com>
Message-ID: <44b78b28-1f37-4e2a-a8ed-208e407d4f67@zmail13.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, April 29, 2012 3:03:35 PM
> Subject: [Engine-devel] +1 in gerrit
> 
> Hi,
> 
> Just an idea for the gerrit reviews: if you review a patch and give
> "+1 Looks good to me, but someone else must approve", then please
> add someone as reviewer, who might be the right person. And then
> after a while the patch will get to someone who knows if the patch
> is good or not.

+1 (but someone else must approve ;-))
> 
> Laszlo
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From lpeer at redhat.com  Sun Apr 29 12:43:52 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Sun, 29 Apr 2012 15:43:52 +0300
Subject: [Engine-devel] +1 in gerrit
In-Reply-To: <44b78b28-1f37-4e2a-a8ed-208e407d4f67@zmail13.collab.prod.int.phx2.redhat.com>
References: <44b78b28-1f37-4e2a-a8ed-208e407d4f67@zmail13.collab.prod.int.phx2.redhat.com>
Message-ID: <4F9D3788.5080208@redhat.com>

On 29/04/12 15:22, Eli Mesika wrote:
> 
> 
> ----- Original Message -----
>> From: "Laszlo Hornyak" <lhornyak at redhat.com>
>> To: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Sunday, April 29, 2012 3:03:35 PM
>> Subject: [Engine-devel] +1 in gerrit
>>
>> Hi,
>>
>> Just an idea for the gerrit reviews: if you review a patch and give
>> "+1 Looks good to me, but someone else must approve", then please
>> add someone as reviewer, who might be the right person. And then
>> after a while the patch will get to someone who knows if the patch
>> is good or not.
> 
> +1 (but someone else must approve ;-))

+1, if you give +1 it would be nice to add who you think should be able
to +2.

>>
>> 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 ovedo at redhat.com  Sun Apr 29 13:23:49 2012
From: ovedo at redhat.com (Oved Ourfalli)
Date: Sun, 29 Apr 2012 09:23:49 -0400 (EDT)
Subject: [Engine-devel] Moving oVirt engine to Jboss AS 7.1.1
In-Reply-To: <536d1da9-044b-4e87-ac2b-671f78daad83@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <1828c694-7a05-4f45-a464-cb1f4ea9e13c@zmail02.collab.prod.int.phx2.redhat.com>

Hey all,

We have pushed patches that make the necessary adjustments to allow working with the newest Jboss version, Jboss AS 7.1.1 Final.

After fetching please do the following:
* Download Jboss AS 7.1.1.Final from http://download.jboss.org/jbossas/7.1/jboss-as-7.1.1.Final/jboss-as-7.1.1.Final.tar.gz
* Change the JBOSS_HOME wherever you defined it.
* Change the Jboss Home in ~/.m2/settings.xml.
* Run a full build, including setup: mvn clean install -DskipTests -Psetup,dep (consider using flags -Dgwt.userAgent=gecko1_8 and -Dgwt.draftCompile=true to avoid compiling GWT on all permutations).
* Run jboss as usual.

If you have any issues, reply here and we'll do anything to help.

The oVirt engine wiki page (http://www.ovirt.org/wiki/Building_oVirt_engine) was changes accordingly.

Thank you,
Oved



From gkotton at redhat.com  Sun Apr 29 10:41:24 2012
From: gkotton at redhat.com (Gary Kotton)
Date: Sun, 29 Apr 2012 13:41:24 +0300
Subject: [Engine-devel] oVirt and Quantum
Message-ID: <4F9D1AD4.8070503@redhat.com>

Hi,

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




From shuming at linux.vnet.ibm.com  Sun Apr 29 15:54:26 2012
From: shuming at linux.vnet.ibm.com (Shu Ming)
Date: Sun, 29 Apr 2012 23:54:26 +0800
Subject: [Engine-devel] Updating ovirt engine from 3.0 to the 3.1.0
	version
In-Reply-To: <acdee83f-1465-4347-8c0b-e154d832df9a@zmail14.collab.prod.int.phx2.redhat.com>
References: <acdee83f-1465-4347-8c0b-e154d832df9a@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <4F9D6432.8060205@linux.vnet.ibm.com>

On 2012-4-29 19:33, Ofer Schreiber wrote:
> I need more info about this:
> 1. It looks like a clean install (DB created from scratch). why do you call it an upgrade?

Sorry for confusion here.  I used engine-cleanup and ran engine-setup 
again after the 3.1 RPM package were installed.

> 2. Do you see any error in JBoss/engine logs? (/var/log/jboss-as and /var/log/ovirt-engine usually)
[root at ovirt-engine-112 ~]# cat /var/log/jboss-as/console.log

01:15:16,901 INFO  [org.jboss.as] (Controller Boot Thread) JBoss AS 
7.1.0.Beta1b "Tesla" started in 2405ms - Started 140 of 203 services (61 
services are passive or on-demand)
01:15:17,207 INFO  [org.jboss.as.server.deployment.scanner] 
(DeploymentScanner-threads - 1) JBAS015014: Re-attempting failed 
deployment engine.ear
01:15:17,431 INFO  [org.jboss.as.server.deployment.scanner] 
(DeploymentScanner-threads - 1) JBAS015014: Re-attempting failed 
deployment ROOT.war
01:15:17,432 INFO  [org.jboss.as.server.deployment.scanner] 
(DeploymentScanner-threads - 1) JBAS015003: Found ROOT.war in deployment 
directory. To trigger deployment create a file called ROOT.war.dodeploy
01:15:17,432 INFO  [org.jboss.as.server.deployment.scanner] 
(DeploymentScanner-threads - 1) JBAS015003: Found engine.ear in 
deployment directory. To trigger deployment create a file called 
engine.ear.dodeploy
01:15:17,478 ERROR [org.jboss.as.controller] (DeploymentScanner-threads 
- 2) JBAS014612: Operation ("add") failed - address: ([("deployment" => 
"engine.ear")]): java.lang.IllegalStateException: JBAS014666: Duplicate 
resource [("deployment" => "engine.ear")]
         at 
org.jboss.as.controller.OperationContextImpl.addResource(OperationContextImpl.java:503) 
[jboss-as-controller-7.1.0.Beta1b.jar:]
         at 
org.jboss.as.controller.OperationContextImpl.createResource(OperationContextImpl.java:471) 
[jboss-as-controller-7.1.0.Beta1b.jar:]
         at 
org.jboss.as.server.deployment.DeploymentAddHandler.execute(DeploymentAddHandler.java:170)
....

         at java.util.concurrent.FutureTask.run(FutureTask.java:166) 
[:1.6.0_24]
         at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165) 
[:1.6.0_24]
         at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266) 
[:1.6.0_24]
         at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) 
[:1.6.0_24]
         at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) 
[:1.6.0_24]
         at java.lang.Thread.run(Thread.java:679) [:1.6.0_24]
         at org.jboss.threads.JBossThread.run(JBossThread.java:122) 
[jboss-threads-2.0.0.GA.jar:]

01:15:17,482 ERROR [org.jboss.as.server.deployment.scanner] 
(DeploymentScanner-threads - 1) JBAS014654: Composite operation was 
rolled back
01:15:17,483 ERROR [org.jboss.as.server.deployment.scanner] 
(DeploymentScanner-threads - 1) JBAS014654: Composite operation was 
rolled back
01:15:17,483 ERROR [org.jboss.as.server.deployment.scanner] 
(DeploymentScanner-threads - 1) {"JBAS014653: Composite operation failed 
and was rolled back. Steps that failed:" => {"Operation step-1" => 
"JBAS014749: Operation handler failed: JBAS014666: Duplicate resource 
[(\"deployment\" => \"engine.ear\")]"}}
01:15:17,483 ERROR [org.jboss.as.server.deployment.scanner] 
(DeploymentScanner-threads - 1) undefined



> 3. Any error in the httpd log?


[root at ovirt-engine-112 ~]# cat /var/log/httpd/access_log
9.181.193.205 - - [30/Apr/2012:00:28:27 +0800] "GET / HTTP/1.0" 404 - 
"-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28) 
Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)"
9.181.193.205 - - [30/Apr/2012:00:28:44 +0800] "GET /favicon.ico 
HTTP/1.0" 404 - "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; 
rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)"
9.181.193.205 - - [30/Apr/2012:00:28:44 +0800] "GET /favicon.ico 
HTTP/1.0" 404 - "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; 
rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)"
9.181.193.205 - - [30/Apr/2012:00:28:54 +0800] "GET / HTTP/1.0" 404 - 
"-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28) 
Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)"
9.181.193.205 - - [30/Apr/2012:00:28:55 +0800] "GET /favicon.ico 
HTTP/1.0" 404 - "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; 
rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)"
[root at ovirt-engine-112 ~]#

[root at ovirt-engine-112 ~]# cat /var/log/httpd/error_log
[Sun Apr 29 03:36:02 2012] [notice] Digest: generating secret for digest 
authentication ...
[Sun Apr 29 03:36:02 2012] [notice] Digest: done
[Sun Apr 29 03:36:02 2012] [notice] SSL FIPS mode disabled
[Sun Apr 29 03:36:02 2012] [notice] Apache/2.2.22 (Unix) DAV/2 
mod_ssl/2.2.22 OpenSSL/1.0.0h-fips configured -- resuming normal operations
[root at ovirt-engine-112 ~]#



> 4. What happens if you stop iptables and access your server with :8080?

The same as before.

>
> Thanks,
> Ofer
>
> ----- Original Message -----
>> Hi,
>>     I built a set of ovirt engine RPM packages from near the latest
>>     ovirt
>> engine source code.  However, when I try to access the engine server
>> with URL "http://ovirt-engine-112:80", the browser displayed a blank
>> page without http error returned.  Any clue about what is going on
>> here?
>> Why didn't the engine administrator home page be shown?
>>
>>
>> And the packages were also installed successfully in my target
>> system,
>> checked this by "rpm -q -a|grep engine".
>>    I) upgraded the packages to the 3.1
>>
>> [root at ovirt-engine-112 ~]# rpm -q -a |grep engine
>> ovirt-engine-restapi-3.1.0_0001-1.8.fc16.x86_64
>> ovirt-engine-dbscripts-3.1.0_0001-1.8.fc16.x86_64
>> ovirt-engine-log-collector-3.0.0_0001-1.6.fc16.x86_64
>> ovirt-engine-genericapi-3.1.0_0001-1.8.fc16.x86_64
>> ovirt-engine-backend-3.1.0_0001-1.8.fc16.x86_64
>> ovirt-engine-setup-3.1.0_0001-1.8.fc16.x86_64
>> ovirt-engine-jbossas-1.2-2.fc16.x86_64
>> ovirt-engine-jboss-deps-3.1.0_0001-1.8.fc16.x86_64
>> ovirt-engine-config-3.1.0_0001-1.8.fc16.x86_64
>> ovirt-engine-3.1.0_0001-1.8.fc16.x86_64
>> ovirt-engine-webadmin-portal-3.1.0_0001-1.8.fc16.x86_64
>> ovirt-engine-userportal-3.1.0_0001-1.8.fc16.x86_64
>> ovirt-engine-tools-common-3.1.0_0001-1.8.fc16.x86_64
>> ovirt-engine-image-uploader-3.1.0_0001-1.8.fc16.x86_64
>> ovirt-engine-notification-service-3.1.0_0001-1.8.fc16.x86_64
>> ovirt-engine-iso-uploader-3.1.0_0001-1.8.fc16.x86_64
>> gtk2-engines-2.20.2-2.fc15.x86_64
>>
>> Step II)
>>      Then I used "engine-setup" to setup the engine.  It seems that
>> everything is ok, see the log below.
>>
>> -------------
>> [root at ovirt-engine-112 ~]# engine-setup
>> Welcome to oVirt Engine setup utility
>> HTTP Port  [80] :
>> HTTPS Port  [443] :
>> Host fully qualified domain name, note that this name should be fully
>> resolvable  [ovirt-engine-112] :
>> ERROR: domain is not a valid domain name
>> User input failed validation, do you still wish to use it? (yes|no):
>> yes
>> Password for Administrator (admin at internal) :
>> Warning: Weak Password.
>> Confirm password :
>> Organization Name for the Certificate: cstl
>> The default storage type you will be using  ['NFS'| 'FC'| 'ISCSI']
>>   [NFS] :
>> Enter DB type for installation ['remote'| 'local']  [local] :
>> Local database password :
>> Warning: Weak Password.
>> Confirm password :
>> Should the installer configure NFS share on this server to be used as
>> an
>> ISO Domain? ['yes'| 'no']  [yes] :
>> Mount point path: /iso-dom
>> ERROR: mount point already exists in /etc/exports
>> Mount point path: /iso-dom
>> Display name for the ISO Domain: iso-domains
>> Firewall ports need to be opened.
>> You can let the installer configure iptables automatically overriding
>> the current configuration. The old configuration will be backed up.
>> Alternately you can configure the firewall later using an example
>> iptables file found under
>> /usr/share/ovirt-engine/conf/iptables.example
>> Configure iptables ? ['yes'| 'no']: yes
>>
>> oVirt Engine will be installed using the following configuration:
>> =================================================================
>> http-port:                     80
>> https-port:                    443
>> host-fqdn:                     ovirt-engine-112
>> auth-pass:                     ********
>> org-name:                      cstl
>> default-dc-type:               NFS
>> db-remote-install:             local
>> db-local-pass:                 ********
>> nfs-mp:                        /iso-dom
>> iso-domain-name:               iso-domains
>> config-nfs:                    yes
>> override-iptables:             yes
>> Proceed with the configuration listed above? (yes|no): yes
>>
>> Installing:
>> Configuring oVirt-engine...                              [ DONE ]
>> Creating CA...                                           [ DONE ]
>> Editing JBoss Configuration...                           [ DONE ]
>> Setting Database Configuration...                        [ DONE ]
>> Setting Database Security...                             [ DONE ]
>> Creating Database...                                     [ DONE ]
>> Updating the Default Data Center Storage Type...         [ DONE ]
>> Editing oVirt Engine Configuration...                    [ DONE ]
>> Editing Postgresql Configuration...                      [ DONE ]
>> Configuring the Default ISO Domain...                    [ DONE ]
>> Configuring Firewall (iptables)...                       [ DONE ]
>> Starting JBoss Service...                                [ DONE ]
>> Handling HTTPD...                                        [ DONE ]
>>
>>    **** Installation completed successfully ******
>>
>>        (Please allow oVirt Engine a few moments to start up.....)
>>
>>
>> Additional information:
>>    * SSL Certificate fingerprint:
>> C6:01:83:93:4B:2C:2A:38:65:C8:49:C9:17:34:FE:4B:1C:10:D5:FF
>>    * SSH Public key fingerprint:
>> 69:8c:bd:05:43:17:0a:43:a3:cc:62:7e:f7:be:0c:42
>>    * A default ISO share has been created on this host.
>>      If IP based access restrictions are required, please edit
>>      /iso-dom
>> entry in /etc/exports
>>    * The firewall has been updated, the old iptables configuration
>>    file
>> was saved to
>> /usr/share/ovirt-engine/conf/iptables.backup.011513-04282012_2225
>>    * The installation log file is available at:
>> /var/log/ovirt-engine/engine-setup_2012_04_28_01_13_01.log
>>    * Please use the user "admin" and password specified in order to
>>    login
>> into oVirt Engine
>>    * To configure additional users, first configure authentication
>> domains using the 'engine-manage-domains' utility
>>    * To access oVirt Engine please go to the following URL:
>> http://ovirt-engine-112:80
>> [root at ovirt-engine-112 ~]#
>>
>>
>> --
>> Shu Ming<shuming at linux.vnet.ibm.com>
>> IBM China Systems and Technology Laboratory
>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>


-- 
Shu Ming<shuming at linux.vnet.ibm.com>
IBM China Systems and Technology Laboratory




From oschreib at redhat.com  Mon Apr 30 07:22:52 2012
From: oschreib at redhat.com (Ofer Schreiber)
Date: Mon, 30 Apr 2012 03:22:52 -0400 (EDT)
Subject: [Engine-devel] Updating ovirt engine from 3.0 to the 3.1.0
	version
In-Reply-To: <4F9D6432.8060205@linux.vnet.ibm.com>
Message-ID: <8faf07bc-015d-439d-b403-8d3d216b58ad@zmail14.collab.prod.int.phx2.redhat.com>

Looks like something went wrong with the .ear deployment. (already saw such an issue in http://lists.ovirt.org/pipermail/engine-devel/2012-January/000483.html)

Can you please:
1. Stop JBoss
2. Make sure jboss deployment directory contain a single engine.ear
  - Remove engine.ear.failed (or similar files if exists)
3. Start JBoss again

----- Original Message -----
> On 2012-4-29 19:33, Ofer Schreiber wrote:
> > I need more info about this:
> > 1. It looks like a clean install (DB created from scratch). why do
> > you call it an upgrade?
> 
> Sorry for confusion here.  I used engine-cleanup and ran engine-setup
> again after the 3.1 RPM package were installed.
> 
> > 2. Do you see any error in JBoss/engine logs? (/var/log/jboss-as
> > and /var/log/ovirt-engine usually)
> [root at ovirt-engine-112 ~]# cat /var/log/jboss-as/console.log
> 
> 01:15:16,901 INFO  [org.jboss.as] (Controller Boot Thread) JBoss AS
> 7.1.0.Beta1b "Tesla" started in 2405ms - Started 140 of 203 services
> (61
> services are passive or on-demand)
> 01:15:17,207 INFO  [org.jboss.as.server.deployment.scanner]
> (DeploymentScanner-threads - 1) JBAS015014: Re-attempting failed
> deployment engine.ear
> 01:15:17,431 INFO  [org.jboss.as.server.deployment.scanner]
> (DeploymentScanner-threads - 1) JBAS015014: Re-attempting failed
> deployment ROOT.war
> 01:15:17,432 INFO  [org.jboss.as.server.deployment.scanner]
> (DeploymentScanner-threads - 1) JBAS015003: Found ROOT.war in
> deployment
> directory. To trigger deployment create a file called
> ROOT.war.dodeploy
> 01:15:17,432 INFO  [org.jboss.as.server.deployment.scanner]
> (DeploymentScanner-threads - 1) JBAS015003: Found engine.ear in
> deployment directory. To trigger deployment create a file called
> engine.ear.dodeploy
> 01:15:17,478 ERROR [org.jboss.as.controller]
> (DeploymentScanner-threads
> - 2) JBAS014612: Operation ("add") failed - address: ([("deployment"
> =>
> "engine.ear")]): java.lang.IllegalStateException: JBAS014666:
> Duplicate
> resource [("deployment" => "engine.ear")]
>          at
> org.jboss.as.controller.OperationContextImpl.addResource(OperationContextImpl.java:503)
> [jboss-as-controller-7.1.0.Beta1b.jar:]
>          at
> org.jboss.as.controller.OperationContextImpl.createResource(OperationContextImpl.java:471)
> [jboss-as-controller-7.1.0.Beta1b.jar:]
>          at
> org.jboss.as.server.deployment.DeploymentAddHandler.execute(DeploymentAddHandler.java:170)
> ....
> 
>          at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> [:1.6.0_24]
>          at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
> [:1.6.0_24]
>          at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> [:1.6.0_24]
>          at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> [:1.6.0_24]
>          at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> [:1.6.0_24]
>          at java.lang.Thread.run(Thread.java:679) [:1.6.0_24]
>          at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> [jboss-threads-2.0.0.GA.jar:]
> 
> 01:15:17,482 ERROR [org.jboss.as.server.deployment.scanner]
> (DeploymentScanner-threads - 1) JBAS014654: Composite operation was
> rolled back
> 01:15:17,483 ERROR [org.jboss.as.server.deployment.scanner]
> (DeploymentScanner-threads - 1) JBAS014654: Composite operation was
> rolled back
> 01:15:17,483 ERROR [org.jboss.as.server.deployment.scanner]
> (DeploymentScanner-threads - 1) {"JBAS014653: Composite operation
> failed
> and was rolled back. Steps that failed:" => {"Operation step-1" =>
> "JBAS014749: Operation handler failed: JBAS014666: Duplicate resource
> [(\"deployment\" => \"engine.ear\")]"}}
> 01:15:17,483 ERROR [org.jboss.as.server.deployment.scanner]
> (DeploymentScanner-threads - 1) undefined
> 
> 
> 
> > 3. Any error in the httpd log?
> 
> 
> [root at ovirt-engine-112 ~]# cat /var/log/httpd/access_log
> 9.181.193.205 - - [30/Apr/2012:00:28:27 +0800] "GET / HTTP/1.0" 404 -
> "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28)
> Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)"
> 9.181.193.205 - - [30/Apr/2012:00:28:44 +0800] "GET /favicon.ico
> HTTP/1.0" 404 - "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
> rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)"
> 9.181.193.205 - - [30/Apr/2012:00:28:44 +0800] "GET /favicon.ico
> HTTP/1.0" 404 - "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
> rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)"
> 9.181.193.205 - - [30/Apr/2012:00:28:54 +0800] "GET / HTTP/1.0" 404 -
> "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28)
> Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)"
> 9.181.193.205 - - [30/Apr/2012:00:28:55 +0800] "GET /favicon.ico
> HTTP/1.0" 404 - "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
> rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)"
> [root at ovirt-engine-112 ~]#
> 
> [root at ovirt-engine-112 ~]# cat /var/log/httpd/error_log
> [Sun Apr 29 03:36:02 2012] [notice] Digest: generating secret for
> digest
> authentication ...
> [Sun Apr 29 03:36:02 2012] [notice] Digest: done
> [Sun Apr 29 03:36:02 2012] [notice] SSL FIPS mode disabled
> [Sun Apr 29 03:36:02 2012] [notice] Apache/2.2.22 (Unix) DAV/2
> mod_ssl/2.2.22 OpenSSL/1.0.0h-fips configured -- resuming normal
> operations
> [root at ovirt-engine-112 ~]#
> 
> 
> 
> > 4. What happens if you stop iptables and access your server with
> > :8080?
> 
> The same as before.
> 
> >
> > Thanks,
> > Ofer
> >
> > ----- Original Message -----
> >> Hi,
> >>     I built a set of ovirt engine RPM packages from near the
> >>     latest
> >>     ovirt
> >> engine source code.  However, when I try to access the engine
> >> server
> >> with URL "http://ovirt-engine-112:80", the browser displayed a
> >> blank
> >> page without http error returned.  Any clue about what is going on
> >> here?
> >> Why didn't the engine administrator home page be shown?
> >>
> >>
> >> And the packages were also installed successfully in my target
> >> system,
> >> checked this by "rpm -q -a|grep engine".
> >>    I) upgraded the packages to the 3.1
> >>
> >> [root at ovirt-engine-112 ~]# rpm -q -a |grep engine
> >> ovirt-engine-restapi-3.1.0_0001-1.8.fc16.x86_64
> >> ovirt-engine-dbscripts-3.1.0_0001-1.8.fc16.x86_64
> >> ovirt-engine-log-collector-3.0.0_0001-1.6.fc16.x86_64
> >> ovirt-engine-genericapi-3.1.0_0001-1.8.fc16.x86_64
> >> ovirt-engine-backend-3.1.0_0001-1.8.fc16.x86_64
> >> ovirt-engine-setup-3.1.0_0001-1.8.fc16.x86_64
> >> ovirt-engine-jbossas-1.2-2.fc16.x86_64
> >> ovirt-engine-jboss-deps-3.1.0_0001-1.8.fc16.x86_64
> >> ovirt-engine-config-3.1.0_0001-1.8.fc16.x86_64
> >> ovirt-engine-3.1.0_0001-1.8.fc16.x86_64
> >> ovirt-engine-webadmin-portal-3.1.0_0001-1.8.fc16.x86_64
> >> ovirt-engine-userportal-3.1.0_0001-1.8.fc16.x86_64
> >> ovirt-engine-tools-common-3.1.0_0001-1.8.fc16.x86_64
> >> ovirt-engine-image-uploader-3.1.0_0001-1.8.fc16.x86_64
> >> ovirt-engine-notification-service-3.1.0_0001-1.8.fc16.x86_64
> >> ovirt-engine-iso-uploader-3.1.0_0001-1.8.fc16.x86_64
> >> gtk2-engines-2.20.2-2.fc15.x86_64
> >>
> >> Step II)
> >>      Then I used "engine-setup" to setup the engine.  It seems
> >>      that
> >> everything is ok, see the log below.
> >>
> >> -------------
> >> [root at ovirt-engine-112 ~]# engine-setup
> >> Welcome to oVirt Engine setup utility
> >> HTTP Port  [80] :
> >> HTTPS Port  [443] :
> >> Host fully qualified domain name, note that this name should be
> >> fully
> >> resolvable  [ovirt-engine-112] :
> >> ERROR: domain is not a valid domain name
> >> User input failed validation, do you still wish to use it?
> >> (yes|no):
> >> yes
> >> Password for Administrator (admin at internal) :
> >> Warning: Weak Password.
> >> Confirm password :
> >> Organization Name for the Certificate: cstl
> >> The default storage type you will be using  ['NFS'| 'FC'| 'ISCSI']
> >>   [NFS] :
> >> Enter DB type for installation ['remote'| 'local']  [local] :
> >> Local database password :
> >> Warning: Weak Password.
> >> Confirm password :
> >> Should the installer configure NFS share on this server to be used
> >> as
> >> an
> >> ISO Domain? ['yes'| 'no']  [yes] :
> >> Mount point path: /iso-dom
> >> ERROR: mount point already exists in /etc/exports
> >> Mount point path: /iso-dom
> >> Display name for the ISO Domain: iso-domains
> >> Firewall ports need to be opened.
> >> You can let the installer configure iptables automatically
> >> overriding
> >> the current configuration. The old configuration will be backed
> >> up.
> >> Alternately you can configure the firewall later using an example
> >> iptables file found under
> >> /usr/share/ovirt-engine/conf/iptables.example
> >> Configure iptables ? ['yes'| 'no']: yes
> >>
> >> oVirt Engine will be installed using the following configuration:
> >> =================================================================
> >> http-port:                     80
> >> https-port:                    443
> >> host-fqdn:                     ovirt-engine-112
> >> auth-pass:                     ********
> >> org-name:                      cstl
> >> default-dc-type:               NFS
> >> db-remote-install:             local
> >> db-local-pass:                 ********
> >> nfs-mp:                        /iso-dom
> >> iso-domain-name:               iso-domains
> >> config-nfs:                    yes
> >> override-iptables:             yes
> >> Proceed with the configuration listed above? (yes|no): yes
> >>
> >> Installing:
> >> Configuring oVirt-engine...                              [ DONE ]
> >> Creating CA...                                           [ DONE ]
> >> Editing JBoss Configuration...                           [ DONE ]
> >> Setting Database Configuration...                        [ DONE ]
> >> Setting Database Security...                             [ DONE ]
> >> Creating Database...                                     [ DONE ]
> >> Updating the Default Data Center Storage Type...         [ DONE ]
> >> Editing oVirt Engine Configuration...                    [ DONE ]
> >> Editing Postgresql Configuration...                      [ DONE ]
> >> Configuring the Default ISO Domain...                    [ DONE ]
> >> Configuring Firewall (iptables)...                       [ DONE ]
> >> Starting JBoss Service...                                [ DONE ]
> >> Handling HTTPD...                                        [ DONE ]
> >>
> >>    **** Installation completed successfully ******
> >>
> >>        (Please allow oVirt Engine a few moments to start up.....)
> >>
> >>
> >> Additional information:
> >>    * SSL Certificate fingerprint:
> >> C6:01:83:93:4B:2C:2A:38:65:C8:49:C9:17:34:FE:4B:1C:10:D5:FF
> >>    * SSH Public key fingerprint:
> >> 69:8c:bd:05:43:17:0a:43:a3:cc:62:7e:f7:be:0c:42
> >>    * A default ISO share has been created on this host.
> >>      If IP based access restrictions are required, please edit
> >>      /iso-dom
> >> entry in /etc/exports
> >>    * The firewall has been updated, the old iptables configuration
> >>    file
> >> was saved to
> >> /usr/share/ovirt-engine/conf/iptables.backup.011513-04282012_2225
> >>    * The installation log file is available at:
> >> /var/log/ovirt-engine/engine-setup_2012_04_28_01_13_01.log
> >>    * Please use the user "admin" and password specified in order
> >>    to
> >>    login
> >> into oVirt Engine
> >>    * To configure additional users, first configure authentication
> >> domains using the 'engine-manage-domains' utility
> >>    * To access oVirt Engine please go to the following URL:
> >> http://ovirt-engine-112:80
> >> [root at ovirt-engine-112 ~]#
> >>
> >>
> >> --
> >> Shu Ming<shuming at linux.vnet.ibm.com>
> >> IBM China Systems and Technology Laboratory
> >>
> >>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> 
> 
> --
> Shu Ming<shuming at linux.vnet.ibm.com>
> IBM China Systems and Technology Laboratory
> 
> 
> 


From dlaor at redhat.com  Mon Apr 30 07:39:26 2012
From: dlaor at redhat.com (Dor Laor)
Date: Mon, 30 Apr 2012 10:39:26 +0300
Subject: [Engine-devel] oVirt and Quantum
In-Reply-To: <4F9D1AD4.8070503@redhat.com>
References: <4F9D1AD4.8070503@redhat.com>
Message-ID: <4F9E41AE.6030302@redhat.com>

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

Gary, would it be possible to compare the current major api verbs 
offered by Quantum vs the ones offered by oVirt?

It would be nice to review the length/feature-rich of each and also the 
ease of use.

In addition, what would be the todo items in order to get OVS working w/ 
oVirt?

Example for Quantum: 
http://docs.openstack.org/incubation/openstack-network/developer/quantum-api-1.0/content/Show_port_Details.html#d6e777

Cheers,
Dor

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



From simon at redhat.com  Mon Apr 30 11:37:33 2012
From: simon at redhat.com (Simon Grinberg)
Date: Mon, 30 Apr 2012 07:37:33 -0400 (EDT)
Subject: [Engine-devel] CPU topology in the API
In-Reply-To: <88cb0396-0c62-4b7f-8a9b-925cecc754b8@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <9db7249e-b92e-4fd8-aa6a-b50005e6743a@zmail17.collab.prod.int.phx2.redhat.com>

Hi list,

The current status is that though they look the same, CPU topology for hosts and VMs differ. 

In both you have    
    <topology cores="N" sockets="Y"/>

for hosts: Cores = Total cores on the host, Y=number of sockets 
for VMs: Cores = Cores per socket, Y=number of sockets

This means that for a hosts that has 4 sockets with 8 cores per socket the topology will be presented as:
    <topology cores="32" sockets="4"/>
While for VM with the same requested topology will show:
    <topology cores="8" sockets="4"/>

I think they should not be different to avoid confusion but:

* The information we displayed for the host can't count on the fact that cores are
distributed evenly across sockets, because theoretically a host could contain
several different CPUs, so it can't be displayed as a multiplication. 
* On the other hand changing the VM topology will break the API though it will make it aligned both with hosts and with the 'New VM' dialogue in the UI.

For oVirt 3.x it may be that nothing can be changed however for oVirt it is allowed in theory to break the API (a bit :)) so the options as I see it are:

1. Don't touch, leave the confusion. 
2. Make host align to VMs with the risk that on some hosts this may be a bit misleading - should be rare.
3. Make host topology looks like VM but allow multiple CPU topologies in the CPUs sub collection of the host. 
   (This also requires change in VDSM API)
4. Align VMs to Hosts

I would go for 4 or 2
Current CPU topology for the hosts is a new commit, thus it may be allowed to change it now since no one is using it yet. This works in favour of 2. In any case only 3 discloses all the information in all possible cases.  


Thoughts?


Thanks, 
Simon.
     


From dlaor at redhat.com  Mon Apr 30 11:43:45 2012
From: dlaor at redhat.com (Dor Laor)
Date: Mon, 30 Apr 2012 14:43:45 +0300
Subject: [Engine-devel] CPU topology in the API
In-Reply-To: <9db7249e-b92e-4fd8-aa6a-b50005e6743a@zmail17.collab.prod.int.phx2.redhat.com>
References: <9db7249e-b92e-4fd8-aa6a-b50005e6743a@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <4F9E7AF1.30809@redhat.com>

On 04/30/2012 02:37 PM, Simon Grinberg wrote:
> Hi list,
>
> The current status is that though they look the same, CPU topology for hosts and VMs differ.
>
> In both you have
>      <topology cores="N" sockets="Y"/>
>
> for hosts: Cores = Total cores on the host, Y=number of sockets
> for VMs: Cores = Cores per socket, Y=number of sockets
>
> This means that for a hosts that has 4 sockets with 8 cores per socket the topology will be presented as:
>      <topology cores="32" sockets="4"/>
> While for VM with the same requested topology will show:
>      <topology cores="8" sockets="4"/>
>
> I think they should not be different to avoid confusion but:
>
> * The information we displayed for the host can't count on the fact that cores are
> distributed evenly across sockets, because theoretically a host could contain
> several different CPUs, so it can't be displayed as a multiplication.

Isn't that rare to not-exist in the standard case?

> * On the other hand changing the VM topology will break the API though it will make it aligned both with hosts and with the 'New VM' dialogue in the UI.
>
> For oVirt 3.x it may be that nothing can be changed however for oVirt it is allowed in theory to break the API (a bit :)) so the options as I see it are:
>
> 1. Don't touch, leave the confusion.
> 2. Make host align to VMs with the risk that on some hosts this may be a bit misleading - should be rare.
> 3. Make host topology looks like VM but allow multiple CPU topologies in the CPUs sub collection of the host.
>     (This also requires change in VDSM API)
> 4. Align VMs to Hosts
>
> I would go for 4 or 2
> Current CPU topology for the hosts is a new commit, thus it may be allowed to change it now since no one is using it yet. This works in favour of 2. In any case only 3 discloses all the information in all possible cases.
>
>
> Thoughts?

If you touch any of this, please be prepared for the future:
  - Use hyperthreads (exists in kvm today)
  - Add numa topology for guest and the hosts
  - Add Cache info (for VMs too)
  - Add number of DIMMs, especially for VMs, for the upcoming memory hot
    plug feature.
  - BE ready for cpu/cpu/memory hotplug for the hosts and the guests.

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



From masayag at redhat.com  Mon Apr 30 11:44:16 2012
From: masayag at redhat.com (Moti Asayag)
Date: Mon, 30 Apr 2012 14:44:16 +0300
Subject: [Engine-devel] signed-off-by in commit message
In-Reply-To: <4F96C2BD.90309@redhat.com>
References: <4F96C2BD.90309@redhat.com>
Message-ID: <4F9E7B10.6090300@redhat.com>

On 04/24/2012 06:11 PM, Itamar Heim wrote:
> per previous thread by Ryan Harper[1] and ovirt meeting today, starting
> may 1st gerrit policy will change for all projects to require
> signed-off-by in the commit message.
> 

You may add the "Signed-off-by" field by adding "-s" flag to the "git
commit" command, either by specifying it for each commit command or by
setting it as an alias in the .git/config

e.g. for ovirt-engine:

[alias]
    cm=commit -s -F config/engine-commit-template.txt -e

> vdsm and ovirt-node already have this active
> 
> Thanks,
>    Itamar
> 
> for more details:
> http://kerneltrap.org/files/Jeremy/DCO.txt
> 
> [1]http://www.mail-archive.com/arch at ovirt.org/msg00273.html
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra



From ovedo at redhat.com  Mon Apr 30 11:50:30 2012
From: ovedo at redhat.com (Oved Ourfalli)
Date: Mon, 30 Apr 2012 07:50:30 -0400 (EDT)
Subject: [Engine-devel] signed-off-by in commit message
In-Reply-To: <4F9E7B10.6090300@redhat.com>
Message-ID: <0d822769-59e4-448c-9891-40503512a242@zmail02.collab.prod.int.phx2.redhat.com>

----- Original Message -----
> From: "Moti Asayag" <masayag at redhat.com>
> To: infra at ovirt.org, engine-devel at ovirt.org
> Sent: Monday, April 30, 2012 2:44:16 PM
> Subject: Re: [Engine-devel] signed-off-by in commit message
> 
> On 04/24/2012 06:11 PM, Itamar Heim wrote:
> > per previous thread by Ryan Harper[1] and ovirt meeting today,
> > starting
> > may 1st gerrit policy will change for all projects to require
> > signed-off-by in the commit message.
> > 
> 
> You may add the "Signed-off-by" field by adding "-s" flag to the "git
> commit" command, either by specifying it for each commit command or
> by
> setting it as an alias in the .git/config
> 
> e.g. for ovirt-engine:
> 
> [alias]
>     cm=commit -s -F config/engine-commit-template.txt -e
> 

Or add the following lines to the commit message git hook:

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


> > vdsm and ovirt-node already have this active
> > 
> > Thanks,
> >    Itamar
> > 
> > for more details:
> > http://kerneltrap.org/files/Jeremy/DCO.txt
> > 
> > [1]http://www.mail-archive.com/arch at ovirt.org/msg00273.html
> > _______________________________________________
> > Infra mailing list
> > Infra at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From gkotton at redhat.com  Mon Apr 30 11:55:29 2012
From: gkotton at redhat.com (Gary Kotton)
Date: Mon, 30 Apr 2012 14:55:29 +0300
Subject: [Engine-devel] oVirt and Quantum
In-Reply-To: <4F9E41AE.6030302@redhat.com>
References: <4F9D1AD4.8070503@redhat.com> <4F9E41AE.6030302@redhat.com>
Message-ID: <4F9E7DB1.1010409@redhat.com>

On 04/30/2012 10:39 AM, Dor Laor wrote:
>
> Gary, would it be possible to compare the current major api verbs 
> offered by Quantum vs the ones offered by oVirt?
Please look at 
https://docs.google.com/presentation/d/1cLW88tPw-8z_ANXU2WC8gd4U2k-ACrPnMQbgj5wDLz4/edit#slide=id.p
This gives a high level explanation of Quantum and the flows. In short 
both Quantum and oVirt enable the creation of logical networks. By 
design Quantum hides the network details from the user. In oVirt the 
user is able to configure the tags etc. We are in the process of 
addressing this.

> It would be nice to review the length/feature-rich of each and also 
> the ease of use.
In addition to linux bridge (which is what oVirt uses today), Quantum 
supports Open vSwitch, RYU and Cisco UCS - these are not supported by 
oVirt at the moment. The RYU and Open vSwitch support OpenFlow
>
> In addition, what would be the todo items in order to get OVS working 
> w/ oVirt?
Actually not much. In fact this is currently supported with the Quantum 
integration. There are two parts:
1. The VM vNic management (implemented):
     i. Create a tap device that has "ethernet" as the the network device
     ii. Set the device us UP
     ii. Attach to the integration bridge and configure tags etc. (The 
Quantum agent does this part)

2. The host management (to be implemented):
     i. oVirt Engine and VDSM need to indicate which physical network 
interfaces will use the integration bridge. This can be one or more NICS 
or a bond (in Quantum this is part of a configuration file). We need to 
think of a nice way to show this in the GUI.
     ii. The logic in oVirt engine that "decides" if a Host is "Non 
Operational" needs to be updated.
> Example for Quantum: 
> http://docs.openstack.org/incubation/openstack-network/developer/quantum-api-1.0/content/Show_port_Details.html#d6e777
>
> Cheers,
> Dor
>
>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>



From Dustin.Schoenbrun at netapp.com  Mon Apr 30 14:00:11 2012
From: Dustin.Schoenbrun at netapp.com (Schoenbrun, Dustin)
Date: Mon, 30 Apr 2012 14:00:11 +0000
Subject: [Engine-devel] Disk Cloning When Creating a VM via a Template
In-Reply-To: <4d827afc-97e6-48d6-9cf1-2c5a6e2e84d6@zmail13.collab.prod.int.phx2.redhat.com>
References: <4F9D0CA2.6070006@redhat.com>
	<4d827afc-97e6-48d6-9cf1-2c5a6e2e84d6@zmail13.collab.prod.int.phx2.redhat.com>
Message-ID: <0A1534657992624AACDCA570F1D3E20003C2C846@SACEXCMBX03-PRD.hq.netapp.com>

Okay, I'll have a look at master and play around with things a little bit.  Thanks for that insight, Ayal!  So, when a VM is cloned from a template, all disks associated with the template are cloned to go with the new VM, correct?  Could I do something similar with the floating disks and just clone all of the associated disks from a VM?  In the meantime, I'll read up a bit more on Floating Disks on the feature pages on the wiki.  Thanks again!

-- Dustin

-----Original Message-----
From: Ayal Baron [mailto:abaron at redhat.com] 
Sent: Sunday, April 29, 2012 6:25 AM
To: Livnat Peer
Cc: engine-devel at ovirt.org; Schoenbrun, Dustin
Subject: Re: [Engine-devel] Disk Cloning When Creating a VM via a Template



----- Original Message -----
> On 26/04/12 22:24, Schoenbrun, Dustin wrote:
> > I know that floating disks are coming in the next version of oVirt, 
> > but in the interim I want to know internally what the procedure is 
> > when a disk is cloned when creating a VM from a template.

I'm not sure what floating disks have to do with it (it would be relevant for cloning a single disk, not cloning an entire VM).
For cloning a single disk I believe that floating disk is already available in master by the way.

> > 
> 
> Hi,
> 
> Today when creating a VM from template the user can choose the 
> provisioning method:
> - It can be 'Thin' in which the engine is taking a snapshot of the 
> template disks (running AddVMCommand which executes
> CreateSnapshotFromTemplateCommand)
> - Or 'Clone' which results in cloning the template disks (executes 
> AddVmFromTemplateCommand which in turn executes
> CreateCloneOfTemplateCommand)

For createCloneOfTemplateCommand, other than the VM configuration being copied, the engine creates copies of all of the template images (calls moveImage in vdsm per Image).


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

From gjansen at redhat.com  Mon Apr 30 14:19:41 2012
From: gjansen at redhat.com (Geert Jansen)
Date: Mon, 30 Apr 2012 17:19:41 +0300
Subject: [Engine-devel] CPU topology in the API
In-Reply-To: <4F9E7AF1.30809@redhat.com>
References: <9db7249e-b92e-4fd8-aa6a-b50005e6743a@zmail17.collab.prod.int.phx2.redhat.com>
	<4F9E7AF1.30809@redhat.com>
Message-ID: <4F9E9F7D.60001@redhat.com>



On 04/30/2012 02:43 PM, Dor Laor wrote:
>> I would go for 4 or 2
>> Current CPU topology for the hosts is a new commit, thus it may be
>> allowed to change it now since no one is using it yet. This works in
>> favour of 2. In any case only 3 discloses all the information in all
>> possible cases.
>>
>>
>> Thoughts?
>
> If you touch any of this, please be prepared for the future:
>   - Use hyperthreads (exists in kvm today)
>   - Add numa topology for guest and the hosts
>   - Add Cache info (for VMs too)
>   - Add number of DIMMs, especially for VMs, for the upcoming memory hot
>     plug feature.
>   - BE ready for cpu/cpu/memory hotplug for the hosts and the guests.

Maybe there will be a time where we need this, but for now we just need 
the total number of cores. This is important for capacity planning. For 
CPU, these capacity planning tools simply add up all the fractional core 
usages for all VMs in a cluster, and then it has to be smaller than the 
number of total cores in the cluster. So it's important to know the 
total number of cores per host.

For a VM, the number of cores is sockets*cores. For a host, it is just 
"cores". If you would use socket*cores for a host, you'll get too many. 
This isn't obvious and in my view it's a bug.

Simon, I don't really see this as an API breaker by the way. The number 
of cores for a host was always cores*sockets even on 3.0, just that 
sockets was always equal to 1 (implicitly).

Regards,
Geert


From simon at redhat.com  Mon Apr 30 14:31:56 2012
From: simon at redhat.com (Simon Grinberg)
Date: Mon, 30 Apr 2012 10:31:56 -0400 (EDT)
Subject: [Engine-devel] CPU topology in the API
In-Reply-To: <4F9E9F7D.60001@redhat.com>
Message-ID: <371afd97-8049-4c60-9cdc-f49036cb7709@zmail17.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Geert Jansen" <gjansen at redhat.com>
> To: dlaor at redhat.com, "Simon Grinberg" <simon at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Monday, April 30, 2012 5:19:41 PM
> Subject: Re: [Engine-devel] CPU topology in the API
> 
> 
> 
> On 04/30/2012 02:43 PM, Dor Laor wrote:
> >> I would go for 4 or 2
> >> Current CPU topology for the hosts is a new commit, thus it may be
> >> allowed to change it now since no one is using it yet. This works
> >> in
> >> favour of 2. In any case only 3 discloses all the information in
> >> all
> >> possible cases.
> >>
> >>
> >> Thoughts?
> >
> > If you touch any of this, please be prepared for the future:
> >   - Use hyperthreads (exists in kvm today)
> >   - Add numa topology for guest and the hosts
> >   - Add Cache info (for VMs too)
> >   - Add number of DIMMs, especially for VMs, for the upcoming
> >   memory hot
> >     plug feature.
> >   - BE ready for cpu/cpu/memory hotplug for the hosts and the
> >   guests.
> 
> Maybe there will be a time where we need this, but for now we just
> need
> the total number of cores. This is important for capacity planning.
> For
> CPU, these capacity planning tools simply add up all the fractional
> core
> usages for all VMs in a cluster, and then it has to be smaller than
> the
> number of total cores in the cluster. So it's important to know the
> total number of cores per host.
> 
> For a VM, the number of cores is sockets*cores. For a host, it is
> just
> "cores". If you would use socket*cores for a host, you'll get too
> many.
> This isn't obvious and in my view it's a bug.
> 
> Simon, I don't really see this as an API breaker by the way. The
> number
> of cores for a host was always cores*sockets even on 3.0, just that
> sockets was always equal to 1 (implicitly).

Yes, however before the fix the API only reported cores (while the socket as you mentioned where implicitly 1), so there was no confusion.
Now it reports cores and sockets but the meaning differs then the VM topology though it looks the same. 

So for VMs the tools will have to calculate cores*sockets 
For hosts they'll have to ignore the sockets parameter. 

> 
> Regards,
> Geert
> 


From gjansen at redhat.com  Mon Apr 30 14:42:41 2012
From: gjansen at redhat.com (Geert Jansen)
Date: Mon, 30 Apr 2012 17:42:41 +0300
Subject: [Engine-devel] CPU topology in the API
In-Reply-To: <4F9E9F7D.60001@redhat.com>
References: <9db7249e-b92e-4fd8-aa6a-b50005e6743a@zmail17.collab.prod.int.phx2.redhat.com>
	<4F9E7AF1.30809@redhat.com> <4F9E9F7D.60001@redhat.com>
Message-ID: <4F9EA4E1.1070804@redhat.com>



On 04/30/2012 05:19 PM, Geert Jansen wrote:

>> If you touch any of this, please be prepared for the future:
>> - Use hyperthreads (exists in kvm today)
>> - Add numa topology for guest and the hosts
>> - Add Cache info (for VMs too)
>> - Add number of DIMMs, especially for VMs, for the upcoming memory hot
>> plug feature.
>> - BE ready for cpu/cpu/memory hotplug for the hosts and the guests.
>
> Maybe there will be a time where we need this, but for now we just need
> the total number of cores. This is important for capacity planning. For
> CPU, these capacity planning tools simply add up all the fractional core
> usages for all VMs in a cluster, and then it has to be smaller than the
> number of total cores in the cluster. So it's important to know the
> total number of cores per host.
>
> For a VM, the number of cores is sockets*cores. For a host, it is just
> "cores". If you would use socket*cores for a host, you'll get too many.
> This isn't obvious and in my view it's a bug.
>
> Simon, I don't really see this as an API breaker by the way. The number
> of cores for a host was always cores*sockets even on 3.0, just that
> sockets was always equal to 1 (implicitly).

Apologies for replying to my own email, but based on this, my vote would 
be for Simon's option #2 (make <host> like <vm>).

I am not so concerned about API breakage as in 3.0 a properly written 
client would, in my view, get the "sockets" attribute of the CPU 
topology, and set it to "1" if it is not present. If ISVs currently do 
not do this, then it's an easy fix to do for them.

Regarding CPUs with different core counts, i think this is very rare and 
not something we should worry about initially.

Regards,
Geert


From dlaor at redhat.com  Mon Apr 30 15:06:47 2012
From: dlaor at redhat.com (Dor Laor)
Date: Mon, 30 Apr 2012 18:06:47 +0300
Subject: [Engine-devel] CPU topology in the API
In-Reply-To: <4F9E9F7D.60001@redhat.com>
References: <9db7249e-b92e-4fd8-aa6a-b50005e6743a@zmail17.collab.prod.int.phx2.redhat.com>
	<4F9E7AF1.30809@redhat.com> <4F9E9F7D.60001@redhat.com>
Message-ID: <4F9EAA87.6030906@redhat.com>

On 04/30/2012 05:19 PM, Geert Jansen wrote:
>
>
> On 04/30/2012 02:43 PM, Dor Laor wrote:
>>> I would go for 4 or 2
>>> Current CPU topology for the hosts is a new commit, thus it may be
>>> allowed to change it now since no one is using it yet. This works in
>>> favour of 2. In any case only 3 discloses all the information in all
>>> possible cases.
>>>
>>>
>>> Thoughts?
>>
>> If you touch any of this, please be prepared for the future:
>> - Use hyperthreads (exists in kvm today)
>> - Add numa topology for guest and the hosts
>> - Add Cache info (for VMs too)
>> - Add number of DIMMs, especially for VMs, for the upcoming memory hot
>> plug feature.
>> - BE ready for cpu/cpu/memory hotplug for the hosts and the guests.
>
> Maybe there will be a time where we need this, but for now we just need
> the total number of cores. This is important for capacity planning. For

Other products and kvm (w/ the exception of memory hotplug which is not 
yet upstream) do support all of the above. If someone changes the api, 
it's time to add the missing features or at least add a place holder for 
them.

> CPU, these capacity planning tools simply add up all the fractional core
> usages for all VMs in a cluster, and then it has to be smaller than the
> number of total cores in the cluster. So it's important to know the
> total number of cores per host.
>
> For a VM, the number of cores is sockets*cores. For a host, it is just
> "cores". If you would use socket*cores for a host, you'll get too many.
> This isn't obvious and in my view it's a bug.
>
> Simon, I don't really see this as an API breaker by the way. The number
> of cores for a host was always cores*sockets even on 3.0, just that
> sockets was always equal to 1 (implicitly).
>
> Regards,
> Geert



From shuming at linux.vnet.ibm.com  Mon Apr 30 16:23:06 2012
From: shuming at linux.vnet.ibm.com (Shu Ming)
Date: Tue, 01 May 2012 00:23:06 +0800
Subject: [Engine-devel] Updating ovirt engine from 3.0 to the 3.1.0
	version
In-Reply-To: <8faf07bc-015d-439d-b403-8d3d216b58ad@zmail14.collab.prod.int.phx2.redhat.com>
References: <8faf07bc-015d-439d-b403-8d3d216b58ad@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <4F9EBC6A.5090803@linux.vnet.ibm.com>

   After deleting the engine.ear in 
/usr/share/jboss-as-7.1.0.Beta1b/standalone/deployments, I can access 
the page now.  Thanks for you suggestions.

  However, when I tried to access "Administrator Portal(no SSL)".  The 
following errors were encountered.


  HTTP Status 404 - /webadmin

------------------------------------------------------------------------

*type* Status report

*message* _/webadmin_

*description* _The requested resource (/webadmin) is not available._

------------------------------------------------------------------------


      JBoss Web/7.0.3.Final



On 2012-4-30 15:22, Ofer Schreiber wrote:
> Looks like something went wrong with the .ear deployment. (already saw such an issue in http://lists.ovirt.org/pipermail/engine-devel/2012-January/000483.html)
>
> Can you please:
> 1. Stop JBoss
> 2. Make sure jboss deployment directory contain a single engine.ear
>    - Remove engine.ear.failed (or similar files if exists)
> 3. Start JBoss again
>
> ----- Original Message -----
>> On 2012-4-29 19:33, Ofer Schreiber wrote:
>>> I need more info about this:
>>> 1. It looks like a clean install (DB created from scratch). why do
>>> you call it an upgrade?
>> Sorry for confusion here.  I used engine-cleanup and ran engine-setup
>> again after the 3.1 RPM package were installed.
>>
>>> 2. Do you see any error in JBoss/engine logs? (/var/log/jboss-as
>>> and /var/log/ovirt-engine usually)
>> [root at ovirt-engine-112 ~]# cat /var/log/jboss-as/console.log
>>
>> 01:15:16,901 INFO  [org.jboss.as] (Controller Boot Thread) JBoss AS
>> 7.1.0.Beta1b "Tesla" started in 2405ms - Started 140 of 203 services
>> (61
>> services are passive or on-demand)
>> 01:15:17,207 INFO  [org.jboss.as.server.deployment.scanner]
>> (DeploymentScanner-threads - 1) JBAS015014: Re-attempting failed
>> deployment engine.ear
>> 01:15:17,431 INFO  [org.jboss.as.server.deployment.scanner]
>> (DeploymentScanner-threads - 1) JBAS015014: Re-attempting failed
>> deployment ROOT.war
>> 01:15:17,432 INFO  [org.jboss.as.server.deployment.scanner]
>> (DeploymentScanner-threads - 1) JBAS015003: Found ROOT.war in
>> deployment
>> directory. To trigger deployment create a file called
>> ROOT.war.dodeploy
>> 01:15:17,432 INFO  [org.jboss.as.server.deployment.scanner]
>> (DeploymentScanner-threads - 1) JBAS015003: Found engine.ear in
>> deployment directory. To trigger deployment create a file called
>> engine.ear.dodeploy
>> 01:15:17,478 ERROR [org.jboss.as.controller]
>> (DeploymentScanner-threads
>> - 2) JBAS014612: Operation ("add") failed - address: ([("deployment"
>> =>
>> "engine.ear")]): java.lang.IllegalStateException: JBAS014666:
>> Duplicate
>> resource [("deployment" =>  "engine.ear")]
>>           at
>> org.jboss.as.controller.OperationContextImpl.addResource(OperationContextImpl.java:503)
>> [jboss-as-controller-7.1.0.Beta1b.jar:]
>>           at
>> org.jboss.as.controller.OperationContextImpl.createResource(OperationContextImpl.java:471)
>> [jboss-as-controller-7.1.0.Beta1b.jar:]
>>           at
>> org.jboss.as.server.deployment.DeploymentAddHandler.execute(DeploymentAddHandler.java:170)
>> ....
>>
>>           at java.util.concurrent.FutureTask.run(FutureTask.java:166)
>> [:1.6.0_24]
>>           at
>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
>> [:1.6.0_24]
>>           at
>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
>> [:1.6.0_24]
>>           at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
>> [:1.6.0_24]
>>           at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
>> [:1.6.0_24]
>>           at java.lang.Thread.run(Thread.java:679) [:1.6.0_24]
>>           at org.jboss.threads.JBossThread.run(JBossThread.java:122)
>> [jboss-threads-2.0.0.GA.jar:]
>>
>> 01:15:17,482 ERROR [org.jboss.as.server.deployment.scanner]
>> (DeploymentScanner-threads - 1) JBAS014654: Composite operation was
>> rolled back
>> 01:15:17,483 ERROR [org.jboss.as.server.deployment.scanner]
>> (DeploymentScanner-threads - 1) JBAS014654: Composite operation was
>> rolled back
>> 01:15:17,483 ERROR [org.jboss.as.server.deployment.scanner]
>> (DeploymentScanner-threads - 1) {"JBAS014653: Composite operation
>> failed
>> and was rolled back. Steps that failed:" =>  {"Operation step-1" =>
>> "JBAS014749: Operation handler failed: JBAS014666: Duplicate resource
>> [(\"deployment\" =>  \"engine.ear\")]"}}
>> 01:15:17,483 ERROR [org.jboss.as.server.deployment.scanner]
>> (DeploymentScanner-threads - 1) undefined
>>
>>
>>
>>> 3. Any error in the httpd log?
>>
>> [root at ovirt-engine-112 ~]# cat /var/log/httpd/access_log
>> 9.181.193.205 - - [30/Apr/2012:00:28:27 +0800] "GET / HTTP/1.0" 404 -
>> "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28)
>> Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)"
>> 9.181.193.205 - - [30/Apr/2012:00:28:44 +0800] "GET /favicon.ico
>> HTTP/1.0" 404 - "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
>> rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)"
>> 9.181.193.205 - - [30/Apr/2012:00:28:44 +0800] "GET /favicon.ico
>> HTTP/1.0" 404 - "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
>> rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)"
>> 9.181.193.205 - - [30/Apr/2012:00:28:54 +0800] "GET / HTTP/1.0" 404 -
>> "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28)
>> Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)"
>> 9.181.193.205 - - [30/Apr/2012:00:28:55 +0800] "GET /favicon.ico
>> HTTP/1.0" 404 - "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
>> rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)"
>> [root at ovirt-engine-112 ~]#
>>
>> [root at ovirt-engine-112 ~]# cat /var/log/httpd/error_log
>> [Sun Apr 29 03:36:02 2012] [notice] Digest: generating secret for
>> digest
>> authentication ...
>> [Sun Apr 29 03:36:02 2012] [notice] Digest: done
>> [Sun Apr 29 03:36:02 2012] [notice] SSL FIPS mode disabled
>> [Sun Apr 29 03:36:02 2012] [notice] Apache/2.2.22 (Unix) DAV/2
>> mod_ssl/2.2.22 OpenSSL/1.0.0h-fips configured -- resuming normal
>> operations
>> [root at ovirt-engine-112 ~]#
>>
>>
>>
>>> 4. What happens if you stop iptables and access your server with
>>> :8080?
>> The same as before.
>>
>>> Thanks,
>>> Ofer
>>>
>>> ----- Original Message -----
>>>> Hi,
>>>>      I built a set of ovirt engine RPM packages from near the
>>>>      latest
>>>>      ovirt
>>>> engine source code.  However, when I try to access the engine
>>>> server
>>>> with URL "http://ovirt-engine-112:80", the browser displayed a
>>>> blank
>>>> page without http error returned.  Any clue about what is going on
>>>> here?
>>>> Why didn't the engine administrator home page be shown?
>>>>
>>>>
>>>> And the packages were also installed successfully in my target
>>>> system,
>>>> checked this by "rpm -q -a|grep engine".
>>>>     I) upgraded the packages to the 3.1
>>>>
>>>> [root at ovirt-engine-112 ~]# rpm -q -a |grep engine
>>>> ovirt-engine-restapi-3.1.0_0001-1.8.fc16.x86_64
>>>> ovirt-engine-dbscripts-3.1.0_0001-1.8.fc16.x86_64
>>>> ovirt-engine-log-collector-3.0.0_0001-1.6.fc16.x86_64
>>>> ovirt-engine-genericapi-3.1.0_0001-1.8.fc16.x86_64
>>>> ovirt-engine-backend-3.1.0_0001-1.8.fc16.x86_64
>>>> ovirt-engine-setup-3.1.0_0001-1.8.fc16.x86_64
>>>> ovirt-engine-jbossas-1.2-2.fc16.x86_64
>>>> ovirt-engine-jboss-deps-3.1.0_0001-1.8.fc16.x86_64
>>>> ovirt-engine-config-3.1.0_0001-1.8.fc16.x86_64
>>>> ovirt-engine-3.1.0_0001-1.8.fc16.x86_64
>>>> ovirt-engine-webadmin-portal-3.1.0_0001-1.8.fc16.x86_64
>>>> ovirt-engine-userportal-3.1.0_0001-1.8.fc16.x86_64
>>>> ovirt-engine-tools-common-3.1.0_0001-1.8.fc16.x86_64
>>>> ovirt-engine-image-uploader-3.1.0_0001-1.8.fc16.x86_64
>>>> ovirt-engine-notification-service-3.1.0_0001-1.8.fc16.x86_64
>>>> ovirt-engine-iso-uploader-3.1.0_0001-1.8.fc16.x86_64
>>>> gtk2-engines-2.20.2-2.fc15.x86_64
>>>>
>>>> Step II)
>>>>       Then I used "engine-setup" to setup the engine.  It seems
>>>>       that
>>>> everything is ok, see the log below.
>>>>
>>>> -------------
>>>> [root at ovirt-engine-112 ~]# engine-setup
>>>> Welcome to oVirt Engine setup utility
>>>> HTTP Port  [80] :
>>>> HTTPS Port  [443] :
>>>> Host fully qualified domain name, note that this name should be
>>>> fully
>>>> resolvable  [ovirt-engine-112] :
>>>> ERROR: domain is not a valid domain name
>>>> User input failed validation, do you still wish to use it?
>>>> (yes|no):
>>>> yes
>>>> Password for Administrator (admin at internal) :
>>>> Warning: Weak Password.
>>>> Confirm password :
>>>> Organization Name for the Certificate: cstl
>>>> The default storage type you will be using  ['NFS'| 'FC'| 'ISCSI']
>>>>    [NFS] :
>>>> Enter DB type for installation ['remote'| 'local']  [local] :
>>>> Local database password :
>>>> Warning: Weak Password.
>>>> Confirm password :
>>>> Should the installer configure NFS share on this server to be used
>>>> as
>>>> an
>>>> ISO Domain? ['yes'| 'no']  [yes] :
>>>> Mount point path: /iso-dom
>>>> ERROR: mount point already exists in /etc/exports
>>>> Mount point path: /iso-dom
>>>> Display name for the ISO Domain: iso-domains
>>>> Firewall ports need to be opened.
>>>> You can let the installer configure iptables automatically
>>>> overriding
>>>> the current configuration. The old configuration will be backed
>>>> up.
>>>> Alternately you can configure the firewall later using an example
>>>> iptables file found under
>>>> /usr/share/ovirt-engine/conf/iptables.example
>>>> Configure iptables ? ['yes'| 'no']: yes
>>>>
>>>> oVirt Engine will be installed using the following configuration:
>>>> =================================================================
>>>> http-port:                     80
>>>> https-port:                    443
>>>> host-fqdn:                     ovirt-engine-112
>>>> auth-pass:                     ********
>>>> org-name:                      cstl
>>>> default-dc-type:               NFS
>>>> db-remote-install:             local
>>>> db-local-pass:                 ********
>>>> nfs-mp:                        /iso-dom
>>>> iso-domain-name:               iso-domains
>>>> config-nfs:                    yes
>>>> override-iptables:             yes
>>>> Proceed with the configuration listed above? (yes|no): yes
>>>>
>>>> Installing:
>>>> Configuring oVirt-engine...                              [ DONE ]
>>>> Creating CA...                                           [ DONE ]
>>>> Editing JBoss Configuration...                           [ DONE ]
>>>> Setting Database Configuration...                        [ DONE ]
>>>> Setting Database Security...                             [ DONE ]
>>>> Creating Database...                                     [ DONE ]
>>>> Updating the Default Data Center Storage Type...         [ DONE ]
>>>> Editing oVirt Engine Configuration...                    [ DONE ]
>>>> Editing Postgresql Configuration...                      [ DONE ]
>>>> Configuring the Default ISO Domain...                    [ DONE ]
>>>> Configuring Firewall (iptables)...                       [ DONE ]
>>>> Starting JBoss Service...                                [ DONE ]
>>>> Handling HTTPD...                                        [ DONE ]
>>>>
>>>>     **** Installation completed successfully ******
>>>>
>>>>         (Please allow oVirt Engine a few moments to start up.....)
>>>>
>>>>
>>>> Additional information:
>>>>     * SSL Certificate fingerprint:
>>>> C6:01:83:93:4B:2C:2A:38:65:C8:49:C9:17:34:FE:4B:1C:10:D5:FF
>>>>     * SSH Public key fingerprint:
>>>> 69:8c:bd:05:43:17:0a:43:a3:cc:62:7e:f7:be:0c:42
>>>>     * A default ISO share has been created on this host.
>>>>       If IP based access restrictions are required, please edit
>>>>       /iso-dom
>>>> entry in /etc/exports
>>>>     * The firewall has been updated, the old iptables configuration
>>>>     file
>>>> was saved to
>>>> /usr/share/ovirt-engine/conf/iptables.backup.011513-04282012_2225
>>>>     * The installation log file is available at:
>>>> /var/log/ovirt-engine/engine-setup_2012_04_28_01_13_01.log
>>>>     * Please use the user "admin" and password specified in order
>>>>     to
>>>>     login
>>>> into oVirt Engine
>>>>     * To configure additional users, first configure authentication
>>>> domains using the 'engine-manage-domains' utility
>>>>     * To access oVirt Engine please go to the following URL:
>>>> http://ovirt-engine-112:80
>>>> [root at ovirt-engine-112 ~]#
>>>>
>>>>
>>>> --
>>>> Shu Ming<shuming at linux.vnet.ibm.com>
>>>> IBM China Systems and Technology Laboratory
>>>>
>>>>
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>
>>
>> --
>> Shu Ming<shuming at linux.vnet.ibm.com>
>> IBM China Systems and Technology Laboratory
>>
>>
>>


-- 
Shu Ming<shuming at linux.vnet.ibm.com>
IBM China Systems and Technology Laboratory

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

From iheim at redhat.com  Mon Apr 30 16:30:17 2012
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 30 Apr 2012 19:30:17 +0300
Subject: [Engine-devel] [vdsm] reserve virtio-balloon device created by
	libvirt
In-Reply-To: <20120429131901.GM21973@redhat.com>
References: <20120429111909.GE21973@redhat.com>
	<8e526e7d-9d98-4d20-923e-f259c43a172a@zmail07.collab.prod.int.phx2.redhat.com>
	<20120429131901.GM21973@redhat.com>
Message-ID: <4F9EBE19.2000409@redhat.com>

On 04/29/2012 04:19 PM, Dan Kenigsberg wrote:
> On Sun, Apr 29, 2012 at 07:24:52AM -0400, Andrew Cathrow wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Dan Kenigsberg"<danken at redhat.com>
>>> To: "Gal Hammer"<ghammer at redhat.com>
>>> Cc: vdsm-devel at lists.fedorahosted.org
>>> Sent: Sunday, April 29, 2012 7:19:10 AM
>>> Subject: Re: [vdsm] reserve virtio-balloon device created by libvirt
>>>
>>> On Mon, Apr 23, 2012 at 04:00:55PM +0300, Gal Hammer wrote:
>>>> On 23/04/2012 12:26, Mark Wu wrote:
>>>>> Hi guys,
>>>>>
>>>>> I saw that an option to create balloon device was added by Gal in
>>>>> http://gerrit.ovirt.org/1573
>>>>> I have a question about it. Why don we preserve the old default
>>>>> behaviour? I know it's not supported by ovirt-engine now, but I
>>>>> can't
>>>>> figure out what will break if it's not disabled explicitly. So do
>>>>> you
>>>>> think we can just make use of the balloon device added by libvirt?
>>>>
>>>> We didn't change the old behavior.
>>>>
>>>> Libvirt creates by default a memory-balloon device, so vdsm
>>>> defaults
>>>> was to disable it by adding a "none"-type device. This was done
>>>> because vdsm didn't include an option to add such device.
>>>>
>>>> My patch added an option to create a memory-balloon through vdsm.
>>>> If
>>>> the user didn't request to add the device, the behavior is same as
>>>> before, disabling the memory-balloon.
>>>
>>> I feel that it would be best not to flip Vdsm's default at the
>>> moment,
>>> even though it is the opposite of libvirt's. I would consider to flip
>>> them only after your (Mark's) patches are in, tested, and proven
>>> worthwhile for the common case.
>>>
>>> Currently, without any management for the balloon, reserving a guest
>>> PCI
>>> device was deemed wasteful.
>>
>> On the other side of the fence
>> - We know that we do need to do ballooning
>> - In the (next?) release we'll end up adding this support
>> - There's no harm (see next point) in adding the device now in fact it saves a config change on upgrade.
>
> Well, there is a surprise factor, for someone running a guest generated
> in a previous version. Suddenly, after Vdsm upgrade, it would see an
> additional device. At the least, I would like Vdsm to have a
> configurable option to keep the old behavior.

please take into consideration engine has an algorithm testing max 
number of devices and it should be aware of newly introduced devices by 
vdsm or it will overflow.

>
>> - While it takes up a PCI slot it's going to be very, very rare deployments that will ever see the limit, libvirt/virtmanager/virt-install has done this forever without seeing push back.
>
>
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/vdsm-devel



From iheim at redhat.com  Mon Apr 30 20:05:39 2012
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 30 Apr 2012 23:05:39 +0300
Subject: [Engine-devel] signed-off-by in commit message
In-Reply-To: <4F9E7B10.6090300@redhat.com>
References: <4F96C2BD.90309@redhat.com> <4F9E7B10.6090300@redhat.com>
Message-ID: <4F9EF093.3050506@redhat.com>

signed-off-by has been enabled and is now required for all projects in 
gerrit.


On 04/30/2012 02:44 PM, Moti Asayag wrote:
> On 04/24/2012 06:11 PM, Itamar Heim wrote:
>> per previous thread by Ryan Harper[1] and ovirt meeting today, starting
>> may 1st gerrit policy will change for all projects to require
>> signed-off-by in the commit message.
>>
>
> You may add the "Signed-off-by" field by adding "-s" flag to the "git
> commit" command, either by specifying it for each commit command or by
> setting it as an alias in the .git/config
>
> e.g. for ovirt-engine:
>
> [alias]
>      cm=commit -s -F config/engine-commit-template.txt -e
>
>> vdsm and ovirt-node already have this active
>>
>> Thanks,
>>     Itamar
>>
>> for more details:
>> http://kerneltrap.org/files/Jeremy/DCO.txt
>>
>> [1]http://www.mail-archive.com/arch at ovirt.org/msg00273.html
>> _______________________________________________
>> Infra mailing list
>> Infra at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/infra
>
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra



From oschreib at redhat.com  Mon Apr 30 20:11:45 2012
From: oschreib at redhat.com (Ofer Schreiber)
Date: Mon, 30 Apr 2012 16:11:45 -0400 (EDT)
Subject: [Engine-devel] Updating ovirt engine from 3.0 to the 3.1.0
	version
In-Reply-To: <4F9EBC6A.5090803@linux.vnet.ibm.com>
References: <8faf07bc-015d-439d-b403-8d3d216b58ad@zmail14.collab.prod.int.phx2.redhat.com>
	<4F9EBC6A.5090803@linux.vnet.ibm.com>
Message-ID: <36C82119-0445-49AD-98E2-B6A240E73D2F@redhat.com>

Please re create the link to engine.ear. 
That's the base java code that contains webadmin. 

If it doesn't deploy, create also engine.ear.dodeploy

Ofer. 



On 30 Apr 2012, at 19:23, Shu Ming <shuming at linux.vnet.ibm.com> wrote:

>   After deleting the engine.ear in /usr/share/jboss-as-7.1.0.Beta1b/standalone/deployments, I can access the page now.  Thanks for you suggestions.
> 
>  However, when I tried to access "Administrator Portal(no SSL)".  The following errors were encountered.
> 
> HTTP Status 404 - /webadmin
> 
> type Status report
> 
> message /webadmin
> 
> description The requested resource (/webadmin) is not available.
> 
> JBoss Web/7.0.3.Final
> 
> 
> 
> On 2012-4-30 15:22, Ofer Schreiber wrote:
>> 
>> Looks like something went wrong with the .ear deployment. (already saw such an issue in http://lists.ovirt.org/pipermail/engine-devel/2012-January/000483.html)
>> 
>> Can you please:
>> 1. Stop JBoss
>> 2. Make sure jboss deployment directory contain a single engine.ear
>>   - Remove engine.ear.failed (or similar files if exists)
>> 3. Start JBoss again
>> 
>> ----- Original Message -----
>>> On 2012-4-29 19:33, Ofer Schreiber wrote:
>>>> I need more info about this:
>>>> 1. It looks like a clean install (DB created from scratch). why do
>>>> you call it an upgrade?
>>> Sorry for confusion here.  I used engine-cleanup and ran engine-setup
>>> again after the 3.1 RPM package were installed.
>>> 
>>>> 2. Do you see any error in JBoss/engine logs? (/var/log/jboss-as
>>>> and /var/log/ovirt-engine usually)
>>> [root at ovirt-engine-112 ~]# cat /var/log/jboss-as/console.log
>>> 
>>> 01:15:16,901 INFO  [org.jboss.as] (Controller Boot Thread) JBoss AS
>>> 7.1.0.Beta1b "Tesla" started in 2405ms - Started 140 of 203 services
>>> (61
>>> services are passive or on-demand)
>>> 01:15:17,207 INFO  [org.jboss.as.server.deployment.scanner]
>>> (DeploymentScanner-threads - 1) JBAS015014: Re-attempting failed
>>> deployment engine.ear
>>> 01:15:17,431 INFO  [org.jboss.as.server.deployment.scanner]
>>> (DeploymentScanner-threads - 1) JBAS015014: Re-attempting failed
>>> deployment ROOT.war
>>> 01:15:17,432 INFO  [org.jboss.as.server.deployment.scanner]
>>> (DeploymentScanner-threads - 1) JBAS015003: Found ROOT.war in
>>> deployment
>>> directory. To trigger deployment create a file called
>>> ROOT.war.dodeploy
>>> 01:15:17,432 INFO  [org.jboss.as.server.deployment.scanner]
>>> (DeploymentScanner-threads - 1) JBAS015003: Found engine.ear in
>>> deployment directory. To trigger deployment create a file called
>>> engine.ear.dodeploy
>>> 01:15:17,478 ERROR [org.jboss.as.controller]
>>> (DeploymentScanner-threads
>>> - 2) JBAS014612: Operation ("add") failed - address: ([("deployment"
>>> =>
>>> "engine.ear")]): java.lang.IllegalStateException: JBAS014666:
>>> Duplicate
>>> resource [("deployment" => "engine.ear")]
>>>          at
>>> org.jboss.as.controller.OperationContextImpl.addResource(OperationContextImpl.java:503)
>>> [jboss-as-controller-7.1.0.Beta1b.jar:]
>>>          at
>>> org.jboss.as.controller.OperationContextImpl.createResource(OperationContextImpl.java:471)
>>> [jboss-as-controller-7.1.0.Beta1b.jar:]
>>>          at
>>> org.jboss.as.server.deployment.DeploymentAddHandler.execute(DeploymentAddHandler.java:170)
>>> ....
>>> 
>>>          at java.util.concurrent.FutureTask.run(FutureTask.java:166)
>>> [:1.6.0_24]
>>>          at
>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
>>> [:1.6.0_24]
>>>          at
>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
>>> [:1.6.0_24]
>>>          at
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
>>> [:1.6.0_24]
>>>          at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
>>> [:1.6.0_24]
>>>          at java.lang.Thread.run(Thread.java:679) [:1.6.0_24]
>>>          at org.jboss.threads.JBossThread.run(JBossThread.java:122)
>>> [jboss-threads-2.0.0.GA.jar:]
>>> 
>>> 01:15:17,482 ERROR [org.jboss.as.server.deployment.scanner]
>>> (DeploymentScanner-threads - 1) JBAS014654: Composite operation was
>>> rolled back
>>> 01:15:17,483 ERROR [org.jboss.as.server.deployment.scanner]
>>> (DeploymentScanner-threads - 1) JBAS014654: Composite operation was
>>> rolled back
>>> 01:15:17,483 ERROR [org.jboss.as.server.deployment.scanner]
>>> (DeploymentScanner-threads - 1) {"JBAS014653: Composite operation
>>> failed
>>> and was rolled back. Steps that failed:" => {"Operation step-1" =>
>>> "JBAS014749: Operation handler failed: JBAS014666: Duplicate resource
>>> [(\"deployment\" => \"engine.ear\")]"}}
>>> 01:15:17,483 ERROR [org.jboss.as.server.deployment.scanner]
>>> (DeploymentScanner-threads - 1) undefined
>>> 
>>> 
>>> 
>>>> 3. Any error in the httpd log?
>>> 
>>> [root at ovirt-engine-112 ~]# cat /var/log/httpd/access_log
>>> 9.181.193.205 - - [30/Apr/2012:00:28:27 +0800] "GET / HTTP/1.0" 404 -
>>> "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28)
>>> Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)"
>>> 9.181.193.205 - - [30/Apr/2012:00:28:44 +0800] "GET /favicon.ico
>>> HTTP/1.0" 404 - "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
>>> rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)"
>>> 9.181.193.205 - - [30/Apr/2012:00:28:44 +0800] "GET /favicon.ico
>>> HTTP/1.0" 404 - "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
>>> rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)"
>>> 9.181.193.205 - - [30/Apr/2012:00:28:54 +0800] "GET / HTTP/1.0" 404 -
>>> "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28)
>>> Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)"
>>> 9.181.193.205 - - [30/Apr/2012:00:28:55 +0800] "GET /favicon.ico
>>> HTTP/1.0" 404 - "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
>>> rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)"
>>> [root at ovirt-engine-112 ~]#
>>> 
>>> [root at ovirt-engine-112 ~]# cat /var/log/httpd/error_log
>>> [Sun Apr 29 03:36:02 2012] [notice] Digest: generating secret for
>>> digest
>>> authentication ...
>>> [Sun Apr 29 03:36:02 2012] [notice] Digest: done
>>> [Sun Apr 29 03:36:02 2012] [notice] SSL FIPS mode disabled
>>> [Sun Apr 29 03:36:02 2012] [notice] Apache/2.2.22 (Unix) DAV/2
>>> mod_ssl/2.2.22 OpenSSL/1.0.0h-fips configured -- resuming normal
>>> operations
>>> [root at ovirt-engine-112 ~]#
>>> 
>>> 
>>> 
>>>> 4. What happens if you stop iptables and access your server with
>>>> :8080?
>>> The same as before.
>>> 
>>>> Thanks,
>>>> Ofer
>>>> 
>>>> ----- Original Message -----
>>>>> Hi,
>>>>>     I built a set of ovirt engine RPM packages from near the
>>>>>     latest
>>>>>     ovirt
>>>>> engine source code.  However, when I try to access the engine
>>>>> server
>>>>> with URL "http://ovirt-engine-112:80", the browser displayed a
>>>>> blank
>>>>> page without http error returned.  Any clue about what is going on
>>>>> here?
>>>>> Why didn't the engine administrator home page be shown?
>>>>> 
>>>>> 
>>>>> And the packages were also installed successfully in my target
>>>>> system,
>>>>> checked this by "rpm -q -a|grep engine".
>>>>>    I) upgraded the packages to the 3.1
>>>>> 
>>>>> [root at ovirt-engine-112 ~]# rpm -q -a |grep engine
>>>>> ovirt-engine-restapi-3.1.0_0001-1.8.fc16.x86_64
>>>>> ovirt-engine-dbscripts-3.1.0_0001-1.8.fc16.x86_64
>>>>> ovirt-engine-log-collector-3.0.0_0001-1.6.fc16.x86_64
>>>>> ovirt-engine-genericapi-3.1.0_0001-1.8.fc16.x86_64
>>>>> ovirt-engine-backend-3.1.0_0001-1.8.fc16.x86_64
>>>>> ovirt-engine-setup-3.1.0_0001-1.8.fc16.x86_64
>>>>> ovirt-engine-jbossas-1.2-2.fc16.x86_64
>>>>> ovirt-engine-jboss-deps-3.1.0_0001-1.8.fc16.x86_64
>>>>> ovirt-engine-config-3.1.0_0001-1.8.fc16.x86_64
>>>>> ovirt-engine-3.1.0_0001-1.8.fc16.x86_64
>>>>> ovirt-engine-webadmin-portal-3.1.0_0001-1.8.fc16.x86_64
>>>>> ovirt-engine-userportal-3.1.0_0001-1.8.fc16.x86_64
>>>>> ovirt-engine-tools-common-3.1.0_0001-1.8.fc16.x86_64
>>>>> ovirt-engine-image-uploader-3.1.0_0001-1.8.fc16.x86_64
>>>>> ovirt-engine-notification-service-3.1.0_0001-1.8.fc16.x86_64
>>>>> ovirt-engine-iso-uploader-3.1.0_0001-1.8.fc16.x86_64
>>>>> gtk2-engines-2.20.2-2.fc15.x86_64
>>>>> 
>>>>> Step II)
>>>>>      Then I used "engine-setup" to setup the engine.  It seems
>>>>>      that
>>>>> everything is ok, see the log below.
>>>>> 
>>>>> -------------
>>>>> [root at ovirt-engine-112 ~]# engine-setup
>>>>> Welcome to oVirt Engine setup utility
>>>>> HTTP Port  [80] :
>>>>> HTTPS Port  [443] :
>>>>> Host fully qualified domain name, note that this name should be
>>>>> fully
>>>>> resolvable  [ovirt-engine-112] :
>>>>> ERROR: domain is not a valid domain name
>>>>> User input failed validation, do you still wish to use it?
>>>>> (yes|no):
>>>>> yes
>>>>> Password for Administrator (admin at internal) :
>>>>> Warning: Weak Password.
>>>>> Confirm password :
>>>>> Organization Name for the Certificate: cstl
>>>>> The default storage type you will be using  ['NFS'| 'FC'| 'ISCSI']
>>>>>   [NFS] :
>>>>> Enter DB type for installation ['remote'| 'local']  [local] :
>>>>> Local database password :
>>>>> Warning: Weak Password.
>>>>> Confirm password :
>>>>> Should the installer configure NFS share on this server to be used
>>>>> as
>>>>> an
>>>>> ISO Domain? ['yes'| 'no']  [yes] :
>>>>> Mount point path: /iso-dom
>>>>> ERROR: mount point already exists in /etc/exports
>>>>> Mount point path: /iso-dom
>>>>> Display name for the ISO Domain: iso-domains
>>>>> Firewall ports need to be opened.
>>>>> You can let the installer configure iptables automatically
>>>>> overriding
>>>>> the current configuration. The old configuration will be backed
>>>>> up.
>>>>> Alternately you can configure the firewall later using an example
>>>>> iptables file found under
>>>>> /usr/share/ovirt-engine/conf/iptables.example
>>>>> Configure iptables ? ['yes'| 'no']: yes
>>>>> 
>>>>> oVirt Engine will be installed using the following configuration:
>>>>> =================================================================
>>>>> http-port:                     80
>>>>> https-port:                    443
>>>>> host-fqdn:                     ovirt-engine-112
>>>>> auth-pass:                     ********
>>>>> org-name:                      cstl
>>>>> default-dc-type:               NFS
>>>>> db-remote-install:             local
>>>>> db-local-pass:                 ********
>>>>> nfs-mp:                        /iso-dom
>>>>> iso-domain-name:               iso-domains
>>>>> config-nfs:                    yes
>>>>> override-iptables:             yes
>>>>> Proceed with the configuration listed above? (yes|no): yes
>>>>> 
>>>>> Installing:
>>>>> Configuring oVirt-engine...                              [ DONE ]
>>>>> Creating CA...                                           [ DONE ]
>>>>> Editing JBoss Configuration...                           [ DONE ]
>>>>> Setting Database Configuration...                        [ DONE ]
>>>>> Setting Database Security...                             [ DONE ]
>>>>> Creating Database...                                     [ DONE ]
>>>>> Updating the Default Data Center Storage Type...         [ DONE ]
>>>>> Editing oVirt Engine Configuration...                    [ DONE ]
>>>>> Editing Postgresql Configuration...                      [ DONE ]
>>>>> Configuring the Default ISO Domain...                    [ DONE ]
>>>>> Configuring Firewall (iptables)...                       [ DONE ]
>>>>> Starting JBoss Service...                                [ DONE ]
>>>>> Handling HTTPD...                                        [ DONE ]
>>>>> 
>>>>>    **** Installation completed successfully ******
>>>>> 
>>>>>        (Please allow oVirt Engine a few moments to start up.....)
>>>>> 
>>>>> 
>>>>> Additional information:
>>>>>    * SSL Certificate fingerprint:
>>>>> C6:01:83:93:4B:2C:2A:38:65:C8:49:C9:17:34:FE:4B:1C:10:D5:FF
>>>>>    * SSH Public key fingerprint:
>>>>> 69:8c:bd:05:43:17:0a:43:a3:cc:62:7e:f7:be:0c:42
>>>>>    * A default ISO share has been created on this host.
>>>>>      If IP based access restrictions are required, please edit
>>>>>      /iso-dom
>>>>> entry in /etc/exports
>>>>>    * The firewall has been updated, the old iptables configuration
>>>>>    file
>>>>> was saved to
>>>>> /usr/share/ovirt-engine/conf/iptables.backup.011513-04282012_2225
>>>>>    * The installation log file is available at:
>>>>> /var/log/ovirt-engine/engine-setup_2012_04_28_01_13_01.log
>>>>>    * Please use the user "admin" and password specified in order
>>>>>    to
>>>>>    login
>>>>> into oVirt Engine
>>>>>    * To configure additional users, first configure authentication
>>>>> domains using the 'engine-manage-domains' utility
>>>>>    * To access oVirt Engine please go to the following URL:
>>>>> http://ovirt-engine-112:80
>>>>> [root at ovirt-engine-112 ~]#
>>>>> 
>>>>> 
>>>>> --
>>>>> Shu Ming<shuming at linux.vnet.ibm.com>
>>>>> IBM China Systems and Technology Laboratory
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Engine-devel mailing list
>>>>> Engine-devel at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>> 
>>> 
>>> --
>>> Shu Ming<shuming at linux.vnet.ibm.com>
>>> IBM China Systems and Technology Laboratory
>>> 
>>> 
>>> 
> 
> 
> -- 
> Shu Ming <shuming at linux.vnet.ibm.com>
> IBM China Systems and Technology Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20120430/3c4b84da/attachment.html>

From dlaor at redhat.com  Mon Apr 30 22:28:29 2012
From: dlaor at redhat.com (Dor Laor)
Date: Tue, 01 May 2012 01:28:29 +0300
Subject: [Engine-devel] [vdsm] reserve virtio-balloon device created by
	libvirt
In-Reply-To: <4F9EBE19.2000409@redhat.com>
References: <20120429111909.GE21973@redhat.com>
	<8e526e7d-9d98-4d20-923e-f259c43a172a@zmail07.collab.prod.int.phx2.redhat.com>
	<20120429131901.GM21973@redhat.com> <4F9EBE19.2000409@redhat.com>
Message-ID: <4F9F120D.2050201@redhat.com>

On 04/30/2012 07:30 PM, Itamar Heim wrote:
> On 04/29/2012 04:19 PM, Dan Kenigsberg wrote:
>> On Sun, Apr 29, 2012 at 07:24:52AM -0400, Andrew Cathrow wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Dan Kenigsberg"<danken at redhat.com>
>>>> To: "Gal Hammer"<ghammer at redhat.com>
>>>> Cc: vdsm-devel at lists.fedorahosted.org
>>>> Sent: Sunday, April 29, 2012 7:19:10 AM
>>>> Subject: Re: [vdsm] reserve virtio-balloon device created by libvirt
>>>>
>>>> On Mon, Apr 23, 2012 at 04:00:55PM +0300, Gal Hammer wrote:
>>>>> On 23/04/2012 12:26, Mark Wu wrote:
>>>>>> Hi guys,
>>>>>>
>>>>>> I saw that an option to create balloon device was added by Gal in
>>>>>> http://gerrit.ovirt.org/1573
>>>>>> I have a question about it. Why don we preserve the old default
>>>>>> behaviour? I know it's not supported by ovirt-engine now, but I
>>>>>> can't
>>>>>> figure out what will break if it's not disabled explicitly. So do
>>>>>> you
>>>>>> think we can just make use of the balloon device added by libvirt?
>>>>>
>>>>> We didn't change the old behavior.
>>>>>
>>>>> Libvirt creates by default a memory-balloon device, so vdsm
>>>>> defaults
>>>>> was to disable it by adding a "none"-type device. This was done
>>>>> because vdsm didn't include an option to add such device.
>>>>>
>>>>> My patch added an option to create a memory-balloon through vdsm.
>>>>> If
>>>>> the user didn't request to add the device, the behavior is same as
>>>>> before, disabling the memory-balloon.
>>>>
>>>> I feel that it would be best not to flip Vdsm's default at the
>>>> moment,
>>>> even though it is the opposite of libvirt's. I would consider to flip
>>>> them only after your (Mark's) patches are in, tested, and proven
>>>> worthwhile for the common case.
>>>>
>>>> Currently, without any management for the balloon, reserving a guest
>>>> PCI
>>>> device was deemed wasteful.
>>>
>>> On the other side of the fence
>>> - We know that we do need to do ballooning
>>> - In the (next?) release we'll end up adding this support
>>> - There's no harm (see next point) in adding the device now in fact
>>> it saves a config change on upgrade.
>>
>> Well, there is a surprise factor, for someone running a guest generated

surprise == another minor reason for windows guest to re-activate.

>> in a previous version. Suddenly, after Vdsm upgrade, it would see an
>> additional device. At the least, I would like Vdsm to have a
>> configurable option to keep the old behavior.

In qemu we have a compatibility level controlled by -M flag.
VDSM should have a similar compatibility level and defaults shouldn't 
normally change in minor releases.

>
> please take into consideration engine has an algorithm testing max
> number of devices and it should be aware of newly introduced devices by
> vdsm or it will overflow.

It is good timing to change the algorithm too. IIRC the algorithm has 
some hard coded assumptions about qemu. Instead, it would be better to 
consult w/ qemu in run time and get the free pci slots number and any 
other limits. Soon qemu will support pci bridges and this will increase 
the number of pci devices and virtio-scsi will insert some other 
calculation factor.

>
>>
>>> - While it takes up a PCI slot it's going to be very, very rare
>>> deployments that will ever see the limit,
>>> libvirt/virtmanager/virt-install has done this forever without seeing
>>> push back.
>>
>>
>> _______________________________________________
>> vdsm-devel mailing list
>> vdsm-devel at lists.fedorahosted.org
>> https://fedorahosted.org/mailman/listinfo/vdsm-devel
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel