Comment 3 for bug 1663719

Revision history for this message
Ben Nemec (bnemec) wrote :

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.