Skip to content
This repository has been archived by the owner on Jun 26, 2024. It is now read-only.

Is it possible to opt out from injecting environment variables? #296

Closed
navidsh opened this issue Jan 17, 2020 · 12 comments
Closed

Is it possible to opt out from injecting environment variables? #296

navidsh opened this issue Jan 17, 2020 · 12 comments
Assignees
Labels
groomed kind/enhancement New feature or request

Comments

@navidsh
Copy link
Member

navidsh commented Jan 17, 2020

Edit by Shoubhik
Jira https://issues.redhat.com/browse/APPSVC-9


Is it possible to skip the "injecting environment variable" step after the controller created service binding secrets?

We are looking into integrating Appsody Operator with Service Binding Operator, and we want our operator to be in charge of modifying the resources (e.g. Deployment, StatefulSet) created by the Appsody operator to run users' applications.

@sbose78
Copy link
Member

sbose78 commented Jan 17, 2020

Heya!

Is it possible to skip the "injecting environment variable" step after the controller created service binding secrets?

We have a task on our planning board to only only generate a managed secret which we never got to :)

Just to throw it out there, if applicationSelector is not defined in ServiceBindingRequest, SBO skips the injection.

You mean, it already works? That would be an unintended feature then :)

@navidsh
Copy link
Member Author

navidsh commented Jan 17, 2020

We have a task on our planning board to only only generate a managed secret which we never got to :)

Nice! Is there any timeline of when it will be implemented?

You mean, it already works? That would be an unintended feature then :)

No, I think specifying applicationSelector is required now. I meant one way to do it is by not defining applicationSelector in the CR :)

@sbose78
Copy link
Member

sbose78 commented Jan 17, 2020

I'll move it up the board, @navidsh .

@DhritiShikhar Could you start working on https://issues.redhat.com/browse/APPSVC-9 again :) , do have a chat with @isutton to avoid conflicts since there's a major refactoring happening in #293 / #286 .

@sbose78
Copy link
Member

sbose78 commented Jan 17, 2020

Created a public copy of the feature request/story #297

@navidsh
Copy link
Member Author

navidsh commented Jan 17, 2020

@sbose78 Thank you very much!

@arthurdm
Copy link
Member

thx guys! this will allow for a seamless integration. 👍

@sbose78
Copy link
Member

sbose78 commented Feb 5, 2020

Update:

We merged #293 which had refactoring to support multiple backing CRs ( example: PostgreSQLService CR and a PostreSQLCredential CR ) ).

As far as I remember, this was one of the use cases in some of the IBM operators which could be used as backing services.

@sbose78
Copy link
Member

sbose78 commented Feb 20, 2020

@DhritiShikhar is working on this, and should have a PR this week.

@arthurdm
Copy link
Member

awesome, thanks guys.

@sbose78
Copy link
Member

sbose78 commented Mar 2, 2020

Work is in progress #350

@Avni-Sharma
Copy link
Contributor

#350 is merged. @DhritiShikhar shall we close this issue?

@DhritiShikhar
Copy link
Contributor

DhritiShikhar commented Mar 19, 2020

Yes. I don't have rights to close the issue though.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
groomed kind/enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants