----- Original Message ----- > 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.)
I don't think it is advisable to spread networking configuration and monitoring all over the place. ultimately all network configuration including physical and non vm networks should be owned by a single "network manager", so I think we should aim for augmenting quantum to support that. > 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. > I think that agents/drivers should only be able to talk back home to the plugin that supervise them. The quantum plugin, in turn, can access ovirt through REST api to get/extract any information needed. > >> > >>>> 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? The 'plug interface' is used to instantiate and configure the logical network/port on the destination host as well as on the fabric the host is connected to (adjacent switch, etc.) Thanks, Roni _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
