[Engine-devel] SPICE IP override

[Itamar Heim]

On 11/15/2012 09:06 AM, Yaniv Kaul wrote:
> ----- Original Message -----
>> On 11/15/2012 08:33 AM, Yaniv Kaul wrote:
>>> On 11/15/2012 06:10 AM, Itamar Heim wrote:
>>>> On 11/11/2012 11:45 AM, Yaniv Kaul wrote:
>>>>> On 11/07/2012 10:52 AM, Simon Grinberg wrote:
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Michal Skrivanek"<michal.skrivanek at redhat.com>
>>>>>>> To:engine-devel at ovirt.org
>>>>>>> Sent: Tuesday, November 6, 2012 10:39:58 PM
>>>>>>> Subject: [Engine-devel] SPICE IP override
>>>>>>>
>>>>>>> Hi all,
>>>>>>> On behalf of Tomas - please check out the proposal for
>>>>>>> enhancing our
>>>>>>> SPICE integration to allow to return a custom IP/FQDN instead
>>>>>>> of the
>>>>>>> host IP address.
>>>>>>> http://wiki.ovirt.org/wiki/Features/Display_Address_Override
>>>>>>> All comments are welcome...
>>>>>> My 2 cents,
>>>>>>
>>>>>> This works under the assumption that all the users are either
>>>>>> outside of the organization or inside.
>>>>>> But think of some of the following scenarios based on a topology
>>>>>> where users in the main office are inside the corporate network
>>>>>> while users on remote offices / WAN are on a detached different
>>>>>> network on the other side of the NAT / public firewall :
>>>>>>
>>>>>> With current 'per host override' proposal:
>>>>>> 1. Admin from the main office won't be able to access the VM
>>>>>> console
>>>>>> 2. No Mixed environment, meaning that you have to have
>>>>>> designated
>>>>>> clusters for remote offices users vs main office users -
>>>>>> otherwise
>>>>>> connectivity to the console is determined based on scheduler
>>>>>> decision, or may break by live migration.
>>>>>> 3. Based on #2, If I'm a user travelling between offices I'll
>>>>>> have
>>>>>> to ask the admin to turn off my VM and move it to internal
>>>>>> cluster
>>>>>> before I can reconnect
>>>>>>
>>>>>> My suggestion is to covert this to 'alternative' IP/FQDN sending
>>>>>> the
>>>>>> spice client both internal fqdn/ip and the alternative. The
>>>>>> spice
>>>>>> client should detect which is available of the two and
>>>>>> auto-connect.
>>>>>>
>>>>>> This requires enhancement of the spice client, but still solves
>>>>>> all
>>>>>> the issues raised above (actually it solves about 90% of the use
>>>>>> cases I've heard about in the past).
>>>>>>
>>>>>> Another alternative is for the engine to 'guess' or 'elect'
>>>>>> which to
>>>>>> use, alternative or main, based on the IP of the client -
>>>>>> meaning
>>>>>> admin provides the client ranges for providing internal host
>>>>>> address
>>>>>> vs alternative - but this is more complicated compared for the
>>>>>> previous suggestion
>>>>>>
>>>>>> Thoughts?
>>>>>
>>>>> Lets not re-invent the wheel. This problem has been pondered
>>>>> before and
>>>>> solved[1], for all scenarios:
>>>>> internal clients connecting to internal resources;
>>>>> internal clients connecting to external resources, without the
>>>>> need for
>>>>> any intermediate assistance
>>>>> external clients connecting to internal resources, with the need
>>>>> for
>>>>> intermediate assistance.
>>>>> VPN clients connecting to internal resources, with or without an
>>>>> internal IP.
>>>>>
>>>>> Any other solution you'll try to come up with will bring you back
>>>>> to
>>>>> this standard, well known (along with its faults) method.
>>>>>
>>>>> The browser client will use PAC to determine how to connect to
>>>>> the hosts
>>>>> and will deliver this to the client. It's also a good path
>>>>> towards real
>>>>> proxy support for Spice.
>>>>> (Regardless, we still need to deal with the Spice protocol's
>>>>> migration
>>>>> command of course).
>>>>>
>>>>>
>>>>> [1] http://en.wikipedia.org/wiki/Proxy_auto-config
>>>>
>>>> so instead of a spice proxy fqdn field, we should just allow user
>>>> to
>>>> specify a pac file which resides under something like
>>>> /etc/ovirt/engine/pac...?
>>>
>>> I would actually encourage the customers to use their own corporate
>>> PAC
>>> and add the information to it.
>>
>> so you are suggesting that there is no need at all to deal with proxy
>> definition/configuration at ovirt engine/user portal level?
>
> I expect the admin/user portal to send the result of the PAC processing to the Spice client.
> I don't think the Spice client should execute the PAC (it's a Javascript...).

ok, so no engine, but just client side support for PAC?