Okay, I can't figure out what's going on here. My mitaka undercloud has no _member_ role at all. My newton undercloud has a _member_ role, but it's not assigned to the admin user:
[centos@undercloud ~]$ openstack role assignment list --user admin --project admin
+----------------------------------+----------------------------------+----------------------------------+
| Role | User | Project |
+----------------------------------+----------------------------------+----------------------------------+
| 89202a5643a645359281fa395cd88de7 | aa6e698809014827bbd328068682d814 | 1a3b39eccc394ba3ae82caa907fe042c |
+----------------------------------+----------------------------------+----------------------------------+
[centos@undercloud ~]$ openstack role list
+----------------------------------+-----------------+
| ID | Name |
+----------------------------------+-----------------+
| 3cb1fa14c18a47a6bb8ab85f75cb8423 | swiftoperator |
| 89202a5643a645359281fa395cd88de7 | admin |
| 8d26aa45539e4b8bb64b07342b06702d | heat_stack_user |
| 9fe2ff9ee4384b1894a90878d3e92bab | _member_ |
+----------------------------------+-----------------+
Based on the timing, maybe the code was intended to target upgrades from liberty? I'm not even sure how to test that at this point. If it was targeted at an out of support release, is there some way we can reconfigure heat so we don't have to carry this workaround forever? That's basically an unsupportable path forward since it's impossible to test in any reasonable fashion.
Okay, I can't figure out what's going on here. My mitaka undercloud has no _member_ role at all. My newton undercloud has a _member_ role, but it's not assigned to the admin user:
[centos@undercloud ~]$ openstack role assignment list --user admin --project admin ------- ------- ------- ------- +------ ------- ------- ------- ------- +------ ------- ------- ------- ------- + ------- ------- ------- ------- +------ ------- ------- ------- ------- +------ ------- ------- ------- ------- + 59281fa395cd88d e7 | aa6e69880901482 7bbd328068682d8 14 | 1a3b39eccc394ba 3ae82caa907fe04 2c | ------- ------- ------- ------- +------ ------- ------- ------- ------- +------ ------- ------- ------- ------- + ------- ------- ------- ------- +------ ------- ----+ ------- ------- ------- ------- +------ ------- ----+ 6bb8ab85f75cb84 23 | swiftoperator | 59281fa395cd88d e7 | admin | bb64b07342b0670 2d | heat_stack_user | 894a90878d3e92b ab | _member_ | ------- ------- ------- ------- +------ ------- ----+
+------
| Role | User | Project |
+------
| 89202a5643a6453
+------
[centos@undercloud ~]$ openstack role list
+------
| ID | Name |
+------
| 3cb1fa14c18a47a
| 89202a5643a6453
| 8d26aa45539e4b8
| 9fe2ff9ee4384b1
+------
Based on the timing, maybe the code was intended to target upgrades from liberty? I'm not even sure how to test that at this point. If it was targeted at an out of support release, is there some way we can reconfigure heat so we don't have to carry this workaround forever? That's basically an unsupportable path forward since it's impossible to test in any reasonable fashion.