-
Notifications
You must be signed in to change notification settings - Fork 112
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
NATS Streaming support #18
Comments
Has there been any progress on this in the recent months, or anything planned for the foreseeable future? It would definitely be great to see the operator support NATS Streaming. I did find this repo via the official docs: https://github.com/canhnt/k8s-nats-streaming
correction: it uses NFS for that, and suggests using GlusterFS on Google Cloud, which would solve my above mentioned problem somewhat (even though it's not provided as a product on GCE, so it's self-managed, which is less than ideal for this crucial storage). |
Hi @JeanMertz yes looking at NATS Streaming support would be next in the list along with prometheus support. |
Alpha version of a NATS Streaming Operator built using the Operator SDK is also available here for now: https://github.com/nats-io/nats-streaming-operator |
As mentioned to @wallyqs privately, I think it's best for everybody if we keep both NATS and NATS-Streaming operators as one. After all, NATS needs to be in place for NATS-Streaming to work. Breaking them apart would mean more operations and more code to maintain. |
I'm very interested in keeping the the two together as well. |
Are there any updates on this ? We're very keen to use it in our pipeline. Appreciate all the work you guys have been doing 👍 |
@sirajmansour I'll resume on this next week, can also try the nats streaming operator built with operator sdk: https://github.com/nats-io/nats-streaming-operator |
There has been a lot of work on the structure of the code, so we can have one operator to rule them all, instead of maintaining separate repos. I'll be working on this over the coming weeks. |
@pires does that mean that the nats-streaming-operator will be deprecated in favor of this |
@diogogmt we would continue to support the nats-streaming-operator too since some may like the separation of responsibilities and streaming operator fairly lightweight anyhow. |
OK so it seems we are misaligned and I'm stopping any work to support NATS Streaming in this repo. |
In the context of user experience, development, and contributions, what are the advantages and disadvantages of one operator for NATS versus having multiple operators? For longer term planning, how would each approach unfold as we add new components (e.g. JetStream, Leaf Nodes), or deprecate parts of NATS? |
From the top of my head here's my pov on having two operators. Pros
Cons
|
OK from the pov of maintenance:
For longer term planning, I think newer features related to NATS transport would be a good addition for the nats-operator. |
I think we should fold the NATS streaming operator functionality into this operator. test will run longer, but one stop shopping for users would be good imo. Flags could enable which components are installed - would it be feasible to have a |
@ColinSullivan1 I don't think we even need flags. Just a different API resource (maybe the one from the other operator impl) or changes to |
nats-streaming is getting clustering support and so it's about time to support it.
The text was updated successfully, but these errors were encountered: