Currently, auto devops domain is configured on project's settings. This is problematic as it prevents users from setting up multiple domains for multiple clusters in an easy, intuitive way.
With multiple group clusters, we cannot set variables like AUTO_DEVOPS_DOMAIN per environment
Further details
Because each cluster has a unique ingress IP, each cluster should provide unique base domain configuration.
Solution
Domain
EE/CE
As an owner or maintainer, I am able to set a domain for both my group and project level clusters.
Group
Project
Auto DevOps project settings
EE/CE
As an owner or maintainer, I am no longer able to set a domain within my project Auto DevOps settings
Instance level domain
Instance level domain will not be changed in this issue and will be addressed when we add instance level clusters.
What does success look like, and how can we measure that?
(If no way to measure success, link to an issue that will implement a way to measure this)
This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
@danielgruesso Important to note that given we don't support environment scoped variables for groups this issue is actually necessary to support multiple group clusters as otherwise we'll just always end up choosing the first one. See internal slack thread https://gitlab.slack.com/archives/CB07X8AQ3/p1543896041050300
Hmmm I might have missed something here but if the domain is configured on the cluster directly and you use a group level cluster for multiple projects then there is a collision no ?
Basic use case is having a group with project A and B and cluster defined at group level.
I want to have domain.com for project A and sub.domain.com for project B, how would I do it if you make this change ?
Basic use case is having a group with project A and B and cluster defined at group level.
I want to have domain.com for project A and sub.domain.com for project B, how would I do it if you make this change ?
@morsok at the moment there isn't really any good ways to do what you're describing since this domain setting is only a base domain at present. So no matter what happens you always end up with the first part of your domain name being the project name.
@DylanGriffith I cheated a bit and modified the auto devops script to use the domains the way I want it on each projects, I guess the issue you linked is what I need to watch for thank you.
Should we generalize and start calling this the KUBE_INGRESS_HOSTNAME ? It should be applicable to users who have a cluster but use something other than Auto DevOps.
1a. Could we call the field "Base domain" ? Given we call it Base Domain in Auto DevOps docs and we also ask users to consider that domain to be wildcard *.domain.com to the Ingress IP in Ingress IP Address help text.
1b. Also, I wonder if the help text should be something like:
Specifying a base domain will allow you to use Auto Review apps and Auto Deploy stages for Auto Devops. The domain should have a wildcard DNS configured to the Ingress IP Address below. Alternatively, 11.11.11.11.nip.io can be used instead of a custom domain. More information
Regarding the documentation, I think we would need to update the docs. We should add information about the base domain to https://docs.gitlab.com/ee/user/project/clusters/index.html and then link to it from the auto devops page. I think the More information link should go to the cluster docs that talks about base domain.
This sounds like a technical challenge. Do you foresee any user-facing component to the migration? Just want to make sure
Do we know what happens when there is a domain set at the instance level and the project level?
For this issue, I would assume that the instance level domin is only used if there is no domain set at the project level.
But this also begs the question of what will happen if there are multiple instance clusters and therefore multiple domains. It doesnt really make sense with the current implication that they will be used for every project...
Shouldn't it be tied with which cluster actually gets used? I.e. whenever cluster X is chosen to pass to CI, then its base domain gets sent with the creds.
Do we know what happens when there is a domain set at the instance level and the project level?
For this issue, I would assume that the instance level domin is only used if there is no domain set at the project level.
@tauriedavis Yes. If the project does not have a domain specified, the instance one will be used.
Are we accounting for the possibility that someone configures ingress manually outside of our gitlab managed apps, and thus the base domain shouldn't be disabled?
Are we accounting for the possibility that someone configures ingress manually outside of our gitlab managed apps, and thus the base domain shouldn't be disabled?
Yes, I would think so. cc @mayra-cabrera I can add this to the issue description but now I'm also curious how we show ingress if they installed it manually outside of GitLab.
Above, I proposed a new deployment variable instead - KUBE_INGRESS_HOSTNAME. (actually KUBE_INGRESS_BASE_DOMAIN is better). Reasoning: one can use our Kubernetes integration and Ingress and not use Auto DevOps.
Above, I proposed a new deployment variable instead - KUBE_INGRESS_HOSTNAME. (actually KUBE_INGRESS_BASE_DOMAIN is better).
I like the name and I think it makes sense. But this will imply to maintain two variables AUTO_DEVOPS_DOMAIN (as legacy) and KUBE_INGRESS_HOSTNAME, so the change is compatible with old releases.
I like the name and I think it makes sense. But this will imply to maintain two variables AUTO_DEVOPS_DOMAIN (as legacy) and KUBE_INGRESS_HOSTNAME, so the change is compatible with old releases.
It would be nice to consider an approach that allows us to deprecate this in 12.0. What would happen if we stopped passing this variable into the CI template in 12.0? Basically anybody that forked the template would have failing deployments and need to manually set the env var AUTO_DEVOPS_DOMAIN or they'd need to update their CI YML. I think this is probably acceptable. Are there any other breaking changes if we remove support for this in 12.0?
Would it make sense to leverage Project#deployment_platform ? That way we can return the cluster's base domain as a deployment variable of the return deployment_platform
I don't think we need to worry about this as part of this issue. The change in the mockup was actually introduced in a separate issue (I think maybe when we were cleaning up the application design but I cant remember for sure) but didn't make it to implementation in time so it was cut. The idea is that the note isn't really necessary after the app is installed, and the note should be presented as an informational alert. The warning is almost an exact duplication of the help text below the IP address and with so much text shown, we saw that users just ignore all of it so the "warning" was removed.
Yes, I would think so. cc @mayra-cabrera I can add this to the issue description but now I'm also curious how we show ingress if they installed it manually outside of GitLab.
Are we accounting for the possibility that someone configures ingress manually outside of our gitlab managed apps, and thus the base domain shouldn't be disabled?
I think it is currently possible for a user to setup Auto Devops without installing GitLab managed app's Ingress, but rather they deploy their own ingress controller to the cluster. This is probably because we don't have ability to configure the nginx controller.
So yes, if we want to maintain the current situation AFAIK, we should allow cluster base domain to be set even though GitLab managed app helm and ingress is not installed.
Regarding the documentation, I think we would need to update the docs. We should add information about the base domain to https://docs.gitlab.com/ee/user/project/clusters/index.html and then link to it from the auto devops page. I think the More information link should go to the cluster docs that talks about base domain.
@danielgruesso, @tauriedavis would it work for you if the following transition is done through a hard refresh?
Without IP
With IP assigned
Meaning the user will install ingress, wait for the IP to be assigned and then refresh the page to see the changes in the "Base domain" text.
I wanted to mimic the behavior of the IP transition on the Ingress row, in which the transition is automatically handled by FE so there's no need to refresh the page:
Without IP
With IP assigned
But the cluster form is handled by rails and not by vue. If we want an automatic transition, like the ones we have on the applications table, I'll need FE help for it
I don't think this would be too difficult. We do something similar in the repository settings page where all of the toggles are governed by Vue, but when toggling certain items it would "reach outside" the Vue component to show or hide some extra settings elsewhere on the page. This would use the same method to update the description text.
Unrelated to this, but I never liked the use of ? in the text box of the ingress app when the IP address assignment is pending. Shouldn't we include one of those loading spinners instead?
I'm not 100% certain I'd be able to finish this before heading off to paternity leave, but I can try. @jerasmus would you be able to work on this in my absence?
Otherwise, I will be back on Mar 4th for the %11.10 release cycle if you wanted to open a separate follow-up issue.
@mikegreiling yeah sure. It might be a good idea to create a follow-up issue just in case it ends up not making it in time for %11.8, in which case I'll pick it up in %11.9
I'm not sure if this is the right place for this, but if I attempt to set a group-level devops domain with the tld ".online" it fails with no further error, and all of my deployments that worked a week ago stop working.
I'm not sure if this is the right place for this, but if I attempt to set a group-level devops domain with the tld ".online" it fails with no further error, and all of my deployments that worked a week ago stop working.