BUG-591266: add deployment name and rename tier-based objects. #242
Conversation
Updated doc with info on how to leverage environment name.
charts/pega/README.md
Outdated
| ```yaml | ||
| global: | ||
| environment: | ||
| name: app1-dev- |
There was a problem hiding this comment.
Is this tied into the global.domain parameter that is used for the hostname for this environment? It seems like it would be less confusing if the environment name value were derived from that value.
There was a problem hiding this comment.
No.
I am not familiar with global.domain (only global.tier[].ingress.domain). Can you point me at a reference?
There was a problem hiding this comment.
Sorry - I meant global.dnsname. I believe this is used for configuration for the ingress.
That said, I also noticed that there is a global.ingress.domain param. Can all of these be consolidated? It seems like they all could potentially be set to the same value.
There was a problem hiding this comment.
I couldn't find a reference to 'dnsname' grepping through the project.
I do see a couple of 'domain' args:
- global.tier[].ingress.domain
- global.tier[].service.domain
- global.tier[].domain
Though I'm inclined to say that we should not derive this from the domain used for ingress. My thought is that these names would be internal identifiers that don't necessarily relate to their public domain names. My intention in bringing up DNS naming conventions was to indicate the constraints on the names given:
https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names
(Don't want folks thinking they can include spaces and such.)
There was a problem hiding this comment.
global.dnsname is referenced in the sce. @zitikay do you have any thoughts about this?
There was a problem hiding this comment.
Actually, @misterdorito you added the dnsname param (in the SCE). I'm just trying to avoid the confusion of having similar parameters with slightly different uses.
How would you differentiate the following to a user?
global.tier[].ingress.domain
global.dnsname
global.environment.name
There was a problem hiding this comment.
global.dnsname: This is only used in the SCE and is largely need to work around the limited utility of the SCE tooling. It is internal to the SCE and among the things that I'd like to refactor out of existence -- as will probably happen soon given my understand of work to come in the near future (as there is need for multiple ingresses for different types of deployments.
I'd rather we did not derive these 'deployment.name'-s (see other comments below regarding the change of nomenclature) from ingress/dns names as I'd expect that these will be relatively short names use to distinguish deployments (mostly so that PDC is capable of reporting on stream nodes in client-managed cloud scenarios). I'd expect this not to be widely used if PDC is not a concern. For SCE deployments, this will not be used. And as there are no guarantees that multiple ingresses in the same deployment will have commonality in their domains.
Right now, yes there should be a '-' (global.environment.name: app1-dev-) the way it is coded currently. Happy to do either. Do you have a preference for adding the dash programmatically? |
I haven't tried, but it shouldn't be a problem. |
So, based on your wordsmithing above, I think it would be appropriate to change global.environment.name to global.deployment.name (reading you words above we're using environment in 2 different ways where the first one is really describing a deployment). With that in mind: Specify a deployment name that is used to differentiate this deployment in your environment. This name will be prepended to the various Pega tiers and the associated k8s objects in your deployment. Your deployment name should be constrained to lowercase alphanumeric and '-' characters. Thoughts? |
There was a problem hiding this comment.
- Are you not planning to add this entry in values.yaml?
- Should we also append the env name to
pega-credentials-secret.yaml,pega-registry-secret.yaml,pega-environment-config.yamlobject names? Though this is not need for original requirement of this bug, but doing this would make things consistent. It also opens feature to deploy more than one pega helm releases in a single namespace - Should we deal with the
-bit programmatically. As I understand, if environment name not ended with-would lead some cluttered output, very minor thing to care for.
@dcasavant Looking a little more closely... We could change this, but there is a minor wrinkle.... We'll have to change some the internal logic regarding isExternalSearch because some of this logic is based on the correlation between the pega-search service and the pegasearch.externalURL being hardcoded to http://pega-search in the values yaml. Should be doable |
|
Hi @misterdorito , |
I've added global.deployment.name to values.yaml, and values-large.yaml. Wasn't planning on adding it to values-minimal.yaml, but I have no objection to adding it.
The charts are adding the dashes at this point. |
I haven't yet, but will take a look tomorrow. I may have questions for you. |
misterdorito
changed the title
I have made changes to this PR to address this concern. I have tested them manually (helm template ... ) and they look correct to me. Please take a look. |
|
@dcasavant Do we want to rename the hazelcast service and constellation services as well? |
|
@misterdorito Is the new deployment name correlated with the namespace at all? I ask this because it sounds like PDC is using the namespace as a first lookup point to identify pods associated with a given customer (when problems are detected). I'm just trying to avoid having too many different ways to configure the name of an infinity deployment (looking at this from a support standpoint) |
Is deployment name correlated to namespace? No. My understanding of the PDC is that within a given PDC tenant, hostnames need to be unique. I don't think it has any understanding of k8s namespaces at this point. In the past unique system names would have caused the stream nodes to be an issue, but according to the PDC folks there is a range of platform releases where info included in the alert format doesn't include system name. The PDC/stream tier uniqueness problem is only a CMC issue. More flavor... Renaming the stream tier could be achieved by renaming the tier name for stream, but the PDC folks posed objections because some clients insisted on using the same values.yaml for multiple deployments of the platform. I can only surmise that they're passing in db connection info via cmd line args to helm. |
misterdorito
added
the
integ-all
|
Starting PR-242 validation on -> integ-all |
1 similar comment
|
Starting PR-242 validation on -> integ-all |
|
Starting PR-242 validation on -> integ-all |
1 similar comment
|
Starting PR-242 validation on -> integ-all |
|
I have performed an out-of-place upgrade with the changes in this branch and it has worked as expected. None of the changes in this PR should impact an in-place upgrade. |
|
Starting PR-242 validation on -> integ-all |
1 similar comment
|
Starting PR-242 validation on -> integ-all |
|
Starting PR-242 validation on -> integ-all |
1 similar comment
|
Starting PR-242 validation on -> integ-all |
charts/pega/README.md
Outdated
| @@ -161,7 +161,7 @@ The default value is "pega" if it is unset. | |||
|
|
|||
| ## Tiers of a Pega deployment | |||
|
|
|||
| Pega supports deployment using a multi-tier architecture to separate processing and functions. Isolating processing in its own tier also allows for unique deployment configuration such as its own prconfig, resource allocations, or scaling characteristics. Use the `tier` section in the helm chart to specify which tiers you wish to deploy and their logical tasks. | |||
| Pega supports deployments that a multi-tier architecture model that separates application processing from k8s functions. Isolating processing in its own tier supports unique deployment configurations, including the Pega application prconfig, resource allocations, and scaling characteristics. Use the tier section in the helm chart to specify which tiers you wish to deploy the tier with nodes dedicated to the logical tasks of the tier. | |||
There was a problem hiding this comment.
almost:
Pega supports deployments using a multi-tier architecture model that separates application processing from k8s functions. Isolating processing in its own tier supports unique deployment configurations, including the Pega application prconfig, resource allocations, and scaling characteristics. Use the tier section in the helm chart to specify into which tiers you wish to deploy the tier with nodes dedicated to the logical tasks of the tier.
|
Starting PR-242 validation on -> integ-all |
1 similar comment
|
Starting PR-242 validation on -> integ-all |
Adding the ability to set an 'deployment' name. This environment name will be prepended to the tier names replacing "pega". This will impact the naming of all of the corresponding tier-centric objects (deployments, statefulsets, services, pods, ingresses, etc.).
The particular motivation for adding this is that currently the PDC service is unable to differentiate stream nodes within a given PDC tenant as all of the pod names are pega-stream-0 and pega-stream-1.
To leverage this ability, set global.deployment.name to the desired prefix. The prefix must consist of an DNS friendly identifier as it will be incorporated into a number of k8s object (which have this restriction). An example of a suitable value would be: "app1-dev".
The default if not specified will remain "pega".