Proper interface to interact with the resource dynamicily

[Ianzhao071102]

Like a REST api that provides higher level of abstraction than the k8s api server

[jeremylvln]

Hi @Ianzhao071102!

Thanks for the proposal, but I don't think this is worth doing. This API would "just" create the Kube resources, which you can already do directly with Kube's API. Also, I would have to do all the "classic API stuff" like authorization, etc... Something Kube already has and do pretty well I must confess.

Also, the CRDs Shulker exposes are already quite high level, so oversimplifying them would prevent some to fulfill some use-cases, which seems counterproductive at best.

However, Shulker has a GRPC API for some very specific use-cases (like spawning a new server from an existing Fleet, which allows to provision servers dynamically). This API can totally be expanded for some other special use-cases, but I'm afraid a REST-like management is not one of them.

I'm really interested knowing why you need such a feature, I can possibly help you think about an alternative? I've no issue thinking about a tech solution if you have a specific need :)

Thanks!

[Ianzhao071102]

because CRDs are static and I saw the issue: #443. which already considered providing shulker's autoscaling API, saw it in the roadmap that it is a long-term stuff. But I am afraid that the severe issue will make jobs harder. Also please update when the issue #443 is resolved.

I am grateful to hear you for being interested in why I need it, well I just need something that allows putting server.properties in the CRD or via any API and stuff like that.

Also because of the lack of documentation, I can't quite understand the overriding of the configuration, maybe something that can be done (by definition) in the CRD dynamically by the operator or something like that.

Also maybe making shulker somewhere extensive above the current level. I am concerned that it could support MQ autoscaling and make bukkit plugins(running inside a server pod) able to interact with shulker's API. so I'd prefer to use the REST. or maybe REST is hard to model stuff so it would be okay to replace it with any other method while providing the access of the api.

[jeremylvln]

Thanks for the feedback, greatly appreciated!

I understand the frustration about the documentation. It's definitely something I will try to work ASAP as it seems to be the most critical issue.

Give me some time to think and I will try to come back to you with a proper solution :)