[Engine-devel] oVirt and Quantum

[Itamar Heim]

On 05/15/2012 02:55 PM, Irena Berezovsky wrote:
...

>> ovirt engine keeps it. how would one query by it though? what api and credentials would they be using to do so?
>> [IB] I think it should be accessible via REST and SDK .
>> I guess it should use admin credentials, but not sure.
>
> REST doesn't support lookup by every property and the is search for vnics/ports.
> so a modeling question.
> I'm not sure i like the concept of providing an administrative user credentials to all hosts, or of managing a password change in this case.
> not sure hosts should use the REST API, or another API intended for bi-directional communication with engine, secured in the same way the xml/rpc is secured.
>
> [IB2] Considering Quantum plugin implementation, I guess that may also handle physical Network configuration (Network between Hypervisors). In such case Quantum Plugin will need to resolve for VIF UUID plugged to certain network on what Server it is deployed. I think is the best way is to get it via SDK or REST. Do you have any suggestion?

from what i understand, this isn't about using quantum for the non vm 
networks (management, storage, live migration, etc.)
we need to find a solution to passing needed info for agents/drivers 
through supported communication channels.
yes, the REST API is there, but i don't see a provisioning process 
providing hosts with credentials to access the REST API (or as specified 
above, REST API having a query to match the requested information).

OTOH, it could make sense to have hosts pull various type of 
configuration information relevant to them from ovirt engine via an api 
limited to hosts, based on their hosts certificates.
then have agents use this as the supported communication channel.

>>
>>>> VM Migrate:
>>>> Even though it's just an initial suggestion, I think that VM
>>>> migration use case should be elaborated also for 'else' cases. What
>>>> happens if target Host does not support Quantum? What happens if
>>>> target host fails to run VM? Another issue is a lack of calls to
>>>> Quantum. For my understanding (but I can be wrong) in OpenStack it
>>>> will issue unplug and plug attachment calls.
>>> I agree. The goal here should be VM uptime and connectivity. If the
>>> "network" connectivity can be support but in a limited fashion then
>>> great - the migration can take place - this should nonetheless only
>>> be done when there is no other option. The live migration algorithm
>>> may have to be tweaked to support this.
>>
>> we do not assume involvement in engine in live migration today other than issuing a 'migrate' command to source host, or host needing information from engine to perform the live migration.
>> there must be a very good reason to break this assumption.
>> [IB] If this assumption should be in place, maybe it worth to consider to invoke 'create port' and 'plug interface' Quantum calls from VDSM node and not from oVirt engine. This this  the model in OpenStack. Nova-compute invokes 'create port' and 'plug interface' Quantum calls.
>> It is described in the following doc:
>> http://wiki.openstack.org/QuantumAPIUseCases
>
> I'm not sure i like that better.
> would it be possible for engine to pre-provision the port on more than one host?
> [IB2] For my understanding, definition of port on the Network just defines a logical port and does not apply the physical location.  Regarding the interface plugging it probably should work for plugging same interface more than once temporarily during VM migration phase.

if it doesn't provide physical location, then i am not sure i understand 
why another call is required to begin with?