merge pmem-ns-init and pmem-vgm into pmem-csi-driver

[okartau]

The information shown in those setup stages (these run in LVM mode only) can be helpful for debugging issues and monitoring storage devices state.

[okartau]

Currently shown output is collected from running driver pods, using e2e framework methods, if I get this correctly. As pmem-ns-init and pmem-vgm do not produce output during the tests run, but during pods startup only, does it make sense not to go into e2e framework with this, but rather to add separate commands:

• kubectl logs PODNAME pmen-ns-init
• kubectl logs PODNAME pmen-vgm

in testing script after pods creation, executed in LVM mode cases only?

[pohly]

Where would you put this? The pods do not necessarily have completed yet after "make start".

We could add it to WaitForPMEMDriver in test/e2e/e2e.go.

[pohly]

Before we add more special cases, let's consider the alternative: we could move the functionality of those separate binaries into the main driver binary itself. This has several advantages:

• we can get rid of the init containers, which simplifies deployment and debugging
• container image becomes smaller (there's duplicate code linked into each of the three binaries)

What advantage(s) does it have to have three different binaries?

[okartau]

I recall very early design was just as you propose, a monolithic one, handling ns-init and vgm parts as function calls. Then there was idea to separate init.stages with the reasoning like:

• modular design, smaller entities
• lets have driver dealing with CSI, and initcontainers handling separate housekeeping which is not CSI related
• those init.stages are needed only in LVM mode, so it is possible to leave those parts totally out in direct mode via deployment-level config.
• was one idea that in LVM mode only the init.part has to deal with libndctl operations (as the main driver will deal with LVM level operations), so we thought we can keep more power-hungry device-mgmt rights out of CSI driver that way ? (not so sure did this really materialize as we wished...)

I think @avalluri was main architect of change to initcontainers, so he may remember some reasons as well.

[pohly]

If those were the goals, then it's probably time to revisit that decision: if we had different images, then it might have resulted in a smaller non-LVM image (but the LVM image might have become larger as a result of linking the Go runtime into multiple binaries). But we don't, and I don't think that "smaller size" is worth the extra complexity, so let's pick the best solution for the single-image scenario.

[avalluri]

I think @avalluri was main architect of change to initcontainers, so he may remember some reasons as well.

The intention of init-containers usage was when we were not using the 'bidirectional' mounts for the driver in LVM mode. But we moved to shared/bidirectional mounts for both the driver modes, so we could drop those init containers and merge the functionality to the driver's LVM device manager.