All of lore.kernel.org
 help / color / mirror / Atom feed
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

             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.