run rancher:master-0f691dc70f86bbda3d6563af11779300a6191584-head in the single-install mode

The following line floods the log of the pod fleet-agent-7dfdfd5846-xjw96

time="2020-09-15T00:18:30Z" level=info msg="Waiting for secret fleet-clusters-system/c-09ea1d541bf704218ec6fc9ab2d60c0392543af636c1c3a90793946522685 for request-2vz49: secrets \"c-09ea1d541bf704218ec6fc9ab2d60c0392543af636c1c3a90793946522685\" not found"

gz#14319

The gitjob image v0.1.11 in 0.3.2 does not have a uid entry for 1000 in /etc/passwd This results in an error when the gitjob attempts to read the git repository.

~The workaround is to patch the gitjob deployment with a securityContext.runAsUser. It appears the nobody user works...~

  securityContext:
    runAsUser: 65534

Hi,

I'm having trouble using sops encrypted resources, getting the error from the fleet-agent container:

time="2020-11-05T18:25:04Z" level=info msg="getting history for release test-manifests-repo-fleet"
time="2020-11-05T18:25:04Z" level=error msg="error syncing 'cluster-stores-test-01-83b14484851f/test-manifests-repo-fleet': handler bundle-deploy: failed to decrypt with sops: Error getting data key: 0 successful groups required, got 0, requeuing"

I have this project installed on the agent cluster - https://github.com/isindir/sops-secrets-operator The idea is that the client / leaf cluster will decrypt (sops/kms) and generate the real secrets.

I take it fleet is also trying to do this, can you advise on how I can either configure fleet agent with the sops details or bypass sops processing by fleet and allow the client sops operator to handle?

Many Thanks

gz#15522

Fixes https://github.com/rancher/fleet/issues/144

Ignores sops related resources (allow downstream to handle)

Currently there is no way to configure sops via fleet (to pass in cloud KMS details) so would be good to allow downstream to handle, e.g. with https://github.com/isindir/sops-secrets-operator

I currently have my fleet-agent in state ErrApplied with the following reason:

another operation (install/upgrade/rollback) is in progress.

I had two fleet-agents under "Installed Apps": One in ns cattle-fleet-system and the other in fleet-system

Not sure how I came to that state, but I recently upgraded from Rancher 2.5.11 to 2.6.2.

The app in cattle-fleet-system was in status Pending-Upgrade

I deleted both apps and made an "upgrade" of fleet app on the local cluster. The fleet-agent seems now properly deployed

Hello,

When we proceed to an update of Rancher from 2.6.3 to 2.6.4 (so upgrade fleet to 0.3.9), we faced an issue regarding Fleet. Everything was fine on 2.6.3 but since we proceeded to the update, we are facing this issue. Here is the message we have of every GitRepo:

git ls-remote ssh://[email protected]:8888/PP0/mygit.git refs/heads/master error: exit status 128, detail: Unable to negotiate with x.x.x.x port 8888: no matching host key type found. Their offer: ssh-rsa
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Regards

The cleanup loop in fleet-agent isn't able to properly identify releases with bundles. For a given release, it looks for the bundle deployment associated to that release. If the release has a different name than fleet-agent expects (based on the bundle deployment) then fleet-agent deletes the release.

The problem is that then a release with the exact same name is created and the next time the cleanup loop runs, fleet-agent will delete the release again.

For example, a bundle deployment with name mcc-anupamafinalrcrke2-managed-system-upgrade creates a release with name mcc-anupamafinalrcrke2-managed-system-upgrade-c-407d2.

It seems that this function should look at status.release as well when trying to determine the name of the release from a bundle deployment.

Fix #699 Fix #899

This commit fixes an issue stopping versions and repos in Helm specs from being overridden in target customizations. It applies root repos and versions to customizations where appropriate to allow targets to properly resolve the correct target.

Test

To test this pull request, I used the following configurations: https://raw.githubusercontent.com/romejoe/fleet-test/main/multi-chart-test/fleet.yaml https://raw.githubusercontent.com/romejoe/fleet-test/main/version-test/fleet-config/fleet.yaml

The first test verifies that if the entire helm reference(repo, chart and version) are specified in a target customization, the proper chart is deployed to those targets.

The second test verifies that if only a version is specified, the updated version will be used. It also verifies that if the chart is overridden, the appropriate chart is still used.

Additional Information

Tradeoff

The only potential trade off is that if the user specifies a repo, chart and version in the root helm spec and then only overrides the chart property in a customization, the target customization will treat the chart as a relative path. The only time this could raise an issue is if the user changes the chart in the customization with the intent of selecting a different chart within the same repo. This is probably out of scope though. The user is still able to do that, they just have to supply at least a repo or version as well in the customization.

Now that rancher/fleet#325 and rancher/fleet#152 are marked as resolved, would this be possible to achieve for non-helm-based resources:

