What is the use case for a project instead of a tenant?

From a quick glance at the code they appear to be the same except a project can not have child tenants or projects.

Is this strictly to allow there to be administrator level users on a project that can not create sub-projects or is there more to it (or coming)?

@gmccullough can you review this question from @ewannema and forward to a SME if necessary.

As I recall the purpose was to support a tenant that cannot be sub-divided. @gtanzillo or @bascar Should be able to verify and provide details on any future functionality.

Thanks for the reply Greg.

I appreciate the what is happening clarification. I am looking more for a better understanding of the feature to get to a point of understanding why I may want to pick one or the other.

I searched the Github issues trying to find documentation on this feature implementation and design, but I came up empty. Should I be looking somewhere else?

The more I understand why a feature exists and what its intended purpose is, the better decisions I can make on how to architect our implementations. This is incredibly helpful to ensure that I don’t get too creative and implement something in a way that differs from what the ManageIQ team intends.

I know from a prior conversation with @bascar that the way we tried to solve one particular problem in MIQ 5.3 with provisioning scope tags went against what was known internally to the MIQ team to be best practice. I am trying to avoid that as we re-implement for 4.1.

Greg had it correct. The only difference between a project instead of the tenant is that a project cannot be then again split into further sub-tenancy. It is the leaf in the tree.

@bascar Are there any user stories or use cases documented around this feature that we would be able to look at? It seems like @ewannema was unable to find anything.


I think the use case is partly explained by @gmccullough and @bascar: delegation.

You may want to create a sub-tenant and then delegate this sub-tenant organizational management to a group of administrators. They are then able to sub-divide the sub-tenant with sub-tenants (node) or projects (leaf), again maybe allowing groups to manage them.

When you create a project (leaf), you can delegate management while forbidding further subdivision.

Maybe we lack privileges and roles to achieve such a use case. I have not checked whether we can implement it.

@hyclak, @ewannema the thread has really captured off the only real difference in a project and a standard tenant. The “project” tenant type simply has a bit set that it is itself not able to be subdivided and the user story is: As a tenant administrator I should be able to create a sub-tenant that cannot be further sub-divided. That tenant should be of a type called “project”.

Ok, I guess we were thinking there might be something indicating when it made sense to use something like this. In this case, it may be more cut and dried. Is there someplace where these use cases are discussed/documented such that when working on solving a problem, the technical aspects of how to achieve a solution to that problem are clearer? Maybe something Chris Wawak’s team could help out with.

@fdupont Thanks for your response. No future reply needed, but here are the thoughts that lead to my original post.

It seems like this could be accomplished by having the sub-tenant administrator group assigned a role without the ability to create tenants vs. a permanent declaration that “this thing is special in this one way”. I would normally approach something that seems like access control via groups and roles.

As a user, it can be frustrating to figure out how to correctly use the product. Access control in particular seems to be fraught with many options and special cases where things work differently. It feels more like walking around in the dark and hoping not to fall off a cliff than a path that will get us from A-B with options to explore if we care to.