[horizon] Changing the Term “Instance” to “Server” for improved clarity and consistency
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. "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. 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.
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. 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.
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.
Thanks, Jay Faulkner
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
Frankly speaking, I think we should be going one way or another anyway. As whenever I am trying to onboard new operators, the first thing to explain to them is how to create a VM or a bare metal server in OpenBao, and why it is called differently from what they are used to in UI. I also do not agree with Jay's comment about Instance/Server not being interchangeable and vague. As at the end of the day, you still issue POST /servers to create an "Instance" which is so much more confusing then distinguishing Server from Node. And for me, both Instance and Server are still completely different from Node terminology, so I don't feel like renaming them makes things any different. Moreover, Bare Metal is still a Server, and whenever you look for the term Bare Metal, it will always be referenced as a Server. So I don't see how such renaming will jeopardize the Ironic purpose of distinguishing things. So if we want to align with the industry and competitors, then we potentially need to add API aliases to Nova, SDK, CLI, OpenBao, Ansible, etc, to support Instances and gradually sunset Servers naming. But this looks like a completely unreasonable amount of work to do. One problem which I wanted to highlight with Instance naming, is a very unobvious one for those whose native language is English. But in both of my native languages, the word "Instance" is kind of either untranslatable, or does have a totally unrelated meaning to the tech industry. With that Server is totally widespread, used and understood. I tried to check translations for EC2 and GCP, but neither of them have actually translated these pages at all. So it also would be interesting to hear out from l18n or non-English speaking audiences if they can understandably translate "Instance" to their native languages. чт, 29 мая 2025 г. в 03:04, Sean Mooney <smooney@redhat.com>:
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
Absolutely agree, the first question that arises for ordinary users is what are instances. We must improve this point.
On 2025-05-29 03:36, Dmitriy Rabotyagov wrote:
Frankly speaking, I think we should be going one way or another anyway. As whenever I am trying to onboard new operators, the first thing to explain to them is how to create a VM or a bare metal server in OpenBao, and why it is called differently from what they are used to in UI.
I have to agree here. Consistent naming is important. Having recently gone through a project were 2 things were using the same name.
I also do not agree with Jay's comment about Instance/Server not being interchangeable and vague. As at the end of the day, you still issue POST /servers to create an "Instance" which is so much more confusing then distinguishing Server from Node. And for me, both Instance and Server are still completely different from Node terminology, so I don't feel like renaming them makes things any different. Moreover, Bare Metal is still a Server, and whenever you look for the term Bare Metal, it will always be referenced as a Server. So I don't see how such renaming will jeopardize the Ironic purpose of distinguishing things.
So if we want to align with the industry and competitors, then we potentially need to add API aliases to Nova, SDK, CLI, OpenBao, Ansible, etc, to support Instances and gradually sunset Servers naming. But this looks like a completely unreasonable amount of work to do.
One problem which I wanted to highlight with Instance naming, is a very unobvious one for those whose native language is English. But in both of my native languages, the word "Instance" is kind of either untranslatable, or does have a totally unrelated meaning to the tech industry. With that Server is totally widespread, used and understood. I tried to check translations for EC2 and GCP, but neither of them have actually translated these pages at all.
Now here I would disagree. Server tends to imply hardware but it works equally for the person bringing me lunch. Having that also be description of virtual machines has actually led to confusion in conversations. Instance is at least different from the name of the hardware the instance is running on. Why not call them VMs (vee-emm-s). That is what they are. The tech industry has a long and storied history of naming stuff with words or names that have very little to do with the function of the stuff.
So it also would be interesting to hear out from l18n or non-English speaking audiences if they can understandably translate "Instance" to their native languages.
чт, 29 мая 2025 г. в 03:04, Sean Mooney <smooney@redhat.com>:
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 >
-- Alvin Starr || land: (647)478-6285 Netvel Inc. || home: (905)513-7688 alvin@netvel.net ||
On 29/05/2025 14:04, Alvin Starr wrote:
On 2025-05-29 03:36, Dmitriy Rabotyagov wrote:
Frankly speaking, I think we should be going one way or another anyway. As whenever I am trying to onboard new operators, the first thing to explain to them is how to create a VM or a bare metal server in OpenBao, and why it is called differently from what they are used to in UI.
I have to agree here. Consistent naming is important. Having recently gone through a project were 2 things were using the same name.
I also do not agree with Jay's comment about Instance/Server not being interchangeable and vague. As at the end of the day, you still issue POST /servers to create an "Instance" which is so much more confusing then distinguishing Server from Node. And for me, both Instance and Server are still completely different from Node terminology, so I don't feel like renaming them makes things any different. Moreover, Bare Metal is still a Server, and whenever you look for the term Bare Metal, it will always be referenced as a Server. So I don't see how such renaming will jeopardize the Ironic purpose of distinguishing things.
So if we want to align with the industry and competitors, then we potentially need to add API aliases to Nova, SDK, CLI, OpenBao, Ansible, etc, to support Instances and gradually sunset Servers naming. But this looks like a completely unreasonable amount of work to do.
One problem which I wanted to highlight with Instance naming, is a very unobvious one for those whose native language is English. But in both of my native languages, the word "Instance" is kind of either untranslatable, or does have a totally unrelated meaning to the tech industry. With that Server is totally widespread, used and understood. I tried to check translations for EC2 and GCP, but neither of them have actually translated these pages at all.
Now here I would disagree. Server tends to imply hardware but it works equally for the person bringing me lunch. Having that also be description of virtual machines has actually led to confusion in conversations. Instance is at least different from the name of the hardware the instance is running on.
Why not call them VMs (vee-emm-s). That is what they are.
because they may not be vms and that would be very incorrect to use in horizon nova supprot provisioning workload called servers (rendered in horizon as instances) that can be physical machines (via ironic compute driver) or virutal machine (libvirt, vmware, zvm) or lxc containers each of these compute option are equally valid implementation fo a server/instance. in the past we also had nova-docker and out of three driver for hyperv or even a protoyp of composable hardware using intels Rackscale design software. https://docs.openstack.org/nova/latest/contributor/project-scope.html#comput... if some wanted to write a systemd machined container compute driver that would be a valid implementation of nova's compute api. nova is an abstraction over the compute context used to execute the workload but it is not just a vritual machine interface. that is why we use the term server because only commonality is that the compute context we commit to providing is somthing that is or looks lie a real machine in the same way that VPS hosting provider use the term to refer to thing like openvz container provisioned through cpannel. so it would be categorically in correct for horizon to refer to instances as VMs. horizon should either maintain the current nameing system to align to all the major cloud platform that use the term instance or it should adopt the official resource name which is `server`.
The tech industry has a long and storied history of naming stuff with words or names that have very little to do with the function of the stuff.
So it also would be interesting to hear out from l18n or non-English speaking audiences if they can understandably translate "Instance" to their native languages.
чт, 29 мая 2025 г. в 03:04, Sean Mooney <smooney@redhat.com>:
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 >
-- Alvin Starr || land: (647)478-6285 Netvel Inc. || home: (905)513-7688 alvin@netvel.net ||
On 2025-05-29 13:18, Sean Mooney wrote: [snip]
One problem which I wanted to highlight with Instance naming, is a very unobvious one for those whose native language is English. But in both of my native languages, the word "Instance" is kind of either untranslatable, or does have a totally unrelated meaning to the tech industry. With that Server is totally widespread, used and understood. I tried to check translations for EC2 and GCP, but neither of them have actually translated these pages at all. Now here I would disagree. Server tends to imply hardware but it works equally for the person bringing me lunch. Having that also be description of virtual machines has actually led to confusion in conversations. Instance is at least different from the name of the hardware the instance is running on.
Why not call them VMs (vee-emm-s). That is what they are.
because they may not be vms and that would be very incorrect to use in horizon
nova supprot provisioning workload called servers (rendered in horizon as instances) that can be physical machines (via ironic compute driver) or virutal machine (libvirt, vmware, zvm) or lxc containers
each of these compute option are equally valid implementation fo a server/instance.
Ok. I stand corrected. Then Instance is likely the best choice in this case.
in the past we also had nova-docker and out of three driver for hyperv or even a protoyp of composable hardware using intels Rackscale design software.
https://docs.openstack.org/nova/latest/contributor/project-scope.html#comput...
if some wanted to write a systemd machined container compute driver that would be a valid implementation of nova's compute api.
nova is an abstraction over the compute context used to execute the workload but it is not just a vritual machine interface.
that is why we use the term server because only commonality is that the compute context we commit to providing is somthing that
is or looks lie a real machine in the same way that VPS hosting provider use the term to refer to thing
like openvz container provisioned through cpannel.
so it would be categorically in correct for horizon to refer to instances as VMs.
your point is well made. It was my myopic thoughts about the recent issues I had with discussions about the servers running the hypervisors and the servers running on the hypervisors.
horizon should either maintain the current nameing system to align to all the major cloud platform that use the term instance
or it should adopt the official resource name which is `server`.
I can get behind either so long as there is consistency. just my $0.02.
[snip] -- Alvin Starr || land: (647)478-6285 Netvel Inc. || home: (905)513-7688 alvin@netvel.net ||
participants (6)
-
Alvin Starr
-
Dmitriy Chubinidze
-
Dmitriy Rabotyagov
-
Ivan Anfimov
-
Jay Faulkner
-
Sean Mooney