mon: remove osd_epoch to avoid out-dated osdmap_cache

[tchaikov]

• replace the OSDMonitor::osd_epoch with the MonSession::osd_epoch
• apply this optimisation to all MonClients
• remove the duplicated code of the two OSDMonitor::send_incremental()

due to the refactory, one of the OSDMonitor::send_incremental() is not able to mark op events anymore.

FIxes: #10930 http://tracker.ceph.com/issues/10930

[loic-bot]

FAILURE: http://jenkins.ceph.dachary.org/job/ceph/6586/

• FAILURE http://jenkins.ceph.dachary.org/job/ceph/LABELS=centos-7&&x86_64/6586/

[tchaikov]

PASS: unittest_erasure_code_shec_all
+ test 124 = 124
+ display_logs ../../ceph-centos-7-jenkins
+ local dir=../../ceph-centos-7-jenkins
+ xargs grep -l FAIL
+ find ../../ceph-centos-7-jenkins -name '*.trs'
+ read file
+ echo abort by timeout after 1h
abort by timeout after 1h

the test failed due to timeout. will rebase and repush to see if it's a false negative.

[ghost]

@tchaikov thanks for repushing. I'm a little concerned, this is the second timeout run in 24h. I'll investigate.

[loic-bot]

FAILURE: http://jenkins.ceph.dachary.org/job/ceph/6593/

• FAILURE http://jenkins.ceph.dachary.org/job/ceph/LABELS=centos-7&&x86_64/6593/

[loic-bot]

SUCCESS: http://jenkins.ceph.dachary.org/job/ceph/6606/

• SUCCESS http://jenkins.ceph.dachary.org/job/ceph/LABELS=centos-7&&x86_64/6606/
• SUCCESS http://jenkins.ceph.dachary.org/job/ceph/LABELS=ubuntu-14.04&&x86_64/6606/

[liewegas]

This looks great. I think the thing to watch out for is when we need an older osd map before s->osd_epoch.

• preprocess_get_osdmap() is used if we get a bad crc and want an old map. This is untouched by this patch and doesn't use or modify s->osd_epock. Ok.
• We set s->osd_epoch to some new map in a lazy fashion (there are a few paths that just send the latest incremental to make sure the client knows there is a new map), but the osd goes back and wants earlier ones. In this case, Objecter will send a subscribe message to an earlier map. I think this is broken. I suggest

1. we consistently make send_incremental turn into a no-op if s->osd_epoch says they have it
2. in check_sub(), we reset s->osd_epoch back in time if they requested an older map.

What do you think?

[tchaikov]

@liewegas i rethought the earlier-osdmap problem:

in check_sub(), we reset s->osd_epoch back in time if they requested an older map.

we'd better reset s->osd_epoch when session_map.add_update_sub(). if we reset it afterwards, chances are that we've sent some osdmaps to the subscriber over this session already, and after resetting s->osd_epoch, these osdmaps will be re-sent.

i was thinking if we should rename osd_epoch into Subscription instead, this sounds more natural to me. but seems we can't. as we have two client types here 1) dedicated subscribers 2) other clients should be updated with latest osdmaps. in the later case, the session is not associated with a Subscription.

[liewegas]

Yeah, I think s->osd_epoch is fine. The current patches look right to me...

[tchaikov]

thanks for your review, sage. will merge it after the mon:thrash qa run.

[loic-bot]

FAILURE: http://jenkins.ceph.dachary.org/job/ceph/6991/

• FAILURE http://jenkins.ceph.dachary.org/job/ceph/LABELS=centos-7&&x86_64/6991/

[ghost]

@tchaikov please ignore the bot false negative, it is being fixed by @dillaman at http://tracker.ceph.com/issues/12664

[tchaikov]

running subset=1/3 rados:monthrash at http://pulpito.ceph.com/kchai-2015-08-20_06:26:38-rados:monthrash-wip-kefu-t3sting---basic-multi/.

[liewegas]

@tchaikov this passed my wip-sage-testing run. we can wait for yours to go as well or just merge, up to you!

[tchaikov]

@liewegas thanks for testing. the monthrash tests are also green. merging.