Re: duration based config settings

2017-12-05 Thread Jason Brown
I like this idea, but tbh I hate overburdening operators with what will
seem them as busywork. Operators have scripts and other infrastructure to
automate the creation of yaml files, and the thoughts of "oh crap, why did
they rename all the properties? And, are these really just simple renames,
or is there something subtly different now?" are onerous and worrysome to
them.

If there's a clever, maintainable, and safe way to implement this change
and be somehow backward compatible I could be on board. However, let's
please keep the operators in mind when making these very externally visible
changes.

Thanks,

-Jason

On Mon, Dec 4, 2017 at 5:33 PM, Jon Haddad  wrote:

> Sure, I’m fine w/ letting the _ms settings work indefinitely.  Can revisit
> retiring them if there’s ever a real need, am OK if that never happens.
>
> I’ll create the JIRA.
>
> > On Dec 4, 2017, at 5:19 PM, Nate McCall  wrote:
> >
> >> I'd be in favour of never retiring the _ms format though - it's almost
> >> free, there's no backward compatibility problems, and it's fairly
> intuitive
> >> so long as we're consistent about it.
> >>
> >
> > Agreed on this point. Overall, this will be excellent for usability.
> >
> > -
> > 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: duration based config settings

2017-12-04 Thread Jon Haddad
Sure, I’m fine w/ letting the _ms settings work indefinitely.  Can revisit 
retiring them if there’s ever a real need, am OK if that never happens.

I’ll create the JIRA.

> On Dec 4, 2017, at 5:19 PM, Nate McCall  wrote:
> 
>> I'd be in favour of never retiring the _ms format though - it's almost
>> free, there's no backward compatibility problems, and it's fairly intuitive
>> so long as we're consistent about it.
>> 
> 
> Agreed on this point. Overall, this will be excellent for usability.
> 
> -
> 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: duration based config settings

2017-12-04 Thread Nate McCall
> I'd be in favour of never retiring the _ms format though - it's almost
> free, there's no backward compatibility problems, and it's fairly intuitive
> so long as we're consistent about it.
>

Agreed on this point. Overall, this will be excellent for usability.

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



Re: duration based config settings

2017-12-04 Thread Jeff Jirsa
To be clear I’m not -1 on this, I just hope we think about upgrading users as 
we deprecate the old stuff out


-- 
Jeff Jirsa


> On Dec 4, 2017, at 4:24 PM, Jon Haddad  wrote:
> 
> I ways back I had entire CASSANDRA-13976 out of sheer annoyance to change the 
> hint time to be in minutes instead of ms.  Millisecond based resolution is a 
> bit absurd for things like hints.  I figured minutes would be better, but 
> after some back and forth realized durations (3h, 30m, etc) would be a lot 
> easier to work with, and would probably be appropriate across the board.
> 
> I’ve dealt with quite a few clusters in the last year, and I’ve seen a 
> handful of fat fingered config files, or non-standard times that make me bust 
> out a calculator to be sure I’ve got things sorted out right, hence the 
> original issue.
> 
> Jeff Jirsa suggested migrating to duration types would result in migration 
> pain, and I’m not disagreeing with him.  I think we if were to move to 
> duration types, we’d want something like the following:
> 
> 1. add a blah_blah for every blah_blah_ms setting which accepts a duration
> 2. convert every setting to use blah_blah 
> 3. if blah_blah_ms is present, use that for blah_blah and set the duration to 
> ms
> 4. internally everything converts to ms
> 5. make all node tool commands use durations 
> 6. for ever setting that’s switch to blah_blah, leave a note that says the 
> setting it’s replacing
> 7. put a warning when people use blah_blah_ms and suggest the conversation to 
> the new config field 
> 8. *sometime* in the future remove _ms.  Maybe as far as a year or two down 
> the line.
> 
> This seems to me like a significant change and I wanted to get some more 
> opinions on the topic before pushing forward.  Thoughts?
> 
> Jon
> -
> 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: duration based config settings

2017-12-04 Thread Benedict Elliott Smith
I'm strongly in favour of it; it's always bugged me, and I hadn't realised
it might be contentious to implement.

I'd be in favour of never retiring the _ms format though - it's almost
free, there's no backward compatibility problems, and it's fairly intuitive
so long as we're consistent about it.

The only sticking point I can personally see is that there might be a
desire to roll this up into a standardisation effort, as we have some
duration properties (e.g. key_cache_save_period) which do not have a unit
suffix.  If we want to standardise on blah_blah_ms, and blah_blah we might
want to moonlight those, migrating them to some new blah_blahish_ms and
blah_blahish.

On 5 December 2017 at 00:24, Jon Haddad  wrote:

> I ways back I had entire CASSANDRA-13976 out of sheer annoyance to change
> the hint time to be in minutes instead of ms.  Millisecond based resolution
> is a bit absurd for things like hints.  I figured minutes would be better,
> but after some back and forth realized durations (3h, 30m, etc) would be a
> lot easier to work with, and would probably be appropriate across the board.
>
> I’ve dealt with quite a few clusters in the last year, and I’ve seen a
> handful of fat fingered config files, or non-standard times that make me
> bust out a calculator to be sure I’ve got things sorted out right, hence
> the original issue.
>
> Jeff Jirsa suggested migrating to duration types would result in migration
> pain, and I’m not disagreeing with him.  I think we if were to move to
> duration types, we’d want something like the following:
>
> 1. add a blah_blah for every blah_blah_ms setting which accepts a duration
> 2. convert every setting to use blah_blah
> 3. if blah_blah_ms is present, use that for blah_blah and set the duration
> to ms
> 4. internally everything converts to ms
> 5. make all node tool commands use durations
> 6. for ever setting that’s switch to blah_blah, leave a note that says the
> setting it’s replacing
> 7. put a warning when people use blah_blah_ms and suggest the conversation
> to the new config field
> 8. *sometime* in the future remove _ms.  Maybe as far as a year or two
> down the line.
>
> This seems to me like a significant change and I wanted to get some more
> opinions on the topic before pushing forward.  Thoughts?
>
> Jon
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>


duration based config settings

2017-12-04 Thread Jon Haddad
I ways back I had entire CASSANDRA-13976 out of sheer annoyance to change the 
hint time to be in minutes instead of ms.  Millisecond based resolution is a 
bit absurd for things like hints.  I figured minutes would be better, but after 
some back and forth realized durations (3h, 30m, etc) would be a lot easier to 
work with, and would probably be appropriate across the board.

I’ve dealt with quite a few clusters in the last year, and I’ve seen a handful 
of fat fingered config files, or non-standard times that make me bust out a 
calculator to be sure I’ve got things sorted out right, hence the original 
issue.

Jeff Jirsa suggested migrating to duration types would result in migration 
pain, and I’m not disagreeing with him.  I think we if were to move to duration 
types, we’d want something like the following:

1. add a blah_blah for every blah_blah_ms setting which accepts a duration
2. convert every setting to use blah_blah 
3. if blah_blah_ms is present, use that for blah_blah and set the duration to ms
4. internally everything converts to ms
5. make all node tool commands use durations 
6. for ever setting that’s switch to blah_blah, leave a note that says the 
setting it’s replacing
7. put a warning when people use blah_blah_ms and suggest the conversation to 
the new config field 
8. *sometime* in the future remove _ms.  Maybe as far as a year or two down the 
line.

This seems to me like a significant change and I wanted to get some more 
opinions on the topic before pushing forward.  Thoughts?

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