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" <wu...@linux.vnet.ibm.com> > >>>To: "VDSM Project Development" <vdsm-devel@lists.fedorahosted.org> > >>>Cc: "Alon Bar-Lev" <alo...@redhat.com>, "Dan Kenigsberg" > >>><dan...@redhat.com>, "Simon Grinberg" <si...@redhat.com>, > >>>"Antoni Segura Puimedon" <asegu...@redhat.com>, "Igor Lvovsky" > >>><ilvov...@redhat.com>, "Daniel P. Berrange" > >>><berra...@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" <dan...@redhat.com> > >>>>>To: "Alon Bar-Lev" <alo...@redhat.com> > >>>>>Cc: "Simon Grinberg" <si...@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. _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
