----- Original Message -----
From: "Itamar Heim" iheim@redhat.com To: "Dan Kenigsberg" danken@redhat.com Cc: "Alon Bar-Lev" alonbl@redhat.com, "VDSM Project Development" vdsm-devel@lists.fedorahosted.org, "Simon Grinberg" simon@redhat.com, "Andrew Cathrow" acathrow@redhat.com Sent: Monday, December 3, 2012 10:56:53 PM Subject: Re: [vdsm] Back to future of vdsm network configuration
On 12/03/2012 06:54 PM, Dan Kenigsberg wrote:
On Mon, Dec 03, 2012 at 04:28:16PM +0200, Itamar Heim wrote:
On 12/03/2012 04:25 PM, Dan Kenigsberg wrote:
On Mon, Dec 03, 2012 at 04:35:34AM -0500, Alon Bar-Lev wrote:
----- Original Message -----
From: "Mark Wu" wudxw@linux.vnet.ibm.com To: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org Cc: "Alon Bar-Lev" alonbl@redhat.com, "Dan Kenigsberg" danken@redhat.com, "Simon Grinberg" simon@redhat.com, "Antoni Segura Puimedon" asegurap@redhat.com, "Igor Lvovsky" ilvovsky@redhat.com, "Daniel P. Berrange" berrange@redhat.com Sent: Monday, December 3, 2012 7:39:49 AM Subject: Re: [vdsm] Back to future of vdsm network configuration
On 11/29/2012 04:24 AM, Alon Bar-Lev wrote: > > ----- Original Message ----- >> From: "Dan Kenigsberg" danken@redhat.com >> To: "Alon Bar-Lev" alonbl@redhat.com >> Cc: "Simon Grinberg" simon@redhat.com, "VDSM Project >> Development" vdsm-devel@lists.fedorahosted.org >> Sent: Wednesday, November 28, 2012 10:20:11 PM >> Subject: Re: [vdsm] MTU setting according to ifcfg files. >> >> On Wed, Nov 28, 2012 at 12:49:10PM -0500, Alon Bar-Lev wrote: >>> 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. >>> >> This bomb has been ticking since ever. We have ovirt-node >> images >> for >> pure hypervisor nodes, but we support plain Linux nodes, >> where >> local >> admins are free to `yum upgrade` in the least convenient >> moment. >> The >> latter mode can be the stuff that nightmares are made of, but >> it >> also >> allows the flexibility and bleeding-endgeness we all cherish. >> > There is a different between having generic OS and having > generic > setup, running your email server, file server and LDAP on a > node > that running VMs. > > I have no problem in having generic OS (opposed of ovirt-node) > but > have full control over that. > > Alon. Can I say we have got agreement on oVirt should cover two kinds of hypervisors? Stateless slave is good for pure and normal virtualization workload, while generic host can keep the flexibility of customization. In my opinion, it's good for the oVirt community to provide choices for users. They could customize it in production, building and even source code according to their requirements and skills.
I also think it will be good to support both modes! It will also good if we can rule the world! :)
Now seriously... :)
If we want to ever have a working solution we need to focus, dropping wishful requirements in favour of the minimum required that will allow us to reach to stable milestone.
Having a good clean interface for vdsm network within the stateless mode, will allow a persistent implementation to exists even if the whole implementation of master and vdsm assume stateless. This kind of implementation will get a new state from master, compare to whatever exists on the host and sync.
I, of course, will be against investing resources in such network management plugin approach... but it is doable, and my vote is not something that you cannot safely ignore.
I cannot say that I do not fail to parse English sentences with double or triple negations...
I'd like to see an API that lets us define a persistent initial management interface, and create volatile network devices during runtime. I'd love to see a define/create distiction, as libvirt has.
How about keeping our current setupNetwork API, with a minor change to its sematics - it would not persist anything. A new persistNetwork API would be added, intending to persist the management network after it has been tested.
On boot, only the management defitions would show up, and Engine (or a small local sevice on top of vdsm) would push the complete configuration.
how does this benefit over loading the last config, and then have engine refresh (always/if needed)?
It's clearer for the local admin: if it's on the file system, it would be there after boot; he can do his worst to them, and we'd try to manage.
Also, it is easier to recover from utterly-horrible remote commands, which had rendered our host incommunicado: the management interface used to send these commands -- and only it -- would show up after boot. This increases the probability that after fencing, we'd see the host again.
i think we mentioned this before, but this will kill any way to have hosts come back to life, also have a policy on connecting to storage, even if engine is still down. (one of these use cases is for the engine itself to be hosted on the hosts as well)
For this use case you'll need much more - you'll need host based clustering (Assuming your engine is on a self hosted VM), this it a total different ball game.
But note that the approach does not contradict that: 1. You always have your admin statefull configuration on host boot - this is the idea behind getting back to the original host network configuration (not necessary just the management interface) that I've raised in one of the numerous threads on this subject. I don't remember if it was on this one or another. 2. The stateless configuration coming from the engine is always on top
Anything required to re-run the engine on a host reboot must be part of the statefull section and not part of the engine config section.