Re: Further thoughts on config deprecations

[Joshua Cohen]

I'm suggesting the latter. It wouldn't necessarily require a monorepo
(though that does make it easier for a cluster operator to run tool). If we
went with something relatively streamlined, it would be easy for job owners
to also run the tool on their individual configs.

I'm taking inspiration from the JS community which is dealing with
relatively high rate of change by providing automated tooling to make
trivial code changes in bulk. I think we could benefit from similar
tooling, but if others don't agree we can continue our less formal process
of grep'ing and sed'ing ;).

On Thu, Feb 4, 2016 at 1:55 AM, Erb, Stephan <stephan@blue-yonder.com>
wrote:

> Are you suggesting a tool that operates against a running Aurora cluster
> and performs a serverside inspection? Or are you implying a tool that works
> on .aurora files?
>
> I'd find the first one way more useful, as the latter one would suggest
> that you had to have a monorepo with access to the all aurora
> configurations.
>
> Cheers,
> Stephan
> 
> From: John Sirois <j...@conductant.com>
> Sent: Thursday, February 4, 2016 2:42 AM
> To: dev@aurora.apache.org
> Subject: Re: Further thoughts on config deprecations
>
> On Wed, Feb 3, 2016 at 6:34 PM, Joshua Cohen <jco...@apache.org> wrote:
>
> > How would folks feel about requiring any changes that deprecate job
> config
> > to include some sort of codemod[1]-like patch that would allow cluster
> > operators to automatically fix deprecated fields across their company's
> > Aurora configs?
> >
> > We could either leverage codemod directly, or create nicer tooling around
> > it that supports applying arbitrary patches (along the lines of
> > jscodeshift[2]).
> >
>
> I'd be really happy with a less ambitious step - a tool folks could run
> that gave them warnings about things that were broken between their current
> release and the targeted release - leaving fixes up to them, though
> suggesting those fixes in console text - possibly with links out to longer
> articles on the web for tougher fixes.
>
>
> >
> > Cheers,
> >
> > Joshua
> >
> > [1] https://github.com/facebook/codemod
> > [2] https://github.com/facebook/jscodeshift
> >
>
>
>
> --
> John Sirois
> 303-512-3301
>

Re: Further thoughts on config deprecations

[John Sirois]

On Wed, Feb 3, 2016 at 6:34 PM, Joshua Cohen  wrote:

> How would folks feel about requiring any changes that deprecate job config
> to include some sort of codemod[1]-like patch that would allow cluster
> operators to automatically fix deprecated fields across their company's
> Aurora configs?
>
> We could either leverage codemod directly, or create nicer tooling around
> it that supports applying arbitrary patches (along the lines of
> jscodeshift[2]).
>

I'd be really happy with a less ambitious step - a tool folks could run
that gave them warnings about things that were broken between their current
release and the targeted release - leaving fixes up to them, though
suggesting those fixes in console text - possibly with links out to longer
articles on the web for tougher fixes.


>
> Cheers,
>
> Joshua
>
> [1] https://github.com/facebook/codemod
> [2] https://github.com/facebook/jscodeshift
>



-- 
John Sirois
303-512-3301

Further thoughts on config deprecations

[Joshua Cohen]

How would folks feel about requiring any changes that deprecate job config
to include some sort of codemod[1]-like patch that would allow cluster
operators to automatically fix deprecated fields across their company's
Aurora configs?

We could either leverage codemod directly, or create nicer tooling around
it that supports applying arbitrary patches (along the lines of
jscodeshift[2]).

Cheers,

Joshua

[1] https://github.com/facebook/codemod
[2] https://github.com/facebook/jscodeshift

Re: Further thoughts on config deprecations

[Erb, Stephan]

Are you suggesting a tool that operates against a running Aurora cluster and 
performs a serverside inspection? Or are you implying a tool that works on 
.aurora files? 

I'd find the first one way more useful, as the latter one would suggest that 
you had to have a monorepo with access to the all aurora configurations.

Cheers,
Stephan

From: John Sirois <j...@conductant.com>
Sent: Thursday, February 4, 2016 2:42 AM
To: dev@aurora.apache.org
Subject: Re: Further thoughts on config deprecations

On Wed, Feb 3, 2016 at 6:34 PM, Joshua Cohen <jco...@apache.org> wrote:

> How would folks feel about requiring any changes that deprecate job config
> to include some sort of codemod[1]-like patch that would allow cluster
> operators to automatically fix deprecated fields across their company's
> Aurora configs?
>
> We could either leverage codemod directly, or create nicer tooling around
> it that supports applying arbitrary patches (along the lines of
> jscodeshift[2]).
>

I'd be really happy with a less ambitious step - a tool folks could run
that gave them warnings about things that were broken between their current
release and the targeted release - leaving fixes up to them, though
suggesting those fixes in console text - possibly with links out to longer
articles on the web for tougher fixes.


>
> Cheers,
>
> Joshua
>
> [1] https://github.com/facebook/codemod
> [2] https://github.com/facebook/jscodeshift
>



--
John Sirois
303-512-3301