Re: [foreman-dev] New T-shirt design

[Martin Bačovský]

On 05/18/2016 04:42 PM, Greg Sutcliffe wrote:

Hi all,

During the FOSDEM / CfgMgmt period we managed to use up pretty much 
all of the current batch of t-shirts, and the time has come to order more.


However, as part of our preparations for Red Hat Summit (more on that 
once it's all organised, but yes - Foreman will be in the Community 
Central part of Summit) we got a new poster out of it. Ohad suggested 
it would look good on our next round of t-shirts, so I thought I'd 
share it with you to see if you agree. Certainly, I like it and would 
wear it ;)


Attached are two versions of the image, with/without frame, flattened 
to 3 colours for t-shirt printing. We still hashing out the final 
pieces, but I'm currently leaning towards:


1. Using the diamond-framed design on the front
2. Putting "Foreman" above it in our usual caps font
3. Just the hard hat and "theforeman.org " on 
the back (one of the criticisms of previous swag was a lack of URLs)


Love it? Hate it? Other comments? :)
--
Greg
IRC: gwmngilfen
--
You received this message because you are subscribed to the Google 
Groups "foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to foreman-dev+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.

I like it and would prefer no frame and "Foreman" or "theforeman.org" below.

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.

Re: [foreman-dev] Katello command line interface/hammer supplement

[Martin Bačovský]

Hey Yoram,

Ballista seems to add useful features. I'm curious what were the reasons
besides the implementation language to not to add this features to
hammer-cli-katello or as a new hammer plugin. If you were considering this
option what were the blockers or biggest pain points that hold you back
from extending Hammer? What can we improve to make it easier to create new
hammer extensions?

Regards,
Martin



On Wed, Jun 15, 2016 at 8:39 AM, Yoram Hekma  wrote:

> Hey all,
>
> I just wanted to show you all a project I and a colleague of mine have
> been working on and has just been added to the "official" Red Hat
> supplemental scripts group on Github. You can find it at
> https://github.com/RedHatSatellite/ballista
>
> Ballista is a tool (so far) primarily aimed at Katello and aims to be a
> supplement to hammer. It started as a tool to recursively publish content
> views and their composites, but it has started growing into a more
> modularized (?) thing that is easily extendable via modules. The
> documentation is not yet up to snuff, but it is actively maintained (and
> used in production environments) and pull requests are always welcome.
>
> Cheers,
> Yoram
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [foreman-dev] Katello command line interface/hammer supplement

[Martin Bačovský]

On Wed, Jun 15, 2016 at 10:12 AM, Yoram Hekma  wrote:

> Our only alternative was to make feature requests for hammer and hope
> someone picks them up since we do not have the knowledge of extending it
> ourselves. Looking at it this way, we figured we might as well write
> something ourselves that may be of use to other people.
>
> I am aware that "We do not master the language the primary tool is written
> in, so we reinvented the wheel" is not really the most solid of reasons,
> but it *is* useful and we do not aim to replace hammer (that would be
> pretty stupid and unfeasible), only provide functionality that hammer does
> not.
>

Thanks for explanation and sharing your tool.
And if you want to give Hammer and Ruby a try let me know ;)

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.

Re: [foreman-dev] Problem make Connection Api with PHP

[Martin Bačovský]

Hello,
I'm not familiar with the python-foreman but the Warning just says that the
API version you are going to use is v1. However the code should still work
as it is just a warning. Are there any other errors?
You can switch to version 2 (which is the current default and recommended)
using api_version parameter [1]

[1]
https://github.com/david-caro/python-foreman/blob/master/foreman/client.py#L554

Martin

On Fri, Aug 26, 2016 at 6:56 PM, junaid ali  wrote:

> Can some one please tell me how to access foreman using python api
>
> i just have installed python 3.4 on my system which compatible with
> foreman python api
> https://pypi.python.org/pypi/python-foreman this one
>
> and using  below code which is defined on
> http://pythonhosted.org/python-foreman/basic.html
>
> >>> from getpass import getpass>>> from foreman.client import Foreman>>> f = 
> >>> Foreman('http://myforeman.server:3000', ('myuser', getpass()))
>
> but each time i run my script gave me this error
> WARNING:root:Api v1 will not be the default in the next version, if you still 
> want to use it, change the call to explicitly ask for it. Though we recommend 
> using the new and improved version 2
>
> and This code not works
> Your help will be very appreciated
>
>
> thanks
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [foreman-dev] Foreman Development getting started

