https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# general
s
This message was deleted.
m
p
Hi ! Exactly ^^. I'm using the typescript wrapper but that's it.
m
Do you have by any chance an example repo?
Otherwise I need to reconstruct an example to understand the issue
p
Hmm, I can create a repo to isolate the issue if you want, but everything is a work in progress and there might be stuff which doesn't have anything to do with the issue ^^'
m
I can create one too. So as far as I understood, you deploy the ingress controller and then your services/deployment of your own app
and during this up you get the error message?
p
Tbh, I'm new to everything around kubernetes, and I'm learning so I can get better at it ^^'. I'm fine developping around with docker-compose, but I want to understand the whole process of modern development under micro services context, so I'm trying to learn kubernetes basics trough Pulumi (as a dev.... :')). So to summarize , I have a folder called "services" with 2 services (one backend for auth with fastify, one frontend which is a vue 3 project). I have a folder named infrastructure with Pulumi and some helpers in TS to easily and automatically integrates any created services. The process is this : • I create a namespace • I create the Ingress controller • I have an automation process looking for each loadable services, dynamically loads them and : ◦ Build a local image (no push) ◦ Build the service (Cluster IP) ◦ Build the deployment • When everything is done, build the Ingress and inject configuration exposed by a loadable service. So far, only my auth service is declared "loadable", which means than the frontend is out of the equation.
Doing things like this, yes, I get an error message saying "connection refused". Then on the next pulumi up command, it runs fine. It sounds like it doesn't know when it can start, or maybe there is a timeout leading to a connection which fails. I don't know how to debug this :s
My env is the latest version of Pulumi, node 16, Kubernetes in a WSL 2 ubuntu distro, injected thanks to Docker Desktop k8s intergration (using default stack docker-desktop)
The exemples works "almost" fine (sometimes I have to reset the cluster through docker desktop as it fails randomly). The only difference I can find is that I have local image building in the process, where the exemples uses an already existing image which is pulled
Here is the complete output when I'm running 
pulumi up
for the first time
I hope this brings enough context, and thank you again for your kind support
m
yes!
p
Tell me if you need a dedicated repo, I'm fine with making a minimal project for it. It's already super kind of you to help me, and I don't want to eat your time like it's nothing 🙂
m
Hi @prehistoric-laptop-47240 it worked for me. Please have a look into https://github.com/dirien/pulumi-ingress-test Maybe I use a different code! Btw: I use Civo as Cluster.
p
Oh wow, thank you so much for your time and effort. I read how you created this project, and I have to admit, I don't see any conceptual difference... I'm wondering if it could be something about env, such as docker-desktop k8s integration... hmm...
And also, I don't push my image to any repository ^^'. This might change something
Weird stuff happening next : I cleaned my images, to rebuild / pull everything and now I get (still from Helm) :
rendered manifests contain a resource that already exists. Unable to continue with install: IngressClass "nginx" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error: key "meta.helm.sh/release-name" must equal "myctrl-helm-9b125594": current value is "myctrl-helm-b24ad579"; annotation validation error: key "meta.helm.sh/release-namespace" must equal "medcms-fd1b7965": current value is "medcms-8267ab2a"
m
Try to delete it by hand
are you runing on docker-desktop?
p
Yes
m
I tried it on a cloud provider. On my docker-desktop I can' get the status to ready, as it is not updating the status of the ingress with the loadbalancer ip
I have to give it a try again or use rancher desktop or kind/minkube
p
I'm afraid I'm doing a beginner mistake... I was extracting the name for the ingress service name from a created service metadata name instead of giving it the same string I gave to generate the name. Maybe it's different ?
m
oh, yes. Either you fix the names so there is no hash at the end. Or you use the output of the service as input for the ingress service definition
could be the reason why the webhook is failing
p
I gave to the ingress, my service.metadata.name output<string>
I'm trying to give the string I used in the name of the service instead
Just in case they can be different
m
could you try the default namespace too?
just to rule this out too. In my tests I used the default NS for my deployment
p
Oh, actually, it does work without namespace x)
Or not, nvm, it's random
m
so as far as I understood, you deploy the controlle into the default ns any your deployment into a specific ns
p
I'm having a namespace shared and used the ingress and all its services
I tried without any namespace as you suggested, but it still generates the error from earlier
Using a string for the service name, instead of the service.metadata.name seems to solve the issue :s
I'm not sure I understand when I should use a string or a metadata... To share my namespace name, I created a namespace from a resource, and used namespace: namespace.metadata.name To me, it makes sense, as It's a generated name. So I was thinking that I would have to do the same to safely share names from any kind of resource :s
m
ok I got smth similar
👀 1
let me check 🙂
✅ 1
p
Actually, weird fact : I logged the inner string inside the Output type, and the actual name I give as a string, and they are equal, even when it doesn't work
what the xD
m
So now it works!
You need to wait with the ingress creation that the controller is fully deployed
so i put a 
pulumi.DependsOn([]pulumi.Resource{namespace, ingressController})
in the creation of the ingress resource
so it will wait until both other resources are deployed and ready
p
😮 that could explain the randomness of the issue. Trying right now
Hmm, that smells great 😄.
So far so good, thank you a million times !
Oh, sometimes I have : kubernetes:networking.k8s.io/v1:Ingress medcms-ingress *creating failed
context deadline exceeded
Hmm, after a cluster reset, it's working fine again 😛
m
ok. maybe some glitched resources
2 Views
Open in Slack
PreviousNext
Powered by