It appears this works on 'Latest' / 5.99.1. We're now going to look at the cluster to see how the cluster is designed via the recipe. Thanks!
Posts made by tking-f5
-
RE: K8s recipe - ticket lodged already
-
RE: K8s recipe - ticket lodged already
@nathanael-h - this includes the K8s version:
{ "id": "0m296bs8j", "properties": { "method": "xoa.recipe.createKubernetesCluster", "params": { "clusterName": "seanp-evaluation-cluster", "controlPlaneIpAddress": "10.146.30.7/26", "controlPlanePoolSize": 1, "gatewayIpAddress": "10.146.30.62", "k8sVersion": "1.31.1", "nameservers": [ "192.168.180.15" ], "nbNodes": 1, "network": "0311868b-99a6-8959-8a1f-8ed2e6a0acd1", "sr": "4c4a1c4a-20a9-c0a0-c395-70a645bbfc7c", "sshKey": "<<<redacted>>>", "workerNodeIpAddresses": [ "10.146.30.8/26" ] }, "name": "API call: xoa.recipe.createKubernetesCluster", "userId": "004e5612-89cd-4e23-890a-83d36b6c8cee", "type": "api.call" }, "start": 1728919997875, "status": "pending", "updatedAt": 1728919997875 }
-
RE: K8s recipe - ticket lodged already
@olivierlambert 'Latest' got us past that error. Now it stopped with just the Control Plane VM and the recipe's task still Pending.
-
RE: K8s recipe - ticket lodged already
@olivierlambert said in K8s recipe - ticket lodged already:
Do you have the same issue on latest?
I haven't tried the Latest channel since the cluster is considered production. How risky would it be?
-
K8s recipe - ticket lodged already
This is simply to share updates on the forum once we find a solution.
We attempted to deploy a K8s recipe on XOA 5.98.1.
1 control and 1 worker.
Static IPs.
SSH key.{ "message": "no object with UUID or opaque ref: undefined", "name": "Error", "stack": "Error: no object with UUID or opaque ref: undefined at Xapi.apply (file:///usr/local/lib/node_modules/xo-server/node_modules/xen-api/index.mjs:757:11) at Xapi.getObject (file:///usr/local/lib/node_modules/xo-server/src/xapi/index.mjs:98:26) at Xapi.apply (file:///usr/local/lib/node_modules/xo-server/src/xapi/mixins/vm.mjs:63:27) at Xapi.createVm (/usr/local/lib/node_modules/xo-server/node_modules/golike-defer/src/index.js:85:19) at Xoa.createCluster (/usr/local/lib/node_modules/xo-server-xoa/src/recipes/kubernetes-cluster.js:395:35) at Task.runInside (/usr/local/lib/node_modules/xo-server/node_modules/@vates/task/index.js:169:22) at Task.run (/usr/local/lib/node_modules/xo-server/node_modules/@vates/task/index.js:153:20) at Api.#callApiMethod (file:///usr/local/lib/node_modules/xo-server/src/xo-mixins/api.mjs:389:20)" }
I'll update here once we find a solution with the folks at Vates.
-
RE: Feature request - VM folders
@olivierlambert Agile-ize it. Make the tag container/folder view first, then add on features as time and resources permit?
-
RE: Feature request - VM folders
@planedrop actually s/object/tag container/g. I think 'tag container' might be a more apt name if 'folder' isn't appropriate.
-
RE: Feature request - VM folders
@planedrop Tags would be fine if there's a way to also create tag objects similar to folders in the VM view. In other words, create some object that lists all VMs with the tag 'ServiceVMs', for example, and that object stay in the users' VM view. The object would stay in place without needing to type a tag filter each time, again similar to having VM folders.
Once that object is created and the VMs populate according to their tag, the ACLs could be applied so users have access only to those VMs with certain tags, and group actions could be taken on those VMs inside that object.
Keeping the object view in place is a major part of this feature request, whether it be a VM folder or some object based on tags. That way, all of these folders/tag containers/pick your name are always viewable at a glance rather than filtering for each tag at a time.
-
Feature request - VM folders
Please point me to a post if this feature request has already been posted.
The ability to place VMs into folders would be beneficial for cluster users to organize their VMs by purpose or team. While tagging and filtering VMs by tag can do this organization, the ability to view folders at a glance would help users navigate more quickly. Folders could also provide an endpoint for other actions.
- ACLs - providing users access only to certain folders
- Resource usage limitations/quotas
- VM group actions, such as power all on or off
- Add VMs dynamically into folders by tags