Re: cdn table and domain_name parameter?

[Mark Torluemke]

Agree, I also believe the CCR profile <> deliveryservice mapping is
superfluous, now that there is a link from cdn <> deliveryservice. This was
discussed when the 'cdn' table was being implemented, but perhaps too late
into the implementation phase. Further, I also agree that the domain_name
parameter should be moved to the 'cdn' table, or its own table entirely,
with a link to the 'cdn' table.

On Mon, Dec 26, 2016 at 8:14 AM, Jan van Doorn  wrote:

> Looking at the ATS 6.2 support for TO which requires a deliveryservice to
> profile mapping, and was wondering why we still have the profile column
> (CCR Profile) in deliveryservice?
>
> At first glance it seems to be used for the domain_name parameter only
> (?), and that could (should?) be moved to the cdn table? Not sure if this
> was considered when the cdn table was added and decided against for a good
> reason?
>
> Cheers,
> JvD
>
>

ATS 6.2 support in Traffic Ops

[Mark Torluemke]

Spawning a different email thread from Jan's original for the topic in the
edited subject line.

Thanks,
Mark

On Mon, Dec 26, 2016 at 8:14 AM, Jan van Doorn  wrote:

> Looking at the ATS 6.2 support for TO which requires a deliveryservice to
> profile mapping, and was wondering why we still have the profile column
> (CCR Profile) in deliveryservice?
>

Feels like Delivery Services should get Parameters (in the same way
Profiles and Cache Groups have them) to support the multi-site origin
concepts. Maybe just a typo above?


>
> At first glance it seems to be used for the domain_name parameter only
> (?), and that could (should?) be moved to the cdn table? Not sure if this
> was considered when the cdn table was added and decided against for a good
> reason?
>
> Cheers,
> JvD
>
>

Re: ATS 6.2 support in Traffic Ops

[Mark Torluemke]

Yeah, if a deployment has many essentially replicated MSO delivery
services, I can certainly see the advantage of making a template for the
settings.

I'm not sure on the actual implementation -- which profile would the params
go on -- each of the origin ones? Might result in a bunch of profiles
necessary to just change one parameter (thinking HTTP response codes).
Another thing to consider -- we typically make a separate origin profile to
make the cache group hierarchy correct, and a separate profile for
different origin 'weights' (@dg4prez might weigh in, in case I misspoke). I
think the cache group topology is good descriptive information for a
profile, but the 'weight' parameter is something that could also go in a
template concept.


On Mon, Dec 26, 2016 at 9:28 AM, Jan van Doorn  wrote:

> You mean we should have deliveryservice <-> parameter directly and not
> deliveryservice <-> profile <-> parameter ?
>
> I think I like using a profile here better. I could see how a set of these
> setting could be re-used over and over again, like a template?
>
> Rgds,
> JvD
>
>
>
> > On Dec 26, 2016, at 09:21, Mark Torluemke  wrote:
> >
> > Spawning a different email thread from Jan's original for the topic in
> the
> > edited subject line.
> >
> > Thanks,
> > Mark
> >
> > On Mon, Dec 26, 2016 at 8:14 AM, Jan van Doorn  wrote:
> >
> >> Looking at the ATS 6.2 support for TO which requires a deliveryservice
> to
> >> profile mapping, and was wondering why we still have the profile column
> >> (CCR Profile) in deliveryservice?
> >>
> >
> > Feels like Delivery Services should get Parameters (in the same way
> > Profiles and Cache Groups have them) to support the multi-site origin
> > concepts. Maybe just a typo above?
> >
> >
> >>
> >> At first glance it seems to be used for the domain_name parameter only
> >> (?), and that could (should?) be moved to the cdn table? Not sure if
> this
> >> was considered when the cdn table was added and decided against for a
> good
> >> reason?
> >>
> >> Cheers,
> >> JvD
> >>
> >>
>
>

Re: cdn table and domain_name parameter?

[Mark Torluemke]

On Mon, Dec 26, 2016 at 9:20 AM, Jan van Doorn  wrote:

> > or its own table entirely, with a link to the 'cdn' table.
>
> Do you think we should consider supporting multiple domains per CDN in the
> future? Or is there another use case?
>
>
That's the use case. I'd love to hear folks from the community weigh in, as
it's been a topic for discussion many times, but we haven't had an explicit
request for it.


> Rgds,
> JvD
>
> > On Dec 26, 2016, at 09:13, Mark Torluemke  wrote:
> >
> > Agree, I also believe the CCR profile <> deliveryservice mapping is
> superfluous, now that there is a link from cdn <> deliveryservice. This was
> discussed when the 'cdn' table was being implemented, but perhaps too late
> into the implementation phase. Further, I also agree that the domain_name
> parameter should be moved to the 'cdn' table, or its own table entirely,
> with a link to the 'cdn' table.
> >
> > On Mon, Dec 26, 2016 at 8:14 AM, Jan van Doorn  j...@knutsel.com>> wrote:
> > Looking at the ATS 6.2 support for TO which requires a deliveryservice
> to profile mapping, and was wondering why we still have the profile column
> (CCR Profile) in deliveryservice?
> >
> > At first glance it seems to be used for the domain_name parameter only
> (?), and that could (should?) be moved to the cdn table? Not sure if this
> was considered when the cdn table was added and decided against for a good
> reason?
> >
> > Cheers,
> > JvD
> >
> >
>
>

Re: ATS 6.2 support in Traffic Ops

[Mark Torluemke]

On Mon, Dec 26, 2016 at 9:28 AM, Jan van Doorn  wrote:

> You mean we should have deliveryservice <-> parameter directly and not
> deliveryservice <-> profile <-> parameter ?
>
> I think I like using a profile here better. I could see how a set of these
> setting could be re-used over and over again, like a template?
>
>
Yeah, if a deployment has many essentially replicated MSO delivery
services, I can certainly see the advantage of making a template for the
settings.

I'm not sure on the actual implementation -- which profile would the params
go on -- each of the origin ones? Might result in a bunch of profiles
necessary to just change one parameter (thinking HTTP response codes).
Another thing to consider -- we typically make a separate origin profile to
make the cache group hierarchy correct, and a separate profile for
different origin 'weights' (@dg4prez might weigh in, in case I misspoke). I
think the cache group topology is good descriptive information for a
profile, but the 'weight' parameter is something that could also go in a
template concept.


> Rgds,
> JvD
>
>
>
> > On Dec 26, 2016, at 09:21, Mark Torluemke  wrote:
> >
> > Spawning a different email thread from Jan's original for the topic in
> the
> > edited subject line.
> >
> > Thanks,
> > Mark
> >
> > On Mon, Dec 26, 2016 at 8:14 AM, Jan van Doorn  wrote:
> >
> >> Looking at the ATS 6.2 support for TO which requires a deliveryservice
> to
> >> profile mapping, and was wondering why we still have the profile column
> >> (CCR Profile) in deliveryservice?
> >>
> >
> > Feels like Delivery Services should get Parameters (in the same way
> > Profiles and Cache Groups have them) to support the multi-site origin
> > concepts. Maybe just a typo above?
> >
> >
> >>
> >> At first glance it seems to be used for the domain_name parameter only
> >> (?), and that could (should?) be moved to the cdn table? Not sure if
> this
> >> was considered when the cdn table was added and decided against for a
> good
> >> reason?
> >>
> >> Cheers,
> >> JvD
> >>
> >>
>
>

Re: traffic_ops_ort doesn't update empty config file problem

[Mark Torluemke]

I think the initial thought was to protect against empty files being
generated from Traffic Ops. However, over time that code has potentially
been shifted some, and that is no longer the functionality. :)

So, yes, I think we could skip that check for files already on disk.

On Tue, Jan 3, 2017 at 12:57 AM, Jifeng Yang (jifyang) 
wrote:

> Hi,
>
> We met a problem about traffic_ops_ort:
>
> The ATS config file “remap.config” happened to be zero size. After that,
> the “remap.config” file couldn't be updated by the traffic_ops_ort.
>
> Checking the code in the file “/opt/ort/traffic_ops_ort.pl”, there is:
>
> sub can_read_write_file {
>my $filename = shift;
>..
>if ( -z $file ) {
> ( $log_level >> $ERROR ) && print "ERROR $file has
> size=0!\n";
> $cfg_file_tracker->{$filename}->{'audit_failed'}++;
> return 0;
> }
> ..
> return 1;
> }
>
> By the code, the zero size file isn't treated as can_read_write_file.
>
> Can we treat zero size file as can_read_write_file? Is there any
> consideration about this?
>
> The configuration file may become zero size file by some reason (such as
> by accident). If zero size config file isn't treated as
> can_read_write_file, it can't be updated any more if a configuration file
> becomes zero size.
>
> Thanks,
> Jifeng
>

Re: Server's sarameters - adding some logic

[Mark Torluemke]

On Sun, Jan 29, 2017 at 2:02 PM, Nir Sopher  wrote:

> Thanks Robert.
>
> Indeed. The parameters-profile mechanism practically solves the scalability
> issue.
> BTW, I noticed there is an ability to assign a variable to a cache group.
> Can someone please elaborate on it? I tried it, setting a variable in
> records.config and examining the result file, but it did not work they way
> I expected.
>

These parameters are on the cache group itself, not on the caches that are
in the cache group.


>
> Nir
>
> -- Forwarded message --
> From: "Robert Butts" 
> Date: Jan 26, 2017 5:58 PM
> Subject: Re: Server's sarameters - adding some logic
> To: 
> Cc:
>
> > I think that we should not attempt to invent a scripting language for
> this
> purpose.
> >
> > My guess is that Lua  is a good
> candidate
> for the job.
>
> +1 on both counts.
>
> Though I'm not convinced we need a scripting language in parameters yet.
>
> > Separating into 2 profile is not scalable.
>
> Creating or embedding a scripting language is a pretty big feature. You can
> assign the same parameters to multiple profiles. So all the parameters
> which are the same can be assigned to both profiles, so no parameters are
> duplicated. Arguably, this scenario is exactly why we have the
> Parameters–Profiles system.
>
> On Thu, Jan 26, 2017 at 5:10 AM, Oren Shemesh  wrote:
>
> > I think that we should not attempt to invent a scripting language for
> this
> > purpose.
> >
> > My guess is that Lua  is a good
> candidate
> > for the job.
> > "Lua is a powerful, efficient, lightweight, embeddable scripting
> language".
> > It can be embedded in all popular languages, specifically in perl
> > and
> > (More relevant, I think) in go
> >  > rlz=1C1LENP_enIL506IL506&ion=1&espv=2&ie=UTF-8#q=calling+lua+from+go>
> > .
> >
> >
> >
> > On Thu, Jan 26, 2017 at 12:51 PM, Nir Sopher  wrote:
> >
> > > Hi,
> > >
> > > Working on TC-121 ,
> > allowing
> > > variables to be evaluated as part of a traffic-server parameter, made
> me
> > > realize that the simple solution of variable substitution is might not
> be
> > > strong enough.
> > >
> > > As an example, lets take traffic server ip bind configuration.
> > > Setting :
> > > LOCAL proxy.local.incoming_ip_to_bind
> > > to be:
> > > STRING __CACHE_IPv4__ [__CACHE_IPv6__]
> > >
> > > If the server's IPv6 address is set, it will work nicely.
> > > But if the IPv6 is not set, we will end up with an invalid
> configuration.
> > >
> > > As far as I know, a single profile cannot support both use-cases.
> > > Separating into 2 profile is not scalable. Splitting a profile for this
> > > purpose may result with many profiles, with small differences between
> > them,
> > > which are hard to follow and identify.
> > >
> > > I would like to suggest an improvement that
> > >
> > >- Allow a parameter to be optional.
> > >- Allow some logic in the evaluation of the parameter's value.
> > >
> > > This can be achieved by using expressions to be evaluated in the
> > > parameter's value.
> > > The syntax of course, needs to be discussed, but lets say for example
> > that:
> > > __COND_BEGIN__/__COND_END__ delimits a condition to be evaluated:
> > > One may set a value to be:
> > > STRING __CACHE_IPv4__ __COND_BEGIN__ __CACHE_IPv6__!="" ?
> > [__CACHE_IPv6__]
> > > :
> > >  ""__COND_END__
> > > Having the IPv6 part in the result only if set.
> > >
> > > Furthermore, a special evaluation result string (e.g. __NA__) may
> > identify
> > > parameters that should be omitted from the server's configuration.
> > >
> > >
> > > I would appreciate your view on the issue.
> > >
> > > Thanks,
> > > Nir
> > >
> >
> >
> >
> > --
> >
> > *Oren Shemesh*
> > Qwilt | Work: +972-72-2221637| Mobile: +972-50-2281168 | or...@qwilt.com
> > 
> >
>

Re: Upcoming TC 2.0 Release Branch

[Mark Torluemke]

Agree -- I think sooner-is-better for branching 2.0.

Cheers,
Mark

On Mon, Feb 20, 2017 at 3:57 PM, Jan van Doorn  wrote:

> +100 !
>
> I really want to get some changes in to 2.1.
>
> Thanks,
> JvD
>
> > On Feb 20, 2017, at 1:42 PM, Eric Friedrich  wrote:
> >
> > Hey All-
> >  Its about time to cut our first branch in the 2.0 series and starting
> > testing release candidates.
> >
> > TC1.8 is not quite yet through the incubator voting process, but it
> appears
> > that approval is hopefully quite close. No changes have gone into 1.8 in
> > the past few months, so on top of the move to Postgres we have quite the
> > set of changes in this upcoming release.
> >
> >
> > Unless I hear strong opinions otherwise in the next 2-3 days, I'll cut
> the
> > TC2.0 release branch later this week and bump the master version numbers
> up
> > to 2.1
> >
> >
> > Thanks,
> > Eric
> > Release Manager-elect
>
>

Re: Goose installer script

[Mark Torluemke]

On Sun, Apr 30, 2017 at 7:05 PM, Gelinas, Derek 
wrote:

> +1 on both of these.
>
> > On Apr 30, 2017, at 8:50 PM, Eric Friedrich (efriedri) <
> efrie...@cisco.com> wrote:
> >
> > Assuming we stick with goose, why not bundle goose source into the
> traffic ops RPM? This will pin the version for us and prevent users from
> needing to run go get
>

Dan had put in a PR to add the Goose source:
https://github.com/apache/incubator-trafficcontrol/pull/157

We ended up closing it, as 375,000 lines felt a bit excessive...



> >
> > We are allowed to bundle code with the MIT license into our releases.
> >
> > As for the go installation, what about modifying the RPM spec file to
> list GoLang as a dependency of the traffic ops RPM?
> >
> > —Eric
> >
> >
> >
> >
> >
> >> On Apr 28, 2017, at 4:46 PM, Dewayne Richardson 
> wrote:
> >>
> >> They are, but makes the tooling easier if we are all in Golang
> >>
> >>> On Fri, Apr 28, 2017 at 1:44 PM, Dave Neuman 
> wrote:
> >>>
> >>> I don't see why re-writing the APIs in something like golang would mean
> >>> that we also need to re-write the database admin script.  I think
> those two
> >>> things are mutually exclusive, right?
> >>>
> >>> On Fri, Apr 28, 2017 at 12:29 PM, Dewayne Richardson <
> dewr...@gmail.com>
> >>> wrote:
> >>>
>  I had that thought, as well as there are more recent versions like
>  https://github.com/mattes/migrate.  The question becomes if we ever
> get
>  around to rewriting TrafficOps APIs in golang, will the Perl version
> then
>  become obsolete?
> 
> > On Fri, Apr 28, 2017 at 11:58 AM, Dave Neuman 
> wrote:
> >
> > Maybe it's time we take a look at what goose really buys us and
> >>> consider
> > writing our own database migration tool.  We already have admin.pl,
> it
> > could probably fit in with that?
> >
> > On Fri, Apr 28, 2017 at 11:45 AM, Eric Friedrich (efriedri) <
> > efrie...@cisco.com> wrote:
> >
> >> Hey Dew-
> >> What calls this script?
> >>
> >> If its called from the Traffic Ops Spec file, then this will cause
> >>> some
> >> pain for those of us that need to install without internet access.
> >>
> >> —Eric
> >>
> >>> On Apr 28, 2017, at 12:41 PM, Dewayne Richardson <
> >>> dewr...@gmail.com>
> >> wrote:
> >>>
> >>> I'm working toward a more streamlined installation process for
>  Traffic
> >> Ops
> >>> (internally) and publicly. Of course, the same hiccups that
> >>> everyone
> > else
> >>> runs into I am as well.  Installation of Golang (proper version)
> >>> and
> >>> installation of Goose.  Goose has been the most challenging for
>  several
> >>> reasons.  The maintainer hasn't made any real changes since 2015,
> >>> and
> > has
> >>> not "branched" his code to allow for explicit version download.
> >>> Per
> > his
> >>> installation instructions "go get bitbucket.org/liamstask/goose/
> >> cmd/goose"
> >>>
> >>> So I'm I'm proposing to write an installer script in bash to help
> >> automate
> >>> the Golang install as well as the Goose install.  My only concern
> >>> (as
> >> well
> >>> as most of yours) is "go get" will grab the latest, but since no
> >>> real
> >>> changes have happened I'm left with no other option.
> >>>
> >>> Proposed:
> >>>
> >>> /opt/traffic_ops/install/bin/install_goose.sh
> >>>
> >>> - Install Golang (version 1.8.x)
> >>> - go get bitbucket.org/liamstask/goose/cmd/goose
> >>>
> >>> Thoughts?
> >>>
> >>> -Dew
> >>
> >>
> >
> 
> >>>
> >
>

Re: Moving Traffic Control the "full" github

[Mark Torluemke]

Also +1. Part of the move from github.com/Comcast to ASF JIRA included a
'scrub', so the move to github.com/apache can likely be scripted.

On Wed, May 17, 2017 at 8:55 AM, Robert Butts 
wrote:

> +1
>
> IMO Github issues, wiki, etc are much, much easier to use than Atlassian
> tools.
>
> On Wed, May 17, 2017 at 8:51 AM, Dave Neuman  wrote:
>
> > While at ApaceCon, a few of us attended a talk about navigating the
> > incubator where we were informed that "full" Github is now available for
> > podlings.  This gives us the ability to use github issues, to use github
> > wiki, to assign PRs, to add tags to PRs, and the "merge PR" button among
> > other things.  It sounds like the process would take our repo down for a
> > short period - minutes not hours - but the URL shouldn't change.  I know
> we
> > just got all of our issues moved to Jira, but we would need to move them
> > over to github as well.
> >
> > Since the apache way is to have a discussion before a vote, I thought I
> > would start the discussion on this topic now and if we feel like this is
> > worth pursuing, we start a vote.  Sothoughts?
> >
> >
> > Thanks,
> > Dave
> >
>

Re: LDAP Access

[Mark Torluemke]

I do not support the position of what appears to be dramatically changing
access without a tangible migration plan -- I feel like we should comply
with the "principle of least surprise" in this case.



On Fri, Jun 2, 2017 at 8:28 AM, Jeremy Mitchell 
wrote:

> I'm fine merging Rob's PR -
> https://github.com/apache/incubator-trafficcontrol/pull/627
>
> as long as it's understood that pure LDAP users (users with no user in the
> tm_user table) will not work for 99% of the UI or the API.
>
> If they want to get back that 99%, they need to have a user created for
> them in the tm_user table where username=their ldap username...
>
> jeremy
>
>
> On Thu, Jun 1, 2017 at 12:20 PM, Dave Neuman  wrote:
>
> > Just because we *can* do something doesn't mean we *should* do something.
> > I don't think we should try to over engineer this part of the system and
> > make it any more complicated than it needs to be.
> > I think Rob's PR should be merged so that LDAP users, by default, have
> very
> > limited capabilities.
> >
> > On Thu, Jun 1, 2017 at 10:16 AM, Robert Butts 
> > wrote:
> >
> > > > that ship has sailed when the roles/capabilities model was agreed
> upon
> > >
> > > I don't agree. We could configure PostgreSQL Roles and Row Security
> > > Policies with the same capabilities, and the same UI. Users would click
> > the
> > > "create role" or "assign capability" button, and the UI would issue an
> > API
> > > call which issues a SQL command to create or assign the appropriate
> > > PostgreSQL Roles and Policies. Same model, different backend.
> > >
> > > On Thu, Jun 1, 2017 at 10:09 AM, Jeremy Mitchell <
> mitchell...@gmail.com>
> > > wrote:
> > >
> > > > > @mitchell852 Actual PostgreSQL users. So, Traffic Ops users would
> > _be_
> > > > PostgreSQL users. There wouldn't be a single "trafficops" Postgres
> > user,
> > > > every TO user would have their own user in Postgres itself.
> > > >
> > > > ^^ Sounds like we need a Postgres DBA for that :) Plus, I think that
> > ship
> > > > has sailed when the roles/capabilities model was agreed upon and is
> > > > currently in the works...
> > > >
> > > > Just to clarify for others, currently, when you login via LDAP and no
> > > user
> > > > is found in the tm_user table with the same username, we assign the
> > > > "read-only" role to the "current user". Rob doesn't think (and he's
> > > > probably right) that the "read-only" role is restrictive enough for
> > these
> > > > LDAP only users. There are lots of GET routes that "read-only" users
> > can
> > > > access that contain "sensitive" info... (depending on your definition
> > of
> > > > sensitive)
> > > >
> > > > Anyhow, with this PR -
> > > > https://github.com/apache/incubator-trafficcontrol/pull/544 - the
> > > concept
> > > > of "capabilities" was introducedroles can now have
> > capabilitiesso
> > > > in theory we could create a role called "Graph Viewer" or something
> > which
> > > > maps to the cdn-graph-read capability that maps to certain api
> > > > endpoints...and then the "Graph Viewer" role would be automatically
> > > > assigned to LDAP only users..just an example.
> > > >
> > > > ^^ however the role/capabilities thing only applies to the API (not
> the
> > > > current TO UI) and was to be enforced by the API gateway
> > > >
> > > > In my opinion, trying to do what's best for the TO UI and the TO API
> at
> > > the
> > > > same time is very difficult, thus, my push to deprecate the TO UI and
> > the
> > > > entire UI namespace of endpoints, in favor of the TO API and the API
> > > > namespace... TO API + API Gateway + Roles/Capabilities gives us more
> > > > granularity
> > > >
> > > > Jeremy
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Thu, Jun 1, 2017 at 9:39 AM, Jeff Elsloo 
> wrote:
> > > >
> > > > > We use LDAP all the time. It's optional of course, but in our
> > > > > deployment nobody should be using local accounts unless they're not
> > in
> > > > > LDAP for some reason (external users, portal users, etc).
> > > > > Application/API accounts could go either way, but users of the TO
> UI
> > > > > should use LDAP whenever possible to avoid having to manage
> multiple
> > > > > accounts/passwords.
> > > > >
> > > > > Basic enterprise operations best practices dictate centralized user
> > > > > management, and most enterprises do so using some sort of LDAP
> based
> > > > > directory (Active Directory, OpenLDAP, etc). I'm a hard -1 on
> moving
> > > > > away from this model. If anything we need to make our LDAP
> > > > > implementation more flexible.
> > > > > --
> > > > > Thanks,
> > > > > Jeff
> > > > >
> > > > >
> > > > > On Thu, Jun 1, 2017 at 9:10 AM, Dewayne Richardson <
> > dewr...@gmail.com>
> > > > > wrote:
> > > > > > I have a question in a similar vein, how often do we really use
> > LDAP?
> > > > My
> > > > > > understanding is we created LDAP access to allow external users
> in
> > to
> > > > see
> > > > > > our TO Graphs.  Now that graphs are in Graphana is the ne

Re: Traffic Ops - Reorganize the client directory

[Mark Torluemke]

Also +1 to having more TO clients, and classifying them into
language-specific directories. Other suggestions welcome, though.

For instance, longer term, should we target a "Traffic Control" client,
with sub-modules for each component? Should the code for these clients live
in the language-specific networks (PyPI, CPAN, etc)?

On Wed, Jun 14, 2017 at 3:11 PM, Dewayne Richardson 
wrote:

> +1 (as long as you don't break anything!, lol).  I think this will be
> valuable because I've already seen 2 different groups out side of ours (at
> Comcast) that are reinventing that wheel over and over.  We should have
> several clients in different languages to open the door to more Traffic Ops
> access.
>
> On Wed, Jun 14, 2017 at 9:35 AM, Scrimo, Robert (Contractor) <
> robert_scr...@comcast.com> wrote:
>
> > All,
> >
> > I would like to add a Python Traffic Ops Client to the
> ‘apache/incubator-trafficcontrol’
> > repository but while I am in there I should probably re-organize the
> golang
> > client that resides in there too.  This will most definitely break other
> > code dependent on its current location, which is the root of the client
> > directory.  I am proposing to move the golang code to a newly created
> > ‘golang’ directory and add a ‘python’ directory for my Python client.  I
> > will fix any references to code using the client from within the
> > ‘incubator-trafficcontrol’ repository.  If anyone has any
> > insight/objections/comments about this please respond.  I will take your
> > silence as approval...
> >
> > Thank you,
> > -Robert
> >
> >
>

Re: Preventing routing to individual caches

[Mark Torluemke]

I'm good with a new column on the profile table. Also, I don't share the
concern on this slowing down any queries significantly.

On Thu, Aug 24, 2017 at 8:52 AM, Gelinas, Derek 
wrote:

> I think profile is right out - that means a profile lookup for each server
> that we process, and that’s going to make an already slow subroutine a lot
> slower.
>
> DG
>
> > On Aug 24, 2017, at 10:40 AM, Gelinas, Derek 
> wrote:
> >
> > I’m not sure it would work, but I’ll look into it.
> >
> > Assuming it does not, does anyone have any strong feelings about any of
> the choices?  My personal preference is to use option 3 or option 1, or to
> use ccr_ignore.
> >
> > 1) Server table flag - when marked, nothing is routed to the host at
> > all.  Not as configurable as option 3, but more so than option 2.  Faster
> > than option 2 as it would be returned with existing search results and
> > could be easily filtered on.  Minor UI change only.
> > 2) Profile parameter - when marked, nothing is routed to any host
> > with this profile.  Heavy handed, and would require additional profile
> > parameter lookups when generating the crconfig, so it'd slow it down. No
> UI
> > change.
> > 3) deliveryservice_servers table flag - an additional column that is
> > true by default.  When desired, the user could pull up a sub-window
> within
> > the delivery service configuration that would present a list of the hosts
> > which have been assigned to the delivery service (and are not of org
> > type).  The user could deselect the desired hosts, setting the DSS
> routing
> > value to false.  This server would then be ignored when generating the
> > crconfig data for that specific delivery service.  This would be the most
> > configurable option, and should be as quick as option 1, but would
> require
> > the most extensive code changes.
> > 4) Column in the “type” table. Like option 1, this would apply at the
> server level.
> > 5) Column in the “profile” table.  Like option 2, this would apply at
> the profile level.
> >
> >
> >> On Aug 23, 2017, at 5:53 PM, rawlin.pet...@gmail.com <
> rawlin_pet...@comcast.com> wrote:
> >>
> >> What about the server status CCR_IGNORE ("Server is ignored by traffic
> router.") that already exists? It doesn't appear to be checked when
> generating CRConfig right now, but maybe it should be?
> >>
> >> --Rawlin
> >>
> >> On 2017-08-22 11:45, "Gelinas, Derek" 
> wrote:
> >>> Iâ?Td agree with you if this was designed to drain, but this is
> intended as a permanent state for a pretty good long list of caches.
> >>>
> >>> DG
> >>>
>  On Aug 22, 2017, at 1:28 PM, Eric Friedrich (efriedri) <
> efrie...@cisco.com> wrote:
> 
>  What about a modification of option 1- adding a new state per server.
> 
>  Instead of ADMIN_DOWN, it could be â?oREPORTED_DRAINâ?  to indicate
> the difference
> 
>  â?"Eric
> 
> > On Aug 22, 2017, at 1:14 PM, Gelinas, Derek <
> derek_geli...@comcast.com> wrote:
> >
> > Thatâ?Ts actually the workaround weâ?Tre using at the moment -
> setting them to admin_down.  Thatâ?Ts a temporary measure, though - we want
> something more permanent.
> >
> > DG
> >> On Aug 22, 2017, at 1:09 PM, Eric Friedrich (efriedri) <
> efrie...@cisco.com> wrote:
> >>
> >> How does your use case differ from marking a server as offline in
> Traffic Ops and snapshotting?
> >>
> >> Thats the easiest way I can think of to get a server in this state
> >>
> >> â?"Eric
> >>
> >>> On Aug 22, 2017, at 1:00 PM, Gelinas, Derek <
> derek_geli...@comcast.com> wrote:
> >>>
> >>> Weâ?Tve run across a situation in which we need certain caches to
> simultaneously have map rules for a delivery service, but not actually have
> those caches routed to when requests are made via traffic router.
> Essentially, this means removing the delivery service from the cacheâ?Ts
> info in the crconfig file.
> >>>
> >>> Thereâ?Ts been a bit of internal debate about the best ways to do
> this, and Iâ?Td like to collect some opinions on the matter.
> >>>
> >>> 1) Server table flag - when marked, nothing is routed to the host
> at all.  Not as configurable as option 3, but more so than option 2.
> Faster than option 2 as it would be returned with existing search results
> and could be easily filtered on.  Minor UI change only.
> >>> 2) Profile parameter - when marked, nothing is routed to any host
> with this profile.  Heavy handed, and would require additional profile
> parameter lookups when generating the crconfig, so itâ?Td slow it down. No
> UI change.
> >>> 3) deliveryservice_servers table flag - an additional column that
> is true by default.  When desired, the user could pull up a sub-window
> within the delivery service configuration that would present a list of the
> hosts which have been assigned to the delivery service (and are not of org
> type).  The user could deselect the desired hosts, setting the DSS routing
> value to 

Re: Initial setup for development

[Mark Torluemke]

Hi Michael,

If you're trying to optimize over the # of instances, I would lean away
from the official production-ready recommendations in the docs, and do more
of what Dave suggested. Something like this:

+---+-+
| Component | VM  |
+---+-+
| TO| VM1 |
| TODB  | VM1 |
| TV| VM1 |
| TM| VM1 |
| TS| --  |
| Influx| --  |
| TR| VM2 |
| ATS-EDGE  | VM3 |
| ATS-MID   | VM4 |
| TP| --  |
+---+-+

The ones with "--" can be added later, if you require that functionality.
Most of the components should have adequate installation documentation, but
reply back the list, or find us on Slack (traffic-control-cdn.slack.com) if
you get stuck.

Cheers,
Mark



On Tue, Sep 5, 2017 at 5:07 PM, Michael Talyansky <
michael.talyan...@ericsson.com> wrote:

> Hi Dave,
>
> Thanks for the offer of help!
>
> So far, I was able to do the following:
>
> 1. Create two VMs as recommended on the website, one for postgres and one
> for TrafficOps
> 2. Configure and start Postgres
> 3. Download and build Traffic Ops
> 4. Verify postgres connectivity and install traffic ops, according to this
> page: https://trafficcontrol.incubator.apache.org/docs/
> latest/admin/traffic_ops/installation.html
> 5. Brought up the GUI, downloaded and imported two missing profiles for
> EDGE_ATS and MID_ATS, so I have 11 profiles listed now:
>
> Profile Name
> Profile Description
> Type
> Cdn
> Last updated
> Profile Details Parameter Details   EDGE_ATS_621_CENTOS_721 Edge Cache
> - Apache Traffic Server v6.2.1-61.1ec1041.el7.centos.x86_64  ATS_PROFILE
>-   2017-09-05 22:54:57.061084+00
> Profile Details Parameter Details   GLOBAL  Global Traffic Ops
> profile, DO NOT DELETE   UNK_PROFILE -   2017-09-05
> 22:14:37.180598+00
> Profile Details Parameter Details   INFLUXDBInfluxDb profile
>   INFLUXDB_PROFILE-   2017-09-05 22:14:37.194697+00
> Profile Details Parameter Details   MID_ATS_532_CENTOS_721  Mid Cache
> - Apache Traffic Server v5.3.2-762.23d37d0.el7.centos.x86_64
> ATS_PROFILE -   2017-09-05 22:53:35.519531+00
> Profile Details Parameter Details   RIAK_ALLRiak profile for
> all CDNs   RIAK_PROFILE-   2017-09-05 22:14:37.195611+00
> Profile Details Parameter Details   TRAFFIC_ANALYTICS   Traffic
> Analytics profile   UNK_PROFILE -   2017-09-05
> 22:14:37.189865+00
> Profile Details Parameter Details   TRAFFIC_OPS Traffic Ops
> profile UNK_PROFILE -   2017-09-05 22:14:37.190855+00
> Profile Details Parameter Details   TRAFFIC_OPS_DB  Traffic Ops DB
> profile  UNK_PROFILE -   2017-09-05 22:14:37.191781+00
> Profile Details Parameter Details   TRAFFIC_PORTAL  Traffic Portal
> profile  TP_PROFILE  -   2017-09-05 22:14:37.192758+00
> Profile Details Parameter Details   TRAFFIC_ROUTER  Traffic Router
> profile  TR_PROFILE  -   2017-09-05 22:52:43.543589+00
> Profile Details Parameter Details   TRAFFIC_STATS   Traffic Stats
> profile   TS_PROFILE  -   2017-09-05 22:14:37.193739+00
> Showing 1 to 11 of 11 entries
>
>
> What would be the next step? Create two more VMs, download and build ATS
> on them? Then, where do I start configuring the whole system to be able to
> pass traffic?
>
> Thanks,
> Michael
>
> On 8/31/17, 2:18 PM, "Dave Neuman"  wrote:
>
> Hey Michael,
> I have built a "CDN in a box" before using KVM and a physical server
> but I
> haven't ever tried to build one in AWS.  I think you will need at
> least 3
> VMs to make this happen.  The first one should be able to run all of
> the TC
> components (Traffic Ops, Postgres, Traffic Monitor, Traffic Router)
> and you
> will need at least two caches.  We require at least a two tier CDN
> with at
> least one EDGE and one MID server.  It might be a little difficult
> getting
> all of the TC components running on one VM, but I think it can be done.
>
> Sorry, we don't really have a how-to on doing what you are trying to
> do,
> but I (and hopefully others) are more than happy to help here.
>
> Thanks,
> Dave
>
> On Thu, Aug 31, 2017 at 2:54 PM, Michael Talyansky <
> michael.talyan...@ericsson.com> wrote:
>
> > Hi,
> >
> > I am trying to set up development and testing environment on AWS. So
> far,
> > I have two VMs, one running postgres, and one on which I built
> > trafficcontrol. I will need to set up at least one caching node, so
> I can
> > test the whole system.
> >
> > Has anyone done something similar before, and if so, is there a
> pointer to
> > a sample configuration of how to do this with the least amount of
> VMs?
> >
> > Thanks in advance!
> >
>
>
>

Re: Initial setup for development

[Mark Torluemke]

Slack should be fixed now. Also, the TC admin guide has the installation
docs: http://trafficcontrol.apache.org/docs/latest/admin/index.html

On Tue, Sep 5, 2017 at 9:17 PM, Michael Talyansky <
michael.talyan...@ericsson.com> wrote:

> Thanks, Mark,
>
> How do I get onto Slack channel? I submitted a form a few days ago, but
> got no reply. Just re-submitted now. Is this enough to get added?
>
> As far as ATS installation, is it documented as part of the Traffic
> Control, or do I have to go to ATS page for that?
>
> Thanks,
> Michael
>
> On 9/5/17, 7:59 PM, "Mark Torluemke"  wrote:
>
> Hi Michael,
>
> If you're trying to optimize over the # of instances, I would lean away
> from the official production-ready recommendations in the docs, and do
> more
> of what Dave suggested. Something like this:
>
> +---+-+
> | Component | VM  |
> +---+-+
> | TO| VM1 |
> | TODB  | VM1 |
> | TV| VM1 |
> | TM| VM1 |
> | TS| --  |
> | Influx| --  |
> | TR| VM2 |
> | ATS-EDGE  | VM3 |
> | ATS-MID   | VM4 |
> | TP| --  |
> +---+-+
>
> The ones with "--" can be added later, if you require that
> functionality.
> Most of the components should have adequate installation
> documentation, but
> reply back the list, or find us on Slack (
> traffic-control-cdn.slack.com) if
> you get stuck.
>
> Cheers,
> Mark
>
>
>
> On Tue, Sep 5, 2017 at 5:07 PM, Michael Talyansky <
> michael.talyan...@ericsson.com> wrote:
>
> > Hi Dave,
> >
> > Thanks for the offer of help!
> >
> > So far, I was able to do the following:
> >
> > 1. Create two VMs as recommended on the website, one for postgres
> and one
> > for TrafficOps
> > 2. Configure and start Postgres
> > 3. Download and build Traffic Ops
> > 4. Verify postgres connectivity and install traffic ops, according
> to this
> > page: https://trafficcontrol.incubator.apache.org/docs/
> > latest/admin/traffic_ops/installation.html
> > 5. Brought up the GUI, downloaded and imported two missing profiles
> for
> > EDGE_ATS and MID_ATS, so I have 11 profiles listed now:
> >
> > Profile Name
> > Profile Description
> > Type
> > Cdn
> > Last updated
> > Profile Details Parameter Details   EDGE_ATS_621_CENTOS_721 Edge
> Cache
> > - Apache Traffic Server v6.2.1-61.1ec1041.el7.centos.x86_64
> ATS_PROFILE
> >-   2017-09-05 22:54:57.061084+00
> > Profile Details Parameter Details   GLOBAL  Global Traffic Ops
> > profile, DO NOT DELETE   UNK_PROFILE -   2017-09-05
> > 22:14:37.180598+00
> > Profile Details Parameter Details   INFLUXDBInfluxDb
> profile
> >   INFLUXDB_PROFILE-   2017-09-05 22:14:37.194697+00
> > Profile Details Parameter Details   MID_ATS_532_CENTOS_721  Mid
> Cache
> > - Apache Traffic Server v5.3.2-762.23d37d0.el7.centos.x86_64
> > ATS_PROFILE -   2017-09-05 22:53:35.519531+00
> > Profile Details Parameter Details   RIAK_ALLRiak profile
> for
> > all CDNs   RIAK_PROFILE-   2017-09-05 22:14:37.195611+00
> > Profile Details Parameter Details   TRAFFIC_ANALYTICS
>  Traffic
> > Analytics profile   UNK_PROFILE -   2017-09-05
> > 22:14:37.189865+00
> > Profile Details Parameter Details   TRAFFIC_OPS Traffic Ops
> > profile UNK_PROFILE -   2017-09-05 22:14:37.190855+00
> > Profile Details Parameter Details   TRAFFIC_OPS_DB  Traffic Ops
> DB
> > profile  UNK_PROFILE -   2017-09-05 22:14:37.191781+00
> > Profile Details Parameter Details   TRAFFIC_PORTAL  Traffic
> Portal
> > profile  TP_PROFILE  -   2017-09-05 22:14:37.192758+00
> > Profile Details Parameter Details   TRAFFIC_ROUTER  Traffic
> Router
> > profile  TR_PROFILE  -   2017-09-05 22:52:43.543589+00
> > Profile Details Parameter Details   TRAFFIC_STATS   Traffic Stats
> > profile   TS_PROFILE  -   2017-09-05 22:14:37.193739+00
> > Showing 1 to 11 of 11 entries
> >
> >
> > What would be the next step? Create two more VMs, download and build
> ATS
> > on them? Then, where do I start configuring the whole system to be
> able to
> >

Re: Building Traffic-Router - Failed to bring jdnssec-tools

[Mark Torluemke]

I think we should be resilient and try both address families...curl might
even do this 'for free' if we enable retries.

On Tue, Oct 3, 2017 at 3:21 PM, Rawlin Peters 
wrote:

> It's possible that Docker isn't playing nicely with IPv6 in your build
> environment. The RPM build script is curling
> http://www.verisignlabs.com/jdnssec-tools/packages/old-
> releases/jdnssec-tools-0.12.tar.gz,
> and in your case is using the  record for some reason. My guess is
> that the container doing the build probably only routes IPv4 by
> default in some environments. Checking in my build environment, none
> of the Docker networks have IPv6 enabled.
>
> Should we pass `-4` to the curl command here [1] to force it to
> resolve to IPv4 addresses only?
>
> - Rawlin
>
> [1] https://github.com/apache/incubator-trafficcontrol/blob/
> master/traffic_router/build/build_rpm.sh#L41
>
> On Tue, Oct 3, 2017 at 3:02 PM, Nir Sopher  wrote:
> > I now see that "./pkg traffic_portal_build" fails as well. This time with
> > no log.
> > It worked before, back when I was building it from master.
> > Where is jdnssec brought from? Is it built during the process? I failed
> to
> > find it in the standard public repositories.
> > Nir
> >
> > On Tue, Oct 3, 2017 at 11:56 PM, David Neuman 
> > wrote:
> >
> >> I have not seen this issue.  It's interesting that it is trying ipv6 for
> >> that.
> >>
> >> On Tue, Oct 3, 2017 at 2:33 PM, Nir Sopher  wrote:
> >>
> >> > Hi,
> >> >
> >> > Yesterday I tried to build the latest 2.1.x traffic-control, calling
> the
> >> > ./pkg command.
> >> > The command failed on traffic-router build, and according to the below
> >> log,
> >> > it is related to bringing the JDNSSEC tools library, not sure from
> which
> >> > repository.
> >> >
> >> > Does anybody else encountered a similar issue?
> >> >
> >> > Thanks,
> >> > Nir
> >> >
> >> > Building the rpm.
> >> >   % Total% Received % Xferd  Average Speed   TimeTime Time
> >> > Current
> >> >  Dload  Upload   Total   SpentLeft
> >> > Speed
> >> >   0 00 00 0  0  0 --:--:--  0:02:07
> --:--:--
> >> >  0curl: (7) Failed to connect to 2620:74:13:4400::201: Network is
> >> > unreachable
> >> > Could not download required jdnssec-tools-0.12 library: 7
> >> >
> >>
>

New Committer - Peter Ryder

[Mark Torluemke]

The Project Management Committee (PMC) for Apache Traffic Control
(incubating) has invited Peter Ryder to become a committer and we are
pleased to announce that he has accepted.

Peter has been contributing to Traffic Control since late 2016.  His major
contributions have been with the incredibly important 'postinstall'
function of Traffic Ops, and has shown his versatility with adding the
support for blocking anonymous proxies in Traffic Router.

Being a committer enables easier contribution to the project since there is
no need to go via the patch
submission process. This should enable better productivity. Being a PMC
member enables assistance with the management and to guide the direction of
the project.

Re: Traffic Control with ATS 7+

[Mark Torluemke]

I agree -- supporting 3 ATS major versions is likely more work than it's
worth. Traffic Ops core should continue to move towards being cache
software agnostic.

Having said that, we have some logic today that generates config files
differently, based on the ATS major version:

https://github.com/apache/incubator-trafficcontrol/blob/a5d9ac705c97388bf18c09b32e8ef8434c243354/traffic_ops/app/lib/API/Configs/ApacheTrafficServer.pm#L2317



On Tue, Nov 21, 2017 at 7:52 PM, Jeremy Mitchell 
wrote:

> IMO, it's a lot to ask of a TC release to support multiple, inherently
> different versions of ATS. We will end up with features or options that
> pertains to one version of ATS but not another. By trying to support too
> many versions of ATS, we complicate TC and if we ever want to implement any
> type of self-service, we need to simplify TC rather than complicate it.
>
> Not sure how realistic this is but I'd like to see something like this:
>
> Examples:
>
> TC version 2.1 works with ATS 5/6
> TC version 2.2 works with ATS 5/6
> TC version 2.3 works with ATS 6/7 <-- sorry, if you are still sitting on
> ATS 5 and want to move to TC 2.3, you need to upgrade ATS
>
> Jeremy
>
> On Tue, Nov 21, 2017 at 3:05 PM, Chris Lemmons  wrote:
>
> > As we continue the work of getting Traffic Control to work properly
> > with ATS 7 and forward, we're having to re-work some of the ways we
> > manipulate cache keys. The crux of the issue is that cacheurl was
> > deprecated in 6 and has been removed in 7. Cacheurl was replaced with
> > cachekey in 6. That unfortunately will make supporting both 5 and 7 a
> > bit tricky. There are a few options for maintaining compatibility, but
> > I thought I'd ask... would anyone find themselves sad if, at some
> > point, Traffic Control stopped working with version 5 of ATS? And if
> > not, what might be the best way to manage that?
> >
>

Re: [VOTE] CHANGELOG.md file (second try)

[Mark Torluemke]

[X] +1 to adding a changelog.MD file
[] -1 to adding a changelog.MD file

[] +1 to adding a changelog label in github
[X] -1 to adding a changelog label in github

FWIW, I think the default should be to add a PR to the changelog, and I
would support a "nochangelog" label. :)




On Tue, Jan 9, 2018 at 10:22 AM, Dave Neuman  wrote:

> Looks like this thread died over the holidays.  Let me try to bring it back
> up before we cut a 2.2 branch.
> Can you please respond with *just* the following:
>
> [] +1 to adding a changelog.MD file
> [] -1 to adding a changelog.MD file
>
> [] +1 to adding a changelog label in github
> [] -1 to adding a changelog label in github
>
> Thanks,
> Dave
>

Re: Google Summer of Code 2018 Mentor Registration

[Mark Torluemke]

+1 on the API migration suggestion.

On Mon, Feb 26, 2018 at 10:50 AM, Dave Neuman  wrote:

> I think any of the perl -> go API stuff would be great.
>
> On Mon, Feb 26, 2018 at 10:19 AM, Eric Friedrich (efriedri) <
> efrie...@cisco.com> wrote:
>
> > I agree, this would be a great way to grow the community.
> >
> > Do we have a list of marked issues in Github that would be good
> candidates?
> >
> > Or perhaps we can brainstorm some issues here on the mailer?
> >
> > —Eric
> >
> > > On Feb 24, 2018, at 5:18 PM, Phil Sorber  wrote:
> > >
> > > I think we should do this.
> > >
> > > -- Forwarded message -
> > > From: Ulrich Stärk 
> > > Date: Sat, Feb 24, 2018 at 2:19 PM
> > > Subject: Google Summer of Code 2018 Mentor Registration
> > > To: 
> > > Cc: d...@community.apache.org 
> > >
> > >
> > > Dear PMCs,
> > >
> > > I'm happy to announce that the ASF has made it onto the list of
> accepted
> > > organizations for
> > > Google Summer of Code 2018! [1,2]
> > >
> > > It is now time for mentors to sign up, so please pass this email on to
> > your
> > > community and
> > > podlings. If you aren’t already subscribed to
> > ment...@community.apache.org
> > > you should do so now else
> > > you might miss important information.
> > >
> > > Mentor signup requires two steps: mentor signup in Google's system [3]
> > and
> > > PMC acknowledgement.
> > >
> > > If you want to mentor a project in this year's SoC you will have to
> > >
> > > 1. Be an Apache committer.
> > > 2. Request an acknowledgement from the PMC for which you want to mentor
> > > projects. Use the below
> > > template and *do not forget to copy ment...@community.apache.org*. We
> > will
> > > use the email adress you
> > > indicate to send the invite to be a mentor for Apache.
> > >
> > > PMCs, read carefully please.
> > >
> > > We request that each mentor is acknowledged by a PMC member. This is to
> > > ensure the mentor is in good
> > > standing with the community. When you receive a request for
> > > acknowledgement, please ACK it and cc
> > > ment...@community.apache.org
> > >
> > > Lastly, it is not yet too late to record your ideas in Jira (see my
> > > previous emails for details).
> > > Students will now begin to explore ideas so if you haven’t already done
> > so,
> > > record your ideas
> > > immediately!
> > >
> > > Cheers,
> > >
> > > Uli
> > >
> > > mentor request email template:
> > > 
> > > to: private@.apache.org
> > > cc: ment...@community.apache.org
> > > subject: GSoC 2018 mentor request for 
> > >
> > >  PMC,
> > >
> > > please acknowledge my request to become a mentor for Google Summer of
> > Code
> > > 2018 projects for Apache
> > > .
> > >
> > > I would like to receive the mentor invite to 
> > >
> > > 
> > >
> > > 
> > >
> > > [1] https://summerofcode.withgoogle.com/organizations/
> > > [2] https://summerofcode.withgoogle.com/organizations/
> 5718432427802624/
> > > [3] https://summerofcode.withgoogle.com/
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > > For additional commands, e-mail: dev-h...@community.apache.org
> >
> >
>

Re: Traffic Server Secondary Streaming IPs Design

[Mark Torluemke]

I would support an 'interfaces' table (adding some sort of a 'type' column)
that would include moving the management and lights out management
interfaces to that table as well.

Cheers,
Mark

On Mon, Apr 2, 2018 at 2:39 PM, Nir Sopher  wrote:

> Hi Zhilin,
>
> I took a quick look into the spec. Hope to have the opportunity to dive
> deeper into it soon so we can further discuss it.
>
> For now I have a 2 questions.
> In the spec, you refer to "secondary interfaces", and you have a list of
> secondary interfaces added.
> IIUC the secondary interfaces are used as long as they are available, and
> when down, you move to the primary interface.
>
> Why not, instead of holding a secondary interfaces table, move all
> interfaces to a separate table? Primary and secondary.
> For each interface you can hold:
>
>- Server id
>- name (e.g. eth0)
>- IPv6
>- IPv4
>- Priority (Integer as flexible as you wish: e.g. "1" for "secondary",
>"2" for "primary" in your example,)
>
>
> Additionally, it is not clear to me what happens if one of the interfaces
> fails?
> Does every interface has a unique DNS name? If an interface fails, are
> redirects
> sent only to the available (secondary) interfaces?
>
> Thanks,
> Nir
>
>
> On Mon, Apr 2, 2018 at 10:21 AM, Zhilin Huang (zhilhuan) <
> zhilh...@cisco.com
> > wrote:
>
> > Hi Guys,
> >
> > This was originally posted in another discussion. Resend this in a
> > standalone topic to catch more awareness. The link for the design doc:
> > https://docs.google.com/document/d/1vgq-pGNoLLYf7Y3cu5hWu67TUKpN5hucrp
> > -ZS9nSsd4/edit?usp=sharing
> >
> >
> > Short summary for the feature design:
> > ---
> > There is feature request from market to add secondary IPs support on edge
> > cache servers, and the functionality to assign a delivery service to a
> > secondary IP of an edge cache.
> >
> > This feature requires Traffic Ops implementation to support secondary IP
> > configuration for edge cache, and delivery service assignment to
> secondary
> > IP.
> >
> > Traffic Monitor should also monitor connectivity of secondary IPs
> > configured. And Traffic Router needs support to resolve streamer FQDN to
> > secondary IP assigned in a delivery service.
> >
> > Traffic Server should record the IP serving client request. And should
> > reject request to an unassigned IP for a delivery service.
> >
> > This design has taken compatibility into consideration: if no secondary
> IP
> > configured, or some parts of the system has not been upgraded to the
> > version supports this feature, the traffic will be served by primary IPs
> as
> > before.
> > ---
> >
> > Much appreciated and welcome to any comments. If no major objections, we
> > planned to start coding this week.
> >
> > Thanks,
> > Zhilin
> >
> >
>