Re: [ovirt-devel] Important change in UI plugins REST API integration

2014-12-02 Thread Sven Kieske


On 01/12/14 20:26, Vojtech Szocs wrote:
 In other words, usability of REST session ID is now strictly
 scoped to GUI user being authenticated. If the user logs in,
 (always) new REST session ID will be passed to all UI plugins.
 If the user logs out, REST session ID will not work anymore.

What if I use just REST for logging in and doing something
without any GUI interaction at all?

this reads a little like: you always need an open web gui
to be able to use REST, which does not make sense at all.

So I guess I'm misreading this?

-- 
Mit freundlichen Grüßen / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH  Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] How To Auto Set oVirt RESTApi Session?

2014-12-02 Thread Alexander Wels
On Tuesday, December 02, 2014 09:45:49 AM 王成俊 wrote:
 Hi,awels:
 
  Thanks for your reply!
 
  I make this servlet to run the backend action which
 names LoginAdminUser, because I want to check admin log in with it,so
 that my engine no need to log in through engine's loginpopupview.
 
  But when I log in through my servlet,the restapi can not get the
 user's certificate.
 
  Can you tell me how to set and resume the restapi session in my case?
 
  Thanks!
 
 Best Regards!
 

You can login to the REST api using standard http connection techniques. For 
instance basic auth you can login doing the following:

http://user%40domain:password@engine_host/ovirt-engine/api

Will list the available REST api.

But I am still not clear on what you are trying to do. Are you trying to write 
your own external servlet, that calls the REST api to do things for you? Or 
are you trying to write a servlet that lives inside the context of the engine 
and implements a new action?

Also please reply all, so we can keep the discussion on the mailing list so 
other people can find it in the future.

Alexander


 2014-12-02 5:42 GMT+08:00 Alexander Wels aw...@redhat.com:
  On Monday, December 01, 2014 04:56:04 PM 王成俊 wrote:
   Dear Sir:
   
I am a new one in studing ovirt engine.Now,I have a Servlet in
   
   org.ovirt.engine.ui.frontend.server.gwt package.
   
I want to call
   
   *Frontend.getInstance().getLoginHandler().**onLoginSuccess(userName,
   password, domain)* to set session for restapi in this servlet.
   
But when I visit this servlet,it occur to show me an error
which
   
   just like *JBWEB71: root cause java.lang.ClassNotFoundException:
   org.ovirt.engine.ui.uicompat.IFrontendActionAsyncCallback from [Module
   quot;deployment.engine.ear.webadmin.war:mainquot; from Service Module
   Loader]*. I found that this error is occured by calling*
   Frontend.getInstance()*.
   
Can you tell me how to resolve this problem or a new way to set
   
   and resume restapi session in a servlet package of
   org.ovirt.engine.ui.front.server.gwt like the RestApiSessionManager in
   org.ovirt.engine.ui.webadmin.plugin.restapi package?
   
  thanks!
   
   Best Regards!
  
  Hi,
  
  The problem you are experiencing is the fact the Frontend.getInstance() is
  a
  frontend (client, which get compiled to javascript) class, and the servlet
  is
  on the server side where this class is not defined (as it is frontend
  only).
  Maybe if you could explain what you are trying to do we could assist
  better.
  
  We have a mechanism of getting the REST api session on the front end when
  you
  log in. On the backend you don't really need that, since you are on the
  backend. So your question sort of confuses me at this point.
  
  Alexander

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Really slow VDSM on F21

2014-12-02 Thread Petr Horacek
Hello,

has anyone else noticed VDSM's problems on Fedora 21?

The problem is that when I start vdsmd via systemd, it takes
about a minute to start the listener (returning Connection
to 0.0.0.0:54321 refused) and next few minutes it returns
'Recovering from crash or Initializing'. After that, `getVdsCaps`
takes cca 20 secs to finish.

I tried to change niceness in vdsmd.service but it's still the same.

When I start vdsm directly (/usr/share/vdsm/vdsm as vdsm user) it
starts within a second as it should.

Have you an idea why this happens?

Best regards,
Petr
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel


[ovirt-devel] oVirt Node Weekly Meeting Minutes - December 2nd 2014

2014-12-02 Thread Fabian Deutsch
Minutes:http://ovirt.org/meetings/ovirt/2014/ovirt.2014-12-02-14.06.html
Minutes (text): http://ovirt.org/meetings/ovirt/2014/ovirt.2014-12-02-14.06.txt
Log:
http://ovirt.org/meetings/ovirt/2014/ovirt.2014-12-02-14.06.log.html

=
#ovirt: oVirt Node Weekly Meeting
=


Meeting started by fabiand at 14:06:16 UTC. The full logs are available
at http://ovirt.org/meetings/ovirt/2014/ovirt.2014-12-02-14.06.log.html
.



Meeting summary
---
* Agenda  (fabiand, 14:06:42)
  * oVirt 3.5  (fabiand, 14:07:53)

* oVirt 3.5  (fabiand, 14:08:23)

* Other Items  (fabiand, 14:09:56)

* oVirt 3.5  (fabiand, 14:11:26)
  * Latest Node scratch build is the one from two weeks ago  (fabiand,
14:13:51)
  * LINK:

https://fedorapeople.org/~fabiand/node/3.5/ovirt-node-iso-3.5.0.ovirt35.20141114.0.el6.iso
(fabiand, 14:14:37)
  * Some stabilizing patches got merged  (fabiand, 14:14:53)
  * Most work focused on the hosted-engine feature  (fabiand, 14:15:48)
  * many HE related patches got reviewed and merged during the last few
days  (fabiand, 14:18:36)
  * Basic HE features seems to work fine  (fabiand, 14:18:48)
  * Joining an existing HA HE is not yet supported  (fabiand, 14:19:03)
  * Targetting 3.5.1 to include ovirt-node. ovirt-node-plugins-vdsm and
ovirt-node-plugin-he rpms  (fabiand, 14:21:06)
  * ovirt-node-plugin-vdsm is looking good  (fabiand, 14:22:42)
  * vdsm-plugin also needs an update to address an el7 issue  (fabiand,
14:24:11)

* Other Items  (fabiand, 14:24:49)
  * Jenkins  (fabiand, 14:26:03)
  * tlitovsk working on jenkins automation  (fabiand, 14:29:27)
  * working on local builders, once working, pushing those changes to
upstream  (fabiand, 14:29:46)
  * Next-Gen Node  (fabiand, 14:31:06)
  * Start thinking about next-gen node and 3.6  (fabiand, 14:44:15)
  * generic registration is a potential feature for 3.6  (fabiand,
14:44:26)
  * Using puppet for configuration changes should get investigated
(fabiand, 14:44:37)
  * Seperating the insatller from the TUI (packaging) is something for
3.6  (fabiand, 14:44:49)
  * Possibly re-visit other cfg mgmt systems like ansible and chef
(fabiand, 14:51:22)
  * systemd has good sides.  (fabiand, 14:52:38)
  * tlitovsk has the idea of baking a configuration into an ISO
(fabiand, 14:58:48)
  * fabiand would liek to reuse existing tools for next-gen node
modifications  (fabiand, 14:59:20)
  * tlitovsk and fabiand to speak about where to do decision making
(fabiand, 15:00:29)
  * fabiand would like to separate rootfs from delivery format (ISO)
(fabiand, 15:03:01)

Meeting ended at 15:04:21 UTC.




Action Items






Action Items, by person
---
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* fabiand (172)
* tlitovsk (16)
* rbarry (15)
* dougsland (13)
* ovirtbot (4)
* sbonazzo (1)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel


Re: [ovirt-devel] [QE][ACTION REQUIRED] oVirt 3.5.1 RC status - postponed

2014-12-02 Thread Dan Kenigsberg
On Tue, Dec 02, 2014 at 06:44:50AM +0100, Sandro Bonazzola wrote:
 Hi,
 We were supposed to start composing oVirt 3.5.1 RC today *2014-12-02 08:00 
 UTC* from 3.5 branch.
 We have still blockers for oVirt 3.5.1 RC release so we need to postpone it 
 untill they'll be fixed.
 The new tentative date for 3.5.1 RC composition is set to *2014-12-09 08:00 
 UTC
 
 The bug tracker [1] shows 2 open blocker:
 Bug IDWhiteboard  Status  Summary
 1168689   infra   ASSIGNEDUpgrading from 3.4.4 to 3.5.1 
 snapshot the vdsm rpm throw an exception

This one actuall has two patches merged. I moved it back to ASSIGNED by
mistake, as I did not notice the section added to
http://gerrit.ovirt.org/#/c/35763/2/vdsm.spec.in

Anyway, this bloke is behind us.

 1160846   sla NEW Can't add disk to VM without 
 specifying disk profile when the storage domain has more than one disk profile
 
 In order to stabilize the release a new branch ovirt-engine-3.5.1 will be 
 created from the same git hash used for composing the RC.
 
 Maintainers:
 - Please be sure that 3.5 snapshot allow to create VMs before *2014-12-08 
 15:00 UTC*
 - Please be sure that no pending patches are going to block the release 
 before *2014-12-08 15:00 UTC*
 - If any patch must block the RC release please raise the issue as soon as 
 possible.
 
 There are still 69 bugs [2] targeted to 3.5.1.
 Excluding node and documentation bugs we still have 46 bugs [3] targeted to 
 3.5.1.
 
 Maintainers / Assignee:
 - Please add the bugs to the tracker if you think that 3.5.1 should not be 
 released without them fixed.
 - Please update the target to 3.5.2 or later for bugs that won't be in 3.5.1:
   it will ease gathering the blocking bugs for next releases.
 - Please fill release notes, the page has been created here [4]
 
 Community:
 - If you're testing oVirt 3.5 nightly snapshot, please add yourself to the 
 test page [5]
 
 
 [1] http://bugzilla.redhat.com/1155170
 [2] http://goo.gl/7G0PDV
 [3] http://goo.gl/6gUbVr
 [4] http://www.ovirt.org/OVirt_3.5.1_Release_Notes
 [5] http://www.ovirt.org/Testing/oVirt_3.5.1_Testing
 
 
 -- 
 Sandro Bonazzola
 Better technology. Faster innovation. Powered by community collaboration.
 See how it works at redhat.com
 ___
 Devel mailing list
 Devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel


Re: [ovirt-devel] How To Auto Set oVirt RESTApi Session?

2014-12-02 Thread Vojtech Szocs


- Original Message -
 From: Alexander Wels aw...@redhat.com
 To: 王成俊 wcj2...@gmail.com
 Cc: devel@ovirt.org
 Sent: Tuesday, December 2, 2014 1:59:21 PM
 Subject: Re: [ovirt-devel] How To Auto Set oVirt RESTApi Session?
 
 On Tuesday, December 02, 2014 09:45:49 AM 王成俊 wrote:
  Hi,awels:
  
   Thanks for your reply!
  
   I make this servlet to run the backend action which
  names LoginAdminUser, because I want to check admin log in with it,so
  that my engine no need to log in through engine's loginpopupview.

Hm, so you're trying to automate WebAdmin GUI login? Can you please
explain your use case without any technical (servlet etc.) details?

  
   But when I log in through my servlet,the restapi can not get the
  user's certificate.
  
   Can you tell me how to set and resume the restapi session in my case?
  
   Thanks!
  
  Best Regards!
  
 
 You can login to the REST api using standard http connection techniques. For
 instance basic auth you can login doing the following:
 
 http://user%40domain:password@engine_host/ovirt-engine/api
 
 Will list the available REST api.
 
 But I am still not clear on what you are trying to do. Are you trying to
 write
 your own external servlet, that calls the REST api to do things for you? Or
 are you trying to write a servlet that lives inside the context of the engine
 and implements a new action?
 
 Also please reply all, so we can keep the discussion on the mailing list so
 other people can find it in the future.
 
 Alexander
 
 
  2014-12-02 5:42 GMT+08:00 Alexander Wels aw...@redhat.com:
   On Monday, December 01, 2014 04:56:04 PM 王成俊 wrote:
Dear Sir:

 I am a new one in studing ovirt engine.Now,I have a Servlet in

org.ovirt.engine.ui.frontend.server.gwt package.

 I want to call

*Frontend.getInstance().getLoginHandler().**onLoginSuccess(userName,
password, domain)* to set session for restapi in this servlet.

 But when I visit this servlet,it occur to show me an error
 which

just like *JBWEB71: root cause java.lang.ClassNotFoundException:
org.ovirt.engine.ui.uicompat.IFrontendActionAsyncCallback from [Module
quot;deployment.engine.ear.webadmin.war:mainquot; from Service Module
Loader]*. I found that this error is occured by calling*
Frontend.getInstance()*.

 Can you tell me how to resolve this problem or a new way to
 set

