I created a configuration repository named ‘k8s’ in the ‘bioman’ group (with private visibility) and another one with public visibility (in case the project visibility would be an issue)
I tried to replace the project_id with the numeric ID for the project, with or without quotes, but no luck at all.
The weird part, is that the agent configuration and project manifest are in the same repository. If i update the agent config.yaml, then the kubernetes agent properly reload config but still can’t find the project with above error.
// getProjectInfo returns an error with code Unavailable if there was a retriable error.
func (s *server) getProjectInfo(ctx context.Context, log *zap.Logger, rpcApi modserver.RpcApi, agentId int64,
agentToken api.AgentToken, projectId string) (*api.ProjectInfo, error) {
projectInfo, err := s.projectInfoClient.GetProjectInfo(ctx, agentToken, projectId)
switch {
case err == nil:
return projectInfo, nil
case errors.Is(err, context.Canceled):
err = status.Error(codes.Canceled, err.Error())
case errors.Is(err, context.DeadlineExceeded):
err = status.Error(codes.DeadlineExceeded, err.Error())
case gitlab.IsForbidden(err):
err = status.Error(codes.PermissionDenied, "forbidden")
case gitlab.IsUnauthorized(err):
err = status.Error(codes.Unauthenticated, "unauthenticated")
case gitlab.IsNotFound(err):
err = status.Error(codes.NotFound, "project not found")
default:
rpcApi.HandleProcessingError(log, agentId, "GetProjectInfo()", err)
err = status.Error(codes.Unavailable, "unavailable")
}
return nil, err
it looks like, authentication and connectivity to kas are OK, but for some reason it can’t found the project (which is the same as the agent configuration repository, and kas found it properly)
Is there anything to enable for the project to be visible by kas/agentk ?
Hi, I have exactly the same issue.
I know in release notes it says that kubernetes agent is now available in community edition but maybe it’s not the case for all of it’s functionality? The documentation says that this feature is apparently premium. I have no idea if that’s how it works or is that documentation issue.
In any case the error isn’t very descriptive and the additional debug logs provide no info.
Yep i saw this but version history at top of the page say :
Version history
Introduced in GitLab Premium 13.7.
Introduced in GitLab 13.11, the Kubernetes Agent became available on GitLab.com.
Introduced in GitLab 14.0, the resource_inclusions and resource_exclusions attributes were removed and reconcile_timeout, dry_run_strategy, prune, prune_timeout, prune_propagation_policy, and inventory_policy attributes were added.
The ci_access attribute was introduced in GitLab 14.3.
The GitLab Kubernetes Agent was moved to GitLab Free in 14.5.
So my thought was the premium part was a mistake in the documentation, because no other way to use the gitlab agent is documented anywhere.
Well you can also use the agent for the CICD tunnel but it only worked for me in the same repo that the agent itself is in. Seems they weren’t well prepared to introduce this functionality to CE.
the worst part, is that you are most probably right, but the error message should say so. And honestly, if they release this agent just to allow us to execute kubectl command, then it does not worth it.
You should be able to set up the CI/CD tunnel with GitLab CE. We are in the process of discussing what other features will be available in GitLab Free and what remains Premium.
You are trying to use a feature that is currently in Premium.
I guess the issue here is that the error isn’t very descriptive. It says that the project is not found which suggests an issue with the setup. If it’s not possible to move the feature to community edition it would be nice if you could at least make the error more descriptive of what the issue actually is.
You should be able to set up the CI/CD tunnel with GitLab CE. We are in the process of discussing what other features will be available in GitLab Free and what remains Premium.
Hi, thanks for the reply, but as @jiji616 mention, CI/CD tunnel does not work for other repository than the configuration repository. So we basically end up with a broken feature:
Cannot sync manifest because free version, meaning i have to use a by project manifest folder
Cannot shared the agent configured in the configuration repository with other project
Meaning, in the current state the Gitlab Kubernetes Agent is useless …
you should think about rewrite your documentation. looking at
the title says “All tiers”. and then i followed all steps described in the page (create agent, write manifest, …). and now you write that the steps in this page are not available to “All tiers”.
as @Bioman wrote, i also think the agent is useless in core in the current state …
I was following the youtube video to install the kubernetes agent, and that results in the same problem.
You could add to the video description that the config.yaml file uses premium features.
With the only difference that in the last link, it tells that the GitOps Workflow is Premium only.
I don’t quiet understand what exactly comes with the All Tier Agent, especially considering it cannot even access my manifest repo, so I basically just get to see if the agent is connected with KAS in Gitlab and nothing more?
thanks for the feedback. We’ve discussed the problems from the initial question, and created a follow-up MR to make sure that the quickstart does not suggest to copy configuration when it is not needed to start using the GitLab Agent for Kubernetes. This removes the gitops config block which led to the questions.
There is more documentation work underway to clarify in this MR.
Sorry to bother you again, but how are we supposed to use configure the review, staging and production scopes for the clusters? How are we supposed to configure base domain?
I managed to setup a “Cluster management template project” and install the cert-manager, ingress and runner. But deploying apps with the Auto DevOps feature is broken.
Only the build job is created. I had to manually set the KUBE_INGRESS_BASE_DOMAIN and CI_KUBERNETES_ACTIVE so that the “Deploy” job would be created. But then it deploys the container with no cert-manager and in the “default” k8s namespace.
I really appreciate the help, but it just appears that this is not documented well, and we have to so somehow figure out how to use this setup.