----- Original Message -----
From: "Einav Cohen" <ecohen(a)redhat.com>
To: "Tomas Jelinek" <tjelinek(a)redhat.com>, "Vojtech Szocs"
<vszocs(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>
Sent: Friday, June 28, 2013 6:01:16 PM
Subject: Re: [Engine-devel] [Spice-devel] SPICE Foreign Menu Using REST
Hi Tomas,
> IIUC the RFE addresses only UIPlugins with their metadata so
> in order to integrate this with the SPICE we nee to either
> enrich the RFE or to create a UIPlugin which will start the
> SPICE. I would vote for the second option. What others?
using a ui-plugin that will start SPICE is an interesting approach - it
haven't crossed my mind. What I had in mind is to somewhat "generalize"
the
RestApiSessionManager to provide REST-API-session-creation services to the
entire GUI (e.g. SPICE-console-opening-code), and not only to the ui-plugins
in particular.
I think that since SPICE is already quite integrated into oVirt (in our
business
logic, dialogs, ...), it would be somewhat weird to use a UI-Plugin in order
to
invoke SPICE, just in order to get the REST-API-session-creation capability.
So I am actually in favor of enriching the RFE (i.e. "generalize" the
RestApiSessionManager), rather than treating SPICE as a UI-Plugin (in a
sense).
yes, you are right.
> Why only for SPICE? I can imagine UIPlugins which could make use of this
> option.
the main difference between SPICE and the UIPlugins is that we know in
advance
how SPICE is going to use REST API.
This is not true anymore - SPICE can add whatever it wants to it's menu and
webadmin/userportal
has no control about it anymore (I'm talking about the non-plugin invocation of the
SPICE).
In addition, SPICE is going to do actions
(e.g.
Stop/Pause/Attach CD) on the VM only when the user chooses to do so (via the
SPICE menu), so actions will be done on behalf of the logged-in user, so it
makes
sense to provide to SPICE the same credentials as the logged-in user.
a ui-plugin is a third-party component which we don't know in advance how it
is
going to act; moreover, the user that is logging into the web-admin doesn't
have
control on it. Imagine a ui-plugin that shuts-down/deletes all VMs
immediately
upon login to the web-admin - all VMs will be shutdown/deleted upon the first
login into the web-admin (after the ui-plugin installation on the engine
server).
If the same-credentials-approach will be used, the shutdown/deletion of all
VMs
will be done on behalf of the user that happened to be the first one logging
into
the web-admin (post ui-plugin installation), which, obviously, is not good.
Well, I did not mean to give this permission to all the plugins - all I wanted to
say is to make this configurable per plugin. I can imagine
also a well-known UI plugin which is trusted by the admin and it does make sense
to make it use the same rights as the logged in user.
I did not mean that each plugin has to have this permissions.
So to sum-up: I think that
- the RestApiSessionManager should be "generalized" to provide
REST-API-session-
creation services to the entire GUI (e.g. SPICE-console-opening-code), and
not only
to the ui-plugins in particular.
completely agree
- RestApiSessionManager should support creation of both
same-credentials-session as
well as other-credentials-session; the same-credentials-session should be
limited to
well-known/well-integrated components (e.g. SPICE), whereas the
other-credentials-session
can be used by third-party components as well (e.g. ui-plugins).
Who should decide about what is the well-known component? I would let the administrator
to
configure this. We can provide the defaults (e.g. the same-credentials-session will be
disabled by
default for ui-plugins but it will be possible to enabled it explicitly for some
ui-plugins).
[I could be wrong - would love to hear what the others GUI maintainers think]
> ----- Original Message -----
> From: "Tomas Jelinek" <tjelinek(a)redhat.com>
> Sent: Friday, June 28, 2013 1:41:11 AM
>
>
>
> ----- Original Message -----
> > From: "Einav Cohen" <ecohen(a)redhat.com>
> > To: "Tomas Jelinek" <tjelinek(a)redhat.com>, "Vojtech
Szocs"
> > <vszocs(a)redhat.com>
> > Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Michael
Pasternak"
> > <mpastern(a)redhat.com>
> > Sent: Thursday, June 27, 2013 6:01:13 PM
> > Subject: Re: [Engine-devel] [Spice-devel] SPICE Foreign Menu Using REST
> >
> > Hi Tomas,
> >
> > > Yes, we can provide the sessionId to authenticate with the REST and the
> > > vm
> > > guid is not a problem.
> >
> > Note that in the web-admin, we already have code that generates REST API
> > session-ID;
> > this code is being utilized in the ui-plugins infrastructure to allow the
> > different
> > ui-plugins to communicate with the rest api.
> > [one related file is this context is RestApiSessionManager.java in the
> > web-admin, not
> > sure if there are others]
>
> Yes, I'm aware of that. This is what I had in mind when was talking about
> passing the SessionId to SPICE.
>
> >
> > maybe the RestApiSessionManager(?) can somehow be utilized for the SPICE
> > purpose as well
> > (I guess that it will require a couple of code-changes though, and maybe
> > worth moving it
> > to gwt-common, to allow its utilization from the user portal as well?) -
> > @Vojtech would
> > probably know best to advise on this.
> >
> > * Note: Today:
> > (a) a *single* REST API session-ID is generated and used across all
> > ui-plugins in the system
> > (upon user login to the web-admin).
> >
> > (b) this REST-API session-ID is generated based on the *same credentials*
> > with which the user
> > logged into the web-admin.
> >
> > both (a) and (b) will change once [1] will be addressed.
>
> Thank you for mentioning this! I was not aware of this RFE. IIUC the RFE
> addresses only
> UIPlugins with their metadata so in order to integrate this with the SPICE
> we
> nee to either
> enrich the RFE or to create a UIPlugin which will start the SPICE. I would
> vote for the second option.
> What others?
>
> > Only for the SPICE case in particular - I think that (b) should remain.
> > so
>
> Why only for SPICE? I can imagine UIPlugins which could make use of this
> option.
>
> > maybe worth allowing
> > both same-credentials-login and different-credentials-login in the
> > REST-API-Session-ID-generation
> > code in the GUI.
>
> This option might make sense also for other UIPlugins so maybe the SPICE
> integration will not be anything special, just a UIPlugin.
>
> >
> > ----
> > Thanks,
> > Einav
> >
> > [1] Bug 962863 - RFE: Improve REST API integration for UI Plugins
> >
https://bugzilla.redhat.com/show_bug.cgi?id=962863
> > some of the planned changes (from the BZ description):
> > """
> > ...
> > - each UI plugin will have its own dedicated REST API session, unrelated
> > to
> > GUI (admin)
> > user credentials
> > ...
> > """
> >
> > > ----- Original Message -----
> > > From: "Tomas Jelinek" <tjelinek(a)redhat.com>
> > > Sent: Thursday, June 27, 2013 5:50:31 AM
> > >
> > >
> > >
> > > ----- Original Message -----
> > > > From: "Christophe Fergeau" <cfergeau(a)redhat.com>
> > > > To: "Tomas Jelinek" <tjelinek(a)redhat.com>
> > > > Cc: "Michal Skrivanek" <michal.skrivanek(a)redhat.com>,
"Itamar Heim"
> > > > <iheim(a)redhat.com>,
> > > > spice-devel(a)lists.freedesktop.org, "engine-devel"
> > > > <engine-devel(a)ovirt.org>,
> > > > "Marc-André Lureau" <mlureau(a)redhat.com>
> > > > Sent: Thursday, June 27, 2013 11:30:10 AM
> > > > Subject: Re: [Engine-devel] [Spice-devel] SPICE Foreign Menu Using
> > > > REST
> > > >
> > > > Hey,
> > > >
> > > > On Thu, Jun 27, 2013 at 05:21:11AM -0400, Tomas Jelinek wrote:
> > > > > well, it seems that everyone agree that the decision what to add
to
> > > > > the
> > > > > menu is the client responsibility. It means there is no
additional
> > > > > work
> > > > > needed on the
> > > > > oVirt engine side - going to remove the feature page.
> > > >
> > > > If we go the REST API way to handle foreign menu, we need additional
> > > > info
> > > > in the .vv files: some way to auth with the REST API, and the guid
of
> > > > the
> > > > VM to act on.
> > > Yes, we can provide the sessionId to authenticate with the REST and the
> > > vm
> > > guid is not a problem.
> > >
> > > >
> > > > Christophe
> > > >
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel(a)ovirt.org
> > >
http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> > >
> > >
> >
>