Re: [Discussion] Windows support

2020-07-30 Thread Yuki Morishita 
Thank you all for your insights!

I will create the new thread to kick off the formal voting process for
removing windows support starting from 4.0.

Regards,
Yuki

On Fri, Jul 31, 2020 at 10:42 AM Erick Ramirez
 wrote:
>
> >
> > My point is, for educational purposes there are plenty of other ways of
> > running small dev clusters that are probably more realistic for most uses
> > cases.
> > I’d be for removing windows support, but I suspect my use case is one of
> > the more minor ones.
> >
>
> Not minor at all. Thanks for that insight, Andy.
>
> I field a lot of questions daily from Windows users and it's a huge drain
> because I mostly work/build/test on Ubuntu. I have a Windows 10 Surface and
> I can say that I waste so much time trying to replicate what mistake users
> made on their PCs so I can help them get past it. But most of the work ends
> up being spent on troubleshooting their PCs and not C* so I'm all for
> dropping it since it causes too much friction with user adoption. Cheers!

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [Discussion] Windows support

2020-07-30 Thread Erick Ramirez 
>
> My point is, for educational purposes there are plenty of other ways of
> running small dev clusters that are probably more realistic for most uses
> cases.
> I’d be for removing windows support, but I suspect my use case is one of
> the more minor ones.
>

Not minor at all. Thanks for that insight, Andy.

I field a lot of questions daily from Windows users and it's a huge drain
because I mostly work/build/test on Ubuntu. I have a Windows 10 Surface and
I can say that I waste so much time trying to replicate what mistake users
made on their PCs so I can help them get past it. But most of the work ends
up being spent on troubleshooting their PCs and not C* so I'm all for
dropping it since it causes too much friction with user adoption. Cheers!

Re: [DISCUSSION] Workshop idea

2020-07-30 Thread Patrick McFadin 
The developer relations team at DataStax has a pretty cool workshop setup
going with Twitch and YouTube we could volunteer for this effort. I think a
4.0 workshop with Ekaterina and Carlos would be amazing! You just need
Skype and some content and we can handle the rest.

Patrick

On Wed, Jul 29, 2020 at 4:36 PM Ekaterina Dimitrova 
wrote:

> +1 on this; would be great to make a demo to show our users the upgrade
> process, I think
>
> On Tue, 28 Jul 2020 at 13:54, Carlos Rolo  wrote:
>
> > I would love this idea!
> > I'm currently working on upgrading cluster to 4.0 (testing) and if
> needed I
> > can talk about that.
> >
> > [image: Pythian]
> > *Carlos Rolo* | Big Data Consultant | [image: LinkedIn]
> > 
> > *m* +351 918 918 100
> > r...@pythian.com   *www.pythian.com*
> > <
> >
> https://www.google.com/url?q=https%3A%2F%2Fwww.pythian.com=D=1=AFQjCNHhR4YJfBb19QxglicHut6aTAjXyQ
> > >
> > [image: Pythian]
> > <
> >
> https://www.google.com/url?q=https%3A%2F%2Fwww.pythian.com%2Femail-footer-click=D=1=AFQjCNF7Ld7zJGpBUtvj3Lum--bqwUvvog
> > >
> >
> >
> > On Tue, Jul 28, 2020 at 5:36 PM Charles Cao 
> wrote:
> >
> > > +1. Great idea. A virtual meetup, Introduction to Cassandra 4.0, will
> > > help users try and test 4.0.
> > >
> > > ~Charles
> > >
> > > On Tue, Jul 28, 2020 at 9:26 AM Ekaterina Dimitrova
> > >  wrote:
> > > >
> > > > Hi Nate, all,
> > > > I was thinking about a 1 hour online talk on 4.0, new features,
> > testing,
> > > etc. I guess it can be also recorded and distributed for those who
> missed
> > > the live session. Slides also could be added to slide share.
> > > > As you mentioned demos, that sounds good to me if people have the
> time
> > > for demos to be recorded and distributed.
> > > >
> > > > Best regards,
> > > > Ekaterina
> > > >
> > > > > On 27 Jul 2020, at 21:29, Nate McCall  wrote:
> > > > >
> > > > > This is a really interesting idea, particularly given that at this
> > > point in
> > > > > our release cycle previously, there would be demos/roadshows
> > happening
> > > at
> > > > > meetups etc. that we just cant do these days in most places now.
> > > > >
> > > > > What is your thinking on format?
> > > > >
> > > > > +1 in general though - that goes for anybody that wants to do
> > something
> > > > > like this.
> > > > >
> > > > >
> > > > >
> > > > > On Tue, Jul 28, 2020 at 12:21 PM Ekaterina Dimitrova <
> > > e.dimitr...@gmail.com>
> > > > > wrote:
> > > > >
> > > > >> Hello everyone,
> > > > >> I hope everyone is doing well in these weird pandemic times.
> > > > >>
> > > > >> I am super excited to see people already testing 4.0 Beta and
> coming
> > > back
> > > > >> with feedback. To me the user experience is one of the most
> > important
> > > > >> factors for a successful release.
> > > > >> While talking about ApacheCon™ last week, an idea was born. How
> does
> > > the
> > > > >> community feel about having a workshop on Cassandra 4.0 in August?
> > > > >> Why do I find this idea great?
> > > > >> 1) Let’s keep the momentum going and try to get the attention of
> > even
> > > more
> > > > >> users to start testing.
> > > > >> 2) ApacheCon™ is only at the end of September, so we can also use
> > the
> > > > >> opportunity to heat up before the conference.
> > > > >> There is no plan or anything at this point. Just an idea was born
> > and
> > > I am
> > > > >> excited to share it with all of you and get some
> > > > >> feedback/suggestions/criticism.
> > > > >> How does the rest of you feel about it?
> > > > >> Looking forward to hearing from you.
> > > > >> Best regards,
> > > > >> Ekaterina
> > > > >>
> > -
> > > > >> 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
> > > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> > >
> >
> > --
> >
> >
> > --
> >
> >
> >
> >
> >
> >
>

