<commit_before>These files allow for running SReview on a Kubernetes cluster.

TODO:

- Actually test this on a real kubernetes cluster. It (seems to) work on
  minikube on my laptop, that's all I can say.
- I used this as a project to learn about Kubernetes. Most likely, I've
  made mistakes. Patches welcome!

Instructions:
- Create three persistent volumes claims:
  - The first should have ReadWriteOnce permissions, and be called
    "postgresdata". It stores the PostgreSQL database's data and should
    be backed up.
  - The second should have ReadOnlyMany permissions, be called
    "inputdata", and is to contain the raw recordings. NOTE: SReview
    does not consider itself with how these files end up on this volume;
    it is assumed that this happens out of band. However, the format is
    important, and should (by default) be in the format
    <room>/<date>/<time>.<container>, e.g.,
    mainroom/2020-01-08/10:00:00.mp4. This can be configured through the
    `inputglob` and `parse_re` configuration values. You can configure
    these either by shipping a file `/etc/sreview/config.pm` to the
    `detect` cron job, or by specifying them as the `SREVIEW_INPUTGLOB`
    and `SREVIEW_PARSE_RE` environment variables to that job.
  - The third should have ReadWriteMany permissions, be called
    "outputdata", and is where the output of SReview will end up on.
  If you use minikube, the "storage-minikube.yaml" file should do that.
<commit_msg>Document that we know that PersistentVolumeClaims shouldn't really be used...<commit_after>These files allow for running SReview on a Kubernetes cluster.

TODO:

- Actually test this on a real kubernetes cluster. It (seems to) work on
  minikube on my laptop, that's all I can say.
- I used this as a project to learn about Kubernetes. Most likely, I've
  made mistakes. Patches welcome!
- I was told about the fact that PersistentVolumeClaims aren't really a
  good thing for cross-pod communication. Will have to modify SReview so
  it can upload/download files before/after working on them...

Instructions:
- Create three persistent volumes claims:
  - The first should have ReadWriteOnce permissions, and be called
    "postgresdata". It stores the PostgreSQL database's data and should
    be backed up.
  - The second should have ReadOnlyMany permissions, be called
    "inputdata", and is to contain the raw recordings. NOTE: SReview
    does not consider itself with how these files end up on this volume;
    it is assumed that this happens out of band. However, the format is
    important, and should (by default) be in the format
    <room>/<date>/<time>.<container>, e.g.,
    mainroom/2020-01-08/10:00:00.mp4. This can be configured through the
    `inputglob` and `parse_re` configuration values. You can configure
    these either by shipping a file `/etc/sreview/config.pm` to the
    `detect` cron job, or by specifying them as the `SREVIEW_INPUTGLOB`
    and `SREVIEW_PARSE_RE` environment variables to that job.
  - The third should have ReadWriteMany permissions, be called
    "outputdata", and is where the output of SReview will end up on.
  If you use minikube, the "storage-minikube.yaml" file should do that.

{'fraction_non_alphanumeric': 0.06339787632729545, 'fraction_numerical': 0.009369144284821987, 'mean_word_length': 3.710294117647059, 'pattern_counts': {'":': 0, '<': 11, '<?xml version=': 0, '>': 11, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 1, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4594893', 'n_tokens_mistral': 906, 'n_tokens_neox': 869, 'n_words': 445}