hello,
I am looking for procedure where i can have my application team's puppet
repository and INFRA puppet repository and both are applied to some hosts,
now i want to put control where my application team cant remove puppet
classes applied to hosts and they can work on only their puppet modules (
add class to host, remove class from host, edit parameters for those
classes and so on)…
i checked filters in katello but did not find it working, does anyone have
any suggestion for me ?
I know i can create separate CVs for both and manage uploads separately but
still adding classes to hosts makes it difficult as user can remove INFRA
classes and they are not suppose to remove.
Regards,
DJ
> hello,
>
> I am looking for procedure where i can have my application team's puppet
> repository and INFRA puppet repository and both are applied to some hosts,
> now i want to put control where my application team cant remove puppet
> classes applied to hosts and they can work on only their puppet modules (
> add class to host, remove class from host, edit parameters for those
> classes and so on)…
>
I'm not sure if this is possible to do with the existing model at all,
giving users (the application team) permissions to edit a host in
Foreman will mean giving them access to control any applied puppet class.
> i checked filters in katello but did not find it working, does anyone have
> any suggestion for me ?
>
> I know i can create separate CVs for both and manage uploads separately but
> still adding classes to hosts makes it difficult as user can remove INFRA
> classes and they are not suppose to remove.
This is your best bet in my opinion (and very creative), although that problem
of removing classes remains as as long as you give users access to edit hosts.
···
On 03/19, Unix SA wrote:
>
> Regards,
> DJ
>
> --
> You received this message because you are subscribed to the Google Groups "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
–
Daniel Lobato Garcia
@eLobatoss
blog.daniellobato.me
daniellobato.me
GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30
Keybase: https://keybase.io/elobato
Hello,
I have to give users access to Hosts for them to be able to
remove/update/add classes belongs to their application group, if they will
create some puppet modules it's good practice they themselves can
add/remove/update on hosts they have given access to…
looks this is not possible with current design, then Allowing granular
level of access control to host will be of limited use.
one more issue is , i have separate CV for my application team for their
puppet modules and they manage it themselves, but when i assign that CV to
my host, i loose my INFRA CV and all classes from that CV 
( i know CCV
will help in that case ) but then they can add/remove/update any puppet
class
Regards,
Dhaval
···
On Sunday, 22 March 2015 13:25:06 UTC+5:45, Daniel Lobato wrote:
>
> On 03/19, Unix SA wrote:
> > hello,
> >
> > I am looking for procedure where i can have my application team's puppet
> > repository and INFRA puppet repository and both are applied to some
> hosts,
> > now i want to put control where my application team cant remove puppet
> > classes applied to hosts and they can work on only their puppet modules
> (
> > add class to host, remove class from host, edit parameters for those
> > classes and so on)..
> >
> I'm not sure if this is possible to do with the existing model at all,
> giving users (the application team) permissions to edit a host in
> Foreman will mean giving them access to control any applied puppet class.
> > i checked filters in katello but did not find it working, does anyone
> have
> > any suggestion for me ?
> >
> > I know i can create separate CVs for both and manage uploads separately
> but
> > still adding classes to hosts makes it difficult as user can remove
> INFRA
> > classes and they are not suppose to remove.
> This is your best bet in my opinion (and very creative), although that
> problem
> of removing classes remains as as long as you give users access to edit
> hosts.
> >
> > Regards,
> > DJ
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "foreman-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to foreman-dev...@googlegroups.com .
> > For more options, visit https://groups.google.com/d/optout.
>
>
> --
> Daniel Lobato Garcia
>
> @eLobatoss
> blog.daniellobato.me
> daniellobato.me
>
> GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30
> Keybase: https://keybase.io/elobato
>
