During the Rocky PTG, we reviewed the unified limit API as a group. One of the things that became apparent during the discussion was that the API shouldn't return a list of all limits when updating limits or creating new limits.
Originally, the API was designed this way so that an operator, or user, could double check their work after making a change. Where things get a bit complicated is if you attempt to delegate limit management to other users. For example, say a system administrator creates a new doamin for a customer and sets some limits on that domain. Let's also assume the customer has the ability to create projects within their domain and manage their limits with respect to the limits the system administrator set on the domain. If the customer makes a change to a limit within their domain, they will get a response that contains limit information for all projects, essentially leaking project information to someone who isn't authorized to see that information.
We should change the unified limit API to account for this by not returning a list of all limits on POST and PUT operations. This will be a backwards incompatible change, but we should be able to make it because the API is still marked as experimental.
now unified limits apis support batch create/update, the behavior is (registered limit and project limit are the same) :
POST one or more limits, return all the limits.
PUT one or more limits, return all the limits.
So we should change to:
Only return the limits which are created/updated in the request.
POST one or more limits, return them.
PUT one or more limits, return them.
According to the discussion during PTG, we still have some other concern, here is my opinion:
1. should the unified limits support batch create/update?
yes. for admin operators, they usually want to create/update all the limits for one service or project in one request.
2. should the unified limits contain uuid?
yes. The tuple (service_id, region_id, project_id, resource_name) can indicate a unique limits, it seems that the uuid can be removed. But actually "region_id" for a service can be none, in this case, the url /services/
BTW, Collen pointed out that we can add a new API: PATCH /limits/{limit_id} to update the specified limits is also a good idea.