-
Notifications
You must be signed in to change notification settings - Fork 969
fix: allow defining MFE-specific env overrides while preserving extra defaults #7090
fix: allow defining MFE-specific env overrides while preserving extra defaults #7090
Conversation
Thanks for the pull request, @Agrendalath! Please note that it may take us up to several weeks or months to complete a review and merge your PR. Feel free to add as much of the following information to the ticket as you can:
All technical communication about the code itself will be done via the GitHub pull request interface. As a reminder, our process documentation is here. Please let us know once your PR is ready for our review and all tests are green. |
# NOTE: This should be overridden by inheriting MFE-specific role. | ||
MFE_ENVIRONMENT_EXTRA: {} | ||
MFE_ENVIRONMENT: '{{ MFE_ENVIRONMENT_DEFAULT | combine(MFE_ENVIRONMENT_EXTRA) }}' | ||
MFE_ENVIRONMENT: '{{ MFE_ENVIRONMENT_DEFAULT | combine(MFE_ENVIRONMENT_DEFAULT_EXTRA) | combine(MFE_ENVIRONMENT_EXTRA) }}' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Agrendalath Why can't you use MFE_DEPLOY_ENVIRONMENT_EXTRA
when defining extra variables for all MFEs? That's what the mfe_deployer README recommends.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pomegranited, ah, I made a typo in the description. I replaced MFE_ENVIRONMENT_EXTRA
with MFE_DEPLOY_ENVIRONMENT_EXTRA
now.
As you can see below, this variable is used with a default
filter, which means that any env_extra
defined for an MFE will override these values:
https://github.com/openedx/configuration/blob/1909bafde44584ec7bd04f7cb6ee6ac0bfa6b521/playbooks/roles/mfe_deployer/tasks/main.yml#L16
I described a way to fix this in Alternative 2, along with my concerns about this being backward-incompatible.
If you meant using the | combine(MFE_DEPLOY_ENVIRONMENT_EXTRA)
variable in the highlighted line (i.e., instead of the newly added MFE_ENVIRONMENT_DEFAULT_EXTRA
), this is similar to Alternative 3 (the only difference is that we would not replace MFE_ENVIRONMENT_EXTRA
with MFE_DEPLOY_ENVIRONMENT_EXTRA
directly in the mfe_deployer
role, but add an extra combine
filter mentioned above to the mfe
role). It would work, but it wouldn't be backward-compatible.
These solutions would be much better (and more straightforward) if we did not care about compatibility. However, I decided to keep this safe by adding a new variable that does not alter how this role currently works. If we knew nobody relied on this behavior, I would be happy to change it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I see the difference now, thank you for explaining!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
I am reluctant to add even more variables to the MFE/deployer role, but I agree that this is the best solution to the issue described.
Will merge this tomorrow if there are no objections. CC @mphilbrick211
- I tested this by checking that the MFE env variables of a deployed MFE service included both those defined in
MFE_ENVIRONMENT_DEFAULT_EXTRA
and those defined in the specific MFE'senv_extra
. - I read through the code and checked usages and comments for the new variable.
-
I checked for accessibility issuesN/A - Includes documentation -- see CHANGELOG and comments.
-
User-facing strings are extracted for translationN/A
@Agrendalath 🎉 Your pull request was merged! Please take a moment to answer a two question survey so we can improve your experience in the future. |
… defaults (openedx-unsupported#7090) (cherry picked from commit ee8a900)
… defaults (openedx-unsupported#7090) (cherry picked from commit ee8a900)
User story
When deploying MFEs through the
mfe_deployer
role (used in theopenedx_native.yml
playbook), you can specify the following configuration:Then, you define some common env variables that will be shared between your MFEs, like:
However, now you want to use the MFE config API, as some of the MFE variables are not populated at build time. You also want to use overrides for individual MFEs (with
/api/mfe_config/v1?mfe=name_of_mfe
), but it doesn't work. That's because theAPP_ID
is not defined anywhere (so the MFE sends queries to/api/mfe_config/v1?mfe=undefined
).To avoid this (without making further modifications to the MFE env defaults or the
mfe_deployer
role), you could use the following config:However, after the deployment, you notice that none of the variables defined in
MFE_DEPLOY_ENVIRONMENT_EXTRA
were used when runningnpm build
for each MFE. That's because themfe_deployer
role overrides the wholeMFE_DEPLOY_ENVIRONMENT_EXTRA
variable with anything you define inenv_extra
:https://github.com/openedx/configuration/blob/1909bafde44584ec7bd04f7cb6ee6ac0bfa6b521/playbooks/roles/mfe_deployer/tasks/main.yml#L16
To mitigate this, I added
MFE_ENVIRONMENT_DEFAULT_EXTRA
, which you can use in Ansible variables (instead ofMFE_DEPLOY_ENVIRONMENT_EXTRA
) to share env variables between MFEs, while still allowing to useenv_extra
for each of them.Alternatives
MFE_ENVIRONMENT_DEFAULT
in your Ansible vars, but you would need to duplicate all these helpful defaults, which is not an elegant approach.default
tocombine
in this line, but this would be a breaking change because it alters the current behavior of the Ansible roles.MFE_ENVIRONMENT_EXTRA
to something likeMFE_DEPLOYER_CUSTOM_MFE_ENVIRONMENT
here, but this is also a breaking change for anybody who relies on the existing behavior.Author's note
I know the
APP_ID
is not the best example here, as we could modify themfe_deployer
role to populate this value automatically. We have a slightly more complex use case for thefrontend-app-learner-portal-enterprise
, but I wanted to keep the user story simple.Private-ref: BB-8397
Configuration Pull Request
Make sure that the following steps are done before merging: