What if the default server set doesn't make sense for the self-service user's delivery service? For example, what if their DS only needs deployed to Denver but the default assignments are in every cachegroup?
Traditional DS-Server assignments will have to be overhauled with the Flexible Cachegroup (aka Bring Your Own Topology) effort, and I em envisioning that there will be a default Topology for DSes to be assigned to which should probably contain servers from all cachegroups. There would also be multiple other Topologies that a DS could be assigned to (e.g. regional), and a self-service user should be able to choose from some set of those Topologies I'd think. Then the self-service user can be somewhat in control of _where_ their DS gets deployed without having to pick individual caches. Operators would still be in charge of logically grouping servers into Server Groups and composing those into Topologies, but the choice of Topology would be left up to the self-service user. We could assign a visibility level to a Topology so that only self-service-approved Topologies are visible to self-service users. - Rawlin On Wed, Dec 5, 2018 at 1:10 PM Jason Tucker <[email protected]> wrote: > > Great, thanks Rob! Glad to hear it's already on the roadmap. > > __Jason > > On Wed, Dec 5, 2018 at 1:01 PM Robert Butts <[email protected]> > wrote: > > > Yep, already part of the Self Service plan. The plan is to add a > > "default_assignable" field to servers, to indicate which servers are > > assigned to new delivery services on creation. You're right, it's necessary > > for Self-Service, or non-operators wouldn't be able to create functioning > > DSes. And I agree, it doesn't seem reasonable to ever let non-operators > > make that decision. > > > > Full plan/spec is here, that's #8 under "Independent Delivery Service > > Changes", if you're interested: > > https://cwiki.apache.org/confluence/display/TC/Traffic+Control++Self+Service+Proposal+for+Change+Integrity#TrafficControlSelfServiceProposalforChangeIntegrity-IndependentDeliveryServiceChanges > > > > > > On Wed, Dec 5, 2018 at 10:52 AM Jason Tucker <[email protected]> > > wrote: > > > >> Hi folks - > >> > >> I've noticed a problem that we seem to run into over and over in our > >> environment, and would like to suggest a way to fix. > >> > >> Often times, I find that delivery services get assigned to cache servers > >> in > >> a very inconsistent way, due in part to the fact that assigning severs to > >> a > >> DS is a very manual process today. It seems to me that there is a need > >> here > >> to have something like "server group profiles". > >> > >> For example, for a given CDN you could have a "pre-production" profile > >> consisting of a small slice of caches, to be used for functional testing. > >> There would also be a "production" profile, consisting of the full > >> compliment of caches that should be in use at any given time. > >> > >> I envision this being used in such a way, that Ops folks would control the > >> contents of those profiles as needed, and that a default server group > >> profile (i.e. "production" profile) would be ASSIGNED BY DEFAULT to any > >> brand new Delivery Service that gets built, unless explicitly overridden. > >> > >> I think this would really make administration of server assignments much > >> simpler, as you can do it at a profile level, rather than having to touch > >> every DS individually to make changes. ALSO, this would solve the > >> inconsistency problem. ALSO ALSO, I think this should be an absolute > >> requirement for eventual self-service, because customers that are managing > >> their own DS'es SHOULD NOT have to care at all about edge server > >> specifics, > >> or what edges their DS should be assigned to. We've seen that our actual > >> CDN team members can't always manage these details consistently, so > >> there's > >> little hope that customers should be expected to do so. > >> > >> Thanks, > >> > >> __Jason > >> > >
