Greg Blomquist, Ohad, Amos, Bryan, and myself had a call this morning to review the work that's been done over the past week on adding support for organizations to Foreman. We spoke about some architectural changes and just want to gather some feedback from all of you.
First, instead of only implementing organizations, we are going to introduce two new objects (via single table inheritance); organizations and locations. Organizations are the parent objects of locations, so you can have an organization with several locations and share some of the same base attributes. We decided that these two separate objects are needed because the use cases for each of them is unique enough that it's important to be able to extend them individually going forward. Greg points out that the relationship between locations and organizations should be many-to-many; a business unit (tenant) can have many locations. For example: "Acme is a global company. It has a presence in APAC and NA. It has marketing, sales, and finance business units. Marketing exists in both APAC and NA." (Greg's exact words :)) If you don't need organizations or locations, then you don't have to use them; this is the same way that hostgroups work right now.
Another important aspect of the org work is nesting. The plan for nesting is to allow nested locations, but not nested organizations. If you have an organization with several datacenters, each with a couple of racks, the case for nested locations becomes more clear. We didn't talk about how permissions will work for locations yet, but I assume they will essentially be an extension of the organization-based permissions with more specific ACL's; there is more work to do to properly hammer out how permissions will be dealt with. Olivier's plan for permissions comes into play here; let's see how we can get that implemented as part of the org work. Again, Greg's words: "Best of all, it feels more like a bolt-on permissions scheme, instead of a baked in permissions scheme."
Would love to hear your thoughts on this.
-Sam
> Greg Blomquist, Ohad, Amos, Bryan, and myself had a call this morning to review the work that's been done over the past week on adding support for organizations to Foreman. We spoke about some architectural changes and just want to gather some feedback from all of you.
>
> First, instead of only implementing organizations, we are going to introduce two new objects (via single table inheritance); organizations and locations. Organizations are the parent objects of locations, so you can have an organization with several locations and share some of the same base attributes. We decided that these two separate objects are needed because the use cases for each of them is unique enough that it's important to be able to extend them individually going forward. Greg points out that the relationship between locations and organizations should be many-to-many; a business unit (tenant) can have many locations. For example: "Acme is a global company. It has a presence in APAC and NA. It has marketing, sales, and finance business units. Marketing exists in both APAC and NA." (Greg's exact words :)) If you don't need organizations or locations, then you don't have to use them; this is the same way that hostgroups work right now.
>
> Another important aspect of the org work is nesting. The plan for nesting is to allow nested locations, but not nested organizations. If you have an organization with several datacenters, each with a couple of racks, the case for nested locations becomes more clear. We didn't talk about how permissions will work for locations yet, but I assume they will essentially be an extension of the organization-based permissions with more specific ACL's; there is more work to do to properly hammer out how permissions will be dealt with. Olivier's plan for permissions comes into play here; let's see how we can get that implemented as part of the org work. Again, Greg's words: "Best of all, it feels more like a bolt-on permissions scheme, instead of a baked in permissions scheme."
>
> Would love to hear your thoughts on this.
Thanks Sam. Can you please share the team's thoughts on how these will
interact with hostgroups, user groups, filters, and roles? (You are
also familiar with my thoughts on usergroup based permissions and
resource groups, so some elaboration there would be useful too.) You
also reference that locations may be an extension of the organizations
permissions model without elaborating what the organizations
permissions model/ACLs will look like. (IE: Can you explain Olivier's
plan for permissions?)
Thanks,
Brian
···
On Tue, Aug 7, 2012 at 2:57 PM, Sam Kottler wrote:
-Sam
Olivier posted in the last thread about organizations
(https://groups.google.com/d/topic/foreman-dev/6ZpqH3OiHTs/discussion).
Ohad points out in that thread (and has also done so more recently) that
providing defaults via nested hostgroups prevents hostgroups from being
used in a more powerful manner as a way to describe the resources
available and required to deploy and maintain an application. See
Organization-Groups-Design - Foreman
for more information on this. Ohad can probably explain the plan for
hostgroups better than I can 
We've kicked the ACL/role discussion down the road for now, but it's
certainly going to be very important once the initial work on locations
& orgs is done. TBH, I haven't thought too much about it beyond that
first thread about organizations and the discussions that stemmed from
it. Of course, each additional class makes the permissions scheme orders
of magnitude (O(n^2)) more complex so we will need to figure this out.
Bryan also mentioned the need for hierarchical permissions inside of
organizations. This will also need to happen in locations since there
are tons of different scenarios in which someone will need to manage a
certain subset of hosts that are denoted by location. Olivier's plan and
the aforementioned considerations will need to be written out into
something actionable. I'll expand Ohad's permissions scheme in the wiki
page above this week with an initial proposal.
···
On 08/07/2012 03:28 PM, Brian Gupta wrote:
> On Tue, Aug 7, 2012 at 2:57 PM, Sam Kottler wrote:
>> Greg Blomquist, Ohad, Amos, Bryan, and myself had a call this morning to review the work that's been done over the past week on adding support for organizations to Foreman. We spoke about some architectural changes and just want to gather some feedback from all of you.
>>
>> First, instead of only implementing organizations, we are going to introduce two new objects (via single table inheritance); organizations and locations. Organizations are the parent objects of locations, so you can have an organization with several locations and share some of the same base attributes. We decided that these two separate objects are needed because the use cases for each of them is unique enough that it's important to be able to extend them individually going forward. Greg points out that the relationship between locations and organizations should be many-to-many; a business unit (tenant) can have many locations. For example: "Acme is a global company. It has a presence in APAC and NA. It has marketing, sales, and finance business units. Marketing exists in both APAC and NA." (Greg's exact words :)) If you don't need organizations or locations, then you don't have to use them; this is the same way that hostgroups work right now.
>>
>> Another important aspect of the org work is nesting. The plan for nesting is to allow nested locations, but not nested organizations. If you have an organization with several datacenters, each with a couple of racks, the case for nested locations becomes more clear. We didn't talk about how permissions will work for locations yet, but I assume they will essentially be an extension of the organization-based permissions with more specific ACL's; there is more work to do to properly hammer out how permissions will be dealt with. Olivier's plan for permissions comes into play here; let's see how we can get that implemented as part of the org work. Again, Greg's words: "Best of all, it feels more like a bolt-on permissions scheme, instead of a baked in permissions scheme."
>>
>> Would love to hear your thoughts on this.
> Thanks Sam. Can you please share the team's thoughts on how these will
> interact with hostgroups, user groups, filters, and roles? (You are
> also familiar with my thoughts on usergroup based permissions and
> resource groups, so some elaboration there would be useful too.) You
> also reference that locations may be an extension of the organizations
> permissions model without elaborating what the organizations
> permissions model/ACLs will look like. (IE: Can you explain Olivier's
> plan for permissions?)
>
> Thanks,
> Brian
>
>> -Sam
>>
>>
So, looking back at Olivier's proposal, and Ohad's wiki, leads me to
believe that we are on a very similar thinking, it's just naming
that's different… IE: what I want to call a "resource group", Olivier
refers to as an "entity", and in current discussion, we are calling
"Organizations" or "locations"? Wondering if it makes sense to make
these a generic class, and have a "resource group"/"entity" with
subclasses "location" and "organization"? (My sense is location and
organzition are basically going to be used identically, with maybe
some slightly different metadata, and scoping rules.)
Thanks,
Brian
P.S. - We can discuss offline more tomorrow, if it's easier.
···
On Tue, Aug 7, 2012 at 4:25 PM, Sam Kottler wrote:
> On 08/07/2012 03:28 PM, Brian Gupta wrote:
>
> On Tue, Aug 7, 2012 at 2:57 PM, Sam Kottler wrote:
>
> Greg Blomquist, Ohad, Amos, Bryan, and myself had a call this morning to
> review the work that's been done over the past week on adding support for
> organizations to Foreman. We spoke about some architectural changes and just
> want to gather some feedback from all of you.
>
> First, instead of only implementing organizations, we are going to introduce
> two new objects (via single table inheritance); organizations and locations.
> Organizations are the parent objects of locations, so you can have an
> organization with several locations and share some of the same base
> attributes. We decided that these two separate objects are needed because
> the use cases for each of them is unique enough that it's important to be
> able to extend them individually going forward. Greg points out that the
> relationship between locations and organizations should be many-to-many; a
> business unit (tenant) can have many locations. For example: "Acme is a
> global company. It has a presence in APAC and NA. It has marketing, sales,
> and finance business units. Marketing exists in both APAC and NA." (Greg's
> exact words :)) If you don't need organizations or locations, then you don't
> have to use them; this is the same way that hostgroups work right now.
>
> Another important aspect of the org work is nesting. The plan for nesting is
> to allow nested locations, but not nested organizations. If you have an
> organization with several datacenters, each with a couple of racks, the case
> for nested locations becomes more clear. We didn't talk about how
> permissions will work for locations yet, but I assume they will essentially
> be an extension of the organization-based permissions with more specific
> ACL's; there is more work to do to properly hammer out how permissions will
> be dealt with. Olivier's plan for permissions comes into play here; let's
> see how we can get that implemented as part of the org work. Again, Greg's
> words: "Best of all, it feels more like a bolt-on permissions scheme,
> instead of a baked in permissions scheme."
>
> Would love to hear your thoughts on this.
>
> Thanks Sam. Can you please share the team's thoughts on how these will
> interact with hostgroups, user groups, filters, and roles? (You are
> also familiar with my thoughts on usergroup based permissions and
> resource groups, so some elaboration there would be useful too.) You
> also reference that locations may be an extension of the organizations
> permissions model without elaborating what the organizations
> permissions model/ACLs will look like. (IE: Can you explain Olivier's
> plan for permissions?)
>
> Thanks,
> Brian
>
> -Sam
>
>
> Olivier posted in the last thread about organizations
> (https://groups.google.com/d/topic/foreman-dev/6ZpqH3OiHTs/discussion). Ohad
> points out in that thread (and has also done so more recently) that
> providing defaults via nested hostgroups prevents hostgroups from being used
> in a more powerful manner as a way to describe the resources available and
> required to deploy and maintain an application. See
> http://theforeman.org/projects/foreman/wiki/Organization-Groups-Design for
> more information on this. Ohad can probably explain the plan for hostgroups
> better than I can ;)
>
> We've kicked the ACL/role discussion down the road for now, but it's
> certainly going to be very important once the initial work on locations &
> orgs is done. TBH, I haven't thought too much about it beyond that first
> thread about organizations and the discussions that stemmed from it. Of
> course, each additional class makes the permissions scheme orders of
> magnitude (O(n^2)) more complex so we will need to figure this out. Bryan
> also mentioned the need for hierarchical permissions inside of
> organizations. This will also need to happen in locations since there are
> tons of different scenarios in which someone will need to manage a certain
> subset of hosts that are denoted by location. Olivier's plan and the
> aforementioned considerations will need to be written out into something
> actionable. I'll expand Ohad's permissions scheme in the wiki page above
> this week with an initial proposal.
Exactly the plan. We will use single table inheritance to manage both
"resource groups/organizations" and "locations" in the same table using
a "type" column 
···
On 08/07/2012 05:00 PM, Brian Gupta wrote:
> On Tue, Aug 7, 2012 at 4:25 PM, Sam Kottler wrote:
>> On 08/07/2012 03:28 PM, Brian Gupta wrote:
>>
>> On Tue, Aug 7, 2012 at 2:57 PM, Sam Kottler wrote:
>>
>> Greg Blomquist, Ohad, Amos, Bryan, and myself had a call this morning to
>> review the work that's been done over the past week on adding support for
>> organizations to Foreman. We spoke about some architectural changes and just
>> want to gather some feedback from all of you.
>>
>> First, instead of only implementing organizations, we are going to introduce
>> two new objects (via single table inheritance); organizations and locations.
>> Organizations are the parent objects of locations, so you can have an
>> organization with several locations and share some of the same base
>> attributes. We decided that these two separate objects are needed because
>> the use cases for each of them is unique enough that it's important to be
>> able to extend them individually going forward. Greg points out that the
>> relationship between locations and organizations should be many-to-many; a
>> business unit (tenant) can have many locations. For example: "Acme is a
>> global company. It has a presence in APAC and NA. It has marketing, sales,
>> and finance business units. Marketing exists in both APAC and NA." (Greg's
>> exact words :)) If you don't need organizations or locations, then you don't
>> have to use them; this is the same way that hostgroups work right now.
>>
>> Another important aspect of the org work is nesting. The plan for nesting is
>> to allow nested locations, but not nested organizations. If you have an
>> organization with several datacenters, each with a couple of racks, the case
>> for nested locations becomes more clear. We didn't talk about how
>> permissions will work for locations yet, but I assume they will essentially
>> be an extension of the organization-based permissions with more specific
>> ACL's; there is more work to do to properly hammer out how permissions will
>> be dealt with. Olivier's plan for permissions comes into play here; let's
>> see how we can get that implemented as part of the org work. Again, Greg's
>> words: "Best of all, it feels more like a bolt-on permissions scheme,
>> instead of a baked in permissions scheme."
>>
>> Would love to hear your thoughts on this.
>>
>> Thanks Sam. Can you please share the team's thoughts on how these will
>> interact with hostgroups, user groups, filters, and roles? (You are
>> also familiar with my thoughts on usergroup based permissions and
>> resource groups, so some elaboration there would be useful too.) You
>> also reference that locations may be an extension of the organizations
>> permissions model without elaborating what the organizations
>> permissions model/ACLs will look like. (IE: Can you explain Olivier's
>> plan for permissions?)
>>
>> Thanks,
>> Brian
>>
>> -Sam
>>
>>
>> Olivier posted in the last thread about organizations
>> (https://groups.google.com/d/topic/foreman-dev/6ZpqH3OiHTs/discussion). Ohad
>> points out in that thread (and has also done so more recently) that
>> providing defaults via nested hostgroups prevents hostgroups from being used
>> in a more powerful manner as a way to describe the resources available and
>> required to deploy and maintain an application. See
>> http://theforeman.org/projects/foreman/wiki/Organization-Groups-Design for
>> more information on this. Ohad can probably explain the plan for hostgroups
>> better than I can ;)
>>
>> We've kicked the ACL/role discussion down the road for now, but it's
>> certainly going to be very important once the initial work on locations &
>> orgs is done. TBH, I haven't thought too much about it beyond that first
>> thread about organizations and the discussions that stemmed from it. Of
>> course, each additional class makes the permissions scheme orders of
>> magnitude (O(n^2)) more complex so we will need to figure this out. Bryan
>> also mentioned the need for hierarchical permissions inside of
>> organizations. This will also need to happen in locations since there are
>> tons of different scenarios in which someone will need to manage a certain
>> subset of hosts that are denoted by location. Olivier's plan and the
>> aforementioned considerations will need to be written out into something
>> actionable. I'll expand Ohad's permissions scheme in the wiki page above
>> this week with an initial proposal.
> So, looking back at Olivier's proposal, and Ohad's wiki, leads me to
> believe that we are on a very similar thinking, it's just naming
> that's different.. IE: what I want to call a "resource group", Olivier
> refers to as an "entity", and in current discussion, we are calling
> "Organizations" or "locations"? Wondering if it makes sense to make
> these a generic class, and have a "resource group"/"entity" with
> subclasses "location" and "organization"? (My sense is location and
> organzition are basically going to be used identically, with maybe
> some slightly different metadata, and scoping rules.)
>
> Thanks,
> Brian
>
> P.S. - We can discuss offline more tomorrow, if it's easier.
For me, the main difference in the types is what they are modeling:
Orgs would model tenants in foreman, or business units in a company. I
think of these as hierarchical. This would probably link to ACLs, and
represent groups of systems based on budget.
Locations model where systems are. They are also hierarchical, but that
hierarchy is a peer to the org hierarchy.
I would expect to say things such as:
A system is owned by one org.
A system is deployed in one location.
An org is allowed to deploy to certain locations.
– bk
···
On 08/07/2012 05:19 PM, Sam Kottler wrote:
> On 08/07/2012 05:00 PM, Brian Gupta wrote:
>> On Tue, Aug 7, 2012 at 4:25 PM, Sam Kottler wrote:
>>> On 08/07/2012 03:28 PM, Brian Gupta wrote:
>>>
>>> On Tue, Aug 7, 2012 at 2:57 PM, Sam Kottler wrote:
>>>
>>> Greg Blomquist, Ohad, Amos, Bryan, and myself had a call this morning to
>>> review the work that's been done over the past week on adding support for
>>> organizations to Foreman. We spoke about some architectural changes and just
>>> want to gather some feedback from all of you.
>>>
>>> First, instead of only implementing organizations, we are going to introduce
>>> two new objects (via single table inheritance); organizations and locations.
>>> Organizations are the parent objects of locations, so you can have an
>>> organization with several locations and share some of the same base
>>> attributes. We decided that these two separate objects are needed because
>>> the use cases for each of them is unique enough that it's important to be
>>> able to extend them individually going forward. Greg points out that the
>>> relationship between locations and organizations should be many-to-many; a
>>> business unit (tenant) can have many locations. For example: "Acme is a
>>> global company. It has a presence in APAC and NA. It has marketing, sales,
>>> and finance business units. Marketing exists in both APAC and NA." (Greg's
>>> exact words :)) If you don't need organizations or locations, then you don't
>>> have to use them; this is the same way that hostgroups work right now.
>>>
>>> Another important aspect of the org work is nesting. The plan for nesting is
>>> to allow nested locations, but not nested organizations. If you have an
>>> organization with several datacenters, each with a couple of racks, the case
>>> for nested locations becomes more clear. We didn't talk about how
>>> permissions will work for locations yet, but I assume they will essentially
>>> be an extension of the organization-based permissions with more specific
>>> ACL's; there is more work to do to properly hammer out how permissions will
>>> be dealt with. Olivier's plan for permissions comes into play here; let's
>>> see how we can get that implemented as part of the org work. Again, Greg's
>>> words: "Best of all, it feels more like a bolt-on permissions scheme,
>>> instead of a baked in permissions scheme."
>>>
>>> Would love to hear your thoughts on this.
>>>
>>> Thanks Sam. Can you please share the team's thoughts on how these will
>>> interact with hostgroups, user groups, filters, and roles? (You are
>>> also familiar with my thoughts on usergroup based permissions and
>>> resource groups, so some elaboration there would be useful too.) You
>>> also reference that locations may be an extension of the organizations
>>> permissions model without elaborating what the organizations
>>> permissions model/ACLs will look like. (IE: Can you explain Olivier's
>>> plan for permissions?)
>>>
>>> Thanks,
>>> Brian
>>>
>>> -Sam
>>>
>>>
>>> Olivier posted in the last thread about organizations
>>> (https://groups.google.com/d/topic/foreman-dev/6ZpqH3OiHTs/discussion). Ohad
>>> points out in that thread (and has also done so more recently) that
>>> providing defaults via nested hostgroups prevents hostgroups from being used
>>> in a more powerful manner as a way to describe the resources available and
>>> required to deploy and maintain an application. See
>>> http://theforeman.org/projects/foreman/wiki/Organization-Groups-Design for
>>> more information on this. Ohad can probably explain the plan for hostgroups
>>> better than I can ;)
>>>
>>> We've kicked the ACL/role discussion down the road for now, but it's
>>> certainly going to be very important once the initial work on locations &
>>> orgs is done. TBH, I haven't thought too much about it beyond that first
>>> thread about organizations and the discussions that stemmed from it. Of
>>> course, each additional class makes the permissions scheme orders of
>>> magnitude (O(n^2)) more complex so we will need to figure this out. Bryan
>>> also mentioned the need for hierarchical permissions inside of
>>> organizations. This will also need to happen in locations since there are
>>> tons of different scenarios in which someone will need to manage a certain
>>> subset of hosts that are denoted by location. Olivier's plan and the
>>> aforementioned considerations will need to be written out into something
>>> actionable. I'll expand Ohad's permissions scheme in the wiki page above
>>> this week with an initial proposal.
>> So, looking back at Olivier's proposal, and Ohad's wiki, leads me to
>> believe that we are on a very similar thinking, it's just naming
>> that's different.. IE: what I want to call a "resource group", Olivier
>> refers to as an "entity", and in current discussion, we are calling
>> "Organizations" or "locations"? Wondering if it makes sense to make
>> these a generic class, and have a "resource group"/"entity" with
>> subclasses "location" and "organization"? (My sense is location and
>> organzition are basically going to be used identically, with maybe
>> some slightly different metadata, and scoping rules.)
>>
>> Thanks,
>> Brian
>>
>> P.S. - We can discuss offline more tomorrow, if it's easier.
> Exactly the plan. We will use single table inheritance to manage both
> "resource groups/organizations" and "locations" in the same table using
> a "type" column :)
>
+1 on that. I was looking at how we use our virtualization hosts this
afternoon, and thinking pretty much the same thing. I would grant an
Org (say, another department) access to a Location (say, a libvirt
host) with appropriate permissions.
Greg
···
On Wed 08 Aug 2012 16:49:42 BST, Bryan Kearney wrote:
> Orgs would model tenants in foreman, or business units in a company. I
> think of these as hierarchical. This would probably link to ACLs, and
> represent groups of systems based on budget.
>
> Locations model where systems are. They are also hierarchical, but
> that hierarchy is a peer to the org hierarchy.
