New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
THREESCALE-9000 Allow adding annotations to components via APIManager CR #836
Conversation
da04ba5
to
51003b2
Compare
Verified that annotations can be created and updated via APIManager CR, code also looks good. /lgtm |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. Only one minor comment
47a81c0
to
75574c2
Compare
/test test-e2e |
1 similar comment
/test test-e2e |
/test test-e2e |
regarding I do not see any step. Just |
I will add CR or comment to make it more clear, but actually we can see here following (comparing with previous query for
|
75574c2
to
bb56273
Compare
8d13c8e
to
ec722ac
Compare
/test test-e2e |
Code Climate has analyzed commit 0ba3cd8 and detected 26 issues on this pull request. Here's the issue category breakdown:
View more on Code Climate. |
Hi @eguzki . Validation section - updated. Added details for Annotation change test |
@Patryk-Stefanski I was thinking about the reconciliation policy for labels and annotations. If the user can add their labels and annotations using the APIManager CR, maybe there is no need to be flexible and allow manually added labels/annotations. There is already a way to specify labels/annotations, so the user should be using that and adding labels/annotations manually is not supported. Wdyt? Related issue https://issues.redhat.com/browse/THREESCALE-9820 So my take about this would be the following approach:
Wdyt?? cc @valerymo |
I have my doubts on |
@eguzki , @Patryk-Stefanski I think need separate Task/PR for discussion. I'd like suggest merge this PR as is, as it was for Labels |
Yeah, I think if someone sets the labels through the APIM they should be prepared that it is the single source of truth, this would mean there is less confusion when trying to figure out where to set labels. So labels set in APIM - APIM single source of truth |
We can do what you suggest. IMO, there is no rush, no need to merge something I currently think it is wrong. The reason being that the reconciliation strategy directly impacts this PR and I am proposing a different one. Hence, let's:
|
Yes. But keep in mind that even when the APIM does not add any labels, the 3scale operator still adds few labels (not sure if annotations as well, but I would assume it does as well). |
After a discussion with @eguzki we decided that were going to leave the reconciliation as is ie. users can create labels/annotations through both APIM and DC, however to delete the label/annotation created through APIM you must first delete it from the DC and then from the APIM (This has to be made clear in the documentation). The reasoning for this decision was that it keeps it simple and doesn't overly complicate any of the functionality as well as we avoid removing any labels/annotations set externally. @valerymo Think this pr should be good to go : ) |
Hi @eguzki , @Patryk-Stefanski , I did few tests (please see below), and it seems to me that the flexible approach that we have taken for labels and annotations is quite suitable. Just one note, regarding delete first label in DC. I saw in tests - need first delete in CR (as label was not deleted from DC, was restored if it exists in PR . Yo will see notes below, in tests).
|
WHAT
Jira: https://issues.redhat.com/browse/THREESCALE-9000
Allow adding annotations to 3scale components via APIManager CR
ApiManager CR example for apicast-staging and backend-listener (see Validation section for CR example for all/other DCs/pods
S3 secret example
Validation
Install 3scale operator
Secrets & CRs for test
echo ABC |base64
TEST
Change Annotation test
test-1-CR9000
totest-2-CR9000