Env : Katello 2.1 / Foreman 1.7 on RHEL 7
I'm trying to understand the general idea behind Organizations and Puppet
Environments within Katello and what the best practice is for setup.
Our situation is 3 different Linux admin groups (call them Orgs) would need
to use this setup. As I understand it, the RedHat Subscriptions can all be
shared - it's not a problem if they can't, I'm just trying to understand
how it is intended to be setup. I have "Acme.CO" as an organization which
has all of the entitlements / manifest, but the subscription and
repositories cannot be seen by OrgA OrgB or OrgC. I don't think I have
understood this correctly.
All Orgs have a Development, Test, and Production LifeCycle environment
with different Content views.
When I get to Puppet Environments (Configure -> Puppet -> Environments), I
thought I'd want to have OrgAProd GroupBProd, GroupCProd, etc… through dev
& test, but Orgs can't share the same Environment Name so they'd have to be
specific to the Org. and it seems to get messy when importing environments
- I've imported where I didn't want to a few times and had to go back,
delete, and reimport.
What I think I'm asking is - it seems like the idea is to allow multiple
Groups (Organizations) to use the same Katello interface for management,
how have others used this in practice? Does it work well or is it better
to just have one Katello server for each group?
You are correct in finding that Red Hat subscriptions, and the content they enable, are available only to a single organization. There is discussion about how best to resolve this in the tooling but this design is in very early stage. For now there are two commonly used alternatives:
Divide the subscriptions into multiple manifests in Red Hat's customer portal and import into each org. A downside of this is that content must be sync'ed and managed separately for each org. The upside is that this will allow a clear division of content resources such as lifecycle environments.
Another option is to use a single org with RBAC (roles & permissions) set up appropriately to limit visibility. The upside of this is that content can be sync'ed and managed together where that is useful. The downside is that RBAC must be managed in fine detail to prevent accidental access across orgs, if that is important.
···
----- Original Message -----
>
> Env : Katello 2.1 / Foreman 1.7 on RHEL 7
>
>
> I'm trying to understand the general idea behind Organizations and Puppet
> Environments within Katello and what the best practice is for setup.
>
> Our situation is 3 different Linux admin groups (call them Orgs) would need
> to use this setup. As I understand it, the RedHat Subscriptions can all be
> shared - it's not a problem if they can't, I'm just trying to understand
> how it is intended to be setup. I have "Acme.CO" as an organization which
> has all of the entitlements / manifest, but the subscription and
> repositories cannot be seen by OrgA OrgB or OrgC. I don't think I have
> understood this correctly.
>
> All Orgs have a Development, Test, and Production LifeCycle environment
> with different Content views.
>
> When I get to Puppet Environments (Configure -> Puppet -> Environments), I
> thought I'd want to have OrgAProd GroupBProd, GroupCProd, etc.. through dev
> & test, but Orgs can't share the same Environment Name so they'd have to be
> specific to the Org. and it seems to get messy when importing environments
> - I've imported where I didn't want to a few times and had to go back,
> delete, and reimport.
>
> What I think I'm asking is - it seems like the idea is to allow multiple
> Groups (Organizations) to use the same Katello interface for management,
> how have others used this in practice? Does it work well or is it better
> to just have one Katello server for each group?
>
>
> --
> 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.
>
So on the assumption that we want to cut down on the amount of content sync
and management and there is a reasonable amount of trust and understanding
in the orgs, would another alternative be to setup Lifecycle Environments,
Host Groups, and Puppet Environment with a group prefix :
groupA-production, groupA-test, etc… ?
I see where we could keep some amount of separation with RBAC, but at the
same time, allow all groups under one org and separate all the env's with
group prefix. Is this workable or a bad idea (assuming groups can work
together and not cause unintended consequences.)
···
On Wednesday, March 4, 2015 at 8:42:27 AM UTC-6, Tom McKay wrote:
>
>
>
> You are correct in finding that Red Hat subscriptions, and the content
> they enable, are available only to a single organization. There is
> discussion about how best to resolve this in the tooling but this design is
> in very early stage. For now there are two commonly used alternatives:
>
> So on the assumption that we want to cut down on the amount of content sync
> and management and there is a reasonable amount of trust and understanding
> in the orgs, would another alternative be to setup Lifecycle Environments,
> Host Groups, and Puppet Environment with a group prefix :
> groupA-production, groupA-test, etc… ?
>
> I see where we could keep some amount of separation with RBAC, but at the
> same time, allow all groups under one org and separate all the env's with
> group prefix. Is this workable or a bad idea (assuming groups can work
> together and not cause unintended consequences.)
>
That would be my suggestion, yes, just use naming conventions (with RBAC to assist with helping keep things uncluttered for users that wish to work with subsets of resources).
···
----- Original Message -----
On Wednesday, March 4, 2015 at 8:42:27 AM UTC-6, Tom McKay wrote:
You are correct in finding that Red Hat subscriptions, and the content
they enable, are available only to a single organization. There is
discussion about how best to resolve this in the tooling but this design is
in very early stage. For now there are two commonly used alternatives:
–
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.
