Change externalElasticsearchUrl to externalElasticsearchHost at cc

[mangoGoForward]

What this PR dose?

Change externalElasticsearchUrl to externalElasticsearchHost at cc, and make the definition more clear.

What this PR does / why we need it:

please see kubesphere/kubesphere#3829.

Which issue(s) this PR fixes:

Fixes kubesphere/kubesphere#3829.

[FeynmanZhou]

/cc @kubesphere/sig-observability

[mangoGoForward]

/assign @calvinyv

[calvinyv]

what about the users from the old version of KubeSphere CC with previous parm? do we have any migration mechanism?

[mangoGoForward]

what about the users from the old version of KubeSphere CC with previous parm? do we have any migration mechanism?

We may could use --set to set spec.common.es.externalElasticsearchHost, or add some logic like this in

helm-charts/src/main/ks-installer/templates/clusterconfiguration.yaml

Line 2 in a620e09

{{ lookup "installer.kubesphere.io/v1alpha1" "ClusterConfiguration" "kubesphere-system" "ks-installer" | toYaml }}

{{- $clusterConfiguration := lookup "installer.kubesphere.io/v1alpha1" "ClusterConfiguration" "kubesphere-system" "ks-installer" -}}
{{- if and $clusterConfiguration.spec.common.es.externalElasticsearchUrl (not $clusterConfiguration.spec.common.es.externalElasticsearchHost) }}
  {{ $clusterConfiguration.spec.common.es.externalElasticsearchHost = $clusterConfiguration.spec.common.es.externalElasticsearchUrl }}
{{ end -}}
{{ toYaml $clusterConfiguration }}

Could you give some suggestions？

[pixiake]

Thanks for this contribution. And https://github.com/kubesphere/ks-installer/pull/1798 has been merged.

But v3.2.0 has been released and does not contain this change. Therefore, I think it is more appropriate to merge this pr and kubesphere/kubekey#742 after the release of the next version, otherwise it will cause v3.2.0 to fail to find externalElasticsearchUrl in the installation process.

[mangoGoForward]

Thanks for this contribution. And kubesphere/ks-installer#1798 has been merged.

But v3.2.0 has been released and does not contain this change. Therefore, I think it is more appropriate to merge this pr and kubesphere/kubekey#742 after the release of the next version, otherwise it will cause v3.2.0 to fail to find externalElasticsearchUrl in the installation process.

Ok. And do we need some compatibility measures for old version like above logic?

[pixiake]

Adding only the logic above should not be fully compatible with the old version, because the install process is already included in the image of the old version.

[ks-ci-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: mangoGoForward
To complete the pull request process, please ask for approval from calvinyv after the PR has been reviewed.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[mangoGoForward]

Adding only the logic above should not be fully compatible with the old version, because the install process is already included in the image of the old version.

I have no idea to avoid now, if you have any idea, please share with me, Thanks a lot.

[pixiake]

I think the best way at present may be to update the chart of ks-installer to v3.2.0 first, and then the later new version can use externalElasticsearchHost.

[FeynmanZhou]

I think the best way at present may be to update the chart of ks-installer to v3.2.0 first, and then the later new version can use externalElasticsearchHost.

@pixiake Do we need to create a GitHub issue to track the ks-installer Helm Chart upgrade? If so, it could be a good first issue.

[mangoGoForward]

I think the best way at present may be to update the chart of ks-installer to v3.2.0 first, and then the later new version can use externalElasticsearchHost.

Ok.

[pixiake]

Do we need to create a GitHub issue to track the ks-installer Helm Chart upgrade? If so, it could be a good first issue.

Yes，I have created an issue #190 .

[mangoGoForward]

Do we still need to modify externalElasticsearchUrl to externalElasticsearchHost? @pixiake