Update the use of "Machines" in Che

[slemeur]

Description

Along with the issue:
#13667

Machine terminology is deprecated and should be updated.

Example:
https://github.com/eclipse/che/blob/07263f1e30089689d71b057f747a44a29283e3c4/wsmaster/che-core-api-workspace/src/main/java/org/eclipse/che/api/workspace/server/hc/ServerChecker.java#L80

[tsmaeder]

@slemeur could you explain why you see this as a blocker? Everything works just fine and I wouldn't classify the use of "machine" as a major embarassment or usability problem.

[slemeur]

We deprecated that naming long time ago, it should have been handled already. Consistency matters as users might get confused by the mismatching of this wording used in other places.

As we mentioned for #13667, we should analyze the impacts and prioritize once we have an understanding of those.

cc @skabashnyuk

[tsmaeder]

I really don't see this as a precondition for shipping 7.0 Feel free to raise a discussion about this.

[skabashnyuk]

@slemeur if we are talking only about this concrete piece of code

String.format("Server '%s' in machine '%s' not available.", serverRef, machineName)); 

we can make it more neutral for GA. However, if we are talking about removing all referencing of machines in the internal core of the workspace orchestration engine I doubt that that is doable for GA..

@l0rd WDYT?

[slemeur]

Can we get the list of all error messages like this which are exposing the term?

[l0rd]

@skabashnyuk I am +1 to do that work extensively on all the code base targetting 7.1.0. We are too close to GA to do this work now. Anyway changing only this single error message for 7.0.0 should not be too hard neither.

[skabashnyuk]

Anyway changing only this single error message for 7.0.0 should not be too hard neither.

Sure, we just looking for similar places to fix them all at once.

[skabashnyuk]

@l0rd can you clarify expectation #13703 (comment). Is this #13808 something that we might/need to merge for GA. Your comment, labels and a milestone of this issue can be interpreted wrong.

[l0rd]

@skabashnyuk it wasn't clear from your answers if the fix was simply changing the log message or doing a major refactoring.

Anyway I am +1 to target milestone 7.0.0 for the simple log message change. @slemeur is responsible for the triage today and should propose to set the milestone if he agrees with it.

[slemeur]

This issue will get milestone 7.0.0.

Please @skabashnyuk create another issue for refactoring the source code. It will get postpone to a later time.

[skabashnyuk]

Please @skabashnyuk create another issue for refactoring the source code. It will get postpone to a later time.

I would like to have a broader discussion first because the purpose and the way how we want to do that is a bit unclear to me.

[slemeur]

@skabashnyuk : I think this has slip from the che 7 duties during too long. One reason is probably it was not in your backlog so you forgot and now we raise that back at a time that is not appropriated. So please, make sure the issue is in your team backlog. The discussion and the clarification (if needed) should be happening in the issue.

[skabashnyuk]

@slemeur or @l0rd can you clarify me what issue I have to create. The scope of that task for me is unclear.

[skabashnyuk]

Changing to 8.x since it requires fundamental changes in API because of the notion of the machine is the base of workspace runtime object. There is no clear way how to make that without the breaking changes.

[l0rd]

@skabashnyuk that means not working on it since 8.x will eventually be Workspace CRD based.