Groups contain at least one user

This will be annoying. For one thing, how do you create a group?

The root group contains all other groups and ever user.

I wonder if this is necessary. Why not have multiple root groups possible?

The infrastructure owner is the de facto owner of the workspace because they have the credentials to manipulate said workspace.

I don't understand how this conclusion is justified. Admins in any system can manipulate the objects associated with a nominal owner. Workspaces shouldn't be any different. As well, I'm puzzled the idea that I as an admin could "own" a workspace that was created without my knowledge and used exclusively by someone else.

"Organization" implies a group that has a lot of configuration knobs and its own resource namespace.

Sounds like a root node to me.

There is little configuration and namespacing

Why preclude this now? I understand not wanting to build it now, but saying we'll never want to seems unnecessarily limitiing.

the term "Team" is the best way to describe this kind of lightweight group.

Not... "group?"

I wonder if this is necessary. Why not have multiple root groups possible?

I'm using the root group to mean the "All Users" group. I'm assuming that organizations are one-level descendants of this root group.

I don't understand how this conclusion is justified. Admins in any system can manipulate the objects associated with a nominal owner. Workspaces shouldn't be any different. As well, I'm puzzled the idea that I as an admin could "own" a workspace that was created without my knowledge and used exclusively by someone else.

They have ownership because they need credentials to set up the template that creates the workspaces. If credentials are in the provisioner environment instead of the template, they can still expose the credentials via local exec, so we should just assume they have full control of the provisioner environment.

Why preclude this now? I understand not wanting to build it now, but saying we'll never want to seems unnecessarily limitiing.

I do think we will want to increase the power of groups eventually.

Not... "group?"

Lol, "group" is also good.

I'm assuming that organizations are one-level descendants of this root group.

Is that a necessary assumption?

we should just assume they have full control of the provisioner environment.

Sure, but that doesn't mean they're owners. All my files on my machine are accessible to root, but the owner is not root. Ownership isn't about access. It's about responsibility and authority. The former would defeat the purpose of having an owner concept in pretty much any system with a superuser.

Is that a necessary assumption?

That organizations cannot be nested within another or that there is one root group?

Sure, but that doesn't mean they're owners. All my files on my machine are accessible to root, but the owner is not root. Ownership isn't about access. It's about responsibility and authority. The former would defeat the purpose of having an owner concept in pretty much any system with a superuser.

I think it would be easier to discuss this if we talk about specifics. Here are some things I'm trying to avoid for the sake of the user:

• Having to associate a workspace with an organization during the create flow. This is an additional step, and the workspace is already administratively "bound" to the template, so now there's a double binding that seems excessive for our first shot at the ownership model.
• Giving cost levers to group admins instead of template admins. This is a similar anti-pattern to giving the user cost levers. Since template admins owns the infrastructure, they have the direct incentive to keep down costs and also understand the capabilities of their infrastructure. Groups can also have access to multiple templates, each of which has different resource models that may not map well in the group settings.
  • In v1 we had all of these org levers that would've made more sense in the provider level.

That organizations cannot be nested within another or that there is one root group?

I was referring to the latter, but I guess I'm not sure the former is necessary either.

Having to associate a workspace with an organization during the create flow. This is an additional step, and the workspace is already administratively "bound" to the template, so now there's a double binding that seems excessive for our first shot at the ownership model.

Why do we have to associate a workspace with an organization instead of the user creating it? That seems both unnecessary and unnecessarily rigid.

Giving cost levers to group admins instead of template admins

This seems pretty doable without having to do a non-standard ownership model. A group admin could set policies and quotas for the users and groups in that group, and they could also carve out an exception for anyone in their group using template X.

For instance, I'm admin for group Alpha, and I want to set policies like:

• All users in group Alpha can have two workspaces running at a time
• Members of group Beta, nested in Alpha, can have three workspaces running at a time
• Members of group Gamma, also nested in Alpha, can have only one workspace running at a time
• Members of group Gamma can run a workspace built on template X without it counting against their maximum

This seems pretty doable without having to do a non-standard ownership model.

I meant that template admins should have the lion's share of cost control abilities. E.g, we have max-ttl as template configuration at the moment. Group admins may also be template admins and control costs through their template admin role.

Why do we have to associate a workspace with an organization instead of the user creating it? That seems both unnecessary and unnecessarily rigid.

This is my point, that we should begin with workspaces associated to templates and not organizations so no additional step is required. This flows into the whole concept of template admins controlling costs and groups being lighter weight structures.

I don't believe that template admins will always (or even usually?) be the ones controlling the resource usage of an organization. We certainly shouldn't bake that assumption in.

This sounds like something we need customer input to resolve.

@ammario will be handling this in a future issue!