Bug 1021738
| Summary: | Server should never report None for a system FQDN | ||
|---|---|---|---|
| Product: | [Retired] Beaker | Reporter: | Amit Saha <asaha> |
| Component: | general | Assignee: | Amit Saha <asaha> |
| Status: | CLOSED DUPLICATE | QA Contact: | tools-bugs <tools-bugs> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | develop | CC: | aigao, asaha, dcallagh, ebaak, llim, qwan, rmancy |
| 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-12-20 05:21:04 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: | 1037878 | ||
| Bug Blocks: | |||
I can't think of when it is ever OK to have the fqdn be empty. I think we should remove them from the DB and ensure every point of fqdn modification is covered to not allow it. (In reply to Raymond Mancy from comment #2) > I can't think of when it is ever OK to have the fqdn be empty. Makes me wonder, how did it land there in the first place? > > I think we should remove them from the DB and ensure every point of fqdn > modification is covered to not allow it. You can just edit the fqdn field and leave it blank and Beaker does not complain (well, it does sort of, but still allows it) I see that fqdn is declared in system_table as " Column('fqdn', Unicode(255), nullable=False),". However, fqdn = None by default. So this is a None != Null situation?
We can't do anything useful with a system without an FQDN (or an IP address in the FQDN field) - it makes sense to me to just make it mandatory. If the concern was freeing up an FQDN previously assigned to a now removed system, appending ".invalid" or ".2.invalid" etc covers that. So it sounds like this doesn't require a schema change (just a model change), so that should make it feasible to tidy up in 0.15.2. The fix for BZ#1021737 will make it impossible to add a system with no fqdn using the Web UI. However, it will still be possible using CSV import feature. Thus, I think the solution is to fix BZ#1037878 (esp. in the light of comment 2). (In reply to Amit Saha from comment #8) > The fix for BZ#1021737 will make it impossible to add a system with no fqdn > using the Web UI. However, it will still be possible using CSV import > feature. Thus, I think the solution is to fix BZ#1037878 (esp. in the light > of comment 2). comment 2 here: https://bugzilla.redhat.com/show_bug.cgi?id=1037878#c2 There's no longer a separate bug here - the issue was with Beaker previously allowing bad data to be uploaded. *** This bug has been marked as a duplicate of bug 1037878 *** |
Description of problem: A user reported the following traceback: > [drohwer@drohwer ~]$ bkr list-systems --status automated > Traceback (most recent call last): > File "/usr/bin/bkr", line 9, in <module> > load_entry_point('bkr.client==0.14.1', 'console_scripts', 'bkr')() > File "/usr/lib/python2.6/site-packages/bkr/client/main.py", line 50, in > main > return cmd.run(*cmd_args, **cmd_opts.__dict__) > File > "/usr/lib/python2.6/site-packages/bkr/client/commands/cmd_list_systems.py", > line 221, in run > print title.text.strip() > AttributeError: 'NoneType' object has no attribute 'strip' > The reason is a system in production beaker which has no FQDN data associated with it. Now it's debatable, whether it's a server bug or a client's, but filing this anyway so that we know that this is a problem. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. See above. 2. 3. Actual results: Expected results: Additional info: