t the few complicated use cases increase the
>>> barrier
>>>> to entry
>>>>>>>> (to using ATC) for the masses.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>&
2019, at 12:50 AM, Gray, Jonathan <
>>> jonathan_g...@comcast.com> wrote:
>>>>>>
>>>>>> It's not just differing types, it's anything that affects the
>>> parent.config which also includes the, qstring configuration, MSO
>>> parents/config, etc. as well.
>&
> > >>> I would be +1 on the idea if we include type though. Two DSs
> > can share the
> > >>> same origin as long as they are of the same type (DNS, HTTP,
> > HTTP_LIVE),
> > >>>
e for each
> Delivery Service. The idea is to have a unique name
> for each Delivery Service, but they all resolve to the same IP address.
> ________
> From: Steve Malenfant
> Sent: Tuesday, January 29, 2019 4:32 PM
> To: dev@trafficcontrol.apache.or
gt;>>
> >>> On Mon, Jan 14, 2019 at 7:53 AM Fieck, Brennan <
> brennan_fi...@comcast.com>
> >>> wrote:
> >>>
> >>>> I don't see this as a complicated use case or a barrier to entry,
> an
>
3 AM Fieck, Brennan <
> brennan_fi...@comcast.com>
> >>> wrote:
> >>>
> >>>> I don't see this as a complicated use case or a barrier to entry,
> an
> >>>> extremely basic introduction to ATC would only make use o
;> 3. Include a DB migration that adds a uniqueness constraint on origin
>>>>> FQDN, removing the API-level checks for that.
>>>>> 4. Prevent an upgrade to N+1 if duplicate origins are found (this
>>>>> might occur as a byproduct of step 3).
>>>>>
&
efore release N+1; otherwise, an
>>>>> upgrade to N+1 will be prohibited.
>>>>>
>>>>> In release N+1 we will:
>>>>> 3. Include a DB migration that adds a uniqueness constraint on origin
>>>>> FQDN, removing the API-level checks fo
rennan
>>> wrote:
>>>
>>>> I don't see this as a complicated use case or a barrier to entry, an
>>>> extremely basic introduction to ATC would only make use of one DS
>>>> (shameless CDN-in-a-Box plug).
>>>> It seems far mor
ould be included in 3.1.0
> >>>>>
> >>>>> +1
> >>>>>
> >>>>> I understand Jonathan's objection, but at some point, we have to be
> >>> able to
> >>>>> move forward. This is a good comprom
;> knowledge, resources, and need for such workarounds.
>> ____________
>> From: Mark Torluemke
>> Sent: Friday, January 11, 2019 1:21 PM
>> To: dev@trafficcontrol.apache.org
>> Subject: Re: [EXTERNAL] Re: Origins assigned to Multipe Delivery
___
> From: Mark Torluemke
> Sent: Friday, January 11, 2019 1:21 PM
> To: dev@trafficcontrol.apache.org
> Subject: Re: [EXTERNAL] Re: Origins assigned to Multipe Delivery Services
> produces indeterminate parent.config
>
> >&
___
> From: Mark Torluemke
> Sent: Friday, January 11, 2019 1:21 PM
> To: dev@trafficcontrol.apache.org
> Subject: Re: [EXTERNAL] Re: Origins assigned to Multipe Delivery Services
> produces indeterminate parent.config
>
> >> 1. Prohibit creating new delivery service
t: Re: [EXTERNAL] Re: Origins assigned to Multipe Delivery Services
produces indeterminate parent.config
>> 1. Prohibit creating new delivery services that would share an
existing origin and prohibit updating a delivery service to a shared
origin
In case my position has been lost, I'm
".
> >
> > On Wed, Dec 19, 2018 at 11:58 AM Fieck, Brennan <
> brennan_fi...@comcast.com>
> > wrote:
> >
> > > Probably. It would impact load times by a bit, but the page for an
> > > individual object is not our bottleneck.
> > >
n "when".
> > >
> > > I stand by my previous proposal:
> > > - Including a warning on startup and an API constraint preventing adding
> > > more bad data in the next 3.0.0 Release Candidate
> > > - Adding a database constraint immediately into master that won't be
> > &g
cherry-picked into 3.0.0 but should be included in 3.1.0
> > ____
> > From: Rawlin Peters
> > Sent: Tuesday, December 18, 2018 4:59 PM
> > To: dev@trafficcontrol.apache.org
> > Subject: Re: [EXTERNAL] Re: Origins assigned to Multipe Deli
gs, which are not only highly complex and confusing, but also
> further
> > entrench us in only supporting ATS as a caching proxy (hurting efforts to
> > integrate e.g. Grove, nginx etc.)
> > ________
> > From: Rawlin Peters
> > Sent: Tuesday, December 18, 2018 2:20 PM
>
ting ATS as a caching proxy (hurting efforts to
> > integrate e.g. Grove, nginx etc.)
> > ________
> > From: Rawlin Peters
> > Sent: Tuesday, December 18, 2018 2:20 PM
> > To: dev@trafficcontrol.apache.org
> > Subject: Re: [EXTER
ol.apache.org
Subject: Re: [EXTERNAL] Re: Origins assigned to Multipe Delivery Services
produces indeterminate parent.config
Also, building more around DS types will make it even harder to get
away from DS types in the future too, which I know is something we've
discussed on this mailing list before
gt; > So no two Delivery Services may share an origin *regardless of cache
> > hierarchy* ? I've been told that DNS Delivery Services can have the same
> > origin as HTTP Delivery Services because they obey the same cache
> > hierarchy. You're saying that would
hing proxy (hurting efforts to
integrate e.g. Grove, nginx etc.)
From: Rawlin Peters
Sent: Tuesday, December 18, 2018 2:20 PM
To: dev@trafficcontrol.apache.org
Subject: Re: [EXTERNAL] Re: Origins assigned to Multipe Delivery Services
produces indeterminate par
ut that's definitely up for debate. With several release candidates
> for
> > > 3.0.0 that _doesn't_ include this restriction already in the wild, I
> > > wouldn't recommend putting it in there. That means to fix the bug as
> soon
> > > as
explicitly disallowed by ATS?
>
> From: Robert Butts
> Sent: Tuesday, December 18, 2018 1:09 PM
> To: dev@trafficcontrol.apache.org
> Subject: Re: [EXTERNAL] Re: Origins assigned to Multipe Delivery
> Services produce
would still produce invalid output and/or is explicitly disallowed
by ATS?
From: Robert Butts
Sent: Tuesday, December 18, 2018 1:09 PM
To: dev@trafficcontrol.apache.org
Subject: Re: [EXTERNAL] Re: Origins assigned to Multipe
d still produce invalid output and/or is explicitly disallowed
by ATS?
From: Robert Butts
Sent: Tuesday, December 18, 2018 1:09 PM
To: dev@trafficcontrol.apache.org
Subject: Re: [EXTERNAL] Re: Origins assigned to Multipe Delivery Servic
explicitly disallowed by ATS?
From: Robert Butts
Sent: Tuesday, December 18, 2018 1:09 PM
To: dev@trafficcontrol.apache.org
Subject: Re: [EXTERNAL] Re: Origins assigned to Multipe Delivery Services
produces indeterminate parent.config
>can you give an ex
>>
> >> > To be clear, the "Warning" I'm talking about would happen at startup,
> >> but
> >> > I'd like a UI-only constraint to come with that to disallow using the
> >> API
> >> > to bind the same origin to multiple Deliver
raint to come with that to disallow using the
>> API
>> > to bind the same origin to multiple Delivery Services with varying
>> > topography requirements. It wouldn't change the existing data, but
>> prevent
>> > users from creating more bad data.
>> >
>> > "warning" doe
ata, but
> prevent
> > users from creating more bad data.
> >
> > "warning" doesn't really sufficiently describe that, my bad.
> > ________________
> > From: Fieck, Brennan
> > Sent: Tuesday, December 18, 2018 11:24 AM
> > To: dev@tra
t;warning" doesn't really sufficiently describe that, my bad.
>
> From: Fieck, Brennan
> Sent: Tuesday, December 18, 2018 11:24 AM
> To: dev@trafficcontrol.apache.org
> Subject: Re: [EXTERNAL] Re: Origins assigned to Multipe Delivery
part of a 3.0.1 provided we had more changes that
would warrant a micro version bump.
From: Gray, Jonathan
Sent: Tuesday, December 18, 2018 9:34 AM
To: dev@trafficcontrol.apache.org
Subject: Re: [EXTERNAL] Re: Origins assigned to Multipe Delivery Services
produces indeterminate parent.config
-1 Ho
From: Gray, Jonathan
Sent: Tuesday, December 18, 2018 9:34 AM
To: dev@trafficcontrol.apache.org
Subject: Re: [EXTERNAL] Re: Origins assigned to Multipe Delivery Services
produces indeterminate parent.config
-1 Holding an ATC upgrade hostage to data cleanup seems like a bad idea. The
issue i
Subject: Re: [EXTERNAL] Re: Origins assigned to Multipe Delivery Services
produces indeterminate parent.config
I'm generally a fan of constrain your data in your database, but not
necessarily exclusively. I see this as a one-way cleanup/conversion so it
doesn't need to be
incentive to
clean up the data.
From: Gray, Jonathan
Sent: Tuesday, December 18, 2018 5:12 AM
To: dev@trafficcontrol.apache.org
Subject: Re: [EXTERNAL] Re: Origins assigned to Multipe Delivery Services
produces indeterminate parent.config
I'm genera
I'm generally a fan of constrain your data in your database, but not
necessarily exclusively. I see this as a one-way cleanup/conversion so it
doesn't need to be configurable; otherwise you have to ask the question what
happens if someone turns it off. That said, something in the UI layer woul
I'm not too concerned with existing deployments -- if an existing TO has
this config, it's exposed to this (what I would call) bug and their system
will have the negative impacts this causes.
+1 on the 'sufficiently advanced SQL query'. I could be +1 on using that to
drive config.
-1 on adding a g
That is an interesting idea...detect at TO startup whether or not
there are duplicate origins and operate in a "prevent duplicate
origins" state if no duplicates are found or "prevent conflicting DS
topologies" state if duplicates are found? So once operators have
replaced all the duplicate origins
These kinds of conditions should be detectable with a sufficiently advanced SQL
query. Is it possible to add the constraint if it passes and emit a warning
during TO startup otherwise? That would let you know the condition exists at
startup but not getting in your way and keep you out of troub
39 matches
Mail list logo