Re: [Discussion] Windows support

2020-07-30 Thread Jeff Jirsa 




> On Jul 30, 2020, at 8:08 AM, Andrew Cobley (Staff)  
> wrote:
> 
> Apologies, I have not been involved in this process for a few years, but I 
> saw this topic pass by and thought I would like to comment.
> 
> I’m a lecturer in computer science and used C* in a couple of dev classes, 
> some of you may remember we ran a couple of Hackday’s with Datastax.  
> Students would develop projects using C* in order to learn NoSQL databases.  
> Many had to run on their own laptops and usually under windows, which was a 
> pain.
> 
> I’ve since moved to using C* under Docker on Gcloud for teaching which 
> removes most of the pain, once students  get used to using cloud services.
> 
> My point is, for educational purposes there are plenty of other ways of 
> running small dev clusters that are probably more realistic for most uses 
> cases.
> 
> I’d be for removing windows support, but I suspect my use case is one of the 
> more minor ones.

I think hearing “we used to use this but now there are better alternatives” is 
great signal 
-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [Discussion] Windows support

2020-07-30 Thread João Reis 
> I agree, let's remove it.  We've had a history of "windows champions"
> (oh, hi Josh) and I don't see a clear one here, nor do I think that's
> a good methodology to promote in the long term (and history shows
> this, too.)  Clearly, 90+% of C* actual usage is on a unix-like
> system, so this is an outlier to support when other avenues are
> available on that platform like WSL.

+1. My use case is a minor one and if the removal of Windows support
leads to a significant improvement of the project's velocity (and
overall quality) then let's drop it and improve our docs to show users
how they can easily get started on WSL/Docker.

Brandon Williams  escreveu no dia quinta, 30/07/2020
à(s) 16:14:
>
> On Thu, Jul 30, 2020 at 9:57 AM Joshua McKenzie  wrote:
> >
> > >
> > > I think that not supporting Windows for local dev environments would make
> > > it harder for developers to get started with Apache Cassandra
> > >
> > I was the one that got Windows fully supported in 2014/2015 for context.
> >
> > I say we pull support out. The way NTFS treats hard links (i.e. inability
> > to delete junctions if someone has a handle open to them even w/the right
> > flags if the file is memory mapped) is just a major headache in terms of
> > the way C*'s file I/O operates.
>
> I agree, let's remove it.  We've had a history of "windows champions"
> (oh, hi Josh) and I don't see a clear one here, nor do I think that's
> a good methodology to promote in the long term (and history shows
> this, too.)  Clearly, 90+% of C* actual usage is on a unix-like
> system, so this is an outlier to support when other avenues are
> available on that platform like WSL.
>
> -
> 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

Re: [Discussion] Windows support

2020-07-30 Thread Brandon Williams 
On Thu, Jul 30, 2020 at 9:57 AM Joshua McKenzie  wrote:
>
> >
> > I think that not supporting Windows for local dev environments would make
> > it harder for developers to get started with Apache Cassandra
> >
> I was the one that got Windows fully supported in 2014/2015 for context.
>
> I say we pull support out. The way NTFS treats hard links (i.e. inability
> to delete junctions if someone has a handle open to them even w/the right
> flags if the file is memory mapped) is just a major headache in terms of
> the way C*'s file I/O operates.

