autocomplete: allow searching for VMs belonging to projects
Currently, when searching for VMs through the CloudMonkey's autocomplete, VMs belonging to projects are not listed. For instance, below are listed all existing VMs of the cloud environment:
(localcloud) 🌵 > list virtualmachines listall=true projectid=-1 filter=id,name,account,project
{
"count": 4,
"virtualmachine": [
{
"id": "2b7f0fe7-c114-4b01-93ab-dd31758b456a",
"name": "project-1-vm-01",
"project": "project-1"
},
{
"id": "79c21a0f-1d5c-46b1-bd9b-691e09c8b7a5",
"name": "project-1-vm-2",
"project": "project-1"
},
{
"account": "admin",
"id": "f69735ac-2bc9-4847-a25f-fc21f27b6cb0",
"name": "admin-vm-1"
},
{
"account": "admin",
"id": "bd29bd06-a186-4470-a1ec-8eb5cbec37c7",
"name": "admin-vm-2"
}
]
}
However, the projects' VMs are not listed as available options in the autocomplete.
This PR, therefore, adds the projectid=-1 parameter to the listVirtualMachines API call that is performed by CloudMonkey when fetching the existing VMs. With that, it is possible to select VMs that belong to projects:
@shwstppr, can we include this one in the CMK 6.5 release?
@bernardodemarco Are the volumes in projects listed and auto-completed ?
I expect all the list behaviours to be consistent. if the vms in projects are listed, what about the following commands ?
- list volumes
- list networks
- list templates etc
I think we could add global flag or global setting like
- set project on
- set projectid
(maybe -1)
@bernardodemarco please check the suggestion from Wei. I guess it will be good to have the consistency.
Using something like set projectid could also be a good idea but will be limited to a single project.
Other way could checking if the API has projectid param and pass it always as -1 to allow handling all such APIs (this can be guarded by a profile config flag)
@weizhouapache @shwstppr, thanks for your review!
I expect all the list behaviours to be consistent.
Yes, I totally agree. The problem, however, is that the ACS APIs themselves are not consistent regarding the projectid parameter. The listNetworks API, for instance, does not list all networks when projectid is defined as -1:
list networks filter=id,name,type,project,account
> list networks filter=id,name,type,project,account,
{
"count": 6,
"network": [
{
"account": "admin",
"id": "4b7a1f4c-5ecc-4947-9898-7a6d7dbd8d5c",
"name": "account-allocated-isolated-network",
"type": "Isolated"
},
{
"account": "admin",
"id": "30eb5338-1f87-440a-9fd5-e2ebcb1864cd",
"name": "account-isolated-network",
"type": "Isolated"
},
{
"account": "admin",
"id": "a8755f65-1b74-46d4-81f9-cbcd32a524fb",
"name": "account-shared-network",
"type": "Shared"
},
{
"id": "5751392c-0ab9-4443-9905-41cacbe7d435",
"name": "domain-shared-network",
"type": "Shared"
},
{
"id": "78646d05-2d22-401c-b9c0-6a53dda292fe",
"name": "global-shared-network",
"type": "Shared"
},
{
"account": "admin",
"id": "7f57254c-179b-489a-b8e2-6b9af166ff30",
"name": "admin-tier",
"type": "Isolated"
}
]
}
list networks filter=id,name,type,project,account, projectid=-1
> list networks filter=id,name,type,project,account, projectid=-1
{
"count": 6,
"network": [
{
"id": "19c93ecd-07e9-439b-b64d-b2c3b13acdd3",
"name": "project-allocated-isolated-network",
"project": "project",
"type": "Isolated"
},
{
"id": "06a572d4-3ff0-47b7-9ee5-b7a30afa0624",
"name": "project-isolated-network",
"project": "project",
"type": "Isolated"
},
{
"id": "da7e582a-2f5c-4719-96aa-be175dbb87ff",
"name": "project-shared-network",
"project": "project",
"type": "Shared"
},
{
"id": "5751392c-0ab9-4443-9905-41cacbe7d435",
"name": "domain-shared-network",
"type": "Shared"
},
{
"id": "78646d05-2d22-401c-b9c0-6a53dda292fe",
"name": "global-shared-network",
"type": "Shared"
},
{
"id": "5f106432-c1fb-41c9-9e0e-28445e9def3b",
"name": "project-tier",
"project": "project",
"type": "Isolated"
}
]
}
Thus, defining projectid=-1 for all APIs that have the projectid parameter could possibly lead to inconsistent autocomplete options. To follow with this approach, it would be first required to normalize all ACS APIs to have the same behavior when specifying projectid=-1.
Do you guys have any ideas on how we could address this?
I think we could add global flag or global setting like
Would there be any reason for someone not wanting the projects resources to be available as autocomplete options? IMHO, whenever possible, all resources the caller has access to should be displayed as options.
Thank you, @bernardodemarco, for looking into the suggestions.
I agree with your finding and have created an issue https://github.com/apache/cloudstack/issues/11517
I feel adding autocompletion for just one resource (VM) would add some inconsistency in cmk as well. Also, there won't be a way currently to identify which options are from project and which are not. Maybe we need to look into something like,
VM_UUID (VM_NAME | <SOME_UNICODE_PROJECT_ICON> <PROJECT_NAME>)
For now, I'm moving this PR to the next milestone to allow a bit more discussion and reach a consensus.
thanks @shwstppr @DaanHoogland @bernardodemarco
I agree with @shwstppr
Would there be any reason for someone not wanting the projects resources to be available as autocomplete options? IMHO, whenever possible, all resources the caller has access to should be displayed as options.
autocomplete option is a very good feature. I want it to be working better.
for example, in your example below
if I choose a virtualmachine in a project, can the volume be attached to the vm in the project ?
please note, the volumes do not belong to the project.