On 11/28/2012 01:20 PM, Saggi Mizrahi wrote:
...
VDSM should not bother with the issue at all, certainly not playing
a
guessing game.
Livant, your 0.02$?
This exactly the reason why we should either define completely
stateless slave host, and apply configuration including what you
call 'defaults'.
Completely stateless is problematic because if the engine is down or
unavailable and VDSM happens to restart you can't use any of your resources.
that's actually a very good point. going forward we would like to be
able for hosts to continue working when engine is down, even post
reboot. engine passing the policy to the hosts and hosts assuming that
policy is relevant post boot would allow that.
(though relying on central network services like qunatum will also cause
an issue for this architecture).
The way forward is currently to get rid of most of the configuration in
vdsm.conf.
Only have things that are necessary for communication with the engine (eg. Core
dump on\off, management interface\port, SSL on\off).
Other VDSM configuration should have a an API introduced to set them and that
will be persisted but only configurable by management (eg. reserved host mem,
guest ram overhead, migration timeouts).
There should be a place where VDSM saves the configuration of owned resources
(eg. managed storage connections, managed interfaces). This will be use by VDSM
to make sure that the resources are configured properly after
restarts\downtimes without the need of the engine.
To reiterate, the general logic for system resources should be that resources
are either owned or used by VDSM, you never share ownership.
Never assume ownership unless expressly given. VDSM has complete control over
owned resources. VDSM has NO control over unowned resources, he can use them
but never configure them.
Every other hybrid scheme is just asking for trouble.
Or, store configuration before we perform any change so we can
revert.
Assuming manual changes and distro specific persistence make the
problem complex in factor of np complete, as we do not know what was
changed when and how to revert.
Itamar though a bomb that we should co-exist on generic host, this is
something I do not know to compute. I still waiting for a response
of where this requirement came from and if that mandatory.
It's all about resource provisioning and ownership delegation.
hybrid mode is something brought up several times as a use case we
should consider. so far our main concern was that SLA in the host would
be needed (cgroup for example) between the native and guest workloads.
as well as making sure hybrid nodes will not contend for critical
resources to reduce the risk of a need to fence them.
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