I agree, let's remove it.  We've had a history of "windows champions"
(oh, hi Josh) and I don't see a clear one here, nor do I think that's
a good methodology to promote in the long term (and history shows
this, too.)  Clearly, 90+% of C* actual usage is on a unix-like
system, so this is an outlier to support when other avenues are
available on that platform like WSL.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [Discussion] Windows support

2020-07-30 Thread Andrew Cobley (Staff) 
Apologies, I have not been involved in this process for a few years, but I saw 
this topic pass by and thought I would like to comment.

I’m a lecturer in computer science and used C* in a couple of dev classes, some 
of you may remember we ran a couple of Hackday’s with Datastax.  Students would 
develop projects using C* in order to learn NoSQL databases.  Many had to run 
on their own laptops and usually under windows, which was a pain.

I’ve since moved to using C* under Docker on Gcloud for teaching which removes 
most of the pain, once students  get used to using cloud services.

My point is, for educational purposes there are plenty of other ways of running 
small dev clusters that are probably more realistic for most uses cases.

I’d be for removing windows support, but I suspect my use case is one of the 
more minor ones.

Andy


From: Joshua McKenzie 
Date: Thursday, 30 July 2020 at 15:56
To: dev@cassandra.apache.org 
Subject: Re: [Discussion] Windows support
>
> I think that not supporting Windows for local dev environments would make
> it harder for developers to get started with Apache Cassandra
>
I was the one that got Windows fully supported in 2014/2015 for context.

I say we pull support out. The way NTFS treats hard links (i.e. inability
to delete junctions if someone has a handle open to them even w/the right
flags if the file is memory mapped) is just a major headache in terms of
the way C*'s file I/O operates. It leads to a large number of edge cases
and quirks in the way things operate on Windows that largely manifest as a
support burden for the project community when there's a clearly superior
dev alternative available in WSL. The "we'll keep a list of files that got
locked and delete them on next startup" plus the complete necessary
disabling of early open are two major things I'm wary of in terms of doing
development work on C* and having faith that the behavioral characteristics
will translate cleanly to a linux env. I also would not advise running C*
on a production environment on Windows Server at this point; Microsoft's
strategic embrace of linux makes the need for that support basically
vestigial.

I've been on WSL since 1.0 fwiw and 2.0 only improves on that experience.

So my point of view: doing dev on Windows w/the plethora of I/O based edge
cases today is a worse user experience than having a very smooth "here's
how to get started with WSL" on-ramp for users. The former consigns them to
a never-ending risk of disruption and disjoint from deployment env, while
the latter is one up-front fixed cost to have pain-free development going
forward. DataStax Desktop also makes that even easier fwiw, but I'd
advocate for us just improving our docs and having a "Developing on
Windows? Here's how to set up WSL" w/screenshots and an easy "get started
in < 5 minutes" guide.

On Wed, Jul 29, 2020 at 11:49 AM João Reis  wrote:

> Personally I still use CCM on windows pretty often and the C# driver even
> has an appveyor job that runs tests with CCM on windows (the drivers smoke
> tests job does this as well). Setting up clusters with multiple nodes is
> not that easy with Docker and WSL 2 because the nodes run inside a VM.
>
> In regards to WSL2, Microsoft has been improving the user experience for
> these use cases so I'm not sure how easy it is to set up these clusters
> with recent windows builds. WSL1 does not run inside a VM so there's no
> issues there.
>
> I think that not supporting Windows for local dev environments would make
> it harder for developers to get started with Apache Cassandra but if the
> community decides to completely drop Windows support then we should offer
> some kind of documentation on how to run Cassandra with WSL / Docker on
> Windows (currently there's no documentation for Windows users AFAIK).
>
> Yuki Morishita  escreveu no dia quarta, 29/07/2020 à(s)
> 02:40:
>
> > Hi,
> >
> > I'd like to raise my concern about Windows support, as we are getting
> > closer to 4.0 release.
> >
> > Since the support for JDK11 (CASSANDRA-9608), Windows script to start
> > Cassandra is broken.
> > The fix for the script is posted to
> > https://issues.apache.org/jira/projects/CASSANDRA/issues/CASSANDRA-14608
> .
> >
> > Windows scripts are not maintained recently, and I don't think we have
> > any Windows environment in CI for testing.
> > I don't think it is a good idea to release Apache Cassandra with
> > broken Windows scripts.
> >
> > With the latest update of Windows 10, even the Windows 10 Home edition
> > users can use Docker for Windows if they enable WSL2 in their machine.
> > However, the update is not yet available for everyone, and I believe
> > many Enterprises hold onto upgrading to the latest version. Even if
> > they do so, they can disable WSL2 from using. Some companies may not
> > allow installing VirtualBox either.
> >
> > So, what we can do for 4.0 release:
> >
> > - Stop supporting Windows. Remove every bat/ps1 scripts from the
> > source and

Re: [Discussion] Windows support

2020-07-30 Thread Joshua McKenzie 
>
> I think that not supporting Windows for local dev environments would make
> it harder for developers to get started with Apache Cassandra
>
I was the one that got Windows fully supported in 2014/2015 for context.

I say we pull support out. The way NTFS treats hard links (i.e. inability
to delete junctions if someone has a handle open to them even w/the right
flags if the file is memory mapped) is just a major headache in terms of
the way C*'s file I/O operates. It leads to a large number of edge cases
and quirks in the way things operate on Windows that largely manifest as a
support burden for the project community when there's a clearly superior
dev alternative available in WSL. The "we'll keep a list of files that got
locked and delete them on next startup" plus the complete necessary
disabling of early open are two major things I'm wary of in terms of doing
development work on C* and having faith that the behavioral characteristics
will translate cleanly to a linux env. I also would not advise running C*
on a production environment on Windows Server at this point; Microsoft's
strategic embrace of linux makes the need for that support basically
vestigial.

I've been on WSL since 1.0 fwiw and 2.0 only improves on that experience.

So my point of view: doing dev on Windows w/the plethora of I/O based edge
cases today is a worse user experience than having a very smooth "here's
how to get started with WSL" on-ramp for users. The former consigns them to
a never-ending risk of disruption and disjoint from deployment env, while
the latter is one up-front fixed cost to have pain-free development going
forward. DataStax Desktop also makes that even easier fwiw, but I'd
advocate for us just improving our docs and having a "Developing on
Windows? Here's how to set up WSL" w/screenshots and an easy "get started
in < 5 minutes" guide.

On Wed, Jul 29, 2020 at 11:49 AM João Reis  wrote:

> Personally I still use CCM on windows pretty often and the C# driver even
> has an appveyor job that runs tests with CCM on windows (the drivers smoke
> tests job does this as well). Setting up clusters with multiple nodes is
> not that easy with Docker and WSL 2 because the nodes run inside a VM.
>
> In regards to WSL2, Microsoft has been improving the user experience for
> these use cases so I'm not sure how easy it is to set up these clusters
> with recent windows builds. WSL1 does not run inside a VM so there's no
> issues there.
>
> I think that not supporting Windows for local dev environments would make
> it harder for developers to get started with Apache Cassandra but if the
> community decides to completely drop Windows support then we should offer
> some kind of documentation on how to run Cassandra with WSL / Docker on
> Windows (currently there's no documentation for Windows users AFAIK).
>
> Yuki Morishita  escreveu no dia quarta, 29/07/2020 à(s)
> 02:40:
>
> > Hi,
> >
> > I'd like to raise my concern about Windows support, as we are getting
> > closer to 4.0 release.
> >
> > Since the support for JDK11 (CASSANDRA-9608), Windows script to start
> > Cassandra is broken.
> > The fix for the script is posted to
> > https://issues.apache.org/jira/projects/CASSANDRA/issues/CASSANDRA-14608
> .
> >
> > Windows scripts are not maintained recently, and I don't think we have
> > any Windows environment in CI for testing.
> > I don't think it is a good idea to release Apache Cassandra with
> > broken Windows scripts.
> >
> > With the latest update of Windows 10, even the Windows 10 Home edition
> > users can use Docker for Windows if they enable WSL2 in their machine.
> > However, the update is not yet available for everyone, and I believe
> > many Enterprises hold onto upgrading to the latest version. Even if
> > they do so, they can disable WSL2 from using. Some companies may not
> > allow installing VirtualBox either.
> >
> > So, what we can do for 4.0 release:
> >
> > - Stop supporting Windows. Remove every bat/ps1 scripts from the
> > source and distribution. Encourage Windows users to use VM/Docker.
> > - Continue supporting Windows. Set up Windows test environment. Test
> > every Windows scripts for future releases.
> >
> > Since I saw enterprises with restricted dev environments (and saw
> > people trying to use cassandra on Windows on StackOverflow), I want to
> > have Windows scripts ready to be used.
> > But I'm also fine if we decide to remove all Windows scripts since I
> > use Docker anyway.
> >
> > Regards,
> > Yuki
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>