Forward-port changes from 4.1.1 #380
Merged
+450
−15
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Fixes ManageIQ#376. Partially undoes 783c58b.
[v4.1.z] Fix underscores for non-suffix plurals
Openshift discovery lists both `templates` and `processedtemplates` for same kind "Template": openshift/origin#21668 `templates` is a regular stored api object. `processedtemplates` endpoint isn't a stored object, its POST is a special input (template + params) -> output function. That functionality is already covered in kubeclient by `process_template` method. It doesn't need regular create_, get_, watch_ etc methods. This is already so because in all openshift versions, `templates` comes after `processedtemplates` and replaces it in `@entities["template"]`.
[v4.1.z] Don't try creating methods for /processedtemplates pseudo-entity
Release 4.1.1
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Merge #377 and #378 (and the release itself #379) back into master.
My idea for
v4.1.zbranch was treating the bug in 4.1.0 as "interrupt", put changes on master and some open PRs aside, release 4.1.1, then pretend 4.1.1 happened before these PRs.Since the changelog for 4.1.1 is also relevant for future releases (next is probably 4.2.0), I can just merge it all to master.
@masayag this is what I meant saying you'll get merge conflicts in your #373. Do you object?
An alternative would be merging #373 to master first, then forward-porting these, but then the y -> ies fix would need merge conflict, and would exist in 2 forms on v4.1.z vs master; I prefer having same change across branches, where possible.
In any case we need to combine #373 with the correct logic supporting y -> ies; I'm happy to help.