Skip to content
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

Add support for defining ILB ports #369

Closed
PleaseStopAsking opened this issue Feb 2, 2022 · 1 comment
Closed

Add support for defining ILB ports #369

PleaseStopAsking opened this issue Feb 2, 2022 · 1 comment
Labels
enhancement New feature or request

Comments

@PleaseStopAsking
Copy link
Contributor

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request

The current implementation of Invoke-ArcGISConfiguration (and the underlying configurations) assumes that if a user defines an ILB via JSON for either ArcGIS Portal or ArcGIS Server, the port it will be listening on is :7443 or :6443 respectively. This works when that is the users implementation but if the port is anything else, it will fail.

To solve this, Invoke-ArcGISConfiguration should allow new values such as in the below example to define what port a users ILB is listening on and fall back to :7443 or :6443 if no value is provided. This would prevent existing users from being impacted while introducing the functionality for those who need it.

Configuration Example

"Server": {
    ...
    "ExternalLoadBalancer": "hosted-example.secmcs.com",
    "InternalLoadBalancer": "example-prd-hst.secmcs.info",
    "InternalLoadBalancerPort": 443
},
 "Portal": {
    "ExternalLoadBalancer": "portal-example.secmcs.com",
    "InternalLoadBalancer": "example-prd-ptl.secmcs.info",
    "InternalLoadBalancerPort": 443
}
@cameronkroeker cameronkroeker added the enhancement New feature or request label Feb 2, 2022
@cameronkroeker
Copy link
Contributor

Hello @PleaseStopAsking,

This capability has been added to v4.0.1.

Thanks,
Cameron K.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants