如何在我的 Jelastic 清单中进行可选的 email 设置并将值返回给用户？

Question

Let's say I have a Jelastic manifest where, in the settings section, I ask the user for an email address (to setup some service). Because the user using Jelastic already is logged on Jelastic with an email, it might make sense to propose to the user that she uses that email. It saves her typing during the manifest setup. So, ideally, what I would like to do is this:

settings:
  fields:
    - name: email
      caption: Email
      type: string
      default: ${user.email}

Then, in the manifest success text, I would like to display it, along with other credentials for the deployed services in the installed Jelastic environment:

success:
  text: |
    **Email**: ${settings.email}

The email is typically used as a username in a service deployed on the new Jelastic environment and in the success text it would be displayed near the corresponding password.

This above is all nice, but it doesn't work. Indeed, I cannot use the ${user.email} in the default field for the email settings.

Currently, the only viable way I've found to make it work is as follows:

settings:
  fields:
    - name: useJelasticEmailAsEmail
      type: toggle
      caption: Use Jelastic Email
      value: true
      hidden: false
      showIf:
        false:
          name: email
          caption: email
          type: string
          required: true

Then, I can use it to install a service like so:

onInstall:
- script: 'return { result: 0, email: ${settings.useJelasticEmailAsEmail} ? "${user.email}" : "${settings.email}" };'
- install:
    jps: my-service-manifest.yml
    settings:
      username: ${response.email}

However, after installation of my-service-manifest.yml , I have no access to the actually used email anymore, therefore I cannot use the ${response.email} in my success text, except maybe if my-service-manifest.yml returned the email somehow (possibly with a return statement?).

The thing is, I may have many services to install like that, but only one requires the email. Additionally, it might be that for some reason that service requiring the email must be installed first. In such a case, with the above solution, I'd need to propagate the email through all services in order to get it out to the success text. The email would be consumed by the first service and somehow returned to the next. The next service does not need the email, but must propagate it, therefore it should take it as settings argument and return it to the next service, and so on. This is not very nice to have a manifest taking arguments it doesn't need, therefore that solution is probably not the right one.

I find that very complicated for a very simple problem. There must be something easier to do, right? Can someone give me a hint?

I'd need a solution for a manifest where I have many of such optional parameters. Currently, I have an issue with the email and also with secrets. In my use-cases, it makes sense that these secrets be provided by me directly in the settings or that they be automatically generated with eg ${fn.password(20)} . For some installations I need to set them myself, for some other installations I need to let them be automatically generated.

Answer 1

So, the working solution I have found goes as follows, assuming I have 2 optional parameters:

1. in the settings section of my jps manifest, I do

settings:
  fields:
    - name: useOptionalParam1
      type: toggle
      caption: Use optional param1
      value: true
      hidden: false
      showIf:
        false:
          name: param1
          caption: Param1
          type: string
          required: true
    - name: useOptionalParam2
      type: toggle
      caption: Use optional param2
      value: true
      hidden: false
      showIf:
        false:
          name: param2
          caption: Param2
          type: string
          required: true

2. define values for those params in the globals section (for the email, this is not necessary, because it is defined as user.email ):

globals:
  OPTIONAL_PARAM1: ${fn.password(20)}
  OPTIONAL_PARAM2: ${fn.password(20)}

3. define an action like this:

actions:
  getOptionalParams:
    - script: 'return { result: 0, param1: ${settings.useOptionalParam1} ? "${globals.OPTIONAL_PARAM1}" : "${settings.param1}", param2: ${settings.useOptionalParam2} ? "${globals.OPTIONAL_PARAM2}" : "${settings.param2}" };'

4. call the action wherever necessary; for example, before the success text:

# settings, globals, nodes sections
[...]

onInstall:
  - myVariousInstalls
  - getOptionalParams

success:
  text: |
    **PARAM1**: ${response.param1}  
    **PARAM2**: ${response.param2}

Note the last call to getOptionalParams at the very end of the onInstall section. It is there to provide the response object to the success section. Interestingly, that works fine. The getOptionalParams action can also be called anywhere in the myVariousInstalls action. It must be called before an operation, for example like this:

actions:
[...]
  myVariousInstalls:
    - getOptionalParams
    - install:
        jps: path/to/manifest
        settings:
          param1: ${response.param1}

In so doing, I solve my initial problem.