Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] JHipster Kubernetes Operator #10053 #10054

Open
wants to merge 9 commits into
base: master
from

Conversation

Projects
None yet
5 participants
@salaboy
Copy link

commented Jul 8, 2019

[skip ci]

This RFC related to #10053

I will appreciate feedback and help to refine the RFC with more details. I am still applying feedback on the following repository to make the Operator (first iteration) simpler.

@salaboy salaboy referenced this pull request Jul 8, 2019

Open

JHipster K8s Operator #10053

1 of 1 task complete
@salaboy

This comment has been minimized.

Copy link
Author

commented Jul 8, 2019

@saturnism @jdubois @deepu105 @pascalgrimaud @PierreBesson I would appreciate feedback on this so I can move the Operator forward. I am doing some more work here: https://github.com/salaboy/jhipster-operator
As I am a firm believer of having something working will help us to richer conversations. But I am happy to move that work to a more formal repo for everyone to keep track of it.

@PierreBesson

This comment has been minimized.

Copy link
Contributor

commented Jul 8, 2019

Great work! I agree let's move your project to the jhipster or hipster-labs github org and create a build pipeline to build and publish your jhipster operator to docker hub.

@salaboy the video has just been published : https://youtu.be/9iqTtwptTT8?list=PL6IFaLdAcgE3aSgmRyhi6eULdlrwjA5sm
Can you add the link to the rfc.

@salaboy

This comment has been minimized.

Copy link
Author

commented Jul 8, 2019

@PierreBesson can you please create the repo so I can start moving the code?
I will link the video to my blog post and the RFC :)

salaboy added some commits Jul 8, 2019

@DanielFran DanielFran added the area: rfc label Jul 8, 2019

@deepu105

This comment has been minimized.

Copy link
Member

commented Jul 8, 2019

While this is really interesting and super cool as a concept, we need a wider discussion before you actually spend more time on it. I'm gonna wear my pragmatic hat now and ask some questions we need to answer first

  1. This definitely is cool but is this really necessary for a JHipster application.
  2. Are we rebuilding any features provided by tools like Istio(coz many of the proposed features looks very similar to what it does)
  3. While a JHipster CRD is cool it also means more tie in into JHipster in terms of deployment architecture is that necessary?

So lets first discuss with the community

@salaboy please don't take this as criticism, it's just that we need to look at the bigger picture. Can you add the advantages of this also in the motivation section compared to our existing architecture?

@jdubois

This comment has been minimized.

Copy link
Member

commented Jul 8, 2019

This definitely looks very cool, but I'm not the most competent on this part -> do you want me to send a few tweets, maybe a Twitter poll, so gather more community feedback?

@deepu105

This comment has been minimized.

Copy link
Member

commented Jul 8, 2019

@jdubois

This comment has been minimized.

Copy link
Member

commented Jul 8, 2019

Sorry, the RFC process is new to me -> isn't discussing the whole point of the RFC? Then, shouldn't this be merged first?

@deepu105

This comment has been minimized.

Copy link
Member

commented Jul 8, 2019

Ya i'm not sure as well, do we merge first and then discuss or discuss before merging?

For me makes sense to discuss first and merge only when approved

@PierreBesson

This comment has been minimized.

Copy link
Contributor

commented Jul 8, 2019

Let's discuss first and merge once we agree on a first version.

@salaboy

This comment has been minimized.

Copy link
Author

commented Jul 9, 2019

@deepu105 I will add more details, so it is clear.
In general I've seen this feeling of .. "this new "thing" is going to change everything".. while in fact it is quite the opposite (it is just an add on, if you are running in k8s to make your life easier), and it can be built in a way where it is optional and deployed later on if you don't want to start with it.
Until now, the only way that I found to remove the fear of the unknown is to have something up and running where people can play with it and see the value. There is no need for commitment, but I would appreciate help on non-blocking it, just for the sake of the experiments.
I will ping you guys when I add more details.. probably today during the day.

@salaboy

This comment has been minimized.

Copy link
Author

commented Jul 9, 2019

@jdubois I am happy to have more eyes on this, I will do my best to explain clearly in the RFC text what this is about and how it will work so we all can see the benefits

@salaboy

This comment has been minimized.

Copy link
Author

commented Jul 9, 2019

@deepu105 I've answered your questions in a FAQ section of the RFC.

I will change the diagrams, because I think that are causing confusion about changing the architecture. The Operator doesn't change the architecture at all, it just extend it, and it should be an optional extension.

@deepu105

This comment has been minimized.

Copy link
Member

commented Jul 9, 2019

salaboy added some commits Jul 9, 2019

@salaboy

This comment has been minimized.

Copy link
Author

commented Jul 9, 2019

More details added @deepu105 @jdubois @PierreBesson @saturnism , I've added some images as well hoping to clarify the whole approach. I've also added a section stating what the Operator is NOT going to do.
I like the idea of more questions for the FAQ section, because it definitely help to explain the scope of the work.

@PierreBesson

This comment has been minimized.

Copy link
Contributor

commented Jul 9, 2019

For me this is a very good idea. It clicked for me during @salaboy talk that this is the missing link to achieve a cohesive microservice stack on Kubernetes like we had on Spring Cloud. For example I have always wondered how should we setup the gateway/registries to dynamically find available microservices in Kubernetes like we had using Eureka/Consul discovery.

Indeed it seems that developping a custom operator is the only way to start to be kubernetes native and adapt our successful existing stack (registry/gateway/etc.) to implement microservices patterns on top of kubernetes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.