From builds at travis-ci.org Tue May 21 15:30:24 2019 From: builds at travis-ci.org (Travis CI) Date: Tue, 21 May 2019 15:30:24 +0000 Subject: [sos-devel] Errored: sosreport/sos#3540 (master - 166f712) In-Reply-To: Message-ID: <5ce4198f9627b_43f9f6d4fdb38404573@0fa5c3ec-488f-4135-8328-a5c31a00d20f.mail> Build Update for sosreport/sos ------------------------------------- Build: #3540 Status: Errored Duration: 4 mins and 54 secs Commit: 166f712 (master) Author: Pavel Moravec Message: [katello] support both locations of qpid SSL certs Newer katello versions deploy certs for qpid to /etc/pki/pulp/qpid/client.crt certs instead of /etc/pki/katello/qpid_client_striped.crt . Sosreport should use either of the location that exists, to successfully run few qpid-stat commands. Resolves: #1680 Signed-off-by: Pavel Moravec View the changeset: https://github.com/sosreport/sos/compare/d0dcb39ea94e...166f712eb447 View the full build log and details: https://travis-ci.org/sosreport/sos/builds/535354735?utm_medium=notification&utm_source=email -- You can unsubscribe from build emails from the sosreport/sos repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=819743&utm_medium=notification&utm_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkonitzer at mirantis.com Tue May 28 21:35:42 2019 From: wkonitzer at mirantis.com (William Konitzer) Date: Tue, 28 May 2019 16:35:42 -0500 Subject: [sos-devel] Help requested getting sosreport to run with custom build of supported plugin Message-ID: <7D3AED65-60F5-473E-849B-F1398BA9C49D@mirantis.com> Hi, I?m looking for some assistance on the best way to get sosreport working on my system. Specifically we?re running a custom build of OpenStack on top of Ubuntu, so for instance if I take something like the ?openstack_nova" plugin, I see it does a check to see if the ?openstack-nova-api.service? is running, but on my system it?s called ?nova-api.service?. I'm trying to understand how to override this as I?m not really running on a unique Linux distribution but I?d like to keep the separation between DebianNova and our custom system so it doesn?t break anything for existing users. Any guidance and insights very much appreciated. Kind regards, Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From bmr at redhat.com Tue May 28 22:00:56 2019 From: bmr at redhat.com (Bryn M. Reeves) Date: Tue, 28 May 2019 23:00:56 +0100 Subject: [sos-devel] Help requested getting sosreport to run with custom build of supported plugin In-Reply-To: <7D3AED65-60F5-473E-849B-F1398BA9C49D@mirantis.com> References: <7D3AED65-60F5-473E-849B-F1398BA9C49D@mirantis.com> Message-ID: <20190528220055.GE18009@localhost.localdomain> On Tue, May 28, 2019 at 04:35:42PM -0500, William Konitzer wrote: > I?m looking for some assistance on the best way to get sosreport working on my system. > > Specifically we?re running a custom build of OpenStack on top of Ubuntu, so for instance if I take something like the ?openstack_nova" plugin, I see it does a check to see if the ?openstack-nova-api.service? is running, but on my system it?s called ?nova-api.service?. > > I'm trying to understand how to override this as I?m not really running on a unique Linux distribution but I?d like to keep the separation between DebianNova and our custom system so it doesn?t break anything for existing users. > > Any guidance and insights very much appreciated. You need to create a new policy that will trigger on your custom build, and then either create new tagged plugins for that policy, or hack around the differences between your environment and one of the existing supported distributions. This is probably the best there is in terms of documentation for this kind of work: https://github.com/sosreport/sos/wiki/How-to-Write-a-Policy Regards, Bryn. From wkonitzer at mirantis.com Wed May 29 14:29:33 2019 From: wkonitzer at mirantis.com (William Konitzer) Date: Wed, 29 May 2019 09:29:33 -0500 Subject: [sos-devel] Help requested getting sosreport to run with custom build of supported plugin In-Reply-To: <20190528220055.GE18009@localhost.localdomain> References: <7D3AED65-60F5-473E-849B-F1398BA9C49D@mirantis.com> <20190528220055.GE18009@localhost.localdomain> Message-ID: <307E6F6F-1B63-433B-844F-25364EA3DCD9@mirantis.com> Hi Bryn, OK, that?s how I thought it was probably supposed to work. However, we just use a stock Ubuntu distro with our custom build of OpenStack on top - I believe each sosreport policy is supposed to be unique, but I don?t know how to make my policy unique as the Ubuntu policy will also load. I?d rather try and fix this in sosreport than hacking the environment.. So essentially for my policy what I?m saying is, it will load both mine and the Ubuntu one, and if that happens I want it to ignore the Ubuntu one. Perhaps a config setting might be the way forward to trigger my custom policy and the rest will fall into place? Would that work? Regards, Will > On May 28, 2019, at 5:00 PM, Bryn M. Reeves wrote: > > On Tue, May 28, 2019 at 04:35:42PM -0500, William Konitzer wrote: >> I?m looking for some assistance on the best way to get sosreport working on my system. >> >> Specifically we?re running a custom build of OpenStack on top of Ubuntu, so for instance if I take something like the ?openstack_nova" plugin, I see it does a check to see if the ?openstack-nova-api.service? is running, but on my system it?s called ?nova-api.service?. >> >> I'm trying to understand how to override this as I?m not really running on a unique Linux distribution but I?d like to keep the separation between DebianNova and our custom system so it doesn?t break anything for existing users. >> >> Any guidance and insights very much appreciated. > > You need to create a new policy that will trigger on your custom build, > and then either create new tagged plugins for that policy, or hack > around the differences between your environment and one of the existing > supported distributions. > > This is probably the best there is in terms of documentation for this > kind of work: > > https://github.com/sosreport/sos/wiki/How-to-Write-a-Policy > > Regards, > Bryn. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bmr at redhat.com Wed May 29 14:45:40 2019 From: bmr at redhat.com (Bryn M. Reeves) Date: Wed, 29 May 2019 15:45:40 +0100 Subject: [sos-devel] Help requested getting sosreport to run with custom build of supported plugin In-Reply-To: <307E6F6F-1B63-433B-844F-25364EA3DCD9@mirantis.com> References: <7D3AED65-60F5-473E-849B-F1398BA9C49D@mirantis.com> <20190528220055.GE18009@localhost.localdomain> <307E6F6F-1B63-433B-844F-25364EA3DCD9@mirantis.com> Message-ID: <20190529144539.GF18009@localhost.localdomain> On Wed, May 29, 2019 at 09:29:33AM -0500, William Konitzer wrote: > Hi Bryn, > > OK, that?s how I thought it was probably supposed to work. However, we just use a stock Ubuntu distro with our custom build of OpenStack on top - I believe each sosreport policy is supposed to be unique, but I don?t know how to make my policy unique as the Ubuntu policy will also load. I?d rather try and fix this in sosreport than hacking the environment.. If you're looking to make something site-specific work, then you really are best off just hacking around it locally - and to be specific, I mean hacking around that in the local sos build, not the environment. A policy can do anything you like, so if you own the environment you can just take over the Ubuntu policy and have it do what you want. Obviously that isn't something that we could take upstream. If you are actually distributing this then it would be worth your while doing the work upstream - this is going to be an extensive set of changes, with plenty of scope for collisions, > So essentially for my policy what I?m saying is, it will load both mine and the Ubuntu one, and if that happens I want it to ignore the Ubuntu one. Perhaps a config setting might be the way forward to trigger my custom policy and the rest will fall into place? Would that work? Take a look at how inheritcance works - you can define additional tagging classes for plugins at any level in the policy hierarchy. Then we'd just need to ensure that your new/extra tagging class is bound more tightly when your sub-policy is in effect. Regards, Bryn. From wkonitzer at mirantis.com Wed May 29 15:15:46 2019 From: wkonitzer at mirantis.com (William Konitzer) Date: Wed, 29 May 2019 10:15:46 -0500 Subject: [sos-devel] Help requested getting sosreport to run with custom build of supported plugin In-Reply-To: <20190529144539.GF18009@localhost.localdomain> References: <7D3AED65-60F5-473E-849B-F1398BA9C49D@mirantis.com> <20190528220055.GE18009@localhost.localdomain> <307E6F6F-1B63-433B-844F-25364EA3DCD9@mirantis.com> <20190529144539.GF18009@localhost.localdomain> Message-ID: <20ECE66C-AB24-46EC-8DAC-9DD9B112A329@mirantis.com> I?m looking to promote sosreport as something we would distribute to customers so, yes I?m looking to integrate this upstream. Do you have an example showing additional tagging classes you could point me at. I think the rest will fall into place once I understand a little better what you are suggesting. Regards, Will > On May 29, 2019, at 9:45 AM, Bryn M. Reeves wrote: > > On Wed, May 29, 2019 at 09:29:33AM -0500, William Konitzer wrote: >> Hi Bryn, >> >> OK, that?s how I thought it was probably supposed to work. However, we just use a stock Ubuntu distro with our custom build of OpenStack on top - I believe each sosreport policy is supposed to be unique, but I don?t know how to make my policy unique as the Ubuntu policy will also load. I?d rather try and fix this in sosreport than hacking the environment.. > > If you're looking to make something site-specific work, then you > really are best off just hacking around it locally - and to be > specific, I mean hacking around that in the local sos build, not > the environment. A policy can do anything you like, so if you own > the environment you can just take over the Ubuntu policy and have > it do what you want. Obviously that isn't something that we could > take upstream. > > If you are actually distributing this then it would be worth your > while doing the work upstream - this is going to be an extensive > set of changes, with plenty of scope for collisions, > >> So essentially for my policy what I?m saying is, it will load both mine and the Ubuntu one, and if that happens I want it to ignore the Ubuntu one. Perhaps a config setting might be the way forward to trigger my custom policy and the rest will fall into place? Would that work? > > Take a look at how inheritcance works - you can define additional > tagging classes for plugins at any level in the policy hierarchy. > > Then we'd just need to ensure that your new/extra tagging class is > bound more tightly when your sub-policy is in effect. > > Regards, > Bryn. > -------------- next part -------------- An HTML attachment was scrubbed... URL: