On Sat, 10 Oct 2015, Haomai Wang wrote: > On Sat, Oct 10, 2015 at 5:49 AM, Sage Weil <s...@newdream.net> wrote: > Hey Marcus, > > On Fri, 2 Oct 2015, Marcus Watts wrote: > > wip-addr > > > > 1. where is it? > > 2. current state > > 3. more info > > 4. cheap fixes > > 5. in case you were wondering why? > > > > ____ 1. where is it? > > > > I've just pushed another update to wip-addr: > > > > g...@github.com:linuxbox2/linuxbox-ceph.git > > wip-addr > > > > ____ 2. current state > > > > This version > > 1/ compiles > > 2/ ran an extremely limited set of tests successfully > > (was able to bring up ceph-mon, ceph-osd). > > > > In theory, it should do everything a recent "master" branch > copy of ceph > > can do and little or nothing past that. Internally it adds > "address vector" > > support, some parsing/print logic, and lots of encoding rules > to pass them > > around, but there's nothing that can create and little that > makes any > > sensible use of this. So this is just the back end encoding > and storage rules. > > This is looking pretty good. I left some comments. There are > still a few > XXX's left... but not many. Haomai, can you help with the async > msgr one? > (Also, Marcus, can you check if the msg/Simple/Pipe.cc connect() > and > accept() code doing the right thing?) > > > I have a quick view among all commits, looks a great improvement for the > future enhancing. > > > One minor thing.. please put the subsystem as the prefix to the > commit > message instead of the branch name (e.g., mds: add features to > event > types). > > > Phase 2 is to add logic to actually make it useful. > > (the very start of this is on linuxbox2 "wip-addr-p2", > > just monmap changes so far...) > > ____ 3. more info > > > > There's an etherpad document that describes this in more > detail, > > > > http://pad.ceph.com/p/wip_addr > > > > ____ 4. cheap fixes > > > > a couple of minor issues that should be easy to resolve, > > 1. > > AsyncConnection.cc > > this passes addresses back and forth as it's setting up the > connection, > > and it also exchanges features. As best I can tell, it looks > like > > it exchanges addresses before it knows what features the other > end > > supports. There should be something in here that > > does this after knowing what features the other end supports. > > Copying Haomai. > > > Right, it should be the same as simple messenger. The "features" bit is > exchanged in "ceph_msg_connect" and "ceph_msg_connect_reply". > > I'm afraid that making features before addr exchange isn't a smooth way. > Maybe we need a middle release to help format migrating. Or we need to > add retry mechanism, we could add proper way to let new-style addr side > detect peer format.
Yeah... it seems like we need the initial exchange to share the addr that we accepted on, and then a second tag + addrvec to share the full list after that if both sides have the new feature bit. In any case, I think in both these cases encoding wth 0 with a FIXME comment is fine for the time being. sage
