hostNetwork?

[utegental]

Didn't found a way to set hostNetwork.

[gre9ory]

Hi @utegental,

you can set the hostNetwork as one of the pod: properties.

As an concrete example, the following should do the trick for an example Deployment myapp:

hull:
  objects:
    deployment:
      myapp:
        pod:
          hostNetwork: true
          containers:
            app:
              ...

Some explanations following:

Any workload based object instance includes the hull.PodTemplate.v1 schema which provides the pod field based on the hull.Pod.v1 schema.

Within hull.Pod.v1 you can work with the HULL based properties (here overwriting the Kubernetes objects properties):

initContainers
containers
volumes

however the documentation of hull.Pod.v1 also points to the Kubernetes API JSON schema for pods where you can find all the other original Kubernetes properties you can directly set on the pod: property (e.g. for Kubenretes 1.27 the podspec-v1-core):

activeDeadlineSeconds
affinity
automountServiceAccountToken
...
hostNetwork
...

This is the composition idea of HULL. You can generally work with all existing Kubernetes properties on the object specifications. Only for particular aspects/properties HULL provides specific means of handling them (in a hopefully improved way). Here for the pod: specification it allows you to manage containers, initContainers and volumes as a dictionary to improve the merging of configuration layers instead of leaving them as arrays. On rendering everything is of course converted to Kubernetes spec conforming YAML.

Hope this helps, if you need further assistance please let me know. Thanks!

[utegental]

@gre9ory, that is very helpful! I'm moving services from deprecated 'k8s-at-home' and from my first experience hull is very simple.

[gre9ory]

Thank you, it is great that you find HULL rather 'simple'. My worry is sometimes that it may have an entry barrier that is too high even if - once you understand the concepts it applies on top of all the other concepts (K8S, Helm) - it is rather simple to work with yet powerful in what it allows you to do. Trying to work on that by improving documentation mostly. But of course it would be helpful if others who like it spread the word too.

Did take a look at k8s-at-home, wasn't aware of it. Appears to be one of the approaches where a common library is created that contains a set of opinionated, manually maintained YAML templates/functions. Maybe conceptionally similar to this onechart or Bitnami common? Those offer some good flexibility in usage but my feeling so far was that they are not generic enough in their approaches and appear to be high-maintanance machines.

I think the HULL approach is a little different in the sense that it does not limit you in what you want to have in the resulting YAML output. The primary goal is really to have any K8S configuration that a user may need to change changeable anywhere downstream the configuration layers. Of course HULL has it's own structure and a little abstraction layer but it is supposed to offer maximum freedom in how to use it to achieve your goals.

For example, compared to the k8s-at-home use case where you want to create a lot of similar charts, you could start building up functions in another library chart that - based on HULL - simplify your special usecase configurations. In that sense HULL is the toolbox that gives you the parts and you start building convenience functions around that to ease recurring configuration scenarios. We do that a lot by now at our company, in this project we have a common structure in several charts and wrap HULL based functionality in functions in a way which allows us to e.g. create a service or ingress or similar in one line of HULL code such as:

configmap:
      camunda-deployment-api:
        data: _HT/hull.vidispine.addon.library.component.configmap.data:COMPONENT:"camunda-deployment-api"

This advanced usage is then again more tailored to your actual product needs and also conceptionally kind of closer to what k8s-at-home and similar offer to their users with pre-made functions to create ConfigMaps etc. with less effort. Yet I think with HULL at the core you still have more possibilities to fit it to your actual needs and not to what others think your needs may be.

But enough for the advertisement part, I will close this issue since I hope it can be considered resolved.