Description of problem: If there is duoplicates in the satelit server the spacecmd exits with a warning spacecmd -s rhnsat -u user system_listinstalledpackages search:name:foo | grep -E "System|redhat-release" Spacewalk Password: INFO: Connected to https://rhnsat/rpc/api as user WARNING: Duplicate system profile names found WARNING: You can delete duplicates with 'system_delete' WARNING: foobar = 1000026123, 1000027424 Version-Release number of selected component (if applicable): spacecmd.noarch 1.8.15-1.fc16 How reproducible: Have one hostname with two ID in rhss and run spacecmd against that hostname Steps to Reproduce: 1. 2. 3. Actual results: Error, even though spacecmd tells me it is a warning Expected results: spacecmd should tell me about the duplicates as a warning, but should generate correct output. Additional info:
Forwarding to upstream.
Looking at the spacecmd codebase, there are three typical contexts in which the get_system_id calls appear: system_id = self.get_system_id(system) if not system_id: return (this is in do_system_listinstalledpackages), then system_id = self.get_system_id(system) if not system_id: continue and as system_id = self.get_system_id(system) variable = self.client.system.someAPICall(self.session, system_id) all of them being within some for system in sorted(systems): loop. Obviously, the return terminates the loop and causes the potential warning to appear as exit, the continue skips the problematic system profile name, and using the zero system_id in API call ... well, will it fail? We probably should come up with unified way of handling nondeterministic profile names and fix all occurrences. Steven, do you have any guidance?
So yes, it looks to me like we should probably replace all of the "if not system_id: return" statements with the continue version - the only risk I see with this is it makes it a bit less obvious that we failed to uniquely look-up a system (if it's one of many systems or a search as above). As you point out, we should also check the return value before the API call in the third example (pretty sure the API call will fail, but it's not going to be a very elegant failure-mode I guess) Agree that coming up with some abstraction to tidy this up would be good.
Assigning to Steven, current spacecmd maintainer.
Reassigning to Aron Parsons, spacecmd maintainer
commits: 007bb1a9968a7dd082a35e08b9d19f8d9b044e6f 3a815ffb55f2413dd68d8978802b431e0eaba645 7324513b0df53d51000c9bb39ee7235ca608266b The behavior you're seeing is the intended behavior. spacecmd does not know which system you're trying to interact with and chooses to not return bad information. If you intend to have duplicate profile names in your Spacewalk instance, you're going to have to refer to systems by ID, in which case spacecmd will behave as expected. As discussed by Jan and Steven, I standardized the behavior for when get_system_id does not return a valid system ID (continue instead of return when inside a loop). I have also changed the error message to be clearer about what's going on when duplicate systems are detected.
This BZ closed some time during 2.5, 2.6 or 2.7. Adding to 2.7 tracking bug.