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.
setSafeNetConfig, and the rollback-on-boot mess would be scrapped.
The only little problem would be to implement setupNetwork without playing with persisted ifcfg* files.