On 28/05/2025 22:51, Jay Faulkner wrote:
On 5/28/25 10:35 AM, Dmitriy Chubinidze wrote:
Propose changing the term "Instance" to "Server" ( "Instances" to "Servers") in the platform’s user interface. This update will be aiming to improve clarity for users, align with industry terminology, and create a more intuitive experience.
I am extremely in disagreement about this move because "Instance" and "Server" are not interchangable. Specifically in the Ironic case, we are extremely careful about the use of terms "Instance" and "Node" as "server" is ambiguous. Being consistent with terminology will prevent folks from making this easy mix up. Also, we are priming users with information that will be actively wrong when/if they upgrade to using the CLI, SDK, or API directly.
there are a few ways to look at this. the offical api resouce in nova is and has alwasy been server. https://docs.openstack.org/api-ref/compute/#servers-servers it is also the name we use in the unified openstack client i.e. `openstack server list` so instance in nova and when ironic is used as a nova compute driver exclisvley refer to the end user resouce that is provision by nova. that is the official term at the API level for the resource provisions by nova weather that is a vm, baremetal server or container. on the other hand in the db and in our obejct model they are called instances. https://github.com/openstack/nova/blob/master/nova/objects/instance.py https://github.com/openstack/nova/blob/master/nova/db/main/models.py#L265 so from a nove perspective server and instance are never ambgious and are alwasy a 1:1 mapping the host that executs the user workload is referted to as teh compute_node in the db https://github.com/openstack/nova/blob/master/nova/db/main/models.py#L173 and referted to as the hypervior in the rest api. https://docs.openstack.org/api-ref/compute/#list-hypervisors physical ironic machines are models as comptue nodes aka hyperviosrs in Nova the workload that is schdule to a machine is still a server. the only real difference with ironic is a compute node can only host on server because an nova server that is provisioned by the ironic compute driver allcoates all the resouces of the compute to the single request. functionally there would be no different in nova if we had a "full-host" libvirt driver that create a vm that used all the resouces on the compute node and only ever allowed 1 server pr compute node. i understand the ironic concern as sometimes its unclear when people say server do the refer to the api resource or to the phsyical hunk of metal that they have racked in a data center. i do personally think if we were creating horizon today from scratch we would call it server, and it is more consistent with the api, cli and sdk as the latter two also use the term server https://github.com/openstack/openstacksdk/blob/master/openstack/compute/v2/s... https://docs.openstack.org/python-openstackclient/latest/cli/command-objects... i believe the orgianl instance terminology comes fomr the very early days of nova when nova tried to provide a ec2 compatible api, as a result the nova flavor was originally called instance_type because that is what its called in ec2 and and server were organically called "instance" again this came form ec2 which still uses that terminology https://aws.amazon.com/ec2/instance-types/ so i do think it would be correct and much more consistent ot use the term "server" everywhere but i also done know if it will make much of a difference on end user long term.
All this being said; I don't work on horizon and so don't really get a vote; but the assertion that server/instance are interchangeable isn't really true in all situations.
"Server" is a more commonly understood term than "Instance", especially for users who are not deeply familiar with cloud computing. Major platforms like AWS and Azure often use "Server" in their UI, even when referring to virtual instances. Adopting this term will make OpenStack easier to use and understand.
actully horizon use of instance came form the fact that AWS calls them instnaces in it api or at least used to when the term was first used in openstack. https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_Instance.html so im not really sure where the assertion that aws uses the term server came from azure uses the term VM on there cli https://learn.microsoft.com/en-us/azure/virtual-machines/linux/quick-create-... https://learn.microsoft.com/en-us/azure/virtual-machines/linux/create-cli-co... also if you look at the side bar, of https://learn.microsoft.com/en-us/azure/virtual-machines/ the have a section called instances which group documenation on how they are size and how to create/delete/reserve vms if we looks at GCP https://cloud.google.com/compute/docs/reference/rest/v1/instances they also use the term instances. so if we are trying to be consistent with AWS EC2, Google Compute Engine and Azure we should continue to refer to them as "instances" not "servers" as instance appears to be the industry standard terminology. do you have counter example to point to where server is used in other cloud plathforms? in enterpirse vitualisation stacks like Proxmox the term server is also not used, they use node to refer to the hypervior and VirtualMachine for the workload kubvirt also uses virtual machine
This change will affect only the visual elements — such as UI labels, menus, and documentation. The underlying code, APIs, and data structures using the term instance will remain unchanged. This ensures there is no impact on functionality or development processes.
We are open to feedback and discussion on this proposal.
if the intent is to be consistent with terminology used in public cloud and enterprise virt like proxmox or kubevirt then i do not think we should use the term "server" as the standard term appear to be instance so useing the term server woudl be confusing for thsoe coming form other cloud platforms.
if the intent is to align how we name thing between the api, cli, sdk (which all use the offical name server) and horizon then yes we can make the change but that is not the argument that was being mead in this thread originally.
Thanks,
Jay Faulkner