Re: [foreman-dev] DHCP filename option no longer honored

[Timo Goebel]

Hi,

Dimitri sent a patch that should fix the problem. It's just a one line 
change, so we just need to test it and it should be ready to merge.


However, we should check what change really introduced the problem to 
see if this needs backporting to 1.16. I have some doubts it was the 
change mentioned below.


Lukas, can you please confirm the patch fixes the issue for you?

Timo

Am 14.12.17 um 14:21 schrieb Lukas Zapletal:

Hey,

I noticed that DHCP filename option is no longer honored in
develop/1.17 branch anymore. This is regression from 1.15/1.16 series,
filed a blocker bug for 1.17:

http://projects.theforeman.org/issues/21975

This breaks UEFI provisioning. I git-bisected

commit e75df1dd3cc30bff2832d337b5bc20bd822e209a
Refs:
Author: Timo Goebel 
AuthorDate: Wed Oct 25 16:26:01 2017 +0200
Commit: Dmitri Dolguikh 
CommitDate: Mon Nov 6 14:28:09 2017 -0800

But I cannot figure it out, help needed. Thanks.




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

[Ondrej Prazak]

Hi,
quick summary about 1.17 branching status. The develop branch moved to
Rails 5 and turbolinks were added to tfm-ror51. Right now, the develop is
basically ready to move to Rails 5.1 by getting in [1]. When that is done,
there are packaging updates that need to be done - we need to update fog to
1.42 [2] and move to higher version of Ruby scl.

There are also other items planned 1.17:

* dynflowd via foreman package [3], [4] - I assume these will go in after
the packaging changes
* broken UEFI provisioning, which was reported today [5]

Given the rapidly approaching holidays and the fact that we are already
behind schedule, I would like to branch next week before people leave for
their vacations and not to postpone the branching until the next year.

O.

[1] https://github.com/theforeman/foreman/pull/4836
[2] https://github.com/theforeman/foreman-packaging/pull/1975
[3] https://github.com/theforeman/foreman-packaging/pull/1549
[4] https://github.com/theforeman/foreman-packaging/pull/1959
[5] http://projects.theforeman.org/issues/21975

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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] Introducing #theforeman-dev-ui, an experiment

[Walden Raines]

The UX team is playing with the idea of forking UI discussions out into a
separate channel.  We will do a month long experiment and see how it goes.

*Background:*  The irc channel #theforeman-dev is very busy and there are
often times multiple conversations taking place simultaneously.

*Hypothesis:*  By using the irc channel #theforeman-dev-ui conversations
will be more relevant to those who are concerned mainly with UI topics.
Having a smaller channel will also facilitate more conversation because of
this focus.

*Methodology:*  All interested in UI related conversations will use
#theforeman-dev-ui for a month and then users on this mailing list will be
polled about their experience during the month.

Please join #theforeman-dev-ui on freenode if you are interested in
participating in our (unpaid) research study.

Thanks,
Walden

*References:*
https://xkcd.com/1782/

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

Re: [foreman-dev] Request for Koji access

[Eric D Helms]

I will work on getting you a cert cut.

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

> On Wed, Dec 13, 2017 at 10:30:53AM +0100, Ondrej Prazak wrote:
>
>> as we are getting closer to 1.17 branching, I would like to ask for access
>> to Koji, because I will need to update build targets and configuration.
>>
>
> +1
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Eric D. Helms
Red Hat Engineering

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

Re: [foreman-dev] 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] Foreman instrumentation for telemetry proposal

[Tom McKay]

Run prometheus container locally
   $ docker run -d -p 9090:9090
registry.access.redhat.com/openshift3/prometheus
The prometheus binary is set as the entrypoint for the container
   $ docker run -d prom/prometheus --help

(Images also available on docker hub prom/prometheus)




On Thu, Dec 14, 2017 at 10:30 AM, Ohad Levy  wrote:

