We should be able to update the domain after deployment. Under the hood this is just a kubectl patch of the configmap. Knative updates the service hostname automatically when the config map is changed.
Solution
Add a Save changes button. We can simplify the form a bit in the process:
If Knative has not yet been installed, it would look the same as today.
What does success look like, and how can we measure that?
Update a Knative field on your k8s clusters many times without a problem and without upgrading your knative version.
Under the hood this is just a kubectl patch of the configmap
I think the update should go through Helm rather than kubectl. Since the setting is controlled by helm it is risky to just update the resultant value using kubectl. It may even just end up getting reverted anyway by Helm if anything else changes.
Since we install our Helm Charts with helm install --upgrade, the update of it is already covered on the backend. Although, some adjustments are required for everything to work out nicely.
Right now we define if an application is updatable by checking if there's a new version of it available. I consider this a definition of upgradable rather than updatable. Our system does not distinguish between the two. This means that, in summary:
Every time the backend gets hit on Clusters::ApplicationsController#create, the app will be updated if there are any different attribute parameters.
Also, every time the backend gets hit on Clusters::ApplicationsController#create, it will upgrade the app if there is a new version available.
Right now, to tell the frontend that an app is updatable/upgradable, we simply check if there's a new version available for that app. Which has nothing to do with an app being updatable, rather upgradable.
That being said, I suggest:
i) We could define the frontend as responsible for enabling a way to update the fields each app can update. Perhaps any app with editable fields should be updatable by default. E.g., Knative can have its Domain changed and CertManager can have its Issuer Email field updated, so they should be updatable.
ii) Some apps like Knative might not be easily upgradable, since it's in alpha. Considering that every request to update an app will also upgrade it, Knative will risk to be broken after the update if a new version of Knative was released. So we should either put a disclaimer on the frontend explaining that Knative could be broken after the update due to its alpha state, or we could force the Knative update to use always the same version of when it got created for the first time. Then later we can improve the logic for defining what's an upgradable app.
iii) Another necessary change is that our Cluster::Concerns::ApplicationStatus.installed scope only considers installed state. This scope is used to find the Functions we need to display in our FunctionsController. So either we edit the scope to also include updated states, or we create another scope and change the function finder to look up for updated as well. Our Gitlab::UsageData might also be broken if we don't fix this scope since all the cluster_application counts make use of this scope.
I understand that there's no backend need then. The backend request could be the same as the one for the Upgrade button we already have.
UPDATE
We'll need from the BE:
Have a second backend endpoint for updating the App without auto-upgrading. This will allow us to not automatically upgrade on an update in case upgrade to a new version could cause any issues. Besides, it also makes it clearer to split the responsibilities on a future API endpoint. (new MR to be created)
Make sure that we have solved from the backend the FunctionsController#index, so the user can see the functions after Knative is updated. This is being discussed here: