Re: [foreman-dev] Nominating additional maintainers in foreman-core

[Martin Bačovský]

+1 to both

On Wed, Dec 6, 2017 at 1:53 PM, Eric D Helms  wrote:

> +1 to both!
>
> On Wed, Dec 6, 2017 at 7:51 AM, Adam Ruzicka  wrote:
>
>> +1 to both
>>
>> -- Adam
>>
>>
>> On Wed, Dec 6, 2017 at 1:40 PM, Tomer Brisker 
>> wrote:
>>
>>> Hello,
>>> ​As many of you may have noticed, foreman-core open PR​ count has been
>>> in the area of 100-110 for most of the last few months. There are only a
>>> few people with merge access that actively review PRs, so that the time it
>>> takes for changes to be accepted can take long. I would like to propose
>>> granting merge access to two more members of the community:
>>>
>>> Shimon Shtein - has 75 merged commits [1] and has taken part in the
>>> reviews of 64 merged commits[2].
>>> Michael Moll - has 71 merged commits [3] and has taken part in the
>>> reviews of 130 merged commits[4]. He is also already a long time maintainer
>>> of several of our other repos and has proven to be a responsible maintainer.
>>>
>>> Please send +1/-1 either to the list or to me in private if you prefer.
>>> Per our process, unless I receive any objections within a week, I will
>>> request one of the organization owners to grant them access.
>>>
>>> [1] https://github.com/theforeman/foreman/pulls?q=is%3Apr+author
>>> %3Ashimshtein+is%3Aclosed
>>> [2] https://github.com/theforeman/foreman/pulls?utf8=%E2%9C%93
>>> =is%3Apr+-author%3Ashimshtein+commenter%3Ashimshtein+is%3Aclosed+
>>> ​[3] https://github.com/theforeman/foreman/pulls?utf8=%E2%9C%93
>>> =is%3Apr+author%3Ammoll+is%3Aclosed+
>>> [4]​ https://github.com/theforeman/foreman/pulls?utf8=%E2%9C%93
>>> =is%3Apr+-author%3Ammoll+commenter%3Ammoll+is%3Aclosed+
>>>
>>> --
>>> Have a nice day,
>>> Tomer Brisker
>>> Red Hat Engineering
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "foreman-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to foreman-dev+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "foreman-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to foreman-dev+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Eric D. Helms
> Red Hat Engineering
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[Martin Bačovský]

I prefer 2 with adding new extension points for the individual cases where
necessary.

M.

On Tue, Nov 14, 2017 at 12:45 AM, Walden Raines  wrote:

> I see.  Yeah I'm sticking with option 2, thanks for the screenshots.
>
> Cheers,
> Walden
>
> On Sun, Nov 12, 2017 at 1:36 PM,  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 and puppet ca proxy
>> fields plus a list of puppet classes assigned to the host.
>>
>> Before:
>> The information is spread on multiple screens:
>> Take a look at this screenshot: https://ibb.co/bsXT8G it shows where
>> this information is currently located on the main tab.
>> This screenshot: https://ibb.co/ksuaoG shows the detailed puppet classes
>> view.
>>
>> After:
>> Everything related to puppet is presented on a single tab. This tab can
>> be enabled and disabled based on user's preference - the user can decide to
>> turn puppet management on or off for this host.
>> https://ibb.co/bNnd8G shows the tab when the fields are enabled, and
>> https://ibb.co/eCJ72b shows all the fields disabled.
>>
>> I hope it helps to visualize both options.
>>
>>
>> On Wednesday, November 8, 2017 at 12:08:06 AM UTC+2, Walden Raines wrote:
>>>
>>> Hey Shim,
>>>
>>> Can you please include screenshots (or, even better, a quick video or
>>> gif) of the new UI to make it easier for people to visualize who don't have
>>> the code checked out?
>>>
>>> Assuming I'm understanding your description of the two options, I would
>>> also vote for option #2 as option #1 sounds like it would be very difficult
>>> to ensure a good UI since some other plugin could just put whatever they
>>> want wherever in the UI.
>>>
>>> Thanks,
>>> Walden
>>>
>>>
>>>
>>> On Tue, Nov 7, 2017 at 5:38 AM, Timo Goebel 
>>> wrote:
>>>
 I have been playing with Facets the last few weeks and must say, that
 they are really great. It's pretty easy to add dedicated functionality to
 the host model and I want to use that for some of my plugins (Omaha,
 Monitoring, something new, ...).
 Everything is great so far except for the missing UI hooks Shim
 mentions.

 What I want to do are mostly easy thing, like adding a new tab to the
 host form or host show page. Currently, the only way to do this is using
 deface.
 But this feels pretty hacky to me and isn't good to maintain. I'd
 really appreciate if there were easy and tested hooks for common areas like
 the host show page.

 In my opinion, we are already too late on finishing the facets (and
 Pagelets) integration. Personally, I don't have a strong opinion on either
 option. But prefer the second approach as well.

 In regards to widening the feature gap for a host ux redesign: We have
 to provide extension points anyways. The Foreman community gains a lot of
 value from the rich plugin ecosystem and the possibility to extend Foreman
 fairly easy.
 When we redo the host ux pages, we have to provide extension points.
 This is not a nice-to-have feature, but a must-have in my opinion.

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

[Martin Bačovský]

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

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

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

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

M.



On Fri, Nov 3, 2017 at 7:29 PM, Lukas Zapletal  wrote:

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

Re: [foreman-dev] Nomination for an additional GitHub org owner

[Martin Bačovský]

+1 for @ehelms

On Fri, Jun 23, 2017 at 2:44 PM, Greg Sutcliffe 
wrote:

> Hi all,
>
> Slightly different to our usual "nominate a new commiter" process, but
> I'm wondering if we need to appoint a new owner on our GitHub
> organisation?
>
> Currently, only Dominic and Ohad are owners, and they are both
> frequently busy with other things, which leads to some delays when
> adding in new repos or moving things about. 2 people is also a fairly
> high bus factor. I think it's time we added a third name to the owners
> - we don't have an official process for this, but I'm treating like
> commit access, so here's a nomination email.
>
> Obviously, this is mainly a role for maintenance - creating/forking
> repos, moving them, creating new teams, etc. rather than about merging
> code. I think a we have a few people that would be a good fit - my
> suggestion would be Eric Helms. He's experienced both in our structure
> & in GitHub-y stuff, and is in a different timezone, which helps if
> something comes up out of European hours.
>
> Any comments/concerns/upvotes? :)
>
> Cheers
> Greg
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+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] Speed up rake apipie:cache:index

[Martin Bačovský]

The current state is that the apipie cache consists of  root index page and
page per API resource and method and JSON desription of whole API
(multiplied by number of languages). Currently we build all the resource
specific pages during the package build time. The index and JSON need to
contain all the resources according to current configuration including all
the plugins that extends API. That is the reason we have to build this
during installation.

During my benchmarks the bottleneck was loading the whole rails env. Before
the rake started to generate anything it took almost a minute on average
machine. May be different now though.

Where we can surely spare some time is rpm package installation. Every
plugin extending API calls apipie:rake:index in %postrans resulting in
about 3 consequent redundant calls for default Katello install. If we can
add some state info that index was already built in this RPM transaction we
could spare a few mins.

I'm not sure if JS would help us with creation of the JSON which is the
most used part of the API docs (used for Hammer and bindings), but I can
imagine it could be put together dynamically on first request from pieces
generated during a build time and cached. This way we could avoid index
creation completely.

Martin

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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] Sosreport parsing and import into centralized log manager

[Martin Bačovský]

Hi,

as I promised on yesterday's demo [1] I'm here with some information about
proof of concept I'm currently working on.

I've put together skeleton of tool [2] that is able to parse logs collected
by sosreport or foreman-debug and send the structured log events to the
centralized log manager.

What I have is parser for yum.log (low hanging fruit) and first attempt for
generic syslog parser. Parsing syslog is challenging because many tools is
logging there in different formats but the results seem promising.

The resulting stream of events is in GELF format and can be directed to
Journald, Graylog, Logstash or any other tool with GELF support.

If you are interested in more details, check the readme [2] on GitHub.

My plans are to add importers for more logs and explore what benefits could
such tool bring.

I'd like to know if people find such tool helpful and of course I welcome
any kind of contribution.

Lastly I'd like to stress out that this tool is not intended to become
solution for centralized logging in the Foreman ;)

Have a great day,
Martin



[1] https://youtu.be/Zz0Bgt87wPE?t=42m28s
[2] https://github.com/mbacovsky/grokngelf

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

[Martin Bačovský]

On Fri, Nov 25, 2016 at 3:40 PM, Marek Hulán  wrote:

> Please share your ideas for other structuring or which of schema mentioned
> above you find better. The level of nesting does not matter from technical
> point of view but I think 2 or 3 directories is the limit.
>

I also like the option with provisioning templates being separated by
template kind. It is much easier to navigate through.

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

[Martin Bačovský]

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/
6e28b70ff1a05344b0af7abd5a2f660d74ba6df7



On Fri, Sep 2, 2016 at 9:44 PM, Tom McKay  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  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/
>> fastgettext/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.