flux-subsystem-argo / flamingo Goto Github PK

Hi, trying to get some idea on proper Flamingo usage for our use-case, but stuck in the beginning.
I have the next basic file structure. And using kustomize overlays to get code as dry as possible

├── infrastructure
│   ├── base
│   ├── development
│   ├── etc
│   └── [etc]
└── apps/etc

in base folder I have keda helmrelease.yaml

apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: keda
spec:
  interval: 24h
  chart:
    spec:
      chart: keda
      version: "2.7.2"
      sourceRef:
        kind: HelmRepository
        name: kedacore
        namespace: flux-system

and kustomization.yaml

resources:
  - helmrelease.yaml

In development I have only kustomization.yaml

namespace: operators
resources:
  - ../../base/keda

I have install Argo with FSA and created the next application config:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: keda
  namespace: argocd
spec:
  destination:
    namespace: operators
    server: https://kubernetes.default.svc
  project: default
  source:
    path: infrastructure/development/keda
    repoURL: https://github.com/org/repo
    targetRevision: HEAD
  syncPolicy:
    syncOptions:
    - ApplyOutOfSyncOnly=true
    - FluxSubsystem=true

As a result I have application created, but no dependencies (even bare helmrelease) present.

I want to have some object tree to be present. What am I doing wrong?

Trying to poke around with flux and argocd as both are good tools. Thanks for this effort!

kustomize build https://github.com/flux-subsystem-argo/flamingo//release\?ref\=v2.5.16-fl.3-main-c4ce7dcc
Error: git cmd = '/usr/bin/git fetch --depth=1 origin v2.5.16-fl.3-main-c4ce7dcc': exit status 128

but kz build https://github.com/flux-subsystem-argo/flamingo//release\?ref\=v2.6.7-fl.4-main-c4ce7dcc works..

is it an explicit mapping from flamingo to argo version? ie 2.5 must have flamingo 2.5?

Great work. much appreciated.

• There is an assumption that argocd is already installed in the namespace argocd
  • if not installed; maybe point them to https://argo-cd.readthedocs.io/en/stable/getting_started/
• The bootstrap heredoc points to your github repo

Hi!

I'm working on FSA+tf-controller POC now, and have noticed some unexpected behaviour. Will appreciate your help!

1. I have deployed ArgoCD Application infra with finalizers set, and Kustomization object was reconciled:

[
   {
      "group":"kustomize.toolkit.fluxcd.io",
      "health":{
         "message":"ReconciliationSucceeded - Applied revision: poc-1/46ca9138db9a958e9251f951f4168a0e21ef396b",
         "status":"Healthy"
      },
      "kind":"Kustomization",
      "name":"infra",
      "namespace":"infra",
      "status":"Synced",
      "version":"v1beta2"
   },
   {
      "group":"source.toolkit.fluxcd.io",
      "health":{
         "message":"Succeeded - stored artifact for revision 'poc-1/46ca9138db9a958e9251f951f4168a0e21ef396b'",
         "status":"Healthy"
      },
      "kind":"GitRepository",
      "name":"infra",
      "namespace":"infra",
      "status":"Synced",
      "version":"v1beta2"
   }
]

kubectl -n argocd get app infra -o jsonpath="{.metadata.finalizers}"
["resources-finalizer.argocd.argoproj.io"]

If I delete the Kustomization object, all related resources are removed. But destroying the Application didn't work out. In the controller logs I see:

level=info msg="Deleting resources" application=infra
level=info msg="Deleting application's resources with Foreground propagation policy" application=infra
level=info msg="Successfully deleted 0 resources" application=infra

So only the Application was deleted.

2. Also, if you check the Application resources list, there is a GitRepository what is not declared anywhere - there is no such file in the repo that ArgoCD is looking at. In the configuration I reference to another GitRepository object with is created by another ArgoCD Application, but they both are equal. Is is possible that FSA creates this object?

kubectl get gitrepositories -A                                      
NAMESPACE   NAME                URL                                                  AGE   READY   STATUS
infra       bootstrap           https://github.com/masterpointio/tf-controller-poc   20h   True    stored artifact for revision 'poc-1/46ca9138db9a958e9251f951f4168a0e21ef396b'
infra       infra               https://github.com/masterpointio/tf-controller-poc   33m   True    stored artifact for revision 'poc-1/46ca9138db9a958e9251f951f4168a0e21ef396b'

Thanks in advance!

Hi,
Where can I find the recommendations of install sequences of flux2, argocd and flamingo for:

• new clusters
• clusters that already have flux2 and we want to deploy flamingo+argo?
  Also, are flux v2.1.x+ CRDs supported?
  Thanks

I've followed the instructions here https://www.weave.works/blog/flamingo-expand-argo-cd-with-flux

For argocd version 2.4.15 (helm chart 5.6.1).

Since the version stated in the documentation is not available.

Now argocd-server pod crash loops.

Error: unknown command "/usr/local/bin/argocd-server" for "argocd-server"
Run 'argocd-server --help' for usage.

Image
ghcr.io/flux-subsystem-argo/fsa/argocd:v2.4.12-fl.2-main-d68e6cb8

This ticket is to track multi-cluster support for Flamingo.

It is the autonomous Flux multi-clusters with Flamingo as UI.
This architecture does not use the Flux push model ({ks, hr}.kubeConfig) as the current Flamingo implementation cannot use information of workloads from this data path. However, the combination of ArgoCD (fake) push / Flux pull model (remote loopback reconciliation) worked.

[ArgoCD -> cluster config -> a leaf cluster -> Flux KS/HR -> workloads]

• CLI implementation flamingo add cluster
• CLI implementation flamingo gen-app
• #57
• CLI implementation flamingo install --core Don't need to implement
• read kubeConfig secretRef from a KS / Helm Release to generate Flamingo cluster definition. This would not work as there is no connection between [ArgoCD + KS / Helm on host] and [workloads on leaf clusters]. We would need a simpler model to define clusters.

Hi,

We are facing issues when using FSA with ArgoCD. Upon creating ArgoCD application thru UI with a private github repo, the GitRepository instance shows error that its not able to clone the repo.
How to pass the github credentials in case of FSA when we select to "User Flux subsystem" and "auto-create Flux resources"?

I have to apologize in advance for such a general issue with such a general question.

Background context:

My team has recently modified an existing ArgoCD deployment to use flamingo (v2.7.2-fl.6-main-b1742696). We have installed flux to the flux-system namespace, and when trying to use any of the new flamingo sync options for a flux-operated Application, we encounter problems. When selecting the "Apply Out Of Sync Only", "Use Flux Subsystem", "Auto-Create Flux Resources" we have experienced frozen user interfaces, various UI errors, and when dropping "Apply Out of Sync Only" in one experiment where several resources had been created, we experience a "no-op" (nothing happens at all). Using a network observation tool we have not uncovered any networking issues between ArgoCD and Flux. We have also not been able to detect any Events or error messages in ArgoCD pod/container logs.

So, we have a problem. Any hints on where to look to find what the specific problem is?

I am trying the demo terraform deployment using the instructions provided in the docs. While everything works as expected with the Terraform resource being reconciled by the tf-controller, the ArgoCD UI does not show me any of the (Kustomize) generated resources which in this case would be the resources created by the GitRepo object and the Terrafrom resource.
This is my view

I see the Kustomize resource icon which means Argo recognizes the flux objects but not the terraform resource type.

Hi,
I'm testing flamingo and there are some pieces missing in my mind.

Is it possible to list objects created by Helm Operator?

I defined 3 objects: HelmRepository, HelmRelease, and Application (for flux).

This will make Flux deploy the app defined in the HelmRelease and the Application will make Argo list the application. But for some reason, all those created objects are not listed in the ArgoCD application. Am I missing something? Do I need to define some labels or annotations in created objects?

Another issue is argo is only listing applications defined on argocd namespace, but I guess it's something with the default config.

Here are the three files I'm defining:

apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: HelmRepository
metadata:
  name: podinfo
  namespace: argocd
spec:
  interval: 1m
  url: https://stefanprodan.github.io/podinfo

apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: podinfo
  namespace: argocd
spec:
  interval: 5m
  chart:
    spec:
      chart: podinfo
      version: 6.1.5
      sourceRef:
        kind: HelmRepository
        name: podinfo
        namespace: argocd
      interval: 1m
  values:
    replicaCount: 2

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: podinfo
  namespace: argocd
spec:
  destination:
    namespace: argocd
    server: https://kubernetes.default.svc
  project: default
  source:
    path: ./demo/artifacts/flux-apps/podinfo
    repoURL: https://github.com/drazul/flamingo-test
    targetRevision: main
  syncPolicy:
    syncOptions:
      - ApplyOutOfSyncOnly=true
      - FluxSubsystem=true

Given the GA of graviton instances on AWS and other major cloud providers (i.e. Oracle), is there a consideration for releasing multiplatform images (like ArgoCD does)?

Atm running ghcr.io/flux-subsystem-argo/fsa/argocd:v2.8.0-rc6-fl.15-main-da46678f on arm instance gives following result:

exec /usr/bin/tini: exec format error

Hi Team,

Great work !
Wanted to check if FSA is production ready ? we are very much interested in using FSA + Weave TF controller but I see the git releases have "pre-release" tag.

Best regards.

Hi. I’m reading that Weaveworks, this project sponsor, is shutting down and had to lay off its employees in Dec 2023. Or, at least, most of them. How’s this reflect on the future of the Flamingo project? Can we still count on it being actively supported. Thank you.

I have a Helm chart that only installs ClusterIssuers. A set of Custom Resource Objects.

Flux does a great job of installing the objects, but the Helm Release objects do not show up in the ArgoUI.

Combining this with: #16, it seems that using FSA where Argo is the front end and Flux is the back, just doesn't seem to work great.

As of right now I'm guessing this is because the Flamingo patches don't handle CRDs and their respective objects?

I see that the status field of an argo application is where objects are tracked.

Hi, great project! Is it ready for use in production or is there a milestone overview somewhere?

Looking at the deployment files, it appears you're using a different image for ArgoCD.
What changes did you make to that image?

Hey there

Any intentions to publish flamingo with ArgoCD 2.8 (currently 2.8.4) baked in?
I saw that there is a pre-release (https://github.com/flux-subsystem-argo/flamingo/releases/tag/v2.8.0-rc6-fl.15-main-da46678f).

We installed Flamingo to get the best of both worlds. Particularly the ability to use Helm's lookup function from Argo.

Unfortunately, Argo still attempts to template the helm chart and complains that the lookup object is missing and fails.

I would have thought Argo would skip templating and directly created Flux objects to do the work.

But no.

WIP: https://github.com/flux-subsystem-argo/flamingo/blob/main/ARCHITECTURE.md

Hi,

Hopefully a quick question if someone knows.

In the Flamingo source at:

it suggests that the label to identify a tenant is limited to the namespace name:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  labels:
    toolkit.fluxcd.io/tenant: %s
  name: flamingo-reconciler
  namespace: %s
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: argocd-application-controller
  namespace: %s

However, Flux multi-tenancy doesn't limit a tenant to a single namespace:

https://fluxcd.io/flux/cmd/flux_create_tenant/

e.g. as per the doc, you can define --with-namespace multiple times which makes sense to me where a team may be allocated more than one namespace in a k8s (shared) cluster:

 # Generate tenant namespaces and role bindings in YAML format
 flux create tenant dev-team \
   --with-namespace=frontend \
   --with-namespace=backend \
   --export > dev-team.yaml

Is this difference between Flamingo tenancy and Flux intended? i..e would I have to work with a tenant = namespace if I wanted to use the Flux subsystem?

thanks for this nice work ;)
for helm-charts it is working very good

we have a kustomization but the resources not showed up in the ui - is this expected ? did i need to setup something more ?

---
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: crossplane-provider-aws
  namespace: argocd
spec:
  destination:
    namespace: crossplane-system
    server: https://kubernetes.default.svc
  project: default
  source:
    path: ./
    repoURL: flux://loopback
    targetRevision: HEAD
  syncPolicy:
    syncOptions:
      - ApplyOutOfSyncOnly=true

  inventory:
    entries:
      - id: _crossplane-aws_pkg.crossplane.io_ControllerConfig
        v: v1alpha1
      - id: _crossplane-aws_pkg.crossplane.io_Provider
        v: v1

Is it possible to change the deployment name from "demo" to something that sounds more production ready. Even if it is stable, it scares people.

Hey! I'm new to flamingo, and currently learn this tool.
I've noticed that there is a difference between the latest tags and releases versions. The latest tag value is v2.4.12-fl.2-main-d68e6cb8, meanwhile the latest release version is lower - v2.2.8-fl.1-main-305be5e6.
Is that expected? What version is recommended to use? Thanks in advance!

I could not find any open source license for this project. Flux2 has 'Apache-2.0' license on its Github page.

Could you please clarify? Wondering if it would be ok to use this open source project ...

The demo solution showcases the Flamingo workflow and abilities, but it is pretty hard to figure out what needs to be changed if one want to use Flamingo in real life on an existing cluster.

It will be helpful to have instructions on how to setup Flamingo without the demo, as in flux bootstrap as opposed to flux install for example.

Some questions this might answer:

