You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficcontrol.apache.org by "Gray, Jonathan" <Jo...@comcast.com> on 2019/01/22 15:31:00 UTC
Re: [EXTERNAL] Re: Removal of CacheURL DS Field from ATC
If a deprecation notice would be needed, that's ok. I would assume regardless there would need to be consensus first. Then I can add this email thread to the ticket so we remember down the road.
Jonathan G
On 1/18/19, 1:41 PM, "Rawlin Peters" <ra...@gmail.com> wrote:
+1. The raw remap line sounds like a reasonable workaround for people
still on ATS 6. That said, stuff like this typically requires a
deprecation notice before removal.
- Rawlin
On Fri, Jan 18, 2019 at 10:58 AM Fieck, Brennan
<Br...@comcast.com> wrote:
>
> +a million on not supporting a product that has reached it's EOL
> (definitely not biased to set a precedent for Python 2)
> ________________________________________
> From: Gray, Jonathan <Jo...@comcast.com>
> Sent: Wednesday, January 16, 2019 9:42 AM
> To: dev@trafficcontrol.apache.org
> Subject: [EXTERNAL] Removal of CacheURL DS Field from ATC
>
> Hello all,
>
> I’d like to get consensus on https://github.com/apache/trafficcontrol/issues/3225 . If we remove the CacheURL delivery service field, you can still use ATS 6 if you must, you’ll just have to use the raw remap text field by hand instead of leaning on TO to generate the config for you. That said, if you’re still on ATS 6 and are doing that, you’re better off upgrading to the more powerful cachekey plugin instead that is supported in ATS 6 and beyond. As ATC supports newer versions of ATS, this is creating extra cruft for new users to stumble across and learn about the hard way not to do.
>
> Jonathan G
Re: [EXTERNAL] Re: Removal of CacheURL DS Field from ATC
Posted by "Gray, Jonathan" <Jo...@comcast.com>.
It was a little fuzzy because removal of field doesn't necessarily remove the functionality. I went with normal deprecation policy of 1 major rev because it does entail a significant operational cost to be paid (which should motivate you to jump to cachekey anyway). Also in terms of sequence of operations I wanted to have the issue open first so I could have the mailing list discussion and deprecation notice PR linked into the issue so someday a developer is empowered to actually do the work.
Jonathan G
On 1/31/19, 10:30 AM, "Rawlin Peters" <ra...@gmail.com> wrote:
Good point, Chris. I think deprecation notices should be placed in
CHANGELOG.md. As a project we need to start getting better at updating
the changelog with any significant changes that have been made
(including deprecation notices), because it should really be the
project's main entrypoint for anyone wanting to know what's changed
and should link to more detailed information in the docs where needed.
That said, it looks like Jonathan already added this deprecation
notice to CHANGELOG.md. Thanks, Jonathan!
- Rawlin
On Thu, Jan 31, 2019 at 9:13 AM Chris Lemmons <al...@gmail.com> wrote:
>
> > I'm also going to declare this to be the deprecation notice in 3.x.
>
> I don't really object, but do we have a specific spot to put
> deprecation notices? Like, in the readme or on the website? Seems like
> that would be useful, if we don't.
>
> On Tue, Jan 29, 2019 at 4:15 PM Gray, Jonathan
> <Jo...@comcast.com> wrote:
> >
> > Since I haven't heard an objection, I'm going to declare consensus on the removal of this field from the data model. Because the removal of this field would require a significant change to delivery services rooted in older versions of ATS which use it, I'm also going to declare this to be the deprecation notice in 3.x.
> >
> > Jonathan Gray
> >
> >
> > On 1/22/19, 8:31 AM, "Gray, Jonathan" <Jo...@comcast.com> wrote:
> >
> > If a deprecation notice would be needed, that's ok. I would assume regardless there would need to be consensus first. Then I can add this email thread to the ticket so we remember down the road.
> >
> > Jonathan G
> >
> >
> > On 1/18/19, 1:41 PM, "Rawlin Peters" <ra...@gmail.com> wrote:
> >
> > +1. The raw remap line sounds like a reasonable workaround for people
> > still on ATS 6. That said, stuff like this typically requires a
> > deprecation notice before removal.
> >
> > - Rawlin
> >
> > On Fri, Jan 18, 2019 at 10:58 AM Fieck, Brennan
> > <Br...@comcast.com> wrote:
> > >
> > > +a million on not supporting a product that has reached it's EOL
> > > (definitely not biased to set a precedent for Python 2)
> > > ________________________________________
> > > From: Gray, Jonathan <Jo...@comcast.com>
> > > Sent: Wednesday, January 16, 2019 9:42 AM
> > > To: dev@trafficcontrol.apache.org
> > > Subject: [EXTERNAL] Removal of CacheURL DS Field from ATC
> > >
> > > Hello all,
> > >
> > > I’d like to get consensus on https://github.com/apache/trafficcontrol/issues/3225 . If we remove the CacheURL delivery service field, you can still use ATS 6 if you must, you’ll just have to use the raw remap text field by hand instead of leaning on TO to generate the config for you. That said, if you’re still on ATS 6 and are doing that, you’re better off upgrading to the more powerful cachekey plugin instead that is supported in ATS 6 and beyond. As ATC supports newer versions of ATS, this is creating extra cruft for new users to stumble across and learn about the hard way not to do.
> > >
> > > Jonathan G
> >
> >
> >
> >
Re: [EXTERNAL] Re: Removal of CacheURL DS Field from ATC
Posted by Rawlin Peters <ra...@gmail.com>.
Good point, Chris. I think deprecation notices should be placed in
CHANGELOG.md. As a project we need to start getting better at updating
the changelog with any significant changes that have been made
(including deprecation notices), because it should really be the
project's main entrypoint for anyone wanting to know what's changed
and should link to more detailed information in the docs where needed.
That said, it looks like Jonathan already added this deprecation
notice to CHANGELOG.md. Thanks, Jonathan!
- Rawlin
On Thu, Jan 31, 2019 at 9:13 AM Chris Lemmons <al...@gmail.com> wrote:
>
> > I'm also going to declare this to be the deprecation notice in 3.x.
>
> I don't really object, but do we have a specific spot to put
> deprecation notices? Like, in the readme or on the website? Seems like
> that would be useful, if we don't.
>
> On Tue, Jan 29, 2019 at 4:15 PM Gray, Jonathan
> <Jo...@comcast.com> wrote:
> >
> > Since I haven't heard an objection, I'm going to declare consensus on the removal of this field from the data model. Because the removal of this field would require a significant change to delivery services rooted in older versions of ATS which use it, I'm also going to declare this to be the deprecation notice in 3.x.
> >
> > Jonathan Gray
> >
> >
> > On 1/22/19, 8:31 AM, "Gray, Jonathan" <Jo...@comcast.com> wrote:
> >
> > If a deprecation notice would be needed, that's ok. I would assume regardless there would need to be consensus first. Then I can add this email thread to the ticket so we remember down the road.
> >
> > Jonathan G
> >
> >
> > On 1/18/19, 1:41 PM, "Rawlin Peters" <ra...@gmail.com> wrote:
> >
> > +1. The raw remap line sounds like a reasonable workaround for people
> > still on ATS 6. That said, stuff like this typically requires a
> > deprecation notice before removal.
> >
> > - Rawlin
> >
> > On Fri, Jan 18, 2019 at 10:58 AM Fieck, Brennan
> > <Br...@comcast.com> wrote:
> > >
> > > +a million on not supporting a product that has reached it's EOL
> > > (definitely not biased to set a precedent for Python 2)
> > > ________________________________________
> > > From: Gray, Jonathan <Jo...@comcast.com>
> > > Sent: Wednesday, January 16, 2019 9:42 AM
> > > To: dev@trafficcontrol.apache.org
> > > Subject: [EXTERNAL] Removal of CacheURL DS Field from ATC
> > >
> > > Hello all,
> > >
> > > I’d like to get consensus on https://github.com/apache/trafficcontrol/issues/3225 . If we remove the CacheURL delivery service field, you can still use ATS 6 if you must, you’ll just have to use the raw remap text field by hand instead of leaning on TO to generate the config for you. That said, if you’re still on ATS 6 and are doing that, you’re better off upgrading to the more powerful cachekey plugin instead that is supported in ATS 6 and beyond. As ATC supports newer versions of ATS, this is creating extra cruft for new users to stumble across and learn about the hard way not to do.
> > >
> > > Jonathan G
> >
> >
> >
> >
Re: [EXTERNAL] Re: Removal of CacheURL DS Field from ATC
Posted by Chris Lemmons <al...@gmail.com>.
> I'm also going to declare this to be the deprecation notice in 3.x.
I don't really object, but do we have a specific spot to put
deprecation notices? Like, in the readme or on the website? Seems like
that would be useful, if we don't.
On Tue, Jan 29, 2019 at 4:15 PM Gray, Jonathan
<Jo...@comcast.com> wrote:
>
> Since I haven't heard an objection, I'm going to declare consensus on the removal of this field from the data model. Because the removal of this field would require a significant change to delivery services rooted in older versions of ATS which use it, I'm also going to declare this to be the deprecation notice in 3.x.
>
> Jonathan Gray
>
>
> On 1/22/19, 8:31 AM, "Gray, Jonathan" <Jo...@comcast.com> wrote:
>
> If a deprecation notice would be needed, that's ok. I would assume regardless there would need to be consensus first. Then I can add this email thread to the ticket so we remember down the road.
>
> Jonathan G
>
>
> On 1/18/19, 1:41 PM, "Rawlin Peters" <ra...@gmail.com> wrote:
>
> +1. The raw remap line sounds like a reasonable workaround for people
> still on ATS 6. That said, stuff like this typically requires a
> deprecation notice before removal.
>
> - Rawlin
>
> On Fri, Jan 18, 2019 at 10:58 AM Fieck, Brennan
> <Br...@comcast.com> wrote:
> >
> > +a million on not supporting a product that has reached it's EOL
> > (definitely not biased to set a precedent for Python 2)
> > ________________________________________
> > From: Gray, Jonathan <Jo...@comcast.com>
> > Sent: Wednesday, January 16, 2019 9:42 AM
> > To: dev@trafficcontrol.apache.org
> > Subject: [EXTERNAL] Removal of CacheURL DS Field from ATC
> >
> > Hello all,
> >
> > I’d like to get consensus on https://github.com/apache/trafficcontrol/issues/3225 . If we remove the CacheURL delivery service field, you can still use ATS 6 if you must, you’ll just have to use the raw remap text field by hand instead of leaning on TO to generate the config for you. That said, if you’re still on ATS 6 and are doing that, you’re better off upgrading to the more powerful cachekey plugin instead that is supported in ATS 6 and beyond. As ATC supports newer versions of ATS, this is creating extra cruft for new users to stumble across and learn about the hard way not to do.
> >
> > Jonathan G
>
>
>
>
Re: [EXTERNAL] Re: Removal of CacheURL DS Field from ATC
Posted by "Gray, Jonathan" <Jo...@comcast.com>.
Since I haven't heard an objection, I'm going to declare consensus on the removal of this field from the data model. Because the removal of this field would require a significant change to delivery services rooted in older versions of ATS which use it, I'm also going to declare this to be the deprecation notice in 3.x.
Jonathan Gray
On 1/22/19, 8:31 AM, "Gray, Jonathan" <Jo...@comcast.com> wrote:
If a deprecation notice would be needed, that's ok. I would assume regardless there would need to be consensus first. Then I can add this email thread to the ticket so we remember down the road.
Jonathan G
On 1/18/19, 1:41 PM, "Rawlin Peters" <ra...@gmail.com> wrote:
+1. The raw remap line sounds like a reasonable workaround for people
still on ATS 6. That said, stuff like this typically requires a
deprecation notice before removal.
- Rawlin
On Fri, Jan 18, 2019 at 10:58 AM Fieck, Brennan
<Br...@comcast.com> wrote:
>
> +a million on not supporting a product that has reached it's EOL
> (definitely not biased to set a precedent for Python 2)
> ________________________________________
> From: Gray, Jonathan <Jo...@comcast.com>
> Sent: Wednesday, January 16, 2019 9:42 AM
> To: dev@trafficcontrol.apache.org
> Subject: [EXTERNAL] Removal of CacheURL DS Field from ATC
>
> Hello all,
>
> I’d like to get consensus on https://github.com/apache/trafficcontrol/issues/3225 . If we remove the CacheURL delivery service field, you can still use ATS 6 if you must, you’ll just have to use the raw remap text field by hand instead of leaning on TO to generate the config for you. That said, if you’re still on ATS 6 and are doing that, you’re better off upgrading to the more powerful cachekey plugin instead that is supported in ATS 6 and beyond. As ATC supports newer versions of ATS, this is creating extra cruft for new users to stumble across and learn about the hard way not to do.
>
> Jonathan G
Re: [EXTERNAL] Re: Removal of CacheURL DS Field from ATC
Posted by Rawlin Peters <ra...@gmail.com>.
It's been a week and no one has -1'd yet, so I think it's safe to say
an informal "lazy consensus" has been achieved. Anyone who wants to
take on that work should be able to do so freely.
- Rawlin
On Tue, Jan 22, 2019 at 8:31 AM Gray, Jonathan
<Jo...@comcast.com> wrote:
>
> If a deprecation notice would be needed, that's ok. I would assume regardless there would need to be consensus first. Then I can add this email thread to the ticket so we remember down the road.
>
> Jonathan G
>
>
> On 1/18/19, 1:41 PM, "Rawlin Peters" <ra...@gmail.com> wrote:
>
> +1. The raw remap line sounds like a reasonable workaround for people
> still on ATS 6. That said, stuff like this typically requires a
> deprecation notice before removal.
>
> - Rawlin
>
> On Fri, Jan 18, 2019 at 10:58 AM Fieck, Brennan
> <Br...@comcast.com> wrote:
> >
> > +a million on not supporting a product that has reached it's EOL
> > (definitely not biased to set a precedent for Python 2)
> > ________________________________________
> > From: Gray, Jonathan <Jo...@comcast.com>
> > Sent: Wednesday, January 16, 2019 9:42 AM
> > To: dev@trafficcontrol.apache.org
> > Subject: [EXTERNAL] Removal of CacheURL DS Field from ATC
> >
> > Hello all,
> >
> > I’d like to get consensus on https://github.com/apache/trafficcontrol/issues/3225 . If we remove the CacheURL delivery service field, you can still use ATS 6 if you must, you’ll just have to use the raw remap text field by hand instead of leaning on TO to generate the config for you. That said, if you’re still on ATS 6 and are doing that, you’re better off upgrading to the more powerful cachekey plugin instead that is supported in ATS 6 and beyond. As ATC supports newer versions of ATS, this is creating extra cruft for new users to stumble across and learn about the hard way not to do.
> >
> > Jonathan G
>
>