2) Second issue: Is there any way of providing the k8s namespace for pod deployment? Anyway via props, env vars etc.?
--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/1a626eee-03f7-4e7b-9fc7-4ba96f66062en%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/daeae86c-8221-4b70-9025-3472ba6710e7n%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-nXva%2BCuB_LGEmH%2B5uVzYaxXLYrH-gKjfcOWkbOGsE04Q%40mail.gmail.com.
Hi Bill,It depends. I think it is better to govern it by application.properties or by options like mvnw clean package -Dquarkus.kubernetes.deploy. It can be useful if in one step, someone wants to cleanly build image and deploy it for quick testing.I checked google cloud code. It uses skaffold and it has deploy section to deploy the image on k8s. This is supported during build time.does quarkus leverages skaffold to deploy or it has its own impl? skaffold seems to me quite useful for full lifecycle including app build, image build, push and deploy. Also, you can do the remote debugging on k8s cluster (quite helpful)
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/fb9686d6-0fed-4c9c-98dc-993fdfa64019n%40googlegroups.com.
Hi,
I had aws as command in my .kube/config which mvnw was picking during
build. Strangely, it could not resolve aws (though it is there in PATH), so
I provided full path in .kube/config and it worked out correctly.
Quarkus is pushing images to ECR and even deploying it on k8s cluster.
can you share what you exactly had in your config where aws gets added to the mix ?
It sounds like the parsing/processing of .kube/config might not be done with the proper environment (i.e. it uses the global system env instead of your terminals current context).
Having an example to reproduce would make it easier for us to fix :)
/max
You received this message because you are subscribed to the Google
Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit
--
You received this message because you are subscribed to the Google
Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit
--
Bill Burke
Red Hat
--
You received this message because you are subscribed to the Google Groups
"Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit
--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/4044d2b2-d0dc-4d6d-91d6-bea6de9db52en%40googlegroups.com.
> In users section of .kube/config, I have below:
>
> users:
> - name: <eks_cluster_arn>
> user:
> exec:
> apiVersion: client.authentication.k8s.io/v1alpha1
> args:
> - --region
> - us-west-2
> - eks
> - get-token
> - --cluster-name
> - <cluster_name>
> *command: aws*
> env: null
hey - I learned something new :) kubernetes cli can use external
authentication.
https://kubernetes.io/docs/reference/access-authn-authz/authentication/
I believe this is a bug - can you open issue for it please ?
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/F96BACFF-4261-461C-A470-20F3684F98EA%40redhat.com.