Re: Proposed change to UI::Parameter conceal_secure_parameter_value

2017-03-17 Thread Jeremy Mitchell
Seems ok to me.

Jeremy

On Thu, Mar 16, 2017 at 10:04 AM, Gelinas, Derek 
wrote:

> Currently secure parameters are restricted to admin level access.  I
> propose that we expand this to operations level access.  Operations already
> have access to the DB dumps, so already basically have access to these
> values.  I’d like to know if there are any objections or thoughts on this.
>
> Derek
>
>
> Derek Gelinas
> IPCDN Engineering
> derek_geli...@cable.comcast.com
> 603.812.5379
>
>


Re: Removing 'internal' from TO API

2017-03-17 Thread Amir Yeshurun
With the API GW, such duplications, or modifications can be defined in the
GW, if required, instead of in TO

On Thu, Mar 16, 2017, 5:52 PM Jan van Doorn  wrote:

> We should also think about the API gateway future I think with that, we
> don't need these special routes at all anymore, right Amir?
>
> Cheers,
> JvD
>
>
> On Wed, Mar 15, 2017 at 9:24 PM Dewayne Richardson 
> wrote:
>
> > I think we should do as Dave mentioned, assess and rename.
> >
> > > On Mar 15, 2017, at 2:18 PM, Jeremy Mitchell 
> > wrote:
> > >
> > > I don't like duplicating routes either but I thought it would ease the
> > > transition rather than just changing the route. So no code duplication,
> > > just 2 routes that go to the same place:
> > >
> > > $r->get("/internal/api/$version/steering")->over( authenticated => 1
> > )->to(
> > > 'Steering#index', namespace => 'API::DeliveryService' );
> > > $r->get("/api/$version/steering")->over( authenticated => 1 )->to(
> > > 'Steering#index', namespace => 'API::DeliveryService' );
> > >
> > > And then we circle back and delete
> > >
> > > $r->get("/internal/api/$version/steering")->over( authenticated => 1
> > )->to(
> > > 'Steering#index', namespace => 'API::DeliveryService' );
> > >
> > > at some point.
> > >
> > > And yes, this internal namespace was introduced for comcast-specific
> > > reasons that I believe no longer exist.
> > >
> > > Jeremy
> > >
> > >
> > >
> > > On Wed, Mar 15, 2017 at 2:13 PM, David Neuman
> > > wrote:
> > >
> > > > At least a few of those (Steering, federations) were put in the
> > "internal"
> > > > namespace to work around Comcast specific issues. I don't know that I
> > like
> > > > the idea of duplicating routes, if anything we should see what is
> > impacted
> > > > by moving them out of the internal namespace.
> > > >
> > > > On Wed, Mar 15, 2017 at 1:30 PM, Jeremy Mitchell
> > > > wrote:
> > > >
> > > > > Currently, we have a number of API routes scoped as "internal".
> Here
> > are
> > > > a
> > > > > few examples:
> > > > >
> > > > > https://github.com/apache/incubator-trafficcontrol/blob/
> > > > > master/traffic_ops/app/lib/TrafficOpsRoutes.pm#L516
> > > > >
> > > > > I believe this is going to make it more difficult as we try to
> > implement
> > > > > more granular roles / capabilities coupled with tenancy.
> > > > >
> > > > > So I'm proposing that we create a duplicate non-internal route like
> > this,
> > > > > for example:
> > > > >
> > > > > $r->get("/api/$version/steering")->over( authenticated => 1 )->to(
> > > > > 'Steering#index', namespace => 'API::DeliveryService' );
> > > > >
> > > > > that way we can slowly move away from the "internal" routes and
> > > > eventually
> > > > > deprecate them.
> > > > >
> > > > > I think with our upcoming more robust role / tenancy model, there
> is
> > no
> > > > > longer a need for "internal".
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > Jeremy
> > > > >
> > > >
>


Re: Update Delivery Service URL

2017-03-17 Thread Eric Friedrich (efriedri)
You will also need to queue updates for the caches assigned to this delivery 
service and run the ORT script in “syncds” mode to update the configuration on 
the caches. This is how remap.config is changed. 

CRConfig only goes out to Traffic Monitor and Traffic Router. 

This is pretty safe to do on the fly, but once you run the ORT script the 
config will be changes on caches, so the caches will no longer respond to the 
original URL remap rule. If this is a system in production, you might want to 
consider setting up a second delivery service that shares the same origin 
server. When rolling out a new DS be sure to run ORT on the caches before 
SnapShot CRConfig.

—Eric
  


 
> On Mar 17, 2017, at 2:43 AM, Burak Sarp  wrote:
> 
> Hi,
> I needed to update Delivery Service URL,Is it enough to update delivery 
> service in ops adn CR Config? I mean after updating Cr Config the 
> remap.config in Traffic Server will be changed?lastly, is it safe to update 
> delivery service url on the fly?
> thanks,burak