feat: add workloads to the plan

[anpep]

Workloads are a way to optionally group services and apply shared run configuration (user, group, environment) to services, in a way that may be extended in the future to support confinement.

services:
    my-service:
        override: replace
        command: /bin/my-service
        workload: my-workload

    my-other-service:
        override: replace
        command: /bin/my-other-service
        workload: my-workload

workloads:
    my-workload:
        user: foo
        group: foo
        environment:
            SHARED_VARIABLE: bar

[paul-rodriguez]

What about the else case?

[anpep]

uid, gid are nil, and setCmdCredential() is not called, resulting in the services being run as the current user

[paul-rodriguez]

Do we allow every environment variable to be customized here? Just thought about this. I guess yes.

[anpep]

Yes, we decided nothing against that when discussing the spec, but I'm happy to explore this. Personally, I don't think there's anything wrong per se with allowing every environment variable to be changed, but if you have arguments against that I'm happy to make them part of the spec discussion

[paul-rodriguez]

Suggestion to rename to IsEmpty

[anpep]

Feels more fitting, however IsZero() is already part of the Section interface in the plan:

pebble/internals/plan/plan.go

Lines 53 to 59 in d8a630a

	type Section interface {
	// Validate checks whether the section is valid, returning an error if not.
	Validate() error
	// IsZero reports whether the section is empty.
	IsZero() bool
	}

[paul-rodriguez]

!other.IsEmpty() && ws.Entries == nil

[anpep]

This would potentially result in a nil pointer dereference in sneaky ways, since it's up to the implementation of IsZero() to dereference or not the pointer receiver. len() is special in that len(nil) == 0 for slices and maps.

[paul-rodriguez]

My intuition is that validate should do that check regardless.

[paul-rodriguez]

Additionally, there could be a lot of invalid stuff in the Environment map. Would it make sense to check here?

[paul-rodriguez]

Considering we allow specifying both user-id and username, or both group-id and group name, there's a possibility of a workload where the group-id doesn't actually match the group name and same for users. Where would we deal with that? I expect this will only get detected for sure in kernos bootstrap. Correct?

[anpep]

This is detected in servstate when calling osutil.NormalizeUidGid(). An error may be returned if user/user-id or group/group-id does not match, as well as when specifying a user/group that does not exist in the system.

[paul-rodriguez]

Except for a couple of minor details this looks good to me. I'm still a bit fuzzy on how this will actually play out in bootstrap.