Designing organizations and locations

Support
1

Organizations came to foreman in part because katello required them. Locations were a commonly asked for feature of katello; and in foreman?

Organizations are also a key component to multi-tenancy required for Satellite-6 so getting them right is important to that "downstream" product. Doing it well, and in a way that the community can benefit, upstream here in foreman and katello is equally important.

In katello, resources such as subscriptions and content views are required to belong to one and only one organization. In foreman, resources such as architectures and subnets may belong to none, one, or any number of orgs. Somewhere along that spectrum is where I'd like to get concensus as to where to land.

I'd like to suggest we ignore the implementation details for now and discuss the user stories around orgs and locations.

As a user, I would like to associate locations with all, one, or many orgs.

As a user, I would like to associate all resources with all, one, or many orgs.

As a user, I would like to create roles to CRUD all resources in all, one, or many orgs.

Fill in the table below with all, one, many, or none. (None will mean that it doesn't make sense to associate this resource the org or location.) Add any resources I forgot. I'll move this to editable wiki after some initial discussion.

ARCHITECTURE
orgs:
locs:

BOOKMARK
orgs:
locs:

COMPUTE PROFILE
orgs:
locs:

COMPUTE RESOURCE
orgs:
locs:

CONFIG GROUP
orgs:
locs:

CONFIG TEMPLATE
orgs:
locs:

DOMAIN
orgs:
locs:

ENVIRONMENT
orgs:
locs:

USER GROUP
orgs:
locs:

ROLE
orgs:
locs:

FILTER
orgs:
locs:

HOSTGROUP
orgs:
locs:

HOST
orgs:
locs:

IMAGE
orgs:
locs:

MEDIUM
orgs:
locs:

MODEL
orgs:
locs:

OPERATING SYSTEM
orgs:
locs:

PARAMETER
orgs:
locs:

PARTITION TABLE
orgs:
locs:

PUPPET CLASS
orgs:
locs:

REALM
orgs:
locs:

REPORT
orgs:
locs:

SUBNET
orgs:
locs:

ACTIVATION KEY
orgs:
locs:

CONTENT VIEW
orgs:
locs:

HOST COLLECTION
orgs:
locs:

GPG KEY
orgs:
locs:

LIFECYCLE ENVIRONMENT
orgs:
locs:

PRODUCT
orgs:
locs:

SYNC PLAN
orgs:
locs:

ACTIVATION KEY
orgs:
locs:

CONTENT HOST
orgs:
locs:

··· -- @thomasmckay

–
“The leader must aim high, see big, judge widely, thus setting himself apart form the ordinary people who debate in narrow confines.” ~ Charles De Gaulle

“Leadership is about making others better as a result of your presence and making sure that impact lasts in your absence.” ~ Harvard Business School

2

>
> Organizations came to foreman in part because katello required them.
> Locations were a commonly asked for feature of katello; and in foreman?
>
> Organizations are also a key component to multi-tenancy required for
> Satellite-6 so getting them right is important to that "downstream" product.
> Doing it well, and in a way that the community can benefit, upstream here in
> foreman and katello is equally important.
>
> In katello, resources such as subscriptions and content views are required to
> belong to one and only one organization. In foreman, resources such as
> architectures and subnets may belong to none, one, or any number of orgs.
> Somewhere along that spectrum is where I'd like to get concensus as to where
> to land.
>
> I'd like to suggest we ignore the implementation details for now and discuss
> the user stories around orgs and locations.
>
> As a user, I would like to associate locations with all, one, or many orgs.
>
> As a user, I would like to associate all resources with all, one, or many
> orgs.
>
> As a user, I would like to create roles to CRUD all resources in all, one, or
> many orgs.
>
> Fill in the table below with all, one, many, or none. (None will mean that it
> doesn't make sense to associate this resource the org or location.) Add any
> resources I forgot. I'll move this to editable wiki after some initial
> discussion.

My suggestion (tl;dr pretty much everything goes to many orgs). I don't know much about the intended usecase of locations so left most of them blank.

>
> ARCHITECTURE
> orgs:
many
> locs:
none

>
> BOOKMARK
> orgs:
many
> locs:
none

>
> COMPUTE PROFILE
> orgs:
many
> locs:
??

>
> COMPUTE RESOURCE
> orgs:
many
> locs:
??

>
> CONFIG GROUP
> orgs:
many
> locs:
??

>
> CONFIG TEMPLATE
> orgs:
many
> locs:
??

>
> DOMAIN
> orgs:
many
> locs:
??

>
> ENVIRONMENT
> orgs:
many
> locs:
??

>
> USER GROUP
> orgs:
many
> locs:
none

>
> ROLE
> orgs:
many
> locs:
none

>
> FILTER
> orgs:
many
> locs:
??

>
> HOSTGROUP
> orgs:
many
> locs:
??

>
> HOST
> orgs:
one or many? (+ nested?)
> locs:
one (+ nested?)

Not sure about HOST, does it make sense to have belong to more than one? Perhaps through nested org/loc?

The use case in my mind is a hypervisor where its guests can span multiple divisions in a company. If the divisions are modeled as orgs then it would make sense for the HV to show up in each.

>
> IMAGE
> orgs:
many
> locs:
??

>
> MEDIUM
> orgs:
many
> locs:
??

>
> MODEL
> orgs:
many
> locs:
??

>
> OPERATING SYSTEM
> orgs:
many
> locs:
??

>
> PARAMETER
> orgs:
many
> locs:
??

>
> PARTITION TABLE
> orgs:
many
> locs:
??

>
> PUPPET CLASS
> orgs:
many
> locs:
??

>
> REALM
> orgs:
many
> locs:
??

>
> REPORT
> orgs:
> locs:

Reports are from hosts which themselves are in orgs, right?

>
> SUBNET
> orgs:
many
> locs:
??

>
> ACTIVATION KEY
> orgs:
many
> locs:
??

>
> CONTENT VIEW
> orgs:
many
> locs:
??

>
> HOST COLLECTION
> orgs:
many
> locs:
??

>
> GPG KEY
> orgs:
many
> locs:
??

>
> LIFECYCLE ENVIRONMENT
> orgs:
many
> locs:
??

>
> PRODUCT
> orgs:
many
> locs:
??

>
> SYNC PLAN
> orgs:
??
> locs:
??

>
> CONTENT HOST
> orgs:
same as HOST
> locs:
same as HOST
>

SUBSCRIPTION
orgs:
many (or one + nested?)
locs:
??

The katello models, having to do with subscriptions and content, are now locked to a single org without a concept of location. I personally would find it useful to have a RHEL content view developed in the platform org that is available in other orgs. This could be accomplished a couple different ways, though, so perhaps multiorg assignment is not the way to go.

  1. Org 1 exports a subscription that is imported into org 2 which lets orgs 2 sync and consume the product.
  2. Product is available in org 1 and org 2 through shared content view.
  3. Other ideas?
··· ----- Original Message -----

–
@thomasmckay

–
“The leader must aim high, see big, judge widely, thus setting himself apart
form the ordinary people who debate in narrow confines.” ~ Charles De Gaulle

“Leadership is about making others better as a result of your presence and
making sure that impact lasts in your absence.” ~ Harvard Business School

–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

3

FWIW… When I first heard about the concept, I assumed everything
should/could go to many orgs and locations were a label.

However, I can see use cases where folks would want to use locations as
a scoping mechanism in the same way that orgs are.

– bk

··· On 09/29/2014 08:22 AM, Tom McKay wrote: > > ----- Original Message ----- >> > >> >Organizations came to foreman in part because katello required them. >> >Locations were a commonly asked for feature of katello; and in foreman? >> > >> >Organizations are also a key component to multi-tenancy required for >> >Satellite-6 so getting them right is important to that "downstream" product. >> >Doing it well, and in a way that the community can benefit, upstream here in >> >foreman and katello is equally important. >> > >> >In katello, resources such as subscriptions and content views are required to >> >belong to one and only one organization. In foreman, resources such as >> >architectures and subnets may belong to none, one, or any number of orgs. >> >Somewhere along that spectrum is where I'd like to get concensus as to where >> >to land. >> > >> >I'd like to suggest we ignore the implementation details for now and discuss >> >the user stories around orgs and locations. >> > >> >As a user, I would like to associate locations with all, one, or many orgs. >> > >> >As a user, I would like to associate all resources with all, one, or many >> >orgs. >> > >> >As a user, I would like to create roles to CRUD all resources in all, one, or >> >many orgs. >> > >> >Fill in the table below with all, one, many, or none. (None will mean that it >> >doesn't make sense to associate this resource the org or location.) Add any >> >resources I forgot. I'll move this to editable wiki after some initial >> >discussion. > My suggestion (tl;dr pretty much everything goes to many orgs). I don't know much about the intended usecase of locations so left most of them blank. >
4

Is anyone against everything being capable of being assigned to an organization? I'd like to get the story onto the backlog for 1.7.

··· ----- Original Message ----- > On 09/29/2014 08:22 AM, Tom McKay wrote: > > > > ----- Original Message ----- > >> > > >> >Organizations came to foreman in part because katello required them. > >> >Locations were a commonly asked for feature of katello; and in foreman? > >> > > >> >Organizations are also a key component to multi-tenancy required for > >> >Satellite-6 so getting them right is important to that "downstream" > >> >product. > >> >Doing it well, and in a way that the community can benefit, upstream here > >> >in > >> >foreman and katello is equally important. > >> > > >> >In katello, resources such as subscriptions and content views are > >> >required to > >> >belong to one and only one organization. In foreman, resources such as > >> >architectures and subnets may belong to none, one, or any number of orgs. > >> >Somewhere along that spectrum is where I'd like to get concensus as to > >> >where > >> >to land. > >> > > >> >I'd like to suggest we ignore the implementation details for now and > >> >discuss > >> >the user stories around orgs and locations. > >> > > >> >As a user, I would like to associate locations with all, one, or many > >> >orgs. > >> > > >> >As a user, I would like to associate all resources with all, one, or many > >> >orgs. > >> > > >> >As a user, I would like to create roles to CRUD all resources in all, > >> >one, or > >> >many orgs. > >> > > >> >Fill in the table below with all, one, many, or none. (None will mean > >> >that it > >> >doesn't make sense to associate this resource the org or location.) Add > >> >any > >> >resources I forgot. I'll move this to editable wiki after some initial > >> >discussion. > > My suggestion (tl;dr pretty much everything goes to many orgs). I don't > > know much about the intended usecase of locations so left most of them > > blank. > > > > FWIW.. When I first heard about the concept, I assumed everything > should/could go to many orgs and locations were a label. > > However, I can see use cases where folks would want to use locations as > a scoping mechanism in the same way that orgs are. > > -- bk > > -- > You received this message because you are subscribed to the Google Groups > "Foreman users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-users+unsubscribe@googlegroups.com. > To post to this group, send email to foreman-users@googlegroups.com. > Visit this group at http://groups.google.com/group/foreman-users. > For more options, visit https://groups.google.com/d/optout. >
5

i'm all for it. +1

··· ----- Original Message ----- > > > ----- Original Message ----- > > On 09/29/2014 08:22 AM, Tom McKay wrote: > > > > > > ----- Original Message ----- > > >> > > > >> >Organizations came to foreman in part because katello required them. > > >> >Locations were a commonly asked for feature of katello; and in foreman? > > >> > > > >> >Organizations are also a key component to multi-tenancy required for > > >> >Satellite-6 so getting them right is important to that "downstream" > > >> >product. > > >> >Doing it well, and in a way that the community can benefit, upstream > > >> >here > > >> >in > > >> >foreman and katello is equally important. > > >> > > > >> >In katello, resources such as subscriptions and content views are > > >> >required to > > >> >belong to one and only one organization. In foreman, resources such as > > >> >architectures and subnets may belong to none, one, or any number of > > >> >orgs. > > >> >Somewhere along that spectrum is where I'd like to get concensus as to > > >> >where > > >> >to land. > > >> > > > >> >I'd like to suggest we ignore the implementation details for now and > > >> >discuss > > >> >the user stories around orgs and locations. > > >> > > > >> >As a user, I would like to associate locations with all, one, or many > > >> >orgs. > > >> > > > >> >As a user, I would like to associate all resources with all, one, or > > >> >many > > >> >orgs. > > >> > > > >> >As a user, I would like to create roles to CRUD all resources in all, > > >> >one, or > > >> >many orgs. > > >> > > > >> >Fill in the table below with all, one, many, or none. (None will mean > > >> >that it > > >> >doesn't make sense to associate this resource the org or location.) Add > > >> >any > > >> >resources I forgot. I'll move this to editable wiki after some initial > > >> >discussion. > > > My suggestion (tl;dr pretty much everything goes to many orgs). I don't > > > know much about the intended usecase of locations so left most of them > > > blank. > > > > > > > FWIW.. When I first heard about the concept, I assumed everything > > should/could go to many orgs and locations were a label. > > > > However, I can see use cases where folks would want to use locations as > > a scoping mechanism in the same way that orgs are. > > > > -- bk > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Foreman users" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to foreman-users+unsubscribe@googlegroups.com. > > To post to this group, send email to foreman-users@googlegroups.com. > > Visit this group at http://groups.google.com/group/foreman-users. > > For more options, visit https://groups.google.com/d/optout. > > > > Is anyone against everything being capable of being assigned to an > organization? I'd like to get the story onto the backlog for 1.7. > > -- > You received this message because you are subscribed to the Google Groups > "Foreman users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-users+unsubscribe@googlegroups.com. > To post to this group, send email to foreman-users@googlegroups.com. > Visit this group at http://groups.google.com/group/foreman-users. > For more options, visit https://groups.google.com/d/optout. >

–

  • adam price
6

I don't think it makes sense to be able to assign something like "arch"
to an org, unless you want to micromanage arches across orgs. They are
universal in the world and should be universal across orgs.

It might be helpful to show a list of things that are currently not
scope-able to an org to decide whether or not they should be.

-Justin

··· On 10/03/2014 08:43 AM, Tom McKay wrote: > > ----- Original Message ----- >> On 09/29/2014 08:22 AM, Tom McKay wrote: >>> ----- Original Message ----- >>>>> Organizations came to foreman in part because katello required them. >>>>> Locations were a commonly asked for feature of katello; and in foreman? >>>>> >>>>> Organizations are also a key component to multi-tenancy required for >>>>> Satellite-6 so getting them right is important to that "downstream" >>>>> product. >>>>> Doing it well, and in a way that the community can benefit, upstream here >>>>> in >>>>> foreman and katello is equally important. >>>>> >>>>> In katello, resources such as subscriptions and content views are >>>>> required to >>>>> belong to one and only one organization. In foreman, resources such as >>>>> architectures and subnets may belong to none, one, or any number of orgs. >>>>> Somewhere along that spectrum is where I'd like to get concensus as to >>>>> where >>>>> to land. >>>>> >>>>> I'd like to suggest we ignore the implementation details for now and >>>>> discuss >>>>> the user stories around orgs and locations. >>>>> >>>>> As a user, I would like to associate locations with all, one, or many >>>>> orgs. >>>>> >>>>> As a user, I would like to associate all resources with all, one, or many >>>>> orgs. >>>>> >>>>> As a user, I would like to create roles to CRUD all resources in all, >>>>> one, or >>>>> many orgs. >>>>> >>>>> Fill in the table below with all, one, many, or none. (None will mean >>>>> that it >>>>> doesn't make sense to associate this resource the org or location.) Add >>>>> any >>>>> resources I forgot. I'll move this to editable wiki after some initial >>>>> discussion. >>> My suggestion (tl;dr pretty much everything goes to many orgs). I don't >>> know much about the intended usecase of locations so left most of them >>> blank. >>> >> FWIW.. When I first heard about the concept, I assumed everything >> should/could go to many orgs and locations were a label. >> >> However, I can see use cases where folks would want to use locations as >> a scoping mechanism in the same way that orgs are. >> >> -- bk >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Foreman users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to foreman-users+unsubscribe@googlegroups.com. >> To post to this group, send email to foreman-users@googlegroups.com. >> Visit this group at http://groups.google.com/group/foreman-users. >> For more options, visit https://groups.google.com/d/optout. >> > Is anyone against everything being capable of being assigned to an organization? I'd like to get the story onto the backlog for 1.7. >
7

> >
> >>>>> Organizations came to foreman in part because katello required them.
> >>>>> Locations were a commonly asked for feature of katello; and in foreman?
> >>>>>
> >>>>> Organizations are also a key component to multi-tenancy required for
> >>>>> Satellite-6 so getting them right is important to that "downstream"
> >>>>> product.
> >>>>> Doing it well, and in a way that the community can benefit, upstream
> >>>>> here
> >>>>> in
> >>>>> foreman and katello is equally important.
> >>>>>
> >>>>> In katello, resources such as subscriptions and content views are
> >>>>> required to
> >>>>> belong to one and only one organization. In foreman, resources such as
> >>>>> architectures and subnets may belong to none, one, or any number of
> >>>>> orgs.
> >>>>> Somewhere along that spectrum is where I'd like to get concensus as to
> >>>>> where
> >>>>> to land.
> >>>>>
> >>>>> I'd like to suggest we ignore the implementation details for now and
> >>>>> discuss
> >>>>> the user stories around orgs and locations.
> >>>>>
> >>>>> As a user, I would like to associate locations with all, one, or many
> >>>>> orgs.
> >>>>>
> >>>>> As a user, I would like to associate all resources with all, one, or
> >>>>> many
> >>>>> orgs.
> >>>>>
> >>>>> As a user, I would like to create roles to CRUD all resources in all,
> >>>>> one, or
> >>>>> many orgs.
> >>>>>
> >>>>> Fill in the table below with all, one, many, or none. (None will mean
> >>>>> that it
> >>>>> doesn't make sense to associate this resource the org or location.) Add
> >>>>> any
> >>>>> resources I forgot. I'll move this to editable wiki after some initial
> >>>>> discussion.
> >>> My suggestion (tl;dr pretty much everything goes to many orgs). I don't
> >>> know much about the intended usecase of locations so left most of them
> >>> blank.
> >>>
> >> FWIW… When I first heard about the concept, I assumed everything
> >> should/could go to many orgs and locations were a label.
> >>
> >> However, I can see use cases where folks would want to use locations as
> >> a scoping mechanism in the same way that orgs are.
> >>
> >> – bk
> >>
> >> –
> >> You received this message because you are subscribed to the Google Groups
> >> "Foreman users" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an
> >> email to foreman-users+unsubscribe@googlegroups.com.
> >> To post to this group, send email to foreman-users@googlegroups.com.
> >> Visit this group at http://groups.google.com/group/foreman-users.
> >> For more options, visit https://groups.google.com/d/optout.
> >>
> > Is anyone against everything being capable of being assigned to an
> > organization? I'd like to get the story onto the backlog for 1.7.
> >
> I don't think it makes sense to be able to assign something like "arch"
> to an org, unless you want to micromanage arches across orgs. They are
> universal in the world and should be universal across orgs.

If that's the case, then shouldn't all the choices be hardcoded into the foreman? Why am I allowed to create a new arch? Should my ARMv8-A arch show up suddenly in all orgs? I think I'd rather micromanage the list of arch than micromanage the roles that allow their visibility.

If we are going to support multi-tenant capability, then I think that we must be able to enforce scoping everything to orgs.

··· ----- Original Message ----- > On 10/03/2014 08:43 AM, Tom McKay wrote: > > ----- Original Message ----- > >> On 09/29/2014 08:22 AM, Tom McKay wrote: > >>> ----- Original Message -----

It might be helpful to show a list of things that are currently not
scope-able to an org to decide whether or not they should be.

-Justin

–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

8

>
>>>>>>> Organizations came to foreman in part because katello required them.
>>>>>>> Locations were a commonly asked for feature of katello; and in foreman?
>>>>>>>
>>>>>>> Organizations are also a key component to multi-tenancy required for
>>>>>>> Satellite-6 so getting them right is important to that "downstream"
>>>>>>> product.
>>>>>>> Doing it well, and in a way that the community can benefit, upstream
>>>>>>> here
>>>>>>> in
>>>>>>> foreman and katello is equally important.
>>>>>>>
>>>>>>> In katello, resources such as subscriptions and content views are
>>>>>>> required to
>>>>>>> belong to one and only one organization. In foreman, resources such as
>>>>>>> architectures and subnets may belong to none, one, or any number of
>>>>>>> orgs.
>>>>>>> Somewhere along that spectrum is where I'd like to get concensus as to
>>>>>>> where
>>>>>>> to land.
>>>>>>>
>>>>>>> I'd like to suggest we ignore the implementation details for now and
>>>>>>> discuss
>>>>>>> the user stories around orgs and locations.
>>>>>>>
>>>>>>> As a user, I would like to associate locations with all, one, or many
>>>>>>> orgs.
>>>>>>>
>>>>>>> As a user, I would like to associate all resources with all, one, or
>>>>>>> many
>>>>>>> orgs.
>>>>>>>
>>>>>>> As a user, I would like to create roles to CRUD all resources in all,
>>>>>>> one, or
>>>>>>> many orgs.
>>>>>>>
>>>>>>> Fill in the table below with all, one, many, or none. (None will mean
>>>>>>> that it
>>>>>>> doesn't make sense to associate this resource the org or location.) Add
>>>>>>> any
>>>>>>> resources I forgot. I'll move this to editable wiki after some initial
>>>>>>> discussion.
>>>>> My suggestion (tl;dr pretty much everything goes to many orgs). I don't
>>>>> know much about the intended usecase of locations so left most of them
>>>>> blank.
>>>>>
>>>> FWIW… When I first heard about the concept, I assumed everything
>>>> should/could go to many orgs and locations were a label.
>>>>
>>>> However, I can see use cases where folks would want to use locations as
>>>> a scoping mechanism in the same way that orgs are.
>>>>
>>>> – bk
>>>>
>>>> –
>>>> You received this message because you are subscribed to the Google Groups
>>>> "Foreman users" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send an
>>>> email to foreman-users+unsubscribe@googlegroups.com.
>>>> To post to this group, send email to foreman-users@googlegroups.com.
>>>> Visit this group at http://groups.google.com/group/foreman-users.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>> Is anyone against everything being capable of being assigned to an
>>> organization? I'd like to get the story onto the backlog for 1.7.
>>>
>> I don't think it makes sense to be able to assign something like "arch"
>> to an org, unless you want to micromanage arches across orgs. They are
>> universal in the world and should be universal across orgs.
> If that's the case, then shouldn't all the choices be hardcoded into the foreman? Why am I allowed to create a new arch? Should my ARMv8-A arch show up suddenly in all orgs? I think I'd rather micromanage the list of arch than micromanage the roles that allow their visibility.
>
> If we are going to support multi-tenant capability, then I think that we must be able to enforce scoping everything to orgs.
Generally when scoping things to orgs they get more complicated than
more simple. Without careful consideration you could easily get into a
situation where parts of the app are unusable to an organization due to
an arch already existing assigned to another org. By doing this you
could be seriously overcomplicating parts of the app and creating a
situation that is much harder to manage than assigning a role to the
'sat admin' that can control what arches exist. There is absolutely NO
gain to assigning arches to organizations. Why would you want to?

Deleting and editing arches belongs in the same vein as org creation as
a site-wide administer role that belongs only to the people maintaining
the foreman instance as a whole. There have to some functions of the
foreman instance that are cross orgs, and I think arches are one of
them. These are the same people you trust to not delete your
organization, so why would you not trust them to maintain arches?

-Justin

··· On 10/03/2014 02:30 PM, Tom McKay wrote: > ----- Original Message ----- >> On 10/03/2014 08:43 AM, Tom McKay wrote: >>> ----- Original Message ----- >>>> On 09/29/2014 08:22 AM, Tom McKay wrote: >>>>> ----- Original Message -----

It might be helpful to show a list of things that are currently not
scope-able to an org to decide whether or not they should be.

-Justin

–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

9

I tend to agree with Justin on this. In service provider use cases, I
would assume that infrastructure setup would be at the site admin
level… not at the org level.

– bk

··· On 10/03/2014 02:38 PM, Justin Sherrill wrote: > On 10/03/2014 02:30 PM, Tom McKay wrote: >> >> ----- Original Message ----- >>> On 10/03/2014 08:43 AM, Tom McKay wrote: >>>> ----- Original Message ----- >>>>> On 09/29/2014 08:22 AM, Tom McKay wrote: >>>>>> ----- Original Message ----- >>>>>>>> Organizations came to foreman in part because katello required >>>>>>>> them. >>>>>>>> Locations were a commonly asked for feature of katello; and in >>>>>>>> foreman? >>>>>>>> >>>>>>>> Organizations are also a key component to multi-tenancy required >>>>>>>> for >>>>>>>> Satellite-6 so getting them right is important to that "downstream" >>>>>>>> product. >>>>>>>> Doing it well, and in a way that the community can benefit, >>>>>>>> upstream >>>>>>>> here >>>>>>>> in >>>>>>>> foreman and katello is equally important. >>>>>>>> >>>>>>>> In katello, resources such as subscriptions and content views are >>>>>>>> required to >>>>>>>> belong to one and only one organization. In foreman, resources >>>>>>>> such as >>>>>>>> architectures and subnets may belong to none, one, or any number of >>>>>>>> orgs. >>>>>>>> Somewhere along that spectrum is where I'd like to get concensus >>>>>>>> as to >>>>>>>> where >>>>>>>> to land. >>>>>>>> >>>>>>>> I'd like to suggest we ignore the implementation details for now >>>>>>>> and >>>>>>>> discuss >>>>>>>> the user stories around orgs and locations. >>>>>>>> >>>>>>>> As a user, I would like to associate locations with all, one, or >>>>>>>> many >>>>>>>> orgs. >>>>>>>> >>>>>>>> As a user, I would like to associate all resources with all, >>>>>>>> one, or >>>>>>>> many >>>>>>>> orgs. >>>>>>>> >>>>>>>> As a user, I would like to create roles to CRUD all resources in >>>>>>>> all, >>>>>>>> one, or >>>>>>>> many orgs. >>>>>>>> >>>>>>>> Fill in the table below with all, one, many, or none. (None will >>>>>>>> mean >>>>>>>> that it >>>>>>>> doesn't make sense to associate this resource the org or >>>>>>>> location.) Add >>>>>>>> any >>>>>>>> resources I forgot. I'll move this to editable wiki after some >>>>>>>> initial >>>>>>>> discussion. >>>>>> My suggestion (tl;dr pretty much everything goes to many orgs). I >>>>>> don't >>>>>> know much about the intended usecase of locations so left most of >>>>>> them >>>>>> blank. >>>>>> >>>>> FWIW.. When I first heard about the concept, I assumed everything >>>>> should/could go to many orgs and locations were a label. >>>>> >>>>> However, I can see use cases where folks would want to use >>>>> locations as >>>>> a scoping mechanism in the same way that orgs are. >>>>> >>>>> -- bk >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups >>>>> "Foreman users" group. >>>>> To unsubscribe from this group and stop receiving emails from it, >>>>> send an >>>>> email to foreman-users+unsubscribe@googlegroups.com. >>>>> To post to this group, send email to foreman-users@googlegroups.com. >>>>> Visit this group at http://groups.google.com/group/foreman-users. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> Is anyone against everything being capable of being assigned to an >>>> organization? I'd like to get the story onto the backlog for 1.7. >>>> >>> I don't think it makes sense to be able to assign something like "arch" >>> to an org, unless you want to micromanage arches across orgs. They are >>> universal in the world and should be universal across orgs. >> If that's the case, then shouldn't all the choices be hardcoded into >> the foreman? Why am I allowed to create a new arch? Should my ARMv8-A >> arch show up suddenly in all orgs? I think I'd rather micromanage the >> list of arch than micromanage the roles that allow their visibility. >> >> If we are going to support multi-tenant capability, then I think that >> we must be able to enforce scoping everything to orgs. > Generally when scoping things to orgs they get more complicated than > more simple. Without careful consideration you could easily get into a > situation where parts of the app are unusable to an organization due to > an arch already existing assigned to another org. By doing this you > could be seriously overcomplicating parts of the app and creating a > situation that is much harder to manage than assigning a role to the > 'sat admin' that can control what arches exist. There is absolutely NO > gain to assigning arches to organizations. Why would you want to? > > Deleting and editing arches belongs in the same vein as org creation as > a site-wide administer role that belongs only to the people maintaining > the foreman instance as a whole. There have to some functions of the > foreman instance that are cross orgs, and I think arches are one of > them. These are the same people you trust to not delete your > organization, so why would you not trust them to maintain arches? > > > -Justin
10

+1 to what Justin said, while I can imagine a case where one org may not want
to see arm architecture since they only use x86_64 but it's not a big deal in
compare to "micromanagement". Also I think that this can be changed later
without major pain on existing setup if proven that customers need it. The
opposite direction would be more difficult.

··· On Friday 03 of October 2014 14:38:21 Justin Sherrill wrote: > On 10/03/2014 02:30 PM, Tom McKay wrote: > > ----- Original Message ----- > > > >> On 10/03/2014 08:43 AM, Tom McKay wrote: > >>> ----- Original Message ----- > >>> > >>>> On 09/29/2014 08:22 AM, Tom McKay wrote: > >>>>> ----- Original Message ----- > >>>>> > >>>>>>> Organizations came to foreman in part because katello required them. > >>>>>>> Locations were a commonly asked for feature of katello; and in > >>>>>>> foreman? > >>>>>>> > >>>>>>> Organizations are also a key component to multi-tenancy required for > >>>>>>> Satellite-6 so getting them right is important to that "downstream" > >>>>>>> product. > >>>>>>> Doing it well, and in a way that the community can benefit, upstream > >>>>>>> here > >>>>>>> in > >>>>>>> foreman and katello is equally important. > >>>>>>> > >>>>>>> In katello, resources such as subscriptions and content views are > >>>>>>> required to > >>>>>>> belong to one and only one organization. In foreman, resources such > >>>>>>> as > >>>>>>> architectures and subnets may belong to none, one, or any number of > >>>>>>> orgs. > >>>>>>> Somewhere along that spectrum is where I'd like to get concensus as > >>>>>>> to > >>>>>>> where > >>>>>>> to land. > >>>>>>> > >>>>>>> I'd like to suggest we ignore the implementation details for now and > >>>>>>> discuss > >>>>>>> the user stories around orgs and locations. > >>>>>>> > >>>>>>> As a user, I would like to associate locations with all, one, or > >>>>>>> many > >>>>>>> orgs. > >>>>>>> > >>>>>>> As a user, I would like to associate all resources with all, one, or > >>>>>>> many > >>>>>>> orgs. > >>>>>>> > >>>>>>> As a user, I would like to create roles to CRUD all resources in > >>>>>>> all, > >>>>>>> one, or > >>>>>>> many orgs. > >>>>>>> > >>>>>>> Fill in the table below with all, one, many, or none. (None will > >>>>>>> mean > >>>>>>> that it > >>>>>>> doesn't make sense to associate this resource the org or location.) > >>>>>>> Add > >>>>>>> any > >>>>>>> resources I forgot. I'll move this to editable wiki after some > >>>>>>> initial > >>>>>>> discussion. > >>>>> > >>>>> My suggestion (tl;dr pretty much everything goes to many orgs). I > >>>>> don't > >>>>> know much about the intended usecase of locations so left most of them > >>>>> blank. > >>>> > >>>> FWIW.. When I first heard about the concept, I assumed everything > >>>> should/could go to many orgs and locations were a label. > >>>> > >>>> However, I can see use cases where folks would want to use locations as > >>>> a scoping mechanism in the same way that orgs are. > >>>> > >>>> -- bk > >>>> > >>>> -- > >>>> You received this message because you are subscribed to the Google > >>>> Groups > >>>> "Foreman users" group. > >>>> To unsubscribe from this group and stop receiving emails from it, send > >>>> an > >>>> email to foreman-users+unsubscribe@googlegroups.com. > >>>> To post to this group, send email to foreman-users@googlegroups.com. > >>>> Visit this group at http://groups.google.com/group/foreman-users. > >>>> For more options, visit https://groups.google.com/d/optout. > >>> > >>> Is anyone against everything being capable of being assigned to an > >>> organization? I'd like to get the story onto the backlog for 1.7. > >> > >> I don't think it makes sense to be able to assign something like "arch" > >> to an org, unless you want to micromanage arches across orgs. They are > >> universal in the world and should be universal across orgs. > > > > If that's the case, then shouldn't all the choices be hardcoded into the > > foreman? Why am I allowed to create a new arch? Should my ARMv8-A arch > > show up suddenly in all orgs? I think I'd rather micromanage the list of > > arch than micromanage the roles that allow their visibility. > > > > If we are going to support multi-tenant capability, then I think that we > > must be able to enforce scoping everything to orgs. > Generally when scoping things to orgs they get more complicated than > more simple. Without careful consideration you could easily get into a > situation where parts of the app are unusable to an organization due to > an arch already existing assigned to another org. By doing this you > could be seriously overcomplicating parts of the app and creating a > situation that is much harder to manage than assigning a role to the > 'sat admin' that can control what arches exist. There is absolutely NO > gain to assigning arches to organizations. Why would you want to? > > Deleting and editing arches belongs in the same vein as org creation as > a site-wide administer role that belongs only to the people maintaining > the foreman instance as a whole. There have to some functions of the > foreman instance that are cross orgs, and I think arches are one of > them. These are the same people you trust to not delete your > organization, so why would you not trust them to maintain arches? > > > -Justin

–
Marek

It might be helpful to show a list of things that are currently not
scope-able to an org to decide whether or not they should be.

-Justin

–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.