I wonder how people using multiple organizations in Foreman manage their
puppet modules. Let's assume I have two organizations A and B and I want them
to be isolated as much as possible. Since puppet environments can be scoped to
organization, we can have separate environments for each organization. Well,
as long as they have unique name, since the validation prevents to have two
environments with the same name even if they are in different organizations.
But the bigger issue seems to be is how puppet classes should work, since they
are not scoped to organizations. When user in organization B tries to import
the class with the same name that users from organization A already imported,
it fails saying the name has already been taken. In theory the organization
should be clear from environment but what if I have two separate environments
for organizations and they want to use same puppet module? And what if their
puppet modules have different versions so the smart class parameters differs?
And does using katello content views with puppet modules helps in this case?
It creates different puppet environment for each content view version but is
there the same problem for puppet class name collision?
Is there some workflow I'm missing? If you have such use case but yout (same
as me) can't solve it with Foreman, how would you change Foreman so it
fulfills your needs?
We have a similar problem. There was a post by me a while back which
discussed this. Basically, Foreman assumes an environment has a set of
classes, regardless of what puppet master that environment exists in. So
to solve this for us, we are deploying environments specific to puppet
masters by organization.
In your example, with ORGA and ORGB, we would have environments named
orgaprod, orgadev, orgbprod, orgbdev, and the "common" module directory
that foreman deploys as an environment set to be ignored by foreman but
still in the modulepath. We deploy enterprise level modules to the common
module dir, then let the org's admins manage their org specific
environments.
I can't say it works great just yet, because we are trying to fit this into
an existing environment. It has worked very well in clean test labs where
nothing pre-existing was setup.
···
On Wednesday, March 1, 2017 at 9:56:23 AM UTC-5, Marek Hulán wrote:
>
> Hello Foreman users,
>
> I wonder how people using multiple organizations in Foreman manage their
> puppet modules. Let's assume I have two organizations A and B and I want
> them
> to be isolated as much as possible. Since puppet environments can be
> scoped to
> organization, we can have separate environments for each organization.
> Well,
> as long as they have unique name, since the validation prevents to have
> two
> environments with the same name even if they are in different
> organizations.
>
> But the bigger issue seems to be is how puppet classes should work, since
> they
> are not scoped to organizations. When user in organization B tries to
> import
> the class with the same name that users from organization A already
> imported,
> it fails saying the name has already been taken. In theory the
> organization
> should be clear from environment but what if I have two separate
> environments
> for organizations and they want to use same puppet module? And what if
> their
> puppet modules have different versions so the smart class parameters
> differs?
>
> And does using katello content views with puppet modules helps in this
> case?
> It creates different puppet environment for each content view version but
> is
> there the same problem for puppet class name collision?
>
> Is there some workflow I'm missing? If you have such use case but yout
> (same
> as me) can't solve it with Foreman, how would you change Foreman so it
> fulfills your needs?
>
> Thanks for any suggestions
>
> --
> Marek
>
Thanks for the answer, definitely worth investigating. I suppose in this case
where you put shared modules into ignored common env, you can't have two
different versions of the same module for each org. Or did I miss something?
Anyway it's a good start.
···
--
Marek
On středa 1. března 2017 13:59:56 CET Sean A wrote:
Hi,
We have a similar problem. There was a post by me a while back which
discussed this. Basically, Foreman assumes an environment has a set of
classes, regardless of what puppet master that environment exists in. So
to solve this for us, we are deploying environments specific to puppet
masters by organization.
In your example, with ORGA and ORGB, we would have environments named
orgaprod, orgadev, orgbprod, orgbdev, and the “common” module directory
that foreman deploys as an environment set to be ignored by foreman but
still in the modulepath. We deploy enterprise level modules to the common
module dir, then let the org’s admins manage their org specific
environments.
I can’t say it works great just yet, because we are trying to fit this into
an existing environment. It has worked very well in clean test labs where
nothing pre-existing was setup.
On Wednesday, March 1, 2017 at 9:56:23 AM UTC-5, Marek Hulán wrote:
Hello Foreman users,
I wonder how people using multiple organizations in Foreman manage their
puppet modules. Let’s assume I have two organizations A and B and I want
them
to be isolated as much as possible. Since puppet environments can be
scoped to
organization, we can have separate environments for each organization.
Well,
as long as they have unique name, since the validation prevents to have
two
environments with the same name even if they are in different
organizations.
But the bigger issue seems to be is how puppet classes should work, since
they
are not scoped to organizations. When user in organization B tries to
import
the class with the same name that users from organization A already
imported,
it fails saying the name has already been taken. In theory the
organization
should be clear from environment but what if I have two separate
environments
for organizations and they want to use same puppet module? And what if
their
puppet modules have different versions so the smart class parameters
differs?
And does using katello content views with puppet modules helps in this
case?
It creates different puppet environment for each content view version but
is
there the same problem for puppet class name collision?
Is there some workflow I’m missing? If you have such use case but yout
(same
as me) can’t solve it with Foreman, how would you change Foreman so it
fulfills your needs?
Foreman Installer sets the module path
I believe the environment module path takes precedence over those paths…
so if you have multiple versions of a module in the path and the
environment, it's the environment's module that gets discovered in foreman.
It's been a while since I've run into that situation, but that's how I
remember it working.
···
to: /etc/puppet/environments/common:/etc/puppet/modules:/usr/share/puppet/modules.
On Monday, March 6, 2017 at 2:15:54 AM UTC-5, Marek Hulán wrote:
Thanks for the answer, definitely worth investigating. I suppose in this
case
where you put shared modules into ignored common env, you can’t have two
different versions of the same module for each org. Or did I miss
something?
Anyway it’s a good start.
–
Marek
On středa 1. března 2017 13:59:56 CET Sean A wrote:
Hi,
We have a similar problem. There was a post by me a while back which
discussed this. Basically, Foreman assumes an environment has a set of
classes, regardless of what puppet master that environment exists in.
So
to solve this for us, we are deploying environments specific to puppet
masters by organization.
In your example, with ORGA and ORGB, we would have environments named
orgaprod, orgadev, orgbprod, orgbdev, and the “common” module directory
that foreman deploys as an environment set to be ignored by foreman but
still in the modulepath. We deploy enterprise level modules to the
common
module dir, then let the org’s admins manage their org specific
environments.
I can’t say it works great just yet, because we are trying to fit this
into
an existing environment. It has worked very well in clean test labs
where
nothing pre-existing was setup.
On Wednesday, March 1, 2017 at 9:56:23 AM UTC-5, Marek Hulán wrote:
Hello Foreman users,
I wonder how people using multiple organizations in Foreman manage
their
puppet modules. Let’s assume I have two organizations A and B and I
want
them
to be isolated as much as possible. Since puppet environments can be
scoped to
organization, we can have separate environments for each organization.
Well,
as long as they have unique name, since the validation prevents to
have
two
environments with the same name even if they are in different
organizations.
But the bigger issue seems to be is how puppet classes should work,
since
they
are not scoped to organizations. When user in organization B tries to
import
the class with the same name that users from organization A already
imported,
it fails saying the name has already been taken. In theory the
organization
should be clear from environment but what if I have two separate
environments
for organizations and they want to use same puppet module? And what if
their
puppet modules have different versions so the smart class parameters
differs?
And does using katello content views with puppet modules helps in this
case?
It creates different puppet environment for each content view version
but
is
there the same problem for puppet class name collision?
Is there some workflow I’m missing? If you have such use case but yout
(same
as me) can’t solve it with Foreman, how would you change Foreman so it
fulfills your needs?
