You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficcontrol.apache.org by "Durfey, Ryan" <Ry...@comcast.com> on 2017/09/01 20:12:33 UTC

Configuration Management - Generic Configuration for Caches and Components

Opening a new thread on Generic Configuration as discussed in our meeting.  I drew a sketch (probably inaccurate) to prompt conversation.  If you can’t see it in the email there is a link to the wiki below where you can see it.  Please keep responses in the email thread (vs. wiki). I will summarize once we conclude debate.

Ryan

Generic_Configuration<https://cwiki.apache.org/#ConfigurationManagement-Generic_Configuration>

  *   There is a desire to move to a generic configuration that is stored by Traffic Ops DB that could be interpreted separately for each CDN component or cache type
  *   We are not exactly sure where interpretation gets done but probably in a separate Traffic Ops module before it is pushed out to the component
     *   It could exist on the component, however in the case of edge caches it might not be efficient to operate an interpreter under heavy loads
  *   It would be the responsibility of the Cache or Component development team to write the interpreter of the generic config file
     *   So if you want to use Varnish caches you would be responsible for writing a Varnish interpreter for the generic configuration file
  *   One issue we might experience is that some cache engines may require new configuration parameters that don't exist in prior engines.
     *    In this case we would need to add something upstream.  Other engines would need to ignore this parameter, which is probably not a problem so long as we go in knowing they can ignore unrecognized parameters without crashing.

[https://cwiki.apache.org/confluence/download/attachments/69405446/image2017-9-1%2013%3A46%3A3.png?version=1&modificationDate=1504295163661&api=v2]


Ryan Durfey
Sr. Product Manager - CDN | Comcast Technology Solutions
1899 Wynkoop Ste. 550 | Denver, CO 80202
M | 303-524-5099
ryan_durfey@comcast.com<ma...@comcast.com>
CDN Support (24x7): 866-405-2993 or cdn_support@comcast.com<ma...@comcast.com>

Re: Configuration Management - Generic Configuration for Caches and Components

Posted by "Durfey, Ryan" <Ry...@comcast.com>.
 Recirculating this topic as well.

Ryan

On Fri, Sep 1, 2017 at 4:12 PM, Durfey, Ryan <Ry...@comcast.com>>
wrote:

Opening a new thread on Generic Configuration as discussed in our
meeting.  I drew a sketch (probably inaccurate) to prompt conversation.  If
you can’t see it in the email there is a link to the wiki below where you
can see it.  Please keep responses in the email thread (vs. wiki). I will
summarize once we conclude debate.



Ryan


Generic_Configuration
https://cwiki.apache.org/confluence/display/TC/Configuration+Management

    - There is a desire to move to a generic configuration that is stored
    by Traffic Ops DB that could be interpreted separately for each CDN
    component or cache type
    - We are not exactly sure where interpretation gets done but probably
    in a separate Traffic Ops module before it is pushed out to the component
       - It could exist on the component, however in the case of edge
       caches it might not be efficient to operate an interpreter under heavy loads
    - It would be the responsibility of the Cache or Component development
    team to write the interpreter of the generic config file
       - So if you want to use Varnish caches you would be responsible for
       writing a Varnish interpreter for the generic configuration file
    - One issue we might experience is that some cache engines may require
    new configuration parameters that don't exist in prior engines.
       -  In this case we would need to add something upstream.  Other
       engines would need to ignore this parameter, which is probably not a
       problem so long as we go in knowing they can ignore unrecognized parameters
       without crashing.



[image:
https://cwiki.apache.org/confluence/download/attachments/69405446/image2017-9-1%2013%3A46%3A3.png?version=1&modificationDate=1504295163661&api=v2]





*Ryan Durfey*

Sr. Product Manager - CDN | Comcast Technology Solutions

1899 Wynkoop Ste. 550 | Denver, CO 80202

M | 303-524-5099 <(303)%20524-5099>

ryan_durfey@comcast.com<ma...@comcast.com>

CDN Support (24x7): 866-405-2993 <(866)%20405-2993> or
cdn_support@comcast.com<ma...@comcast.com>

Re: Configuration Management - Generic Configuration for Caches and Components

Posted by "Durfey, Ryan" <Ry...@comcast.com>.
We are on ATS 6.2 right now and working towards 7.x.  Chris Lemmons is working on the cache url issue so we can upgrade to ATS 7.x and he can comment further.

Ryan Durfey    M | 303-524-5099
CDN Support (24x7): 866-405-2993 or cdn_support@comcast.com<ma...@comcast.com>


From: Steve Malenfant <sm...@gmail.com>
Reply-To: "dev@trafficcontrol.incubator.apache.org" <de...@trafficcontrol.incubator.apache.org>
Date: Wednesday, September 6, 2017 at 5:42 PM
To: "dev@trafficcontrol.incubator.apache.org" <de...@trafficcontrol.incubator.apache.org>
Subject: Re: Configuration Management - Generic Configuration for Caches and Components

Ryan,

I'm just going through what it takes to upgrade Traffic Server from 5.3.2
to 7.1 right now. There is a few things that changed in the configuration
which are easy to take care of, some others are not.

The easy one which I'm already taking care of :
- logs_xmls.config changed to logging.config (#1126)
- ORT change to use traffic_ctl instead traffic_line (#1128)

The one that will require some heavier work (github issue #1130) :
- cacheurl is deprecated, but the UI and API is specific to cacheurl.
Should be a good time to rename those and document how they should be used.
This is a "specific" Traffic Server case which actually becomes an issue
between version. The new plugin is called "cachekey".

I would like some feedback on how we can resolve issues between traffic
server as the profiles can't handle this at the moment. This is where the
"client" side processing of specific features would be nice.

Thanks,

Steve


On Fri, Sep 1, 2017 at 4:12 PM, Durfey, Ryan <Ry...@comcast.com>>
wrote:

Opening a new thread on Generic Configuration as discussed in our
meeting.  I drew a sketch (probably inaccurate) to prompt conversation.  If
you can’t see it in the email there is a link to the wiki below where you
can see it.  Please keep responses in the email thread (vs. wiki). I will
summarize once we conclude debate.



Ryan


Generic_Configuration
<https://cwiki.apache.org/#ConfigurationManagement-Generic_Configuration>

    - There is a desire to move to a generic configuration that is stored
    by Traffic Ops DB that could be interpreted separately for each CDN
    component or cache type
    - We are not exactly sure where interpretation gets done but probably
    in a separate Traffic Ops module before it is pushed out to the component
       - It could exist on the component, however in the case of edge
       caches it might not be efficient to operate an interpreter under heavy loads
    - It would be the responsibility of the Cache or Component development
    team to write the interpreter of the generic config file
       - So if you want to use Varnish caches you would be responsible for
       writing a Varnish interpreter for the generic configuration file
    - One issue we might experience is that some cache engines may require
    new configuration parameters that don't exist in prior engines.
       -  In this case we would need to add something upstream.  Other
       engines would need to ignore this parameter, which is probably not a
       problem so long as we go in knowing they can ignore unrecognized parameters
       without crashing.



[image:
https://cwiki.apache.org/confluence/download/attachments/69405446/image2017-9-1%2013%3A46%3A3.png?version=1&modificationDate=1504295163661&api=v2]





*Ryan Durfey*

Sr. Product Manager - CDN | Comcast Technology Solutions

1899 Wynkoop Ste. 550 | Denver, CO 80202

M | 303-524-5099 <(303)%20524-5099>

ryan_durfey@comcast.com<ma...@comcast.com>

CDN Support (24x7): 866-405-2993 <(866)%20405-2993> or
cdn_support@comcast.com<ma...@comcast.com>

Re: Configuration Management - Generic Configuration for Caches and Components

Posted by Steve Malenfant <sm...@gmail.com>.
Ryan,

I'm just going through what it takes to upgrade Traffic Server from 5.3.2
to 7.1 right now. There is a few things that changed in the configuration
which are easy to take care of, some others are not.

The easy one which I'm already taking care of :
- logs_xmls.config changed to logging.config (#1126)
- ORT change to use traffic_ctl instead traffic_line (#1128)

The one that will require some heavier work (github issue #1130) :
- cacheurl is deprecated, but the UI and API is specific to cacheurl.
Should be a good time to rename those and document how they should be used.
This is a "specific" Traffic Server case which actually becomes an issue
between version. The new plugin is called "cachekey".

I would like some feedback on how we can resolve issues between traffic
server as the profiles can't handle this at the moment. This is where the
"client" side processing of specific features would be nice.

Thanks,

Steve


On Fri, Sep 1, 2017 at 4:12 PM, Durfey, Ryan <Ry...@comcast.com>
wrote:

> Opening a new thread on Generic Configuration as discussed in our
> meeting.  I drew a sketch (probably inaccurate) to prompt conversation.  If
> you can’t see it in the email there is a link to the wiki below where you
> can see it.  Please keep responses in the email thread (vs. wiki). I will
> summarize once we conclude debate.
>
>
>
> Ryan
>
>
> Generic_Configuration
> <https://cwiki.apache.org/#ConfigurationManagement-Generic_Configuration>
>
>    - There is a desire to move to a generic configuration that is stored
>    by Traffic Ops DB that could be interpreted separately for each CDN
>    component or cache type
>    - We are not exactly sure where interpretation gets done but probably
>    in a separate Traffic Ops module before it is pushed out to the component
>       - It could exist on the component, however in the case of edge
>       caches it might not be efficient to operate an interpreter under heavy loads
>    - It would be the responsibility of the Cache or Component development
>    team to write the interpreter of the generic config file
>       - So if you want to use Varnish caches you would be responsible for
>       writing a Varnish interpreter for the generic configuration file
>    - One issue we might experience is that some cache engines may require
>    new configuration parameters that don't exist in prior engines.
>       -  In this case we would need to add something upstream.  Other
>       engines would need to ignore this parameter, which is probably not a
>       problem so long as we go in knowing they can ignore unrecognized parameters
>       without crashing.
>
>
>
> [image:
> https://cwiki.apache.org/confluence/download/attachments/69405446/image2017-9-1%2013%3A46%3A3.png?version=1&modificationDate=1504295163661&api=v2]
>
>
>
>
>
> *Ryan Durfey*
>
> Sr. Product Manager - CDN | Comcast Technology Solutions
>
> 1899 Wynkoop Ste. 550 | Denver, CO 80202
>
> M | 303-524-5099 <(303)%20524-5099>
>
> ryan_durfey@comcast.com
>
> CDN Support (24x7): 866-405-2993 <(866)%20405-2993> or
> cdn_support@comcast.com
>
>
>