10:31 a.m.
-----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
-----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-----
11:01 a.m.
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(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler
11:08 a.m.
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
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 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(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/cobbler
>
>
_______________________________________________
cobbler mailing list
cobbler(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler
11:16 a.m.
-----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 SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFImc5nECmX3C4JWKgRAugQAKC9BbZqcBkiq2F/zMA6FWy6a4BTfQCeIcPh
HhTdHMCd8OK6KzyMYPLO/TI=
=PAx3
-----END PGP SIGNATURE-----
2:18 p.m.
-----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(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFImfjtECmX3C4JWKgRAiYPAJ4rl2hC7N8CXA74ouQe46DKr1S0rwCeLbS3
Z1HItbM6Umtex436ZshH2Ts=
=dVrC
-----END PGP SIGNATURE-----
3:03 p.m.
Anderson Silva wrote:
-----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).
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
9:52 a.m.
New subject: cobblersysreport utility
-----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
-----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-----
10:08 a.m.
New subject: cobblersysreport utility
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:
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.
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(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler
12:20 p.m.
New subject: cobblersysreport utility
-----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
-----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-----
1:27 p.m.
New subject: cobblersysreport utility
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(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler
1:36 p.m.
New subject: cobblersysreport utility
-----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
-----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-----
2:45 p.m.
New subject: cobblersysreport utility
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(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler
2:44 p.m.
New subject: cobblersysreport utility
-----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 SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFIm1CaECmX3C4JWKgRAqL8AKDIz4g8wl3+MnuZImKQbOOYhUG0tACg17DB
IQFDRZh9WpvNkolypuxVY9w=
=UnsP
-----END PGP SIGNATURE-----
2:17 p.m.
New subject: cobblersysreport utility
-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFIqxw4ECmX3C4JWKgRAjMOAJwLpt2+RQLCKofbWK6SToSuV0j28gCfSdAg
5GtulbzalpbUpUGvzMR6onU=
=Ur4v
-----END PGP SIGNATURE-----
2:29 p.m.
New subject: cobblersysreport utility
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
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
Outstanding. Thanks for doing this!
--Michael
5750
days inactive
5763
days old
cobbler@lists.fedorahosted.org
15 comments
2 participants
participants (2)
-
Anderson Silva -
Michael DeHaan