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/server.py

https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/server.html


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-cli#create-the-virtual-machine

https://learn.microsoft.com/en-us/azure/virtual-machines/linux/create-cli-complete#create-a-vm

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
>