7:33 a.m.
Hi all,
for the non plugin invocation of the console
(http://www.ovirt.org/Features/Non_plugin_console_invocation) the dynamicMenu property is
not usable to enrich the SPICE client menu.
This feature is about requesting this menu using oVirt's REST API and than calling it
back once some item from this menu has been selected.
The oVirt's feature page with specific details:
http://www.ovirt.org/Features/Foreign_Menu_Using_REST
Any comments are more than welcomed.
Thanx,
Tomas
8:31 a.m.
New subject: [Engine-devel] [Spice-devel] SPICE Foreign Menu Using REST
----- Mensaje original -----
Hi all,
for the non plugin invocation of the console
(http://www.ovirt.org/Features/Non_plugin_console_invocation) the
dynamicMenu property is not usable to enrich the SPICE client menu.
This feature is about requesting this menu using oVirt's REST API and than
calling it back once some item from this menu has been selected.
The oVirt's feature page with specific details:
http://www.ovirt.org/Features/Foreign_Menu_Using_REST
How does the client know what vmID it should access? The client shouldn't need to know
how to form the base menu URL itself.
Regarding the XML, most of the elements would be nicer as properties imho.
- "id"
What is this used for?
- "text"
Why not just call it "label"? "text" is quite generic name, could be a
hint etc.. Btw, is the menu localizable and should the client add the LC_LANG or something
in the request?
- "marked"
I suggest to follow Gtk/Qt naming "checked", since we expect a check mark next
to the label.
- "item_code"
This is quite badly named. Afaik, none of the Spice client implemented accelerators via
the menu (it isn't specified in
http://spice-space.org/page/Whiteboard/ControllerProtocol). I think in the past there was
no default menu provided by the client but the one created by the portal. So the client
was configured with CONTROLLER_HOTKEYS and just displayed whatever the menu text was.
There was no additional accelerators created. So, this should be considered as a new
feature.
I would also like to see the accelerator format specified somewhere (shift, ctrl, alt, fN,
char seperated by + afaik)
It could be useful and easy to add a "sensitive" property too already.
I would also like to see the "Comet" approach being discussed in alternatives,
instead of the polling and the second refresh request, which I can imagine racy if two
items are clicked quickly. Can we expect refresh reply in order (to allow
"pipelining" of requests)?
thanks
9 a.m.
On 06/19/2013 04:33 PM, Tomas Jelinek wrote:
Hi all,
for the non plugin invocation of the console
(http://www.ovirt.org/Features/Non_plugin_console_invocation) the dynamicMenu property is
not usable to enrich the SPICE client menu.
This feature is about requesting this menu using oVirt's REST API and than calling it
back once some item from this menu has been selected.
The oVirt's feature page with specific details:
http://www.ovirt.org/Features/Foreign_Menu_Using_REST
Any comments are more than welcomed.
Why are we putting the logic of the menu into the REST API?
can't the menu be builded by client based on getting the list of ISO's
and current CD?
5:07 a.m.
--TYecfFk8j8mZq+dy
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Hey Itamar,
On Wed, Jun 19, 2013 at 06:00:47PM +0300, Itamar Heim wrote:
On 06/19/2013 04:33 PM, Tomas Jelinek wrote:
>Hi all,
>
>for the non plugin invocation of the console (http://www.ovirt.org/Featu=
res/Non_plugin_console_invocation) the dynamicMenu property is not usable t=
o enrich the SPICE client menu.
>
>This feature is about requesting this menu using oVirt's REST API and th=
an calling it back once some item from this menu has been selected.
>
>The oVirt's feature page with specific details: http://www.ovirt.org/Fea=
tures/Foreign_Menu_Using_REST
>
>Any comments are more than welcomed.
=20
Why are we putting the logic of the menu into the REST API?
can't the menu be builded by client based on getting the list of
ISO's and current CD?
The client needs a way to get the list of available ISOs in order to build
the menu, as well as a way to let the engine know when the user clicked on
an ISO in the menu. One way of doing that is to have the menu stuff exposed
in the REST API. Another way would be to expose the list of ISOs in the
REST API (I'd have a slight preference for that I think).
Or do you have anything in mind for the client to get the list of ISOs
available to the engine?
Christophe
--TYecfFk8j8mZq+dy
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
iEYEARECAAYFAlHC4mMACgkQJKRp+3pW94455wCfZDpNvZD6wsMKZCm4mPy8wisa
7dEAoIofZnbfoqcCybDi1XygVtUFeD4N
=UslC
-----END PGP SIGNATURE-----
--TYecfFk8j8mZq+dy--
5:09 a.m.
On 06/20/2013 02:07 PM, Christophe Fergeau wrote:
Hey Itamar,
On Wed, Jun 19, 2013 at 06:00:47PM +0300, Itamar Heim wrote:
> On 06/19/2013 04:33 PM, Tomas Jelinek wrote:
>> Hi all,
>>
>> for the non plugin invocation of the console
(http://www.ovirt.org/Features/Non_plugin_console_invocation) the dynamicMenu property is
not usable to enrich the SPICE client menu.
>>
>> This feature is about requesting this menu using oVirt's REST API and than
calling it back once some item from this menu has been selected.
>>
>> The oVirt's feature page with specific details:
http://www.ovirt.org/Features/Foreign_Menu_Using_REST
>>
>> Any comments are more than welcomed.
>
> Why are we putting the logic of the menu into the REST API?
> can't the menu be builded by client based on getting the list of
> ISO's and current CD?
The client needs a way to get the list of available ISOs in order to build
the menu, as well as a way to let the engine know when the user clicked on
an ISO in the menu. One way of doing that is to have the menu stuff exposed
in the REST API. Another way would be to expose the list of ISOs in the
REST API (I'd have a slight preference for that I think).
that's my preference as well, and the REST API should already do that today:
- get list of ISOs of available in a DC (the one the VM is in)
- ability to change the CD of the VM
Or do you have anything in mind for the client to get the list of
ISOs
available to the engine?
my preference is to provide the data, not the semantics of the menu.
iiuc, we are on the same page.
Christophe
6:13 a.m.
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Christophe Fergeau" <cfergeau(a)redhat.com>
Cc: "Tomas Jelinek" <tjelinek(a)redhat.com>, "engine-devel"
<engine-devel(a)ovirt.org>,
spice-devel(a)lists.freedesktop.org, "Marc-André Lureau"
<mlureau(a)redhat.com>
Sent: Thursday, June 20, 2013 1:09:21 PM
Subject: Re: [Engine-devel] [Spice-devel] SPICE Foreign Menu Using REST
On 06/20/2013 02:07 PM, Christophe Fergeau wrote:
> Hey Itamar,
>
> On Wed, Jun 19, 2013 at 06:00:47PM +0300, Itamar Heim wrote:
>> On 06/19/2013 04:33 PM, Tomas Jelinek wrote:
>>> Hi all,
>>>
>>> for the non plugin invocation of the console
>>> (http://www.ovirt.org/Features/Non_plugin_console_invocation) the
>>> dynamicMenu property is not usable to enrich the SPICE client menu.
>>>
>>> This feature is about requesting this menu using oVirt's REST API and
>>> than calling it back once some item from this menu has been selected.
>>>
>>> The oVirt's feature page with specific details:
>>> http://www.ovirt.org/Features/Foreign_Menu_Using_REST
>>>
>>> Any comments are more than welcomed.
>>
>> Why are we putting the logic of the menu into the REST API?
>> can't the menu be builded by client based on getting the list of
>> ISO's and current CD?
>
> The client needs a way to get the list of available ISOs in order to build
> the menu, as well as a way to let the engine know when the user clicked on
> an ISO in the menu. One way of doing that is to have the menu stuff exposed
> in the REST API. Another way would be to expose the list of ISOs in the
> REST API (I'd have a slight preference for that I think).
that's my preference as well, and the REST API should already do that today:
- get list of ISOs of available in a DC (the one the VM is in)
- ability to change the CD of the VM
Well, and what about the stop/suspend VM for
example, what we have in the menu today?
Also this should be something that the client decide to have or not have?
> Or do you have anything in mind for the client to get the list of ISOs
> available to the engine?
my preference is to provide the data, not the semantics of the menu.
We should
clarify something here. There are two possibilities who should be responsible for
deciding
what should the foreign menu contain and also what to do if it the item is selected:
1: the client - e.g. we will not provide any support for the menu in REST because the
client reads what needs
and knows how to call the oVirt back
2: the server side - e.g. we will provide in REST side the menu structure with the
description what to do if something is
selected
Both have some advantages and disadvantages but we need to clarify which way to go. So,
who is the one responsible to decide
what is in the foreign menu (now or in the future) and how to react if something is
selected? Client or engine?
iiuc, we are on the same page.
>
> Christophe
>
6:27 a.m.
On 06/20/2013 03:13 PM, Tomas Jelinek wrote:
----- Original Message -----
> From: "Itamar Heim" <iheim(a)redhat.com>
> To: "Christophe Fergeau" <cfergeau(a)redhat.com>
> Cc: "Tomas Jelinek" <tjelinek(a)redhat.com>, "engine-devel"
<engine-devel(a)ovirt.org>,
> spice-devel(a)lists.freedesktop.org, "Marc-André Lureau"
<mlureau(a)redhat.com>
> Sent: Thursday, June 20, 2013 1:09:21 PM
> Subject: Re: [Engine-devel] [Spice-devel] SPICE Foreign Menu Using REST
>
> On 06/20/2013 02:07 PM, Christophe Fergeau wrote:
>> Hey Itamar,
>>
>> On Wed, Jun 19, 2013 at 06:00:47PM +0300, Itamar Heim wrote:
>>> On 06/19/2013 04:33 PM, Tomas Jelinek wrote:
>>>> Hi all,
>>>>
>>>> for the non plugin invocation of the console
>>>> (http://www.ovirt.org/Features/Non_plugin_console_invocation) the
>>>> dynamicMenu property is not usable to enrich the SPICE client menu.
>>>>
>>>> This feature is about requesting this menu using oVirt's REST API
and
>>>> than calling it back once some item from this menu has been selected.
>>>>
>>>> The oVirt's feature page with specific details:
>>>> http://www.ovirt.org/Features/Foreign_Menu_Using_REST
>>>>
>>>> Any comments are more than welcomed.
>>>
>>> Why are we putting the logic of the menu into the REST API?
>>> can't the menu be builded by client based on getting the list of
>>> ISO's and current CD?
>>
>> The client needs a way to get the list of available ISOs in order to build
>> the menu, as well as a way to let the engine know when the user clicked on
>> an ISO in the menu. One way of doing that is to have the menu stuff exposed
>> in the REST API. Another way would be to expose the list of ISOs in the
>> REST API (I'd have a slight preference for that I think).
>
> that's my preference as well, and the REST API should already do that today:
> - get list of ISOs of available in a DC (the one the VM is in)
> - ability to change the CD of the VM
Well, and what about the stop/suspend VM for example, what we have in the menu today?
supported as well.
Also this should be something that the client decide to have or not
have?
I think the client should decide on the features relevant to the client.
>
>> Or do you have anything in mind for the client to get the list of ISOs
>> available to the engine?
>
> my preference is to provide the data, not the semantics of the menu.
We should clarify something here. There are two possibilities who should be responsible
for deciding
what should the foreign menu contain and also what to do if it the item is selected:
1: the client - e.g. we will not provide any support for the menu in REST because the
client reads what needs
and knows how to call the oVirt back
2: the server side - e.g. we will provide in REST side the menu structure with the
description what to do if something is
selected
Both have some advantages and disadvantages but we need to clarify which way to go. So,
who is the one responsible to decide
what is in the foreign menu (now or in the future) and how to react if something is
selected? Client or engine?
my preference is the client will decide this, as there are various
clients to the REST API, and each should decide which features are
important for them.
> iiuc, we are on the same page.
>
>>
>> Christophe
>>
>
>
2:02 a.m.
On Jun 20, 2013, at 14:27 , Itamar Heim <iheim(a)redhat.com> wrote:
On 06/20/2013 03:13 PM, Tomas Jelinek wrote:
>
>
> ----- Original Message -----
>> From: "Itamar Heim" <iheim(a)redhat.com>
>> To: "Christophe Fergeau" <cfergeau(a)redhat.com>
>> Cc: "Tomas Jelinek" <tjelinek(a)redhat.com>,
"engine-devel" <engine-devel(a)ovirt.org>,
>> spice-devel(a)lists.freedesktop.org, "Marc-André Lureau"
<mlureau(a)redhat.com>
>> Sent: Thursday, June 20, 2013 1:09:21 PM
>> Subject: Re: [Engine-devel] [Spice-devel] SPICE Foreign Menu Using REST
>>
>> On 06/20/2013 02:07 PM, Christophe Fergeau wrote:
>>> Hey Itamar,
>>>
>>> On Wed, Jun 19, 2013 at 06:00:47PM +0300, Itamar Heim wrote:
>>>> On 06/19/2013 04:33 PM, Tomas Jelinek wrote:
>>>>> Hi all,
>>>>>
>>>>> for the non plugin invocation of the console
>>>>> (http://www.ovirt.org/Features/Non_plugin_console_invocation) the
>>>>> dynamicMenu property is not usable to enrich the SPICE client menu.
>>>>>
>>>>> This feature is about requesting this menu using oVirt's REST API
and
>>>>> than calling it back once some item from this menu has been
selected.
>>>>>
>>>>> The oVirt's feature page with specific details:
>>>>> http://www.ovirt.org/Features/Foreign_Menu_Using_REST
>>>>>
>>>>> Any comments are more than welcomed.
>>>>
>>>> Why are we putting the logic of the menu into the REST API?
>>>> can't the menu be builded by client based on getting the list of
>>>> ISO's and current CD?
>>>
>>> The client needs a way to get the list of available ISOs in order to build
>>> the menu, as well as a way to let the engine know when the user clicked on
>>> an ISO in the menu. One way of doing that is to have the menu stuff exposed
>>> in the REST API. Another way would be to expose the list of ISOs in the
>>> REST API (I'd have a slight preference for that I think).
>>
>> that's my preference as well, and the REST API should already do that today:
>> - get list of ISOs of available in a DC (the one the VM is in)
>> - ability to change the CD of the VM
> Well, and what about the stop/suspend VM for example, what we have in the menu
today?
supported as well.
> Also this should be something that the client decide to have or not have?
I think the client should decide on the features relevant to the client.
>
>>
>>> Or do you have anything in mind for the client to get the list of ISOs
>>> available to the engine?
>>
>> my preference is to provide the data, not the semantics of the menu.
> We should clarify something here. There are two possibilities who should be
responsible for deciding
> what should the foreign menu contain and also what to do if it the item is selected:
> 1: the client - e.g. we will not provide any support for the menu in REST because the
client reads what needs
> and knows how to call the oVirt back
>
> 2: the server side - e.g. we will provide in REST side the menu structure with the
description what to do if something is
> selected
>
> Both have some advantages and disadvantages but we need to clarify which way to go.
So, who is the one responsible to decide
> what is in the foreign menu (now or in the future) and how to react if something is
selected? Client or engine?
my preference is the client will decide this, as there are various clients to the REST
API, and each should decide which features are important for them.
I would agree as long as it is not hardcoded and can be change in some config file easily.
We shouldn't wait for next RHEL release to do a little modification if possible.
I think "owning" the menu in some form on RHEV-M side has an advantage of
delivery synchronization.
>
>> iiuc, we are on the same page.
>>
>>>
>>> Christophe
>>>
>>
>>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
2:08 a.m.
On 06/24/2013 11:02 AM, Michal Skrivanek wrote:
On Jun 20, 2013, at 14:27 , Itamar Heim <iheim(a)redhat.com> wrote:
> On 06/20/2013 03:13 PM, Tomas Jelinek wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Itamar Heim" <iheim(a)redhat.com>
>>> To: "Christophe Fergeau" <cfergeau(a)redhat.com>
>>> Cc: "Tomas Jelinek" <tjelinek(a)redhat.com>,
"engine-devel" <engine-devel(a)ovirt.org>,
>>> spice-devel(a)lists.freedesktop.org, "Marc-André Lureau"
<mlureau(a)redhat.com>
>>> Sent: Thursday, June 20, 2013 1:09:21 PM
>>> Subject: Re: [Engine-devel] [Spice-devel] SPICE Foreign Menu Using REST
>>>
>>> On 06/20/2013 02:07 PM, Christophe Fergeau wrote:
>>>> Hey Itamar,
>>>>
>>>> On Wed, Jun 19, 2013 at 06:00:47PM +0300, Itamar Heim wrote:
>>>>> On 06/19/2013 04:33 PM, Tomas Jelinek wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> for the non plugin invocation of the console
>>>>>> (http://www.ovirt.org/Features/Non_plugin_console_invocation)
the
>>>>>> dynamicMenu property is not usable to enrich the SPICE client
menu.
>>>>>>
>>>>>> This feature is about requesting this menu using oVirt's REST
API and
>>>>>> than calling it back once some item from this menu has been
selected.
>>>>>>
>>>>>> The oVirt's feature page with specific details:
>>>>>> http://www.ovirt.org/Features/Foreign_Menu_Using_REST
>>>>>>
>>>>>> Any comments are more than welcomed.
>>>>>
>>>>> Why are we putting the logic of the menu into the REST API?
>>>>> can't the menu be builded by client based on getting the list of
>>>>> ISO's and current CD?
>>>>
>>>> The client needs a way to get the list of available ISOs in order to
build
>>>> the menu, as well as a way to let the engine know when the user clicked
on
>>>> an ISO in the menu. One way of doing that is to have the menu stuff
exposed
>>>> in the REST API. Another way would be to expose the list of ISOs in the
>>>> REST API (I'd have a slight preference for that I think).
>>>
>>> that's my preference as well, and the REST API should already do that
today:
>>> - get list of ISOs of available in a DC (the one the VM is in)
>>> - ability to change the CD of the VM
>> Well, and what about the stop/suspend VM for example, what we have in the menu
today?
>
> supported as well.
>
>> Also this should be something that the client decide to have or not have?
>
> I think the client should decide on the features relevant to the client.
>
>>
>>>
>>>> Or do you have anything in mind for the client to get the list of ISOs
>>>> available to the engine?
>>>
>>> my preference is to provide the data, not the semantics of the menu.
>> We should clarify something here. There are two possibilities who should be
responsible for deciding
>> what should the foreign menu contain and also what to do if it the item is
selected:
>> 1: the client - e.g. we will not provide any support for the menu in REST because
the client reads what needs
>> and knows how to call the oVirt back
>>
>> 2: the server side - e.g. we will provide in REST side the menu structure with
the description what to do if something is
>> selected
>>
>> Both have some advantages and disadvantages but we need to clarify which way to
go. So, who is the one responsible to decide
>> what is in the foreign menu (now or in the future) and how to react if something
is selected? Client or engine?
>
> my preference is the client will decide this, as there are various clients to the
REST API, and each should decide which features are important for them.
I would agree as long as it is not hardcoded and can be change in some config file
easily. We shouldn't wait for next RHEL release to do a little modification if
possible.
I think "owning" the menu in some form on RHEV-M side has an advantage of
delivery synchronization.
this forces you to maintain backward compatibility in the "Menu API",
the client to handle ignoring new features/items in the menu they don't
support yet, etc.
while the *data* which is the important part is already in the stable,
backward compatible, API.
>
>>
>>> iiuc, we are on the same page.
>>>
>>>>
>>>> Christophe
>>>>
>>>
>>>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
2:23 a.m.
On Jun 24, 2013, at 10:08 , Itamar Heim <iheim(a)redhat.com> wrote:
On 06/24/2013 11:02 AM, Michal Skrivanek wrote:
>
> On Jun 20, 2013, at 14:27 , Itamar Heim <iheim(a)redhat.com> wrote:
>
>> On 06/20/2013 03:13 PM, Tomas Jelinek wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Itamar Heim" <iheim(a)redhat.com>
>>>> To: "Christophe Fergeau" <cfergeau(a)redhat.com>
>>>> Cc: "Tomas Jelinek" <tjelinek(a)redhat.com>,
"engine-devel" <engine-devel(a)ovirt.org>,
>>>> spice-devel(a)lists.freedesktop.org, "Marc-André Lureau"
<mlureau(a)redhat.com>
>>>> Sent: Thursday, June 20, 2013 1:09:21 PM
>>>> Subject: Re: [Engine-devel] [Spice-devel] SPICE Foreign Menu Using REST
>>>>
>>>> On 06/20/2013 02:07 PM, Christophe Fergeau wrote:
>>>>> Hey Itamar,
>>>>>
>>>>> On Wed, Jun 19, 2013 at 06:00:47PM +0300, Itamar Heim wrote:
>>>>>> On 06/19/2013 04:33 PM, Tomas Jelinek wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> for the non plugin invocation of the console
>>>>>>> (http://www.ovirt.org/Features/Non_plugin_console_invocation)
the
>>>>>>> dynamicMenu property is not usable to enrich the SPICE client
menu.
>>>>>>>
>>>>>>> This feature is about requesting this menu using oVirt's
REST API and
>>>>>>> than calling it back once some item from this menu has been
selected.
>>>>>>>
>>>>>>> The oVirt's feature page with specific details:
>>>>>>> http://www.ovirt.org/Features/Foreign_Menu_Using_REST
>>>>>>>
>>>>>>> Any comments are more than welcomed.
>>>>>>
>>>>>> Why are we putting the logic of the menu into the REST API?
>>>>>> can't the menu be builded by client based on getting the list
of
>>>>>> ISO's and current CD?
>>>>>
>>>>> The client needs a way to get the list of available ISOs in order to
build
>>>>> the menu, as well as a way to let the engine know when the user
clicked on
>>>>> an ISO in the menu. One way of doing that is to have the menu stuff
exposed
>>>>> in the REST API. Another way would be to expose the list of ISOs in
the
>>>>> REST API (I'd have a slight preference for that I think).
>>>>
>>>> that's my preference as well, and the REST API should already do that
today:
>>>> - get list of ISOs of available in a DC (the one the VM is in)
>>>> - ability to change the CD of the VM
>>> Well, and what about the stop/suspend VM for example, what we have in the
menu today?
>>
>> supported as well.
>>
>>> Also this should be something that the client decide to have or not have?
>>
>> I think the client should decide on the features relevant to the client.
>>
>>>
>>>>
>>>>> Or do you have anything in mind for the client to get the list of
ISOs
>>>>> available to the engine?
>>>>
>>>> my preference is to provide the data, not the semantics of the menu.
>>> We should clarify something here. There are two possibilities who should be
responsible for deciding
>>> what should the foreign menu contain and also what to do if it the item is
selected:
>>> 1: the client - e.g. we will not provide any support for the menu in REST
because the client reads what needs
>>> and knows how to call the oVirt back
>>>
>>> 2: the server side - e.g. we will provide in REST side the menu structure
with the description what to do if something is
>>> selected
>>>
>>> Both have some advantages and disadvantages but we need to clarify which way
to go. So, who is the one responsible to decide
>>> what is in the foreign menu (now or in the future) and how to react if
something is selected? Client or engine?
>>
>> my preference is the client will decide this, as there are various clients to the
REST API, and each should decide which features are important for them.
>
> I would agree as long as it is not hardcoded and can be change in some config file
easily. We shouldn't wait for next RHEL release to do a little modification if
possible.
> I think "owning" the menu in some form on RHEV-M side has an advantage of
delivery synchronization.
>
this forces you to maintain backward compatibility in the "Menu API", the
client to handle ignoring new features/items in the menu they don't support yet, etc.
while the *data* which is the important part is already in the stable, backward
compatible, API.
i don't think it would be needed. We don't really need much features on spice
client side except for displaying and invoking a generic REST call. Items support is based
on Engine side if the menu is supplied by Engine side.
>
>>
>>>
>>>> iiuc, we are on the same page.
>>>>
>>>>>
>>>>> Christophe
>>>>>
>>>>
>>>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
3:47 a.m.
--JWEK1jqKZ6MHAcjA
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Mon, Jun 24, 2013 at 10:02:29AM +0200, Michal Skrivanek wrote:
I would agree as long as it is not hardcoded and can be change in
some
config file easily. We shouldn't wait for next RHEL release to do a
little modification if possible.
I think "owning" the menu in some form on RHEV-M side has an advantage of
delivery synchronization.
This probably would also make things harder from a client documentation
point of view. With something too generic, there's also always the risk
that it becomes a way to add workaround for bugs, or that the menu starts
containing things that would be better integrated in other places in the
client, ...
Christophe
--JWEK1jqKZ6MHAcjA
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
iEYEARECAAYFAlHIFbcACgkQJKRp+3pW945fvACfep8q8JMPb1/3QwuD+9j3Hk7U
e94AoKTtRuLFHOPJbqy5hOAinBDEOXzv
=ICrs
-----END PGP SIGNATURE-----
--JWEK1jqKZ6MHAcjA--
3:21 a.m.
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.
----- Original Message -----
From: "Christophe Fergeau" <cfergeau(a)redhat.com>
To: "Michal Skrivanek" <michal.skrivanek(a)redhat.com>
Cc: "Itamar Heim" <iheim(a)redhat.com>, "Tomas Jelinek"
<tjelinek(a)redhat.com>, spice-devel(a)lists.freedesktop.org,
"engine-devel" <engine-devel(a)ovirt.org>, "Marc-André Lureau"
<mlureau(a)redhat.com>
Sent: Monday, June 24, 2013 11:47:36 AM
Subject: Re: [Engine-devel] [Spice-devel] SPICE Foreign Menu Using REST
On Mon, Jun 24, 2013 at 10:02:29AM +0200, Michal Skrivanek wrote:
> I would agree as long as it is not hardcoded and can be change in some
> config file easily. We shouldn't wait for next RHEL release to do a
> little modification if possible.
> I think "owning" the menu in some form on RHEV-M side has an advantage of
> delivery synchronization.
This probably would also make things harder from a client documentation
point of view. With something too generic, there's also always the risk
that it becomes a way to add workaround for bugs, or that the menu starts
containing things that would be better integrated in other places in the
client, ...
Christophe
3:30 a.m.
--Clx92ZfkiYIKRjnr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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.
Christophe
--Clx92ZfkiYIKRjnr
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
iEYEARECAAYFAlHMBiIACgkQJKRp+3pW947Y5QCgl0p5Pv4g6bu3F/GlhQgR8Dxr
D0cAoJg7vJHqAGPXbFyPD+Q3+d+7E2aA
=j+mn
-----END PGP SIGNATURE-----
--Clx92ZfkiYIKRjnr--
3:50 a.m.
----- 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
10:01 a.m.
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]
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.
Only for the SPICE case in particular - I think that (b) should remain. so maybe worth
allowing
both same-credentials-login and different-credentials-login in the
REST-API-Session-ID-generation
code in the GUI.
----
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
>
>
>
11:41 p.m.
----- 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
>
>
>
10:01 a.m.
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).
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. 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.
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.
- 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).
[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
> > >
> > >
> > >
> >
>
11:29 p.m.
----- 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
> > >
> > >
> > >
> >
>
7:20 a.m.
----- Original Message -----
From: "Tomas Jelinek" <tjelinek(a)redhat.com>
Sent: Monday, July 1, 2013 1:29:20 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>
> 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).
>
> [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
> > > >
> > > >
> > > >
> > >
> >
>
12:22 a.m.
----- Original Message -----
From: "Einav Cohen" <ecohen(a)redhat.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>, "Tomas Jelinek"
<tjelinek(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)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(a)redhat.com>
> Sent: Monday, July 1, 2013 1:29:20 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>
> > 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(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
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
3948
days inactive
3961
days old
19 comments
6 participants
participants (6)
-
Christophe Fergeau -
Einav Cohen -
Itamar Heim -
Marc-André Lureau -
Michal Skrivanek -
Tomas Jelinek