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

[Evgeni Golov]

This has been identified as an upstream regression:
https://github.com/OpenSCAP/openscap/issues/744
And a patch has been already merged:
https://github.com/OpenSCAP/openscap/pull/745
Should ship in OpenSCAP 1.2.15

On Thu, May 18, 2017 at 6:15 PM, Evgeni Golov  wrote:
> So, continuing talking to myself ;)
>
> I looked into upstream tests
> (https://github.com/OpenSCAP/ruby-openscap/blob/master/test/ds/sds_test.rb#L43-L54)
> and they are supposed to catch that, but they do not, as their loop
> never executes with their DS file.
> Using our file I get the exact same error as in my fist mail. And
> using our file I don't get the warning with my code above either.
> So it's seems that the issue is in OpenSCAP itself.
> I'll bring that up on their issue tracker tomorrow, let's see what they think.
>
> Thanks for listening.
> Evgeni
>
> On Wed, May 17, 2017 at 5:53 PM, Evgeni Golov  wrote:
>> 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
>
>
>
> --
> 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, 

Re: [foreman-dev] Moments of Coffee Meeting: Fog and Compute Resrouces NG

[Timo Goebel]

> On 22. May 2017, at 12:27, Ohad Levy  wrote:
> 
> Since we get a lot of lift from fog, especially for popular providers (e.g. 
> ec2) IMHO its not a good idea to remove fog, which means that we balance 
> between community contributions to fog (e.g. stuff we won't "enjoy" as we 
> will not corporate) vs other benefits mentioned above. 
> 
> I for one, is not convinced the effort to not run with fog is less work then 
> adding / updating a fog provider.
> 
> Ohad

I do agree with Ohad here. I'd focus on improving the fog-providers and not 
trying to reinvent the weel.
I think, "cloud" topics like focussing on real server orchestration (think 
hostgroup as an auto scaling group) adds more benefits for a user. A user 
usually doesn't care about the library used. Using foreman as a tool to setup a 
cloud or container environment on bare metal does add value.

Fog doesn't do any network orchestration, yet. If we add this (e.g. provision a 
vlan on a switchport or some SDN), that would be a valid point imho to switch 
the library.

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

Re: [foreman-dev] Moments of Coffee Meeting: Fog and Compute Resrouces NG

[Ohad Levy]

On Mon, May 22, 2017 at 12:30 PM, Lukas Zapletal  wrote:

> Hey,
>
> I brought an interesting topic about RHEV support in Foreman, Ori
> pointed out that RHEV v3 API is going to be deprecated soon (rumors
> are 4.2 which is very soon) and since we are still using v3 via
> rbovirt, it's the time to start dicussion in moving towards v4.
>
> We switched to discussing the idea to implement RHEV v4 support via
> newly created API that would allow us easily creating new CR
> providers, Fog based or non-Fog based. Concerns were obvious - we do
> not want to rewrite Fog or big part of it, on the other hand Marek
> pointed out we want very simple API which will be pure Ruby (and not
> XML hell) as minimal as it can be.
>
Which XML hell do you currently have? granted v3 of ovirt api uses XML, but
that's surely not related to fog.


> Marek pointed out that our API could include things like memory sizes,
> pool sizes and other lists (OS lists) which are spread around in Fog,
> but we want consistent UX. Our API could be a chance to unify these.
> Also our approach can increase performance as we not always need all
> flags and data.
>
> Shim brought an idea to use Facets for the new CR (CRNG - new
> generation) which would allow to run multiple versions of compute
> resources easily which is something we will need to do for RHEV (we
> still want to support oVirt 3.x for some time).
>
that would be nice, especially if we can separate workers (and not load all
into every process memory).

>
> He also raised concern in going too far in unification, Marek answered
> that we should only unify internal things and primarily data (memory).
> Greg added that UI is added value and not core goal. He also mentioned
> that Fog project lost its momentum a bit and it is not very relevant
> to us these days.
>
> I would disagree around UI, IMHO we need to strive and improve are UI,
imho most people who leave foreman do so because of a poor UX, or lack of
relevance in new set of techonologies ( cloud born companies, containers
only etc).


> I brought an idea to solve our long-standing request to proxy CR
> communication through proxy, we should keep that in mind when
> designing the new API. Which should be definitely as minimal as
> possible to allow writing non-Fog providers. Also one problem we could
> tackle is to stop doing long HTTP requests from web request thead, we
> could consider using Rails Jobs or Foreman Tasks for tasks.
>

TBH I do believe that fog actually supports proxy (excon and rest client do
which imho are the majority of http connections).

>
> We agreed that we are not getting rid of Fog anytime soon, but we
> would love to have the possibility not to use Fog in the future. This
> is a good candidate for RFC and we are running out of time thank to
> RHEV v3 API deprecation.
>

Since we get a lot of lift from fog, especially for popular providers (e.g.
ec2) IMHO its not a good idea to remove fog, which means that we balance
between community contributions to fog (e.g. stuff we won't "enjoy" as we
will not corporate) vs other benefits mentioned above.

I for one, is not convinced the effort to not run with fog is less work
then adding / updating a fog provider.

Ohad

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

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