It seems that we forgot to add MAC Pool related permissions to ClusterAdmin role when we moved MAC Pools from DC to cluster. Martin, could you please take a look?

notes: 
CLUSTER_ADMIN role missed action group named CONFIGURE_MAC_POOL. Supplied patch fixes it. 

However DATA_CENTER_ADMIN role does have this action group, so iiuc original report, and CLUSTER_ADMIN should imply DATA_CENTER_ADMIN role, then there is something not just.

after fix DATA_CENTER_ADMIN and CLUSTER_ADMIN are able to create cluster. Even before change DATA_CENTER_ADMIN should be able to create cluster (I did not test this one), same for super_user (which I did test, and which works even before change).

So. action group named configure_mac_pool added only to cluster admin role. Is there any other role which should have it?

I suspect this is a regression due to our per-cluster macpool feature.

This bug report has Keywords: Regression or TestBlocker.
Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP.

I have ovirt-engine-4.1.2-0.1.el7.noarch and I guess this fix missed the release:

2017-05-03 17:39:37,464+03 INFO  [org.ovirt.engine.core.bll.AddClusterCommand] (default task-17) [ffc00066-7bff-4319-ad02-a25fa99eac3a] No permission found for user '20e77d71-753d-4a96-8bea-07ff8764358a' or one of the groups he is member of, when running action 'AddCluster', Required permissions are: Action type: 'ADMIN' Action group: 'CONFIGURE_MAC_POOL' Object type: 'MAC Pool' 

https://engine/ovirt-engine/api/users/20e77d71-753d-4a96-8bea-07ff8764358a/permissions :

...
<permission href="/ovirt-engine/api/users/20e77d71-753d-4a96-8bea-07ff8764358a/permissions/df7d1fea-8288-4bb0-b5ff-917275307857" id="df7d1fea-8288-4bb0-b5ff-917275307857">
  <data_center href="/ovirt-engine/api/datacenters/fa1e0b4c-1aa4-4bd9-99d1-c07acd6cfa19" id="fa1e0b4c-1aa4-4bd9-99d1-c07acd6cfa19"/>
  <role href="/ovirt-engine/api/roles/def00001-0000-0000-0000-def000000001" id="def00001-0000-0000-0000-def000000001"/>
  <user href="/ovirt-engine/api/users/20e77d71-753d-4a96-8bea-07ff8764358a" id="20e77d71-753d-4a96-8bea-07ff8764358a"/>
</permission>
...

https://engine/ovirt-engine/api/roles/def00001-0000-0000-0000-def000000001 :

<role href="/ovirt-engine/api/roles/def00001-0000-0000-0000-def000000001" id="def00001-0000-0000-0000-def000000001">
  <name>ClusterAdmin</name>
  <description>
    Administrator Role, permission for all the objects underneath a specific Cluster
  </description>
  <link href="/ovirt-engine/api/roles/def00001-0000-0000-0000-def000000001/permits" rel="permits"/>
  <administrative>true</administrative>
  <mutable>false</mutable>
</role>

https://engine/ovirt-engine/api/datacenters/fa1e0b4c-1aa4-4bd9-99d1-c07acd6cfa19/permissions :

...
<permission href="/ovirt-engine/api/users/20e77d71-753d-4a96-8bea-07ff8764358a/permissions/9896d966-1890-4341-9bee-7b2003d54d57" id="9896d966-1890-4341-9bee-7b2003d54d57">
  <data_center href="/ovirt-engine/api/datacenters/fa1e0b4c-1aa4-4bd9-99d1-c07acd6cfa19" id="fa1e0b4c-1aa4-4bd9-99d1-c07acd6cfa19"/>
  <role href="/ovirt-engine/api/roles/def00001-0000-0000-0000-def000000001" id="def00001-0000-0000-0000-def000000001"/>
  <user href="/ovirt-engine/api/users/20e77d71-753d-4a96-8bea-07ff8764358a" id="20e77d71-753d-4a96-8bea-07ff8764358a"/>
</permission>
...

https://engine/ovirt-engine/api/roles/def00001-0000-0000-0000-def000000001/permits :

...
<permit href="/ovirt-engine/api/roles/def00001-0000-0000-0000-def000000001/permits/1663" id="1663">
  <name>configure_mac_pool</name>
  <administrative>true</administrative>
  <role href="/ovirt-engine/api/roles/def00001-0000-0000-0000-def000000001" id="def00001-0000-0000-0000-def000000001"/>
