From jjaggars at redhat.com Mon Feb 6 23:04:32 2012 From: jjaggars at redhat.com (Jesse Jaggars) Date: Mon, 06 Feb 2012 18:04:32 -0500 (EST) Subject: [sos-devel] sanitize upstream In-Reply-To: <5dc4df55-c4a4-4ec1-8ffe-9aa786445856@zmail09.collab.prod.int.phx2.redhat.com> Message-ID: <705d29c9-89be-4dde-981d-6ee7ef4366ae@zmail09.collab.prod.int.phx2.redhat.com> I noticed that the sanitize plugin is not present in sosreport master. It seems to be in the 2.1 release in F16 (and in RHEL too I'm sure). Anybody know when or why it was removed? Jesse From bmr at redhat.com Tue Feb 7 10:18:41 2012 From: bmr at redhat.com (Bryn M. Reeves) Date: Tue, 07 Feb 2012 10:18:41 +0000 Subject: [sos-devel] sanitize upstream In-Reply-To: <705d29c9-89be-4dde-981d-6ee7ef4366ae@zmail09.collab.prod.int.phx2.redhat.com> References: <705d29c9-89be-4dde-981d-6ee7ef4366ae@zmail09.collab.prod.int.phx2.redhat.com> Message-ID: <4F30FA81.1020605@redhat.com> On 02/06/2012 11:04 PM, Jesse Jaggars wrote: > I noticed that the sanitize plugin is not present in sosreport > master. It seems to be in the 2.1 release in F16 (and in RHEL too > I'm sure). Anybody know when or why it was removed? > > Jesse commit 383863ef10bc46d5ddc7ca3a943861d9f5624ce2 Author: pcarrier Date: Tue Nov 23 09:16:17 2010 +0000 [sos] removal of sanitize.py Does not belong here. git-svn-id: svn+ssh://svn.fedorahosted.org/svn/sos/trunk at 1029 ef72aa8b-4018-0410-8976-d6e080ef94d8 I tend to agree with the commit message. The sanitize module was a silly idea with a half-baked implementation. This is also one reason for my wanting to get the RHEL packaging into git - it makes finding discrepancies between the branches much easier (we're missing a few fixes in master that are present in rhel-6 for e.g.). Regards, Bryn. From bmr at redhat.com Tue Feb 7 10:44:41 2012 From: bmr at redhat.com (Bryn M. Reeves) Date: Tue, 07 Feb 2012 10:44:41 +0000 Subject: [sos-devel] sanitize upstream In-Reply-To: <4F30FA81.1020605@redhat.com> References: <705d29c9-89be-4dde-981d-6ee7ef4366ae@zmail09.collab.prod.int.phx2.redhat.com> <4F30FA81.1020605@redhat.com> Message-ID: <4F310099.4070109@redhat.com> On 02/07/2012 10:18 AM, Bryn M. Reeves wrote: > commit 383863ef10bc46d5ddc7ca3a943861d9f5624ce2 Author: pcarrier > Date: Tue Nov 23 > 09:16:17 2010 +0000 > > [sos] removal of sanitize.py > > Does not belong here. > > git-svn-id: svn+ssh://svn.fedorahosted.org/svn/sos/trunk at 1029 > ef72aa8b-4018-0410-8976-d6e080ef94d8 OK, I just took a look at the actual plugin in 2.2: it's total garbage. It duplicates functionality from the general plugin and provides so little functionality it's scary - I really would not want anyone to get the impression that the "scrubbing" it does is actually worth a damn so I am tempted to remove it in a future RHEL6 update and migrate what little it does to the general plugin. Regards, Bryn. From jjaggars at redhat.com Tue Feb 7 15:44:36 2012 From: jjaggars at redhat.com (Jesse Jaggars) Date: Tue, 07 Feb 2012 10:44:36 -0500 (EST) Subject: [sos-devel] sanitize upstream In-Reply-To: <4F310099.4070109@redhat.com> Message-ID: Ok, I took a look after seeing the thread on gss-list yesterday. I really don't think a plugin makes any sense so it's good that it was removed. Thanks, Jesse ----- Original Message ----- On 02/07/2012 10:18 AM, Bryn M. Reeves wrote: > commit 383863ef10bc46d5ddc7ca3a943861d9f5624ce2 Author: pcarrier > Date: Tue Nov 23 > 09:16:17 2010 +0000 > > [sos] removal of sanitize.py > > Does not belong here. > > git-svn-id: svn+ssh://svn.fedorahosted.org/svn/sos/trunk at 1029 > ef72aa8b-4018-0410-8976-d6e080ef94d8 OK, I just took a look at the actual plugin in 2.2: it's total garbage. It duplicates functionality from the general plugin and provides so little functionality it's scary - I really would not want anyone to get the impression that the "scrubbing" it does is actually worth a damn so I am tempted to remove it in a future RHEL6 update and migrate what little it does to the general plugin. Regards, Bryn. From bmr at redhat.com Wed Feb 8 19:16:04 2012 From: bmr at redhat.com (Bryn M. Reeves) Date: Wed, 08 Feb 2012 19:16:04 +0000 Subject: [sos-devel] s/plugin/module/g? Message-ID: <4F32C9F4.6020700@redhat.com> I find myself increasingly talking about sos modules rather than plugins mostly to try to avoid the impression that we're offering a stable interface to 3rd party code. Module bothers me a little due to potential confusion with python modules but I wonder if it's worth changing the term (to module or some other better name) in our code and docs to make this clearer? I definitely want to document the fact that we prefer all the bits (apart from site-local possibly) to be shipped in the sos package for future versions. Cheers, Bryn. From streeter at redhat.com Wed Feb 8 20:01:05 2012 From: streeter at redhat.com (Guy Streeter) Date: Wed, 08 Feb 2012 14:01:05 -0600 Subject: [sos-devel] sospreort plugin for realtime kernel Message-ID: <4F32D481.3060006@redhat.com> Our rt kernel developers suggested a few things sos might report for systems running the realtime kernel. I've created and test a plugin to implement this. thanks, --Guy -------------- next part -------------- A non-text attachment was scrubbed... Name: kernel_rt.py Type: text/x-python Size: 1563 bytes Desc: not available URL: From jjaggars at redhat.com Wed Feb 8 20:07:14 2012 From: jjaggars at redhat.com (Jesse Jaggars) Date: Wed, 08 Feb 2012 15:07:14 -0500 (EST) Subject: [sos-devel] s/plugin/module/g? In-Reply-To: <4F32C9F4.6020700@redhat.com> Message-ID: <7719f8f1-cf13-4ad1-b9ed-fefe45bad118@zmail09.collab.prod.int.phx2.redhat.com> I can see a small benefit in calling them modules, since they literally are python modules. My only reservation would be that module doesn't really explain what purpose they serve, although plugin is just as bad. I have been operating under the assumption that the 'plugin' interface was intended to be stable. I did make alterations, but I also believe we should bump the major version number to reflect the change. In terms of pure terminology, I don't think plugin is a better or worse term than module, so either term is acceptable to me. Thanks, Jesse ----- Original Message ----- I find myself increasingly talking about sos modules rather than plugins mostly to try to avoid the impression that we're offering a stable interface to 3rd party code. Module bothers me a little due to potential confusion with python modules but I wonder if it's worth changing the term (to module or some other better name) in our code and docs to make this clearer? I definitely want to document the fact that we prefer all the bits (apart from site-local possibly) to be shipped in the sos package for future versions. Cheers, Bryn. _______________________________________________ Sos-devel mailing list Sos-devel at redhat.com https://www.redhat.com/mailman/listinfo/sos-devel From bmr at redhat.com Wed Feb 8 20:18:19 2012 From: bmr at redhat.com (Bryn M. Reeves) Date: Wed, 08 Feb 2012 20:18:19 +0000 Subject: [sos-devel] s/plugin/module/g? In-Reply-To: <7719f8f1-cf13-4ad1-b9ed-fefe45bad118@zmail09.collab.prod.int.phx2.redhat.com> References: <7719f8f1-cf13-4ad1-b9ed-fefe45bad118@zmail09.collab.prod.int.phx2.redhat.com> Message-ID: <4F32D88B.8080002@redhat.com> On 02/08/2012 08:07 PM, Jesse Jaggars wrote: > I can see a small benefit in calling them modules, since they literally > are python modules. My only reservation would be that module doesn't > really explain what purpose they serve, although plugin is just as bad. Right :) I find myself using module as a least-worst kind of thing. > I have been operating under the assumption that the 'plugin' interface was > intended to be stable. I did make alterations, but I also believe we should > bump the major version number to reflect the change. I think there are two problems with the interface as it stands: in the past it's never really been well-defined or had guarantees and because of the way the plugins operate we've sometimes had to make changes across whole sets of files in updates. Out of tree modules make that even more complex as you have to chase them down and get updates there too. The other problem is that the plugins also create an interface to consumers of the data. This has the same problem with definition (or a lack of it) but that's something we've already talked about improving. > In terms of pure terminology, I don't think plugin is a better or worse term > than module, so either term is acceptable to me. No strong attachments here either apart from the connotations of plugin but I can't think of anything better so far.. Cheers, Bryn. From jjaggars at redhat.com Wed Feb 8 20:57:39 2012 From: jjaggars at redhat.com (Jesse Jaggars) Date: Wed, 08 Feb 2012 14:57:39 -0600 Subject: [sos-devel] s/plugin/module/g? In-Reply-To: <4F32D88B.8080002@redhat.com> References: <7719f8f1-cf13-4ad1-b9ed-fefe45bad118@zmail09.collab.prod.int.phx2.redhat.com> <4F32D88B.8080002@redhat.com> Message-ID: <4F32E1C3.2000403@redhat.com> On 02/08/2012 02:18 PM, Bryn M. Reeves wrote: > On 02/08/2012 08:07 PM, Jesse Jaggars wrote: >> I can see a small benefit in calling them modules, since they literally >> are python modules. My only reservation would be that module doesn't >> really explain what purpose they serve, although plugin is just as bad. > Right :) > > I find myself using module as a least-worst kind of thing. > >> I have been operating under the assumption that the 'plugin' interface was >> intended to be stable. I did make alterations, but I also believe we should >> bump the major version number to reflect the change. > I think there are two problems with the interface as it stands: in the > past it's never really been well-defined or had guarantees and because > of the way the plugins operate we've sometimes had to make changes > across whole sets of files in updates. Out of tree modules make that > even more complex as you have to chase them down and get updates there too. > > The other problem is that the plugins also create an interface to > consumers of the data. This has the same problem with definition (or a > lack of it) but that's something we've already talked about improving. Ah I agree that these are both issues with the current system. At the implementation level there are several ugly bits about the interface between a plugin/module subclass and the superclass. Those could be ironed out and cleaned up, but I'm not sure if just tweaking the current 'api' is the best thing or not. I do think that if we ever want to widen support for sosreport beyond the redhat/fedora/jboss world we will have to present a stable API for folks to use. The outbound interface is a tough problem for sure, but I think it's such a different issue that it has to be handled in a completely different conversation (though it is certainly just as important and valuable). >> In terms of pure terminology, I don't think plugin is a better or worse term >> than module, so either term is acceptable to me. > No strong attachments here either apart from the connotations of plugin > but I can't think of anything better so far.. Today we now have a policy 'api' for defining how to work with other distributions and operating systems. I have simply been calling those policies. I can't summon up a better term for what we have been calling a plugin either. > Cheers, > Bryn. Jesse From ndevos at redhat.com Sat Feb 11 11:00:09 2012 From: ndevos at redhat.com (Niels de Vos) Date: Sat, 11 Feb 2012 11:00:09 +0000 Subject: [sos-devel] sospreort plugin for realtime kernel In-Reply-To: <4F32D481.3060006@redhat.com> References: <4F32D481.3060006@redhat.com> Message-ID: <4F364A39.50101@redhat.com> On 02/08/2012 08:01 PM, Guy Streeter wrote: > Our rt kernel developers suggested a few things sos might report for systems > running the realtime kernel. I've created and test a plugin to implement this. Nice! I would suggest to include these two files regardless of kernel type: - /sys/devices/system/clocksource/clocksource0/available_clocksource - /sys/devices/system/clocksource/clocksource0/current_clocksource Was this tested when the package 'tuna' was installed? /ust/bin/head would likely give an error... > if self.isInstalled('tuna'): > self.collectExtOutput('/usr/bin/tuna -CP | /ust/bin/head -20') Cheers, Niels From streeter at redhat.com Mon Feb 13 15:56:47 2012 From: streeter at redhat.com (Guy Streeter) Date: Mon, 13 Feb 2012 09:56:47 -0600 Subject: [sos-devel] sospreort plugin for realtime kernel In-Reply-To: <4F364A39.50101@redhat.com> References: <4F32D481.3060006@redhat.com> <4F364A39.50101@redhat.com> Message-ID: <4F3932BF.5050508@redhat.com> On 02/11/2012 05:00 AM, Niels de Vos wrote: > On 02/08/2012 08:01 PM, Guy Streeter wrote: >> Our rt kernel developers suggested a few things sos might report for systems >> running the realtime kernel. I've created and test a plugin to implement this. > > Nice! > > I would suggest to include these two files regardless of kernel type: > - /sys/devices/system/clocksource/clocksource0/available_clocksource > - /sys/devices/system/clocksource/clocksource0/current_clocksource > > Was this tested when the package 'tuna' was installed? /ust/bin/head would > likely give an error... > > > if self.isInstalled('tuna'): > > self.collectExtOutput('/usr/bin/tuna -CP | /ust/bin/head -20') > lovely. I went back and added the full paths to the executables after I tested :) --Guy From bmr at redhat.com Tue Feb 21 10:21:05 2012 From: bmr at redhat.com (Bryn M. Reeves) Date: Tue, 21 Feb 2012 10:21:05 +0000 Subject: [sos-devel] Fwd: Re: Some fedora projects are still not using transifex (properly) In-Reply-To: <20120221095625.GA2714@f15.lan> References: <20120221095625.GA2714@f15.lan> Message-ID: <4F437011.1060600@redhat.com> I lost the top of thread but this is another topic for our (soon-to-be appointed or re-appointed :-) sos Fedora maintainer: -------- Original Message -------- Subject: Re: Some fedora projects are still not using transifex (properly) Date: Tue, 21 Feb 2012 10:56:25 +0100 From: K?vin Raymond Reply-To: Development discussions related to Fedora To: Development discussions related to Fedora Le mardi 21 f?vr. 2012 ? 10:20:32 (+0100), Alan Pevec a ?crit : > > Semi-related question: what's the procedure to get new language team > approved on transifex? > I see few teams hanging in requested state at > https://fedora.transifex.net/projects/p/fedora/ They have probably not done all necessary steps: https://fedoraproject.org/wiki/L10N_Maintainer But I am not sure if anyone take care of them in order to help growing our community. IMHO this is FLSCo related, we should probably handle new election after the next release to refresh things. (Last election was on 2008). -- K?vin Raymond (Shaiton) -------------- next part -------------- A non-text attachment was scrubbed... Name: Attached Message Part Type: application/pgp-signature Size: 199 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Attached Message Part URL: