Re: [foreman-dev] Moving foreman-tasks to the core: the plan

2017-01-19 Thread Ewoud Kohl van Wijngaarden 
On Thu, Jan 19, 2017 at 06:04:58PM +0100, Ivan Necas wrote:
> Lukas Zapletal  writes:
> 
> >>
> >> I'm not sure I follow what you mean by administrative tasks. Note that
> >> reports
> >> import and puppet envs import are core actiones that now run as a foreman
> >> task
> >> (both synchronous and asynchronous variants). By making the UI part
> >> optional
> >> users would not be able to monitor their progress, cancel them etc if they
> >> don't install the plugin. What would be the benefit of such setup?
> >>
> >
> > I am not telling not to ship it, but making it optional (but installed by
> > default). Assuming that processes would work normally without the UI part.
> >
> > Other option is to simply move the UI into core, I don't think we should
> > make our decomposition effort a dogma. Let's be realistic.
> >
> > Benefit? Solving the stalemate perhaps :-)
> 
> So the latest updates updates if you don't follow the packaging PR [1]
> 
> The goal right now is to:
> 
>   1. unblock the nightlies
>   2. keep the async operations possible
>   3. prefer proper way over hacks
> 
> Although the goal is to get the foreman-tasks functionality to the core,
> I don't think we can effort blocking nightlies much longer. To preserve
> the async possibility there.
> 
> I'm looking into leveraging ActiveJob interface to define the async
> operations we added. The idea is: when there is no foreman-tasks, the
> in-thread executor, that already is build into Rails, will be used, and
> from the end user, it will behave as before.
> 
> However, when foreman-tasks will be around and configured to be used for
> async processing, the operation will go though that.
> 
> Once this would be done, we could start adding the UI around async
> operations directly to the core: so the foreman-tasks functionality
> would be gradually moved to the core this way: once the core is given certain
> functionality, it can be removed from the tasks.
> 
> The important thing here is we could work on enhancing tasking
> infrastructure in core while still supporting the current foreman-tasks
> users and delivering enhancements there in the meantime.
> 
> I'm setting the deadline for this on Monday EOB. If by that time turns
> our this plan is not feasible, we would need to sacrifice goal 1., 2. or
> 3.

To me this sounds like a good plan.

-- 
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] Is this the new UI style from patternfly?

2017-01-19 Thread Tom McKay 
I was making a role filter and see that the UI table is very different than
other pages[1]. Is this what we should update the katello pages to as well?
I couldn't find equivalent on patternfly.org.

[1]
http://www.awesomescreenshot.com/image/2080169/0a330d7663bc9617fbe28e2ac49b

-- 
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] Community template repository labels

2017-01-19 Thread Ewoud Kohl van Wijngaarden 
https://github.com/theforeman/prprocessor/pull/55 should implement this,
but it's pending the refactor Marek mentioned.

On Mon, Jan 16, 2017 at 09:21:13AM +0100, Marek Hulán wrote:
> Hello,
> 
> labels might help so +1 for that. I plan to send a PR with new directory 
> structure as discussed at [1] soon. It might help the bot to just check the 
> directories of touched files.
> 
> [1] https://groups.google.com/forum/#!topic/foreman-dev/bzfBWEtIMpg
> 
> --
> Marek
> 
> On pátek 13. ledna 2017 10:19:02 CET Eric D Helms wrote:
> > If this will help with getting reviews or directing reviews then sounds all
> > good. The bot could handle this afaik as long as they are predictable which
> > is which.
> > 
> > On Jan 12, 2017 6:26 AM, "Ewoud Kohl van Wijngaarden" <
> > 
> > ew...@kohlvanwijngaarden.nl> wrote:
> > > Hello all,
> > > 
> > > Since there are multiple types of templates in community templates, I
> > > wonder if it's time to (automatically) attach labels to PRs. I was
> > > thinking:
> > > 
> > > * Remote exection
> > > * Provisioning
> > > 
> > > Maybe we need to split up Provisioning into a label per distro.
> > > 
> > > Any thoughts on this? Can the foreman bot be easily modified to do this
> > > for us?
> > > 
> > > --
> > > 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] cosmetic yumrepo issue in foreman-infra causing large amount of cron mail

2017-01-19 Thread Greg Sutcliffe 
On Thursday, 19 January 2017 16:45:00 GMT Ewoud Kohl van Wijngaarden wrote:
> Pretty sure adding a name should be all. I'd recommend the same as the ID
> now to prevent duplicate resources

Thanks, https://github.com/theforeman/foreman-infra/pull/271 submitted.

Greg

-- 
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] Moving foreman-tasks to the core: the plan

2017-01-19 Thread Ivan Necas 
Lukas Zapletal  writes:

>>
>> I'm not sure I follow what you mean by administrative tasks. Note that
>> reports
>> import and puppet envs import are core actiones that now run as a foreman
>> task
>> (both synchronous and asynchronous variants). By making the UI part
>> optional
>> users would not be able to monitor their progress, cancel them etc if they
>> don't install the plugin. What would be the benefit of such setup?
>>
>
> I am not telling not to ship it, but making it optional (but installed by
> default). Assuming that processes would work normally without the UI part.
>
> Other option is to simply move the UI into core, I don't think we should
> make our decomposition effort a dogma. Let's be realistic.
>
> Benefit? Solving the stalemate perhaps :-)

So the latest updates updates if you don't follow the packaging PR [1]

The goal right now is to:

  1. unblock the nightlies
  2. keep the async operations possible
  3. prefer proper way over hacks

Although the goal is to get the foreman-tasks functionality to the core,
I don't think we can effort blocking nightlies much longer. To preserve
the async possibility there.

I'm looking into leveraging ActiveJob interface to define the async
operations we added. The idea is: when there is no foreman-tasks, the
in-thread executor, that already is build into Rails, will be used, and
from the end user, it will behave as before.

However, when foreman-tasks will be around and configured to be used for
async processing, the operation will go though that.

Once this would be done, we could start adding the UI around async
operations directly to the core: so the foreman-tasks functionality
would be gradually moved to the core this way: once the core is given certain
functionality, it can be removed from the tasks.

The important thing here is we could work on enhancing tasking
infrastructure in core while still supporting the current foreman-tasks
users and delivering enhancements there in the meantime.

I'm setting the deadline for this on Monday EOB. If by that time turns
our this plan is not feasible, we would need to sacrifice goal 1., 2. or
3.

-- Ivan

[1] 
https://github.com/theforeman/foreman-packaging/pull/1436#issuecomment-273780029

>
>
>> Moving the code into core code base might take time until it's reviewed and
>> merged. The workaround would get nightly builds back before the code is
>> moved.
>>
>
> Oh that :-D Sure.
>
> -- 
> 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] cosmetic yumrepo issue in foreman-infra causing large amount of cron mail

2017-01-19 Thread Ewoud Kohl van Wijngaarden 
Pretty sure adding a name should be all. I'd recommend the same as the ID now 
to prevent duplicate resources

> On 19 Jan 2017, at 16:29, Greg Sutcliffe  wrote:
> 
> I'm getting a lot of mails from the slaves at the moment like the one below. 
> I'm not super-familiar with the 'yumrepo' puppet resource, but does it just 
> need a 'name' parameter added to this block?
> 
> https://github.com/theforeman/foreman-infra/blob/master/puppet/modules/slave/
> manifests/init.pp#L226
> 
> Or is it more than that? Happy to send a trivial PR if thats all it is.
> 
> Greg
> 
> --  Forwarded Message  --
> 
> Subject: Cron  run-parts /etc/cron.hourly
> Date: Thursday, 19 January 2017, 16:14:35 GMT
> From: (Cron Daemon) 
> To: r...@slave02.rackspace.theforeman.org
> 
> /etc/cron.hourly/0yum-hourly.cron:
> 
> Repository 'isimluk-openscap' is missing name in configuration, using id
> 
> -
> 
> --
> IRC / Twitter: gwmngilfen
> Diaspora: gwmngil...@joindiaspora.com
> 
> -- 
> 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.

[foreman-dev] cosmetic yumrepo issue in foreman-infra causing large amount of cron mail

2017-01-19 Thread Greg Sutcliffe 
I'm getting a lot of mails from the slaves at the moment like the one below. 
I'm not super-familiar with the 'yumrepo' puppet resource, but does it just 
need a 'name' parameter added to this block?

https://github.com/theforeman/foreman-infra/blob/master/puppet/modules/slave/
manifests/init.pp#L226

Or is it more than that? Happy to send a trivial PR if thats all it is.

Greg

--  Forwarded Message  --

Subject: Cron  run-parts /etc/cron.hourly
Date: Thursday, 19 January 2017, 16:14:35 GMT
From: (Cron Daemon) 
To: r...@slave02.rackspace.theforeman.org

/etc/cron.hourly/0yum-hourly.cron:

Repository 'isimluk-openscap' is missing name in configuration, using id

-

--
IRC / Twitter: gwmngilfen
Diaspora: gwmngil...@joindiaspora.com

-- 
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] Puppetdb Plugin Options Update .

2017-01-19 Thread Ewoud Kohl van Wijngaarden 
On Mon, Jan 16, 2017 at 03:01:23AM -0800, Karen Harutyunyan wrote:
> PuppetDB plugin has new version which bring a lot of interesting parameters 
> to get puppetdb.4.3 working properly . like ssl-ca and etc. Please can 
> someone send me docs how to add (or create pull request) to this params. If 
> you have time enough to do that it`s also perfect for me .

https://github.com/theforeman/puppet-foreman/commit/c12169e8f6b13b05a6f70074078ce4ede78b5d6e
fixes this and is part of puppet-foreman 7.1.0.

-- 
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-19 Thread Marek Hulán 
On úterý 17. ledna 2017 14:45:53 CET Ondrej Prazak wrote:
> 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.

Or use the flag the same way as you describe below so it would happen only 
once, basically when you install the plugin?

> 
> > > # 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.

The flag would have to be on the permission - role association I guess and it 
would have to persist even after it's removal. For other resources in seeds we 
abuse audits for this, if audit exists, we don't touch the resource.

> 
> > > 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