Re: [Engine-devel] REST API - where did bookmarks go?

[Martin Perina]

- Original Message -
> From: "Juan Hernandez" 
> To: "Einav Cohen" , "Gilad Chaplik" , 
> "Martin Perina" 
> Cc: "engine-devel" 
> Sent: Monday, March 24, 2014 5:33:49 PM
> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> 
> On 03/24/2014 05:17 PM, Einav Cohen wrote:
> >> - Original Message -
> >> From: "Gilad Chaplik" 
> >> Sent: Monday, March 24, 2014 11:58:01 AM
> >>
> >> So iiuc, we are going to develop a known obsolete feature :-) ?
> >> Can we break it in 4.0?
> > 
> > well, since they were never exposed, we can also decide that we are
> > not implementing them at all, but this means that we are losing the
> > server-side bookmarks once we move the GUI to work with the REST-API.
> > question is if everyone are OK with that...
> > 
> > to be on the safe side and to not lose any functionality/data, I
> > suggest to add them to the REST API, and for 4.0 - discuss whether
> > they should be removed (and possibly replaced with client-side
> > bookmarks in the GUI)
> > 
> 
> Actually adding support for bookmarks has been targeted for 4.0, and
> work is about to start (if not started yet).
> 
> Martin, please, don't start working on this till it is decided if we
> will have or not the bookmarks in 4.0.

Ok, I will wait until decision is made.

> 
> >>
> >> Thanks,
> >> Gilad.
> >>
> >>
> >> - Original Message -
> >>> From: "Einav Cohen" 
> >>> To: "Gilad Chaplik" 
> >>> Cc: "Juan Hernandez" , "engine-devel"
> >>> 
> >>> Sent: Monday, March 24, 2014 5:55:20 PM
> >>> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> >>>
> >>>> - Original Message -
> >>>> From: "Gilad Chaplik" 
> >>>> Sent: Monday, March 24, 2014 11:46:04 AM
> >>>>
> >>>> Hi Einav,
> >>>>
> >>>> I agree with every word. also thought about it, that's why I wrote a
> >>>> possible
> >>>> solution.
> >>>> Not sure we need to design the RESTful API according to UI's needs (add
> >>>> features in this case).
> >>>
> >>> the REST API should not be designed according to UI's needs - but the
> >>> REST
> >>> API
> >>> should allow to retrieve all engine-managed business entities. Bookmarks
> >>> is
> >>> one
> >>> of them.
> >>> There is a chance that creating Bookmarks as an engine-managed
> >>> business-entity
> >>> in the first place was a bad design decision, but they are there now, as
> >>> managed
> >>> business-entities, and as such - should be exposed via the REST API.
> >>>
> >>>>
> >>>>
> >>>>
> >>>> Thanks,
> >>>> Gilad.
> >>>>
> >>>>
> >>>> - Original Message -
> >>>>> From: "Einav Cohen" 
> >>>>> To: "Gilad Chaplik" 
> >>>>> Cc: "Vojtech Szocs" , "Juan Hernandez"
> >>>>> , "engine-devel"
> >>>>> 
> >>>>> Sent: Monday, March 24, 2014 5:38:33 PM
> >>>>> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> >>>>>
> >>>>> Hi Gilad, "client-side Bookmarks" is a great suggestion, however it
> >>>>> is a (non-related) RFE, which may be implemented instead of, or in
> >>>>> addition to, the already-existing server-side Bookmarks.
> >>>>>
> >>>>> [keep in mind that server-side bookmarks allow you to add bookmarks
> >>>>> that may be used by other users; it is also a feature that exists
> >>>>> for a long time in oVirt, so need to think a little bit before
> >>>>> removing it]
> >>>>>
> >>>>> As long as we have server-side Bookmarks (i.e. as long as Bookmark
> >>>>> is an engine-managed business entity), they need to be exposed via
> >>>>> the REST API.
> >>>>>
> >>>>> 
> >>>>> Thanks,
> >>>>> Einav
> >>>>>
> >>>>> - Original Message -
> >>>>>>

Re: [Engine-devel] ovirt-engine-3.4.0 is broken

[Martin Perina]

- Original Message -
> From: "Omer Frenkel" 
> To: "Moti Asayag" , "Martin Perina" 
> Cc: "engine-devel" 
> Sent: Monday, March 10, 2014 11:04:59 AM
> Subject: ovirt-engine-3.4.0 is broken
> 
> Hi,
> looks like both commits:
> http://gerrit.ovirt.org/#/c/25436/
> http://gerrit.ovirt.org/#/c/25313/
> 
> introduced an upgrade script with the same number to the 3.4.0 branch, and
> now build fails.
> can you please fix this?
> 

Moti answered me on IRC, that he will look at the issue. Hopefully
he will rename 03_04_0650_delete_network_labels_action_groups.sql
to 03_04_0660_delete_network_labels_action_groups.sql so the script names
will be the same as in ovirt-engine-3.4 branch.


___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Schema upgrade failure on master

[Martin Perina]

- Original Message -
> From: "Liran Zelkha" 
> To: "Martin Perina" 
> Cc: "engine-devel" 
> Sent: Tuesday, March 4, 2014 10:15:47 AM
> Subject: Re: [Engine-devel] Schema upgrade failure on master
> 
> Happens to me too, on engine_dao_tests.
> DB is not empty, one line:
> engine_dao_tests=> select * from event_subscriber;
> subscriber_id | event_up_name | method_id |
> method_address | tag_name | notification_method
> --+---+---++--+-
>  9bf7c640-b620-456f-a550-0348f366544a | TestRun   | 1 |
>| testrun  |
> (1 row)

This row caused the issue, I wonder how it was created when notification_method 
column is created
during 03_05_0050_event_notification_methods.sql script execution ...

Delete this row and after this run schema upgrade. I tested with master and 
empty db and dao tests work fine.

> 
> 
> 
> 
> On Tue, Mar 4, 2014 at 7:10 AM, Martin Perina  wrote:
> 
> > Hi Adam,
> >
> > I didn't notice any problem with this script. Was the database you tried
> > to upgrade empty?
> > If not could you please send me contents of your event_subscriber table?
> >
> > Thanks
> >
> > Martin Perina
> >
> > - Original Message -
> > > From: "Adam Litke" 
> > > To: engine-devel@ovirt.org
> > > Sent: Monday, March 3, 2014 11:26:28 PM
> > > Subject: [Engine-devel] Schema upgrade failure on master
> > >
> > > Hi,
> > >
> > > I've recently rebased to master and it looks like the
> > > 03_05_0050_event_notification_methods.sql script is failing on schema
> > > upgrade.  Is this a bug or am I doing something wrong?  To upgrade I
> > > did the normal proceedure with my development installation:
> > >
> > > make install-dev ...
> > > ~/ovirt/bin/engine-setup
> > >
> > > Got this result in the log file:
> > >
> > >
> > psql:/home/alitke/ovirt-**FILTERED**/share/ovirt-**FILTERED**/dbscripts/upgrade/03_05_0050_event_notification_methods.sql:10:
> > > ERROR:  column "notification_method" contains null values
> > > FATAL: Cannot execute sql command:
> > >
> > --file=/home/alitke/ovirt-**FILTERED**/share/ovirt-**FILTERED**/dbscripts/upgrade/03_05_0050_event_notification_methods.sql
> > >
> > > 2014-03-03 17:20:34 DEBUG otopi.context context._executeMethod:152 method
> > > exception
> > > Traceback (most recent call last):
> > >   File "/usr/lib/python2.7/site-packages/otopi/context.py", line 142, in
> > >   _executeMethod
> > > method['method']()
> > >   File
> > >
> > "/home/alitke/ovirt-**FILTERED**/share/ovirt-**FILTERED**/setup/bin/../plugins/ovirt-**FILTERED**-setup/ovirt-**FILTERED**/db/schema.py",
> > >   line 280, in _misc
> > > osetupcons.DBEnv.PGPASS_FILE
> > >   File "/usr/lib/python2.7/site-packages/otopi/plugin.py", line 451, in
> > >   execute
> > > command=args[0],
> > > RuntimeError: Command
> > >
> > '/home/alitke/ovirt-**FILTERED**/share/ovirt-**FILTERED**/dbscripts/schema.sh'
> > > failed to execute
> > >
> > > --
> > > Adam Litke
> > > ___
> > > Engine-devel mailing list
> > > Engine-devel@ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> > ___
> > Engine-devel mailing list
> > Engine-devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Schema upgrade failure on master

[Martin Perina]

Hi Adam,

I didn't notice any problem with this script. Was the database you tried to 
upgrade empty?
If not could you please send me contents of your event_subscriber table?

Thanks

Martin Perina

