Re: [foreman-dev] HoundCI - annoying?

[Marek Hulán]

Hello,

yes, I find it annoying and I liked the jenkins job more. It would be great if 
hound would be able to use reviews that would generate one email per review. 
Hopefully they work on it. Otherwise I'd be for moving back to jenkins.

On středa 11. ledna 2017 12:07:38 CET David Davis wrote:
> Not sure if it helps you but you can filter out the HoundCI emails by
> checking for emails from "Hound ”. Also, when a
> HoundCI comment is addressed, isn’t the comment collapsed?

Sometimes that's annoying as well, the the hound comments in collapsed thread.

--
Marek

> I agree though that HoundCI doesn’t seem to work properly. On Katello,
> we’ve seen it add inline comments but pass PRs, fail Pos without inline
> comments, and raise inline comments that we’re not seeing when running
> rubocop locally.
> 
> Another reason to move to Jenkins is that sometimes HoundCI doesn’t catch
> all the errors that actually rubocop might since it only looks at the lines
> changed. Like right now, it doesn’t look like rubocop is passing for
> foreman on develop.
> 
> 
> David
> 
> On Wed, Jan 11, 2017 at 11:18 AM, Timo Goebel  wrote:
> > Hi devs,
> > 
> > I'm usually not very easily annoyed. What get's me started though
> > eventually is when things don't work properly.
> > HoundCI is one of those things.
> > 
> > My main concern is, that I get an e-mail and/or Github notification for
> > every single comment. These can easily be ten or more e-mails. They're not
> > grouped as other reviews.
> > In addition, the inline comments are very distracting when reviewing a PR
> > imho. When the issues are fixed, I'd prefer for the comments to be
> > removed.
> > When reviewing a PR, I usually don't care about the style issues. I just
> > want to see if there are some problems or if all is fine.
> > 
> > Back in the days, code style was checked by Jenkins. I think, it did a far
> > better job in displaying style issues. With the current Jenkins Github
> > plugin it believe would be easily possible to show style issues as a
> > separate line along with all the other CI checks.
> > 
> > One argument in favor of HoundCI is, that it checks JavaScript style. But
> > I think, that can easily be set up in Jenkins as well by running eslint.
> > 
> > Any comments? How do others feel?
> > 
> > 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] Revert removal of @host.params for host_param

[Stephen Benjamin]

- Original Message -
> From: "Daniel Lobato Garcia" 
> To: foreman-dev@googlegroups.com
> Sent: Wednesday, January 11, 2017 11:05:39 AM
> Subject: [foreman-dev] Revert removal of @host.params for host_param
> 
> Hi foreman devs,
> 
> Just noticed today https://github.com/theforeman/foreman/pull/3983/files
> after some comments on IRC. What's the background behind this change?
> 
> As far as I can see, this merely moves
> 
> @host.param to host_param
> @host.param_true? to host_param_true?
> @host.param_false? to host_param_false?
> @host.info to host_enc
> 
> without gaining anything from the change. This will force people to
> change their templates (including our community templates) when the
> deprecation is removed, and there's nothing to gain.
> 
> Does someone know what's the rationale behind this change? As it stands
> right now, I propose reverting that commit entirely to avoid inflicting
> that pain on users - which include many devs who maintain templates.
> 
> Best,
> 

I know the macros look better, but it seems like a small gain for a
lot of pain.  A lot of users use the existing methods in parameter values
(ERB w/ safe mode off), and their own custom templates.

And the standard response to these kinds of complaints is "well, it's
deprecated and users have enough time to change."  But I really just
don't think that's sufficient, this is more change for the sake of
change.

Also, the deprecation wasn't really smooth as it broke REX tests.
  http://ci.theforeman.org/job/test_plugin_matrix/2466/


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

[foreman-dev] Dev/Design Weekly Demo Notes - Users, User Groups

[Roxanne Hoover]

Sharing my notes from the weekly Dev/Design Demo. This week Marek presented 
on Users, User Groups, Roles.


These are my notes and thoughts only from a UX/UI perspective, they are not 
mandates and are open to feedback/discussion.



General Comments - issues found throughout the application:


   1. 
   
   Button color, placement and style - Buttons appear outside of standard 
   color, stylization and layout expectations.
   2. 
   
   Title case for forms and buttons - Some form labels and buttons do not 
   follow title case. For example in the Users section: Authorized by 
   (incorrect) vs. Authorized By (correct).
   3. 
   
   Inline Messaging Stylization and placement - layouts are inconsistent as 
   well as placement on the page.
   4. 
   
   Documentation Button - This needs to be evaluated for best placement and 
   color. It varies throughout the application.
   5. 
   
   Infotips - many fields have additional description text that should be 
   placed in an infotip. Occasionally the description text is redundant to the 
   form label.
   6. 
   
   There is the occasional tooltip on a button. I find it intrusive.  A 
   good rule of thumb is that if a button isn’t self-explanatory, then there 
   is something wrong with the button or the process.
   
   
Notes:


   1. 
   
   Password authorization - Weak/Normal/Strong visualization would not pass 
   528 compliance for those visually impaired. The colors associated with each 
   strength level seems mismatched. For example: Normal is red. A red status 
   as well as form field highlight indicates an error. Weak is grey, and also 
   possibly not high enough contrast for the visually impaired. The solution 
   may be to simplify the password strength to text only, “Weak Password, 
   Strong Password”. Also - greater thought or discussion could be had around 
   “Normal” or “Strong”. If a “Normal” indicator is shown, does this actually 
   change user behavior in the same way “Weak” does? Perhaps only “weak” is 
   needed.
   


   1. 
   
   Inline messaging regarding email notification should be moved above 
   content but within the content box.
   


   1. 
   
   Login button changes to loading. I believe this is not standard 
   patternfly behavior.
   


   1. 
   
   Users > Email settings
   1. 
  
  Search drop down has a find field. It doesn’t seem like this is 
  practical given the limited number of choices and the inability to make 
  more options. 
  1. 
 
 I believe an alternate layout and input method could be used that 
 would make choices more obvious at first glance.
 2. 
  
  Order of fields changes on submit. They should remain in the same 
  order.
  3. 
  
  Test Email button seems misplaced and not patternfly standard button.
  
  2. 
   
   Admin/Administrator check boxes - Text labels should be consistent. 
   Consider using infotip to better describe the role. A better layout may 
   also make it feel less out of place when placed alongside the dual 
   pane/shuttle selector. 
   
   3. 
   
   Edit User Page:
   1. 
  
  Description (box description is generic and most likely not needed).
  2. 
  
  Re-login Permission denied box layout is not correct. Filter field is 
  touching masthead.
  
  4. 
   
   User Group Main page -  Delete button, text is red. A default grey 
   button should be used. Perhaps confirmation of deletion in terms of 
   extended implications could be displayed?
   
   5. 
   
   New Authorization Source Create page does not follow patternfly.
   
   6. 
   
   LDAP Authentication Page > Account:
   1. 
  
  Group Base field is shorter than LDAP Filter.
  2. 
  
  LDAP filter should be larger to accommodate multiple line filters 
  (common)
  
  7. 
   
   User Groups > External groups:
   1. 
  
  External groups = External Groups
  2. 
  
  I believe the table functionality could be improved to show more 
  details/actions with potential inline editing. This would remove the 
“show 
  linked external user groups” button whose results displayed could be 
  extraordinarily long. 
  3. 
  
  As an additional note - moving away from two-pane view would allow 
  detailed pages like this to take advantage of additional screen real 
estate.
  









-- 
You received this message because you are subscribed 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] HoundCI - annoying?

[David Davis]

Not sure if it helps you but you can filter out the HoundCI emails by
checking for emails from "Hound ”. Also, when a
HoundCI comment is addressed, isn’t the comment collapsed?

I agree though that HoundCI doesn’t seem to work properly. On Katello,
we’ve seen it add inline comments but pass PRs, fail Pos without inline
comments, and raise inline comments that we’re not seeing when running
rubocop locally.

Another reason to move to Jenkins is that sometimes HoundCI doesn’t catch
all the errors that actually rubocop might since it only looks at the lines
changed. Like right now, it doesn’t look like rubocop is passing for
foreman on develop.


David

On Wed, Jan 11, 2017 at 11:18 AM, Timo Goebel  wrote:

> Hi devs,
>
> I'm usually not very easily annoyed. What get's me started though
> eventually is when things don't work properly.
> HoundCI is one of those things.
>
> My main concern is, that I get an e-mail and/or Github notification for
> every single comment. These can easily be ten or more e-mails. They're not
> grouped as other reviews.
> In addition, the inline comments are very distracting when reviewing a PR
> imho. When the issues are fixed, I'd prefer for the comments to be removed.
> When reviewing a PR, I usually don't care about the style issues. I just
> want to see if there are some problems or if all is fine.
>
> Back in the days, code style was checked by Jenkins. I think, it did a far
> better job in displaying style issues. With the current Jenkins Github
> plugin it believe would be easily possible to show style issues as a
> separate line along with all the other CI checks.
>
> One argument in favor of HoundCI is, that it checks JavaScript style. But
> I think, that can easily be set up in Jenkins as well by running eslint.
>
> Any comments? How do others feel?
>
> 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.

[foreman-dev] HoundCI - annoying?

[Timo Goebel]

Hi devs,

I'm usually not very easily annoyed. What get's me started though 
eventually is when things don't work properly.
HoundCI is one of those things.

My main concern is, that I get an e-mail and/or Github notification for 
every single comment. These can easily be ten or more e-mails. They're not 
grouped as other reviews.
In addition, the inline comments are very distracting when reviewing a PR 
imho. When the issues are fixed, I'd prefer for the comments to be removed.
When reviewing a PR, I usually don't care about the style issues. I just 
want to see if there are some problems or if all is fine.

Back in the days, code style was checked by Jenkins. I think, it did a far 
better job in displaying style issues. With the current Jenkins Github 
plugin it believe would be easily possible to show style issues as a 
separate line along with all the other CI checks.

One argument in favor of HoundCI is, that it checks JavaScript style. But I 
think, that can easily be set up in Jenkins as well by running eslint.

Any comments? How do others feel?

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.

[foreman-dev] Revert removal of @host.params for host_param

[Daniel Lobato Garcia]

Hi foreman devs,

Just noticed today https://github.com/theforeman/foreman/pull/3983/files
after some comments on IRC. What's the background behind this change?

As far as I can see, this merely moves

@host.param to host_param
@host.param_true? to host_param_true?
@host.param_false? to host_param_false?
@host.info to host_enc

without gaining anything from the change. This will force people to
change their templates (including our community templates) when the
deprecation is removed, and there's nothing to gain.

Does someone know what's the rationale behind this change? As it stands
right now, I propose reverting that commit entirely to avoid inflicting
that pain on users - which include many devs who maintain templates.

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.


signature.asc
Description: PGP signature

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  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 
> wrote:
>
>>
>>
>> - Original Message -
>> > From: "Tom McKay" 
>> > 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 
>> > wrote:
>> >
>> > >
>> > >
>> > > - Original Message -
>> > > > From: "Ewoud Kohl van Wijngaarden" 
>> > > > 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
>> > >
>> > > 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.
>> >
>>
>> --
>> You received this message because you are subscribed 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,