Re: Proposal for CDN definition file based configuration management

[David Neuman]

The discussion around delivery service configs should probably be it's own
thread, however I am going to contribute to the hijacking of this thread
anyway.

We need to make sure that we keep the Traffic Router in mind when
discussing delivery service changes that get applied "instantly" and
individually.  There are certain attributes of a delivery service that
affect the Traffic Router and we need to make sure that we don't cause an
issue by pushing a config to a cache before the Traffic Router has it or
visa-versa.

On Fri, Apr 14, 2017 at 8:07 AM, Amir Yeshurun  wrote:

> It seems that with Nir's approach there is no problem to enforce a size
> limit on historical data
>
> On Fri, Apr 14, 2017 at 4:07 PM Eric Friedrich (efriedri) <
> efrie...@cisco.com> wrote:
>
> > I think this sounds good Nir.
> >
> > Its not so much the size that is the main concern. Rather, people tend to
> > have strong reactions to “its permanent, it will be there forever”. As
> long
> > as we give some way to delete and preferably with a batch mode we should
> be
> > all set.
> >
> > —Eric
> >
> > > On Apr 13, 2017, at 3:08 PM, Nir Sopher  wrote:
> > >
> > > Hi Eric,
> > >
> > > I thought to start with saving for each configuration the range of
> dates
> > it
> > > was the "head" revision, and the range of dates it was deployed.
> > > This will allow the operator to remove old versions via designated
> script
> > > using criteria like "configuration age", "ds history length" or "was it
> > > deployed". For example "Leave all deployed revisions and up to 100 non
> > > deployed revisions".
> > > I haven't thought of the option to support the marking of configuration
> > > versions as "never delete", but it can surely be added.
> > >
> > > I did not intended to create something more sophisticated, and believe
> > that
> > > the mentioned script will be used only on rare cases that something is
> > > trashing the DB, as the math I did lead me to believe it is a none
> issue:
> > > Judging from the kable-town example, a delivery-service configuration
> > size
> > > is less than 500B. Lets say the average is *1K *to support future
> growth.
> > > Lets also say we support *10K *DSs (which is much much more than any TC
> > > deployment I'm aware of has) and we have *1K *revisions per DS.
> > > In such a case versioning will use 10GB, which I believe is not an
> issue
> > > for postgres to hold (yet, I'm not a postgres expert).
> > >
> > > Nir
> > >
> > >
> > > On Thu, Apr 13, 2017 at 3:53 PM, Eric Friedrich (efriedri) <
> > > efrie...@cisco.com> wrote:
> > >
> > >> Hey Nir-
> > >>  If we keep all DS versions in the DB, are there any concerns about
> the
> > >> amount of data retained? I know Delivery Services don’t change very
> > often,
> > >> but over time do we really need to keep the last 1000 revisions of a
> > >> delivery service?
> > >>
> > >> Its more of an implementation detail, but I think it would be useful
> to
> > >> give some control over version retention policies (i.e. keep last n
> > based
> > >> on quantity or dates, mark some as “never delete”)
> > >>
> > >> More inline
> > >>> On Apr 12, 2017, at 12:53 AM, Nir Sopher  wrote:
> > >>>
> > >>> Thanks Derek for the clarification.
> > >>>
> > >>> So the definition file is a global file for the CDN.
> > >>> Does it contain the information of which server has which DS?
> > >>> Does it hold all CDN's DSs configuration together?
> > >>> On a single DS change, will all servers in the CDN download the
> entire
> > >> file
> > >>> for every DS change?
> > >>>
> > >>> What I'm practically asking is, if it is not already your intention,
> > "can
> > >>> the definition file hold only the information of which server holds
> > which
> > >>> DS (and configuration version when we add it), and the DS
> configuration
> > >> be
> > >>> held and pulled separately on a DS level granularity?"
> > >>>
> > >>> When discussing "self-service" we would like to decouple the
> operations
> > >> of
> > >>> the different users / content providers. Ultimately, when a DS is
> > >> changed,
> > >>> the change should be deployed immediately to the CDN - with no
> > dependency
> > >>> with other DSs, and possibly with "no buffering" by the operator
> > >> deploying
> > >>> batch of DS changes together. This allows to improve the user
> > experience
> > >>> and independence when working on the CDN.
> > >>> Following the change you are suggesting, will the DS configuration
> > >>> deployment coupling get tighter? We prefer not to have the need to
> > >> "finish
> > >>> your work and not start additional work before the queued run has
> > >>> completed".
> > >> EF> Agree. The less steps our users have to take, the happier they
> are.
> > If
> > >> it was a common workflow to batch a bunch of DS changes and them roll
> > them
> > >> out together, I would probably be a stronger advocate for keeping the
> > queue
> > >> update/snapshot crconfig steps around. In 

Re: Multiple custom access log files for ATS

[Jan van Doorn]

I don’t see an issue, provided you make it backwards compatible, and it looks 
like you are.

Rgds,
JvD

> On Apr 14, 2017, at 12:04 AM, John Shen (weifensh)  wrote:
> 
> Currently TO supports only one custom access log file by configuring the 
> "LogFormat" and "LogObject" parameters for "logs_xml.config". We have a 
> requirement to support multiple custom access log files. As ATS does support 
> this, we are planning to extend "LogFormat"&"LogObject" on TO, and add extra 
> 9 groups (9 should be enough) of parameters like: "LogFormat1"&"LogObject1", 
> "LogFormat2"&"LogObject2" ... "LogFormat9"&"LogObject9". Only when 
> "LogFormatN"&"LogObjectN" are configured, they will appear in 
> "logs_xml.config"; otherwise the file does not change, so the current 
> behavior does not change either. Any comment for this plan?
> 
> Thanks,
> John
> 

Re: Proposal for CDN definition file based configuration management

[Eric Friedrich (efriedri)]

I think this sounds good Nir. 

Its not so much the size that is the main concern. Rather, people tend to have 
strong reactions to “its permanent, it will be there forever”. As long as we 
give some way to delete and preferably with a batch mode we should be all set.

—Eric

> On Apr 13, 2017, at 3:08 PM, Nir Sopher  wrote:
> 
> Hi Eric,
> 
> I thought to start with saving for each configuration the range of dates it
> was the "head" revision, and the range of dates it was deployed.
> This will allow the operator to remove old versions via designated script
> using criteria like "configuration age", "ds history length" or "was it
> deployed". For example "Leave all deployed revisions and up to 100 non
> deployed revisions".
> I haven't thought of the option to support the marking of configuration
> versions as "never delete", but it can surely be added.
> 
> I did not intended to create something more sophisticated, and believe that
> the mentioned script will be used only on rare cases that something is
> trashing the DB, as the math I did lead me to believe it is a none issue:
> Judging from the kable-town example, a delivery-service configuration size
> is less than 500B. Lets say the average is *1K *to support future growth.
> Lets also say we support *10K *DSs (which is much much more than any TC
> deployment I'm aware of has) and we have *1K *revisions per DS.
> In such a case versioning will use 10GB, which I believe is not an issue
> for postgres to hold (yet, I'm not a postgres expert).
> 
> Nir
> 
> 
> On Thu, Apr 13, 2017 at 3:53 PM, Eric Friedrich (efriedri) <
> efrie...@cisco.com> wrote:
> 
>> Hey Nir-
>>  If we keep all DS versions in the DB, are there any concerns about the
>> amount of data retained? I know Delivery Services don’t change very often,
>> but over time do we really need to keep the last 1000 revisions of a
>> delivery service?
>> 
>> Its more of an implementation detail, but I think it would be useful to
>> give some control over version retention policies (i.e. keep last n based
>> on quantity or dates, mark some as “never delete”)
>> 
>> More inline
>>> On Apr 12, 2017, at 12:53 AM, Nir Sopher  wrote:
>>> 
>>> Thanks Derek for the clarification.
>>> 
>>> So the definition file is a global file for the CDN.
>>> Does it contain the information of which server has which DS?
>>> Does it hold all CDN's DSs configuration together?
>>> On a single DS change, will all servers in the CDN download the entire
>> file
>>> for every DS change?
>>> 
>>> What I'm practically asking is, if it is not already your intention, "can
>>> the definition file hold only the information of which server holds which
>>> DS (and configuration version when we add it), and the DS configuration
>> be
>>> held and pulled separately on a DS level granularity?"
>>> 
>>> When discussing "self-service" we would like to decouple the operations
>> of
>>> the different users / content providers. Ultimately, when a DS is
>> changed,
>>> the change should be deployed immediately to the CDN - with no dependency
>>> with other DSs, and possibly with "no buffering" by the operator
>> deploying
>>> batch of DS changes together. This allows to improve the user experience
>>> and independence when working on the CDN.
>>> Following the change you are suggesting, will the DS configuration
>>> deployment coupling get tighter? We prefer not to have the need to
>> "finish
>>> your work and not start additional work before the queued run has
>>> completed".
>> EF> Agree. The less steps our users have to take, the happier they are. If
>> it was a common workflow to batch a bunch of DS changes and them roll them
>> out together, I would probably be a stronger advocate for keeping the queue
>> update/snapshot crconfig steps around. In our discussion, that doesn’t seem
>> to be often used. Should we consider deprecating those stages and
>> immediately (excepting ORT polling interval of course) applying config
>> changes when the DS is changed?
>> 
>>> 
>>> Another requirement is to be able to rollback changes on a DS level and
>> not
>>> only on a CDN level, as it is not desired to rollback changes of user "A"
>>> because of errors of user "B". If I understand correctly, the definition
>>> file does not support that.
>> EF> I think the definition file can support this- only the rolled-back DS
>> would change inside that file. No other users would be affected because
>> their DS configs would not change.
>> 
>>> 
>>> Last, using the definition file, must all servers in a CDN work with the
>>> same set of DSs? One of the reasons we consider "DS versioning" is to
>> allow
>>> deployment of a change in a DS only for a subset of the server for canary
>>> testing.
>> EF> When I think of canary testing today, my mind first goes to Steering
>> DS. With those steering delivery services, do we still need ability to set
>> per-cache DS versions?
>> 
>> —Eric
>> 
>> 
>>> 
>>> Thanks,
>>> Nir
>>> 
>>> 
>>> 
>>> 

Multiple custom access log files for ATS

[John Shen (weifensh)]

Currently TO supports only one custom access log file by configuring the 
"LogFormat" and "LogObject" parameters for "logs_xml.config". We have a 
requirement to support multiple custom access log files. As ATS does support 
this, we are planning to extend "LogFormat"&"LogObject" on TO, and add extra 9 
groups (9 should be enough) of parameters like: "LogFormat1"&"LogObject1", 
"LogFormat2"&"LogObject2" ... "LogFormat9"&"LogObject9". Only when 
"LogFormatN"&"LogObjectN" are configured, they will appear in 
"logs_xml.config"; otherwise the file does not change, so the current behavior 
does not change either. Any comment for this plan?

Thanks,
John