> it's not > reasonable to expect Scylla to contribute > such a huge effort to the C* server
But it's reasonable that a major portion of Scylla's business model is profiting off those huge efforts other companies have made? Seems a little hypocritical to me. On Mon, Apr 23, 2018, 8:18 PM Dor Laor <d...@scylladb.com> wrote: > On Mon, Apr 23, 2018 at 5:03 PM, Sankalp Kohli <kohlisank...@gmail.com> > wrote: > > > Is one of the “abuse” of Apache license is ScyllaDB which is using > > Cassandra but not contributing back? > > > > It's not that we have a private version of Cassandra and we don't release > all of it or some of it back.. > > We didn't contribute because we have a different server base. We always > contribute where it makes sense. > I'll be happy to have several beers or emails about the cons and pros of > open source licensing but I don't think > this is the case. The discussion is about whether the community wish to > accept our contributions, we initiated it, > didn't we? > > Let's be practical, I think it's not reasonable to commit C* protocol > changes that the community doesn't intend > to implement in C* in the short term (thread-per-core like), it's not > reasonable to expect Scylla to contribute > such a huge effort to the C* server. It is reasonable to collaborate around > protocol enhancements that are acceptable, > even without coding and make sure the protocol is enhanceable in a way that > forward compatible. > > > Happy to be proved wrong as I am not a lawyer and don’t understand various > > licenses .. > > > > > On Apr 23, 2018, at 16:55, Dor Laor <d...@scylladb.com> wrote: > > > > > >> On Mon, Apr 23, 2018 at 4:13 PM, Jonathan Haddad <j...@jonhaddad.com> > > wrote: > > >> > > >> From where I stand it looks like you've got only two options for any > > >> feature that involves updating the protocol: > > >> > > >> 1. Don't built the feature > > >> 2. Built it in Cassanda & scylladb, update the drivers accordingly > > >> > > >> I don't think you have a third option, which is built it only in > > ScyllaDB, > > >> because that means you have to fork *all* the drivers and make it > work, > > >> then maintain them. Your business model appears to be built on not > > doing > > >> any of the driver work yourself, and you certainly aren't giving back > to > > >> the open source community via a permissive license on ScyllaDB itself, > > so > > >> I'm a bit lost here. > > >> > > > > > > It's totally not about business model. > > > Scylla itself is 99% open source with AGPL license that prevents abuse > > and > > > forces to be committed back to the project. We also have our core > engine > > > (seastar) licensed > > > as Apache since it needs to be integrated with the core application. > > > Recently one of our community members even created a new Seastar based, > > C++ > > > driver. > > > > > > Scylla chose to be compatible with the drivers in order to leverage the > > > existing infrastructure > > > and (let's be frank) in order to allow smooth migration. > > > We would have loved to contribute more to the drivers but up to > recently > > we: > > > 1. Were busy on top of our heads with the server > > > 2. Happy w/ the existing drivers > > > 3. Developed extensions - GoCQLX - our own contribution > > > > > > Finally we can contribute back to the same driver project, we want to > do > > it > > > the right way, > > > without forking and without duplicated efforts. > > > > > > Many times, having a private fork is way easier than proper open source > > > work so from > > > a pure business perspective, we don't select the shortest path. > > > > > > > > >> > > >> To me it looks like you're asking a bunch of volunteers that work on > > >> Cassandra to accommodate you. What exactly do we get out of this > > >> relationship? What incentive do I or anyone else have to spend time > > >> helping you instead of working on something that interests me? > > >> > > > > > > Jon, this is certainty not the case. > > > We genuinely wish to make true *open source* work on: > > > a. Cassandra drivers > > > b. Client protocol > > > c. Scylla server side. > > > d. Cassandra community related work: mailing list, Jira, design > > > > > > But not > > > e. Cassandra server side > > > > > > While I wouldn't mind doing the Cassandra server work, we don't have > the > > > resources or > > > the expertise. The Cassandra _developer_ community is welcome to decide > > > whether > > > we get to contribute a/b/c/d. Avi has enumerated the options of > > > cooperation, passive cooperation > > > and zero cooperation (below). > > > > > > 1. The protocol change is developed using the Cassandra process in a > JIRA > > > ticket, culminating in a patch to doc/native_protocol*.spec when > > consensus > > > is achieved. > > > 2. The protocol change is developed outside the Cassandra process. > > > 3. No cooperation. > > > > > > Look, I can understand the hostility and suspicious, however, from the > C* > > > project POV, it makes no > > > sense to ignore, otherwise we'll fork the drivers and you won't get > > > anything back. There is another > > > at least one vendor today with their server fork and driver fork and it > > > makes sense to keep the protocol > > > unified in an extensible way and to discuss new features _together_. > > > > > > > > > > > >> > > >> Jon > > >> > > >> > > >> On Mon, Apr 23, 2018 at 7:59 AM Ben Bromhead <b...@instaclustr.com> > > wrote: > > >> > > >>>>>> This doesn't work without additional changes, for RF>1. The token > > >> ring > > >>>> could place two replicas of the same token range on the same > physical > > >>>> server, even though those are two separate cores of the same server. > > >> You > > >>>> could add another element to the hierarchy (cluster -> datacenter -> > > >> rack > > >>>> -> node -> core/shard), but that generates unneeded range movements > > >> when > > >>> a > > >>>> node is added. > > >>>>> I have seen rack awareness used/abused to solve this. > > >>>>> > > >>>> > > >>>> But then you lose real rack awareness. It's fine for a quick hack, > but > > >>>> not a long-term solution. > > >>>> > > >>>> (it also creates a lot more tokens, something nobody needs) > > >>>> > > >>> > > >>> I'm having trouble understanding how you loose "real" rack awareness, > > as > > >>> these shards are in the same rack anyway, because the address and > port > > >> are > > >>> on the same server in the same rack. So it behaves as expected. Could > > you > > >>> explain a situation where the shards on a single server would be in > > >>> different racks (or fault domains)? > > >>> > > >>> If you wanted to support a situation where you have a single rack per > > DC > > >>> for simple deployments, extending NetworkTopologyStrategy to behave > the > > >> way > > >>> it did before > https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_CASSANDRA-2D7544&d=DwIFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=qK2RkRAsGtixYf0IgKlRBYLfTrXyOKED9OOTyMVvDf4&m=-KTfwBfQviFYMIYG-0-uLvTOWvudhHfm3Nlwkd1iLck&s=01FsBvCihZndkHTmett65RHyy-gs8IQENF-wXOTdbD0&e= > > with > > >>> respect to treating InetAddresses as servers rather than the address > > and > > >>> port would be simple. Both this implementation in Apache Cassandra > and > > >> the > > >>> respective load balancing classes in the drivers are explicitly > > designed > > >> to > > >>> be pluggable so that would be an easier integration point for you. > > >>> > > >>> I'm not sure how it creates more tokens? If a server normally owns > 256 > > >>> tokens, each shard on a different port would just advertise ownership > > of > > >>> 256/# of cores (e.g. 4 tokens if you had 64 cores). > > >>> > > >>> > > >>>> > > >>>>> Regards, > > >>>>> Ariel > > >>>>> > > >>>>>> On Apr 22, 2018, at 8:26 AM, Avi Kivity <a...@scylladb.com> wrote: > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>> On 2018-04-19 21:15, Ben Bromhead wrote: > > >>>>>>> Re #3: > > >>>>>>> > > >>>>>>> Yup I was thinking each shard/port would appear as a discrete > > >> server > > >>>> to the > > >>>>>>> client. > > >>>>>> This doesn't work without additional changes, for RF>1. The token > > >> ring > > >>>> could place two replicas of the same token range on the same > physical > > >>>> server, even though those are two separate cores of the same server. > > >> You > > >>>> could add another element to the hierarchy (cluster -> datacenter -> > > >> rack > > >>>> -> node -> core/shard), but that generates unneeded range movements > > >> when > > >>> a > > >>>> node is added. > > >>>>>> > > >>>>>>> If the per port suggestion is unacceptable due to hardware > > >>>> requirements, > > >>>>>>> remembering that Cassandra is built with the concept scaling > > >>>> *commodity* > > >>>>>>> hardware horizontally, you'll have to spend your time and energy > > >>>> convincing > > >>>>>>> the community to support a protocol feature it has no (current) > use > > >>>> for or > > >>>>>>> find another interim solution. > > >>>>>> Those servers are commodity servers (not x86, but still > commodity). > > >> In > > >>>> any case 60+ logical cores are common now (hello AWS i3.16xlarge or > > >> even > > >>>> i3.metal), and we can only expect logical core count to continue to > > >>>> increase (there are 48-core ARM processors now). > > >>>>>> > > >>>>>>> Another way, would be to build support and consensus around a > clear > > >>>>>>> technical need in the Apache Cassandra project as it stands > today. > > >>>>>>> > > >>>>>>> One way to build community support might be to contribute an > Apache > > >>>>>>> licensed thread per core implementation in Java that matches the > > >>>> protocol > > >>>>>>> change and shard concept you are looking for ;P > > >>>>>> I doubt I'll survive the egregious top-posting that is going on in > > >>> this > > >>>> list. > > >>>>>> > > >>>>>>> > > >>>>>>>> On Thu, Apr 19, 2018 at 1:43 PM Ariel Weisberg < > ar...@weisberg.ws > > >>> > > >>>> wrote: > > >>>>>>>> > > >>>>>>>> Hi, > > >>>>>>>> > > >>>>>>>> So at technical level I don't understand this yet. > > >>>>>>>> > > >>>>>>>> So you have a database consisting of single threaded shards and > a > > >>>> socket > > >>>>>>>> for accept that is generating TCP connections and in advance you > > >>>> don't know > > >>>>>>>> which connection is going to send messages to which shard. > > >>>>>>>> > > >>>>>>>> What is the mechanism by which you get the packets for a given > TCP > > >>>>>>>> connection delivered to a specific core? I know that a given TCP > > >>>> connection > > >>>>>>>> will normally have all of its packets delivered to the same > queue > > >>>> from the > > >>>>>>>> NIC because the tuple of source address + port and destination > > >>>> address + > > >>>>>>>> port is typically hashed to pick one of the queues the NIC > > >>> presents. I > > >>>>>>>> might have the contents of the tuple slightly wrong, but it > always > > >>>> includes > > >>>>>>>> a component you don't get to control. > > >>>>>>>> > > >>>>>>>> Since it's hashing how do you manipulate which queue packets > for a > > >>> TCP > > >>>>>>>> connection go to and how is it made worse by having an accept > > >> socket > > >>>> per > > >>>>>>>> shard? > > >>>>>>>> > > >>>>>>>> You also mention 160 ports as bad, but it doesn't sound like a > big > > >>>> number > > >>>>>>>> resource wise. Is it an operational headache? > > >>>>>>>> > > >>>>>>>> RE tokens distributed amongst shards. The way that would work > > >> right > > >>>> now is > > >>>>>>>> that each port number appears to be a discrete instance of the > > >>>> server. So > > >>>>>>>> you could have shards be actual shards that are simply colocated > > >> on > > >>>> the > > >>>>>>>> same box, run in the same process, and share resources. I know > > >> this > > >>>> pushes > > >>>>>>>> more of the complexity into the server vs the driver as the > server > > >>>> expects > > >>>>>>>> all shards to share some client visible like system tables and > > >>> certain > > >>>>>>>> identifiers. > > >>>>>>>> > > >>>>>>>> Ariel > > >>>>>>>>> On Thu, Apr 19, 2018, at 12:59 PM, Avi Kivity wrote: > > >>>>>>>>> Port-per-shard is likely the easiest option but it's too ugly > to > > >>>>>>>>> contemplate. We run on machines with 160 shards (IBM POWER > > >>> 2s20c160t > > >>>>>>>>> IIRC), it will be just horrible to have 160 open ports. > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> It also doesn't fit will with the NICs ability to automatically > > >>>>>>>>> distribute packets among cores using multiple queues, so the > > >> kernel > > >>>>>>>>> would have to shuffle those packets around. Much better to have > > >>> those > > >>>>>>>>> packets delivered directly to the core that will service them. > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> (also, some protocol changes are needed so the driver knows how > > >>>> tokens > > >>>>>>>>> are distributed among shards) > > >>>>>>>>> > > >>>>>>>>>> On 2018-04-19 19:46, Ben Bromhead wrote: > > >>>>>>>>>> WRT to #3 > > >>>>>>>>>> To fit in the existing protocol, could you have each shard > > >> listen > > >>>> on a > > >>>>>>>>>> different port? Drivers are likely going to support this due > to > > >>>>>>>>>> > https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_CASSANDRA-2D7544&d=DwIFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=qK2RkRAsGtixYf0IgKlRBYLfTrXyOKED9OOTyMVvDf4&m=-KTfwBfQviFYMIYG-0-uLvTOWvudhHfm3Nlwkd1iLck&s=01FsBvCihZndkHTmett65RHyy-gs8IQENF-wXOTdbD0&e= > ( > > >>>>>>>>>> > https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_CASSANDRA-2D11596&d=DwIFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=qK2RkRAsGtixYf0IgKlRBYLfTrXyOKED9OOTyMVvDf4&m=-KTfwBfQviFYMIYG-0-uLvTOWvudhHfm3Nlwkd1iLck&s=RggcL9lWBe5uDAPbMWW4S_7-ZzYVctqUA5W6GYSwBm4&e=). > I'm > > >> not > > >>>> super > > >>>>>>>>>> familiar with the ticket so their might be something I'm > missing > > >>>> but it > > >>>>>>>>>> sounds like a potential approach. > > >>>>>>>>>> > > >>>>>>>>>> This would give you a path forward at least for the short > term. > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> On Thu, Apr 19, 2018 at 12:10 PM Ariel Weisberg < > > >>> ar...@weisberg.ws> > > >>>>>>>> wrote: > > >>>>>>>>>>> Hi, > > >>>>>>>>>>> > > >>>>>>>>>>> I think that updating the protocol spec to Cassandra puts the > > >>> onus > > >>>> on > > >>>>>>>> the > > >>>>>>>>>>> party changing the protocol specification to have an > > >>> implementation > > >>>>>>>> of the > > >>>>>>>>>>> spec in Cassandra as well as the Java and Python driver > (those > > >>> are > > >>>>>>>> both > > >>>>>>>>>>> used in the Cassandra repo). Until it's implemented in > > >> Cassandra > > >>> we > > >>>>>>>> haven't > > >>>>>>>>>>> fully evaluated the specification change. There is no > > >> substitute > > >>>> for > > >>>>>>>> trying > > >>>>>>>>>>> to make it work. > > >>>>>>>>>>> > > >>>>>>>>>>> There are also realities to consider as to what the > maintainers > > >>> of > > >>>> the > > >>>>>>>>>>> drivers are willing to commit. > > >>>>>>>>>>> > > >>>>>>>>>>> RE #1, > > >>>>>>>>>>> > > >>>>>>>>>>> I am +1 on the fact that we shouldn't require an extra hop > for > > >>>> range > > >>>>>>>> scans. > > >>>>>>>>>>> In JIRA Jeremiah made the point that you can still do this > from > > >>> the > > >>>>>>>> client > > >>>>>>>>>>> by breaking up the token ranges, but it's a leaky abstraction > > >> to > > >>>> have > > >>>>>>>> a > > >>>>>>>>>>> paging interface that isn't a vanilla ResultSet interface. > > >> Serial > > >>>> vs. > > >>>>>>>>>>> parallel is kind of orthogonal as the driver can do either. > > >>>>>>>>>>> > > >>>>>>>>>>> I agree it looks like the current specification doesn't make > > >> what > > >>>>>>>> should > > >>>>>>>>>>> be simple as simple as it could be for driver implementers. > > >>>>>>>>>>> > > >>>>>>>>>>> RE #2, > > >>>>>>>>>>> > > >>>>>>>>>>> +1 on this change assuming an implementation in Cassandra and > > >> the > > >>>>>>>> Java and > > >>>>>>>>>>> Python drivers. > > >>>>>>>>>>> > > >>>>>>>>>>> RE #3, > > >>>>>>>>>>> > > >>>>>>>>>>> It's hard to be +1 on this because we don't benefit by boxing > > >>>>>>>> ourselves in > > >>>>>>>>>>> by defining a spec we haven't implemented, tested, and > decided > > >> we > > >>>> are > > >>>>>>>>>>> satisfied with. Having it in ScyllaDB de-risks it to a > certain > > >>>>>>>> extent, but > > >>>>>>>>>>> what if Cassandra decides to go a different direction in some > > >>> way? > > >>>>>>>>>>> > > >>>>>>>>>>> I don't think there is much discussion to be had without an > > >>> example > > >>>>>>>> of the > > >>>>>>>>>>> the changes to the CQL specification to look at, but even > then > > >> if > > >>>> it > > >>>>>>>> looks > > >>>>>>>>>>> risky I am not likely to be in favor of it. > > >>>>>>>>>>> > > >>>>>>>>>>> Regards, > > >>>>>>>>>>> Ariel > > >>>>>>>>>>> > > >>>>>>>>>>>> On Thu, Apr 19, 2018, at 9:33 AM, glom...@scylladb.com > wrote: > > >>>>>>>>>>>> On 2018/04/19 07:19:27, kurt greaves <k...@instaclustr.com> > > >>>> wrote: > > >>>>>>>>>>>>>> 1. The protocol change is developed using the Cassandra > > >>> process > > >>>> in > > >>>>>>>>>>>>>> a JIRA ticket, culminating in a patch to > > >>>>>>>>>>>>>> doc/native_protocol*.spec when consensus is achieved. > > >>>>>>>>>>>>> I don't think forking would be desirable (for anyone) so > this > > >>>> seems > > >>>>>>>>>>>>> the most reasonable to me. For 1 and 2 it certainly makes > > >> sense > > >>>> but > > >>>>>>>>>>>>> can't say I know enough about sharding to comment on 3 - > > >> seems > > >>>> to me > > >>>>>>>>>>>>> like it could be locking in a design before anyone truly > > >> knows > > >>>> what > > >>>>>>>>>>>>> sharding in C* looks like. But hopefully I'm wrong and > there > > >>> are > > >>>>>>>>>>>>> devs out there that have already thought that through. > > >>>>>>>>>>>> Thanks. That is our view and is great to hear. > > >>>>>>>>>>>> > > >>>>>>>>>>>> About our proposal number 3: In my view, good protocol > designs > > >>> are > > >>>>>>>>>>>> future proof and flexible. We certainly don't want to > propose > > >> a > > >>>>>>>> design > > >>>>>>>>>>>> that works just for Scylla, but would support reasonable > > >>>>>>>>>>>> implementations regardless of how they may look like. > > >>>>>>>>>>>> > > >>>>>>>>>>>>> Do we have driver authors who wish to support both > projects? > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> Surely, but I imagine it would be a minority. > > >>>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>> > --------------------------------------------------------------------- > > >>>>>>>>>>>> To unsubscribe, e-mail: > dev-unsubscr...@cassandra.apache.org > > >>> For > > >>>>>>>>>>>> additional commands, e-mail: dev-h...@cassandra.apache.org > > >>>>>>>>>>>> > > >>>>>>>>>>> > > >>>> > --------------------------------------------------------------------- > > >>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > >>>>>>>>>>> For additional commands, e-mail: > dev-h...@cassandra.apache.org > > >>>>>>>>>>> > > >>>>>>>>>>> -- > > >>>>>>>>>> Ben Bromhead > > >>>>>>>>>> CTO | Instaclustr < > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.instaclustr.com_&d=DwIFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=qK2RkRAsGtixYf0IgKlRBYLfTrXyOKED9OOTyMVvDf4&m=-KTfwBfQviFYMIYG-0-uLvTOWvudhHfm3Nlwkd1iLck&s=fmbcKjLNXdZWdw_-IczFSSyqkEQqOAjnyZBgb4iUeug&e= > > > > >>>>>>>>>> +1 650 284 9692 <(650)%20284-9692> <(650)%20284-9692> > > >>> <(650)%20284-9692> > > >>>>>>>>>> Reliability at Scale > > >>>>>>>>>> Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and > Softlayer > > >>>>>>>>>> > > >>>>>>>>> > > >>> --------------------------------------------------------------------- > > >>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > >>>>>>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org > > >>>>>>>>> > > >>>>>>>> > > >>> --------------------------------------------------------------------- > > >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > >>>>>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org > > >>>>>>>> > > >>>>>>>> -- > > >>>>>>> Ben Bromhead > > >>>>>>> CTO | Instaclustr < > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.instaclustr.com_&d=DwIFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=qK2RkRAsGtixYf0IgKlRBYLfTrXyOKED9OOTyMVvDf4&m=-KTfwBfQviFYMIYG-0-uLvTOWvudhHfm3Nlwkd1iLck&s=fmbcKjLNXdZWdw_-IczFSSyqkEQqOAjnyZBgb4iUeug&e= > > > > >>>>>>> +1 650 284 9692 <(650)%20284-9692> <(650)%20284-9692> > > >>>>>>> Reliability at Scale > > >>>>>>> Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer > > >>>>>>> > > >>>>>> > > >>>>>> ------------------------------------------------------------ > > >> --------- > > >>>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > >>>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org > > >>>>>> > > >>>>> > > >>>>> ------------------------------------------------------------ > > >> --------- > > >>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > >>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org > > >>>>> > > >>>> > > >>>> -- > > >>> Ben Bromhead > > >>> CTO | Instaclustr < > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.instaclustr.com_&d=DwIFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=qK2RkRAsGtixYf0IgKlRBYLfTrXyOKED9OOTyMVvDf4&m=-KTfwBfQviFYMIYG-0-uLvTOWvudhHfm3Nlwkd1iLck&s=fmbcKjLNXdZWdw_-IczFSSyqkEQqOAjnyZBgb4iUeug&e= > > > > >>> +1 650 284 9692 <(650)%20284-9692> > > >>> Reliability at Scale > > >>> Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer > > >>> > > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > >
