Create generic objects from manifest files

[omerlh]

Currently the create method support creating resources from python objects, but how can I create objects from manifest files? There is support for wrappers for some objects, but not for everything (service account, cluster role, CRD etc). How can I create them?

[edaniszewski]

The loading from manifests and marshaling into the Kubernetes types largely happens in https://github.com/vapor-ware/kubetest/blob/master/kubetest/manifest.py and is exposed through the object wrapper base class in the load method

kubetest/kubetest/objects/api_object.py

Line 205 in 924075a

obj = load_file(path, cls.obj_type)

It is kept fairly generic, so it should work for object wrappers that kubetest defines. Unfortunately, I haven't found a good way of automatically wrapping objects/having a fallback to do basic wrapping around objects that don't have explicit wrappers defined.

The thought we had was that as support for more objects were needed, they could be added either by us or contributors. You are welcome to open a PR with any additional object wrapper support, or open an issue for any additional objects and we can work on adding them.

[lfn3]

So I think this is a feature that I'm after. We're using istio within our k8s cluster, which defines some additional resources.

While I can add these locally (and in this case it may be desirable to add some convenience methods), I don't think it would be reasonable of me to upstream these into kubetest.

Do you have any ideas for how to approach the generic wrapping of k8s api objects?

This might be closely related to #158

[edaniszewski]

I've been thinking about this on and off since this issue was opened and haven't really come up with anything that I think is particularly great. I think the best that could be done is to some sort of generic object (whether thats a new GenericObject or part of the existing ApiObject base class) which would act as a fall back if it can't be loaded into one of the kubetest wrappers.

I think thats basically as far as things can go in terms of generic objects though (in the current implementation of kubetest). It should fulfill the requirement of being able to load from manifest, but thats pretty much it. I don't see any straightforward path for adding in any sort of generic utility functions for these generic objects (e.g. refresh/get, wait, delete, ...) because AFAIK, you need to know what the object is in order to interact with it (e.g. read_namespaced_deployment_status).

That said, this feature does seem useful and generally necessary for this project to remain broadly useful and maintainable, so I think that it is going to be the core of v1 development. I'll probably start work on a development branch to try some things out around this, but generally speaking, I think this can be accomplished by trying to auto-determine the python API calls based on the object type of the api object. I doubt I can get it to work for all API objects initially, but I do think that it should work for the majority of them, and any common outliers could be implemented more manually.

So I guess the TL;DR here is that:

• I don't think there is a good approach to wrapping generic objects within the current kubetest implementation
• This feature will be the core feature of a stable version 1.0 of the library
• It will take some time for the above to be developed/land, since I don't work on this full time, so it likely will not be ready for use in the super near future

I'm more than happy to discuss any ideas you may have or any other use cases/features/etc you can think of that would be useful to include in v1

[lfn3]

Just being able to load it from a manifest would definitely help in our case, particularly if we could then access any properties on the deployed api object by treating the object like a dict.

With the way the code is currently structured (relying on the swagger generated clients/models) it isn't entirely clear to me how you would go about handling objects that are under custom resources and therefore can't have generated swagger api clients included unless they're generated somehow.