>
>
> On Thu, Dec 14, 2017 at 5:28 PM, Lukas Zapletal  wrote:
>
>> Exactly, I based my proposal on Prometheus and Statsd. You can choose.
>>
>> I am going to work on my PR next week hopefully, but you can test it
>> today:
>>
>> https://gist.github.com/lzap/2dfdd4dea29786a837cb1b7feb7862fd
>
>
> Don't you have a docker container somewhere all setup? ;)
>
>>
>>
>> Thanks for feedback!
>>
>> On Thu, Dec 14, 2017 at 3:52 PM, Tom McKay 
>> wrote:
>> > Ooops! I should have watched your video first. :) Watching it now.
>> "Proposal
>> > to integrate Prometheus and Statsd instrumentation libraries into
>> Foreman
>> > ..."
>> >
>> > On Thu, Dec 14, 2017 at 9:26 AM, Tom McKay 
>> wrote:
>> >>
>> >> Openshift uses Prometheus[1] which seems very similar and compatible
>> with
>> >> your ideas. Is that something you've looked at already? If/when
>> foreman is
>> >> containerized and perhaps run under kubernetes your work could be very
>> >> useful as well.
>> >>
>> >> https://blog.openshift.com/tag/prometheus/
>> >>
>> >>
>> >>
>> >> On Fri, Nov 24, 2017 at 12:54 PM, Lukas Zapletal 
>> wrote:
>> >>>
>> >>> > 1. what happened to the PCP approach we talked about in the past?
>> >>>
>> >>> Thats going in parallel, PCP is just a monitoring framework you can
>> >>> integrate with instrumentation data just like any other.
>> >>>
>> >>> > 2. how would you integrate this to sosreport/foreman-debug? I'm
>> >>> > thinking of
>> >>> > storing the statsd data locally, collecting them with foreman-debug,
>> >>> > and
>> >>> > then, being able to import them later to the prometheus and other
>> >>> > tools. Is
>> >>> > this how this could work? Any other options?
>> >>>
>> >>> This is my ultimate goal to have working PCP deployment including
>> >>> telemetry data and archives could be collected by foreman-debug, they
>> >>> are pretty small (few MBs per day).
>> >>>
>> >>> > 3. does every host/runtime needs it's own statsd service, or there
>> >>> > would be
>> >>> > one shared process? Asking bith for multi-host and containers
>> use-case
>> >>>
>> >>> It is up to you if you want one statsd service per guest/container,
>> >>> host or subnet. Prometheus endpoint will not require any external
>> >>> daemon once sharing metrics is merged into upstream. For this reason,
>> >>> statsd will server as a temporary solution and alternative for the
>> >>> future.
>> >>>
>> >>> > The proposal of the telemetry api itself seems reasonable, let's
>> >>> > discuss
>> >>> > that on an actual PR
>> >>>
>> >>> Thanks, I hope to finish it this year.
>> >>>
>> >>> --
>> >>> Later,
>> >>>   Lukas @lzap Zapletal
>> >>>
>> >>> --
>> >>> You received this message because you are subscribed to the Google
>> Groups
>> >>> "foreman-dev" group.
>> >>> To unsubscribe from this group and stop receiving emails from it,
>> send an
>> >>> email to foreman-dev+unsubscr...@googlegroups.com.
>> >>> For more options, visit https://groups.google.com/d/optout.
>> >>
>> >>
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "foreman-dev" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an
>> > email to foreman-dev+unsubscr...@googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>> --
>> Later,
>>   Lukas @lzap Zapletal
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "foreman-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to foreman-dev+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [foreman-dev] Foreman instrumentation for telemetry proposal

[Ohad Levy]

On Thu, Dec 14, 2017 at 5:28 PM, Lukas Zapletal  wrote:

> Exactly, I based my proposal on Prometheus and Statsd. You can choose.
>
> I am going to work on my PR next week hopefully, but you can test it today:
>
> https://gist.github.com/lzap/2dfdd4dea29786a837cb1b7feb7862fd


Don't you have a docker container somewhere all setup? ;)

>
>
> Thanks for feedback!
>
> On Thu, Dec 14, 2017 at 3:52 PM, Tom McKay  wrote:
> > Ooops! I should have watched your video first. :) Watching it now.
> "Proposal
> > to integrate Prometheus and Statsd instrumentation libraries into Foreman
> > ..."
> >
> > On Thu, Dec 14, 2017 at 9:26 AM, Tom McKay 
> wrote:
> >>
> >> Openshift uses Prometheus[1] which seems very similar and compatible
> with
> >> your ideas. Is that something you've looked at already? If/when foreman
> is
> >> containerized and perhaps run under kubernetes your work could be very
> >> useful as well.
> >>
> >> https://blog.openshift.com/tag/prometheus/
> >>
> >>
> >>
> >> On Fri, Nov 24, 2017 at 12:54 PM, Lukas Zapletal 
> wrote:
> >>>
> >>> > 1. what happened to the PCP approach we talked about in the past?
> >>>
> >>> Thats going in parallel, PCP is just a monitoring framework you can
> >>> integrate with instrumentation data just like any other.
> >>>
> >>> > 2. how would you integrate this to sosreport/foreman-debug? I'm
> >>> > thinking of
> >>> > storing the statsd data locally, collecting them with foreman-debug,
> >>> > and
> >>> > then, being able to import them later to the prometheus and other
> >>> > tools. Is
> >>> > this how this could work? Any other options?
> >>>
> >>> This is my ultimate goal to have working PCP deployment including
> >>> telemetry data and archives could be collected by foreman-debug, they
> >>> are pretty small (few MBs per day).
> >>>
> >>> > 3. does every host/runtime needs it's own statsd service, or there
> >>> > would be
> >>> > one shared process? Asking bith for multi-host and containers
> use-case
> >>>
> >>> It is up to you if you want one statsd service per guest/container,
> >>> host or subnet. Prometheus endpoint will not require any external
> >>> daemon once sharing metrics is merged into upstream. For this reason,
> >>> statsd will server as a temporary solution and alternative for the
> >>> future.
> >>>
> >>> > The proposal of the telemetry api itself seems reasonable, let's
> >>> > discuss
> >>> > that on an actual PR
> >>>
> >>> Thanks, I hope to finish it this year.
> >>>
> >>> --
> >>> Later,
> >>>   Lukas @lzap Zapletal
> >>>
> >>> --
> >>> You received this message because you are subscribed to the Google
> Groups
> >>> "foreman-dev" group.
> >>> To unsubscribe from this group and stop receiving emails from it, send
> an
> >>> email to foreman-dev+unsubscr...@googlegroups.com.
> >>> For more options, visit https://groups.google.com/d/optout.
> >>
> >>
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "foreman-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to foreman-dev+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> Later,
>   Lukas @lzap Zapletal
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [foreman-dev] Foreman instrumentation for telemetry proposal

[Lukas Zapletal]

Exactly, I based my proposal on Prometheus and Statsd. You can choose.

I am going to work on my PR next week hopefully, but you can test it today:

https://gist.github.com/lzap/2dfdd4dea29786a837cb1b7feb7862fd

Thanks for feedback!

On Thu, Dec 14, 2017 at 3:52 PM, Tom McKay  wrote:
> Ooops! I should have watched your video first. :) Watching it now. "Proposal
> to integrate Prometheus and Statsd instrumentation libraries into Foreman
> ..."
>
> On Thu, Dec 14, 2017 at 9:26 AM, Tom McKay  wrote:
>>
>> Openshift uses Prometheus[1] which seems very similar and compatible with
>> your ideas. Is that something you've looked at already? If/when foreman is
>> containerized and perhaps run under kubernetes your work could be very
>> useful as well.
>>
>> https://blog.openshift.com/tag/prometheus/
>>
>>
>>
>> On Fri, Nov 24, 2017 at 12:54 PM, Lukas Zapletal  wrote:
>>>
>>> > 1. what happened to the PCP approach we talked about in the past?
>>>
>>> Thats going in parallel, PCP is just a monitoring framework you can
>>> integrate with instrumentation data just like any other.
>>>
>>> > 2. how would you integrate this to sosreport/foreman-debug? I'm
>>> > thinking of
>>> > storing the statsd data locally, collecting them with foreman-debug,
>>> > and
>>> > then, being able to import them later to the prometheus and other
>>> > tools. Is
>>> > this how this could work? Any other options?
>>>
>>> This is my ultimate goal to have working PCP deployment including
>>> telemetry data and archives could be collected by foreman-debug, they
>>> are pretty small (few MBs per day).
>>>
>>> > 3. does every host/runtime needs it's own statsd service, or there
>>> > would be
>>> > one shared process? Asking bith for multi-host and containers use-case
>>>
>>> It is up to you if you want one statsd service per guest/container,
>>> host or subnet. Prometheus endpoint will not require any external
>>> daemon once sharing metrics is merged into upstream. For this reason,
>>> statsd will server as a temporary solution and alternative for the
>>> future.
>>>
>>> > The proposal of the telemetry api itself seems reasonable, let's
>>> > discuss
>>> > that on an actual PR
>>>
>>> Thanks, I hope to finish it this year.
>>>
>>> --
>>> Later,
>>>   Lukas @lzap Zapletal
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "foreman-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to foreman-dev+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Later,
  Lukas @lzap Zapletal

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

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

[Lukas Zapletal]

I have this aliases:

alias bi="bundle install && test -f package.json && npm install ||
node_modules/.bin/npm install"
alias bu="bundle update && test -f package.json && npm upgrade ||
node_modules/.bin/npm upgrade"

We don't have Gemfile.lock in git, therefore update needs to be
executed often. I guess it does not apply to npm. Confusing.


On Thu, Dec 14, 2017 at 4:24 PM, Ewoud Kohl van Wijngaarden
 wrote:
> 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.



-- 
Later,
  Lukas @lzap Zapletal

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

Re: [foreman-dev] 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] Foreman instrumentation for telemetry proposal

[Tom McKay]

Ooops! I should have watched your video first. :) Watching it now. "Proposal
to integrate Prometheus and Statsd instrumentation libraries into Foreman
..."

On Thu, Dec 14, 2017 at 9:26 AM, Tom McKay  wrote:

> Openshift uses Prometheus[1] which seems very similar and compatible with
> your ideas. Is that something you've looked at already? If/when foreman is
> containerized and perhaps run under kubernetes your work could be very
> useful as well.
>
> https://blog.openshift.com/tag/prometheus/
>
>
>
> On Fri, Nov 24, 2017 at 12:54 PM, Lukas Zapletal  wrote:
>
>> > 1. what happened to the PCP approach we talked about in the past?
>>
>> Thats going in parallel, PCP is just a monitoring framework you can
>> integrate with instrumentation data just like any other.
>>
>> > 2. how would you integrate this to sosreport/foreman-debug? I'm
>> thinking of
>> > storing the statsd data locally, collecting them with foreman-debug, and
>> > then, being able to import them later to the prometheus and other
>> tools. Is
>> > this how this could work? Any other options?
>>
>> This is my ultimate goal to have working PCP deployment including
>> telemetry data and archives could be collected by foreman-debug, they
>> are pretty small (few MBs per day).
>>
>> > 3. does every host/runtime needs it's own statsd service, or there
>> would be
>> > one shared process? Asking bith for multi-host and containers use-case
>>
>> It is up to you if you want one statsd service per guest/container,
>> host or subnet. Prometheus endpoint will not require any external
>> daemon once sharing metrics is merged into upstream. For this reason,
>> statsd will server as a temporary solution and alternative for the
>> future.
>>
>> > The proposal of the telemetry api itself seems reasonable, let's discuss
>> > that on an actual PR
>>
>> Thanks, I hope to finish it this year.
>>
>> --
>> Later,
>>   Lukas @lzap Zapletal
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "foreman-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to foreman-dev+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: [foreman-dev] Foreman instrumentation for telemetry proposal

[Tom McKay]

Openshift uses Prometheus[1] which seems very similar and compatible with
your ideas. Is that something you've looked at already? If/when foreman is
containerized and perhaps run under kubernetes your work could be very
useful as well.

https://blog.openshift.com/tag/prometheus/



On Fri, Nov 24, 2017 at 12:54 PM, Lukas Zapletal  wrote:

> > 1. what happened to the PCP approach we talked about in the past?
>
> Thats going in parallel, PCP is just a monitoring framework you can
> integrate with instrumentation data just like any other.
>
> > 2. how would you integrate this to sosreport/foreman-debug? I'm thinking
> of
> > storing the statsd data locally, collecting them with foreman-debug, and
> > then, being able to import them later to the prometheus and other tools.
> Is
> > this how this could work? Any other options?
>
> This is my ultimate goal to have working PCP deployment including
> telemetry data and archives could be collected by foreman-debug, they
> are pretty small (few MBs per day).
>
> > 3. does every host/runtime needs it's own statsd service, or there would
> be
> > one shared process? Asking bith for multi-host and containers use-case
>
> It is up to you if you want one statsd service per guest/container,
> host or subnet. Prometheus endpoint will not require any external
> daemon once sharing metrics is merged into upstream. For this reason,
> statsd will server as a temporary solution and alternative for the
> future.
>
> > The proposal of the telemetry api itself seems reasonable, let's discuss
> > that on an actual PR
>
> Thanks, I hope to finish it this year.
>
> --
> Later,
>   Lukas @lzap Zapletal
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[foreman-dev] DHCP filename option no longer honored

[Lukas Zapletal]

Hey,

I noticed that DHCP filename option is no longer honored in
develop/1.17 branch anymore. This is regression from 1.15/1.16 series,
filed a blocker bug for 1.17:

http://projects.theforeman.org/issues/21975

This breaks UEFI provisioning. I git-bisected

commit e75df1dd3cc30bff2832d337b5bc20bd822e209a
Refs:
Author: Timo Goebel 
AuthorDate: Wed Oct 25 16:26:01 2017 +0200
Commit: Dmitri Dolguikh 
CommitDate: Mon Nov 6 14:28:09 2017 -0800

But I cannot figure it out, help needed. Thanks.


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