[foreman-dev] slave02.rackspace.theforeman.org is down

[Eric D Helms]

It appears that currently slave02.rackspace.theforeman.org is currently
down. This is affecting most repositories as the pull_request_scanner job
that checks nearly every repositories PRs is designed to run on that
particular slave.

I am not familiar enough with our Rackspace slave's so if anyone else from
infra (Michael, Greg, Ewoud) gets a chance to look into its disappearance
it would be appreciated.

-- 
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] Prprocessor Moved

[Eric D Helms]

Ended up with a small error in how I ran the update script for some
repositories. They should all be fixed for real now.

On Mon, Dec 25, 2017 at 12:16 PM, Tomer Brisker <tbris...@redhat.com> wrote:

> https://github.com/theforeman/foreman/pull/5110
> https://github.com/theforeman/foreman/pull/5111
>
> On Mon, Dec 25, 2017 at 6:41 PM, Eric D Helms <eric.d.he...@gmail.com>
> wrote:
>
>> Can you send an example?
>>
>> On Dec 25, 2017 5:14 AM, "Tomer Brisker" <tbris...@redhat.com> wrote:
>>
>>> Looks like the processor still isn't running on the foreman-core repo.
>>>
>>> On Sat, Dec 23, 2017 at 4:01 AM, Eric D Helms <eric.d.he...@gmail.com>
>>> wrote:
>>>
>>>> Appreciate the report Tomer. Turns out the update script was
>>>> overwriting parts of the configuration leading the errors occurring on most
>>>> repositories. I've modified the script [1] and re-ran it to update every
>>>> repository. The example PRs you linked appear to have been updated by the
>>>> prproccessor as of my checking this evenings.
>>>>
>>>> Please report any further oddities!
>>>>
>>>> Cheers,
>>>> E
>>>>
>>>> [1] https://github.com/theforeman/prprocessor/pull/77
>>>>
>>>> On Dec 22, 2017 5:32 PM, "Tomer Brisker" <tbris...@redhat.com> wrote:
>>>>
>>>>> Looks like the latest PRs didn't trigger the prprocessor:
>>>>> https://github.com/theforeman/foreman/pull/5107
>>>>> https://github.com/theforeman/foreman/pull/5108
>>>>> https://github.com/theforeman/foreman/pull/5109
>>>>>
>>>>> On Thu, Dec 21, 2017 at 3:59 PM, Eric D Helms <ericdhe...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> All,
>>>>>>
>>>>>> The prprocessor has been moved off of Openshift V2 onto the same box
>>>>>> that contains our Redmine instance and now has a permanent DNS. All
>>>>>> repositories that used the prprocessor have been updated. The new site 
>>>>>> is:
>>>>>>
>>>>>> http://prprocessor.theforeman.org/status
>>>>>>
>>>>>>
>>>>>> If you encounter any issues, such as not seeing labels or theforeman
>>>>>> bot commenting on pull requests please let us know here so that we can
>>>>>> investigate.
>>>>>>
>>>>>> --
>>>>>> 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.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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.
>>>>
>>>
>>>
>>>
>>> --
>>> 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.
>>
>
>
>
> --
> 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.
>



-- 
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] Prprocessor Moved

[Eric D Helms]

Can you send an example?

On Dec 25, 2017 5:14 AM, "Tomer Brisker" <tbris...@redhat.com> wrote:

> Looks like the processor still isn't running on the foreman-core repo.
>
> On Sat, Dec 23, 2017 at 4:01 AM, Eric D Helms <eric.d.he...@gmail.com>
> wrote:
>
>> Appreciate the report Tomer. Turns out the update script was overwriting
>> parts of the configuration leading the errors occurring on most
>> repositories. I've modified the script [1] and re-ran it to update every
>> repository. The example PRs you linked appear to have been updated by the
>> prproccessor as of my checking this evenings.
>>
>> Please report any further oddities!
>>
>> Cheers,
>> E
>>
>> [1] https://github.com/theforeman/prprocessor/pull/77
>>
>> On Dec 22, 2017 5:32 PM, "Tomer Brisker" <tbris...@redhat.com> wrote:
>>
>>> Looks like the latest PRs didn't trigger the prprocessor:
>>> https://github.com/theforeman/foreman/pull/5107
>>> https://github.com/theforeman/foreman/pull/5108
>>> https://github.com/theforeman/foreman/pull/5109
>>>
>>> On Thu, Dec 21, 2017 at 3:59 PM, Eric D Helms <ericdhe...@gmail.com>
>>> wrote:
>>>
>>>> All,
>>>>
>>>> The prprocessor has been moved off of Openshift V2 onto the same box
>>>> that contains our Redmine instance and now has a permanent DNS. All
>>>> repositories that used the prprocessor have been updated. The new site is:
>>>>
>>>> http://prprocessor.theforeman.org/status
>>>>
>>>>
>>>> If you encounter any issues, such as not seeing labels or theforeman
>>>> bot commenting on pull requests please let us know here so that we can
>>>> investigate.
>>>>
>>>> --
>>>> 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.
>>>>
>>>
>>>
>>>
>>> --
>>> 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.
>>
>
>
>
> --
> 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] Prprocessor Moved

[Eric D Helms]

All,

The prprocessor has been moved off of Openshift V2 onto the same box that
contains our Redmine instance and now has a permanent DNS. All repositories
that used the prprocessor have been updated. The new site is:

http://prprocessor.theforeman.org/status


If you encounter any issues, such as not seeing labels or theforeman bot
commenting on pull requests please let us know here so that we can
investigate.

-- 
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] Request for Koji access

[Eric D Helms]

I will work on getting you a cert cut.

On Thu, Dec 14, 2017 at 10:59 AM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:

> On Wed, Dec 13, 2017 at 10:30:53AM +0100, Ondrej Prazak wrote:
>
>> as we are getting closer to 1.17 branching, I would like to ask for access
>> to Koji, because I will need to update build targets and configuration.
>>
>
> +1
>
>
> --
> 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] 1.17 branching - status update 3

[Eric D Helms]

Thanks for the weekly updates!

Do you forsee 1.17 working as:

 1) Wait till the core codebase is updated to Rails 5.1 then branch and
notify plugins
 2) Branch soon at some stable point and backport the Rails 5.1 code changes


I believe also on the list of items is the update to fog 1.42 that has a
pending PR given the current version of Fog requires JSON < 2 and Ruby 2.4
comes with JSON 2+.

On Dec 7, 2017 7:02 AM, "Ondrej Prazak"  wrote:

> Hi,
> this is a quick summary of current 1.17 branching status. As before, feel
> free to correct/complete the information below.
>
> The new version of turbolinks-classic (2.5.4) was released about 12 hours
> ago, and we work on adding it to tfm-ror51 [1].
>
> Dynflowd deployment on Debian is almost ready to be merged [2].
>
> OAuth fix for Rails 5 [3] did not receive much attention from OAuth
> maintainers. We plan to package a forked version with included fix until
> new gem version compatible with Rails 5 is released.
>
> The plan is to move slowly forward with Rails 5.0 [4], then introduce
> incompatible changes to Rails 4.2 and move to 5.1
>
> O.
>
> [1] https://github.com/theforeman/tfm-ror51-packaging/pulls
> [2] https://github.com/theforeman/foreman-packaging/pull/1959
> [3] https://github.com/oauth-xx/oauth-ruby/pull/150
> [4] https://github.com/theforeman/foreman/pull/4867
>
> --
> 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] Be sure to import your product content data for Katello 3.6

[Eric D Helms]

This sounds great! How long on average are you seeing the import take?

On Dec 6, 2017 10:07 AM, "Jonathon Turel"  wrote:

> Hi all,
>
> A change
> 
> landed in Katello yesterday which introduced a new pattern of importing
> product content information from Candlepin into the Katello DB. This is in
> support of some new feature work and means that Candlepin will no longer be
> consulted for that information until it's time to be refreshed. All areas
> of Katello which use product content data are affected such as the Red Hat
> Repositories page and several APIs.
>
> In order to populate your local cache, please run `rake
> katello:upgrades:3.6:import_product_content`. From that point on the
> cache should be updated through ordinary use of Katello - importing
> manifests, etc. This step is not necessary unless you have a manifest
> imported and/or custom products created.
>
> I'm working on a change for the installer to do the same import and I'll
> update this thread once it's ready for review & test.
>
> Let me know if you have problems, questions, or concerns.
>
> Thanks,
>
> Jonathon
>
> --
> 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 additional maintainers in foreman-core

[Eric D Helms]

+1 to both!

On Wed, Dec 6, 2017 at 7:51 AM, Adam Ruzicka <aruzi...@redhat.com> wrote:

> +1 to both
>
> -- Adam
>
>
> On Wed, Dec 6, 2017 at 1:40 PM, Tomer Brisker <tbris...@redhat.com> wrote:
>
>> Hello,
>> ​As many of you may have noticed, foreman-core open PR​ count has been in
>> the area of 100-110 for most of the last few months. There are only a few
>> people with merge access that actively review PRs, so that the time it
>> takes for changes to be accepted can take long. I would like to propose
>> granting merge access to two more members of the community:
>>
>> Shimon Shtein - has 75 merged commits [1] and has taken part in the
>> reviews of 64 merged commits[2].
>> Michael Moll - has 71 merged commits [3] and has taken part in the
>> reviews of 130 merged commits[4]. He is also already a long time maintainer
>> of several of our other repos and has proven to be a responsible maintainer.
>>
>> Please send +1/-1 either to the list or to me in private if you prefer.
>> Per our process, unless I receive any objections within a week, I will
>> request one of the organization owners to grant them access.
>>
>> [1] https://github.com/theforeman/foreman/pulls?q=is%3Apr+author
>> %3Ashimshtein+is%3Aclosed
>> [2] https://github.com/theforeman/foreman/pulls?utf8=%E2%9C%93
>> =is%3Apr+-author%3Ashimshtein+commenter%3Ashimshtein+is%3Aclosed+
>> ​[3] https://github.com/theforeman/foreman/pulls?utf8=%E2%9C%93
>> =is%3Apr+author%3Ammoll+is%3Aclosed+
>> [4]​ https://github.com/theforeman/foreman/pulls?utf8=%E2%9C%93
>> =is%3Apr+-author%3Ammoll+commenter%3Ammoll+is%3Aclosed+
>>
>> --
>> 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.
>



-- 
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] The road to Rails 5.1

[Eric D Helms]

On Thu, Nov 30, 2017 at 5:52 PM, Michael Moll <kved...@kvedulv.de> wrote:

> Hi,
>
> On Thu, Nov 30, 2017 at 02:20:09PM -0500, Eric D Helms wrote:
> >  * Rails 5 SCL initial builds minus turbolinks exist [1]
> >  * Turobolinks 2.4.5 is being released that will have Rails 5
> compatability
> >  * Work is progressing to test rebuild Foreman stack against SCL, this
> will
> >be followed up runtime tests
> >
> > Would someone with more knowledge on the code side of the Rails 5 mind
> > sending along an update of the path we see for getting to 5.1?
>
> We're currently blocked by two external dependencies:
> - https://github.com/turbolinks/turbolinks-classic/pull/679 (already
>   merged, we're only waiting for the gem release)
> - https://github.com/oauth-xx/oauth-ruby/pull/150


Are these requires for 5.0 or 5.1?


>
>
> Once there are gem releases out, I'd open PRs to raise the lower version
> boundary of these in core and after these got in, I'd ask
> https://github.com/theforeman/foreman/pull/4867
> to get merged (BTW, Eric, please see the comment at the bottom).
>
> At that state, core would be using Rails 5.0 only and I'd open one PR
> including the 5.0 only parts of
> https://github.com/theforeman/foreman/pull/4836
>
> After that one got merged, core would be using Rails 5.0 and be
> incompatible with Rails 4.2.
>
> Plugin authors should start updating their plugins to Rails 5.0
> standards at that point.
>
> Then I'd open a PR with the switch from Rails 5.0 to 5.1 and
> https://github.com/theforeman/foreman/pull/5026
>
> After that one got merged, core is using Rails 5.1 (and probably not
> even Rails 5.0 compatible) and the RPM work can start. DEBs should just
> work fine without modifications.
>
> Plugin authors should check if anything is missing for Rails 5.1 and
> update, if needed.
>
> After that, the remaining deprecation notices with Rails 5.1 should get
> fixed and once this is done, Rails 5.2 is probably already released.
>

Generally speaking, now that we've done the up front work to get the start
of an SCL built, ran basic tests I am OK unblocking migrating core to 5.0
based on the plan above. We'll have a week or three of brokenness but if
we've planned on that and are communicating status routinely then I think
that is the best approach possible to move the code base and fix packaging.

Eric


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



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

[foreman-dev] Koji Space on /

[Eric D Helms]

Today Koji filled up its root partition which is designed to be small. In
part, there was 2.0 GB of httpd logs due to the API intensive use of Koji.
These logs are currently rotated and not compressed in anyway.

How should we handle this? A few ideas for discussion:

 1) Modify logrotate configuration to try to compress the logs
 2) Setup a cron job to compress the rotated logs
 3) Rotate the logs less

We also noticed about 850MB of mrepo cache.

-- 
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] Nominating cfouant for write access to hammer-cli-katello

[Eric D Helms]

+1 -- even though this appears to be done already -- welcome to CLI team
Christine!

On Fri, Dec 1, 2017 at 8:31 AM, Walden Raines <wrai...@redhat.com> wrote:

> +1
>
> On Thu, Nov 30, 2017 at 5:26 PM, Tom McKay <thomasmc...@redhat.com> wrote:
>
>> +1
>>
>> On Tue, Nov 21, 2017 at 11:55 AM, Chris Roberts <cdoberman1...@gmail.com>
>> wrote:
>>
>>> +1 from me
>>>
>>> On Tuesday, November 21, 2017 at 11:40:48 AM UTC-5, Andrew Kofink wrote:
>>>>
>>>> I hereby nominate Christine Fouant to gain commit access to
>>>> hammer-cli-katello. She currently has 12 merged PRs
>>>> <https://github.com/search?utf8=%E2%9C%93=author%3Acfouant+repo%3AKatello%2Fhammer-cli-katello+is%3Amerged=Issues>
>>>>  and
>>>> has helped to review 11 merged PRs
>>>> <https://github.com/search?utf8=%E2%9C%93=commenter%3Acfouant+-author%3Acfouant+repo%3AKatello%2Fhammer-cli-katello+is%3Amerged=>
>>>> .
>>>>
>>>> Let the +/-1's begin!
>>>>
>>>> --
>>>> Andrew Kofink
>>>> ako...@redhat.com
>>>> IRC: akofink
>>>> Software Engineer
>>>> Red Hat Satellite
>>>>
>>> --
>>> 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.
>



-- 
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] The road to Rails 5.1

[Eric D Helms]

On Thu, Nov 30, 2017 at 8:16 PM, Michael Moll <kved...@kvedulv.de> wrote:

> On Thu, Nov 30, 2017 at 08:06:53PM -0500, Eric D Helms wrote:
> > Thanks for the update Michael! In working on test builds, something I
> > noticed was that we currently have fog 1.41 which is locked to json < 2.
> > However, Ruby 2.4 provides json 2+. Fog  1.42 appears to require json 2+.
> > Is this a dependency that we can update alongside the Rails update?
>
> I found https://github.com/theforeman/foreman/pull/4869


Good find! I know this will likely break nightlies on the RPM side given
JSON is only at 2+ in Ruby 2.4. However, based on your previous email it
sounds like we are going to have to bite the bullet on some length of time
where RPMs are broken? The question then is how long do we allow that
period to be based upon how much time we give plugins to switch to Rails 5?


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



-- 
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] The road to Rails 5.1

[Eric D Helms]

Thanks for the update Michael! In working on test builds, something I
noticed was that we currently have fog 1.41 which is locked to json < 2.
However, Ruby 2.4 provides json 2+. Fog  1.42 appears to require json 2+.
Is this a dependency that we can update alongside the Rails update?

On Thu, Nov 30, 2017 at 5:52 PM, Michael Moll <kved...@kvedulv.de> wrote:

> Hi,
>
> On Thu, Nov 30, 2017 at 02:20:09PM -0500, Eric D Helms wrote:
> >  * Rails 5 SCL initial builds minus turbolinks exist [1]
> >  * Turobolinks 2.4.5 is being released that will have Rails 5
> compatability
> >  * Work is progressing to test rebuild Foreman stack against SCL, this
> will
> >be followed up runtime tests
> >
> > Would someone with more knowledge on the code side of the Rails 5 mind
> > sending along an update of the path we see for getting to 5.1?
>
> We're currently blocked by two external dependencies:
> - https://github.com/turbolinks/turbolinks-classic/pull/679 (already
>   merged, we're only waiting for the gem release)
> - https://github.com/oauth-xx/oauth-ruby/pull/150
>
> Once there are gem releases out, I'd open PRs to raise the lower version
> boundary of these in core and after these got in, I'd ask
> https://github.com/theforeman/foreman/pull/4867
> to get merged (BTW, Eric, please see the comment at the bottom).
>
> At that state, core would be using Rails 5.0 only and I'd open one PR
> including the 5.0 only parts of
> https://github.com/theforeman/foreman/pull/4836
>
> After that one got merged, core would be using Rails 5.0 and be
> incompatible with Rails 4.2.
>
> Plugin authors should start updating their plugins to Rails 5.0
> standards at that point.
>
> Then I'd open a PR with the switch from Rails 5.0 to 5.1 and
> https://github.com/theforeman/foreman/pull/5026
>
> After that one got merged, core is using Rails 5.1 (and probably not
> even Rails 5.0 compatible) and the RPM work can start. DEBs should just
> work fine without modifications.
>
> Plugin authors should check if anything is missing for Rails 5.1 and
> update, if needed.
>
> After that, the remaining deprecation notices with Rails 5.1 should get
> fixed and once this is done, Rails 5.2 is probably already released.
>
> 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.
>



-- 
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] The road to Rails 5.1

[Eric D Helms]

Circling back to this as we've made some progress on the SCL front.

Updates

 * Rails 5 SCL initial builds minus turbolinks exist [1]
 * Turobolinks 2.4.5 is being released that will have Rails 5 compatability
 * Work is progressing to test rebuild Foreman stack against SCL, this will
be followed up runtime tests

Would someone with more knowledge on the code side of the Rails 5 mind
sending along an update of the path we see for getting to 5.1?


[1] https://copr.fedorainfracloud.org/coprs/g/theforeman/tfm-ror51/

On Fri, Oct 20, 2017 at 12:20 PM, Ohad Levy <ohadl...@gmail.com> wrote:

>
>
> On Oct 20, 2017 11:39 AM, "Tomas Strachota" <tstra...@redhat.com> wrote:
>
> I'm also fine with removing them. I don't think it adds much value
> when we're moving towards UI based on React.
>
>
> I would be happy if someone compare UI responsiveness before we make the
> changes
>
>
> T.
>
> On Fri, Oct 20, 2017 at 8:17 AM, Ivan Necas <ine...@redhat.com> wrote:
> > Not hard feelings from me to remove turbo-links:)
> >
> > -- Ivan
> >
> > On Thu, Oct 19, 2017 at 7:55 PM, Walden Raines <wrai...@redhat.com>
> wrote:
> >> I personally would be okay if we removed turbolinks from foreman
> entirely.
> >> We want to replace it in the future with a true single page app
> anyway.  But
> >> if others want to put in the effort to maintain it I would support that
> >> effort as well.
> >>
> >> Cheers,
> >> Walden
> >>
> >> On Tue, Oct 17, 2017 at 7:48 PM, Eric D Helms <ericdhe...@gmail.com>
> wrote:
> >>>
> >>> Thanks for the update Michael. I just want to point interested parties
> to
> >>> the RPM side of the discussions that are on going over in
> >>> https://groups.google.com/forum/#!topic/foreman-dev/xJyxMx1lXy4
> >>>
> >>> On Tue, Oct 17, 2017 at 4:32 PM, Michael Moll <kved...@kvedulv.de>
> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> while the original plan was to switch to Rails 5.0 soon and then begin
> >>>> 5.1 work, it's a major downside that RPMs would be broken for a
> >>>> potentially longer period, so I closed
> >>>> https://github.com/theforeman/foreman/pull/4867 and like to draw the
> >>>> attention of interested parties to
> >>>> https://github.com/theforeman/foreman/pull/4836 where all the changes
> >>>> that are queued up lead to a still 100% green Rails 5.0 test run and
> >>>> leave 21 test failures with 5.1.
> >>>>
> >>>> I guess two of iNečas' recently opened PRs will fix some of these.
> >>>>
> >>>> Besides the missing changes to get green tests one major problem is
> that
> >>>> there's no Rails 5 compatible version of turbolinks-classic, so either
> >>>> Foreman needs to move to turbolinks 5 or a forked turbolinks-classic
> gem
> >>>> would be needed, if turbolinks should be kept.
> >>>>
> >>>> In the meanwhile Rails 5.1 should be packaged for RPM in some way...
> :)
> >>>>
> >>>> 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.
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> 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.
> >>
> >>
> >> --
> >> 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

[foreman-dev] Re: Katello Rails 5 PR Testing

[Eric D Helms]

Updates. The test job is currently working as expected for Katello and
failing with an error a developer will need to look into. See traceback
below.

NOTE: For any other plugin maintainers reading this if you'd like a
dedicated Rails 5 PR test job let me know and we can work to add one
similar to what I've done for Katello.

 |   class AddDockerManifestList < ActiveRecord::Migration[4.2]
(called from load at
/usr/local/rvm/gems/ruby-2.4.0@katello-pr-test-29/bin/rake:22)
== 20171010172724 AddDockerManifestList: migrating 
-- create_table(:katello_docker_manifest_lists, {})
   -> 0.0028s
-- create_table(:katello_repository_docker_manifest_lists, {})
   -> 0.0020s
-- create_table(:katello_docker_manifest_list_manifests, {})
   -> 0.0019s
-- remove_foreign_key(:katello_docker_tags, :docker_manifest)
rake aborted!
StandardError: An error has occurred, this and all later migrations canceled:

Table 'katello_docker_tags' has no foreign key for docker_manifest
/usr/local/rvm/gems/ruby-2.4.0@katello-pr-test-29/gems/activerecord-5.0.6/lib/active_record/connection_adapters/abstract/schema_statements.rb:970:in
`foreign_key_for!'
/usr/local/rvm/gems/ruby-2.4.0@katello-pr-test-29/gems/activerecord-5.0.6/lib/active_record/connection_adapters/abstract/schema_statements.rb:940:in
`remove_foreign_key'
/usr/local/rvm/gems/ruby-2.4.0@katello-pr-test-29/gems/activerecord-5.0.6/lib/active_record/migration.rb:846:in
`block in method_missing'
/usr/local/rvm/gems/ruby-2.4.0@katello-pr-test-29/gems/activerecord-5.0.6/lib/active_record/migration.rb:815:in
`block in say_with_time'
/usr/local/rvm/gems/ruby-2.4.0@katello-pr-test-29/gems/activerecord-5.0.6/lib/active_record/migration.rb:815:in
`say_with_time'
/usr/local/rvm/gems/ruby-2.4.0@katello-pr-test-29/gems/activerecord-5.0.6/lib/active_record/migration.rb:835:in
`method_missing'
/var/lib/workspace/workspace/katello-pr-test/db/migrate/20171010172724_add_docker_manifest_list.rb:23:in
`up'


On Wed, Nov 29, 2017 at 3:36 PM, Eric D Helms <ericdhe...@gmail.com> wrote:

> Katello developers may notice a 'rails-5' status pop up on pull requests.
> I am working to add testing against Rails 5 stack. This currently fails so
> it can safely be ignored. This thread will get an update when the testing
> has been officially implemented and thus should be a gate for new PRs.
>
> --
> Eric D. Helms
> Red Hat Engineering
>



-- 
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] Proposal: Foreman 1.18 = 2.0

[Eric D Helms]

My two cents are that we shouldn't arbitrarily bump the version. Versions
have and signal meaning to users. Especially when we are talking about the
main line, core project. Fortunately or unfortunately, major version bumps
signal either a major shift or change and/or a marketing opportunity.
Further, major version changes should signal that plugins are also going to
have to change to stay compliant. I'd suggest we stick with folks
suggestions of finding some things to entirely deprecate and bump the
version and/or adding some major support components so that 2.0 is a major
change. Things I've head so far:

 * Rails 5.1 and Ruby 2.4 support
 * Remove API v1
 * Vertical Nav

Some further, potentially more boring ideas as part of a "Foreman 2.0, new
stack, new look" release:

 * Pick your own config management (aka dropping Puppet as default within
the application obviously stilled required for the installer)
 * Updates to repository structure such as adding a client repository
 * Tasks support in Core


This, based on comments, also sounds like a good time to visit a versioning
policy so that we adhere to it and give plugins and users some
predictability.


Eric



On Wed, Nov 29, 2017 at 12:07 PM, Eric D Helms <ericdhe...@gmail.com> wrote:

>
>
> On Wed, Nov 29, 2017 at 8:49 AM, Bernhard Suttner <sutt...@atix.de> wrote:
>
>> I also like the idea of a version 2.0 very much. Personally, I would be
>> very happy to move bastion from katello to foreman so that it's possible to
>> create modern, angular js components within foreman. One more reason to do
>> this is, because I think foreman should be the structure, the base
>> "framework" all other plugins like katello can live in. Just my thoughts...
>>
>
> This is not going to happen regardless. All net new UI is being created in
> React. Bastion is effectively in a critical bug fix state only. All React
> work is being done in Foreman core, or plugins directly (e.g. all new React
> work in Katello is going into Katello directly). You can consider the use
> of Angular within Foreman and Katello dead  for all intents and purposes.
>
> Eric
>
>
>>
>> Best regards,
>> Bernhard Suttner
>>
>> ATIX - The Linux & Open Source Company
>> https://www.atix.de
>>
>> -Ursprüngliche Nachricht-
>> > Von:Lukas Zapletal <l...@redhat.com>
>> > Gesendet: Mittwoch 29 November 2017 14:18
>> > An: foreman-dev <foreman-dev@googlegroups.com>
>> > Betreff: Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0
>> >
>> > > Bikeshedding about SemVer aside, I'm good with doing a 2.0 release in
>> > > the near future, but *please* lets use it to deprecate / drop stuff we
>> > > no longer want to maintain. Otherwise there's no real point to it.
>> >
>> > I agree we can take this "opportunity" to drop some deprecated things
>> > like V1 API, but I don't see many other things. We are pretty good in
>> > deprecating things using our "two releases" rule which should be
>> > followed no matter if we bump major version or not.
>> >
>> > Let's not block 2.0 with any feature, I wrote the reasons, if we fit
>> > in some deprecation work why not. But's let's agree on 2.0 timeframe
>> > regardless of any planning.
>> >
>> > --
>> > 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.
>> >
>>
>> --
>> 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
>



-- 
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] Proposal: Foreman 1.18 = 2.0

[Eric D Helms]

On Wed, Nov 29, 2017 at 8:49 AM, Bernhard Suttner <sutt...@atix.de> wrote:

> I also like the idea of a version 2.0 very much. Personally, I would be
> very happy to move bastion from katello to foreman so that it's possible to
> create modern, angular js components within foreman. One more reason to do
> this is, because I think foreman should be the structure, the base
> "framework" all other plugins like katello can live in. Just my thoughts...
>

This is not going to happen regardless. All net new UI is being created in
React. Bastion is effectively in a critical bug fix state only. All React
work is being done in Foreman core, or plugins directly (e.g. all new React
work in Katello is going into Katello directly). You can consider the use
of Angular within Foreman and Katello dead  for all intents and purposes.

Eric


>
> Best regards,
> Bernhard Suttner
>
> ATIX - The Linux & Open Source Company
> https://www.atix.de
>
> -Ursprüngliche Nachricht-
> > Von:Lukas Zapletal <l...@redhat.com>
> > Gesendet: Mittwoch 29 November 2017 14:18
> > An: foreman-dev <foreman-dev@googlegroups.com>
> > Betreff: Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0
> >
> > > Bikeshedding about SemVer aside, I'm good with doing a 2.0 release in
> > > the near future, but *please* lets use it to deprecate / drop stuff we
> > > no longer want to maintain. Otherwise there's no real point to it.
> >
> > I agree we can take this "opportunity" to drop some deprecated things
> > like V1 API, but I don't see many other things. We are pretty good in
> > deprecating things using our "two releases" rule which should be
> > followed no matter if we bump major version or not.
> >
> > Let's not block 2.0 with any feature, I wrote the reasons, if we fit
> > in some deprecation work why not. But's let's agree on 2.0 timeframe
> > regardless of any planning.
> >
> > --
> > 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.
> >
>
> --
> 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] Community-developed Ansible modules for Foreman API objects

[Eric D Helms]

As well, hammer is a bit of a beast dependency wise. We currently package
it in the SCL, I'm not sure how well it works from gem install and even if
with all of that you are increasing the barrier to entry for users by
requiring Ruby, gem installs, potentially the SCL for newer Ruby versions.
I appreciate the thought behind it but it feels more like a can of worms
that is better off with the lid staying on.

Eric

On Wed, Nov 29, 2017 at 8:06 AM, Andrew Kofink <akof...@redhat.com> wrote:

> Yeah, modules have to be written in Python for inclusion in Ansible core
> [1].
>
> [1] http://docs.ansible.com/ansible/latest/dev_guide/
> developing_modules_checklist.html
>
> On Wed, Nov 29, 2017 at 4:40 AM, Ewoud Kohl van Wijngaarden <
> ew...@kohlvanwijngaarden.nl> wrote:
>
>> I had a look at this at some point but what I really dislike about Hammer
>> as an API is that the JSON output is also capitalized and inconsistent.
>> Ended up with large mappings and quickly gave up. Maybe I missed something
>> and it can be done easily.
>>
>>
>> On Wed, Nov 29, 2017 at 09:35:46AM +, Sean O'Keeffe wrote:
>>
>>> Here's a radical thought, use Hammer...
>>>
>>> Ansible modules do not have to be written in Python[2], although Ansible
>>> does provide some nice shortcuts with Python, all that is really required
>>> is JSON output... Some Ruby examples [1]
>>> A couple of things to note if we were to entertain going down this route;
>>> - How does DOCUMENTATION work for non-python modules? I played around
>>> for a
>>> bit, but couldn't get ansible-doc to work..
>>> - If the goal is to get them into Ansible core, will they accept Ruby
>>> modules? Looking at Ansible core I think all the modules are python...
>>>
>>>
>>> [1] https://github.com/ansible/ansible-for-rubyists
>>> [2]
>>> http://ansible-docs.readthedocs.io/zh/stable-2.0/rst/develop
>>> ing_modules.html
>>>
>>> On Fri, Oct 27, 2017 at 8:11 PM, Michael Hofer <
>>> michael.ho...@adfinis-sygroup.ch> wrote:
>>>
>>> On Wed, 25 Oct 2017 08:09:10 -0400
>>>> Andrew Kofink <akof...@redhat.com> wrote:
>>>> [...]
>>>> > If given a choice, I would vote for Nailgun, a more mature project
>>>> with
>>>> > more contributors and guaranteed future contribution from Satellite
>>>> QA.
>>>> > There is a bit of a gap between foreman-ansible-modules and Nailgun,
>>>> given
>>>> > that it is not purpose built; for this, we do include
>>>> > ansible_nailgun_cement.py [1].
>>>> >
>>>> > I appreciate the support and interest from the community.
>>>>
>>>> So far we've only used python-foreman in a few different projects, one
>>>> to
>>>> configure Foreman based on a YAML file. We use python-foreman to resolve
>>>> the
>>>> IDs first thus the actual names of the templates, etc. can be used.
>>>> Working
>>>> with the lib is nice but it still needs some glue because the API is
>>>> inconsistent and doing a lookup for the ID is not aligned for all
>>>> resources.
>>>>
>>>> I have no experience with nailgun but from my point of view dependencies
>>>> are
>>>> not that big of a deal when provided as proper packages. E.g. to use the
>>>> Ansible mysql_db module you require python-mysqldb.
>>>>
>>>> I'd love to switch to an upstream Ansible module to configure Foreman
>>>> and
>>>> improve our existing playbooks.
>>>>
>>>> Thanks for all the hard work so far!
>>>>
>>>
>> --
>> 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.
>>
>
>
>
> --
> Andrew Kofink
> akof...@redhat.com
> IRC: akofink
> Software Engineer
> Red Hat Satellite
>
> --
> 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] 1.16.0 release builds started

[Eric D Helms]

Is there an expected or target date for the release to go out since builds
have started? That would help plugins plan for release work.

On Wed, Nov 29, 2017 at 8:16 AM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:

> A quick heads up: 1.16.0 final was tagged and we started the builds.
> Especially the ARM builds a take a while.
>
> --
> 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] Koji repo sync metadata problem

[Eric D Helms]

The update seems to have completed, with the new CentOS repository added to
Koji and repositories regenerated. For the moment, the
foreman-nightly*-rhel7-build tags have been updated to remove rhel as an
external repository and have been replaced with CentOS (7.4). If you notice
any oddities building, please let us know so we can work through them.


Eric

On Thu, Nov 16, 2017 at 7:14 PM, Eric D Helms <ericdhe...@gmail.com> wrote:

> I started an mrepo run after adding CentOS in a screen session. The run
> appears to be running a lot longer than previous and it's not clear to me
> what exactly it's doing at present or whats safe to do. Lukas could you
> check on it in your morning and see if you spot anything odd about why it
> seems to have stalled or slowed down?
>
> On Thu, Nov 16, 2017 at 6:01 AM, Ewoud Kohl van Wijngaarden <
> ew...@kohlvanwijngaarden.nl> wrote:
>
>> Those sound like good arguments, but if we don't test on older releases
>> then we don't know for sure they work either. IMHO it's acceptable to
>> explicitly only support EL 7.4 and up. We don't have the resources to
>> support older versions especially since CentOS doesn't support that either.
>> If users want verified working versions on EL < 7.4 then they should either
>> help us properly support it or buy support from a vendor that does want to
>> promise it works.
>>
>>
>> On Thu, Nov 16, 2017 at 08:56:39AM +0100, Lukas Zapletal wrote:
>>
>>> I would be against syncing regularly but I don't do much packaging so
>>> it's up to you. The problem I see is "random" breakage. You come to
>>> work on Monday after sync and if you don't realize the package was
>>> deleted from EPEL, you can burn hour or something to figure it out
>>> sometimes. This was pretty clear case but as you know there are
>>> situations (SCL) when it is not that clear.
>>>
>>> If we ever deploy new koji, I'd vote to avoid getting OS updates
>>> completely, just base channels and explicit updates when we need it.
>>> We need reproducible builds, with autosync we are not getting it.
>>>
>>> One note, if we sync CentOS or RHEL base to particular version,
>>> chances are that SELinux won't load on older releases. So basically we
>>> must be ready to do minimum requirements change here.
>>>
>>> Thanks for solving the problem.
>>>
>>> LZ
>>>
>>> On Wed, Nov 15, 2017 at 10:05 PM, Ewoud Kohl van Wijngaarden
>>> <ew...@kohlvanwijngaarden.nl> wrote:
>>>
>>>> I think we should sync & update. CentOS has no concept of supported
>>>> minor
>>>> releases and we should be testing with a supported release.
>>>>
>>>>
>>>> On Wed, Nov 15, 2017 at 03:57:40PM -0500, Eric D Helms wrote:
>>>>
>>>>>
>>>>> This now appears to be working again. One out standing question that
>>>>> affects nodejs- packaging builds.
>>>>>
>>>>> As part of the RHEL 7.4 release, http-parser was removed from EPEL.
>>>>> With
>>>>> this latest round of Koji external repositories update we now have a
>>>>> newer
>>>>> EPEL with this package removed. We did not update our CentOS external
>>>>> repository that would include this package. Not updating the base OS
>>>>> has
>>>>> been our policy for a while now it would seem. We have two options:
>>>>>
>>>>> 1) Sync and update CentOS
>>>>> 2) Add http-parser to the overrides tag for foreman-nightly
>>>>>
>>>>> On Wed, Nov 15, 2017 at 2:11 PM, Eric D Helms <ericdhe...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> I had forgotten to run the repo-regen on Koji. That is finishing up
>>>>>> now.
>>>>>> I
>>>>>> will run another test after and report back.
>>>>>>
>>>>>> On Wed, Nov 15, 2017 at 2:08 PM, Patrick Creech <pcre...@redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>> On Wed, 2017-11-15 at 14:00 -0500, Patrick Creech wrote:
>>>>>>> > On Wed, 2017-11-15 at 19:56 +0100, Lukas Zapletal wrote:
>>>>>>> > > I do not have access here, can someone take a look? Are repodata
>>>>>>> > > present for EPEL7?
>>>>>>> >
>>>>>>> > If I have the correct path, it does not appear so:
>>>>>>> >
>>

Re: [foreman-dev] Getting Foreman and Smart-Proxy to run in FIPS environment.

[Eric D Helms]

is would be
temporary until we are fully FIPS compliant?


> Considering the amount of dependencies Foreman and Smart-Proxy have, I
> think would be useful to have all CI environments switched to run in
> FIPS mode: this should increase the probability of discovering of new
> FIPS-related issues before our users.
> Lastly, a FIPS-compatible caching solution for Rails needs to be
> found, if none exist, an existing one needs to be modified to support
> FIPS.
>

Big +1 -- if we reach FIPS compliancy, then I am all for turning it on on
all the Jenkins slaves as well as ensuring that our Vagrant boxes (for
users and CI) have it turned out so we are running in that mode at all
times.


>
>
> Any feedback would be appreciated,
> -d
>
> [1] Wikipedia article on FIPS 140-2, https://en.wikipedia.org/wiki/
> FIPS_140-2
> [2] Approved Security Functions for FIPS 140-2,
> https://csrc.nist.gov/csrc/media/publications/fips/140/2/fin
> al/documents/fips1402annexa.pdf
> [3] List of algorithms not approved for FIPS 140-2,
> https://docs.oracle.com/cd/E36784_01/html/E54953/fips-notok-1.html
> [4] Ruby project’s gdb helper functions,
> https://github.com/ruby/ruby/blob/trunk/.gdbinit
> [5] Catching SIGABRTs with gdb and ruby-specific .gdbinit,
> https://gist.github.com/witlessbird/904fefb0031c2eda96da61bd19424c86
>
> --
> 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] Koji repo sync metadata problem

[Eric D Helms]

I started an mrepo run after adding CentOS in a screen session. The run
appears to be running a lot longer than previous and it's not clear to me
what exactly it's doing at present or whats safe to do. Lukas could you
check on it in your morning and see if you spot anything odd about why it
seems to have stalled or slowed down?

On Thu, Nov 16, 2017 at 6:01 AM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:

> Those sound like good arguments, but if we don't test on older releases
> then we don't know for sure they work either. IMHO it's acceptable to
> explicitly only support EL 7.4 and up. We don't have the resources to
> support older versions especially since CentOS doesn't support that either.
> If users want verified working versions on EL < 7.4 then they should either
> help us properly support it or buy support from a vendor that does want to
> promise it works.
>
>
> On Thu, Nov 16, 2017 at 08:56:39AM +0100, Lukas Zapletal wrote:
>
>> I would be against syncing regularly but I don't do much packaging so
>> it's up to you. The problem I see is "random" breakage. You come to
>> work on Monday after sync and if you don't realize the package was
>> deleted from EPEL, you can burn hour or something to figure it out
>> sometimes. This was pretty clear case but as you know there are
>> situations (SCL) when it is not that clear.
>>
>> If we ever deploy new koji, I'd vote to avoid getting OS updates
>> completely, just base channels and explicit updates when we need it.
>> We need reproducible builds, with autosync we are not getting it.
>>
>> One note, if we sync CentOS or RHEL base to particular version,
>> chances are that SELinux won't load on older releases. So basically we
>> must be ready to do minimum requirements change here.
>>
>> Thanks for solving the problem.
>>
>> LZ
>>
>> On Wed, Nov 15, 2017 at 10:05 PM, Ewoud Kohl van Wijngaarden
>> <ew...@kohlvanwijngaarden.nl> wrote:
>>
>>> I think we should sync & update. CentOS has no concept of supported minor
>>> releases and we should be testing with a supported release.
>>>
>>>
>>> On Wed, Nov 15, 2017 at 03:57:40PM -0500, Eric D Helms wrote:
>>>
>>>>
>>>> This now appears to be working again. One out standing question that
>>>> affects nodejs- packaging builds.
>>>>
>>>> As part of the RHEL 7.4 release, http-parser was removed from EPEL. With
>>>> this latest round of Koji external repositories update we now have a
>>>> newer
>>>> EPEL with this package removed. We did not update our CentOS external
>>>> repository that would include this package. Not updating the base OS has
>>>> been our policy for a while now it would seem. We have two options:
>>>>
>>>> 1) Sync and update CentOS
>>>> 2) Add http-parser to the overrides tag for foreman-nightly
>>>>
>>>> On Wed, Nov 15, 2017 at 2:11 PM, Eric D Helms <ericdhe...@gmail.com>
>>>> wrote:
>>>>
>>>> I had forgotten to run the repo-regen on Koji. That is finishing up now.
>>>>> I
>>>>> will run another test after and report back.
>>>>>
>>>>> On Wed, Nov 15, 2017 at 2:08 PM, Patrick Creech <pcre...@redhat.com>
>>>>> wrote:
>>>>>
>>>>> On Wed, 2017-11-15 at 14:00 -0500, Patrick Creech wrote:
>>>>>> > On Wed, 2017-11-15 at 19:56 +0100, Lukas Zapletal wrote:
>>>>>> > > I do not have access here, can someone take a look? Are repodata
>>>>>> > > present for EPEL7?
>>>>>> >
>>>>>> > If I have the correct path, it does not appear so:
>>>>>> >
>>>>>> > [root@koji repodata]# pwd
>>>>>> > /mnt/koji/external-repos/epel7-x86_64/epel/repodata
>>>>>> > [root@koji repodata]# ls
>>>>>> > [root@koji repodata]#
>>>>>> >
>>>>>>
>>>>>> I might not have, this path DOES have repodata:
>>>>>>
>>>>>> /mnt/koji/external-repos/www/epel7-x86_64/RPMS.epel/repodata
>>>>>>
>>>>>> > > LZ
>>>>>> > >
>>>>>> > > On Wed, Nov 15, 2017 at 6:15 PM, Ewoud Kohl van Wijngaarden
>>>>>> > > <ew...@kohlvanwijngaarden.nl> wrote:
>>>>>> > > > I still get errors when building:
>>>>>> > > 

Re: [foreman-dev] Koji repo sync metadata problem

[Eric D Helms]

This now appears to be working again. One out standing question that
affects nodejs- packaging builds.

As part of the RHEL 7.4 release, http-parser was removed from EPEL. With
this latest round of Koji external repositories update we now have a newer
EPEL with this package removed. We did not update our CentOS external
repository that would include this package. Not updating the base OS has
been our policy for a while now it would seem. We have two options:

 1) Sync and update CentOS
 2) Add http-parser to the overrides tag for foreman-nightly

On Wed, Nov 15, 2017 at 2:11 PM, Eric D Helms <ericdhe...@gmail.com> wrote:

> I had forgotten to run the repo-regen on Koji. That is finishing up now. I
> will run another test after and report back.
>
> On Wed, Nov 15, 2017 at 2:08 PM, Patrick Creech <pcre...@redhat.com>
> wrote:
>
>> On Wed, 2017-11-15 at 14:00 -0500, Patrick Creech wrote:
>> > On Wed, 2017-11-15 at 19:56 +0100, Lukas Zapletal wrote:
>> > > I do not have access here, can someone take a look? Are repodata
>> > > present for EPEL7?
>> >
>> > If I have the correct path, it does not appear so:
>> >
>> > [root@koji repodata]# pwd
>> > /mnt/koji/external-repos/epel7-x86_64/epel/repodata
>> > [root@koji repodata]# ls
>> > [root@koji repodata]#
>> >
>>
>> I might not have, this path DOES have repodata:
>>
>> /mnt/koji/external-repos/www/epel7-x86_64/RPMS.epel/repodata
>>
>> > > LZ
>> > >
>> > > On Wed, Nov 15, 2017 at 6:15 PM, Ewoud Kohl van Wijngaarden
>> > > <ew...@kohlvanwijngaarden.nl> wrote:
>> > > > I still get errors when building:
>> > > >
>> > > > http://koji.katello.org/koji/taskinfo?taskID=52363
>> > > > http://koji.katello.org/kojifiles/work/tasks/2363/52363/root.log
>> > > >
>> > > > DEBUG util.py:439:  Error downloading packages:
>> > > > DEBUG util.py:439:1:nodejs-6.10.3-1.el7.x86_64: failed to
>> retrieve
>> > > > nodejs-6.10.3-1.el7.x86_64.rpm from build
>> > > > DEBUG util.py:439:  error was [Errno 2] Local file does not exist:
>> > > > /mnt/koji/external-repos/www/epel7-x86_64/RPMS.epel/nodejs-6
>> .10.3-1.el7.x86_64.rpm
>> > > > DEBUG util.py:439:http-parser-2.7.1-3.el7.x86_64: failed to
>> retrieve
>> > > > http-parser-2.7.1-3.el7.x86_64.rpm from build
>> > > > DEBUG util.py:439:  error was [Errno 2] Local file does not exist:
>> > > > /mnt/koji/external-repos/www/epel7-x86_64/RPMS.epel/http-par
>> ser-2.7.1-3.el7.x86_64.rpm
>> > > > DEBUG util.py:439:1:npm-3.10.10-1.6.10.3.1.el7.x86_64: failed
>> to
>> > > > retrieve npm-3.10.10-1.6.10.3.1.el7.x86_64.rpm from build
>> > > > DEBUG util.py:439:  error was [Errno 2] Local file does not exist:
>> > > > /mnt/koji/external-repos/www/epel7-x86_64/RPMS.epel/npm-3.10
>> .10-1.6.10.3.1.el7.x86_64.rpm
>> > > >
>> > > >
>> > > > On Wed, Nov 15, 2017 at 11:44:24AM -0500, Eric D Helms wrote:
>> > > > >
>> > > > > Looks like everything is back up and working as expected. For
>> packagers,
>> > > > > keep in mind that this updated some of our external repositories
>> to their
>> > > > > latest versions if you see any oddities. This also means that
>> Fedora 27 is
>> > > > > available as an external repository for Pulp and Katello clients.
>> > > > >
>> > > > > On Wed, Nov 15, 2017 at 9:32 AM, Lukas Zapletal <l...@redhat.com>
>> wrote:
>> > > > >
>> > > > > > Hey,
>> > > > > >
>> > > > > > when I initiated mrepo -n (dry run) this morning to see how
>> mrepo
>> > > > > > works on our koji in order to test if we are able to add Fedora
>> 27 for
>> > > > > > Pulp, I learned that this "dry run" is actually a real run and
>> mrepo
>> > > > > > initiated full resync of our content without metadata
>> regeneration.
>> > > > > >
>> > > > > > This rendered our external repositories unusable as all
>> metadata were
>> > > > > > deleted. All builds will fail today with missing dependencies.
>> > > > > >
>> > > > > > The plan: we need to let mrepo finish "dry run" downloading of
>> Fedora
>> > > >

Re: [foreman-dev] Koji repo sync metadata problem

[Eric D Helms]

I had forgotten to run the repo-regen on Koji. That is finishing up now. I
will run another test after and report back.

On Wed, Nov 15, 2017 at 2:08 PM, Patrick Creech <pcre...@redhat.com> wrote:

> On Wed, 2017-11-15 at 14:00 -0500, Patrick Creech wrote:
> > On Wed, 2017-11-15 at 19:56 +0100, Lukas Zapletal wrote:
> > > I do not have access here, can someone take a look? Are repodata
> > > present for EPEL7?
> >
> > If I have the correct path, it does not appear so:
> >
> > [root@koji repodata]# pwd
> > /mnt/koji/external-repos/epel7-x86_64/epel/repodata
> > [root@koji repodata]# ls
> > [root@koji repodata]#
> >
>
> I might not have, this path DOES have repodata:
>
> /mnt/koji/external-repos/www/epel7-x86_64/RPMS.epel/repodata
>
> > > LZ
> > >
> > > On Wed, Nov 15, 2017 at 6:15 PM, Ewoud Kohl van Wijngaarden
> > > <ew...@kohlvanwijngaarden.nl> wrote:
> > > > I still get errors when building:
> > > >
> > > > http://koji.katello.org/koji/taskinfo?taskID=52363
> > > > http://koji.katello.org/kojifiles/work/tasks/2363/52363/root.log
> > > >
> > > > DEBUG util.py:439:  Error downloading packages:
> > > > DEBUG util.py:439:1:nodejs-6.10.3-1.el7.x86_64: failed to
> retrieve
> > > > nodejs-6.10.3-1.el7.x86_64.rpm from build
> > > > DEBUG util.py:439:  error was [Errno 2] Local file does not exist:
> > > > /mnt/koji/external-repos/www/epel7-x86_64/RPMS.epel/nodejs-
> 6.10.3-1.el7.x86_64.rpm
> > > > DEBUG util.py:439:http-parser-2.7.1-3.el7.x86_64: failed to
> retrieve
> > > > http-parser-2.7.1-3.el7.x86_64.rpm from build
> > > > DEBUG util.py:439:  error was [Errno 2] Local file does not exist:
> > > > /mnt/koji/external-repos/www/epel7-x86_64/RPMS.epel/http-
> parser-2.7.1-3.el7.x86_64.rpm
> > > > DEBUG util.py:439:1:npm-3.10.10-1.6.10.3.1.el7.x86_64: failed to
> > > > retrieve npm-3.10.10-1.6.10.3.1.el7.x86_64.rpm from build
> > > > DEBUG util.py:439:  error was [Errno 2] Local file does not exist:
> > > > /mnt/koji/external-repos/www/epel7-x86_64/RPMS.epel/npm-3.
> 10.10-1.6.10.3.1.el7.x86_64.rpm
> > > >
> > > >
> > > > On Wed, Nov 15, 2017 at 11:44:24AM -0500, Eric D Helms wrote:
> > > > >
> > > > > Looks like everything is back up and working as expected. For
> packagers,
> > > > > keep in mind that this updated some of our external repositories
> to their
> > > > > latest versions if you see any oddities. This also means that
> Fedora 27 is
> > > > > available as an external repository for Pulp and Katello clients.
> > > > >
> > > > > On Wed, Nov 15, 2017 at 9:32 AM, Lukas Zapletal <l...@redhat.com>
> wrote:
> > > > >
> > > > > > Hey,
> > > > > >
> > > > > > when I initiated mrepo -n (dry run) this morning to see how mrepo
> > > > > > works on our koji in order to test if we are able to add Fedora
> 27 for
> > > > > > Pulp, I learned that this "dry run" is actually a real run and
> mrepo
> > > > > > initiated full resync of our content without metadata
> regeneration.
> > > > > >
> > > > > > This rendered our external repositories unusable as all metadata
> were
> > > > > > deleted. All builds will fail today with missing dependencies.
> > > > > >
> > > > > > The plan: we need to let mrepo finish "dry run" downloading of
> Fedora
> > > > > > 27 and then we need to reexecute it with proper flags:
> > > > > >
> > > > > > cat /usr/local/bin/koji-sync-external-repos
> > > > > > #!/bin/bash
> > > > > > mrepo -qugf
> > > > > > koji list-targets --quiet | awk '{print $2}' | sort -u | xargs
> -I '{}'
> > > > > > koji regen-repo --nowait '{}'
> > > > > >
> > > > > > Note the -u -g -f flags for mrepo, this will cause all metadata
> to be
> > > > > > regenerated. Once this command is done, koji will see missing
> > > > > > dependencies to appear.
> > > > > >
> > > > > > The dry run of mrepo is running in screen and it is about to
> finish
> > > > > > hopefully soon. I will defer this to Eric in case it won't
> finish by
> > > > > > EMEA EOB.
> > > >

Re: [foreman-dev] Koji repo sync metadata problem

[Eric D Helms]

Looks like everything is back up and working as expected. For packagers,
keep in mind that this updated some of our external repositories to their
latest versions if you see any oddities. This also means that Fedora 27 is
available as an external repository for Pulp and Katello clients.

On Wed, Nov 15, 2017 at 9:32 AM, Lukas Zapletal <l...@redhat.com> wrote:

> Hey,
>
> when I initiated mrepo -n (dry run) this morning to see how mrepo
> works on our koji in order to test if we are able to add Fedora 27 for
> Pulp, I learned that this "dry run" is actually a real run and mrepo
> initiated full resync of our content without metadata regeneration.
>
> This rendered our external repositories unusable as all metadata were
> deleted. All builds will fail today with missing dependencies.
>
> The plan: we need to let mrepo finish "dry run" downloading of Fedora
> 27 and then we need to reexecute it with proper flags:
>
> cat /usr/local/bin/koji-sync-external-repos
> #!/bin/bash
> mrepo -qugf
> koji list-targets --quiet | awk '{print $2}' | sort -u | xargs -I '{}'
> koji regen-repo --nowait '{}'
>
> Note the -u -g -f flags for mrepo, this will cause all metadata to be
> regenerated. Once this command is done, koji will see missing
> dependencies to appear.
>
> The dry run of mrepo is running in screen and it is about to finish
> hopefully soon. I will defer this to Eric in case it won't finish by
> EMEA EOB.
>
> Sorry for inconvenience, but dry run should be dry run, right.
>
> --
> 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.
>



-- 
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] Regular Foreman-core issue triage?

[Eric D Helms]

Bump - any thoughts here from the -dev community? Simple +1 or -1 or even a
+0 for indifference would be great to just know where folks stand and
whether this would be worth while.

On Thu, Nov 9, 2017 at 8:28 AM, Eric D Helms <ericdhe...@gmail.com> wrote:

> Writing this up inspired me to capture it for the long term [1]. I'd be
> happy to run the first one or two given my experience with it (and assuming
> the timeslot works) just to get into the groove. Note that our process for
> triaging does require some overall Redmine process change with the way we
> uses some of the empty and Recycle Bin releases.
>
>
> [1] https://github.com/theforeman/theforeman.org/pull/970
>
> On Thu, Nov 9, 2017 at 7:54 AM, Greg Sutcliffe <g...@emeraldreverie.org>
> wrote:
>
>> On 08/11/17 16:47, Eric D Helms wrote:
>> [tons of useful stuff]
>>
>> Thanks Eric! I think that format will work for us too, might take a
>> little practice. We'll need volunteers to be the runner, ofc ;)
>>
>> On 09/11/17 07:03, Marek Hulan wrote:
>> > I'd join regularly, after few years for which I receive all
>> > notifications from redmine, I can confirm there are bugs without much
>> > attention.
>> >
>> > If we won't have representatives from all areas, we might need some
>> > tooling to ping people in redmine tickets. Again, after few years, I can
>> > tell that mentioning name in comment does not always work. There used to
>> > be a question plugin which works similarly as needinfo in BZ. Perhaps we
>> > could install it?
>>
>> http://www.redmine.org/projects/redmine/wiki/PluginQuestion is what
>> you're referring to right? Looks nice, I can look into adding it - some
>> Redmine work is definitely on my short-term todo list anyway.
>>
>> > Thanks Greg for bringing this up
>>
>> Still looking for suggested time slots. Perhaps I should create a poll?
>>
>> 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.
>>
>
>
>
> --
> Eric D. Helms
> Red Hat Engineering
>



-- 
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] Building a Rails 5.1 SCL

[Eric D Helms]

Based on the feedback, I have started the repository for this effort [1]
and opened an initial PR [2] that adds tooling and an initial set of
packages in order to ensure that tooling works. My goal is to get the
initial package and tooling reviewed and committed before moving on to
other packages. This should allow developer collaboration creating
packages, and ensure from the start we have everything setup. Thus, I
invite all developers and especially those on the packaging team to review.

My next goal, before that PR is merged, is to add PR testing so that from
the start we have the infrastructure to support changes and new pckages.


Eric

[1] https://github.com/theforeman/tfm-ror51-packaging
[2] https://github.com/theforeman/tfm-ror51-packaging/pull/1

On Tue, Nov 7, 2017 at 12:03 PM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:

> +1 for 2.4. I believe currently it's beta in SCLo but I assume that it'll
> be GA by the time we finish it and the RH-SCL version is already GA.
>
>
> On Tue, Nov 07, 2017 at 11:59:43AM -0500, Eric D Helms wrote:
>
>> One thing I didn't include as part of this discussion was a discussion of
>> the version of Ruby to use. Currently a Ruby 2.4 and Ruby 2.3 SCL exists
>> from the RHSCL team within CentOS. I propose we use Ruby 2.4 given that it
>> is latest and greatest. This is important, since the Rails SCL will have
>> to
>> depend on a Ruby SCL version.
>>
>> Eric
>>
>> On Fri, Nov 3, 2017 at 9:23 AM, Eric D Helms <ericdhe...@gmail.com>
>> wrote:
>>
>>
>>>
>>> On Thu, Nov 2, 2017 at 6:24 AM, Daniel Lobato Garcia <
>>> elobat...@gmail.com>
>>> wrote:
>>>
>>> I agree with all of that, definitely something to do in a different
>>>> repository.
>>>>
>>>> Just one question, my understanding is that you prefer to do this (SCL)
>>>> because we are uncertain of the time/effort required for vendoring the
>>>> gems/npm
>>>> packages. Given that long-term we would have to keep up building SCLs
>>>> (which if I’m not wrong are going to be less used from EL8 onward) and
>>>> maintaining
>>>> packages (which consumes a great deal of our time).
>>>>
>>>>
>>> To be fair, I judged this based on what the community prefers not just my
>>> personal preference per the other thread. I do tend to still think NPM
>>> should be vendorized given how it does not provide runtime dependencies
>>> and
>>> only build time as well as the complex nature of how it handles packages
>>> and dependencies (and sheer scale of packages).
>>>
>>> Eric
>>>
>>>
>>>
>>>> Parallel to this effort, do you think it’s worth moving forward with the
>>>> vendorization of npm so that gems can follow suit?
>>>>
>>>
> --
> 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] Proposal: Move Foreman Jenkins Jobs to foreman-ci repository

[Eric D Helms]

On Thu, Nov 9, 2017 at 9:46 AM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:

> On Thu, Nov 09, 2017 at 02:37:10PM +, Greg Sutcliffe wrote:
>
>> On 09/11/17 14:25, Ewoud Kohl van Wijngaarden wrote:
>>
>>> If a separate repository, would it not be as simple as adding a git
>>>> clone?
>>>>
>>>
>>> Possibly, I don't have that much insight into the entire deployment
>>> flow. Hence my preference of making small changes since our backlog is
>>> big enough already. Of course if you're willing to take it on then be my
>>> guest.
>>>
>>
>> Currently it's a Jenkins Job [1] that notices a change in the upstream
>> repo, and deploys it to the puppetmaster. Should be trivial enough to
>> make the changes you want there - adding a git submodule to the infra
>> repo might "just work", looking at it.
>>
>> [1] http://ci.theforeman.org/job/deploy_puppet/
>>
>
> A git submodule might work - we wouldn't get automatic updates thus
> doubling the work though. If you mean adding a separate repository to the
> config then that could work well.


Another option is we just move this out of puppet all together and a have a
job that runs JJB whenever the repository updates to update the jobs
(job-ception).


>
>
> --
> 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] Proposal: Move Foreman Jenkins Jobs to foreman-ci repository

[Eric D Helms]

On Thu, Nov 9, 2017 at 9:00 AM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:

> On Wed, Nov 08, 2017 at 07:35:04AM -0500, Eric D Helms wrote:
>
>> All,
>>
>> I brought this idea up in a separate thread, but want to formalize it into
>> it's own direct proposal. As of today, the Jenkins Job (JJB)
>> configurations
>> live buried inside the foreman-infra repository. I believe this makes them
>> hard to discover [1] and awkward to work with being inside a puppet
>> module.
>> My proposal is:
>>
>> 1) Create foreman-ci github repository
>> 2) Move everything under [1] to foreman-ci
>> 3) Update the jenkins_job_builder puppet_module to clone this new
>> repository
>>
>> Further, I think this will allow CI focused work to happen and be separate
>> from the maintenance of our community infrastructure.
>>
>
> +1 to making it more visible.
>
> I'm not sure whether a separate repo or a top level directory in
> foreman-infra is best. One benefit of a single repository is that they're
> somewhat tightly linked: the JJB version and the templates we use.
>

I don't know when you say template here. What template?


>
> Would a we be able to move the directory to the top level and have a
> symlink at the puppet module level? If that'd work I'd prefer that as a
> first step since we wouldn't have to modify our current deployment model.


If a separate repository, would it not be as simple as adding a git clone?


>
>
> Eric
>>
>> [1]
>> https://github.com/theforeman/foreman-infra/tree/master/pupp
>> et/modules/jenkins_job_builder/files/theforeman.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.
>



-- 
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] Regular Foreman-core issue triage?

[Eric D Helms]

Writing this up inspired me to capture it for the long term [1]. I'd be
happy to run the first one or two given my experience with it (and assuming
the timeslot works) just to get into the groove. Note that our process for
triaging does require some overall Redmine process change with the way we
uses some of the empty and Recycle Bin releases.


[1] https://github.com/theforeman/theforeman.org/pull/970

On Thu, Nov 9, 2017 at 7:54 AM, Greg Sutcliffe <g...@emeraldreverie.org>
wrote:

> On 08/11/17 16:47, Eric D Helms wrote:
> [tons of useful stuff]
>
> Thanks Eric! I think that format will work for us too, might take a
> little practice. We'll need volunteers to be the runner, ofc ;)
>
> On 09/11/17 07:03, Marek Hulan wrote:
> > I'd join regularly, after few years for which I receive all
> > notifications from redmine, I can confirm there are bugs without much
> > attention.
> >
> > If we won't have representatives from all areas, we might need some
> > tooling to ping people in redmine tickets. Again, after few years, I can
> > tell that mentioning name in comment does not always work. There used to
> > be a question plugin which works similarly as needinfo in BZ. Perhaps we
> > could install it?
>
> http://www.redmine.org/projects/redmine/wiki/PluginQuestion is what
> you're referring to right? Looks nice, I can look into adding it - some
> Redmine work is definitely on my short-term todo list anyway.
>
> > Thanks Greg for bringing this up
>
> Still looking for suggested time slots. Perhaps I should create a poll?
>
> 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.
>



-- 
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] Re: Moving katello-packaging to foreman-packaging

[Eric D Helms]

On Wed, Nov 8, 2017 at 1:55 PM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:

> On Wed, Nov 08, 2017 at 11:49:55AM -0500, Eric D Helms wrote:
>
>> The work for this transition has completed. All packages have been moved
>> at
>> this point, and katello-packaging fully deprecated. The packaging PR
>> testing on foreman-packaging has been updated to account for these new
>> packages as well as the rubygem-katello, katello-installer and
>> hammer_cli_katello nightly RPM builds have been updated for this shift.
>>
>
> I recall we only did nightlies so I assume KATELLO-3.5 from
> katello-packaging is still active. Correct?


Correct. That will be the last release still managed from kpackaging.


>
>
> --
> 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] Re: Moving katello-packaging to foreman-packaging

[Eric D Helms]

The work for this transition has completed. All packages have been moved at
this point, and katello-packaging fully deprecated. The packaging PR
testing on foreman-packaging has been updated to account for these new
packages as well as the rubygem-katello, katello-installer and
hammer_cli_katello nightly RPM builds have been updated for this shift.
Thanks for all the reviews and encouragement.

Per standard policy, I will wait a week and add the individuals nominated
to the packagers group.

Eric

On Tue, Nov 7, 2017 at 3:08 AM, Evgeni Golov <evg...@redhat.com> wrote:

> +1 for Justin, Stephen and John :)
>
> On Tue, Nov 7, 2017 at 8:01 AM, Ondrej Prazak <opra...@redhat.com> wrote:
> > +1 from me
> >
> > On Mon, Nov 6, 2017 at 4:15 PM, Greg Sutcliffe <g...@emeraldreverie.org>
> > wrote:
> >>
> >> On 06/11/17 13:20, Eric D Helms wrote:
> >> > An important part I missed with the migration and initial proposal is
> >> > around maintainers. I am proposing that all katello-packagers be given
> >> > commit access to foreman-packaging as part of this move.
> >>
> >> +1 from me, all good candidates :)
> >>
> >> --
> >> 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.
>
>
>
> --
> Beste Grüße/Kind regards,
>
> Evgeni Golov
> Software Engineer
> 
> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
> Commercial register: Amtsgericht Muenchen, HRB 153243,
> Managing Directors: Charles Cachera, Michael Cunningham, Michael
> O'Neill, Eric Shander
>
> --
> 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.

[foreman-dev] Proposal: Move Foreman Jenkins Jobs to foreman-ci repository

[Eric D Helms]

All,

I brought this idea up in a separate thread, but want to formalize it into
it's own direct proposal. As of today, the Jenkins Job (JJB) configurations
live buried inside the foreman-infra repository. I believe this makes them
hard to discover [1] and awkward to work with being inside a puppet module.
My proposal is:

 1) Create foreman-ci github repository
 2) Move everything under [1] to foreman-ci
 3) Update the jenkins_job_builder puppet_module to clone this new
repository

Further, I think this will allow CI focused work to happen and be separate
from the maintenance of our community infrastructure.


Eric

[1]
https://github.com/theforeman/foreman-infra/tree/master/puppet/modules/jenkins_job_builder/files/theforeman.org

-- 
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] Building a Rails 5.1 SCL

[Eric D Helms]

One thing I didn't include as part of this discussion was a discussion of
the version of Ruby to use. Currently a Ruby 2.4 and Ruby 2.3 SCL exists
from the RHSCL team within CentOS. I propose we use Ruby 2.4 given that it
is latest and greatest. This is important, since the Rails SCL will have to
depend on a Ruby SCL version.

Eric

On Fri, Nov 3, 2017 at 9:23 AM, Eric D Helms <ericdhe...@gmail.com> wrote:

>
>
> On Thu, Nov 2, 2017 at 6:24 AM, Daniel Lobato Garcia <elobat...@gmail.com>
> wrote:
>
>> I agree with all of that, definitely something to do in a different
>> repository.
>>
>> Just one question, my understanding is that you prefer to do this (SCL)
>> because we are uncertain of the time/effort required for vendoring the
>> gems/npm
>> packages. Given that long-term we would have to keep up building SCLs
>> (which if I’m not wrong are going to be less used from EL8 onward) and
>> maintaining
>> packages (which consumes a great deal of our time).
>>
>
> To be fair, I judged this based on what the community prefers not just my
> personal preference per the other thread. I do tend to still think NPM
> should be vendorized given how it does not provide runtime dependencies and
> only build time as well as the complex nature of how it handles packages
> and dependencies (and sheer scale of packages).
>
> Eric
>
>
>>
>> Parallel to this effort, do you think it’s worth moving forward with the
>> vendorization of npm so that gems can follow suit?
>>
>> --
>> 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
>



-- 
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] Foreman instrumenting analysis

[Eric D Helms]

Honestly, pull approach via simple HTTP REST API seems cleaner but it
> > is just not good fit and also it creates other unnecessary
> > responsibility on the app itself. You are working on containerizing
> > Foreman, so it is also actually against this effort.
> >
> > Anyway, let me throw another integration. Collectd has an agent (or
> > plugin) that opens a local socket which can be used to receive data
> > from other applications. I wrote Ruby client library the other day
> > (https://github.com/lzap/collectd-uxsock) but I believe this make no
> > difference than statsd - you still need a local process to gather the
> > data.
> >
> > --
> > 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.
>
> --
> 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] speeding up tests

[Eric D Helms]

things we can
change. For example, finding and suggesting tests to remove that provide no
value, looking for less resource intensive ways to do some tests, or find
flaws in how tests were crafted to begin with. An example of that last one
is a test might be seeding the database with a lot of extraneous data that
causes it to run slow due to database operations.

6) Reduce Support Matrix

Granted, in general, if there is not significant load on Jenkins, all of
our testing runs in parallel across Jenkins executors. However, this is
generally not true for our infrastructure. Further, developers have
expressed a desire to increase the amount of testing we do by adding
plugins into the matrix.

That being said, today we support 3 databases and 3 versions of Ruby. We
attempt to give users choice in production between postgres and mysql, and
provide developers the use of a lightweight database in sqlite. Further, we
support a single RPM based production setup and multiple Debian giving us a
range of Rubies. This is compounded by wanting to test against potential
upgrades in our Rails and Ruby stack.

With choice comes burden on infrastructure and testing. I'd ask that we
consider being more opinionated and reducing this matrix. For example, if
we centralize on Forklift based development environments we could drop
sqlite. I will say up front I am less knowledgeable about Debian, but the
packaging repository makes it appear we support 4 different versions.
Perhaps we consider, if such a thing exists, locking in on LTS type
versions or dropping support sooner to focus on a few hardened environments.


Eric

[1] https://www.youtube.com/watch?v=URSWYvyc42M
[2] http://blog.cleancoder.com/uncle-bob/2017/05/05/TestDefinitions.html
[3]
http://ci.theforeman.org/job/test_develop_pr_core/14972/database=postgresql,ruby=2.3,slave=fast/testReport/(root)/

On Tue, Nov 7, 2017 at 5:35 AM, Lukas Zapletal <l...@redhat.com> wrote:

> > We can define these tests as a seperate set that gets only a weekly run,
> > but deletion is IMHO the completetly wrong way.
>
> https://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf
>
> A cleanup *is* reasonable, not completely wrong way. I bet that week
> after we move this into 2nd tier it starts breaking and nobody will
> care, because code would had been merged already. That's the point
> here.
>
> > I think both are needed. Integration tests are much slower than unit
> > tests, in general.
>
> And by the way our unit tests are not fast, really. They are slow as
> hell, mainly because most of them are not really unit tests. I am
> speaking to you, model tests. Let me give you an example:
>
> test/models/architecture_test.rb
>
> Not a unit test, not an integration test, not a system test, haven't
> failed for a very long time, useless if we have the most important
> stuff covered in an integration or system test, which we do.
>
> --
>   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.
>



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

[foreman-dev] Infra/Deployment/Platform Roadmap Update

[Eric D Helms]

i-server service deployment


   - Migration off of Openshift V2
  - Updates
 - None
  - Notes


   - Redmine -- moved to stand alone server and off of Openshift entirely


   - prprocessor -- still running on Openshift V2


   - etherpad -- moved from katello to foreman openshift v2 instance


-- 
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] PrPRocessor not working correctly

[Eric D Helms]

I think I might be seeing some git push operations not kicking of PR
testing.

On Mon, Nov 6, 2017 at 9:39 AM, Greg Sutcliffe <g...@emeraldreverie.org>
wrote:

> Hi all,
>
> PrProcessor appears to have some issues - at the moment it's not
> applying labels correctly etc. See [1] for an example, labels applied
> manually, no mention of commit message, etc.
>
> Eric has made some changes which we think will help, but if you see
> other weirdness, please report it here so we can collate a list of
> things to watch / investigate.
>
> Greg
>
> [1] https://github.com/theforeman/foreman/pull/4980
>
> --
> 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.

[foreman-dev] Re: Moving katello-packaging to foreman-packaging

[Eric D Helms]

An important part I missed with the migration and initial proposal is
around maintainers. I am proposing that all katello-packagers be given
commit access to foreman-packaging as part of this move. All developers in
this group have shown to be solid participants in packaging, the ability to
build and maintain packages and understand the process. Those devs are:

 * Evgeni
 * Justin
 * Stephen
 * John

On Sat, Nov 4, 2017 at 12:28 PM, Eric D Helms <ericdhe...@gmail.com> wrote:

> I should also note, any currently open PRs against katello-packaging will
> have to be re-opened against foreman-packaging. I will ping each PR
> individually and eventually close each if there is no action taken.
>
>
> Eric
>
> On Sat, Nov 4, 2017 at 12:27 PM, Eric D Helms <ericdhe...@gmail.com>
> wrote:
>
>> Per the previous plan proposal, for which no objections were raised, I
>> have started this migration process. There are a number of grouped PRs open
>> to foreman-packaging [1] to move the various packages into a `katello/`
>> sub-directory for now. There is a large PR open to katello-packaging to
>> inevitably remove and deprecate the repository (except for Katello 3.5 and
>> below) [2].
>>
>>
>> [1] https://github.com/theforeman/foreman-packaging/pulls
>> [2] https://github.com/Katello/katello-packaging/pull/575
>>
>> --
>> Eric D. Helms
>> Red Hat Engineering
>>
>
>
>
> --
> Eric D. Helms
> Red Hat Engineering
>



-- 
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] Propsing a move from Google Groups to Discourse

[Eric D Helms]

I think about this in two ways:

 1) Who are our lists for?
 2) How can we provide the most value through our lists to the audience?

Often I find digging up old threads to reference to users more painful than
it should be. Often, I am curious about popular or trending threads and
cannot find this information easily. This latter point I think can be
important for users and developers if there is a hot button breakage or
workflow topic being discussed. Often, when I want to answer a user, I find
the interface of email lists to be limited when it comes to including
screenshots, or writing code blocks. Further, I find asking users for
information to help with debugging difficult because they have limited
options for attachments or screenshots for inclusion. Often I find writing
structured emails for things like proposals or recaps difficult. 75% of the
time I am going to prefer email given it is what I am used to and my
primary interface for everything else. But 25%, I want something more.

If Discourse can help solve these problems, and make the users of the lists
experiences better when interacting amongst themselves as well as
developers then a big ole +1 from me. Mailing lists are great, times
change, users change, requirements change.

Mailing lists are for communication, and whatever increases communication
the most I am all for.

Eric

On Fri, Nov 3, 2017 at 2:29 PM, Lukas Zapletal <l...@redhat.com> wrote:

> Greg, I absolutely understand the motivation, every two years amount
> of programmers doubles. That is a crazy amount of newcomers. But these
> new people are not idiots and some technical level is required even
> for soft roles in our community. And we can make lists approachable
> very much like forums.
>
> Do not put me into position of blind and angry dev who can't accept
> something different or new. I understand all contexts and I say
> Discourse is an overkill that will bother me and possibly others. God
> I wish Google Groups are gone, but not for this.
>
> > * do nothing
>
> Honestly, yeah.
>
> > * switch mailing list for minimal improvement
>
> s/minimal/reasonable/
>
> > * switch to a forum, big upheaval but potential big payoff
>
> Sure, because there are no downsides.
>
> It's not about a list standard e-mail headers. The forum has different
> workflow and features and there will be new features as well while
> mailing list will stay the same. This will screw my inbox. This will
> but a wall between e-mail users and web forum users. This is what's
> this all about. And I think we don't need to go that direction.
>
> LZ
>
> On Fri, Nov 3, 2017 at 6:45 PM, Greg Sutcliffe <g...@emeraldreverie.org>
> wrote:
> > One more thought occurred to me while I was out on the nursery pickup,
> so I'll drop here before I bow out for the weekend.
> >
> > Lukas, I think part of our disagreement is our different goals. As I
> highlighted in the last mail, users behave differently to devs. These days
> I consider myself more user than dev (when did I last contribute code), so
> I have a different world view.
> >
> > You want to protect a tried and trusted workflow, likely used by many
> here - that's fine. My job is to promote and develop the user community, so
> I see room for improvement.
> >
> > Here's the catch though... Our future devs, as a community, *come from*
> the user community. If we don't focus there, then we risk stagnating the
> dev community too.
> >
> > I won't deny this change is a larger net benefit for the user group. The
> case for the dev community is harder to argue. But there *is* benefit, and
> compared to running a list (for dev) and a forum (for users) I think the
> better argument is to use a forum for both.
> >
> > I don't expect to convince everyone, so this is going to come down to a
> group decision - but not for a while yet. We need to do more tests.
> >
> > Have a great weekend all,
> > Greg
> > --
> > Sent from my Android device with K-9 Mail. Please excuse my brevity.
> >
> > --
> > 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.
>
>
>
> --
> 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.
>



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

[foreman-dev] Re: Moving katello-packaging to foreman-packaging

[Eric D Helms]

I should also note, any currently open PRs against katello-packaging will
have to be re-opened against foreman-packaging. I will ping each PR
individually and eventually close each if there is no action taken.


Eric

On Sat, Nov 4, 2017 at 12:27 PM, Eric D Helms <ericdhe...@gmail.com> wrote:

> Per the previous plan proposal, for which no objections were raised, I
> have started this migration process. There are a number of grouped PRs open
> to foreman-packaging [1] to move the various packages into a `katello/`
> sub-directory for now. There is a large PR open to katello-packaging to
> inevitably remove and deprecate the repository (except for Katello 3.5 and
> below) [2].
>
>
> [1] https://github.com/theforeman/foreman-packaging/pulls
> [2] https://github.com/Katello/katello-packaging/pull/575
>
> --
> Eric D. Helms
> Red Hat Engineering
>



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

[foreman-dev] Moving katello-packaging to foreman-packaging

[Eric D Helms]

Per the previous plan proposal, for which no objections were raised, I have
started this migration process. There are a number of grouped PRs open to
foreman-packaging [1] to move the various packages into a `katello/`
sub-directory for now. There is a large PR open to katello-packaging to
inevitably remove and deprecate the repository (except for Katello 3.5 and
below) [2].


[1] https://github.com/theforeman/foreman-packaging/pulls
[2] https://github.com/Katello/katello-packaging/pull/575

-- 
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] Moving katello puppet modules to the foreman github namespace

[Eric D Helms]

All repositories have been transfered to theforeman Github organization. A
new team has been created named 'Katello Installer' that contains all
puppet modules and users from the same team in the Katello github
organization.

On Fri, Nov 3, 2017 at 9:50 AM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:

> On Fri, Nov 03, 2017 at 09:28:18AM -0400, Eric D Helms wrote:
>
>> On Fri, Nov 3, 2017 at 9:03 AM, Ewoud Kohl van Wijngaarden <
>> ew...@kohlvanwijngaarden.nl> wrote:
>>
>> Not sure if I understand what you mean. Are you saying to create a katello
>>> installer team in theforeman org to match it with the katello org one?
>>> That
>>> was similar to what I was thinking. It's the easiest in the short term
>>> and
>>> we can easily iterate from there.
>>>
>>
>>
>> Yes, thanks for clarifying. Essentially, just port the existing team over
>> and we can then go from there towards future integrations between
>> repositories and teams. All the modulesync PRs are merged. I'll create the
>> team and then transfer each module if you are ready?
>>
>
> I'm ready.
>
>
> On Thu, Nov 02, 2017 at 01:42:31PM -0400, Eric D Helms wrote:
>>>
>>> I am ready to move them when you give the green light.
>>>>
>>>> My inclination for permissions and team setup would be to maintain all
>>>> individual maintership on the modules to date. Further, to take the
>>>> katello
>>>> installer team and add them to a similar installer team on theforeman
>>>> organization.
>>>>
>>>> On Thu, Nov 2, 2017 at 12:38 PM, Ewoud Kohl van Wijngaarden <
>>>> ew...@kohlvanwijngaarden.nl> wrote:
>>>>
>>>> Hello all,
>>>>
>>>>>
>>>>> Previously this has been discussed in various threads but now we're
>>>>> ready
>>>>> to make it a reality. All modules should be ready to use a single
>>>>> modulesync repository and a pull request has been opened.
>>>>> https://github.com/theforeman/foreman-installer-modulesync/pull/78
>>>>> lists all tasks that need to be completed.
>>>>>
>>>>> Some important things to note:
>>>>>
>>>>> * We invite users to submit redmine issues to the foreman installer
>>>>> project. Previously we only pointed them to Redmine without specific
>>>>> directions.
>>>>> * We will continue to publish modules on the puppet forge under the
>>>>> katello user. Moving modules there requires a bit more effort for
>>>>> little
>>>>> benefit.
>>>>> * This does (not yet) include merging the installers. For now
>>>>> foreman-installer won't ship the katello modules.
>>>>>
>>>>>
>>>> --
>>> 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.
>>
>
> --
> 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] Building a Rails 5.1 SCL

[Eric D Helms]

On Thu, Nov 2, 2017 at 6:24 AM, Daniel Lobato Garcia <elobat...@gmail.com>
wrote:

> I agree with all of that, definitely something to do in a different
> repository.
>
> Just one question, my understanding is that you prefer to do this (SCL)
> because we are uncertain of the time/effort required for vendoring the
> gems/npm
> packages. Given that long-term we would have to keep up building SCLs
> (which if I’m not wrong are going to be less used from EL8 onward) and
> maintaining
> packages (which consumes a great deal of our time).
>

To be fair, I judged this based on what the community prefers not just my
personal preference per the other thread. I do tend to still think NPM
should be vendorized given how it does not provide runtime dependencies and
only build time as well as the complex nature of how it handles packages
and dependencies (and sheer scale of packages).

Eric


>
> Parallel to this effort, do you think it’s worth moving forward with the
> vendorization of npm so that gems can follow suit?
>
> --
> 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] Building a Rails 5.1 SCL

[Eric D Helms]

On Thu, Nov 2, 2017 at 8:02 AM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:

> On Wed, Nov 01, 2017 at 02:00:29PM -0400, Eric D Helms wrote:
>
>> In a previous thread [1], we discussed building an SCL vs. vendorizing
>> gems
>> and the general consensus was to build an SCL. This thread is to outline a
>> starting plan for how to build and maintain a Rails 5.1 SCL. I invite and
>> appreciate comments towards this design.
>>
>> I'll begin by laying out some overall goals for the effort, a general
>> proposal of information and finally a breakdown of the why for each of the
>> proposal items to better explain my thinking.
>>
>>
>> Goals
>>
>> * Stand alone Rails 5.1 SCL and repository
>> * Owned and maintained by the Foreman community
>> * Easy to update and maintain
>> * Strive for automation and package tooling to reduce maintenance cost
>>
>>
>> Proposal
>>
>> Build location: Copr
>> SCL Name: tfm-ror51
>> Git repository: theforeman/tfm-ror51-packaging
>> Hosted: yum.theforeman.org/rails/tfm-ror51
>> RPM Signing: signed by unique Foreman owned GPG key
>> Tooling Repo: create package tooling repository separate from
>> tfm-ror51-packaging repo
>> Tooling Technology: Ansible
>>
>>
>> Breakdown
>>
>> Build Location
>>
>> There has been discussion around moving our RPM builds to Copr and off of
>> Koji. This will require shifting our configuration and setup, testing and
>> working out kinks in Copr workflow. Building this Rails SCL provides us an
>> opportunity to use Copr from the start, get familiar with it and workout
>> tooling to interact with and manage a repository there. Therefore, I am
>> proposing to start with Copr from the get go and avoid Koji.
>>
>
> +1
>
> SCL Name
>>
>> Given the Foreman community will own the SCL, and our SCL namespace is
>> 'tfm' I am suggesting we follow convention by naming it tfm-ror51.
>> Previous
>> Rails SCLs, were named similarly: rh-ror41, rh-ror42, sclo-ror42.
>>
>
> +1 though we could look at creating a CentOS SIG to do it under the sclo
> flag. IMHO this can be parallel to the development or even after the fact.
>
> Git Repository
>>
>> I am proposing we don't put this into foreman-packaging given the
>> lifecycle
>> of the SCL will not follow that of Foreman. Further, with the goal to
>> create a stand-alone Rails SCL repository this should have its own
>> lifecycle.
>>
>
> +1
>
> Hosted
>>
>> We could point at the direct Copr repository, and reduce our bandwidth.
>> However, since we own this Rails SCL I believe we should host it as such
>> officially. Further, this would allow us to do some pre-flight testing by
>> building a repository in Copr, running a test of either the SCL itself
>> and/or Foreman against the SCL updates before promoting.
>>
>
> +1
>
> This would be similar to how we now have koji: as a staging ground, we
> test against this and promote if it's stable with the added benefit that
> it's easier to consume.
>
> RPM Signing
>>
>> I am recommending here that we sign the SCL RPMs with a new GPG key
>> generated just for signing the SCL packages.
>>
>
> COPR signs repos by default with its own GPG key. Do you want a separate
> GPG key when we host it on yum.theforeman.org?
>
> Tooling
>>
>> With an eye towards foreman-packaging changes, I am proposing we create a
>> separate git repository for all package tooling. The goal here would to
>> build out new tooling to allow easier maintenance of the packaging and
>> repository.  This will allow the tooling to evolve independently of either
>> packaging repository.  Further, when applying this tooling to
>> foreman-packaging later, the tooling would not have to be duplicated
>> across
>> branches.
>>
>
> +1
>
> Tooling Technology
>>
>> I am proposing a centralization on Ansible as the tooling technology for a
>> number of reasons. First, I feel that it has a low barrier to entry while
>> providing a mix of high and low level interfaces. Secondly, Ansible allows
>> orchestrating and building out more complex and directed tasks. Third, a
>> team of us has some built out Ansible tooling that has been working well
>> for us in another area that would be easy to port for packaging
>> management.
>> I personally think bash is complex to understand for complex actions and
>> is
>> too simple for building up a set of cohesive tooling.
>>
>
> For me this

Re: [foreman-dev] Moving katello puppet modules to the foreman github namespace

[Eric D Helms]

I am ready to move them when you give the green light.

My inclination for permissions and team setup would be to maintain all
individual maintership on the modules to date. Further, to take the katello
installer team and add them to a similar installer team on theforeman
organization.

On Thu, Nov 2, 2017 at 12:38 PM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:

> Hello all,
>
> Previously this has been discussed in various threads but now we're ready
> to make it a reality. All modules should be ready to use a single
> modulesync repository and a pull request has been opened.
> https://github.com/theforeman/foreman-installer-modulesync/pull/78
> lists all tasks that need to be completed.
>
> Some important things to note:
>
> * We invite users to submit redmine issues to the foreman installer
> project. Previously we only pointed them to Redmine without specific
> directions.
> * We will continue to publish modules on the puppet forge under the
> katello user. Moving modules there requires a bit more effort for  little
> benefit.
> * This does (not yet) include merging the installers. For now
> foreman-installer won't ship the katello modules.
>
> --
> 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] Propsing a move from Google Groups to Discourse

[Eric D Helms]

I skimmed the site over, played with configuration, clicked and tried to
play with various part of it. There are parts I'll have to get used to, and
there are parts I wish were done slightly different but overall I like the
advanced power behind it.

Thinking a loud, it seems like this might allow us to more easily expanded
topic areas in the future? For example, if we wanted to have infrastructure
focused/tagged emails, or plugins specific, or design discussions that are
marked as such?

On Wed, Nov 1, 2017 at 3:28 PM, Greg Sutcliffe <g...@emeraldreverie.org>
wrote:

> The site will be made public if/when we go live with it. I assume Google
> will index it then, I don't think it does any robots.txt stuff - certainly
> I'm using google to look up configuration questions on meta.discourse.org
> :)
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
> --
> 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] Merge permission for theforemen/foreman-ansible-modules

[Eric D Helms]

+1 from me as well (I'll aim to add you in the requisite 5 more days
depending on the further outcome)

On Wed, Nov 1, 2017 at 3:24 PM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:

> +1 while I haven't looked at his ansible work that closely I have seen
> that he's already behaving like an excellent maintainer: good reviews,
> active and generally a good and friendly person to have around.
>
> On Mon, Oct 30, 2017 at 11:46:34AM -0400, Andrew Kofink wrote:
>
>> +1 from me! We have benefited greatly from Matthias' contributions in
>> foreman-ansible-modules. If you'd like to see some of his work, here are
>> his merged PRs
>> <https://github.com/search?utf8=%E2%9C%93=author%3Amdellwe
>> g+repo%3Atheforeman%2Fforeman-ansible-modules+is%3Amerged=Issues>,
>> and here are all the PRs he has helped to review
>> <https://github.com/search?utf8=%E2%9C%93=commenter%3Amdel
>> lweg+-author%3Aakofink+repo%3Atheforeman%2Fforeman-ansible
>> -modules+is%3Amerged=>
>> .
>>
>> On Mon, Oct 30, 2017 at 11:34 AM, Matthias Dellweg <dell...@atix.de>
>> wrote:
>>
>> Hello,
>>> i was just encouraged, to ask for merge/push permission in
>>> theforeman/foreman-ansible-modules.
>>> I have contributed to this repository almost since the beginning (yes,
>>> it's a very young one),
>>> and did a hand full of reviews that lead to constructive discussions. The
>>> collaboration with
>>> Andrew, Eric and Evgeni have always been very fruitful from my
>>> perspective.
>>> For co-inventing the DRY glue layer 'cement' (with fobheb), github
>>> classifies me as the top
>>> garbage collector with by far the most removed lines.
>>>
>>> I ask you kindly to vote, whether i shall be entrusted with the power of
>>> the merge.
>>> Thanks for considering,
>>>   Matthias
>>>
>>
> --
> 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.

[foreman-dev] Building a Rails 5.1 SCL

[Eric D Helms]

In a previous thread [1], we discussed building an SCL vs. vendorizing gems
and the general consensus was to build an SCL. This thread is to outline a
starting plan for how to build and maintain a Rails 5.1 SCL. I invite and
appreciate comments towards this design.

I'll begin by laying out some overall goals for the effort, a general
proposal of information and finally a breakdown of the why for each of the
proposal items to better explain my thinking.


Goals

 * Stand alone Rails 5.1 SCL and repository
 * Owned and maintained by the Foreman community
 * Easy to update and maintain
 * Strive for automation and package tooling to reduce maintenance cost


Proposal

Build location: Copr
SCL Name: tfm-ror51
Git repository: theforeman/tfm-ror51-packaging
Hosted: yum.theforeman.org/rails/tfm-ror51
RPM Signing: signed by unique Foreman owned GPG key
Tooling Repo: create package tooling repository separate from
tfm-ror51-packaging repo
Tooling Technology: Ansible


Breakdown

Build Location

There has been discussion around moving our RPM builds to Copr and off of
Koji. This will require shifting our configuration and setup, testing and
working out kinks in Copr workflow. Building this Rails SCL provides us an
opportunity to use Copr from the start, get familiar with it and workout
tooling to interact with and manage a repository there. Therefore, I am
proposing to start with Copr from the get go and avoid Koji.

SCL Name

Given the Foreman community will own the SCL, and our SCL namespace is
'tfm' I am suggesting we follow convention by naming it tfm-ror51. Previous
Rails SCLs, were named similarly: rh-ror41, rh-ror42, sclo-ror42.

Git Repository

I am proposing we don't put this into foreman-packaging given the lifecycle
of the SCL will not follow that of Foreman. Further, with the goal to
create a stand-alone Rails SCL repository this should have its own
lifecycle.

Hosted

We could point at the direct Copr repository, and reduce our bandwidth.
However, since we own this Rails SCL I believe we should host it as such
officially. Further, this would allow us to do some pre-flight testing by
building a repository in Copr, running a test of either the SCL itself
and/or Foreman against the SCL updates before promoting.

RPM Signing

I am recommending here that we sign the SCL RPMs with a new GPG key
generated just for signing the SCL packages.

Tooling

With an eye towards foreman-packaging changes, I am proposing we create a
separate git repository for all package tooling. The goal here would to
build out new tooling to allow easier maintenance of the packaging and
repository.  This will allow the tooling to evolve independently of either
packaging repository.  Further, when applying this tooling to
foreman-packaging later, the tooling would not have to be duplicated across
branches.

Tooling Technology

I am proposing a centralization on Ansible as the tooling technology for a
number of reasons. First, I feel that it has a low barrier to entry while
providing a mix of high and low level interfaces. Secondly, Ansible allows
orchestrating and building out more complex and directed tasks. Third, a
team of us has some built out Ansible tooling that has been working well
for us in another area that would be easy to port for packaging management.
I personally think bash is complex to understand for complex actions and is
too simple for building up a set of cohesive tooling.

-- 
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] Foreman instrumenting analysis

[Eric D Helms]

On Wed, Nov 1, 2017 at 3:51 AM, Lukas Zapletal <l...@redhat.com> wrote:

> Statsd can be configured for remote transport, meaning that the
> collecting agent (or aggregating process if you like) can run on
> remote server (or container). It is recommended to run it either on
> localhost or at least LAN, it is not a good idea to route the UDP
> packets through complex environments tho as they can get lost. Also
> creating a SPOF is not a good idea, but I've seen articles or comments
> about having one central statsd collector for all hosts. Those people
> had usually questions around scaleability because single point of
> entry was getting overloaded.
>
> There are some WIP patches for Prometheus as well giving a possibility
> to have single HTTP REST endpoint for all subprocesses of a Rails app
> server, but if you take a look into this (links are in my original
> email) these are pretty hacky. One is creating a local shared memory
> block for communication, the other is doing the same via serialized db
> file. This is doing dozens of system calls per single measurement,
> compared to just one or two for UDP datagram this is way too much
> IMHO.
>

Does Prometheus only not work in a multi-process Rails web server? Does it
work for a single process multi-threaded web server? This is an interesting
roadblock given you'd expect this to affect lots of webserver across
multiple languages out there.


>
> The question tho is if there is another protocol I am not aware of.
> There are actually two which I both tested to be honest:
>
> 1) PCP trace API - http://pcp.io/man/man3/pmdatrace.3.html
>
> PCP is a monitoring collecting daemon which is in most Linux distros
> (and in RHEL as well) and it has a very simple API which uses TCP
> connection for communication with trace agent (called PMDA trace). I
> wrote a Ruby wrapper around this simple API
> (https://github.com/lzap/ruby-pcptrace) and I have a working
> prototype. Disadvantage is that in PCP world this API is seen as
> legacy, might get removed in the future. Also aggregation is only done
> for transaction type observation.
>
> 1) PCP MMV API - http://pcp.io/books/PCP_PG/html/id5213288nat.html
>
> Another agent which uses memory mapped files for ultra-fast
> communication. This is the fastest possible application
> instrumentation I've seen, but it is a little bit of an overkill
> primarily targeted to HPC environment. Also no aggregation is done and
> there is no Ruby bindings at all. In both cases, a PCP daemon needs to
> be running.
>
> One question tho - isn't standard practice to have one container per
> pod that will serve as monitoring endpoint? I am no expert with
> Kubernetes, but I believe that's exactly what this technology is built
> for - you can specify services and their dependency on each other. The
> price we need to pay (an extra service) is balanced with better
> reliability - I can imagine when Rails/Passenger stops responding you
> won't be able to reach the monitoring endpoint as well thus we'd need
> to maintain a separate web stack for that.
>

Yes, standard practice is to think about one container per pod (in a
Kubernetes environment). However, there are patterns for things like log
aggregation and monitoring such as doing a sidecar container that ensures
co-location. The part I don't entirely get with sidecars is if I scale the
pod to say 5, I get 5 web applications and 5 monitoring containers and that
seems odd. Which I why I think the tendency is towards models where your
single process/application is the end point for your metrics to be scrapped
by an outside agent or services.

I agree you want the collector to be separate, but if your web application
is down what value would a monitoring endpoint being alive provide? The
application would be down, thus no metrics to serve up. The other exporters
such as the one exporting metrics about the underlying system would be
responsible for giving system metrics. In the Kube world, this is handled
by readiness and liveness probes for Kubenernetes to re-spin the container
if it stops responding.


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



-- 
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] Merge Permissions for Katello/katello

[Eric D Helms]

+1

On Oct 31, 2017 10:17 AM, "Walden Raines"  wrote:

> +1, figured you already had merge permissions.
>
> On Tue, Oct 31, 2017 at 8:16 AM, Brad Buckingham 
> wrote:
>
>> +1 to providing Andrew with merge permissions!!
>>
>> On Fri, Oct 27, 2017 at 10:25 AM, Andrew Kofink 
>> wrote:
>>
>>> Hello,
>>>
>>> I'm not sure why I waited so long to ask, but in light of other
>>> requests, I submit my own. Here are my merged PRs
>>> ,
>>> and here are other PRs I've helped review
>>> .
>>> Do you consent to giving me the mighty power of the Green Button?
>>>
>>> Andrew
>>>
>>> --
>>> Andrew Kofink
>>> akof...@redhat.com
>>> IRC: akofink
>>> Software Engineer
>>> Red Hat Satellite
>>>
>>> --
>>> 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.
>

-- 
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 permissions for Katello/katello

[Eric D Helms]

+1

On Oct 31, 2017 9:10 AM, "Andrew Kofink"  wrote:

> +1
>
> On Tue, Oct 31, 2017 at 8:17 AM, Brad Buckingham 
> wrote:
>
>> +1 from me as well!
>>
>> On Fri, Oct 27, 2017 at 9:19 AM, John Mitsch  wrote:
>>
>>> +1 from me!
>>>
>>> John Mitsch
>>> Red Hat Engineering
>>> (860)-967-7285 <(860)%20967-7285>
>>> irc: jomitsch
>>>
>>> On Thu, Oct 26, 2017 at 4:00 PM, Jonathon Turel 
>>> wrote:
>>>
 Hey folks,

 The time has come (through some helpful suggestions) that I should make
 my request to have $subject bestowed upon me. If you'd like to see some of
 my contributions to Katello here are my merged PRs
 
 and PRs I've otherwise participated in
 .
 Looking forward to contributing more as I continue to come up to speed.
 What do you all think?

 Thanks!

 Jonathon

 --
 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.
>>
>
>
>
> --
> Andrew Kofink
> akof...@redhat.com
> IRC: akofink
> Software Engineer
> Red Hat Satellite
>
> --
> 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 instrumenting analysis

[Eric D Helms]

 takes all aggregation and storing
> temporary data out of Ruby application. It also brings chances of
> regressions in our codebase to bare minimum - in the worst case the
> aggregating agent can fail but UDP packets will simply get lost
> without interrupting the application. The best Ruby client library
> seems to be statsd-instrument actively maintained by Shopify, it is
> very small without any runtime dependency.
>
>
> https://github.com/etsy/statsd/blob/master/docs/metric_types.md
> https://github.com/Shopify/statsd-instrument
> https://github.com/prometheus/statsd_exporter
> https://github.com/statsite/statsite
> https://codeascraft.com/2011/02/15/measure-anything-measure-everything/
>
>
> New Relic, Instrumental, DataDog, Rollbar
>
>
> All are paid services, some clients are open-source (Instrumental is
> MIT licenced) but usually with not well documented protocol and worse
> integration to different monitoring solutions. There are plenty of
> similar offerings, I might have missed some here.
>
>
> https://newrelic.com
> https://instrumentalapp.com
> https://instrumentalapp.com/docs/tcp-collector
>
>
> Zabbix, Nagios, Icinga
>
>
> These are more of "alerting" systems (system or service is down) and
> they all support application instrumentation to some degree, but it is
> not the core of what they do. I have seen them referred as "legacy
> monitoring systems", but I think they are still very relevant. They
> are not good fit for my use case tho at all.
>
>
> Conclusion
>
>
> To me it looks like the most open and flexible protocol seems to be
> statsd. This will give our users the largest flexibility for further
> integration - there are plenty of generic agents which can relay data
> to backend systems.
>
>
> Comments?
>
> --
> 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.
>



-- 
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] Vendorizing or Building RPMs

[Eric D Helms]

The conversation has been open for 2 weeks now, and I appreciate all of the
feedback and conversation. I am going to summarize the conversations as
they stand and outline what I believe next steps are based on the feedback.

RPMs

I performed a quick tally of those that responded and essentially got the
following counts on SCL vs. vendor.

  SCL: 4
  Vendorizing: 2

Further, there appeared to be a lot of unanswered technical questions
around how we maintain a vendorized stack with plugins that need to add
dependencies. Based on this feedback,  I believe the goal should be to
create a new Rails SCL that we own and maintain. As for the plan, the how,
of creating and maintaining this new SCL, I will start a new thread to
discuss the plan and improvements we can make along the way.


NPM

Across the board, everyone appeared to be in favor of vendorizing our NPM
modules to reduce the frequency of breakages and to allow the UI work that
is on going across Foreman and plugins to continue at a rapid pace. I'll
start a similar thread to outline and discuss the changes for this.


Eric

On Sun, Oct 29, 2017 at 5:43 PM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:

> On Mon, Oct 23, 2017 at 09:52:39AM +0100, Greg Sutcliffe wrote:
>
>> On Mon, 2017-10-16 at 14:36 +0100, Greg Sutcliffe wrote:
>>
>>>
>>> That said, I've not really been involved with the RPMs, so I'm unsure
>>> if this causes a bigger headache for Yum users than Apt users. I'm
>>> also unsure of the work required to create an SCL, but if it's non-
>>> trivial then I'd be looking to CentOS to collaborate on a Rails SCL
>>> for everyone to use - for just ourselves, then vendoring seems
>>> easier.
>>>
>>
>> I spoke to a few people I know about this, and it seems there's not
>> much appetite for making new SCLs. We might be able to attract
>> contributors once it's created, but I think we should assume the effort
>> for creating/maintaining SCLs will fall on us initially.
>>
>> Do we have any conclusions on this thread? It's going to matter for
>> 1.17 which is getting closer by the day.
>>
>
> Personally I feel an updated RoR SCL is the way to go for 1.17 and to
> prove that I'm willing to invest the time to make it a reality. After 1.16
> RC2 is out I'm going to spend time on it.
>
>
> --
> 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] Centralizing tool_belt in theforeman Github

[Eric D Helms]

The work to transfer tool_belt officially to theforeman for use is now
complete. The foreman configs have been moved into the repository, the old
repository deleted and the original transferred. I have created a team to
manage the repository based on the top code committers to date. If you'd
like to be a part of the team and contribute please reach out.

If anyone would like more information around what it can or how it can help
with your own release please let us know and I'd be happy to write
something up or do a small deep dive.


Eric

On Thu, Oct 26, 2017 at 10:37 AM, Eric D Helms <ericdhe...@gmail.com> wrote:

> I've began this process by capturing what I believe is everything from [1]
> as an PR to the mainline tool_belt repository:
>
> https://github.com/ehelms/tool_belt/pull/58
>
> Once this is approved, I will do the delete and transfer dance.
>
>
> [1] https://github.com/theforeman/tool_belt
>
> On Mon, Oct 23, 2017 at 9:08 AM, Andrew Kofink <akof...@redhat.com> wrote:
>
>> +1 I guess the foreman and katello config files will still live
>> separately (i.e. katello_35.yaml and foreman_16.yaml) but in the same repo.
>>
>> On Mon, Oct 23, 2017 at 5:59 AM, Daniel Lobato Garcia <
>> elobat...@gmail.com> wrote:
>>
>>> On 10/20, Eric D Helms wrote:
>>> > For quite a few releases now, we've been using a little tool named
>>> > tool_belt as a CLI to perform release tasks such as finding cherry
>>> picks,
>>> > or building koji configurations. The larger idea of the repository is
>>> you
>>> > define a release via a configuration file and perform various release
>>> > actions based on the data within the config file. The original
>>> repository
>>> > lives on my personal Github account [1]. At some point, this was
>>> forked to
>>> > theforeman organization and configurations for just Foreman stored in
>>> it.
>>> > Meanwhile, in the original repository are configs for Katello releases.
>>> >
>>> > I would like to propose merging the configuration files from
>>> theforeman to
>>> > my original repository, deleting thetheforeman fork and then
>>> transferring
>>> > my repository to theforeman to serve as the single shared repository.
>>> If
>>> > you have any concerns, objections or questions please raise them here.
>>> >
>>> > If there are no objections, I will perform this next Wednesday or
>>> Thursday.
>>> >
>>> >
>>> > [1] https://github.com/ehelms/tool_belt
>>> > [2] https://github.com/theforeman/tool_belt
>>> >
>>> > --
>>> > 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.
>>>
>>> +1, I would also like to merge https://github.com/dlobatog/fo
>>> reman_release
>>> into that repository, making each of the scripts a subcommand of
>>> tool_belt
>>>
>>> --
>>> 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.
>>>
>>
>>
>>
>> --
>> Andrew Kofink
>> akof...@redhat.com
>> IRC: akofink
>> Software Engineer
>> Red Hat Satellite
>>
>> --
>> 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
>



-- 
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] Community-developed Ansible modules for Foreman API objects

[Eric D Helms]

level and time should
we push modules to ansible/ansible versus providing them via a stand alone
git repository. I think there are pros and cons to both when it comes to
managing the modules, getting changes into the modules, developing new
modules or functionality and ease of use by a user. I think we want to
balance development efficiency with ease of use.


>
> I wanted to commit that code into https://github.com/theforeman/
> foreman-ansible-modules but had some issue.
> - I would overwrite the nailgun using modules like foreman_ptable.py etc.
> - there is no place to put Ansible module documentation fragments into
> like utils/module_docs_fragments/foreman.py
>
>
We can get that directory made (Andrew?). As for over-writing versus
merging the two ideas when there are competing modules, I tend to defer a
bit to the ATIX-crew who wrote most of the Foreman ones currently in there.
But I assume this in general will likely depend on the prior topic of
discussion.

If the other maintainers on the repository are OK with it, I think my
preferred plan (to help get your code centralized and more eyes and hands
working on it):

 1) merge your modules in, even if we put them in a separate directory for
now to avoid the clashes
 2) Add you as a maintainer on the repository
 3) Then you can update your repository to say we've moved
 4) In between all of those keep discussing the above

This will allow the benefits noted above, and allow us to just do further
re-factoring depending on direction within the theforeman repository.

Eric


> If anyone has an idea how to fix that let me know ;)
>
>
> Happy to see how it's going on
> Nosmoht
>
> --
> 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] Centralizing tool_belt in theforeman Github

[Eric D Helms]

I've began this process by capturing what I believe is everything from [1]
as an PR to the mainline tool_belt repository:

https://github.com/ehelms/tool_belt/pull/58

Once this is approved, I will do the delete and transfer dance.


[1] https://github.com/theforeman/tool_belt

On Mon, Oct 23, 2017 at 9:08 AM, Andrew Kofink <akof...@redhat.com> wrote:

> +1 I guess the foreman and katello config files will still live separately
> (i.e. katello_35.yaml and foreman_16.yaml) but in the same repo.
>
> On Mon, Oct 23, 2017 at 5:59 AM, Daniel Lobato Garcia <elobat...@gmail.com
> > wrote:
>
>> On 10/20, Eric D Helms wrote:
>> > For quite a few releases now, we've been using a little tool named
>> > tool_belt as a CLI to perform release tasks such as finding cherry
>> picks,
>> > or building koji configurations. The larger idea of the repository is
>> you
>> > define a release via a configuration file and perform various release
>> > actions based on the data within the config file. The original
>> repository
>> > lives on my personal Github account [1]. At some point, this was forked
>> to
>> > theforeman organization and configurations for just Foreman stored in
>> it.
>> > Meanwhile, in the original repository are configs for Katello releases.
>> >
>> > I would like to propose merging the configuration files from theforeman
>> to
>> > my original repository, deleting thetheforeman fork and then
>> transferring
>> > my repository to theforeman to serve as the single shared repository. If
>> > you have any concerns, objections or questions please raise them here.
>> >
>> > If there are no objections, I will perform this next Wednesday or
>> Thursday.
>> >
>> >
>> > [1] https://github.com/ehelms/tool_belt
>> > [2] https://github.com/theforeman/tool_belt
>> >
>> > --
>> > 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.
>>
>> +1, I would also like to merge https://github.com/dlobatog/fo
>> reman_release
>> into that repository, making each of the scripts a subcommand of tool_belt
>>
>> --
>> 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.
>>
>
>
>
> --
> Andrew Kofink
> akof...@redhat.com
> IRC: akofink
> Software Engineer
> Red Hat Satellite
>
> --
> 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.

[foreman-dev] Koji Outage

[Eric D Helms]

Our Koji is currently down from a web perspective and ssh access. Please
don't merge anything further to -packaging until we've resolved this. All
actions requiring Koji repositories for testing or actions in Koji cannot
be performed.

If Bryan or Lukas (since I am not sure who has AWS access to the box) could
investigate for us please.

-- 
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] Merge permissions to foreman-packaging

[Eric D Helms]

+1 from me as well. I'll look to add you to the team come Monday if no
objections are raised.

On Tue, Oct 24, 2017 at 5:53 AM, Ohad Levy <ohadl...@gmail.com> wrote:

>
>
> On Mon, Oct 23, 2017 at 7:16 PM, Ewoud Kohl van Wijngaarden <
> ew...@kohlvanwijngaarden.nl> wrote:
>
>> Hello all,
>>
>> To get more involved in packaging I'd like to request merge access to
>> foreman-packaging. I've already been monitoring PRs and submitted various
>> patches[1][2].
>>
>
> +1
>
>>
>> Regards,
>> Ewoud Kohl van Wijngaarden
>>
>> [1]: https://github.com/theforeman/foreman-packaging/commits/rpm/
>> develop?author=ekohl
>> [2]: https://github.com/theforeman/foreman-packaging/commits/deb/
>> develop?author=ekohl
>>
>> --
>> 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.
>



-- 
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] Issue with foreman tests

[Eric D Helms]

In hindsight, I should caught this on the PR. This scratched an itch in the
back of mind and there was the reminder:

https://github.com/Katello/katello/blob/master/lib/katello/tasks/reset.rake#L52

On Mon, Oct 23, 2017 at 11:59 AM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:

> Hello all,
>
> On Friday a PR was merged[1] that was intended to verify seeding worked.
> It turns out that you can't run rake db:migrate db:seed in one command
> which resulted in failing tests. An issue has been created[2] and a
> workaround implemented[3]. Please rerun tests that failed on
>
> NOT NULL constraint failed: architectures.name: INSERT INTO
> "architectures" ("created_at", "updated_at") VALUES (?, ?)
>
> If tests are still broken after that please do report back.
>
> [1]: https://github.com/theforeman/foreman-infra/commit/b275d94f8
> 8e2a60306a13154a7727e638bb4a874
> [2]: https://projects.theforeman.org/issues/21431
> [3]: https://github.com/theforeman/foreman-infra/commit/5099902d7
> 1e79ce7a0b2ec80239d942b92373ecf
>
> --
> 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] Katello Packaging Migration to Foreman Packaging Plan Proposal

[Eric D Helms]

On Mon, Oct 23, 2017 at 5:57 AM, Daniel Lobato Garcia <elobat...@gmail.com>
wrote:

> On 10/20, Eric D Helms wrote:
> > All,
> >
> > One of the items on the Roadmap I've sent out is centralizing packaging
> > into a single repository. The last time I tried this I attempted to go
> > whole hog migrating all things all at once. In order to make this more
> > approachable, and to encourage reviews, I would like to follow the
> > following plan in this rough order for nightlies only:
> >
> >  1) Move comps to foreman-packaging and update mash scripts
> >  2) copy releasers and tito.props to foreman-packaging for katello
> > repositories
> >  3) Move packages 1 by 1 to foreman-packaging starting leaving nightly
> RPMs
> > (rubygem-katello, hammer_cli_katello, and katello-installer) for last.
> This
> > will involve a PR to foreman-packaging and PR to katello-packaging adding
> > to the former and removing from the latter.
> >  4) Update katello-packaging README to indicate deperecation
> >
> > I am sending this plan along to gather feedback, find holes in the plan
> and
> > to get approval/disapproval from the community in taking this step.
> >
> > My plan would be to begin this migration towards the end of next week.
>
> I think it sounds great, ping me when you submit these PRs if you want
> someone
> to take a look.
>
> Would koji be affected by this? For example, new katello packages in the
> foreman-packaging repository would need to be in foreman tags or still the
> katello tags? If the latter, any reason why it would not make sense to
> change that
> to treat it like any other plugin?
>

Koji has no binding to the git repository, as long as the releasers tag
target Katello's (for the releasers I plan to bring over) then it will
release the package to the standard Katello tags. There are a few forces at
play in order to get Katello to be treated like other plugins:

 1) Move the git packaging to the same repository
 2) Devise a plan that allows any plugin to be individually tested and
committed to Koji or pushed to the repositories.
 3) Revise Foreman yum repository structure to handle Pulp, Candlepin and
Client repositories (per
https://groups.google.com/forum/#!searchin/foreman-dev/repos%7Csort:date/foreman-dev/6j0itrYnuJo/poJPo2FFAQAJ
)
 4) Solve the bandwidth issue (Greg mentioned they are working on this)

There are rough plans in place for everything but #2. And given that today,
Katello runs a system level test before pushing this one is imperative for
assuring the same level of assurance in the code.


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

[foreman-dev] Katello Packaging Migration to Foreman Packaging Plan Proposal

[Eric D Helms]

All,

One of the items on the Roadmap I've sent out is centralizing packaging
into a single repository. The last time I tried this I attempted to go
whole hog migrating all things all at once. In order to make this more
approachable, and to encourage reviews, I would like to follow the
following plan in this rough order for nightlies only:

 1) Move comps to foreman-packaging and update mash scripts
 2) copy releasers and tito.props to foreman-packaging for katello
repositories
 3) Move packages 1 by 1 to foreman-packaging starting leaving nightly RPMs
(rubygem-katello, hammer_cli_katello, and katello-installer) for last. This
will involve a PR to foreman-packaging and PR to katello-packaging adding
to the former and removing from the latter.
 4) Update katello-packaging README to indicate deperecation

I am sending this plan along to gather feedback, find holes in the plan and
to get approval/disapproval from the community in taking this step.

My plan would be to begin this migration towards the end of next week.

-- 
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] Current State of Nightlies

[Eric D Helms]

Nightlies are back to green.

On Wed, Oct 18, 2017 at 9:50 AM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:

> And https://github.com/theforeman/foreman-packaging/pull/1869 should fix
> the other issue.
>
>
> On Wed, Oct 18, 2017 at 02:24:19PM +0200, Ewoud Kohl van Wijngaarden wrote:
>
>> Agreed. https://github.com/theforeman/foreman-packaging/pull/1866
>>
>> On Tue, Oct 17, 2017 at 09:16:52AM +0200, Lukas Zapletal wrote:
>>
>>> EPEL is not great place to be for Rails or Node components. You should
>>> not bump versions in EPEL7 (major relase should go into EPEL8).
>>>
>>> On Tue, Oct 17, 2017 at 12:01 AM, Eric D Helms <eric.d.he...@gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Oct 16, 2017 5:17 PM, "Sean O'Keeffe" <sokee...@redhat.com> wrote:
>>>>
>>>> Why dont we ask the maintainer to pkg a new version or someone offer to
>>>> become a co-maintainer and get a new version into EPEL ?
>>>>
>>>>
>>>> While I think this is the right open source path, I'd weigh:
>>>>
>>>>  1) how long will nighties be broken waiting on a new package?
>>>>  2) 2.0 to 4.1 is a large jump and as a base dependency other EPEL
>>>> packages
>>>> may not work.
>>>>
>>>>
>>>>
>>>> On Mon, Oct 16, 2017 at 9:31 PM, Ewoud Kohl van Wijngaarden
>>>> <ew...@kohlvanwijngaarden.nl> wrote:
>>>>
>>>>>
>>>>> On Mon, Oct 16, 2017 at 04:18:53PM -0400, Eric D Helms wrote:
>>>>>
>>>>>>
>>>>>> Nightly RPM and tests have been broken for around 2 weeks now. This
>>>>>> morning
>>>>>> a bit of a regression was merged to foreman core to fix the breaking
>>>>>> RPM
>>>>>> aspect and I can report that nightly RPMs are now building. However,
>>>>>> this
>>>>>> leads to a breakage in plugin asset usage with the newer React
>>>>>> components.
>>>>>> To potentially address this I have opened [1] for testing and input.
>>>>>> As
>>>>>> part of the original breakage, I added to test_develop running npm
>>>>>> install
>>>>>> and webpack compile the same way our RPMs do in order to catch these
>>>>>> sort
>>>>>> of issues earlier.
>>>>>>
>>>>>
>>>>>
>>>>> Thanks for this!
>>>>>
>>>>> The second half is that after RPMs were built, repoclosure on the test
>>>>>> pipeline is currently failing [2]. The highlight being:
>>>>>>
>>>>>> *20:10:35* package: nodejs-react-dom-15.6.2-1.el7.noarch from
>>>>>> undertest-yum_el7-4203183943-68*20:10:35*   unresolved deps:
>>>>>> *20:10:35*  npm(object-assign) >= 0:4.1.0*20:10:35*
>>>>>> npm(loose-envify) < 0:2*20:10:35*  npm(loose-envify) >= 0:1.1.0
>>>>>>
>>>>>>
>>>>>>
>>>>>> nodejs-object-assign-2.0.0 exists in EPEL leading me to believe we
>>>>>> will
>>>>>> need to add both of these as top level packages carried in
>>>>>> foreman-packaging. Can anyone confirm or deny that is how this should
>>>>>> be
>>>>>> working? Or should another package we build be providing these?
>>>>>>
>>>>>
>>>>>
>>>>> I do believe we need to package this ourselves since we need a newer
>>>>> version than in EPEL.
>>>>>
>>>>> [1] https://github.com/theforeman/foreman/pull/4924
>>>>>> [2] http://ci.theforeman.org/job/packaging_repoclosure/37110/console
>>>>>>
>>>>>
> --
> 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.

[foreman-dev] Infra/Deployment/Platform Roadmap Update

[Eric D Helms]

A week or two back, I sent out a gathered Roadmap of tasks in
Infra/Deployment/Platform. The following is a report of updates on some of
those endeavors until I can move this to a better location for facilitating
updates and tracking.


   - Rails 5.X


   - Updates
  - Discussion on vendorizing vs. building SCL
  https://groups.google.com/forum/#!topic/foreman-dev/xJyxMx1lXy4
  - Notice of current state of core running on 5.1:
  https://groups.google.com/forum/#!topic/foreman-dev/kCMCCNZUN4w
   - Prior


   - need rh-ror50 or custom built SCL


   - consider whether we introduce a new SCL (e.g. tfm-ruby23) to separate
  RPMs built against old SCL vs. new


   - comment mmoll: We would need to upgrade Ruby (to 2.4 or 2.5) later,
  but I'd expect Rails 5.0 and even 5.1 to fully work also on Ruby 2.2


   - commend ekohl: if package names remained equal then it would simplify
  the installer/docs


   - should we jump to 5.1.latest and build the SCL instead? rh-ror50 is
  the last Rails SCL from RHSCL team


   - comment mmoll: with a little help from core and plugin devs, a move to
  Rails 5.1 for 1.17 feels achievable.


   - dlobatog: +1 - introducing the SCL to retire it quite soon will be a
  pain for upgrades and 5.1 for 1.17 doesn't seem that far off.


   - Jenkins Migration


   - Updates
  - Jenkins now has HTTPS interface: https://ci.theforeman.org/
  - redirect from HTTP needs adding
   - Prior
  - Migrate Jenkins master to EL7


   - add https interface to Jenkins


   - Jenkins Job Updates


   - Updates
  - Foreman nightly release pipeline created and has replaced former
  Foreman nightly jobs
   - Prior
  - Migrate jobs to pipelines


   - What is the benefit for this effort?


   - modern approach, more secure, provides more efficient jobs, jobs that
  are protected against crashes and restarts


   - Move all jobs into JJB


   - Update JJB code location within git for discoverability


   - Update jobs to run tests with all plugins installed


   - Update hammer core tests to run tests also for the major plugins (at
  least foreman and katello)


   - Add job for running hammer integration tests against live
  foreman/katello


   - Running Container Stack


   - Updates
  - No updates
   - Prior
  - address Github issues created from initial merge


   - remove current hacks in deployment


   - build up test suite for verifying container stack


   - add Jenkins job to build containers nightly


   - find way to continuously test container deployment


   - Merging katello-packaging to foreman-packaging


   - Updates
  - No updates
   - Prior
  - develop and agree on strategy for moving packages


   - move packages


   - any chance of moving Katello tags into foreman-plugins directly?


   - yes, but we need to solve other problems first:


   - updated yum repository structure (see below)


   - individual package release pipelines


   - Release automation


   - Updates
  - No updates
   - Prior
  - Using tool_belt & foreman_release to do the
cherry_picking/tagging/building/signing
  automatically


   - Update http://projects.theforeman.org/projects/
  foreman/wiki/Release_Process to document how it should work


   - Moving Katello puppet modules to foreman


   - Updates
  - foreman-module-sync being synchronized with Katello's
  - Ewoud working on migration steps to undertake in the next week
   - Prior
  - move modules to theforeman Organization


   - add puppet modules to foreman-installer-modulesync


   - Merging katello and foreman installers


   - Updates
  - No updates
   - Prior
  - Move all checks/hooks


   - Add katello modules


   - Move bin/{foreman-proxy-certs-generate,katello-certs-check}


   - Migrate scenarios


   - Sort out the packaging


   - Add deprecation notices to katello-installer / wipe master branch


   - Updated yum repository structure


   - Updates
  - No updates
   - Prior
  - Email thread discussing re-structure of repositories


   - agree on layout


   - re-factor mash scripts for new deployment


   - re-factor sync scripts to yum/deb repositories


   - update foreman release RPM for new repositories


   - Move package building from Koji to Copr


   - Updates
  - No updates
   - Prior
  - Phase 1: Submit builds in paralel - only rubygems and nodejs


   - Phase 2: Submit builds in paralel - foreman-core packages


   - Phase 3: Migrate to Copr


   - Multi-server service deployment


   - Migration off of Openshift V2


   - Redmine -- moved to stand alone server and off of Openshift entirely


   - prprocessor -- still running on Openshift V2


   - etherpad -- moved from katello to foreman openshift v2 instance


-- 
Eric D. Helms
Red Hat Engineering

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe f

Re: [foreman-dev] The road to Rails 5.1

[Eric D Helms]

Thanks for the update Michael. I just want to point interested parties to
the RPM side of the discussions that are on going over in
https://groups.google.com/forum/#!topic/foreman-dev/xJyxMx1lXy4

On Tue, Oct 17, 2017 at 4:32 PM, Michael Moll <kved...@kvedulv.de> wrote:

> Hi,
>
> while the original plan was to switch to Rails 5.0 soon and then begin
> 5.1 work, it's a major downside that RPMs would be broken for a
> potentially longer period, so I closed
> https://github.com/theforeman/foreman/pull/4867 and like to draw the
> attention of interested parties to
> https://github.com/theforeman/foreman/pull/4836 where all the changes
> that are queued up lead to a still 100% green Rails 5.0 test run and
> leave 21 test failures with 5.1.
>
> I guess two of iNečas' recently opened PRs will fix some of these.
>
> Besides the missing changes to get green tests one major problem is that
> there's no Rails 5 compatible version of turbolinks-classic, so either
> Foreman needs to move to turbolinks 5 or a forked turbolinks-classic gem
> would be needed, if turbolinks should be kept.
>
> In the meanwhile Rails 5.1 should be packaged for RPM in some way... :)
>
> 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.
>



-- 
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] Vendorizing or Building RPMs

[Eric D Helms]

Plugins do present the most complicated part of this process given they
would each potentially be requiring a few independent gems separate from
the core stack and we would not want bloat. Seems we'd need either:

 1) a single gem stack that plugins contribute to and is renegenrated with
all them enabled
 2) a method for plugins to generate the bundle install, and pick out just
the gems they need to contribute on top of the core stack

On Tue, Oct 17, 2017 at 6:42 PM, Dmitri Dolguikh <witlessb...@gmail.com>
wrote:

> > Today we package all required rubygems as RPMs and utilize a thirdparty
> > Software Collection (SCL) for both the Ruby (rh-ruby22) and Rails stack
> > (sclo-ror42). The team that manages the RHSCLs has already released Ruby
> > 2.3 and RUby 2.4 SCLs and will continue to do so. However, there are no
> > plans to release any further SCLs for the Rails stack. This means, in
> > addition to our own dependencies, we need to build and manage the Rails
> > stack for the versions we want. This adds more packaging burden on the
> RPM
> > side. GIven this, we have a few options:
> >
> >1) Build and manage our own SCLs for every version of Rails from here
> on
> > out
> >2) Vendorize Rails and thirdparty gems into a one or more base RPMs
> > (e.g. an RPM for rails stack and one for thirdparty dependencies)
>
> Not sure if this has already been considered: use bundler to package the
> app. In this case all dependencies, including rails will be cached locally,
> and we could then wrap the result into an rpm. Not sure how plugins would
> fit into this though.
>
> -d
>
> On Tue, Oct 17, 2017 at 11:17 AM, Bryan Kearney <bryan.kear...@gmail.com>
> wrote:
>
>> On 10/16/2017 04:36 AM, Michael Moll wrote:
>> > I don't really have stakes in RPMs, but I'd try to stick with option 1
>> > and I even expect that there's some demand for Rails SCLs at least in
>> > the RHEL/CentOS world by other projects, too.
>> >
>> > Regards
>>
>> I would suggest the decision be made based on the assumption that the
>> foreman community owns all the work for options 1 and 2. I have no
>> special instights, but I would hate to assume we could package based on
>> another communities work. Assume this commuity owns it all, which way is
>> better/easier/quicker/less error prone.
>>
>> -- bk
>>
>> --
>> 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.
>



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

[foreman-dev] Requesting dynflow 0.8.31 Release

[Eric D Helms]

The Katello nightly builds are currently failing after the merge of [1]
which added a required on dynflo w 0.8.31 that has been released to
rubygems but not to packaging repository yet. If we could please get a
release within the next day or two to unstick these builds it would be
appreciated.


[1]
https://github.com/Katello/katello/commit/ea51f03c05436c04c5f8a79c5fa8b8fce007864a

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

[foreman-dev] Current State of Nightlies

[Eric D Helms]

All,

Nightly RPM and tests have been broken for around 2 weeks now. This morning
a bit of a regression was merged to foreman core to fix the breaking RPM
aspect and I can report that nightly RPMs are now building. However, this
leads to a breakage in plugin asset usage with the newer React components.
To potentially address this I have opened [1] for testing and input. As
part of the original breakage, I added to test_develop running npm install
and webpack compile the same way our RPMs do in order to catch these sort
of issues earlier.

The second half is that after RPMs were built, repoclosure on the test
pipeline is currently failing [2]. The highlight being:

*20:10:35* package: nodejs-react-dom-15.6.2-1.el7.noarch from
undertest-yum_el7-4203183943-68*20:10:35*   unresolved deps:
*20:10:35*  npm(object-assign) >= 0:4.1.0*20:10:35*
npm(loose-envify) < 0:2*20:10:35*  npm(loose-envify) >= 0:1.1.0



nodejs-object-assign-2.0.0 exists in EPEL leading me to believe we will
need to add both of these as top level packages carried in
foreman-packaging. Can anyone confirm or deny that is how this should be
working? Or should another package we build be providing these?

[1] https://github.com/theforeman/foreman/pull/4924
[2] http://ci.theforeman.org/job/packaging_repoclosure/37110/console

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

[foreman-dev] Changes to test_develop and PRs

[Eric D Helms]

All,

As part of the recent nightly build failure, I have attempted to add an
additional check to test_develop (and thus PRs) to run the same npm install
and webpack build step the same was the packaging build. Please keep an eye
out for PRs failing in this area and bring to my attention.


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

[foreman-dev] Vendorizing or Building RPMs

[Eric D Helms]

Note: This is specific to RPMs because as far as I know the Debian process
is different and uses gems directly. Please correct me and contribute any
information with respect to Debian that I miss. I believe the Nodejs part
of the email does apply to Debian.

This proposal is in two parts: gems and node packages. The general issue
applies to both, the project has a need to be able to move and update
dependencies more quickly given the speed at which platforms like Rails,
React and Webpack update.


Node/NPM Packages

Today, we package nearly all nodejs packages that are required to either
build the UI or runtime UI dependencies into packages. At current count,
there are 78 nodejs packages listed in Koji as RPMs. Over the past few
months, the move to React and updating UI within Foreman core and branching
into plugins has led to multiple, and at times, compounding packaging and
thus nightly breakages. One of those breakages lasted over a week with
multiple developers spending many hours tracking down the issue. The speed
at which these changes are made makes keeping up successful nightly builds
difficult. The git repository gets well ahead of the packaging which leads
to compounding issues. This has also been the cause of stable version
release delays.

Proposal:
Deprecate nodejs packages in favor of foreman-assets or a new RPM
foreman-node-modules that contains a source tarball of node_modules/
packaged into a simple RPM that is used as a build dependency. This tarball
would be regenerated, and the package bumped, as dependency updates are
needed.


Ruby Gems

Today we package all required rubygems as RPMs and utilize a thirdparty
Software Collection (SCL) for both the Ruby (rh-ruby22) and Rails stack
(sclo-ror42). The team that manages the RHSCLs has already released Ruby
2.3 and RUby 2.4 SCLs and will continue to do so. However, there are no
plans to release any further SCLs for the Rails stack. This means, in
addition to our own dependencies, we need to build and manage the Rails
stack for the versions we want. This adds more packaging burden on the RPM
side. GIven this, we have a few options:

   1) Build and manage our own SCLs for every version of Rails from here on
out
   2) Vendorize Rails and thirdparty gems into a one or more base RPMs
(e.g. an RPM for rails stack and one for thirdparty dependencies)

Option 2, to vendorize, is a deviation from our prior practices in the area
of production deployment. Thus, I am reaching out to the community to get
feedback. One interesting consideration for vendorizing is when containers
are considered and having the ability to build them using 'bundle install'
versus using RPM based installation.

In theory vendorizing allows the community to move faster, keep up to date
with dependencies more easily and reduces the burden on RPM packaging to
keep nightly builds flowing. However, this does stray from the standard RPM
based installation benefits typically associated to it.


Please consider carefully, and weigh in even if it is simply to +1 or -1 a
given idea. Deployment is a large part of our project and the more voices
weighing in the better.

Thanks,
Eriic

-- 
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] Re: Etherpad Back Online (Sorta)

[Eric D Helms]

I was a bit pre-mature. There is no sorta! I upgraded the storage just
enough to let me fully restore the database. You should find anything as of
Sunday available on it now. If something is missing please let me know. But
for all intents and purposes, consider this up and running now.

Eric

On Tue, Oct 3, 2017 at 3:40 PM, Eric D Helms <ericdhe...@gmail.com> wrote:

> All,
>
> Openshift V2 sunsetting caused out normal etherpad to go down. I've been
> able to partially restore it on our still running V2 account. I was able to
> what I can surmise as partially restore the database, so if you had prior
> pads with data you need that may or may not exist on it. The partial
> restore is due to how much space mongodb consumes when restoring a database
> and the limited size of the V2 gear. We still have the original mongodb
> that can still be restored on other hardware or setup to recover any data
> that users may need. For now, if you need a scratch etherpad feel free to
> use this but please don't use it as long term storage. Prefer instead to
> use it for collaboration and move off anything you need to store to -dev
> mailing list or wiki for now.
>
> http://pad-theforeman.rhcloud.com/
>
> --
> Eric D. Helms
> Red Hat Engineering
>



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

[foreman-dev] Etherpad Back Online (Sorta)

[Eric D Helms]

All,

Openshift V2 sunsetting caused out normal etherpad to go down. I've been
able to partially restore it on our still running V2 account. I was able to
what I can surmise as partially restore the database, so if you had prior
pads with data you need that may or may not exist on it. The partial
restore is due to how much space mongodb consumes when restoring a database
and the limited size of the V2 gear. We still have the original mongodb
that can still be restored on other hardware or setup to recover any data
that users may need. For now, if you need a scratch etherpad feel free to
use this but please don't use it as long term storage. Prefer instead to
use it for collaboration and move off anything you need to store to -dev
mailing list or wiki for now.

http://pad-theforeman.rhcloud.com/

-- 
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] Release process & permissions

[Eric D Helms]

d have to ask someone to tag
>>>> > repositories, modify jenkins jobs, upload GPG signatures, post to the
>>>> > mailing list, tag new builds in Koji...
>>>> >
>>>> > 2 is to extend http://ci.theforeman.org/view/Release%20pipeline/ and
>>>> > make it a real pipeline from 0 to release completed. At this moment,
>>>> > releases that are not the first RC1 are mostly automated by
>>>> > https://github.com/dlobatog/foreman_release and
>>>> > https://github.com/theforeman/tool_belt.
>>>> >
>>>> > My proposal is to go forward with 2. Give Jenkins permissions to do
>>>> all
>>>> > of the actions needed, and whoever is the release nanny, ideally only
>>>> > has to make sure all of the steps are moving forward. If something
>>>> > breaks, figure out how to fix it for the next release.
>>>> >
>>>> > This would mean making a few extra jobs before and after the current
>>>> > release pipeline. In my opinion, it's the way to go to ensure anyone
>>>> can
>>>> > take over this responsibility.
>>>> >
>>>> > At this moment, we are in a situation where only people who
>>>> > mostly have permissions everywhere can successfully do a release
>>>> without
>>>> > asking many people for favors.
>>>> >
>>>> > Personally if we complete this, I see it as a big win as it would
>>>> dwarf
>>>> > our bus factor for release managers & allow us to release at any pace
>>>> we
>>>> > desire (right now it's slow because we can't truly release things from
>>>> > one day to the next due to the work involved).
>>>> >
>>>> > Thoughts?
>>>> >
>>>> > Here's the list of permissions:
>>>> >
>>>> > 
>>>> >
>>>> > Github:
>>>> >  - Push in foreman, foreman-selinux, foreman-installer,
>>>> >smart-proxy, foreman-infra, foreman-packaging
>>>> >
>>>> > Transifex -
>>>> >  - Allow to change the auto-update URL to point to latest -stable
>>>> >branch
>>>> >
>>>> > Redmine -
>>>> >  - Create new "Found in Release" version
>>>> >
>>>> > Jenkins -
>>>> >  - Modify jobs
>>>> >  - Run jobs
>>>> >
>>>> > Koji -
>>>> >  - Create tags
>>>> >  - SSH access to update the mash scripts
>>>> >  - Create packages
>>>> >  - Tag builds
>>>> >
>>>> > Repository servers
>>>> >  - ssh in deb.theforeman.org
>>>> >  - ssh in yum.theforeman.org
>>>> >
>>>> > Announcements -
>>>> >  - Post to foreman-announce
>>>> >  - Merge access in theforeman.org
>>>> >  - Change IRC message
>>>> >  - Publish in Twitter, G+
>>>> >
>>>> > ---
>>>> >
>>>> > --
>>>> > Daniel Lobato Garcia
>>>> >
>>>> > @dLobatog
>>>> > blog.daniellobato.me
>>>> > daniellobato.me
>>>> >
>>>> > GPG: http://keys.gnupg.net/pks/lookup?op=get=0x7A92D6DD38D
>>>> 6DE30
>>>> > 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...@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.
>>
>
> --
> 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] Building an Infra/Deployment/Platform Roadmap

[Eric D Helms]

This has been out for about a week with some comments and discussion so far
on the etherpad. I want to give a round of mention and discussion via -dev
list as well since sometimes etherpad is not obvious for updates. I have
copied the etherpad here. I will leave this thread open for around a week,
at which point, based on discussions that have occurred, take this and copy
it out to a more stable location and begin to give updates routinely on
these items over time.


High Level Needs

   - Rails 5.X


   - need rh-ror50 or custom built SCL


   - consider whether we introduce a new SCL (e.g. tfm-ruby23) to separate
   RPMs built against old SCL vs. new


   - comment mmoll: We would need to upgrade Ruby (to 2.4 or 2.5) later,
   but I'd expect Rails 5.0 and even 5.1 to fully work also on Ruby 2.2


   - commend ekohl: if package names remained equal then it would simplify
   the installer/docs


   - should we jump to 5.1.latest and build the SCL instead? rh-ror50 is
   the last Rails SCL from RHSCL team


   - comment mmoll: with a little help from core and plugin devs, a move to
   Rails 5.1 for 1.17 feels achievable.


   - dlobatog: +1 - introducing the SCL to retire it quite soon will be a
   pain for upgrades and 5.1 for 1.17 doesn't seem that far off.


   - Jenkins Migration


   - Migrate Jenkins master to EL7


   - add https interface to Jenkins


   - Jenkins Job Updates


   - Migrate jobs to pipelines


   - What is the benefit for this effort?


   - modern approach, more secure, provides more efficient jobs, jobs that
   are protected against crashes and restarts


   - Move all jobs into JJB


   - Update JJB code location within git for discoverability


   - Update jobs to run tests with all plugins installed


   - Update hammer core tests to run tests also for the major plugins (at
   least foreman and katello)


   - Add job for running hammer integration tests against live
   foreman/katello


   - Running Container Stack


   - address Github issues created from initial merge


   - remove current hacks in deployment


   - build up test suite for verifying container stack


   - add Jenkins job to build containers nightly


   - find way to continuously test container deployment


   - Merging katello-packaging to foreman-packaging


   - develop and agree on strategy for moving packages


   - move packages


   - any chance of moving Katello tags into foreman-plugins directly?


   - yes, but we need to solve other problems first:


   - updated yum repository structure (see below)


   - individual package release pipelines


   - Release automation


   - Using tool_belt & foreman_release to do the
   cherry_picking/tagging/building/signing automatically


   - Update
   http://projects.theforeman.org/projects/foreman/wiki/Release_Process to
   document how it should work


   - Moving Katello puppet modules to foreman


   - move modules to theforeman Organization


   - add puppet modules to foreman-installer-modulesync


   - Merging katello and foreman installers


   - Move all checks/hooks


   - Add katello modules


   - Move bin/{foreman-proxy-certs-generate,katello-certs-check}


   - Migrate scenarios


   - Sort out the packaging


   - Add deprecation notices to katello-installer / wipe master branch


   - Updated yum repository structure


   - Email thread discussing re-structure of repositories


   - agree on layout


   - re-factor mash scripts for new deployment


   - re-factor sync scripts to yum/deb repositories


   - update foreman release RPM for new repositories


   - Move package building from Koji to Copr


   - Phase 1: Submit builds in paralel - only rubygems and nodejs


   - Phase 2: Submit builds in paralel - foreman-core packages


   - Phase 3: Migrate to Copr


   - Multi-server service deployment


   - Migration off of Openshift V2


   - Redmine


   - prprocessor


   - etherpad


On Tue, Sep 19, 2017 at 8:24 AM, Eric D Helms <ericdhe...@gmail.com> wrote:

>
>
> On Tue, Sep 19, 2017 at 5:10 AM, Greg Sutcliffe <greg.sutcli...@gmail.com>
> wrote:
>
>> So, +1 to this idea, we've been lacking in direction for a bit, and a
>> "community roadmap" has been on my agenda for a while. Whilst that's
>> not 1:1 the same as what you're saying, it's related, and planning is a
>> good idea.
>>
>> On Mon, 2017-09-18 at 11:21 -0400, Eric D Helms wrote:
>> >
>> > [1] http://pad-katello.rhcloud.com/p/infra-deployment-roadmap
>>
>> Two things - firstly, isn't this hosted on Openshift v2, which is going
>> away soon? Secondly, are you aware of http://projects.theforeman.org/pr
>> ojects/foreman/wiki/Infrastructure_Updates
>> <http://projects.theforeman.org/projects/foreman/wiki/Infrastructure_Updates>
>> on the wiki?
>>
>
> First, yep which I mentioned in the thread related to Openshift V2
> migrations. Se

Re: [foreman-dev] request for write-access to katello-packaging

[Eric D Helms]

+1 from me as well

On Fri, Sep 22, 2017 at 3:57 AM, Lukas Zapletal <l...@redhat.com> wrote:

> +1 thanks for all the help there.
>
> On Thu, Sep 21, 2017 at 6:47 PM, John Mitsch <jomit...@redhat.com> wrote:
> > +1 from me, you've been a great help at reviewing the katello scripts!
> >
> > -John
> >
> > John Mitsch
> > Red Hat Engineering
> > (860)-967-7285
> > irc: jomitsch
> >
> > On Thu, Sep 21, 2017 at 12:00 PM, Evgeni Golov <evg...@redhat.com>
> wrote:
> >>
> >> Ohai,
> >>
> >> I would like to request write access to katello-packaging.
> >>
> >> I have 14 merged PRs [1] resulting in 14 commits [2].
> >> If I count it right, I also somehow reviewed 19 PRs [3].
> >>
> >> TIA
> >> Evgeni
> >>
> >> [1]
> >> https://github.com/Katello/katello-packaging/pulls?page=
> 1=is%3Apr+author%3Aevgeni=%E2%9C%93
> >> [2] https://github.com/Katello/katello-packaging/commits?author=evgeni
> >> [3]
> >> https://github.com/Katello/katello-packaging/pulls?utf8=%
> E2%9C%93=involves%3Aevgeni%20is%3Apr%20
> >>
> >>
> >> --
> >> Beste Grüße/Kind regards,
> >>
> >> Evgeni Golov
> >> Software Engineer
> >> 
> 
> >> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
> >> Commercial register: Amtsgericht Muenchen, HRB 153243,
> >> Managing Directors: Charles Cachera, Michael Cunningham, Michael
> >> O'Neill, Eric Shander
> >>
> >> --
> >> 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.
>
>
>
> --
> 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.
>



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

[foreman-dev] Database and Service Actions in RPM Post Scripts

[Eric D Helms]

Howdy,

There have been recent conversations that have popped up on PRs, for
example [1], and IRC conversations around whether or not our RPM packages
should be performing database actions and restarting services. This thread
is intended to gather feedback and view points to arrive a community
decision on whether or not we should continue this behavior, alter it with
limitation or out right get rid of it.

This mostly happens within Foreman and some plugins, and the actions
performed today:

 * database migrations
 * database seeds
 * apipie cache
 * httpd restart
 * foreman-tasks restart

There may be others, these are the ones I am aware of. The history of these
actions, as I understand it, is so that in theory you can yum install a
plugin and, without further action, the Foreman server continue to run now
with your plugin.

Now, for my personal view point. Our application stack is fairly complex,
and there are a decently large number high percentage install plugins and
ecosystem of plugins in general. Plugins performing these sorta actions as
part of yum install has the potential to create unintended consequences. We
have created an idempotent installer to manage our server installations for
a reason, to help orchestrate changes, provide a framework for known and
coordinated change. And that these types of actions should be strictly
relegated to it.

I encourage all Foreman and plugin developers to please weigh in so that we
may reach consensus.

Thanks for your time and consideration.


[1] https://github.com/theforeman/foreman-packaging/pull/1761

-- 
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] Building an Infra/Deployment/Platform Roadmap

[Eric D Helms]

On Tue, Sep 19, 2017 at 5:10 AM, Greg Sutcliffe <greg.sutcli...@gmail.com>
wrote:

> So, +1 to this idea, we've been lacking in direction for a bit, and a
> "community roadmap" has been on my agenda for a while. Whilst that's
> not 1:1 the same as what you're saying, it's related, and planning is a
> good idea.
>
> On Mon, 2017-09-18 at 11:21 -0400, Eric D Helms wrote:
> >
> > [1] http://pad-katello.rhcloud.com/p/infra-deployment-roadmap
>
> Two things - firstly, isn't this hosted on Openshift v2, which is going
> away soon? Secondly, are you aware of http://projects.theforeman.org/pr
> ojects/foreman/wiki/Infrastructure_Updates on the wiki?
>

First, yep which I mentioned in the thread related to Openshift V2
migrations. Second, I am aware of that as thats where I got some of the
items in the list. When this is all said and done, I can move it to the
wiki (or somewhere else) but the wiki is not a great platform for comments
and building up a discussion.


>
> Combining those two points, would it be better to have this in the wiki
> rather than on an etherpad?
>
> From my side, I'm working with Michael on upgrading the Puppet/Foreman
> infra, and with Evgeni on migrating/upgrading Redmine. I don't think
> either of these is controversial, but it's out there for the record ;)
>
> 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.
>



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

[foreman-dev] Building an Infra/Deployment/Platform Roadmap

[Eric D Helms]

Howdy All,

We've recently had some discussions about infra changes, past discussions
about deployment projects and additions (e.g. containers) and platform
changes (e.g. Rails 5.X support). For me, these all live in a similar area
of functionality or at the very least similar area of how they affect the
overall project and its constituents. Further, infra, deployment and
platform changes tend to be involved with wide ranging affects across core,
plugins, testing and infrastructure.  To that end, I'd like to build up a
Roadmap of items that fall into these categories and working list of
mid-level tasks that must be examined or completed in order to achieve them.

I've started a list of these pulled from discussions that have happened on
the mailing list, IRC or in PR discussions and put them into the etherpad
[1]. I'd like to ask for comments on existing, additional tasks, questions
or concerns, and other items that fit the theme of the discussion to be
added to the etherpad.

After some amount of gathering, editing and initial discussion, I plan to
post the list to the mailing list for any further discussion and then
finalizing it as the "current" Roadmap for items within it with some sense
of priority and timing for each. With the goal being to keep it up to date
over time so that we are continuing to track and provide visibility in
these areas.


[1] http://pad-katello.rhcloud.com/p/infra-deployment-roadmap

-- 
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] [infra] Packaging reorganization

[Eric D Helms]

On Sep 2, 2017 10:22 AM, "Timo Goebel" <m...@timogoebel.name> wrote:

I am wondering if we should name the katello-client repository either
foreman-client or just client. I can think of more plugins that need a
client package.
Timo


I was not going to suggest this yet, but since you brought it up and know
of other client tools I think this would be a great addition and coming
together for Foreman and Katello.  For the yum repositories (maybe this
also translates for Debian? sorry I am not as familiar with them) I'd then
suggest changing our structure to the following:

http://yum.theforeman.org
  -- nightly/
 -- foreman/
   -- el7/
 -- plugins/
   -- el7/
 -- client/
   -- el7/
   -- el6/
   -- el5/
   -- f25/
   -- f26/
 -- katello/
   -- el7/
 -- pulp/
   -- el7/
 -- candlepin/
   -- el7/
  -- 1.15
  -- 1.14

Another question, though possibly overkill would be if its worth separating
out the smart proxy (and plugins) to their own repository to differentiate
them more clearly (and potentially support more distros?).


On 2. Sep 2017, at 01:48, Eric D Helms <ericdhe...@gmail.com> wrote:

Howdy,

As a lead-in to being working towards migrating Katello's packages to the
foreman-packaging repository, I'd like to propose a slight re-organization
of the repository. As well, to seek any other ideas or problems any might
see with the proposal.

Currently, the packaging repository is a flat structure with all packages
being represented by a directory containing sources and a spec file. When
looking at it, I find it hard to think about them in an organized manner
given we separate by repository into foreman and foreman-plugins (and
eventually katello repositories). Thus, my proposal is to let the packaging
repository reflect the repository organization by moving things into the
following directories:

foreman-packaging
   - foreman
   - plugins
   - katello
   - katello-client


Thoughts?

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

-- 
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] [infra] Packaging reorganization

[Eric D Helms]

On Sep 2, 2017 6:17 AM, "Ewoud Kohl van Wijngaarden" <
ew...@kohlvanwijngaarden.nl> wrote:

On Fri, Sep 01, 2017 at 07:48:19PM -0400, Eric D Helms wrote:

> As a lead-in to being working towards migrating Katello's packages to the
> foreman-packaging repository, I'd like to propose a slight re-organization
> of the repository. As well, to seek any other ideas or problems any might
> see with the proposal.
>
> Currently, the packaging repository is a flat structure with all packages
> being represented by a directory containing sources and a spec file. When
> looking at it, I find it hard to think about them in an organized manner
> given we separate by repository into foreman and foreman-plugins (and
> eventually katello repositories). Thus, my proposal is to let the packaging
> repository reflect the repository organization by moving things into the
> following directories:
>
> foreman-packaging
>   - foreman
>   - plugins
>   - katello
>   - katello-client
>
>
> Thoughts?
>

It makes sense to me and I have the same problem but it does make me wonder
how we deal repo boundries/repoclosure.

Plugins probably needs foreman where katello probably requires foreman and
maybe plugins. If a package from plugins is now required in foreman, is it
moved?


Yes. The breakdown in the packaging repository would essentially be by
repository. So if something lives in the foreman repository it lives in the
foreman folder. Repository requires and repoclosure should not be affected
by this change.


I assume katello-client is supposed not to require any other repos, just
base OS and possibly EPEL. If a package is needed in both foreman and
katello-client, should it be copied?


That's a good question. I would say it should go in the most base of
repositories in a heirarchy given that koji only lets you have a single
build in it but can be tagged across. I think this situation should be rare.


Long term/big picture: I know we have pulp and candlepin. Where do they fit
in? Should katello eventually be merged into plugins?


We don't manage Pulp and Candlepin packaging from that perspective. We make
use of their builds but the process is separate. I think most would
probably argue for putting Katello into the plugins repository once we
figure out a few constraints within our CI.

Eric



-- 
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] [Infra] Proposal to Move Jenkins Job Configurations

[Eric D Helms]

On Sep 2, 2017 6:27 AM, "Ewoud Kohl van Wijngaarden" <
ew...@kohlvanwijngaarden.nl> wrote:

On Fri, Sep 01, 2017 at 07:27:23PM -0400, Eric D Helms wrote:

> Howdy,
>
> Some quick background, for those that don't know a majority of our Jenkins
> job configuration are stored in git. I find our Jenkins job configuration
> to be important for developers to be able to understand and contribute
> changes. However, today, these configurations are stored deep inside the
> foreman-infra [1] repository. I am proposing one of two ideas to bring
> these to the forefront:
>
> 1) Move them to the top of foreman-infra under a "jenkins" or "jobs" folder
> 2) Move them to their own repository (e.g. foreman-ci)
>
>
> [1]
> https://github.com/theforeman/foreman-infra/tree/master/pupp
> et/modules/jenkins_job_builder/files/theforeman.org
>

+1 on bringing them to the forefront. The question where to put them is,
for better or worse, tightly coupled to the way we deploy them. Currently
it's puppet. If you move them to the top it can still be deployed easily
with a symlink or other scripting magic.

Splitting to their own repository makes it harder to re-use the puppet
deployment pipeline and we'd need to build a new one. Where would we put
this? Usually you think of Jenkins when building a pipeline but having
Jenkins manage itself might not be the best idea.


Could the puppet just clone the repository if using option #2 and work like
before?


Given that background right now I'm leaning to 1) but I can easily be
convinced of 2) if a more suitable deployment method is found.


-- 
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] [infra] Packaging reorganization

[Eric D Helms]

Howdy,

As a lead-in to being working towards migrating Katello's packages to the
foreman-packaging repository, I'd like to propose a slight re-organization
of the repository. As well, to seek any other ideas or problems any might
see with the proposal.

Currently, the packaging repository is a flat structure with all packages
being represented by a directory containing sources and a spec file. When
looking at it, I find it hard to think about them in an organized manner
given we separate by repository into foreman and foreman-plugins (and
eventually katello repositories). Thus, my proposal is to let the packaging
repository reflect the repository organization by moving things into the
following directories:

foreman-packaging
   - foreman
   - plugins
   - katello
   - katello-client


Thoughts?

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

[foreman-dev] [Infra] Proposal to Move Jenkins Job Configurations

[Eric D Helms]

Howdy,

Some quick background, for those that don't know a majority of our Jenkins
job configuration are stored in git. I find our Jenkins job configuration
to be important for developers to be able to understand and contribute
changes. However, today, these configurations are stored deep inside the
foreman-infra [1] repository. I am proposing one of two ideas to bring
these to the forefront:

 1) Move them to the top of foreman-infra under a "jenkins" or "jobs" folder
 2) Move them to their own repository (e.g. foreman-ci)


[1]
https://github.com/theforeman/foreman-infra/tree/master/puppet/modules/jenkins_job_builder/files/theforeman.org

-- 
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] Enabling RHEL7 extra repository on koji

[Eric D Helms]

Works for me. Would only the foreman-nightly-rhel7 tag need this as an
external repository?

On Fri, Sep 1, 2017 at 8:40 AM, Lukas Zapletal <l...@redhat.com> wrote:

> Hello,
>
> we have a long-standing bug in SELinux (#18284) - conflict between
> docker and foreman policies. In order to properly handle this, we need
> to have container-selinux present in the buildroot. The thing is this
> is RHEL7 extras repository, we only have base and optional.
>
> I would like to propose enabling this in the next maintenance window.
>
> --
> 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.
>



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

[foreman-dev] [Infra] Jenkins Job Naming Conventions

[Eric D Helms]

Howdy,

This is a bit of bike shedding perhaps, but as I start to re-write some of
our jobs into Jenkins pipeline in my spare time I'd like to establish and
follow some conventions along the way since this is a bit of a fresh start.
Two example PRs for those curious are at [1] [2].

The topic for this question is around job naming conventions. I see it as
two options:

 1) functionality - entity
   -- test-katello
   -- test-foreman
   -- release-katello
   -- test-foreman-pull-request
   -- test-foreman-tasks
 2) entity - functionality
   -- katello-test
   -- katello-release
   -- foreman-test
   -- foreman-release
   -- foreman-pull-request-test
   -- foreman-tasks-test


[1] https://github.com/theforeman/foreman-infra/pull/321
[2] https://github.com/theforeman/foreman-infra/pull/323


-- 
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] Test failures and merging PRs

[Eric D Helms]

sulted in a snowball effect. This
has never been an enjoyable position to be in, since it could come on
unexpectedly. Other plugin's have suffered the same and expressed the same.

I would argue that since Foreman provides the plugin ability, it has to
honor not breaking them. When this all started, there was a shallow plugin
API and the way to "integrate" your plugin was through judicious use of
Rubyisms not a public, standardized API. Times have changed and we should
change with them. However, I don't think we can whole hog change the way
things work until we provide the ability to do things properly. To that
end, I think we have two other conversations worth having and gathering
data about:

 1) What does it mean to be a plugin
 2) What are the ways plugins try to extend Foreman and which are not
covered by a sustainable API

To date, the best resource we have is [1]. And note, even [1] describes
methods of overriding any functionality found within Foreman (or another
plugin for that matter). This could both easily be their own email topics
or a single topic but moved to their own thread. I've also wondered if
plugins are still the right way to go if we stopped to look back at what
our goals with them are but thats another, much larger discussion to be had.

I am happy to break out these topics to their own threads if people think
that would be prudent.

Eric

[1]
http://projects.theforeman.org/projects/foreman/wiki/How_to_Create_a_Plugin


>
> If it turns out there are more PRs that are failing with same errors, we
>> merge
>> PRs if we're sure they don't introduce new Katello failures. At this time,
>> we're not blocking merges until Katello is green again. (*) here the
>> suggestion applies
>>
>> 4) upgrade is red
>>
>> this is very similar to katello job, if there's some issue in upgrade, we
>> should not merge the PR. I remember though, there was a time when we knew
>> the
>> job is broken which fall under "known to be broken" category.
>>
> +1, if upgrade is broken the PR is broken.
>
>>
>> 5) There's no 5, all the rest must be green. Sometimes hound service does
>> not
>> respond and remains in "running" state, then it's retriggered by the
>> reviewer.
>> prprocessor and travis must always be happy.
>>
> Don't get me started on hound. But it's the best we have right now, so
> generally speaking: Yes: Linting is important. If there are lint warnings,
> we shouldn't merge the PR.
>
>>
>> Now the promised suggestion. When we see katello/upgrade job is broken on
>> multiple PRs, the first reviewer who spots it should notify the rest of
>> developers about "from now on, we ignore tests XY". The ideal channel
>> seems to
>> be this list. This helps Katello devs to find out when it started, what
>> were
>> the commits that first induced it.
>>
>> [1] https://groups.google.com/forum/#!topic/foreman-dev/p7ESagXwNwk
>>
>> Thanks for comments
>>
>> --
>> Marek
>>
>> Timo
>
>
> --
> 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] [Infra] Openshift V2 Sunsetting: Redmine and Prprocessor

[Eric D Helms]

Yea - I honestly don't think we even need to migrate the etherpad per say.
But rather, just spin up a new etherpad that we can make use of and note to
users to port any existing "long lived" pads over themselves.

Eric

On Wed, Aug 30, 2017 at 12:25 PM, Greg Sutcliffe <greg.sutcli...@gmail.com>
wrote:

> On Wed, 2017-08-30 at 11:22 -0400, Eric D Helms wrote:
> > In addition, we realized today that there is another project we
> > should migrate (and migrate to Foreman proper) the etherpad that is
> > under the Katello namespace:
> >
> > http://pad-katello.rhcloud.com
>
> I would expect that to be easy enough, but I have no access to the
> katello openshift namespace. Once we've moved the rest we can sync on
> getting that migrated.
>
> No word yet on the requested extra resources.
>
> 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.
>



-- 
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] [Infra] Openshift V2 Sunsetting: Redmine and Prprocessor

[Eric D Helms]

In addition, we realized today that there is another project we should
migrate (and migrate to Foreman proper) the etherpad that is under the
Katello namespace:

http://pad-katello.rhcloud.com

On Mon, Aug 28, 2017 at 9:34 AM, Greg Sutcliffe <greg.sutcli...@gmail.com>
wrote:

> Update from today's testing... many thanks to Evgeni for his help!
> There are 3 apps listed on the v2 platform:
>
> # Pluginmatrix
>
> http://pluginmatrix-theforeman.rhcloud.com/
>
> I don't think this is in active use, but if it's still needed, we can
> add it to the migration list. No action taken so far.
>
> # PrProcessor
>
> We got this running on v3 without too much effort. I updated the
> webhook in foreman_templates to test against the new URL and saw a post
> from GitHub in the logs, things seemed to happen.
>
> We think this is ready for larger testing - ideally we'd like to use
> Foreman core as lots happens there. Process would be to alter the url
> of the webhook to the new processor and let it run for a day or two to
> check all is fine. We can then look at updating the webhooks on all the
> configured repos (there is a script to do this in the codebase).
>
> There are some small niggle to figure out as part of that, such as
> getting a sensible custom url, and making cron work. we're confident we
> can get that running.
>
> Does anyone have concerns over enabling this in a few days time on
> foreman/foreman for testing? I'll notify again before I do so, just in
> case.
>
> # Redmine
>
> Obviously more complex, but initial tests have gone well. We got Psql
> and Redmine (from our fork, with a few extra patches) running, db
> migrated (clean, not a copy of ours), and could see the web interface.
> Cron will also need enabling here (as above) and outgoing email needs
> testing too, but so far it's promising.
>
> We're requesting more resources to our account so that we can try a
> larger test, and I'll update again once that's done. I *think we may be
> able to run them side-by-side for a bit, which will allow some user
> load testing - this is important as we have to move up to Ruby 2.2 or
> 2.3 as part of this (v2 is on 1.9.3), so making sure nothing subtle is
> broken will help.
>
> So far so good. Thanks again to Evgeni for the help!
> 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.
>



-- 
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] [Infra] Reducing Test Matrix

[Eric D Helms]

There are a few different points to reply to, hopefully I did not miss one.
For the base topic, based on feedback and target for post 1.16, I think we
end up with:

 * 2.2 - postgres
 * 2.3 - postgres
 * 2.4 - postgres
 * 2.2 - mysql
 * 2.2 - sqlite3

Jenkinsfile in Repos

I think there are valid points and reasons for why this could be a good
idea. However, I lean more towards this meaning a later goal and not an
initial target. This would provide a more Travis like experience. I think
to achieve this we need enough stability in both our job definitions, but
also in the expectations that our Jenkins would be providing for plugins
and other projects. If we want to share common code to make writing of the
jobs easier, we need to have that common code stabilized or else we end up
having to update multiple repositories every time we make a change. Thus, I
would put this on the back burner as a goal when we stabilize. The
centralized infra repository allows easier job definitions, and code
sharing and development.

Docker

I would love to get to this point compared to how RVM setups work. I think
this should be a second pass update that we make across the board after we
make the first set of jobs given that we already know the slaves are
configured and work with the RVM and database setups. I think we need to do
some up front gathering and testing of information for things like:

 a) what all do we need containers of? (versions of ruby, OSes, databases,
puppet availability etc.)
 b) which set of slaves can run docker? and label them
 c) what configuration updates do we need to make to slaves to run docker
on them

I think this can be done in parallel to my efforts if someone would like to
take it on. We can add it to the wiki page as an item.

Hound Dropping

This probably deserves it's own thread whether we drop Hound in favor of
using Jenkins to do the linting.


Eric

On Wed, Aug 23, 2017 at 5:05 AM, Michael Moll <kved...@kvedulv.de> wrote:

> Hi,
>
> On Tue, Aug 22, 2017 at 07:44:42PM -0400, Eric D Helms wrote:
> > I am beginning to look at updating some of our test infrastructure by
> > re-writing Jenkins jobs into the pipeline plugin [1]. This is a new
> style,
> > with a different way of both writing and thinking about how jobs are
> > crafted. I've started this work by attempting to write jobs for both
> > Foreman and Katello [2].
>
> +1!
>
> >  ruby: 2.1, 2.2, 2.3, 3.4
> >  databases: mysql, postgresql, sqlite3
> >
> > I would like to propose the following:
> >
> >  1) We drop sqlite3 entirely
>
> At least one Ruby version should get tested with sqlite3, as almost all
> dev setups will be sqlite and that's making it easy to reproduce test
> failures.
>
> >  3) We pick the most widely used Ruby version and test mysql with that
>
> Sounds OK.
>
> >  2.2 -- used in RPM production
>
> This will need to get updated for Rails 5 anyway.
>
> >  2.1, 2.3, 2.4 -- used by Debian production
>
> 2.1 is Debian/jessie, which will be dropped with Rails 5. 2.4 is not
> used in any Debian or Ubuntu version and it's highly likely that
> Debian/unstable (and thus the next Ubuntu LTS 18.04) will go from 2.3 to
> 2.5 directly.
>
> At the end with Rails 5 only Ruby 2.3 and 2.4 would stay and 2.5 get
> added in Q1/2018. Depending on the RPM situation 2.4 could get dropped
> theroretically again in Q2/2018.
>
> 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.
>



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

[foreman-dev] [Infra] Reducing Test Matrix

[Eric D Helms]

I am beginning to look at updating some of our test infrastructure by
re-writing Jenkins jobs into the pipeline plugin [1]. This is a new style,
with a different way of both writing and thinking about how jobs are
crafted. I've started this work by attempting to write jobs for both
Foreman and Katello [2].

The current test_develop job for Foreman (which runs after pull requests
are merged) is a 4x3 matrix resulting in 12 different configurations
running. They are:

 ruby: 2.1, 2.2, 2.3, 3.4
 databases: mysql, postgresql, sqlite3

I would like to propose the following:

 1) We drop sqlite3 entirely
 2) We test all rubies on postgresql only
 3) We pick the most widely used Ruby version and test mysql with that

This would effectively reduce the number of test runs in the matrix to 5
which should in theory increase throughput of testing and keep things
focused on the most important pieces to test. Further, sqlite3 is not a
production database so I feel it not worth the resources (but it would only
add one more job to keep it). I also don't see how Ruby version should
affect database choice and thus find no reason to run the full matrix
across all rubies for Mysql.

>From what I think I know, of the Rubies:

 2.2 -- used in RPM production
 2.1, 2.3, 2.4 -- used by Debian production

[1] https://jenkins.io/doc/book/pipeline/
[2] https://github.com/theforeman/foreman-infra/pull/321

-- 
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] request for write-access to forklift

[Eric D Helms]

It has been a week with only positives. Evgeni welcome to the team!

On Wed, Aug 2, 2017 at 9:36 PM, Tom McKay <thomasmc...@redhat.com> wrote:

> +2 thanks for your contributions!
>
> On Wed, Aug 2, 2017 at 9:34 AM, Christine Fouant <cfou...@redhat.com>
> wrote:
>
>> +1
>>
>> On Wed, Aug 2, 2017 at 9:26 AM, John Mitsch <jomit...@redhat.com> wrote:
>>
>>> +1 You've made a lot of good contributions to forklift!
>>>
>>> John Mitsch
>>> Red Hat Engineering
>>> (860)-967-7285 <(860)%20967-7285>
>>> irc: jomitsch
>>>
>>> On Wed, Aug 2, 2017 at 8:57 AM, Ewoud Kohl van Wijngaarden <
>>> ew...@kohlvanwijngaarden.nl> wrote:
>>>
>>>> On Wed, Aug 02, 2017 at 02:45:52PM +0200, Evgeni Golov wrote:
>>>>
>>>>> I would like to request write access to forklift.
>>>>>
>>>>
>>>> Big +1 Evgeni has shown great insight in details with his reviews and
>>>> high quality PRs.
>>>>
>>>> I have 19 merged PRs [1] resulting in 19 commits [2].
>>>>> If I count it right, I also somehow reviewed 7 PRs [3].
>>>>>
>>>>> TIA
>>>>> Evgeni
>>>>>
>>>>> [1] https://github.com/theforeman/forklift/pulls?page=1=is%3Ap
>>>>> r+author%3Aevgeni=%E2%9C%93
>>>>> [2] https://github.com/theforeman/forklift/commits?author=evgeni
>>>>> [3] https://github.com/theforeman/forklift/pulls?utf8=%E2%9C%93;
>>>>> q=involves%3Aevgeni%20is%3Apr%20
>>>>>
>>>>
>>>> --
>>>> 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.
>>>
>>
>>
>>
>> --
>>
>> Christine Fouant
>>
>> Software Engineer
>>
>> Red Hat
>>
>> <https://www.redhat.com>
>> <https://red.ht/sig>
>>
>> --
>> 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.
>



-- 
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] Request to join Katello Installer team in Katello Org

[Eric D Helms]

It has been a week with only positives. Welcome to the team Chris!

On Wed, Aug 2, 2017 at 9:35 AM, Christine Fouant <cfou...@redhat.com> wrote:

> +1
>
> On Wed, Aug 2, 2017 at 9:31 AM, John Mitsch <jomit...@redhat.com> wrote:
>
>> +1 from me as well, Chris has been working in the installer for a while
>> now.
>>
>> John Mitsch
>> Red Hat Engineering
>> (860)-967-7285 <(860)%20967-7285>
>> irc: jomitsch
>>
>> On Tue, Aug 1, 2017 at 3:04 PM, Eric D Helms <ericdhe...@gmail.com>
>> wrote:
>>
>>> +1 from me, Chris has been very involved and adding value to both puppet
>>> and installer itself.
>>>
>>> On Tue, Jul 25, 2017 at 6:54 PM, <chrob...@redhat.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> Since my last request almost a year ago I have been making quite a lot
>>>> of commits and they have gone from being pretty awful to alot better and
>>>> through that I have been understanding Puppet and Ruby alot better thanks
>>>> to people like Stephen Benjamin, Ekohl, and Justin.
>>>>
>>>> My commits started out as some basic Ruby but went on to more advanced
>>>> Ruby and bigger Puppet commits.
>>>>
>>>> I have also been doing reviews of Puppet PRS mostly from Ekohl.
>>>>
>>>> Here are some of my PR's both in the Ruby and Puppet:
>>>>
>>>> https://github.com/Katello/katello-installer/pull/518
>>>>
>>>> https://github.com/Katello/puppet-katello/pull/175
>>>>
>>>> https://github.com/Katello/puppet-qpid/pull/51
>>>>
>>>> https://github.com/Katello/puppet-katello/pull/168/files
>>>>
>>>> https://github.com/Katello/puppet-qpid/pull/65
>>>>
>>>> https://github.com/Katello/puppet-qpid/pull/62
>>>>
>>>> https://github.com/Katello/puppet-pulp/pull/189
>>>>
>>>> https://github.com/Katello/puppet-katello/pull/162
>>>>
>>>> https://github.com/Katello/katello-installer/pull/472
>>>>
>>>> Here are some of the ones I have reviewed around puppet/Ruby recently:
>>>>
>>>> https://github.com/Katello/puppet-qpid/pull/60
>>>>
>>>> https://github.com/Katello/puppet-katello/pull/190
>>>>
>>>> https://github.com/Katello/puppet-katello/pull/198
>>>>
>>>> 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
>>>
>>> --
>>> 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.
>>
>
>
>
> --
>
> Christine Fouant
>
> Software Engineer
>
> Red Hat
>
> <https://www.redhat.com>
> <https://red.ht/sig>
>
> --
> 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] Aligning Foreman & Katello git repositories

[Eric D Helms]

as
> installed the katello release RPM which enables the needed yum repositories
> but that will not be true anymore if we ship it within foreman-installer.
>
> We'll also want to remove/disable the katello scenarios on Debian/Ubuntu.
>

Yes please! The benefits here do out weight the issues that need addressing.


>
> You may notice I haven't thought this through too much and it may depend
> on a unified Yum repository structure but there are big usability and
> reliability wins we can gain.
>
> [1]: https://github.com/theforeman/foreman-bats
> [2]: https://github.com/theforeman/forklift
> [3]: https://github.com/theforeman/foreman-packaging
> [4]: https://github.com/katello/katello-packaging
> [5]: https://github.com/theforeman/foreman-packaging/pull/1541
> [6]: https://github.com/theforeman/foreman-installer-modulesync
> [7]: https://github.com/katello/foreman-installer-modulesync
> [8]: https://github.com/katello/katello-installer
> [9]: https://github.com/theforeman/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.
>



-- 
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] request for write-access to forklift

[Eric D Helms]

+! from me

On Wed, Aug 2, 2017 at 8:57 AM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:

> On Wed, Aug 02, 2017 at 02:45:52PM +0200, Evgeni Golov wrote:
>
>> I would like to request write access to forklift.
>>
>
> Big +1 Evgeni has shown great insight in details with his reviews and high
> quality PRs.
>
> I have 19 merged PRs [1] resulting in 19 commits [2].
>> If I count it right, I also somehow reviewed 7 PRs [3].
>>
>> TIA
>> Evgeni
>>
>> [1] https://github.com/theforeman/forklift/pulls?page=1=is%3Ap
>> r+author%3Aevgeni=%E2%9C%93
>> [2] https://github.com/theforeman/forklift/commits?author=evgeni
>> [3] https://github.com/theforeman/forklift/pulls?utf8=%E2%9C%93;
>> q=involves%3Aevgeni%20is%3Apr%20
>>
>
> --
> 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] Foreman in Containers

[Eric D Helms]

The work Sebastian mentions here [1] and talked about in my deep dive have
now been merged to Forklift.

Does this mean it's developer or production ready? No, there is still a
chunk of work as outlined by [2] but this does push us closer to having a
more stable version of this working.

What does this mean for me then? If you are interested in container work,
you can now more easily collaborate on the work by:

 1) Testing and using it and filing issues at [3]
 2) Tackling one of the open issues at [2]
 3) Open PRs to Forklift master with fixes and enhancements


Eric

[1] https://github.com/theforeman/forklift/pull/424
[2] https://github.com/theforeman/forklift/projects/1
[3] https://github.com/theforeman/forklift/issues/new

On Wed, Jun 21, 2017 at 9:10 AM, Sebastian Gräßl <sebast...@validcode.me>
wrote:

> Hej all,
>
> There have been a few requests and questions about official containers
> already
> and it may increase with the push of container infrastructure.
> There have also been conversations in the past about containers and
> even though Foreman has it's focus more on lower decks of the
> infrastructure,
> putting more effort into documenting and taking action to easily start a
> Foreman
> or Katello container either as standalones or in combination with services
> in other containers.
>
> Eric has already done great work in forklift[1] to build images with
> ansible-container and setting up containers in Open Shift.
> There are also other repositories that on GitHub to build foreman and
> smart-proxy images[2][3] and
> there are probably a few local experiments around as well.
>
> Once Eric's PR is merged, I'm going to building scripts and jobs for/in
> Jenkins.
>
> There is already an image on Docker Hub[4], which should, when ready,
> be replaced by the new nightly ones and pushed regularly.
>
> Meanwhile it might be good to have a discussion on what the expectations
> are on how the images can be used.
>
> All the best,
> Sebastian
>
> [1] https://github.com/theforeman/forklift/pull/424
> [2] https://github.com/HearstAT/docker_foreman_dev
> [3] https://github.com/HearstAT/docker_foreman_smart_proxy_chef
> [4] https://hub.docker.com/r/foreman/foreman/
>
> --
> 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] Katello with debian repositories

[Eric D Helms]

On Tue, Jul 18, 2017 at 11:50 AM, Matthias Dellweg <dell...@atix.de> wrote:

> Thanks for the compliments!
>
> Actually, the pulp_deb part is an active pull request '
> https://github.com/pulp/pulp_deb/pull/24'.
> It's features can be tested with the pulp-admin command.
> The Katello part however is not ready to be merged anywhere.
> Is it complicated to do the reviews against our repositories?
>

A bit - and a PR does not mean it has to be merged. You can mark it as WIP.
I too am excited to see this work being tackled and would request PRs to
make review and cycle of it easier. Plus, this makes awareness easier too.

E


>
>   Matthias
>
> - Original Message -
> From: "Justin Sherrill" <jsher...@redhat.com>
> To: "foreman-dev" <foreman-dev@googlegroups.com>
> Sent: Tuesday, July 18, 2017 3:34:13 PM
> Subject: Re: [foreman-dev] Katello with debian repositories
>
> This is awesome!
>
> Would you be willing to open Pull requests against the main projects for
> easier review?
>
> -Justin
>
>
> On 07/18/2017 04:43 AM, Matthias Dellweg wrote:
> > Hi all,
> > here at ATIX-AG (Munich), we started to implement the necessary steps,
> to integrate Debian/Ubuntu repositories in Katello's content management
> system.
> > Since we reached a point of minimal functionality, we thought, we could
> share our progress with the community.
> > Since a handfull of software stacks are involved in the problem,
> modifications to no less than three projects were necessary.
> >
> > With the following combinations of the branches we can sync and publish
> the stable release of a debian repository:
> > * https://github.com/ATIX-AG/katello/tree/feature/add_deb_
> repository_type
> > * https://github.com/ATIX-AG/runcible/tree/feature/add_deb_type
> > * https://github.com/ATIX-AG/pulp_deb/tree/feature/sync_
> release_structure
> >
> > Since we added some debian archive specific filters for releases,
> components and architectures in pulp_deb,
> > the next step will be to implement the corresponding configuration
> options in the Katello UI.
> >
> > We would be happy if anyone were willing to test this and comment on it.
> > Matthias and the ATIX crew
> >
> > --
> > ATIX - The Linux & Open Source Company
> > http://www.atix.de
>
> --
> 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] Dropping Fedora 24 packages

[Eric D Helms]

I went ahead an opened a PR to remove this in preparation [1]. We don't
have any official policies that I can think of for how long to let this
discussion sit before pulling the trigger.

As ewoud points out, we should split the "dropping Fedora all together"
into its own discussion. I think this one is a bit less controversial with
F26 out.


[1] https://github.com/theforeman/foreman-packaging/pull/1725

On Wed, Jul 12, 2017 at 8:20 PM, Eric D Helms <ericdhe...@gmail.com> wrote:

> This gets a +1 from me due to the fact that Fedora 24 is now no longer in
> support mode and the low percentage of users using Fedora in general. This
> would reduce our overall overhead of support.
>
>
> Eric
>
> On Wed, Jul 12, 2017 at 10:58 AM, Greg Sutcliffe <greg.sutcli...@gmail.com
> > wrote:
>
>> Forgot to add a link:
>>
>> https://theforeman.org/2017/03/2017-foreman-survey-analysis.html#page1
>>
>> Page down to the first table (not pie chart) in that section.
>>
>> 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.
>>
>
>
>
> --
> Eric D. Helms
> Red Hat Engineering
>



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

[foreman-dev] Re: [foreman-users] Re: [event] Deep Dive: Running the Foreman Stack in Containers - Mon 10th July, 2pm (UK)

[Eric D Helms]

On Mon, Jul 10, 2017 at 10:43 PM, Alejandro Cortina <
alejandro.corti...@gmail.com> wrote:

> Ey,
>
> thank you for the video! really good stuff.
>
> Since one of the strong points of k8s is to make rapid development I think
> it would be good to make a P2 video showing that. Ex.: how can you
> code/update/ mix and mach new services and deploy and/or rollback if broken.
>

I'll put this on the list for when we get to this in general. I've mostly
spent time just trying to get the stack to come up and not on advanced
workflows yet. This is definitely in the pipeline of things to look at
though. And I think it would be helpful to get info from users as to how
they see themselves wanting to use and deploy the stack on a platform like
this given what it can provide.

For example, in my current way of tackling it I am imaging users pulling
pre-built images and running them. That is, not pushing the requirement to
build the images on to the users. This comes with its own benefits and
potential downsides for flexibility.


>
> I think also it would be good to add Kubernetes to the title to make it
> more reachable in youtube.
>

Greg - is that possible to add keywords or adjust the title for Kubernetes
/ Openshift?


>
> Cheers,
>
> Alex
>
> On Thursday, June 29, 2017 at 11:15:45 PM UTC+9, Greg Sutcliffe wrote:
>>
>> Hi all,
>>
>> Running Foreman in a container is a question that comes up from time to
>> time in the Foreman community. Eric Helms has been experimenting with
>> running the whole Foreman stack (core, proxies, plugins) inside
>> Kubernetes, and wants to show you how it looks. We'll be holding a deep
>> dive into this on Monday 10th July, at 2pm (GMT +1). You can tune in
>> here:
>>
>> https://www.youtube.com/watch?v=mPjUvNAYp1c
>>
>> As always, we welcome your contributions to the video - do join us live
>> on YouTube Live chat or in our IRC channel to put your questions to
>> Eric!
>>
>> Cheers,
>> Greg
>> --
>> IRC / Twitter: @gwmngilfen
>> Diaspora: gwmng...@joindiaspora.com
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Foreman users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-users+unsubscr...@googlegroups.com.
> To post to this group, send email to foreman-us...@googlegroups.com.
> Visit this group at https://groups.google.com/group/foreman-users.
> 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] Dropping Fedora 24 packages

[Eric D Helms]

This gets a +1 from me due to the fact that Fedora 24 is now no longer in
support mode and the low percentage of users using Fedora in general. This
would reduce our overall overhead of support.


Eric

On Wed, Jul 12, 2017 at 10:58 AM, Greg Sutcliffe <greg.sutcli...@gmail.com>
wrote:

> Forgot to add a link:
>
> https://theforeman.org/2017/03/2017-foreman-survey-analysis.html#page1
>
> Page down to the first table (not pie chart) in that section.
>
> 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.
>



-- 
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-users] Re: [foreman-dev] [event] Deep Dive: Running the Foreman Stack in Containers - Mon 10th July, 2pm (UK)

[Eric D Helms]

I did not get a chance to answer all the questions during the deep dive so
here is my follow up.

On Mon, Jul 3, 2017 at 8:20 AM, Ohad Levy <ohadl...@gmail.com> wrote:
>
>  * Current state and future Roadmap
>>
>
> I would be happy if you could also cover:
> - Smart proxy features (and how it works - e.g. a container per feature
> with base container etc).
>

I have not touched more of the core smart proxy feature management such as
DHCP and DNS yet.


> - Dev vs Production (whats in scope vs not)
>

I mentioned this in the video, but I'll recap. I have mostly targeted
production setups but there are known strategies for development. There are
a few ways we could consider and try to do development with this:

 1) ansible-container run is local docker and has a section for
dev_overrides [1]. With this you should point and mount source code
directly in when using 'run' (however, run does not entirely work currently
due to size of the setup)
 2) Openshift could have a host path mounted for development and allow
source code to be edited directly to use it as a dev environment
 3) Openshift has an rsync strategy to rsync a directory to a container for
development work

[1]
https://docs.ansible.com/ansible-container/container_yml/reference.html#dev-overrides


> - Installer - do we still need it in a context of a Kubernetes
> application?
>

I would say no given the current state of the installer. The installer is
designed around a single machine deployment currently. The puppet modules
themselves are not currently usable as they would each need to be tweaked
to allow for deploying no runtime configuration. We could then explore
trying to puppet apply them to build the containers. You could argue it is
bad on me to try to not re-use them due to all the work that has gone into
them. I just found starting from scratch and working with Ansible to be
easier and quicker than attempting to dissect them so far.

I do believe we still need an "installer" or "deployer" to orchestrate
everything being configured and setup for users. Our stack can get complex,
and between all the customization pieces, passwords, certificates, having a
tool to manage that would be useful for user interaction and ease.


> - SCL ? can we move away from it?
>

I think that's a big question. You are essentially asking can we move away
from RPM packaging (since Deb uses gems directly if I recall). There is a
valid argument for using gems directly. That would reduce build overhead,
allow for development and production to be closer to together and reduce
build time. We'd still want the SCL for runtime on enterprise Linux to
allow for upgrading the version of Ruby as I think that is better than
relying on RVM.


> - reuse? for example, https://github.com/manageiq?q=container have some
> basic ruby / rails containers etc
>

Sure, any container could be used as a base and built on top of. This would
come down to how much customization do we need or is there in an existing
container. Right now I build the entire stack, so every application gets a
container built except for using thirdparty Postgres and Mongodb.


> - application scaling ? (e.g. more dynflow workers etc).
>

I touched on this briefly, by default I am attempting to set services as
scaled by default to enforce getting used to and dealing with those
behaviors for scaling. For example, having 2 Foreman applications, 4 Pulp
workers by default. I have not yet tried a 2 or more foreman-tasks replica
yet. But I'll put it on my list to bump next spin up.

Eric


>
> sorry for the long list :)
>
> thanks,
> Ohad
>
>>
>>
>> Thanks,
>> Eric
>>
>>
>> [1] https://github.com/theforeman/forklift/pull/424
>>
>> On Thu, Jun 29, 2017 at 10:15 AM, Greg Sutcliffe <
>> greg.sutcli...@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> Running Foreman in a container is a question that comes up from time to
>>> time in the Foreman community. Eric Helms has been experimenting with
>>> running the whole Foreman stack (core, proxies, plugins) inside
>>> Kubernetes, and wants to show you how it looks. We'll be holding a deep
>>> dive into this on Monday 10th July, at 2pm (GMT +1). You can tune in
>>> here:
>>>
>>> https://www.youtube.com/watch?v=mPjUvNAYp1c
>>>
>>> As always, we welcome your contributions to the video - do join us live
>>> on YouTube Live chat or in our IRC channel to put your questions to
>>> Eric!
>>>
>>> Cheers,
>>> Greg
>>> --
>>> IRC / Twitter: @gwmngilfen
>>> Diaspora: gwmngil...@joindiaspora.com
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "foreman-de