-
Notifications
You must be signed in to change notification settings - Fork 216
OWLS 86115: Model in Image should not use operator generated configuration overrides #2285
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 7 commits
7d55190
1797cdc
78257a8
7438911
df14d4d
ad00e84
7ec7810
eca7d2f
2bcc31b
b4b4345
48e4252
c116a66
00c29e5
28f0e72
4c8ec57
5851ba6
2cf4b3e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -767,6 +767,10 @@ def addNetworkAccessPoint(self, server, nap, is_server_template): | |
| nap_protocol = getNAPProtocol(nap, server, self.env.getDomain(), is_server_template) | ||
|
|
||
| if istio_enabled == 'true': | ||
| name = nap.getName() | ||
| if name.startswith('http-') or name.startswith('tcp-') or name.startswith('tls-') or name.startswith('https-'): | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Could this be fragile? The customer could have a nap name that starts with one of these prefixes. Do we have some earlier validation that ensures that the only names with these prefixes would be naps that were edited by our Istio functionality?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I could be wrong but I couldn't find any validation for naps that have these prefixes edited by our Istio functionality. @jshum2479 is there validation for these naps that I didn't see?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This function is to write out the topology in the introspector output (not config override), it is trying to format the name in istio ways. If the customer already have it that way and you skipped writing to the topology yaml, then they won't be setup in the pod correctly, perhaps changing the logic to not prepend the protocol again instead of returning. |
||
| # skip istio ports already defined by WDT filtering for MII | ||
| return | ||
| http_protocol = [ 'http' ] | ||
| https_protocol = ['https','admin'] | ||
| tcp_protocol = [ 't3', 'snmp', 'ldap', 'cluster-broadcast', 'iiop', 'sip'] | ||
|
|
@@ -1606,10 +1610,11 @@ def introspect(self): | |
| tg = TopologyGenerator(self.env) | ||
|
|
||
| if tg.validate(): | ||
| SitConfigGenerator(self.env).generate() | ||
| DOMAIN_SOURCE_TYPE = self.env.getEnvOrDef("DOMAIN_SOURCE_TYPE", None) | ||
| if DOMAIN_SOURCE_TYPE != "FromModel": | ||
| SitConfigGenerator(self.env).generate() | ||
| BootPropertiesGenerator(self.env).generate() | ||
| UserConfigAndKeyGenerator(self.env).generate() | ||
| DOMAIN_SOURCE_TYPE = self.env.getEnvOrDef("DOMAIN_SOURCE_TYPE", None) | ||
|
|
||
| if DOMAIN_SOURCE_TYPE == "FromModel": | ||
| trace("cfgmap write primordial_domain") | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -37,6 +37,7 @@ WDT_OUTPUT="/tmp/wdt_output.log" | |
| WDT_BINDIR="${WDT_ROOT}/bin" | ||
| WDT_FILTER_JSON="/weblogic-operator/scripts/model-filters.json" | ||
| WDT_CREATE_FILTER="/weblogic-operator/scripts/model-wdt-create-filter.py" | ||
| WDT_MII_FILTER="/weblogic-operator/scripts/wdt_mii_filter.py" | ||
| UPDATE_RCUPWD_FLAG="" | ||
| WLSDEPLOY_PROPERTIES="${WLSDEPLOY_PROPERTIES} -Djava.security.egd=file:/dev/./urandom" | ||
| ARCHIVE_ZIP_CHANGED=0 | ||
|
|
@@ -319,9 +320,9 @@ function createWLDomain() { | |
| fi | ||
|
|
||
| # copy the filter related files to the wdt lib | ||
|
|
||
| cp ${WDT_FILTER_JSON} ${WDT_ROOT}/lib/model_filters.json | ||
| cp ${WDT_CREATE_FILTER} ${WDT_ROOT}/lib | ||
| cp ${WDT_MII_FILTER} ${WDT_ROOT}/lib | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. consider appending |
||
|
|
||
| # check to see if any model including changed (or first model in image deploy) | ||
| # if yes. then run create domain again | ||
|
|
@@ -793,6 +794,13 @@ function generateMergedModel() { | |
|
|
||
| export __WLSDEPLOY_STORE_MODEL__="${NEW_MERGED_MODEL}" | ||
|
|
||
| local wdtArgs="" | ||
| wdtArgs+=" -oracle_home ${ORACLE_HOME}" | ||
| wdtArgs+=" ${model_list} ${archive_list} ${variable_list}" | ||
| wdtArgs+=" -domain_type ${WDT_DOMAIN_TYPE}" | ||
|
|
||
| trace "About to call '${WDT_BINDIR}/validateModel.sh ${wdtArgs}'." | ||
|
|
||
| ${WDT_BINDIR}/validateModel.sh -oracle_home ${ORACLE_HOME} ${model_list} \ | ||
| ${archive_list} ${variable_list} -domain_type ${WDT_DOMAIN_TYPE} > ${WDT_OUTPUT} 2>&1 | ||
tbarnes-us marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| ret=$? | ||
|
|
@@ -917,6 +925,15 @@ function wdtUpdateModelDomain() { | |
| # make sure wdt create write out the merged model to a file in the root of the domain | ||
| export __WLSDEPLOY_STORE_MODEL__=1 | ||
|
|
||
| local wdtArgs="" | ||
| wdtArgs+=" -oracle_home ${ORACLE_HOME}" | ||
| wdtArgs+=" -domain_home ${DOMAIN_HOME}" | ||
| wdtArgs+=" ${model_list} ${archive_list} ${variable_list}" | ||
| wdtArgs+=" -domain_type ${WDT_DOMAIN_TYPE}" | ||
| wdtArgs+=" ${UPDATE_RCUPWD_FLAG}" | ||
|
|
||
| trace "About to call '${WDT_BINDIR}/updateDomain.sh ${wdtArgs}'." | ||
|
|
||
| ${WDT_BINDIR}/updateDomain.sh -oracle_home ${ORACLE_HOME} -domain_home ${DOMAIN_HOME} $model_list \ | ||
| ${archive_list} ${variable_list} -domain_type ${WDT_DOMAIN_TYPE} ${UPDATE_RCUPWD_FLAG} > ${WDT_OUTPUT} 2>&1 | ||
tbarnes-us marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| ret=$? | ||
|
|
||
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.
This is going to change our pod hash (
weblogic.sha256) which means that any MII pod that is running when the operator is upgraded will be rolled. Can this instead be set in the pod start script (startServer.sh).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.
Just to clarify the scenario you're describing for my understanding, this is when upgrading the Operator from a previous MII domain that uses sit config overrides to this version which uses the model filter? The one place that uses this environment is in startNodeManager.sh (as a server startup argument) and I couldn't determine how we know the domain source type is 'FromModel' (MII). serverStart.sh does:
if [ -f /weblogic-operator/introspector/domainzip.secure ]; then
...
fi
I think this should work. Let me make the change and verify.
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.
Right, a customer is using operator 3.1.4 and has a MII domain. The admin server and some number of managed servers are running. The customer upgrades to 3.2.0 containing your work. I would expect that pods do not roll simply because I upgrade the operator.
Thinking more deeply about this... The change to add the extra environment variable would have caused the existing pods to roll. I think that we have a workaround in that we can set this in startServer.sh. However, we likely have an earlier issue... Your change to not generate config overrides will mean that the generated domain home will be different. This change would also cause existing pods to roll, correct? If so, we should talk together with @jshum2479 and see if we can come up with a way to roll this out so that existing pods are not rolled or restarted, but newly created pods come up with the new pattern.
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.
We can add logic in start script to reset the env when the DOMAIN_SOURCE_TYPE is FromModel.
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.
It doesn't look like it'd hurt to leave it alone. It'd become a NO-OP.
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.
The
FAIL_BOOT_ON_SITUATIONAL_CONFIG_ERRORis for the core config override logic to failed to start the server if the override file is wrong, the start server script already have the logic to set it to true if the environment is not set, the env is for the case if user choose to override it.I am not seeing a reason to set it for mii since we are using override and it will cause the roll because of the pod spec hash changed because the newly introduced environment variable.
Uh oh!
There was an error while loading. Please reload this page.
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.
The overall point is that there's no need to change or add the old env var setting in this pull. We don't care what it's set to in the new path...
Uh oh!
There was an error while loading. Please reload this page.
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.
in startNodeManager.sh, we set FAIL_BOOT_ON_SITUATIONAL_CONFIG_ERROR system property to 'true' by default. Managed servers fail to start/boot with the following error:
<Mar 29, 2021 8:22:23 PM GMT> <The SitConfigRequired configuration element is set to true, but no situational config files were found.>
<Mar 29, 2021 8:22:23 PM GMT> <Server failed. Reason: 141327>
<Mar 29, 2021 8:22:23 PM GMT>
The validation in WLS is in SituationalConfigManagerImpl:
if (isSitConfigRequired() && unexpiredFiles.isEmpty()) {
if (debugLogger.isDebugEnabled()) {
debugLogger.debug( "[SitConfig] isSitConfigRequired is true and no Sit Config Files exist. Failing boot.");
}
String l = ManagementLogger.logSituationalConfigRequired();
throw new ServiceFailureException(l);
}
So it looks like we should either set it to 'false' or not define it for MII.
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.
The point is that we're not supporting custom or internal sit-cfg in MII regardless, so there won't be any sit-cfg that can fail, so the flag should have no effect. If removing it is safe (doesn't cause a roll), then feel free to remove it. Or feel free to leave it untouched.