RE: A JIRA proposing a seperate repository for the online documentation
I don't know what we are doing for the website technologies right now because like everything else what we do is not documented anywhere. Where are the servers: the cloud? What server software are we running? How is the html, etc. generated and published? How is search done for the website? Kenneth Brotman -Original Message- From: Rahul Singh [mailto:rahul.xavier.si...@gmail.com] Sent: Saturday, March 17, 2018 7:12 AM To: dev@cassandra.apache.org Subject: RE: A JIRA proposing a seperate repository for the online documentation Static site generator just takes content from flat files or apis (that can be managed from a headless cms) and creates static files or progressive web apps that are optimized for speed. Nothing to do with multi-media or dynamic in terms of client side javascript / css. It’s just an old technology with a new name. Thats how we used to generate sites back in 1990s.. :) -- Rahul Singh rahul.si...@anant.us Anant Corporation On Mar 17, 2018, 10:03 AM -0400, Kenneth Brotman , wrote: > How about if we look at the website a little differently. Isn't it an > opportunity to showcase Cassandra and related technologies like search! > Shouldn't we be an extraordinary advocate and example of the technology > ourselves? > > Rahul, your comment on the different users with different use cases was very > wise. > > I've been writing html a long time; since about 1990. You're asking me to > learn a weird little program, a static site generator just to change > something I can already do without using a program at all. > > Another weird thing: Wouldn't we want a website that is dynamic and > multi-media rich? > > Kenneth Brotman > > > -Original Message- > From: Rahul Singh [mailto:rahul.xavier.si...@gmail.com] > Sent: Saturday, March 17, 2018 5:57 AM > To: dev@cassandra.apache.org > Subject: RE: A JIRA proposing a seperate repository for the online > documentation > > I’ve previously deep dived into Static Site generators and there are numerous > ones. > > http://leaves.anant.us/#!/leaf/7255?tag=static.site > > I don’t like changing technology for the sake of change. I think it’s a > stupid waste of time. In one hand I agree, the substance is more important > than the form. On the other hand. I [insert f-bomb] hate writing HTML / CSS, > or restructured text. Markdown is much easier. Hugo is one of many that if > setup right, it can save a ton of time and make it more accessible for people > to contribute. > > There is a difference however in developer documentation for developers of > cassandra, user documentation for cassandra users, documentation for and > administrators. They are different users and have different use cases Some > need reference style docs, others need guides. > > Some good examples, (the software quality not-withstanding), correlate with > software propularity are Wordpress. I am not wild about Wordpress, but their > codex.wordpress.org has been generally a good “user doc.” > > Envision the outcome even if you have to mimic someone else. I don’t mind > stealing/copying if it gets us one step further than we are. The reaper docs > look easy to maintain and I could care less about Hugo, Hexo, Jekyll, Hyde, > KafkasMom, EinsteinsDog, ShrodingersCat static site generator. > > I think action should come before decision in open source. Prove something > before suggesting a change. Jon’s reaper example is good. If anyone has > something better, show it. Prove it. > > -- > Rahul Singh > rahul.si...@anant.us > > Anant Corporation > > On Mar 16, 2018, 6:54 PM -0400, Kenneth Brotman > , wrote: > > There is no need for another program. Keep the code in html, css and js > > People can modify that and show proposed changes in that. No need to > > convert back and forth from other formats. If someone is doing something > > more involved, they probably already have a program themselves. > > > > -Original Message- > > From: beggles...@apple.com [mailto:beggles...@apple.com] > > Sent: Friday, March 16, 2018 3:16 PM > > To: dev@cassandra.apache.org > > Subject: Re: A JIRA proposing a seperate repository for the online > > documentation > > > > It would probably be more productive to list some specific concerns you > > have with Hugo. Then explain why you think they make using it a bad idea > > Then offer some alternatives. > > > > On 3/16/18, 1:18 PM, "Kenneth Brotman" wrote: > > > > Thanks for that Eric Evans. > > > > I'm not sure Hugo is the way to go. I don't see how I would generate the > > quality of work I would want with it. It seems like another example of > > coders learning and using a more complicated program to generate the code > > they could have already generated - it’s a disease in the I.T. industry > > right now. But I could be wrong. > > > > Here's the thing. I've been spending a lot of my time for the past three > > weeks now trying to help with the website. That is a tiny website. I've > > never worked
Re: Debug logging enabled by default since 2.2
Hi Paulo, I understand the intent and Jeremiah suggested on the ticket that logging causing performance issues should be switched to TRACE level. It's a tiny bit unusual to turn on debug logging for all users by default though, and there should be occasions to turn it on when facing issues that you want to debug (if they can be easily reproduced). I'll go down the read and write path to make a patch that turns debug logging into trace logging and will run new benchmarks with debug logging activated. There's a danger that contributors might add debug loggings in the future though, with the idea that it comes for free since the appender is asynchronous (I would think so), and create new performance issues. Can someone assign the ticket to me? Thanks! Le dim. 18 mars 2018 à 04:33, Paulo Motta a écrit : > The reasoning to have debug.log enabled by default after > CASSANDRA-10241 is to have a "safety log" that you can use when you > want to troubleshoot issues after the fact, that is verbose enough > that you can reconstruct events that may have caused a problem, but > should have negligible performance impact. The way we found to > implement this was the following: > - INFO: Human-readable operator log. > - DEBUG: Safety-log to be used for troubleshooting and bug reporting. > - TRACE: C* Programmer Debugging. > > If debug.log is causing performance problems we should definitely fix > it, but this has been very useful to troubleshoot complex production > issues since it has been added. > > 2018-03-17 16:35 GMT-03:00 Michael Kjellman : > > ive never understood this change. and it’s been explained to me multiple > times. > > > > DEBUG shouldn’t run by default in prod. and it certainly shouldn’t be > enabled by default for users. > > > > but hey, what do i know! just my 2 cents. > > > >> On Mar 17, 2018, at 10:55 AM, J. D. Jordan > wrote: > >> > >> We went through an exercise of setting things up so that DEBUG logging > was asynchronous would give people a “production” debug log. > https://issues.apache.org/jira/browse/CASSANDRA-10241 > >> If there are some things going out at DEBUG that cause performance > issues then most likely those should be moved to TRACE so that debug > logging can stay enabled for all the useful information found there. > >> > >> -Jeremiah > >> > >>> On Mar 17, 2018, at 1:49 PM, Alexander Dejanovski < > a...@thelastpickle.com> wrote: > >>> > >>> Hi folks, > >>> > >>> we've been upgrading clusters from 2.0 to 2.2 recently and we've > noticed > >>> that debug logging was causing serious performance issues in some > cases, > >>> specifically because of its use in the query pager. > >>> > >>> I've opened a ticket with some benchmarks and flame graphs : > >>> https://issues.apache.org/jira/browse/CASSANDRA-14318 > >>> > >>> The problem should be less serious in the read path with Cassandra 3.0 > and > >>> above as the query pager code has been reworked and doesn't log at > debug > >>> level. > >>> I think that debug logging shouldn't be turned on by default though, > since > >>> we see it doesn't come for free and that it lowers read performance in > 2.2. > >>> > >>> Was there any specific reason why it was enabled by default in 2.2 ? > >>> > >>> Is anyone opposed to disabling debug logging by default in all > branches ? > >>> > >>> -- > >>> - > >>> Alexander Dejanovski > >>> France > >>> @alexanderdeja > >>> > >>> Consultant > >>> Apache Cassandra Consulting > >>> http://www.thelastpickle.com > > > > - > > 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 > > -- - Alexander Dejanovski France @alexanderdeja Consultant Apache Cassandra Consulting http://www.thelastpickle.com
Re: Debug logging enabled by default since 2.2
+1. this is how it works. your computer doesn’t run at debug logging by default. your phone doesn’t either. neither does your smart tv. your database can’t be running at debug just because it makes our lives as engineers easier. > On Mar 18, 2018, at 5:14 AM, Alexander Dejanovski > wrote: > > It's a tiny bit unusual to turn on debug logging for all users by default > though, and there should be occasions to turn it on when facing issues that > you want to debug (if they can be easily reproduced).
Re: Debug logging enabled by default since 2.2
That really depends on whether you're judicious in deciding what to log at debug, doesn't it? On Sun, Mar 18, 2018 at 12:57 PM, Michael Kjellman wrote: > +1. this is how it works. > > your computer doesn’t run at debug logging by default. your phone doesn’t > either. neither does your smart tv. your database can’t be running at debug > just because it makes our lives as engineers easier. > > > On Mar 18, 2018, at 5:14 AM, Alexander Dejanovski < > a...@thelastpickle.com> wrote: > > > > It's a tiny bit unusual to turn on debug logging for all users by default > > though, and there should be occasions to turn it on when facing issues > that > > you want to debug (if they can be easily reproduced). > -- Jonathan Ellis co-founder, http://www.datastax.com @spyced
Re: Debug logging enabled by default since 2.2
it’s too easy to make a regression there. and does anyone even have a splunk (or equivalent) infrastructure to actually keep debug logs around for a long enough retention period to even have them be helpful? again: this is something engineers for the project want. it’s not in the best interest for our users. > On Mar 18, 2018, at 11:21 AM, Jonathan Ellis wrote: > > That really depends on whether you're judicious in deciding what to log at > debug, doesn't it? > > On Sun, Mar 18, 2018 at 12:57 PM, Michael Kjellman > wrote: > >> +1. this is how it works. >> >> your computer doesn’t run at debug logging by default. your phone doesn’t >> either. neither does your smart tv. your database can’t be running at debug >> just because it makes our lives as engineers easier. >> >>> On Mar 18, 2018, at 5:14 AM, Alexander Dejanovski < >> a...@thelastpickle.com> wrote: >>> >>> It's a tiny bit unusual to turn on debug logging for all users by default >>> though, and there should be occasions to turn it on when facing issues >> that >>> you want to debug (if they can be easily reproduced). >> > > > > -- > Jonathan Ellis > co-founder, http://www.datastax.com > @spyced - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Debug logging enabled by default since 2.2
what really baffles me with this entire thing is as a project we don’t even log things like partition keys along with the tombstone overwhelming or batch to large log messages.. this would immediately be helpful to thousands and thousands of people... yet somehow we think it’s okay to log tons of crap at debug to users drives that will shorten their ssds and objectively reduce the performance of the actual database due to logging overhead for some possible day in the future when we might need them to debug a problem really we should have figured out and reproduced ourselves in the first place. > On Mar 18, 2018, at 11:24 AM, Michael Kjellman wrote: > > it’s too easy to make a regression there. and does anyone even have a splunk > (or equivalent) infrastructure to actually keep debug logs around for a long > enough retention period to even have them be helpful? > > again: this is something engineers for the project want. it’s not in the best > interest for our users. > > >> On Mar 18, 2018, at 11:21 AM, Jonathan Ellis wrote: >> >> That really depends on whether you're judicious in deciding what to log at >> debug, doesn't it? >> >> On Sun, Mar 18, 2018 at 12:57 PM, Michael Kjellman >> wrote: >> >>> +1. this is how it works. >>> >>> your computer doesn’t run at debug logging by default. your phone doesn’t >>> either. neither does your smart tv. your database can’t be running at debug >>> just because it makes our lives as engineers easier. >>> On Mar 18, 2018, at 5:14 AM, Alexander Dejanovski < >>> a...@thelastpickle.com> wrote: It's a tiny bit unusual to turn on debug logging for all users by default though, and there should be occasions to turn it on when facing issues >>> that you want to debug (if they can be easily reproduced). >>> >> >> >> >> -- >> Jonathan Ellis >> co-founder, http://www.datastax.com >> @spyced > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org >
Re: Debug logging enabled by default since 2.2
If there are some log messages you think should be improved to make them more useful please do so. Saying things are “crap” is not productive. I have seen having the extra information from the debug.log be very helpful in debugging production issues after the fact on operational clusters many times. Also if you think there are things logged at DEBUG, since it was cleaned it up, that are not useful, then please improve them or change their logging level. You are also free to change the logging level on clusters you run if you don’t want the extra information. And again we are only talking about versions where DEBUG has been cleaned up. When running 2.1 or earlier, yes there is a ton of stuff at DEBUG and you would not want that on by default, even asynchronously. It is up to reviewers and committers to understand the impact of and rules around the use of different log levels. Said reviewers and committers should teach new contributors those rules during reviews if they are violated. -Jeremiah > On Mar 18, 2018, at 2:31 PM, Michael Kjellman wrote: > > what really baffles me with this entire thing is as a project we don’t even > log things like partition keys along with the tombstone overwhelming or batch > to large log messages.. this would immediately be helpful to thousands and > thousands of people... yet somehow we think it’s okay to log tons of crap > at debug to users drives that will shorten their ssds and objectively reduce > the performance of the actual database due to logging overhead for some > possible day in the future when we might need them to debug a problem really > we should have figured out and reproduced ourselves in the first place. > >> On Mar 18, 2018, at 11:24 AM, Michael Kjellman wrote: >> >> it’s too easy to make a regression there. and does anyone even have a >> splunk (or equivalent) infrastructure to actually keep debug logs around for >> a long enough retention period to even have them be helpful? >> >> again: this is something engineers for the project want. it’s not in the >> best interest for our users. >> >> >>> On Mar 18, 2018, at 11:21 AM, Jonathan Ellis wrote: >>> >>> That really depends on whether you're judicious in deciding what to log at >>> debug, doesn't it? >>> >>> On Sun, Mar 18, 2018 at 12:57 PM, Michael Kjellman >>> wrote: >>> +1. this is how it works. your computer doesn’t run at debug logging by default. your phone doesn’t either. neither does your smart tv. your database can’t be running at debug just because it makes our lives as engineers easier. > On Mar 18, 2018, at 5:14 AM, Alexander Dejanovski < a...@thelastpickle.com> wrote: > > It's a tiny bit unusual to turn on debug logging for all users by default > though, and there should be occasions to turn it on when facing issues that > you want to debug (if they can be easily reproduced). >>> >>> >>> >>> -- >>> Jonathan Ellis >>> co-founder, http://www.datastax.com >>> @spyced >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >> For additional commands, e-mail: dev-h...@cassandra.apache.org >> > ТÐÐ¥FòVç7V'67&–&RÂRÖ֖âFWb×Vç7V'67&–&T676æG&æ6†Ræ÷&pФf÷"FF—F–öæÂ6öÖÖæG2ÂRÖ֖âFWbÖ†VÇ676æG&æ6†Ræ÷&pÐ > Ð - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Debug logging enabled by default since 2.2
i’m not trying to get into a fight here jeremiah. and this will be my last reply on this as i’ve made my opinion pretty clear. but ask yourself: would you run c* in idea debugger and then do performance testing? no. because it’s a DEBUGger. > On Mar 18, 2018, at 11:43 AM, J. D. Jordan wrote: > > If there are some log messages you think should be improved to make them more > useful please do so. Saying things are “crap” is not productive. > > I have seen having the extra information from the debug.log be very helpful > in debugging production issues after the fact on operational clusters many > times. > > Also if you think there are things logged at DEBUG, since it was cleaned it > up, that are not useful, then please improve them or change their logging > level. > > You are also free to change the logging level on clusters you run if you > don’t want the extra information. > > And again we are only talking about versions where DEBUG has been cleaned up. > When running 2.1 or earlier, yes there is a ton of stuff at DEBUG and you > would not want that on by default, even asynchronously. > > It is up to reviewers and committers to understand the impact of and rules > around the use of different log levels. Said reviewers and committers should > teach new contributors those rules during reviews if they are violated. > > -Jeremiah > >> On Mar 18, 2018, at 2:31 PM, Michael Kjellman wrote: >> >> what really baffles me with this entire thing is as a project we don’t >> even log things like partition keys along with the tombstone overwhelming or >> batch to large log messages.. this would immediately be helpful to thousands >> and thousands of people... yet somehow we think it’s okay to log tons of >> crap at debug to users drives that will shorten their ssds and objectively >> reduce the performance of the actual database due to logging overhead for >> some possible day in the future when we might need them to debug a problem >> really we should have figured out and reproduced ourselves in the first >> place. >> >>> On Mar 18, 2018, at 11:24 AM, Michael Kjellman wrote: >>> >>> it’s too easy to make a regression there. and does anyone even have a >>> splunk (or equivalent) infrastructure to actually keep debug logs around >>> for a long enough retention period to even have them be helpful? >>> >>> again: this is something engineers for the project want. it’s not in the >>> best interest for our users. >>> >>> On Mar 18, 2018, at 11:21 AM, Jonathan Ellis wrote: That really depends on whether you're judicious in deciding what to log at debug, doesn't it? On Sun, Mar 18, 2018 at 12:57 PM, Michael Kjellman wrote: > +1. this is how it works. > > your computer doesn’t run at debug logging by default. your phone > doesn’t > either. neither does your smart tv. your database can’t be running at > debug > just because it makes our lives as engineers easier. > >> On Mar 18, 2018, at 5:14 AM, Alexander Dejanovski < > a...@thelastpickle.com> wrote: >> >> It's a tiny bit unusual to turn on debug logging for all users by default >> though, and there should be occasions to turn it on when facing issues > that >> you want to debug (if they can be easily reproduced). > -- Jonathan Ellis co-founder, http://www.datastax.com @spyced >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>> >> ТÐÐ¥FòVç7V'67&–&RÂRÖ֖âFWb×Vç7V'67&–&T676æG&æ6†Ræ÷&pФf÷"FF—F–öæÂ6öÖÖæG2ÂRÖ֖âFWbÖ†VÇ676æG&æ6†Ræ÷&pÐ >> Ð > > - > 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: Debug logging enabled by default since 2.2
First of all thanks for raising this ticket and important discussion Alexander! See answers inline below: > It's a tiny bit unusual to turn on debug logging for all users by default > though, and there should be occasions to turn it on when facing issues that > you want to debug (if they can be easily reproduced). > This is not supposed to be "debugging" log in the strict sense of the word used for development purposes, but rather a "verbose system log" - which is verbose enough to difficult human reading of "system.log" but not enough to affect performance and could aid in troubleshooting. Perhaps this is not so clear so we should definitely improve communication in that front for committers and reviewers, but this has been very useful to troubleshoot and investigate hard to reproduce issues in production environments. Advanced operators can still disable it if they have automated log analysis, but it's useful to the beginner operator to understand system.log and "escalate" to debug.log if/when they are facing problems. > There's a danger that contributors might add debug loggings in the future > though, with the idea that it comes for free since the appender is > asynchronous (I would think so), and create new performance issues. > It's up to the committer and reviewer to ensure the log statements do not affect performance, as per our review guidelines (http://cassandra.apache.org/doc/latest/development/how_to_review.html#review-checklist): Logging - Are logging statements logged at the correct level? - Are there logs in the critical path that could affect performance? - Is there any log that could be added to communicate status or troubleshoot potential problems in this feature? - Can any unnecessary logging statement be removed? This is a subjective area and we can definitely try to quantify this and make this guideline more explicit if we start seeing more problems like this in the future. > Can someone assign the ticket to me? Assigned! > > Thanks! > > Le dim. 18 mars 2018 à 04:33, Paulo Motta a > écrit : > >> The reasoning to have debug.log enabled by default after >> CASSANDRA-10241 is to have a "safety log" that you can use when you >> want to troubleshoot issues after the fact, that is verbose enough >> that you can reconstruct events that may have caused a problem, but >> should have negligible performance impact. The way we found to >> implement this was the following: >> - INFO: Human-readable operator log. >> - DEBUG: Safety-log to be used for troubleshooting and bug reporting. >> - TRACE: C* Programmer Debugging. >> >> If debug.log is causing performance problems we should definitely fix >> it, but this has been very useful to troubleshoot complex production >> issues since it has been added. >> >> 2018-03-17 16:35 GMT-03:00 Michael Kjellman : >> > ive never understood this change. and it’s been explained to me multiple >> times. >> > >> > DEBUG shouldn’t run by default in prod. and it certainly shouldn’t be >> enabled by default for users. >> > >> > but hey, what do i know! just my 2 cents. >> > >> >> On Mar 17, 2018, at 10:55 AM, J. D. Jordan >> wrote: >> >> >> >> We went through an exercise of setting things up so that DEBUG logging >> was asynchronous would give people a “production” debug log. >> https://issues.apache.org/jira/browse/CASSANDRA-10241 >> >> If there are some things going out at DEBUG that cause performance >> issues then most likely those should be moved to TRACE so that debug >> logging can stay enabled for all the useful information found there. >> >> >> >> -Jeremiah >> >> >> >>> On Mar 17, 2018, at 1:49 PM, Alexander Dejanovski < >> a...@thelastpickle.com> wrote: >> >>> >> >>> Hi folks, >> >>> >> >>> we've been upgrading clusters from 2.0 to 2.2 recently and we've >> noticed >> >>> that debug logging was causing serious performance issues in some >> cases, >> >>> specifically because of its use in the query pager. >> >>> >> >>> I've opened a ticket with some benchmarks and flame graphs : >> >>> https://issues.apache.org/jira/browse/CASSANDRA-14318 >> >>> >> >>> The problem should be less serious in the read path with Cassandra 3.0 >> and >> >>> above as the query pager code has been reworked and doesn't log at >> debug >> >>> level. >> >>> I think that debug logging shouldn't be turned on by default though, >> since >> >>> we see it doesn't come for free and that it lowers read performance in >> 2.2. >> >>> >> >>> Was there any specific reason why it was enabled by default in 2.2 ? >> >>> >> >>> Is anyone opposed to disabling debug logging by default in all >> branches ? >> >>> >> >>> -- >> >>> - >> >>> Alexander Dejanovski >> >>> France >> >>> @alexanderdeja >> >>> >> >>> Consultant >> >>> Apache Cassandra Consulting >> >>> http://www.thelastpickle.com >> > >> > - >> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >> > For additional commands, e-mail: dev-h..
RE: A JIRA proposing a seperate repository for the online documentation
The answer is right before us: Let's use Rahul Singh's Awesome Cassandra list for now: https://github.com/anant/awesome-cassandra while he works on some other things for us. I will be submitting contributions to it regularly and referencing it as the go to resource. It will serve us well for now. Kenneth Brotman -Original Message- From: Kenneth Brotman [mailto:kenbrot...@yahoo.com.INVALID] Sent: Sunday, March 18, 2018 4:41 AM To: dev@cassandra.apache.org Subject: RE: A JIRA proposing a seperate repository for the online documentation I don't know what we are doing for the website technologies right now because like everything else what we do is not documented anywhere. Where are the servers: the cloud? What server software are we running? How is the html, etc. generated and published? How is search done for the website? Kenneth Brotman -Original Message- From: Rahul Singh [mailto:rahul.xavier.si...@gmail.com] Sent: Saturday, March 17, 2018 7:12 AM To: dev@cassandra.apache.org Subject: RE: A JIRA proposing a seperate repository for the online documentation Static site generator just takes content from flat files or apis (that can be managed from a headless cms) and creates static files or progressive web apps that are optimized for speed. Nothing to do with multi-media or dynamic in terms of client side javascript / css. It’s just an old technology with a new name. Thats how we used to generate sites back in 1990s.. :) -- Rahul Singh rahul.si...@anant.us Anant Corporation On Mar 17, 2018, 10:03 AM -0400, Kenneth Brotman , wrote: > How about if we look at the website a little differently. Isn't it an > opportunity to showcase Cassandra and related technologies like search! > Shouldn't we be an extraordinary advocate and example of the technology > ourselves? > > Rahul, your comment on the different users with different use cases was very > wise. > > I've been writing html a long time; since about 1990. You're asking me to > learn a weird little program, a static site generator just to change > something I can already do without using a program at all. > > Another weird thing: Wouldn't we want a website that is dynamic and > multi-media rich? > > Kenneth Brotman > > > -Original Message- > From: Rahul Singh [mailto:rahul.xavier.si...@gmail.com] > Sent: Saturday, March 17, 2018 5:57 AM > To: dev@cassandra.apache.org > Subject: RE: A JIRA proposing a seperate repository for the online > documentation > > I’ve previously deep dived into Static Site generators and there are numerous > ones. > > http://leaves.anant.us/#!/leaf/7255?tag=static.site > > I don’t like changing technology for the sake of change. I think it’s a > stupid waste of time. In one hand I agree, the substance is more important > than the form. On the other hand. I [insert f-bomb] hate writing HTML / CSS, > or restructured text. Markdown is much easier. Hugo is one of many that if > setup right, it can save a ton of time and make it more accessible for people > to contribute. > > There is a difference however in developer documentation for developers of > cassandra, user documentation for cassandra users, documentation for and > administrators. They are different users and have different use cases Some > need reference style docs, others need guides. > > Some good examples, (the software quality not-withstanding), correlate with > software propularity are Wordpress. I am not wild about Wordpress, but their > codex.wordpress.org has been generally a good “user doc.” > > Envision the outcome even if you have to mimic someone else. I don’t mind > stealing/copying if it gets us one step further than we are. The reaper docs > look easy to maintain and I could care less about Hugo, Hexo, Jekyll, Hyde, > KafkasMom, EinsteinsDog, ShrodingersCat static site generator. > > I think action should come before decision in open source. Prove something > before suggesting a change. Jon’s reaper example is good. If anyone has > something better, show it. Prove it. > > -- > Rahul Singh > rahul.si...@anant.us > > Anant Corporation > > On Mar 16, 2018, 6:54 PM -0400, Kenneth Brotman > , wrote: > > There is no need for another program. Keep the code in html, css and js > > People can modify that and show proposed changes in that. No need to > > convert back and forth from other formats. If someone is doing something > > more involved, they probably already have a program themselves. > > > > -Original Message- > > From: beggles...@apple.com [mailto:beggles...@apple.com] > > Sent: Friday, March 16, 2018 3:16 PM > > To: dev@cassandra.apache.org > > Subject: Re: A JIRA proposing a seperate repository for the online > > documentation > > > > It would probably be more productive to list some specific concerns you > > have with Hugo. Then explain why you think they make using it a bad idea > > Then offer some alternatives. > > > > On 3/16/18, 1:18 PM, "Kenneth Brotman" wrote: > > >
Re: Debug logging enabled by default since 2.2
It seems to me the power user who wants to eek out that last bit of performance can do so. It also seems like the user who doesn't even know about that is the exact kind of user that's going to need the debug log in the future. On Sun, Mar 18, 2018 at 1:45 PM, Michael Kjellman wrote: > i’m not trying to get into a fight here jeremiah. and this will be my last > reply on this as i’ve made my opinion pretty clear. but ask yourself: would > you run c* in idea debugger and then do performance testing? no. because > it’s a DEBUGger. > > > On Mar 18, 2018, at 11:43 AM, J. D. Jordan > wrote: > > > > If there are some log messages you think should be improved to make them > more useful please do so. Saying things are “crap” is not productive. > > > > I have seen having the extra information from the debug.log be very > helpful in debugging production issues after the fact on operational > clusters many times. > > > > Also if you think there are things logged at DEBUG, since it was cleaned > it up, that are not useful, then please improve them or change their > logging level. > > > > You are also free to change the logging level on clusters you run if you > don’t want the extra information. > > > > And again we are only talking about versions where DEBUG has been > cleaned up. When running 2.1 or earlier, yes there is a ton of stuff at > DEBUG and you would not want that on by default, even asynchronously. > > > > It is up to reviewers and committers to understand the impact of and > rules around the use of different log levels. Said reviewers and committers > should teach new contributors those rules during reviews if they are > violated. > > > > -Jeremiah > > > >> On Mar 18, 2018, at 2:31 PM, Michael Kjellman > wrote: > >> > >> what really baffles me with this entire thing is as a project we > don’t even log things like partition keys along with the tombstone > overwhelming or batch to large log messages.. this would immediately be > helpful to thousands and thousands of people... yet somehow we think it’s > okay to log tons of crap at debug to users drives that will shorten their > ssds and objectively reduce the performance of the actual database due to > logging overhead for some possible day in the future when we might need > them to debug a problem really we should have figured out and reproduced > ourselves in the first place. > >> > >>> On Mar 18, 2018, at 11:24 AM, Michael Kjellman > wrote: > >>> > >>> it’s too easy to make a regression there. and does anyone even have > a splunk (or equivalent) infrastructure to actually keep debug logs around > for a long enough retention period to even have them be helpful? > >>> > >>> again: this is something engineers for the project want. it’s not in > the best interest for our users. > >>> > >>> > On Mar 18, 2018, at 11:21 AM, Jonathan Ellis > wrote: > > That really depends on whether you're judicious in deciding what to > log at > debug, doesn't it? > > On Sun, Mar 18, 2018 at 12:57 PM, Michael Kjellman < > kjell...@apple.com> > wrote: > > > +1. this is how it works. > > > > your computer doesn’t run at debug logging by default. your phone > doesn’t > > either. neither does your smart tv. your database can’t be running > at debug > > just because it makes our lives as engineers easier. > > > >> On Mar 18, 2018, at 5:14 AM, Alexander Dejanovski < > > a...@thelastpickle.com> wrote: > >> > >> It's a tiny bit unusual to turn on debug logging for all users by > default > >> though, and there should be occasions to turn it on when facing > issues > > that > >> you want to debug (if they can be easily reproduced). > > > > > > -- > Jonathan Ellis > co-founder, http://www.datastax.com > @spyced > >>> > >>> - > >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > >>> For additional commands, e-mail: dev-h...@cassandra.apache.org > >>> > >> ТÐÐ¥Fò > Vç7V'67&–&R RÖÖ –â FWb×Vç7V'67&–&T 6 76 æG& æ 6†Ræ÷&pФf÷" FF—F–öæ  > 6öÖÖ æG2 RÖÖ –â FWbÖ†VÇ 6 76 æG& æ 6†Ræ÷&pÐ Ð > > > > - > > 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: Debug logging enabled by default since 2.2
In Cassandra-10241 I said I was torn on this whole ticket, since most people would end up turning it off if it had a negative impact. You said: “I'd like to emphasize that we're not talking about turning debug or trace on for client-generated request paths. There's way too much data generated and it's unlikely to be useful. What we're proposing is enabling debug logging ONLY for cluster state changes like gossip and schema, and infrequent activities like repair. “ Clearly there’s a disconnect here - we’ve turned debug logging on for everything and shuffled some stuff to trace, which is a one time action but is hard to protect against regression. In fact, just looking at the read callback shows two instances of debug log in the client request path (exercise for the reader to “git blame”). Either we can go clean up all the surprises that leaked through, or we can turn off debug and start backing out some of the changes in 10241. Putting stuff like compaction in the same bucket as digest mismatch and gossip state doesn’t make life materially better for most people. -- Jeff Jirsa > On Mar 18, 2018, at 11:21 AM, Jonathan Ellis wrote: > > That really depends on whether you're judicious in deciding what to log at > debug, doesn't it? > > On Sun, Mar 18, 2018 at 12:57 PM, Michael Kjellman > wrote: > >> +1. this is how it works. >> >> your computer doesn’t run at debug logging by default. your phone doesn’t >> either. neither does your smart tv. your database can’t be running at debug >> just because it makes our lives as engineers easier. >> >>> On Mar 18, 2018, at 5:14 AM, Alexander Dejanovski < >> a...@thelastpickle.com> wrote: >>> >>> It's a tiny bit unusual to turn on debug logging for all users by default >>> though, and there should be occasions to turn it on when facing issues >> that >>> you want to debug (if they can be easily reproduced). >> > > > > -- > Jonathan Ellis > co-founder, http://www.datastax.com > @spyced
Re: A JIRA proposing a seperate repository for the online documentation
On Mon, Mar 19, 2018 at 12:41 AM, Kenneth Brotman wrote: > I don't know what we are doing for the website technologies right now because > like everything else what we do is not documented anywhere. Where are the > servers: the cloud? What server software are we running? How is the html, > etc. generated and published? How is search done for the website? http://cassandra.apache.org/doc/latest/development/documentation.html The resulting static HTML from Sphinx is hosted on ASF infrastructure. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Debug logging enabled by default since 2.2
Hi, In a way the real issue might be that we don’t have nightly performance runs that would make an accidentally introduced debug statement obvious. A log statement that runs once or more per read or write should be easy to spot. I haven’t measured the impact though. And as a bonus by having this we can spot a variety of performance issues introduced by all kinds of changes. Ariel > On Mar 18, 2018, at 3:46 PM, Jeff Jirsa wrote: > > In Cassandra-10241 I said I was torn on this whole ticket, since most people > would end up turning it off if it had a negative impact. You said: > > “I'd like to emphasize that we're not talking about turning debug or trace on > for client-generated request paths. There's way too much data generated and > it's unlikely to be useful. > What we're proposing is enabling debug logging ONLY for cluster state changes > like gossip and schema, and infrequent activities like repair. “ > > Clearly there’s a disconnect here - we’ve turned debug logging on for > everything and shuffled some stuff to trace, which is a one time action but > is hard to protect against regression. In fact, just looking at the read > callback shows two instances of debug log in the client request path > (exercise for the reader to “git blame”). > > Either we can go clean up all the surprises that leaked through, or we can > turn off debug and start backing out some of the changes in 10241. Putting > stuff like compaction in the same bucket as digest mismatch and gossip state > doesn’t make life materially better for most people. > > > -- > Jeff Jirsa > > >> On Mar 18, 2018, at 11:21 AM, Jonathan Ellis wrote: >> >> That really depends on whether you're judicious in deciding what to log at >> debug, doesn't it? >> >> On Sun, Mar 18, 2018 at 12:57 PM, Michael Kjellman >> wrote: >> >>> +1. this is how it works. >>> >>> your computer doesn’t run at debug logging by default. your phone doesn’t >>> either. neither does your smart tv. your database can’t be running at debug >>> just because it makes our lives as engineers easier. >>> On Mar 18, 2018, at 5:14 AM, Alexander Dejanovski < >>> a...@thelastpickle.com> wrote: It's a tiny bit unusual to turn on debug logging for all users by default though, and there should be occasions to turn it on when facing issues >>> that you want to debug (if they can be easily reproduced). >>> >> >> >> >> -- >> Jonathan Ellis >> co-founder, http://www.datastax.com >> @spyced - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Debug logging enabled by default since 2.2
On the same page as Michael here. We disable debug logs in production due to the performance impact. Personally I think if debug logging is necessary for users to use the software we're doing something wrong. Also in my experience, if something doesn't reproduce it will not get fixed. Debug logging helps, but I've never seen a case where an actual bug simply *doesn't* reproduce eventually, and I'm sure if this issue appears debug logging could be enabled after the fact for the relevant classes and eventually it will reoccur and we could solve the problem. I've never seen a user say no to helping debug a problem with patched jars/changes to their system (like logging). I'd much prefer we pushed that harder rather than just saying "Everyone gets debug logging!". I'm also really not sold that debug logging saves the day. To me it mostly just speeds up the identification process, it generally doesn't expose magical information that wasn't available before, you just had to think about it a bit more. In a way the real issue might be that we don’t have nightly performance > runs that would make an accidentally introduced debug statement obvious. This is an issue, but I don't think it's the *real* issue. As already noted, debug logging is for debugging, which normal users shouldn't have to think about when they are just operating the software. We shouldn't risk performance regressions just for developer convenience. On 19 March 2018 at 00:55, Ariel Weisberg wrote: > Hi, > > In a way the real issue might be that we don’t have nightly performance > runs that would make an accidentally introduced debug statement obvious. > > A log statement that runs once or more per read or write should be easy to > spot. I haven’t measured the impact though. And as a bonus by having this > we can spot a variety of performance issues introduced by all kinds of > changes. > > Ariel > > > On Mar 18, 2018, at 3:46 PM, Jeff Jirsa wrote: > > > > In Cassandra-10241 I said I was torn on this whole ticket, since most > people would end up turning it off if it had a negative impact. You said: > > > > “I'd like to emphasize that we're not talking about turning debug or > trace on for client-generated request paths. There's way too much data > generated and it's unlikely to be useful. > > What we're proposing is enabling debug logging ONLY for cluster state > changes like gossip and schema, and infrequent activities like repair. “ > > > > Clearly there’s a disconnect here - we’ve turned debug logging on for > everything and shuffled some stuff to trace, which is a one time action but > is hard to protect against regression. In fact, just looking at the read > callback shows two instances of debug log in the client request path > (exercise for the reader to “git blame”). > > > > Either we can go clean up all the surprises that leaked through, or we > can turn off debug and start backing out some of the changes in 10241. > Putting stuff like compaction in the same bucket as digest mismatch and > gossip state doesn’t make life materially better for most people. > > > > > > -- > > Jeff Jirsa > > > > > >> On Mar 18, 2018, at 11:21 AM, Jonathan Ellis wrote: > >> > >> That really depends on whether you're judicious in deciding what to log > at > >> debug, doesn't it? > >> > >> On Sun, Mar 18, 2018 at 12:57 PM, Michael Kjellman > >> wrote: > >> > >>> +1. this is how it works. > >>> > >>> your computer doesn’t run at debug logging by default. your phone > doesn’t > >>> either. neither does your smart tv. your database can’t be running at > debug > >>> just because it makes our lives as engineers easier. > >>> > On Mar 18, 2018, at 5:14 AM, Alexander Dejanovski < > >>> a...@thelastpickle.com> wrote: > > It's a tiny bit unusual to turn on debug logging for all users by > default > though, and there should be occasions to turn it on when facing issues > >>> that > you want to debug (if they can be easily reproduced). > >>> > >> > >> > >> > >> -- > >> Jonathan Ellis > >> co-founder, http://www.datastax.com > >> @spyced > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
