On Sat, Dec 03, 2011 at 06:08:45PM -0500, Ayal Baron wrote:
> 
> 
> ----- Original Message -----
> > On Thu, Dec 01, 2011 at 10:13:53PM -0500, Saggi Mizrahi wrote:
> > > I want to suggest a different way of handling constants.py and
> > > config.py
> > > the current way is clumsy and makes making convoluted code easy.
> > > 
> > > GLOBAL VARIABLES ARE BAD. It's not something I invented. It's well
> > > accepted that proper scoping yields better code.
> > 
> > FOLLOWING UPERCASE MAXIMS BLINDLY IS BAD. (and that's something I
> > have invented.)
> > 
> > > 
> > > The way we use those two files shows how much of a mess globally
> > > accessible variable can be.
> > > 
> > > Not putting paths to executable in constants.py
> > > -----------------------------------------------
> > > Instead we should have a module for each utility executable. The
> > > module
> > > should wrap the utility with a pythonic interface. That way there
> > > is no
> > > reason for more then one module to have access to a utility's path.
> > > 
> > > For example:
> > > 
> > > cat.py
> > > ------
> > > 
> > > _CAT_PATH = @CAT_PATH@
> > > 
> > > def cat(files):
> > >     cmd = [_CAT_PATH] + files
> > >     out, err = exec(cmd)
> > >     return out
> > > 
> > > Now there is no need to know where cat is. You have a proper
> > > interface
> > > to use. Preventing people from re-wrapping the utility over and
> > > over.
> > > This in turn means you have a canonical wrapper that is more likely
> > > to work.
> > 
> > I agree that our current behavior is clunky. Most external executable
> > should be
> > wrapped by functions that exposes the functionality which we need
> > from them.
> > 
> > I am not sure that having a module per executable makes the most
> > sense; I'd
> > separate modularity based on Vdsm usage of them. Anyway, the only up
> > side of our
> > current constants-aggregating approach, is that the number of files
> > editted by
> > autoconf is limitted.
> > 
> > P.S. EXT_CAT is a horrible example. It exists only for letting Vdsm
> > read
> > /etc/multipath.conf. This functionality must be wrapped properly and
> > shoved into
> > supervdsm.
> 
> That doesn't mean that supervdsm shouldn't have a canonical way of using it 
> which could be later on leveraged in other places.
> i.e. assuming we converge on this way of doing things, it should apply to 
> supervdsm as well.

I'm not sure what you are saying here...
But I would like to stress again that "cat" is way too low-level and
generic to be exposed by supervdsm. supervdsm should expose higher-level
functions that cannot harm irrelevant parts of the host.

Dan.
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to