[
https://issues.apache.org/jira/browse/CASSANDRA-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16345901#comment-16345901
]
Ariel Weisberg edited comment on CASSANDRA-7544 at 1/30/18 10:15 PM:
---------------------------------------------------------------------
bq. I see that the protocol version is incremented but there are no edits to
the native_protocol spec. Oversight?
The native protocol didn't change per se. The clients use the protocol version
to select the correct system tables when querying metadata. It's definitely
something I could include in the spec, although historically the spec is silent
WRT to the contents of Cassandra system tables.
bq. Also, is this the right place to change the default protocol? Shouldn't
that be a separate discussion?
What is the default protocol? You mean move v5 out of beta? I'm not sure how we
intended that to work. We don't have trunk releases so what is the expectation
there from the perspective of clients?
We could put it in back in beta and update the code elsewhere that relies on
the beta functionality to be correct to use the beta version (cqlsh,
sstableloader, maybe the hadoop stuff).
Then when we move it out of beta we have to remove the use beta flag otherwise
we will be releasing utilities that use the next beta version (v6) of the
protocol. Seems a bit like the tail wagging the dog, but then end result is
similar.
was (Author: aweisberg):
bq. I see that the protocol version is incremented but there are no edits to
the native_protocol spec. Oversight?
The native protocol didn't change per se. The clients use the protocol version
to select the correct system tables when querying metadata. It's definitely
something I could include in the spec, although historically the spec is
incomplete WRT to the contents of Cassandra system tables.
bq. Also, is this the right place to change the default protocol? Shouldn't
that be a separate discussion?
What is the default protocol? You mean move v5 out of beta? I'm not sure how we
intended that to work. We don't have trunk releases so what is the expectation
there from the perspective of clients?
We could put it in back in beta and update the code elsewhere that relies on
the beta functionality to be correct to use the beta version (cqlsh,
sstableloader, maybe the hadoop stuff).
Then when we move it out of beta we have to remove the use beta flag otherwise
we will be releasing utilities that use the next beta version (v6) of the
protocol. Seems a bit like the tail wagging the dog, but then end result is
similar.
> Allow storage port to be configurable per node
> ----------------------------------------------
>
> Key: CASSANDRA-7544
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7544
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Sam Overton
> Assignee: Ariel Weisberg
> Priority: Major
> Fix For: 4.0
>
>
> Currently storage_port must be configured identically on all nodes in a
> cluster and it is assumed that this is the case when connecting to a remote
> node.
> This prevents running in any environment that requires multiple nodes to be
> able to bind to the same network interface, such as with many automatic
> provisioning/deployment frameworks.
> The current solutions seems to be
> * use a separate network interface for each node deployed to the same box.
> This puts a big requirement on IP allocation at large scale.
> * allow multiple clusters to be provisioned from the same resource pool, but
> restrict allocation to a maximum of one node per host from each cluster,
> assuming each cluster is running on a different storage port.
> It would make operations much simpler in these kind of environments if the
> environment provisioning the resources could assign the ports to be used when
> bringing up a new node on shared hardware.
> The changes required would be at least the following:
> 1. configure seeds as IP:port instead of just IP
> 2. gossip the storage port as part of a node's ApplicationState
> 3. refer internally to nodes by hostID instead of IP, since there will be
> multiple nodes with the same IP
> (1) & (2) are mostly trivial and I already have a patch for these. The bulk
> of the work to enable this is (3), and I would structure this as a separate
> pre-requisite patch.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
