Adding lots of resources & methods #52
Conversation
- Resynced and added missing CRUD methods where possible - More consistent options default declaration in function params - Consistent promise rejection for missing name param - Ordering, spacing, etc. all aligned. There's a lot of dupe/boilerplate, maybe this could be refactored into a higher order CRUD object that takes in a resource name and base URL...
- Slight style alignment with promise rejection message
ghost
added
the
|
Wow! :) |
|
@tavogel I haven't had a chance to really review this yet, but just wanted to say thanks for such a comprehensive effort! Are you free to say what project you are working on with this module? |
|
Hey @lance, the tool is our "Shippy" internal provisioning API/CLI/UI. We discuss it briefly during our talk from OpenShift Commons: https://youtu.be/GRjz775Na-M?t=1038 |
|
@tavogel i'm starting to go through this and i noticed the comments, which i sort of use as documentation, are being removed. any reason for this? |
|
@lholmquist Reason primarily being that I rebuilt all of the modules from a common template (copy paste, find replace). Every resource has the same basic functions... findAll, find, create, update, remove, removeAll (depending on the resource, not all are included). Some functions were documented, but most were not (and not all of the same type, for all resources). Some documentation was incorrect/misleading, or pointing at differing versions of the OpenShift documentation. If these comments are high value to you i'd recommend using JSDoc across all functions, and picking an OpenShift version to target. Really the only things that change between the modules is the name of the resource, whether it uses Kube or OpenShift API, whether it is namespaced, and some resources don't have all of the methods defined. If you use your Since this pattern is so repeatable i'd probably recommend having a common, shared "resource" module, and just passing in a configuration object (you already have a higher order client wrapper -- it could go in there). This would define the name of the resource, the base url, which methods to include, and then return the same modules to you (without duplication). Then adding new resources is a matter of configuration. Added benefit: you wouldn't need as many duped tests either. I would have taken a stab at it but I thought it would be more challenging to merge, so I simply adopted your style for now. Here's one example of this, from another OSS lib we're using in Shippy: https://github.com/kr1sp1n/node-vault/blob/master/src/commands.js |
|
@tavogel yea, the lib could be a little more simplified, but, thats a future thing :) So the reason we only had certain methods added and not others was because we didn't need them at the time. This lib is used by another lib called nodeshift, https://github.com/bucharest-gold/nodeshift. So i only added the endpoints i needed. what you've added is awesome! |
|
@tavogel thanks for this. i'll release a new version soon |
|
@tavogel just released 0.11.0 https://www.npmjs.com/package/openshift-rest-client 🍾 🎆 |
|
Happy to help! |
Hey there! We needed a good deal of resources & methods that weren't exposed by the library, and have added them. Hope this is useful!
Build-configs
Builds
Cluster-role-bindings
ConfigMaps
DeploymentConfig
Groups
ImageStreams
Pods
ProjectRequests
Projects
Replication Controllers
Role-bindings
Routes
Secrets
Services