-1 on "DS requests" long-term, post real Self Service, because there's no
need, it's unnecessary complexity.

More complexity means more code to maintain, more bugs. More complexity to
maintain in the database. It's also more UI complexity, which means more
tenants have to learn, more to get wrong, etc.

+1 on the validation. But that validation should be fast, and return UI
feedback, like highlighting fields red, or a notification. Beyond that,
when we have true SS, tenant users should have "save" and "snapshot/apply"
buttons, and maybe not even the latter. To paraphrase Einstein, "Everything
should be made as simple as possible, but no simpler."


On Mon, Feb 19, 2018 at 12:29 PM, Jeremy Mitchell <mitchell...@gmail.com>
wrote:

> 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