Re: [foreman-dev] Foreman plugin accessing katello host data like asigned content view

2017-01-17 Thread Daniel Kuffner 

Great, going to dig into the docker plugin first.
thank you,
Daniel

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] undefined method `sub!' for nil:NilClass on foreman 1.14

2017-01-17 Thread James Perry 
Here is the stack trace. It clearly shows the error is in Cockpit. 

*NoMethodError*
*undefined method `sub!' for nil:NilClass*
/opt/theforeman/tfm/root/usr/share/gems/gems/foreman_cockpit-2.0.2/app/controllers/concerns/foreman_cockpit/hosts_controller_extensions.rb:26:in
 
`allow_cockpit_iframe'
/opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:432:in
 
`block in make_lambda'
/opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:145:in
 
`call'
/opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:145:in
 
`block in halting_and_conditional'
/opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:504:in
 
`call'
/opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:504:in
 
`block in call'
/opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:504:in
 
`each'
/opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:504:in
 
`call'
/opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:498:in
 
`block (2 levels) in around'
/opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:313:in
 
`call'
/opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:313:in
 
`block (2 levels) in halting'
/opt/theforeman/tfm/root/usr/share/gems/gems/rails-observers-0.1.2/lib/rails/observers/action_controller/caching/sweeping.rb:73:in
 
`around'
/opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:455:in
 
`public_send'
/opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:455:in
 
`block in make_lambda'
/opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:312:in
 
`call'
/opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:312:in
 
`block in halting'
/opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:497:in
 
`call'
/opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:497:in
 
`block in around'
/opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:505:in
 
`call'
/opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:505:in
 
`call'
/opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:498:in
 
`block (2 levels) in around'
/opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:313:in
 
`call'
/opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:313:in
 
`block (2 levels) in halting'
/usr/share/foreman/app/controllers/concerns/application_shared.rb:14:in 
`set_timezone'
/opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:432:in
 
`block in make_lambda'
/opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:312:in
 
`call'
/opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:312:in
 
`block in halting'
/opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:497:in
 
`call'
/opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:497:in
 
`block in around'
/opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:505:in
 
`call'
/opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:505:in
 
`call'
/opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:498:in
 
`block (2 levels) in around'
/opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:313:in
 
`call'
/opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:313:in
 
`block (2 levels) in halting'
/usr/share/foreman/app/models/concerns/foreman/thread_session.rb:32:in 
`clear_thread'
/opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:432:in
 
`block in make_lambda'
/opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:312:in
 
`call'
/opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:312:in
 
`block in halting'
/opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:497:in
 
`call'

Re: [foreman-dev] undefined method `sub!' for nil:NilClass on foreman 1.14

2017-01-17 Thread James Perry 
Any updates or details on how you removed the cockpit plugin?  I have 
disabled it in my Foreman 1.14 but it is still giving the error. 

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[foreman-dev] Rubocop enhancements for foreman plugins - your opinion is needed

2017-01-17 Thread sshtein 

As we all know, foreman core uses rubocop for enforcing style rules. Many 
plugins, especially those that are in theforeman organization, use rubocop 
too.
The problem is, that the rules are not unified between foreman core and 
plugins. In addition to that when rubocop version changes in core, core's 
rules change accordingly, but plugins remain often with the old ruleset for 
no reason.

I am suggesting inheriting foreman's ruleset as a base ruleset for plugins.
I have found two ways to accomplish that:

   1. Rubocop has an option to inherit a remote URL [1] 
   
,
 
   so we can point a plugin to github URL for foreman master ruleset [2] 
   . 
   
   Advantages: it's simple. 
   Disadvantages: You have to be connected in order to download the file 
   (Although rubocop has caching mechanism for it)
   2. We can utilize another Rubocop config option: inheriting the settings 
   from a gem [3] 
   
.
 
   This will require us to create a special development gem, that would be 
   used by foreman core and plugins. This gem will contain a proper ruleset.
   I am a bit biased, since I have already started foreman_devel plugin [4] 
    that should help plugin 
   developers in multiple tasks.
   Advantages: It's a plugin that can do a lot more than just ruleset repo. 
   It's versioned properly. It's offline, once you have the gem installed.
   Disadvantages: Extra gem. Installation is more complicated. Affects the 
   core too

I would like to hear your opinions about the issue. Both whether you like 
the basic idea of inheriting the same ruleset and if so, which is the 
preferred way to go.

Shim,



[1] 
https://github.com/bbatsov/rubocop/blob/master/manual/configuration.md#inheriting-configuration-from-a-remote-url
[2] 
https://raw.githubusercontent.com/theforeman/foreman/develop/.rubocop.yml
[3] 
https://github.com/bbatsov/rubocop/blob/master/manual/configuration.md#inheriting-configuration-from-a-dependency-gem
[4] https://github.com/ShimShtein/foreman_devel

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] Foreman plugin accessing katello host data like asigned content view

2017-01-17 Thread Eric D Helms 
If there is any specific data that you aren't sure about, feel free to ping
and ask here. Ruby allows you access to almost anything, and there are
certainly some better practices we've discovered over the years for how and
where to do this access to reduce the chance of breakage between releases.

We would also find it interesting to see where and what you';d like
"supported" access to in case that presents an opportunity to build a
supported API for plugin access to Katello.


Eric

On Tue, Jan 17, 2017 at 6:39 AM, Daniel Lobato Garcia 
wrote:

> On 01/16, Daniel Kuffner wrote:
> > Hi All,
> >
> > I'm generally interested if it is possible to access from within a
> > foreman_plugin data from Katello plugin (plugin accesses data from other
> > plugin).
> > For example I would like to extract the content-view/asigned repository
> > information for a given host.
>
> Yes, after initialization your plugin should be able to access all
> katello properties.
>
> The foreman-docker plugin for instance does different things depending
> on whether Katello is available or not, like in:
>
> github.com/theforeman/foreman-docker/blob/master/app/views/
> containers/steps/image.html.erb
>
> >
> > regards,
> > Daniel
> >
> > --
> > 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+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
>
> --
> Daniel Lobato Garcia
>
> @dLobatog
> blog.daniellobato.me
> daniellobato.me
>
> GPG: http://keys.gnupg.net/pks/lookup?op=get=0x7A92D6DD38D6DE30
> Keybase: https://keybase.io/elobato
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Eric D. Helms
Red Hat Engineering

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] Opinions from plugin maintainers wanted: permissions and roles

2017-01-17 Thread Lukas Zapletal 
On Mon, Jan 16, 2017 at 6:55 PM, oprazak  wrote:
> So if a plugin is installed, user has to go and find what role/permission is
> missing or ask someone who can grant permissions.

I do not think the proposed approach is the best, here is my lengthy
explanation:

https://github.com/theforeman/foreman/pull/4168#issuecomment-273187422

-- 
Later,
  Lukas @lzap Zapletal

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] Opinions from plugin maintainers wanted: permissions and roles

2017-01-17 Thread Ondrej Prazak 
On Tue, Jan 17, 2017 at 12:08 PM, Tomas Strachota 
wrote:

> On Mon, Jan 16, 2017 at 6:55 PM, oprazak  wrote:
> > Hi,
> > I recently started identifying problematic areas in Permissions and
> Roles,
> > especially with regard to plugins. Foreman provides 'Viewer' and
> 'Manager'
> > roles out of the box and users expect these roles to work for plugins as
> > well. But plugins generally do not add their permissions to core's roles,
> > some of them just have their own plugin-specific roles, some not. So if a
> > plugin is installed, user has to go and find what role/permission is
> missing
> > or ask someone who can grant permissions.
> >
> > After a brief discussion in team C, it was decided that plugins should
> add
> > their permissions to 'Manager' role and their 'view_' permissions to
> > 'Viewer' role. They should also keep their plugin-specific roles (or
> create
> > them) for higher granularity and backward compatibility.
> > I started initial work which should allow plugin maintainers to do this,
> it
> > can be found at [1]. I decided to create 2 methods that would be called
> from
> > Engine, but we could take a different approach and add permissions from
> > plugins automatically by modifying the 'permission' method that is called
> > from 'security_block'.
> >
> > The way I see things:
> >
> > * adding permissions explicitly, using DSL
> >   - extra work for plugin maintainers
> >   - permissions can be ommited/forgotten
> >  # can be covered with tests? something like the already existing
> > AccessPermissionsTest
> >   - extra code in Engine
> >   - better control, can handle special cases
> >
> > * adding permissions automatically without plugin knowing about it by
> > modifying 'permission' method
> >   - no need for plugin maintainers to do anything
> >   - cannot handle special cases
> >   - if user removes permission from these default roles, there is no way
> to
> > detect it and permissions get added again on server restart
>
> I'm afraid this could be quite frustrating if you try to modify your
> roles. I'm not entirely sure what part of permissions is stored in the
> db and what is in the code, but would it be possible to add
> permissions during seed and don't touch it on server start?
>

   All permissions are in db and plugins get loaded before migration runs,
so it should be possible I think. Seems much better (and less frustrating
for users) than resetting to initial state on each restart,
  the downside is you will need a migration each time you introduce new
permissions.


>
> > # users do not modify default roles, they can clone it and modify the
> > cloned one
> > # if the default roles are not meant to be modified, they should be
> > 'frozen' and user should not be able to modify them, implementing this
> would
> > add code and complexity
>
> Even though it's more work for plugin maintainers I prefer option A
> because it gives you more control over what gets added.
>
> BTW how would both approaches behave on migration of existing
> installations? Would it add the permissions too?
>

  Yes, both would add the permissions, forgot to mention that they are
added on each restart for the case A as well :-(
  Maybe we could add some sort of 'dirty' flag on the role, as in: when
modified by user, do not touch this role. But then it would not add
permissions when plugins were installed after role was modified. Tricky.


>
> >
> > Anything that I have missed? Where do you stand as a plugin maintainers?
> Can
> > you think of other ways to go?
> >
> > Ondra
> >
> > [1] https://github.com/theforeman/foreman/pull/4168
> >
> > --
> > 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+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] Foreman plugin accessing katello host data like asigned content view

2017-01-17 Thread Daniel Lobato Garcia 
On 01/16, Daniel Kuffner wrote:
> Hi All,
>
> I'm generally interested if it is possible to access from within a
> foreman_plugin data from Katello plugin (plugin accesses data from other
> plugin).
> For example I would like to extract the content-view/asigned repository
> information for a given host.

Yes, after initialization your plugin should be able to access all
katello properties.

The foreman-docker plugin for instance does different things depending
on whether Katello is available or not, like in:

github.com/theforeman/foreman-docker/blob/master/app/views/containers/steps/image.html.erb

>
> regards,
> Daniel
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.


--
Daniel Lobato Garcia

@dLobatog
blog.daniellobato.me
daniellobato.me

GPG: http://keys.gnupg.net/pks/lookup?op=get=0x7A92D6DD38D6DE30
Keybase: https://keybase.io/elobato

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [foreman-dev] Opinions from plugin maintainers wanted: permissions and roles

2017-01-17 Thread Tomas Strachota 
On Mon, Jan 16, 2017 at 6:55 PM, oprazak  wrote:
> Hi,
> I recently started identifying problematic areas in Permissions and Roles,
> especially with regard to plugins. Foreman provides 'Viewer' and 'Manager'
> roles out of the box and users expect these roles to work for plugins as
> well. But plugins generally do not add their permissions to core's roles,
> some of them just have their own plugin-specific roles, some not. So if a
> plugin is installed, user has to go and find what role/permission is missing
> or ask someone who can grant permissions.
>
> After a brief discussion in team C, it was decided that plugins should add
> their permissions to 'Manager' role and their 'view_' permissions to
> 'Viewer' role. They should also keep their plugin-specific roles (or create
> them) for higher granularity and backward compatibility.
> I started initial work which should allow plugin maintainers to do this, it
> can be found at [1]. I decided to create 2 methods that would be called from
> Engine, but we could take a different approach and add permissions from
> plugins automatically by modifying the 'permission' method that is called
> from 'security_block'.
>
> The way I see things:
>
> * adding permissions explicitly, using DSL
>   - extra work for plugin maintainers
>   - permissions can be ommited/forgotten
>  # can be covered with tests? something like the already existing
> AccessPermissionsTest
>   - extra code in Engine
>   - better control, can handle special cases
>
> * adding permissions automatically without plugin knowing about it by
> modifying 'permission' method
>   - no need for plugin maintainers to do anything
>   - cannot handle special cases
>   - if user removes permission from these default roles, there is no way to
> detect it and permissions get added again on server restart

I'm afraid this could be quite frustrating if you try to modify your
roles. I'm not entirely sure what part of permissions is stored in the
db and what is in the code, but would it be possible to add
permissions during seed and don't touch it on server start?

> # users do not modify default roles, they can clone it and modify the
> cloned one
> # if the default roles are not meant to be modified, they should be
> 'frozen' and user should not be able to modify them, implementing this would
> add code and complexity

Even though it's more work for plugin maintainers I prefer option A
because it gives you more control over what gets added.

BTW how would both approaches behave on migration of existing
installations? Would it add the permissions too?

>
> Anything that I have missed? Where do you stand as a plugin maintainers? Can
> you think of other ways to go?
>
> Ondra
>
> [1] https://github.com/theforeman/foreman/pull/4168
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] New community-templates structure

2017-01-17 Thread Marek Hulán 
On čtvrtek 8. prosince 2016 16:58:24 CET Greg Sutcliffe wrote:
> Oh, another thought, possibly half-baked - is there any impact on backwards
> compatibility? IIRC foreman_templates doesn't actually care about the
> directory structure (it's a **/*erb glob) but perhaps I've overlooked
> something?

Sorry for late answer, the new structure should work with foreman_templates 
just fine. Foreman core has a list of files it seeds, I'm happy to provide a 
PR for it with new paths [1] if we change the structure in core too but we 
could start seeding all we have there since we'd have metadata for each 
template.

[1] 
https://github.com/theforeman/foreman/blob/develop/db/seeds.d/07-provisioning_templates.rb#L21

--
Marek

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.