and resume restapi session in a servlet package of
org.ovirt.engine.ui.front.server.gwt like the RestApiSessionManager in
org.ovirt.engine.ui.webadmin.plugin.restapi package?

   thanks!

Best Regards!
   
   Hi,
   
   The problem you are experiencing is the fact the Frontend.getInstance()
   is
   a
   frontend (client, which get compiled to javascript) class, and the
   servlet
   is
   on the server side where this class is not defined (as it is frontend
   only).
   Maybe if you could explain what you are trying to do we could assist
   better.
   
   We have a mechanism of getting the REST api session on the front end when
   you
   log in. On the backend you don't really need that, since you are on the
   backend. So your question sort of confuses me at this point.
   
   Alexander
 
 ___
 Devel mailing list
 Devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Important change in UI plugins REST API integration

2014-12-02 Thread Vojtech Szocs


- Original Message -
 From: Alon Bar-Lev alo...@redhat.com
 To: Sven Kieske s.kie...@mittwald.de
 Cc: devel@ovirt.org
 Sent: Tuesday, December 2, 2014 9:43:18 AM
 Subject: Re: [ovirt-devel] Important change in UI plugins RESTAPI 
 integration
 
 
 
 - Original Message -
  From: Sven Kieske s.kie...@mittwald.de
  To: devel@ovirt.org
  Sent: Tuesday, December 2, 2014 10:41:00 AM
  Subject: Re: [ovirt-devel] Important change in UI plugins REST API
  integration
  
  
  
  On 01/12/14 20:26, Vojtech Szocs wrote:
   In other words, usability of REST session ID is now strictly
   scoped to GUI user being authenticated. If the user logs in,
   (always) new REST session ID will be passed to all UI plugins.
   If the user logs out, REST session ID will not work anymore.
  
  What if I use just REST for logging in and doing something
  without any GUI interaction at all?

This announcement was about UI plugins in WebAdmin. If you use
Engine REST API without any GUI interaction involved, you aren't
affected in any way.

  
  this reads a little like: you always need an open web gui
  to be able to use REST, which does not make sense at all.

Sorry if my email confused you. It should read like: if you're
an author of oVirt UI plugin for WebAdmin, please beware that
REST API session ID (automatically acquired by UI plugin infra
on behalf of all UI plugins) will not work after GUI logout.

 
 If you provide your own credentials nothing changed.
 
 The change is only effecting RESTAPI usage within the user interface using
 the credentials obtained interactively from the user within login page.
 
  So I guess I'm misreading this?
  
  --
  Mit freundlichen Grüßen / Regards
  
  Sven Kieske
  
  Systemadministrator
  Mittwald CM Service GmbH  Co. KG
  Königsberger Straße 6
  32339 Espelkamp
  T: +49-5772-293-100
  F: +49-5772-293-333
  https://www.mittwald.de
  Geschäftsführer: Robert Meyer
  St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
  Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
  ___
  Devel mailing list
  Devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/devel
 ___
 Devel mailing list
 Devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Some ideas on oVirt Java SDK

2014-12-02 Thread Vojtech Szocs


