Update example with env values does not work

[ileneruth]

Unlike variable store, env values seem to need to get passed as key value pairs:

"env_values":[
   {
     "MY_KEY":"my_value"
   },
  {
     "TF_var":"value"
  }
]

I wish that I could mark some of these as secure or hidden, but that doesn't seem possible.

When I use the example given, I get the following error, but it works with key value pairs.:

timestamp:  2021-11-01T20:10:21.603600403Z
messageid:  M1003
message:    There was an internal Error. Please wait a few minutes and try again. If you still encounter this problem, contact IBM Cloud support.
statuscode: 500
requestid:  <id>

[geethasathyamurthy]

@ileneruth

Could you please share the requestid details, as we are unable to track the issue with the information provided to us.

However, our engineer team is working at the back end for taking metadata from the user. Here are the internal issue details. https://github.ibm.com/blueprint/product/issues/5245

[nastacio]

I am having the same problem.

Docs says the elements of env_values is an array of objects with keys like name, value, and sensitive, while other examples in the same page suggest they look like this (variable name as a JSON key name)

"env_values":[
   {
     "MY_KEY":"my_value"
   },
  {
     "TF_var":"value"
  }
]

[nastacio]

Docs are quite confusing on this topic: https://cloud.ibm.com/docs/schematics?topic=schematics-set-parallelism&interface=ui#parallelism-example

This JSON example for creating the workspace has env_values using the environment variable names as JSON keys:

The very next example has a different structure for each environment value:

[nastacio]

And if you try to use the latter form on call to `ibmcloud schematics workspace update --id ... -f schematics_file.json, it gets really confused, mangling the parsing of the intended value.

For instance, I passed this:

      "env_values": [
        {
          "name": "AWS_ACCESS_KEY_ID",
          "value": "some_access_key",
          "secure": false,
          "hidden": false
        },
        {
          "name": "AWS_SECRET_ACCESS_KEY",
          "value": "some_secret_key",
          "secure": false,
          "hidden": false
        },
        {
          "name": "AWS_DEFAULT_REGION",
          "value": "us-east-1",
          "secure": false,
          "hidden": false
        }

And after the update operation, I ran

ibmcloud schematics  workspace get --id ${ws_id} --json

and this is what env_values looked like:

     "env_values": [
        {
          "name": "value",
          "value": "some_access_key",
          "secure": false,
          "hidden": false
        },
        {
          "name": "hidden",
          "value": "false",
          "secure": false,
          "hidden": false
        },
        {
          "name": "secure",
          "value": "false",
          "secure": false,
          "hidden": false
        }

This aspect of passing environment variables is mostly broken, to the point we had to refactor our terraform files to stop relying on them.

[geethasathyamurthy]

@nastacio Sorry to hear there was a inconvenience cause in the structure. Thanks in bringing this to our notice, we will check and revert with the update shortly.

Regards, Geetha

[nastacio]

I see some other example in another page mentioning a env_values_metadata: https://cloud.ibm.com/docs/schematics?topic=schematics-workspaces-faq

So I guess this correct (?) format needs to be consistently applied to all document pages mentioning env_values.

[geethasathyamurthy]

@nastacio We have created an issue https://github.ibm.com/blueprint/product/issues/7375 internally to fix the findings, and the docs will also be updated accordingly.

Thanks, Geetha

[geethasathyamurthy]

So I guess this correct (?) format needs to be consistently applied to all document pages mentioning env_values.

Hi @ileneruth

We have incorporated the findings in all the env_values and published the content, request to confirm if the issue is fixed and close the issue.

Thanks,

[geethasathyamurthy]

Closing the issue, request to reopen the issue in case you observe the findings are unfixed.