[
https://issues.apache.org/jira/browse/BOOKKEEPER-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154644#comment-14154644
]
Ivan Kelly commented on BOOKKEEPER-634:
---------------------------------------
use of abstractFuture is a weird.
in case of an error, the callback should do
setException(BKException.create(rc)); you can manage the different exceptions
in the "for (ReadLedgerMetadataCb cb : ledgers) {", without having to use a
Status object at all.
I don't actually see the point of limit. Why would you only want to update some
random subset of ledgers? How do you know if there are still ledgers that exist
with the ip based bookieid.
rename printUpdateLedgerStatus to maybePrintUpdateLedgerStatus or something.
It's a imperative function, but may not actually carry out what it says it will.
Don't throw Exception from updateBookieIdInLedgers(), throw BKException. The
Future.get() will throw a ExecutionException, but you should be able to cast
the result of getCause() to BKException, since that's what you have put there.
One thing that's a little weird about the tool is that it only updates the
ledgers for a single bookie. So for each bookie changed, you'll have to iterate
over all ledgers. Not sure how to fix this cleanly though.
Don't manually put "localhost:" into the tests. This is likely to break on
different configurations.
there's no guarantee that addEntry is actually still in progress when you do a
rename in testRenameWhenAddEntryInProgress(). Possibly the source of the test
error.
Another thing to consider is that a ledger may continue to use the old bookie
id, after the bookie has restarted with the new bookie id, if nothing was
written to the ledger during the restart period. This means that a ledger
rename could occur, and you would assume that all ledgers have the new bookie
id, but then a ensemble change happens on the aforementioned ledger and the old
bookie id comes back into play. I dunno if this is bad, but we should be aware
of it at least. For example, if someone switches to hostnames in anticipation
of a big ip change, they could get caught on this.
For this reason I think we need to be clearer on the scenarios in which a admin
would use this tool, and also we need to be able to audit the ledgers to ensure
that if we update a bookie id, it doesn't exist in the system and can't remerge
in the system.
As this is a tool, I suggest we move this to next release (which should be soon
after 4.3.0 (Dec maybe?); 4.3.0 has much too much in it). If a user needs the
tool they can get it from trunk before then. It doesn't stop anyone from
starting to use the new bookie ids with 4.3.0.
> 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.0
>
> 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)