</permit>
...

Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.

branch 4.1.2 does not exist. I have no idea, how to verify whether this patch is in version Aleksei Slaikovskii tested, or how to get it there.

please specify, what action is needed.

Why are you relaying this question to me, Martin?

Aleksey, can you specify the ENGINE_CUTOFF of ovirt-engine-4.1.2-0.1.el7.noarch which you have tested?

(In reply to Dan Kenigsberg from comment #9)
> Why are you relaying this question to me, Martin?
> 
> Aleksey, can you specify the ENGINE_CUTOFF of
> ovirt-engine-4.1.2-0.1.el7.noarch which you have tested?

ENGINE_CUTOFF: 22683aa7b1906bee05807596cd55bd11a64bd893

git co 22683aa7b1906bee05807596cd55bd11a64bd893
HEAD is now at 22683aa... build: ovirt-engine-4.1.2.1

cat /home/mmucha/projects/ovirt-engine/packaging/dbscripts/upgrade/04_01_0780_add_configure_mac_pool_role_to_data_center_admin.sql
select fn_db_add_action_group_to_role('DEF00001-0000-0000-0000-DEF000000001', 1663);


ie. patch was backported to this version.

(In reply to Martin Mucha from comment #11)
> git co 22683aa7b1906bee05807596cd55bd11a64bd893
> HEAD is now at 22683aa... build: ovirt-engine-4.1.2.1
> 
> cat
> /home/mmucha/projects/ovirt-engine/packaging/dbscripts/upgrade/
> 04_01_0780_add_configure_mac_pool_role_to_data_center_admin.sql
> select
> fn_db_add_action_group_to_role('DEF00001-0000-0000-0000-DEF000000001', 1663);
> 
> 
> ie. patch was backported to this version.

I've updated engine to ovirt-engine-4.1.2.1-0.1.el7.noarch which has cutoff above but still it doesn't work.

As agreed, this won't block 4.1.2 release and will be included in 4.1.3

a) tested engine seemed to miss content of upgrade script: 04_01_0780_add_configure_mac_pool_role_to_data_center_admin.sql
even if it was in db marked as applied. That was fixed.

b) thanks to help of tjelinek was discovered, that this bug is present, if cluster admin is defined on specific cluster and not whole system. If we move this role from cluster to system level, it works.

IIRC mac pools are top level entity, and is not beneath DC/cluster or whatever, maybe this is causing issue, but I don't know how to express, that clusterAdmin for whichever cluster has also 'system' permission to CONFIGURE_MAC_POOL.

Arik, can you advise?

I think this should be done in a similar way as for example the 	
CpuProfileOperator.

So, I think you should create a new role: MacPoolOperator which will have the CONFIGURE_MAC_POOL permission and assign this role to everyone on the system. 

@Ravi, what you think?

Martin's fix is included in the specified version. I think we have another problem.

The permissions a user needs for adding cluster to a dc are:
1. 'ActionGroup.CREATE_CLUSTER' on the dc
2. 'ActionGroup.CONFIGURE_MAC_POOL' on the selected mac pool.

Regarding 1-
Looking at the rest api outputs in #comment 6, I see that the the user has 'ClusterAdmin' role on the dc.

I don't see it in the outputs, but. 'ClusterAdmin' role should contain 'ActionGroup.CREATE_CLUSTER'. So I guess the problem is not here.

(Please attach the full output of 'https://engine/ovirt-engine/api/roles/def00001-0000-0000-0000-def000000001/permits' to be sure).

Regarding 2-
Does the mac-pool you select for the newly created cluster has a role that supports 'ActionGroup.CONFIGURE_MAC_POOL'?
The predefined roles which support 'ActionGroup.CONFIGURE_MAC_POOL' are - "SuperUser"
"ClusterAdmin"
"DataCenterAdmin"
"MacPoolAdmin"
"MacPoolUser"

Do your mac pool contain any of those?
(You can see it via the ui - Configure => mac address pool=> select the mac pool => you will see its permissions).
Unfortunately, I couldn't find a good way to check it via the rest.

Created attachment 1277601 [details]
https://engine/ovirt-engine/api/roles/def00001-0000-0000-0000-def000000001/permits

1. I've added attachment with XML.
2. I can see admin (SuperUser) and Everyone (UserProfileEditor) in pool's permissions.

ok. So that's the problem. The pool you're assigning to the cluster should have one of the following roles - "ClusterAdmin", "DataCenterAdmin", "MacPoolAdmin",
"MacPoolUser" for the user.
Martin gave me the credentials to your environment. I logged in to it and added "MacPoolUser" role to the default mac pool (for 'user1').
(Did is as admin).
Then logged in as 'user1' and managed to add the cluster.

In my opinion, it is not a bug. I would close it as not a bug.

(In reply to Alona Kaplan from comment #18)
> ok. So that's the problem. The pool you're assigning to the cluster should
> have one of the following roles - "ClusterAdmin", "DataCenterAdmin",
> "MacPoolAdmin",
> "MacPoolUser" for the user.
> Martin gave me the credentials to your environment. I logged in to it and
> added "MacPoolUser" role to the default mac pool (for 'user1').
> (Did is as admin).
> Then logged in as 'user1' and managed to add the cluster.
> 
> In my opinion, it is not a bug. I would close it as not a bug.

Am I understand it right, that in 4.0 it was enough to be ClusterAdmin on specific cluster, but after upgrade to 4.1 all those users will be also required to be at least MacPoolUser for the pool assigned to the cluster? So isn't it a regression from 4.0? Shouldn't everybody have read access to the mac pool by default?

Not an expert in this feature, so I have a question. Can a mac pool be shared between clusters? If not, I'd remove the requirement to have the configure_mac_pool action group when creating clusters. The first one who uses the mac pool, gets it. How often would that he an issue? I guess never. Again, that assumes we really can't share mac pools between clusters. If we can then perhaps you'd want to limit that.

(In reply to Oved Ourfali from comment #20)
> Not an expert in this feature, so I have a question. Can a mac pool be
> shared between clusters? If not, I'd remove the requirement to have the
> configure_mac_pool action group when creating clusters. The first one who
> uses the mac pool, gets it. How often would that he an issue? I guess never.
> Again, that assumes we really can't share mac pools between clusters. If we
> can then perhaps you'd want to limit that.

MacPool is a system level entity. It can be shared between clusters (even clusters from different data centers).

(In reply to Martin Perina from comment #19)
> (In reply to Alona Kaplan from comment #18)
> > ok. So that's the problem. The pool you're assigning to the cluster should
> > have one of the following roles - "ClusterAdmin", "DataCenterAdmin",
> > "MacPoolAdmin",
> > "MacPoolUser" for the user.
> > Martin gave me the credentials to your environment. I logged in to it and
> > added "MacPoolUser" role to the default mac pool (for 'user1').
> > (Did is as admin).
> > Then logged in as 'user1' and managed to add the cluster.
> > 
> > In my opinion, it is not a bug. I would close it as not a bug.
> 
> Am I understand it right, that in 4.0 it was enough to be ClusterAdmin on
> specific cluster, but after upgrade to 4.1 all those users will be also
> required to be at least MacPoolUser for the pool assigned to the cluster? So
> isn't it a regression from 4.0? Shouldn't everybody have read access to the
> mac pool by default?

In 4.0, each data center could choose only one mac pool. All the clusters in the dc used only this pool. The desired mac pool was chosen when adding/editing a data center. Therefore, for adding/editing a dc, the users needed to have ActionGroup.CONFIGURE_MAC_POOL permissions on the chosen mac pool.

Since 4.1, each cluster can have its own mac pool. The user chooses the desired pool for the cluster when adding/updating the cluster. Therefore, the permission for using the mac pool (ActionGroup.CONFIGURE_MAC_POOL) that previously was needed for adding/modifying the dc, now needed for adding/modifying the cluster.

It is not a regression, just a planned change in the functionality.

BTW, ActionGroup.CONFIGURE_MAC_POOL is not a read only permission. It is permission to acquire macs from the pool.

Please reopen if granting the use ActionGroup.CONFIGURE_MAC_POOL on his mac pool does not solve the issue for you.

Thanks guys!

But I have another question. GlusterAdmin role has create_cluster permit but doesn't have configure_mac_pool. Is it related to this bug or I should open new one?

If you believe that GlusterAdmin should have configure_mac_pool, please explain why in a fresh bug.