[Engine-devel] oVirt and Quantum

[Roni Luxenberg]

----- 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