Access to disk offerings for different domains

["Vash_X@gmx.de" <Va...@gmx.de>]

Hi,

Overall Usecase:
- we want to provide separate storage pools for different domains
- we want to provide customized disk offerings for each domain which use
the different storage pools and prevent usage of the "shipped" disk
offerings. These shall stay in place for use with SystemVMs /
SystemOfferings

Has anyone a similar usecase or give "best practices" for such a setup?

Nevertheless I am currently looking into the access rights for service
offerings - especially the "shipped" one wich are availeable out of the box.
Therefore for getting a better understanding i am looking for the tables
where a "change" of access settings is stored.
Could anyone point out the tables where these "access rights" are stored?

Regards,
Chris

Re: Access to disk offerings for different domains

["Vash_X@gmx.de" <Va...@gmx.de>]

Hey Daniel,

thanks for so many information. Will take a looki into it - highly
apreciated!

Regards,
Chris

Am Di., 6. Sept. 2022 um 17:17 Uhr schrieb Daniel Augusto Veronezi Salvador
<dv...@gmail.com>:

> Hi Chris,
>
> Regarding your first doubt:
> - while creating disk offerings one can define storage tags to indicate
> in which storage (that matches with the tags) the volume should be
> created. Also, one can define the disk offering as not public and
> dedicate it to a set of domains. This way, the domain will have access
> only to a set of offerings that will direct the volumes to the specific
> storage. Bare in mind that volumes with disk offerings without storage
> tags can be created in any storage, regardless of the storage tags of
> the storage.
> - if you do not want to use the shipped disk offerings, you can remove
> them.
> - system offerings are not affected by the disk offerings you see via UI
> or listing via API. When you create a compute/system offering, they are
> automatically shipped with their own disk offering, which cannot be used
> individually.
>
> About your second doubt:
> - If the offerings are marked as public, they are accessible by anyone
> who can list the offerings. The data is stored in the tables
> "cloud.disk_offering_details" for disk offerings,
> "cloud.service_offering_details" for compute and service offerings, and
> "cloud.network_offering_details" for network offerings. If there are
> entries in these tables ("cloud.disk_offering_details",
> "cloud.service_offering_details", and "cloud.network_offering_details")
> with the name "domainid", it means the offering is dedicated to the
> domains; otherwise, it is public.
> - If you are seeking for permissions to the APIs, they are based on the
> role the user is using. The table storing the role permission is
> "cloud.role_permissions".
>
> Best regards,
> Daniel Salvador
>
> On 05/09/2022 07:32, Vash_X@gmx.de wrote:
> > Hi,
> >
> > Overall Usecase:
> > - we want to provide separate storage pools for different domains
> > - we want to provide customized disk offerings for each domain which use
> > the different storage pools and prevent usage of the "shipped" disk
> > offerings. These shall stay in place for use with SystemVMs /
> > SystemOfferings
> >
> > Has anyone a similar usecase or give "best practices" for such a setup?
> >
> > Nevertheless I am currently looking into the access rights for service
> > offerings - especially the "shipped" one wich are availeable out of the
> box.
> > Therefore for getting a better understanding i am looking for the tables
> > where a "change" of access settings is stored.
> > Could anyone point out the tables where these "access rights" are stored?
> >
> > Regards,
> > Chris
> >
>

Re: Access to disk offerings for different domains

[Daniel Augusto Veronezi Salvador <dv...@gmail.com>]

Hi Chris,

Regarding your first doubt:
- while creating disk offerings one can define storage tags to indicate 
in which storage (that matches with the tags) the volume should be 
created. Also, one can define the disk offering as not public and 
dedicate it to a set of domains. This way, the domain will have access 
only to a set of offerings that will direct the volumes to the specific 
storage. Bare in mind that volumes with disk offerings without storage 
tags can be created in any storage, regardless of the storage tags of 
the storage.
- if you do not want to use the shipped disk offerings, you can remove them.
- system offerings are not affected by the disk offerings you see via UI 
or listing via API. When you create a compute/system offering, they are 
automatically shipped with their own disk offering, which cannot be used 
individually.

About your second doubt:
- If the offerings are marked as public, they are accessible by anyone 
who can list the offerings. The data is stored in the tables 
"cloud.disk_offering_details" for disk offerings, 
"cloud.service_offering_details" for compute and service offerings, and 
"cloud.network_offering_details" for network offerings. If there are 
entries in these tables ("cloud.disk_offering_details", 
"cloud.service_offering_details", and "cloud.network_offering_details") 
with the name "domainid", it means the offering is dedicated to the 
domains; otherwise, it is public.
- If you are seeking for permissions to the APIs, they are based on the 
role the user is using. The table storing the role permission is 
"cloud.role_permissions".

Best regards,
Daniel Salvador

On 05/09/2022 07:32, Vash_X@gmx.de wrote:
> Hi,
>
> Overall Usecase:
> - we want to provide separate storage pools for different domains
> - we want to provide customized disk offerings for each domain which use
> the different storage pools and prevent usage of the "shipped" disk
> offerings. These shall stay in place for use with SystemVMs /
> SystemOfferings
>
> Has anyone a similar usecase or give "best practices" for such a setup?
>
> Nevertheless I am currently looking into the access rights for service
> offerings - especially the "shipped" one wich are availeable out of the box.
> Therefore for getting a better understanding i am looking for the tables
> where a "change" of access settings is stored.
> Could anyone point out the tables where these "access rights" are stored?
>
> Regards,
> Chris
>