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?
_______________________________________________
Engine-devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/engine-devel
