The more I think about this, the more I think it's not as straightforward as I think to queue updates for a delivery service (meaning to queue updates for all the caches employed by the ds).
For example, imagine you had a delivery service that employed 10 caches....and you removed 2 caches from the ds...then queue'd updates for the ds.....this would queue updates for the 8 remaining caches but really the 2 caches you removed are the ones that need the updates... So unless told otherwise or someone has a solution to this problem (I can't think of one currently), I'm gonna hold off on that issue. Jeremy On Wed, Feb 1, 2017 at 8:58 PM, Jeremy Mitchell <[email protected]> wrote: > Created this issue. Would like input from more people to ensure this is a > good idea and I'm not overlooking something... > > https://issues.apache.org/jira/browse/TC-129 > > On Tue, Jan 31, 2017 at 10:47 AM, Eric Friedrich (efriedri) < > [email protected]> wrote: > >> Yes, when modifying a DS, it would be useful to have an API to queue on >> just servers relevant to that DS. >> >> —Eric >> >> > On Jan 31, 2017, at 12:36 PM, Jeremy Mitchell <[email protected]> >> wrote: >> > >> > Currently, you can queue updates: >> > >> > - for a specific server >> > - for a specific cachegroup (all the servers in that cachegroup) >> > - for a specific cdn (all the servers in that cdn) >> > >> > but you can't queue updates for: >> > >> > - a specific delivery service (all the servers explicitly (edges) or >> > implicitly (mids) assigned to that DS) >> > >> > Does it make sense to add this functionality? At least to the API? >> > >> > I "think" when a delivery service change is made, it is common practice >> to >> > queue updates on the ENTIRE cdn that the DS belongs to. This seems like >> it >> > would unnecessarily queue updates for a lot of servers that don't >> belong to >> > the DS. >> > >> > I know we may move away from the queue update approach at some point but >> > does this functionality make sense in the short term? >> > >> > Jeremy >> >> >
