Re: [Spice-devel] [Engine-devel] SPICE Foreign Menu Using REST
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 cferg...@redhat.com To: Michal Skrivanek michal.skriva...@redhat.com Cc: Itamar Heim ih...@redhat.com, Tomas Jelinek tjeli...@redhat.com, spice-devel@lists.freedesktop.org, engine-devel engine-de...@ovirt.org, Marc-André Lureau mlur...@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 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [Engine-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. Christophe pgpBQK40WZhYE.pgp Description: PGP signature ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [Engine-devel] SPICE Foreign Menu Using REST
- Original Message - From: Christophe Fergeau cferg...@redhat.com To: Tomas Jelinek tjeli...@redhat.com Cc: Michal Skrivanek michal.skriva...@redhat.com, Itamar Heim ih...@redhat.com, spice-devel@lists.freedesktop.org, engine-devel engine-de...@ovirt.org, Marc-André Lureau mlur...@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 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [Engine-devel] SPICE Foreign Menu Using REST
On Jun 20, 2013, at 14:27 , Itamar Heim ih...@redhat.com wrote: On 06/20/2013 03:13 PM, Tomas Jelinek wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Christophe Fergeau cferg...@redhat.com Cc: Tomas Jelinek tjeli...@redhat.com, engine-devel engine-de...@ovirt.org, spice-devel@lists.freedesktop.org, Marc-André Lureau mlur...@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-de...@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [Engine-devel] SPICE Foreign Menu Using REST
On Jun 24, 2013, at 10:08 , Itamar Heim ih...@redhat.com wrote: On 06/24/2013 11:02 AM, Michal Skrivanek wrote: On Jun 20, 2013, at 14:27 , Itamar Heim ih...@redhat.com wrote: On 06/20/2013 03:13 PM, Tomas Jelinek wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Christophe Fergeau cferg...@redhat.com Cc: Tomas Jelinek tjeli...@redhat.com, engine-devel engine-de...@ovirt.org, spice-devel@lists.freedesktop.org, Marc-André Lureau mlur...@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-de...@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [Engine-devel] SPICE Foreign Menu Using REST
On 06/24/2013 11:02 AM, Michal Skrivanek wrote: On Jun 20, 2013, at 14:27 , Itamar Heim ih...@redhat.com wrote: On 06/20/2013 03:13 PM, Tomas Jelinek wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Christophe Fergeau cferg...@redhat.com Cc: Tomas Jelinek tjeli...@redhat.com, engine-devel engine-de...@ovirt.org, spice-devel@lists.freedesktop.org, Marc-André Lureau mlur...@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-de...@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [Engine-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 pgpGCZWhnjaJ9.pgp Description: PGP signature ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [Engine-devel] SPICE Foreign Menu Using REST
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). Or do you have anything in mind for the client to get the list of ISOs available to the engine? Christophe pgpvc5GXRZRae.pgp Description: PGP signature ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [Engine-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 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 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [Engine-devel] SPICE Foreign Menu Using REST
- Original Message - From: Itamar Heim ih...@redhat.com To: Christophe Fergeau cferg...@redhat.com Cc: Tomas Jelinek tjeli...@redhat.com, engine-devel engine-de...@ovirt.org, spice-devel@lists.freedesktop.org, Marc-André Lureau mlur...@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 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [Engine-devel] SPICE Foreign Menu Using REST
On 06/20/2013 03:13 PM, Tomas Jelinek wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Christophe Fergeau cferg...@redhat.com Cc: Tomas Jelinek tjeli...@redhat.com, engine-devel engine-de...@ovirt.org, spice-devel@lists.freedesktop.org, Marc-André Lureau mlur...@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 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [Engine-devel] SPICE Foreign Menu Using REST
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 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [Engine-devel] SPICE Foreign Menu Using REST
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? ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
