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 <ohadl...@gmail.com> wrote:

>
>
> On Thu, Dec 14, 2017 at 5:28 PM, Lukas Zapletal <l...@redhat.com> 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 <thomasmc...@redhat.com>
>> 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 <thomasmc...@redhat.com>
>> 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 <l...@redhat.com>
>> 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

[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 <thomasmc...@redhat.com> 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 <l...@redhat.com> 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] Friday tip of the day: use 'jq' to parse json

[Tom McKay]

@daviddavis reminded me of a nice utility I learned about recently: jq[1].
I use it quite often in scripts involving container images where I need the
long sha256 to reference them.

sudo skopeo inspect --raw docker-daemon:
satellite.example.com:5000/examplecorp-docker_hub-alpine:3.4 | jq '.config
| .digest'

Enjoy!

[1] https://stedolan.github.io/jq/tutorial/

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

Re: [foreman-dev] Nominating cfouant for write access to hammer-cli-katello

[Tom McKay]

+1

On Tue, Nov 21, 2017 at 11:55 AM, Chris Roberts 
wrote:

> +1 from me
>
> On Tuesday, November 21, 2017 at 11:40:48 AM UTC-5, Andrew Kofink wrote:
>>
>> I hereby nominate Christine Fouant to gain commit access to
>> hammer-cli-katello. She currently has 12 merged PRs
>> 
>>  and
>> has helped to review 11 merged PRs
>> 
>> .
>>
>> Let the +/-1's begin!
>>
>> --
>> Andrew Kofink
>> ako...@redhat.com
>> IRC: akofink
>> Software Engineer
>> Red Hat Satellite
>>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [foreman-dev] Re: [UX] Facets and Host UI - roadmap discussion.

[Tom McKay]

Perhaps another (or additional) approach to consider is having different
"views" of the objects.

Consider hosts currently. Depending on the user's role for that moment, the
information and flows needed will be vastly different. The first engineer
may, for example, be the provisioning one. Perhaps the puppet flow is
paramount, or perhaps it's ansible, or whatever. This engineer doesn't need
or care about the other flavors. Next task for this engineer, or a
different one, is to confirm subscriptions. Another task is to check on
package versions. If I could choose which "view" I wanted for the
particular task of the day, that would be great.

The implementation could simply be that the main table had different view
choices (which columns to show) which would then lead to different
click-through pages.

As a plugin writer, I may wish to provide a view entirely my own.
Alternatively, I may wish to be included in details on other views. To me
both inline (deface style) and additional tabs (easier) are needed but
cramming every aspect of a host into a single view is not ideal.


On Wed, Nov 15, 2017 at 8:24 AM, Tomer Brisker  wrote:

> On Wed, Nov 15, 2017 at 2:23 PM,   wrote:
> >
> > Marek, you lead me to an interesting conclusion:
> >
> > I think we have to distinguish two things here - there are workflows
> (such
> > as provisioning, config management, fact reporting) and there are
> > information aspects.
> > An information aspect is a set of properties that describe a host in
> > different system. For example puppet facet would store all properties
> that
> > are needed to describe a host in puppet. Ovirt facet would store all
> > properties that describe the host in ovirt system.
> > Workflow, on the other hand, is a set of actions that needed to be taken
> in
> > a certain order to achieve some operational goal. Examples to that would
> be
> > provisioning - a set of actions that involve different systems (dhcp,
> dns,
> > vm infrastructure and OS installer) that result in a fully operational
> > server. Another example would be monitoring - in this case we will want
> > multiple systems (like puppet's facter, vm's power status e.t.c.) to
> report
> > to the user.
> >
> > Now, once we have those concepts, we can try and translate this into the
> UI:
> > In my opinion, data entry should be done from screens centered on
> > information aspects, regardless of the workflows where this information
> > could be used. On the other hand each workflow deserves a "summary" read
> > only screen, where we will combine data from multiple facets to show
> which
> > data would be used for that particular workflow.
>
> I have to disagree on this point. Users shouldn't care about the
> "behind the scenes" of Foreman. They want a host provisioned in their
> environment and don't care if we store the data needed for that in 1
> table or 10. The most important point is that the user's workflow is
> easy as possible for the majority of cases, with ability to add more
> information if needed in special cases. Entering a lot of info that
> may or may not be needed before they can take any action with that
> info feels to me like more complication, not less.
>
> >
> > From a more practical  point of view, our current screens serve both
> > workflows and data entry. It means that we have to establish for each
> screen
> > what it tries to achieve - either it's a data entry page, such as host's
> > new\edit form or it's a workflow preview/result page such as host show
> page.
> > Data entry pages should be rigidly grouped by facets, but workflow pages
> > should be extensible, so each facet will be able to show relevant
> > information on the same page.
> >
> > How does this sound to you?
> > Roxanne, does it fit with your vision of form's next generation?
> >
> >
> >
> > On Wednesday, November 15, 2017 at 8:33:35 AM UTC+2, Marek Hulan wrote:
> >>
> >> I think these screenshots illustrate that pure option 2 can have
> negative
> >> impact on usability. If I'm a puppet user, the puppet environment is one
> >> of
> >> the most important thing to set. Having it in last tab completely
> separate
> >> from hostgroup does not feel right. If some field of facet is part of
> >> provisioning workflow, it should be extending provisioning UI/facet.
> >> Another example from content management, the content source is
> definitely
> >> a
> >> part provisioning, I want to be able to choose content view as an
> >> installation medium.
> >>
> >> --
> >> Marek
> >>
> >> --
> >> Marek
> >>
> >>
> >>
> >> On November 12, 2017 19:36:14 ssh...@redhat.com wrote:
> >>
> >> >
> >> > OK, I have managed to create some screenshots of the before and after
> >> > state. Please don't judge the styling - it's more about the technical
> >> > abilities than the styling.
> >> >
> >> > I will take Puppet as an example. Let's say we have puppet facet that
> >> > has
> >> > the following data: puppet environment, puppet proxy 

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

[Tom McKay]

+2 thanks for your contributions!

On Wed, Aug 2, 2017 at 9:34 AM, Christine Fouant  wrote:

> +1
>
> On Wed, Aug 2, 2017 at 9:26 AM, John Mitsch  wrote:
>
>> +1 You've made a lot of good contributions to forklift!
>>
>> John Mitsch
>> Red Hat Engineering
>> (860)-967-7285 <(860)%20967-7285>
>> irc: jomitsch
>>
>> On Wed, Aug 2, 2017 at 8:57 AM, Ewoud Kohl van Wijngaarden <
>> ew...@kohlvanwijngaarden.nl> wrote:
>>
>>> On Wed, Aug 02, 2017 at 02:45:52PM +0200, Evgeni Golov wrote:
>>>
 I would like to request write access to forklift.

>>>
>>> Big +1 Evgeni has shown great insight in details with his reviews and
>>> high quality PRs.
>>>
>>> I have 19 merged PRs [1] resulting in 19 commits [2].
 If I count it right, I also somehow reviewed 7 PRs [3].

 TIA
 Evgeni

 [1] https://github.com/theforeman/forklift/pulls?page=1=is%3Ap
 r+author%3Aevgeni=%E2%9C%93
 [2] https://github.com/theforeman/forklift/commits?author=evgeni
 [3] https://github.com/theforeman/forklift/pulls?utf8=%E2%9C%93;
 q=involves%3Aevgeni%20is%3Apr%20

>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "foreman-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to foreman-dev+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "foreman-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to foreman-dev+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
>
> Christine Fouant
>
> Software Engineer
>
> Red Hat
>
> 
> 
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and 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] Proposal: Update Pulp to 2.13.2 in Katello 3.4

[Tom McKay]

+1 There are a number of fixes in pulp-2.13 related to syncing container
images from registries. The schema-2 will perhaps cause some visual oddness
in UI but not blocker to functionality. I would suggest raising the
priority of those issues for fixing by katello-3.15.

On Fri, Jun 30, 2017 at 9:11 AM, Justin Sherrill 
wrote:

