I think this is primarily a documentation issue. If you can’t access the expected tenants from a given EMS, it means the OpenStack user associated with the EMS isn’t configured properly. In addition to documenting this, we need to be able to test and verify the behavior. In order to better accomplish this, I think our test/dev environments need to be configured to have more variation in regard to tenants and users.
To start the discussion, I’m going to take an initial swag at defining what the environment should look like. Once we’re satisfied with the definition, we can discuss any issues surrounding its implementation.
Our current environments have too few tenants, and we tend to use the
admin tenant by default. I don’t think we should ever use the
admin tenant for testing or development, except for rare cases (ytbd) where it’s absolutely necessary. Instead, I think we should use tenants that are defined for specific purposes.
test tenants for use by the spec tests.
- One or more
dev tenants for use by developers for experimentation and discovery purposes.
- One or more
demo tenants, used to host demonstration environments as needed.
Isolating sub-environments by tenant should eliminate cross-environment impact. For example, changes made to the
demo environments should have no impact on the spec tests, which will only use the
Users define the view into the environments, since they determine which tenants can be accessed, and by whom. As with the ‘admin’ tenant, we tend to use the
admin user by default as well. Here to, I think direct use of the
admin user should be rare. Instead, each sub-environment should have users defined specifically to access the environment in question. For example,
test_admin would be a user with admin privileges, that only has access to the
In order to test and verify tenant-specific behavior, I think our test environments should have a minimum of two users and four tenants. For example:
testa_admin will have access to
testb_admin will have access to
To test overlapping views, we may also define:
test_admin that can access testa_tenant1
that can be accessed by bothtesta_admin
We may also want to define associated non-admin users:
##Dev and Demo environments
These environments don’t need to be as strictly defines as the test environment, but they should be defined such that they are isolated from the test environment, and from each other.