- Original Message -
> From: "Adam Litke" 
> To: engine-devel@ovirt.org
> Sent: Monday, March 3, 2014 11:26:28 PM
> Subject: [Engine-devel] Schema upgrade failure on master
> 
> Hi,
> 
> I've recently rebased to master and it looks like the
> 03_05_0050_event_notification_methods.sql script is failing on schema
> upgrade.  Is this a bug or am I doing something wrong?  To upgrade I
> did the normal proceedure with my development installation:
> 
> make install-dev ...
> ~/ovirt/bin/engine-setup
> 
> Got this result in the log file:
> 
> psql:/home/alitke/ovirt-**FILTERED**/share/ovirt-**FILTERED**/dbscripts/upgrade/03_05_0050_event_notification_methods.sql:10:
> ERROR:  column "notification_method" contains null values
> FATAL: Cannot execute sql command:
> --file=/home/alitke/ovirt-**FILTERED**/share/ovirt-**FILTERED**/dbscripts/upgrade/03_05_0050_event_notification_methods.sql
> 
> 2014-03-03 17:20:34 DEBUG otopi.context context._executeMethod:152 method
> exception
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/otopi/context.py", line 142, in
>   _executeMethod
> method['method']()
>   File
>   
> "/home/alitke/ovirt-**FILTERED**/share/ovirt-**FILTERED**/setup/bin/../plugins/ovirt-**FILTERED**-setup/ovirt-**FILTERED**/db/schema.py",
>   line 280, in _misc
> osetupcons.DBEnv.PGPASS_FILE
>   File "/usr/lib/python2.7/site-packages/otopi/plugin.py", line 451, in
>   execute
> command=args[0],
> RuntimeError: Command
> '/home/alitke/ovirt-**FILTERED**/share/ovirt-**FILTERED**/dbscripts/schema.sh'
> failed to execute
> 
> --
> Adam Litke
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

[Engine-devel] [ANN] engine-manage-domains arguments changed

[Martin Perina]

Hi,

patch, that changes engine-manage-domains command line arguments from Java type 
(-someOption)
to standard long type (--some-option), was merged today. Please consult man 
page or run
engine-manage-domains --help to find out differences.

Thanks

Martin Perina

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] oVirt 3.4.0 beta is now available

[Martin Perina]

Hi,

I tried to install on F19, but openstack* packages >= 3.0.2 are missing:

Error: Package: ovirt-engine-3.4.0-0.5.beta1.fc19.noarch 
(ovirt-3.4.0-prerelease)
   Requires: openstack-java-quantum-model >= 3.0.2
   Available: openstack-java-quantum-model-3.0.1-1.fc19.noarch (updates)
   openstack-java-quantum-model = 3.0.1-1.fc19
Error: Package: ovirt-engine-3.4.0-0.5.beta1.fc19.noarch 
(ovirt-3.4.0-prerelease)
   Requires: openstack-java-glance-client >= 3.0.2
   Available: openstack-java-glance-client-3.0.1-1.fc19.noarch (updates)
   openstack-java-glance-client = 3.0.1-1.fc19
Error: Package: ovirt-engine-3.4.0-0.5.beta1.fc19.noarch 
(ovirt-3.4.0-prerelease)
   Requires: openstack-java-glance-model >= 3.0.2
   Available: openstack-java-glance-model-3.0.1-1.fc19.noarch (updates)
   openstack-java-glance-model = 3.0.1-1.fc19
Error: Package: ovirt-engine-3.4.0-0.5.beta1.fc19.noarch 
(ovirt-3.4.0-prerelease)
   Requires: openstack-java-client >= 3.0.2
   Available: openstack-java-client-3.0.1-1.fc19.noarch (updates)
   openstack-java-client = 3.0.1-1.fc19
Error: Package: ovirt-engine-3.4.0-0.5.beta1.fc19.noarch 
(ovirt-3.4.0-prerelease)
   Requires: openstack-java-keystone-model >= 3.0.2
   Available: openstack-java-keystone-model-3.0.1-1.fc19.noarch 
(updates)
   openstack-java-keystone-model = 3.0.1-1.fc19
Error: Package: ovirt-engine-3.4.0-0.5.beta1.fc19.noarch 
(ovirt-3.4.0-prerelease)
   Requires: openstack-java-resteasy-connector >= 3.0.2
   Available: openstack-java-resteasy-connector-3.0.1-1.fc19.noarch 
(updates)
   openstack-java-resteasy-connector = 3.0.1-1.fc19
Error: Package: ovirt-engine-3.4.0-0.5.beta1.fc19.noarch 
(ovirt-3.4.0-prerelease)
   Requires: openstack-java-quantum-client >= 3.0.2
   Available: openstack-java-quantum-client-3.0.1-1.fc19.noarch 
(updates)
   openstack-java-quantum-client = 3.0.1-1.fc19
Error: Package: ovirt-engine-3.4.0-0.5.beta1.fc19.noarch 
(ovirt-3.4.0-prerelease)
   Requires: openstack-java-keystone-client >= 3.0.2
   Available: openstack-java-keystone-client-3.0.1-1.fc19.noarch 
(updates)
   openstack-java-keystone-client = 3.0.1-1.fc19


I didn't found any info about additional repositories in release notes ...

Thanks

Martin Perina


- Original Message -
> From: "Sandro Bonazzola" 
> To: annou...@ovirt.org, "arch" , us...@ovirt.org, 
> "engine-devel" 
> Sent: Wednesday, January 22, 2014 11:56:19 AM
> Subject: [Engine-devel] oVirt 3.4.0 beta is now available
> 
> The oVirt team is pleased to announce that the 3.4.0 Release is now available
> in beta for testing.
> 
> Release notes and information on the changes for this update are still being
> worked on and will be available soon on the wiki[1].
> Please ensure to follow install instruction from release notes if you're
> going to test it.
> A new repository ovirt-3.4.0-prerelease has been added for delivering this
> beta and future refreshes until release candidate.
> 
> A new oVirt Node build will be available soon as well.
> 
> You're welcome to join us testing this beta release in tomorrow test day [2]!
> 
> 
> [1] http://www.ovirt.org/OVirt_3.4.0_release_notes
> [2] http://www.ovirt.org/OVirt_3.4_Test_Day
> 
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Showing stacktrace info in GUI error dialog

[Martin Perina]

Hi,

I would like to correct a few things in this case.

The reason for patch [1] was to identify, from which part of engine code
InvocationTargetException came from. (more details are at [2] and [3]).
In both cases this exception was not logged in engine.log or server.log

Trying to verify this patch I found out this:

1) If this exception was raised during command/query execution, it would be part
   VdsReturnValue and shown in UI in Operation Canceled dialog. And what's most
   important, the exception would be definitely logged in engine.log

2) If this exception was raised on backend side outside of command/query 
execution
   (I simulated this by throwing RuntimeException inside 
Backend.runAction/runQuery)
   it would be shown in UI with HTTP status code (500 in this case) and also 
would
   be logged in engine.log

3) If this exception was raised somewhere servlet part of frontend code 
(GenericApiGWTServiceImpl)
   it would also be shown in UI with HTTP status code (500 in this case) and 
also
   would be logged in server.log

4) For all other cases there is shown dialog in UI with
'Error while executing action: A Request to the Server failed: XXX'
   where XXX is the exception message. Patch [1] adds stacktrace to this dialog 
so
   we will be able to identify origin of those rare exceptions.

So the exception was raised somewhere else and since bugs [2],[3] wasn't been 
successfully
reproduced yet, it's the only way how to find out origin of the exception.

And I should also note, that I have no intention to show stacktrace in UI for 
"normal"
exceptions described in 1), 2) or 3)

Thanks

Martin


[1] http://gerrit.ovirt.org/23096
[2] http://bugzilla.redhat.com/1039248
[3] http://bugzilla.redhat.com/1034437



