Bug 1021738 - Server should never report None for a system FQDN
Server should never report None for a system FQDN
Status: CLOSED DUPLICATE of bug 1037878
Product: Beaker
Classification: Community
Component: general (Show other bugs)
develop
Unspecified Unspecified
unspecified Severity unspecified (vote)
: ---
: ---
Assigned To: Amit Saha
tools-bugs
:
Depends On: 1037878
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-21 20:21 EDT by Amit Saha
Modified: 2015-07-26 18:15 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-12-20 00:21:04 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Amit Saha 2013-10-21 20:21:24 EDT
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:
Comment 2 Raymond Mancy 2013-10-21 23:27:21 EDT
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.
Comment 3 Amit Saha 2013-10-21 23:38:00 EDT
(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.
Comment 4 Raymond Mancy 2013-10-21 23:50:13 EDT
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)
Comment 5 Amit Saha 2013-10-22 03:46:10 EDT
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?
Comment 6 Nick Coghlan 2013-10-22 03:47:04 EDT
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.
Comment 7 Nick Coghlan 2013-10-22 03:50:56 EDT
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.
Comment 8 Amit Saha 2013-12-15 19:29:29 EST
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 9 Amit Saha 2013-12-15 19:30:07 EST
(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
Comment 10 Nick Coghlan 2013-12-20 00:21:04 EST
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 ***

Note You need to log in before you can comment on or make changes to this bug.