Re: [Engine-devel] oVirt and Quantum

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?