• What are the metadata.weave.works/flamingo-fsa-demo, metadata.weave.works/flamingo-fsa-installation, metadata.weave.works/flamingo-default-app annotations for? are they a must?
• It seems all that is needed is to install the clis, bootstrap flux, and install argo through the https://github.com/flux-subsystem-argo/flamingo/blob/main/release/kustomization.yaml kustomization. Is that the case?

I believe this will make Flamingo more approachable.

I see https://www.weave.works/blog/flamingo-expand-argo-cd-with-flux has some instructions on the bottom. Maybe this should be incorporated into the readme as well.

Installing on debian image without sudo fails with error.
This seems to be due to

        eval "sudo ${CMD_MOVE}"

Is there a way to markup argocd applications to generate kustomize.toolkit.fluxcd.io manifests with fields like dependsOn and healthChecks?

Hi,

When using FSA, a GitRepository resource with same ArgoCd application name will be created, while can't find a way to include GitRepository private ssh credential reference to Argo Kind Application.

May I know is there a way to setup global sourceref for all GitRepository resources in a specific namespace?

Thanks.

I feel there's a lack of documentation on how to actually use Flamingo. That may be why I'm currently unable to get Flamingo to work as below.

I want to create an Argo application that creates a Flux HelmRelease.

Really I just want the full Helm functionality that Flux has but we're heavily invested in Argo, so I want it to be as transparent as possible.

I create the following Argo application...

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: cert-issuers
  namespace: argo-cd
spec:
  syncPolicy:
    syncOptions:
    - ApplyOutOfSyncOnly=true
    - FluxSubsystem=true
    - AutoCreateFluxResources=true
    automated:
      prune: true
      selfHeal: true
  project: ""
  destination:
    namespace: cert-manager
    server: https://kubernetes.default.svc
  source:
    path: ./
    repoURL: https://<redacted-repo-url>/cert-issuers.git
    targetRevision: HEAD
    helm:
      releaseName: cert-issuers

Yet, I get a

apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
kind: Kustomization
...
...

object.

Also, I'm not sure how to pass repo credentials specifications through to the created Flux objects.

I can give creds to the repo via the command line, but they just get wiped out by the created git repo resource.

Ideally the Flux repo would be able to pull creds from Argo, but it doesn't seem to do much in this regard.

And again, I don't know where to look for docs on these relationships.

Hi,
Not sure if this is the correct place to report, but I'm trying to get the deployment.yaml file for FSA in the following way:

https://github.com/flux-subsystem-argo/flamingo//release?ref=v2.8.0-rc2-fl.15-main-ed1f41f7

But, I'm getting 404 in any browser, I've also tried with different versions and I got the same result, in the installation section the following kubectl commands are written:

export VERSION=v2.8.0-rc2-fl.15-main-ed1f41f7
kubectl create ns argocd
kubectl -n argocd apply -k https://github.com/flux-subsystem-argo/flamingo//release?ref=${VERSION}

Kind Regards.
Max.

