If you haven't had a chance to read https://cwiki.apache.org/
confluence/display/TC/Delivery+Service+Requests, I would recommend it.

Self-service is quite a large undertaking so to make it more digestible,
we've created the notion of "delivery service requests". Think of it like
PRs (or pull requests) for delivery services. When enabled, all delivery
service changes submitted in the Traffic Portal (create, update and delete)
are captured as requests that need to be fulfilled by an ops/admin user.
When disabled, all delivery service changes follow the normal flow and
currently require the ops/admin role.

There are a few advantages to this approach:

1. Because they are only "requests", we can allow users with non-elevated
permissions (ops/admin) to create these requests.
2. We can provide pseudo self-service in the short term while end-to-end,
automated self-service is designed and built.
3. Like a PR, there are 2 participants (in this case requester and
fulfiller). More participants == less errors.
4. There is a history of changes for a delivery service, who requested them
and who fulfilled them.

Here's an example of the workflow:

1. User submits a request to create a new delivery service
2. Ops/admin user reviews and fulfills the request (which creates the
delivery service and marks the request as "pending")
3. Ops/admin user does additional things like

   - assign caches to the ds
   - queue updates
   - snapshot config

4. Ops/admin user manually marks request as 'complete'

The DS has now been created and the user can attach SSL keys, manage
steering targets or just use the DS.

There are a few manual steps here as you can see and we need to remove
those (i.e. queue updates and snapshot). That will be the bigger challenge.

There will be some debate I'm sure whether these "delivery service
requests" will be part of the longer term solution but in my opinion, I
don't see why not.

Longer term example workflow:

1. User submits a request to create a new delivery service
2. Something validates the ds config (maybe a CI process?)
3. If validation was successful, changes are persisted to the database
4. Request is marked as 'complete'

No more human intervention.

Here are 2 PR's that have been submitted for this initiative. Comments,
concerns welcome.

API (traffic ops) -
https://github.com/apache/incubator-trafficcontrol/pull/1888
UI (traffic portal) -
https://github.com/apache/incubator-trafficcontrol/pull/1818

Jeremy







On Thu, Dec 14, 2017 at 4:00 PM, Durfey, Ryan <ryan_dur...@comcast.com>
wrote:

> We are starting on building a “Delivery Service Request” system into the
> Traffic Portal UI.  This will start as a manual system to streamline new
> service builds using user inputs and manual operations review and system
> updates.  This system will evolve over time into full self-service with
> automated validation and deployment.
>
> Initial Notes: https://cwiki.apache.org/confluence/display/TC/
> Delivery+Service+Requests
>
> Once we get a bit more organized and documented we will circulate concepts
> for comment.
>
> Ryan Durfey
> Sr. Product Manager - CDN | Comcast Technology Solutions
> 1899 Wynkoop Ste. 550 | Denver, CO 80202
> M | 303-524-5099
> ryan_dur...@comcast.com<mailto:ryan_dur...@comcast.com>
> CDN Support (24x7): 866-405-2993 or cdn_supp...@comcast.com<mailto:
> cdn_supp...@comcast.com>
>
>

Reply via email to