we are adding a series of ExternalSecrets on each new cluster that is spun up. Unfortunately we have not yet found a way to register new cluster in hashicorp vault, that remains a manual step, but we would like for the externalSecrets to be formed properly to reflect the cluster and the role names that are based on cluster name.

so essentualy, we need to concatenate string with value from cluster-display-name label, such as - this is PSEUDO-CODE-EXAMPLE not intended to work: I cluster name is:

global: 
  fleet: 
    clusterLabels.management.cattle.io/cluster-display-name: gke_some-cluster-external

and I want to add something like "-role" to the cluster name as a value to a helm attribute:

apiVersion: 'kubernetes-client.io/v1'
kind: ExternalSecret
metadata:
  name: jaeger-operator-jaeger
spec:
  backendType: vault
  vaultMountPoint: $(global.fleet.clusterLabels.management.cattle.io/cluster-display-name)-external-secrets
  vaultRole: $(global.fleet.clusterLabels.management.cattle.io/cluster-display-name)-role
  kvVersion: 2
  data:
  - name: ES_USERNAME
    key: infra-secrets/data/elastic-cloud
    property: ES_USERNAME

to achieve something like this as a final result that gets applied to the cluster (see vaultMountPoint and vaultRole keys ):

apiVersion: 'kubernetes-client.io/v1'
kind: ExternalSecret
metadata:
  name: jaeger-operator-jaeger
spec:
  backendType: vault
  vaultMountPoint: gke_some-cluster-external-secrets
  vaultRole: gke_some-cluster-role
  kvVersion: 2
  data:
  - name: ES_USERNAME
    key: infra-secrets/data/elastic-cloud
    property: ES_USERNAME

if i deploy the helm chart https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack the included prometheus operator install two statefulsets. after installing we see this

cluster-79fd2a35037e   16/17           2/2           xyz      2021-04-07T08:36:12Z   Modified(1) [Bundle mo-lpg-stack]; statefulset.apps mo-logging-monitoring/alertmanager-mo-lpg-stack-kube-promethe-alertmanager extra; statefulset.apps mo-logging-monitoring/prometheus-mo-lpg-stack-kube-promethe-prometheus extra
cluster-86aff2d3b822   16/17           2/2           xyz      2021-04-07T08:29:04Z   Modified(1) [Bundle mo-lpg-stack]; statefulset.apps mo-logging-monitoring/alertmanager-mo-lpg-stack-kube-promethe-alertmanager extra; statefulset.apps mo-logging-monitoring/prometheus-mo-lpg-stack-kube-promethe-prometheus extra

with diff patch we couldn't avoid this. the bundlestate looks like this:

    - bundleState: Modified
      modifiedStatus:
      - apiVersion: apps/v1
        delete: true
        kind: StatefulSet
        name: alertmanager-mo-lpg-stack-kube-promethe-alertmanager
        namespace: mo-logging-monitoring
      - apiVersion: apps/v1
        delete: true
        kind: StatefulSet
        name: prometheus-mo-lpg-stack-kube-promethe-prometheus
        namespace: mo-logging-monitoring
      name: fleet-market-stage/cluster-f501e0eb409b

This PR introduces the ability for fleet.yaml's helm.values object to contain go template strings in either the keys or values. The context of the go template also includes the cluster labels (for convenient migration from the existing global.fleet.clusterLabels.FOO users.

Cluster specific template variables can be added to Cluster CR under a new optional key in spec.templateContext

Related issues/PRs

• rancher/fleet#507 but adds the per-cluster custom template context
• rancher/fleet#375
• rancher/fleet#355

Bumps bci/bci-base from 15.4.27.14.23 to 15.4.27.14.26.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps bci/golang from 1.19-18.50 to 1.19-19.8.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps github.com/go-git/go-billy/v5 from 5.3.1 to 5.4.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Is there an existing issue for this?

• [X] I have searched the existing issues

Current Behavior

Currently using fleet gitops pipeline for our organization project. I think fleet GitHub repo resource will sync with cluster state at some interval of time in day to keep the environment similar. But in our use cases we want to sync the fleet created resources with cluster after some interval of time. like 2 hours or 4 hours through yaml file. We are creating all fleet resources through login into rancher dashboard on continuous delivery option. Hence we are not getting the sync option to apply after 2 hours or 4 hours. After creation force update option will be there but we wanted to execute through yaml and after interval of time.

Please help

Is there way to do force update kind of cron job defining in fleet yaml file.

Expected Behavior

There has to yaml file definition to force update

Steps To Reproduce

n/a

Environment

- Architecture:
- Fleet Version:
- Cluster:
  - Provider:
  - Options:
  - Kubernetes Version:

Logs

n/a

Anything else?

n/a

Bumps sigs.k8s.io/cli-utils from 0.33.0 to 0.34.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps sigs.k8s.io/controller-runtime from 0.12.3 to 0.14.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.