We have installed ArgCD with FSA on the Open Shift cluster. We created a project with Argo CD to create Terraform resources using Weave TF Controller.[https://github.com/prajyot-narulkar925/terraform-aws-ec2]. How can we provide the AWS Credentials for the terraform resource creation?

We are getting the below error in the pod.
Provider: no valid credential sources for Terraform AWS Provider found.\n\nPlease see https://registry.terraform.io/providers/hashicorp/aws\nfor more information about providing credentials.\n\nError: failed to refresh cached credentials, no EC2 IMDS role found, operation error ec2imds: GetMetadata, request send failed, Get "http://169.254.169.254/latest/meta-data/iam/security-credentials/\": dial tcp 169.254.169.254:80: i/o timeout\n\n\n

Appreciate any pointers on this.

Hi,

We use Flux v2.2.3 and Flamingo v0.8.2.

We only use helm.toolkit.fluxcd.io/v2beta2.

Previously, the HelmRelease displayed the state of the resources it created in the user interface, but now we only have the state of the HelmRelease.

I don't see anything relevant in the ArgoCD logs, everything seems to be going well.

Is this a bad configuration on our part or a new behaviour?

Regards,

Flux Subsystem for Argo already supports visualizing Terraform objects managed by https://github.com/weaveworks/tf-controller (to be clear this can be done with just Flux + weaveworks/tf-controller, and visualized with either FSA or any other supporting Flux UI). This benefits users who want to do Terraform + GitOps on Kubernetes without the requirement of subscribing to Terraform cloud.

However, Hashicorp cloud commercial customers are likely to prefer https://github.com/hashicorp/terraform-k8s over weaveworks/tf-controller, because it's certified for Hashicorp support, matches Hashicorp’s learning materials, etc. The subset of these users who are also Argo users could benefit from FSA additional support for visualizing Terraform objects managed by hashicorp/terraform-k8s just as it does for the same objects when managed by weaveworks/tf-controller.

I've followed the instructions in readme. Everything went smoothly, but the podinfo-hr seems to be stuck in "progressing" state.

$ kubectl describe applications -n argocd  podinfo-hr
---
Name:         podinfo-hr
Namespace:    argocd
Labels:       app.kubernetes.io/managed-by=flamingo
              flamingo/destination-namespace=podinfo-helm
              flamingo/source-type=HelmRepository
              flamingo/workload-name=podinfo
              flamingo/workload-type=HelmRelease
Annotations:  weave.gitops.flamingo/base-url: http://localhost:9001
              weave.gitops.flamingo/cluster-name: Default
API Version:  argoproj.io/v1alpha1
Kind:         Application
Metadata:
  Creation Timestamp:  2024-01-31T17:37:53Z
  Generation:          16
  Resource Version:    4646
  UID:                 d98adc9e-fa49-4159-870b-2c1891721479
Spec:
  Destination:
    Namespace:  podinfo-helm
    Server:     https://kubernetes.default.svc
  Project:      default
  Source:
    Chart:  podinfo
    Helm:
      Release Name:   podinfo
    Repo URL:         oci://ghcr.io/stefanprodan/charts
    Target Revision:  *
  Sync Policy:
    Sync Options:
      ApplyOutOfSyncOnly=true
      FluxSubsystem=true
Status:
  Controller Namespace:  argocd
  Health:
    Status:  Progressing
  History:
    Deploy Started At:  2024-01-31T17:43:12Z
    Deployed At:        2024-01-31T17:43:12Z
    Id:                 0
    Source:
      Chart:  podinfo
      Helm:
        Release Name:   podinfo
      Repo URL:         oci://ghcr.io/stefanprodan/charts
      Target Revision:  *
  Operation State:
    Finished At:  2024-01-31T17:43:12Z
    Message:      successfully synced (no more tasks)
    Operation:
      Initiated By:
        Username:  admin
      Retry:
      Sync:
        Revision:  *
        Sync Options:
          ApplyOutOfSyncOnly=true
          FluxSubsystem=true
        Sync Strategy:
          Hook:
    Phase:       Succeeded
    Started At:  2024-01-31T17:43:12Z
    Sync Result:
      Revision:  
      Source:
        Chart:  podinfo
        Helm:
          Release Name:   podinfo
        Repo URL:         oci://ghcr.io/stefanprodan/charts
        Target Revision:  *
  Reconciled At:          2024-01-31T18:01:30Z
  Resources:
    Group:  helm.toolkit.fluxcd.io
    Health:
      Message:  Helm install succeeded for release podinfo-helm/podinfo-helm-podinfo.v1 with chart [email protected]
      Status:   Healthy
    Kind:       HelmRelease
    Name:       podinfo
    Namespace:  podinfo-helm
    Status:     Synced
    Version:    v2beta1
    Group:      source.toolkit.fluxcd.io
    Health:
      Message:  Waiting for HelmRepository to reconcile ...
      Status:   Progressing
    Kind:       HelmRepository
    Name:       podinfo
    Namespace:  podinfo-helm
    Status:     Synced
    Version:    v1beta2
  Summary:
  Sync:
    Compared To:
      Destination:
        Namespace:  podinfo-helm
        Server:     https://kubernetes.default.svc
      Source:
        Chart:  podinfo
        Helm:
          Release Name:   podinfo
        Repo URL:         oci://ghcr.io/stefanprodan/charts
        Target Revision:  *
    Status:               Synced
Events:
  Type    Reason              Age   From                           Message
  ----    ------              ----  ----                           -------
  Normal  ResourceUpdated     24m   argocd-application-controller  Updated sync status:  -> Synced
  Normal  ResourceUpdated     24m   argocd-application-controller  Updated health status:  -> Progressing
  Normal  OperationStarted    19m   argocd-server                  admin initiated sync to *
  Normal  OperationCompleted  19m   argocd-application-controller  Sync operation to  succeeded

Unsure if this is a bug or something I'm doing wrong. Any pointers appreciated.

I've installed Flamingo with the standard install command

flamingo install

I created an app using the Flamingo cli as follows:

flamingo generate-app --app-name=flux-helloworld-kustomize-ks ks/flux-helloworld-kustomize -N argocd -n flux-demo

I see the flamingo app (and associated flux kustomization) in the Flamingo UI. The Flamingo UI app delete button seems to work fine, however my use case is that I want to delete an app via the Flamingo cli.

However, when trying to delete it via the Flamingo cli, I get an app not found error.

% flamingo get -N argocd -n flux-demo   
NAMESPACE  APP-NS  APP                           FLUX-TYPE      SOURCE-TYPE    STATUS   MESSAGE
flux-demo  argocd  flux-helloworld-kustomize-ks  Kustomization  OCIRepository  Healthy  Applied revision: latest@sha256:a6e862eb ...

% flamingo delete flux-helloworld-kustomize-ks -N argocd -n flux-demo 
✗ applications.argoproj.io "flux-helloworld-kustomize-ks" not found

As I mention, deleting it from the UI works as expected, just the command line cli seemingly not working for the delete:

Is there something obvious I'm doing wrong here?

Feature Request

Summary

Flamingo currently lacks visibility into the suspension status of Kustomization or Helm Releases. This issue proposes enhancing Flamingo to reflect the suspension status in the user interface.

Details

The Flux CLI provides the ability to suspend and resume the automation of resources. When a Kustomization or Helm Release is in a suspended state, it is crucial for users to be aware of this status directly within the Flamingo UI.

Expected Behavior

Flamingo should visually communicate the suspension status of Kustomization or Helm Releases within the UI, making it clear when automation is temporarily halted.

Reference

For more information on the Flux CLI and resource suspension, please refer to the Flux documentation.

Environment

• Flamingo (FSA) version: [v2.8]

Hi,

The documentation at https://www.weave.works/blog/get-started-flamingo-flux-cd-subsystem-for-argo-cd suggests there is a --read-only-mode flag for the cli when installing it (in tenant/namespaced mode), but I don't see the flag actually available/referenced in the cli help (or when trying it):

flamingo install [--read-only-mode] [--dev --version=v2.8.3-dev]

I'd be keen to see such an option:

 % flamingo install --help
 
# Install the Flux Subsystem for Argo
flamingo install --version=v2.8.6

# Install the Flux Subsystem for Argo with the anonymous UI enabled
flamingo install --version=v2.8.6 --anonymous

Usage:
  flamingo install [flags]

Flags:
      --anonymous        enable anonymous UI
      --export           export manifests instead of installing
  -h, --help             help for install
      --mode string      installation mode [crds-only, all, tenant] (default "all")
  -v, --version string   version of Flamingo to install (default "v2.8.6")

Global Flags:
  -N, --app-ns string                  namespace where Flamingo and applications are located (default "argocd")
      --as string                      Username to impersonate for the operation. User could be a regular user or a service account in a namespace.
      --as-group stringArray           Group to impersonate for the operation, this flag can be repeated to specify multiple groups.
      --as-uid string                  UID to impersonate for the operation.
      --cache-dir string               Default cache directory (default "/Users/tr658049/.kube/cache")
      --certificate-authority string   Path to a cert file for the certificate authority
      --client-certificate string      Path to a client certificate file for TLS
      --client-key string              Path to a client key file for TLS
      --cluster string                 The name of the kubeconfig cluster to use
      --context string                 The name of the kubeconfig context to use
      --disable-compression            If true, opt-out of response compression for all requests to the server
      --insecure-skip-tls-verify       If true, the server's certificate will not be checked for validity. This will make your HTTPS connections insecure
      --kube-api-burst int             The maximum burst queries-per-second of requests sent to the Kubernetes API. (default 300)
      --kube-api-qps float32           The maximum queries-per-second of requests sent to the Kubernetes API. (default 50)
      --kubeconfig string              Path to the kubeconfig file to use for CLI requests.
  -n, --namespace string               If present, the namespace scope for this CLI request (default "flux-system")
      --server string                  The address and port of the Kubernetes API server
      --timeout duration               timeout for this operation (default 10m0s)
      --tls-server-name string         Server name to use for server certificate validation. If it is not provided, the hostname used to contact the server is used
      --token string                   Bearer token for authentication to the API server
      --user string                    The name of the kubeconfig user to use
      --verbose                        print generated objects

After setting this up, I portforwarded the argo server and I was surprised to see there was no authentication. Is this normal, if so shouldn't the instructions mentioning the login page be removed?