Hi, On Sat, Apr 17, 2010 at 11:40:36AM +0200, Lars Marowsky-Bree wrote: > On 2010-04-16T23:51:55, Lars Ellenberg <[email protected]> wrote: > > > > > We need it for ACL support in pacemaker. > > I thought that was going to be done differently, as it needs to be > > solved differently anyways to support remote TCP (or in general, non > > unix domain) connections? > > That doesn't preclude the need for being able to identify local sockets, > which work quite differently from TCP; the user has already identified > to the system and we want to be able to reuse those credentials. > > > So I'll post it complete > > (with a few comment changes, to hopefully clear things up). > > It is basically a revert of the revert, moving the members > > to the end of the struct, bumping version-info, > > and adding the new IPC_UDS_CRED alias. > > Lars, I have no other way of saying this, but I still think you're > completely misguided in this desire to preserve binary compatibility. > You're acting as if this was important - it is not. We've never cared in > the past. You might have a point if this required old code to be > changed, but it's simply a recompile.
In the past everything was part of the single Heartbeat project. > This _does_ complicate code, and we're stuck with the runtime handling > forever. All for 2 simple ints added! Didn't review the proposed patch thoroughly, but can't imagine that it would be complex. If it does, then we won't do that. > What you STILL have failed to reply to at all is my major comment > regarding the process of installing the upgrade: for _any_ cluster-glue > upgrade to take effect, the cluster stack needs a restart anyway. ie, no > additional service downtime if they upgrade the rest too. > > What's the point in preserving local ABI compatibility if they have to > restart everything anyway? Right. Given that everything is upgraded. Most users would probably do that, but some may not. > Two additional comments on that - > > First, show me the user where "cluster-glue" is the driving motivator > for an upgrade. "Oh yes, I really need to upgrade my core libraries, > lets take my cluster down for this and not install all those more > significant bugfixes in pacemaker at the same time"? > > (If they're on heartbeat, there have been much less changes there of > course, but still, installing a rebuild heartbeat package is trivial as > well.) > > Second, I believe getting users an incentive (even if it is slight, see > first point) to upgrade is _good_. > > > I have absolutely no understanding for your desire to keep this ABI > compatible and make code more complicated by needing to support > different semantics. And I get _paid_ to ship binary-compatible > distributions, have been for a decade, and I still don't get it. > > I can't imagine a customer environment where this actually matters. > Noone will install just cluster-glue in the modern environments. Nobody > brings down their cluster for just that. > > You're making the wrong call on the trade-off. > > Anyway, I've had my say. If you want to go down this route, do so. But I > get to say "I told you so". We have already expended so much energy on this matter which doesn't really deserve that. It is going to be resolved and the needed functionality will be there. Unfortunately, I made a mistake not reacting earlier. That would've saved us all quite a bit of time. Cheers, Dejan > Regards, > Lars > > -- > Architect Storage/HA, OPS Engineering, Novell, Inc. > SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) > "Experience is the name everyone gives to their mistakes." -- Oscar Wilde > > _______________________________________________________ > Linux-HA-Dev: [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > Home Page: http://linux-ha.org/ _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
