bf2fc6cc711aee1a0c2a/kas-installer

Changes to support provisioning a Kafka on a dedicated cluster a.k.a enterprise data plane cluster

machi1990 opened this issue · 18 comments

machi1990 commented
MikeEdgar commented

make sure that KFM is running in OCM mode and not standalone mode when enterprise feature is to be used

Do you envision a new flag that indicates whether the user intends to use enterprise features and the installer performs some basic validation and generates an empty CLUSTER_LIST based on that?

Update SUPPORTED_INSTANCE_TYPES: https://github.com/bf2fc6cc711aee1a0c2a/kas-fleet-manager/blob/main/templates/service-template.yml#L160 for include supported billing models

kas-installer currently just uses the default from the template unless the user intentionally overrides this via a kas-fleet-manager-service-template-params script. With the tag update, the default value includes all of the billing types so we may be covered on this out-of-the-box. Thoughts?

Being able to deregister an enterprise cluster

Are you thinking a wrapper/convenience script or guidance to use rhoas?

machi1990 commented

make sure that KFM is running in OCM mode and not standalone mode when enterprise feature is to be used

Do you envision a new flag that indicates whether the user intends to use enterprise features and the installer performs some basic validation and generates an empty CLUSTER_LIST based on that?

I was thinking this as well. What do you think?

Update SUPPORTED_INSTANCE_TYPES: https://github.com/bf2fc6cc711aee1a0c2a/kas-fleet-manager/blob/main/templates/service-template.yml#L160 for include supported billing models

kas-installer currently just uses the default from the template unless the user intentionally overrides this via a kas-fleet-manager-service-template-params script. With the tag update, the default value includes all of the billing types so we may be covered on this out-of-the-box. Thoughts?

+1. So is a quick win. I hope no one overrides the default one in their kas-fleet-manager-service-template-params script.

Being able to deregister an enterprise cluster

Are you thinking a wrapper/convenience script or guidance to use rhoas?

+1 .I know for a fact that this is a planned work in the CLI, @dimakis can you confirm? So, I think kas-installer needs to only do it after the CLI has support for it. In the meanwhile, the user can directly call the KFM endpoint. What do you think?

dimakis commented

Are you thinking a wrapper/convenience script or guidance to use rhoas?

+1 .I know for a fact that this is a planned work in the CLI, @dimakis can you confirm? So, I think kas-installer needs to only do it after the CLI has support for it. In the meanwhile, the user can directly call the KFM endpoint. What do you think?

indeed, we do plan on adding a de-register command to the CLI 👍

  • 👍1
MikeEdgar commented

So, I think kas-installer needs to only do it after the CLI has support for it. In the meanwhile, the user can directly call the KFM endpoint. What do you think?

I don't mind scripting it in the short term. At a minimum, it will give me some hands-on experience with the new endpoint(s) and would be good to have in the uninstall.sh process too. It might be good to have a version de-registration available outside of rhoas anyway for the un-installation to avoid relying on an active session, etc.

  • 👍1
machi1990 commented

I don't mind scripting it in the short term. At a minimum, it will give me some hands-on experience with the new endpoint(s) and would be good to have in the uninstall.sh process too. It might be good to have a version de-registration available outside of rhoas anyway for the un-installation to avoid relying on an active session, etc.

Okay. One thing the script will need to do as well is - remove the AddOns.

  • 👍1
MikeEdgar commented

Being able to register the cluster with KFM. We can use the latest release of the rhoas CLI for this.

Based on my understanding of the CLI on the dedicated branch, we may be blocked on this until a separate OCM API endpoint can be specified.

machi1990 commented

Being able to register the cluster with KFM. We can use the latest release of the rhoas CLI for this.

Based on my understanding of the CLI on the dedicated branch, we may be blocked on this until a separate OCM API endpoint can be specified.

@dimakis created an alpha release a few weeks ago. Maybe we can have another one with latest changes on redhat-developer/app-services-cli#1804. Any plans on that @dimakis ?

dimakis commented

Being able to register the cluster with KFM. We can use the latest release of the rhoas CLI for this.

Based on my understanding of the CLI on the dedicated branch, we may be blocked on this until a separate OCM API endpoint can be specified.

@dimakis created an alpha release a few weeks ago. Maybe we can have another one with latest changes on redhat-developer/app-services-cli#1804. Any plans on that @dimakis ?

I'm just waiting for someone to approve those changes. As soon as I do I'll release another alpha with the latest changes.

MikeEdgar commented

Very nice, I didn't see that PR. I'll at least try to run that locally until there is a release with those changes. Thanks for mentioning it @machi1990 !

dimakis commented

Very nice, I didn't see that PR. I'll at least try to run that locally until there is a release with those changes. Thanks for mentioning it @machi1990 !

there's an alpha release now with the most up to date changes:

curl -o- https://raw.githubusercontent.com/redhat-developer/app-services-cli/main/scripts/install.sh | bash -s v0.52.2-alpha1

will grap and install it 👍

MikeEdgar commented

Is it expected that the bootstrap domain does not have the kas prefix when CNAME registration is not used? I see in rhoas that the apps subdomain is removed from the cluster DNS, which means KFM does not replace it with kas.

  • 👍1
machi1990 commented

Is it expected that the bootstrap domain does not have the kas prefix when CNAME registration is not used? I see in rhoas that the apps subdomain is removed from the cluster DNS, which means KFM does not replace it with kas.

Good catch, that's a bug. apps. should be there for the cluster_dns when CNAME registration is not used. /cc @dimakis

machi1990 commented

@MikeEdgar @dimakis I'll prepare a PR against RHOAS CLI and ping you on it.

dimakis commented

Is it expected that the bootstrap domain does not have the kas prefix when CNAME registration is not used? I see in rhoas that the apps subdomain is removed from the cluster DNS, which means KFM does not replace it with kas.

Good catch, that's a bug. apps. should be there for the cluster_dns when CNAME registration is not used. /cc @dimakis

So are there instances of the DNS where the ".apps." Is not in the DNS?

MikeEdgar commented

So are there instances of the DNS where the ".apps." Is not in the DNS?

The default ingress for OSD handles the apps subdomain, but for MK there are additional subdomains created where apps is replaced with kas. The current KFM logic just swaps the subdomain (search/replace) so it's expected to be there in the cluster configuration.

machi1990 commented

@MikeEdgar @dimakis here is an attempt for a fix redhat-developer/app-services-cli#1806 please have a look.

  • 👀1
machi1990 commented

Thanks @MikeEdgar

all the tasks in this are completed. I’ll close the issue