Some of the services are restricted on the corporate network for security purposes e.g. services that expose cluster info/data. There should be some kind of indication (widget) which could indicate that this service is network restricted so that the users are more aware about these services.

Helm Chart Versions should follow SemVer 2 standard. Versions should not have a "v" prefix. Helm Chart apiVersion: v2 will reject Charts if their Version field starts with "v". Helm v2 works better if the Version field does not have a "v" prefix.

This is strictly about the Chart version field. No comment on appVersion or GitHub release tag.

The helm chart does not deploy the custom resource definition.

Great app - considering to replace Homer. I would like to propose a differentiating feature when compared to Homer and similar apps that do not monitor the k8s control plane.

Currently it is necessary to add the forecastle.stakater.com/expose annotation to each ingress. This makes easy to forget adding new applications to forecastle. It also makes it similar to other apps where I have to manually update a list of apps.

I would like to add all ingresses by default so they show up in the dashboard - then I can later on do the tuning such as changing the icon. This way the list is guarantied to include all apps deployed in the cluster without admin intervention.

This might be implemented with an addByDefault Forecastle option which would default to False to follow the current implementation.

It should still be possible to exclude apps by explicitly setting forecastle.stakater.com/expose to False.

We should allow users to deploy multiple instances of Forecastle and label them.

This way they can create custom dashboards per team for example they can have the following dashboard running simultaneously:

• ProductTeam1: Jenkins(Namespace: tools), App1(Namespace: p1), App2(Namespace: p1)
• ProductTeam2: Jenkins(Namespace: tools), App1(Namespace: p2), App2(Namespace: p2)

Although we can restrict forecastle to watch in certain namespaces but this will give users more flexibility as to which app should be shown on which forecastle instance. An example would be running forecastle with a flag --instance-name devteam and have an annotation like forecastle.stakater.com/instance: devteam which can be added to the apps for devteam

Right now we assume that the ingress name is the same as the app name. We need to allow the user to be able to control application name.

Proposal
We can create an annotation that can be used for specifying the app's name. The default behavior would be the same. Annotation can be something like forecastle.stakater.com/appName.

Currently forecastle pod needs to be deleted in order for new apps to be listed; which is quite cumbersome and make forecastle bit less useful!

To start with each page refresh should fetch new list of apps to be listed; so, it doesn't need restart.

For prod environments I would like to have a theme/skin e.g. RED colored and GREEN for non-prod environments.

There's no parameter to define LoadBalancer type IP via HelmChart.
Ideally all basic parameters could be supported, see: https://github.com/k8s-at-home/charts/blob/master/templates/chart/values.yaml

We use Forecastle and really like it. I'm trying to convince other teams in our company to use it as well. It would be great to be able to display additional information on a registered app e.g. in a tool tip or something alike.

what
Display additional information for a registered app such as links to monitoring and tracing tools, maintainer, SLAs, image version and so on. This information could be displayed as tool tip or in an info panel.

why
Display all relevant info and links for an app in a central place (Single point of truth for all apps in a k8 cluster).

how
Additional info can be registered as a simple key/value list or an html snippet by the app. Forecastle then displays the provided data as a table in a tool tip or info panel. URLs are recognized based on regular expressions and automatically displayed as links.

Feature
Ability to change forecastle app root path

Use case
Serve several instances of forecastle under the same FQDN but through different paths.

Current issue
I have tried doing URL path rewrite through ingress controller, something like exposing one forecastle instance through example.com/firstinstace. When opening this URL in the browser, it tries some GETs of assets and favicon though the apps root URL example.com/ which leads to a broken page.
If the apps root could be changed, there would be no need to do a path rewrite.

How to
I don't understand react but I found this article https://skryvets.com/blog/2018/09/20/an-elegant-solution-of-deploying-react-app-into-a-subdirectory/ that explains the issue and how to solve it in the an-instruction-for-the-solution-with-base-url-element section.

As same app can be deployed in different namespaces so, to make it more understandable/readable/usable apps should be listed per namespace.

To start with we can have just one page with different sections per namespace. So, we can have a section template with header containing name of the namespace and the body listing the apps; just like we are showing right now.

Although forecastle supports displaying apps per namespace, sometimes its not ideal to have the namespace name as the group name for certain apps.

Proposal
We should have an annotation for overriding the group name e.g., namespace via annotation. The default behavior will be the same e.g., the namespace name will become the group name, but for overriding we can have an annotation like forecastle.stakater.com/groupName.

• requests and limits should be set as a best practice.
• define default values as to avoid breaking change.

Using stakater/forecastle:v1.0.54 docker image, the web page displays with header and footer, but the main panel just says:

Results couldn't be loaded due to an error

• There is nothing in the server logs to indicate an error.
• There is nothing in the web browser console.
• Viewing all requests in the browser development tools shows all requests returned with status 200.

This makes it very hard to debug.

My guess is that it is not finding any apps and is failing to display an empty list.

Here is the value set in the manifest:

forecastle.stakater.com/icon: https://github.com/stakater/ForecastleIcons/raw/master/kibana.png

And here is the content of apps.json we recieve:

[{"Name":"kibana","URL":"https://cp.lab187.k8syard.com/kibana/","Icon":"https"}]

Look the Icon value is wrong! Therefore the icon is not loaded as expected. Please add unit test for this.

Add support to watch all namespaces by default

Its quite misleading with hardcoded namespace name dev in the CRB

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: forecastle-cluster-ingress-role-binding
  labels:
    app: forecastle
    group: com.stakater.platform
    provider: stakater
    version: "0.0.17"
    chart: "forecastle-0.0.17"
    release: "RELEASE-NAME"
    heritage: "Tiller"
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: forecastle-cluster-ingress-role
subjects:
- kind: ServiceAccount
  name: forecastle
  namespace: dev

https://github.com/stakater/Forecastle/blob/master/deployments/kubernetes/forecastle.yaml#L98

Currently forecastle only picks apps and associates them with the first path in their ingress. We need to add functionality for forecastle to consider ingresses with multiple paths

You already allow the header colour to be changed but it would be great if there were a way to inject more CSS, either a URL to a file or ideally as part of the configmap

Hi!

I have deployed forecastle pretty much along the lines of the helm chart.
My config looks like this:

  config.yaml: |-
    headerBackground: "#3f51b5"
    headerForeground: "#ffffff"
    instanceName: "skr forecastle"
    title: Snyk Management Cluster
    crdEnabled: true
    namespaceSelector:
      any: true

I added a single ForecastleApp CRD to my cluster:

apiVersion: forecastle.stakater.com/v1alpha1
kind: ForecastleApp
metadata:
  name: argocd
spec:
  group: Command & Control
  icon: https://argoproj.github.io/static/argo-wheel.23b3ad84.png
  name: ArgoCD
  networkRestricted: false
  url: http://<redacted>

This app does not seem to get picked up, though. The only log lines from forecastle Pods are:

skr/forecastle-f4f54b4b4-6frnz[forecastle]: time="2020-04-01T11:56:46Z" level=info msg="Listening at port 3000" _source="Forecastle/forecastle.go:42"
skr/forecastle-f4f54b4b4-xh9wq[forecastle]: time="2020-04-01T11:56:54Z" level=info msg="Looking for forecastle apps in the following namespaces: []" _source="handlers/appsHandler.go:41"

Meanwhile /api/apps returns null, leading the frontend to just display "Results couldn't be loaded due to an error"

Any idea what I might be missing?

Release v1.1.0 is tagged last year https://github.com/stakater/Forecastle/releases/v1.1.0

The current version is v1.0.42. This is confusing a dependency tool we use into thinking the older release tagged as v1.1.0 is newer.

Thanks

Steps to Recreate:
Create a CustomResource which refers to a route that doesn't exist

apiVersion: forecastle.stakater.com/v1alpha1
kind: ForecastleApp
metadata:
  name: <TEST_NAME>
  namespace: <TEST_NAMESPACE>
spec:
  name: TestRoute
  group: Build
  icon: <ICON_URL>
  urlFrom:
    routeRef:
      name: some-app-route    # This doesn't exist in the namespace

