Re: [foreman-dev] Proposal to move "How to create a plugin" page to github.

[Marek Hulán]

> Am 22.06.17 um 11:16 schrieb Greg Sutcliffe:
> > +1 for moving the plugin documentation to the plugins part of the
> > website. I think that makes sense, and we can (as with other areas)
> > keep the wiki for footnotes, edge cases, and tips.
> > 
> > Greg
> 
> I'd suggest to add a Markdown file to the core repo. I believe code
> documentation is better suited to be in the code repo and the
> documentation can be reviewed alongside the code change in core by core
> maintainers. The website should be more for foreman users. But
> theforeman.org is fine with me as well.
> 
> - Timo

Having this info in the codebase itself sounds reasonable but I'd prefer 
having it on one place with other pages such as template writing wiki. The 
later is also useful for users and ideally will be moved to theforeman.org one 
day.

If there was a reliable way to sync it from theforeman.org to core codebase, 
that would we great. If I had to choose between these two, then I find 
theforeman.org better. I think Google would give better results for potential 
plugin writers too.

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

Re: [foreman-dev] Proposal to move "How to create a plugin" page to github.

[Timo Goebel]

Am 22.06.17 um 11:16 schrieb Greg Sutcliffe:

+1 for moving the plugin documentation to the plugins part of the
website. I think that makes sense, and we can (as with other areas)
keep the wiki for footnotes, edge cases, and tips.

Greg

I'd suggest to add a Markdown file to the core repo. I believe code 
documentation is better suited to be in the code repo and the 
documentation can be reviewed alongside the code change in core by core 
maintainers. The website should be more for foreman users. But 
theforeman.org is fine with me as well.


- 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] Weekly Dev/Design Meeting: Ansible Plugin

[Roxanne Hoover]

https://docs.google.com/document/d/1ThdUib-UMsY8bQaSy2YlmzrUNzt8gtp6Ah3eDaa8F4Q/edit

Ansible Plugin

Presented by Daniel

 


   - 
   
   No Bulk actions available, include checkboxes of bulk actions. Though 
   bulk actions may not be appropriate for all tables, this might be one.
   - 
   
   Future feature - be able to click on role to see parameters. Integrate 
   terminal options into UI.
   - 
   
   Improve table column width and column sorting.
   - 
   
   Order by name on default
   - 
   
   There is no help on this page
   
 


   - 
   
   Is saying “Import from..” needed? Would a user assume that since it’s 
   the import button it would be importing from the selected source. If so, 
   drop down options could include the name only, “Import from Foreman host” → 
   “Forem host”
   - 
   
   Make “Import” blue as it is the only and primary action on the page
   
   

   - 
   
   Toggle icons are redundant and probably unnecessary. 
   - 
   
   I think it’s possible a new layout with iconography added to Add or 
   Remove would be more visually appealing
   
 

 


   - 
   
   Break out report by Ansible, Puppet, etc.
   - 
   
   Those with color blindness would not find the color boxes helpful.
   

   - 
   
   “Ansible Roles” button is not clear what action is performing. Consider 
   renaming to “Run Ansible Roles” or whatever Ansible references in their 
   documentation, remove icon. We have been keeping button actions icon free 
   (or aiming to).
   
   
 

 

   - 
   
   Text is not easily read. Users must scan excessively to find results: Is 
   it possible to remove unnecessary syntax and redo formatting to make more 
   readable? If not, would a search be helpful? How can we make this more like 
   the puppet output.
   
 

 

 


   - 
   
   Level indicators 
   
 

 

 

-- 
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] HTTP proxy for requests

[Sebastian Gräßl]

I haven't thought as far as having it as an official plugin yet and not 
considered all the necessary parts for that.

I can also add it into core.

My thoughts on preferring to have it as a plugin were that, 
even though the code should be relatively small,
as it would probably only be initialiser code to set the HTTP proxy for 
various http libraries,
it does have a big impact on the whole application and 
having it as a plugin allows to disable all of it's doing by uninstalling 
it.

I actually also briefly thought that it be a generic rubygem, but that 
would have gone way too far. :D

On Thursday, June 22, 2017 at 2:08:13 PM UTC+2, Marek Hulán wrote:

