On Mon, Oct 17, 2011 at 09:19:15AM -0500, Adam Litke wrote:
> On Sat, Oct 15, 2011 at 11:16:04PM +0200, Yaniv Kaul wrote:
> > On 10/15/2011 11:05 PM, Dan Kenigsberg wrote:
> > > On Sat, Oct 15, 2011 at 10:34:55PM +0200, Yaniv Kaul wrote:
> > >> On 10/15/2011 10:19 PM, Dan Kenigsberg wrote:
> > >>
> > >> <SNIP>
> > >>> I find it quite awkward for ovirt-engine to send code to MOM. It is not
> > >>> like the
> > >>> programmers of ovirt-engine are smarter than you and could devise a
> > >>> better
> > >>> policy. It *is* important to have "ballooning profiles" attached to
> > >>> guests (e.g.
> > >>> "this VM is holy, do not balloon unless host is in deep manure") or
> > >>> hosts ("keep
> > >>> 100Mb free at all costs"). I think that defining the available profiles
> > >>> is the
> > >>> business of MOM - no one can do it better.
> > >>>
> > >>> Dan.
> > >> I disagree, for one reason - the engine has an overall view of the
> > >> system, not just of a single node.
> > >> However, I haven't found yet where it can be advantage. I'm sure
> > >> there are such cases, though.
> > >> The knowledge of an operating system, its properties (to which user
> > >> it belongs, its priority, is it related to another VM, ...) probably
> > >> has some value.
> > > Sure, but these should be a finite set policies and their parameters.
> > > Management
> > > layer should be provided with useful knobs and handles, not the ability
> > > to push
> > > generic code.
> > >
> > > Can you ever envisage ovirt-engine compiling a completely new policy on
> > > its own
> > > volition? This would require AI capabilities out of its current scope. The
> > > Engine may have several policies dumped in its database, and it would
> > > have to
> > > apply one of them to a host every time it changes to Up. The only
> > > advantage I
> > > see in this is that introducing a new policy in a new Engine version is
> > > simpler,
> > > and does not require updating all of its nodes.
> > >
> > > Dan.
> > Unless the customers want to write their own policies.
> Yes, and beyond customers think about vendors. MOM as designed allows for
> additional Collectors and Controllers to be dropped in and used by new
> Imagine adding a storage appliance that comes with a recommended policy
I think that this creates an uncomfortable marriage of code deployment
and control. Customets, as vendors, do not need the MOM api to put a
policy definition on the node - they can use rpm and yum, scp, or a
vdsm-devel mailing list