[Availability]
The package nvme-stas is already in Ubuntu universe.
The package nvme-stas builds for the architectures it is designed to work on.
It currently builds and works for architecture all
Link to package https://launchpad.net/ubuntu/+source/nvme-stas
[Rationale]
- The package nvme-stas is required for our nvme over fabric story
- It provides STorage Appliance Services (STAS) over nvme and has
been packaged by other distributions.
- The package nvme-stas will be useful for server administrators who
have the need to deploy such solutions.
- We would like to include it in main in order for the Canonical
foundations team to give official support on this package.
- There is no other/better way to solve this that is already in main or
should go universe->main instead of this.
- It would be great and useful to community/processes to have the
package nvme-stas in Ubuntu main, but there is no definitive deadline.
[Security]
- No CVEs/security issues in this software in the past
- no `suid` or `sgid` binaries
- no executables in `/sbin` and `/usr/sbin`
- Package does install services, timers or recurring jobs
- stafd
- stacd
- Packages does not open privileged ports (ports < 1024)
- Packages does not contain extensions to security-sensitive software
(filters, scanners, plugins, UI skins, ...)
[Quality assurance - function/usage]
- The package works well right after install. A manual service start for stafd
and stacd might be needed.
[Quality assurance - maintenance]
- The package is maintained well in Debian/Ubuntu/Upstream and does
not have too many, long-term & critical, open bugs
- Ubuntu https://bugs.launchpad.net/ubuntu/+source/nvme-stas/+bug
- Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=nvme-stas
- GitHub https://github.com/linux-nvme/nvme-stas/issues
- The package is well maintained in GitHub, with frequent commits to the
repository and latest upstream release on June 13th, 2023.
[Quality assurance - testing]
- The package runs a test suite on build time, if it fails
it makes the build fail. The test suite is located in test/
and contains 13 tests (build log attached).
- The package runs an autopkgtest, and is currently passing on
amd64, arm64, armhf, and ppc64el, link to test logs:
https://autopkgtest.ubuntu.com/packages/nvme-stas
- The package does have failing autopkgtests tests right now for s390x,
which are currently being investigated in bug #2026878.
- The i386 failures are ok to be ignored because this package does not
publish to i386.
[Quality assurance - packaging]
- debian/watch is present and works
- debian/control defines a correct Maintainer field
- Ubuntu does not carry a delta
- This package does not yield any lintian Warnings (with --pedantic)
- Lintian overrides are present, but ok because all of the three overrides have
explanations in comments in d/s/lintian-overrides and
d/nvme-stas.lintian-overrides.
- This package does not rely on obsolete or about to be demoted packages.
- This package has no python2 or GTK2 dependencies
- The package will be installed by default, but does not ask debconf
questions higher than medium
- Packaging and build is easy, link to debian/rules:
https://git.launchpad.net/ubuntu/+source/nvme-stas/tree/debian/rules
[UI standards]
- Application is not end-user facing (does not need translation)
[Dependencies]
- There are further dependencies that are not yet in main, MIR for them is at
https://bugs.launchpad.net/ubuntu/+source/dasbus/+bug/2025912
[Standards compliance]
- This package correctly follows FHS and Debian Policy
[Maintenance/Owner]
- Owning Team will be foundations-bugs
- Team is not yet, but will subscribe to the package before promotion
- This does not use static builds
- This does not use vendored code
- This package is not rust based
- The package was test rebuilt in sbuild recently (build logs attached)
[Background information]
The Package description explains the package well
Upstream Name is nvme-stas
Link to upstream project: https://github.com/linux-nvme/nvme-stas
Review for Source Package: nvme-stas
[Summary]
MIR team ACK under the constraint to resolve the below listed
required TODOs and as much as possible having a look at the
recommended TODOs.
This does need a security review, so I'll assign ubuntu-security
List of specific binary packages to be promoted to main: nvme-stas
Specific binary packages built, but NOT to be promoted to main: none
Recommended TODOs:
#1
- The package should get a team bug subscriber before being promoted
# 2
- Since this is rather new (not brekaing many existing cases) but doing a
very special limited set of things (might be easy to describe) it might be
very helpful to consider writing apparmor profiles and/or using more of
the system service isolation features.
#3
- We are currently in discussions to make it easier for software that needs
special hardware to get into main. And this is IMHO such a case. Gladly it
only provides usability sugar over what components that are already in main
(kernel, libnvme, nvme-cli) already provide. But I've not heard about testing
on actual nvme-of hardware. I'd like to ask you to read through [1][2] where
we list some ideas how a case like that could be overcome.
As often there are so many alone the lower transport nvmet-rdma or a real
adapter loading qla2xxx adapter or nvme_tcp - but one would be better than
none; Maybe you can even test this fully virtual - think of two qemu guests,
one with emulated NVME which it provides via nvme_tcp and the other the client
that does access it, test write/loads some and disconnects. Add the auto
discovery of stafd/stacd on top and this might be great.
To be clear - all that this package adds - is tested well, so this is only
a recommended task but if possible would help to QA the whole stack regularly.
#4
- Build time tests complain about missing components skipping tests
../test/
../test/
../test/
../test/
Would it pollute/break the build if you'd build-depend (with !nocheck)?
Because if that could work it would be an easy win for QA.
If you are concerned of the build env, then consider re-run this test in an
autopkgtest stage?
[1]: https:/
[2]: https:/
[Duplication]
It is related to some other similar sounding packages like nvme-cli, libnvme
and belongs to the same area. But there is no other package in main providing
the same functionality as nvme-stas.
[Dependencies]
OK:
- no other Dependencies to MIR due to this
- dasbus in requested bug 2025912
- python3-nvme is from libnvme in bug 1998114 and considered fine to come back
- no others
- no -dev/-debug/-doc packages that need exclusion
- No dependencies in main that are only superficially tested requiring
more tests now.
Problems: None
[Embedded sources and static linking]
OK:
- no embedded source present
In fact I appreciate that it is reusing code ...