File based bindings#1669
Conversation
theghost5800
force-pushed
the
fileBasedBindings
branch
from
c7bd974 to
4ea6213
Compare
| <jackson.databind.version>2.19.1</jackson.databind.version> | ||
| <liquibase.version>4.32.0</liquibase.version> | ||
| <liquibase-slf4j.version>5.1.0</liquibase-slf4j.version> | ||
| <cloudfoundry-client.version>2.58.0</cloudfoundry-client.version> |
There was a problem hiding this comment.
This change in adopted cloudfoundrry client is done temporary to test the change. Before merge It will be necessary to adopt new release of cf-java-client or just move whole project into multiapps-controller 😆
| Map<String, Boolean> appFeatures = (Map<String, Boolean>) PropertiesUtil.getPropertyValue(parametersList, | ||
| SupportedParameters.APP_FEATURES, | ||
| Collections.emptyMap()); | ||
| Map<String, Boolean> appFeaturesWithOverriddenSsh = new HashMap<>(appFeatures); | ||
| if (isSshEnabled != null && !appFeatures.containsKey(Constants.APP_FEATURE_SSH)) { | ||
| appFeaturesWithOverriddenSsh.put(Constants.APP_FEATURE_SSH, isSshEnabled); | ||
| } |
There was a problem hiding this comment.
Please extract this logic in separate method like:
Map<String, Boolean> appFeatures = getNormalizedAppFeatures(parametersList, isSshEnabled);
Also do we need to use two Map objects?
There was a problem hiding this comment.
Yes, this is necessary in case when app-features parameter is not set and still ssh-enabled is used. This is done in order to be backwards compatible.
| // (48) app-features parameter with multiple features enabled/disabled | ||
| Arguments.of( | ||
| "/mta/app-features/mtad-app-features.yaml", "/mta/app-features/config-app-features.mtaext", "/mta/cf-platform.json", null, null, false, | ||
| new String[] { "feature-app" }, // mtaArchiveModules |
| </extensionElements> | ||
| </callActivity> | ||
| <sequenceFlow id="sid-26C87D1E-88D5-47E3-907B-0F8EBBCD2C36" sourceRef="executeTasksCallActivity" targetRef="publishProvidedDependenciesTask"></sequenceFlow> | ||
| <callActivity id="hooksCallActivity" name="Execute Hooks Call Activity" flowable:async="true" calledElement="${hookProcessGetter.get(hookForExecution, execution)}" flowable:calledElementType="key" flowable:inheritVariables="false" flowable:completeAsync="true" flowable:fallbackToDefaultTenant="false"> |
There was a problem hiding this comment.
why this is removed inheritVariables="false"
There was a problem hiding this comment.
This is really interesting topic how was set at first place because flowable modeler did remove this explicit set to false.
theghost5800
force-pushed
the
fileBasedBindings
branch
from
1fcc587 to
0c7a72d
Compare
| } | ||
|
|
||
| @SuppressWarnings("unchecked") | ||
| private Map<String, Boolean> getAppFeatures(List<Map<String, Object>> parametersList, Boolean isSshEnabled) { |
There was a problem hiding this comment.
this method does too many things, split it and reduce number of params
| @@ -39,6 +42,7 @@ public Staging parse(List<Map<String, Object>> parametersList) { | |||
| SupportedParameters.HEALTH_CHECK_HTTP_ENDPOINT, | |||
| getDefaultHealthCheckHttpEndpoint(healthCheckType)); | |||
| Boolean isSshEnabled = (Boolean) PropertiesUtil.getPropertyValue(parametersList, SupportedParameters.ENABLE_SSH, null); | |||
There was a problem hiding this comment.
will we depracate this?
There was a problem hiding this comment.
We don't have such discussion yet but most probably yes because app-feature parameter will unite all similar settings including ssh enablement. With this change if ssh-enabled and app-features: ssh: true/false were specified, it will print warning and will ignore ssh-enabled parameter value.
| return !StringUtils.isBlank(newCommand) && !Objects.equals(newCommand, existingProcess.getCommand()); | ||
| } | ||
|
|
||
| private boolean isAppFeaturesChanged(Map<String, Boolean> newAppFeatures, Map<String, Boolean> existingAppFeatures) { |
There was a problem hiding this comment.
rename to areAppFeaturesChanged ?
| return newAppFeatures.entrySet() | ||
| .stream() | ||
| .anyMatch(newAppFeature -> !Objects.equals(newAppFeature.getValue(), |
There was a problem hiding this comment.
what will happen if someone deletes their app features from the descriptor?
this will result in false, and we will not modify the already existing app features -> in context of cf deploy
in blue-green we will creata a new app and it will have the CF defaults?
Is this an inconsisteny and should we provide default values for app features?
There was a problem hiding this comment.
I think it's not good idea to set default values on our own, it is already done by cloudfoundry itself. In the case where application already exist is interesting what to do because we cannot just get default values from cf, the only app feature which is configured per space is ssh enablement - https://v3-apidocs.cloudfoundry.org/version/3.196.0/#list-space-features
if we set explicitly now default values for app features, in future when new app features are added we won't have default values for them. The whole feature parameter is implemented in a way that allows customers easily to specify all app feature parameters in the future.
theghost5800
force-pushed
the
fileBasedBindings
branch
from
0c7a72d to
5228c60
Compare
JIRA:LMCROSSITXSADEPLOY-3111
JIRA:LMCROSSITXSADEPLOY-3111
JIRA:LMCROSSITXSADEPLOY-3111
theghost5800
dismissed stale reviews from s-yonkov-yonkov and IvanBorislavovDimitrov
via
72204f8
theghost5800
force-pushed
the
fileBasedBindings
branch
from
5228c60 to
72204f8
Compare
|
3 participants
No description provided.