Hi, >From the conversation so far it feels like a new "server type" is needed, and *maybe *some way to mark delivery services to be deployed on this kind of servers as well. If the "marking" is required, it can also be done in the (to be discussed) "deployed DS versions" table.
Either way, please take into consideration self-service and tenancy - the variables of a DS in the DS table should be managed by the DS owner. As I see it, adding "CDN deployment related parameters" to the DS itself, brings the DS owner control over something he should not have. Nir On Wed, Aug 23, 2017 at 10:45 AM, Gelinas, Derek <derek_geli...@comcast.com> wrote: > I suppose it could be a new type. How are you thinking we'd implement in > that case? Off the cuff I'm thinking we could have a type filter ds > parameter which would list the various server types we want routed. In > that way we could differentiate between the default edge type and something > else. Doing it that way would require a bit of retooling the query used to > generate the delivery service list, but that's about it. Though in that > case it really wouldn't need to be a different delivery service type, so I > suspect you've something else in mind. > > On Aug 23, 2017, at 12:14 AM, Eric Friedrich (efriedri) < > efrie...@cisco.com<mailto:efrie...@cisco.com>> wrote: > > Could this be a new DS type or does it apply to a whole server? > ________________________________________ > From: Gelinas, Derek [derek_geli...@comcast.com<mailto: > derek_geli...@comcast.com>] > Sent: Tuesday, August 22, 2017 6:22 PM > To: dev@trafficcontrol.incubator.apache.org<mailto:dev@ > trafficcontrol.incubator.apache.org> > Subject: Re: Preventing routing to individual caches > > The use case is fairly specific. Suffice it to say we have reverse > proxies that need configuration without being treated as potential > destinations by traffic router. > > DG > > On Aug 22, 2017, at 3:19 PM, Nir Sopher <n...@qwilt.com<mailto:nirs@ > qwilt.com><mailto:n...@qwilt.com>> wrote: > > Hi Derek, > > Could you please shade more light on the problem you are trying to solve? > > As I see it, option #3 is indeed more flexible - as it can work in a DS > granularity. > It is even more powerful when you combine it with other extensions for this > table suggested in the "Drop Server -> Delivery Service assignments". > > However, as you describe options #1,#2 as valid options, it seems that the > problem you are dealing with completely resides in the "servers" domain - > as the server should have the same behavior for all delivery-services. > Therefore, option #1 might be more suitable. > > Nir > > On Tue, Aug 22, 2017 at 8:45 PM, Gelinas, Derek <derek_geli...@comcast.com > <mailto:derek_geli...@comcast.com><mailto:derek_geli...@comcast.com>> > wrote: > > I'd 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<mailto:efrie...@cisco.com><mailto:efrie...@cisco.com>> > wrote: > > What about a modification of option 1- adding a new state per server. > > Instead of ADMIN_DOWN, it could be "REPORTED_DRAIN" to indicate the > difference > > -Eric > > On Aug 22, 2017, at 1:14 PM, Gelinas, Derek <derek_geli...@comcast.com< > mailto:derek_geli...@comcast.com><mailto:derek_geli...@comcast.com>> > wrote: > > That's actually the workaround we're using at the moment - setting them > to admin_down. That's a temporary measure, though - we want something more > permanent. > > DG > On Aug 22, 2017, at 1:09 PM, Eric Friedrich (efriedri) < > efrie...@cisco.com<mailto:efrie...@cisco.com><mailto: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<mailto:derek_geli...@comcast.com><mailto: > derek_geli...@comcast.com>> wrote: > > We've 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's info > in the crconfig file. > > There's been a bit of internal debate about the best ways to do this, > and I'd 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'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. > > Personally, I like option 3, but would very much like to hear > opinions, arguments, and other options that I haven't thought of or listed > here. > > Derek > > > > > > >