> Why do you want to introduce it in a new plugin? I can see the global 
> proxy 
> setting in core. When we get to the point when we want to have separate 
> proxy 
> per library/plugin/communication then I think we should start using the 
> foreman_http_proxies plugin and enhance it if needed. From my experience, 
> starting a plugin brings a lot of extra maintenance effort, such as test 
> infrastructure, redmine setup, plugin manual write-up, hammer plugin from 
> scratch, support in installer. Why not simply add a new setting in 
> Foreman? 
>
> -- 
> Marek 
>
> On středa 21. června 2017 16:28:38 CEST Sebastian Gräßl wrote: 
> > The biggest part of this all is actually ensuring that all requests made 
> by 
> > the application are actually going through the HTTP proxy. 
> > 
> > As a solution to that, I was thinking of starting a plugin that 
> configures 
> > the proxy for HTTP libraries (Net::HTTP, Excon, RestClient, etc.) used. 
> > At first it would only make sure that we have all requests covered. 
> > As a nicety it could also have a debug mode to show outgoing requests 
> via 
> > something like httplog[1]. 
> > 
> > The HTTP proxy would at first just be one global setting, but later on 
> by 
> > extending the used libraries' underlying request methods it could 
> > also allow for dynamically choosing the appropriate proxy per request. 
> > This then can be used by the foreman_http_proxies[2] plugin. 
> > 
> > [1] https://github.com/trusche/httplog 
> > [2] https://github.com/jlsherrill/foreman_http_proxies 
> > 
> > On Thursday, May 25, 2017 at 11:58:12 AM UTC+2, Marek Hulán wrote: 
> > > sorry for typo, it should have been: 
> > > 
> > > AFAIK we don't *have* the solution *implemented* atm. 
> > > 
> > > On čtvrtek 25. května 2017 11:49:24 CEST Marek Hulán wrote: 
> > > > Sorry for being late to the party, sending my 2c: 
> > > > 
> > > > I agree with having more complicated solution where users could have 
> > > > separate proxies per service is good long-term goal. AFAIK we don't 
> the 
> > > > solution atm. Therefore I think introducing support for single, 
> global 
> > > > proxy sounds as improvement already to what we have now (nothing). 
> > > 
> > > What's 
> > > 
> > > > good on this, migrating to specific proxies should be easy, the RFC 
> > > > explicitly[1] mentions it. The global proxy can have granular rules 
> of 
> > > 
> > > what 
> > > 
> > > > communication should be passed through untouched and what should be 
> sent 
> > > > through maybe other proxies. Another advantage I see is that the 
> global 
> > > > proxy offloads the configuration from Foreman/Katello, which does 
> not 
> > > > really belongs into our domain. 
> > > > 
> > > > Later, when the RFC is implemented via foreman_http_proxies plugin, 
> I'm 
> > > > happy to stop using global proxy and improve plugins to use 
> > > > foreman_http_proxies if it makes sense. It will take some time 
> before 
> > > > everyone adopts it. But meanwhile we'd still have the option to let 
> user 
> > > > configure their master proxy according to their needs. 
> > > > 
> > > > [1] https://github.com/theforeman/rfcs/pull/18/ 
> > > > files#diff-12584a6580dac145ae55c2b5d67088dfR45 
> > > > 
> > > > > On 05/17/2017 07:57 AM, Tom McKay wrote: 
> > > > > > After reading the RFC I think that more robust and adaptable 
> > > 
> > > solution 
> > > 
> > > > > > would be better. A single env var is not going to cover the 
> needs of 
> > > > > > all the scenarios. A simple example may be accessing both 
> > > > > > registry.access.redhat.com  
> > > > > > (through proxy) and myopenshift:5000 (no proxy). 
> > > > > > 
> > > > > > As @jlsherrill noted on the PR, the temporary solution for the 
> > > > > > foreman-docker plugin is alright for the moment. 
> > > > > 
> > > > > I'd like to echo what tom said, we've had many users that want to 
> > > 
> > > access 
> > > 
> > > > > content externally through a proxy and internally (where the proxy 
> is 
> > > > > not controlled by them and does not properly proxy internal 
> requests). 
> > > > > Its happened enough for me to say that a simple solution is not 
> good 
> > > > > enough long term. 
> > > > > 
> > > > > > On Wed, May 17, 2017 at 3:08 AM, Sebastian Gräßl 
> > > > > > 
> > > > > >  

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

[Marek Hulán]

Why do you want to introduce it in a new plugin? I can see the global proxy 
setting in core. When we get to the point when we want to have separate proxy 
per library/plugin/communication then I think we should start using the 
foreman_http_proxies plugin and enhance it if needed. From my experience, 
starting a plugin brings a lot of extra maintenance effort, such as test 
infrastructure, redmine setup, plugin manual write-up, hammer plugin from 
scratch, support in installer. Why not simply add a new setting in Foreman?

--
Marek

On středa 21. června 2017 16:28:38 CEST Sebastian Gräßl wrote:
> The biggest part of this all is actually ensuring that all requests made by
> the application are actually going through the HTTP proxy.
> 
> As a solution to that, I was thinking of starting a plugin that configures
> the proxy for HTTP libraries (Net::HTTP, Excon, RestClient, etc.) used.
> At first it would only make sure that we have all requests covered.
> As a nicety it could also have a debug mode to show outgoing requests via
> something like httplog[1].
> 
> The HTTP proxy would at first just be one global setting, but later on by
> extending the used libraries' underlying request methods it could
> also allow for dynamically choosing the appropriate proxy per request.
> This then can be used by the foreman_http_proxies[2] plugin.
> 
> [1] https://github.com/trusche/httplog
> [2] https://github.com/jlsherrill/foreman_http_proxies
> 
> On Thursday, May 25, 2017 at 11:58:12 AM UTC+2, Marek Hulán wrote:
> > sorry for typo, it should have been:
> > 
> > AFAIK we don't *have* the solution *implemented* atm.
> > 
> > On čtvrtek 25. května 2017 11:49:24 CEST Marek Hulán wrote:
> > > Sorry for being late to the party, sending my 2c:
> > > 
> > > I agree with having more complicated solution where users could have
> > > separate proxies per service is good long-term goal. AFAIK we don't the
> > > solution atm. Therefore I think introducing support for single, global
> > > proxy sounds as improvement already to what we have now (nothing).
> > 
> > What's
> > 
> > > good on this, migrating to specific proxies should be easy, the RFC
> > > explicitly[1] mentions it. The global proxy can have granular rules of
> > 
> > what
> > 
> > > communication should be passed through untouched and what should be sent
> > > through maybe other proxies. Another advantage I see is that the global
> > > proxy offloads the configuration from Foreman/Katello, which does not
> > > really belongs into our domain.
> > > 
> > > Later, when the RFC is implemented via foreman_http_proxies plugin, I'm
> > > happy to stop using global proxy and improve plugins to use
> > > foreman_http_proxies if it makes sense. It will take some time before
> > > everyone adopts it. But meanwhile we'd still have the option to let user
> > > configure their master proxy according to their needs.
> > > 
> > > [1] https://github.com/theforeman/rfcs/pull/18/
> > > files#diff-12584a6580dac145ae55c2b5d67088dfR45
> > > 
> > > > On 05/17/2017 07:57 AM, Tom McKay wrote:
> > > > > After reading the RFC I think that more robust and adaptable
> > 
> > solution
> > 
> > > > > would be better. A single env var is not going to cover the needs of
> > > > > all the scenarios. A simple example may be accessing both
> > > > > registry.access.redhat.com 
> > > > > (through proxy) and myopenshift:5000 (no proxy).
> > > > > 
> > > > > As @jlsherrill noted on the PR, the temporary solution for the
> > > > > foreman-docker plugin is alright for the moment.
> > > > 
> > > > I'd like to echo what tom said, we've had many users that want to
> > 
> > access
> > 
> > > > content externally through a proxy and internally (where the proxy is
> > > > not controlled by them and does not properly proxy internal requests).
> > > > Its happened enough for me to say that a simple solution is not good
> > > > enough long term.
> > > > 
> > > > > On Wed, May 17, 2017 at 3:08 AM, Sebastian Gräßl
> > > > > 
> > > > >   > 
> > >> wrote:
> > > > > There was some feedback regarding this on the PR[1] mentioned in
> > > > > the beginning.
> > > > > There is already a RFC[2] regarding this and a plugin[3] to
> > > > > implement the solution proposed in the RFC.
> > > > > 
> > > > > The solution proposed by jlsherrill allows to add multiple
> > > > > HTTP-proxies in Foreman and use these in plugins and allow to
> > > > > configure what HTTP-proxy should be used for what requests.
> > > > > So far the plugin only adds the ability to add HTTP proxies and
> > > > > misses a essential part, which is applying the HTTP proxies to
> > > > > requests.
> > > > > 
> > > > > While looking at how other applications handle this and also
> > > > > considering typical HTTP proxy configurations, it feels that
> > 
> > such
> > 
> > > > > a solution would make it rather complex in practice to apply.

Re: [foreman-dev] Proposal to move "How to create a plugin" page to github.

[Greg Sutcliffe]

On Thu, 2017-06-22 at 09:16 +0200, Marek Hulán wrote:
> +1, I think it could be added to developer handbook [1] or new
> section at [2] 
> or to plugins page [3]
> 
> [1] https://theforeman.org/contribute.html
> [2] https://theforeman.org/documentation.html
> [3] https://theforeman.org/plugins/

+1 for moving the plugin documentation to the plugins part of the
website. I think that makes sense, and we can (as with other areas)
keep the wiki for footnotes, edge cases, and tips.

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.

Re: [foreman-dev] Proposal to move "How to create a plugin" page to github.

[Marek Hulán]

+1, I think it could be added to developer handbook [1] or new section at [2] 
or to plugins page [3]

[1] https://theforeman.org/contribute.html
[2] https://theforeman.org/documentation.html
[3] https://theforeman.org/plugins/

--
Marek

On čtvrtek 22. června 2017 8:48:39 CEST ssht...@redhat.com wrote:
> Hi all,
> 
> Recently I have created a couple of PR's that added extension point to
> plugins. These extension point needed to be documented in the
> http://projects.theforeman.org/projects/foreman/wiki/How_to_Create_a_Plugin
>  document.
> The problem is that between the time I have created the code PR and the
> time it got merged (and the doc change was necessary) passed a couple of
> months. I had to remember the context when I was writing the PR in order to
> write the wiki page.
> 
> I suggest creating a docs PR side by side with the code PR and creating a
> reference between them.
> Benefits:
> 1. The documentation would be created in the same context by the developer,
> while it's fresh in his memory and he remembers all the caveats for the
> user.
> 2. The reviewers could better understand what the PR is offering.
> 3. There is less chance for the developer to forget to update the docs
> 
> In order to do that, we have to move the page to github (somewhere in
> theforeman.org  repo).
> To mitigate a concern about the ease of change, we can put a link to edit
> the page in the header/footer of the page itself, so it will be one click
> away for anyone who wants to edit it.
> 
> Comments?


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