Re: [Spacewalk-devel] XMLRPC APIs

2009-07-08 Thread Pradeep Kilambi

Jason Dobies wrote:
In registration.py, why is the new_system_activation_key API commented 
out? I might be missing it but I don't see an explanation in the code.




To being with that was just a place holder. That call was never 
implemented afaik. It was added as part of the initial RHEL-5 changes. 
We already handle the activation keys in create_systems call which is in 
turn called by new_system and new_system_user_pass so use that instead. 
Lemme know if you need help with usage on that. I dont see any need for 
the call based on current use cases we have. I'll go ahead and clean it up.


~ Prad

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel


[Spacewalk-devel] XMLRPC APIs

2009-07-08 Thread Jason Dobies
In registration.py, why is the new_system_activation_key API commented 
out? I might be missing it but I don't see an explanation in the code.


--
Jason Dobies
RHN Satellite / Spacewalk
RHCE# 805008743336126
Freenode: jdob @ #spacewalk #spacewalk-devel

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel


[Spacewalk-devel] [PATCH] rhncfg-client channels lists channels in the wrong order

2009-07-08 Thread Maxim Burgerhout
This is a resend, something seems to have gone horribly wrong with the
previous attempt...

Hi,

The patch below reverses the order in which the Python rhncfg-client
script lists subscribed configuration channels for the current system.
The current commandline implementation lists the channels from the
lowest to highest rank, like this:

$ sudo rhncfg-client channels
Config channels:
Label   Name
-  
lowest channel with lowest priority
low  channel with low priority
high channel with high priority
highestchannel with highest priority

The Satellite / Spacewalk web-based management interface lists the
channels the other way around. As the rhncfg-client script output has
no indication what the order is in which the channels are listed, and
because the order of the channels can be pretty important, I suggest a
small fix.

Which is patching /usr/share/rhn/config_client/rpc_cli_repository.py like this:

--- rpc_cli_repository.py.orig  2009-07-08 15:23:28.0 +0200
+++ rpc_cli_repository.py   2009-07-08 15:25:07.0 +0200
@@ -53,6 +53,7 @@
log_debug(4)
self.config_channels = self.rpc_call(
'config.client.list_config_channels', self.system_id)
+self.config_channels.reverse()
return self.config_channels

def list_files(self):

This makes sure self.config_channels will be filled with the
subscribed configuration channels for the current system, in the order
that is consistent with the web-based interface.

Mind that I made this patch against the Satellite code I have at hand
here. I did check Spacewalk git master to see if the scripts look
different there and they do not, so the patch should apply fine. I do
*not* know, however, if Spacewalk returns the channels in the 'right'
order in the first place, contrary to Satellite.

Maxim Burgerhout
ma...@wzzrd.com

GPG Fingerprint
1CC2 A9B2 FE2E 799D 01DB 8A89 0AE8 B60A ACA3 4452

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel


[Spacewalk-devel] [PATCH] rhncfg-client channels lists channels in the wrong order

2009-07-08 Thread Maxim Burgerhout
Hi,

The patch below reverses the order in which the Python rhncfg-client
script lists subscribed configuration channels for the current system.
The current commandline implementation lists the channels from the
lowest to highest rank, like this:

$ sudo rhncfg-client channels
Config channels:
Label   Name
-  
lowest channel with lowest priority
low  channel with low priority
high channel with high priority
highestchannel with highest priority

The Satellite / Spacewalk web-based management interface lists the
channels the other way around. As the rhncfg-client script output has
no indication what the order is in which the channels are listed, and
because the order of the channels can be pretty important, I suggest a
small fix.

Which is patching /usr/share/rhn/config_client/rpc_cli_repository.py like this:

--- rpc_cli_repository.py.orig  2009-07-08 15:23:28.0 +0200
+++ rpc_cli_repository.py   2009-07-08 15:25:07.0 +0200
@@ -53,6 +53,7 @@
 log_debug(4)
 self.config_channels = self.rpc_call(
 'config.client.list_config_channels', self.system_id)
+self.config_channels.reverse()
 return self.config_channels

 def list_files(self):

This makes sure self.config_channels will be filled with the
subscribed configuration channels for the current system, in the order
that is consistent with the web-based interface.

Mind that I made this patch against the Satellite code I have at hand
here. I did check Spacewalk git master to see if the scripts look
different there and they do not, so the patch should apply fine. I do
*not* know, however, if Spacewalk returns the channels in the 'right'
order in the first place, contrary to Satellite.

Maxim Burgerhout
ma...@wzzrd.com

GPG Fingerprint
1CC2 A9B2 FE2E 799D 01DB 8A89 0AE8 B60A ACA3 4452

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel