Infra Container Enhancement #10933
Comments
openshift-ci
bot
added
the
kind/feature
|
The StaticDir isn't something we know before the container is created - it's configured by c/storage as part of container creation? |
|
hmmm okay @mheon I guess the issue is there is not equiv place as there is w/ regular containers to do specific mount such as overlay which uses the |
|
Doesn't the infra container get a staticdir? |
|
Yes @rhatdan it does but not it cannot be explicitly set until infra goes through the normal container creation process. I am brainstorming on how to consolidate infra and regular container creation since infra ends up getting mostly written by regular container creation anyway. I feel like they should be more comparable and easy to track. Gonna look into this more later today and tomorrow. |
InfraContainer should go through the same creation process as regular containers. This change was from the cmd level down, involving new container CLI opts and specgen creating functions. What now happens is that both container and pod cli options are populated in cmd and used to create a podSpecgen and a containerSpecgen. The process then goes as follows FillOutSpecGen (infra) -> MapSpec (podOpts -> infraOpts) -> PodCreate -> MakePod -> createPodOptions -> NewPod -> CompleteSpec (infra) -> MakeContainer -> NewContainer -> newContainer -> AddInfra (to pod state) removed runtime_pod_infra_linux.go, infra now is on its way to following basic container creation path. resolves containers#10933 Signed-off-by: cdoern <cdoern@redhat.com>
|
A friendly reminder that this issue had no activity for 30 days. |
github-actions
bot
added
the
locked - please file new issue/PR
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind feature
Description
InfraContainerConfigis not as parallel as it should be toContainerConfigand therefore container creation seems to be split into two different paths. There should be clear differences as certain attributes do not apply. However, for simplicity and readability I believe we should begin a slight rework of whatInfraContainerConfiglooks like.The codepath for a container is as follows
cmd => filloutspecgen => containercreate => completespec => makecontainer => newContainer()
while infra is...
cmd => podcreate => makepod => createpodoptions => newPod => makeinfracontainer => createinfracontainer => newContainer()
They end up at the same place and require most of the same options therefore should be combined into one codepath further up in the list.
Ran into this while working on
pod createflags. Certain things that can be done while creating a regular container cannot be done while creating infra due to a lot of missing attributes. This is a good foundational step before building uppodman pod create. A good specific example is while implementing the--volumeflag, I could not use overlayVolumes becauseoverlay.Mount()requires the usage of the containersStaticDirwhich is where persistent libpod data is stored. Infra does not have this. This change led me down a rabbit hole of other changes that could be made which leads me to think a general rework is called for.Will link commits I make to my infraEnhance branch so others can see what I am suggesting.
Open for suggestions and discussions!
The text was updated successfully, but these errors were encountered: