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:
> [EMAIL PROTECTED] 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:
> [EMAIL PROTECTED] 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:
>
> [EMAIL PROTECTED] 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
> [email protected]
> https://fedorahosted.org/mailman/listinfo/cobbler
>
_______________________________________________
cobbler mailing list
[email protected]
https://fedorahosted.org/mailman/listinfo/cobbler
