[
https://issues.apache.org/jira/browse/CASSANDRA-9761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14738426#comment-14738426
]
Sam Tunnicliffe commented on CASSANDRA-9761:
--------------------------------------------
[~slebresne], I'm not sure how I didn't notice in the first place, but I
realised that your original branch was based on 3.0, not 2.2. Was it
intentional to skip 2.2 with this fix, or just an oversight?
Seeing as dtests on 3.0/trunk are holding this up anyway, I've backported to
2.2 and updated my branches for CI.
Patches:
* [2.2 branch|https://github.com/beobal/cassandra/tree/9761-2.2]
* [3.0 branch|https://github.com/beobal/cassandra/tree/9761-3.0]
* [trunk branch|https://github.com/beobal/cassandra/tree/9761-trunk]
CI Tests:
* [2.2
testall|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-9761-2.2-testall/]
* [2.2
dtest|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-9761-2.2-dtest/]
* [3.0
testall|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-9761-3.0-testall/]
* [3.0
dtest|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-9761-3.0-dtest/]
* [trunk
testall|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-9761-trunk-testall/]
* [trunk
dtest|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-9761-trunk-dtest/]
> Delay auth setup until peers are upgraded
> -----------------------------------------
>
> Key: CASSANDRA-9761
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9761
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Sam Tunnicliffe
> Assignee: Sylvain Lebresne
> Fix For: 3.0.0 rc1, 2.2.2
>
>
> The built in auth classes {{CassandraRoleManager}} and
> {{CassandraAuthorizer}} both attempt to do some setup and data conversion
> when a node is upgraded to version 2.2 or higher. At the moment, each node
> attempts the operations with the expectation that this will fail until enough
> of the cluster has been upgraded for it to succeed (i.e. enough nodes have
> the latest schema with the requisite new tables). These expected failures are
> largely harmless, but they are annoying because they cause the receiving node
> (the non-upgraded node) to close the connection with the upgraded node, which
> then has to be restablished. Although this is the normal behaviour on schema
> disagreement (see CASSANDRA-9136 for further discussion), it may be possible
> to avoid in this specific circumstance. Given that we expect the operations
> to fail until enough nodes are upgraded, we could defer them until we're sure
> they can succeed by checking the messaging service version of peers.
> Right now these are a one shot thing, each node only makes one attempt at the
> conversion (until it is restarted). Without investigating further, I don't
> know if we'd need to add in retries in case it takes a little time for each
> peer's MS version to be updated as they're upgraded. The setup & conversion
> operations are idempotent, so there shouldn't be a great issue if several
> nodes attempt them at the same time anyway.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
