[Engine-devel] [Spice-devel] SPICE Foreign Menu Using REST

Tomas Jelinek tjelinek at redhat.com
Tue Jul 2 06:22:03 UTC 2013



----- Original Message -----
> From: "Einav Cohen" <ecohen at redhat.com>
> To: "Vojtech Szocs" <vszocs at redhat.com>, "Tomas Jelinek" <tjelinek at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, July 1, 2013 3:20:42 PM
> Subject: Re: [Engine-devel] [Spice-devel] SPICE Foreign Menu Using REST
> 
> > ----- Original Message -----
> > From: "Tomas Jelinek" <tjelinek at redhat.com>
> > Sent: Monday, July 1, 2013 1:29:20 AM
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Einav Cohen" <ecohen at redhat.com>
> > > To: "Tomas Jelinek" <tjelinek at redhat.com>, "Vojtech Szocs"
> > > <vszocs at redhat.com>
> > > Cc: "engine-devel" <engine-devel at 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).
> 
> +1
> having the same-credentials-session disabled by default for ui-plugins and
> having
> the admin explicitly enabling it per plugin where necessary makes perfect
> sense.
> 
> note that for SPICE, which is NOT a UI plugin, but is still a third-party
> component
> (but one that is well-integrated into ovirt), I think that we should use the
> same-
> credentials-session method by default (i.e. without the administrator
> explicitly
> allowing it).

+1

> 
> > 
> > > 
> > > [I could be wrong - would love to hear what the others GUI maintainers
> > > think]
> > > 
> > > 
> > > > ----- Original Message -----
> > > > From: "Tomas Jelinek" <tjelinek at redhat.com>
> > > > Sent: Friday, June 28, 2013 1:41:11 AM
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Einav Cohen" <ecohen at redhat.com>
> > > > > To: "Tomas Jelinek" <tjelinek at redhat.com>, "Vojtech Szocs"
> > > > > <vszocs at redhat.com>
> > > > > Cc: "engine-devel" <engine-devel at ovirt.org>, "Michael Pasternak"
> > > > > <mpastern at 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 at redhat.com>
> > > > > > Sent: Thursday, June 27, 2013 5:50:31 AM
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Christophe Fergeau" <cfergeau at redhat.com>
> > > > > > > To: "Tomas Jelinek" <tjelinek at redhat.com>
> > > > > > > Cc: "Michal Skrivanek" <michal.skrivanek at redhat.com>, "Itamar
> > > > > > > Heim"
> > > > > > > <iheim at redhat.com>,
> > > > > > > spice-devel at lists.freedesktop.org, "engine-devel"
> > > > > > > <engine-devel at ovirt.org>,
> > > > > > > "Marc-André Lureau" <mlureau at 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 at ovirt.org
> > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > 
> > > > > > 
> > > > > >
> > > > > 
> > > >
> > >
> > 
> 



More information about the Engine-devel mailing list