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

Hosted cluster deployment, adjust get_random_hosted_cluster_name to work with multiple platforms #10279

Closed
DanielOsypenko opened this issue Aug 12, 2024 · 3 comments
Assignees
Labels
lifecycle/stale No recent activity provider-client Provider-client solution

Comments

@DanielOsypenko
Copy link
Contributor

Following the PR #9957
We need to adjust the get_random_hosted_cluster_name function

Comment from @dahorak:

I understood, that it is good to be able to match the hosted cluster somehow with the hosting cluster, but I'm not sure about this approach, because it is quite specific for the particular environment. I'm not sure, if it is possible, that we would like to run this on octo-argo environment (maybe that is not even sufficient, not sure), or wouldn't this be later used on other platforms as well - e.g. vSphere?
What about at least make the bm_name part optional? So it will not fail if the env_name will not match the expected form or will be missing. Since the last part of the cluster name is anyway random, there shouldn't be any conflict in the cluster name and the only drawback will be the fact, that it will not be directly visible where the cluster belongs to.
Another option which might be sufficient would be to make the whole part bmX configurable and add this configuration to the environment specific conf files.

@DanielOsypenko
Copy link
Contributor Author

    registry_image = catsrc_data.get("spec").get("image")
    return registry_image.split(":")[-1]

same function:
@dahorak
Also I'm not sure, if it is applicable for the places, where this function is used, but this will not work correctly for GA version of ODF.
address this as well

Copy link

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 30 days if no further activity occurs.

@github-actions github-actions bot added the lifecycle/stale No recent activity label Nov 10, 2024
Copy link

This issue has been automatically closed due to inactivity. Please re-open if this still requires investigation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lifecycle/stale No recent activity provider-client Provider-client solution
Projects
None yet
Development

No branches or pull requests

1 participant