Even though they're tied together, description and title aren't the same thing. We use --title as an identifier for operating systems. By default it's "<name> <major>.<minor>". If user sets a description, we use it's shortened version for title.
You can also notice that the update command has both --title (identifier) and --description (value setter). This approach is consistent with the UI.
 
I understand that it might not be 100% intuitive and from user's perspective it's just title with some default value. Unifying them could be a good step, but we must do it in both UI and CLI for the sake of consistency.

I'm asking our UX expert Roxanne to decide here. If she agrees it's worth changing, I'll open one more bug for the UI counterpart. Otherwise I think we should close this as notabug.

I know that if I omit --description upon os creation then the title is "<name> <major>.<minor>" That's the automatic title, and I can override it with my own if I want to.

But still the option can be named --title (instead of --description)

I can have title empty and then is generated out of required fields.
Even @UI the field can be named Title instead of Description (for the sake of consistency).

If I override the title and I provide a description does that then override the title?

Are you asking whether we should get rid of description... is there a need for it?

In fact the title field isn't exposed to users for editing at all. You can only enter description, which then overrides the title. If no description is provided, title is generated automatically.

I don't think the description is used for anything else but generating the title. Both fields are searchable, but there's probably not much benefit in searching for OSs that have certain title but no description.

So I'm asking whether you see any benefit in the current state (having two terms "description" and "title") or whether you think it's better to unify them into one.

Since one isn't editable and is generated from the other I vote for unification.

Swapnil, you marked upstream as needing more info. Do you have what you need?

Questions for @tomas @lukas (basically summing up my understanding)

1. HammerCLI - create/update/info/delete : --title would be the only option available and not --description?
2. UI - `Description` should be replaced by `Title`? - (If yes, I'll create a new BZ for this)
3. 'Description' won't be updated in any of the above cases?
4. Should the 'description' field/column be removed from `operatingsystem` table(or deprecate now and remove later)?
5. Are we sure about the fact that 'description' never gets updated independently and doesn't have an assertive role?

Hi Swapnil

Ad 1.
Yes, --title everywhere, no --description. Plus the update command would need to have --new-title

Ad 2.
Yes, it should be replaced with Title.

Ad 3 and 4.
Description column should be removed from db.

Ad 5.
Descriptions are currently searchable independently of titles. Also API returns them as a separate fields. Other than that they aren't really exposed anywhere and they serve only as a source for the title (which is description shortened to 255 characters). So the current value of keeping them both is very little.

Upstream bug assigned to sabnave

Upstream bug assigned to sabnave

Created attachment 1263738 [details]
explain-title-description-confusion

I am reverting this BZ status to NEW. Need to discuss with the owner of OS feature, removing 'description' would be an acceptable option or not.

As I see that 'Description' and 'Title' is creating lots of confusion between 3 realms: API | Web-UI | HammerCLI

API:
create and update API uses 'Description'

Web-UI:
While creating OS, 'Description' is offered to enter. Later copied to 'Title' and shown in the list(index) as 'Title'.

HammerCLI:
As Lukas described: https://bugzilla.redhat.com/show_bug.cgi?id=1393524#c0
Adding to it. hammer list shows the header as 'TITLE'
See attached image to get the whole idea.

Upstream bug assigned to sabnave

Upstream bug assigned to sabnave

Thank you for your interest in Satellite 6. We have evaluated this request, and we do not expect this to be implemented in the product in the foreseeable future. We are therefore closing this out as WONTFIX. If you have any concerns about this, please feel free to contact Rich Jerrido or Bryan Kearney. Thank you.