Thanks for all the input. Here's what I heard. For a refresher, these are the 7 things that a "non-ops" user should be able to perform to achieve "delivery service self-service":
1. CRUD delivery services - ✓ - non-ops users will be able to create "delivery service requests". ops users will be able to fulfill those requests. so indirectly, non-ops users can CRUD ds's. I will be creating documentation around this shortly. 2. Manage DS regexes - X - this action should continue to be limited to ops users...however, maybe we allow non-ops users to create cnames and cnames only that don't contain regex values but conform to hostname format only. more research needed here. 3. Manage SSL keys - ✓ - non-ops users should be able to manage (add, generate) ssl keys for their delivery services. 4. Manage URL sig keys - ✓ - non-ops users can already do this for their delivery services 5. Manage URI signing keys - X - this action should continue to be limited to ops users as it could be dangerous at the moment (i.e. bad neighbor behavior). need more research here. 6. Manage steering targets - ✓ - Tenancy dictates which delivery services can be defined as a target therefore no risk to allowing non-ops users to manage steering targets. (they can only point a steering ds to their own ds's) 7. Invalidate DS content - ✓ - non-ops users can already do this for their delivery services Not bad. 5 out of 7. I will follow up later regarding "Manage DS regexes" and "Manage URI signing keys" so we can figure out a way to provide that functionality to non-ops users... Thanks again, Jeremy On Mon, Feb 5, 2018 at 12:26 PM, Nir Sopher <[email protected]> wrote: > Hi Jeremy and all, > > Jeremy, thanks for putting it all together! > > I'll be short, as I mostly agree with most of point the Jeremy's pointed > out. > > Regarding the "DS regex", like Ryan IIUC, I believe, the operator needs to > be able to configure it and control it. > First of all as it defines a resource in the operator's domain. > Second, the definition of the regex requires some clear methodology to > avoid collisions, or reuse/abuse. > Following Rawlin remark, some reasonable default should be provided, but we > must have the ability to change it. > Note that path regexs are important as DS identifiers, supporting the SVA > open-caching scheme. > > For the last point, the DS/Server assignment, I believe it should be in the > hands of the operator. > In the future it can be delegated the the user, subject to capacity > management. The user should not be familiar with the actual caches, but can > use some filters/tagging for defining the caches to be used. > > Nir > > On Mon, Feb 5, 2018 at 8:23 PM, Rawlin Peters <[email protected]> > wrote: > > > Replies inline > > > > On Fri, Feb 2, 2018 at 1:43 PM, Jeremy Mitchell <[email protected]> > > wrote: > > > 2. Manage DS regexes > > > > > > Here's an explanation of this: > > > http://traffic-control-cdn.readthedocs.io/en/latest/ > > admin/traffic_ops/using.html#delivery-service-regexp > > > > > > Currently, this requires the Operations role and for good reason. The > > > danger here involves the risk of a normal user entering a bad regex. > For > > > example, it is my understanding that the regex in position zero needs > to > > > always follow this format: .*\.foo\..*. > > > > > > Maybe with some better API validation we could let normal users manage > DS > > > regexes....or maybe these end up going away in favor of something > > > better/easier...not sure yet... > > > > I think the approach that the Traffic Portal takes today is good. Just > > giving a DS a default HOST regex with order = 0 using the xml_id will > > probably cover most use cases for the DS. Then for the cases where > > someone is CNAMEing to the DS FQDN, the DS owner should be able to add > > a max number of HOST regexes with order > 0 matching the CNAME fqdn. > > We should probably just call those "CNAME aliases" or something and > > just expose them as a simple hostname list in the UI rather than as > > HOST regexes with a specific ordering. For a list of aliases, I don't > > think the order really matters at that point as long as they're > > greater than 0 and sequential. That operation could be safe for a > > regular DS owner assuming we validate that the alias is a valid > > hostname (not a regex), unique, and not in use anywhere else in that > > CDN. > > > > We might want to prohibit creating multiple HOST regexes with wildcard > > characters (i.e. non-CNAME-alias)...I'm not even sure there's a valid > > use case for that. > > > > I'm not totally familiar with the usage of PATH and HEADER regexes, > > but they both seem like they should be secondary to the primary HOST > > regex that's created by default (e.g. the request should be matched > > against all primary HOST regexes first before checking against the > > other types). Right now I can create a PATH regex that essentially > > black-holes other DSes (which ones get black-holed depends on the > > order DSes come in CRConfig.json, which seems non-deterministic). So > > we don't want to allow a regular DS owner to modify the PATH and > > HEADER types unless we modify TR to guarantee that primary-secondary > > relationship between HOST and PATH/HEADER regexes. > > > > > 6. Manage DS targets (steering* only) > > > > > > Here's an explanation of this: > > > http://traffic-control-cdn.readthedocs.io/en/latest/ > > admin/quick_howto/steering.html?highlight=steering > > > > > > Currently, to manage DS targets requires the Admin or Steering role. Is > > > there any harm in allowing a normal user to "steer" their delivery > > service > > > to another delivery service as long as the target delivery service > falls > > in > > > their tenancy? > > > > I think this should be alright as long as *all* target DSes of the > > Steering DS fall in their tenancy. > > > > -Rawlin > > > > On Fri, Feb 2, 2018 at 1:43 PM, Jeremy Mitchell <[email protected]> > > wrote: > > > As we move in the direction of self-service, there are a few obstacles > > that > > > need to be overcome and I'd like to discuss them a bit so grab a cup of > > > coffee... > > > > > > When I say self-service, what I really mean is "delivery service > > > self-service" or the ability to manage your own delivery services (as > > > dictated by tenancy) and everything related to those delivery services. > > > "Everything" includes the following (afaik): > > > > > > 1. Create/Read/Update/Delete delivery services > > > 2. Manage DS regexes > > > 3. Manage DS SSL keys (if applicable) > > > 4. Manage DS URL sig keys (if applicable) > > > 5. Manage DS URI signing keys (if applicable) > > > 6. Manage DS targets (steering* only) > > > 7. Creating DS invalidate content jobs > > > 8. Manage DS / cache assignments > > > > > > If you can't do 1-7 yourself, it's not really self-service is it? #8 is > > > debatable. > > > > > > I'll discuss each one: > > > > > > 1. Create/Read/Update/Delete delivery services > > > > > > Ideally, you could CRUD your own delivery services but our system has > > some > > > limitations. > > > > > > A) Our CDN is not properly insulated from bad DS configurations. If a > > user > > > enters a bad value, bad things could potentially happen to a cache or > > worse > > > the whole CDN. > > > B) Certain DS configuration changes requires queue updates and/or > > snapshot > > > for the change to take effect. We're not ready (nor will we ever be > > > probably) to let normal users queue updates and/or snapshot. > > > > > > So in the interim, we're working on the ability to allow normal users > to > > > create "delivery service requests" to facilitate > > creating/updating/deleting > > > a delivery service. These "requests" will have to be reviewed/fulfilled > > by > > > a higher level user (Ops or Admin) who can then queue/snapshot if > needed. > > > > > > 2. Manage DS regexes > > > > > > Here's an explanation of this: > > > http://traffic-control-cdn.readthedocs.io/en/latest/ > > admin/traffic_ops/using.html#delivery-service-regexp > > > > > > Currently, this requires the Operations role and for good reason. The > > > danger here involves the risk of a normal user entering a bad regex. > For > > > example, it is my understanding that the regex in position zero needs > to > > > always follow this format: .*\.foo\..*. > > > > > > Maybe with some better API validation we could let normal users manage > DS > > > regexes....or maybe these end up going away in favor of something > > > better/easier...not sure yet... > > > > > > 3. Manage DS SSL keys > > > > > > SSL keys are only applicable where protocol > 0 (HTTPS, HTTP AND HTTPS, > > or > > > HTTP TO HTTPS) and currently, to manage them requires the Admin role. > > Why? > > > I'm not sure. Is their harm in letting normal users manage their own > SSL > > > keys? > > > > > > 4. Manage DS URL sig keys > > > > > > URL sig keys ( > > > http://traffic-control-cdn.readthedocs.io/en/latest/ > > admin/traffic_ops/using.html#generate-url-sig-keys) > > > are only applicable where signingAlgorithm = 'url_sig' and currently, > to > > > manage them requires NO role apparently (only a tenancy check is > > > performed). This is the 1st one on the list that a "normal" user can do > > > currently. > > > > > > 5. Manage DS URI signing keys > > > > > > URI signing keys are only applicable where signingAlgorithm = > > 'uri_signing' > > > and currently, to manage DS URI signing keys requires the Admin role. > Is > > it > > > necessary to restrict this functionality to Admins only or can we allow > > > normal users to mange URI signing keys for their DS's? > > > > > > 6. Manage DS targets (steering* only) > > > > > > Here's an explanation of this: > > > http://traffic-control-cdn.readthedocs.io/en/latest/ > > admin/quick_howto/steering.html?highlight=steering > > > > > > Currently, to manage DS targets requires the Admin or Steering role. Is > > > there any harm in allowing a normal user to "steer" their delivery > > service > > > to another delivery service as long as the target delivery service > falls > > in > > > their tenancy? > > > > > > 7. Creating DS invalidate content jobs > > > > > > http://traffic-control-cdn.readthedocs.io/en/latest/ > > admin/traffic_ops/using.html?highlight=invalidate#invalidate-content > > > > > > You can currently do this for your own DS's. This is the 2nd one on the > > > list that a "normal" user can do currently. > > > > > > 8. Manage DS / cache assignments > > > > > > This is the debatable one. To provide true delivery service > self-service > > > should a user have the ability to determine which caches are assigned > to > > > their delivery service. I'm thinking NO. Currently, this action > requires > > > the Ops role and I'm in favor of leaving it that way... > > > > > > In summary, to provide true delivery service self-service I think we > need > > > to do a few things: > > > > > > 1. Introduce DS requests until the day in which DS configurations can > be > > > guaranteed and queue updates/snapshot becomes a thing of the past. > (this > > is > > > in progress) > > > 2. Revisit DS regexes or make their management more fool proof. > > > 3. Tweak the roles of these actions. Currently, a lot of these things > are > > > reserved for Ops/Admin. We have to change that or full DS self-service > if > > > not possible. I'd like to make each of these things accessible to users > > > with the "Portal" role with the exception of #8. > > > > > > Thoughts? Concerns? Funny jokes? > > > > > > Jeremy > > >
