[Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations

Sun Nov 11 16:24:39 UTC 2012


----- Original Message -----
> From: "Simon Grinberg" <simon at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "Dan Kenigsberg" <danken at redhat.com>
> Sent: Sunday, November 11, 2012 5:45:41 PM
> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
> 
> Trying to answer open questions + provide feedback
> 
> -1. We need to change the term Power Management, we only do fencing
> here so why not call it by name, it may confuse with real power
> modes management that we'll probably do via VDSM and not via OOB
> management. Especially as some of the devices external to the host
> can only do fencing anyhow.
> 
> I'll change the requirement page, to reflect that + I'll split the
> proxy from dual card support, as the design should.

This was already done:
http://wiki.ovirt.org/wiki/Features/Design/HostPMProxyPreferences
http://wiki.ovirt.org/wiki/Features/Design/HostPMMultipleAgents


Have to move, will comment on other issues later on, please modify the new slitted wiki pages

> 
> 
> -2. Default value should be 'cluster, dc, engine' not the other way
> around. Actually most users I've been talking to will just use
> 'cluster' since this matches the classic cluster definition where
> host could only be fenced by another host in the cluster.
> 
> I'll change requirements to reflect that.
> 
> -3. The directly selected hosts comes to accommodate two use cases:
>    -3.1- Switch failure - if the fence network for hosts in a
>    DC/Cluster have to split between two switches. Then you will
>    prefer to use hosts that are for sure on the other switch
>    -3.2- Legacy clusters merged into larger clusters due to a move to
>    oVirt then the infrastructural may still fit to the legacy
>    connectivity - lot's of firewalls rules or direct connections
>    that limit access to fencing devices to specific hosts.
>    -3.3- Clustered applications within the VMs, you only want your
>    pears to be allowed to fence you. This is limited for VMs running
>    on specific host group (affinity management that we don't have
>    yet, but we can lock VMs to specific hosts).
> 
>    Note that the above was not meant to accommodate any random
>    server, just hosts in the setup, hosts that already run VDSM.
>    Meaning that maybe instead of the FQDN we can just use hostname -
>    so the UUID will be registered in the tables
>    I don't why it's so complex, if a host provided is removed from
>    the system you either get a canDoAction to remove it from the
>    configuration as well (or a warning that this will remove the
>    host from the fencing configuration). Your only risk if all of
>    them are removed, then you need to set the exclamation mark again
>    (power management is not configured for this host)
> 
> - 4. Assumption that every host will have all elements is wrong. In
> the requirement page I've gave combinations where it isn't.
>    Like said there are use cases where you don't want to diverge from
>    hosts in the same cluster. Reason is that if the last host in the
>    cluster (assuming clustered VMs running on this host) you may
>    actually prefer it won't be fenced. Similar to -3.3-
> 
> - 5. Thinking about it more, Though the chain is more generic and
> flexible, I would like to return to my original suggestion, of
> having just primary and secondary proxy:
>      Primary Proxy 1 => Drop down -> Any cluster host / Any DC host /
>      RHEV Manager / Named host out of the list of all the hosts
>      Secondary Proxy 2 => Drop down -> Any cluster host / Any DC host
>      / RHEV Manager / Named host out of the list of all the hosts
>      I think is simpler as far as a user is concerned and it's
>      simpler for us to implement two fields single value in each.
>      And I don't believe we really need more, even in the simple
>      case of cluster only hosts, for clusters larger then 4 hosts by
>      the time you get to the secondary it may be too late. Secondary
>      is more critical for the 'Named host' option or small clusters.
> 
> I'll look at it some more later today, but sending now to get as much
> feedback as possible.
> 
> Regards,
> Simon
>  
> 
> ----- Original Message -----
> > From: "Eli Mesika" <emesika at redhat.com>
> > To: "Dan Kenigsberg" <danken at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Sunday, November 11, 2012 1:18:53 PM
> > Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy
> > selection algorithm for Power Management operations
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Eli Mesika" <emesika at redhat.com>
> > > To: "Itamar Heim" <iheim at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Friday, November 9, 2012 12:06:05 PM
> > > Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy
> > > selection algorithm for Power Management operations
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Itamar Heim" <iheim at redhat.com>
> > > > To: "Eli Mesika" <emesika at redhat.com>
> > > > Cc: "engine-devel" <engine-devel at ovirt.org>, "Michael
> > > > Pasternak"
> > > > <mpastern at redhat.com>, "Simon Grinberg"
> > > > <sgrinber at redhat.com>, "Dan Kenigsberg" <danken at redhat.com>
> > > > Sent: Friday, November 9, 2012 12:02:37 PM
> > > > Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving
> > > > proxy
> > > > selection algorithm for Power Management operations
> > > > 
> > > > On 11/09/2012 10:52 AM, Eli Mesika wrote:
> > > > 
> > > > >> >
> > > > >> >  > FenceWrapper
> > > > >> >
> > > > >> >i understand danken suggested going this way, rather than
> > > > >> >than
> > > > >> >another
> > > > >> >instance of vdsm.
> > > > >> >is vdsm only calling these scripts today and all logic is
> > > > >> >in
> > > > >> >engine,
> > > > >> >or
> > > > >> >does vdsm has any logic in wrapping these scripts (not a
> > > > >> >blocker
> > > > >> >to
> > > > >> >doing FenceWrapper, just worth extracting that logic from
> > > > >> >vdsm
> > > > >> >to
> > > > >> >such a
> > > > >> >script, then using it in both. i hope answer is 'no
> > > > >> >logic'...)
> > > > > vdsm has some logic that maps between the call passed to it
> > > > > from
> > > > > engine and the actual parameters generated for the script.
> > > > > AFAIK, this logic only "builds" the correct arguments for the
> > > > > command according to the agent type
> > > > >
> > > > 
> > > > can we extract it to an external wrapper?
> > > > I'd hate to fix bugs/changes twice for this.
> > > 
> > > I'll check it with danken on SUN
> > 
> > Well, looked at it a bit , the VDSM code is in fenceNote function
> > in
> > API.py
> > What I think is that we can exclude the fenceNote implementation to
> > a
> > separate fence.py file and call it from the API.py
> > Then we can use one of the following in Java to call the method
> > from
> > fence.py
> > 1) jython
> > 2) org.python.util.PythonInterpreter
> > 
> > See
> > http://stackoverflow.com/questions/8898765/calling-python-in-java
> > 
> > danken, what do you think ?
> > 
> > > 
> > > > 
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
>