OSM charms promulgation request for cs:~davigar15/bundle/knf-lma-stack-1

charm
1

The OSM team would like to request the promulgation of the following LMA bundle:
cs:~davigar15/bundle/knf-lma-stack-1
This has been modified for the upcoming hackfest demo. The purpose is to give audience a good experience of deploying the bundle by:
juju deploy knf-lma-stack
Thanks

1 Like
2

I have a few questions related to this:

  • You requested knf-lma-stack-1 to be promulgated; this has mock-knf scaled to 3 units. knf-lma-stack-2 has it scaled to 1 unit. Are you sure you want -1 promulgated instead of -2?
  • The filebeat charm is related to graylog, but nothing else. Did you perhaps miss a mock-knf:filebeat relation? Without relating to a log producer, I don’t see how graylog will have any data to show.
  • ES and Graylog can be resource-intensive. Consider adding min hardware requirements to the Pre-req section of README.md so people don’t try deploying this on an under-powered machine. uK8s hardware reqs are listed here as a starting point.
  • README.md recommends update-status-hook-interval=1m. This seems aggressive, and i’m worried that update-status will block other hooks and cause unnecessary deployment delays.
  • How would a user contact you for support/suggestions? I’d recommend setting some contribution links for this bundle:
  charm set cs:~davigar15/bundle/knf-lma-stack \
    homepage=<link to src repo> \
    bugs-url=<link to issues/bug page>
3

We prefer the -2 promulgated. @wajeeha-hamid correct me if I’m wrong

The filebeat is a daemonset that runs on all the k8s workers, and gets the logs from /var/logs/pods. That’s why graylog can actually see the logs. We are getting the logs from all the k8s pods in the cluster.

I will update the README.md now with the minimum requirements.

Regarding the update-status-hook-interval: There an issue right now with the mongodb charm. There’s no hook telling the charm when the mongod service is up. So, in order to configure the replica set, it uses the update-status-hook. The default interval is 5m, which means we may have to wait up to 5 minutes for the mongodb to configure properly. That’s fine in normal deployments, but for the demo, the time is a bit critical. If this is a big issue, we can remove that from the README.md and only execute that ourselves when doing the demo for avoiding issues.

I will also add the homepage and bugs url :slight_smile:

4

@davigar15, I haven’t run filebeat inside a cluster like this, so I was confused as to what logs it would be watching. TIL!

Thanks for min reqs and homepage/bugs-url links. Those feel like easy additions that could prevent end user frustration.

The mongo/update-status explanation makes sense. It’s not a big deal for this promulgation, but without your post, I would not have guessed it was related to the mongodb deployment. Maybe worth a “Known Issues” section in the readme that talks about slow mongo deployments being sped up with this model-config – with the trade-off being that update-status runs more often.

I see revision 3 in the store now. Let me know if that’s the rev that you’d like promulgated.

5

yes @davigar15, we want rev 2 where we don’t have the scaling as part of the bundle.

6

@kwmonroe Hello! I just updated the README of the bundle. We can promote the revision 4

7

Looks good: knf lma stack | Juju

(thanks for the assist @kos.tsakalozos)