As we continue down our examination of moving Katello on to Foreman,
discussions have ensued that point to a need to reconcile the difference
between how Katello and Foreman treat an organization. Each project has
their own reasons and requirements that have driven them to toward one
design or the other. Further, there are potential implications on either
side towards how the organization model affects the functionality of other
models. The basic usage of each:
Katello - treats an organization as a 'master' scope that all other
entities (minus users and roles) belong to, entities can only belong to one
organization at a time.
Foreman - treats an organization as a multi-use object that allows other
entities to be treated as global entities and shared between organizations
In order to truly assess this impact, I'd like to ask anyone with domain
knowledge on any given Katello (for example, the previous mentions around
how organizations affect repositories) or Foreman entities to assess and
discuss in this email thread the impact (and implications) of each approach
to organizations.
As you mention, there are already objects in katello that are scoped to an
org (eg. systems) and ones that are not (eg. users). Users, however, can be
scoped by RBAC to having only certain permissions in an org so this is
effectively another way to scope things (versus via database schema).
Continuing Systems as an example, it could be beneficial to have a single
System object have roles in different orgs. Some of the roles could be
mutually exclusive. For example, a "subscribe to content from Org1" would
be exclusive (ie. cannot have more than one org-level subscribe to
content), while the "list in Eastern Datacenter Org" and "list in Org1" may
both coexist.
From a candlepin back-end perspective, the system would only (currently) be
able to belong to one of candlepin's orgs (they call them owners). So a
role of "subscribe to content" should limit to a single relation from
system to subscription. Each backend (engine?) could define the roles and
relations they support, though.
···
On Tuesday, July 30, 2013 10:59:41 AM UTC-4, Eric Helms wrote:
>
> Howdy,
>
> As we continue down our examination of moving Katello on to Foreman,
> discussions have ensued that point to a need to reconcile the difference
> between how Katello and Foreman treat an organization. Each project has
> their own reasons and requirements that have driven them to toward one
> design or the other. Further, there are potential implications on either
> side towards how the organization model affects the functionality of other
> models. The basic usage of each:
>
> Katello - treats an organization as a 'master' scope that all other
> entities (minus users and roles) belong to, entities can only belong to one
> organization at a time.
>
> Foreman - treats an organization as a multi-use object that allows other
> entities to be treated as global entities and shared between organizations
>
>
> In order to truly assess this impact, I'd like to ask anyone with domain
> knowledge on any given Katello (for example, the previous mentions around
> how organizations affect repositories) or Foreman entities to assess and
> discuss in this email thread the impact (and implications) of each approach
> to organizations.
>
>
> Thanks for your input,
> Eric
>
The main use case driving this is the service provider. So, think a
provider that wants true tenants which are unique from each other. So, I
buy services from ACME_Cloud and I am one org. You buy as well, and you
are a unique account.
The design codes that model in, but then opens up the issue of sharing
items across orgs. I am fine making it more open by default, if I know
we can lock down for the service provider model. There may be an issue
with candlepin and subscriptions which we would need to work with
however, so we should have those discussions sooner rather than later.
– bk
···
On 07/30/2013 10:59 AM, Eric D Helms wrote:
> Howdy,
>
> As we continue down our examination of moving Katello on to Foreman,
> discussions have ensued that point to a need to reconcile the difference
> between how Katello and Foreman treat an organization. Each project has
> their own reasons and requirements that have driven them to toward one
> design or the other. Further, there are potential implications on either
> side towards how the organization model affects the functionality of
> other models. The basic usage of each:
>
> Katello - treats an organization as a 'master' scope that all other
> entities (minus users and roles) belong to, entities can only belong to
> one organization at a time.
>
> Foreman - treats an organization as a multi-use object that allows other
> entities to be treated as global entities and shared between organizations
>
>
> In order to truly assess this impact, I'd like to ask anyone with domain
> knowledge on any given Katello (for example, the previous mentions
> around how organizations affect repositories) or Foreman entities to
> assess and discuss in this email thread the impact (and implications) of
> each approach to organizations.
>
>
The main use case I have heard about cross org sharing is content. I
define an SOE, I want you to use it.
There are some improvements in setup (if we all share a location, etc)
so some set up as well could benefit. But, the main sharing use case I
have heard is setup.
– bk
···
On 07/30/2013 11:31 AM, Thomas McKay wrote:
>
>
> On Tuesday, July 30, 2013 10:59:41 AM UTC-4, Eric Helms wrote:
>
> Howdy,
>
> As we continue down our examination of moving Katello on to Foreman,
> discussions have ensued that point to a need to reconcile the
> difference between how Katello and Foreman treat an organization.
> Each project has their own reasons and requirements that have driven
> them to toward one design or the other. Further, there are potential
> implications on either side towards how the organization model
> affects the functionality of other models. The basic usage of each:
>
> Katello - treats an organization as a 'master' scope that all other
> entities (minus users and roles) belong to, entities can only belong
> to one organization at a time.
>
> Foreman - treats an organization as a multi-use object that allows
> other entities to be treated as global entities and shared between
> organizations
>
>
> In order to truly assess this impact, I'd like to ask anyone with
> domain knowledge on any given Katello (for example, the previous
> mentions around how organizations affect repositories) or Foreman
> entities to assess and discuss in this email thread the impact (and
> implications) of each approach to organizations.
>
>
> Thanks for your input,
> Eric
>
>
> As you mention, there are already objects in katello that are scoped to
> an org (eg. systems) and ones that are not (eg. users). Users, however,
> can be scoped by RBAC to having only certain permissions in an org so
> this is effectively another way to scope things (versus via database
> schema).
>
> Continuing Systems as an example, it could be beneficial to have a
> single System object have roles in different orgs. Some of the roles
> could be mutually exclusive. For example, a "subscribe to content from
> Org1" would be exclusive (ie. cannot have more than one org-level
> subscribe to content), while the "list in Eastern Datacenter Org" and
> "list in Org1" may both coexist.
>
> From a candlepin back-end perspective, the system would only
> (currently) be able to belong to one of candlepin's orgs (they call them
> owners). So a role of "subscribe to content" should limit to a single
> relation from system to subscription. Each backend (engine?) could
> define the roles and relations they support, though.
In discussing how candlepin/pulp/thumbslug handle product subscriptions and
their certs, it is clear that there will certainly be cases where some
objects have to be scoped to an org if subscription-manager and rhsm are
going to be supported (which is not optional, afaik). Depending on the
complexity, though, there could be two code paths when creating repos: 1) I
plan on using subscriptions, and 2) I plan on using something else.
So, overall my opinion is that there absolutely needs to be support for
scoping objects to orgs. I do expect, however, that there are probably
clever choices to choose from.
···
On Tuesday, July 30, 2013 11:31:12 AM UTC-4, Thomas McKay wrote:
>
>
>
> On Tuesday, July 30, 2013 10:59:41 AM UTC-4, Eric Helms wrote:
>>
>> Howdy,
>>
>> As we continue down our examination of moving Katello on to Foreman,
>> discussions have ensued that point to a need to reconcile the difference
>> between how Katello and Foreman treat an organization. Each project has
>> their own reasons and requirements that have driven them to toward one
>> design or the other. Further, there are potential implications on either
>> side towards how the organization model affects the functionality of other
>> models. The basic usage of each:
>>
>> Katello - treats an organization as a 'master' scope that all other
>> entities (minus users and roles) belong to, entities can only belong to one
>> organization at a time.
>>
>> Foreman - treats an organization as a multi-use object that allows other
>> entities to be treated as global entities and shared between organizations
>>
>>
>> In order to truly assess this impact, I'd like to ask anyone with domain
>> knowledge on any given Katello (for example, the previous mentions around
>> how organizations affect repositories) or Foreman entities to assess and
>> discuss in this email thread the impact (and implications) of each approach
>> to organizations.
>>
>>
>> Thanks for your input,
>> Eric
>>
>
> As you mention, there are already objects in katello that are scoped to an
> org (eg. systems) and ones that are not (eg. users). Users, however, can be
> scoped by RBAC to having only certain permissions in an org so this is
> effectively another way to scope things (versus via database schema).
>
> Continuing Systems as an example, it could be beneficial to have a single
> System object have roles in different orgs. Some of the roles could be
> mutually exclusive. For example, a "subscribe to content from Org1" would
> be exclusive (ie. cannot have more than one org-level subscribe to
> content), while the "list in Eastern Datacenter Org" and "list in Org1" may
> both coexist.
>
> From a candlepin back-end perspective, the system would only (currently)
> be able to belong to one of candlepin's orgs (they call them owners). So a
> role of "subscribe to content" should limit to a single relation from
> system to subscription. Each backend (engine?) could define the roles and
> relations they support, though.
>
Anecdote: We spoke with one service provider who wanted a unique LDAP
server per org. That way, the customer could manage their own users in
that org.
– bk
···
On 07/30/2013 11:28 AM, Bryan Kearney wrote:
> On 07/30/2013 10:59 AM, Eric D Helms wrote:
>> Howdy,
>>
>> As we continue down our examination of moving Katello on to Foreman,
>> discussions have ensued that point to a need to reconcile the difference
>> between how Katello and Foreman treat an organization. Each project has
>> their own reasons and requirements that have driven them to toward one
>> design or the other. Further, there are potential implications on either
>> side towards how the organization model affects the functionality of
>> other models. The basic usage of each:
>>
>> Katello - treats an organization as a 'master' scope that all other
>> entities (minus users and roles) belong to, entities can only belong to
>> one organization at a time.
>>
>> Foreman - treats an organization as a multi-use object that allows other
>> entities to be treated as global entities and shared between
>> organizations
>>
>>
>> In order to truly assess this impact, I'd like to ask anyone with domain
>> knowledge on any given Katello (for example, the previous mentions
>> around how organizations affect repositories) or Foreman entities to
>> assess and discuss in this email thread the impact (and implications) of
>> each approach to organizations.
>>
>>
>
> The main use case driving this is the service provider. So, think a
> provider that wants true tenants which are unique from each other. So, I
> buy services from ACME_Cloud and I am one org. You buy as well, and you
> are a unique account.
>
> The design codes that model in, but then opens up the issue of sharing
> items across orgs. I am fine making it more open by default, if I know
> we can lock down for the service provider model. There may be an issue
> with candlepin and subscriptions which we would need to work with
> however, so we should have those discussions sooner rather than later.
>
> -- bk
>
>
>
>
>
From an interaction standpoint, the Katello workflow always has a user in
the context of an organization. That is to say, a user must 'always' have a
current organization and all objects created are created within the context
of that organization. For example, this means that there is no explicit
selection of the organization that a Provider is tied to. For how this
interaction I see two possibilities (using providers as an example):
Providers could be created (and managed) without having a current
organization chosen, but require that the user select a single organization
at creation time. If the user has a currently selected organization, that
organization is automatically selected and the user cannot change it during
creation.
Providers navigation is hidden from the user when not in the context of
an organization. Upon selecting an organization, a user can then create
(and manage) a Provider. Then, either
A) The Provider is attached to the current organization behind the
scenes.
B) The Provider displays an organization field that is explicitly
displaying the current organization that the Provider will be attached to,
but cannot be changed by the user.
Eric
···
On Wed, Jul 31, 2013 at 7:59 AM, Thomas McKay wrote:
On Tuesday, July 30, 2013 11:31:12 AM UTC-4, Thomas McKay wrote:
On Tuesday, July 30, 2013 10:59:41 AM UTC-4, Eric Helms wrote:
Howdy,
As we continue down our examination of moving Katello on to Foreman,
discussions have ensued that point to a need to reconcile the difference
between how Katello and Foreman treat an organization. Each project has
their own reasons and requirements that have driven them to toward one
design or the other. Further, there are potential implications on either
side towards how the organization model affects the functionality of other
models. The basic usage of each:
Katello - treats an organization as a ‘master’ scope that all other
entities (minus users and roles) belong to, entities can only belong to one
organization at a time.
Foreman - treats an organization as a multi-use object that allows other
entities to be treated as global entities and shared between organizations
In order to truly assess this impact, I’d like to ask anyone with domain
knowledge on any given Katello (for example, the previous mentions around
how organizations affect repositories) or Foreman entities to assess and
discuss in this email thread the impact (and implications) of each approach
to organizations.
Thanks for your input,
Eric
As you mention, there are already objects in katello that are scoped to
an org (eg. systems) and ones that are not (eg. users). Users, however, can
be scoped by RBAC to having only certain permissions in an org so this is
effectively another way to scope things (versus via database schema).
Continuing Systems as an example, it could be beneficial to have a single
System object have roles in different orgs. Some of the roles could be
mutually exclusive. For example, a “subscribe to content from Org1” would
be exclusive (ie. cannot have more than one org-level subscribe to
content), while the “list in Eastern Datacenter Org” and “list in Org1” may
both coexist.
From a candlepin back-end perspective, the system would only (currently)
be able to belong to one of candlepin’s orgs (they call them owners). So a
role of “subscribe to content” should limit to a single relation from
system to subscription. Each backend (engine?) could define the roles and
relations they support, though.
In discussing how candlepin/pulp/thumbslug handle product subscriptions
and their certs, it is clear that there will certainly be cases where some
objects have to be scoped to an org if subscription-manager and rhsm are
going to be supported (which is not optional, afaik). Depending on the
complexity, though, there could be two code paths when creating repos: 1) I
plan on using subscriptions, and 2) I plan on using something else.
So, overall my opinion is that there absolutely needs to be support for
scoping objects to orgs. I do expect, however, that there are probably
clever choices to choose from.