> +1, there is a nasty bug that prevents the syncing of some yum repos which
> sadly isn't being backported.  That seems severe enough to warrant pulling
> it in IMHO.
>
> Justin
>
> On 06/28/2017 08:36 PM, Eric D Helms wrote:
>
> Devs,
>
> I am proposing to update Katello 3.4 to Pulp 2.13.2 in order to pull in a
> number of fixes that are affecting users. These updates would move us to
> the most recent stable release of Pulp and prevent users from having to do
> work arounds to fix repositories that occasionally break.
>
> One question is around changes to how Docker Schema V2 are handled and are
> addressed by the open PR [1]. The inclination is to include that change
> along with the update.
>
> If anyone has any objects, questions or approval please speak up. This
> would most likely be done as a stand-alone release update to limit the
> amount of change.
>
> [1] https://github.com/Katello/katello/pull/6775
>
> --
> Eric D. Helms
> Red Hat Engineering
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [foreman-dev] [Deep Dive] Vertical Navigation Proposal, with Rox & Serena

[Tom McKay]

Some additional info from the cockpit project which makes use of patternfly
as well:
https://github.com/cockpit-project/cockpit/wiki/Feature:-Task-Switcher


On Wed, Jun 21, 2017 at 11:58 AM, Greg Sutcliffe 
wrote:

> Hi all,
>
> A while back there was a proposal for a vertical navigation for Foreman
> [1,2]. This has been rumbling on for a while, so I felt it might be
> time to shine a spotlight on it and get some fresh voices in the
> discussion. When it comes to UI changes though, I find screenshots hard
> to visualize, so perhaps a live demo is in order... :P
>
> Accordingly, there will be a deep dive on Tuesday where Rox and Serena
> will spend some time talking about what they feel is wrong with our
> current UI (and horizontal UIs in general), how moving to a vertical
> navigation helps, how it worked out for a couple of other communities,
> and how it *might* look for us.
>
> https://www.youtube.com/watch?v=hQwJ11GYfjY
>
> To be clear, these are still *proposals* at this stage, and we
> definitely want to hear from people about how they feel on this - what
> you feel is wrong with the current UI, and how we might fix it. This is
> one approach, but perhaps you have other suggestions :)
>
> Feel free to join us live and ask questions to Rox & Serena via the
> usual IRC or YouTube methods, or if you catch it later, we can continue
> the discussion here on the mailing list.
>
> Thanks!
> Greg
>
> 1 https://groups.google.com/d/topic/foreman-dev/2dERjSniGzc/discussion
> 2 https://github.com/theforeman/foreman/pull/4302
>
> --
> IRC / Twitter: @gwmngilfen
> Diaspora: gwmngil...@joindiaspora.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[foreman-dev] redmine issues for failing forklift devel?

[Tom McKay]

Are there specific redmine issues tracking the failing forklift devel
failure? This is impacting closing out work for releases.

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

[Tom McKay]

I'd like to make the katello pool model export api json via rabl but the
path is incorrect. I'm not sure what the correct solution is, though.
Should plugin models register their rabl path or something?

There isn't a redmine category for foreman-hooks plugin, where do issues go?

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

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

Re: [foreman-dev] [RFC] HTTP proxy for requests

[Tom McKay]

As a dev I am curious how this is handled in our code. Does every usage of
RestClient need to know about the existence of a proxy? Are there multiple
proxies for different aspects (eg. https://cdn.redhat.com vs.
https://myinternalserver.example.com)?

On Thu, Apr 20, 2017 at 8:43 AM, Timo Goebel  wrote:

> Hi,
>
> Am 20.04.17 um 13:06 schrieb Sebastian Gräßl:
>
>> How common is a setup where external resources requiring HTTP are used
>> with Foreman behind a HTTP proxy?
>>
>> I believe, this is very common in enterprise environments. Usually any
> internet access is blocked for security reasons and only connections via a
> proxy server are allowed. The proxy ususally does a MITM attack to be able
> to investigate encrypted traffic. While this does make sense in some cases,
> don't get me started why it does not make any sense in others.
>
> Comments?
>>
>
> I think especially access to all the docker registries out there is
> something a corporate it-security team would want to go through a proxy
> server. Setting a proxy server on a server via environment variables
> (http_proxy) is quite easy with systemd unit files. However that may lead
> to problems when the client doesn't respect the 'no_proxy' environment
> variable and suddenly all requests to a smart proxy are routed via the http
> proxy. This is problematic when smart-proxy is on the same network and not
> reachable via the proxy server.
> I personally prefer only to have an explicit option in a settings file.
>
> - Timo
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[Tom McKay]

Can we get the tests into bats instead of non-live-server? I think that's
the only way issues with authorization, etc. are going to be found. I agree
all the modules should be part of the suite.

On Wed, Mar 29, 2017 at 5:48 PM, Andrew Kofink  wrote:

> Hello CLI maintainers,
>
> (TL;DR I'm tired of broken tests in hammer-cli-katello due to hammer-cli
> changes)
>
> We have a complex dependency structure between our CLI libraries
> (hammer-cli, hammer-cli-foreman, hammer-cli-katello, csv, admin, etc.), and
> it's not necessarily immune to changes in lower projects (i.e. hammer-cli).
> An example is this recent PR (https://github.com/theforeman
> /hammer-cli/pull/233) that slightly changes the options/all_options
> methods in the abstract command. This caused failures in hammer-cli-katello
> where we override/extend those methods, and I had to open a PR to address
> the changes.
>
> I'd like to start a discussion on ways to keep this from happening in the
> future. Some solutions I've thought of include (1) mentioning people on PRs
> that have the potential to break dependent projects and (2) running
> dependent projects' tests when a PR is submitted.
>
> (1) is not very robust. People can easily forget to mention others, and
> it's difficult to remember all the appropriate people to mention.
>
> (2) seems like more of a pain for maintainers of the lower projects
> (hammer-cli). If we went with this, it would still be up to the dependent
> projects to update to adapt to the changes in hammer-cli. It has the
> benefit of immediately alerting the maintainers that a breaking change is
> incoming. Overall, the hammer tests run in seconds; I think
> hammer-cli-foreman is the longest-running at ~120 seconds. hammer-cli runs
> in less than a second, and hammer-cli-katello runs in about 5 seconds.
>
> Let me know what you think!
>
> - Andrew
>
> --
> Andrew Kofink
> akof...@redhat.com
> IRC: akofink
> Associate Software Engineer
> Red Hat Satellite
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [foreman-dev] Seeding templates overrides custom changes - should we lock templates we ship?

[Tom McKay]

+1 to locking

I have messed up a production install by changing a template for personal
use, not realizing that they span other orgs... oops!

On Fri, Feb 17, 2017 at 9:04 AM, Marek Hulán  wrote:

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

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

Re: [foreman-dev] Host Creation

[Tom McKay]

I like the "add" buttons (eg. operating system) but there were some
resources that didn't have add buttons (eg. partition tables). Should all
of the associated resources have buttons? Not UX specifically, but it would
also be helpful if the choice lists were made api calls to populate choices
when opened. This way when a resource is added (perhaps on a different
browser page) that resource is selectable without a page refresh (very
painful in current new host ui).

I would also note that it is not uncommon, at least for me, to have the
resource already existing (ie. don't need to create it) but it is either in
the wrong org/loc or missing the association (eg. template not associated
correctly). How would this case be handled?

Highlighting the fields red is great but when does that happen? Is the red
persistent (ie. I leave the wizard and return later)? Having the wizard
step number icons change color would be helpful too. Could be red if error
but maybe some other color/style to indicate that the step is incomplete?

Plugins would need to be able to add/remote steps (eg. ansible), and change
forms. Any UX implications?

Is there a pattern for sub-steps? Step 5, parameters, for example has three
subsections. Would there be cases where each of those lettered sections
have their own pages with a step progress bar? (Not sure if needed.)

After I've created a host, does it become a "template" automatically? I
would like a way to, from a host, go to its wizard and duplicate (could be
just change the name and relaunch, for example).

Overall looks great!




On Wed, Feb 8, 2017 at 3:24 PM, Roxanne Hoover  wrote:

> All -
>
> It was identified amongst users that the Host Creation process could use
> some improvement.
>
> I've come up with a design to help reduce confusion, create a
> clearer/unobstructed path to completion and that also integrates some
> features asked for by users.
>
> I feel the design is complete in terms of the knowledge I posses, and am
> now looking for feedback from the community who I'm sure will have thoughts
> - technical or otherwise -  I hadn't yet considered.
>
> Looking forward to any feedback.
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and 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] disable logging of GET /notification_recipients

[Tom McKay]

Those two issues are useful but don't really address what I see. I don't
need the server being hammered for notifications every 10 seconds. Some
scaling back would be very welcome.

#18438 is http://theforeman.org/issues/18438 "Bug #18438: Allow adjusting
notification checking period - Foreman"

On Wed, Jan 25, 2017 at 1:49 AM, Ohad Levy <ohadl...@gmail.com> wrote:

>
>
> On Wed, Jan 25, 2017 at 12:52 AM, Tom McKay <thomasmc...@redhat.com>
> wrote:
>
>> My email history search failed but I think there is a way to disable
>> logging of certain api routes; anyone know how?
>>
>> I'd like to suggest that we disable the logging of
>>
>> 2017-01-24T22:51:22 9e5f9d73 [app] [I] Started GET
>> "/notification_recipients" for 127.0.0.1 at 2017-01-24 22:51:22 +
>> 2017-01-24T22:51:22 9e5f9d73 [app] [I] Processing by
>> NotificationRecipientsController#index as */* 2017-01-24T22:51:22
>> 9e5f9d73 [app] [D] Setting current user thread-local variable to admin
>> 2017-01-24T22:51:23 9e5f9d73 [app] [D] Body: {"notifications":[],"total":0}
>> 2017-01-24T22:51:23 9e5f9d73 [app] [I] Completed 200 OK in 26ms (Views:
>> 0.3ms | ActiveRecord: 0.9ms)
>>
>> since my log will be about 99% that after a weekend afk.
>>
>
> there are two redmine issues that will probably help reducing it, [1] and
> [2]. bottom line, it should only request notifications when the user
> session is active and idle time out did not met, I'm uncreatain we should
> disable logging as it can lead to other surprises down the road.. I do
> agree that long term we want to move away from pulling to websocket based
> notifications.
>
> Ohad
>
> [1] http://projects.theforeman.org/issues/18191
> [2] http://projects.theforeman.org/issues/18192
>
>>
>> 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.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and 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] Make container provisioning more like host provisioning?

[Tom McKay]

I don't mean building containers, I mean using prebuilt.

You're right that maybe it shouldn't be like provisioning but more like rex?

The use cases for me are:

1. Run short-lived container that performs some action. I wrap hammer into
a container, add a layer w/ credentials and apipie, then use that to rex
hammer commands against my server. Certainly not a use case for the
foreman-docker plugin.

2. Run long-lived container that provides a service. In my case I run solr
to provide a search engine to pulp's crane. Starting the container has
varied options (storage, etc.). After the container is running it needs to
be further configured, both inside the container and by accessing the api.
I wouldn't use foreman-docker for this unless I had some "provisioning
template" type actions available. This too is probably a better rex use
case, probably in combination with ansible. This is what I have done. I can
also add the ansible role while provisioning a new atomic host to host my
solr container.

3. Run long-lived multiple containers. The projectatomic.io atomic registry
(openshift) is a simple example of this. Certainly wouldn't use
foreman-docker to start the containers in a coordinated fashion. Really not
a great use case for foreman at all but if that's the tool at hand very
doable with rex (again in combination with ansible).

So yeah, maybe containers are nothing like provisioned hosts. :)

On Fri, Feb 3, 2017 at 8:33 AM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:

> On Sun, Jan 29, 2017 at 12:54:48PM -0500, Tom McKay wrote:
> > The foreman-docker container provisioning is not as richly featured as
> host
> > provisioning and it has me thinking what I would do differently.
> >
> > For my case I needed to "docker run" the container and then "docker exec"
> > several commands, and finally curl against it to configure. What I ended
> up
> > doing, which worked beautifully, was to make an ansible role that
> > accomplished all this plus additional steps of modifying the atomic host
> > the container was running on. Magic!
> >
> > I did run into some issues and limitations with foreman-ansible plugin (I
> > had to run ansible manually outside foreman) but overall ansible is the
> > tool for the job.
> >
> > Looking at the ansible modules around docker it's clear that even if I
> had
> > a nice wizard, if that wizard ended up generating me a playbook that I
> > could further modify it would be awesome.
> >
> > I have very little knowledge of puppet and provisioning but I feel that
> > wiring ansible into the container provisioning might be a very powerful
> > introduction to ansible for foreman users.
> >
> > Is this a realistic idea?
>
> I'm wondering if it is a good idea. Containers should be stateless and I
> think what you're describing goes aginst that.
>
> For me the whole idea behind a docker container is that it's prebuilt.
> That's what Dockerfiles are for. In case you are describing building
> images, then I think Packer[1] does something similar to what you want.
>
> [1]: https://www.packer.io/docs/builders/docker.html
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and 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] disable logging of GET /notification_recipients

[Tom McKay]

My email history search failed but I think there is a way to disable
logging of certain api routes; anyone know how?

I'd like to suggest that we disable the logging of

2017-01-24T22:51:22 9e5f9d73 [app] [I] Started GET
"/notification_recipients" for 127.0.0.1 at 2017-01-24 22:51:22 +
2017-01-24T22:51:22 9e5f9d73 [app] [I] Processing by
NotificationRecipientsController#index as */* 2017-01-24T22:51:22 9e5f9d73
[app] [D] Setting current user thread-local variable to admin
2017-01-24T22:51:23 9e5f9d73 [app] [D] Body: {"notifications":[],"total":0}
2017-01-24T22:51:23 9e5f9d73 [app] [I] Completed 200 OK in 26ms (Views:
0.3ms | ActiveRecord: 0.9ms)

since my log will be about 99% that after a weekend afk.

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: Re: Re: [foreman-dev] Notifications API & UI available - quick HOWTO

[Tom McKay]

On Tue, Jan 24, 2017 at 6:55 AM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:

> On Tue, Jan 24, 2017 at 11:32:39AM +0100, Daniel Lobato Garcia wrote:
> > On 01/23, Tom McKay wrote:
> > > + Every notification we add to this system should be required to have a
> > > unique ID based on where it is in the code. This ID could be leveraged
> for
> > > access insights, docs, etc. (Maybe this is already the case?)
> >
> > It's the case - the notification blueprint comes with a 'subject' field
> > which is meant for specifying which object does this notification 'stem
> > from'
>
> I think Tom means a unique code for every notification type, like the
> smart proxy has error codes. To me a subject sounds like the subject of
> an email.
>
>
Yes, I mean unique code for each message type ("XYZ-1234 Capsule '
mycapsule.example.com' is offline"). I could then choose to include/exclude
these error messages from the UI. Perhaps I exclude from the UI and add
that message type to the list of email notifications.

It's great we have a little UI widget but the larger picture of
notifications and their delivery would be good to address too. Unique
message type/id would be an incremental step towards that.

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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] Notifications API & UI available - quick HOWTO

[Tom McKay]

Wish list...

+ Every notification we add to this system should be required to have a
unique ID based on where it is in the code. This ID could be leveraged for
access insights, docs, etc. (Maybe this is already the case?)
+ Dedicated notifications API/CLI/UI to manage notifications and messages
(search, delete older than X, etc.)
+ Ability to subscribe to notifications in the UI (eg. I see a message in
the history that is not normally displayed in the UI, I choose to
"subscribe to message ID=X")

I'm looking forward to a unified notification framework.


On Mon, Jan 23, 2017 at 11:54 AM, Daniel Lobato Garcia <elobat...@gmail.com>
wrote:

> On 01/23, Tom McKay wrote:
> > Is there a dedicated page where these notifications are displayed? For
> > example, if I mark one as "read" and it disappears, where do I go to see
> it
> > in a history view?
>
> It doesn't dissapear, it's displayed but the group isn't in bold anymore
> and it will not display '1 new event'.
>
> It dissapears though when the notification is expired.
>
> >
> > On Fri, Jan 20, 2017 at 12:08 PM, Lukas Zapletal <l...@redhat.com>
> wrote:
> >
> > > When ERROR message appears in Smart Proxy log buffer, we could make a
> > > notification.
> > >
> > > Maybe when a host is discovered, not sure.
> > >
> > > LZ
> > >
> > > On Fri, Jan 20, 2017 at 1:15 PM, Daniel Lobato Garcia
> > > <elobat...@gmail.com> wrote:
> > > > Hi Foreman devs,
> > > >
> > > > Thanks to Gail Steiger and Ohad Levy -
> > > > https://github.com/theforeman/foreman/pull/4170
> > > > https://github.com/theforeman/foreman/pull/3902
> > > >
> > > > https://cloud.githubusercontent.com/assets/
> > > 598891/21989268/91469e06-dc0a-11e6-828f-44d37183c572.png
> > > > https://cloud.githubusercontent.com/assets/
> > > 598891/21989267/91440f06-dc0a-11e6-8940-d1f1a100e79b.png
> > > >
> > > > we have now a fancy-looking notifications drawer in Foreman! It works
> > > > and looks nice, and I'd recommend taking a look at both the React
> > > > implementation and the Rails part as neither are complicated to
> > > > understand in my opinion.
> > > >
> > > > Now, what's this notifications drawer useful for if we don't have any
> > > > notifications? That's where you come into play:
> > > >
> > > > Notifications in Foreman are stored in what we call a
> > > > "NotificationBlueprint", which stores the information about the
> > > > notification (e.g, level, message, subject..). The blueprint should
> > > > contain information about what happened and ideally how to diagnose
> or
> > > > resolve the problem (if it's a problem)
> > > >
> > > > The idea is that plugins or Foreman itself will define these
> blueprints
> > > > somwhere (via the engine, or a db seed, for example).
> > > >
> > > > In order to trigger them, you need to instantiate a Notification
> object
> > > > that uses the NotificationBlueprint you defined. This Notification
> will
> > > > store information related to the recipients (e.g: when will the
> > > > notification expire, who is it meant for, etcetera). This will
> > > > automatically setup the notification for consumption by users.
> > > >
> > > >
> > > >
> > > > Here's some example code:
> > > >
> > > > a = NotificationBlueprint.new(
> > > > :group => 'Hi There',
> > > > :message => "Hello, I'm back",
> > > > :level => 'info',
> > > > :subject => SmartProxy.first,
> > > > :name => 'example',
> > > > :expires_in => 1.hour
> > > > )
> > > > b = Notification.new(
> > > > :notification_blueprint => a,
> > > > :initiator => User.find_by_login('dlobatog'),
> > > > :audience => Notification::AUDIENCE_GLOBAL,
> > > > )
> > > >
> > > > --
> > > >
> > > > What actions would you like to see as notifications in Foreman? We
> want
> > > > the drawer to only contain important information, as to not overwhelm
> > > > the user with notifications.
> > > >
> > > > So things like: 'host failed a puppetrun' is probably too common an
> event
> > > > to have notifications for, but things like 'this T

Re: [foreman-dev] Notifications API & UI available - quick HOWTO

[Tom McKay]

Is there a dedicated page where these notifications are displayed? For
example, if I mark one as "read" and it disappears, where do I go to see it
in a history view?

On Fri, Jan 20, 2017 at 12:08 PM, Lukas Zapletal  wrote:

> When ERROR message appears in Smart Proxy log buffer, we could make a
> notification.
>
> Maybe when a host is discovered, not sure.
>
> LZ
>
> On Fri, Jan 20, 2017 at 1:15 PM, Daniel Lobato Garcia
>  wrote:
> > Hi Foreman devs,
> >
> > Thanks to Gail Steiger and Ohad Levy -
> > https://github.com/theforeman/foreman/pull/4170
> > https://github.com/theforeman/foreman/pull/3902
> >
> > https://cloud.githubusercontent.com/assets/
> 598891/21989268/91469e06-dc0a-11e6-828f-44d37183c572.png
> > https://cloud.githubusercontent.com/assets/
> 598891/21989267/91440f06-dc0a-11e6-8940-d1f1a100e79b.png
> >
> > we have now a fancy-looking notifications drawer in Foreman! It works
> > and looks nice, and I'd recommend taking a look at both the React
> > implementation and the Rails part as neither are complicated to
> > understand in my opinion.
> >
> > Now, what's this notifications drawer useful for if we don't have any
> > notifications? That's where you come into play:
> >
> > Notifications in Foreman are stored in what we call a
> > "NotificationBlueprint", which stores the information about the
> > notification (e.g, level, message, subject..). The blueprint should
> > contain information about what happened and ideally how to diagnose or
> > resolve the problem (if it's a problem)
> >
> > The idea is that plugins or Foreman itself will define these blueprints
> > somwhere (via the engine, or a db seed, for example).
> >
> > In order to trigger them, you need to instantiate a Notification object
> > that uses the NotificationBlueprint you defined. This Notification will
> > store information related to the recipients (e.g: when will the
> > notification expire, who is it meant for, etcetera). This will
> > automatically setup the notification for consumption by users.
> >
> >
> >
> > Here's some example code:
> >
> > a = NotificationBlueprint.new(
> > :group => 'Hi There',
> > :message => "Hello, I'm back",
> > :level => 'info',
> > :subject => SmartProxy.first,
> > :name => 'example',
> > :expires_in => 1.hour
> > )
> > b = Notification.new(
> > :notification_blueprint => a,
> > :initiator => User.find_by_login('dlobatog'),
> > :audience => Notification::AUDIENCE_GLOBAL,
> > )
> >
> > --
> >
> > What actions would you like to see as notifications in Foreman? We want
> > the drawer to only contain important information, as to not overwhelm
> > the user with notifications.
> >
> > So things like: 'host failed a puppetrun' is probably too common an event
> > to have notifications for, but things like 'this TFTP proxy went down'
> > or 'your RH subscription is about to expire' is a much more important
> > notification that should show up. A cronjob could check out the health
> > of your infrastructure to add these notifications, or ... do you have
> > any ideas? Please reply in this thread as I'd love to see the drawer
> > getting some use ASAP for 1.15 :)
> >
> > Best,
> >
> > --
> > Daniel Lobato Garcia
> >
> > @dLobatog
> > blog.daniellobato.me
> > daniellobato.me
> >
> > GPG: http://keys.gnupg.net/pks/lookup?op=get=0x7A92D6DD38D6DE30
> > Keybase: https://keybase.io/elobato
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "foreman-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to foreman-dev+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> 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] Is this the new UI style from patternfly?

[Tom McKay]

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

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

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

Re: [foreman-dev] setting up rex w/ katello dev forklift

[Tom McKay]

I see ssh now after a fresh forklift dev. I will post custom playbooks used
for feedback.

On Tue, Jan 10, 2017 at 3:45 PM, Tom McKay <thomasmc...@redhat.com> wrote:

>
>
> yum install tfm-rubygem-foreman_remote_execution
> rubygem-smart_proxy_remote_execution_ssh
> added to katello-devel-answers.yaml
> still no rex options
>
>
> On Tue, Jan 10, 2017 at 3:03 PM, Stephen Benjamin <step...@redhat.com>
> wrote:
>
>>
>>
>> - Original Message -
>> > From: "Tom McKay" <thomasmc...@redhat.com>
>> > To: foreman-dev@googlegroups.com
>> > Sent: Tuesday, January 10, 2017 1:59:00 PM
>> > Subject: Re: [foreman-dev] setting up rex w/ katello dev forklift
>> >
>> > Yes, I have the rex gem as noted in original post. The missing steps are
>> > how to configure the smart proxy to have rex available.
>> >
>>
>> Can you try this:
>>
>>   echo 'foreman_proxy::plugin::remote_execution::ssh: false' >>
>> /etc/foreman-installer/scenarios.d/katello-devel-answers.yaml
>>
>>
>> And see if that's enough to get the options?
>>
>>
>> Once you do that you should be able to run:
>>
>>   foreman-installer --enable-foreman-proxy-plugin-remote-execution-ssh
>>
>>
>>
>>
>> > On Tue, Jan 10, 2017 at 1:42 PM, Stephen Benjamin <step...@redhat.com>
>> > wrote:
>> >
>> > >
>> > >
>> > > - Original Message -
>> > > > From: "Ewoud Kohl van Wijngaarden" <ew...@kohlvanwijngaarden.nl>
>> > > > To: foreman-dev@googlegroups.com
>> > > > Sent: Tuesday, January 10, 2017 12:14:18 PM
>> > > > Subject: Re: [foreman-dev] setting up rex w/ katello dev forklift
>> > > >
>> > > > On Tue, Jan 10, 2017 at 11:50:04AM -0500, Tom McKay wrote:
>> > > > > I'm trying to figure out the steps to get rex working with a dev
>> > > forklift.
>> > > > > Here's what I have so far...
>> > > > >
>> > > > > vagrant up devbox
>> > > > > sshfs mount in git checkout, which includes rex plugin
>> > > > > rake katello:reset
>> > > > > hammer csv smart-proxies to add back smart proxy on 9090
>> > > > > rake db:seed
>> > > > > rake db:migrate
>> > > > > yum install rubygem-smart_proxy_remote_execution_ssh
>> > > > > mkdir ~foreman-proxy/.ssh chown foreman-proxy ~foreman-proxy/.ssh
>> sudo
>> > > -u
>> > > > > foreman-proxy ssh-keygen -f ~foreman-proxy/.ssh/id_rsa_for
>> eman_proxy
>> > > -N ''
>> > > > > systemctl restart foreman-proxy.service
>> > > > >
>> > > > > I was hoping that the foreman-installer would have the necessary
>> flags
>> > > to
>> > > > > just make it work but I see no remote-execution flags at all in
>> > > > > foreman-installer --help
>> > > > >
>> > > > > Does anyone have a forklift playbook that wires all this up
>> correctly?
>> > > >
>> > > > Looks like the katello scenario does expose it:
>> > > >
>> > > > https://github.com/Katello/katello-installer/blob/
>> > > 9d08de2589d7a3c01f9965fa0aaf5f86be992b9b/config/katello-answ
>> ers.yaml#L68
>> > > >
>> > > > But katello-devel doesn't:
>> > > >
>> > > > https://github.com/Katello/katello-installer/blob/
>> > > 9d08de2589d7a3c01f9965fa0aaf5f86be992b9b/config/katello-deve
>> l-answers.yaml
>> > > >
>> > > > For for me worked was:
>> > > >
>> > > > echo '  foreman::plugin::remote_execution: false' >>
>> > > > /etc/foreman-installer/scenarios.d/katello-devel-answers.yaml
>> > > >
>> > > > Then the option should become visible, but maybe the options aren't
>> in
>> > > > the parser cache because I don't see those.
>> > > >
>> > >
>> > > I answered already on IRC, but this isn't going to work.  If you have
>> a dev
>> > > environment, it's the same process to install any Foreman plugin,
>> check out
>> > > the source and add it to your bundler.d.
>> > >
>> > >http://projects.theforeman.org/projects/foreman/wiki/How_
>> > > to_Create_a_Plugin#Installing-the-plugin
>> &

Re: [foreman-dev] setting up rex w/ katello dev forklift

[Tom McKay]

Yes, I have the rex gem as noted in original post. The missing steps are
how to configure the smart proxy to have rex available.

On Tue, Jan 10, 2017 at 1:42 PM, Stephen Benjamin <step...@redhat.com>
wrote:

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

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

[foreman-dev] setting up rex w/ katello dev forklift

[Tom McKay]

I'm trying to figure out the steps to get rex working with a dev forklift.
Here's what I have so far...

vagrant up devbox
sshfs mount in git checkout, which includes rex plugin
rake katello:reset
hammer csv smart-proxies to add back smart proxy on 9090
rake db:seed
rake db:migrate
yum install rubygem-smart_proxy_remote_execution_ssh
mkdir ~foreman-proxy/.ssh chown foreman-proxy ~foreman-proxy/.ssh sudo -u
foreman-proxy ssh-keygen -f ~foreman-proxy/.ssh/id_rsa_foreman_proxy -N ''
systemctl restart foreman-proxy.service

I was hoping that the foreman-installer would have the necessary flags to
just make it work but I see no remote-execution flags at all in
foreman-installer --help

Does anyone have a forklift playbook that wires all this up correctly?

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

[Tom McKay]

+1 from me as, at a minimum, gives me an idea of who I could ping on IRC to
look at a PR.

On Tue, Dec 6, 2016 at 1:11 PM, Marek Hulán  wrote:

> On úterý 6. prosince 2016 12:37:23 CET Daniel Lobato Garcia wrote:
> > On 12/06, Sean O'Keeffe wrote:
> > > Hows this going for everybody? I personally quite like it
> >
> > Personally it's just noise for me, but if it works for some people it
> > causes no harm
>
> +1, I'm failing to get time for reviews and this does not help me, but I'm
> ok
> with it pinging me if it helps others.
>
> --
> Marek
>
> >
> > > On Fri, Oct 28, 2016 at 12:36 PM, Greg Sutcliffe
> > > 
> > >
> > > wrote:
> > > > On 27 October 2016 at 14:55, Ohad Levy  wrote:
> > > >> On Mon, Oct 17, 2016 at 4:02 PM, Greg Sutcliffe
> > > >>  > > >>
> > > >> > wrote:
> > > >>> On 13 October 2016 at 13:28, Eric D Helms 
> wrote:
> > >  This has been turned on for the Katello repo, if devs find it
> needs
> > >  tweaking there is a configuration file that can be added (
> > >  https://github.com/facebook/mention-bot#configuration).
> > > >>>
> > > >>> How's that going for you?
> > > >>>
> > > >>> Dominic or Ohad, could you turn it on for the other repos
> mentioned,
> > > >>> as
> > > >>> a trial? Thanks!
> > > >>
> > > >> Done.
> > > >
> > > > Thanks. It's already pinged me for a review, so that was cool.
> > > >
> > > > Lets see how it goes for a few weeks and we can see if we want to
> expand
> > > > to other repos. Feedback welcome as we go :)
> > > >
> > > > Greg
> > > >
> > > > --
> > > > You received this message because you are subscribed to the Google
> > > > Groups
> > > > "foreman-dev" group.
> > > > To unsubscribe from this group and stop receiving emails from it,
> send
> > > > an
> > > > email to foreman-dev+unsubscr...@googlegroups.com.
> > > > For more options, visit https://groups.google.com/d/optout.
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> Groups
> > > "foreman-dev" group. To unsubscribe from this group and stop receiving
> > > emails from it, send an email to
> > > foreman-dev+unsubscr...@googlegroups.com. For more options, visit
> > > https://groups.google.com/d/optout.
> >
> > --
> > Daniel Lobato Garcia
> >
> > @dLobatog
> > blog.daniellobato.me
> > daniellobato.me
> >
> > GPG: http://keys.gnupg.net/pks/lookup?op=get=0x7A92D6DD38D6DE30
> > Keybase: https://keybase.io/elobato
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[foreman-dev] assistance adding new models and migrations

[Tom McKay]

In the spirt of "teach me to fish", can someone guide me on how best to add
new entries to the database from some new models I need? I am adding
content view filters that will limit docker tags[1]. Similar models already
exist for rpm packages so I had a good place to start, but I'm struggling
to know what the migrations should be.

Thanks!


[1]
https://github.com/Katello/katello/compare/patternfly-compliance...thomasmckay:docker-cv-filter

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

[Tom McKay]

w/ @ewoud help all good! I'll comment on PR and go from there.
++ for the help

On Sat, Oct 22, 2016 at 12:31 PM, Eric D Helms <eric.d.he...@gmail.com>
wrote:

> Off the top of my head not sure, try using Puppet 3?
>
> On Oct 22, 2016 12:03 PM, "Tom McKay" <thomasmc...@redhat.com> wrote:
>
>>
>>
>> On Sat, Oct 22, 2016 at 10:28 AM, Eric D Helms <ericdhe...@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Sat, Oct 22, 2016 at 9:35 AM, Tom McKay <thomasmc...@redhat.com>
>>> wrote:
>>>
>>>> I will try with your PR...
>>>>
>>>> I see the katello_devel/tasks/main.yml runs the installer. How do other
>>>> playbooks add to this? This is probably also applicable to my
>>>> atomic_registry playbook as well: If I wanted to have it alter the
>>>> parameters to the foreman-installer (ie. change registry port), how is that
>>>> accomplished? Also need to enable ostree.
>>>>
>>>
>>> I have updated my PR to make use of Stephen's new foreman_installer role
>>> that centralizes calls to foreman_installer. Given that you can run
>>> multiple playbooks, and that our installer is idempotent you have a few
>>> options:
>>>
>>>  1) Use the foreman_installer_options under 'variables' section in the
>>> box definition similar to what oyu have below (that ought to work with my
>>> refactor)
>>>
>>
>> This option seems most appropriate so went with that.
>>
>> First run I got puppet_repositories_version is undefined. I defined it to
>> 4, then next run I get "bin/sh: /opt/puppetlabs/puppet/bin/gem: No such
>> file or directory".
>>
>> Any pointers on that?
>>
>> I am on the atomic-registry PR and then I rebased it to your PR. Here is
>> the boxes.yaml
>>
>> registry:
>>   box: centos7
>>   ansible:
>> group: 'devel'
>> variables:
>>   katello_devel_github_username: "thomasmckay"
>>   foreman_installer_module_prs: "katello/capsule/101"
>>   foreman_installer_options: "--capsule-docker-registry-port=5001"
>>   atomic_registry_registry_port: "5000"
>>   puppet_repositories_version: 4
>> playbook:
>> - 'playbooks/devel.yml'
>> - 'playbooks/katello_atomic_registry.yml'
>>
>>
>>  2) Call the foreman-installer AFTER the devel setup with the options you
>>> need (the installer stores all the previous, so you ought to be able to run
>>> it again, updating any new options you want)
>>>  3) Create a new playbook that you configure with everything you need
>>>
>>>
>>> Try re-running what you have against my updates to my PR. Note that I
>>> changed the playbook to simply 'devel'
>>>
>>>
>>>
>>>>
>>>> I can be on IRC today, if that is easier.
>>>>
>>>> Running these PRs together:
>>>> https://github.com/Katello/forklift/pull/279
>>>> https://github.com/Katello/forklift/pull/325
>>>>
>>>> Fatal: [registry]: FAILED! => {"failed": true, "msg": "The conditional
>>>> check 'skip_installer == False' failed. The error was: error while
>>>> evaluating conditional (skip_installer == False): 'skip_installer' is
>>>> undefined\n\nThe error appears to have been in
>>>> '/home/thomasmckay/code/forklift/playbooks/roles/katello_devel/tasks/main.yml':
>>>> line 12, column 3, but may\nbe elsewhere in the file depending on the exact
>>>> syntax problem.\n\nThe offending line appears to be:\n\n\n- name: 'Run
>>>> devel installer'\n ^ here\n"}
>>>>
>>>> registry:
>>>>   box: centos7
>>>>   ansible:
>>>> group: 'devel'
>>>> variables:
>>>>   katello_devel_github_username: "thomasmckay"
>>>>   foreman_installer_module_prs: "katello/capsule/101"
>>>>   foreman_installer_options: "--capsule-docker-registry-port=5001"
>>>>   atomic_registry_registry_port: "5000"
>>>> playbook:
>>>> - 'playbooks/katello_devel.yml'
>>>> - 'playbooks/katello_atomic_registry.yml'
>>>>
>>>>
>>>>
>>>> On Sat, Oct 22, 2016 at 8:58 AM, Eric D Helms <ericdhe...@gmail.com>
>>>> wrote:
>>>>
>>>>> I think you have a couple options:
&

Re: [foreman-dev] help using forklift for katello dev box

[Tom McKay]

I will try with your PR...

I see the katello_devel/tasks/main.yml runs the installer. How do other
playbooks add to this? This is probably also applicable to my
atomic_registry playbook as well: If I wanted to have it alter the
parameters to the foreman-installer (ie. change registry port), how is that
accomplished? Also need to enable ostree.

I can be on IRC today, if that is easier.

Running these PRs together:
https://github.com/Katello/forklift/pull/279
https://github.com/Katello/forklift/pull/325

Fatal: [registry]: FAILED! => {"failed": true, "msg": "The conditional
check 'skip_installer == False' failed. The error was: error while
evaluating conditional (skip_installer == False): 'skip_installer' is
undefined\n\nThe error appears to have been in
'/home/thomasmckay/code/forklift/playbooks/roles/katello_devel/tasks/main.yml':
line 12, column 3, but may\nbe elsewhere in the file depending on the exact
syntax problem.\n\nThe offending line appears to be:\n\n\n- name: 'Run
devel installer'\n ^ here\n"}

registry:
  box: centos7
  ansible:
group: 'devel'
variables:
  katello_devel_github_username: "thomasmckay"
  foreman_installer_module_prs: "katello/capsule/101"
  foreman_installer_options: "--capsule-docker-registry-port=5001"
  atomic_registry_registry_port: "5000"
playbook:
- 'playbooks/katello_devel.yml'
- 'playbooks/katello_atomic_registry.yml'



On Sat, Oct 22, 2016 at 8:58 AM, Eric D Helms <ericdhe...@gmail.com> wrote:

> I think you have a couple options:
>
>  1) Use my PR and review it to see about achieving what you want
>  2) Spin up a dev box and then 'ansible-playbook -l registry
> playbooks/atomic_registry.yaml'
>
>
> On Sat, Oct 22, 2016 at 8:32 AM, Tom McKay <thomasmc...@redhat.com> wrote:
>
>> I see... I'm trying to turn this into a dev install so that I can
>> hopefully turn off selinux and have it actually work:
>>
>> registry:
>>   box: centos7
>>   ansible:
>> group: 'server'
>> variables:
>>   foreman_installer_module_prs: "katello/capsule/101,theforema
>> n/foreman_proxy/303"
>>   foreman_installer_options: "--capsule-docker-registry-port=5001"
>>   atomic_registry_registry_port: "5000"
>> playbook:
>> - 'playbooks/katello.yml'
>> - 'playbooks/katello_atomic_registry.yml'
>>
>>
>> On Sat, Oct 22, 2016 at 8:11 AM, Eric D Helms <ericdhe...@gmail.com>
>> wrote:
>>
>>> My PR to move the devel setup to Ansible has not been merged yet (
>>> https://github.com/Katello/forklift/pull/279) so what you have is still
>>> valid. Which is why I ask what the issue you are running in to is.
>>>
>>> On Sat, Oct 22, 2016 at 8:08 AM, Tom McKay <thomasmc...@redhat.com>
>>> wrote:
>>>
>>>> I was told the 'options' section is no longer relevant. I'd just like
>>>> to know how to convert this old format to new.
>>>>
>>>> On Sat, Oct 22, 2016 at 8:03 AM, Eric D Helms <eric.d.he...@gmail.com>
>>>> wrote:
>>>>
>>>>> What's actually broken though?
>>>>>
>>>>> On Oct 22, 2016 7:48 AM, "Tom McKay" <thomasmc...@redhat.com> wrote:
>>>>>
>>>>>> This is my old boxes.yaml stanza, could someone help me translate it
>>>>>> to the latest forklift format? I'm blocked on testing because I can't
>>>>>> disable selinux and so want to set up a new dev box.
>>>>>>
>>>>>> katello:
>>>>>>   box: centos7
>>>>>>   shell: 'yum -y install ruby && cd /vagrant && ./setup.rb'
>>>>>>   installer: >-
>>>>>> --katello-devel-use-rvm=false
>>>>>> --katello-devel-github-username=thomasmckay
>>>>>> --katello-devel-enable-ostree=true
>>>>>>   options: >-
>>>>>> --scenario katello-devel
>>>>>> --disable-selinux
>>>>>> --koji-repos
>>>>>>   memory: 8192
>>>>>>   cpus: 4
>>>>>>   hostname: katello.example.com
>>>>>>   networks:
>>>>>> - type: 'private_network'
>>>>>>   options:
>>>>>> ip: 192.168.100.219
>>>>>> libvirt__network_name: provisioning
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Gr

Re: [foreman-dev] help using forklift for katello dev box

[Tom McKay]

I see... I'm trying to turn this into a dev install so that I can hopefully
turn off selinux and have it actually work:

registry:
  box: centos7
  ansible:
group: 'server'
variables:
  foreman_installer_module_prs:
"katello/capsule/101,theforeman/foreman_proxy/303"
  foreman_installer_options: "--capsule-docker-registry-port=5001"
  atomic_registry_registry_port: "5000"
playbook:
- 'playbooks/katello.yml'
- 'playbooks/katello_atomic_registry.yml'


On Sat, Oct 22, 2016 at 8:11 AM, Eric D Helms <ericdhe...@gmail.com> wrote:

> My PR to move the devel setup to Ansible has not been merged yet (
> https://github.com/Katello/forklift/pull/279) so what you have is still
> valid. Which is why I ask what the issue you are running in to is.
>
> On Sat, Oct 22, 2016 at 8:08 AM, Tom McKay <thomasmc...@redhat.com> wrote:
>
>> I was told the 'options' section is no longer relevant. I'd just like to
>> know how to convert this old format to new.
>>
>> On Sat, Oct 22, 2016 at 8:03 AM, Eric D Helms <eric.d.he...@gmail.com>
>> wrote:
>>
>>> What's actually broken though?
>>>
>>> On Oct 22, 2016 7:48 AM, "Tom McKay" <thomasmc...@redhat.com> wrote:
>>>
>>>> This is my old boxes.yaml stanza, could someone help me translate it to
>>>> the latest forklift format? I'm blocked on testing because I can't disable
>>>> selinux and so want to set up a new dev box.
>>>>
>>>> katello:
>>>>   box: centos7
>>>>   shell: 'yum -y install ruby && cd /vagrant && ./setup.rb'
>>>>   installer: >-
>>>> --katello-devel-use-rvm=false
>>>> --katello-devel-github-username=thomasmckay
>>>> --katello-devel-enable-ostree=true
>>>>   options: >-
>>>> --scenario katello-devel
>>>> --disable-selinux
>>>> --koji-repos
>>>>   memory: 8192
>>>>   cpus: 4
>>>>   hostname: katello.example.com
>>>>   networks:
>>>> - type: 'private_network'
>>>>   options:
>>>> ip: 192.168.100.219
>>>> libvirt__network_name: provisioning
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "foreman-dev" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to foreman-dev+unsubscr...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "foreman-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to foreman-dev+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "foreman-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to foreman-dev+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Eric D. Helms
> Red Hat Engineering
> Ph.D. Student - North Carolina State University
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [foreman-dev] help using forklift for katello dev box

[Tom McKay]

I was told the 'options' section is no longer relevant. I'd just like to
know how to convert this old format to new.

On Sat, Oct 22, 2016 at 8:03 AM, Eric D Helms <eric.d.he...@gmail.com>
wrote:

> What's actually broken though?
>
> On Oct 22, 2016 7:48 AM, "Tom McKay" <thomasmc...@redhat.com> wrote:
>
>> This is my old boxes.yaml stanza, could someone help me translate it to
>> the latest forklift format? I'm blocked on testing because I can't disable
>> selinux and so want to set up a new dev box.
>>
>> katello:
>>   box: centos7
>>   shell: 'yum -y install ruby && cd /vagrant && ./setup.rb'
>>   installer: >-
>> --katello-devel-use-rvm=false
>> --katello-devel-github-username=thomasmckay
>> --katello-devel-enable-ostree=true
>>   options: >-
>> --scenario katello-devel
>> --disable-selinux
>> --koji-repos
>>   memory: 8192
>>   cpus: 4
>>   hostname: katello.example.com
>>   networks:
>> - type: 'private_network'
>>   options:
>> ip: 192.168.100.219
>> libvirt__network_name: provisioning
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "foreman-dev" group.
>> To unsubscribe from this group and 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.

[foreman-dev] help using forklift for katello dev box

[Tom McKay]

This is my old boxes.yaml stanza, could someone help me translate it to the
latest forklift format? I'm blocked on testing because I can't disable
selinux and so want to set up a new dev box.

katello:
  box: centos7
  shell: 'yum -y install ruby && cd /vagrant && ./setup.rb'
  installer: >-
--katello-devel-use-rvm=false
--katello-devel-github-username=thomasmckay
--katello-devel-enable-ostree=true
  options: >-
--scenario katello-devel
--disable-selinux
--koji-repos
  memory: 8192
  cpus: 4
  hostname: katello.example.com
  networks:
- type: 'private_network'
  options:
ip: 192.168.100.219
libvirt__network_name: provisioning

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

[Tom McKay]

I have just recently dusted off a pet project, sample-bastion-plugin[1],
that I had started to use as a model for the generator-bastion[2] work.
While I'm not sure there is anything greatly technical here, it is an
opportunity to cover all aspects of a RoR UI project.

The idea was that I would create a generic sample plugin that followed the
best practices _in all aspects_ of a katello plugin. It would do everything
from rubocop and travis, to testing, models, migrations, and ui. This would
then serve as a template to the 'yo' generator. You could quickly generate
a skeleton plugin with models, controllers, etc.

It's a lot of work and covers a lot of the baseline stuff we devs need to
do and be aware of.

[1] https://github.com/thomasmckay/sample-bastion-plugin
[2] https://github.com/thomasmckay/generator-bastion/tree/plugin

On Thu, Sep 29, 2016 at 11:57 AM, Lukas Zapletal  wrote:

> Hello,
>
> few students of mine are considering doing Diploma Thesis for Red Hat.
> Can you figure out some good Foreman topics? Unfortunately, it looks
> like today UNIX and datacenter administration is uncool, as I have
> learned the other day, so ideally they are looking for:
>
> - JavaScript and UI/UX
> - web app development in general
> - mobile programming
> - iOS / macOS / Swift (need to google that one out)
>
> Ideal task is something isolated, that can be done as a different
> project or plugin. Send me your ideas, 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.
>

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

[Tom McKay]

I guess patches for katello are also needed so still blocked.

On Wed, Sep 14, 2016 at 3:56 AM, Lukas Zapletal  wrote:

> > Hostgroup creation is blocked by ->
> > http://projects.theforeman.org/issues/16532
>
> Yeah, sorry about that, I've changed the attributes of the
> architecture_selected and os_selected to match the media_selected
> implementation to allow pxe_loader hook.
>
> This patch in Foreman core makes forms usable again:
>
> https://github.com/theforeman/foreman/pull/3840
>
> --
> 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] cannot provision w/ foreman

[Tom McKay]

The media selection is unusable on host and host group creation forms in
nightly[1]. I assume foreman-1.13 w/ katello is similarly broken. @partha
is trying to fix it but if a foreman dev familiar with the UI webpack
changes that are the root can help out, that would be much appreciated. I
don't know if bare foreman has issues but failing to provision out of
katello is a blocker.

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

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

[foreman-dev] Re: hammer config :mark_translated: true

[Tom McKay]

https://github.com/theforeman/hammer-cli/pull/216

The :mark_translated: needs to be in :ui: section. Thanks Martin for
pointing that out!

On Tue, Sep 6, 2016 at 7:29 PM, Tom McKay <thomasmc...@redhat.com> wrote:

> :mark_translated: true
>
> How do I get this to work? None of the foreman, katello, or plugin
> commands mark the translations with ><.
>
> [1] https://github.com/theforeman/hammer-cli/commit/
> 6e28b70ff1a05344b0af7abd5a2f660d74ba6df7#diff-
> fdb567676ef7447dc779b6cedb2d4dd6R9
>

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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: error calling hammer.run() from w/in 'hammer csv subscriptions'

[Tom McKay]

Without the lines add_text_domain the errors happen. Could be that katello
is not initialized at the time I am calling hammer.run() for one of its
commands? I'm just guessing at things at this point.

I am on ruby-2.3.1 w/ fast_gettext-1.2.0

On Mon, Sep 5, 2016 at 4:13 AM, Martin Bačovský <martin.bacov...@gmail.com>
wrote:

> Recently there were some changes in how the translation domains are
> handled in hammer with new fast_gettext. See the PR [1] for more details.
> There was hammer 0.8.0 gem released last week containing the changes.
> What hammer version anf fast_gettext do you use?
>
> I checked the hammer-cli-csv PR and I'm not sure why are you adding the
> domain manualy for the second time and not only with 
> HammerCLI::I18n.add_domain
> but it was not necessary for hammer-cli-foreman.
>
>
> [1] https://github.com/theforeman/hammer-cli/commit/6e28b70ff1a0
> 5344b0af7abd5a2f660d74ba6df7
>
>
>
> On Fri, Sep 2, 2016 at 9:44 PM, Tom McKay <thomasmc...@redhat.com> wrote:
>
>> Opened a PR that works but I'd like to understand the problem and what
>> changed, if anyone has any insights.
>> https://github.com/Katello/hammer-cli-csv/pull/121
>>
>> On Fri, Sep 2, 2016 at 1:14 PM, Tom McKay <thomasmc...@redhat.com> wrote:
>>
>>> I get an error "RuntimeError (Current textdomain (nil) was not added,
>>> use FastGettext.add_text_domain !" during a call to hammer.run() from w/in
>>> another hammer command. Effectively 'hammer csv subscriptions' is calling
>>> 'hammer subscription upload' from w/in itself. If I add this code[1] prior
>>> to calling hammer.run() then things work as expected (and as it had
>>> previously).
>>>
>>> What is the proper way to config FastGettext in hammer module?
>>>
>>>
>>> [1] https://github.com/thomasmckay/hammer-cli-csv/blob/fastgette
>>> xt/lib/hammer_cli_csv/subscriptions.rb#L62-L68
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "foreman-dev" group.
>> To unsubscribe from this group and 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] Re: RFC for foreman_api_v3

[Tom McKay]

On Mon, Aug 29, 2016 at 7:33 AM, Tomas Strachota 
wrote:


>> If we decide that jsonapi is the way to go for v3 I think it would
>> be better to implement it as part of the foreman core. We can
>> clearly mark it as devel preview with no guarantees, let it evolve
>> alongside with v2 and freeze when we're happy with it.
>>
>>
>> I don't see the advantage of implementing a new api as part of core
>> until if/when it is stable and has community adoption.
>>
>>
> I think that it can actually attract the community more when it's in the
> core and users/devs can start experimenting with it just by changing the
> version in url. The result is more or less the same. The only difference is
> in entry barriers (installing a plugin vs. changing number in url).
>

Personally I like the API being a plugin that's treated like core in terms
of tests-must-pass, etc. The benefits I can think of at a quick glance:
+ all changes to routes and parameters in one uncluttered place
(uncluttered meaning not a mix of other "core" PRs)
+ all changes to json body output format in one uncluttered place (big
headache currently when data relied on changes)
+ plugin github ack/nack/mergers dedicated devs committed to not breaking
api (these devs know the space and mission statement)


Negatives are:
+ have to submit two PRs, one to foreman one to api plugin, when changes
impacting both
+ would other plugins (katello, rex, etc.) be encouraged/required to have
separate github repo for their APIs too?

Writing a new api via a plugin is not a new idea as several of the
katello/Satellite-6 devs/users/customers have thought about doing this for
some time. I know Joseph's plugin arises from his work but it's great to
see this. I also like that it's based on jsonapi.org which would act as the
arbitrer of disagreements in style and such. Thanks Joseph for starting
this 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] bringing pulp-2.10 into katello

[Tom McKay]

On Wed, Aug 24, 2016 at 5:58 PM, Justin Sherrill <jsher...@redhat.com>
wrote:

> On 08/24/2016 05:48 PM, Tom McKay wrote:
>
>
>
> On Wed, Aug 24, 2016 at 5:36 PM, Chris Duryee <cdur...@redhat.com> wrote:
>
>>
>>
>> On 08/24/2016 05:33 PM, Tom McKay wrote:
>> > Katello and foreman are nearing dev freeze in early September but there
>> are
>> > a few features centered around Atomic Host and Atomic Registry that will
>> > need changes introduced in pulp-2.10. While I understand pulp-2.10 is
>> > currently still in beta, I was hoping we could bring it into katello now
>> > ahead of dev freeze so the dependent integration could be completed.
>> >
>> > If we did bring in pulp-2.10, it would have to be with the understanding
>> > that breakages on both sides would need to be fixed prior to katello
>> > releasing. I know this is usually how things go anyways but I just
>> wanted
>> > to state it up front.
>> >
>> > Also, are there resources to do this work? If I understand things
>> > correctly, it's not just as simple as updating a repo file to point to
>> > pulp-2.10, but that changes to runcible would also need to be made? Is
>> this
>> > something that could be done ASAP? Sooner means more time to shake out
>> > issues.
>>
>> 2.10 should have additive-only changes from 2.9, I don't think runcible
>> would change unless it was to support something new in 2.10.
>>
>
> We would be passing username/password for docker registries w/
> authentication. Not sure if there are other changes too, @partha?
>
>
> Generally when pulling in a new pulp release, we only initially introduce
> changes required to maintain existing functionality.  New functionality is
> added after that is done in one or more PRs.
>
>
Of course, so yes @beav is correct.


