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

Expose image type (ext3/squashfs) with inspect #1268

Closed
kav2k opened this issue Jan 24, 2018 · 8 comments
Closed

Expose image type (ext3/squashfs) with inspect #1268

kav2k opened this issue Jan 24, 2018 · 8 comments

Comments

@kav2k
Copy link

kav2k commented Jan 24, 2018

Version of Singularity:

2.4.2-dist

Expected behavior

It is expected that inspect (or another singularity command) is able to tell that an image is immutable or not.

Actual behavior

No such information is currently exposed.

In fact, there's no way to determine it using singularity itself, other than trying to run a container with --writeable and detecting the error.

As a workaround, this produces the required information:

SINGULARITY_MESSAGELEVEL=0 /usr/local/libexec/singularity/bin/image-type some_image.simg

However, it's desirable to be able to get this information with standard commands.

@ArangoGutierrez
Copy link
Contributor

I think we must first discuss how we want to read this info

Here I show a 0.1 proposal for this feature.

singularity inspect nginx.img 
{
    "org.label-schema.usage.singularity.deffile.bootstrap": "docker",
    "maintainer": "NGINX Docker Maintainers <docker-maint@nginx.com>",
    "org.label-schema.usage.singularity.deffile": "Singularity",
    "org.label-schema.schema-version": "1.0",
    "org.label-schema.usage.singularity.deffile.includecmd": "no",
    "org.label-schema.usage.singularity.deffile.from": "nginx",
    "org.label-schema.build-date": "Tue,_23_Jan_2018_17:39:21_-0500",
    "org.label-schema.usage.singularity.version": "2.4.1-release-2.4.g56581cf3",
    "org.label-schema.build-size": "111MB"
    "org.label-schema.image-format": "squash,ext3,tar" << Proposal
}

@vsoch
Copy link
Collaborator

vsoch commented Jan 24, 2018

@ArangoGutierrez the specification is here: http://label-schema.org/rc1/ the namespace needs to fall under singularity then some label. I would suggest starting even simpler than that - if the user asks for

singularity inspect -f <container> 

The ``-f(or-if`) would signify image format, and the entrypoint to inspect would use the `SINGULARITY_libexecdir` to target the executable, change the message level to 0 to be quiet, and then call it to return the format.

singularity inspect -f <container> 
SQUASHFS

and thus it's basically a wrapper for the command that already exists. For the integration with the other json, since we are transitioning to go it would be ok to wait to re-write that code, although you could follow suit with calling the executable (or using the function I wrote to get the format) and then returning the same thing. Up to you!

@carterpeel
Copy link
Contributor

Hello,

This is a templated response that is being sent out to all open issues. We are working hard on 'rebuilding' the Singularity community, and a major task on the agenda is finding out what issues are still outstanding.

Please consider the following:

  1. Is this issue a duplicate, or has it been fixed/implemented since being added?
  2. Is the issue still relevant to the current state of Singularity's functionality?
  3. Would you like to continue discussing this issue or feature request?

Thanks,
Carter

@vsoch
Copy link
Collaborator

vsoch commented May 15, 2021

This will also eventually be valuable for perhaps using singularity containers with OCI. It was more of an issue before when there were more image types, and now probably it would help to show the version of SIF.

@stale
Copy link

stale bot commented Jul 14, 2021

This issue has been automatically marked as stale because it has not had activity in over 60 days. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Jul 14, 2021
@vsoch
Copy link
Collaborator

vsoch commented Jul 14, 2021

Don't close stalebot, the contributors to this issue have responded and it's the maintainers that have not.

@stale stale bot removed the stale label Jul 14, 2021
@pedroalvesbatista
Copy link
Contributor

@kav2k We're looking into the issue carefully, soon will bring to community and discuss ways to better solve as well address this. Thankyou for keeping the interest in the subject.

@kmuriki
Copy link
Collaborator

kmuriki commented Jun 7, 2022

Copied into Apptainer new issue #491. Closing this in the old Singularity repo.

@kmuriki kmuriki closed this as completed Jun 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants