[
https://issues.apache.org/jira/browse/BOOKKEEPER-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14156264#comment-14156264
]
Ivan Kelly commented on BOOKKEEPER-634:
---------------------------------------
{quote}
-1 on Future.
it is mixing callback with Future, which brings in too much inconsistent
styles in BookKeeperAdmin. I think we already have quite good pattern on
replication code about multiple callbacks. if we are sticking on the callback
styles, you don't even need to have a different set of status code. we should
only use a single set of status code, rather than introducing something
different, which make code maintenance complicated.
{quote}
The call exposed in BookKeeperAdmin is synchronous, so the Future stuff is just
used in the implementation of the callback. The other option here would be to
use a CountDownLatch and variables to store the return code and return value,
i.e. a reimplentation of AbstractFuture.
{quote}
1) cookie will be updated first, which hence bookie will be restarted and
registered bookie id as different id.
2) every client will be aware of the book id change, since the
available_bookies zookeeper path will be updated.
3) after this point, running updating ledger metadata will change the metadata
version, hence the writers will have to re-read metadata in case of ensemble
changing. so new ledger or new ensemble will use the new bookie id, while the
old ledger metadata will be updated when re-reading on bad version.
{quote}
Before 1, the configuration on the bookie should be updated also. What worries
me more than anything is the mergeEnsembles behaviour. <digression>I think the
ensemble change needs to be revisited, in particular, making ledger metadata
immutable will clarify a lot of the sequence. Also, we should only allow one
bookie change at a time. It's unlikely to have 2 at a time, and it would make
the logic simpler, i.e.
1. create new metadata replacing bookie in position x of ensemble.
2. write to metadata store
3. if conflict, go to 1
4. if ok, replace metadata in ledger
We should also change this sequence so that if it fails, but the ensemble still
have enough bookies to reach ack quorum, we can continue. This is not for this
change though, more for after the release.</digression>
Also, what happens if we rename a bookie id, a ledger doesn't write anything
while the bookie is down, then tries to close the ledger. Again we get a
conflict, but what does close do in this situation. My guess, not having
looked, it that is just fails, which propagates up, maybe taking down the
writer. I guess this is ok, but again, it's something the client should be
aware of.
> Provide admin tool to rename bookie identifier in ledger metadata
> -----------------------------------------------------------------
>
> Key: BOOKKEEPER-634
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-634
> Project: Bookkeeper
> Issue Type: Sub-task
> Components: bookkeeper-client, bookkeeper-server
> Affects Versions: 4.2.1
> Reporter: Rakesh R
> Assignee: Rakesh R
> Fix For: 4.3.1
>
> Attachments: 0001-BOOKKEEPER-634-initial-draft-version.patch,
> 001-BOOKKEEPER-634-rename-bookieid-in-ledger.patch,
> 002-BOOKKEEPER-634-rename-bookieid-in-ledger.patch,
> BOOKKEEPER-634-rename-bookieid-in-ledger.patch, BOOKKEEPER-634.patch,
> BOOKKEEPER-634.patch
>
>
> This JIRA to discuss about admin tool for changing the bookie's IP to
> hostname.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
