On Fri, Aug 22, 2008 at 12:05 PM, Graeme Fowler [off-list ref] wrote:

On Fri, 2008-08-22 at 11:56 +0200, Julius Volz wrote:

quoted

There's also a '__u8 reserved' field at the beginning of that struct
which could be used. But in general, is it reasonable to expect both
nodes to use the same kernel version, which gets rid of the
extensibility problems? It's not really an ABI that can't be broken,
right?

I think from an operational (ie. end user) perspective, ABI breakage is
something to try to avoid but _not_ at all costs.

If it's possible to extend the sync daemon protocol by reusing the
existing code and ABI, all well and good; however if a fundamental
change is made which breaks the old sync daemon ABI then as long as it's
documented and we make sure that users know to have the same (or higher)
kernel versions on their directors then everyone wins.

Yeah, and it's not an ABI, it's a very specialized protocol between
two kernels, so the rules are less clear. However, I totally agree
with you that it's not convenient from the users' point of view.

quoted

Yes, without jumping through hoops, we have to probably break the
current protocol anyways for new features? Even if we designated
unused fields for new information, an old kernel will not look at them
/ fill them out, which limits the possibilities...

I guess that as and when this change is made and gets into mainline
releases, Joe and I will have to have a mantra of "ensure your directors
are using the same kernel version" in response to queries on
lvs-users :)

He :) Imagine an old kernel on the backup receiving new messages and
not understanding them. How could we at least handle that situation
gracefully (without totally confusing the older kernel)? We'd need to
do it in a way that old features are still communicated in the same
way. E.g., v4-only connection syncs still use the same message format,
but once you use v6 entries, an unused flag or the 'reserved' field in
ip_vs_sync_conn is used. A v6 message would still confuse an older
kernel then, but a user would already notice that ipvsadm can't
configure the v6 services on the older kernel, so that's not too bad.

Anyways, these are just some thoughts. I'm unsure if we really need to
worry about this extension right now or if we could postpone it? At
least for me, it makes more sense to clean up the minimal set of IPv6
features first and then think about the more advanced/optional ones,
like the sync daemon.

Julius

-- 
Google Switzerland GmbH