[Martin Bačovský]

On Tue, Oct 11, 2016 at 10:08 AM, Daniel Lobato Garcia 
wrote:

> > We are using foreman in our company for a about 3 years but we would like
> > to extend some features. For example hammer-cli "host list". We would
> like
> > to have here an additional column for "description". How could u do that?
>


If it is the filed 'Comment' what you have on your mind, it is fairly
simple to add. It is already part of API response so the only thing you
need to do is to add it to the hammer command here [1]

Depending on your plans you can either suggest this change for inclusion in
hammer via redmine feature request [2] and send pull request in the Github
or start building hammer plugin of your own (some hints are here [3]).

--Martin

[1]
https://github.com/theforeman/hammer-cli-foreman/blob/master/lib/hammer_cli_foreman/host.rb#L164
[2] http://projects.theforeman.org/projects/hammer-cli/issues/new
[3]
https://github.com/theforeman/hammer-cli/blob/master/doc/developer_docs.md#hammer-development-docs

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and 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] Smart or Foreman Proxy? Let's do Foreman Smart Proxy

[Martin Bačovský]

+1 for Foreman Proxy

On Nov 3, 2016 8:12 AM,  wrote:

> +1 for Foreman Proxy
>
> IMHO the "Smart" word does not add any useful information to the reader.
>
> On Wednesday, November 2, 2016 at 11:30:35 AM UTC+2, Tomas Strachota wrote:
>>
>> On 10/17/2016 03:26 PM, Greg Sutcliffe wrote:
>> > On 17 October 2016 at 14:12, Lukas Zapletal > > > wrote:
>> >>
>> >> > This appears more inconsistent than the current situation, as there
>> will
>> >> > now be three terms, differing between the UI names ("Foreman Smart
>> >> > Proxy"), API/module names ("smart proxy"), and package names
>> ("foreman
>> >> > proxy").
>> >>
>> >> That's indeed a very true statement, I'll add that the new term aims
>> to
>> >> be the glue between the other two.
>> >
>> > I think I agree with Dominic, a third standard to fix two other
>> > standards is a common mistake.
>> >
>> >> To be honest, I'd rather kill "Smart Proxy" than "Foreman Proxy" if I
>> >> had to choose just one.
>> >
>> > +1 to that, Foreman Proxy would be my choice.
>>
>> +1 for Foreman Proxy
>>
>> >
>> > 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...@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] 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.

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

Re: [foreman-dev] [RFC] Proposal: make foreman STI to work even when an inherited class is not found in Ruby.

[Martin Bačovský]

+1 for fixing the integrity during plugin uninstallation. Option "A" seems
to be clean and most easy to maintain.

On Tue, May 9, 2017 at 4:21 PM, Lukas Zapletal  wrote:

> Wow this is nice! I did not see this coming...
>
> LZ
>
> On Sun, May 7, 2017 at 3:58 PM, Shimon Shtein  wrote:
> >
> > OK, it wasn't exactly my intention, but I see the discussion moves
> towards
> > general plugin install/uninstall procedure.
> >
> > I have discovered a nice feature that enables us to isolate plugin
> > migrations, and run them on per-plugin manner:
> > Apparently we can run:
> > rake db:migrate SCOPE=my_plugin
> > rake db:migrate SCOPE=my_plugin VARSION=0 # to migrate down
> > And it will run only migrations that are tagged for that scope. One can
> > achieve that by generating proper migration names:
> > _..rb
> > I have added a PR that generates migrations for plugins with the proper
> > naming: https://github.com/theforeman/foreman/pull/4509.
> >
> > This should be the base for complete removal. Then, if we add a down-only
> > migration that removes STI's - it should be enough to remove all DB
> traces
> > for a plugin.
> >
> >
> >
> > On Wed, May 3, 2017 at 2:11 PM, Lukas Zapletal  wrote:
> >>
> >> I agree with Tomas, it's more cleaner to remove all the data right
> >> away. Therefore I suggest that we check for these kind of objects
> >> during initialization and if such an class is (not) found, then we can
> >> throw an error like "Run foreman-rake plugin:clean" to delete orhpaned
> >> records.
> >>
> >> I am for (A) - remove all the data.
> >>
> >> LZ
> >>
> >> On Wed, May 3, 2017 at 11:16 AM, Tomas Strachota 
> >> wrote:
> >> > This issue is tightly coupled with plugin uninstallation and I think
> >> > we should solve the two problems together. At the moment there's no
> >> > standard plugin uninstallation procedure that would take care of
> >> > cleaning up the system. This is something each plugin should provide.
> >> > One thing (imho the less important in this context) is where we put
> >> > such code. Should it be a rake task, part of installer, part of
> >> > maintanance script, somewhere else?
> >> >
> >> > What I see as more important is to decide what data will the
> >> > uninstallation process remove (keep all vs. keep only settings vs.
> >> > wipe all) and how we want the plugin to behave if it's installed
> >> > again. This will affect how we approach missing STI classes.
> >> >
> >> > I can see 3 options:
> >> >
> >> > a) Remove all data
> >> > Plugin would remove all tables and records it created. In such case we
> >> > probably don't need to change the STI behavior. Plugin uninstallation
> >> > should take care of removing the data correctly. If it fails it's fine
> >> > to throw exception to indicate the system integrity is broken. This
> >> > approach is imho safer for us as developers and requires less
> >> > defensive coding.
> >> >
> >> > b) Keep all the data
> >> > In this case the original data should be present when the plugin is
> >> > installed again. STI records without classes should be completely
> >> > hidden in the default scope. If all records are listed we should
> >> > return either instances of base class or some special class for the
> >> > missing types. I'm afraid this approach is quite fragile and can lead
> >> > to many surprises when a plugin is uninstalled, the foreman lives
> >> > without it for some time and then you install it again. I'm also not
> >> > sure how common is such usecase.
> >> >
> >> > c) Combination of a) and b)
> >> > We can keep data where it's safe (like settings) and delete the rest.
> >> >
> >> > I'm in favor of a) or c)
> >> >
> >> > T.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > On Sun, Apr 30, 2017 at 10:05 AM,   wrote:
> >> >>
> >> >> Hello,
> >> >>
> >> >> lately I was switching plugins on and off, and I stumbled upon an
> >> >> annoying
> >> >> issue: Many plugins that add some STI classes (for example Katello
> that
> >> >> adds
> >> >> settings, or Discovery that adds DiscoveredHost).
> >> >> A problem starts when such a plugin is removed from the system, since
> >> >> default STI implementation will throw an error if it can't load a
> class
> >> >> that
> >> >> corresponds to the :type column in the DB.
> >> >>
> >> >> I propose a custom handling for such cases, since they are not
> exactly
> >> >> exceptions in our system design.
> >> >> I was thinking about one of the following options to handle this
> case,
> >> >> and
> >> >> would like to see a voting which one you prefer. Of course other
> >> >> options can
> >> >> be proposed too.
> >> >>
> >> >> 1. Return a base class for such records (Maybe with an error already
> >> >> set)
> >> >> 2. Return nil/some kind of special AR object for such records (will
> >> >> require
> >> >> defensive coding while handling heterogeneous lists)
> >> >> 3. Filter those records out with default scope (will require more
> >> >> declaration in plugins, or more DB queries on system startup)
> >> >>
> >> >

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] 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, 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] 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&q
>>> =is%3Apr+-author%3Ashimshtein+commenter%3Ashimshtein+is%3Aclosed+
>>> ​[3] https://github.com/theforeman/foreman/pulls?utf8=%E2%9C%93&q
>>> =is%3Apr+author%3Ammoll+is%3Aclosed+
>>> [4]​ https://github.com/theforeman/foreman/pulls?utf8=%E2%9C%93&q
>>> =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.