Add custom cluster mgmt url flag

redhat-developer / app-services-cli

Command Line Interface for RHOAS

https://redhat-developer.github.io/app-services-website/

Apache License 2.0

41 stars 72 forks source link

Add custom cluster mgmt url flag #1803

Closed dimakis closed 1 year ago

dimakis commented 1 year ago

This allows the user to specify a custom api-gateway for their clustermgmt (ocm) which allows the CLI to install stage Addons if the targeted KFM deployment is stage.

Closes #

Verification Steps

Do x
Do y

Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation change
[ ] Other (please specify)

dimakis commented 1 year ago

@machi1990 do you suspect that a private network will be the default? the reason I have that as is, is that I presumed public would be default. This was also mentioned by Keith Wall. I'm easy either way really.

machi1990 commented 1 year ago

@machi1990 do you suspect that a private network will be the default? the reason I have that as is, is that I presumed public would be default. This was also mentioned by Keith Wall. I'm easy either way really.

Hi @dimakis there is a bug in that logic which I highlighted. If someone choose to allow for private kafkas - i.e accessKafkasViaPublicNetwork set to "true" then with the logic current in place, it'll send the value as false. And vice versa.

machi1990 commented 1 year ago

@machi1990 do you suspect that a private network will be the default? the reason I have that as is, is that I presumed public would be default. This was also mentioned by Keith Wall. I'm easy either way really.

Also note: the suggested fix does not change the default value.

dimakis commented 1 year ago

@machi1990 do you suspect that a private network will be the default? the reason I have that as is, is that I presumed public would be default. This was also mentioned by Keith Wall. I'm easy either way really.

Hi @dimakis there is a bug in that logic which I highlighted. If someone choose to allow for private kafkas - i.e accessKafkasViaPublicNetwork set to "true" then with the logic current in place, it'll send the value as false. And vice versa.

@machi1990 It is not a bug, its a feature 😛 The wording is changed to public, i.e. would you like your kafkas to have access to a public network hence the inversion.

it is a little confusing yes, as the var in the endpoint is private

machi1990 commented 1 year ago

@machi1990 do you suspect that a private network will be the default? the reason I have that as is, is that I presumed public would be default. This was also mentioned by Keith Wall. I'm easy either way really.

Hi @dimakis there is a bug in that logic which I highlighted. If someone choose to allow for private kafkas - i.e accessKafkasViaPublicNetwork set to "true" then with the logic current in place, it'll send the value as false. And vice versa.

@machi1990 It is not a bug, its a feature stuck_out_tongue The wording is changed to public, i.e. would you like your kafkas to have access to a public network hence the inversion.

it is a little confusing yes, as the var in the endpoint is private

Right. That's confusing. And the fact that it defaults to no public access is also confusing.

jackdelahunt commented 1 year ago

Closed because work is done in other pr #1794