Split up create config handling of namespaces and security

[haircommander]

As it stands, createconfig is a huge struct. This works fine when the only caller is when we create a container with a fully created config. However, if we wish to share code for security and namespace configuration, a single large struct becomes unweildy, as well as difficult to configure with the single createConfigToOCISpec function.

This PR breaks up namespace and security configuration into their own structs, with the eventual goal of allowing the namespace/security fields to be configured by the pod create cli, and allow the infra container to share this with the pod's containers. This will solve many requests (#3837, #2957, #2808) of further customizing pod creation.

This is NOT DONE AT ALL. but, I am putting the beginnings here for people to tell me their thoughts about the design, approach etc. The next steps include:

• actually use the namespace functions in spec generation/creation (after this step I will likely push to have this PR merged so it doesn't bloat too much)
• create a path for a pod create to take namespaces and security and configure the infra container's fields
• add the appropriate subset of podman create cli flags for namespace/security creation
• integrate into play kube
• test the day lights out of it

[mheon]

I'd prefer to put all namespace configuration together if we can

[haircommander]

Even if we do i'd still like proceessing of them to be separated so if a pod only shares a couple of namespaces, all fields don't have to be configured fully

[mheon]

I'm in the planning stages of related refactoring, so we might want to sync on this tomorrow

[haircommander]

Sgtm, i'm second half day PTO but on PST, maybe sync around watercooler?

[haircommander]

Alright, this PR as is is ready to be merged PTAL @mheon @baude @rhatdan @TomSweeneyRedHat @QiWang19 @jwhonce @vrothberg

[mheon]

One thing I'd really like to do is have a unified, sane type for namespaces. Podman should probably allow --uts=ns:$PATH like we do for --net, for example. It seems like it would be easier to handle them all together.

[haircommander]

@mheon the problem about that is where the options diverge. net has like a thousand options. We could create an interface for the shared ones, but we couldn't use that interface in a very generic way, so the added benefit is not clear to me

[rh-atomic-bot]

☔ The latest upstream changes (presumably #4310) made this pull request unmergeable. Please resolve the merge conflicts.

[rhatdan]

@haircommander Could you rebase?

[haircommander]

@rhatdan done

[rhatdan]

LGTM

[vrothberg]

LGTM, nice work @haircommander

I will let @mheon and/or @baude have a final look.

[rhatdan]

/lgtm
/approve

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: haircommander, rhatdan

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [rhatdan]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[rh-atomic-bot]

☔ The latest upstream changes (presumably #4374) made this pull request unmergeable. Please resolve the merge conflicts.

[haircommander]

rebased to resolve conflicts

[rhatdan]

/lgtm
/hold
hold cancel when tests pass.

[haircommander]

/hold cancel

[haircommander]

/retest

[rhatdan]

/test images

[rh-atomic-bot]

☔ The latest upstream changes (presumably #4447) made this pull request unmergeable. Please resolve the merge conflicts.

[rhatdan]

@haircommander needs a rebase.

[rhatdan]

/lgtm