Skip to content

Enhancement Request: Support initializeDomainOnPV in discoverDomain output for WebLogic Kubernetes Operator #1628

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

Open
mxb904 opened this issue Apr 23, 2025 · 1 comment

Comments

@mxb904
Copy link

mxb904 commented Apr 23, 2025

Hi team,

We are currently migrating our WebLogic domains to Kubernetes using the WebLogic Kubernetes Operator, and we've chosen the Domain-on-PV pattern as our preferred configuration—primarily because most of our domains are ADF (JRF) based.

As part of this migration, we are deploying empty domains and planning to use the new initializeDomainOnPV feature introduced in the operator. However, when using the discoverDomain tool to generate model files, there is currently no way to include the initializeDomainOnPV field in the resulting model, even when using -target wko or -target wko-pv.

We would like to request support for this feature in discoverDomain. Automatically populating initializeDomainOnPV (perhaps via a flag or template option) would help streamline our domain setup process and reduce the need for post-processing the generated model.

Thank you for considering this enhancement!

@robertpatrick
Copy link
Member

robertpatrick commented Apr 28, 2025

@mxb904 Thanks for the suggestion. Unfortunately, the initializeDomainOnPV section of the WebLogic Kubernetes Operator domain spec is complex and includes many fields that WDT would have no way of knowing what you want. Since WDT knows almost nothing about Kubernetes and is not involved in image creation, we couldn't fill in anything related to the Persistent Volume or Persistent Volume Claim or even about the initializeDomainOnPV image being used. As such, we would create this complex section with a bunch of fields that have to be edited so this doesn't seem like something that would add any value to the discoverDomain output. However, we do have another suggestion that you might want to explore.

The basic idea would be for you to create your own templatized model file that only contains the kubernetes section of the model to add/specify the fields you want in the generated yaml file. Presumably, you could use this same template for all domains and fix it up for each specific domain during the provisioning process.

The high level provisioning process flow would be something like:

  1. Run discoverDomain with the -target wko-pv argument to get the WDT model files from the source domain.
  2. Copy your templatized model into the same output location.
  3. Run some text processing on the templatized model (or its accompanying WDT variables file if you wanted to fill in the blanks this way) to make the templatized model have everything you need for the WKO domain spec for this domain.
  4. Run extractDomainResources feeding in both the model from step 1 and step 3 to produce new domain yaml and create secrets scripts.

Discussing this internally, this seems like it would create a much better result than almost anything we could do as a result of enhancing discoverDomain.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants