Re: [foreman-dev] Dropping Ruby 2.0 support in 1.16?

[Stephen Benjamin]

On Wed, May 17, 2017 at 10:45 AM, Michael Moll  wrote:
> Hi,
>
> On Wed, May 17, 2017 at 03:11:12PM +0300, Tomer Brisker wrote:
>> What do people think about dropping it in 1.16? This will still give people
>> enough time to upgrade their systems as 1.15 will still be supported for
>> the next 6 months.
>
> +1 on dropping 2.0 support for Foreman core.
> --

For the installer, we're going to be in the same painful situation as
we were with 1.8.7.  EL7 still
has quite a few years left, what are the chances to get it inside SCL
or (urgh) fully into Puppet
AIO ruby environment?

-- 
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-installer ansible role

[Stephen Benjamin]

On Thu, May 18, 2017 at 7:57 AM, Sean O'Keeffe  wrote:
> Hey guys!
>
> I have a foreman-installer Ansible role[1], its really flexible and works by
> merging a hash of custom parameters with the default ones defined in the
> scenario's answer file.
> I would quite like to move it to theforeman Github organisation and publish
> it in Ansible galaxy under TheForeman name if people agree ?
>
> My use case was for configuring a foreman cluster.

There is one in Forklift already:
  
https://github.com/theforeman/forklift/tree/master/playbooks/roles/foreman_installer

If there's features that yours has that this one doesn't maybe we could merge
them together and then release it on Ansible galaxy.

- Stephen



> [1] https://github.com/sean797/ansible-role-foreman_installer
>
> --
> 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-hooks with plugins

[Stephen Benjamin]

See: http://projects.theforeman.org/issues/8379, also
https://github.com/theforeman/foreman_hooks/pull/17.  Maybe someone
wants to have another try?

On Mon, Apr 24, 2017 at 5:53 PM, Tom McKay  wrote:
> I'd like to make the katello pool model export api json via rabl but the
> path is incorrect. I'm not sure what the correct solution is, though. Should
> plugin models register their rabl path or something?
>
> There isn't a redmine category for foreman-hooks plugin, where do issues go?
>
> http://projects.theforeman.org/issues/19367
>
>
> --
> 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] Nominating Daniel Lobato for commiter to release related tasks

[Stephen Benjamin]

+1, see other comments below


On Mon, Apr 24, 2017 at 8:47 AM, Tomer Brisker  wrote:
> +1
>
> On Mon, Apr 24, 2017 at 2:59 PM, Marek Hulán  wrote:
>>
>> Hello devs,
>>
>> based on our handbook [1]. I'd like to nominate Daniel for commit access
>> to
>> the following repositories:
>>
>>  - foreman-infra
>>  - foreman-installer
>>  - foreman-packaging ( to branch and cherry-pick to the release branch )
>>
>> Daniel contributes to the project for a long time, also in this area
>> [2][3][4]
>> and always has only the best intentions. He worked on 1.15 RC1 and I think
>> there's no reason why he shouldn't have access to places which are needed
>> to
>> update during the release process.
>>
>> Also I'd like to nominate him for the following.
>>
>>  - access to deb.theforeman.org to change stable, clone repos, and
>> run freight cache
>>  - add tags and build targets in koji
>>  - access to koji.katello.org to copy the mash scripts and configuration

See: http://projects.theforeman.org/projects/foreman/wiki/Koji

E-mail tmlc...@redhat.com or jbla...@redhat.com to get Koji
certificates, and probably CC someone who already has Katello Koji
access so they can confirm? I don't see we have actual guidelines
about who should get access.


>>  - access to downloads.theforeman.org to upload signed tarballs
>>  - permission to set /topic on IRC

It would be really useful to have more people with access to IRC in
general.  It's not frequent, but occasionally during non-emea hours
there's someone flooding the channel with join/quits or some other
behavior that might need an op to take care of.  So +1 to Daniel but
it'd be nice if some people in North America had access too.

>>  - redmine permissions to modify fields http://projects.theforeman.org/
>> custom_fields/4/edit (I think administrator permission is required)
>>
>> The process for getting this is not documented anywhere, but I think it's
>> clear that Daniel would only use all of this to improve Foreman.
>>
>> Please thumbs up in the thread. I'll update the thread in one week in case
>> there were some private concerns.
>>
>> [1] https://theforeman.org/handbook.html#Becomingamaintainer
>> [2] https://github.com/theforeman/foreman-packaging/pulls?q=is%3Apr+is
>> %3Aclosed+author%3Adlobatog
>> [3] https://github.com/theforeman/foreman-installer/pulls?q=is%3Apr+is
>> %3Aclosed+author%3Adlobatog
>> [4]
>> https://github.com/theforeman/foreman-infra/pulls?q=is%3Apr+is%3Aclosed
>> +author%3Adlobatog
>>
>> --
>> 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.
>
>
>
>
> --
> Have a nice day,
> Tomer Brisker
> 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.

-- 
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] Customizing the installer's configuration

[Stephen Benjamin]

Hi all,

It's been a long standing issue that installer users who try to alter
Foreman settings end up surprised when those changes get wiped out
when they upgrade (by running the installer again).  Many things can
be set by installer flags, but not all.

Most recently we added the ability to interface directly with Hiera in
/etc/foreman/custom-hiera.yaml
(https://theforeman.org/manuals/1.14/index.html#advanced-module-configuration)
which greatly opens up the configuration to customization.

However, there's still a few limitations with this, particularly if
you need to instantiate a new resource. A good example is wanting to
tune postgresql configuration which uses the
`postgresql::server::config_entry` defined type.

You can get around it this by using the foreman puppet classes
directly and then including a class of your own with the additional
config.  But what if you want to use the installer?

Should we deal with these on a case-by-case basis - maybe make
specific postgresql settings accessible in puppet-foreman flags or
take a hash of them in the module?

The other thing I was thinking - and I'm not sure if this is overkill
- is giving the user a directory to dump their own custom puppet
modules in, and then using the custom-hiera.yaml feature to include
them.

Thoughts/ideas would be much appreciated.


Thanks

Stephen

-- 
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] Seeding templates overrides custom changes - should we lock templates we ship?

[Stephen Benjamin]

Oh :-(

It looks like the fix would be just to pass the `template` attribute
to  audit_modified?, it can check other attributes than name.

But locking the templates we ship would be preferable to me.


- Stephen

On Fri, Feb 17, 2017 at 9:04 AM, Marek Hulán  wrote:
> Hello foreman-devs,
>
> recently I was told about the bug that we override all templates in database
> whenever we run db:seed. From the code [1] and commit message [2], it was not
> the intended behavior. It was supposed to check whether user made some changes
> and only apply the new version if the template was not touched. Sadly, the
> method only checks the name attribute for changes [3], so if "only" template
> content was changed, we still override it.
>
> While I can try to fix it to originally intended behavior, I'd like to ask
> whether it wouldn't be better to use this opportunity and start locking
> templates we ship by default. The recommended workflow for users would be to
> clone the template if custom changes are needed. We'd always update locked
> templates. Obviously, user would need to merge new version to cloned template
> on his own. With foreman_templates plugin it should be easy enough to export
> templates and see the diff between default and customized template, apply the
> changes user wants and then reimport them back.
>
> I think this would be overall better user experience and safer workflow. The
> originally intended behavior would never update a template that user modified.
> That means after update user ends up with template from old Foreman version
> (with custom changes) that might not be compatible with the new Foreman
> version. This is more likely to happen than before because we now version
> templates in community-repo and we don't keep backward compatibility as we did
> before.
>
> Thanks for reading, thoughts?
>
> [1] 
> https://github.com/theforeman/foreman/blob/1.14.0/db/seeds.d/07-provisioning_templates.rb#L98
> [2] https://github.com/theforeman/foreman/commit/
> d4ed70154fa9f6c83597adc784240e3865845563
> [3] https://github.com/theforeman/foreman/blob/1.14-stable/db/seeds.rb#L33
>
> --
> 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.

-- 
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] Draft community survey questions

[Stephen Benjamin]

Also "Smart proxy, Hammer & API" page - I think maybe adding "Katello"
in parens next to smart_proxy_pulp might help people know what it's
for. I doubt most Katello users are aware of the plugin name on the
smart proxy side.



On Fri, Jan 20, 2017 at 3:49 PM, Stephen Benjamin <step...@redhat.com> wrote:
> The 1 to 5 selectors don't seem to be working correctly, it's not a
> preference order right?
>
> On Fri, Jan 20, 2017 at 11:56 AM, Greg Sutcliffe
> <greg.sutcli...@gmail.com> wrote:
>> On Friday, 20 January 2017 06:45:16 GMT Duncan Innes wrote:
>>> On page 4, I can only select one Compute Resource when question asks
>>> "select all that apply".  Same for selecting which features I use on my
>>> Smart Proxies and which Smart Proxy plugins I use on page 5.
>>>
>>> Should't these three inputs be checkboxes instead of radio buttons?
>>
>> You are correct - the dangers of cut'n'paste. Should be fixed now, thanks!
>>
>> 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.

-- 
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] Draft community survey questions

[Stephen Benjamin]

The 1 to 5 selectors don't seem to be working correctly, it's not a
preference order right?

On Fri, Jan 20, 2017 at 11:56 AM, Greg Sutcliffe
 wrote:
> On Friday, 20 January 2017 06:45:16 GMT Duncan Innes wrote:
>> On page 4, I can only select one Compute Resource when question asks
>> "select all that apply".  Same for selecting which features I use on my
>> Smart Proxies and which Smart Proxy plugins I use on page 5.
>>
>> Should't these three inputs be checkboxes instead of radio buttons?
>
> You are correct - the dangers of cut'n'paste. Should be fixed now, thanks!
>
> 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.

-- 
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] Revert removal of @host.params for host_param

[Stephen Benjamin]

- Original Message -
> From: "Daniel Lobato Garcia" 
> To: foreman-dev@googlegroups.com
> Sent: Wednesday, January 11, 2017 11:05:39 AM
> Subject: [foreman-dev] Revert removal of @host.params for host_param
> 
> Hi foreman devs,
> 
> Just noticed today https://github.com/theforeman/foreman/pull/3983/files
> after some comments on IRC. What's the background behind this change?
> 
> As far as I can see, this merely moves
> 
> @host.param to host_param
> @host.param_true? to host_param_true?
> @host.param_false? to host_param_false?
> @host.info to host_enc
> 
> without gaining anything from the change. This will force people to
> change their templates (including our community templates) when the
> deprecation is removed, and there's nothing to gain.
> 
> Does someone know what's the rationale behind this change? As it stands
> right now, I propose reverting that commit entirely to avoid inflicting
> that pain on users - which include many devs who maintain templates.
> 
> Best,
> 

I know the macros look better, but it seems like a small gain for a
lot of pain.  A lot of users use the existing methods in parameter values
(ERB w/ safe mode off), and their own custom templates.

And the standard response to these kinds of complaints is "well, it's
deprecated and users have enough time to change."  But I really just
don't think that's sufficient, this is more change for the sake of
change.

Also, the deprecation wasn't really smooth as it broke REX tests.
  http://ci.theforeman.org/job/test_plugin_matrix/2466/


- Stephen

-- 
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] setting up rex w/ katello dev forklift

[Stephen Benjamin]

- Original Message -
> From: "Tom McKay" <thomasmc...@redhat.com>
> To: foreman-dev@googlegroups.com
> Sent: Tuesday, January 10, 2017 1:59:00 PM
> Subject: Re: [foreman-dev] setting up rex w/ katello dev forklift
> 
> Yes, I have the rex gem as noted in original post. The missing steps are
> how to configure the smart proxy to have rex available.
>

Can you try this:

  echo 'foreman_proxy::plugin::remote_execution::ssh: false' >> 
/etc/foreman-installer/scenarios.d/katello-devel-answers.yaml


And see if that's enough to get the options?


Once you do that you should be able to run:

  foreman-installer --enable-foreman-proxy-plugin-remote-execution-ssh




> On Tue, Jan 10, 2017 at 1:42 PM, Stephen Benjamin <step...@redhat.com>
> wrote:
> 
> >
> >
> > - Original Message -
> > > From: "Ewoud Kohl van Wijngaarden" <ew...@kohlvanwijngaarden.nl>
> > > To: foreman-dev@googlegroups.com
> > > Sent: Tuesday, January 10, 2017 12:14:18 PM
> > > Subject: Re: [foreman-dev] setting up rex w/ katello dev forklift
> > >
> > > On Tue, Jan 10, 2017 at 11:50:04AM -0500, Tom McKay wrote:
> > > > I'm trying to figure out the steps to get rex working with a dev
> > forklift.
> > > > Here's what I have so far...
> > > >
> > > > vagrant up devbox
> > > > sshfs mount in git checkout, which includes rex plugin
> > > > rake katello:reset
> > > > hammer csv smart-proxies to add back smart proxy on 9090
> > > > rake db:seed
> > > > rake db:migrate
> > > > yum install rubygem-smart_proxy_remote_execution_ssh
> > > > mkdir ~foreman-proxy/.ssh chown foreman-proxy ~foreman-proxy/.ssh sudo
> > -u
> > > > foreman-proxy ssh-keygen -f ~foreman-proxy/.ssh/id_rsa_foreman_proxy
> > -N ''
> > > > systemctl restart foreman-proxy.service
> > > >
> > > > I was hoping that the foreman-installer would have the necessary flags
> > to
> > > > just make it work but I see no remote-execution flags at all in
> > > > foreman-installer --help
> > > >
> > > > Does anyone have a forklift playbook that wires all this up correctly?
> > >
> > > Looks like the katello scenario does expose it:
> > >
> > > https://github.com/Katello/katello-installer/blob/
> > 9d08de2589d7a3c01f9965fa0aaf5f86be992b9b/config/katello-answers.yaml#L68
> > >
> > > But katello-devel doesn't:
> > >
> > > https://github.com/Katello/katello-installer/blob/
> > 9d08de2589d7a3c01f9965fa0aaf5f86be992b9b/config/katello-devel-answers.yaml
> > >
> > > For for me worked was:
> > >
> > > echo '  foreman::plugin::remote_execution: false' >>
> > > /etc/foreman-installer/scenarios.d/katello-devel-answers.yaml
> > >
> > > Then the option should become visible, but maybe the options aren't in
> > > the parser cache because I don't see those.
> > >
> >
> > I answered already on IRC, but this isn't going to work.  If you have a dev
> > environment, it's the same process to install any Foreman plugin, check out
> > the source and add it to your bundler.d.
> >
> >http://projects.theforeman.org/projects/foreman/wiki/How_
> > to_Create_a_Plugin#Installing-the-plugin
> >
> > The installer can automate some of this for the dev environment but
> > I haven't tried this feature.  Look for "extra-plugins" in the help:
> >
> >   https://github.com/Katello/puppet-katello_devel/blob/
> > master/manifests/init.pp#L65
> >
> >
> >
> >
> >
> >
> > - Stephen
> >
> > --
> > 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] setting up rex w/ katello dev forklift

[Stephen Benjamin]

- Original Message -
> From: "Ewoud Kohl van Wijngaarden" 
> To: foreman-dev@googlegroups.com
> Sent: Tuesday, January 10, 2017 12:14:18 PM
> Subject: Re: [foreman-dev] setting up rex w/ katello dev forklift
> 
> On Tue, Jan 10, 2017 at 11:50:04AM -0500, Tom McKay wrote:
> > I'm trying to figure out the steps to get rex working with a dev forklift.
> > Here's what I have so far...
> > 
> > vagrant up devbox
> > sshfs mount in git checkout, which includes rex plugin
> > rake katello:reset
> > hammer csv smart-proxies to add back smart proxy on 9090
> > rake db:seed
> > rake db:migrate
> > yum install rubygem-smart_proxy_remote_execution_ssh
> > mkdir ~foreman-proxy/.ssh chown foreman-proxy ~foreman-proxy/.ssh sudo -u
> > foreman-proxy ssh-keygen -f ~foreman-proxy/.ssh/id_rsa_foreman_proxy -N ''
> > systemctl restart foreman-proxy.service
> > 
> > I was hoping that the foreman-installer would have the necessary flags to
> > just make it work but I see no remote-execution flags at all in
> > foreman-installer --help
> > 
> > Does anyone have a forklift playbook that wires all this up correctly?
> 
> Looks like the katello scenario does expose it:
> 
> https://github.com/Katello/katello-installer/blob/9d08de2589d7a3c01f9965fa0aaf5f86be992b9b/config/katello-answers.yaml#L68
> 
> But katello-devel doesn't:
> 
> https://github.com/Katello/katello-installer/blob/9d08de2589d7a3c01f9965fa0aaf5f86be992b9b/config/katello-devel-answers.yaml
> 
> For for me worked was:
> 
> echo '  foreman::plugin::remote_execution: false' >>
> /etc/foreman-installer/scenarios.d/katello-devel-answers.yaml
> 
> Then the option should become visible, but maybe the options aren't in
> the parser cache because I don't see those.
> 

I answered already on IRC, but this isn't going to work.  If you have a dev
environment, it's the same process to install any Foreman plugin, check out
the source and add it to your bundler.d.

   
http://projects.theforeman.org/projects/foreman/wiki/How_to_Create_a_Plugin#Installing-the-plugin

The installer can automate some of this for the dev environment but
I haven't tried this feature.  Look for "extra-plugins" in the help:

  
https://github.com/Katello/puppet-katello_devel/blob/master/manifests/init.pp#L65






- Stephen

-- 
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] Katello documentation moved to theforeman.org repo

[Stephen Benjamin]

- Original Message -
> From: "Ewoud Kohl van Wijngaarden" 
> To: "foreman-dev" 
> Sent: Tuesday, November 29, 2016 3:56:23 PM
> Subject: Re: [foreman-dev] Katello documentation moved to theforeman.org repo
> 
> On Tue, Nov 29, 2016 at 10:50:24AM -0500, Eric D Helms wrote:
> > The katello.org website itself has also been updated to redirect users
> > to the new documentation locations.
> 
> Should it use HTTP redirects so search engines get updated as well?

We do, all old deep links are redirected:
  http://katello.org/docs/3.2/upgrade/puppet.html

We kept the index page to let users know we moved.  We'll change it to a 
redirect at some point, probably whenever we're ready to stop renewing
the domain.


- Stephen


> --
> 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: Creating a plugin-for-tests (was [foreman-dev] Plugin test failures)

[Stephen Benjamin]

- Original Message -
> From: "Dominic Cleal" <domi...@cleal.org>
> To: foreman-dev@googlegroups.com
> Sent: Tuesday, November 8, 2016 5:42:04 AM
> Subject: Re: Creating a plugin-for-tests (was [foreman-dev] Plugin test 
> failures)
> 
> On 07/11/16 15:39, Stephen Benjamin wrote:
> > The wiki says that public methods will be deprecated and given a chance
> > to adjust our code in a reasonable time where possible:
> > 
> > "Foreman will always strive to make no incompatible changes in a minor
> > release, but be prepared
> > to make updates on major releases. Where possible, deprecation warnings
> > will be added for old
> > public methods before their removal. Warnings will be issued for two
> > major releases and then the
> > old method removed in the third release, giving plenty of time to
> > update plugins."
> > 
> > I read that as being quasi-official to be able to do alias_method_chain on
> > public methods
> 
> No, this means public methods should still be able to be called, not
> redefined. There's no mention of support for redefining methods via
> alias_method_chain (or others) in the plugin documentation.
> 
> There's little Foreman can do if a method is being redefined and is
> later deprecated in favour of something else, since Foreman would no
> longer call the deprecated method. The deprecation is only useful when
> it's called, not modified.
> 
> > but very often - nearly always - they are not deprecated and
> > the signature just changes or maybe the method is even removed. It
> > constantly breaks
> > my plugin.
> 
> Be more defensive against signature changes by redefining the method
> with a splat operator, e.g. def foo(*args) and passing *args to the
> original method. If arguments with defaults are added, no change is
> required to the redefined method.
> 
> > And the plugin API (which itself is a mess given it grows organically and
> > ad hoc instead
> > of some team spending time to get it right) is pretty limited if you want
> > to add on to Foreman objects.
> 
> Please expand it then, or at least ensure a ticket is filed in the
> Plugins category in Foreman's issue tracker for the functionality you
> require.
> 
> It's good that it's ad-hoc because those are the extensions points that
> plugin authors have needed, and they can be specifically tested.

I strongly disagree with this. One thing we see now is as they get added
organically, every single one works in a different way and stores the
plugin configuration in a different way, often resulting in bugs.  Just
look at this and the attached bugs: http://projects.theforeman.org/issues/12747

We don't only add API calls whenever a need to use it comes up,  likewise
obviously important objects should have plugin extension points.

I suggested adding a representative plugin to the test matrix so users were
aware that particular methods are used by plugins and maybe find a way to
avoid changing it, at least until the plugin extension points are better. 
There is definitely a common set of things that people are 
alias_method_chaining or
hooking onto to add objects to host groups, hosts, title bar actions, etc.

But the answer from this thread is basically, "too bad." So I'm just going
to stop trying to plug the holes in the drowning ship that is foreman_salt.

- Stephen


> --
> Dominic Cleal
> domi...@cleal.org
> 
> --
> 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: Creating a plugin-for-tests (was [foreman-dev] Plugin test failures)

[Stephen Benjamin]

- Original Message -
> From: ssht...@redhat.com
> To: "foreman-dev" 
> Sent: Sunday, November 6, 2016 3:34:40 AM
> Subject: Re: Re: Creating a plugin-for-tests (was [foreman-dev] Plugin test 
> failures)
> 
> +1 for Daniel.
> 
> IMHO most of the breakages that I saw were related to changes in the code
> that were not "officially declared" as API. Good examples are
> alias_method_chain for various methods.

The wiki says that public methods will be deprecated and given a chance
to adjust our code in a reasonable time where possible:

"Foreman will always strive to make no incompatible changes in a minor 
release, but be prepared
to make updates on major releases. Where possible, deprecation warnings 
will be added for old
public methods before their removal. Warnings will be issued for two major 
releases and then the
old method removed in the third release, giving plenty of time to update 
plugins."

I read that as being quasi-official to be able to do alias_method_chain on
public methods, but very often - nearly always - they are not deprecated and
the signature just changes or maybe the method is even removed. It constantly 
breaks
my plugin.

The last time I had test green, they were green for ONE DAY.  There's no 
consideration
at all for changes to Foreman's public methods.

And the plugin API (which itself is a mess given it grows organically and ad 
hoc instead
of some team spending time to get it right) is pretty limited if you want
to add on to Foreman objects.

Being a plugin maintainer really sucks.



- Stephen


> 
> On Friday, November 4, 2016 at 1:48:13 PM UTC+2, Daniel Lobato wrote:
> >
> > On 11/03, Greg Sutcliffe wrote:
> > > 
> > > 
> > > > You should file a bug against Foreman immediately if you see that a
> > > > plugin interface has been broken, so we can ensure the change isn't
> > > > released and a fix can be written.
> > > > 
> > > 
> > > Fair enough - in this case it's an interface that wasn't tested and a
> > user
> > > has found
> > > it subsequently (#17203 in set_hostgroup_defaults), so I think the
> > > not-releasing-it
> > > option is gone. I'll open an issue to write some tests for that
> > interface,
> > > though.
> > > 
> > > More generally, does it make sense for someone to do an audit of the
> > most
> > > common
> > > places that plugins hook in, and make sure we have tests for them?
> >
> > The 'problem' is that the places plugins hook in are usually parts of
> > the app, e.g 'Host.foo', 'computeresource.bar'. The defined endpoints
> > for the plugin API are usually fine, but other methods that are equally
> > as important to the plugin could change behavior unexpectedly.
> >
> > Personally I think from core the important part is being aware of these
> > changes and communicating them promptly - helping to fix them when
> > possible too.
> >
> > > 
> > > Cheers
> > > 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...@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.
> 

-- 
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] Removal of Ruby 1.8.7 in Puppet module tests

[Stephen Benjamin]

- Original Message -
> From: "Michael Moll" 
> To: foreman-dev@googlegroups.com
> Sent: Wednesday, October 19, 2016 6:05:43 AM
> Subject: Re: [foreman-dev] Removal of Ruby 1.8.7 in Puppet module tests
> 
> Hi,
> 
> On Wed, Oct 19, 2016 at 11:39:21AM +0200, Ewoud Kohl van Wijngaarden wrote:
> > I like the major version bump as a last fully supported version but I
> > disagree we should fully drop EL6 support. At least EL6 AIO installs
> > should continue to be supported. Non-AIO should be a best-effort
> > support: we don't test it but we still accept patches to continue
> > supporting it.
> 
> Thinking about this again, this makes sense, but as I'd like to support
> EL6 longer in theforeman-puppet (even with 1.8.7, ideally) as in
> theforeman-foreman(_proxy) and depdendent modules, we'll likely to have
> the topic on the plate with the 1.14 at the latest.
> 
> Regards
> --
> Michael Moll
> 
> --
> 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.
> 

Not a lot of time for feedback - just barely 24 hours, but it only encompassed 1
day in the US as it was merged before we came in this morning... :-\

Great we're getting rid of 1.8.7, but will any of this leak into 1.13 installer?
I would think not, but just want to make sure.

It really is unfortunate though we're going to officially dump el6 support for
modules users may use outside of Foreman (dhcp, tftp, puppet, etc).



 -Stephen

-- 
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] Plugin test failures

[Stephen Benjamin]

Tasks, salt and a bunch of plugins are failing tests, has anyone has a chance 
to look into it?  e.g.:

  http://ci.theforeman.org/job/test_plugin_matrix/2015/#showFailuresLink

This most recent failure has me thinking again about the difficulties of being 
a plugin maintainer
for Foreman.

Would it be possible to get a standard plugin in Foreman's test matrix for PR? 
Perhaps tasks is a good
candidate.  Not on all databases/rubies, but something might help gain 
awareness of the impact of
certain changes on plugins. Katello is there, but it doesn't run all (any?) of 
Foreman's tests.

Along side that, we should be tracking what plugin maintainers need to do to 
update from one release
to the next.

It really is a recurring problem for me, that Salt is constantly broken due to 
incompatibilities
introduced in Foreman.   We do a poor job of tracking them.  Maybe if I'm lucky 
someone is nice
enough to send a mail to foreman-dev. Or if the planets align, someone opens a 
PR to foreman_salt
and fixes it. But more often than not, my project just goes red and I have to 
figure out why.
But this is just a side thing, and I rarely get to immediately look at 
failures.  They end up piling
up.