- Original Message -
> From: "Greg Sheremeta" 
> To: "Einav Cohen" 
> Cc: "engine-devel" , "users" , 
> "Martin Perina" 
> Sent: Tuesday, January 14, 2014 6:35:53 PM
> Subject: Re: [Engine-devel] Showing stacktrace info in GUI error dialog
> 
> 
> 
> - Original Message -
> > From: "Einav Cohen" 
> > To: "engine-devel" , "users" ,
> > "Martin Perina" 
> > Sent: Tuesday, January 14, 2014 11:23:34 AM
> > Subject: [Engine-devel] Showing stacktrace info in GUI error dialog
> > 
> > Hi, this is about patch [1] - showing server-side-exception
> > stacktrace info in GUI error dialog.
> > 
> > a couple of notes about this patch:
> > 
> > (1) I find it a little strange that server-side exceptions
> > are not logged in the server side and are / will be displayed
> > only on the client-side - this needs to be fixed first.
> > 
> +1.
> 
> > (2) once everything is logged on the server side, we can
> > debate whether it makes sense to put the full exception
> > stack-trace *also* in the GUI error pop-up.
> > I think that it is not completely necessary (since if there
> > is a server side exception, the user is likely to go to the
> > server side log anyway to get the full picture / context), but
> > if it is (and I'd like to hear your opinion about that) - we
> > shouldn't show the entire exception in the dialog once the dialog
> > is displayed - that's too much information to absorb.
> > We should show whatever we are showing today, and also something
> > like a "More Details" collapsible section (collapsed by default)
> > that, when expanded, displays the full exception details.
> > 
> > comments are welcome.
> 
> I personally appreciate web apps that allow me to see an error (or even
> expose an entire log file), but do so gracefully -- hide it under a option,
> use a "More Details" option like you mention, etc.
> 
> I think saving a person the step of ssh'ing to a server and digging for a log
> file is a nice-to-have.
> 
> Greg
> 
> > 
> > 
> > Thanks,
> > Einav
> > 
> > [1] http://gerrit.ovirt.org/#/c/23096/
> > ___
> > Engine-devel mailing list
> > Engine-devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Setup in latest master apparently broken

[Martin Perina]

- Original Message -
> From: "Alon Bar-Lev" 
> To: "Roy Golan" 
> Cc: "Juan Hernandez" , engine-devel@ovirt.org
> Sent: Monday, January 6, 2014 9:23:12 AM
> Subject: Re: [Engine-devel] Setup in latest master apparently broken
> 
> 
> 
> - Original Message -
> > From: "Roy Golan" 
> > To: "Yedidyah Bar David" 
> > Cc: "Juan Hernandez" , engine-devel@ovirt.org
> > Sent: Monday, January 6, 2014 10:10:49 AM
> > Subject: Re: [Engine-devel] Setup in latest master apparently broken
> > 
> > On Mon 06 Jan 2014 08:54:47 AM IST, Yedidyah Bar David wrote:
> > > - Original Message -
> > >> From: "Juan Hernandez" 
> > >> To: engine-devel@ovirt.org
> > >> Sent: Monday, January 6, 2014 12:47:09 AM
> > >> Subject: [Engine-devel] Setup in latest master apparently broken
> > >>
> > >> The setup tool in the latest master (hash e992aa) is apparently broken,
> > >> it fails with the following message:
> > >>
> > >> [ ERROR ] Failed to execute stage 'Misc configuration': 'module' object
> > >> has no attribute 'processTemplate'
> > >>
> > >> Traceback (most recent call last):
> > >>File "/usr/lib/python2.7/site-packages/otopi/context.py", line 142,
> > >>in
> > >> _executeMethod
> > >>  method['method']()
> > >>File
> > >> "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/apache/ovirt_engine.py",
> > >> line 67, in _misc
> > >>  content=outil.processTemplate(
> > >> AttributeError: 'module' object has no attribute 'processTemplate'
> > >>
> > >> The code there is importing "util" from "ovirt_engine", but printing the
> > >
> > > Are you sure it does not 'from ovirt_engine import util as outil'?
> > >
> > >> value of the "util" result gives the following:
> > >>
> > >>  > >> '/usr/lib/python2.7/site-packages/otopi/util.pyc'>
> > >
> > > You are probably referring to http://gerrit.ovirt.org/22827 .
> > > This change did not touch the spec file/requirements, so you need to
> > > manually
> > > make sure you have latest relevant packages.
> > >
> > > I didn't try that, though - I might be wrong...
> > 
> > worked around with:
> > 
> > git revert 6aee0c5d0eb9b0229950bb9f02aa3d206a0bd0a7
> > and
> > make -e install-dev EXTRA_BUILD_FLAGS="-pl
> > org.ovirt.engine:engine-server-ear"
> > 
> > Alon?
> 
> Please do not revert.
> 
> Try:
> $ rm -fr $HOME/ovirt-engine/share/ovirt-engine/setup
> $ make install-dev PREFIX=$HOME/ovirt-engine DEV_REBUILD=0
> 

Same problem appears also to me, when trying to setup engine installed
from newly created RPMs on F19. Installation log contains:

2014-01-06 11:28:31 DEBUG otopi.context context._executeMethod:138 Stage misc 
METHOD 
otopi.plugins.ovirt_engine_setup.base.network.firewall_manager.Plugin._prepare_examples
2014-01-06 11:28:31 DEBUG otopi.transaction transaction._prepare:77 preparing 
'File transaction for '/etc/ovirt-engine/firewalld/ovirt-postgres.xml''
2014-01-06 11:28:31 DEBUG otopi.filetransaction filetransaction.prepare:189 
file '/etc/ovirt-engine/firewalld/ovirt-postgres.xml' missing
2014-01-06 11:28:32 DEBUG otopi.transaction transaction._prepare:77 preparing 
'File transaction for '/etc/ovirt-engine/firewalld/ovirt-websocket-proxy.xml''
2014-01-06 11:28:32 DEBUG otopi.filetransaction filetransaction.prepare:189 
file '/etc/ovirt-engine/firewalld/ovirt-websocket-proxy.xml' missing
2014-01-06 11:28:32 DEBUG otopi.transaction transaction._prepare:77 preparing 
'File transaction for '/etc/ovirt-engine/firewalld/ovirt-http.xml''
2014-01-06 11:28:32 DEBUG otopi.filetransaction filetransaction.prepare:189 
file '/etc/ovirt-engine/firewalld/ovirt-http.xml' missing
2014-01-06 11:28:32 DEBUG otopi.transaction transaction._prepare:77 preparing 
'File transaction for '/etc/ovirt-engine/firewalld/ovirt-https.xml''
2014-01-06 11:28:32 DEBUG otopi.filetransaction filetransaction.prepare:189 
file '/etc/ovirt-engine/firewalld/ovirt-https.xml' missing
2014-01-06 11:28:32 DEBUG otopi.transaction transaction._prepare:77 preparing 
'File transaction for '/etc/ovirt-engine/iptables.example''
2014-01-06 11:28:32 DEBUG otopi.filetransaction filetransaction.prepare:189 
file '/etc/ovirt-engine/iptables.example' missing
2014-01-06 11:28:32 DEBUG otopi.context context._executeMethod:138 Stage misc 
METHOD 
otopi.plugins.ovirt_engine_setup.ovirt_engine.all-in-one.core.Plugin._misc
2014-01-06 11:28:32 DEBUG otopi.context context._executeMethod:144 condition 
False
2014-01-06 11:28:32 DEBUG otopi.context context._executeMethod:138 Stage misc 
METHOD 
otopi.plugins.ovirt_engine_setup.ovirt_engine.all-in-one.storage.Plugin._misc
2014-01-06 11:28:32 DEBUG otopi.context context._executeMethod:144 condition 
False
2014-01-06 11:28:32 DEBUG otopi.context context._executeMethod:138 Stage misc 
METHOD 
otopi.plugins.ovirt_engine_setup.ovirt_engine.all-in-one.vdsm.Plugin._misc
2014-01-06 11:28:32 DEBUG otopi.context context._executeMethod:144 condition 
False
2014-01-06 11:28:32 DEBUG otopi.context context._executeMethod:138 Stage misc 
METHOD 
oto

Re: [Engine-devel] Fwd: Custom properties per device + vNIC profile = not working (< 3.3)

[Martin Perina]

- Original Message -
> From: "Mike Kolesnik" 
> To: "Martin Perina" 
> Cc: engine-devel@ovirt.org
> Sent: Monday, November 11, 2013 10:48:40 AM
> Subject: Re: [Engine-devel] Fwd: Custom properties per device + vNIC profile 
> = not working (< 3.3)
> 
> 
> - Original Message -
> > Hi Mike,
> > 
> > - Original Message -
> > > From: "Mike Kolesnik" 
> > > To: "engine-devel" 
> > > Cc: "Barak Azulay" , "Martin Perina"
> > > , "Livnat Peer" ,
> > > "Itamar Heim" 
> > > Sent: Monday, November 11, 2013 8:49:33 AM
> > > Subject: Custom properties per device + vNIC profile = not working (<
> > > 3.3)
> > > 
> > > Hi,
> > > 
> > > I came across a situation where I wanted to define custom properties on a
> > > vNIC profile sitting under a network in a 3.2 data center.
> > > From what I saw the configuration value for custom properties
> > > (CustomDeviceProperties) is split into 4, one per each version (3.0, 3.1,
> > > 3.2, 3.3).
> > > Since vNIC profile is located under the DC tree, it takes the DC version
> > > -
> > > 3.2 in this specific case.
> > 
> > Custom Device Properties were designed to be specified for each cluster
> > version
> > independently, it doesn't care about DC version. AFAIK cluster version
> > defines
> > what features are available ...
> > 
> > > 
> > > I tried to set the config value for 3.2 but got:
> > > $ engine-config -s
> > > CustomDeviceProperties="{type=interface;prop={myProp=[a-zA-Z0-9-]+}}"
> > > --cver=3.2
> > > Cannot set value {type=interface;prop={myProp=[a-zA-Z0-9-]+}} to key
> > > CustomDeviceProperties. Device custom properties are not supported in
> > > version 3.2
> > > 
> > > This is already not very good, since in a 3.2 DC there can be 3.3
> > > clusters
> > > with 3.3 hosts that do support custom device properties.
> > 
> > Specify your properties for 3.3 version, since they will be used in 3.3
> > clusters ...
> > 
> 
> But the effective version is the DC version as I explained.
> 
> In a DC 3.0-3.3 I can have clusters which the minimal version is the DC
> version, and the maximal version is 3.3.
> For example I can have the following:
> DC - version 3.0
>  + Cluster 1 - version 3.0
>  + Cluster 2 - version 3.1
>  + Cluster 3 - version 3.2
>  + Cluster 4 - version 3.3
> 
> In this constellation, I could use custom device properties only on Cluster
> 4, but it's not possible to define them since the vNIC profile is using the
> DC version 3.0.
> So effectively this feature is not usable to me unless I use a 3.3 DC.

No, it's not usable for you, because you are not using device custom properties
in a way that they were designed. You want to specify custom device
properties per DC version (or general version), but they were designed
to be specified per cluster level. Because currently currently if you
specify properties for cluster version 3.3, they can be used for all
clusters with version 3.3 regardless of DC version they are members of ...

> 
> > > 
> > > I also tried to alter the config value in the DB directly, but the custom
> > > properties code ignored it since custom properties are not supported in
> > > 3.2.
> > > So, de facto, I have no reasonable way as a user to define custom device
> > > properties to use for my vNIC profiles in DC < 3.3.
> > 
> > There are two configuration properties  for Custom Device Properties:
> > 
> > 1) SupportCustomDeviceProperties
> >  - defines in what version properties are supported
> >  - cannot be altered by users of course
> > 
> > 2) CustomDeviceProperties
> >  - holds properties specification for each version
> >  - can be defined using engine-config
> > 
> > > 
> > > I opened the bug https://bugzilla.redhat.com/show_bug.cgi?id=1028757 for
> > > this, however I also want to discuss the situation:
> > 
> > I looked at the bug and the problem is, that management network profile
> > is bound to DC and not the Cluster. And that's something we never thought
> > of
> > ...
> > 
> > > 
> > > 1. As a user, I can't set custom properties for level < 3.3 which is not
> > > good.
> > 
> > Well, it's 3.3 feature, so it looks OK for me
> > 
> > > Removing the blocking, and loading custom properties fo