Forecastle UI fails to load and shows the following error:
Results couldn't be loaded due to an error

Error from the pod:
error msg="An error occurred while looking for forceastle CRD apps: routes.route.openshift.io \"some-app-route\" not found" _source="filename/filename.go:22"

Expected Behavior:
If the route doesn't exist. Throw an error and ignore that particular CR and loads all the other valid CRs.

It would useful to be able to link to a group.

We're using Forecastle v1.0.68, everytime we try to apply the forecastle crd with spec.urlFrom.ingressRef.name: xxx, it gets ignored.

Attempt:

apiVersion: forecastle.stakater.com/v1alpha1
kind: ForecastleApp
metadata:
  name: "test-1"
  namespace: test
spec:
  name: "test-app"
  group: "test-group"
  icon: ""
  networkRestricted: false
  instance: "test1"
  urlFrom:
    ingressRef:
      name: "test-ingress"

After it gets applied:

apiVersion: forecastle.stakater.com/v1alpha1
kind: ForecastleApp
metadata:
  name: "test-1"
  namespace: test
spec:
  name: "test-app"
  group: "test-group"
  icon: ""
  networkRestricted: false
  instance: "test1"
  urlFrom:
    ingressRef:
      name: {}

Hello guys,

I am sorry to bother but I am trying out Forecastle in my EKS cluster but I am a bit confused.

I did use the vanilla manifests approach but when accessing the UI I get these logs:

time="0001-01-01T00:00:00Z" level=info msg="Listening at port 3000" _source="Forecastle/forecastle.go:40"

time="0001-01-01T00:00:00Z" level=info msg="Namespaces to look for forecastle apps: [stakater test-app-ingress]" _source="handlers/appsHandler.go:40"

time="0001-01-01T00:00:00Z" level=error msg="An error occurred while looking for forceastle appsingresses.extensions is forbidden: User \"system:serviceaccount:forecastle:forecastle\" cannot list resource \"ingresses\" in API group \"extensions\" in the namespace \"test-app-ingress\"" _source="handlers/appsHandler.go:44"

Am I missing anything?

regards,
Matteo

When Forecastle's configuration changes, it needs to be restarted to load the changes. I know Stakater's solution is Reloader, but Helm also has a solution, which is to annotate the Pod template with a checksum of the configuration.

Ideally, the Forecastle chart would do this automatically. At a minimum, the chart should allow for annotations of the Pod template much like it allows annotation of the Deployment itself.

I have several ingress configured as following :

  kind: Ingress
  metadata:
    name: alertmanager
    namespace: monitoring
    annotations:
      forecastle.stakater.com/expose: 'true'
      forecastle.stakater.com/icon: 'https://github.com/stakater/ForecastleIcons/raw/master/prometheus.png'
      kubernetes.io/ingress.class: internal
      nginx.ingress.kubernetes.io/force-ssl-redirect: 'true'
    labels:
      app: alertmanager
  spec:
    rules:
      - host: alertmanager.examples.com
        http:
          paths:
            - path: '/'
              backend:
                serviceName: alertmanager-main
                servicePort: web

Where servicePort is the label defined in the service.

what is happening

Forecastle is composing the uri like http://alertmanager.examples.comweb/.

how it should behave

it should ignore the servicePort param because the ingress expose them in 80/443 and compose the uri like http://alertmanager.examples.com

Forecastle is wonderful! It's a missing piece in the kubernetes ecosystem.

what

• Add support for the VirtualService CRD

why

• Forecastle doesn't discover annotations on VirtualService CRDs which are used instead of Ingress resources to configure routing to backend services

use-case

• We're moving microservices over to using istio for better tracing and telemetry, but still want to announce services to forecastle.

Since the page header is configurable, the page title should be configurable as well.

Hello,

First thanks for the app, it's very usefull for us.

We migrate our cluster to traefik CRDs ingressroute* and we saw that they aren't be supported.

It would be great to add this feature. We don't dev in go otherwise i would submit a PR

Thanks.
Chris

Please update your chart, right now it is not working with k8s 1.22 or newer:

https://blog.hycorve.com/migrating-from-ingress-networking-k8s-io-v1beta1-to-v1/

I have been running v1.0.62 fine for weeks, this morning when my pod restarted I started getting just 404 responses from the application. Looking at docker hub it appears someone pushed a new image to v1.0.62 yesterday so I think someone has pushed something which is broken?

Switching back to v1.0.61 or forward to v1.0.63 and it works fine again

As explained by @Nuru in another ticket:
I would also like to have the ability to explicitly specify the linked path via an annotation. It is an issue right now in that I have an app where I want the Forecastle icon to take the user to https://host/console/view but it only goes to https://host/

This is somewhat similar to, but different than, the nginx-ingress annotation nginx.ingress.kubernetes.io/app-root. In this case, I do not want to generally redirect /, I just want to specify the path for the Forecastle link.

Just a feature request to add a proper helm repository (probably just using github pages like the majority of them)

annotated the ingress with:
forecastle.stakater.com/properties: "finodsGroup=test1,applicationEnvironment=test2"

and it fails with:

time="2020-01-03T19:40:10Z" level=info msg="Found ingress with Name 'eos-jfr-srv-d1-fsjetty' in Namespace 'eos-jfr-srv-d1'" _source="filename/filename.go:22"
github.com/stakater/Forecastle/pkg/forecastle/ingressapps.convertIngressesToForecastleApps(0xc000680000, 0x8, 0x8, 0x1, 0xc0000171c8, 0xc0000ac060)
        /go/src/github.com/stakater/Forecastle/pkg/forecastle/ingressapps/apps.go:74 +0x413
github.com/stakater/Forecastle/pkg/forecastle/ingressapps.(*List).Populate(0xc0000178d8, 0xc0004952e0, 0x1, 0x1, 0x2)
        /go/src/github.com/stakater/Forecastle/pkg/forecastle/ingressapps/apps.go:52 +0x209
github.com/stakater/Forecastle/pkg/handlers.AppsHandler(0x1776d40, 0xc0003c0000, 0xc00053c800)
        /go/src/github.com/stakater/Forecastle/pkg/handlers/appsHandler.go:44 +0x521
net/http.HandlerFunc.ServeHTTP(0x162b318, 0x1776d40, 0xc0003c0000, 0xc00053c800)
        /usr/local/go/src/net/http/server.go:2007 +0x44
github.com/gorilla/mux.(*Router).ServeHTTP(0xc000270b60, 0x1776d40, 0xc0003c0000, 0xc00053c800)
        /go/pkg/mod/github.com/gorilla/[email protected]/mux.go:162 +0x104
net/http.serverHandler.ServeHTTP(0xc0001461c0, 0x1776d40, 0xc0003c0000, 0xc00053c400)
        /usr/local/go/src/net/http/server.go:2802 +0xa4
net/http.(*conn).serve(0xc0000a2aa0, 0x177aac0, 0xc0004ef540)
        /usr/local/go/src/net/http/server.go:1890 +0x875
created by net/http.(*Server).Serve
        /usr/local/go/src/net/http/server.go:2927 +0x38e```

I guess not much explanation needed nowadays ;)

Feature Request:

It would be nice if I could just explicitly add an external link (for example to PagerDuty) to a Forescatle ingress group without requiring an ingress. Forecastle puts together a nice collection of all the dynamic ingresses, but I would like to include links to external resources on the same page

I installed forecastle using helm install forecastle stakater/forecastle.

When I access the web interface I only get "Results couldn't be loaded due to an error".
There is no error shown in kubectl logs.

What might be wrong? Is there a way to debug further?

I'm seeing this chart version:

helm search repo forecastle
NAME                    CHART VERSION   APP VERSION     DESCRIPTION                             
stakater/forecastle     1.0.65                          forecastle chart that runs on kubernetes

but only 1.0.63 in this repo.
Where does it come from?

We consistently get:

time="2022-06-25T22:30:24Z" level=info msg="Found forecastleApp with Name 'wel-user-mgmt-shb-s1' in Namespace 'wel-test'" _source="filename/filename.go:22"
time="2022-06-25T22:30:25Z" level=error msg="An error occurred while rendering json to output: write tcp 10.200.58.74:3000->10.200.58.1:41314: write: broken pipe" _source="filename/filename.go:22"
2022/06/25 22:30:25 http: superfluous response.WriteHeader call from github.com/stakater/Forecastle/pkg/handlers.AppsHandler (appsHandler.go:96)

in the log, and forecastle is unable to respond when there is a lot of apps in the cluster.

I have a mix of k8s ingress defined apps and CRD defined apps and group ordering seems to be random-ish. It appears that the ingress defined apps are first, in semi-alphabetical order, then the CRD apps groups appear next and they seem to be alphabetical.

Now forecastle logo is in place; so, we should change to it instead of using stakater logo

When I apply the helm chart 1.0.65 with CRD on a fresh and empty kubernetes 1.19.11 cluster I get the following errors

The CustomResourceDefinition "forecastleapps.forecastle.stakater.com" is invalid: 
* spec.validation.openAPIV3Schema.type: Required value: must not be empty at the root
* spec.preserveUnknownFields: Invalid value: true: cannot set to true, set x-preserve-unknown-fields to true in spec.versions[*].schema instead

I can fix this errors by changing the CRD in the following way:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: forecastleapps.forecastle.stakater.com
spec:
  conversion:
    strategy: None
  group: forecastle.stakater.com
  names:
    kind: ForecastleApp
    listKind: ForecastleAppList
    plural: forecastleapps
    singular: forecastleapp
  preserveUnknownFields: false # has to be false, otherwise '* spec.preserveUnknownFields: Invalid value: true: cannot set to true, set x-preserve-unknown-fields to true in spec.versions[*].schema instead'
  scope: Namespaced
  versions:
  - name: v1alpha1
    schema:
      openAPIV3Schema:
        type: object  # needed, otherwise '* spec.validation.openAPIV3Schema.type: Required value: must not be empty at the root''
        properties:

The lines with the comments are my quick workarounds to get things deployed and running.

As by default it's expanded and if the list is very large it becomes quite cumbersome to go through the list; so, we should add expand all and collapse all

Currently, Forecastle filters out ingresses if the ingress.class annotation isn't present.

In our use case, we deploy Pomerium for our authentication layer. Pomerium requires the ingress.class annotation to be absent in favour of some other specific annotations.

The services in question are still very much exposed and we wish for them to show in Forecastle.

If we set the Forecastle expose annotation to true, I'd expect the ingress to be exposed in Forecastle regardless of the presence of an ingress.class.

I could be useful if one is exposing apps through LoadBalancer (not using Ingress)

Ingress apiVersion extensions/v1beta1 is deprecated and being replaced with networking.k8s.io/v1beta1, which itself is now deprecated and being replaced with networking.k8s.io/v1. Forecastle needs to support the new apiVersion by both monitoring for it and enabling access to monitor for it by adding networking.k8s.io to the RBAC API list:

Is there a way to increase the log level?

I can't figure it out, my manifests are

REBELinBLUE/k3s-rpi-cluster@d726cbb (custom build of the image to run on an raspberry pi)

but all I get in the output is

time="0001-01-01T00:00:00Z" level=info msg="Listening at port 3000" _source="Forecastle/forecastle.go:40"

nothing on the launchpad and the /apps endpoint just returns null

• Upon deployment with helm deployment and service receive irrelevant annotations with what seems to be some values internal to stakater org:

deployment:
authproxy.stakater.com/redirection-url: https://cp.stackator.com
service:
config.xposer.stakater.com/Domain: "stackator.com"
etc.

There is no other way to override those values than to edit values.yaml - therefore this chart cannot be packed and hosted (in ChartMuseum for example).

• There is no ingress created with deployment through helm. Seems like ingress creation is handled by another tool - xposer, that is neither a dependency of forecastle nor even mentioned on the README.md. Maybe add a config option to choose one or another?

• README.md has outdated configuration parameter names. See crdEnabled vs values.yaml: createCustomResource .

• README.md also does not mention that all config values have to be prepended with forecastle., therefore helm ... --set title="My Title" has no effect and has to be transformed to helm ... --set forecastle.config.title="My Title".