Cronjob Support about library-charts

[bjw-s]

I think the miscommunication here is rooted in the fact that the k8s-at-home library chart is intended as a library to be used for our own library of Helm charts.

It is very flattering and cool that it is being used outside of that realm, but (for now) its only intended goal is to make our own chart development easier.

I'll see if I can add a note to the README to communicate that more clearly, and I'll discuss with the fellow project maintainers if/how we want to expand the scope of the library.

[onedr0p]

I am not convinced adding a CronJob controller to the common chart will be worth it IMO. CronJob specs are pretty different from Deployments, StatefulSets and DaemonSets and are generally pretty easy to write with little code. For example https://github.com/onedr0p/home-cluster/tree/main/cluster/apps/monitoring/uptimerobot-heartbeat

I don't have much to say about NetworkPolicy but maybe that is useful? I am not sure.

[bjw-s]

I am inclined to agree with @onedr0p on this. The idea behind the common chart is to be a library that is useful to a large part of our charts. I think only a very limited number of charts would benefit from having direct support for CronJob and/or NetworkPolicy objects.

NetworkPolicy objects are also very user-specific, so I would think the amount of yaml that would be written in the values.yaml file will end up pretty similar to just adding a NetworkPolicy manifest manually. But I must admit that I am not super well versed in them yet, so I may be completely wrong there 😛

[qgervacio]

I think it's a good idea to support CronJob and NetworkPolicy natively because it will only be a matter of time when someone would need it; that time is now and that someone is me 😅

Also, I don't think it's an option to look for another chart library that has a NetworkPolicy implementation which will then be attempted to coexist with commons. Doing so would be a horror to implement(?).

For NetworkPolicy we use it in all projects. I noticed there's a addons/vpn/_networkpolicy.tpl which I was hesitant to use hence I had to come up with the following. I followed the implementation of common.ingress

networkpolicy:
  aaa:
    enabled: true
    podSelector:
      matchExpressions:
      - {key: ..., operator: In, values: ["..."] }
    ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            name: ...
      ports:
      - port: ...
        protocol: TCP
    egress:
    - ports:
      - port: ...
        protocol: TCP
      to:
      - ipBlock:
          cidr: ...
  bbb: ...
  ccc: ...

[bjw-s]

I think it's a good idea to support CronJob and NetworkPolicy natively because it will only be a matter of time when someone would need it; that time is now and that someone is me 😅

Implementing something across almost all of our charts because a single user has a need is usually not the main reason why we do it 😉 Adding a feature means more maintenance, more chance of breakage and more mental overhead when trying to keep broad k8s version compatibility.

Also, I don't think it's an option to look for another chart library that has a NetworkPolicy implementation which will then be attempt to coexist with commons. I think doing so would be a horror to implement(?).

Depending on your exact use case it is not required to put all your manifests in a Helm chart. You can deploy the bulk of an application through Helm and add/store/apply the NetworkPolicy as a separate yaml manifest.

networkpolicy:
  aaa:
    enabled: true
    podSelector:
      matchExpressions:
      - {key: ..., operator: In, values: ["..."] }
    ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            name: ...
      ports:
      - port: ...
        protocol: TCP
    egress:
    - ports:
      - port: ...
        protocol: TCP
      to:
      - ipBlock:
          cidr: ...
  bbb: ...
  ccc: ...

This enforces my feeling that the content of values.yaml for networkPolicies would be pretty much the same as the actual manifest. We are trying (as much as possible) to stay away from 1:1 passthrough of complete values blocks to rendered manifests.

[qgervacio]

Implementing something across almost all of our charts because a single user has a need is usually not the main reason why we do it 😉 Adding a feature means more maintenance, more chance of breakage and more mental overhead when trying to keep broad k8s version compatibility.

I can't say for sure if i'm the only one who needs it. I did audited alternatives such as https://github.com/bitnami/charts/tree/master/bitnami/common/ and https://github.com/hmcts/chart-library. True enough though both of these doesn't supports NetworkPolicy as well. commons is my recommendation to my company thus all backend devs uses it and NetworkPolicy is always a requirement. CronJob is rare.

Depending on your exact use case it is not required to put all your manifests in a Helm chart. You can deploy the bulk of an application through Helm and add/store/apply the NetworkPolicy as a separate yaml manifest.

This also introduces another resource and possibly another library which is also a mental overhead for devs. The chart design I advocate to teams is to use a single application chart where participating microservices are just sub-charts and all the heavy lifting is provided by this sweet lib.

This enforces my feeling that the content of values.yaml for networkPolicies would be pretty much the same as the actual manifest. We are trying (as much as possible) to stay away from 1:1 passthrough of complete values blocks to rendered manifests.

I agree that it is indeed a passthrough just to complete a manifest but I think it does makes the implementation more cleaner and natural since it's just filling-in the blanks.

so yep, for us, we do need commons to support these 2 kube kinds and supporting these would be the right solution, where the rest would just be a workaround 😭

i give up though 😭, please proceed to close this request enhancement.

[adelwin]

I'm inclined to agree with @qgervacio there. I happen to have the same requirement to apply a common NetworkPolicy across dozens of clusters.

Now I'm not suggesting for a lib-chart that covers the whole k8s resource-types, but Jobs/CronJobs are getting pretty common, a lot of charts out there uses CronJobs as a pre-setup for their actual Deployment/DaemonSet

Plus, I think it's pretty normal for a library to expand its scope as time goes on.