You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cloudstack.apache.org by GitBox <gi...@apache.org> on 2021/08/20 13:06:09 UTC

[GitHub] [cloudstack] GabrielBrascher commented on pull request #4200: Allow domain admins to create offering without mentioning domainid

GabrielBrascher commented on pull request #4200:
URL: https://github.com/apache/cloudstack/pull/4200#issuecomment-902679167


   I would be "-1" only in the case of a domain admin creating public offerings when the domain ID is NULL. However, this has been already checked and that's not the case here.
   
   My main concern right now is with the API description that would need some updates in [createServiceOffering](https://cloudstack.apache.org/api/apidocs-4.15/apis/createServiceOffering.html). Right now it gives the idea of creating public offerings:
   ```
   Parameter: domainid
   Description: the ID of the containing domain(s), null for public offerings
   Required: false
   ```
   
   With that said, I do not see risks with this PR. Domains admins create offerings to:
   **A.** their domain (not public)
   **B.** their subdomains (it still not public)
   
   The proposal would be to allow creating offerings on **A** by default. In the case of **B** then the domain admin would specify the domain ID.
   
   It is not like the domain admin will create offerings outside its domain scope nor a public offering that other users can access.
   In the worst-case, an ADMIN by mistake creates an offering to its domain, instead of to a specific subdomain. In my opinion, this does not bring great risks that would justify **-1**.
   
   As @weizhouapache mentioned, shared network _acltype_ and _domain/account_ are not required. So far I have never seen any issue in a CloudStack zone due to such liberty given to Admins, for example, the one raised by @weizhouapache. On the other hand, I've seen numerous cases where Admins complain about too many restrictions.
   
   I see that global settings might be an approach, but personally, I prefer to avoid global settings as much as possible.
   We might go in a direction of multiple easter eggs hidden in the global settings where users will touch and understand just the 'tip of the iceberg'.
   


-- 
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.

To unsubscribe, e-mail: commits-unsubscribe@cloudstack.apache.org

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