-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I've written a python utility that interacts with the cobbler API, to allow a person to select what fields they want reported formatted for either: media wiki, doku, trac or plain text... here is an example:
Trac output: [root@bean2 tmp]# cobblersysreport -s cobbler.re.redhat.com -f trac ||profile||name||hostname||ip_address||vm|| ||RHEL-5-Server-U1-xen-x86_64||build01_re_redhat_com||build01||10.10.42.5||Yes|| ||RHEL-5-Server-U1-xen-x86_64||buildmaster01_re_redhat_com||buildmaster01||10.10.42.6||Yes|| ||RHEL-5-Server-U1-i386||buildnode01_re_redhat_com||buildnode01||10.10.42.10||No||
Doku output: [root@bean2 tmp]# cobblersysreport -s cobbler.re.redhat.com -f doku ^profile^name^hostname^ip_address^vm^ |RHEL-5-Server-U1-xen-x86_64|build01_re_redhat_com|build01|10.10.42.5|Yes| |RHEL-5-Server-U1-xen-x86_64|buildmaster01_re_redhat_com|buildmaster01|10.10.42.6|Yes| |RHEL-5-Server-U1-i386|buildnode01_re_redhat_com|buildnode01|10.10.42.10|No|
The fields reported can be picked by the user at /etc/cobblersysreport.conf, which looks like:
[root@bean2 tmp]# cat /etc/cobblersysreport.conf # all available fields (assumes only inft0 is available) # fields = 'profile','owners','kickstart','virt_bridge','name',\ # 'parent','virt_cpus','virt_type','dhcp_tag','subnet','virt_bridge',\ # 'hostname','mac_address','ip_address','gateway','vm' # # Fields to Display (order matters) order = 'profile', 'name', 'hostname', 'ip_address', 'vm'
The only major limitation of this utility right now it that it only allows 1 interface (intf0) to be selected via the config file.
I've talked privately to DeHaan about this and he suggested I share it on the list. I'm interesting into merging this feature upstream (as DeHaan has suggested):
like: cobbler system report [--name foo] [--format trac|text|...]
But, I am not sure if I should address the intf0 limitation first, and if this feature would really be worth being merged upstream or if it is too specific and would end up bloating the project too much.
I am up for discussions... Thanks,
AS
Anderson Silva wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I've written a python utility that interacts with the cobbler API, to allow a person to select what fields they want reported formatted for either: media wiki, doku, trac or plain text... here is an example:
Trac output: [root@bean2 tmp]# cobblersysreport -s cobbler.re.redhat.com -f trac ||profile||name||hostname||ip_address||vm|| ||RHEL-5-Server-U1-xen-x86_64||build01_re_redhat_com||build01||10.10.42.5||Yes|| ||RHEL-5-Server-U1-xen-x86_64||buildmaster01_re_redhat_com||buildmaster01||10.10.42.6||Yes|| ||RHEL-5-Server-U1-i386||buildnode01_re_redhat_com||buildnode01||10.10.42.10||No||
Doku output: [root@bean2 tmp]# cobblersysreport -s cobbler.re.redhat.com -f doku ^profile^name^hostname^ip_address^vm^ |RHEL-5-Server-U1-xen-x86_64|build01_re_redhat_com|build01|10.10.42.5|Yes| |RHEL-5-Server-U1-xen-x86_64|buildmaster01_re_redhat_com|buildmaster01|10.10.42.6|Yes| |RHEL-5-Server-U1-i386|buildnode01_re_redhat_com|buildnode01|10.10.42.10|No|
The fields reported can be picked by the user at /etc/cobblersysreport.conf, which looks like:
[root@bean2 tmp]# cat /etc/cobblersysreport.conf # all available fields (assumes only inft0 is available) # fields = 'profile','owners','kickstart','virt_bridge','name',\ # 'parent','virt_cpus','virt_type','dhcp_tag','subnet','virt_bridge',\ # 'hostname','mac_address','ip_address','gateway','vm' # # Fields to Display (order matters) order = 'profile', 'name', 'hostname', 'ip_address', 'vm'
The only major limitation of this utility right now it that it only allows 1 interface (intf0) to be selected via the config file.
I've talked privately to DeHaan about this and he suggested I share it on the list. I'm interesting into merging this feature upstream (as DeHaan has suggested):
like: cobbler system report [--name foo] [--format trac|text|...]
Right, as we were talking about it, it will default to "text" but we can offer up other options.
The question might come up as to why we also might want to do JSON/YAML, but at that point the thing doing the talking is an application that should probably be using the XMLRPC API. CSV is probably a fairly useful option for making spreadsheets.
Another idea I've had for a while is to teach cobbler report about what fields it should show. We could default this to a sane set of defaults, but also allow for custom usage like:
cobbler report [--name=foo] --fields=name,mac_address
Which would just generate a sorted list of system objects and their mac addresses.
This allows for things like:
cobbler system find --hostname="*web*" | xargs -n1 --replace cobbler report --name={} --fields=name,mac_address
Which would show all mac addresses with "web" in the hostname.
But, I am not sure if I should address the intf0 limitation first, and if this feature would really be worth being merged upstream or if it is too specific and would end up bloating the project too much.
I think it's worth it and fairly interesting, especially if we can move the report printing code out of each item_*.py file and into something like utils, it really won't be in the way.
I am up for discussions... Thanks,
AS -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFImcPJECmX3C4JWKgRAiuxAJoDP5ZfQI7U+ug5EoZGNosH/08tQgCfWh4U 1tzHRWxlhGkTfUc5u4K6j34= =dCrx -----END PGP SIGNATURE----- _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Michael DeHaan wrote:
Anderson Silva wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I've written a python utility that interacts with the cobbler API, to allow a person to select what fields they want reported formatted for either: media wiki, doku, trac or plain text... here is an example:
Trac output: [root@bean2 tmp]# cobblersysreport -s cobbler.re.redhat.com -f trac ||profile||name||hostname||ip_address||vm|| ||RHEL-5-Server-U1-xen-x86_64||build01_re_redhat_com||build01||10.10.42.5||Yes|| ||RHEL-5-Server-U1-xen-x86_64||buildmaster01_re_redhat_com||buildmaster01||10.10.42.6||Yes|| ||RHEL-5-Server-U1-i386||buildnode01_re_redhat_com||buildnode01||10.10.42.10||No||
Doku output: [root@bean2 tmp]# cobblersysreport -s cobbler.re.redhat.com -f doku ^profile^name^hostname^ip_address^vm^ |RHEL-5-Server-U1-xen-x86_64|build01_re_redhat_com|build01|10.10.42.5|Yes| |RHEL-5-Server-U1-xen-x86_64|buildmaster01_re_redhat_com|buildmaster01|10.10.42.6|Yes| |RHEL-5-Server-U1-i386|buildnode01_re_redhat_com|buildnode01|10.10.42.10|No|
The fields reported can be picked by the user at /etc/cobblersysreport.conf, which looks like:
[root@bean2 tmp]# cat /etc/cobblersysreport.conf # all available fields (assumes only inft0 is available) # fields = 'profile','owners','kickstart','virt_bridge','name',\ # 'parent','virt_cpus','virt_type','dhcp_tag','subnet','virt_bridge',\ # 'hostname','mac_address','ip_address','gateway','vm' # # Fields to Display (order matters) order = 'profile', 'name', 'hostname', 'ip_address', 'vm'
The only major limitation of this utility right now it that it only allows 1 interface (intf0) to be selected via the config file.
I've talked privately to DeHaan about this and he suggested I share it on the list. I'm interesting into merging this feature upstream (as DeHaan has suggested):
like: cobbler system report [--name foo] [--format trac|text|...]
Right, as we were talking about it, it will default to "text" but we can offer up other options.
The question might come up as to why we also might want to do JSON/YAML, but at that point the thing doing the talking is an application that should probably be using the XMLRPC API. CSV is probably a fairly useful option for making spreadsheets.
Another idea I've had for a while is to teach cobbler report about what fields it should show. We could default this to a sane set of defaults, but also allow for custom usage like:
cobbler report [--name=foo] --fields=name,mac_address
Which would just generate a sorted list of system objects and their mac addresses.
This allows for things like:
cobbler system find --hostname="*web*" | xargs -n1 --replace cobbler report --name={} --fields=name,mac_address
Which would show all mac addresses with "web" in the hostname.
But, I am not sure if I should address the intf0 limitation first, and if this feature would really be worth being merged upstream or if it is too specific and would end up bloating the project too much.
I think it's worth it and fairly interesting, especially if we can move the report printing code out of each item_*.py file and into something like utils, it really won't be in the way.
I am up for discussions... Thanks,
AS -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFImcPJECmX3C4JWKgRAiuxAJoDP5ZfQI7U+ug5EoZGNosH/08tQgCfWh4U 1tzHRWxlhGkTfUc5u4K6j34= =dCrx -----END PGP SIGNATURE----- _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Forgot to mention, WRT multiple interfaces, it's probably fair to just report multiple lines for the system in that case, rather than making it bleed over if using any of the Wiki/CSV type outputs. This basically makes the system report be a report of it's interfaces. The text can probably remain as it is today, though some improvement is welcome there too.
Yes, we'll want to support multiple interfaces as they are in wide-enough use that it would cause some confusion if we didn't.
--Michael
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Forgot to mention, WRT multiple interfaces, it's probably fair to just report multiple lines for the system in that case, rather than making it bleed over if using any of the Wiki/CSV type outputs. This basically makes the system report be a report of it's interfaces. The text can probably remain as it is today, though some improvement is welcome there too.
Yes, we'll want to support multiple interfaces as they are in wide-enough use that it would cause some confusion if we didn't.
Here is my question about multiple interfaces:
Let say I did:
cobbler system report --fields=name,mac_address
What mac_address would that be? Should one have to specify which interface they want? Or should we just assume that ==fields,mac_address will show as many mac_addresses as they are defined for a given system?
Pending the question above, here is my plan:
Alright, I will work on adapting the code to support multiple interfaces, and also instead of using the config file, I'll add the - --fields parameter.
Once I get that working, I will 'come back' and discuss more about integrating with cobbler.
Thanks,
AS
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I've made the following changes to cobblersysreport:
1. dropped config file 2. added support to pass fields via command line paramenter 3. added support to multiple interfaces (although display may be a bit quirky still).
[root@bean2 cobbler]# cobblersysreport -h Usage: cobblersysreport [options]
Options: -h, --help show this help message and exit -s SERVER, --server=SERVER Server you wish to user -t TYPE, --type=TYPE Type of output format -f FIELDS, --fields=FIELDS Fields for the report. Comma delimited. Available fields: profile,owners,kickstart, virt_bridge,name,parent,virt_cpus,virt_type, dhcp_tag,subnet,hostname,mac_address,ip_address gateway,vm -l, --list-types Available types of output
[root@bean2 cobbler]# cobblersysreport -f "name, hostname, vm, ip_address" -s cobbler.re.redhat.com -t trac ||name||hostname||vm||ip_address|| ||build01_re_redhat_com||build01||Yes||10.10.42.5|| ||buildmaster01_re_redhat_com||buildmaster01||Yes||10.10.42.6|| ||buildnode01_re_redhat_com||buildnode01||No||10.10.42.10|| ||buildnode02_re_redhat_com||buildnode02||Yes||10.10.42.11||
If there is more than one interface configured, let's say, host has 2 IP addresses, the information (for now would show up like this):
||ip_address|| || 10.0.0.1 10.0.0.2||
AS
Anderson Silva wrote:
Forgot to mention, WRT multiple interfaces, it's probably fair to just report multiple lines for the system in that case, rather than making it bleed over if using any of the Wiki/CSV type outputs. This basically makes the system report be a report of it's interfaces. The text can probably remain as it is today, though some improvement is welcome there too.
Yes, we'll want to support multiple interfaces as they are in wide-enough use that it would cause some confusion if we didn't.
Here is my question about multiple interfaces:
Let say I did:
cobbler system report --fields=name,mac_address
What mac_address would that be? Should one have to specify which interface they want? Or should we just assume that ==fields,mac_address will show as many mac_addresses as they are defined for a given system?
Pending the question above, here is my plan:
Alright, I will work on adapting the code to support multiple interfaces, and also instead of using the config file, I'll add the --fields parameter.
Once I get that working, I will 'come back' and discuss more about integrating with cobbler.
Thanks,
AS
_______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Anderson Silva wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I've made the following changes to cobblersysreport:
- dropped config file
- added support to pass fields via command line paramenter
- added support to multiple interfaces (although display may be a bit
quirky still).
Sounds good, next step is to submit a patch adding it to "cobbler report" :)
--Michael
[root@bean2 cobbler]# cobblersysreport -h Usage: cobblersysreport [options]
Options: -h, --help show this help message and exit -s SERVER, --server=SERVER Server you wish to user -t TYPE, --type=TYPE Type of output format -f FIELDS, --fields=FIELDS Fields for the report. Comma delimited. Available fields: profile,owners,kickstart, virt_bridge,name,parent,virt_cpus,virt_type, dhcp_tag,subnet,hostname,mac_address,ip_address gateway,vm -l, --list-types Available types of output
[root@bean2 cobbler]# cobblersysreport -f "name, hostname, vm, ip_address" -s cobbler.re.redhat.com -t trac ||name||hostname||vm||ip_address|| ||build01_re_redhat_com||build01||Yes||10.10.42.5|| ||buildmaster01_re_redhat_com||buildmaster01||Yes||10.10.42.6|| ||buildnode01_re_redhat_com||buildnode01||No||10.10.42.10|| ||buildnode02_re_redhat_com||buildnode02||Yes||10.10.42.11||
If there is more than one interface configured, let's say, host has 2 IP addresses, the information (for now would show up like this):
||ip_address|| || 10.0.0.1 10.0.0.2||
AS
This seems workable, the other option would be one interface per line, I'm not really sure which is better but we can wait until someone who is using it expresses the desire to have that, could even do both. I wouldn't worry about it too much now.
--Michael
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Sounds good, next step is to submit a patch adding it to "cobbler report" :)
--Michael
I am starting to look into the cobbler code... At first glance, it seems I should be able to patch commands.py
to add the following functionality:
cobbler system report [--name=foo] [--fields=name,mac_address] [--type=mediawiki]
On commands.py, it seems I need at least 2 things:
1. allow module to 'understand' the new parameters 2. have one or more functions that will take the new parameters and collect_fn() and generate the output.
I do have one question though, as cobblersysreport stands today, one is able to easily generate new 'outputtypes' for the report, currently doku, mediawiki, text and trac exist. See the file structure below:
|-- AUTHORS |-- INSTALL |-- LICENSE |-- MANIFEST.in |-- cobblersysreport |-- cobblersysreport.spec |-- cobblersystemreport | |-- __init__.py | `-- outputtype | |-- __init__.py | |-- doku.py | |-- mediawiki.py | |-- outputformat.py | |-- text.py | `-- trac.py `-- setup.py
What would be the preferred way to go about creating 'outputtype' within cobbler?
AS
Anderson Silva wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Sounds good, next step is to submit a patch adding it to "cobbler report" :)
--Michael
I am starting to look into the cobbler code... At first glance, it seems I should be able to patch commands.py
to add the following functionality:
cobbler system report [--name=foo] [--fields=name,mac_address] [--type=mediawiki]
On commands.py, it seems I need at least 2 things:
- allow module to 'understand' the new parameters
- have one or more functions that will take the new parameters and
collect_fn() and generate the output.
Sounds about right...
I do have one question though, as cobblersysreport stands today, one is able to easily generate new 'outputtypes' for the report, currently doku, mediawiki, text and trac exist. See the file structure below:
|-- AUTHORS |-- INSTALL |-- LICENSE |-- MANIFEST.in |-- cobblersysreport |-- cobblersysreport.spec |-- cobblersystemreport | |-- __init__.py | `-- outputtype | |-- __init__.py | |-- doku.py | |-- mediawiki.py | |-- outputformat.py | |-- text.py | `-- trac.py `-- setup.py
What would be the preferred way to go about creating 'outputtype' within cobbler?
The report code is in commands.py which is pretty much the only file you really need to change.
If you would want to create a file like action_report.py and move all the code into there I think that's reasonable too. commands.py could call out to that.
We probably don't want a file for each different output format, I imagine they are all rather short and can live in that one file.
No worries though, if you submit something and we decided to rearrange it later, that's not a problem.
AS -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFImww0ECmX3C4JWKgRAmvvAJsF4t9gDfTcPUfUOPeHxoT4SlwS2QCfT4Vy +CKbck5I+Dd4mbb4az9BC4M= =DRsH -----END PGP SIGNATURE----- _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The report code is in commands.py which is pretty much the only file
you
really need to change.
If you would want to create a file like action_report.py and move all the code into there I think that's reasonable too. commands.py could call out to that.
We probably don't want a file for each different output format, I imagine they are all rather short and can live in that one file.
No worries though, if you submit something and we decided to rearrange it later, that's not a problem.
Alright, so as I've done more reading on the code, I am not sure how excited I'd be about hardcoding templates into commands.py... Plus, part of the idea of cobblersysreport was to generate a table/grid like output for quick documentation on a wiki.
For the amount of information given out by cobbler report --what=all (for example), I don't think a table like output would make much sense.
And the idea to filter the fields is a good one, but that can be accomplished by using egrep, like:
[root@cobbler ~]# cobbler report --what=all | egrep -e "(system|mac)" system : build01_re_redhat_com mac address : 00:16:3e:01:4a:b9 system : buildmaster01_re_redhat_com mac address : 00:16:3e:76:4f:69 system : buildnode01_re_redhat_com mac address : 00:0F:1F:03:FE:63 system : buildnode02_re_redhat_com mac address : 00:16:3e:4d:98:52 system : cobbler_re_redhat_com mac address : 00:16:3e:3b:26:14
So, unless anyone disagrees with me and have a good argument to try to keep moving any of those features into cobbler itself, I will go ahead and withdraw from this 'feature' for cobbler.
Let me know.
AS
Anderson Silva wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The report code is in commands.py which is pretty much the only file
you
really need to change.
If you would want to create a file like action_report.py and move all the code into there I think that's reasonable too. commands.py could call out to that.
We probably don't want a file for each different output format, I imagine they are all rather short and can live in that one file.
No worries though, if you submit something and we decided to rearrange it later, that's not a problem.
Alright, so as I've done more reading on the code, I am not sure how excited I'd be about hardcoding templates into commands.py... Plus, part of the idea of cobblersysreport was to generate a table/grid like output for quick documentation on a wiki.
I don't believe anything was said about "hardcoding" anything.
For the amount of information given out by cobbler report --what=all (for example), I don't think a table like output would make much sense.
Which is why we only want to generate reports for certain things/fields, yes...
And the idea to filter the fields is a good one, but that can be accomplished by using egrep, like:
[root@cobbler ~]# cobbler report --what=all | egrep -e "(system|mac)" system : build01_re_redhat_com mac address : 00:16:3e:01:4a:b9 system : buildmaster01_re_redhat_com mac address : 00:16:3e:76:4f:69 system : buildnode01_re_redhat_com mac address : 00:0F:1F:03:FE:63 system : buildnode02_re_redhat_com mac address : 00:16:3e:4d:98:52 system : cobbler_re_redhat_com mac address : 00:16:3e:3b:26:14
Grep doesn't make sense when wanting to report table formatted output like what you were opposing.
So, unless anyone disagrees with me and have a good argument to try to keep moving any of those features into cobbler itself, I will go ahead and withdraw from this 'feature' for cobbler.
If you don't want to add it after all, don't add it. I'm not sure I understand the change of heart, but I am not going to argue with someone about adding a feature they don't want to add.
Let me know.
AS -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFImy7TECmX3C4JWKgRAvblAJ0eT5b86jYN7jYCdjbbGozKRO1zmwCeMD5F PUhMDtkBI9C/VBpmhFi9jAY= =iM/X -----END PGP SIGNATURE----- _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
If you don't want to add it after all, don't add it. I'm not sure I understand the change of heart, but I am not going to argue with someone about adding a feature they don't want to add.
I am not trying to argue at all... I am just questioning the usability of adding such a specific feature to cobbler. Maybe the xmlrpc service, plus the API, and cobbler report, may already be good enough for ways to extract data from cobbler.
That's all I am questioning. I am just trying discuss with anyone on the list who may have an opinion about this.
AS
Anderson Silva wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
If you don't want to add it after all, don't add it. I'm not sure I
understand the change of heart, but I am not going to argue with someone about adding a feature they don't want to add.
I am not trying to argue at all... I am just questioning the usability of adding such a specific feature to cobbler. Maybe the xmlrpc service, plus the API, and cobbler report, may already be good enough for ways to extract data from cobbler.
That's all I am questioning. I am just trying discuss with anyone on the list who may have an opinion about this.
I would find being able to output into multiple data formats, particularly CSV, to be rather useful.
AS -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFIm0DJECmX3C4JWKgRAhuhAKCYQ9vEoq59dlJDBHi4k+icLtZQEQCglYD0 EV1WiRDobnhpRFp/IwCB6Q4= =K7IE -----END PGP SIGNATURE----- _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Michael DeHaan wrote:
Anderson Silva wrote:
If you don't want to add it after all, don't add it. I'm not sure I
understand the change of heart, but I am not going to argue with someone about adding a feature they don't want to add.
I am not trying to argue at all... I am just questioning the usability of adding such a specific feature to cobbler. Maybe the xmlrpc service, plus the API, and cobbler report, may already be good enough for ways to extract data from cobbler.
That's all I am questioning. I am just trying discuss with anyone on the list who may have an opinion about this.
I would find being able to output into multiple data formats, particularly CSV, to be rather useful.
AS
fair enough... I will keep poking at it. Thanks.
AS
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Just an update on the cobbler report front:
I have the following working:
cobbler report --what=systems --type=mediawiki --fields=name,profile
1. It supports: mediawiki, trac, csv, doku and text.
text is the default (and currently, it just uses the standard: reporting_print_sorted and reporting_list_names2 functions.
2. I have moved reporting to its own action: action_report.py
3. I've removed things out of cli_misc.py, and created a cli_report.py
I still have to do some more cleaning up, and a bit more documenting, I hope to have a working patch by the end of the week.
AS
Anderson Silva wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Just an update on the cobbler report front:
I have the following working:
cobbler report --what=systems --type=mediawiki --fields=name,profile
- It supports: mediawiki, trac, csv, doku and text.
text is the default (and currently, it just uses the standard: reporting_print_sorted and reporting_list_names2 functions.
I have moved reporting to its own action: action_report.py
I've removed things out of cli_misc.py, and created a cli_report.py
I still have to do some more cleaning up, and a bit more documenting, I hope to have a working patch by the end of the week.
AS
Outstanding. Thanks for doing this!
--Michael
cobbler@lists.fedorahosted.org