Istio extension

[Alex Soto Bueno]

I was thinking if we could create a really simple Istio extension extending the Kubernetes extension that if it is in the classpath it just sets 

annotations:

        sidecar.istio.io/inject: "true"

to the generated Kubernetes.

I know that I can set them in application.properties manually, but I never remember the annotation, so it would help.

Another option could be create a new property at Kubernetes extension like quarkus.kubernetes.istio=true that does the same thing.

Alex.

[Georgios Andrianakis]

Sounds more like something that should just be documented than an entire extension or a dedicated config option, no?

--
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/cec2f3fe-2851-472f-a488-d853526d4d7en%40googlegroups.com.

[Alex Soto Bueno]

Well we can document but I still need to remember the annotation and how to set an annotation in Kubernetes extension. It is just to help/improve the development experience. 

[Georgios Andrianakis]

On Thu, Feb 11, 2021 at 6:14 PM Alex Soto Bueno <asot...@redhat.com> wrote:

Well we can document but I still need to remember the annotation and how to set an annotation in Kubernetes extension. It is just to help/improve the development experience. 

I think that if you document exactly what Quarkus property one needs to set, then you won't need to remember it anymore and the experience will be just fine.

If on the other hand there are more way that the Kubernetes Manifests should be updated for Istio, then in that case I think a new extension is warranted. But just for a single annotation, I don't think it makes sense

[Ioannis Canellos]

Since we are talking about a single annotation, I think that using a property like `quarkus.kubernetes.istio=true` is more appropriate.

--
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/cec2f3fe-2851-472f-a488-d853526d4d7en%40googlegroups.com.

--

Ioannis Canellos

[Georgios Andrianakis]

But adding an annotation is so easy anyway, why add another way to add this annotation?

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CADHGh9Xgh-XN%3D-w0cvPAMfx-xxqUM4qAH%2Biou5Cq-AVmW%2B1pig%40mail.gmail.com.

[Alex Soto Bueno]

Well my point is that a developer does not need to remember two things 1) how to add an annotation in Quarkus 2) what is the annotation is Istio. 

With quarkus.kubernetes.istio annotation is a really simple to remember, both things.

Compare:

quarkus.kubernetes.annotations.sidecar.istio.io/inject=true

Actually I even don't know how to map the Istio annotation in a Quarkus Kubernetes configuration file.

[Max Rydahl Andersen]

If that annotation is truly the only thing we can ever imagine istio would mean
for Quarkus then a single property is the way forward.

If there is more to istio then it warrants an extension.

This assumes though we've found a way to ensure that configuration of one thing (like istio)
gets reflected both in kubernetes and openshift resources.

Right now I think we have some discrepancies where if I set a kubernetes property I also have
to set it for openshift ...that would be bad.

/max

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAOaD6kJj4yCh95gSi%2B50U%2BkgiW%2BeuKrdULxsFSkxgBqj7%3DnWqw%40mail.gmail.com.

/max
https://xam.dk/about