-
Notifications
You must be signed in to change notification settings - Fork 244
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
R&D - component configuration semantics #675
Comments
Are you sure that a ConfigMap or Secret is the appropriate format @jorgemoralespou ? That will imply that the user knows the YAML/JSON syntax to be used to pass such additional information. We could start with a very simple file as we prototype with Spring Boot to pass additional info such by example name of the application, env vars, service instance (parameters,...) E.g
|
I'm not quite sure about the reference you're making. This issue should provide for a mechanism to when you want to provide an What we need is to abstract the user the fact of where and how that information will be stored and provide with semantics for him to use configuration files, ssl certificates, properties, environmental values,... |
No as typicaly the services definition will be used to configure the service instance when you select a class from the catalog. Otherwise, it will be required that the |
I agree with you that here we need a secret or a vault store to manage certificate/keys and mount them within the pod of the developer. Nevertheless, it could be possible that the developer will add within the METADATA yaml file some fields needed in order to know the algorithm to be used, ... to encrypt or decrypt the keys, ... So, again, this METADATA or APPLICATION.yml file will help us |
@cmoulliard then we need to define this METADATA file, and it's something that should be out of the scope of this issue. Maybe this issue should depend on us having defined that metadata file. There's an issue for that. #579 |
Ok to define the spec of the MANIFEST or application.yml file with the ticket #579 |
This is perhaps out of scope excepted if we will offer the possibility when we create a component to by example pass the
|
So I assume the goal here is to: User doesn’t need to be bothered about configmaps or secrets, so abstracting the complexity is a prime thing to consider here. |
[updated] Proposal : Abstracting config map and Secrets from the userBy default values will come from configmaps or secrets, the name of configmap/secret keys will be same as environment variable names. Problem with this way of implementing: for setting environment variables$odo config set variable <variable name>=<Value>
Environment variable with <variable name> created successfully This will create a Config map with We can also add $odo config set variable <variable name>=<Value> --secret
Environment variable with <variable name> created successfully for viewing environment variables in a particular
|
@kadel @jorgemoralespou ^ If this looks good for you guys, then I can look forward for Implementation part. |
What will be the name of the ConfigMap? What happens if I run
I think that it might be better to show variables just for particular compnent rather then for the whole app.
This syntax look weird. It should be
|
configmap name will be unique for each component, so <app_name>-<component_name>
if new <variable_name>, then adds the new variable as key in the same configmap, append environment names in deployment config. if specifying same <variable_name>, prompt for
aggree 👍
aggree, ^ this one looks more appealing to me. also, am updating the old comment #675 (comment) with the inputs from here |
Can we turn this into a proposal document type as a PR, as they do in K8S, so we can fix the proposal when comments are made, and when merge we have the full document of what we want and how we want? Some examples:
|
Sometimes I have a feeling that you are reading my mind :-D |
proposing a way to a way for users to deal with environment variables and configuration files for the applications deployed on openshift cluster using odo. fix issue redhat-developer#675
can continue discussions on this PR #806 |
Some commands related to this are specified in |
A lot of has changed since this issue started. We have reworked some of the commands, and partially implemented some of the ideas from this issue. |
We need to provide configuration semantics in different scenarios:
Component creation time. When creating a component, we need to be able to provide configuration for this component in different manners.
After the fact. When a component exists, we need to be able to provide/update/remove configuration for this component in different manners.
We need to define what will be the primitives and possibilities supported. Let's use this issue to define possible options and then come up with a proposal before implementation.
Following is a list of examples that show what needs to be done now, and how this could look like.
UC-CF1: Create a component with an environment variable
UC-CF2: Create a component with properties from a configmap
UC-CF3: Create a component with a configmap as a file
cc/ @kadel @marekjelen @gshipley
The text was updated successfully, but these errors were encountered: