Would it be possible to get this backported into 6.5?

Created attachment 846313 [details]
2.0 version patch

I have created https://github.com/sosreport/sosreport/pull/228 to apply this patch to the community version of the code.

Might it make more sense to ship a sosreport plugin in OpenShift Enterprise instead?

We can ship fixes a lot faster than RHEL, and more than one version of OSE is supported on RHEL at a time.

(In reply to Luke Meyer from comment #12)
> Might it make more sense to ship a sosreport plugin in OpenShift Enterprise
> instead?
> 
> We can ship fixes a lot faster than RHEL, and more than one version of OSE
> is supported on RHEL at a time.

Are we also going to ship/maintain the mongo sosreport plugin and the AMQ plugin that the ose plugin will be using (at lease that is the desing Bryn and I discussed)? 

I think it makes since for us to ship / support the OSE and Mongo plugins out of OSE but AMQ should come from the AMQ channels or RHEL depending on who wants to ship / support them. 

When this starts to happen I think we start getting into some interesting dependency issues with entitlements (potentaly). 

- I point out this would only be a real problem if we ever swith message brokers or the DB that we support, or if we ever start support multiples (etc, etc)

> I think it makes since for us to ship / support the OSE and Mongo plugins out 
> of OSE but AMQ should come from the AMQ channels or RHEL depending on who 
> wants to ship / support them. 

Experience shows that this tends to get complicated quite quickly; it's almost always easier to just include everything in the main sos RPM. Unless there are differences of schedule that cannot be reconciled this is the preferred approach (and in that case it's generally better to ship a modified sos package in the other product's channels rather than fragmenting it across several packages/channels).

> For things like Mongo OSE and the SCL behave differently, is this being 
> considered when thinking about the sosplugin for mongo

Can you elaborate on the requirements here?

If it's not been recorded in bugzilla or the upstream issue-tracker it probably has not been taken into consideration.

(In reply to Bryn M. Reeves from comment #15)
channels).
> > For things like Mongo OSE and the SCL behave differently, is this being 
> > considered when thinking about the sosplugin for mongo
> 
> Can you elaborate on the requirements here?
> 
> If it's not been recorded in bugzilla or the upstream issue-tracker it
> probably has not been taken into consideration.

OpenShift Ships a version of Mongo that is it uses for the Broker (application). However we use the Mongo from the SCL to provide a cartridge for developers / users of the system. 

If were developing a Mongo sos-plugin that is RHEL supported I would assume that we would be looking for data from the SCL. As RHEL only supports Mongo out of this location. 

However the rub here is that OpenShift uses mongo stored out of a standard RPM install of mongo (IE: /etc, /var/log, etc) but this RPM is only shipped with add on products like OpenShift or OpenStack and between products they may not be the same version or distribution. 

Just wanted to know if this was considered when looking at the (dependency plugins).

To make it more interesting, now that the MongoDB SCL has actually been released, it would not surprise me if OpenShift and/or OpenStack start relying on that in the near future instead of shipping MongoDB separately.

I think these concerns belong upstream really; we won't make changes speculatively in RHEL6 for things that could happen in the future (e.g. OpenShift using an SCL version of Mongo). Once the change is being actively planned for a release we can revisit the sos support and adapt as needed.

I'm planning to take the OpenShift plugin (and related modules) that are now upstream and backport those pretty much 1:1 to sos-2.2.

commit f58eb6e445962a74c15e27cd010a890873a0046a
Author: Bryn M. Reeves <bmr>
Date:   Fri Jul 4 18:39:01 2014 +0100

    [mongodb] backport new plugin from upstream

commit 3774c418b967878081799b0c500cda4bf94a7049
Author: Bryn M. Reeves <bmr>
Date:   Fri Jul 4 18:38:45 2014 +0100

    [activemq] backport new plugin from upstream

commit 2264655266ff81e5bba3c016f247da34cc3edb04
Author: Bryn M. Reeves <bmr>
Date:   Fri Jul 4 18:38:22 2014 +0100

    [openshift] sync plugin with upstream

commit 1672d26505b76fc708f015377343c1e1ee2fffb4
Author: Bryn M. Reeves <bmr>
Date:   Fri Jul 4 18:36:49 2014 +0100

    [plugin] backport collectExtOutputs and addCopySpecs
    
    Backport the plural collection methods from upstream. This
    simplifies plugin backports (simple search-and-replace rather
    than converting a list argument into multiple function calls).

commit 27cf8454651453553a60c20c38040dbc3ccb770e
Author: Bryn M. Reeves <bmr>
Date:   Thu Dec 20 16:59:28 2012 +0000

    Make OpenShift module collect domain information
    
    Make the OpenShift module attempt a zone transfer for its domain
    (rather than it's hostname as originally implemented).

commit f4d351fb9d08667995254d2431a39e7d136e404c
Author: Bryn M. Reeves <bmr>
Date:   Mon Dec 17 19:55:24 2012 +0000

    Add 'gear' option to OpenShift module
    
    Add an option to allow the user to specify an optional gear UUID.

commit 51960a6af2fff7eb0914ddeccd859ae1bcd6a2c5
Author: Bryn M. Reeves <bmr>
Date:   Mon Dec 17 19:07:38 2012 +0000

    Add OpenShift module
    
    Add a module to collect OpenShift broker and node information.

Created attachment 916078 [details]
patch openshift.py to reduce glob based collection, obfuscate pwd

The /etc/openshift glob is collecting key material, replaced it with more targeted collection.

Also we were missing some obfuscation in the node's mcollective configuration.

> -            "/etc/openshift-enterprise-*",
> +            "/etc/openshift-enterprise-release",
 
Is this intentional? Iirc upstream the glob was required to match two possible variants in this path name?

>                  "/cgroup/*/openshift",

I missed this upstream; it's not a big deal for now but we should rip this out in future - it's duplicating paths collected by the cgroups plugin (and /cgroup isn't going to exist on anything up to date anyway).

(In reply to Bryn M. Reeves from comment #21)
> > -            "/etc/openshift-enterprise-*",
> > +            "/etc/openshift-enterprise-release",
>  
> Is this intentional? Iirc upstream the glob was required to match two
> possible variants in this path name?

In the upstream discussion there was a doubt about the file name; I've checked and at least for OSE 2.x it's -release, and as the plugin is aiming at 2.x and the patch was reducing glob-based collection I thought I'd update that too, feel free to ignore here and we'll clean up upstream for future versions.

> >                  "/cgroup/*/openshift",
> 
> I missed this upstream; it's not a big deal for now but we should rip this
> out in future - it's duplicating paths collected by the cgroups plugin (and
> /cgroup isn't going to exist on anything up to date anyway).

Yup we noticed during testing too... there are other minor things in the plugins that should be improved, but the patch in comment #20 was only aiming at the more serious parts (involving password/key collection).

https://github.com/openshift/origin-server/pull/5743 << This is something being considered (for node debuging) it would be nice to check for the ARCHIVE_DESTROYED_GEARS variable and ARCHIVE_DESTROYED_GEARS_DIR on a node and include that with what the node collects.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-1528.html