- Original Message -
 From: Juan Hernández jhern...@redhat.com
 To: Vojtech Szocs vsz...@redhat.com
 Cc: devel@ovirt.org, Michael Pasternak mishka8...@yahoo.com
 Sent: Tuesday, December 2, 2014 10:02:36 AM
 Subject: Re: [ovirt-devel] Some ideas on oVirt Java SDK
 
 On 12/01/2014 06:36 PM, Vojtech Szocs wrote:
  
  
  - Original Message -
  From: Juan Hernández jhern...@redhat.com
  To: Vojtech Szocs vsz...@redhat.com
  Cc: devel@ovirt.org
  Sent: Monday, December 1, 2014 4:24:45 PM
  Subject: Re: [ovirt-devel] Some ideas on oVirt Java SDK
 
  On 12/01/2014 04:13 PM, Vojtech Szocs wrote:
 
 
  - Original Message -
  From: Juan Hernández jhern...@redhat.com
  To: Michael Pasternak mishka8...@yahoo.com, Vojtech Szocs
  vsz...@redhat.com, devel@ovirt.org
  Sent: Monday, December 1, 2014 9:54:51 AM
  Subject: Re: [ovirt-devel] Some ideas on oVirt Java SDK
 
  On 11/30/2014 12:26 PM, Michael Pasternak wrote:
  Hey Vojtech,
 
  How are you?, please see my reply inline.
 
 
 
  On Friday, November 28, 2014 5:26 PM, Vojtech Szocs
  vsz...@redhat.com mailto:vsz...@redhat.com wrote:
 
 
  Hi guys,
 
  since the initial (small, working  well-tested) version of oVirtJS
  JavaScript SDK is finished [*], I've started working on GWT wrapper
  for oVirtJS.
 
  While analyzing/reverse-engineering oVirt Java SDK, some thoughts
  came to my mind, and I wanted to share them with you.
 
  [*] TODO(vszocs) upload new patchset with all recent changes
 
  First, the way XJC (JAXB binding compiler that generates Java beans
  out of REST XSD schema) is invoked looks a bit weird to me, as Java
  SDK's XsdCodegen does this:
 
Runtime.getRuntime().exec(command)
 
  Why not simply use existing Maven plugins to invoke XJC?
  - either: https://github.com/highsource/maven-jaxb2-plugin
  https://github.com/highsource/maven-jaxb2-plugin
 
 
  [MP] sdk was using jaxb to begin with, it was replaced with XJC just
  recently,
  btw Juan, what was the motivation behind this?
 
  This didn't change, the use of xjc is there since commit 95a25a4, Nov
  12 2012.
 
  Note that using Maven for this isn't as simple as it may look. The
  development model of the SDK is that the maven build does *not* generate
  any code, it just builds what has been manually generated previously.
 
  To clarify, my question was meant for ovirt-engine-sdk-java-codegen
  project and its org.ovirt.engine.sdk.codegen.Main class that produces
  Java classes out of XSD as part of XsdCodegen.generate() method.
 
  But if XsdCodegen invokes XJC programatically, what is the purpose of:
 
org.jvnet.jaxb2.maven2:maven-jaxb22-plugin:generate
 
  in ovirt-engine-sdk-java-codegen project's pom.xml?
 
  Is it related to what XsdCodegen is doing?
 
 
  The code generator invokes xjc directly in order to generate from the
  XML schema the code that will eventually be part of the generated SDK.
  In order to do its work it needs to parse the RSDL metadata, and for
  that it uses JAXB and classes generated from the XML schema. Those
  classes are generated as part of the build process of the code
  generator. So the XML schema is converted into Java classes twice: once
  for the internal use of the generator (during build time of the
  generator), and another time for the generated SDK (during run time of
  the generator). This is convenient in order to avoid dependencies
  between the generator and the SDK.
  
  Thanks for clarification.
  
  IMHO calling XJC just to generate JAXB code that parses RSDL data
  is an overkill. In oVirtJS GWT wrapper project, I'm parsing RSDL
  as XML file directly.
  
 
 The xjc compiler isn't called directly to generate the code to parse
 RSDL, it is called to generate the code of the SDK.

Yes, that's what XsdCodegen is doing.

 
 The code that the generator uses internally is generated using the Maven
 plugin (which in turn calls xjc).

Yes, that's what maven-jaxb22-plugin is doing
in ovirt-engine-sdk-java-codegen/pom.xml file.

 
 We could argue about the convenience of using JAXB or manually parsing
 the RSDL, but it won't take us anywhere. If you find it convenient
 parsing it directly just do it.
 
  Conceptually, RSDL definition shouldn't even be inside api.xsd:
  
xs:element name=rsdl type=RSDL/
  
  Above ^^ is unrelated to REST entity schema, it describes RSDL
  schema. It's inside api.xsd just to parse RSDL via JAXB. Entity
  schema and RSDL schema are two separate things.
  
  I suggest to split above into separate file, i.e. rsdl.xsd
  and reference shared types (like Version) from api.xsd.
  This would be the proper separation these two schemas.
  
 
 The RSDL is just one resource offered by the RESTAPI, like a VM or a
 host. It supports multiple formats (XML, JSON, etc) and it is consumed
 by clients. So its entities, like any other entity, must be described in
 the XML schema. We only have one XML schema, and we can split it as it
 would