[foreman-dev] Re: smart_proxy_openscap tests fail with OpenSCAP >= 1.2.11

[Evgeni Golov]

Trivial reproducer, without our code:

  require 'openscap'
  require 'openscap/source'
  require 'openscap/ds/arf'
  require 'openscap/xccdf/benchmark'

  scap_file= '/tmp/ruby-openscap/test/data/sds-complex.xml'

  OpenSCAP.oscap_init
  @source = OpenSCAP::Source.new(scap_file)

  sds = OpenSCAP::DS::Sds.new @source
  sds.select_checklist
  html = sds.html_guide

(the file is 
https://github.com/OpenSCAP/ruby-openscap/blob/master/test/data/sds-complex.xml)

Running this with OpenSCAP 1.2.10 results in the following warning printed:
WARNING: Processing an unresolved XCCDF document. This may have
unexpected results.
You can resolve the document using "oscap xccdf resolve -o
resolved-xccdf.xml xccdf.xml"

This warning is missing when executing the above with 1.2.11, instead
you get the already known:
Internal error: Could not acquire handle to xccdf.xml source.
[ds_sds_session.c:339] (OpenSCAP::OpenSCAPError)

I am calling it a day, and will dig deeper tomorrow.

On Wed, May 17, 2017 at 4:41 PM, Evgeni Golov  wrote:
> Ohai,
>
> the tests for smart_proxy currently fail when executed with OpenSCAP
>>= 1.2.11 (like in EL6 or Fedora 25):
>
> Error: test_scap_content_guide(ScapContentParserApiTest):
>   JSON::ParserError: 784: unexpected token at 'Error occurred:
> Internal error: Could not acquire handle to xccdf.xml source.
> [ds_sds_session.c:357]
>   '
> /home/remote/egolov/.gem/ruby/gems/json-1.8.6/lib/json/common.rb:155:in 
> `parse'
> /home/remote/egolov/.gem/ruby/gems/json-1.8.6/lib/json/common.rb:155:in 
> `parse'
> /tmp/smart_proxy_openscap/test/scap_content_parser_api_test.rb:50:in
> `test_scap_content_guide'
>  47:
>  48:   def test_scap_content_guide
>  49: post
> '/scap_content/guide/xccdf_org.ssgproject.content_profile_rht-ccp',
> @scap_content, 'CONTENT_TYPE' => 'text/xml'
>   => 50: result = JSON.parse(last_response.body)
>  51: assert(result['html'].start_with?(''))
>  52: assert(last_response.successful?)
>  53:   end
>
> Seems that Marek did hit that issue at some point too:
> http://projects.theforeman.org/issues/17839
>
> It works fine with OpenSCAP 1.2.9 (Debian Stretch) and 1.2.10 (EL7),
> but will terribly fail on EL6 (1.2.13) and Fedora 25 (1.2.14).
> Pulling builds from Koji I tracked that down to 1.2.11 being the
> culprit, a proper bisect between 1.2.10 and 1.2.11 is yet outstanding.
> And I guess an OpenSCAP update in EL7 is coming at some point too.
>
> I am yet unsure if that is us doing something fishy, or whether it is
> an actual bug in OpenSCAP.
>
> Cheers
> Evgeni
>
> --
> Beste Grüße/Kind regards,
>
> Evgeni Golov
> Software Engineer
> 
> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
> Commercial register: Amtsgericht Muenchen, HRB 153243,
> Managing Directors: Charles Cachera, Michael Cunningham, Michael
> O'Neill, Eric Shander



-- 
Beste Grüße/Kind regards,

Evgeni Golov
Software Engineer

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Eric Shander

-- 
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] Dropping Ruby 2.0 support in 1.16?

[Ewoud Kohl van Wijngaarden]

On Wed, May 17, 2017 at 04:47:46PM +0200, Michael Moll wrote:
> Hi,
> 
> On Wed, May 17, 2017 at 04:11:31PM +0300, Tomer Brisker wrote:
> > Is there some similar solution we can find for Debian so we don't hit the
> > same issue when we want to drop 2.1 eventually while still supporting
> > Jessie?
> 
> I can't think of a solution that's maintainable without requiring a huge
> amount of time (that we can't provide), so let's simply postpone the question
> of dropping Debian/jessie when it's time to desupport Ruby 2.1.

I agree. It's very likely that Strech will be out when 1.16 is released
and that ships 2.3. Once Strech is out we can start to consider dropping
Jessie for new releases.

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

Re: [foreman-dev] Dropping Ruby 2.0 support in 1.16?

[Michael Moll]

Hi,

On Wed, May 17, 2017 at 04:11:31PM +0300, Tomer Brisker wrote:
> Is there some similar solution we can find for Debian so we don't hit the
> same issue when we want to drop 2.1 eventually while still supporting
> Jessie?

I can't think of a solution that's maintainable without requiring a huge
amount of time (that we can't provide), so let's simply postpone the question
of dropping Debian/jessie when it's time to desupport Ruby 2.1.
-- 
Michael Moll

-- 
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] Dropping Ruby 2.0 support in 1.16?

[Michael Moll]

Hi,

On Wed, May 17, 2017 at 03:11:12PM +0300, Tomer Brisker wrote:
> What do people think about dropping it in 1.16? This will still give people
> enough time to upgrade their systems as 1.15 will still be supported for
> the next 6 months.

+1 on dropping 2.0 support for Foreman core.
-- 
Michael Moll

-- 
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] Dropping Ruby 2.0 support in 1.16?

[Ivan Necas]

Tomer Brisker  writes:

> Hello,
>
> Ruby 2.0 has been EOL'ed over a year ago. More and more of our dependent
> libraries are dropping support for it, which means that we are either stuck
> with older versions or need to fix support in those libraries which may or
> may not be interested in it. This also prevents us from leveraging newer
> features and simplifying our CI pipeline.
>
> Currently AFAIK the only supported distro that requires it is Ubuntu 14.04,
> as we can use SCL to get a newer version on RH-based distros. Ubuntu 16.04
> has already been out for a year and ships with ruby 2.3. Debian Jessie
> ships with Ruby 2.1 which we will have to support for a while more as there
> is no way to easily upgrade the system ruby there.
>
> What do people think about dropping it in 1.16? This will still give people
> enough time to upgrade their systems as 1.15 will still be supported for
> the next 6 months.

+1 for dropping in Foreman Rails

Btw. the tracker seems like a good thing to have to see all the related
issues to different Ruby versions, created similar one for 2.1, as there
are some deps already that require 2.2 at least:
http://projects.theforeman.org/issues/19577

-- Ivan

>
> There is already a tracker on Redmine [1] to track various related issues.
>
> [1] http://projects.theforeman.org/issues/15954
>
> -- 
> 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.

Re: [foreman-dev] Dropping Ruby 2.0 support in 1.16?

[Tomer Brisker]

Hi,

As a first step, I think about dropping it in Foreman core and its plugins,
since those have the largest dependencies and would be easiest to achieve.
I would be happy to also drop it in the proxy and the installer, but as
Eric mentioned, that would be more complex as we don't SCL those yet, so we
would also be blocked by EL7 there.

Going forward, would we be able to use SCL for the proxy and installer?
While it might still be feasible to support Ruby 2.0 for them right now,
eventually we will have no choice but figuring some way to solve it as EL7
isn't going anywhere soon.
Is there some similar solution we can find for Debian so we don't hit the
same issue when we want to drop 2.1 eventually while still supporting
Jessie?


On Wed, May 17, 2017 at 3:43 PM, Eric D Helms  wrote:

>
>
> On Wed, May 17, 2017 at 8:19 AM, Ewoud Kohl van Wijngaarden <
> ew...@kohlvanwijngaarden.nl> wrote:
>
>> On Wed, May 17, 2017 at 03:11:12PM +0300, Tomer Brisker wrote:
>> > What do people think about dropping it in 1.16? This will still give
>> people
>> > enough time to upgrade their systems as 1.15 will still be supported for
>> > the next 6 months.
>>
>> Would you drop it for both Foreman and Smart Proxy or just Foreman?
>>
>
> Similarly, are you talking just the server and not the installer portion
> of our stack? Given EL7 comes with Ruby 2.0 by default and the installer is
> not SCL'd (same for the smart proxy).
>
> Eric
>
>
>>
>> --
>> 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.
>



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

Re: [foreman-dev] Dropping Ruby 2.0 support in 1.16?

[Eric D Helms]

On Wed, May 17, 2017 at 8:19 AM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:

> On Wed, May 17, 2017 at 03:11:12PM +0300, Tomer Brisker wrote:
> > What do people think about dropping it in 1.16? This will still give
> people
> > enough time to upgrade their systems as 1.15 will still be supported for
> > the next 6 months.
>
> Would you drop it for both Foreman and Smart Proxy or just Foreman?
>

Similarly, are you talking just the server and not the installer portion of
our stack? Given EL7 comes with Ruby 2.0 by default and the installer is
not SCL'd (same for the smart proxy).

Eric


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

[foreman-dev] Weekly Dev/Design Meeting: Smart Class Parameters

[Roxanne Hoover]

https://docs.google.com/document/d/1H_2feb4MkuZobk6gXvYSGpnXl4Vxp5MgUSyfMbgsraA/edit


Smart Class Parameters

Presented by Ori





   - 
   
   Switch order of buttons 
   (http://www.patternfly.org/pattern-library/forms-and-controls/forms/)
   


   - 
   
   Put help text in inline help
   - 
   
   Remove entire link on “Reset Puppet Environment….” to Reset Puppet 
   Environment to match selected Content View.
   



   - 
   
   Omit inline help icon should not be blue.
   




   - 
   
   Tooltip for overriden flag icon so users know what it means
   - 
   
   Searching within specific environments, this is a greater problem of 
   consistency with search interaction. Some search criteria dropdowns appear 
   before the input box, and in this instance after.
   - 
   
   User Title Case for all labels… such as “ Key type” = “Key Type”
   




   - 
   
   Change help icons to black
   - 
   
   New Documentation button solution coming soon!
   - 
   
   Remove blue from Add Matcher
   - 
   
   Lines probably not needed in Specify Matchers table
   




   - 
   
   Add error icon and remove red text.
   




   - 
   
   When items are removed - remove error.
   - 
   
   Add Error icon to tab
   


   - 
   
   Remove lines, use spacing to create rows because fields are already 
   boxed in.
   


   - 
   
   Have full screen button remain in the top right.
   









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

[Justin Sherrill]

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.
Configuring rules for requests or just ensuring the proper request
is using the right HTTP proxy is better configurable in the HTTP
proxy itself.

I believe a very bold simple solution would be the better, which
in my opinion would be to ensure all parts respect a HTTP proxy
configuration and have good documentation around it to advice on
how to configure the HTTP proxy correctly. Taken other
applications in the same area the HTTP_PROXY environment variable
seems to be the common standard to use.

Please, I would love to hear more feedback on this and what are
common HTTP proxy setups.

[1] https://github.com/theforeman/foreman-docker/pull/189

[2] https://github.com/theforeman/rfcs/pull/18

[3] https://github.com/jlsherrill/foreman_http_proxies


On Thursday, April 20, 2017 at 1:07:33 PM UTC+2, Sebastian Gräßl
wrote:

Hej,

at the moment there is a PR[1] open on foreman-docker to set a
HTTP proxy for requests to registries.
The PR allows to set a HTTP proxy on the HTTP client, in this
case deep down Excon, only for registry requests.

A HTTP proxy won't be set on requests if a `HTTP_PROXY`
environment variable is available, since it is an unlikely
setup to have registry request routed over a different proxy
than other requests. However setting it via the environment
variable will allow requests to succeed to resources available
by the HTTP proxy, but will fail for those inside and possible
blocked.

The `HTTP_PROXY` environment variable seems to be a standard,
and therefore Excon is built to use it when available.
Excon is used by docker-api as well as fog, it might be used
by other components and there might be other parts that use
another HTTP client like RestClient, which also respects the
variable.

This means at the moment with that environment variable set
some requests would already rely on it.
In any case this should be in mentioned in the manual to be
aware of, also because some operating systems set this globally.

The question is should we make an afford to ensure deployment
behind a HTTP proxy on a system with HTTP blocked works
without issues and provide a way to configure it properly?

I've tested Foreman with HTTP blocked and `HTTP_PROXY` set,
but in a very basic setup, with the only external requests
being to Docker registries outside and squid configured to
just pass requests through regardless there to.

It didn't show any apparent issue, but there are for sure
issues with a more robust configured HTTP proxy.
This raises another question: How common is a setup where
external resources requiring HTTP are used with Foreman behind
a HTTP proxy?

Comments?

All the best,
Sebastian

[1] https://github.com/theforeman/foreman-docker/pull/189


-- 
You received this message because you are 

Re: [foreman-dev] Migration to Copr POC

[Dominic Cleal]

On 16/05/17 13:32, Lukas Zapletal wrote:
> Delete existing testing Copr repositories in @theforeman Copr group,
> it's not shown in the UI who created them but I believe it was Dominic
> or Eric: https://copr.fedorainfracloud.org/groups/g/theforeman/coprs/

Those are mine, you can delete them if you need to. I can always
re-create them.

-- 
Dominic Cleal
domi...@cleal.org

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