Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

options: keep using prior drivers if found #1618

Merged
merged 1 commit into from
May 26, 2023

Conversation

flouthoc
Copy link
Collaborator

@flouthoc flouthoc commented May 24, 2023

There is no need for vfs to be the default storage driver since kernel
>= 5.13 supports overlay natively however there is use-case for users
who don't had any configs and they started using vfs in a default manner following check is a hack to keep buildah and podman working for such users.

See: #1571 for prior discussions.

@flouthoc
Copy link
Collaborator Author

@nalind @giuseppe PTAL , this is a hack to prevent breaking old users, was not able to think of any other cheap way to prevent this break.

types/options.go Outdated Show resolved Hide resolved
@nalind
Copy link
Member

nalind commented May 24, 2023

There's a whole scanPriorDrivers() function in drivers/drivers.go. Can we find a way to refrain from bypassing it?

@flouthoc
Copy link
Collaborator Author

There's a whole scanPriorDrivers() function in drivers/drivers.go. Can we find a way to refrain from bypassing it?

Ah it does a similar check, I think its a good idea if we can find a way so c/storage does not bypass it while checking config. Let me take a look.

@giuseppe
Copy link
Member

we may need to tweak scanPriorDrivers() though as it has an explicit check to skip vfs, looking at the only caller of the function it should be fine to just drop the driver != "vfs" check

@flouthoc
Copy link
Collaborator Author

When I was looking at this is seems this part was always ignored by buildah or podman https://github.com/containers/storage/blob/main/drivers/driver.go#L345, since config itself defaults to a DriverName so New( will never receive empty driver string.

@flouthoc flouthoc changed the title options: keep using vfs for old users options: keep using prior drivers if found May 25, 2023
@flouthoc
Copy link
Collaborator Author

@giuseppe @nalind PTAL, it seems modifying behavior of New( could again break API users, so instead I think adding a similar check in types is safer way. Which will be only triggered if no selection of driver was set by user and c/storage is trying to find a default driver, in such case it will first check if any prior driver was set.

types/options.go Outdated Show resolved Hide resolved
@rhatdan
Copy link
Member

rhatdan commented May 25, 2023

@giuseppe @nalind PTAL

@flouthoc
Copy link
Collaborator Author

flouthoc commented May 25, 2023

cc @edsantiago (for info) I think this will unblock buildah vendor.

Copy link
Member

@giuseppe giuseppe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@nalind
Copy link
Member

nalind commented May 25, 2023

types/options.go will need to add _ "github.com/containers/storage/drivers/register" to its list of imports, otherwise its first call to ScanPriorDrivers() appears to be iterating through the map of registered drivers before that map is populated. LGTM once that's changed.

There is no need for `vfs` to be the default storage driver since kernel
>= 5.13 supports `overlay` natively however there is use-case for users
who don't had any configs and they started using `vfs` in a default
manner following check is a hack to keep `buildah` and `podman` working
for such users.

See: containers#1571 for prior
discussions.

Signed-off-by: Aditya R <arajan@redhat.com>
@rhatdan
Copy link
Member

rhatdan commented May 26, 2023

LGTM

@rhatdan rhatdan merged commit 55ee2d1 into containers:main May 26, 2023
18 checks passed
@Luap99
Copy link
Member

Luap99 commented Jun 9, 2023

This change is causing a huge bloat for rootlessport (size increase is 3 MB) in podman. Making storage/types depend on the drivers causes a new gigantic transitive dependency chain.

But more importantly this now causes build issues because it tries to build the devmapper driver even on systems without the device-mapper-devel installed, of course the correct thing is to use exclude_graphdriver_devicemapper but that wasn't necessary before which means likely other users who only depend on github.com/containers/storage/types will run into the same problem.

And to clarify rootlessport does not depend on c/storage/types directly. It only needs c/common/pkg/config but this package depends on c/storage/types which means everyone depending only on c/common/pkg/config and not the storage drivers will not suffer a almost 3 MB bloat in binary size.

Is there any way we can move this check into another package? Shouldn't this be decided in driver.New() and not in types?

@rhatdan
Copy link
Member

rhatdan commented Jun 10, 2023

@flouthoc PTAL

We should have never allowed the change in types/options.go

Lets revert this change and rework it.

@@ -10,6 +10,8 @@ import (
	"time"

	"github.com/BurntSushi/toml"
+	drivers "github.com/containers/storage/drivers"
+	_ "github.com/containers/storage/drivers/register"
	cfg "github.com/containers/storage/pkg/config"
	"github.com/containers/storage/pkg/idtools"
	"github.com/sirupsen/logrus"

@flouthoc
Copy link
Collaborator Author

flouthoc commented Jun 10, 2023

@rhatdan We can move ScanPriorDrivers to a different pkg , that should resolve this.

Luap99 added a commit to Luap99/libpod that referenced this pull request Jun 12, 2023
Because of a c/storage change[1] all we get a lot of new dependencies in
rootlessport despite not using them. Add build tags to exclude storage
drivers to make the binary smaller until it get addressed in c/storage.

This saves about 800 MB but the bloat due that change is still causing
us to gain over 2 MB. This is not ideal but we should get vendoring
going and not wait any longer.

[1] containers/storage#1618

Signed-off-by: Paul Holzinger <pholzing@redhat.com>
@flouthoc
Copy link
Collaborator Author

I think moving entire check to Drivers.New( would break the API which will return empty driver when no driver is selected in the config and if we default to only vfs then we will have to hack Drivers.New to support native overlay again.

A simpler solution could be to create a function similar to ScanPriorDrivers for types/options which will only work on text filtering from a list of drivers ( e.g []string{"overlay", "vfs" ... } ) instead of going through a map of registered drivers.

This will remove types/options.go dependency on drivers and drivers can still keep using older code.

@containers/storage-maintainers @Luap99 WDYT ?

@Luap99
Copy link
Member

Luap99 commented Jun 12, 2023

I think moving entire check to Drivers.New( would break the API which will return empty driver when no driver is selected in the config and if we default to only vfs then we will have to hack Drivers.New to support native overlay again.

I cannot follow that statement? Looking at drivers.New() that function tries all drivers before it errors out when no driver works.

@flouthoc
Copy link
Collaborator Author

flouthoc commented Jun 12, 2023

@Luap99 @containers/storage-maintainers This is patch which i want to propose 0c6fcf4 on my branch https://github.com/flouthoc/storage/tree/move_scan_prior

@flouthoc
Copy link
Collaborator Author

Nvm I think there is another simpler patch suggested by @giuseppe , d7a6662 on the branch https://github.com/flouthoc/storage/tree/use-readdir-prior, this should do the trick as well.

@flouthoc
Copy link
Collaborator Author

@Luap99 Following PR should address this #1637

cgiradkar pushed a commit to cgiradkar/podman that referenced this pull request Jul 12, 2023
Because of a c/storage change[1] all we get a lot of new dependencies in
rootlessport despite not using them. Add build tags to exclude storage
drivers to make the binary smaller until it get addressed in c/storage.

This saves about 800 MB but the bloat due that change is still causing
us to gain over 2 MB. This is not ideal but we should get vendoring
going and not wait any longer.

[1] containers/storage#1618

Signed-off-by: Paul Holzinger <pholzing@redhat.com>
cgiradkar pushed a commit to cgiradkar/podman that referenced this pull request Jul 13, 2023
Because of a c/storage change[1] all we get a lot of new dependencies in
rootlessport despite not using them. Add build tags to exclude storage
drivers to make the binary smaller until it get addressed in c/storage.

This saves about 800 MB but the bloat due that change is still causing
us to gain over 2 MB. This is not ideal but we should get vendoring
going and not wait any longer.

[1] containers/storage#1618

Signed-off-by: Paul Holzinger <pholzing@redhat.com>
cgiradkar pushed a commit to cgiradkar/podman that referenced this pull request Jul 17, 2023
Because of a c/storage change[1] all we get a lot of new dependencies in
rootlessport despite not using them. Add build tags to exclude storage
drivers to make the binary smaller until it get addressed in c/storage.

This saves about 800 MB but the bloat due that change is still causing
us to gain over 2 MB. This is not ideal but we should get vendoring
going and not wait any longer.

[1] containers/storage#1618

Signed-off-by: Paul Holzinger <pholzing@redhat.com>
cgiradkar pushed a commit to cgiradkar/podman that referenced this pull request Jul 17, 2023
Because of a c/storage change[1] all we get a lot of new dependencies in
rootlessport despite not using them. Add build tags to exclude storage
drivers to make the binary smaller until it get addressed in c/storage.

This saves about 800 MB but the bloat due that change is still causing
us to gain over 2 MB. This is not ideal but we should get vendoring
going and not wait any longer.

[1] containers/storage#1618

Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants