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.
-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" <emes...@redhat.com>
> To: "Dan Kenigsberg" <dan...@redhat.com>
> Cc: "engine-devel" <engine-devel@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" <emes...@redhat.com>
> > To: "Itamar Heim" <ih...@redhat.com>
> > Cc: "engine-devel" <engine-devel@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" <ih...@redhat.com>
> > > To: "Eli Mesika" <emes...@redhat.com>
> > > Cc: "engine-devel" <engine-devel@ovirt.org>, "Michael Pasternak"
> > > <mpast...@redhat.com>, "Simon Grinberg"
> > > <sgrin...@redhat.com>, "Dan Kenigsberg" <dan...@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@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> _______________________________________________
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