[Engine-devel] Fwd: Custom properties per device + vNIC profile = not working (< 3.3)

[Martin Perina]

Hi Mike,

- Original Message -
> From: "Mike Kolesnik" 
> To: "engine-devel" 
> Cc: "Barak Azulay" , "Martin Perina" 
> , "Livnat Peer" ,
> "Itamar Heim" 
> Sent: Monday, November 11, 2013 8:49:33 AM
> Subject: Custom properties per device + vNIC profile = not working (< 3.3)
> 
> Hi,
> 
> I came across a situation where I wanted to define custom properties on a
> vNIC profile sitting under a network in a 3.2 data center.
> From what I saw the configuration value for custom properties
> (CustomDeviceProperties) is split into 4, one per each version (3.0, 3.1,
> 3.2, 3.3).
> Since vNIC profile is located under the DC tree, it takes the DC version -
> 3.2 in this specific case.

Custom Device Properties were designed to be specified for each cluster version
independently, it doesn't care about DC version. AFAIK cluster version defines
what features are available ...

> 
> I tried to set the config value for 3.2 but got:
> $ engine-config -s
> CustomDeviceProperties="{type=interface;prop={myProp=[a-zA-Z0-9-]+}}"
> --cver=3.2
> Cannot set value {type=interface;prop={myProp=[a-zA-Z0-9-]+}} to key
> CustomDeviceProperties. Device custom properties are not supported in
> version 3.2
> 
> This is already not very good, since in a 3.2 DC there can be 3.3 clusters
> with 3.3 hosts that do support custom device properties.

Specify your properties for 3.3 version, since they will be used in 3.3 
clusters ...

> 
> I also tried to alter the config value in the DB directly, but the custom
> properties code ignored it since custom properties are not supported in 3.2.
> So, de facto, I have no reasonable way as a user to define custom device
> properties to use for my vNIC profiles in DC < 3.3.

There are two configuration properties  for Custom Device Properties:

1) SupportCustomDeviceProperties
 - defines in what version properties are supported
 - cannot be altered by users of course

2) CustomDeviceProperties
 - holds properties specification for each version
 - can be defined using engine-config

> 
> I opened the bug https://bugzilla.redhat.com/show_bug.cgi?id=1028757 for
> this, however I also want to discuss the situation:

I looked at the bug and the problem is, that management network profile
is bound to DC and not the Cluster. And that's something we never thought of ...

> 
> 1. As a user, I can't set custom properties for level < 3.3 which is not
> good.

Well, it's 3.3 feature, so it looks OK for me 

> Removing the blocking, and loading custom properties for all versions would
> fix the bug and allow using custom device properties for older versions, the
> reasonable place to block this would be running a VM (or plugging a device).
> Basically this is the lesser issue..
> 
> 2. I just don't see the added value of splitting the definition of the
> properties per level..

The idea behind the version splitting was:

1) We have a device with a feature that doesn't work correctly with version 3.3,
   but it's fixed in 3.4
2) By specifying custom property per version we cane disable this feature for 
3.3
   and enable for 3.4
   
> The custom properties are extensions which might or might not be available to
> a certain VM, I don't see how having different sets of custom properties per
> version (what version, DC version, cluster version?) would make any
> difference - either the VM can utilize the extension given some state of the
> system, or it can't, but the determining factor is not the version but
> rather the availability of the extension.
> For example, I can have a hook for vNIC altering some property installed on
> host A and not host B, if the VM runs on host A it will get this capability
> and on host B it won't, regardless the DC version the VM is in.
> 
> This is not to say we shouldn't block custom properties on the engine-VDSM
> API level since it's only available since 3.3, but this is handled by
> another config value (SupportCustomDeviceProperties) which is not alterable
> by the user.
> So basically, I think splitting the value per version is over complication
> and see no added value to the users, just more maintenance should they
> choose to use this feature.
> 
> Your thoughts please.

AFAIK only network and storage team wanted to use device custom properties
in 3.3 version, but I'm not sure what's current usage status.

But IMHO it's too late for 3.3 to change specification ...

Martin



___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Java Development Lifecycle

[Martin Perina]

For me the most time consuming problem is GWT compilation. It would be really 
nice
if we can agree to create some clear separation between frontend and backend 
part, for
example if frontend would communicate with backend only through REST API, GWT 
would
have to recompile only if REST API or some frontend code has been changed.

It's not something what can be done i short term, but it would be nice if we can
find a way how to do it and create a schedule for this task.



- Original Message -
> From: "Mooli Tayer" 
> To: "engine-devel" 
> Sent: Tuesday, August 27, 2013 1:29:01 PM
> Subject: [Engine-devel] Java Development Lifecycle
> 
> Hello,
> 
> I've been working on the engine for a few month now,
> And I feel I have not yet been able to find a productive and fast approach
> for Java development in different engine components.
> 
> This revolves mainly around:
> 
> Compiling and deploying artifacts:
> ==
> If I want to check a small change in the engine,
> Be it in an artifact that is part of engine.ear or when I am working on one
> of the side tools
> that might run as a service (e.g ovirt-engine-notifier)
> or just a single jar (engine-manage-domains)
> It is essential to compile only parts of the project and not all of it.
> 
> This can be achieved usually quite easily with mvn,
> however afterwards I would like to be able to also deploy and run it locally
> or even take all jars comprising a project and run them exploded inside my
> IDE
> (I use intellij idea) so I can enjoy live code editing and other benefits
> idea
> jboss & gwt integration offers. I have been using remote debug
> (which is available by default in the engine and non existent in other jars
> so
> I have to tamper manually with a python service file to add debug flags - see
> next)
> But it's not as powerful as running inside an IDE and I feel my current
> development lifecycle is
> not as fast and productive as it could have been.
> (I do understand the engine is complex regarding configuration and
> deployment, so it's a challenge)
> 
> Configuration:
> ==
> This might be more of a todo item, I'm not sure..
> After deployment of an artifact to run on a machine(again, engine, notifier
> or whatever)
> if I want to change it's configuration
> (configure it for remote debug as mentioned or change it's logging behavior
> and so on)
> It seems I always have to do it in a different place which I always spend
> hours finding.
> It could be great if for all artifacts configuration could be streamlined and
> monolithic
> across different components.
> 
> These issues might seem obvious to some of you or unneeded to others, but
> I've decided to shout out
> in engine-devel because my usual way of approaching individuals has not got
> me very far,
> and also because I'm convinced some of you have found ways to be productive I
> am unaware of -
> Please share them! Others may have their own good ideas & approaches(or their
> own needs).
> 
> Thanks,
> Mooli.
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] SSH Soft Fencing

[Martin Perina]

- Original Message -
> From: "Livnat Peer" 
> To: "Martin Perina" 
> Cc: engine-devel@ovirt.org
> Sent: Wednesday, July 3, 2013 2:32:16 PM
> Subject: Re: [Engine-devel] SSH Soft Fencing
> 
> Hi Martin,
> I have some more questions,
> - Do we persist the host root password for this feature?
> - If we do, is this feature limited for new hosts, can I provide it for
> already existing hosts?
> - Do we encrypt this value when storing in the DB?
> 
> Thanks, Livnat
> 

Well, SSH connection uses engine default SSH key, no password. So I think
this is usable for all hosts.


> 
> On 07/03/2013 02:55 PM, Martin Perina wrote:
> > Let's summarize again, SSH Soft Fencing patches has been merged yesterday
> > with following functionality:
> > 
> > 1) For hosts with power management configured, SSH Soft Fencing is the 1st
> >fencing stage. If it doesn't help, real fencing will be executed.
> > 
> > 2) For hosts without power management configured, SSH Soft Fencing is the
> > only
> >fencing stage. If it doesn't help, host will become non responsive.
> > 
> > 3) SSH Soft Fencing is enabled by default, there's no configuration option
> >to disable it
> > 
> > 4) SshSoftFencingCommand option is used to define what command is executed
> >during SSH Soft Fencing. It can only be changed manually in database.
> > 
> > The whole fencing process in oVirt 3.3 is decribed at
> > 
> > http://www.ovirt.org/Automatic_Fencing#Automatic_Fencing_in_oVirt_3.3
> > 
> > 
> > 
> > Martin Perina
> > 
> > 
> > - Original Message -
> >> From: "Michal Skrivanek" 
> >> To: engine-devel@ovirt.org
> >> Sent: Wednesday, July 3, 2013 12:03:13 PM
> >> Subject: Re: [Engine-devel] SSH Soft Fencing
> >>
> >>
> >> On Jul 2, 2013, at 10:44 , Eli Mesika  wrote:
> >>
> >>>
> >>>
> >>> - Original Message -
> >>>> From: "Livnat Peer" 
> >>>> To: "Yair Zaslavsky" 
> >>>> Cc: engine-devel@ovirt.org
> >>>> Sent: Monday, July 1, 2013 12:57:34 PM
> >>>> Subject: Re: [Engine-devel] SSH Soft Fencing
> >>>>
> >>>> On 07/01/2013 11:27 AM, Yair Zaslavsky wrote:
> >>>>>
> >>>>>
> >>>>> - Original Message -
> >>>>>> From: "Martin Perina" 
> >>>>>> To: engine-devel@ovirt.org
> >>>>>> Sent: Monday, July 1, 2013 11:23:12 AM
> >>>>>> Subject: Re: [Engine-devel] SSH Soft Fencing
> >>>>>>
> >>>>>> So let me summarize it:
> >>>>>>
> >>>>>> We have come to agreement in those questions:
> >>>>>>
> >>>>>> 1) SSH Soft Fencing logic should be extracted from
> >>>>>> VdsNotRespondingTreatment
> >>>>>>   command to its own SshSoftFencingCommand
> >>>>>>
> >>>>>> 2) VdsNotRespondingCommand should be refactored so it's not inherited
> >>>>>> from
> >>>>>>   VdsRestartCommand, but it should run SshSoftFencingCommand
> >>>>>>   or VdsRestartCommand based on defined fencing flow
> >>>>>>
> >>>>>>
> >>>>>> These questions has not been resolved yet:
> >>>>>>
> >>>>>> 3) Should SSH Soft Fencing be executed also for hosts without PM
> >>>>>> configured?
> >>>>>>
> >>>>>> 4) Should SSH Soft Fencing execution for hosts without PM configured
> >>>>>> be
> >>>>>> enabled
> >>>>>>   by default and admin can turn off these feature using configuration
> >>>>>>   options
> >>>>>>   SshSoftFencingWithoutPmEnabled (or something like that)?
> >>>>>>
> >>>>>> 5) Should SshSoftFencingWithoutPmEnabled be a global option or a
> >>>>>> cluster
> >>>>>> wide
> >>>>>>   option (can be turned off for specific cluster version) or a VDS
> >>>>>>   option
> >>>>>>   (it can be turned off for each host)?
> >>>>>>
> >>>>>>
> >>>>>> Personally I would sugge

