stdevel / arsa Goto Github PK

The --dry-run pararemeter is ignored if a huge amount of actions is being removed (workaround).

Currently newer releases such as Spacewalk 2.3 or 2.4 are not supported because of the API level check.

Red Hat Portal user "Remmele" had the idea to prompt the user for login information: https://access.redhat.com/site/discussions/874773

Passing the login information using shell variables can be a security problem unless you're dropping shell history support for your command:

HISTFILE="" SATELLITE_LOGIN=mylogin SATELLITE_PASSWORD=mypass ./arsa.py -l

Another idea is to also implement username/password files (with permissions 0600) - the script could also read the credentials from that file.

Actions are currently deleted sequentially which can cause problems if you're deleting a lot of actions (due to flooding).

As the Spacewalk API call schedule.deleteActions() also supports deleting multiple actions it would be better to create one deletion request including all the action IDs.

Here´s a diff to allow only system tasks to be archived/deleted. This is very useful if you need only to make thinkgs softer but care for the history of Satellite.
arsa.diff.txt

Currently, I need to alter the toolkit after every new release of Spacewalk. It would useful to have a parameter to ignore API level validation as I might not find much time for maintaining this toolkit, anymore. :)

Johnny Vergeer from the Red Hat Network board requested the possibility to also remove failed actions: https://access.redhat.com/comment/792363#comment-792363

When I try to run arsa.py, we run into a problem:

[root@ft-spacewalk arsa]# python arsa.py 
Username: myusername
Password: 
Found completed action #52972 ('Show differences between profiled config files and deployed config files')...
Found completed action #52971 ('Show differences between profiled config files and deployed config files')...
Found completed action #52970 ('Show differences between profiled config files and deployed config files')...
Found completed action #52969 ('Show differences between profiled config files and deployed config files')...
(snip)
Found archived action #63063 ('Show differences between profiled config files and deployed config files')...
Found archived action #63062 ('Show differences between profiled config files and deployed config files')...
Archiving actions...
Enabling workaround to archive/delete more than 100 actions...
[65536, 65541, 65543, 65547, 65548, 65553, 65554, 65558, 65559, 65565, 65566, 65570, 65571, 65574, 65576, 65577, 65583, 65584, 65588, 65589, 65590, 65592, 65595, 65601, 65604, 65607, 65613, 65614, 65618, 65619, 65623, 65625, 65631, 65634, 32868, 65637, 65643, 65644, 65648, 65649, 65655, 65661, 
(snip)
72211, 71446, 71447]
Traceback (most recent call last):
  File "arsa.py", line 152, in <module>
    client.schedule.deleteActions(key,tempActions)
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1199, in __call__
    return self.__send(self.__name, args)
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1489, in __request
    verbose=self.__verbose
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1243, in request
    headers
xmlrpclib.ProtocolError: <ProtocolError for localhost/rpc/api: 500 Internal Server Error>

• There are ~5400 entries in the array. I had already archived like 30,0000 through the GUI ;)

Perhaps there are WAY more in the "archive" ? I am deleting them 10,000 at a time through the webUI for now, hopefully we can setup arsa.py to run periodically and not get into this state again :)

I think the problem was encountered during the "delete" step rather than the archive step, where there was ~55,000 entries in my archive (unless I lost count deleting them 10k at a time through the browser)

It would be better to use a logger instead of manual printing messages if debug mode is enabled.

Currently the whole code is implemented in main() - it would be better to create functions to optimize readability.

Running arsa on Red Hat Satellite 5.6 and Spacewalk 2.2 fails because the API level is not mentioned in the array of supported levels.

It it necessary to add the following API levels to fix this:
13, 13.0, 15, 15.0