From: Sage Weil <sweil@redhat.com>
To: zhjwpku@gmail.com, ceph-devel@vger.kernel.org
Subject: wip-addr-features
Date: Thu, 5 May 2016 11:41:17 -0400 (EDT) [thread overview]
Message-ID: <alpine.DEB.2.11.1605051043220.15518@cpach.fuggernut.com> (raw)
Hi Zhao,
We identified wip-addr as a desireable first step to fixing up the
messenger protocol. It has a bunch of other nice benefits as well, like
being able to support both IPv4 and IPv6 in the same cluster.
I started rebasing the branch this morning ran into a bunch of non-trivial
questions about how we should structure the entity_addr_t to support both
new address types (ipv4, ipv6, xio, etc.) *and* the a new on-wire
protocol. But this is actually step 2...
Step 1 is to just get the feature bits plumbed down to every bit of code
that encodes an entity_addr_t to send over the wire so that we will
know whether to encode using the new or legacy format. To do that, I
pushed a simplified branch, wip-addr-features, to
https://github.com/liewegas/ceph/commits/wip-addr-features
The are some prelim encoding patches, then a patch that makes
entity_addr_t and entity_inst_t *optionally* accept feature bits. Let's
call it optional-features-patch. This compiles cleanly, and allows either
an existing featureless encode
entity_addr_t foo;
::encode(foo, bl); // old way we need to eliminate
or a featured encode
entity_addr_t foo;
::encode(foo, bl, features); // what we want
compile.
Then there's a patch that makes the old way not compile. Let's call it
required-features-patch. This will make the compiler spit out a million
errors for all the call sites that still need to be fixed.
Finally, there is a 'wip' commit that fixes some but not all call sites.
This commit needs to be broken down into simple, individual changes that
can be tested and reviewed separately.
The idea is to work with the require-features-patch applied to identify
remaining call sites that need features to encode entity_addr_t. Create
small, contained patches that fix individual modules, call sites, or add
supporting infrastructure (like the changes that expose features to OSD
cls ops in objclass/*).
Once there are several of those, remove the require-features-patch, and
make sure the changes are safe and clean and everything still works
properly. We can merge these as we go to make incremental progress.
Finally, once *everything* is fixed to pass features to addr encode sites,
the last commit will be the require-features-patch, and we can get it all
in master.
That will lay the foundation so that we can change the entity_addr_t
encoding to support the new protocols and encoding, the entity_addrvec_t
type, and so on.
(The plan is to replace most instnaces of entity_addr_t with
entity_addrvec_t--a list of addresses instead of a single one. And make
entity_addrvec_t encoded with old features spit out the legacy addr with
the legacy entity_addr_t encoding so that old clients can still function.)
We're all in #ceph-devel on irc.oftc.net--feel free to ask questions there
or on this email thread. Or we can do another video conf session to go
through it.
Thanks!
sage
next reply other threads:[~2016-05-05 15:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-05 15:41 Sage Weil [this message]
2016-05-08 15:00 ` wip-addr-features Junwang Zhao
2016-05-09 12:20 ` wip-addr-features Sage Weil
2016-05-09 14:14 ` wip-addr-features Junwang Zhao
2016-05-10 1:07 ` wip-addr-features Junwang Zhao
2016-05-10 11:34 ` wip-addr-features Junwang Zhao
2016-05-10 11:40 ` wip-addr-features Haomai Wang
[not found] ` <CAEG8a3+EsfBkATnOgVjwEoMNwa0sShz68hJE8YNODPeh3fCw8g@mail.gmail.com>
2016-05-10 11:46 ` wip-addr-features Junwang Zhao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.11.1605051043220.15518@cpach.fuggernut.com \
--to=sweil@redhat.com \
--cc=ceph-devel@vger.kernel.org \
--cc=zhjwpku@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.