Блог

Допустим, у меня есть манифест Jelastic, в котором в разделе настроек я запрашиваю у пользователя адрес электронной почты (для настройки какой-либо службы). Поскольку пользователь, использующий Jelastic, уже вошел в систему Jelastic по электронной почте, возможно, имеет смысл предложить пользователю использовать это электронное письмо. Это экономит ее ввод во время настройки манифеста. Итак, в идеале я хотел бы сделать следующее:

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

Затем в тексте манифеста об успешном выполнении я хотел бы отобразить его вместе с другими учетными данными для развернутых служб в установленной среде Jelastic:

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

Электронное письмо обычно используется в качестве имени пользователя в службе, развернутой в новой среде Jelastic, и в тексте об успешном выполнении оно будет отображаться рядом с соответствующим паролем.

Это все хорошо, но это не работает. Действительно, я не могу использовать ${user.email} поле default в email настройках.

В настоящее время я нашел единственный жизнеспособный способ заставить его работать следующим образом:

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

Затем я могу использовать его для установки такой службы:

 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.

Я нахожу это очень сложным для очень простой задачи. Должно же быть что-то более простое, верно? Может кто-нибудь дать мне подсказку?

Мне понадобится решение для манифеста, в котором у меня есть много таких необязательных параметров. В настоящее время у меня проблема с электронной почтой, а также с секретами. В моих случаях использования имеет смысл, чтобы эти секреты предоставлялись мной непосредственно в настройках или чтобы они автоматически создавались, например ${fn.password(20)} . Для некоторых установок мне нужно установить их самостоятельно, для некоторых других установок мне нужно, чтобы они создавались автоматически.