Status of Project?

[aaronmell]

Not seeing much work being done lately. We have started to use the tool, but are considering switching if its no longer going to be maintained, before we get in too deep.

[squaremo]

Hi @aaronmell, thank you for pitching up and asking. Honest answer: I have not given up on the ideas here, and would like to spend more time on it, but for the foreseeable future I likely won't be able to. If you are looking to make a long term investment in tooling, rather than experimenting, this is a risky way to go right now. I would look at Deno (if a TypeScript runtime is what you're after), and perhaps CDK8s (if you need types for Kubernetes config).

[dlespiau]

I wholeheartedly agree with Michael. The ideas are sound and implemented to various degrees elsewhere. It would need a lot of energy to revive the momentum around jk. Thanks @squaremo for providing alternatives!

[aaronmell]

Really appreciate the response. What you built was really good. Just wish it had some legs :)

[adnaan]

We are still using jkcfg a lot at taxfix.de. It works beautifully for kubernetes config and also for other non-trivial use cases like generating gitlab ci yamls. Not ready to give up on this just yet 🙂

[adnaan]

What would it take to give it some legs ? IMO jkcfg is still the best approach for a generic configuration library out there.

[aaronmell]

The project is in a fairly usable state. As long as the kubernetes api could be kept up to date.

On Fri, Jan 8, 2021 at 4:55 AM Adnaan Badr [email protected] wrote:

What would it take to give it some legs ? IMO jkcfg is still the best approach for a generic configuration library out there.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jkcfg/jk/issues/365#issuecomment-756691675, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADXZTRWMVRPSWCDWSP5Q43SY3QBRANCNFSM4R7EM2DQ .

[squaremo]

@adnaan Thank you for the supportive message <3

May I ask, which bits of jk are you using? And which bits would you like to use, but they don't work as well as you need them to?

[adnaan]

Everything works. And we use almost all of the available APIs. Except one thing: commonjs modules. Not being able to bundle commonjs modules has made us take some hacky paths. Rest of it just works.

Additionally we have done some work to generate grafana charts.

We have a library on top of jkcfg. It encodes our best practices and defaults.

[adnaan]

@squaremo Maybe I can help with some maintenance work ?

[squaremo]

@adnaan That's a kind offer :-) There is certainly upkeep to do -- e.g., I was looking at updating the Kubernetes schema definitions the other day and noticed that the upstream https://github.com/instrumenta/kubernetes-json-schema has been abandoned, so that needs reworking. Can you email me at the address on my profile, please? Thank you!

[adnaan]

Hello ! Used some of my vacation time to work on porting jkcfg API to Deno: https://github.com/dxcfg/dxcfg.

• Tried to be as close as possible to the jkcfg/std API. Although, I have taken liberties in tweaking the API here and there. Some of the API's are natively available in Deno itself.

• Dropped the jkcfg/kubernetes overlay, chart, shorts APIs completely. After using jkcfg in production pipelines for last 18 months, the learning was that these things can become really really specific to your use case and sway away from the core APIs quickly. Although initially I was able to port it, I realised that supporting any kind of overlay API will be a lot of maintenance in the future. Instead the plan is to provide direct integrations to things like kustomise. I feel it would be better to keep any kind of opinionated config structure outside of the API. dxcfg can remain focused on managing yaml, json and toml better.

• Have used the generators from livecyle/deploykit to generate the k8s API for 1.22.3. The blueprints pattern from deploykit is quite interesting. Thank you @Yshayy

• Next step is to come up with a roadmap

Thank you. Have a nice day.