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

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

Reply via email to