Re: [Engine-devel] SSH Soft Fencing

[Martin Perina]

Let's summarize again, SSH Soft Fencing patches has been merged yesterday
with following functionality:

1) For hosts with power management configured, SSH Soft Fencing is the 1st
   fencing stage. If it doesn't help, real fencing will be executed.

2) For hosts without power management configured, SSH Soft Fencing is the only
   fencing stage. If it doesn't help, host will become non responsive.

3) SSH Soft Fencing is enabled by default, there's no configuration option
   to disable it

4) SshSoftFencingCommand option is used to define what command is executed
   during SSH Soft Fencing. It can only be changed manually in database.

The whole fencing process in oVirt 3.3 is decribed at

http://www.ovirt.org/Automatic_Fencing#Automatic_Fencing_in_oVirt_3.3



Martin Perina


- Original Message -
> From: "Michal Skrivanek" 
> To: engine-devel@ovirt.org
> Sent: Wednesday, July 3, 2013 12:03:13 PM
> Subject: Re: [Engine-devel] SSH Soft Fencing
> 
> 
> On Jul 2, 2013, at 10:44 , Eli Mesika  wrote:
> 
> > 
> > 
> > - Original Message -
> >> From: "Livnat Peer" 
> >> To: "Yair Zaslavsky" 
> >> Cc: engine-devel@ovirt.org
> >> Sent: Monday, July 1, 2013 12:57:34 PM
> >> Subject: Re: [Engine-devel] SSH Soft Fencing
> >> 
> >> On 07/01/2013 11:27 AM, Yair Zaslavsky wrote:
> >>> 
> >>> 
> >>> - Original Message -
> >>>> From: "Martin Perina" 
> >>>> To: engine-devel@ovirt.org
> >>>> Sent: Monday, July 1, 2013 11:23:12 AM
> >>>> Subject: Re: [Engine-devel] SSH Soft Fencing
> >>>> 
> >>>> So let me summarize it:
> >>>> 
> >>>> We have come to agreement in those questions:
> >>>> 
> >>>> 1) SSH Soft Fencing logic should be extracted from
> >>>> VdsNotRespondingTreatment
> >>>>   command to its own SshSoftFencingCommand
> >>>> 
> >>>> 2) VdsNotRespondingCommand should be refactored so it's not inherited
> >>>> from
> >>>>   VdsRestartCommand, but it should run SshSoftFencingCommand
> >>>>   or VdsRestartCommand based on defined fencing flow
> >>>> 
> >>>> 
> >>>> These questions has not been resolved yet:
> >>>> 
> >>>> 3) Should SSH Soft Fencing be executed also for hosts without PM
> >>>> configured?
> >>>> 
> >>>> 4) Should SSH Soft Fencing execution for hosts without PM configured be
> >>>> enabled
> >>>>   by default and admin can turn off these feature using configuration
> >>>>   options
> >>>>   SshSoftFencingWithoutPmEnabled (or something like that)?
> >>>> 
> >>>> 5) Should SshSoftFencingWithoutPmEnabled be a global option or a cluster
> >>>> wide
> >>>>   option (can be turned off for specific cluster version) or a VDS
> >>>>   option
> >>>>   (it can be turned off for each host)?
> >>>> 
> >>>> 
> >>>> Personally I would suggest:
> >>>> 
> >>>> ad 3) Yes, SSH Soft Fencing should be executed also for hosts without PM
> >>>> configured
> >>>> 
> >> 
> >> 
> >> +1
> >> 
> >>>> ad 4) Yes, SSH Soft Fencing for hosts without PM configured should be
> >>>> enabled by default
> >>>> 
> >> 
> >> +1
> >> 
> >>>> ad 5) I don't see any significant reason why someone would like to turn
> >>>> off
> >>>> SSH Soft Fencing
> >>>>   for hosts without PM configured. But if someone would like to do
> >>>>   that,
> >>>>   I think
> >>>>   he would like to turn it off only for specific hosts, so VDS level
> >>>>   option makes sense
> >>>>   for me
> >>> 
> >>> After re-thinking 5 - I agree.
> >>> +1 on the other suggestions, but of course we need to get more consensus
> >>> here.
> >>> 
> >> 
> >> I think it does not need to be configurable.
> 
> I think a configuration option, as cumbersome and confusing as it can be, is
> still better than no choice. Especially if it means to restore the previous
> behavior.
> If it only can happen in a theoretical problem at customer where vdsm restart
> cause issues for whatever theoretical reason….it would be of great help
> then.
> And if you don't understand the parameter - just don't touch it, I hope
> that's a general rule:-)
>
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] SSH Soft Fencing

[Martin Perina]

So let me summarize it:

We have come to agreement in those questions:

1) SSH Soft Fencing logic should be extracted from VdsNotRespondingTreatment
   command to its own SshSoftFencingCommand

2) VdsNotRespondingCommand should be refactored so it's not inherited from
   VdsRestartCommand, but it should run SshSoftFencingCommand
   or VdsRestartCommand based on defined fencing flow


These questions has not been resolved yet:

3) Should SSH Soft Fencing be executed also for hosts without PM configured?

4) Should SSH Soft Fencing execution for hosts without PM configured be enabled
   by default and admin can turn off these feature using configuration options
   SshSoftFencingWithoutPmEnabled (or something like that)?

5) Should SshSoftFencingWithoutPmEnabled be a global option or a cluster wide
   option (can be turned off for specific cluster version) or a VDS option
   (it can be turned off for each host)?


Personally I would suggest:

 ad 3) Yes, SSH Soft Fencing should be executed also for hosts without PM 
configured

 ad 4) Yes, SSH Soft Fencing for hosts without PM configured should be enabled 
by default

 ad 5) I don't see any significant reason why someone would like to turn off 
SSH Soft Fencing
   for hosts without PM configured. But if someone would like to do that, I 
think
   he would like to turn it off only for specific hosts, so VDS level 
option makes sense
   for me


Martin
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Problem with development environment

[Martin Perina]

Hi,

workaround helped.

Thanks

Martin


