You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficcontrol.apache.org by GitBox <gi...@apache.org> on 2021/05/11 18:06:52 UTC
[GitHub] [trafficcontrol] srijeet0406 opened a new pull request #5834: CDN Locks Blueprint
srijeet0406 opened a new pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834
<!--
************ STOP!! ************
If this Pull Request is intended to fix a security vulnerability, DO NOT submit it! Instead, contact
the Apache Software Foundation Security Team at security@trafficcontrol.apache.org and follow the
guidelines at https://www.apache.org/security/ regarding vulnerability disclosure.
-->
## What does this PR (Pull Request) do?
<!-- Explain the changes you made here. If this fixes an Issue, identify it by
replacing the text in the checkbox item with the Issue number e.g.
- [x] This PR fixes #9001 OR is not related to any Issue
^ This will automatically close Issue number 9001 when the Pull Request is
merged (The '#' is important).
Be sure you check the box properly, see the "The following criteria are ALL
met by this PR" section for details.
-->
- [x] This PR is not related to any Issue <!-- You can check for an issue here: https://github.com/apache/trafficcontrol/issues -->
## Which Traffic Control components are affected by this PR?
<!-- Please delete all components from this list that are NOT affected by this
Pull Request. Also, feel free to add the name of a tool or script that is
affected but not on the list.
Additionally, if this Pull Request does NOT affect documentation, please
explain why documentation is not required. -->
- Documentation
## What is the best way to verify this PR?
<!-- Please include here ALL the steps necessary to test your Pull Request. If
it includes tests (and most should), outline here the steps needed to run the
tests. If not, lay out the manual testing procedure and please explain why
tests are unnecessary for this Pull Request. -->
Go through the blueprint and make sure it looks correct .
## If this is a bug fix, what versions of Traffic Control are affected?
<!-- If this PR fixes a bug, please list here all of the affected versions - to
the best of your knowledge. It's also pretty helpful to include a commit hash
of where 'master' is at the time this PR is opened (if it affects master),
because what 'master' means will change over time. For example, if this PR
fixes a bug that's present in master (at commit hash '1df853c8'), in v4.0.0,
and in the current 4.0.1 Release candidate (e.g. RC1), then this list would
look like:
- master (1df853c8)
- 4.0.0
- 4.0.1 (RC1)
If you don't know what other versions might have this bug, AND don't know how
to find the commit hash of 'master', then feel free to leave this section
blank (or, preferably, delete it entirely).
-->
- master
## The following criteria are ALL met by this PR
<!-- Check the boxes to signify that the associated statement is true. To
"check a box", replace the space inside of the square brackets with an 'x'.
e.g.
- [ x] <- Wrong
- [x ] <- Wrong
- [] <- Wrong
- [*] <- Wrong
- [x] <- Correct!
-->
- [x] Tests are unnecessary, this is just a blueprint PR
- [x] This PR includes documentation
- [x] This PR doe not include an update to CHANGELOG.md
- [x] This PR includes any and all required license headers
- [x] This PR **DOES NOT FIX A SERIOUS SECURITY VULNERABILITY** (see [the Apache Software Foundation's security guidelines](https://www.apache.org/security/) for details)
## Additional Information
<!-- If you would like to include any additional information on the PR for
potential reviewers please put it here.
Some examples of this would be:
- Before and after screenshots/gifs of the Traffic Portal if it is affected
- Links to other dependent Pull Requests
- References to relevant context (e.g. new/updates to dependent libraries,
mailing list records, blueprints)
Feel free to leave this section blank (or, preferably, delete it entirely).
-->
<!--
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.
-->
--
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
[GitHub] [trafficcontrol] srijeet0406 commented on pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
srijeet0406 commented on pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#issuecomment-840628344
Alright, all changes should be done now.
--
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
[GitHub] [trafficcontrol] ocket8888 commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
ocket8888 commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r630424027
##########
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,
+ "lastUpdated": "2021-05-10 16:03:34-06"
+}
+```
+
+The following table describes the top level `CDN_Lock` object:
+
+| field | type | optionality | description |
+| ----------- | --------------------------- | ----------- | ----------------------------------------------------------------------------------------|
+| userName | string | required | the user name of the user that wants to acquire a lock on the CDN |
Review comment:
can we make this `username` to line up with the casing of the User object field it represents?
##########
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,
+ "lastUpdated": "2021-05-10 16:03:34-06"
+}
+```
+
+The following table describes the top level `CDN_Lock` object:
+
+| field | type | optionality | description |
+| ----------- | --------------------------- | ----------- | ----------------------------------------------------------------------------------------|
+| userName | string | required | the user name of the user that wants to acquire a lock on the CDN |
+| cdnName | string | required | the name of the CDN on which the lcok needs to be acquired |
+| message | string | optional | the message stating a reason behind locking the CDN |
+| shared | boolean | required | whether or not this is a shared lock |
+| creator | boolean | optional | whether or not the requesting `userName` is the first one to acquire a lock on `cdnName`|
+| lastUpdated | time | optional | the last time this lock was updated |
+
+**API constraints:**
+- a `userName` and `cdnName` combination must be unique id `shared` is set to `false`. In other words, there can be only one `exclusive`
+lock for a CDN
+- a CDN can have multiple `shared` locks
+- the `creator` will be set to `true` if the user is the first one acquiring a lock for the specified `cdnName`
+- a user can snap/ queue a CDN only if the `creator` field corresponding to the `userName` and `cdnName` combination is `true`
+- a user can delete their `exclusive` lock whenever, since the user is the creator in this case
+- a user who is the creator cannot delete their `shared` lock until all other non-creator users have releases their shared locks for that CDN
+- an `admin` user can delete the locks of other users on any CDN
Review comment:
This should also be expressed as a User Permission too (currently called a "Capability")
##########
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,
+ "lastUpdated": "2021-05-10 16:03:34-06"
+}
+```
+
+The following table describes the top level `CDN_Lock` object:
+
+| field | type | optionality | description |
+| ----------- | --------------------------- | ----------- | ----------------------------------------------------------------------------------------|
+| userName | string | required | the user name of the user that wants to acquire a lock on the CDN |
+| cdnName | string | required | the name of the CDN on which the lcok needs to be acquired |
+| message | string | optional | the message stating a reason behind locking the CDN |
+| shared | boolean | required | whether or not this is a shared lock |
+| creator | boolean | optional | whether or not the requesting `userName` is the first one to acquire a lock on `cdnName`|
+| lastUpdated | time | optional | the last time this lock was updated |
+
+**API constraints:**
+- a `userName` and `cdnName` combination must be unique id `shared` is set to `false`. In other words, there can be only one `exclusive`
+lock for a CDN
+- a CDN can have multiple `shared` locks
+- the `creator` will be set to `true` if the user is the first one acquiring a lock for the specified `cdnName`
+- a user can snap/ queue a CDN only if the `creator` field corresponding to the `userName` and `cdnName` combination is `true`
+- a user can delete their `exclusive` lock whenever, since the user is the creator in this case
+- a user who is the creator cannot delete their `shared` lock until all other non-creator users have releases their shared locks for that CDN
+- an `admin` user can delete the locks of other users on any CDN
+
+Three new endpoints will be added for `GET`, `POST` and `DELETE` functionality with respect to CDN locks.
+##### GET `cdn_locks`
+
+response JSON:
+```JSON
+{
+ "response": [
+ {
+ "userName": "foo",
+ "cdnName": "cdn1",
+ "message": "snapping cdn",
+ "shared": true,
+ "creator": true,
+ "lastUpdated": "2021-05-10 16:03:34-06"
+ },
+ {
+ "userName": "bar",
+ "cdnName": "cdn2",
+ "message": "queue cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10 17:04:34-06"
+ }
+ ]
+}
+```
+
+##### POST `cdn_locks`
+
+request JSON:
+```JSON
+{
+ "cdnName": "bar",
+ "message": "snapping cdn",
+ "shared": false
+}
+```
+
+response JSON:
+```JSON
+{
+ "alerts": [
+ {
+ "text": "CDN lock acquired!",
+ "level": "success"
+ }
+ ],
+ "response": {
+ "userName": "foo",
+ "cdnName": "bar",
+ "message": "snapping cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10 17:05:30-06"
+ }
+}
+```
+
+##### `DELETE /cdn_locks?cdn=bar`
+
+response JSON:
+```JSON
+{
+ "alerts": [
+ {
+ "text": "Cdn lock deleted",
+ "level": "success"
+ }
+ ]
+}
+```
Review comment:
From the API Guidelines:
> _"When ... deletion successfully occurs, the response body MUST contain a representation of the destroyed object."_
##########
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
Review comment:
This is probably too detailed to get into here, but I think the form should be a dialog because squeezing all those controls into a dropdown sounds annoying to both user and developer.
##########
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
Review comment:
Won't this will also require changes to
- `/cachegroups/{{ID}}/queue_update`
- `/cdns/{{ID}}/queue_update`
- `/servers/{{hostname}}/queue_update`
- `/snapshot`
- `/topologies/{{name}}/queue_update`
?
##########
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,
+ "lastUpdated": "2021-05-10 16:03:34-06"
+}
+```
+
+The following table describes the top level `CDN_Lock` object:
+
+| field | type | optionality | description |
+| ----------- | --------------------------- | ----------- | ----------------------------------------------------------------------------------------|
+| userName | string | required | the user name of the user that wants to acquire a lock on the CDN |
+| cdnName | string | required | the name of the CDN on which the lcok needs to be acquired |
+| message | string | optional | the message stating a reason behind locking the CDN |
+| shared | boolean | required | whether or not this is a shared lock |
+| creator | boolean | optional | whether or not the requesting `userName` is the first one to acquire a lock on `cdnName`|
+| lastUpdated | time | optional | the last time this lock was updated |
+
+**API constraints:**
+- a `userName` and `cdnName` combination must be unique id `shared` is set to `false`. In other words, there can be only one `exclusive`
+lock for a CDN
+- a CDN can have multiple `shared` locks
+- the `creator` will be set to `true` if the user is the first one acquiring a lock for the specified `cdnName`
+- a user can snap/ queue a CDN only if the `creator` field corresponding to the `userName` and `cdnName` combination is `true`
+- a user can delete their `exclusive` lock whenever, since the user is the creator in this case
+- a user who is the creator cannot delete their `shared` lock until all other non-creator users have releases their shared locks for that CDN
+- an `admin` user can delete the locks of other users on any CDN
+
+Three new endpoints will be added for `GET`, `POST` and `DELETE` functionality with respect to CDN locks.
+##### GET `cdn_locks`
+
+response JSON:
+```JSON
+{
+ "response": [
+ {
+ "userName": "foo",
+ "cdnName": "cdn1",
+ "message": "snapping cdn",
+ "shared": true,
+ "creator": true,
+ "lastUpdated": "2021-05-10 16:03:34-06"
+ },
+ {
+ "userName": "bar",
+ "cdnName": "cdn2",
+ "message": "queue cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10 17:04:34-06"
+ }
+ ]
+}
+```
+
+##### POST `cdn_locks`
+
+request JSON:
+```JSON
+{
+ "cdnName": "bar",
+ "message": "snapping cdn",
+ "shared": false
+}
+```
+
+response JSON:
+```JSON
+{
+ "alerts": [
+ {
+ "text": "CDN lock acquired!",
+ "level": "success"
+ }
+ ],
+ "response": {
+ "userName": "foo",
+ "cdnName": "bar",
+ "message": "snapping cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10 17:05:30-06"
+ }
+}
+```
+
+##### `DELETE /cdn_locks?cdn=bar`
+
+response JSON:
+```JSON
+{
+ "alerts": [
+ {
+ "text": "Cdn lock deleted",
+ "level": "success"
+ }
+ ]
+}
+```
+
+#### Client Impact
+
+New Go client methods will be added for the `/cdn_locks` endpoints in order to write TO API tests for the new endpoints.
+
+#### Data Model / Database Impact
+<!--
+*How* will this impact the Traffic Ops data model?
+*How* will this impact the Traffic Ops database schema?
+
+What changes to the lib/go-tc structs will be required?
+What new tables and columns will be required?
+How will existing tables and columns be changed?
+What are the column data types and modifiers?
+What are the FK references and constraints?
+-->
+A new database table for `cdn_lock`, as described below, will be created.
+```text
+ Table "traffic_ops.cdn_lock"
+ Column | Type | Collation | Nullable | Default
+---------------+--------------------------+-----------+----------+--------
+ id | bigint | | not null |
+ username | text | | not null |
+ cdn_name | text | | not null |
+ message | test | | |
+ shared | boolean | | not null | true
+ creator | boolean | | not null | false
+ last_updated | timestamp with time zone | | not null | now()
+Indexes:
+ "pk_cdn_lock" PRIMARY KEY(id)
+Foreign-key constraints:
+ "fk_lock_cdn" FOREIGN KEY (cdn_name) REFERENCES cdn(name)
+ "fk_lock_username" FOREIGN KEY ("username") REFERENCES tm_user(username)
+```
Review comment:
Should this have a uniqueness constraint of some kind on `(username, cdn_name)`? A user shouldn't be able to have more than one lock on a single CDN, right?
##########
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
Review comment:
I would argue that the user should be incapable of attempting to snap or queue a locked CDN in Traffic Portal.
##########
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,
+ "lastUpdated": "2021-05-10 16:03:34-06"
+}
+```
+
+The following table describes the top level `CDN_Lock` object:
+
+| field | type | optionality | description |
+| ----------- | --------------------------- | ----------- | ----------------------------------------------------------------------------------------|
+| userName | string | required | the user name of the user that wants to acquire a lock on the CDN |
+| cdnName | string | required | the name of the CDN on which the lcok needs to be acquired |
+| message | string | optional | the message stating a reason behind locking the CDN |
+| shared | boolean | required | whether or not this is a shared lock |
+| creator | boolean | optional | whether or not the requesting `userName` is the first one to acquire a lock on `cdnName`|
+| lastUpdated | time | optional | the last time this lock was updated |
+
+**API constraints:**
+- a `userName` and `cdnName` combination must be unique id `shared` is set to `false`. In other words, there can be only one `exclusive`
+lock for a CDN
+- a CDN can have multiple `shared` locks
+- the `creator` will be set to `true` if the user is the first one acquiring a lock for the specified `cdnName`
+- a user can snap/ queue a CDN only if the `creator` field corresponding to the `userName` and `cdnName` combination is `true`
+- a user can delete their `exclusive` lock whenever, since the user is the creator in this case
+- a user who is the creator cannot delete their `shared` lock until all other non-creator users have releases their shared locks for that CDN
+- an `admin` user can delete the locks of other users on any CDN
+
+Three new endpoints will be added for `GET`, `POST` and `DELETE` functionality with respect to CDN locks.
+##### GET `cdn_locks`
+
+response JSON:
+```JSON
+{
+ "response": [
+ {
+ "userName": "foo",
+ "cdnName": "cdn1",
+ "message": "snapping cdn",
+ "shared": true,
+ "creator": true,
+ "lastUpdated": "2021-05-10 16:03:34-06"
Review comment:
Can we make these RFC3339-compliant in keeping with the API guidelines?
##########
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,
+ "lastUpdated": "2021-05-10 16:03:34-06"
+}
+```
+
+The following table describes the top level `CDN_Lock` object:
+
+| field | type | optionality | description |
+| ----------- | --------------------------- | ----------- | ----------------------------------------------------------------------------------------|
+| userName | string | required | the user name of the user that wants to acquire a lock on the CDN |
+| cdnName | string | required | the name of the CDN on which the lcok needs to be acquired |
Review comment:
could we just call that `cdn`, since they are only identified in one way here (by name)?
##########
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,
+ "lastUpdated": "2021-05-10 16:03:34-06"
+}
+```
+
+The following table describes the top level `CDN_Lock` object:
+
+| field | type | optionality | description |
+| ----------- | --------------------------- | ----------- | ----------------------------------------------------------------------------------------|
+| userName | string | required | the user name of the user that wants to acquire a lock on the CDN |
+| cdnName | string | required | the name of the CDN on which the lcok needs to be acquired |
+| message | string | optional | the message stating a reason behind locking the CDN |
+| shared | boolean | required | whether or not this is a shared lock |
+| creator | boolean | optional | whether or not the requesting `userName` is the first one to acquire a lock on `cdnName`|
+| lastUpdated | time | optional | the last time this lock was updated |
+
+**API constraints:**
+- a `userName` and `cdnName` combination must be unique id `shared` is set to `false`. In other words, there can be only one `exclusive`
+lock for a CDN
+- a CDN can have multiple `shared` locks
+- the `creator` will be set to `true` if the user is the first one acquiring a lock for the specified `cdnName`
+- a user can snap/ queue a CDN only if the `creator` field corresponding to the `userName` and `cdnName` combination is `true`
+- a user can delete their `exclusive` lock whenever, since the user is the creator in this case
+- a user who is the creator cannot delete their `shared` lock until all other non-creator users have releases their shared locks for that CDN
+- an `admin` user can delete the locks of other users on any CDN
+
+Three new endpoints will be added for `GET`, `POST` and `DELETE` functionality with respect to CDN locks.
+##### GET `cdn_locks`
+
+response JSON:
+```JSON
+{
+ "response": [
+ {
+ "userName": "foo",
+ "cdnName": "cdn1",
+ "message": "snapping cdn",
+ "shared": true,
+ "creator": true,
+ "lastUpdated": "2021-05-10 16:03:34-06"
+ },
+ {
+ "userName": "bar",
+ "cdnName": "cdn2",
+ "message": "queue cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10 17:04:34-06"
+ }
+ ]
+}
+```
+
+##### POST `cdn_locks`
+
+request JSON:
+```JSON
+{
+ "cdnName": "bar",
+ "message": "snapping cdn",
+ "shared": false
+}
+```
+
+response JSON:
+```JSON
+{
+ "alerts": [
+ {
+ "text": "CDN lock acquired!",
+ "level": "success"
+ }
+ ],
+ "response": {
+ "userName": "foo",
+ "cdnName": "bar",
+ "message": "snapping cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10 17:05:30-06"
+ }
+}
+```
+
+##### `DELETE /cdn_locks?cdn=bar`
+
+response JSON:
+```JSON
+{
+ "alerts": [
+ {
+ "text": "Cdn lock deleted",
+ "level": "success"
+ }
+ ]
+}
+```
+
+#### Client Impact
+
+New Go client methods will be added for the `/cdn_locks` endpoints in order to write TO API tests for the new endpoints.
+
+#### Data Model / Database Impact
+<!--
+*How* will this impact the Traffic Ops data model?
+*How* will this impact the Traffic Ops database schema?
+
+What changes to the lib/go-tc structs will be required?
+What new tables and columns will be required?
+How will existing tables and columns be changed?
+What are the column data types and modifiers?
+What are the FK references and constraints?
+-->
+A new database table for `cdn_lock`, as described below, will be created.
+```text
+ Table "traffic_ops.cdn_lock"
+ Column | Type | Collation | Nullable | Default
+---------------+--------------------------+-----------+----------+--------
+ id | bigint | | not null |
+ username | text | | not null |
+ cdn_name | text | | not null |
+ message | test | | |
+ shared | boolean | | not null | true
+ creator | boolean | | not null | false
Review comment:
`creator` is listed as optional in the data model changes, should it be required since this is `not null`?
--
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
[GitHub] [trafficcontrol] mitchell852 commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
mitchell852 commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r631315027
##########
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
Review comment:
yeah, creating/maintaining a list of shared lock users would be unmanageable imo. so it seems there are just 2 types of locks:
exclusive lock: only the owner of the lock can snap/queue OR make cdn changes (that affect the snap/queue)
shared lock: only the owner of the lock can snap/queue but ANYBODY can make cdn changes (that affect the snap/queue)
--
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
[GitHub] [trafficcontrol] ocket8888 commented on pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
ocket8888 commented on pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#issuecomment-839233519
Well I was thinking that you could just do
1. User `A` grabs a shared lock on CDN `foo`.
2. Users `B` and `C` can still make changes, because the lock is "shared", but cannot snap or queue
3. User `A` deletes the shared lock. Now anyone can snap or queue
It's simpler, but it doesn't let you distribute locks so that anyone can prevent everyone else from snapping or queuing and I'm just wondering why you'd want to do that? I don't think it's a security risk or anything, just wondering what the use case is,
--
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
[GitHub] [trafficcontrol] srijeet0406 commented on pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
srijeet0406 commented on pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#issuecomment-840105303
> > i think you've overcomplicated it. i think this is all that is needed:
> > ```
> > exclusive lock: only owner can make cdn changes/snap/queue
> > shared lock: only owner can snap/queue; owner and non-owners can make cdn changes
> > no lock: anyone can make cdn changes/snap/queue
> > ```
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > the user can decide what level of protection they are looking for. i'm pretty sure this is what @rawlinp was thinking when he proposed the shared lock.
>
> Yeah, that is what I was thinking. I thought there would only be a single exclusive lock and a single shared lock (per-CDN). Each lock can only have one owner at a time, and only one type of lock can be held at a time (per-CDN).
>
> I think it helps to start with the use cases behind each type of lock. For example, if I wanted to update a DS certificate, I could grab the exclusive lock since I don't want anyone else's changes to be propagated until I've had a chance to test the new cert on a single cache. Once I've verified the cert, I will queue the entire CDN then release the exclusive lock.
>
> As another example, say there are a lot of certs about to expire and we want to divide the work among multiple operators. One operator would grab the shared lock (preventing anyone else from queuing updates). The other operators are still free to update their certs anytime (since only a shared lock is held), and when ready, the lock holder will queue updates on single cache. Then all the operators can test their certs before the lock holder queues the entire CDN and releases the shared lock.
>
> We shouldn't make this solution overly complicated, since I see this more as a temporary solution until we have the time to tackle the full solution (delivery service snapshots and server snapshots). Right?
Alright, I think I may have misunderstood your explanation of "shared" locks earlier. This will simplify the solution a lot. I'll make the changes to the blueprint.
--
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
[GitHub] [trafficcontrol] srijeet0406 commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
srijeet0406 commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r631323799
##########
File path: blueprints/to-locks.md
##########
@@ -0,0 +1,279 @@
+<!--
+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
+ - Disable the snap/ queue button 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.
+The following endpoints will need to handle the locks logic:
+- `/cachegroups/{{ID}}/queue_update`
+- `/cdns/{{ID}}/queue_update`
+- `/servers/{{hostname}}/queue_update`
+- `/snapshot`
+- `/topologies/{{name}}/queue_update`
+
+#### REST API Impact
+
+The following is the JSON representation of a `CDN_Lock` object:
+```JSON
+{
+ "username": "foo",
+ "cdn": "cdn1",
+ "message": "snapping cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10T16:03:34-06:00"
+}
+```
+
+The following table describes the top level `CDN_Lock` object:
+
+| field | type | optionality | description |
+| ----------- | --------------------------- | ----------- | ----------------------------------------------------------------------------------------|
+| username | string | required | the user name of the user that wants to acquire a lock on the CDN |
+| cdn | string | required | the name of the CDN on which the lcok needs to be acquired |
+| message | string | optional | the message stating a reason behind locking the CDN |
+| shared | boolean | required | whether or not this is a shared lock |
+| creator | boolean | required | whether or not the requesting `username` is the first one to acquire a lock on `cdn`|
+| lastUpdated | time | required | the last time this lock was updated |
+
+**API constraints:**
+- a `username` and `cdn` combination must be unique if `shared` is set to `false`. In other words, there can be only one `exclusive`
+lock for a CDN
+- a CDN can have multiple `shared` locks
+- the `creator` will be set to `true` if the user is the first one acquiring a lock for the specified `cdn`
+- a user can snap/ queue a CDN only if the `creator` field corresponding to the `username` and `cdn` combination is `true`
+- a user can delete their `exclusive` lock whenever, since the user is the creator in this case
+- a user who is the creator cannot delete their `shared` lock until all other non-creator users have releases their shared locks for that CDN
+- a user with at least `all-read` and `all-write` capabilities can delete the locks of other users on any CDN. The `all-write` capability will be modified
+to include a new capability `delete-all-locks`.
+
+Three new endpoints will be added for `GET`, `POST` and `DELETE` functionality with respect to CDN locks.
+##### GET `cdn_locks`
+
+response JSON:
+```JSON
+{
+ "response": [
+ {
+ "username": "foo",
+ "cdn": "cdn1",
+ "message": "snapping cdn",
+ "shared": true,
+ "creator": true,
+ "lastUpdated": "2021-05-10T16:03:34-06:00"
+ },
+ {
+ "username": "bar",
+ "cdn": "cdn2",
+ "message": "queue cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10T17:04:34-06:00"
+ }
+ ]
+}
+```
+
+##### POST `cdn_locks`
+
+request JSON:
+```JSON
+{
+ "cdn": "bar",
+ "message": "snapping cdn",
+ "shared": false
+}
+```
+
+response JSON:
+```JSON
+{
+ "alerts": [
+ {
+ "text": "CDN lock acquired!",
+ "level": "success"
+ }
+ ],
+ "response": {
+ "username": "foo",
+ "cdn": "bar",
+ "message": "snapping cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10T17:05:30-06:00"
+ }
+}
+```
+
+##### `DELETE /cdn_locks?cdn=bar`
+
+response JSON:
+```JSON
+{
+ "alerts": [
+ {
+ "text": "Cdn lock deleted",
+ "level": "success"
+ }
+ ],
+ "response": {
+ "username": "foo",
+ "cdn": "bar",
+ "message": "snapping cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10T17:05:30-06:00"
+ }
+}
+```
+
+#### Client Impact
+
+New Go client methods will be added for the `/cdn_locks` endpoints in order to write TO API tests for the new endpoints.
+
+#### Data Model / Database Impact
Review comment:
In the first scenario, if user 2 uses `If-UnModified-Since` in their request (which we can make a requirement in the backend).
For the second scenario, we can add a mutex or some kind of sync mechanism to make sure that a lock cannot be released by the "owner" when a snap is in progress. Frankly, I think thats a very rare edge case, because the snap usually takes a very small amount of time, and you would really have to try hard to release the lock between the time you press the `snap` button and the snap completes.
Note that when `user1` has a lock on `cdn` (assuming `user1` is the owner of the lock), only `user1` can snap/ queue, so it won't really matter if another user that has the shared lock on `cdn` releases the lock during this time or not. Hope that makes 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
[GitHub] [trafficcontrol] srijeet0406 commented on pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
srijeet0406 commented on pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#issuecomment-839237522
So I think the main use case for this was the scenario when a group of users is working on modifying different areas of a CDN, say, DS and servers. We would want to preserve the singularity of the ability to snap/ queue, while adding some safety to it, and saying "When I create a shared lock, I'm fine with anyone making changes, as long as they don't snap the CDN before I'm done with my changes".
--
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
[GitHub] [trafficcontrol] srijeet0406 commented on pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
srijeet0406 commented on pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#issuecomment-840022405
> > Well I was thinking that you could just do
> >
> > 1. User `A` grabs a shared lock on CDN `foo`.
> > 2. Users `B` and `C` can still make changes, because the lock is "shared", but cannot snap or queue (only user A can)
> > 3. User `A` deletes the shared lock. Now anyone can snap or queue
>
> ^^ this is how i understood a "shared lock" to work and i understood an "exclusive lock" to work like:
>
> 1. User `A` grabs an exclusive lock on CDN `foo`.
> 2. Users `B` and `C` CANNOT make CDN changes or snap/queue because the lock is "exclusive" to User `A`
> 3. User `A` deletes the exclusive lock. Now anyone can make changes/snap/queue
>
> Only one person ever "owns" a lock (shared or exclusive) at a time.
Right, thats the case for exclusive locks. But in case of shared locks, if the person who had originally created the shared lock deletes the lock, who has the right to snap/ queue the CDN? If we leave it open to anyone, then we are back to square one IMO.
--
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
[GitHub] [trafficcontrol] mitchell852 edited a comment on pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
mitchell852 edited a comment on pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#issuecomment-840018724
--
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
[GitHub] [trafficcontrol] mitchell852 commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
mitchell852 commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r632659019
##########
File path: blueprints/to-locks.md
##########
@@ -0,0 +1,281 @@
+<!--
+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
+
+1. Currently, there is no way to guarantee that only your changes will make their way into a snapshot 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.
+
+2. There is no way to prevent another user from performing a snapshot and prematurely propagating the (incomplete) changes
+ to Traffic Router and Traffic Monitor.
+
+3. There is no way to prevent other users from queueing updates on servers, and prematurely propagating the (incomplete) changes
+ to the Traffic Servers.
+
+All the above three cases 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 (hard locks)
+- Anybody can make changes but only you can snap/ queue your CDN (soft locks)
+
+`Hard` 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 hard locks.
+
+The second category of locks is `soft` 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, say user `A` has acquired the `soft` lock
+on cdn `foo`. Now, any number of users (including `A`) can make changes on the CDN. However, only the first user who grabbed the soft lock,
+in this case, user `A`, 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 soft
+and hard). 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 `Soft Lock` 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
+ - Disable the snap/ queue button if another user has the lock on that CDN.
Review comment:
this is a nice to have imo but it adds complexity to the UI. typically nothing is disabled in TP and the TO API simply catches actions the user is not authorized to perform and returns a 403.
--
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
[GitHub] [trafficcontrol] srijeet0406 commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
srijeet0406 commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r631249417
##########
File path: blueprints/to-locks.md
##########
@@ -0,0 +1,279 @@
+<!--
+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
+ - Disable the snap/ queue button 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.
+The following endpoints will need to handle the locks logic:
+- `/cachegroups/{{ID}}/queue_update`
+- `/cdns/{{ID}}/queue_update`
+- `/servers/{{hostname}}/queue_update`
+- `/snapshot`
+- `/topologies/{{name}}/queue_update`
+
+#### REST API Impact
+
+The following is the JSON representation of a `CDN_Lock` object:
+```JSON
+{
+ "username": "foo",
+ "cdn": "cdn1",
+ "message": "snapping cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10T16:03:34-06:00"
+}
+```
+
+The following table describes the top level `CDN_Lock` object:
+
+| field | type | optionality | description |
+| ----------- | --------------------------- | ----------- | ----------------------------------------------------------------------------------------|
+| username | string | required | the user name of the user that wants to acquire a lock on the CDN |
+| cdn | string | required | the name of the CDN on which the lcok needs to be acquired |
+| message | string | optional | the message stating a reason behind locking the CDN |
+| shared | boolean | required | whether or not this is a shared lock |
+| creator | boolean | required | whether or not the requesting `username` is the first one to acquire a lock on `cdn`|
+| lastUpdated | time | required | the last time this lock was updated |
+
+**API constraints:**
+- a `username` and `cdn` combination must be unique if `shared` is set to `false`. In other words, there can be only one `exclusive`
+lock for a CDN
+- a CDN can have multiple `shared` locks
+- the `creator` will be set to `true` if the user is the first one acquiring a lock for the specified `cdn`
+- a user can snap/ queue a CDN only if the `creator` field corresponding to the `username` and `cdn` combination is `true`
+- a user can delete their `exclusive` lock whenever, since the user is the creator in this case
+- a user who is the creator cannot delete their `shared` lock until all other non-creator users have releases their shared locks for that CDN
+- a user with at least `all-read` and `all-write` capabilities can delete the locks of other users on any CDN. The `all-write` capability will be modified
+to include a new capability `delete-all-locks`.
+
+Three new endpoints will be added for `GET`, `POST` and `DELETE` functionality with respect to CDN locks.
+##### GET `cdn_locks`
+
+response JSON:
+```JSON
+{
+ "response": [
+ {
+ "username": "foo",
+ "cdn": "cdn1",
+ "message": "snapping cdn",
+ "shared": true,
+ "creator": true,
+ "lastUpdated": "2021-05-10T16:03:34-06:00"
+ },
+ {
+ "username": "bar",
+ "cdn": "cdn2",
+ "message": "queue cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10T17:04:34-06:00"
+ }
+ ]
+}
+```
+
+##### POST `cdn_locks`
+
+request JSON:
+```JSON
+{
+ "cdn": "bar",
+ "message": "snapping cdn",
+ "shared": false
+}
+```
+
+response JSON:
+```JSON
+{
+ "alerts": [
+ {
+ "text": "CDN lock acquired!",
+ "level": "success"
+ }
+ ],
+ "response": {
+ "username": "foo",
+ "cdn": "bar",
+ "message": "snapping cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10T17:05:30-06:00"
+ }
+}
+```
+
+##### `DELETE /cdn_locks?cdn=bar`
+
+response JSON:
+```JSON
+{
+ "alerts": [
+ {
+ "text": "Cdn lock deleted",
+ "level": "success"
+ }
+ ],
+ "response": {
+ "username": "foo",
+ "cdn": "bar",
+ "message": "snapping cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10T17:05:30-06:00"
+ }
+}
+```
+
+#### Client Impact
+
+New Go client methods will be added for the `/cdn_locks` endpoints in order to write TO API tests for the new endpoints.
+
+#### Data Model / Database Impact
Review comment:
When a user sends a request to snap/ queue a CDN, the backend code for API endpoint does a database check to see if the current user has a lock on the CDN. If not, then a `403 Forbidden` is returned to the user.
The API uniqueness constraint (of `cdn` in case of an exclusive lock and `username`+`cdn` in case of a shared lock) will prevent two users obtaining the lock on the same resource. We also suggest the clients make use of the `If-Unmodified-Since` header to make sure the locks data doesn't change on them before they complete their request.
--
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
[GitHub] [trafficcontrol] limited commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
limited commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r631243781
##########
File path: blueprints/to-locks.md
##########
@@ -0,0 +1,279 @@
+<!--
+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
+ - Disable the snap/ queue button 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.
+The following endpoints will need to handle the locks logic:
+- `/cachegroups/{{ID}}/queue_update`
+- `/cdns/{{ID}}/queue_update`
+- `/servers/{{hostname}}/queue_update`
+- `/snapshot`
+- `/topologies/{{name}}/queue_update`
+
+#### REST API Impact
+
+The following is the JSON representation of a `CDN_Lock` object:
+```JSON
+{
+ "username": "foo",
+ "cdn": "cdn1",
+ "message": "snapping cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10T16:03:34-06:00"
+}
+```
+
+The following table describes the top level `CDN_Lock` object:
+
+| field | type | optionality | description |
+| ----------- | --------------------------- | ----------- | ----------------------------------------------------------------------------------------|
+| username | string | required | the user name of the user that wants to acquire a lock on the CDN |
+| cdn | string | required | the name of the CDN on which the lcok needs to be acquired |
+| message | string | optional | the message stating a reason behind locking the CDN |
+| shared | boolean | required | whether or not this is a shared lock |
+| creator | boolean | required | whether or not the requesting `username` is the first one to acquire a lock on `cdn`|
+| lastUpdated | time | required | the last time this lock was updated |
+
+**API constraints:**
+- a `username` and `cdn` combination must be unique if `shared` is set to `false`. In other words, there can be only one `exclusive`
+lock for a CDN
+- a CDN can have multiple `shared` locks
+- the `creator` will be set to `true` if the user is the first one acquiring a lock for the specified `cdn`
+- a user can snap/ queue a CDN only if the `creator` field corresponding to the `username` and `cdn` combination is `true`
+- a user can delete their `exclusive` lock whenever, since the user is the creator in this case
+- a user who is the creator cannot delete their `shared` lock until all other non-creator users have releases their shared locks for that CDN
+- a user with at least `all-read` and `all-write` capabilities can delete the locks of other users on any CDN. The `all-write` capability will be modified
+to include a new capability `delete-all-locks`.
+
+Three new endpoints will be added for `GET`, `POST` and `DELETE` functionality with respect to CDN locks.
+##### GET `cdn_locks`
+
+response JSON:
+```JSON
+{
+ "response": [
+ {
+ "username": "foo",
+ "cdn": "cdn1",
+ "message": "snapping cdn",
+ "shared": true,
+ "creator": true,
+ "lastUpdated": "2021-05-10T16:03:34-06:00"
+ },
+ {
+ "username": "bar",
+ "cdn": "cdn2",
+ "message": "queue cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10T17:04:34-06:00"
+ }
+ ]
+}
+```
+
+##### POST `cdn_locks`
+
+request JSON:
+```JSON
+{
+ "cdn": "bar",
+ "message": "snapping cdn",
+ "shared": false
+}
+```
+
+response JSON:
+```JSON
+{
+ "alerts": [
+ {
+ "text": "CDN lock acquired!",
+ "level": "success"
+ }
+ ],
+ "response": {
+ "username": "foo",
+ "cdn": "bar",
+ "message": "snapping cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10T17:05:30-06:00"
+ }
+}
+```
+
+##### `DELETE /cdn_locks?cdn=bar`
+
+response JSON:
+```JSON
+{
+ "alerts": [
+ {
+ "text": "Cdn lock deleted",
+ "level": "success"
+ }
+ ],
+ "response": {
+ "username": "foo",
+ "cdn": "bar",
+ "message": "snapping cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10T17:05:30-06:00"
+ }
+}
+```
+
+#### Client Impact
+
+New Go client methods will be added for the `/cdn_locks` endpoints in order to write TO API tests for the new endpoints.
+
+#### Data Model / Database Impact
Review comment:
What prevents two users from obtaining a lock on the same resource?
Similarly, what guarantees that a user has the lock when the snap/queue operation is performed?
--
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
[GitHub] [trafficcontrol] rawlinp commented on pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
rawlinp commented on pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#issuecomment-840103884
> i think you've overcomplicated it. i think this is all that is needed:
> ```
> exclusive lock: only owner can make cdn changes/snap/queue
> shared lock: only owner can snap/queue; owner and non-owners can make cdn changes
> no lock: anyone can make cdn changes/snap/queue
> ```
> the user can decide what level of protection they are looking for. i'm pretty sure this is what @rawlinp was thinking when he proposed the shared lock.
Yeah, that is what I was thinking. I thought there would only be a single exclusive lock and a single shared lock. Each lock can only have one owner at a time, and only one type of lock can be held at a time.
I think it helps to start with the use cases behind each type of lock. For example, if I wanted to update a DS certificate, I could grab the exclusive lock since I don't want anyone else's changes to be propagated until I've had a chance to test the new cert on a single cache. Once I've verified the cert, I will queue the entire CDN then release the exclusive lock.
As another example, say there are a lot of certs about to expire and we want to divide the work among multiple operators. One operator would grab the shared lock (preventing anyone else from queuing updates). The other operators are still free to update their certs anytime (since only a shared lock is held), and when ready, the lock holder will queue updates on single cache. Then all the operators can test their certs before the lock holder queues the entire CDN and releases the shared lock.
We shouldn't make this solution overly complicated, since I see this more as a temporary solution until we have the time to tackle the full solution (delivery service snapshots and server snapshots). Right?
--
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
[GitHub] [trafficcontrol] mitchell852 commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
mitchell852 commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r632119026
##########
File path: blueprints/to-locks.md
##########
@@ -0,0 +1,268 @@
+<!--
+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
Review comment:
there are really 3 problems:
1. there is no way to prevent others from "dirtying" your snapshot with their own changes (you address this)
2. there is no way to prevent others from performing a snapshot and prematurely propagating changes to TR/TM
3. there is no way to prevent others from queuing (server) updates and prematurely propagating changes to caches
i would suggest that you mention all 3.
--
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
[GitHub] [trafficcontrol] ocket8888 commented on pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
ocket8888 commented on pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#issuecomment-839240824
okay. It seems I've fundamentally misunderstood the nature of a lock. It doesn't actually prevent anything other than snap/queue whether it's shared or not, correct? I think I get it now.
--
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
[GitHub] [trafficcontrol] mitchell852 edited a comment on pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
mitchell852 edited a comment on pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#issuecomment-840064797
> if the person who had originally created the shared lock deletes the lock, who has the right to snap/ queue the CDN? If we leave it open to anyone, then we are back to square one IMO.
yep, if no lock on a cdn (shared or exclusive) then anybody can do anything which i think is fine. if you don't like that then don't delete the lock :) you don't pass locks from one person to another. you just take them when _you_ want one and delete it when _you_ don't need it anymore.
--
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
[GitHub] [trafficcontrol] rawlinp edited a comment on pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
rawlinp edited a comment on pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#issuecomment-840103884
> i think you've overcomplicated it. i think this is all that is needed:
> ```
> exclusive lock: only owner can make cdn changes/snap/queue
> shared lock: only owner can snap/queue; owner and non-owners can make cdn changes
> no lock: anyone can make cdn changes/snap/queue
> ```
> the user can decide what level of protection they are looking for. i'm pretty sure this is what @rawlinp was thinking when he proposed the shared lock.
Yeah, that is what I was thinking. I thought there would only be a single exclusive lock and a single shared lock (per-CDN). Each lock can only have one owner at a time, and only one type of lock can be held at a time.
I think it helps to start with the use cases behind each type of lock. For example, if I wanted to update a DS certificate, I could grab the exclusive lock since I don't want anyone else's changes to be propagated until I've had a chance to test the new cert on a single cache. Once I've verified the cert, I will queue the entire CDN then release the exclusive lock.
As another example, say there are a lot of certs about to expire and we want to divide the work among multiple operators. One operator would grab the shared lock (preventing anyone else from queuing updates). The other operators are still free to update their certs anytime (since only a shared lock is held), and when ready, the lock holder will queue updates on single cache. Then all the operators can test their certs before the lock holder queues the entire CDN and releases the shared lock.
We shouldn't make this solution overly complicated, since I see this more as a temporary solution until we have the time to tackle the full solution (delivery service snapshots and server snapshots). Right?
--
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
[GitHub] [trafficcontrol] srijeet0406 commented on pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
srijeet0406 commented on pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#issuecomment-840086933
> > user `A` gets the shared lock on `cdn1`
> > users `B` and `C` get the shared lock on `cdn1`
> > at this point, user `A` releases the lock, so now `B` and `C`. an snap/ queue `cdn1`(which opens us up to the same issue again)
> > user `D` comes in and gets the shared lock on `cdn1`, making `D` the `owner` of the lock
> > now again, `B` and `C` are locked out of snapping/ queueing `cdn1`
> > Form `B` and `C`'s perspective, the system will let them allow snapping/ queueing once, followed by denying them, even though they haven't changed anything from their end. I think this might create confusion for the users.
>
> i think you've overcomplicated it. i think this is all that is needed:
>
> ```
> exclusive lock: only owner can make cdn changes/snap/queue
> shared lock: only owner can snap/queue; owner and non-owners can make cdn changes
> no lock: anyone can make cdn changes/snap/queue
> ```
>
> the user can decide what level of protection they are looking for. i'm pretty sure this is what @rawlinp was thinking when he proposed the shared lock.
Then I suggest deleteing all non-owner shared locks for a CDN when the owner deletes their shared lock, because its as good as not having a lock at that point. We could use the notifications feature to show this in TP.
--
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
[GitHub] [trafficcontrol] limited commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
limited commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r630676391
##########
File path: blueprints/to-locks.md
##########
@@ -0,0 +1,279 @@
+<!--
+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`.
Review comment:
Can any user lock a CDN?
##########
File path: blueprints/to-locks.md
##########
@@ -0,0 +1,279 @@
+<!--
+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
+ - Disable the snap/ queue button 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.
+The following endpoints will need to handle the locks logic:
+- `/cachegroups/{{ID}}/queue_update`
+- `/cdns/{{ID}}/queue_update`
+- `/servers/{{hostname}}/queue_update`
+- `/snapshot`
+- `/topologies/{{name}}/queue_update`
+
+#### REST API Impact
+
+The following is the JSON representation of a `CDN_Lock` object:
+```JSON
+{
+ "username": "foo",
+ "cdn": "cdn1",
+ "message": "snapping cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10T16:03:34-06:00"
+}
+```
+
+The following table describes the top level `CDN_Lock` object:
+
+| field | type | optionality | description |
+| ----------- | --------------------------- | ----------- | ----------------------------------------------------------------------------------------|
+| username | string | required | the user name of the user that wants to acquire a lock on the CDN |
+| cdn | string | required | the name of the CDN on which the lcok needs to be acquired |
+| message | string | optional | the message stating a reason behind locking the CDN |
+| shared | boolean | required | whether or not this is a shared lock |
+| creator | boolean | required | whether or not the requesting `username` is the first one to acquire a lock on `cdn`|
+| lastUpdated | time | required | the last time this lock was updated |
+
+**API constraints:**
+- a `username` and `cdn` combination must be unique if `shared` is set to `false`. In other words, there can be only one `exclusive`
+lock for a CDN
+- a CDN can have multiple `shared` locks
+- the `creator` will be set to `true` if the user is the first one acquiring a lock for the specified `cdn`
Review comment:
`owner` of the lock might be a more common term
##########
File path: blueprints/to-locks.md
##########
@@ -0,0 +1,279 @@
+<!--
+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
+ - Disable the snap/ queue button 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.
+The following endpoints will need to handle the locks logic:
+- `/cachegroups/{{ID}}/queue_update`
+- `/cdns/{{ID}}/queue_update`
+- `/servers/{{hostname}}/queue_update`
+- `/snapshot`
+- `/topologies/{{name}}/queue_update`
+
+#### REST API Impact
+
+The following is the JSON representation of a `CDN_Lock` object:
+```JSON
+{
+ "username": "foo",
+ "cdn": "cdn1",
+ "message": "snapping cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10T16:03:34-06:00"
+}
+```
+
+The following table describes the top level `CDN_Lock` object:
+
+| field | type | optionality | description |
+| ----------- | --------------------------- | ----------- | ----------------------------------------------------------------------------------------|
+| username | string | required | the user name of the user that wants to acquire a lock on the CDN |
+| cdn | string | required | the name of the CDN on which the lcok needs to be acquired |
+| message | string | optional | the message stating a reason behind locking the CDN |
+| shared | boolean | required | whether or not this is a shared lock |
+| creator | boolean | required | whether or not the requesting `username` is the first one to acquire a lock on `cdn`|
+| lastUpdated | time | required | the last time this lock was updated |
+
+**API constraints:**
+- a `username` and `cdn` combination must be unique if `shared` is set to `false`. In other words, there can be only one `exclusive`
+lock for a CDN
+- a CDN can have multiple `shared` locks
+- the `creator` will be set to `true` if the user is the first one acquiring a lock for the specified `cdn`
+- a user can snap/ queue a CDN only if the `creator` field corresponding to the `username` and `cdn` combination is `true`
+- a user can delete their `exclusive` lock whenever, since the user is the creator in this case
+- a user who is the creator cannot delete their `shared` lock until all other non-creator users have releases their shared locks for that CDN
Review comment:
what use cases/concerns is this addressing?
##########
File path: blueprints/to-locks.md
##########
@@ -0,0 +1,279 @@
+<!--
+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
+ - Disable the snap/ queue button 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.
+The following endpoints will need to handle the locks logic:
+- `/cachegroups/{{ID}}/queue_update`
+- `/cdns/{{ID}}/queue_update`
+- `/servers/{{hostname}}/queue_update`
+- `/snapshot`
+- `/topologies/{{name}}/queue_update`
+
+#### REST API Impact
+
+The following is the JSON representation of a `CDN_Lock` object:
+```JSON
+{
+ "username": "foo",
+ "cdn": "cdn1",
+ "message": "snapping cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10T16:03:34-06:00"
+}
+```
+
+The following table describes the top level `CDN_Lock` object:
+
+| field | type | optionality | description |
+| ----------- | --------------------------- | ----------- | ----------------------------------------------------------------------------------------|
+| username | string | required | the user name of the user that wants to acquire a lock on the CDN |
+| cdn | string | required | the name of the CDN on which the lcok needs to be acquired |
+| message | string | optional | the message stating a reason behind locking the CDN |
+| shared | boolean | required | whether or not this is a shared lock |
+| creator | boolean | required | whether or not the requesting `username` is the first one to acquire a lock on `cdn`|
+| lastUpdated | time | required | the last time this lock was updated |
+
+**API constraints:**
+- a `username` and `cdn` combination must be unique if `shared` is set to `false`. In other words, there can be only one `exclusive`
+lock for a CDN
+- a CDN can have multiple `shared` locks
+- the `creator` will be set to `true` if the user is the first one acquiring a lock for the specified `cdn`
+- a user can snap/ queue a CDN only if the `creator` field corresponding to the `username` and `cdn` combination is `true`
Review comment:
a user can snap/queue a CDN only if their username matches the `creator` username?
##########
File path: blueprints/to-locks.md
##########
@@ -0,0 +1,279 @@
+<!--
+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
+ - Disable the snap/ queue button 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.
+The following endpoints will need to handle the locks logic:
+- `/cachegroups/{{ID}}/queue_update`
+- `/cdns/{{ID}}/queue_update`
+- `/servers/{{hostname}}/queue_update`
+- `/snapshot`
+- `/topologies/{{name}}/queue_update`
+
+#### REST API Impact
+
+The following is the JSON representation of a `CDN_Lock` object:
+```JSON
+{
+ "username": "foo",
+ "cdn": "cdn1",
+ "message": "snapping cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10T16:03:34-06:00"
+}
+```
+
+The following table describes the top level `CDN_Lock` object:
+
+| field | type | optionality | description |
+| ----------- | --------------------------- | ----------- | ----------------------------------------------------------------------------------------|
+| username | string | required | the user name of the user that wants to acquire a lock on the CDN |
+| cdn | string | required | the name of the CDN on which the lcok needs to be acquired |
+| message | string | optional | the message stating a reason behind locking the CDN |
+| shared | boolean | required | whether or not this is a shared lock |
+| creator | boolean | required | whether or not the requesting `username` is the first one to acquire a lock on `cdn`|
+| lastUpdated | time | required | the last time this lock was updated |
+
+**API constraints:**
+- a `username` and `cdn` combination must be unique if `shared` is set to `false`. In other words, there can be only one `exclusive`
+lock for a CDN
+- a CDN can have multiple `shared` locks
+- the `creator` will be set to `true` if the user is the first one acquiring a lock for the specified `cdn`
+- a user can snap/ queue a CDN only if the `creator` field corresponding to the `username` and `cdn` combination is `true`
+- a user can delete their `exclusive` lock whenever, since the user is the creator in this case
+- a user who is the creator cannot delete their `shared` lock until all other non-creator users have releases their shared locks for that CDN
+- a user with at least `all-read` and `all-write` capabilities can delete the locks of other users on any CDN. The `all-write` capability will be modified
+to include a new capability `delete-all-locks`.
+
+Three new endpoints will be added for `GET`, `POST` and `DELETE` functionality with respect to CDN locks.
+##### GET `cdn_locks`
+
+response JSON:
+```JSON
+{
+ "response": [
+ {
+ "username": "foo",
+ "cdn": "cdn1",
+ "message": "snapping cdn",
+ "shared": true,
+ "creator": true,
+ "lastUpdated": "2021-05-10T16:03:34-06:00"
+ },
+ {
+ "username": "bar",
+ "cdn": "cdn2",
+ "message": "queue cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10T17:04:34-06:00"
+ }
+ ]
+}
+```
+
+##### POST `cdn_locks`
+
+request JSON:
+```JSON
+{
+ "cdn": "bar",
+ "message": "snapping cdn",
+ "shared": false
+}
+```
+
+response JSON:
+```JSON
+{
+ "alerts": [
+ {
+ "text": "CDN lock acquired!",
+ "level": "success"
+ }
+ ],
+ "response": {
+ "username": "foo",
+ "cdn": "bar",
+ "message": "snapping cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10T17:05:30-06:00"
+ }
+}
+```
+
+##### `DELETE /cdn_locks?cdn=bar`
+
+response JSON:
+```JSON
+{
+ "alerts": [
+ {
+ "text": "Cdn lock deleted",
+ "level": "success"
+ }
+ ],
+ "response": {
+ "username": "foo",
+ "cdn": "bar",
+ "message": "snapping cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10T17:05:30-06:00"
+ }
+}
+```
+
+#### Client Impact
+
+New Go client methods will be added for the `/cdn_locks` endpoints in order to write TO API tests for the new endpoints.
+
+#### Data Model / Database Impact
Review comment:
I didn't see any discussion of the actual implementation, so I'm curious.
How will the lock be implemented? Will you be using Postgres Advisory locks? If not, are there particular atomic operations you'll make use of to avoid race conditions in acquiring, evaluating, and releasing locks?
##########
File path: blueprints/to-locks.md
##########
@@ -0,0 +1,279 @@
+<!--
+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
+ - Disable the snap/ queue button 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.
+The following endpoints will need to handle the locks logic:
+- `/cachegroups/{{ID}}/queue_update`
+- `/cdns/{{ID}}/queue_update`
+- `/servers/{{hostname}}/queue_update`
+- `/snapshot`
+- `/topologies/{{name}}/queue_update`
+
+#### REST API Impact
+
+The following is the JSON representation of a `CDN_Lock` object:
+```JSON
+{
+ "username": "foo",
+ "cdn": "cdn1",
+ "message": "snapping cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10T16:03:34-06:00"
+}
+```
+
+The following table describes the top level `CDN_Lock` object:
+
+| field | type | optionality | description |
+| ----------- | --------------------------- | ----------- | ----------------------------------------------------------------------------------------|
+| username | string | required | the user name of the user that wants to acquire a lock on the CDN |
+| cdn | string | required | the name of the CDN on which the lcok needs to be acquired |
+| message | string | optional | the message stating a reason behind locking the CDN |
+| shared | boolean | required | whether or not this is a shared lock |
+| creator | boolean | required | whether or not the requesting `username` is the first one to acquire a lock on `cdn`|
+| lastUpdated | time | required | the last time this lock was updated |
+
+**API constraints:**
+- a `username` and `cdn` combination must be unique if `shared` is set to `false`. In other words, there can be only one `exclusive`
Review comment:
`cdn` by itself must be unique if the lock is `exclusive`, right?
(`user1`, `cdn`) and (`user2`, `cdn`) should not be allowed for an exclusive lock
For a shared lock, (`username`, `cdn`) must be unique.
--
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
[GitHub] [trafficcontrol] srijeet0406 commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
srijeet0406 commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r631236711
##########
File path: blueprints/to-locks.md
##########
@@ -0,0 +1,279 @@
+<!--
+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
+ - Disable the snap/ queue button 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.
+The following endpoints will need to handle the locks logic:
+- `/cachegroups/{{ID}}/queue_update`
+- `/cdns/{{ID}}/queue_update`
+- `/servers/{{hostname}}/queue_update`
+- `/snapshot`
+- `/topologies/{{name}}/queue_update`
+
+#### REST API Impact
+
+The following is the JSON representation of a `CDN_Lock` object:
+```JSON
+{
+ "username": "foo",
+ "cdn": "cdn1",
+ "message": "snapping cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10T16:03:34-06:00"
+}
+```
+
+The following table describes the top level `CDN_Lock` object:
+
+| field | type | optionality | description |
+| ----------- | --------------------------- | ----------- | ----------------------------------------------------------------------------------------|
+| username | string | required | the user name of the user that wants to acquire a lock on the CDN |
+| cdn | string | required | the name of the CDN on which the lcok needs to be acquired |
+| message | string | optional | the message stating a reason behind locking the CDN |
+| shared | boolean | required | whether or not this is a shared lock |
+| creator | boolean | required | whether or not the requesting `username` is the first one to acquire a lock on `cdn`|
+| lastUpdated | time | required | the last time this lock was updated |
+
+**API constraints:**
+- a `username` and `cdn` combination must be unique if `shared` is set to `false`. In other words, there can be only one `exclusive`
+lock for a CDN
+- a CDN can have multiple `shared` locks
+- the `creator` will be set to `true` if the user is the first one acquiring a lock for the specified `cdn`
+- a user can snap/ queue a CDN only if the `creator` field corresponding to the `username` and `cdn` combination is `true`
+- a user can delete their `exclusive` lock whenever, since the user is the creator in this case
+- a user who is the creator cannot delete their `shared` lock until all other non-creator users have releases their shared locks for that CDN
+- a user with at least `all-read` and `all-write` capabilities can delete the locks of other users on any CDN. The `all-write` capability will be modified
+to include a new capability `delete-all-locks`.
+
+Three new endpoints will be added for `GET`, `POST` and `DELETE` functionality with respect to CDN locks.
+##### GET `cdn_locks`
+
+response JSON:
+```JSON
+{
+ "response": [
+ {
+ "username": "foo",
+ "cdn": "cdn1",
+ "message": "snapping cdn",
+ "shared": true,
+ "creator": true,
+ "lastUpdated": "2021-05-10T16:03:34-06:00"
+ },
+ {
+ "username": "bar",
+ "cdn": "cdn2",
+ "message": "queue cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10T17:04:34-06:00"
+ }
+ ]
+}
+```
+
+##### POST `cdn_locks`
+
+request JSON:
+```JSON
+{
+ "cdn": "bar",
+ "message": "snapping cdn",
+ "shared": false
+}
+```
+
+response JSON:
+```JSON
+{
+ "alerts": [
+ {
+ "text": "CDN lock acquired!",
+ "level": "success"
+ }
+ ],
+ "response": {
+ "username": "foo",
+ "cdn": "bar",
+ "message": "snapping cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10T17:05:30-06:00"
+ }
+}
+```
+
+##### `DELETE /cdn_locks?cdn=bar`
+
+response JSON:
+```JSON
+{
+ "alerts": [
+ {
+ "text": "Cdn lock deleted",
+ "level": "success"
+ }
+ ],
+ "response": {
+ "username": "foo",
+ "cdn": "bar",
+ "message": "snapping cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10T17:05:30-06:00"
+ }
+}
+```
+
+#### Client Impact
+
+New Go client methods will be added for the `/cdn_locks` endpoints in order to write TO API tests for the new endpoints.
+
+#### Data Model / Database Impact
Review comment:
So the lock object is just another database table. So when a snap/ queue request comes in, we just do a look up in the `cdn_lock` table to see if the current user has the lock, and if so, proceed with the operation. In the current scenarion, this is just like checking for the `If-Modified-Since` or `If-Unmodified-Since` header.
##########
File path: blueprints/to-locks.md
##########
@@ -0,0 +1,279 @@
+<!--
+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
+ - Disable the snap/ queue button 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.
+The following endpoints will need to handle the locks logic:
+- `/cachegroups/{{ID}}/queue_update`
+- `/cdns/{{ID}}/queue_update`
+- `/servers/{{hostname}}/queue_update`
+- `/snapshot`
+- `/topologies/{{name}}/queue_update`
+
+#### REST API Impact
+
+The following is the JSON representation of a `CDN_Lock` object:
+```JSON
+{
+ "username": "foo",
+ "cdn": "cdn1",
+ "message": "snapping cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10T16:03:34-06:00"
+}
+```
+
+The following table describes the top level `CDN_Lock` object:
+
+| field | type | optionality | description |
+| ----------- | --------------------------- | ----------- | ----------------------------------------------------------------------------------------|
+| username | string | required | the user name of the user that wants to acquire a lock on the CDN |
+| cdn | string | required | the name of the CDN on which the lcok needs to be acquired |
+| message | string | optional | the message stating a reason behind locking the CDN |
+| shared | boolean | required | whether or not this is a shared lock |
+| creator | boolean | required | whether or not the requesting `username` is the first one to acquire a lock on `cdn`|
+| lastUpdated | time | required | the last time this lock was updated |
+
+**API constraints:**
+- a `username` and `cdn` combination must be unique if `shared` is set to `false`. In other words, there can be only one `exclusive`
+lock for a CDN
+- a CDN can have multiple `shared` locks
+- the `creator` will be set to `true` if the user is the first one acquiring a lock for the specified `cdn`
+- a user can snap/ queue a CDN only if the `creator` field corresponding to the `username` and `cdn` combination is `true`
Review comment:
yes, you're correct. Because in exclusive locks, no one else has the lock, and in shared locks, only the creator/ owner of the lock is allowed to snap/ queue the cdn.
##########
File path: blueprints/to-locks.md
##########
@@ -0,0 +1,279 @@
+<!--
+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
+ - Disable the snap/ queue button 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.
+The following endpoints will need to handle the locks logic:
+- `/cachegroups/{{ID}}/queue_update`
+- `/cdns/{{ID}}/queue_update`
+- `/servers/{{hostname}}/queue_update`
+- `/snapshot`
+- `/topologies/{{name}}/queue_update`
+
+#### REST API Impact
+
+The following is the JSON representation of a `CDN_Lock` object:
+```JSON
+{
+ "username": "foo",
+ "cdn": "cdn1",
+ "message": "snapping cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10T16:03:34-06:00"
+}
+```
+
+The following table describes the top level `CDN_Lock` object:
+
+| field | type | optionality | description |
+| ----------- | --------------------------- | ----------- | ----------------------------------------------------------------------------------------|
+| username | string | required | the user name of the user that wants to acquire a lock on the CDN |
+| cdn | string | required | the name of the CDN on which the lcok needs to be acquired |
+| message | string | optional | the message stating a reason behind locking the CDN |
+| shared | boolean | required | whether or not this is a shared lock |
+| creator | boolean | required | whether or not the requesting `username` is the first one to acquire a lock on `cdn`|
+| lastUpdated | time | required | the last time this lock was updated |
+
+**API constraints:**
+- a `username` and `cdn` combination must be unique if `shared` is set to `false`. In other words, there can be only one `exclusive`
+lock for a CDN
+- a CDN can have multiple `shared` locks
+- the `creator` will be set to `true` if the user is the first one acquiring a lock for the specified `cdn`
Review comment:
I'll make that change.
##########
File path: blueprints/to-locks.md
##########
@@ -0,0 +1,279 @@
+<!--
+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
+ - Disable the snap/ queue button 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.
+The following endpoints will need to handle the locks logic:
+- `/cachegroups/{{ID}}/queue_update`
+- `/cdns/{{ID}}/queue_update`
+- `/servers/{{hostname}}/queue_update`
+- `/snapshot`
+- `/topologies/{{name}}/queue_update`
+
+#### REST API Impact
+
+The following is the JSON representation of a `CDN_Lock` object:
+```JSON
+{
+ "username": "foo",
+ "cdn": "cdn1",
+ "message": "snapping cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10T16:03:34-06:00"
+}
+```
+
+The following table describes the top level `CDN_Lock` object:
+
+| field | type | optionality | description |
+| ----------- | --------------------------- | ----------- | ----------------------------------------------------------------------------------------|
+| username | string | required | the user name of the user that wants to acquire a lock on the CDN |
+| cdn | string | required | the name of the CDN on which the lcok needs to be acquired |
+| message | string | optional | the message stating a reason behind locking the CDN |
+| shared | boolean | required | whether or not this is a shared lock |
+| creator | boolean | required | whether or not the requesting `username` is the first one to acquire a lock on `cdn`|
+| lastUpdated | time | required | the last time this lock was updated |
+
+**API constraints:**
+- a `username` and `cdn` combination must be unique if `shared` is set to `false`. In other words, there can be only one `exclusive`
Review comment:
Yes, for an exclusive lock, `cdn` must be unique.
For a shared lock, (`username`, `cdn`) must be unique.
##########
File path: blueprints/to-locks.md
##########
@@ -0,0 +1,279 @@
+<!--
+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`.
Review comment:
Any user who is capable of snapping or queueing the CDN can lock it.
--
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
[GitHub] [trafficcontrol] mitchell852 merged pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
mitchell852 merged pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834
--
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
[GitHub] [trafficcontrol] mitchell852 edited a comment on pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
mitchell852 edited a comment on pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#issuecomment-840018724
> Well I was thinking that you could just do
>
> 1. User `A` grabs a shared lock on CDN `foo`.
> 2. Users `B` and `C` can still make changes, because the lock is "shared", but cannot snap or queue
> 3. User `A` deletes the shared lock. Now anyone can snap or queue
^^ this is how i understood a "shared lock" to work and i understood an "exclusive lock" to work like:
1. User `A` grabs an exclusive lock on CDN `foo`.
2. Users `B` and `C` CANNOT make CDN changes or snap/queue because the lock is "exclusive" to User `A`
3. User `A` deletes the exclusive lock. Now anyone can make changes/snap/queue
--
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
[GitHub] [trafficcontrol] limited commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
limited commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r630679983
##########
File path: blueprints/to-locks.md
##########
@@ -0,0 +1,279 @@
+<!--
+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
+ - Disable the snap/ queue button 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.
+The following endpoints will need to handle the locks logic:
+- `/cachegroups/{{ID}}/queue_update`
+- `/cdns/{{ID}}/queue_update`
+- `/servers/{{hostname}}/queue_update`
+- `/snapshot`
+- `/topologies/{{name}}/queue_update`
+
+#### REST API Impact
+
+The following is the JSON representation of a `CDN_Lock` object:
+```JSON
+{
+ "username": "foo",
+ "cdn": "cdn1",
+ "message": "snapping cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10T16:03:34-06:00"
+}
+```
+
+The following table describes the top level `CDN_Lock` object:
+
+| field | type | optionality | description |
+| ----------- | --------------------------- | ----------- | ----------------------------------------------------------------------------------------|
+| username | string | required | the user name of the user that wants to acquire a lock on the CDN |
+| cdn | string | required | the name of the CDN on which the lcok needs to be acquired |
+| message | string | optional | the message stating a reason behind locking the CDN |
+| shared | boolean | required | whether or not this is a shared lock |
+| creator | boolean | required | whether or not the requesting `username` is the first one to acquire a lock on `cdn`|
+| lastUpdated | time | required | the last time this lock was updated |
+
+**API constraints:**
+- a `username` and `cdn` combination must be unique if `shared` is set to `false`. In other words, there can be only one `exclusive`
+lock for a CDN
+- a CDN can have multiple `shared` locks
+- the `creator` will be set to `true` if the user is the first one acquiring a lock for the specified `cdn`
+- a user can snap/ queue a CDN only if the `creator` field corresponding to the `username` and `cdn` combination is `true`
+- a user can delete their `exclusive` lock whenever, since the user is the creator in this case
+- a user who is the creator cannot delete their `shared` lock until all other non-creator users have releases their shared locks for that CDN
Review comment:
what use cases/concerns is this addressing?
--
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
[GitHub] [trafficcontrol] ocket8888 commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
ocket8888 commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r631983599
##########
File path: blueprints/to-locks.md
##########
@@ -77,42 +77,43 @@ the CDN on behalf of user `A`.
- 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.
+`soft` vs `hard` locks, and forbid a user from snapping/ queueing a CDN if another user possesses a lock on that CDN.
+The following endpoints will need to handle the locks logic:
+- `/cachegroups/{{ID}}/queue_update`
+- `/cdns/{{ID}}/queue_update`
+- `/servers/{{hostname}}/queue_update`
+- `/snapshot`
+- `/topologies/{{name}}/queue_update`
Review comment:
So, let me try to make sure I understand this one last time.
If I have a Soft lock on a CDN, anyone can still make changes, but these endpoints need to be aware that only a certain user is allowed to use them.
But if I have a Hard lock, these endpoints still need to be aware of that, but also nobody else is permitted to make any changes within the scope of the CDN, right? That means that very nearly every endpoint is affected; it might be a shorter list to itemize the endpoints that *won't* need to be changed as a result of this.
Basically, every endpoint that controls data scoped to a CDN (e.g. `/profiles`), every endpoint that controls data owned by objects scoped to a CDN (e.g. `/parameters`), and every endpoint that controls data that defines interactions between objects scoped to a CDN even if the data itself is not scoped to a CDN (e.g. `/cachegroups`) will need to be updated to be aware of the locking mechanism.
--
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
[GitHub] [trafficcontrol] srijeet0406 commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
srijeet0406 commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r631985951
##########
File path: blueprints/to-locks.md
##########
@@ -77,42 +77,43 @@ the CDN on behalf of user `A`.
- 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.
+`soft` vs `hard` locks, and forbid a user from snapping/ queueing a CDN if another user possesses a lock on that CDN.
+The following endpoints will need to handle the locks logic:
+- `/cachegroups/{{ID}}/queue_update`
+- `/cdns/{{ID}}/queue_update`
+- `/servers/{{hostname}}/queue_update`
+- `/snapshot`
+- `/topologies/{{name}}/queue_update`
Review comment:
You are correct. So basically all `PUT/POST/DELETE` endpoints that have any relation to a CDN should be locked down (to other users) if a user has a Hard lock on a particular CDN. I'll add this statement to the blueprint.
--
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
[GitHub] [trafficcontrol] srijeet0406 commented on pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
srijeet0406 commented on pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#issuecomment-840071046
> > if the person who had originally created the shared lock deletes the lock, who has the right to snap/ queue the CDN? If we leave it open to anyone, then we are back to square one IMO.
>
> yep, if no lock (shared or exclusive) then anybody can do anything which i think is fine. if you don't like that then don't delete the lock :) you don't pass locks from one person to another. you just take them when _you_ want one and delete it when _you_ don't need it anymore.
I think when you open a shared lock, you are agreeing to the fact that others might use it, and if you created the lock, you take on the responsibility of not corrupting the snapshot. If we were to follow what you're saying, then there will be a period when a shared lock doesn't have an owner, and in that time frame, anyone who has access to the shared lock can queue/ snap, inspite of not being the owner. Also, this would create problems in the following case:
user `A` gets the shared lock on `cdn1`
users `B` and `C` get the shared lock on `cdn1`
at this point, user `A` releases the lock, so now `B` and `C`. an snap/ queue `cdn1`(which opens us up to the same issue again)
user `D` comes in and gets the shared lock on `cdn1`, making `D` the `owner` of the lock
now again, `B` and `C` are locked out of snapping/ queueing `cdn1`
Form `B` and `C`'s perspective, the system will let them allow snapping/ queueing once, followed by denying them, even though they haven't changed anything from their end. I think this might create confusion for the users.
--
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
[GitHub] [trafficcontrol] mitchell852 commented on pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
mitchell852 commented on pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#issuecomment-840076220
> user `A` gets the shared lock on `cdn1`
> users `B` and `C` get the shared lock on `cdn1`
> at this point, user `A` releases the lock, so now `B` and `C`. an snap/ queue `cdn1`(which opens us up to the same issue again)
> user `D` comes in and gets the shared lock on `cdn1`, making `D` the `owner` of the lock
> now again, `B` and `C` are locked out of snapping/ queueing `cdn1`
>
> Form `B` and `C`'s perspective, the system will let them allow snapping/ queueing once, followed by denying them, even though they haven't changed anything from their end. I think this might create confusion for the users.
i think you've overcomplicated it. i think this is all that is needed:
```
exclusive lock: only owner can make cdn changes/snap/queue
shared lock: only owner can snap/queue; owner and non-owners can make cdn changes
no lock: anyone can make cdn changes/snap/queue
```
the user can decide what level of protection they are looking for.
--
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
[GitHub] [trafficcontrol] mitchell852 commented on pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
mitchell852 commented on pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#issuecomment-840018724
> Well I was thinking that you could just do
>
> 1. User `A` grabs a shared lock on CDN `foo`.
> 2. Users `B` and `C` can still make changes, because the lock is "shared", but cannot snap or queue
> 3. User `A` deletes the shared lock. Now anyone can snap or queue
this is how i understood a "shared lock" to work.
--
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
[GitHub] [trafficcontrol] mitchell852 commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
mitchell852 commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r630463079
##########
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:
creator:true isn't making a lot of sense to me. maybe i need to think about it more
--
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
[GitHub] [trafficcontrol] ocket8888 commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
ocket8888 commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r632685679
##########
File path: blueprints/to-locks.md
##########
@@ -0,0 +1,281 @@
+<!--
+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
+
+1. Currently, there is no way to guarantee that only your changes will make their way into a snapshot 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.
+
+2. There is no way to prevent another user from performing a snapshot and prematurely propagating the (incomplete) changes
+ to Traffic Router and Traffic Monitor.
+
+3. There is no way to prevent other users from queueing updates on servers, and prematurely propagating the (incomplete) changes
+ to the Traffic Servers.
+
+All the above three cases 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 (hard locks)
+- Anybody can make changes but only you can snap/ queue your CDN (soft locks)
+
+`Hard` 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 hard locks.
+
+The second category of locks is `soft` 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, say user `A` has acquired the `soft` lock
+on cdn `foo`. Now, any number of users (including `A`) can make changes on the CDN. However, only the first user who grabbed the soft lock,
+in this case, user `A`, 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 soft
+and hard). 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 `Soft Lock` 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
+ - Disable the snap/ queue button if another user has the lock on that CDN.
Review comment:
disabling an option you know will fail is a good UX IMO - and there are precedents in TP, actually. For example, right click on a server that isn't a cache server in the servers table, notice that "Queue Updates" and "Clear Updates" are disabled
--
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
[GitHub] [trafficcontrol] srijeet0406 commented on pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
srijeet0406 commented on pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#issuecomment-839243004
> okay. It seems I've fundamentally misunderstood the nature of a lock. It doesn't actually prevent anything other than snap/queue whether it's shared or not, correct? I think I get it now.
Exactly, the main goal is to prevent those users from snapping/ queueing who either do not have the lock on a CDN/ did not create the lock on a CDN.
--
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
[GitHub] [trafficcontrol] mitchell852 commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
mitchell852 commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r632119026
##########
File path: blueprints/to-locks.md
##########
@@ -0,0 +1,268 @@
+<!--
+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
Review comment:
there are really 3 problems:
1. there is no way to prevent others from "dirtying" your snapshot with their own changes (you addressed this)
2. there is no way to prevent others from performing a snapshot and prematurely propagating changes to TR/TM
3. there is no way to prevent others from queuing (server) updates and prematurely propagating changes to caches
i would suggest that you mention all 3.
--
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
[GitHub] [trafficcontrol] ocket8888 commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
ocket8888 commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r632686221
##########
File path: blueprints/to-locks.md
##########
@@ -0,0 +1,281 @@
+<!--
+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
+
+1. Currently, there is no way to guarantee that only your changes will make their way into a snapshot 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.
+
+2. There is no way to prevent another user from performing a snapshot and prematurely propagating the (incomplete) changes
+ to Traffic Router and Traffic Monitor.
+
+3. There is no way to prevent other users from queueing updates on servers, and prematurely propagating the (incomplete) changes
+ to the Traffic Servers.
+
+All the above three cases 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 (hard locks)
+- Anybody can make changes but only you can snap/ queue your CDN (soft locks)
+
+`Hard` 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 hard locks.
+
+The second category of locks is `soft` 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, say user `A` has acquired the `soft` lock
+on cdn `foo`. Now, any number of users (including `A`) can make changes on the CDN. However, only the first user who grabbed the soft lock,
+in this case, user `A`, 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 soft
+and hard). 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 `Soft Lock` 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
+ - Disable the snap/ queue button 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
+`soft` vs `hard` locks, and forbid a user from snapping/ queueing a CDN if another user possesses a lock on that CDN.
+The following endpoints will need to handle the locks logic:
+- `/cachegroups/{{ID}}/queue_update`
+- `/cdns/{{ID}}/queue_update`
+- `/servers/{{hostname}}/queue_update`
+- `/snapshot`
+- `/topologies/{{name}}/queue_update`
+
+In addition to these, all `PUT`, `POST`, `DELETE` endpoints that scope to a CDN will have to add in the logic to check if there
+is a "hard" lock by some other user, before a user can modify data.
+Basically, every endpoint that affects data related to a CDN directly (for example, `profiles`), and every endpoint that affects data
+related to a CDN indirectly (for example, `parameters`, `cachegroups`) will need to be updated to perform the above mentioned check.
+
+#### REST API Impact
+
+The following is the JSON representation of a `CDN_Lock` object:
+```JSON
+{
+ "username": "foo",
+ "cdn": "cdn1",
+ "message": "snapping cdn",
+ "soft": false,
+ "lastUpdated": "2021-05-10T16:03:34-06:00"
+}
+```
+
+The following table describes the top level `CDN_Lock` object:
+
+| field | type | optionality | description |
+| ----------- | --------------------------- | ----------- | -----------------------------------------------------------------------------------------------------------------------------|
+| username | string | required | the user name of the user that wants to acquire a lock on the CDN |
+| cdn | string | required | the name of the CDN on which the lcok needs to be acquired |
+| message | string | optional | the message stating a reason behind locking the CDN |
+| soft | boolean | required | whether or not this is a shared lock, meaning if a user has the lock, whether or not other users can make changes to the CDN |
+| lastUpdated | time | required | the last time this lock was updated |
+
+**API constraints:**
+- a CDN can have only one `hard` or `soft` lock at a time
+- a user can snap/ queue a CDN only if they are the one holding the lock (of either kind) on the `cdn`. Alternatively, if no one has the lock on the `cdn`, anyone can snap/ queue/ make changes to the CDN
+- a user can delete their `hard` or `soft` lock whenever they want
+- a user with at least `all-read` and `all-write` capabilities can delete the locks of other users on any CDN. The `all-write` capability will be modified
Review comment:
Yeah, sorry, I should've been more clear. It should still specify the privilege levels, since that's what we actually use today
--
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
[GitHub] [trafficcontrol] limited commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
limited commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r631243781
##########
File path: blueprints/to-locks.md
##########
@@ -0,0 +1,279 @@
+<!--
+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
+ - Disable the snap/ queue button 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.
+The following endpoints will need to handle the locks logic:
+- `/cachegroups/{{ID}}/queue_update`
+- `/cdns/{{ID}}/queue_update`
+- `/servers/{{hostname}}/queue_update`
+- `/snapshot`
+- `/topologies/{{name}}/queue_update`
+
+#### REST API Impact
+
+The following is the JSON representation of a `CDN_Lock` object:
+```JSON
+{
+ "username": "foo",
+ "cdn": "cdn1",
+ "message": "snapping cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10T16:03:34-06:00"
+}
+```
+
+The following table describes the top level `CDN_Lock` object:
+
+| field | type | optionality | description |
+| ----------- | --------------------------- | ----------- | ----------------------------------------------------------------------------------------|
+| username | string | required | the user name of the user that wants to acquire a lock on the CDN |
+| cdn | string | required | the name of the CDN on which the lcok needs to be acquired |
+| message | string | optional | the message stating a reason behind locking the CDN |
+| shared | boolean | required | whether or not this is a shared lock |
+| creator | boolean | required | whether or not the requesting `username` is the first one to acquire a lock on `cdn`|
+| lastUpdated | time | required | the last time this lock was updated |
+
+**API constraints:**
+- a `username` and `cdn` combination must be unique if `shared` is set to `false`. In other words, there can be only one `exclusive`
+lock for a CDN
+- a CDN can have multiple `shared` locks
+- the `creator` will be set to `true` if the user is the first one acquiring a lock for the specified `cdn`
+- a user can snap/ queue a CDN only if the `creator` field corresponding to the `username` and `cdn` combination is `true`
+- a user can delete their `exclusive` lock whenever, since the user is the creator in this case
+- a user who is the creator cannot delete their `shared` lock until all other non-creator users have releases their shared locks for that CDN
+- a user with at least `all-read` and `all-write` capabilities can delete the locks of other users on any CDN. The `all-write` capability will be modified
+to include a new capability `delete-all-locks`.
+
+Three new endpoints will be added for `GET`, `POST` and `DELETE` functionality with respect to CDN locks.
+##### GET `cdn_locks`
+
+response JSON:
+```JSON
+{
+ "response": [
+ {
+ "username": "foo",
+ "cdn": "cdn1",
+ "message": "snapping cdn",
+ "shared": true,
+ "creator": true,
+ "lastUpdated": "2021-05-10T16:03:34-06:00"
+ },
+ {
+ "username": "bar",
+ "cdn": "cdn2",
+ "message": "queue cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10T17:04:34-06:00"
+ }
+ ]
+}
+```
+
+##### POST `cdn_locks`
+
+request JSON:
+```JSON
+{
+ "cdn": "bar",
+ "message": "snapping cdn",
+ "shared": false
+}
+```
+
+response JSON:
+```JSON
+{
+ "alerts": [
+ {
+ "text": "CDN lock acquired!",
+ "level": "success"
+ }
+ ],
+ "response": {
+ "username": "foo",
+ "cdn": "bar",
+ "message": "snapping cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10T17:05:30-06:00"
+ }
+}
+```
+
+##### `DELETE /cdn_locks?cdn=bar`
+
+response JSON:
+```JSON
+{
+ "alerts": [
+ {
+ "text": "Cdn lock deleted",
+ "level": "success"
+ }
+ ],
+ "response": {
+ "username": "foo",
+ "cdn": "bar",
+ "message": "snapping cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10T17:05:30-06:00"
+ }
+}
+```
+
+#### Client Impact
+
+New Go client methods will be added for the `/cdn_locks` endpoints in order to write TO API tests for the new endpoints.
+
+#### Data Model / Database Impact
Review comment:
What prevents two users from obtaining a lock on the same resource?
--
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
[GitHub] [trafficcontrol] mitchell852 commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
mitchell852 commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r632656998
##########
File path: blueprints/to-locks.md
##########
@@ -0,0 +1,281 @@
+<!--
+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
+
+1. Currently, there is no way to guarantee that only your changes will make their way into a snapshot 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.
+
+2. There is no way to prevent another user from performing a snapshot and prematurely propagating the (incomplete) changes
+ to Traffic Router and Traffic Monitor.
+
+3. There is no way to prevent other users from queueing updates on servers, and prematurely propagating the (incomplete) changes
+ to the Traffic Servers.
+
+All the above three cases 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 (hard locks)
+- Anybody can make changes but only you can snap/ queue your CDN (soft locks)
+
+`Hard` 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 hard locks.
+
+The second category of locks is `soft` 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, say user `A` has acquired the `soft` lock
+on cdn `foo`. Now, any number of users (including `A`) can make changes on the CDN. However, only the first user who grabbed the soft lock,
+in this case, user `A`, 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 soft
+and hard). 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 `Soft Lock` field that can be set to `true` or `false` based on user requirement
Review comment:
the UI probably needs 2 radio buttons. 1 for hard lock and one for soft lock (with a tooltip of what each means or something) so the user can see both options and decide which makes sense for them.
--
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
[GitHub] [trafficcontrol] mitchell852 commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
mitchell852 commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r630461872
##########
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
Review comment:
for the most part TP is pretty dumb. showing/hiding things based on your ability to do things was never implemented (except for tenancy restrictions). TP really depends on the API for that. maybe the next version of TP along w/ roles/permissions can do a better job of that.
--
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
[GitHub] [trafficcontrol] mitchell852 commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
mitchell852 commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r632672500
##########
File path: blueprints/to-locks.md
##########
@@ -0,0 +1,281 @@
+<!--
+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
+
+1. Currently, there is no way to guarantee that only your changes will make their way into a snapshot 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.
+
+2. There is no way to prevent another user from performing a snapshot and prematurely propagating the (incomplete) changes
+ to Traffic Router and Traffic Monitor.
+
+3. There is no way to prevent other users from queueing updates on servers, and prematurely propagating the (incomplete) changes
+ to the Traffic Servers.
+
+All the above three cases 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 (hard locks)
+- Anybody can make changes but only you can snap/ queue your CDN (soft locks)
+
+`Hard` 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 hard locks.
+
+The second category of locks is `soft` 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, say user `A` has acquired the `soft` lock
+on cdn `foo`. Now, any number of users (including `A`) can make changes on the CDN. However, only the first user who grabbed the soft lock,
+in this case, user `A`, 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 soft
+and hard). 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 `Soft Lock` 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
+ - Disable the snap/ queue button 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
+`soft` vs `hard` locks, and forbid a user from snapping/ queueing a CDN if another user possesses a lock on that CDN.
+The following endpoints will need to handle the locks logic:
+- `/cachegroups/{{ID}}/queue_update`
+- `/cdns/{{ID}}/queue_update`
+- `/servers/{{hostname}}/queue_update`
+- `/snapshot`
+- `/topologies/{{name}}/queue_update`
+
+In addition to these, all `PUT`, `POST`, `DELETE` endpoints that scope to a CDN will have to add in the logic to check if there
+is a "hard" lock by some other user, before a user can modify data.
+Basically, every endpoint that affects data related to a CDN directly (for example, `profiles`), and every endpoint that affects data
+related to a CDN indirectly (for example, `parameters`, `cachegroups`) will need to be updated to perform the above mentioned check.
+
+#### REST API Impact
+
+The following is the JSON representation of a `CDN_Lock` object:
+```JSON
+{
+ "username": "foo",
+ "cdn": "cdn1",
+ "message": "snapping cdn",
+ "soft": false,
+ "lastUpdated": "2021-05-10T16:03:34-06:00"
+}
+```
+
+The following table describes the top level `CDN_Lock` object:
+
+| field | type | optionality | description |
+| ----------- | --------------------------- | ----------- | -----------------------------------------------------------------------------------------------------------------------------|
+| username | string | required | the user name of the user that wants to acquire a lock on the CDN |
+| cdn | string | required | the name of the CDN on which the lcok needs to be acquired |
+| message | string | optional | the message stating a reason behind locking the CDN |
+| soft | boolean | required | whether or not this is a shared lock, meaning if a user has the lock, whether or not other users can make changes to the CDN |
+| lastUpdated | time | required | the last time this lock was updated |
+
+**API constraints:**
+- a CDN can have only one `hard` or `soft` lock at a time
+- a user can snap/ queue a CDN only if they are the one holding the lock (of either kind) on the `cdn`. Alternatively, if no one has the lock on the `cdn`, anyone can snap/ queue/ make changes to the CDN
+- a user can delete their `hard` or `soft` lock whenever they want
+- a user with at least `all-read` and `all-write` capabilities can delete the locks of other users on any CDN. The `all-write` capability will be modified
Review comment:
this is fine but permissions don't work that way currently and maybe not for some time so you need to pin each action to a role.
GET locks = read/only role
POST locks = operations+ role?
DELETE lock = operations+ role and only your own lock unless admin role?
--
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
[GitHub] [trafficcontrol] srijeet0406 commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
srijeet0406 commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r630528824
##########
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,
+ "lastUpdated": "2021-05-10 16:03:34-06"
+}
+```
+
+The following table describes the top level `CDN_Lock` object:
+
+| field | type | optionality | description |
+| ----------- | --------------------------- | ----------- | ----------------------------------------------------------------------------------------|
+| userName | string | required | the user name of the user that wants to acquire a lock on the CDN |
+| cdnName | string | required | the name of the CDN on which the lcok needs to be acquired |
+| message | string | optional | the message stating a reason behind locking the CDN |
+| shared | boolean | required | whether or not this is a shared lock |
+| creator | boolean | optional | whether or not the requesting `userName` is the first one to acquire a lock on `cdnName`|
+| lastUpdated | time | optional | the last time this lock was updated |
+
+**API constraints:**
+- a `userName` and `cdnName` combination must be unique id `shared` is set to `false`. In other words, there can be only one `exclusive`
+lock for a CDN
+- a CDN can have multiple `shared` locks
+- the `creator` will be set to `true` if the user is the first one acquiring a lock for the specified `cdnName`
+- a user can snap/ queue a CDN only if the `creator` field corresponding to the `userName` and `cdnName` combination is `true`
+- a user can delete their `exclusive` lock whenever, since the user is the creator in this case
+- a user who is the creator cannot delete their `shared` lock until all other non-creator users have releases their shared locks for that CDN
+- an `admin` user can delete the locks of other users on any CDN
+
+Three new endpoints will be added for `GET`, `POST` and `DELETE` functionality with respect to CDN locks.
+##### GET `cdn_locks`
+
+response JSON:
+```JSON
+{
+ "response": [
+ {
+ "userName": "foo",
+ "cdnName": "cdn1",
+ "message": "snapping cdn",
+ "shared": true,
+ "creator": true,
+ "lastUpdated": "2021-05-10 16:03:34-06"
+ },
+ {
+ "userName": "bar",
+ "cdnName": "cdn2",
+ "message": "queue cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10 17:04:34-06"
+ }
+ ]
+}
+```
+
+##### POST `cdn_locks`
+
+request JSON:
+```JSON
+{
+ "cdnName": "bar",
+ "message": "snapping cdn",
+ "shared": false
+}
+```
+
+response JSON:
+```JSON
+{
+ "alerts": [
+ {
+ "text": "CDN lock acquired!",
+ "level": "success"
+ }
+ ],
+ "response": {
+ "userName": "foo",
+ "cdnName": "bar",
+ "message": "snapping cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10 17:05:30-06"
+ }
+}
+```
+
+##### `DELETE /cdn_locks?cdn=bar`
+
+response JSON:
+```JSON
+{
+ "alerts": [
+ {
+ "text": "Cdn lock deleted",
+ "level": "success"
+ }
+ ]
+}
+```
+
+#### Client Impact
+
+New Go client methods will be added for the `/cdn_locks` endpoints in order to write TO API tests for the new endpoints.
+
+#### Data Model / Database Impact
+<!--
+*How* will this impact the Traffic Ops data model?
+*How* will this impact the Traffic Ops database schema?
+
+What changes to the lib/go-tc structs will be required?
+What new tables and columns will be required?
+How will existing tables and columns be changed?
+What are the column data types and modifiers?
+What are the FK references and constraints?
+-->
+A new database table for `cdn_lock`, as described below, will be created.
+```text
+ Table "traffic_ops.cdn_lock"
+ Column | Type | Collation | Nullable | Default
+---------------+--------------------------+-----------+----------+--------
+ id | bigint | | not null |
+ username | text | | not null |
+ cdn_name | text | | not null |
+ message | test | | |
+ shared | boolean | | not null | true
+ creator | boolean | | not null | false
Review comment:
Yes, you're right. I'll change it to be `required`. Basically the user requesting a lock will never send the `creator` field in the request. It is taken care of in the API backend logic. If a user is the first one to acquire the lock on a CDN, that user will have the `creator` field set to `true`. Else, every other user will have it set to `false`.
--
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
[GitHub] [trafficcontrol] srijeet0406 commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
srijeet0406 commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r630529237
##########
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,
+ "lastUpdated": "2021-05-10 16:03:34-06"
+}
+```
+
+The following table describes the top level `CDN_Lock` object:
+
+| field | type | optionality | description |
+| ----------- | --------------------------- | ----------- | ----------------------------------------------------------------------------------------|
+| userName | string | required | the user name of the user that wants to acquire a lock on the CDN |
+| cdnName | string | required | the name of the CDN on which the lcok needs to be acquired |
+| message | string | optional | the message stating a reason behind locking the CDN |
+| shared | boolean | required | whether or not this is a shared lock |
+| creator | boolean | optional | whether or not the requesting `userName` is the first one to acquire a lock on `cdnName`|
+| lastUpdated | time | optional | the last time this lock was updated |
+
+**API constraints:**
+- a `userName` and `cdnName` combination must be unique id `shared` is set to `false`. In other words, there can be only one `exclusive`
+lock for a CDN
+- a CDN can have multiple `shared` locks
+- the `creator` will be set to `true` if the user is the first one acquiring a lock for the specified `cdnName`
+- a user can snap/ queue a CDN only if the `creator` field corresponding to the `userName` and `cdnName` combination is `true`
+- a user can delete their `exclusive` lock whenever, since the user is the creator in this case
+- a user who is the creator cannot delete their `shared` lock until all other non-creator users have releases their shared locks for that CDN
+- an `admin` user can delete the locks of other users on any CDN
+
+Three new endpoints will be added for `GET`, `POST` and `DELETE` functionality with respect to CDN locks.
+##### GET `cdn_locks`
+
+response JSON:
+```JSON
+{
+ "response": [
+ {
+ "userName": "foo",
+ "cdnName": "cdn1",
+ "message": "snapping cdn",
+ "shared": true,
+ "creator": true,
+ "lastUpdated": "2021-05-10 16:03:34-06"
+ },
+ {
+ "userName": "bar",
+ "cdnName": "cdn2",
+ "message": "queue cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10 17:04:34-06"
+ }
+ ]
+}
+```
+
+##### POST `cdn_locks`
+
+request JSON:
+```JSON
+{
+ "cdnName": "bar",
+ "message": "snapping cdn",
+ "shared": false
+}
+```
+
+response JSON:
+```JSON
+{
+ "alerts": [
+ {
+ "text": "CDN lock acquired!",
+ "level": "success"
+ }
+ ],
+ "response": {
+ "userName": "foo",
+ "cdnName": "bar",
+ "message": "snapping cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10 17:05:30-06"
+ }
+}
+```
+
+##### `DELETE /cdn_locks?cdn=bar`
+
+response JSON:
+```JSON
+{
+ "alerts": [
+ {
+ "text": "Cdn lock deleted",
+ "level": "success"
+ }
+ ]
+}
+```
+
+#### Client Impact
+
+New Go client methods will be added for the `/cdn_locks` endpoints in order to write TO API tests for the new endpoints.
+
+#### Data Model / Database Impact
+<!--
+*How* will this impact the Traffic Ops data model?
+*How* will this impact the Traffic Ops database schema?
+
+What changes to the lib/go-tc structs will be required?
+What new tables and columns will be required?
+How will existing tables and columns be changed?
+What are the column data types and modifiers?
+What are the FK references and constraints?
+-->
+A new database table for `cdn_lock`, as described below, will be created.
+```text
+ Table "traffic_ops.cdn_lock"
+ Column | Type | Collation | Nullable | Default
+---------------+--------------------------+-----------+----------+--------
+ id | bigint | | not null |
+ username | text | | not null |
+ cdn_name | text | | not null |
+ message | test | | |
+ shared | boolean | | not null | true
+ creator | boolean | | not null | false
+ last_updated | timestamp with time zone | | not null | now()
+Indexes:
+ "pk_cdn_lock" PRIMARY KEY(id)
+Foreign-key constraints:
+ "fk_lock_cdn" FOREIGN KEY (cdn_name) REFERENCES cdn(name)
+ "fk_lock_username" FOREIGN KEY ("username") REFERENCES tm_user(username)
+```
Review comment:
You're right, a user can have a maximum of one lock per CDN. I'll change it.
--
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
[GitHub] [trafficcontrol] mitchell852 commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
mitchell852 commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r632672500
##########
File path: blueprints/to-locks.md
##########
@@ -0,0 +1,281 @@
+<!--
+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
+
+1. Currently, there is no way to guarantee that only your changes will make their way into a snapshot 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.
+
+2. There is no way to prevent another user from performing a snapshot and prematurely propagating the (incomplete) changes
+ to Traffic Router and Traffic Monitor.
+
+3. There is no way to prevent other users from queueing updates on servers, and prematurely propagating the (incomplete) changes
+ to the Traffic Servers.
+
+All the above three cases 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 (hard locks)
+- Anybody can make changes but only you can snap/ queue your CDN (soft locks)
+
+`Hard` 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 hard locks.
+
+The second category of locks is `soft` 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, say user `A` has acquired the `soft` lock
+on cdn `foo`. Now, any number of users (including `A`) can make changes on the CDN. However, only the first user who grabbed the soft lock,
+in this case, user `A`, 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 soft
+and hard). 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 `Soft Lock` 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
+ - Disable the snap/ queue button 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
+`soft` vs `hard` locks, and forbid a user from snapping/ queueing a CDN if another user possesses a lock on that CDN.
+The following endpoints will need to handle the locks logic:
+- `/cachegroups/{{ID}}/queue_update`
+- `/cdns/{{ID}}/queue_update`
+- `/servers/{{hostname}}/queue_update`
+- `/snapshot`
+- `/topologies/{{name}}/queue_update`
+
+In addition to these, all `PUT`, `POST`, `DELETE` endpoints that scope to a CDN will have to add in the logic to check if there
+is a "hard" lock by some other user, before a user can modify data.
+Basically, every endpoint that affects data related to a CDN directly (for example, `profiles`), and every endpoint that affects data
+related to a CDN indirectly (for example, `parameters`, `cachegroups`) will need to be updated to perform the above mentioned check.
+
+#### REST API Impact
+
+The following is the JSON representation of a `CDN_Lock` object:
+```JSON
+{
+ "username": "foo",
+ "cdn": "cdn1",
+ "message": "snapping cdn",
+ "soft": false,
+ "lastUpdated": "2021-05-10T16:03:34-06:00"
+}
+```
+
+The following table describes the top level `CDN_Lock` object:
+
+| field | type | optionality | description |
+| ----------- | --------------------------- | ----------- | -----------------------------------------------------------------------------------------------------------------------------|
+| username | string | required | the user name of the user that wants to acquire a lock on the CDN |
+| cdn | string | required | the name of the CDN on which the lcok needs to be acquired |
+| message | string | optional | the message stating a reason behind locking the CDN |
+| soft | boolean | required | whether or not this is a shared lock, meaning if a user has the lock, whether or not other users can make changes to the CDN |
+| lastUpdated | time | required | the last time this lock was updated |
+
+**API constraints:**
+- a CDN can have only one `hard` or `soft` lock at a time
+- a user can snap/ queue a CDN only if they are the one holding the lock (of either kind) on the `cdn`. Alternatively, if no one has the lock on the `cdn`, anyone can snap/ queue/ make changes to the CDN
+- a user can delete their `hard` or `soft` lock whenever they want
+- a user with at least `all-read` and `all-write` capabilities can delete the locks of other users on any CDN. The `all-write` capability will be modified
Review comment:
this is fine but permissions don't work that way currently and maybe not for some time so you need to pin each action to a role.
GET locks/ = read/only role
POST locks = operations+ role?
DELETE lock = operations+ role and only your own lock unless admin role?
--
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
[GitHub] [trafficcontrol] mitchell852 commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
mitchell852 commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r630463710
##########
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:
is that supposed to mean "am I the creator?"
--
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
[GitHub] [trafficcontrol] mitchell852 commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
mitchell852 commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r631316192
##########
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:
lock.creator still feels redundant with lock.username imo. if lock.username != me, i know that i'm not the "creator" :)
--
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
[GitHub] [trafficcontrol] mitchell852 commented on pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
mitchell852 commented on pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#issuecomment-840064797
> if the person who had originally created the shared lock deletes the lock, who has the right to snap/ queue the CDN? If we leave it open to anyone, then we are back to square one IMO.
yep, if no lock (shared or exclusive) then anybody can do anything which i think is fine.
--
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
[GitHub] [trafficcontrol] mitchell852 edited a comment on pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
mitchell852 edited a comment on pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#issuecomment-840018724
> Well I was thinking that you could just do
>
> 1. User `A` grabs a shared lock on CDN `foo`.
> 2. Users `B` and `C` can still make changes, because the lock is "shared", but cannot snap or queue (only user A can)
> 3. User `A` deletes the shared lock. Now anyone can snap or queue
^^ this is how i understood a "shared lock" to work and i understood an "exclusive lock" to work like:
1. User `A` grabs an exclusive lock on CDN `foo`.
2. Users `B` and `C` CANNOT make CDN changes or snap/queue because the lock is "exclusive" to User `A`
3. User `A` deletes the exclusive lock. Now anyone can make changes/snap/queue
--
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
[GitHub] [trafficcontrol] srijeet0406 commented on pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
srijeet0406 commented on pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#issuecomment-840137750
> just a thought. what if instead of naming it exclusive/shared locks (as shared is a bit confusing), we call it hard/soft locks? just spit balling or maybe that's confusing as well. :)
>
> ```
> hard lock: only the owner can make cdn changes/snap/queue
> soft lock: only the owner can snap/queue (others are free to make cdn changes)
> no lock: anyone (with the proper permissions of course) can make cdn changes/snap/queue (current behavior)
> ```
Agreed, in my head, `shared` == `a lock that can be used by multiple users`, but since thats not the case, renaming them might be a good idea.
--
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
[GitHub] [trafficcontrol] srijeet0406 commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
srijeet0406 commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r630550307
##########
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
Review comment:
Made the change.
--
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
[GitHub] [trafficcontrol] srijeet0406 commented on a change in pull request #5834: CDN Locks Blueprint
Posted by 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
[GitHub] [trafficcontrol] mitchell852 commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
mitchell852 commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r630465622
##########
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
Review comment:
with a shared lock, one person owns it (and can snap/queue the cdn) but many others can make changes right? do we need to specify who these others are? and if so, how?
--
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
[GitHub] [trafficcontrol] srijeet0406 commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
srijeet0406 commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r632898523
##########
File path: blueprints/to-locks.md
##########
@@ -0,0 +1,281 @@
+<!--
+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
+
+1. Currently, there is no way to guarantee that only your changes will make their way into a snapshot 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.
+
+2. There is no way to prevent another user from performing a snapshot and prematurely propagating the (incomplete) changes
+ to Traffic Router and Traffic Monitor.
+
+3. There is no way to prevent other users from queueing updates on servers, and prematurely propagating the (incomplete) changes
+ to the Traffic Servers.
+
+All the above three cases 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 (hard locks)
+- Anybody can make changes but only you can snap/ queue your CDN (soft locks)
+
+`Hard` 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 hard locks.
+
+The second category of locks is `soft` 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, say user `A` has acquired the `soft` lock
+on cdn `foo`. Now, any number of users (including `A`) can make changes on the CDN. However, only the first user who grabbed the soft lock,
+in this case, user `A`, 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 soft
+and hard). 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 `Soft Lock` 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
+ - Disable the snap/ queue button if another user has the lock on that CDN.
Review comment:
I'm not a UI expert, so I'll let you two figure this one out.
--
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
[GitHub] [trafficcontrol] mitchell852 commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
mitchell852 commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r630463710
##########
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:
is that supposed to mean "am I the creator?" if so, i can probably figure that out on my own. either my username is foo or not, right?
--
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
[GitHub] [trafficcontrol] mitchell852 commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
mitchell852 commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r633799805
##########
File path: blueprints/to-locks.md
##########
@@ -0,0 +1,281 @@
+<!--
+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
+
+1. Currently, there is no way to guarantee that only your changes will make their way into a snapshot 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.
+
+2. There is no way to prevent another user from performing a snapshot and prematurely propagating the (incomplete) changes
+ to Traffic Router and Traffic Monitor.
+
+3. There is no way to prevent other users from queueing updates on servers, and prematurely propagating the (incomplete) changes
+ to the Traffic Servers.
+
+All the above three cases 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 (hard locks)
+- Anybody can make changes but only you can snap/ queue your CDN (soft locks)
+
+`Hard` 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 hard locks.
+
+The second category of locks is `soft` 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, say user `A` has acquired the `soft` lock
+on cdn `foo`. Now, any number of users (including `A`) can make changes on the CDN. However, only the first user who grabbed the soft lock,
+in this case, user `A`, 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 soft
+and hard). 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 `Soft Lock` 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
+ - Disable the snap/ queue button if another user has the lock on that CDN.
Review comment:
yes, you are correct @ocket8888. if the info is readily available, i do disable certain features in the UI for good UX reasons. but in this case a cdn does not know it's locked unless it makes an extra api call to GET cdn_locks and that's fine if we want to build in the api call to determine if the button is enabled/disabled.
--
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
[GitHub] [trafficcontrol] rawlinp commented on pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
rawlinp commented on pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#issuecomment-840141767
"Hard" and "soft" locks sound ok to me.
--
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
[GitHub] [trafficcontrol] mitchell852 edited a comment on pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
mitchell852 edited a comment on pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#issuecomment-840076220
> user `A` gets the shared lock on `cdn1`
> users `B` and `C` get the shared lock on `cdn1`
> at this point, user `A` releases the lock, so now `B` and `C`. an snap/ queue `cdn1`(which opens us up to the same issue again)
> user `D` comes in and gets the shared lock on `cdn1`, making `D` the `owner` of the lock
> now again, `B` and `C` are locked out of snapping/ queueing `cdn1`
>
> Form `B` and `C`'s perspective, the system will let them allow snapping/ queueing once, followed by denying them, even though they haven't changed anything from their end. I think this might create confusion for the users.
i think you've overcomplicated it. i think this is all that is needed:
```
exclusive lock: only owner can make cdn changes/snap/queue
shared lock: only owner can snap/queue; owner and non-owners can make cdn changes
no lock: anyone can make cdn changes/snap/queue
```
the user can decide what level of protection they are looking for. i'm pretty sure this is what @rawlinp was thinking when he proposed the shared lock.
--
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
[GitHub] [trafficcontrol] srijeet0406 commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
srijeet0406 commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r631320222
##########
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:
I'm going to change it to `owner`. The username will be what the user of the current lock request is. If we dont have an `owner` field, we wont know who created the lock in the first place. This is information that we'll need in case of shared locks.
--
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
[GitHub] [trafficcontrol] srijeet0406 commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
srijeet0406 commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r630527737
##########
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
Review comment:
Yeah I think it is a dialog box in the current prototype code.
--
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
[GitHub] [trafficcontrol] mitchell852 edited a comment on pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
mitchell852 edited a comment on pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#issuecomment-840064797
> if the person who had originally created the shared lock deletes the lock, who has the right to snap/ queue the CDN? If we leave it open to anyone, then we are back to square one IMO.
yep, if no lock (shared or exclusive) then anybody can do anything which i think is fine. if you don't like that then don't delete the lock :)
--
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
[GitHub] [trafficcontrol] rawlinp edited a comment on pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
rawlinp edited a comment on pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#issuecomment-840103884
> i think you've overcomplicated it. i think this is all that is needed:
> ```
> exclusive lock: only owner can make cdn changes/snap/queue
> shared lock: only owner can snap/queue; owner and non-owners can make cdn changes
> no lock: anyone can make cdn changes/snap/queue
> ```
> the user can decide what level of protection they are looking for. i'm pretty sure this is what @rawlinp was thinking when he proposed the shared lock.
Yeah, that is what I was thinking. I thought there would only be a single exclusive lock and a single shared lock (per-CDN). Each lock can only have one owner at a time, and only one type of lock can be held at a time (per-CDN).
I think it helps to start with the use cases behind each type of lock. For example, if I wanted to update a DS certificate, I could grab the exclusive lock since I don't want anyone else's changes to be propagated until I've had a chance to test the new cert on a single cache. Once I've verified the cert, I will queue the entire CDN then release the exclusive lock.
As another example, say there are a lot of certs about to expire and we want to divide the work among multiple operators. One operator would grab the shared lock (preventing anyone else from queuing updates). The other operators are still free to update their certs anytime (since only a shared lock is held), and when ready, the lock holder will queue updates on single cache. Then all the operators can test their certs before the lock holder queues the entire CDN and releases the shared lock.
We shouldn't make this solution overly complicated, since I see this more as a temporary solution until we have the time to tackle the full solution (delivery service snapshots and server snapshots). Right?
--
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
[GitHub] [trafficcontrol] mitchell852 edited a comment on pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
mitchell852 edited a comment on pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#issuecomment-840064797
> if the person who had originally created the shared lock deletes the lock, who has the right to snap/ queue the CDN? If we leave it open to anyone, then we are back to square one IMO.
yep, if no lock (shared or exclusive) then anybody can do anything which i think is fine. if you don't like that then don't delete the lock :) you don't pass locks from one person to another. you just take them when _you_ want one and delete it when _you_ don't need it anymore.
--
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
[GitHub] [trafficcontrol] mitchell852 commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
mitchell852 commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r632672500
##########
File path: blueprints/to-locks.md
##########
@@ -0,0 +1,281 @@
+<!--
+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
+
+1. Currently, there is no way to guarantee that only your changes will make their way into a snapshot 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.
+
+2. There is no way to prevent another user from performing a snapshot and prematurely propagating the (incomplete) changes
+ to Traffic Router and Traffic Monitor.
+
+3. There is no way to prevent other users from queueing updates on servers, and prematurely propagating the (incomplete) changes
+ to the Traffic Servers.
+
+All the above three cases 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 (hard locks)
+- Anybody can make changes but only you can snap/ queue your CDN (soft locks)
+
+`Hard` 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 hard locks.
+
+The second category of locks is `soft` 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, say user `A` has acquired the `soft` lock
+on cdn `foo`. Now, any number of users (including `A`) can make changes on the CDN. However, only the first user who grabbed the soft lock,
+in this case, user `A`, 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 soft
+and hard). 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 `Soft Lock` 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
+ - Disable the snap/ queue button 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
+`soft` vs `hard` locks, and forbid a user from snapping/ queueing a CDN if another user possesses a lock on that CDN.
+The following endpoints will need to handle the locks logic:
+- `/cachegroups/{{ID}}/queue_update`
+- `/cdns/{{ID}}/queue_update`
+- `/servers/{{hostname}}/queue_update`
+- `/snapshot`
+- `/topologies/{{name}}/queue_update`
+
+In addition to these, all `PUT`, `POST`, `DELETE` endpoints that scope to a CDN will have to add in the logic to check if there
+is a "hard" lock by some other user, before a user can modify data.
+Basically, every endpoint that affects data related to a CDN directly (for example, `profiles`), and every endpoint that affects data
+related to a CDN indirectly (for example, `parameters`, `cachegroups`) will need to be updated to perform the above mentioned check.
+
+#### REST API Impact
+
+The following is the JSON representation of a `CDN_Lock` object:
+```JSON
+{
+ "username": "foo",
+ "cdn": "cdn1",
+ "message": "snapping cdn",
+ "soft": false,
+ "lastUpdated": "2021-05-10T16:03:34-06:00"
+}
+```
+
+The following table describes the top level `CDN_Lock` object:
+
+| field | type | optionality | description |
+| ----------- | --------------------------- | ----------- | -----------------------------------------------------------------------------------------------------------------------------|
+| username | string | required | the user name of the user that wants to acquire a lock on the CDN |
+| cdn | string | required | the name of the CDN on which the lcok needs to be acquired |
+| message | string | optional | the message stating a reason behind locking the CDN |
+| soft | boolean | required | whether or not this is a shared lock, meaning if a user has the lock, whether or not other users can make changes to the CDN |
+| lastUpdated | time | required | the last time this lock was updated |
+
+**API constraints:**
+- a CDN can have only one `hard` or `soft` lock at a time
+- a user can snap/ queue a CDN only if they are the one holding the lock (of either kind) on the `cdn`. Alternatively, if no one has the lock on the `cdn`, anyone can snap/ queue/ make changes to the CDN
+- a user can delete their `hard` or `soft` lock whenever they want
+- a user with at least `all-read` and `all-write` capabilities can delete the locks of other users on any CDN. The `all-write` capability will be modified
Review comment:
this is fine but permissions don't work that way currently and maybe not for some time so you need to pin each action to a role.
GET locks/lock = read/only role
POST locks = operations+ role?
DELETE lock = operations+ role and only your own lock unless admin role?
--
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
[GitHub] [trafficcontrol] srijeet0406 commented on pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
srijeet0406 commented on pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#issuecomment-839190554
> What's the use-case for allowing arbitrary numbers of shared locks to exist on a single CDN and prevent unlocking until all non-creator locks are removed?
User `A` grabs a shared lock on CDN `foo`.
Users `B` and `C` (in that order) also grab shared locks on CDN `foo` after `A`.
Now, if `A` deletes the lock on CDN `foo`, nobody has the ability to snap/ queue CDN `foo`.
We could be fancy and transfer the lock to the next user who grabbed the lock (in this case, `B`), but that would add to the complexity.
--
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
[GitHub] [trafficcontrol] srijeet0406 commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
srijeet0406 commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r630527127
##########
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
Review comment:
Yeah maybe I could have worded this better. So currently in the prototype code, the API just rejects the request to snap/ queue a CDN by a user who doesn't have the lock on that particular CDN, and TP displays it. No other change is required for this use case as far as TP is concerned.
--
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
[GitHub] [trafficcontrol] mitchell852 commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
mitchell852 commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r630461872
##########
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
Review comment:
for the most part TP is pretty dumb. showing/hiding things based on your ability to do things was never implemented (except for tenancy restrictions). it really depends on the API for that. maybe the next version of TP along w/ roles/permissions can do a better job of that.
--
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
[GitHub] [trafficcontrol] limited commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
limited commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r631290113
##########
File path: blueprints/to-locks.md
##########
@@ -0,0 +1,279 @@
+<!--
+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
+ - Disable the snap/ queue button 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.
+The following endpoints will need to handle the locks logic:
+- `/cachegroups/{{ID}}/queue_update`
+- `/cdns/{{ID}}/queue_update`
+- `/servers/{{hostname}}/queue_update`
+- `/snapshot`
+- `/topologies/{{name}}/queue_update`
+
+#### REST API Impact
+
+The following is the JSON representation of a `CDN_Lock` object:
+```JSON
+{
+ "username": "foo",
+ "cdn": "cdn1",
+ "message": "snapping cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10T16:03:34-06:00"
+}
+```
+
+The following table describes the top level `CDN_Lock` object:
+
+| field | type | optionality | description |
+| ----------- | --------------------------- | ----------- | ----------------------------------------------------------------------------------------|
+| username | string | required | the user name of the user that wants to acquire a lock on the CDN |
+| cdn | string | required | the name of the CDN on which the lcok needs to be acquired |
+| message | string | optional | the message stating a reason behind locking the CDN |
+| shared | boolean | required | whether or not this is a shared lock |
+| creator | boolean | required | whether or not the requesting `username` is the first one to acquire a lock on `cdn`|
+| lastUpdated | time | required | the last time this lock was updated |
+
+**API constraints:**
+- a `username` and `cdn` combination must be unique if `shared` is set to `false`. In other words, there can be only one `exclusive`
+lock for a CDN
+- a CDN can have multiple `shared` locks
+- the `creator` will be set to `true` if the user is the first one acquiring a lock for the specified `cdn`
+- a user can snap/ queue a CDN only if the `creator` field corresponding to the `username` and `cdn` combination is `true`
+- a user can delete their `exclusive` lock whenever, since the user is the creator in this case
+- a user who is the creator cannot delete their `shared` lock until all other non-creator users have releases their shared locks for that CDN
+- a user with at least `all-read` and `all-write` capabilities can delete the locks of other users on any CDN. The `all-write` capability will be modified
+to include a new capability `delete-all-locks`.
+
+Three new endpoints will be added for `GET`, `POST` and `DELETE` functionality with respect to CDN locks.
+##### GET `cdn_locks`
+
+response JSON:
+```JSON
+{
+ "response": [
+ {
+ "username": "foo",
+ "cdn": "cdn1",
+ "message": "snapping cdn",
+ "shared": true,
+ "creator": true,
+ "lastUpdated": "2021-05-10T16:03:34-06:00"
+ },
+ {
+ "username": "bar",
+ "cdn": "cdn2",
+ "message": "queue cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10T17:04:34-06:00"
+ }
+ ]
+}
+```
+
+##### POST `cdn_locks`
+
+request JSON:
+```JSON
+{
+ "cdn": "bar",
+ "message": "snapping cdn",
+ "shared": false
+}
+```
+
+response JSON:
+```JSON
+{
+ "alerts": [
+ {
+ "text": "CDN lock acquired!",
+ "level": "success"
+ }
+ ],
+ "response": {
+ "username": "foo",
+ "cdn": "bar",
+ "message": "snapping cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10T17:05:30-06:00"
+ }
+}
+```
+
+##### `DELETE /cdn_locks?cdn=bar`
+
+response JSON:
+```JSON
+{
+ "alerts": [
+ {
+ "text": "Cdn lock deleted",
+ "level": "success"
+ }
+ ],
+ "response": {
+ "username": "foo",
+ "cdn": "bar",
+ "message": "snapping cdn",
+ "shared": false,
+ "creator": true,
+ "lastUpdated": "2021-05-10T17:05:30-06:00"
+ }
+}
+```
+
+#### Client Impact
+
+New Go client methods will be added for the `/cdn_locks` endpoints in order to write TO API tests for the new endpoints.
+
+#### Data Model / Database Impact
Review comment:
Is either of these examples possible?
```
User1 API request received to acquire exclusive lock. API checks database, no existing lock
User2 API request received to acquire exclusive lock. API checks database, no existing lock
User1 writes lock to DB. Returns lock via API
User2 writes lock to DB. Returns lock via API
```
```
(User1, cdn) lock in db
User1 sends API request to snap. API checks database, lock exists
Before snap completes, user1 releases lock, removing entry from db table
User2 modifies CDN
User1 snap resumes and includes User 2 modifications (bad?)
```
--
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
[GitHub] [trafficcontrol] ocket8888 commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
ocket8888 commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r630548927
##########
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
Review comment:
I just think the button should be `ng-disabled="cdnIsLocked(cdn.name)"`
--
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
[GitHub] [trafficcontrol] ocket8888 commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
ocket8888 commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r632684320
##########
File path: blueprints/to-locks.md
##########
@@ -0,0 +1,281 @@
+<!--
+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
+
+1. Currently, there is no way to guarantee that only your changes will make their way into a snapshot 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.
+
+2. There is no way to prevent another user from performing a snapshot and prematurely propagating the (incomplete) changes
+ to Traffic Router and Traffic Monitor.
+
+3. There is no way to prevent other users from queueing updates on servers, and prematurely propagating the (incomplete) changes
+ to the Traffic Servers.
+
+All the above three cases 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 (hard locks)
+- Anybody can make changes but only you can snap/ queue your CDN (soft locks)
+
+`Hard` 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 hard locks.
+
+The second category of locks is `soft` 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, say user `A` has acquired the `soft` lock
+on cdn `foo`. Now, any number of users (including `A`) can make changes on the CDN. However, only the first user who grabbed the soft lock,
+in this case, user `A`, 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 soft
+and hard). 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 `Soft Lock` field that can be set to `true` or `false` based on user requirement
Review comment:
or a checkbox (or "switch") for whether or not it's a "hard" lock - down with `select`s containing only the options "true" and "false".
--
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
[GitHub] [trafficcontrol] srijeet0406 commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
srijeet0406 commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r630525627
##########
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
Review comment:
I was thinking instead of specifying the entire list of users that has the shared lock on the CDN, we could just use a notification displaying the "first" user to have acquired a shared lock on that CDN, since only that user can snap/ queue the CDN.
--
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
[GitHub] [trafficcontrol] mitchell852 edited a comment on pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
mitchell852 edited a comment on pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#issuecomment-840136903
just a thought. what if instead of naming it exclusive/shared locks (as shared is a bit confusing), we call it hard/soft locks? just spit balling or maybe that's confusing as well. :)
```
hard lock: only the lock owner can make cdn changes/snap/queue
soft lock: only the lock owner can snap/queue the cdn (others are free to make cdn changes)
no lock: anyone (with the proper permissions of course) can make cdn changes/snap/queue (current behavior)
```
--
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
[GitHub] [trafficcontrol] mitchell852 commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
mitchell852 commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r630465622
##########
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
Review comment:
with a shared lock, one person owns it (and is the ONLY person that can snap/queue the cdn) but many others can make changes right to the cdn's resources? do we need to specify who these others are? and if so, how?
--
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
[GitHub] [trafficcontrol] mitchell852 commented on pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
mitchell852 commented on pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#issuecomment-840136903
just a thought. what if instead of naming it exclusive/shared locks (as shared is a bit confusing), we call it hard/soft locks? just spit balling or maybe that's confusing as well. :)
```
hard lock: only the owner can make cdn changes/snap/queue
soft lock: only the owner can snap/queue (others are free to make cdn changes)
no lock: anyone (with the proper permissions of course) can make cdn changes/snap/queue (current behavior)
```
--
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
[GitHub] [trafficcontrol] srijeet0406 commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
srijeet0406 commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r630526318
##########
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
Review comment:
Yeah I mentioned that the snap/ queue endpoints will have to add logic to handle the locks, but I will explicitly mention the endpoints to make it clearer.
--
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
[GitHub] [trafficcontrol] ocket8888 commented on a change in pull request #5834: CDN Locks Blueprint
Posted by GitBox <gi...@apache.org>.
ocket8888 commented on a change in pull request #5834:
URL: https://github.com/apache/trafficcontrol/pull/5834#discussion_r631985617
##########
File path: blueprints/to-locks.md
##########
@@ -0,0 +1,268 @@
+<!--
+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 (hard locks)
+- Anybody can make changes but only you can snap/ queue your CDN (soft locks)
+
+`Hard` 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 hard locks.
+
+The second category of locks is `soft` 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, say user `A` has acquired the `soft` lock
+on cdn `foo`. Now, any number of users (including `A`) can make changes on the CDN. However, only the first user who grabbed the soft lock,
+in this case, user `A`, 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 soft
+and hard). 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 `Soft Lock` 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
+ - Disable the snap/ queue button 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
+`soft` vs `hard` locks, and forbid a user from snapping/ queueing a CDN if another user possesses a lock on that CDN.
+The following endpoints will need to handle the locks logic:
+- `/cachegroups/{{ID}}/queue_update`
+- `/cdns/{{ID}}/queue_update`
+- `/servers/{{hostname}}/queue_update`
+- `/snapshot`
+- `/topologies/{{name}}/queue_update`
+
+#### REST API Impact
+
+The following is the JSON representation of a `CDN_Lock` object:
+```JSON
+{
+ "username": "foo",
+ "cdn": "cdn1",
+ "message": "snapping cdn",
+ "soft": false,
+ "lastUpdated": "2021-05-10T16:03:34-06:00"
+}
+```
+
+The following table describes the top level `CDN_Lock` object:
+
+| field | type | optionality | description |
+| ----------- | --------------------------- | ----------- | -----------------------------------------------------------------------------------------------------------------------------|
+| username | string | required | the user name of the user that wants to acquire a lock on the CDN |
+| cdn | string | required | the name of the CDN on which the lcok needs to be acquired |
+| message | string | optional | the message stating a reason behind locking the CDN |
+| soft | boolean | required | whether or not this is a shared lock, meaning if a user has the lock, whether or not other users can make changes to the CDN |
+| lastUpdated | time | required | the last time this lock was updated |
+
+**API constraints:**
+- a CDN can have only one `hard` or `soft` lock at a time
+- a user can snap/ queue a CDN only if they are the one holding the lock (of either kind) on the `cdn`. Alternatively, if no one has the lock on the `cdn`, anyone can snap/ queue/ make changes to the CDN
+- a user can delete their `hard` or `soft` lock whenever they want
+- a user with at least `all-read` and `all-write` capabilities can delete the locks of other users on any CDN. The `all-write` capability will be modified
+to include a new capability `delete-all-locks`.
+
+Three new endpoints will be added for `GET`, `POST` and `DELETE` functionality with respect to CDN locks.
+##### GET `cdn_locks`
+
+response JSON:
+```JSON
+{
+ "response": [
+ {
+ "username": "foo",
+ "cdn": "cdn1",
+ "message": "snapping cdn",
+ "soft": true,
+ "lastUpdated": "2021-05-10T16:03:34-06:00"
+ },
+ {
+ "username": "bar",
+ "cdn": "cdn2",
+ "message": "queue cdn",
+ "soft": false,
+ "lastUpdated": "2021-05-10T17:04:34-06:00"
+ }
+ ]
+}
+```
+
+##### POST `cdn_locks`
+
+request JSON:
+```JSON
+{
+ "cdn": "bar",
+ "message": "snapping cdn",
+ "soft": false
+}
+```
+
+response JSON:
+```JSON
+{
+ "alerts": [
+ {
+ "text": "CDN lock acquired!",
+ "level": "success"
+ }
+ ],
+ "response": {
+ "username": "foo",
+ "cdn": "bar",
+ "message": "snapping cdn",
+ "soft": false,
+ "lastUpdated": "2021-05-10T17:05:30-06:00"
+ }
+}
+```
+
+##### `DELETE /cdn_locks?cdn=bar`
+
+response JSON:
+```JSON
+{
+ "alerts": [
+ {
+ "text": "Cdn lock deleted",
+ "level": "success"
+ }
+ ],
+ "response": {
+ "username": "foo",
+ "cdn": "bar",
+ "message": "snapping cdn",
+ "soft": false,
+ "lastUpdated": "2021-05-10T17:05:30-06:00"
+ }
+}
+```
+
+#### Client Impact
+
+New Go client methods will be added for the `/cdn_locks` endpoints in order to write TO API tests for the new endpoints.
+
+#### Data Model / Database Impact
+A new database table for `cdn_lock`, as described below, will be created.
+```text
+ Table "traffic_ops.cdn_lock"
+ Column | Type | Collation | Nullable | Default
+---------------+--------------------------+-----------+----------+--------
+ id | bigint | | not null |
+ username | text | | not null |
+ cdn_name | text | | not null |
+ message | test | | |
+ soft | boolean | | not null | true
+ last_updated | timestamp with time zone | | not null | now()
+Indexes:
+ "pk_cdn_lock" PRIMARY KEY(cdn)
+Foreign-key constraints:
+ "fk_lock_cdn" FOREIGN KEY (cdn) REFERENCES cdn(name)
+ "fk_lock_username" FOREIGN KEY (username) REFERENCES tm_user(username)
+```
+
+The `capability` table will need to add another capability by the name of `delete-all-locks` and the `all-write` capability
+will include this new capability.
+### ORT Impact
+No impact
+
+### Traffic Monitor Impact
+No impact
+
+### Traffic Router Impact
+No impact
+
+### Traffic Stats Impact
+No impact
+
+### Traffic Vault Impact
+No impact
+
+### Documentation Impact
+All new endpoints will need to be documented, along with the documentation explaining `cdn_locks`.
+
+### Testing Impact
+Client/API integration tests should be written to verify the
+functionality as described in [API](#sec:api).
+
+### Performance Impact
+We do not anticipate significant performance impact, as this process will just entail one additional check
+in the database before performing a snap or queue operation.
+
+### Security Impact
+We do not anticipate any impact on security due to the introduction of `cdn_locks`.
+
+### Upgrade Impact
+There will be two database migrations, one to create the `cdn_locks` table, and the other to add
+the new capability. This does not depend on any existing data, so nothing should ideally cause this migration to fail.
Review comment:
Oh, also, you don't need a migration to add the new capabilities. Those can just go in `seeds.sql`.
--
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