>
>
>> >
>> > 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.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and 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] Possible to move redmine Katello project under Foreman?

[Tom McKay]

Thanks @ohadlevy for making this happen.

On Tue, Aug 9, 2016 at 9:29 AM, Tom McKay <thomasmc...@redhat.com> wrote:

> The katello project will be moved under foreman as a sub-project next
> week. If there are any concerns, please speak up before then. Thanks!
>
> On Thu, Aug 4, 2016 at 10:03 AM, Lukas Zapletal <l...@redhat.com> wrote:
>
>> > You do realize that every other plugin except Katello is under the
>> foreman
>> > project in redmine, correct?
>>
>> I haven't realized that, sorry for the noise :-)
>>
>> --
>> 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] conundrum: content host autoheal flag not saved via api

[Tom McKay]

tl;dr - Setting the autoheal on a host via API does not get saved... why?

There is an issue[1] describing the case where changing a (content) host's
autoheal flag via API doesn't actually change the value. I spent some time
last week but am no closer to understanding what is special about this
particular attribute over others. I opened a PR[2] that works... but then
breaks other params. Perhaps this is a clue? Any takers to look at this?

[1] http://projects.theforeman.org/issues/15935
[2] https://github.com/Katello/katello/pull/6256

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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] Possible to move redmine Katello project under Foreman?

