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