Very frustrating, as when I do find time to work on it, it's not to do 
something cool, but just
to figure out what changed in core and how to fix it in the plugin :-\


- Stephen

-- 
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] Request write access to katello-installer

[Stephen Benjamin]

- Original Message -
> From: "Eric D Helms" 
> To: "foreman-dev" 
> Sent: Thursday, September 22, 2016 11:09:53 AM
> Subject: Re: [foreman-dev] Request write access to katello-installer
> 
> Hi Chris,
> 
> We also like to see proof of review (note the katello.org page mentions 3
> reviews) to gauge understanding of the ecosystem of the project as a whole
> given that being a maintainer means more than just being able to merge your
> own code. I would also add that the larger community guidelines around
> becoming a maintainer are good to strive for and helpful for evaluation
> [1]. We'd love to have your help maintaining, so if there is anything we
> can do to help point out good PRs to review or tasks to take on, we are
> more than happy to help in that regard.
> 
> 
> Eric
> 
> [1] https://theforeman.org/handbook.html#Becomingamaintainer

Hi,

I'd also add to what Eric said to say the installer team maintains the puppet
modules, as well. I prefer for team members to be familiar with those repos,
as well - a couple of commits and reviews would be helpful to show familiarity
with puppet.

Thanks for the contributions so far.


- Stephen



> On Thu, Sep 22, 2016 at 11:02 AM,  wrote:
> 
> > Per the guidelines of:
> >
> > http://www.katello.org/developers/github_workflow.html
> >
> > I have had over 11 commits:
> >
> > https://nimbus.everhelper.me/client/notes/share/586311/
> > eczglswonn1tors90piq
> >
> > and also part of the katello-devel team under Mike McCune as a Software
> > Developer and no longer under GSS.
> >
> > Thanks,
> >
> > - Chris Roberts
> >
> > --
> > 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
> Ph.D. Student - North Carolina State University
> 
> --
> 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] smart-proxy plugin installation failure

[Stephen Benjamin]

- Original Message -
> From: "lakier" 
> To: "foreman-dev" 
> Cc: step...@redhat.com
> Sent: Monday, September 19, 2016 4:11:15 PM
> Subject: Re: [foreman-dev] smart-proxy plugin installation failure
> 
> As I mentioned in first post, I've refreshed this...

It wasn't clear to me that you did that after starting the smart proxy
after step 6 in your summary.

Does it show up in the output of the features API call 
(https://localhost:8443/features)?

Did you run db:seed as well on the foreman? This is what creates the 
Salt feature in the database.




> On Monday, September 19, 2016 at 7:54:25 PM UTC+2, stephen wrote:
> >
> > You would need to refresh the features from the Infrastructure/Proxies
> > page on the Foreman server.
> >
> >
> > - Original Message -
> > > From: "lakier" 
> > > To: "foreman-dev" 
> > > Cc: dom...@cleal.org 
> > > Sent: Monday, September 19, 2016 1:19:13 PM
> > > Subject: Re: [foreman-dev] smart-proxy plugin installation failure
> > > 
> > > Thank you for your reply.
> > > I've followed these steps once again, still no change...
> > > 
> > > I see in smart-proxy (debug) log:
> > > Successfully initialized 'salt'
> > > But on the foreman gui still no 'salt' feature after smart-proxy
> > refresh.
> > > Moreover proxy.log doesn't contain any other useful information...
> > > I'm using 'foreman_salt' foreman plugin via source install:
> > > /usr/share/foreman/bundler.d/Gemfile.local.rb (using 6.0.0 branch, my
> > > foreman is 1.12), which seems to install just fine.
> > > 
> > > To sum up steps:
> > > 1. sudo foreman-installer \
> > >--no-enable-foreman-proxy \
> > >--no-enable-puppet \
> > >--puppet-server=false \
> > >--foreman-user-groups=EMPTY_ARRAY \
> > >--foreman-server-ssl-ca=$CA_CERT \
> > >--foreman-server-ssl-chain=$CA_CERT \
> > >--foreman-server-ssl-cert=$FOREMAN_CERT \
> > >--foreman-server-ssl-key=$FOREMAN_KEY \
> > >--foreman-server-ssl-crl=$FOREMAN_CRL \
> > >--foreman-client-ssl-ca=$CA_CERT \
> > >--foreman-client-ssl-cert=$FOREMAN_CERT \
> > >--foreman-client-ssl-key=$FOREMAN_KEY \
> > >--foreman-websockets-ssl-cert=$FOREMAN_CERT \
> > >--foreman-websockets-ssl-key=$FOREMAN_KEY \
> > >--puppet-ssldir=$CERT_BASEDIR \
> > >--foreman-puppet-ssldir=$CERT_BASEDIR
> > > 
> > > (it seems to install smart-proxy - I can see it in *ps aux, *I'm killing
> > > this process)
> > > 
> > > 2. installing foreman_salt using aforementioned method, running
> > db:migrate.
>
> > > 3. Cloning my fork of smart-proxy-salt and smart-proxy
> > > 4. gem build *.gemspec; sudo gem install *.gem
> > > 5. changing settings in smart-proxy/settings.d (generic and salt ones,
> > > :enabled is set to https), running *bundle install* (I see
> > smart_proxy_salt)
> > > 6. run smart-proxy/bin/smart-proxy
> > > 
> > > Outcome:
> > > smart-proxy doesn't show salt feature, absolutely nothing in logs...
> > > 
> > > On Monday, September 19, 2016 at 8:55:54 AM UTC+2, Dominic Cleal wrote:
> > > > 
> > > > On 18/09/16 22:03, lakier wrote:
> > > > > Hi,
> > > > > 
> > > > > I was willing to install my version of salt-smart-proxy plugin.
> > > > > And basically the question is:
> > > > > *How to do this? ELI5*
> > > > > *
> > > > > *
> > > > > I've
> > > > > read
> > > > 
> > http://projects.theforeman.org/projects/foreman/wiki/How_to_Install_a_Smart-Proxy_Plugin
> > > > > so spare me that (I suggest making it clear that package
> > installation is
> > > > > fundamentally different that source install).
> > > > > After some time I've discovered that gem installing my
> > smart_proxy_salt
> > > > > doesn't do anything.
> > > > 
> > > > The gem has to be installed, but you also need a bundler.d/ entry to
> > > > load it (e.g.
> > > > 
> > > > 
> > https://github.com/theforeman/smart_proxy_salt/blob/master/bundler.d/salt.rb)
> >
> > > > 
> > > > and a configuration file in settings.d/ to activate it.
> > > > 
> > > > > Cloning smart-proxy repo, adding gem 'smart_proxy_salt' to
> > > > > Gemfile.local.rb, adding settings files to /config/ dir and doing
> > > > > /bundle install /doesn't setup salt at all (refreshing smart-proxy
> > in
> > > > > foreman gui doesn't show salt /feature/)
> > > > 
> > > > "bundle install" doesn't list smart_proxy_salt? If so, check that the
> > > > entry in your Gemfile.local.rb is correct and that it's at
> > > > bundler.d/Gemfile.local.rb.
> > > > 
> > > > Check the smart proxy log file, particularly on debug mode rather than
> > > > using the list of enabled features in Foreman. The logs will show if
> > any
> > > > modules are failing to load, or being loaded but are disabled, plus
> > > > using Foreman requires you to have an equivalent Foreman plugin
> > > > installed that can recognise the smart proxy feature.
> > > > 
> > > > > Where for the God's sake you actually PLUG your plugin to
> > 

Re: [foreman-dev] Using certificates for SSH access

[Stephen Benjamin]

- Original Message -
> From: "Marek Hulán" 
> To: foreman-dev@googlegroups.com
> Sent: Tuesday, September 13, 2016 10:13:45 AM
> Subject: Re: [foreman-dev] Using certificates for SSH access
> 
> Hello
> 
> some comments below
> 
> On Tuesday 13 of September 2016 08:51:12 Ohad Levy wrote:
> > Hi,
> > 
> > I was looking at [1] which talks about how to leverage a CA for managing
> > SSH access, and I thought it could be interesting for REX and potentially
> > for foreman to manage.
> > 
> > In the post, they describe how they create different principles (groups -
> > think hostgroups) for access, generating certificates with expatriation
> > etc.
> > 
> > Since we already have some of the certificate handling code (puppet ca,
> > pulp / katello certs) I wonder if it make sense to generalize it and offer
> > SSH certificates (and their management and possible an auditing system for
> > their usage) offering?
> 
> I was thinking about this earlier, the major benefit I see is that in case we
> change the key that Foreman uses we wouldn't have to update all hosts. Since
> we currently only install it during provisioning it might be very helpful.
> OTOH we should also provide puppet module that would configure this key so
> there's easy way to update it also for unmanaged hosts. Then the CA might not
> have that many benefits, we'd have to distribute the CA pub key instead of
> the
> main pub key. Probably the biggest benefit would be the key expiration.
> 
> If we decide to generalize the CA handling I'd first look if we could use
> something existing, e.g. FreeIPA. Maybe we could provide our simple backend
> too but I'd like to avoid building our own CA on top ssh-keygen :-) I'd also
> like to keep it in separate plugin - probably rex.


The CA use with ssh-keygen is a neat idea, but FreeIPA does some great things
that I'd rather not have us have to deal with.  The Facebook article towards
the end evens offers warnings about the lack of any kind of revocation scheme.

FreeIPA can do that, and handles it quite gracefully.  If a smart proxy key
gets compromised, you can just remove it from authorized keys in FreeIPA
and it propagates everywhere automatically.

And we could even go further with FreeIPA and not have to deal with SSH keys
at all and go the kerberos route, which handles access controls, key revocation,
expiration, etc all very nicely.  We have an RFE for that[1].


- Stephen

[1] http://projects.theforeman.org/issues/11936


> --
> Marek
> 
> > 
> > Ohad
> > 
> > [1]
> > https://code.facebook.com/posts/365787980419535/scalable-and-secure-access-w
> > ith-ssh/
> 
> --
> 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] Katello pipeline status

[Stephen Benjamin]

- Original Message -
> From: "Stephen Benjamin" <step...@redhat.com>
> To: "Foreman" <foreman-dev@googlegroups.com>
> Sent: Tuesday, August 23, 2016 9:27:28 AM
> Subject: [foreman-dev] Katello pipeline status
> 
> Hi,
> 
> Status: red[1]
> 
> I'm about halfway through my rotation, so a brief update about where we are.
> 
> Last week, we were working on getting a new foreman_tasks release that was
> compatible with Foreman 1.13 strong params change.  Due to tasks being
> depended
> on by other plugins (Salt, Chef, and Remote Execution), we also needed to fix
> their compatibility with 1.13 and release them.  We did that for all three,
> and got foreman-tasks released and packaged.
> 
> We're just waiting for the Foreman plugins job to push it to
> yum.theforeman.org.
> Once that's done, I can kick off the pipeline again. I expect that to
> happen today.

Hi,

New packages are now available in nightly.

Status is still red, officially, as ehelms is still moving some
things around on jenkins jobs. However, BATS has passed and 
everything was rsync'd over manually to fedorapeople.

- Stephen


> In the meanwhile, I've built a local bats box against koji this morning.  It
> installed clean and BATs passed, so I'm hopeful we'll see the same on the
> pipeline shortly.
> 
> Thanks to everyone who helped get the plugins updated and released.
> 
> 
> Na na na na,
> 
> BATSman
> 
> 
> 
> [1] http://ci.theforeman.org/view/Katello%20Pipeline/
> 
> --
> 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] Katello pipeline status

[Stephen Benjamin]

Hi,

Status: red[1]

I'm about halfway through my rotation, so a brief update about where we are.

Last week, we were working on getting a new foreman_tasks release that was
compatible with Foreman 1.13 strong params change.  Due to tasks being depended
on by other plugins (Salt, Chef, and Remote Execution), we also needed to fix
their compatibility with 1.13 and release them.  We did that for all three,
and got foreman-tasks released and packaged.  

We're just waiting for the Foreman plugins job to push it to yum.theforeman.org.
Once that's done, I can kick off the pipeline again. I expect that to
happen today.

In the meanwhile, I've built a local bats box against koji this morning.  It
installed clean and BATs passed, so I'm hopeful we'll see the same on the
pipeline shortly.

Thanks to everyone who helped get the plugins updated and released.


Na na na na,

BATSman



[1] http://ci.theforeman.org/view/Katello%20Pipeline/

-- 
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] Webpack merged into develop branch

[Stephen Benjamin]

- Original Message -
> From: "Eric D Helms" <ericdhe...@gmail.com>
> To: "foreman-dev" <foreman-dev@googlegroups.com>
> Sent: Saturday, August 20, 2016 11:34:27 AM
> Subject: Re: [foreman-dev] Webpack merged into develop branch
> 
> Are there any errors in the console related to fetching of assets from the
> server? Can you look through the list of files loaded from the server in
> your browser console and see if bundle.js is present with content?


It works this morning without doing anything, so it must've been my browser
cache or something.

- Stephen


> On Fri, Aug 19, 2016 at 2:35 PM, Stephen Benjamin <step...@redhat.com>
> wrote:
> 
> >
> >
> > - Original Message -
> > > From: "Stephen Benjamin" <step...@redhat.com>
> > > To: foreman-dev@googlegroups.com
> > > Sent: Friday, August 19, 2016 7:29:21 AM
> > > Subject: Re: [foreman-dev] Webpack merged into develop branch
> > >
> > >
> > >
> > > - Original Message -
> > > > From: "Greg Sutcliffe" <greg.sutcli...@gmail.com>
> > > > To: "Foreman" <foreman-dev@googlegroups.com>
> > > > Sent: Friday, August 19, 2016 4:24:17 AM
> > > > Subject: Re: [foreman-dev] Webpack merged into develop branch
> > > >
> > > > On 19 August 2016 at 07:26, Daniel Lobato <elobat...@gmail.com> wrote:
> > > >
> > > > > I'm not sure why - but I also can reproduce this.
> > > > >
> > > > > It seems like having `foreman_templates` on your list of plugins is
> > > > > what's
> > > > > causing this. I don't really know why yet but I don't get the error
> > > > > without
> > > > > that plugin, and I get it the moment I put it in bundler.d
> > > > >
> > > >
> > > > I know I haven't updated templates for this:
> > https://groups.google.com/d/
> > > > topic/foreman-dev/MFW1bAj-eFk/discussion (hit that myself last
> > night). Not
> > > > the same error, but possibly related. I'll push that change to
> > > > templates/develop today and hopefully it'll help.
> > > >
> > >
> > > Thank you, that was it. foreman_chef wasn't updated for that.
> > >
> > >
> > > - Stephen
> >
> > Well, sort of.  Now none of the menus, dropdowns etc work.  There's plenty
> > of errors in the JS console like this:
> >
> >   ReferenceError: $ is not defined editable_form.self.js:5:5
> >   ReferenceError: jQuery is not defined
> >
> > I've tried cleaning out the node_modules dir and reinstalled, and trying
> > webpack:compile with the server off, and it doesn't help.
> >
> >
> > - Stephen
> >
> >
> > --
> > 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
> Ph.D. Student - North Carolina State University
> 
> --
> 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] Webpack merged into develop branch

[Stephen Benjamin]

- Original Message -
> From: "Stephen Benjamin" <step...@redhat.com>
> To: foreman-dev@googlegroups.com
> Sent: Friday, August 19, 2016 7:29:21 AM
> Subject: Re: [foreman-dev] Webpack merged into develop branch
> 
> 
> 
> - Original Message -
> > From: "Greg Sutcliffe" <greg.sutcli...@gmail.com>
> > To: "Foreman" <foreman-dev@googlegroups.com>
> > Sent: Friday, August 19, 2016 4:24:17 AM
> > Subject: Re: [foreman-dev] Webpack merged into develop branch
> > 
> > On 19 August 2016 at 07:26, Daniel Lobato <elobat...@gmail.com> wrote:
> > 
> > > I'm not sure why - but I also can reproduce this.
> > >
> > > It seems like having `foreman_templates` on your list of plugins is
> > > what's
> > > causing this. I don't really know why yet but I don't get the error
> > > without
> > > that plugin, and I get it the moment I put it in bundler.d
> > >
> > 
> > I know I haven't updated templates for this: https://groups.google.com/d/
> > topic/foreman-dev/MFW1bAj-eFk/discussion (hit that myself last night). Not
> > the same error, but possibly related. I'll push that change to
> > templates/develop today and hopefully it'll help.
> > 
> 
> Thank you, that was it. foreman_chef wasn't updated for that.
> 
> 
> - Stephen

Well, sort of.  Now none of the menus, dropdowns etc work.  There's plenty
of errors in the JS console like this:

  ReferenceError: $ is not defined editable_form.self.js:5:5
  ReferenceError: jQuery is not defined

I've tried cleaning out the node_modules dir and reinstalled, and trying 
webpack:compile with the server off, and it doesn't help.


- Stephen


-- 
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] Webpack merged into develop branch

[Stephen Benjamin]

- Original Message -
> From: "Greg Sutcliffe" 
> To: "Foreman" 
> Sent: Friday, August 19, 2016 4:24:17 AM
> Subject: Re: [foreman-dev] Webpack merged into develop branch
> 
> On 19 August 2016 at 07:26, Daniel Lobato  wrote:
> 
> > I'm not sure why - but I also can reproduce this.
> >
> > It seems like having `foreman_templates` on your list of plugins is what's
> > causing this. I don't really know why yet but I don't get the error without
> > that plugin, and I get it the moment I put it in bundler.d
> >
> 
> I know I haven't updated templates for this: https://groups.google.com/d/
> topic/foreman-dev/MFW1bAj-eFk/discussion (hit that myself last night). Not
> the same error, but possibly related. I'll push that change to
> templates/develop today and hopefully it'll help.
> 

Thank you, that was it. foreman_chef wasn't updated for that.


- Stephen

-- 
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] Webpack merged into develop branch

[Stephen Benjamin]

- Original Message -
> From: "Tomer Brisker" 
> To: "foreman-dev" 
> Sent: Wednesday, August 10, 2016 8:01:57 AM
> Subject: [foreman-dev] Webpack merged into develop branch
> 
> Hello,
> 
> I am happy to inform you that Webpack has finally been added to Foreman.
> This step which will help us modernize our front-end code, take advantage
> of the blooming javascript eco-system, and easily integrate technologies
> such as ES2015, React, js unit testing and more.
> A deep-dive will be scheduled soon to explain all the changes, but there
> are a few details that require your attention for running the current
> develop branch.
> 
> This change requires a slight change to your workflow in the development
> environment. First, you need to run `npm install` to get all of the needed
> node modules to install (similar to `bundle install` for gems).
> ​Second, to run your server in development environment, you should use
> `foreman start` which will run ​both the rails server and the webpack
> live-reload development server. If you wish to use a non-default setting
> for the rails server (e.g. using puma), you can set the RAILS_STARTUP
> environment variable with the relevant command (see Procfile for an
> example).
> 
> Please note that running this way will limit the ability to use pry for
> debugging, as foreman prevents stdin echo. To use with pry, you can run
> both servers separately in different terminals - run rails as usual in one,
> and run `./node_modules/.bin/webpack-dev-server --config
> config/webpack.config.js` in the other.
> 
> Also, new javascript code should be put in webpack/assets/javascript and
> placed inside modules, using ES2015 syntax, whenever possible. Old code
> will be gradually migrated into that location.
> 
> --
> Have a nice day,
> Tomer Brisker
> Red Hat Engineering

Am I missing something in getting this to work?

I tried several things -

npm install
foreman start

And it fails. I also tried:


Set `:webpack_dev_server: false` in settings.yml
rake webpack:compile
rails s


In both cases I get:

couldn't find file 'bootstrap' with type 'application/javascript'

Checked in these paths: 
  /home/vagrant/foreman/app/assets/images
  /home/vagrant/foreman/app/assets/javascripts
  /home/vagrant/foreman/app/assets/stylesheets
  /home/vagrant/foreman/vendor/assets/fonts
  /home/vagrant/foreman/vendor/assets/javascripts
  /home/vagrant/foreman/vendor/assets/stylesheets
  
/home/vagrant/.rvm/gems/ruby-2.2.4/gems/ipaddrjs-rails-1.1.1/vendor/assets/javascripts
  
/home/vagrant/.rvm/gems/ruby-2.2.4/gems/jquery_pwstrength_bootstrap_4-1.2.2/vendor/assets/javascript
  
/home/vagrant/.rvm/gems/ruby-2.2.4/gems/spice-html5-rails-0.1.5/vendor/assets/javascripts
  
/home/vagrant/.rvm/gems/ruby-2.2.4/gems/ace-rails-ap-4.1.0/vendor/assets/javascripts
  
/home/vagrant/.rvm/gems/ruby-2.2.4/gems/gettext_i18n_rails_js-1.1.0/lib/assets/javascripts
  
/home/vagrant/.rvm/gems/ruby-2.2.4/gems/gettext_i18n_rails_js-1.1.0/vendor/assets/javascripts
  
/home/vagrant/.rvm/gems/ruby-2.2.4/gems/select2-rails-3.5.10/vendor/assets/images
  
/home/vagrant/.rvm/gems/ruby-2.2.4/gems/select2-rails-3.5.10/vendor/assets/javascripts
  
/home/vagrant/.rvm/gems/ruby-2.2.4/gems/select2-rails-3.5.10/vendor/assets/stylesheets
  
/home/vagrant/.rvm/gems/ruby-2.2.4/gems/gridster-rails-0.5.6.1/vendor/assets/javascripts
  
/home/vagrant/.rvm/gems/ruby-2.2.4/gems/gridster-rails-0.5.6.1/vendor/assets/stylesheets
  
/home/vagrant/.rvm/gems/ruby-2.2.4/gems/multi-select-rails-0.9.12/app/assets/images
  
/home/vagrant/.rvm/gems/ruby-2.2.4/gems/multi-select-rails-0.9.12/app/assets/javascripts
  
/home/vagrant/.rvm/gems/ruby-2.2.4/gems/multi-select-rails-0.9.12/app/assets/stylesheets
  
/home/vagrant/.rvm/gems/ruby-2.2.4/gems/jquery-turbolinks-2.1.0/vendor/assets/javascripts
  /home/vagrant/katello/app/assets/images
  /home/vagrant/katello/app/assets/javascripts
  /home/vagrant/katello/app/assets/stylesheets
  /home/vagrant/katello/vendor/assets/images
  /home/vagrant/katello/vendor/assets/javascripts
  /home/vagrant/katello/vendor/assets/stylesheets
  /home/vagrant/.rvm/gems/ruby-2.2.4/gems/bastion-3.3.1/app/assets/javascripts
  /home/vagrant/.rvm/gems/ruby-2.2.4/gems/bastion-3.3.1/app/assets/stylesheets
  
/home/vagrant/.rvm/gems/ruby-2.2.4/gems/bastion-3.3.1/vendor/assets/javascripts
  
/home/vagrant/.rvm/gems/ruby-2.2.4/gems/angular-rails-templates-0.1.2/vendor/assets/javascripts
  /home/vagrant/katello/engines/bastion_katello/app/assets/javascripts
  /home/vagrant/katello/engines/bastion_katello/app/assets/stylesheets
  
/home/vagrant/.rvm/gems/ruby-2.2.4/gems/jquery-ui-rails-4.2.1/app/assets/images
  
/home/vagrant/.rvm/gems/ruby-2.2.4/gems/jquery-ui-rails-4.2.1/app/assets/javascripts
  
/home/vagrant/.rvm/gems/ruby-2.2.4/gems/jquery-ui-rails-4.2.1/app/assets/stylesheets
  
/home/vagrant/.rvm/gems/ruby-2.2.4/gems/foreman_docker-3.0.0/app/assets/javascripts
  

Re: [foreman-dev] Merge foreman-bats into Forklift

[Stephen Benjamin]

- Original Message -
> From: "Dominic Cleal" <domi...@cleal.org>
> To: foreman-dev@googlegroups.com
> Sent: Thursday, May 26, 2016 5:42:33 AM
> Subject: Re: [foreman-dev] Merge foreman-bats into Forklift
> 
> On 25/05/16 17:25, Ewoud Kohl van Wijngaarden wrote:
> > On Wed, May 25, 2016 at 10:38:04AM -0400, Stephen Benjamin wrote:
> >> I can understand separating it from development tools, so what about
> >> moving
> >> Katello's bats to foreman-bats?
> > 
> > What would then be the primary way of getting the latest bats tests? A
> > script to clone the foreman-bats repository?
> 
> Assuming you just want to get foreman-bats to use its helpers then yes,
> just clone the repo and they should be usable. Freight does something
> similar to use another library of BATS helpers
> (https://github.com/freight-team/freight/blob/master/Makefile#L88).
> 
> Else you could use a submodule/tree to stay with a particular version.
> The helpers could always be moved into their own repo if necessary.

I don't "just" want foreman-bats helpers, that's just one reason to merge
the projects. I think they should be in the same repo together, wherever
that is, and work with Forklift's Vagrant setup.

One of the benefits of how Forklift does things is that you can easily
`vagrant up centos7-bats` and run katello bats locally. Why should
foreman-bats stay in its own repo and maintain an entirely separate
and different vagrant configuration?


- Stephen


> --
> Dominic Cleal
> domi...@cleal.org
> 
> --
> 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] Merge foreman-bats into Forklift

[Stephen Benjamin]

- Original Message -
> From: "Dominic Cleal" 
> To: foreman-dev@googlegroups.com
> Sent: Wednesday, May 25, 2016 10:29:41 AM
> Subject: Re: [foreman-dev] Merge foreman-bats into Forklift
> 
> On 23/05/16 21:48, Ewoud Kohl van Wijngaarden wrote:
> > Hello all,
> > 
> > With katello-deploy being renamed to Forklift[1], I was wondering if we
> > should merge foreman-bats into it. The benefit would be that it already
> > contains some bats tests for Katello and if it's going to be the tool to
> > deploy a development env or test env, it's a logical fit for all our
> > system tests.
> > 
> > Thoughts?
> 
> I'd prefer to keep foreman-bats where it is, I don't want to mix
> it with development tools or plugins. foreman-bats serves a limited
> purpose well right now.

Well, Katello hosts its bats tests in Forklift, and we share a lot of common
code.  Katello misses out on new features and changes to bats helpers.

I can understand separating it from development tools, so what about moving
Katello's bats to foreman-bats?


> --
> Dominic Cleal
> domi...@cleal.org
> 
> 
> --
> 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.