[GitHub] [trafficcontrol] srijeet0406 commented on a change in pull request #5834: CDN Locks Blueprint

[GitBox <gi...@apache.org>]

srijeet0406 commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r630524718



##########
File path: blueprints/to-locks.md
##########
@@ -0,0 +1,272 @@
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+    http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+# CDN Traffic Ops Locks
+
+## Problem Description
+
+Currently, there is no way to guarantee that only your changes will make their way into a snapshot or queue updates 
+for the servers of a CDN. If somebody else makes changes while you're in the middle of modifying your CDN components
+or properties, their changes will "dirty" your snapshot and change the integrity of the data that you'd expect in your 
+snapshot. This could result in data mismatches and inconsistencies.
+
+CDN locks will serve as a way to avoid data corruption in snapshots and queue update activities by ensuring
+that only the intended user(s) is able to pass their changes to the snapshot/ queue updates. By placing locks 
+on a CDN, a user can essentially block out other users from modifying data that would dirty their view of the 
+CDN.
+
+This will be an optional feature in Traffic Ops/ Traffic Portal, which can be made use of by a user for their 
+own guarantee of a "clean slate".
+
+## Proposed Change
+
+We propose a locking mechanism by which you can guarantee the exclusivity of your changes.
+With CDN locks, you can ensure one or both of the following conditions:
+- Only you can make changes and snap/ queue your CDN (exclusive locks)
+- Anybody can make changes but only you can snap/ queue your CDN (shared locks)
+
+`Exclusive` locks will help in cases where you are not collaborating with other users on the changes that you are
+making to a CDN. We anticipate all automated scripts and cron jobs to make use of these exclusive locks.
+
+The second category of locks is `shared` locks. This will be useful in a scenario when a group of users is working
+on different parts of a CDN, but their changes are not related to each other. In such a case, any number of users can 
+grab the shared lock and make changes on the CDN. However, only the first user who grabbed the shared lock can actually
+snap/ queue updates on the CDN. This way, the first user to grab the lock still has the chance to review the changes, and
+also ensure that nobody else snaps/ queues the CDN before they are done with their intended modifications.
+
+There is also the third option of not using locks at all, in which case, the software will behave exactly the way it does
+today, that is, no safety that your changes will not be corrupted by somebody else before you snap/ queue.
+
+For unlocking a CDN under normal circumstances, only the user who has acquired the lock can unlock it (both shared 
+and exclusive). However, in the rare case that a user `A` forgets to unlock a CDN, an `admin` role user can unlock 
+the CDN on behalf of user `A`.
+
+### Traffic Portal Impact
+
+- Landing Page
+    - New "lock" icon to give the user the ability to lock a particular CDN
+    - A dropdown list that appears when you click the above mentioned lock icon, which lists the list of CDNs that you can lock
+    - A `Message` field that appears under the dropdown list that the user can populate with a custom message stating the reason behind locking the CDN
+    - A `Shared` field that can be set to `true` or `false` based on user requirement
+    - A CDN notification displaying which CDN is locked by which user
+    - An "unlock" option that appears next to the notification, only for the user who has locked the CDN
+    - A way for the `admin` user to be able to unlock CDNs on other users' behalf
+    
+- Snapshot/ Queue Updates Page
+    - A way to display an error on a snap/ queue operation by one user, if another user has the lock on that CDN
+
+### Traffic Ops Impact
+
+`/cdn_locks`
+- List all CDN Locks
+- GET+POST+DELETE
+
+Traffic Ops will need to add the logic to check for locks before snapping/ queueing a CDN. It'll also need to account for
+`shared` vs `exclusive` locks, and forbid a user from snapping/ queueing a CDN if another user possesses a lock on that CDN.
+
+#### REST API Impact
+
+The following is the JSON representation of a `CDN_Lock` object:
+```JSON
+{
+  "userName": "foo",
+  "cdnName": "cdn1",
+  "message": "snapping cdn",
+  "shared": false,
+  "creator": true,

Review comment:
       Yeah, so the `creator` field is for the following case:
   Say user A acquires a shared lock on a CDN. This creates a shared lock in the database with the creator set to `user A`
   After that, user B also acquires a shared lock on the same CDN. This time the creator does not get set to `user B`, but is set as `user A`, since `A` was the first one to create this shared lock.
   Now when user B tries to snap the CDN, the system should reject the request saying that since the "creator" (or first creator) of the shared lock was user A, only A can snap/ queue the CDN. Does that make sense?




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org