[Tom McKay]

The katello project will be moved under foreman as a sub-project next week.
If there are any concerns, please speak up before then. Thanks!

On Thu, Aug 4, 2016 at 10:03 AM, Lukas Zapletal  wrote:

> > You do realize that every other plugin except Katello is under the
> foreman
> > project in redmine, correct?
>
> I haven't realized that, sorry for the noise :-)
>
> --
> 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] syncing content through a capsule

[Tom McKay]

Justin & Brad,
As part of the docker registry work I have the following setup:


+---+   +---+
++
|  https://katello  | <---> |  https://capsule  | <---> |  https://registry
|
+---+   +---+
++

>From a system that can see the capsule, I would like to run:

% hammer repository synchronize \
  --server https://capsule \
  --name docker-repository \
  --source-url https://registry

This would initiate a sync from registry through the capsule to katello.

In addition, I'd like sync plans on the repo to know that the source-url is
through the capsule.

As a user, I want to sync content to katello that is visible only to the
capsule.

How do I accomplish 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] Possible to move redmine Katello project under Foreman?

[Tom McKay]

On Wed, Aug 3, 2016 at 10:26 AM, Lukas Zapletal  wrote:

> > Is there a case for keeping katello separate any longer, or can we
> combine?
>
> Because it's a plugin? And plugins have its own release cadence, own
> planning (Release versions, Target versions) and Categories. I don't see
> enough benefits of merging when I consider all the above.
>
> I don't know, I would not like to see Discovery project merged into the
> Core. I'd like to keep all plugins separate.
>

I'm suggesting that we make katello a subproject of foreman. There are
already plugin subprojects (eg. discovery). By moving it under the single
parent project other redmine features become usable (eg. loading a sprint
with issues from both foreman and katello).

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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] Possible to move redmine Katello project under Foreman?

[Tom McKay]

As we try to work towards better bugzilla and redmine component definitions
and relations, I keep finding myself wishing I could use redmine for both
foreman and katello issues together.

For example, several dev teams are experimenting with redmine "versions"
for their sprints[1]. I don't think that a single version can include
issues from both foreman and katello projects. If katello was a subproject
of foreman, though, then teams could bring any issue into their sprint view.

Is there a case for keeping katello separate any longer, or can we combine?

[1]
http://projects.theforeman.org/projects/foreman/roadmap#Team_Ivan_Iteration_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.

[foreman-dev] Re: adding VCR tests to hammer-cli

[Tom McKay]

https://github.com/Katello/hammer-cli-csv/pull/116

Maybe this is right?

On Fri, Jul 29, 2016 at 4:11 PM, Tom McKay <thomasmc...@redhat.com> wrote:

> I'd like to add VCR tests to hammer-cli-csv[1]. The tests I have currently
> run only against a live server. I was pointed to runcible as an example but
> am a bit overwhelmed by what I need to do in the time I have to do it. Has
> anyone done something similar already? Ideally I'd like to just be able to
> switch the existing tests from live to vcr but maybe that's not the best
> approach.
>
> [1]
> https://github.com/Katello/hammer-cli-csv/blob/master/test/settings_test.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] adding VCR tests to hammer-cli

[Tom McKay]

I'd like to add VCR tests to hammer-cli-csv[1]. The tests I have currently
run only against a live server. I was pointed to runcible as an example but
am a bit overwhelmed by what I need to do in the time I have to do it. Has
anyone done something similar already? Ideally I'd like to just be able to
switch the existing tests from live to vcr but maybe that's not the best
approach.

[1]
https://github.com/Katello/hammer-cli-csv/blob/master/test/settings_test.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] forklift error: Parameter katello-devel-github-username invalid

[Tom McKay]

==> katello: Running shell command: foreman-installer --scenario
katello-devel --scenario katello-devel --katello-devel-use-rvm false
==> katello: stty: standard input: Inappropriate ioctl for device
==> katello: Parameter katello-devel-github-username invalid
==> katello:
==> katello: Error during configuration, exiting

Fresh checkout of forklift then vagrant up katello with this boxes.yaml

katello:
  box: centos7-devel
  installer: '--scenario katello-devel --katello-devel-use-rvm false'
  options: '--disable-selinux --koji-repos'
  memory: 4096
  cpus: 2
  hostname: katello.example.com
  networks:
- type: 'private_network'
  options:
ip: 192.168.111.159
libvirt__network_name: provisioning
libvirt__iface_name: virbr2

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