Can *you* spot the error in the first argument to this command:
$ swift-get-nodes /etc/swift/object.tar.gz account container object
Traceback (most recent call last):
File "/usr/local/bin/swift-get-nodes", line 6, in <module>
exec(compile(open(__file__).read(), __file__, 'exec'))
File "/vagrant/swift/bin/swift-get-nodes", line 81, in <module>
print_item_locations(ring, ring_name, *args, **vars(options))
TypeError: print_item_locations() takes at most 5 arguments (10 given)
Yeah, me either! And the traceback wasn't not really helpful at identifying "ring does not exist"
I *think* it's trying to turn /etc/swift/object.tar.gz into an account named /etc a container named /swift and an object named object.tar.gz because there is no file on the filesystem /etc/swift/object.tar.gz - but that logic can't be right
There's a lot of ways to call this command, policy by ring, policy by option, discover policy *from* ring, discover ring *from* policy - then you have "account container object" or "[/]account/container/object"
I'm not really sure if we can rid of any of those signatures - but maybe if we enumerate all the various call signatures we can decide if there is some way to discover what the use intended.
Either way it can't be helpful that we ever pass in a bogus call signature to print_item_locations and let a traceback out!
Fix proposed to branch: master
Review: https:/