- Original Message -
> From: "Alon Bar-Lev" 
> To: "Martin Perina" 
> Cc: engine-devel@ovirt.org
> Sent: Friday, June 28, 2013 9:46:36 AM
> Subject: Re: [Engine-devel] Problem with development environment
> 
> 
> Hello Marina,
> 
> Thank you for the report.
> 
> I can confirm that.
> 
> Workaround:
> 
> rm -f packaging/dbscripts/upgrade.sh.log
> 
> I will fix that soon.
> 
> Thanks,
> Alon
> 
> - Original Message -
> > From: "Martin Perina" 
> > To: engine-devel@ovirt.org
> > Sent: Friday, June 28, 2013 8:59:53 AM
> > Subject: [Engine-devel] Problem with development environment
> > 
> > Hi,
> > 
> > I've encountered a problem using development environment. When I run
> > 
> >  make clean install-dev PREFIX="$HOME/ovirt-engine"
> > 
> > there appears this error message:
> > 
> > make[2]: Leaving directory `/home/mperina/projects/ovirt/ovirt-engine'
> > # we should avoid make these directories dirty
> > make copy-recursive SOURCEDIR=packaging/dbscripts
> > TARGETDIR="/home/mperina/ovirt-engine/share/ovirt-engine/dbscripts" \
> > EXCLUDE_GEN="packaging/bin/engine-prolog.sh packaging/bin/pki-common.sh
> > packaging/conf/engine.conf.defaults 
> > packaging/conf/notifier.conf.defaults
> > packaging/conf/ovirt-websocket-proxy.conf.defaults
> > packaging/etc/engine-config/log4j.xml
> > packaging/etc/engine-manage-domains/log4j.xml
> > packaging/etc/engine-manage-domains/engine-manage-domains.conf
> > packaging/etc/notifier/log4j.xml
> > packaging/sys-etc/logrotate.d/ovirt-engine
> > packaging/services/config.py packaging/services/ovirt-engine.systemd
> > packaging/services/ovirt-engine.sysv
> > packaging/services/ovirt-engine-notifier.systemd
> > packaging/services/ovirt-engine-notifier.sysv
> > packaging/services/ovirt-websocket-proxy.systemd
> > packaging/services/ovirt-websocket-proxy.sysv
> > packaging/setup/ovirt_engine_setup/config.py
> > packaging/bin/ovirt-engine-log-setup-event.sh ovirt-engine.spec " \
> > EXCLUDE="$(find packaging/dbscripts \( -name '*.scripts.md5' -or -name
> > '*.schema' -or -name '*.log' \))"
> > make[2]: Entering directory `/home/mperina/projects/ovirt/ovirt-engine'
> > ( cd "packaging/dbscripts" && find . -type d -printf '%P\n' ) | while read
> > d;
> > do \
> > install -d -m 755
> > "/home/mperina/ovirt-engine/share/ovirt-engine/dbscripts/${d}"; \
> > done
> > ( \
> > cd "packaging/dbscripts" && find . -type f -printf '%P\n' | \
> > while read f; do \
> > exclude=false; \
> > set -x; \
> > for x in packaging/bin/engine-prolog.sh 
> > packaging/bin/pki-common.sh
> > packaging/conf/engine.conf.defaults 
> > packaging/conf/notifier.conf.defaults
> > packaging/conf/ovirt-websocket-proxy.conf.defaults
> > packaging/etc/engine-config/log4j.xml
> > packaging/etc/engine-manage-domains/log4j.xml
> > packaging/etc/engine-manage-domains/engine-manage-domains.conf
> > packaging/etc/notifier/log4j.xml
> > packaging/sys-etc/logrotate.d/ovirt-engine 
> > packaging/services/config.py
> > packaging/services/ovirt-engine.systemd
> > packaging/services/ovirt-engine.sysv
> > packaging/services/ovirt-engine-notifier.systemd
> > packaging/services/ovirt-engine-notifier.sysv
> > packaging/services/ovirt-websocket-proxy.systemd
> > packaging/services/ovirt-websocket-proxy.sysv
> > packaging/setup/ovirt_engine_setup/config.py
> > packaging/bin/ovirt-engine-log-setup-event.sh ovirt-engine.spec 
> > ; do \
> > if [ "packaging/dbscripts/${f}" = "${x}.in" ]; then \
> > exclude=true; \
> > break; \
> > fi; \
> > done; \
> > for x in packaging/dbscripts/upgrade.sh.log
> > /bin/sh: -c: line 12: syntax error: unexpected end of file
> > make[2]: *** [copy-recursive] Error 1
> > make[2]: Leaving directory `/home/mperina/projects/ovirt/ovirt-engine'
> > make[1]: *** [install-packaging-files] Error 2
> > make[1]: Leaving directory `/home/mperina/projects/ovirt/ovirt-engine'
> > make: *** [install-dev] Error 2
> > 
> > 
> > I've already upgraded to otopi 1.1 (currently
> > 1.1.0-0.0.master.20130626.git33d9561.fc18).
> > 
> > 
> > Martin Perina
> > 
> > ___
> > Engine-devel mailing list
> > Engine-devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

[Engine-devel] Problem with development environment

[Martin Perina]

Hi,

I've encountered a problem using development environment. When I run

 make clean install-dev PREFIX="$HOME/ovirt-engine"

there appears this error message:

make[2]: Leaving directory `/home/mperina/projects/ovirt/ovirt-engine'
# we should avoid make these directories dirty
make copy-recursive SOURCEDIR=packaging/dbscripts 
TARGETDIR="/home/mperina/ovirt-engine/share/ovirt-engine/dbscripts" \
EXCLUDE_GEN="packaging/bin/engine-prolog.sh packaging/bin/pki-common.sh 
packaging/conf/engine.conf.defaults packaging/conf/notifier.conf.defaults 
packaging/conf/ovirt-websocket-proxy.conf.defaults 
packaging/etc/engine-config/log4j.xml 
packaging/etc/engine-manage-domains/log4j.xml 
packaging/etc/engine-manage-domains/engine-manage-domains.conf 
packaging/etc/notifier/log4j.xml packaging/sys-etc/logrotate.d/ovirt-engine 
packaging/services/config.py packaging/services/ovirt-engine.systemd 
packaging/services/ovirt-engine.sysv 
packaging/services/ovirt-engine-notifier.systemd 
packaging/services/ovirt-engine-notifier.sysv 
packaging/services/ovirt-websocket-proxy.systemd 
packaging/services/ovirt-websocket-proxy.sysv 
packaging/setup/ovirt_engine_setup/config.py 
packaging/bin/ovirt-engine-log-setup-event.sh ovirt-engine.spec " \
EXCLUDE="$(find packaging/dbscripts \( -name '*.scripts.md5' -or -name 
'*.schema' -or -name '*.log' \))"
make[2]: Entering directory `/home/mperina/projects/ovirt/ovirt-engine'
( cd "packaging/dbscripts" && find . -type d -printf '%P\n' ) | while read d; 
do \
install -d -m 755 
"/home/mperina/ovirt-engine/share/ovirt-engine/dbscripts/${d}"; \
done
( \
cd "packaging/dbscripts" && find . -type f -printf '%P\n' | \
while read f; do \
exclude=false; \
set -x; \
for x in packaging/bin/engine-prolog.sh 
packaging/bin/pki-common.sh packaging/conf/engine.conf.defaults 
packaging/conf/notifier.conf.defaults 
packaging/conf/ovirt-websocket-proxy.conf.defaults 
packaging/etc/engine-config/log4j.xml 
packaging/etc/engine-manage-domains/log4j.xml 
packaging/etc/engine-manage-domains/engine-manage-domains.conf 
packaging/etc/notifier/log4j.xml packaging/sys-etc/logrotate.d/ovirt-engine 
packaging/services/config.py packaging/services/ovirt-engine.systemd 
packaging/services/ovirt-engine.sysv 
packaging/services/ovirt-engine-notifier.systemd 
packaging/services/ovirt-engine-notifier.sysv 
packaging/services/ovirt-websocket-proxy.systemd 
packaging/services/ovirt-websocket-proxy.sysv 
packaging/setup/ovirt_engine_setup/config.py 
packaging/bin/ovirt-engine-log-setup-event.sh ovirt-engine.spec ; do \
if [ "packaging/dbscripts/${f}" = "${x}.in" ]; then \
exclude=true; \
break; \
fi; \
done; \
for x in packaging/dbscripts/upgrade.sh.log
/bin/sh: -c: line 12: syntax error: unexpected end of file
make[2]: *** [copy-recursive] Error 1
make[2]: Leaving directory `/home/mperina/projects/ovirt/ovirt-engine'
make[1]: *** [install-packaging-files] Error 2
make[1]: Leaving directory `/home/mperina/projects/ovirt/ovirt-engine'
make: *** [install-dev] Error 2


I've already upgraded to otopi 1.1 (currently 
1.1.0-0.0.master.20130626.git33d9561.fc18).


Martin Perina

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

[Engine-devel] SSH Soft Fencing

[Martin Perina]

Hi,

SSH Soft Fencing is a new feature for 3.3 and it tries to restart VDSM
using SSH connection on non responsive hosts prior to real fencing.
More info can be found at 

http://www.ovirt.org/Automatic_Fencing#Automatic_Fencing_in_oVirt_3.3

In current SSH Soft Fencing implementation the restart VDSM using SSH
command is part of standard fencing implementation in 
VdsNotRespondingTreatmentCommand. But this command is executed only
if a host has a valid PM configuration. If host doesn't have a valid
PM configuration, the execution of the command is disabled and host
state is change to Non Responsive.

So my question are:

1) Should SSH Soft Fencing be executed on hosts without valid PM
   configuration?

2) Should VDSM restart using SSH command be reimplemented
   as standalone command to be usable also in other parts of engine?
   If 1) is true, I think it will have to be done anyway.


Martin Perina
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

[Engine-devel] Engine config and device custom properties

[Martin Perina]

Hi,

I'm working on a patch to support custom device properties in ovirt-engine.
I would like that custom device properties format can be set using engine-config
command in a similar way as UserDefinedVMProperties. What is needed to be done
to support this?

Thanks

Martin
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Device custom properties

[Martin Perina]

- Original Message -
> From: "Martin Perina" 
> To: "Eli Mesika" 
> Cc: engine-devel@ovirt.org
> Sent: Thursday, May 9, 2013 10:31:07 AM
> Subject: Re: [Engine-devel] Device custom properties
> 
> 
> 
> - Original Message -
> > From: "Eli Mesika" 
> > To: "Martin Perina" 
> > Cc: engine-devel@ovirt.org
> > Sent: Sunday, May 5, 2013 9:18:07 AM
> > Subject: Re: [Engine-devel] Device custom properties
> > 
> > 
> > 
> > - Original Message -
> > > From: "Martin Perina" 
> > > To: engine-devel@ovirt.org
> > > Sent: Saturday, May 4, 2013 8:13:44 AM
> > > Subject: Re: [Engine-devel] Device custom properties
> > > 
> > > 
> > > 
> > > - Original Message -
> > > > From: "Martin Perina" 
> > > > To: engine-devel@ovirt.org
> > > > Sent: Friday, May 3, 2013 11:06:05 AM
> > > > Subject: [Engine-devel] Device custom properties
> > > > 
> > > > Hi,
> > > >  
> > > > I'm currently trying to implement device custom properties
> > > > infrastructure
> > > > in
> > > > ovirt-engine.
> > > > During discussion with Yair, we found out, that it's not clear, for
> > > > what
> > > > type
> > > > of devices
> > > > custom properties should be available? In engine we have the
> > > > VmDeviceType
> > > > enum which
> > > > contains following values:
> > > >  
> > > >  FLOPPY("floppy", "14"),
> > > >  DISK("disk", "17"),
> > > >  CDROM("cdrom", "15"),
> > > >  INTERFACE("interface", "10"),
> > > >  BRIDGE("bridge", "3"),
> > > >  VIDEO("video", "20"),
> > > >  USB("usb", "23"),
> > > >  CONTROLLER("controller", "23"),
> > > >  REDIR("redir", "23"),
> > > >  SPICEVMC("spicevmc", "23"),
> > > >  QXL("qxl"),
> > > >  CIRRUS("cirrus"),
> > > >  SOUND("sound"),
> > > >  ICH6("ich6"),
> > > >  AC97("ac97"),
> > > >  MEMBALLOON("memballoon"),
> > > >  SMARTCARD("smartcard"),
> > > >  BALLOON("balloon"),
> > > >  OTHER("other", "0"),
> > > >  UNKNOWN("unknown", "-1");
> > > >  
> > > > But VmDevice class has two String attributes device and type. So for
> > > > example
> > > > a disk is a device
> > > > which has device set to disk and type set to disk (according to
> > > > VmDeviceCommonUtils.isDisk method).
> > > >  
> > > > So my question is, if I have a custom properties for disk, will they be
> > > > available for all disk
> > > > devices (disk, cdrom, floppy, ...) or only for real disk? So should we
> > > > support custom properties
> > > > for all VmDeviceType enum value separately?
> > > > 
> > > > Thanks for suggestions
> > > > 
> > > > Martin
> > 
> > The reason for that difference is that we had types in the backend code
> > only
> > for managed devices . (i.e. devoices that are known and handled by the
> > backend)
> > Any other device as balloon etc. is considered as unmanaged device , that
> > means that VDSM tells us that it exists and therefore tell us its type as
> > well...
> > 
> > 
> 
> Ok, I understand this.
> 
> But there are also OTHER and UNKNOWN device types in backend, but these types
> doesn't
> corresponds to ANY type in VDSM. I don't want to refactor VmDevice device and
> type attributes
> too much, so is it safe to expect that device attribute of VmDevice can only
> contain
> one of VDSM device types ('disk', 'interface', 'video', 'sound',
> 'controller', 'balloon',
> 'channel', 'console', 'smartcard')? It's really important question, because
> replacing
> String type with enum would save a lot of code in device custom properties
> implementation.
> 

Sorry, I wrote wrong attribute. Do you think it's safe to expect that type 
attribute
of VmDevice can only contain one of VDSM device types ('disk', 'interface', 
'video', 'sound',
'controller', 'balloon', 'channel', 'console', 'smartcard')?

Martin
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Device custom properties

[Martin Perina]

- Original Message -
> From: "Eli Mesika" 
> To: "Martin Perina" 
> Cc: engine-devel@ovirt.org
> Sent: Sunday, May 5, 2013 9:18:07 AM
> Subject: Re: [Engine-devel] Device custom properties
> 
> 
> 
> - Original Message -
> > From: "Martin Perina" 
> > To: engine-devel@ovirt.org
> > Sent: Saturday, May 4, 2013 8:13:44 AM
> > Subject: Re: [Engine-devel] Device custom properties
> > 
> > 
> > 
> > - Original Message -
> > > From: "Martin Perina" 
> > > To: engine-devel@ovirt.org
> > > Sent: Friday, May 3, 2013 11:06:05 AM
> > > Subject: [Engine-devel] Device custom properties
> > > 
> > > Hi,
> > >  
> > > I'm currently trying to implement device custom properties infrastructure
> > > in
> > > ovirt-engine.
> > > During discussion with Yair, we found out, that it's not clear, for what
> > > type
> > > of devices
> > > custom properties should be available? In engine we have the VmDeviceType
> > > enum which
> > > contains following values:
> > >  
> > >  FLOPPY("floppy", "14"),
> > >  DISK("disk", "17"),
> > >  CDROM("cdrom", "15"),
> > >  INTERFACE("interface", "10"),
> > >  BRIDGE("bridge", "3"),
> > >  VIDEO("video", "20"),
> > >  USB("usb", "23"),
> > >  CONTROLLER("controller", "23"),
> > >  REDIR("redir", "23"),
> > >  SPICEVMC("spicevmc", "23"),
> > >  QXL("qxl"),
> > >  CIRRUS("cirrus"),
> > >  SOUND("sound"),
> > >  ICH6("ich6"),
> > >  AC97("ac97"),
> > >  MEMBALLOON("memballoon"),
> > >  SMARTCARD("smartcard"),
> > >  BALLOON("balloon"),
> > >  OTHER("other", "0"),
> > >  UNKNOWN("unknown", "-1");
> > >  
> > > But VmDevice class has two String attributes device and type. So for
> > > example
> > > a disk is a device
> > > which has device set to disk and type set to disk (according to
> > > VmDeviceCommonUtils.isDisk method).
> > >  
> > > So my question is, if I have a custom properties for disk, will they be
> > > available for all disk
> > > devices (disk, cdrom, floppy, ...) or only for real disk? So should we
> > > support custom properties
> > > for all VmDeviceType enum value separately?
> > > 
> > > Thanks for suggestions
> > > 
> > > Martin
> 
> The reason for that difference is that we had types in the backend code only
> for managed devices . (i.e. devoices that are known and handled by the
> backend)
> Any other device as balloon etc. is considered as unmanaged device , that
> means that VDSM tells us that it exists and therefore tell us its type as
> well...
> 
> 

Ok, I understand this.

But there are also OTHER and UNKNOWN device types in backend, but these types 
doesn't
corresponds to ANY type in VDSM. I don't want to refactor VmDevice device and 
type attributes
too much, so is it safe to expect that device attribute of VmDevice can only 
contain
one of VDSM device types ('disk', 'interface', 'video', 'sound', 'controller', 
'balloon',
'channel', 'console', 'smartcard')? It's really important question, because 
replacing
String type with enum would save a lot of code in device custom properties 
implementation.

Martin

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Device custom properties

[Martin Perina]

- Original Message -
> From: "Martin Perina" 
> To: engine-devel@ovirt.org
> Sent: Friday, May 3, 2013 11:06:05 AM
> Subject: [Engine-devel] Device custom properties
> 
> Hi,
>  
> I'm currently trying to implement device custom properties infrastructure in
> ovirt-engine.
> During discussion with Yair, we found out, that it's not clear, for what type
> of devices
> custom properties should be available? In engine we have the VmDeviceType
> enum which
> contains following values:
>  
>  FLOPPY("floppy", "14"),
>  DISK("disk", "17"),
>  CDROM("cdrom", "15"),
>  INTERFACE("interface", "10"),
>  BRIDGE("bridge", "3"),
>  VIDEO("video", "20"),
>  USB("usb", "23"),
>  CONTROLLER("controller", "23"),
>  REDIR("redir", "23"),
>  SPICEVMC("spicevmc", "23"),
>  QXL("qxl"),
>  CIRRUS("cirrus"),
>  SOUND("sound"),
>  ICH6("ich6"),
>  AC97("ac97"),
>  MEMBALLOON("memballoon"),
>  SMARTCARD("smartcard"),
>  BALLOON("balloon"),
>  OTHER("other", "0"),
>  UNKNOWN("unknown", "-1");
>  
> But VmDevice class has two String attributes device and type. So for example
> a disk is a device
> which has device set to disk and type set to disk (according to
> VmDeviceCommonUtils.isDisk method).
>  
> So my question is, if I have a custom properties for disk, will they be
> available for all disk
> devices (disk, cdrom, floppy, ...) or only for real disk? So should we
> support custom properties
> for all VmDeviceType enum value separately?
> 
> Thanks for suggestions
> 
> Martin



I've looked at VDSM code, here are device type even more detailed (please 
correct me if I'm wrong):

DEVICE TYPE
'disk' 'disk', 'cdrom', 'floppy'
'interface''bridge'
'video''cirrus', 'std', 'vmware', 'qxl', 'none'
'sound''ac97', 'pcspk', 'sb16', 'es1370', 'hda', 'ich6'
'controller'   'ide', 'fdc', 'scsi', 'sata', 'usb', 'ccid', 'virtio-serial'
'balloon'  'memballoon'
'channel'  'unix', 'spicevmc', 'virtio-serial'
'console'  'console'
'smartcard''smartcard'
'watchdog' 'watchdog'

So I suggest to refactor engine device type to match VDSM side and engine will 
support device
custom properties to be set for these devices types:

'disk', 'interface', 'video', 'sound', 'controller', 'balloon', 'channel', 
'console', 'smartcard', 'watchdog'

Is it ok?


Martin


___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

[Engine-devel] Device custom properties

[Martin Perina]

Hi,
 
I'm currently trying to implement device custom properties infrastructure in 
ovirt-engine.
During discussion with Yair, we found out, that it's not clear, for what type 
of devices
custom properties should be available? In engine we have the VmDeviceType enum 
which
contains following values:
 
 FLOPPY("floppy", "14"),
 DISK("disk", "17"),
 CDROM("cdrom", "15"),
 INTERFACE("interface", "10"),
 BRIDGE("bridge", "3"),
 VIDEO("video", "20"),
 USB("usb", "23"),
 CONTROLLER("controller", "23"),
 REDIR("redir", "23"),
 SPICEVMC("spicevmc", "23"),
 QXL("qxl"),
 CIRRUS("cirrus"),
 SOUND("sound"),
 ICH6("ich6"),
 AC97("ac97"),
 MEMBALLOON("memballoon"),
 SMARTCARD("smartcard"),
 BALLOON("balloon"),
 OTHER("other", "0"),
 UNKNOWN("unknown", "-1");
 
But VmDevice class has two String attributes device and type. So for example a 
disk is a device
which has device set to disk and type set to disk (according to 
VmDeviceCommonUtils.isDisk method).
 
So my question is, if I have a custom properties for disk, will they be 
available for all disk
devices (disk, cdrom, floppy, ...) or only for real disk? So should we support 
custom properties
for all VmDeviceType enum value separately?

Thanks for suggestions

Martin
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] cannot sign in to gerrit.ovirt.org with google ID?

[Martin Perina]

> > - Original Message -
> > From: "Martin Perina" 
> > Sent: Thursday, May 2, 2013 9:06:58 AM
> > 
> > Hi Einav,
> 
> Hi Martin,
> 
> > 
> > I don't have any problems signing into gerrit.ovirt.org using my google
> > account, I've just tried
> > it few minutes ago. You can try to look at your G+ account / Security
> > settings / Connected
> > applications and sites, if gerrit.ovirt.org is among them.
> 
> yes, I already have gerrit.ovirt.org among them. thanks.
> 

So try to revoke it, restart browser and try to login to gerrit again.

Martin
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] cannot sign in to gerrit.ovirt.org with google ID?

[Martin Perina]

Hi Einav,

I don't have any problems signing into gerrit.ovirt.org using my google 
account, I've just tried
it few minutes ago. You can try to look at your G+ account / Security settings 
/ Connected
applications and sites, if gerrit.ovirt.org is among them.

Martin


- Original Message -
> From: "Einav Cohen" 
> To: "Tomas Jelinek" 
> Cc: "engine-devel" 
> Sent: Thursday, May 2, 2013 2:57:08 PM
> Subject: Re: [Engine-devel] cannot sign in to gerrit.ovirt.org with google ID?
> 
> Hi Tomas,
> 
> > I had this issue when I have enabled the google+ on my account - it changes
> > something with openID.
> > Did you do this?
> 
> I enabled google+ on my account a *long* time ago, however problems with
> signing
> into gerrit started only today (yesterday it worked fine).
> I haven't changed anything in my google account settings recently.
> other ideas?...
> 
> > 
> > Tomas
> > 
> > - Original Message -
> > > From: "Einav Cohen" 
> > > To: "engine-devel" 
> > > Sent: Thursday, May 2, 2013 2:45:42 PM
> > > Subject: [Engine-devel] cannot sign in to gerrit.ovirt.org with google
> > > ID?
> > > 
> > > Hi,
> > > 
> > > It seems that I cannot log into gerrit.ovirt.org web-interface with my
> > > google ID anymore: when attempting to sign-in, it asks me for my Open ID,
> > > and when providing my google ID - the page just refreshes without signing
> > > me in.
> > > [see attached video]
> > > [same behavior from FireFox and Chrome]
> > > [tried deleting cookies/history/etc...]
> > > [I experience no problems signing in with my google account to
> > > chrome/gmail]
> > > [I can sign in to gerrit.ovirt.org with my Yahoo ID (as an "Anonymous
> > > Coward"...)]
> > > 
> > > did someone else experience that? any idea how to solve it?
> > > 
> > > 
> > > Thanks,
> > > Einav
> > > ___
> > > Engine-devel mailing list
> > > Engine-devel@ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > ___
> > Engine-devel mailing list
> > Engine-devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> > 
> > 
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

[Engine-devel] Added support for POSIX and GNU long parameters to engine-manage-domains

[Martin Perina]

Hi,

I've created a patch that adds support for POSIX and GNU long paramaters.
Patch is using argparse4j library (argparse4j.sourceforge.net), which suites
our needs in my opinion better than other libraries I've tested (JCommander,
commons-cli, args4j).

Patch includes these changes:

1) "-action" parameter has been removed, each action is specified
   directly, for example "engine-manage-domains list"
2) "-interactive" parameter has been removed, if "--passwordFile"
   parameter is not specified, then the password will be read
   interactively
3) "-addPermissions" parameter has been rename to "--superuser" with
   "-s" short version
4) Each parameter has POSIX variant ("-p PROVIDER") and corresponding
   GNU long variant ("--provider=PROVIDER")
5) Commands and parameters names can be abbreviated as long as
   the abbreviation is unambiguous (for example "list" command can be
   specified like "engine-manage-domains l")

So for example command to create a domain now may look like this:

engine-manage-domains add -d xyz.com -p IPA -u admin
engine-manage-domains add --domain=xyz.com --provider=IPA --user=admin
engine-manage-domains a -d xyz.com -p ipa --user=admin

All variants do the same.


If you're interested, please review the patch:

http://gerrit.ovirt.org/#/c/13776/


Regards

Martin Perina

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Adding JCommander library to projects

[Martin Perina]

- Original Message -
> From: "Alon Bar-Lev" 
> To: "Martin Perina" 
> Cc: engine-devel@ovirt.org
> Sent: Thursday, March 28, 2013 10:18:19 AM
> Subject: Re: [Engine-devel] Adding JCommander library to projects
> 
> 
> 
> - Original Message -
> > From: "Martin Perina" 
> > To: engine-devel@ovirt.org
> > Sent: Thursday, March 28, 2013 10:48:07 AM
> > Subject: [Engine-devel] Adding JCommander library to projects
> > 
> > Hi,
> > 
> > I'm currently working on bug 904029, support for POSIX parameters
> > and
> > values
> > in engine-manage-domains. I think there are two possible solutions:
> > 
> >   1) Write custom parser (similar to EngineConfigCLIParser used for
> >   engine-config)
> >   2) Add CLI parsing library to project and use it for all command
> >   line clients
> >  (first implementation could be for engine-manage-domains)
> > 
> > I think 2) is much better approach, but I'm not sure about the
> > process of adding new
> > library to project.
> > 
> > Personally I like JCommander ( http://jcommander.org ), using
> > annotation for parameter
> > specification is great. JCommander is licensed with Apache 2.0
> > license, so the addition
> > shouldn't be a problem.
> > 
> > So, would it be possible to add JCommander library to project?
> 
> I believe that any other solution will be better than current
> situation.
> 
> However, I recommend of horizontal change when such introduced,
> leaving hybrid implementation in tree will just make maintenance
> cost higher when introducing new dependency. It should not be that
> difficult to port all current implementation to the new dependency
> when selected.
> 
> Regards,
> Alon.
> 

Sure, reference implementation will be for engine-manage-domains
and after that I will implement this solution for the rest of commands.

Martin
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

[Engine-devel] Adding JCommander library to projects

[Martin Perina]

Hi,

I'm currently working on bug 904029, support for POSIX parameters and values
in engine-manage-domains. I think there are two possible solutions:

  1) Write custom parser (similar to EngineConfigCLIParser used for 
engine-config)
  2) Add CLI parsing library to project and use it for all command line clients
 (first implementation could be for engine-manage-domains)

I think 2) is much better approach, but I'm not sure about the process of 
adding new
library to project.

Personally I like JCommander ( http://jcommander.org ), using annotation for 
parameter
specification is great. JCommander is licensed with Apache 2.0 license, so the 
addition
shouldn't be a problem.

So, would it be possible to add JCommander library to project?

Martin Perina


___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Move SQL out of stored procedures

[Martin Perina]

Hello,

according to my experiences Hibernate/JPA is the best solution for application
which has to support multiple databases. Even when I was part of the team who
migrated application with business login written in Oracle PL/SQL procedures
to JBoss using Hibernate (application ran only on Oracle), it became much easier
to maintain this applications and also customer was pleased that application
ran much better.

Now imagine the scenario, that for example Postgresql, MySQL, Oracle and MS SQL 
would be
supported. I you need to change some stored procedure you should do this on 4 
places using
4 different database dialects.

Like any other technologies, Hibernate/JPA has some drawbacks, but when it's 
used properly
and database objects are redesigned to fit Hibernate and portability needs, it 
works fine.



Martin Perina


- Original Message -
> From: "Alon Bar-Lev" 
> To: "Juan Hernandez" 
> Cc: engine-devel@ovirt.org
> Sent: Tuesday, March 26, 2013 7:39:16 PM
> Subject: Re: [Engine-devel] Move SQL out of stored procedures
> 
> 
> 
> - Original Message -
> > From: "Juan Hernandez" 
> > To: engine-devel@ovirt.org
> > Sent: Tuesday, March 26, 2013 7:34:04 PM
> > Subject: [Engine-devel] Move SQL out of stored procedures
> > 
> > Hello,
> > 
> > I would like to start a discussion about the subject. I think this
> > is
> > something we need to do if one day we want to be able to use any
> > database other than PostgreSQL.
> 
> Hello,
> 
> I think that database layer is a software interface like any other
> software interface, if done properly, a dba can convert the stored
> procedure to any other database without any code change.
> 
> This way the database specific implementation lives within the
> database and maintained by the designated dba.
> 
> Fixups and optimizations can be done in database without touching the
> code.
> 
> Backward compatibility layer is much simpler to implement based on
> stored procedures than complex set of views and tables.
> 
> Also, accessing the database via different technologies is simpler if
> there is maintained database interface (stored procedures).
> 
> I've seen hibernate based java applications that promised to be
> database independent but at the edges when performance counts, the
> DAO became HQL, then a special dialect and finally database specific
> SQLS.
> 
> Regards,
> Alon Bar-Lev.
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel