On Wed, Feb 9, 2011 at 2:17 PM, Dejan Muhamedagic <deja...@fastmail.fm> wrote:
> Hi Andrew,
>
> On Wed, Feb 09, 2011 at 01:33:03PM +0100, Andrew Beekhof wrote:
>> On Wed, Feb 9, 2011 at 12:15 PM, Dejan Muhamedagic <deja...@fastmail.fm> 
>> wrote:
>> > On Wed, Feb 09, 2011 at 12:06:04PM +0100, Florian Haas wrote:
>> >> On 2011-02-09 11:56, Dejan Muhamedagic wrote:
>> >> >> It is plugin compatible to the old version of the agent.
>> >> >
>> >> > Great! Unfortunately, we can't replace the old db2 now, the
>> >> > number of changes is very large:
>> >> >
>> >> >  db2 | 1076 
>> >> > +++++++++++++++++++++++++++++++++++++++++++-------------------------
>> >> >  1 file changed, 687 insertions(+), 389 deletions(-)
>> >> >
>> >> > And the code is completely new (though I have no doubt that it is
>> >> > of excellent quality). So, I'd suggest to add this as another db2
>> >> > RA. Once it gets some field testing we can mark the old one as
>> >> > deprecated. What name would you suggest? db2db2?
>> >>
>> >> Just making sure: Is that a joke?
>> >
>> > A bit of a joke, yes. But the alternatives such as db22 or db2new
>> > looked a bit boring.
>>
>> I think boring is the least of our problems with those names.
>> Are you going to change the name of every agent that gets a rewrite?
>>
>>    IPaddr2-ng-ng-again-and-one-more-plus-one
>
> I don't think it is going to happen that often.

It happens often enough - its just normally by a core developer.
And realistically, almost every RA is going to get similar treatment
(over time) as they're merged with the Red Hat ones.

>
>> Solicit feedback, like was done for kliend's new agent, and replace
>> the existing one it if/when people respond positively.
>
> That would be for the best, but it takes time. We may opt for it,
> but I wanted to add the this agent to the new release.

Understood - but I think the long-term pain that is created outweighs
any perceived benefit in the short-term.

> Also, it
> is very seldom that people test anything which is not contained
> in the release. Unless there's no alternative as was the case
> with conntrac.
>
>> Its not like the old one disappears from the face of the earth after
>> you merge the new one.
>>
>>    wget -o /usr/lib/ocf/resource.d/heartbeat/db2
>> http://hg.linux-ha.org/agents/file/agents-1.0.3/heartbeat/db2
>
> What do you suggest? That we add to the release announcement:
>
>        The db2 RA has been rewritten and didn't get yet a lot of
>        field testing. Please help test it.

So don't do that :-)
Put up a wiki page with instructions for how to download+use the new
agent and give feedback.

If the new version is significantly better, you're going to hear
people pleading for its inclusion pretty soon.

> But, if you want to keep
>        the old agent, download the old one from the repository and
>        use it instead of the new one. And don't forget to do the
>        same when installing the next resource-agents release.
>
> At any rate, I wouldn't want to take responsibility for replacing
> the existing (and working RA) with a completely new and not yet
> tested code. Call me coward :)

I wouldn't either - which is why I keep saying "test then replace" :-)
Another alternative, create a "testing" provider... not sure if its a
good idea or not, just putting it out there.

> Finally, I expected that the new functionality is going to be
> added without much changes to the existing code. But it turned
> out to be a rewrite.
>
> Cheers,
>
> Dejan
>
>> >> > HADR is a very different beast from non-HADR db, right? Why not
>> >> > then add the "hadr" boolean parameter and use that instead of
>> >> > checking if the resource has been configured as multi-state?
>> >>
>> >> I'll take responsibility for suggesting the use of ocf_is_ms(), and I'd
>> >> be curious to find out what you think is wrong with that approach.
>> >
>> > There's nothing wrong in the sense whether it is going to work.
>> > But someday, db2 may sport say HADR2 or VHA or whatever else
>> > which may run as a ms resource. I just think that it's better to
>> > make it obvious in the configuration that the user runs HADR.
>> > Does that make sense?
>> >
>> >> Because if anything is, then the mysql RA needs fixing too.
>> >
>> > No idea what's up with mysql.
>> >
>> > Cheers,
>> >
>> > Dejan
>> >
>> >> Florian
>> >>
>> >
>> >
>> >
>> >> _______________________________________________________
>> >> Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
>> >> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
>> >> Home Page: http://linux-ha.org/
>> >
>> > _______________________________________________________
>> > Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
>> > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
>> > Home Page: http://linux-ha.org/
>> >
>> _______________________________________________________
>> Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
>> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
>> Home Page: http://linux-ha.org/
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
>
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

Reply via email to