[foreman-dev] Code owners attempt 2

[Ewoud Kohl van Wijngaarden]

Hello all,

A while ago I proposed code owners for the packaging files. We tried 
this[1] but didn't work in our setup. It turns out that those mentioned 
as owners need permissions on the repository. In our case the packaging 
team (not individual members) has no permission.


There are 3 options:

1) Remove the file since it doesn't work
2) Create a packaging-core group with the intersection of both groups
3) Give @theforeman/packaging permissions on core

Personally I'd really like us to work together better and think this 
could reduce our packaging issues but have no preference between 2 or 3.


[1]: https://github.com/theforeman/foreman/blob/develop/.github/CODEOWNERS

--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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] Releases for EOL Fedora, why ?

[Ewoud Kohl van Wijngaarden]

On Sun, Dec 17, 2017 at 02:11:25AM -0800, Matt wrote:

Why are the latest Fedora versions so poorly supported and EOL ones are ?


Lack of time to properly package and test it. Is the primairy reason. 
Another thing that was always difficult for the main foreman package was 
keeping rails versions aligned.


Somewhere we decided to drop F24 but not add a newer Fedora release. Now 
that core is upgrading to Rails 5.1 we could target F27 again.



Because of this there is a very annoying gap for freeIPA releases as CentOS
is too far behind on FreeIPA and Foreman doesn't support the proxy on the
latest supported Fedora version.


The proxy should be much easier to support since it has fewer 
dependencies. The hardest part might be that our current testing is 
based on booting a Foreman instance with a proxy and see if it 
registers. If we boot a proxy but not a Foreman we'll need new tests so 
it's sufficiently covered.


We do have pipelines in forklift[1] that deploy a separate proxy - that 
could be modified to test the proxy on Fedora but deploy foreman on 
CentOS. Biggest worry there is CI resources but we're working on that.



Any idea how to fix this annoying gap all the time ?


Help us fix it in the foreman-packaging[2] repository. I'd be happy to 
help you in getting things going.


[1]: https://github.com/theforeman/forklift
[2]: https://github.com/theforeman/foreman-packaging

--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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] Forklift boxes are moving

[Ewoud Kohl van Wijngaarden]

Hello all,

tl;dr: forklift boxes are now in boxes.d/*.yaml and you manage 
boxes.d/99-local.yaml instead of boxes.yaml. Migration should happen 
automatically but do rebase your open PRs.


Longer explanation:

https://github.com/theforeman/forklift/pull/393 was merged. This change 
unifies all boxes in a boxes.d directory.


Previously we had:
* config/base_boxes.yaml
* boxes.yaml
* .tmp_boxes/*.yaml

Now we have:
* boxes.d/00-base.yaml
* boxes.d/99-local.yaml
* boxes.d/*.yaml

They're loaded in alphabetical order so you can influence loading. 
Temporary pipeline boxes are created as boxes.d/80-tmp-*.yaml.


You should now create a boxes.d/99-local.yaml instead of a boxes.yaml. 
Forklift will migrate the box if needed but if you have open PRs then 
you should rebase them. While migrating it ignores symlinks which should 
making switching back and forth possible.


As always: please report any problems you might have.

--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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

[Ewoud Kohl van Wijngaarden]

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.

Re: [foreman-dev] The package.json thing in git

[Ewoud Kohl van Wijngaarden]

On Thu, Dec 14, 2017 at 04:18:45PM +0100, Lukas Zapletal wrote:

for some reason, npm upgrade is touching my package.json on every run.
This file is in git, so it is annoying to have that edited every run.
Can we do something with this?


I think you're supposed to use npm install. npm upgrade is an alias for 
npm update (don't get me started that there's also the hardcoded udpate 
alias). npm update updates a package.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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

[Ewoud Kohl van Wijngaarden]

On Thu, Dec 07, 2017 at 01:02:00PM +0100, Ondrej Prazak wrote:

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.

[3] https://github.com/oauth-xx/oauth-ruby/pull/150


The PR has been merged and version 0.5.4 has been released. Looks like 
we should test with this.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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

[Ewoud Kohl van Wijngaarden]

On Thu, Dec 07, 2017 at 09:52:21AM -0500, Eric D Helms wrote:

Thanks for the weekly updates!


I'll echo that. Greatly appreciated.


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


Option 1 sounds easier.


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


https://github.com/theforeman/foreman/pull/4869 was merged earlier this 
week. We now need to update fog in our packages.


https://github.com/theforeman/foreman-packaging/pull/1970 adds fog-ovirt
https://github.com/theforeman/foreman-packaging/pull/1975 bumps fog. 
This needs json >= 2 and I think that's only available in the new SCL.



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.


In RPM packaging we could carry a patch since we've unbundled. In Debian 
packaging this doesn't work due to bundling so we might need to fork.



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.

Re: [foreman-dev] Custom hiera in Katello 3.4 deployment

[Ewoud Kohl van Wijngaarden]

On Thu, Dec 07, 2017 at 04:16:14PM +0100, Lukas Zapletal wrote:

I have Katello 3.4 and I created this file:

/etc/foreman-installer/custom-hiera.yaml

---
dns::zones:
 home.lan:
   soa: winter.home.lan
   soaip: 192.168.99.1
   contact: hostmaster.home.lan.

After re-running the installer (in dry mode) nothing really happens.
This is already configured system, is there anything I need to do in
order to add this zone?


That depends on 88d31627716da45696a0628a892c83dc10ebfc86[1] which was 
included in theforeman-dns 5.0.1. Foreman 1.15 only includes 3.0.1 so it 
needs a backport. I don't think we'll be doing more of those for 
upstream but I can do it downstream.


[1]: 
https://github.com/theforeman/puppet-dns/commit/88d31627716da45696a0628a892c83dc10ebfc86

--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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

[Ewoud Kohl van Wijngaarden]

On Wed, Dec 06, 2017 at 07:07:05AM -0800, Jonathon Turel wrote:

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.


Perhaps this is unrelated and not even possible, but I'd like to know if 
we could change database provisioning/seeding to not require candlepin. 
Currently for the organization a matching org in candlepin is created. 
That's a dependency that ideally shouldn't be there. Do you see this as 
an option?


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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

[Ewoud Kohl van Wijngaarden]

On Wed, Dec 06, 2017 at 02:40:36PM +0200, Tomer Brisker wrote:

Shimon Shtein - has 75 merged commits [1] and has taken part in the reviews
of 64 merged commits[2].


+1


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.


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

Re: [foreman-dev] Firefox 57 and noVNC

[Ewoud Kohl van Wijngaarden]

On Tue, Dec 05, 2017 at 09:43:20AM +0100, Lukas Zapletal wrote:

I was trying noVNC the other day on FF 57. Imported katello CA (it was
a katello intance), but it didn't work until I flipped flag
"network.websocket.allowInsecureFromHTTPS" on and then it worked.

I remember that Firefox always worked out of box - when server CA was
imported, it worked like charm. In the documentation we have "FF might
need to turn on this flag". Anyone knows under which circumstances we
need to flip this on?

Any luck setting up FF 57 without any hacking with noVNC?

https://theforeman.org/manuals/1.15/index.html#7.1NoVNC


There are settings (websockets_ssl_{key,cert}) to choose which 
certificate is presented by the VNC websockets proxy. Are you sure the 
correct certificates are used by 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.

Re: [foreman-dev] Kanban tools and redmine

[Ewoud Kohl van Wijngaarden]

On Thu, Nov 30, 2017 at 10:27:40AM +0100, Marek Hulán wrote:

Dne středa 29. listopadu 2017 9:05:28 CET, Lukas Zapletal napsal(a):

Can you elaborate on why something does not make sense to track in
RedMine? I am not following, RedMine is a generic ticketing system and
you can create as many tickets as you want, e.g. Buy milk. It will
work. This is a dogma I do not take as an argument. What's relevant is
if you need to create private work items, but we do have a private
feature in RedMine and we use it from time to time. And frankly, we
don't need these very often (mostly security issues).


Sorry for answering someone else question, but from my experience, redmine is
great for tracking dev stuff, including back traces, links to PR, BZ, release
that includes the fix etc. Stuff like buy milk that does not hopefully have a
backtrace is easier to track in some board as it's easier to manipulate. More
realistically, things like "review PR $number" is easier to add and track in
more lightweight system. I think these are simply two different use cases and
I'm fine using two different tools for them.

So for me, I'd prefer to keep using what I need, redmine and some board and
not trying to combine both together.


This mirrors my experience. It's also easier to keep downstream issues 
out of upstream but still track them.



If you look to the past, various scrum teams tried dozens off tools.
But hey, you know what is still here? RedMine (and RHBZ of course :-)
- those systems survived. My sole opinion is let's ditch RedMine and
use RHBZ for everything, many open source projects do this. But I
understand many people cannot live with Bugzilla, that's fine. OK!
Let's just stick to RedMine then. If people want to try RedMine
plugins, I totally do support that. What I really like is to have
everything in one place - no copies.

Historically, there have been problems with RedMine plugins for scrum,
it was overloading the server when whole team was moving tickets. But
we might upgraded to better hosting how, if infrateam approves I am
all for trying anything that is a RedMine plugin and works with
regular issues.

This could be a chance to setup "staging" redmine, since we still have
some knowledge from the migration. There we can test it on our current
data and vote how we like it.

LZ

On Wed, Nov 29, 2017 at 8:00 AM, Ivan Necas  wrote:
> My uderstanding of kanban is, that moving the cards manually on the signal
> board is actually part of the kanban way of doing things. Another thing,
> that is integrated part of the kanban process is
> WIP limits, that I don't even see on the redmine plugin. Another reason
> for
> actually not using
> redmine for this is the rasks, that don't make sense to actually track in
> redmine.
>
> I have a pr to nice Marek's tooling around automating some common actions
> around
> Kanboard https://github.com/ares/kansync/pull/5 and so far, I'm happy with
> this.
>
> -- Ivan
>
> út 28. 11. 2017 v 22:37 odesílatel Andrew Kofink 
>
> napsal:
>> I'm open to using other kanban style tools. To me it doesn't really
>> matter
>> that much how we plan - it's the same information just in a different
>> format. So, if people have reasons, then I'm fine with switching.
>>
>> On Tue, Nov 28, 2017 at 4:29 PM, Walden Raines 

wrote:

>>> Hey,
>>>
>>> With several teams moving to kanban style tools for the visualization of
>>> tasks I'm wondering if anyone has tried redmine's PluginKanban [1].
>>>
>>> I really like the idea of a trello/kanboard like tool but I hate having
>>> to update tasks in multiple places.  Another idea I had was to switch
>>> (back) to using GH issues and use GH projects [2] as well.
>>>
>>> Any other thoughts on how to make these kanban boards work better with
>>> redmine?
>>>
>>> Cheers,
>>> Walden
>>>
>>> [1] http://www.redmine.org/projects/redmine/wiki/PluginKanban
>>> [2] https://help.github.com/articles/about-project-boards/


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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

[Ewoud Kohl van Wijngaarden]

On Thu, Nov 30, 2017 at 09:57:24AM +0100, Marek Hulán wrote:

Dne středa 29. listopadu 2017 14:36:18 CET, Ewoud Kohl van Wijngaarden
napsal(a):

On Wed, Nov 29, 2017 at 02:18:35PM +0100, Lukas Zapletal wrote:
>> 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.

+1 this is very similar to Django's release policy: in 1.x it was x
deprecated and x+2 removed. Starting 2.0 they'll follow semver. I'd
suggest we do the same.

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

+1 on letting 2.0 drop block on dropping things rather than adding
things.


Actually I'd prefer to use this opportunity to drop or rewrite stuff we know
is problematic. E.g. taxonomies (especially nesting), API v1, hostgroup
provisioning, extracting puppet to a plugin, smart variables merging with
parameters (not smart class parameters), dropping unattended installation mode
(or at least refactoring).


These sound like good goals. How hard would it be to make the changes 
you're suggesting?


I have a slight preference to make 1.17 the 2.0 already because of the 
changes it's introducing but other than dropping API v1 and unattended 
installation mode they all sound like non-trivial tasks that will not be 
ready in time for 1.17.


Maybe we need a list of deprecated features/desired breaking changes so 
we can look at it after a release when we're starting to plan for the 
next. If it grows to a certain size or the release manager feels like 
it's time for a major then they can announce it's being considered. That 
way devs have time to give priority to the breaking changes a long time 
in advance rather than the 2 weeks prior to branching.


What I'm proposing are guidelines that mostly focus on clear 
communication - no strict policy. Communication is much more important 
than what we actually do.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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] Unique IDs and UI testing automation

[Ewoud Kohl van Wijngaarden]

On Wed, Nov 29, 2017 at 01:08:13PM -0500, Walden Raines wrote:

In order to assist in UI automation, I would like to propose that we add
unique IDs to the following elements:

  - Tables and table rows (s)
  - All inputs, including those not technically in a form (row select
  checkboxes, for example)
  - All buttons

These IDs should all follow the same format, perhaps something like
object.class-object.id-element.type.  For example, product-2-row and
product-2-checkbox.

Thoughts on this?  Anything that needs to be added or changed?


+1 This was also the feedback I heard from QE. Sometimes they have to 
use xpaths to test which are more likely to break than IDs.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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

[Ewoud Kohl van Wijngaarden]

Usually that's as fast as possible. Given the current status and time in 
this timezone I'd expect that's somewhere tomorrow.


On Wed, Nov 29, 2017 at 08:22:20AM -0500, Eric D Helms wrote:

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.

Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0

[Ewoud Kohl van Wijngaarden]

On Wed, Nov 29, 2017 at 02:18:35PM +0100, Lukas Zapletal wrote:

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.


+1 this is very similar to Django's release policy: in 1.x it was x 
deprecated and x+2 removed. Starting 2.0 they'll follow semver. I'd 
suggest we do the same.



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.


+1 on letting 2.0 drop block on dropping things rather than adding 
things.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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] 1.16.0 release builds started

[Ewoud Kohl van Wijngaarden]

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.

Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0

[Ewoud Kohl van Wijngaarden]

Anything that's on the mailing list with [plugin author action required] 
is likely breaking the API.


Recently we had the mass change from FactoryGirl to FactoryBot (which is 
causing a lot of pain while cherry picking to older releases as well).  
That had to be coordinated to sync it up with all plugins that were 
using it.


I recall Stephen got so sick of his salt plugin breaking every time he 
stopped maintaining it. That was mostly due to accidental breakage 
because there's no clear API that we guarantee.


So I'd disagree we use SemVer.

On Wed, Nov 29, 2017 at 01:04:45PM +0100, Lukas Zapletal wrote:

Where exactly do we have any info about SemVer for core? I know about
plugins, but not core.

Core plugin API gets rarely broken, we've been only extending it in
the past (although there were some cases I think).

LZ

On Wed, Nov 29, 2017 at 12:01 PM, Greg Sutcliffe
 wrote:

On 29/11/17 10:45, Lukas Zapletal wrote:

Oh no, *everyone* is talking features. :-) This has really nothing to
do with features, because that can easily fall into "neverending"
category of what's big enough change or not.


Well, *technically* we use SemVer (I know, I know...). For that, while
features play a part, for me it's more about correctly calling out
breaking changes. So if we're every going to deprecate a bunch of stuff,
then we should call *that* 2.0. Otherwise it's just grandstanding ;)
 *Technically* we should be including the internal plugin API in our
SemVer and bumping the major version every time plugins need to
update... but that might get silly :P


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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

[Ewoud Kohl van Wijngaarden]

On Wed, Nov 29, 2017 at 10:39:42AM +0100, Lukas Zapletal wrote:

What have Linus Torvalds and me in common? We both don't remember
numbers higher than ten.

I propose to follow Linux kernel versioning and do 2.0 instead of 1.18
for no other reason that it's just too high number and it's
approaching crazy 20. "One point eighteen" sounds crazy, I always mess
up with "One point eight". Frankly, I kinda lost track somewhere after
1.14. :-)

I'd like also to propose to avoid exceeding 10 in the future - someone
speak up as we will approach to 1.8. Or we can put this to release
wiki.

If we already have some infrastructure set for 1.18, I propose 1.19 to
be 2.0 and act now - let's define a plan what needs to be done in
advance. I can only think of version number in RedMine, but you tell
me here what's needed.

I really hope it's not just me messing around with higher numbers or
having problems with typing four characters instead of three many
times.


While I don't care if we pick 1.18, 1.19 or maybe even 1.17 I do agree 
it's getting to the point where we are hard to compare with the 1.0 
release.


I'd like to consider implementing semver as well. Some things I can 
think of:


* A formal plugin API
* Functions in templates

Deprecations can happen but are only removed in 3.0. This might mean we 
do 2 -> 3 a lot faster than 1 -> 2 but that's ok IMHO.


We can also implement APIs as experimental if we're unsure if they're 
the best.


With this in mind the rails 4.2 -> rails 5.1 might be a good reason to 
adopt 2.0. Since rails 5.2 will the last 5.x, rails 6.0 might be a 3.0 
reason.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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

[Ewoud Kohl van Wijngaarden]

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

Re: Re: [foreman-dev] Kanban tools and redmine

[Ewoud Kohl van Wijngaarden]

On Wed, Nov 29, 2017 at 09:45:49AM +0100, Daniel Lobato Garcia wrote:

On 11/28, Ewoud Kohl van Wijngaarden wrote:

On Tue, Nov 28, 2017 at 04:29:01PM -0500, Walden Raines wrote:
> I really like the idea of a trello/kanboard like tool but I hate having to
> update tasks in multiple places.  Another idea I had was to switch (back)
> to using GH issues and use GH projects [2] as well.

Just going to jump on the GH projects. While I really like the idea, for me
they're too limiting since they're only within a single repo while a lot of
work involves multiple PRs in different repos.

> [2] https://help.github.com/articles/about-project-boards/


Projects in GitHub are also per-team,
https://github.com/orgs/theforeman/projects, which allows to track
issues in multiple repos. I'm fine with anything, but as Lukas said
previously, the less places we have to look at the better.


Regardless of the current discussion this is useful. I was sure I read 
somewhere that it was possible but couldn't find it.



BZ + GitHub would work for me, we would have to update our Redmine
automation to BZ of course.


There's a lot of automation downstream too and yesterday we discussed 
adding the ability of use BZ + GH directly. Many installer module PRs 
don't have a Redmine issue which would be similar. Currently it's still 
causing a lot of manual work.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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] Kanban tools and redmine

[Ewoud Kohl van Wijngaarden]

On Tue, Nov 28, 2017 at 04:29:01PM -0500, Walden Raines wrote:

I really like the idea of a trello/kanboard like tool but I hate having to
update tasks in multiple places.  Another idea I had was to switch (back)
to using GH issues and use GH projects [2] as well.


Just going to jump on the GH projects. While I really like the idea, for 
me they're too limiting since they're only within a single repo while a 
lot of work involves multiple PRs in different repos.



[2] https://help.github.com/articles/about-project-boards/


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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

[Ewoud Kohl van Wijngaarden]

On Thu, Nov 23, 2017 at 02:03:11PM +0100, Ondrej Prazak wrote:

this is just a quick summary of where we stand with 1.17, please feel free
to correct me if I got something wrong.


#21546 is also blocking proxy registration on Debs. That's already on 
Rails 5 but EL7 is getting closer to switching over as well which means 
we'll likely be blocked on all platforms.


https://projects.theforeman.org/issues/21564

--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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: Re: Re: [foreman-dev] Re: 1.15.4 - 1.16 RC.1 - 1.17 status

[Ewoud Kohl van Wijngaarden]

On Mon, Nov 20, 2017 at 05:36:29PM +, Ivan Necas wrote:

po 20. 11. 2017 v 13:36 odesílatel Daniel Lobato Garcia <elobat...@gmail.com>
napsal:


On 11/20, Ohad Levy wrote:
> On Sun, Nov 19, 2017 at 10:35 PM, Ewoud Kohl van Wijngaarden <
> ew...@kohlvanwijngaarden.nl> wrote:
>
> > On Sun, Nov 19, 2017 at 11:27:57AM +0200, Ohad Levy wrote:
> >
> >>
> >> Can anyone shed some light on ETA for 1.16 GA?
> >>
> >>
> > I should have given an update earlier.
> >
> > So far we've been wanting to include the foreman tasks as a service
from
> > core rather than from foreman-tasks. As always we want that change to
first
> > land in develop but we've been struggling with broken nightlies for
quite
> > some time. It loked like it was fixed since the builds started to pass
> > aagin but we have no validation on the actual UI. Turns out that's
broken
> > and we have no automated testing for this.
> >
> > Would it be an option to ship 1.16 without dynflow service in the core
or
> > would that break things?
>
>
> AFAIU - nothing uses it atm as we were uncertain if it can really  be
> used.. there is some code in core regarding that, so I'm not sure if that
> matters... Daniel?

It definitely can be used as proven by:

https://github.com/theforeman/foreman/pull/4240
https://github.com/Katello/katello/pull/6750
https://github.com/Katello/katello/pull/6752
https://github.com/theforeman/foreman/pull/4717

Not having a separate service to run Dynflow doesn't have many
implications now
that nothing is using it.

If foreman-tasks still ships the service to start/stop the dynflow
executor,
we're still fine (same as 1.15). Even without tasks, there's always a
dynflow
executor running with Foreman
(
https://github.com/theforeman/foreman/blob/1.16-stable/config/application.rb#L245
)
but this one cannot be stopped or started without restarting Passenger too.



If we decide for releasing without that, we need to put the files back into
foreman tasks for 1.16:
I would definitely rather see this resolved properly. Anythink we can help
with?


Right now we have verified it works on EL7 and are working on Debian. 
When that works, we will merge it to nightly. IMHO it's up to Daniel to 
make the call if we want to backport it to 1.16 since he's the release 
manager.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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: Re: [foreman-dev] Re: 1.15.4 - 1.16 RC.1 - 1.17 status

[Ewoud Kohl van Wijngaarden]

On Tue, Nov 21, 2017 at 11:10:41AM +0200, Ohad Levy wrote:

On Tue, Nov 21, 2017 at 11:02 AM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:


On Sun, Nov 19, 2017 at 09:35:04PM +0100, Ewoud Kohl van Wijngaarden wrote:


On Sun, Nov 19, 2017 at 11:27:57AM +0200, Ohad Levy wrote:



Can anyone shed some light on ETA for 1.16 GA?


I should have given an update earlier.

So far we've been wanting to include the foreman tasks as a service from
core rather than from foreman-tasks. As always we want that change to first
land in develop but we've been struggling with broken nightlies for quite
some time. It loked like it was fixed since the builds started to pass
aagin but we have no validation on the actual UI. Turns out that's broken
and we have no automated testing for this.



After bumping some dependencies and fixing some koji issues I can now open
the UI and end up without javascript compilation errors in the console.
Haven't verified much more than clicking through various pages but this
will allow us to start focussing on the needed packaging changes (dynflow,
Rails 5.1).



great news, thanks :) just wondering, i assume we can now release 1.16
first (which imho is a higher prio dynflow, and rails 5.1?)


I agree it's higher prio, but I can't judge if the current release could 
be considered ready to release or if the dynflow change is halfway in 
the migration. I'll let Daniel and Ivan discuss that further while I 
work on getting dynflow in nightly.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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: Re: [foreman-dev] Re: 1.15.4 - 1.16 RC.1 - 1.17 status

[Ewoud Kohl van Wijngaarden]

On Sun, Nov 19, 2017 at 09:35:04PM +0100, Ewoud Kohl van Wijngaarden wrote:

On Sun, Nov 19, 2017 at 11:27:57AM +0200, Ohad Levy wrote:


Can anyone shed some light on ETA for 1.16 GA?



I should have given an update earlier.

So far we've been wanting to include the foreman tasks as a service 
from core rather than from foreman-tasks. As always we want that 
change to first land in develop but we've been struggling with broken 
nightlies for quite some time. It loked like it was fixed since the 
builds started to pass aagin but we have no validation on the actual 
UI. Turns out that's broken and we have no automated testing for this.


After bumping some dependencies and fixing some koji issues I can now 
open the UI and end up without javascript compilation errors in the 
console. Haven't verified much more than clicking through various pages 
but this will allow us to start focussing on the needed packaging 
changes (dynflow, Rails 5.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.

Re: Re: [foreman-dev] Re: 1.15.4 - 1.16 RC.1 - 1.17 status

[Ewoud Kohl van Wijngaarden]

On Sun, Nov 19, 2017 at 11:27:57AM +0200, Ohad Levy wrote:


Can anyone shed some light on ETA for 1.16 GA?



I should have given an update earlier.

So far we've been wanting to include the foreman tasks as a service from 
core rather than from foreman-tasks. As always we want that change to 
first land in develop but we've been struggling with broken nightlies 
for quite some time. It loked like it was fixed since the builds started 
to pass aagin but we have no validation on the actual UI. Turns out 
that's broken and we have no automated testing for this.


Would it be an option to ship 1.16 without dynflow service in the core 
or would that break things?


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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?

[Ewoud Kohl van Wijngaarden]

+1 the open issues need to be reviewed. I don't know if this is the best 
solution but can't hurt to get more eyes on them.


What I don't see is something to go over old issues that have been 
triaged at some point. I did that a while back for the installer and 
could close a few issues that had been fixed already or could be closed 
with WONTFIX.


On Tue, Nov 14, 2017 at 05:12:36PM -0500, Eric D Helms wrote:

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

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

[Ewoud Kohl van Wijngaarden]

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

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

[Ewoud Kohl van Wijngaarden]

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

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

[Ewoud Kohl van Wijngaarden]

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


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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] Plugin gems with a single author - redux

[Ewoud Kohl van Wijngaarden]

On Fri, Nov 10, 2017 at 02:02:10PM +, Greg Sutcliffe wrote:

To make this a more "official" policy, I've created a "Foreman" account
on Rubygems, and the user  can be added
to any gem we keep on our namespace. This should minimize any issues
when transferring gems to new owners.


For what it's worth: it'd be good if this was rubyg...@theforeman.org, 
even if it's still stored on gmail. That way you can easily change it as 
long as you own the domain.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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] Plugin gems with a single author - redux

[Ewoud Kohl van Wijngaarden]

On Fri, Nov 10, 2017 at 02:02:10PM +, Greg Sutcliffe wrote:

A few months ago we added a policy that required 2 gem authors per
plugin. We did, however struggle to actually get two authors on some
plugins.

To make this a more "official" policy, I've created a "Foreman" account
on Rubygems, and the user  can be added
to any gem we keep on our namespace. This should minimize any issues
when transferring gems to new owners.

The account has a recovery email of my RedHat address, which means it
can be recovered even if I get hit by a bus (because my superiors can
open it). I will also revive the discussion about sharing infra
passwords with appropriate security ;)

Unless anyone has any strong objections, I'll send a PR for review to
make adding this owner an official policy for our gems.


I like this. What are the opinions on deploying gems through Travis like 
voxpupuli does?


https://docs.travis-ci.com/user/deployment/rubygems/

tl;dr: on tags it can deploy the gem to rubygems. It standardizes the 
deploy process and you're sure that any gem has a tag and vice versa.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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

[Ewoud Kohl van Wijngaarden]

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.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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

[Ewoud Kohl van Wijngaarden]

On Thu, Nov 09, 2017 at 09:04:55AM -0500, Eric D Helms wrote:

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?


Sorry, that was a weird thing in my head: it's how we distribute the 
jenkins jobs. Besides the plain text files we also have some slave 
configs[1] and they're templated. I don't know if those should be moved 
too or translated into pure JJB files but it's part of how Jenkins is 
configured.


[1]: 
https://github.com/theforeman/foreman-infra/tree/master/puppet/modules/slave/templates


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?


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.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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

[Ewoud Kohl van Wijngaarden]

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.


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.



Eric

[1]
https://github.com/theforeman/foreman-infra/tree/master/puppet/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.

[foreman-dev] Status of the nightlies

[Ewoud Kohl van Wijngaarden]

Hello all,

tl;dr: nightlies are fixed, we're staying on top of them. report issues

As you might have picked up, the nightlies were a bit unstable and 
unreliable lately. The biggest problem was that core and packaging 
drifted apart. For now this has been synced up.


Now the challenge is to keep them synced up. For starters we introduced 
code owners[1]. The idea is that we have files for which we consider the 
packaging team the owner. They should be involved in any PR which 
changes these files so we can act on changes rather than seeing the 
nightlies fail. A compounding facter is that bundler does check 
dependencies where npm doesn't. With a (current) lack of tooling manual 
work must suffice.


This is currently not yet working since the packaging team doesn't have 
merge permissions and even then we don't know how well it'll work in 
practice. Time and experience will tell.


If you have a change that might affect packaging, feel free to ask 
@theforeman/packaging on github.


In the longer term we should develop tooling that can automatically 
point us to problems and help us respond faster to changes.


We've also talked about vendorizing NPM packages. While this is still 
planned, there are other high priority items (Foreman tasks to core, 
Rail 5.1) so no promises on the timeline. Until then we have our current 
solution that does work and we know how to handle.


[1] 
https://github.com/theforeman/foreman/commit/17501e48cea4f62ee23dc04dc7a153ce3b059278

--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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

[Ewoud Kohl van Wijngaarden]

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?


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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] Abandoned plugins under theforeman github org

[Ewoud Kohl van Wijngaarden]

+1 on just marking it in README and in the github description.

On Wed, Nov 08, 2017 at 12:07:43PM +0100, Ivan Necas wrote:

+1 of marking as unmaintained, but keeping around

-- Ivan

On Wed, Nov 8, 2017 at 12:04 PM, Timo Goebel  wrote:

... i would not remove it from the github org. There are even more abandoned 
plugins there. I would not delete the code, maybe somebody wants to start work 
on them again.

I would mark them as unmaintained in the repo description, remove the jenkins 
jobs and remove them from packaging.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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

[Ewoud Kohl van Wijngaarden]

+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  wrote:




On Thu, Nov 2, 2017 at 6:24 AM, Daniel Lobato Garcia 
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.

Re: [foreman-dev] Re: Foreman instrumenting analysis

[Ewoud Kohl van Wijngaarden]

Have you had a look at influxdb? While I have limited experience with 
it, it's push based which can have benefits. There's infludb-rails[1] 
which states:


Out of the box, you'll automatically get reporting of your controller, 
view, and db runtimes for each request.


That sounds a lot like what you're interested in.

[1]: https://github.com/influxdata/influxdb-rails

On Tue, Nov 07, 2017 at 10:49:56AM +0100, Lukas Zapletal wrote:

Any other ideas for telemetry protocols?

If there are none, I will rebase my telemetry patch back to the
original version based on statsd.

LZ

On Tue, Oct 31, 2017 at 8:33 PM, Lukas Zapletal  wrote:

Hello,

I am seeking for app instrumenting protocol for Foreman Rails
application that will fulfill the following requirements:

The protocol must work with multi-process server like Passneger.
The protocol can be easily integrated into Foreman Tasks and Smart Proxy.
The protocol or agent must support aggregation of time-based data
(quantiles, average).
The protocol must integrate with top three open-source monitoring frameworks.

Let me summarize my findings so far. I am looking for advice or
comments on this topic. I already worked on some prototypes, but
before I commit to some final solution, I want to be sure I will not
miss something I don't know about.

Before you send comments, please keep in mind I am not searching for
monitoring solution to integrate with. I want an application
instrumentation library (or protocol) to be able export measurements
(or telemetry data if you like) from Rails (like number or requests
processed, SQL queries, time spent in db or view, time spent rendering
a template or calling a backend system).


Prometheus


Flexible text-based protocol (alternatively protobuf) with HTTP
REST-like communication. It was designed to be pull-based, meaning
that an agent makes HTTP calls to web application which holds all
metrics until they are flushed. It was build for Prometheus monitoring
framework (Apache licenced) created by SoundCloud initially. Server
and most agents are written in Go, can run without external database
or export into 3rd party storage backends.


It looks great, but it has a major problem - the Ruby client library
(called client_ruby) does not support multi-process web servers at
all. There are some hacks but these are using local temp files or
shared memory with rather bad benchmark results (see the links down
below).


There is a possibility to push metrics into a separate component
called PushGateway, but this was created for things like cron jobs or
rake tasks. Doing multiple HTTP requests for each metric per single
app request will unlikely perform well. In the README authors have
note that this should be considered as "temporary solution".


Although Prometheus seems to have vibrant community, the Ruby library
development pace slowed down as SoundCloud "does not use many Ruby
apps anymore". But it is still a good option to have.


https://prometheus.io
https://prometheus.io/docs/instrumenting/pushing/
https://github.com/prometheus/client_ruby
https://github.com/prometheus/client_ruby/issues/9
https://github.com/prometheus/client_ruby/commits/multiprocess


OpenTSDB


OpenTSDB consists of a Time Series Daemon (TSD) as well as set of
command line utilities. Interaction with OpenTSDB is primarily
achieved by running one or more of the TSDs. Each TSD is independent.
There is no master, no shared state so you can run as many TSDs as
required to handle any load you throw at it. Each TSD uses the open
source database Hadoop/HBase or hosted Google Bigtable service to
store and retrieve time-series data.


It uses push mechanism via REST JSON API with alternative
"telnet-like" text endpoint. Although it does have some agents, it is
more used as a storage backend than end-to-end monitoring solution.


http://opentsdb.net/overview.html


Statsd


Main idea behind this instrumentation protocol is simple - get the
measurement out of the application as fast as possible using UDP
datagram. A collector agent usually runs locally, it does aggregation
and relays the measurements to target backend system. The vanilla
version does not support tagging, but there are extensions or mappings
possible to support that.


Almost all monitoring platforms has some kind of
agent/importer/exporter that talks via statsd. The original statsd
daemon was written in Perl years ago, then it was re-popularized by
node.js implementation, but there are many alternative agents from
which the most promising is statsite with very easy extensibility.


This protocol is my favourite because it plays well with multiprocess
Ruby servers or other Foreman components (all can just send UDP
packets to localhost) and it also 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 

Re: [foreman-dev] speeding up tests

[Ewoud Kohl van Wijngaarden]

On Tue, Nov 07, 2017 at 08:34:45AM -0500, Eric D Helms wrote:

So many items to unpack here that I am going to attempt to break my
response into categorizations. If I miss a key point, please point it out
so I can follow up addressing it.


There's a lot of good thoughts in your mail. I'm just going to jump on 
one of them.



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.


For Debian we try to support the latest supported version and we skip 
their LTS support. This allows us to to focus on usually 1 version. We 
already decided to drop Jessie for 1.17 so that can be dropped from the 
matrix.


For Ubuntu we currently have two LTS versions (14.04 Trusty and 16.04 
Xenial) but I'm unsure about the Trusty support. I wouldn't mind 
dropping it so we can focus on the latest LTS only.


If we limit to Debian Stretch and Ubuntu Xenial then we only need to 
test on Ruby 2.3. For EL7 we need to choose a new version to base on. 
While we could pick 2.3 so all major supported packaging is on the same 
Ruby version, I think we should continue testing on Ruby 2.4 anyway.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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

[Ewoud Kohl van Wijngaarden]

+1

On Mon, Nov 06, 2017 at 08:20:26AM -0500, 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. 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  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 
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


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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

[Ewoud Kohl van Wijngaarden]

My views do align with Martin here: email does feel like a second class 
citizen. Sending email does work properly (likely because they could 
just use the github parser gem) but what it sends out is ... barely 
enough.


On the other hand (and this has been pointed out by other people), it 
might be much better for users. Given that foreman-dev is not a very 
high activity mailing list (which I like, good signal/noise ratio) I 
think it can be a good trade-off for better user interaction. While we 
could consider splitting into a discourse for -users and a mailing list 
for -dev, IMHO the downsides of that a much bigger than the upsides.


Right now we have done an experiment and with these initial findings I 
think we can approach the Discourse community to ask them what their 
views are. Perhaps we can work together to improve it (yay open source).


To state what's perhaps obvious: we're never going to find a perfect 
solution that makes everybody happy. We should strive to find a local 
maximum that makes most people happy / the least people unhappy. For 
-dev we can ask the devs since that's a pretty consistent group and we 
know most. That's not true for -users since they might be unhappy now 
but not tell us. I'm willing to trust others that it's the better 
choice even if I see some downsides for me personally.


On Sun, Nov 05, 2017 at 07:51:45PM +0100, Martin Bačovský wrote:

For monitoring of what is going on on the foreman-dev/users I prefer to
consume it as a mailing list. It is lightweight and efficient and fits well
to my mail-centric workflow. I understand the benefits of the forum so I
gave Discourse a try to see how it works and if its mailing-list mode
promises smooth transition.

Things I like:
- searching during new post compose
- existence of "groups"
- likes (even work when sent via mail)
- rich-text messages, syntax highlighting, markdown
- easy to share links to individual posts

Things I didn't like (I guess some are likely interference with the Gmail
client and some can be tuned up):
- for some reason the threads are not kept together in my Gmail and the
messages from one thread are split into multiple threads even if they seem
to have same subject. I'm not sure why, it may be because I tuned the
account settings. I'll keep testing this
- it took about 15 min since I sent mail to the time I received it from
the list (not sure what are the reaction times on the list today but this
won't improve it)
- mails from Discourse take too much visual space - the footer saying how
to unsubscribe, reply or visit the topic  is included in each message.
First post should be enough. There is also extra username with avatar and
forum role next to User name in the From field. Is this configurable?
- "likes" are only indicated in forum notifications but not in emails. If
you send '+1' to the list the like is added but no message is sent to the
users (just the notification)

So far for me it is difficult to follow the Discourse discussion using just
Gmail. For further testing I'd like to see more traffic in the Testing
area. I'd also appreciate experience with mailing-list mode testing form
others.

M.



On Fri, Nov 3, 2017 at 7:29 PM, Lukas Zapletal  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 
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 

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

[Ewoud Kohl van Wijngaarden]

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.


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.

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

[Ewoud Kohl van Wijngaarden]

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.

Re: [foreman-dev] Building a Rails 5.1 SCL

[Ewoud Kohl van Wijngaarden]

On Thu, Nov 02, 2017 at 11:24:26AM +0100, Daniel Lobato Garcia wrote:

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


My expectation is that vendorizing RPMs would cost a similar time as 
building the SCL. Given separate packaging has a lot of benefits over 
bundling[1].


Thinking about this, we currently don't check the licenses of bundled 
npm modules in our existing packaging. It's possible we currently ship 
something we're not legally allowed to ship but we simply don't know.o


With regards to EL8 I think you're hinting at the modularization effort 
that's currently in Fedora. For those unaware: it's aimed to be a much 
better version of SCLs. Better integrated in the system but also allow 
easily producing containers. At the moment there's still little 
documentation and we'll likely support EL7 for a while so at this point 
I'm not planning much. What we do want to do is move from our own Koji 
instance to COPR. That should be prepared for modularization. Developing 
the SCL in COPR can be seen as a first step in this process.


[1]: 
https://fedoraproject.org/wiki/Bundled_Libraries?rd=Packaging:Bundled_Libraries#Why_Bundled_Libraries_are_a_problem


Parallel to this effort, do you think it’s worth moving forward with the
vendorization of npm so that gems can follow suit?


Personally I'd say gems shouldn't follow suit unless maintaining the SCL 
proves too much work. In fact, the only reason I currently accept npm 
vendorization is that we currently can't keep up with the changes. If we 
can develop sufficient tooling I'd actually like to roll back npm 
vendorization too when we can provide the same developer flexibility.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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

[Ewoud Kohl van Wijngaarden]

+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
,
and here are all the PRs he has helped to review

.

On Mon, Oct 30, 2017 at 11:34 AM, Matthias Dellweg  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.

Re: [foreman-dev] Koji Outage

[Ewoud Kohl van Wijngaarden]

Turns out it was started in a new security group which didn't allow 
rsync. lzap fixed that now.


On Sat, Oct 28, 2017 at 08:09:39PM +0200, Ewoud Kohl van Wijngaarden wrote:
It looks like the rsync service isn't started causing our promotion 
pipeline to fail. Could you have a look?


On Thu, Oct 26, 2017 at 03:31:28PM +0200, Lukas Zapletal wrote:

Here is an update. Restart did not help, we stopped the instance and I
am following this guide to create new AMI and start it:

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html

Image which is now pending completion is called ami-2ecd6b54 and it
has both root EBS volume and data EBS volume (900 GB) which is the
reason why this is so slow. Then we can start new AMI to see if it
boots up. The instance type was i3.xlarge for the record, we want the
same one which was the best performance/price ratio for Koji workload.

After new koji boots up we want to recreate /mnt/tmp folder structure
and swap. Open /mnt/fstab to see the mountpoints, the i3.xlarge has
like 950 GB ephemeral storage, but it was unused (we had 400 GB swap
and 400 GB /mnt/tmp). In the /mnt/tmp directory there was just few
directories where koji was doing building locally. More CPU intensive
flavours were more expensive so we had this IO intensive one instead
which stills delivers 4 cores and 32 GB RAM which is good.

On the main EBS volume (900 GB one) there is a backup directory and in
this directory we should have a backup of the directory structure.
There is a cron job that does this daily. It was not backing up
temporary files, just directories. This should be enough to get koji
daemons back online. There should be a daily backup of postgre
database as well.

The EBS volume snapshot is ongoing, it is required to do snapshot
first and then you can create new AMI from it. I have some family
business in an hour, so I am writing this summary so someone else form
US timezone can carry on from here. Next step would be - start new
instance, let it boot (there might be ext4 file system check - not
sure if we use XFS or ext4 for the data volume - see the AMI console
for boot) and then find the /mnt/tmp backups, restore the directory
structure, restart (rather whole system than just koji) and it should
show up. Last thing would be to associate the elastic IP.



On Thu, Oct 26, 2017 at 2:56 PM, Lukas Zapletal <l...@redhat.com> wrote:

Likely a hardware failure according to notification, our instance is
not responding. We are trying restart first.

***

EC2 has detected degradation of the underlying hardware hosting your
Amazon EC2 instance associated with this event in the us-east-1
region. Due to this degradation, your instance could already be
unreachable. After 2017-10-30 00:00 UTC your instance, which has an
EBS volume as the root device, will be stopped.

You can see more information on your instances that are scheduled for
retirement in the AWS Management Console
(https://console.aws.amazon.com/ec2/v2/home?region=us-east-1#Events)

* How does this affect you?
Your instance's root device is an EBS volume and the instance will be
stopped after the specified retirement date. You can start it again at
any time. Note that if you have EC2 instance store volumes attached to
the instance, any data on these volumes will be lost when the instance
is stopped or terminated as these volumes are physically attached to
the host computer

* What do you need to do?
You may still be able to access the instance. We recommend that you
replace the instance by creating an AMI of your instance and launch a
new instance from the AMI. For more information please see Amazon
Machine Images (http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html)
in the EC2 User Guide. In case of difficulties stopping your
EBS-backed instance, please see the Instance FAQ
(http://aws.amazon.com/instance-help/#ebs-stuck-stopping).

* Why retirement?
AWS may schedule instances for retirement in cases where there is an
unrecoverable issue with the underlying hardware. For more information
about scheduled retirement events please see the EC2 user guide
(http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-retirement.html).
To avoid single points of failure within critical applications, please
refer to our architecture center for more information on implementing
fault-tolerant architectures: http://aws.amazon.com/architecture

LZ

On Thu, Oct 26, 2017 at 1:51 PM, Eric D Helms <ericdhe...@gmail.com> wrote:

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 unsub

Re: [foreman-dev] Vendorizing or Building RPMs

[Ewoud Kohl van Wijngaarden]

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.

Re: [foreman-dev] Merge rights to Katello installer

[Ewoud Kohl van Wijngaarden]

On Thu, Oct 26, 2017 at 10:39:28AM +0100, Sean O'Keeffe wrote:

I'd like to request write access to the installer team.


+1 Sean has shown insight in the modules and the overall picture. His 
PRs are consistently of a high quality.



I've been involved with 38 PRs across what I'd consider to be the 'main'
repos, apparently I created 15 of them and I guess I reviewed the rest.

https://github.com/Katello/puppet-katello/pulls?q=is%3Apr%20involves%3Asean797%20
https://github.com/Katello/katello-installer/pulls?utf8=%E2%9C%93=is%3Apr%20involves%3Asean797
https://github.com/Katello/puppet-certs/pulls?utf8=%E2%9C%93=is%3Apr%20involves%3Asean797%20
https://github.com/Katello/puppet-candlepin/pulls?utf8=%E2%9C%93=is%3Apr%20involves%3Asean797%20
https://github.com/Katello/puppet-foreman_proxy_content/pulls?utf8=%E2%9C%93=is%3Apr%20involves%3Asean797
https://github.com/Katello/puppet-pulp/pulls?utf8=%E2%9C%93=is%3Apr%20involves%3Asean797%20
https://github.com/Katello/puppet-qpid/pulls?utf8=%E2%9C%93=is%3Apr%20involves%3Asean797


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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] Issue with foreman tests

[Ewoud Kohl van Wijngaarden]

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/b275d94f88e2a60306a13154a7727e638bb4a874
[2]: https://projects.theforeman.org/issues/21431
[3]: 
https://github.com/theforeman/foreman-infra/commit/5099902d71e79ce7a0b2ec80239d942b92373ecf

--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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 RC2 preparation

[Ewoud Kohl van Wijngaarden]

puppet-puppet 8.0.3 included a fix for that and RC2 should include that 
fix. So when I said 'prepare the installer side' was get everything in 
place so we can do a release. That'll mean tagging and building 
packages.


On Mon, Oct 23, 2017 at 02:29:41PM +0200, Roger Martensson wrote:

There seems to be a problem with Puppet 5 with the Foreman-installer.
https://github.com/theforeman/puppet-puppet/issues/549

It seems to be merged in master:
https://github.com/theforeman/puppet-puppet/pull/548/files

Doesn't seem to be installed in 1.16RC.
Would love to see installed in 1.16.

2017-10-23 13:55 GMT+02:00 Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl>:


On Thu, Oct 12, 2017 at 05:42:19PM +0200, Ewoud Kohl van Wijngaarden wrote:


While Daniel is on PTO I'd like to take over the 1.16 RC2 preparation.
From the installer side I can handle it, but will need help from a core
maintainer and a proxy maintainer to tag releases.



We did prepare the installer side, but had too little time to prepare
actual releases and test them. We'll work on getting it out soon.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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 RC2 preparation

[Ewoud Kohl van Wijngaarden]

On Thu, Oct 12, 2017 at 05:42:19PM +0200, Ewoud Kohl van Wijngaarden wrote:
While Daniel is on PTO I'd like to take over the 1.16 RC2 preparation. 
From the installer side I can handle it, but will need help from a 
core maintainer and a proxy maintainer to tag releases.


We did prepare the installer side, but had too little time to prepare 
actual releases and test them. We'll work on getting it out soon.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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

[Ewoud Kohl van Wijngaarden]

On Fri, Oct 20, 2017 at 04:59:33PM -0400, 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


Sounds like a good idea

--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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

[Ewoud Kohl van Wijngaarden]

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.

Re: [foreman-dev] Current State of Nightlies

[Ewoud Kohl van Wijngaarden]

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.

Re: [foreman-dev] Sharing and idea: VMWare VIX instead of DHCP for vCenter VM's provisioning

[Ewoud Kohl van Wijngaarden]

On Mon, Oct 16, 2017 at 11:39:56AM -0700, Evgeny Vasilchenko wrote:

I'd like to share an idea for provisioning of VMware guest VM's with
Foreman.

The idea required programming new type of Foreman proxy - unfortunately, I
neither have time or enough skills for that.

*The goal:*

  - Allow configuration of Linux (and maybe Windows) VM network interfaces
  with VMWare VIX's API 
  instead of DHCP

*Facts:*

  - VMWare offers a free VM management API called *VIX*
  - https://blogs.vmware.com/vix/2008/07/what-is-vix-and.html
 - *VIX is an API that lets you programmatically control the products
 that host VMware VMs, and control the VMs themselves.*
- it works with many VMWare products including vCenter
 -
- VIX package can be installed on both

*Linux and Windows *
  - VIX has a wrapper utility called *vmrun*
  (https://www.vmware.com/support/developer/vix-api/vix112_vmrun_command.pdf)
  which offers a CLI for controlling VM's running - e.g. starting, stopping,
  pausing, deleting, etc...

  - vmrun can be installed on a *Foreman Smart-Proxy* (AKA Sat6 capsule)
  *host* and
 - run any command or script *INSIDE* of a guest VM running on a
 vCenter computing resource - i

*.e. it can configure whatever, including network interfaces. *
  - in order to run something inside of VM - vmrun only need to
  know (beside of vCenter credentials of course)
  - *path to .VMX file* (already known after VM provisioning)
   - guest OS username (i.e. root, administrator) and password
- command line or script name to be executed

In fact VIX API and vmrun can do way more that this - I feel it simply must
be integrated into Foreman Proxy.
I've been using it for various VCenter related automation tasks and like
it's versatility and power.

Any ideas?


Would a VMware VIX backend to Remote Execution be feasable and useful?

--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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

[Ewoud Kohl van Wijngaarden]

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.

Re: [foreman-dev] Found In Version Katello Redmine custom field

[Ewoud Kohl van Wijngaarden]

https://projects.theforeman.org/projects/foreman/issues/new has this, 
but I'm not sure we can rename the Release field since it's part of the 
Redmine Backlogs plugin though my memory is fuzzy here. I think someone 
with admin rights on Redmine can say more about the practicalities but 
the idea makes a lot of sense to me.


On Mon, Oct 16, 2017 at 01:38:18PM -0400, John Mitsch wrote:

+1

If we do this, we should clarify that the current "version" field is used
for releases by calling it "target version" or something similar.

John Mitsch
Red Hat Engineering
(860)-967-7285
irc: jomitsch

On Mon, Oct 16, 2017 at 10:18 AM, Andrew Kofink  wrote:


RFC:

Because Katello is a nested project under Foreman in Redmine, we can only
see Foreman versions in the "version" field. It would be great to have a
custom text box field "Found In Version" that bug reporters can provide the
exact RPM they installed to see the issue.

Let me know if you would find this useful.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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] Redmine available over HTTPS

[Ewoud Kohl van Wijngaarden]

Hello all,

Long overdue, but we now have https://projects.theforeman.org available. 
For now we have no redirects or change defaults. Please start testing it 
while we look for places that need to update to new URLs. If you have 
any scripts, please change them too.


If you have any issues, please let us know.

--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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] Availablity of yum.theforeman.org

[Ewoud Kohl van Wijngaarden]

On Fri, Oct 13, 2017 at 05:35:45AM -0700, Dirk Götz wrote:

http://yum.theforeman.org/ is showing the Debian apache default package and
a colleague and I having both problems with timeouts and package
availablitiy during installation in two different environments.
Is there some work going on or do we have the same resource problems like
with redmine?


Thanks for the report. It looks like a yum update httpd restored 
welcome.conf which shows the welcome page rather than a directory 
listing like we want. Luckily it only affected the index and not the 
actual files so yum could still update.


I don't see why we would have timeout but I can't investigate that 
because I don't have access to any monitoring.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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] Redmine running slowly

[Ewoud Kohl van Wijngaarden]

On Thu, Oct 12, 2017 at 11:50:55AM +0100, Greg Sutcliffe wrote:

And we're back. Please test extensively and report issues ;)

In particular, we're now on Ruby 2.0 (up from 1.9 on Openshift) so I
suspect the plugins might have issues. Any issues, please report them
here and we'll take a look. I checked quickly and didn't see any
errors, but I was in a hurry :P

Things still to do:

* Add logrotate for the production.log files
* Add HTTPS (ewoud is on that)
* Upgrade to latest Redmine (I'm looking into it)
* Puppetize it so we can migrate more easily in future

We'll monitor to see if the resources are enough, let me know if you
see any issues (no, Backlogs does not count, that thing is *slow* :P)


We did have to do some changes to the importing of git repos. If you 
merge an issue with a keyword (refs or fixes) and it doesn't update the 
issue in an hour then please let us know.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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] Jenkins over HTTPS

[Ewoud Kohl van Wijngaarden]

Hello all,

We now have https://ci.theforeman.org/ but there's no redirect yet. I'd 
like to ask you to start testing - especially if you log in.


The next step is to replace all URLs we have to HTTPS and set up a 
redirect.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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] Redmine running slowly

[Ewoud Kohl van Wijngaarden]

On Wed, Oct 11, 2017 at 07:36:39PM +0300, Ohad Levy wrote:

On Oct 11, 2017 5:40 PM, "Greg Sutcliffe"  wrote:

Update on migration:

http://51.15.192.166 is now live for your testing pleasure, with a copy


Any chance to update/enable https in the process?


That is the plan, but first we want to know it's working. If you can 
create DNS records we can already test the process with letsencrypt:


redmine01.theforeman.org A 51.15.192.166
redmine01.theforeman.org  2001:bc8:4400:2300::5:e03


Thanks!

of the DB from a few days ago. Email is currently disabled, so you
can't spam anyone. There's still a few small tasks to sort out that
will keep me busy, but if you want to see if you can break it, go
ahead.

Sadly, SMTP outbound is blocked by default on Scaleway, which I didn't
realise until about 20 mins ago. I've raised a ticket to lift this so
Redmine can send email, but until that's resolved we can't complete the
migration.

Once email is confirmed working, we'll schedule a maintenance window,
where I will stop the Openshift instance and make a final DB dump. Ohad
will then do a DNS switch, and as soon as it comes back you should all
be good to go.

Stay tuned for further updates. I'll announce the maintenance window
before I start.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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] Redmine running slowly

[Ewoud Kohl van Wijngaarden]

We deployed a new version but that took longer than expected. Now we use 
bare git clones rather than doing full checkouts. This should save a lot 
of IO which is generally a limiting factor. Hopefully this helps enough 
until we can migrate to the new platform.


https://github.com/theforeman/redmine/commit/cb4ccf049e0c892fcbba98861c904492e9833a67

On Tue, Oct 10, 2017 at 10:50:24AM -0400, Andrew Kofink wrote:

Me as well. It's quite difficult to work this way.

On Tue, Oct 10, 2017 at 10:40 AM, Dirk Götz  wrote:


Now Redmine seems to be down completely. Only getting 404 or 502 errors
since an half hour.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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] Proposed drop of supporting ruby 2.0 in hammer

[Ewoud Kohl van Wijngaarden]

On Tue, Oct 10, 2017 at 01:21:36PM +0200, Tomas Strachota wrote:

Hi all,
we recently encountered a compatibility issue with older version of
Clamp that we use on ruby 2.0 installations. Latest Clamp releases
require ruby 2.1+. See [1] for some more details.

The easiest solution seems to be dropping ruby 2.0 support, which was
eol 2016-02-24 anyway. We use scl with ruby 2.2 on rpm based distros,
so we should be safe there.

The question is how big deal it would be for Debian based distros. I
checked ruby versions on what we currently support:
- Debian Jessie - ruby 2.1 (https://packages.debian.org/jessie/ruby)
- Debian Stretch - ruby 2.3 (https://packages.debian.org/stretch/ruby)
- Ubuntu Trusty - ruby 1.9 (https://packages.ubuntu.com/trusty/ruby)
but we depend on a package ruby2.0
- Ubuntu Xenial - ruby 2.3 (https://packages.ubuntu.com/xenial/ruby)

So the only issue seems to be with Trusty, where we could bump the
dependency to ruby2.3.

What do you think, are there any objections against dropping it?


Support for Trusty has been dropped in 1.16 and 1.17 will drop Jessie. 
Focussing on 2.1+ or 2.2+ should be no problem.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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 UX nitpick - Sync Status

[Ewoud Kohl van Wijngaarden]

Given 3.4 has been released I think that renaming a menu item is not in 
order. Patch releases should fix bugs, not introduce enhancements.


On Mon, Oct 09, 2017 at 05:13:58PM +0200, Lukas Zapletal wrote:

While I have no issues with redesigning things for better UX, I was
hoping for some suggestion (a rename perhaps) that could go into
Katello 3.4. I hit the wrong page every second day, I was wondering if
this is just me or other people also hit Sync Plans instead Sync
Status :-)

On Fri, Oct 6, 2017 at 6:53 PM, Walden Raines  wrote:

If we had a 'repositories' page where we could just list repos across the
organization, that would likely be a better place to show this information
(and allow the user to filter to see only what are currently syncing).


Sorry, I didn't articulate my idea very well.  It would basically be
renaming the products page to "Repositories" and making that page a list of
repositories rather than products.  Perhaps they repositories are grouped
into products, perhaps not.  Whether or not the concept of a "product" is
actually useful is something that interviews with users can determine.


If we were going to just yank the sync status page, i think we would need
to do some user interviews and confirm that the products page and dashboard
widgets  fulfill their needs.


For sure, and I wouldn't just yank it out (as much as I'd like to) but I do
see an opportunity to remove a page by combining its functionality into
another.  This is a trend that I would like to continue going forward as I
believe our current nearly 1-to-1 mapping of pages to database relations
isn't very user friendly.  You almost have to know how the application is
designed in order to use it effectively.  I would much rather see an "action
based" approach to our pages where the page in the UI is a representation of
something you want to do rather than something that exists (if that makes
sense at all).

Cheers,
Walden

On Fri, Oct 6, 2017 at 11:31 AM, Justin Sherrill 
wrote:




On 10/06/2017 11:16 AM, Walden Raines wrote:

Hey,

As part of my campaign to reduce the number of menu items I would love to
remove the sync status page entirely.

As far as I know the sync status page doesn't really provide any
additional functionality over the products page with the exception of being
able to select individual repositories from diverse products to sync (i.e.
the products page bulk sync forces you to sync all of the repositories in
each product).  I think we could add this to the products page pretty
easily.

There is also a dashboard widget that shows sync status if you use the
sync status page just to look at the status of your syncs.

So really what is the purpose of the sync status page?

I believe it was so you could get a better overview of what repositories
were syncing.  I think the sync status dashboard widget is not currently
well suited for that.

If we had a 'repositories' page where we could just list repos across the
organization, that would likely be a better place to show this information
(and allow the user to filter to see only what are currently syncing).

If we were going to just yank the sync status page, i think we would need
to do some user interviews and confirm that the products page and dashboard
widgets  fulfill their needs.

-Justin



Cheers,
Walden

On Fri, Oct 6, 2017 at 10:58 AM, Sean O'Keeffe 
wrote:


“Sync Plans” -> “Planned Sync’s” ?

On Fri, 6 Oct 2017 at 15:56, Lukas Zapletal  wrote:


Hey,

I constantly keep mis-clicking on Sync Plans instead Sync Status in
Katello.

Any UX advice how to change that? I suggest either rename one to be
more visible so you can easily target that with mouse or break these
two guys into different main menu entries.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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: Re: [foreman-dev] unscheduled 1.15.5

[Ewoud Kohl van Wijngaarden]

It looks like #19986 was fixed in puppetserver 2.8.0 and GH-249 was 
merged so from the installers side I think we're good to go.


On Wed, Oct 04, 2017 at 05:34:51PM +0200, Ewoud Kohl van Wijngaarden wrote:
These are now released and the PR[1] is open to bump the versions. 
Note that I want to implement a workaround for #19986[2] and backport 
that to 1.15.5 as well.


[1]: https://github.com/theforeman/foreman-installer/pull/249
[2]: http://projects.theforeman.org/issues/19986

On Tue, Oct 03, 2017 at 12:38:55PM +0200, Ewoud Kohl van Wijngaarden wrote:

That's only part of it. These are still open:

Fix issues on EL7.4:
* https://github.com/theforeman/puppet-foreman_proxy/pull/376
* https://github.com/theforeman/puppet-foreman_proxy/pull/377

Fix OpenSCAP on Puppet 4 systems:
* https://github.com/theforeman/puppet-puppet/pull/554

Once those are merged I'll create releases and update the installer. 
These also fix issues downstream.


On Tue, Oct 03, 2017 at 12:26:07PM +0200, Daniel Lobato Garcia wrote:

Similarly I think the installer is meant to be updated to work with 7.4
- 
https://github.com/theforeman/foreman-installer/commit/f07567ee06742155a079f076823c6a3bfbc38120

On 10/03, Lukas Zapletal wrote:

Ondra,

what fixes are you talking about? Is this the container selinux
installation issue?

If there is a chance of sneaking in

https://github.com/theforeman/foreman/pull/4555

if this is merged in the deadline, that would be great. Pretty
important provisioning DHCP issue there.

LZ

On Tue, Oct 3, 2017 at 10:35 AM, Ondrej Prazak <opra...@redhat.com> wrote:

Hi,
there will be a 1.15.5 Foreman release. Main motivation behind this is to
get SELinux fixes into 1.15, but if you are aware of any critical fix that
should go in there, let me know.

Have a nice day,
Ondrej Prazak


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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 katello-packaging

[Ewoud Kohl van Wijngaarden]

Was this ever implemented?

On Fri, Sep 22, 2017 at 08:40:20PM -0400, Eric D Helms wrote:

+1 from me as well

On Fri, Sep 22, 2017 at 3:57 AM, Lukas Zapletal  wrote:


+1 thanks for all the help there.

On Thu, Sep 21, 2017 at 6:47 PM, John Mitsch  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 
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.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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: Re: [foreman-dev] unscheduled 1.15.5

[Ewoud Kohl van Wijngaarden]

These are now released and the PR[1] is open to bump the versions. Note 
that I want to implement a workaround for #19986[2] and backport that to 
1.15.5 as well.


[1]: https://github.com/theforeman/foreman-installer/pull/249
[2]: http://projects.theforeman.org/issues/19986

On Tue, Oct 03, 2017 at 12:38:55PM +0200, Ewoud Kohl van Wijngaarden wrote:

That's only part of it. These are still open:

Fix issues on EL7.4:
* https://github.com/theforeman/puppet-foreman_proxy/pull/376
* https://github.com/theforeman/puppet-foreman_proxy/pull/377

Fix OpenSCAP on Puppet 4 systems:
* https://github.com/theforeman/puppet-puppet/pull/554

Once those are merged I'll create releases and update the installer. 
These also fix issues downstream.


On Tue, Oct 03, 2017 at 12:26:07PM +0200, Daniel Lobato Garcia wrote:

Similarly I think the installer is meant to be updated to work with 7.4
- 
https://github.com/theforeman/foreman-installer/commit/f07567ee06742155a079f076823c6a3bfbc38120

On 10/03, Lukas Zapletal wrote:

Ondra,

what fixes are you talking about? Is this the container selinux
installation issue?

If there is a chance of sneaking in

https://github.com/theforeman/foreman/pull/4555

if this is merged in the deadline, that would be great. Pretty
important provisioning DHCP issue there.

LZ

On Tue, Oct 3, 2017 at 10:35 AM, Ondrej Prazak <opra...@redhat.com> wrote:

Hi,
there will be a 1.15.5 Foreman release. Main motivation behind this is to
get SELinux fixes into 1.15, but if you are aware of any critical fix that
should go in there, let me know.

Have a nice day,
Ondrej Prazak


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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] Access to foreman-infra

[Ewoud Kohl van Wijngaarden]

On Wed, Oct 04, 2017 at 10:18:12AM +0100, Greg Sutcliffe wrote:

On Mon, 2017-09-25 at 14:01 +0200, Ewoud Kohl van Wijngaarden wrote:

Hello all,

To get more involved in foreman infra I'd like to request push access
to foreman-infra. At first I'd like to help more with the CI.


That's over a week, no concerns - welcome to the infra team Ewoud :)


Thank you all :)

--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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: Re: [foreman-dev] unscheduled 1.15.5

[Ewoud Kohl van Wijngaarden]

That's only part of it. These are still open:

Fix issues on EL7.4:
* https://github.com/theforeman/puppet-foreman_proxy/pull/376
* https://github.com/theforeman/puppet-foreman_proxy/pull/377

Fix OpenSCAP on Puppet 4 systems:
* https://github.com/theforeman/puppet-puppet/pull/554

Once those are merged I'll create releases and update the installer. 
These also fix issues downstream.


On Tue, Oct 03, 2017 at 12:26:07PM +0200, Daniel Lobato Garcia wrote:

Similarly I think the installer is meant to be updated to work with 7.4
- 
https://github.com/theforeman/foreman-installer/commit/f07567ee06742155a079f076823c6a3bfbc38120

On 10/03, Lukas Zapletal wrote:

Ondra,

what fixes are you talking about? Is this the container selinux
installation issue?

If there is a chance of sneaking in

https://github.com/theforeman/foreman/pull/4555

if this is merged in the deadline, that would be great. Pretty
important provisioning DHCP issue there.

LZ

On Tue, Oct 3, 2017 at 10:35 AM, Ondrej Prazak  wrote:
> Hi,
> there will be a 1.15.5 Foreman release. Main motivation behind this is to
> get SELinux fixes into 1.15, but if you are aware of any critical fix that
> should go in there, let me know.
>
> Have a nice day,
> Ondrej Prazak


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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

[Ewoud Kohl van Wijngaarden]

+1 on not doing a release just for the sake of it. Sometimes it's needed 
but most of the time it's not. See the differences between 1.15.0 and 
1.15.4:


https://github.com/theforeman/foreman-installer/compare/1.15.0...1.15.4

On Thu, Sep 28, 2017 at 07:57:34PM -0400, Eric D Helms wrote:

Related to Dmitri's point, and I've thrown this question out with Katello
releases at least every other release, do all the components that are
currently released "together" need to be so these days? That is to say, can
any of the "versioned together components" be released more independently
but within the version stream? For example, say we are approaching 1.17
release, that is a good time to cut puppet releases, installer and
potentially smart proxy but do they need to be released together? Does
Foreman 1.17.1 necessitate a 1.17.1 installer? Or reverse it, does an
installer update have to wait on a Foreman 1.17.1 release?

Katello used to do this practice with a lot of repositories (e.g.
katello-agent, katello-selinux) and were at times releasing projects "just
because" without any real changes. After moving away from that, to let
katello-agent, katello-selinux and hammer-cli-katello more independently
release the process got a lot simpler. Further, I'd argue that each project
got a bit more focused and more thought put into maintenance and release.

Food for thought and discussion.

E


On Thu, Sep 28, 2017 at 2:29 PM, Dmitri Dolguikh <witlessb...@gmail.com>
wrote:


Why not distribute the release process? Each component can have (probably
already does) multiple maintainers who are capable of doing most of the
leg-work. The role of the release nanny then becomes coordinating the
effort, making public announcements and such. Such an approach would help
avoid overly broad permissions too.

-d

On Thu, Sep 28, 2017 at 3:23 AM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:


To release a gem to rubygems I'd recommend looking at how voxpupuli
implemented this using Travis[1]. The same can be done for puppet[2]. That
means you can push a tag to git and the release is there.

There are also tools that help you bump. For puppet there is
puppet-blacksmith[3]. How to do annotated tags is in my notes[3]. A more
generic script is bump2version[5] and I'm sure there are similar tools in
the ruby world.

IMHO these tools should be suggested in the plugin templates.

[1]: https://github.com/voxpupuli/modulesync/blob/e53079030501756
fc4111511fb9b6a239ffcb2a3/.travis.yml#L18-L27
[2]: https://github.com/voxpupuli/puppet-nginx/blob/fc363114e509f
439b51ea22723a996ffca8a107d/.travis.yml#L48-L58
[3]: https://github.com/voxpupuli/puppet-blacksmith
[4]: http://pad-katello.rhcloud.com/p/releasing-modules
[5]: https://github.com/c4urself/bump2version

On Wed, Sep 27, 2017 at 08:08:46AM -0700, Daniel Lobato wrote:


For foreman-docker I had a process:

https://github.com/theforeman/foreman-docker/blob/master/rel
ease/RELEASE.md
https://github.com/theforeman/foreman-docker/blob/master/rel
ease/rollout-release

which I planned to implement in all theforeman org plugins ideally.
It didn't happen but it's a similar thing.

On Wednesday, September 27, 2017 at 4:56:51 PM UTC+2, Timo Goebel wrote:



... isn‘t continuous delivery old these days? Why aren‘t we doing it?
I vote in favor of automating this. This ensures predictable results and
hopefully makes this process easier. To be honest: The current process
scares me.
Same for plugin releases. They also are way too manual right now.

Timo

> On 27. Sep 2017, at 16:46, Daniel Lobato Garcia <elob...@gmail.com

> wrote:
>
> Hi devs,
>
> After a few releases, and now that I'm trying to help someone else to
> take over in case it's needed, I found a roadblock.
>
> Whoever is doing the release, needs to have **many** permissions.
>
> Otherwise, it doesn't make much sense for a person to take over
release
> responsibilities. For example, if Ondrej has to do 1.15.5, he would
need
> the following permissions (see at the end of the email).
>
> Of course there are alternatives:
>
> 1 is to have the release nanny be supervised by people who have
'earned'
> these permissions. This is a bad idea because some of the tasks just
> cannot be 'supervised'. The nanny would 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 t

Re: [foreman-dev] Release process & permissions

[Ewoud Kohl van Wijngaarden]

IMHO that's another (better?) way of phrasing the point I made about 
relasing being about communication in another email.


On Thu, Sep 28, 2017 at 11:29:36AM -0700, Dmitri Dolguikh wrote:

Why not distribute the release process? Each component can have (probably
already does) multiple maintainers who are capable of doing most of the
leg-work. The role of the release nanny then becomes coordinating the
effort, making public announcements and such. Such an approach would help
avoid overly broad permissions too.

-d

On Thu, Sep 28, 2017 at 3:23 AM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:


To release a gem to rubygems I'd recommend looking at how voxpupuli
implemented this using Travis[1]. The same can be done for puppet[2]. That
means you can push a tag to git and the release is there.

There are also tools that help you bump. For puppet there is
puppet-blacksmith[3]. How to do annotated tags is in my notes[3]. A more
generic script is bump2version[5] and I'm sure there are similar tools in
the ruby world.

IMHO these tools should be suggested in the plugin templates.

[1]: https://github.com/voxpupuli/modulesync/blob/e53079030501756
fc4111511fb9b6a239ffcb2a3/.travis.yml#L18-L27
[2]: https://github.com/voxpupuli/puppet-nginx/blob/fc363114e509f
439b51ea22723a996ffca8a107d/.travis.yml#L48-L58
[3]: https://github.com/voxpupuli/puppet-blacksmith
[4]: http://pad-katello.rhcloud.com/p/releasing-modules
[5]: https://github.com/c4urself/bump2version

On Wed, Sep 27, 2017 at 08:08:46AM -0700, Daniel Lobato wrote:


For foreman-docker I had a process:

https://github.com/theforeman/foreman-docker/blob/master/rel
ease/RELEASE.md
https://github.com/theforeman/foreman-docker/blob/master/rel
ease/rollout-release

which I planned to implement in all theforeman org plugins ideally.
It didn't happen but it's a similar thing.

On Wednesday, September 27, 2017 at 4:56:51 PM UTC+2, Timo Goebel wrote:



... isn‘t continuous delivery old these days? Why aren‘t we doing it?
I vote in favor of automating this. This ensures predictable results and
hopefully makes this process easier. To be honest: The current process
scares me.
Same for plugin releases. They also are way too manual right now.

Timo

> On 27. Sep 2017, at 16:46, Daniel Lobato Garcia <elob...@gmail.com

> wrote:
>
> Hi devs,
>
> After a few releases, and now that I'm trying to help someone else to
> take over in case it's needed, I found a roadblock.
>
> Whoever is doing the release, needs to have **many** permissions.
>
> Otherwise, it doesn't make much sense for a person to take over release
> responsibilities. For example, if Ondrej has to do 1.15.5, he would
need
> the following permissions (see at the end of the email).
>
> Of course there are alternatives:
>
> 1 is to have the release nanny be supervised by people who have
'earned'
> these permissions. This is a bad idea because some of the tasks just
> cannot be 'supervised'. The nanny would 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 mas

Re: [foreman-dev] Release process & permissions

[Ewoud Kohl van Wijngaarden]

To release a gem to rubygems I'd recommend looking at how voxpupuli 
implemented this using Travis[1]. The same can be done for puppet[2]. 
That means you can push a tag to git and the release is there.


There are also tools that help you bump. For puppet there is 
puppet-blacksmith[3]. How to do annotated tags is in my notes[3]. A 
more generic script is bump2version[5] and I'm sure there are similar 
tools in the ruby world.


IMHO these tools should be suggested in the plugin templates.

[1]: 
https://github.com/voxpupuli/modulesync/blob/e53079030501756fc4111511fb9b6a239ffcb2a3/.travis.yml#L18-L27
[2]: 
https://github.com/voxpupuli/puppet-nginx/blob/fc363114e509f439b51ea22723a996ffca8a107d/.travis.yml#L48-L58
[3]: https://github.com/voxpupuli/puppet-blacksmith
[4]: http://pad-katello.rhcloud.com/p/releasing-modules
[5]: https://github.com/c4urself/bump2version

On Wed, Sep 27, 2017 at 08:08:46AM -0700, Daniel Lobato wrote:

For foreman-docker I had a process:

https://github.com/theforeman/foreman-docker/blob/master/release/RELEASE.md
https://github.com/theforeman/foreman-docker/blob/master/release/rollout-release

which I planned to implement in all theforeman org plugins ideally.
It didn't happen but it's a similar thing.

On Wednesday, September 27, 2017 at 4:56:51 PM UTC+2, Timo Goebel wrote:


... isn‘t continuous delivery old these days? Why aren‘t we doing it?
I vote in favor of automating this. This ensures predictable results and
hopefully makes this process easier. To be honest: The current process
scares me.
Same for plugin releases. They also are way too manual right now.

Timo

> On 27. Sep 2017, at 16:46, Daniel Lobato Garcia  wrote:
>
> Hi devs,
>
> After a few releases, and now that I'm trying to help someone else to
> take over in case it's needed, I found a roadblock.
>
> Whoever is doing the release, needs to have **many** permissions.
>
> Otherwise, it doesn't make much sense for a person to take over release
> responsibilities. For example, if Ondrej has to do 1.15.5, he would need
> the following permissions (see at the end of the email).
>
> Of course there are alternatives:
>
> 1 is to have the release nanny be supervised by people who have 'earned'
> these permissions. This is a bad idea because some of the tasks just
> cannot be 'supervised'. The nanny would 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=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...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.




--
You received this message because you are subscribed to the Google Groups 

Re: [foreman-dev] Release process & permissions

[Ewoud Kohl van Wijngaarden]

While I agree we should automate a lot, I agree with Eric. Doing a 
Foreman release should involve a human to keep the end-to-end quality. 
Just giving permissions is wrong.


For example in Foreman 1.15.5 the installer was tagged and released 
before I could push in my changes. That communication failure might have 
been partly my fault but IMHO the job of a release manager is to 
communicate with all the maintainers if everything is in place for a 
release.


Now you state it as a problem that you need a lot of people, but you 
need to communicate with them anyway. Yes, the tagging and releasing 
should be scripted but planning a release will require humans.


Like Eric I think we should start by documenting. Right now it's a huge 
black box for most people, let's start there.


On Wed, Sep 27, 2017 at 09:19:10PM -0400, Eric D Helms wrote:

There are two considerations that I'd like to put forth as we think about
this:

1) Instead of adding jobs, we re-think and re-write the release job in
Pipeline syntax similar to my starter here --
https://github.com/theforeman/foreman-infra/pull/323
2) We don't automate all the things as there are some tasks that should be
done by a human. The tedious, repetitive bits we should automate. The
aspects that require some human foresight, approval or double checking of
we should either require a releaser to "yes" to a job over or to perform
semi-automated in that the user uses tooling but ultimately has input. For
example, cherry picking should be 90% automated but 10% human input to
ensure nothing seems off since our issue-to-change is not flawless.

While we have some automation already in place, from my experience I would
recommend one of the following approaches.

1) create a flow chart of every action that has to happen using something
like plantuml with parallel actions where possible
2) Create a new release job, starting either from the beginning or the end
of the process and add each next step to it


Eric

On Wed, Sep 27, 2017 at 10:46 AM, Daniel Lobato Garcia 
wrote:


Hi devs,

After a few releases, and now that I'm trying to help someone else to
take over in case it's needed, I found a roadblock.

Whoever is doing the release, needs to have **many** permissions.

Otherwise, it doesn't make much sense for a person to take over release
responsibilities. For example, if Ondrej has to do 1.15.5, he would need
the following permissions (see at the end of the email).

Of course there are alternatives:

1 is to have the release nanny be supervised by people who have 'earned'
these permissions. This is a bad idea because some of the tasks just
cannot be 'supervised'. The nanny would 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=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 

Re: [foreman-dev] Requesting discovery test for core PRs

[Ewoud Kohl van Wijngaarden]

On Wed, Sep 27, 2017 at 01:34:08PM +0200, Lukas Zapletal wrote:

what you think about adding discovery to core PRs test suite, just one
Ruby version on sqlite3?


+1


Recently we had all red situation when we bumped to Rails 5. After
Ivan fixed that, we have the same due to fact import refactoring.
These changes are good, it's just bad timing when we are doing 1.16 RC
and these unexpected regressions happen. I would like to know in
advance.

This could set a precedent, but frankly I am ok with adding more
plugins there. What's important I think is to run all core tests
without any plugin and all plugin tests (without core tests) for all
top-tier plugins. We don't do that, we are trying to achieve "ideal"
world of all combinations all rubies all db stacks individually which
is not realistic approach with our resources.


In other discussions other people have suggested that only testing with 
Katello is odd and I agree. Either we test no plugins or a bunch of 
popular ones. Since testing is good, I'd prefer a bunch of popular ones.


We can argue about the rules for inclusion. My suggestion is to keep it 
simple: including in the main test matrix is a commitment from both 
sides and we need at least 2 active developers willing to help with test 
failures/potential regressions in core PRs.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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] Access to foreman-infra

[Ewoud Kohl van Wijngaarden]

Hello all,

To get more involved in foreman infra I'd like to request push access to 
foreman-infra. At first I'd like to help more with the CI.


Regards,
Ewoud Kohl van Wijngaarden

--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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] Database and Service Actions in RPM Post Scripts

[Ewoud Kohl van Wijngaarden]

On Fri, Sep 22, 2017 at 04:19:43PM -0400, Eric D Helms wrote:

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


While I generally like it when a yum install just works(tm), I do get 
the feeling that doing it for every plugin causes a lot of extra load 
that shouldn't be needed. Ideally you could queue up tasks like a rake 
db:migrate, apipie:cache:index and restart until everything is done but 
I'm not sure yum can do this and if so how well that'll work.


Another question I have is whether the apipie cache can be incrementally 
generated or if it's a full regenerate every time.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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] Removing old Jenkins jobs

[Ewoud Kohl van Wijngaarden]

It appears I don't have permission to delete these jobs.

On Thu, Sep 21, 2017 at 08:39:15AM -0400, Eric D Helms wrote:

+1

On Thu, Sep 21, 2017 at 8:22 AM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:


Hello all,

We have many old jobs in Jenkins that are no longer relevant. To make a
start I'm proposing to the delete 'installer lint and *' jobs. You can see
them at http://ci.theforeman.org/view/Installer/

As you can see they haven't been used for 3 years and it all happens on
Travis these days.

--
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and 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.

[foreman-dev] Removing old Jenkins jobs

[Ewoud Kohl van Wijngaarden]

Hello all,

We have many old jobs in Jenkins that are no longer relevant. To make a 
start I'm proposing to the delete 'installer lint and *' jobs. You can 
see them at http://ci.theforeman.org/view/Installer/


As you can see they haven't been used for 3 years and it all happens on 
Travis these days.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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

[Ewoud Kohl van Wijngaarden]

On Mon, Sep 18, 2017 at 11:21:04AM -0400, Eric D Helms wrote:

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


I filled in the "Merging katello and foreman installers" section since I 
already started the work.


I started to replace checks/disk_size.rb[1] and 
hooks/pre/17-memory_check.rb[2] but others I still need to investigate.


For example there's pre/10-reset_feature.rb[3] in katello which is a lot 
like pre/10-reset_foreman_db.rb[4].


pre_validations/11-check_proxy_url.rb[6] is already handled in 
puppet-katello[7] with Puppet 4 types.


Other things might be simplified by extending kafo. There's a lot of 
duplication in the katello hooks, like the broken exit function[8] meant 
you had to use kafo.class.exit() rather than exit(). Some helpers could 
also be moved in the library itself.


All in all this might be larger than I initially suspected but we'll get 
there.


[1]: 
https://github.com/Katello/katello-installer/blob/master/checks/disk_size.rb
[2]: 
https://github.com/Katello/katello-installer/blob/master/hooks/pre/17-memory_check.rb
[3]: 
https://github.com/Katello/katello-installer/blob/master/hooks/pre/10-reset_feature.rb
[4]: 
https://github.com/theforeman/foreman-installer/blob/develop/hooks/pre/10-reset_foreman_db.rb
[5]: 
https://github.com/Katello/katello-installer/blob/master/hooks/pre_validations/12-check_capsule_tar.rb
[6]: 
https://github.com/Katello/katello-installer/blob/master/hooks/pre_validations/11-check_proxy_url.rb
[7]: 
https://github.com/Katello/puppet-katello/blob/6c88e13ca39015ab034aa7396752a72141e3cb18/manifests/init.pp#L84
[8]: https://github.com/theforeman/kafo/pull/218
[9]: 
https://github.com/Katello/katello-installer/blob/master/hooks/pre_migrations/01-migrate_legacy_foreman_installer_config.rb

--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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: [POC] Automatic inspection of user-created provisioning templates

[Ewoud Kohl van Wijngaarden]

On Wed, Sep 13, 2017 at 12:05:49PM -0700, ssht...@redhat.com wrote:


First attempt to create a design. It's an open discussion, everyone who
wants to chime in, please do.

The engine: will be deployed as a separate gem. My name suggestion
the-detective  (Sinatra
plays a cop).

It will wrap the invocation of rubocop with defaults and parameters needed
to support our use case:
1. Support for erb
2. Support for completely customized set of cops.
3. Parametrized list of folders containing cops to be added to the list.

In addition it will add tooling to expose a rack endpoint for rubocop
invocation:
1. List of all available cops (kind of metadata)
2. A POST method that receives a source file, list of cops, and output
format that will return the result of rubocop's analysis.
3. Will be mountable to any Rails application
4. Will have an option to run as a standalone process (probably using
passenger with sort-lived process retention settings, since its one process
per request nature)


Why should it be a rack endpoint? My thinking was much more of a normal 
ruby API with a command line tool around it. There should be no 
passenger dependency to keep its dependencies small. foreman_templates 
can consume the ruby API and expose it to the user as it wants.



Usage for foreman needs:

Use case 1 (community templates CI):
1. Reference the detective gem from templates plugin.
2. Deploy foreman-core with templates plugin enabled.
3. Add rake task that will invoke rubocop on specified folder using
detective's invocation wrapper.


Ideally we'd have a light command line tool that does:

detective \
 --cops /path/to/foreman/checkout/cops \
 --cops /path/to/katello/checkout/cops \
 --cops /path/to/other/plugin/with/cops \
 /path/to/some/template/dir \
 /path/to/another/template/dir

That way we can do a simple git clone foreman in community-templates, 
bundle install and run it within Travis. This can indeed be wrapped in a 
rake task but given the paths can change on a developers workstation it 
is good to have an easy manual option.



Use case 2 (Validate single template from templates UI)
1. Reference detective gem from templates plugin.
2. Add cops declaration ability to plugins in foreman core
3. Templates plugin is responsible for adding/maintaining detective's
endpoint.
4. Foreman core exposes an option to add actions to template editing screen.
5. Templates plugin uses extension point from 4 to add its own action that
will invoke detective's endpoint and modify template editor to show the
result as linting (it's possible with ace and monaco).

Use case 3 (upgrade scenario):
As a first step, we can try and report broken templates after the upgrade.
It will be pretty similar to community templates CI use case, only the
templates code will be exported from user's database.


I want to start working on the engine gem as soon as possible, so I would
really appreciate any inputs on the process before I have started with this
implementation.

Shim.



On Wednesday, August 30, 2017 at 11:48:09 AM UTC+3, ssh...@redhat.com wrote:



After a great talk on community demo
, here is a follow up with
the points that were raised during the discussion:

Use cases:

   1. Run all cops as part of community templates CI against the whole
   repository
   2. Run all cops against a single template invoked by the user from
   template editing screen (foreman core)
   3. Upgrade scenario: Preferably run cops for the next foreman version
   before the actual upgrade to make sure the templates will remain valid.


Features:

   1. List of rues should be pluggable [Shim]: It looks like it is a
   must-have for the engine.
   2. Deployment options
   1. Engine as a separate gem, cops in a relevant repository - core cops
  in core, plugin cops in plugins.
  2. Engine with all cops in a single gem, versioned per foreman
  version.
  3. Engine as part of templates plugin, cops as part of relevant
  plugins.
  4. Separate gems for everything: foreman-cops-engine,
  foreman-cops-core, foreman-cops-plugin1, foreman-cops-plugin2 e.t.c. 
Engine
  is versioned per foreman release version (for the sake of rubocop 
version),
  cops are versioned per plugin version.

General comments:

   1. Cops writing should be enforced on PR's that are changing the way
   to write templates [mhulan]
   2. Cops are dependent on core/plugin version [gwmngilfen]




On Monday, August 14, 2017 at 2:29:02 PM UTC+3, ssh...@redhat.com wrote:


TL;DR: I have developed a way to scan any template and see if there are
suspicious/incorrect code patterns in them, so the templates will remain
valid even after foreman code changes.

Recently I have started to think about user created templates and foreman
upgrades.

When user upgrades foreman, hist default templates get upgraded by the
installer/migrations, but templates created by the user 

Re: [foreman-dev] From Foreman to Iot Platforme

[Ewoud Kohl van Wijngaarden]

In that case I would start with foreman_hooks and perform the POST 
request. You can even do this in bash with curl if you want.


https://github.com/theforeman/foreman_hooks#usage describes how you can 
create your own hooks.


On Wed, Sep 13, 2017 at 02:39:58AM -0700, Fairouz el ouazi wrote:

I m a beginner in ruby so that 's why i  felt a little bit a shame to  put
it in public im trying to make at first the plugin functional . For my
case  i know that i want to make a post request to my platform by in the
foreman side how can i do it ..

Le mercredi 13 septembre 2017 11:31:33 UTC+2, Ewoud Kohl van Wijngaarden a
écrit :


On Wed, Sep 13, 2017 at 02:25:01AM -0700, Fairouz el ouazi wrote:
> I m trying to develop a plugin in Foreman so i can manage  all the
>devices that are connected to my IoT  platform . I can communicate with
my
>IoT platform via REST API . In first place with GET request i can get all
>the devices on Foreman with their parameters . My problem now is when i
>change the parameters in foreman or deleting devices  I need to see the
>changes on my IoT platform . i really need  help because  i m trying to
>convince my colleague that Foreman can do  it .

Is the plugin open source and available somewhere? That generally makes
it much easier to help.

For inspiration it might be good to look at foreman_hooks. That has
triggers when an object is changed or deleted. You might even find that
just using foreman_hooks could be enough for your use case.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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] From Foreman to Iot Platforme

[Ewoud Kohl van Wijngaarden]

On Wed, Sep 13, 2017 at 02:25:01AM -0700, Fairouz el ouazi wrote:

I m trying to develop a plugin in Foreman so i can manage  all the
devices that are connected to my IoT  platform . I can communicate with my
IoT platform via REST API . In first place with GET request i can get all
the devices on Foreman with their parameters . My problem now is when i
change the parameters in foreman or deleting devices  I need to see the
changes on my IoT platform . i really need  help because  i m trying to
convince my colleague that Foreman can do  it .


Is the plugin open source and available somewhere? That generally makes 
it much easier to help.


For inspiration it might be good to look at foreman_hooks. That has 
triggers when an object is changed or deleted. You might even find that 
just using foreman_hooks could be enough for your use case.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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] Problems with Katello Bastion UI when changing Foreman base URL

[Ewoud Kohl van Wijngaarden]

That's good to know. Added a comment about the JQuery ajax calls.

On Tue, Sep 12, 2017 at 09:57:43AM -0400, Walden Raines wrote:

See also issue #20313 [1] which has an open PR [2].

Cheers,
Walden

[1] http://projects.theforeman.org/issues/20313
[2] https://github.com/Katello/bastion/pull/206

On Tue, Sep 12, 2017 at 8:18 AM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:


Hello Gerrit,

You're right that a lot assumes a static location. Katello has much more
assumptions in this area than vanilla Foreman and while there is an effort
to at least be able to split services onto different hosts where we might
tackle some assumptions in the process there is a long way to go.

For now I'd advise you to use a separate vhost and use DNS, separate IP
and/or port for your own application because it sounds like that's more
relocatable.

On Tue, Sep 12, 2017 at 05:07:13AM -0700, gerrit.schwerth...@avid.com
wrote:


Hello Ewoud,

thanks for your informative and quick answer. As it looks to me that the
required changes are touching quite a lot of sensitive points (from which
many are not yet identified?), I think it's better for me not to continue
with my undertaking and not to touch the sources.

For now, I will the just redirect ^/$ with httpd to point to an alias of
where my own service sits. This way, only the dashboard of Foreman cannot
be reached anymore, but the rest of Foreman and Katello is still intact
and
seems to work for everything I need.

I also already tried running Foreman in production on non-default ports,
but it seems like this is even causing more issues as there seem to be
some
hard coded ports for the communication with Pulp in the sources (like
https://github.com/Katello/katello/blob/6aca54157e579d6312a9
e4a49609df0ffa1685b1/app/services/katello/proxy_status/pulp.rb#L45).

If you have any other ideas I could try out, I would be very grateful if
you share them with me.

Many thanks and regards,

--Gerrit


On Tuesday, September 12, 2017 at 12:29:05 PM UTC+2, Ewoud Kohl van
Wijngaarden wrote:



On Tue, Sep 12, 2017 at 02:56:06AM -0700, gerrit.sc...@avid.com
 wrote:
>I am having a setup where I use Foreman as a complete backend service.
>Another service works on the document root of the HTTPD server. In order
to
>have all pages of Foreman still reachable, I tried altering the base URL
of
>Foreman by changing the value for the foreman_url in the
foreman-installer.
>This is working great so far, all pages of Foreman now changed to
>https:///foreman, all API calls are working fine.
>
>However, when I try to visit a Katello page like content views or
products,
>the page cannot load and it ends up in an endless loop. I can provide
more
>detailed logging output if required, but as far as I can see, there is
not
>much information that can be found in the logs.
>
>Did anyone ever try changing the base URL and ran into this issue? Is
there
>a possibility to configure Katello such that the pages work with an
altered
>base? Is there maybe a setting in the foreman-installer that I need to
>change to make it work?
>
>Thanks for reading and all the best,

https://github.com/Katello/puppet-katello/pull/211 was merged just last
week so I'm guessing few people do. There may be other dragons hiding
because deployment_url is considered relative in post_sync_url now but
in candlepin it might have been considered absolute so I dug in deeper
(as I should have when I merged 211) and it looks like the whole
deployment_url is unused in puppet-candlepin and we should just remove
that part. https://github.com/Katello/puppet-candlepin/pull/82 together
with https://github.com/Katello/puppet-katello/pull/214 should take care
of that.

Looking through the source then I see some examples that should work but
many that do not. What should work is using the foreman_url helper like

https://github.com/Katello/katello/blob/b02526bea7026560b2d6
d66fac9038cfeb74bab9/app/assets/javascripts/katello/
hosts/activation_key_edit.js#L22

What doesn't work is plain URLs like

https://github.com/Katello/katello/blob/b02526bea7026560b2d6
d66fac9038cfeb74bab9/app/assets/javascripts/katello/
hosts/host_and_hostgroup_edit.js#L28

In short: I think you're entering uncharted/unsupported territory.



--
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and 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 
"forem

Re: [foreman-dev] Problems with Katello Bastion UI when changing Foreman base URL

[Ewoud Kohl van Wijngaarden]

Hello Gerrit,

You're right that a lot assumes a static location. Katello has much more 
assumptions in this area than vanilla Foreman and while there is an 
effort to at least be able to split services onto different hosts where 
we might tackle some assumptions in the process there is a long way to 
go.


For now I'd advise you to use a separate vhost and use DNS, separate 
IP and/or port for your own application because it sounds like that's 
more relocatable.


On Tue, Sep 12, 2017 at 05:07:13AM -0700, gerrit.schwerth...@avid.com wrote:

Hello Ewoud,

thanks for your informative and quick answer. As it looks to me that the
required changes are touching quite a lot of sensitive points (from which
many are not yet identified?), I think it's better for me not to continue
with my undertaking and not to touch the sources.

For now, I will the just redirect ^/$ with httpd to point to an alias of
where my own service sits. This way, only the dashboard of Foreman cannot
be reached anymore, but the rest of Foreman and Katello is still intact and
seems to work for everything I need.

I also already tried running Foreman in production on non-default ports,
but it seems like this is even causing more issues as there seem to be some
hard coded ports for the communication with Pulp in the sources (like
https://github.com/Katello/katello/blob/6aca54157e579d6312a9e4a49609df0ffa1685b1/app/services/katello/proxy_status/pulp.rb#L45).

If you have any other ideas I could try out, I would be very grateful if
you share them with me.

Many thanks and regards,

--Gerrit


On Tuesday, September 12, 2017 at 12:29:05 PM UTC+2, Ewoud Kohl van
Wijngaarden wrote:


On Tue, Sep 12, 2017 at 02:56:06AM -0700, gerrit.sc...@avid.com
 wrote:
>I am having a setup where I use Foreman as a complete backend service.
>Another service works on the document root of the HTTPD server. In order
to
>have all pages of Foreman still reachable, I tried altering the base URL
of
>Foreman by changing the value for the foreman_url in the
foreman-installer.
>This is working great so far, all pages of Foreman now changed to
>https:///foreman, all API calls are working fine.
>
>However, when I try to visit a Katello page like content views or
products,
>the page cannot load and it ends up in an endless loop. I can provide
more
>detailed logging output if required, but as far as I can see, there is
not
>much information that can be found in the logs.
>
>Did anyone ever try changing the base URL and ran into this issue? Is
there
>a possibility to configure Katello such that the pages work with an
altered
>base? Is there maybe a setting in the foreman-installer that I need to
>change to make it work?
>
>Thanks for reading and all the best,

https://github.com/Katello/puppet-katello/pull/211 was merged just last
week so I'm guessing few people do. There may be other dragons hiding
because deployment_url is considered relative in post_sync_url now but
in candlepin it might have been considered absolute so I dug in deeper
(as I should have when I merged 211) and it looks like the whole
deployment_url is unused in puppet-candlepin and we should just remove
that part. https://github.com/Katello/puppet-candlepin/pull/82 together
with https://github.com/Katello/puppet-katello/pull/214 should take care
of that.

Looking through the source then I see some examples that should work but
many that do not. What should work is using the foreman_url helper like

https://github.com/Katello/katello/blob/b02526bea7026560b2d6d66fac9038cfeb74bab9/app/assets/javascripts/katello/hosts/activation_key_edit.js#L22

What doesn't work is plain URLs like

https://github.com/Katello/katello/blob/b02526bea7026560b2d6d66fac9038cfeb74bab9/app/assets/javascripts/katello/hosts/host_and_hostgroup_edit.js#L28

In short: I think you're entering uncharted/unsupported territory.



--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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] Permissions cleanup

[Ewoud Kohl van Wijngaarden]

On Mon, Sep 11, 2017 at 12:41:02PM +0100, Greg Sutcliffe wrote:

In the context of the plugins-bus-factor discussion, etc, it occurred
to me that we still have a lot of people with access who aren't really
active any more - this can make it hard to see where action is needed.

We've never really done a permissions cleanup before, so I thought it
might be time. Here's a list of people / things I found that I'd like
to fix. I've tried to keep this to core and related stuff, as plugins
are free to handle their own affairs, to a large extent (also the list
would be huge). In vaguely alphabetical order then:

* Amos Benari:
 * Github: no commits in over a year, remove commit on
   - community-templates
   - foreman
   - rfcs
   - smart-proxy
   - theforeman.org
* Brian Gupta:
 * Github: no commits in over a year, remove commit on
   - community-templates
   - foreman
   - foreman-selinux
   - hammer_cli
   - rfcs
   - smart-proxy
 * Remove Admin level on Redmine, last login, Apr 2015
 * Brandorr (Brian's org) also has an SSH key for the infra. Since we
   still host some stuff with them, let's leave that for now.
* Dominic Cleal:
 * GitHub - Owner status:
 While commit access lasts for a year, Dom has not been seen on
 the mailing lists, Redmine, or Github since May/June (with the
 exception of a single commit in July). In the context of having
 active owners that we discussed previously, I propose we demote
 him from owner level.
* Joseph Magen (istratrade):
 * Github: no commits in over a year, remove commit on
   - community-templates
   - foreman
   - foreman-selinux
   - rfcs
   - smart-proxy
* Corey Osman (logicminds):
 * Github: no commits in over a year, remove commit on
   - community-templates
   - foreman
   - foreman-selinux
   - rfcs
   - smart-proxy
* Sam Kottler:
 * Github: no commits in over a year, remove commit on
   - foreman-installer
   - foreman-packaging
   - foreman-infra
   - community-templates
   - kafo
   - foreman-bats
   - redmine (our fork)
   - prprocessor
   - jenkins-job-builder (our fork)
 * Remove SSH key on infra

There's probably more, but that's a first pass. Thoughts?


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

Re: [foreman-dev] Problems with Katello Bastion UI when changing Foreman base URL

[Ewoud Kohl van Wijngaarden]

On Tue, Sep 12, 2017 at 02:56:06AM -0700, gerrit.schwerth...@avid.com wrote:

I am having a setup where I use Foreman as a complete backend service.
Another service works on the document root of the HTTPD server. In order to
have all pages of Foreman still reachable, I tried altering the base URL of
Foreman by changing the value for the foreman_url in the foreman-installer.
This is working great so far, all pages of Foreman now changed to
https:///foreman, all API calls are working fine.

However, when I try to visit a Katello page like content views or products,
the page cannot load and it ends up in an endless loop. I can provide more
detailed logging output if required, but as far as I can see, there is not
much information that can be found in the logs.

Did anyone ever try changing the base URL and ran into this issue? Is there
a possibility to configure Katello such that the pages work with an altered
base? Is there maybe a setting in the foreman-installer that I need to
change to make it work?

Thanks for reading and all the best,


https://github.com/Katello/puppet-katello/pull/211 was merged just last 
week so I'm guessing few people do. There may be other dragons hiding 
because deployment_url is considered relative in post_sync_url now but 
in candlepin it might have been considered absolute so I dug in deeper 
(as I should have when I merged 211) and it looks like the whole 
deployment_url is unused in puppet-candlepin and we should just remove 
that part. https://github.com/Katello/puppet-candlepin/pull/82 together 
with https://github.com/Katello/puppet-katello/pull/214 should take care 
of that.


Looking through the source then I see some examples that should work but 
many that do not. What should work is using the foreman_url helper like 
https://github.com/Katello/katello/blob/b02526bea7026560b2d6d66fac9038cfeb74bab9/app/assets/javascripts/katello/hosts/activation_key_edit.js#L22


What doesn't work is plain URLs like
https://github.com/Katello/katello/blob/b02526bea7026560b2d6d66fac9038cfeb74bab9/app/assets/javascripts/katello/hosts/host_and_hostgroup_edit.js#L28

In short: I think you're entering uncharted/unsupported territory.

--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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] What is the process to get new resources added to transifex?

[Ewoud Kohl van Wijngaarden]

+1 to adding Bryan. We don't have a process in place and Bryan obviously 
cares.


On Mon, Sep 11, 2017 at 10:36:27AM +0200, Marek Hulán wrote:

I think we don't have to follow the full-blown nomination process here, any
concerns regarding giving Bryan admin access? Please let me know here or
privately, otherwise I'll add Bryan in few days.

--
Marek

On pátek 8. září 2017 22:31:48 CEST bk wrote:

Also... hammer-cli-foreman-tasks.. could that get added as a resource?

On Thursday, September 7, 2017 at 3:48:05 PM UTC-4, bk wrote:
> On 08/31/2017 07:49 AM, Bryan Kearney wrote:
> > On 08/31/2017 05:36 AM, Daniel Lobato Garcia wrote:
> >> On 08/30, Bryan Kearney wrote:
> >>> I would like to see katello and katello-bastion added to transifex.
>
> Once
>
> >>> that is done, I can ask folks to add string syncing to the build
> >>> process. I
> >>> can translate, but I dont have access to add resources.
> >>>
> >>> -- bk
> >>
> >> I think you would need to gather the .po files for the projects you
>
> want
>
> >> to add, then upload them to
> >> https://www.transifex.com/foreman/foreman/content/
> >>
> >> The administrators at the moment according to
> >> https://www.transifex.com/foreman/public/ are: lzap, ohadlevy,
>
> domcleal
>
> >> mhulan, Claer. They could add the .po files or add you as another
> >> aministrator.
> >
> > I have these, and I can either supply them or append them to
> >
> > https://github.com/Katello/katello/pull/6929
> >
> > which I put in to generate them. I am also happy to beg for admin
>
> status.
>
> > -- bk
>
> ok.. third try. Can I get an admin to please upload these. Thanks!
>
> -- 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.

Re: [foreman-dev] [infra] Packaging reorganization

[Ewoud Kohl van Wijngaarden]

On Mon, Sep 04, 2017 at 02:13:27PM -0400, Justin Sherrill wrote:


On 09/02/2017 03:00 PM, Eric D Helms wrote:


On Sep 2, 2017 10:22 AM, "Timo Goebel" > 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:
It might be even more out of scope, but i could see value in having 
hammer and all the hammer plugins in a client repo as well.


From an issue in puppet-foreman we know users deploy Hammer using 
puppet-foreman without installing foreman itself so that might make 
sense. Makes me wonder if we should split off foreman::cli into a 
separate hammer module.



-Justin



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


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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

[Ewoud Kohl van Wijngaarden]

On Sat, Sep 02, 2017 at 08:02:32AM -0400, Eric D Helms wrote:

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/puppet/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?


This biggest challenge I see here is the correct triggers, but I must 
admit that I don't know how it's triggered now. AFAIK foreman-infra 
currently pretty much contains /etc/puppet and is checked out there. 
This should also be moved to a proper control repository (and there's a 
TODO item for that).



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.

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

[Ewoud Kohl van Wijngaarden]

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


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.

Re: [foreman-dev] [infra] Packaging reorganization

[Ewoud Kohl van Wijngaarden]

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?


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?


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


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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] Jenkins Job Naming Conventions

[Ewoud Kohl van Wijngaarden]

Joining in on the party: +1 for #2

On Fri, Sep 01, 2017 at 09:29:17AM -0400, John Mitsch wrote:

Another vote for #2 as you can scan quickly and group by project.

John Mitsch
Red Hat Engineering
(860)-967-7285
irc: jomitsch

On Fri, Sep 1, 2017 at 8:56 AM, Justin Sherrill  wrote:


My vote would be #2, as it groups things by entity a bit nicer.  I don't
normally care to look at the release job across all projects, but would
want to look at all jobs across a particular project.

On 09/01/2017 08:43 AM, Eric D Helms wrote:

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.


--
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and 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] Katello pulp_export_destination checks happen inside the application

[Ewoud Kohl van Wijngaarden]

On Mon, Aug 21, 2017 at 08:06:01AM +0200, Timo Goebel wrote:

Am 20.08.17 um 22:39 schrieb Ewoud Kohl van Wijngaarden:
I think if Pulp took a parameter to publish to a non-default 
location, we
would not need to do the extra copy step that ties Katello and 
Pulp closely

together. Currently it is needed because we need the export to land in
pulp_export_destination.


That would be nice. To me it looks like it already sends the 
export_directory to pulp and has an absolute path. Is there a reason 
this can't be set to Setting['pulp_export_destination'] directly?
What would you think, if we let smart_proxy_pulp handle the copy job 
and checking if the directories exist? That would loosen the coupling 
between Katello and Pulp?


That was my first thought as well and it is the typical approach taken 
within the (vanilla) Foreman architecture. This is where Katello really 
differs and would require a major rewrite of certain integrations.


If we all agree Katello should never assume a service shares its 
filesystem with another service I can create issues for everything I run 
into.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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 pulp_export_destination checks happen inside the application

[Ewoud Kohl van Wijngaarden]

On Sun, Aug 20, 2017 at 04:11:13PM -0400, Christopher Duryee wrote:

On Sun, Aug 20, 2017 at 4:02 PM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:


Hello all,

While working on splitting the Katello installation from its services I
ran into the pulp_export_destination setting. That made me look at the
Repository Export[1] which assumes the pulp server and application server
share the same filesystem.

That means I'm stuck in attempting to split services to different machines
where I don't want to assume a shared filesystem. Looking at the containers
it's not handled there either. I don't see a way to support this feature
without a major rewrite of the code but I'm not familiar with the Katello
code base.

Anyone has advice on how to deal with this?



I think if Pulp took a parameter to publish to a non-default location, we
would not need to do the extra copy step that ties Katello and Pulp closely
together. Currently it is needed because we need the export to land in
pulp_export_destination.


That would be nice. To me it looks like it already sends the 
export_directory to pulp and has an absolute path. Is there a reason 
this can't be set to Setting['pulp_export_destination'] directly?






[1]: 
https://github.com/Katello/katello/blob/master/app/lib/actions/katello/repository/export.rb


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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 pulp_export_destination checks happen inside the application

[Ewoud Kohl van Wijngaarden]

Hello all,

While working on splitting the Katello installation from its services I 
ran into the pulp_export_destination setting. That made me look at the 
Repository Export[1] which assumes the pulp server and application server 
share the same filesystem.


That means I'm stuck in attempting to split services to different 
machines where I don't want to assume a shared filesystem. Looking at 
the containers it's not handled there either. I don't see a way to 
support this feature without a major rewrite of the code but I'm not 
familiar with the Katello code base.


Anyone has advice on how to deal with this?

[1]: 
https://github.com/Katello/katello/blob/master/app/lib/actions/katello/repository/export.rb

--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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] Plugin gems with a single author

[Ewoud Kohl van Wijngaarden]

On Sun, Aug 20, 2017 at 09:56:40AM -0700, Dmitri Dolguikh wrote:

On Sun, Aug 20, 2017 at 6:49 AM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:


On Fri, Aug 18, 2017 at 12:48:06PM +0100, Greg Sutcliffe wrote:
Ewoud Kohl van Wijngaarden:

- smart_proxy_dns_powerdns



Looking for a co-owner here :)



You can add me.

Cheers,
-d


Done

--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.