Bug 885715
Summary: | Spacecmd exits with error if there is duplicats in sattelite server | ||
---|---|---|---|
Product: | [Community] Spacewalk | Reporter: | Bo Wiberg <bo.wiberg> |
Component: | Clients | Assignee: | Aron Parsons <aronparsons> |
Status: | CLOSED NOTABUG | QA Contact: | Red Hat Satellite QA List <satqe-list> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 1.8 | CC: | chalal, jpazdziora, mmello, msuchy, shardy |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-03-03 23:38:05 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 1484117 |
Description
Bo Wiberg
2012-12-10 13:16:48 UTC
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. |