Re: [Ganglia-developers] gmond python modules location
I think this mostly works out: * https://github.com/ganglia/monitor-core/pull/183 * https://github.com/ganglia/gmond_python_modules/pull/184 On 02/06/2015 09:35 AM, Chris Burroughs wrote: That makes sense. For me in the import short term the thing is not manually trying to keep dupe code in sync. I'll start work on reconciling. On 02/05/2015 02:45 PM, Dave Rawks wrote: IIRC at least some of the motivation behind the current split had to do with separating out modules which aren't generally platform agnostic since platform specific stuff sometimes causes problems with downstream linux distro adoption/packaging. I.E. the official python modules should be expected to work on the full set of platforms that gmond works on. -Dave On 02/05/2015 11:21 AM, Chris Burroughs wrote: Currently python modules are bundled in monitor-core, some are in gmond_python_modules (or os specific repos), and a few are in both. Ones in monitor-core (at least in RedHat-land) get their own package which makes them easy to install. I suspect they are also presumed to by users to be somehow more 'official' or at least that's how I thought of them. I don't think gmond_python_modules has releases or os packaging for example. I suspect some of this might reflect a pre-git situation where it was harder to contribute to monitoring-core. I'd like to propose the following for now: * For modules that are in both monitor-core and somewhere else, make the monitor-core version canonical and remove the other. * Everything else stays where it is. This will make it for to contribute patches are report issues without looking in two different places and manually syncing files. Longer term there is probably something fancy we could do such as build time flags to opt modules in, or maybe switch to a deb/rpm per module. That way 'is this module good enough' can be decoupled from which repo is it in. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] gmond python modules location
You could change the location of all modules with modpython.conf, but I'm not sure there is a way to add multiple locations to the search path. What is the problem you are running into with one directory? I've usually had success with having $INSERT_CONFIG_MNGMT_TOOL drop in additional files. On 02/06/2015 04:37 PM, Yale Connect wrote: Is there best practices for separating custom/contrib gmond python modules from the packaged ones ? Currently I have to install everything under lib64 (ie. /usr/lib64/libganglia/python_modules) on our redhat boxes. It would be easier to do sysadmin tasks if the custom ones had a different location or easy to identify based on filename. regards, chris hunter yale hpc group On 02/05/2015 11:21 AM, Chris Burroughs wrote: Currently python modules are bundled in monitor-core, some are in gmond_python_modules (or os specific repos), and a few are in both. Ones in monitor-core (at least in RedHat-land) get their own package which makes them easy to install. I suspect they are also presumed to by users to be somehow more 'official' or at least that's how I thought of them. I don't think gmond_python_modules has releases or os packaging for example. I suspect some of this might reflect a pre-git situation where it was harder to contribute to monitoring-core. I'd like to propose the following for now: * For modules that are in both monitor-core and somewhere else, make the monitor-core version canonical and remove the other. * Everything else stays where it is. This will make it for to contribute patches are report issues without looking in two different places and manually syncing files. Longer term there is probably something fancy we could do such as build time flags to opt modules in, or maybe switch to a deb/rpm per module. That way 'is this module good enough' can be decoupled from which repo is it in. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] gmond python modules location
Thanks Chris for doing this. Vladimir On 02/09/2015 10:05 AM, Chris Burroughs wrote: I think this mostly works out: * https://github.com/ganglia/monitor-core/pull/183 * https://github.com/ganglia/gmond_python_modules/pull/184 On 02/06/2015 09:35 AM, Chris Burroughs wrote: That makes sense. For me in the import short term the thing is not manually trying to keep dupe code in sync. I'll start work on reconciling. On 02/05/2015 02:45 PM, Dave Rawks wrote: IIRC at least some of the motivation behind the current split had to do with separating out modules which aren't generally platform agnostic since platform specific stuff sometimes causes problems with downstream linux distro adoption/packaging. I.E. the official python modules should be expected to work on the full set of platforms that gmond works on. -Dave -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] gmond python modules location
That makes sense. For me in the import short term the thing is not manually trying to keep dupe code in sync. I'll start work on reconciling. On 02/05/2015 02:45 PM, Dave Rawks wrote: IIRC at least some of the motivation behind the current split had to do with separating out modules which aren't generally platform agnostic since platform specific stuff sometimes causes problems with downstream linux distro adoption/packaging. I.E. the official python modules should be expected to work on the full set of platforms that gmond works on. -Dave On 02/05/2015 11:21 AM, Chris Burroughs wrote: Currently python modules are bundled in monitor-core, some are in gmond_python_modules (or os specific repos), and a few are in both. Ones in monitor-core (at least in RedHat-land) get their own package which makes them easy to install. I suspect they are also presumed to by users to be somehow more 'official' or at least that's how I thought of them. I don't think gmond_python_modules has releases or os packaging for example. I suspect some of this might reflect a pre-git situation where it was harder to contribute to monitoring-core. I'd like to propose the following for now: * For modules that are in both monitor-core and somewhere else, make the monitor-core version canonical and remove the other. * Everything else stays where it is. This will make it for to contribute patches are report issues without looking in two different places and manually syncing files. Longer term there is probably something fancy we could do such as build time flags to opt modules in, or maybe switch to a deb/rpm per module. That way 'is this module good enough' can be decoupled from which repo is it in. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] gmond python modules location
Is there best practices for separating custom/contrib gmond python modules from the packaged ones ? Currently I have to install everything under lib64 (ie. /usr/lib64/libganglia/python_modules) on our redhat boxes. It would be easier to do sysadmin tasks if the custom ones had a different location or easy to identify based on filename. regards, chris hunter yale hpc group On 02/05/2015 11:21 AM, Chris Burroughs wrote: Currently python modules are bundled in monitor-core, some are in gmond_python_modules (or os specific repos), and a few are in both. Ones in monitor-core (at least in RedHat-land) get their own package which makes them easy to install. I suspect they are also presumed to by users to be somehow more 'official' or at least that's how I thought of them. I don't think gmond_python_modules has releases or os packaging for example. I suspect some of this might reflect a pre-git situation where it was harder to contribute to monitoring-core. I'd like to propose the following for now: * For modules that are in both monitor-core and somewhere else, make the monitor-core version canonical and remove the other. * Everything else stays where it is. This will make it for to contribute patches are report issues without looking in two different places and manually syncing files. Longer term there is probably something fancy we could do such as build time flags to opt modules in, or maybe switch to a deb/rpm per module. That way 'is this module good enough' can be decoupled from which repo is it in. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] gmond python modules location
IIRC at least some of the motivation behind the current split had to do with separating out modules which aren't generally platform agnostic since platform specific stuff sometimes causes problems with downstream linux distro adoption/packaging. I.E. the official python modules should be expected to work on the full set of platforms that gmond works on. -Dave On 02/05/2015 11:21 AM, Chris Burroughs wrote: Currently python modules are bundled in monitor-core, some are in gmond_python_modules (or os specific repos), and a few are in both. Ones in monitor-core (at least in RedHat-land) get their own package which makes them easy to install. I suspect they are also presumed to by users to be somehow more 'official' or at least that's how I thought of them. I don't think gmond_python_modules has releases or os packaging for example. I suspect some of this might reflect a pre-git situation where it was harder to contribute to monitoring-core. I'd like to propose the following for now: * For modules that are in both monitor-core and somewhere else, make the monitor-core version canonical and remove the other. * Everything else stays where it is. This will make it for to contribute patches are report issues without looking in two different places and manually syncing files. Longer term there is probably something fancy we could do such as build time flags to opt modules in, or maybe switch to a deb/rpm per module. That way 'is this module good enough' can be decoupled from which repo is it in. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
