I can confirm that on latest, using XOA plugin v0.29.1 that all options of control planes 1 -> 7 deploys using DHCP and also tested a three control plane instance using static IP's. Pretty cool

kubectl get nodes
NAME STATUS ROLES AGE VERSION
cp-1 Ready control-plane 12m v1.30.2
cp-2 Ready control-plane 9m15s v1.30.2
cp-3 Ready control-plane 6m11s v1.30.2
worker-1 Ready <none> 3m30s v1.30.2
worker-2 Ready <none> 3m16s v1.30.2
worker-3 Ready <none> 3m23s v1.30.2

@olivierlambert stable, which would probably explain it

@Davidj-0 No, from what i gather the UK domain is completely separate. So administrators can restrict access to specific areas for users Potentially via the self service mechanism only allowing the restricted "local" usage .

Not sure im phrasing it well enough but not sure how deep i can go officially

@lawrencesystems so again its a compliance piece.. BTW big fan of the videos

@DustinB so its as much a compliance piece as anything else. UK instance of a US company with data sovereignty laws in play.

Hi,

I have a requirement to authenticate against two different Active Directory instances and was wondering if it's possible. The two AD instances have different naming schemes for users and such,.One instance being used for administrative functions and the other for general users.

I was wondering if it would be as simple as:

• taking a copy of xo-server-auth-ldap
• amending the package.json
• change the class name to separate it from the original within XO https://github.com/vatesfr/xen-orchestra/blob/master/packages/xo-server-auth-ldap/src/index.js#L187
• import the plugin

Or would it be more involved? I wasn't sure if the internal ldap references were general text, called functions or specific to the integration so thought it best to check before I hacked at it too much.

This would initially be used in the self compile ( docker container ) version of Xen Orchestra but hoping the company will also pick up a licence so liable to be added into a separate instance of XOA, I'm guessing it would be the same kind of import process for the second plugin there too.

Sorry if there's something already about on this. When I looked all I could find was a post around a master and backup of the same AD instance as opposed to two different instances

I can confirm that on latest, using XOA plugin v0.29.1 that all options of control planes 1 -> 7 deploys using DHCP and also tested a three control plane instance using static IP's. Pretty cool

kubectl get nodes
NAME STATUS ROLES AGE VERSION
cp-1 Ready control-plane 12m v1.30.2
cp-2 Ready control-plane 9m15s v1.30.2
cp-3 Ready control-plane 6m11s v1.30.2
worker-1 Ready <none> 3m30s v1.30.2
worker-2 Ready <none> 3m16s v1.30.2
worker-3 Ready <none> 3m23s v1.30.2

@olivierlambert stable, which would probably explain it

@shinuza said in XOA receipe not creating VIP address (balancer):

xoa-server plug-in

Thanks for that. Yup the plugin reports being at 0.29.0, although XOA reports being up to date too

Hi,

Long time user (xcp-ng) first time commentor. I've attempted to use the recipe to deploy k8s, having thought about having a cluster for a while but never had the motivation to look into creating one so the functionality of the recipe sounded awesome. Unfortunately I've hit the same problem by the sounds of it. I can create a single control plane node with workers but when attempting to deploy a more resilient configuration it stops at one node and the screen output reports that cloud-init failed and the logs report it's an issue connecting to the vip by the looks of it. Hopefully it's ok to upload my log in place of igorf's but looking at it it talks about checking the various containers so I did for the vip container and get:

root@cp-1:/home/debian# crictl --runtime-endpoint unix:///var/run/containerd/containerd.sock logs 8f33bda832123
time="2024-07-16T09:16:08Z" level=info msg="Starting kube-vip.io [v0.8.1]"
time="2024-07-16T09:16:08Z" level=info msg="namespace [kube-system], Mode: [ARP], Features(s): Control Plane:[true], Services:[true]"
time="2024-07-16T09:16:08Z" level=info msg="prometheus HTTP server started"
time="2024-07-16T09:16:08Z" level=info msg="Using node name [cp-1]"
time="2024-07-16T09:16:08Z" level=info msg="Starting Kube-vip Manager with the ARP engine"
time="2024-07-16T09:16:08Z" level=info msg="beginning services leadership, namespace [kube-system], lock name [plndr-svcs-lock], id [cp-1]"
I0716 09:16:08.494929 1 leaderelection.go:250] attempting to acquire leader lease kube-system/plndr-svcs-lock...
time="2024-07-16T09:16:08Z" level=info msg="Beginning cluster membership, namespace [kube-system], lock name [plndr-cp-lock], id [cp-1]"
I0716 09:16:08.496428 1 leaderelection.go:250] attempting to acquire leader lease kube-system/plndr-cp-lock...
E0716 09:16:10.511560 1 leaderelection.go:332] error retrieving resource lock kube-system/plndr-svcs-lock: leases.coordination.k8s.io "plndr-svcs-lock" is forbidden: User "kubernetes-admin" cannot get resource "leases" in API group "coordination.k8s.io" in the namespace "kube-system"
E0716 09:16:10.511638 1 leaderelection.go:332] error retrieving resource lock kube-system/plndr-cp-lock: leases.coordination.k8s.io "plndr-cp-lock" is forbidden: User "kubernetes-admin" cannot get resource "leases" in API group "coordination.k8s.io" in the namespace "kube-system"
........( message loops )....

which, although I haven't really touched the stuff so can't be sure looks like it could possibly be to do with https://github.com/kube-vip/kube-vip/issues/684

cloud-init-output.log.txt

louhisuo created this issue in kube-vip/kube-vip

open kube-vip requires super-admin.conf with Kubernetes 1.29 #684