[needs-packaging] openjdk-17-crac

Bug #2073609 reported by Pushkar Kulkarni
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu
New
Wishlist
Pushkar Kulkarni

Bug Description

OpenJDK with Coordinated Restore at Checkpoint (CRaC) is a project under the OpenJDK umbrella [1][2]. It offers a solution to the Java application startup problem using the checkpoint/restore in user-space (criu)[3] approach, making it applicable for cloud-native, microservices-based Java backends.

Currently, JDK vendors like Azul [4] and Liberica[5] have CRaC-based JDK offerings. Java-frameworks like SpringBoot [6] and Micronaut[7] have released support for CRaC. I am hereby proposing that Ubuntu also offers the CRaC functionality with openjdk-17 through a new openjdk-17-crac package in universe.

URL: https://openjdk.org/projects/crac

License: GPL 2.0 License

Notes: The openjdk-17-crac source package will offer crac-jre, crac-jre-headless, crac-jdk and crac-jdk-headless which can be installed independent of (and alongside) the openjdk-17 packages.

[1] https://openjdk.org/projects/crac
[2] https://github.com/openjdk/crac
[3] https://criu.org/Main_Page
[4] https://www.azul.com/products/components/crac/
[5] https://bell-sw.com/libericajdk-with-crac/
[6] https://spring.io/blog/2023/11/23/spring-boot-3-2-0-available-now
[7] https://micronaut-projects.github.io/micronaut-crac/2.3.0/guide/

tags: added: needs-packaging
Revision history for this message
Brian Murray (brian-murray) wrote :

*** This is an automated message ***

This bug is tagged needs-packaging which identifies it as a request for a new package in Ubuntu. As a part of the managing needs-packaging bug reports specification, https://wiki.ubuntu.com/QATeam/Specs/NeedsPackagingBugs, all needs-packaging bug reports have Wishlist importance. Subsequently, I'm setting this bug's status to Wishlist.

Changed in ubuntu:
importance: Undecided → Wishlist
Revision history for this message
Pushkar Kulkarni (pushkarnk) wrote :

The proposed package is available here:
https://launchpad.net/~pushkarnk/+archive/ubuntu/openjdk-crac

The source package is pushed here for reference:
https://git.launchpad.net/~pushkarnk/+git/openjdk-17-crac/?h=main

Revision history for this message
Pushkar Kulkarni (pushkarnk) wrote (last edit ):
Download full text (3.2 KiB)

Some comments that might help in the review.

Packaging
----------
1. This is a derivative of the openjdk-17 source package [1]. Though it contains additional dependencies and a different upstream code repository, the Debian packaging code is borrowed from the openjdk-17 and modified to suit openjdk/crac needs.

2. The binary openjdk-17-crac-* packages may be installed alongside the vanilla openjdk-17-* packages. They may be configured using `update-alternatives --config java`.

3. I have proposed vendoring in three dependencies and here are the rationales:

   googletest: openjdk-17 also vendors in a specific version of googletest because it's upstream [2] uses it as a test-dependency. Because the openjdk-17-crac upstream [3] is also based upon the openjdk-17 upstream and we need the same version of googletest vendored in.

   crac-criu: The checkpoint/restore functionality in openjdk-17-crac is driven by criu [4]. We have a 'criu' package in universe[5]. But what the openjdk/crac project uses is a significantly modified version of criu, named crac-criu [6]. Given that crac-criu binaries are "specialized criu binaries" for the openjdk/crac project, they are unlikely to have an independent identity in the Ubuntu archive. I hence thought it is better to vendor in this dependency. I have updated the debian/copyrights file to include the criu licenses.

   lz4: Things get complicated here. The upstream crac-criu code pulls in a specific version of lz4 (which happens to be their last release) as a 'git submodule' [7]. Along with the static liblz4.a, the upstream crac-criu Makefile also builds another liblz4io.a from a specific object file, and in turn links these two archives into the crac-criu binaries [8]. I think this will be difficult to emulate by using lz4 as a builddep or through Built-Using (which I haven't explored much). I have vendored-in the latest official lz4 release and included the relevant licenses in the debian/copyrights file.

Maintenance
-----------
1. The openjdk-17-crac upstream [3] will have the latest JDK 17 security updates [2] augmented with openjdk/crac patches from [9]. For now, it includes security/CVE fixes that the April 2024 security updates of JDK 17. I intend to keep rebasing the openjdk/crac patches to the latest JDK 17 security updates on a quarterly basis (which is the openjdk project's cadence).

2. The crac-criu upstream [6] has specialized crac patches based upon checkpoint-restore/criu [10]. The latter exists in universe and has been stable over the last year. However, in the case of any CVEs being reported/fixed in checkpoint-restore/criu, I intend to bring them over to crac-criu as soon as they are published upstream.

Suitability
-----------
1. The licenses and copyrights of all vendored dependencies have been included in the debian/copyright file.

[1] https://launchpad.net/ubuntu/+source/openjdk-17
[2] https://github.com/openjdk/jdk17u
[3] https://github.com/canonical/openjdk-17-crac
[4] https://criu.org/Main_Page
[5] https://launchpad.net/ubuntu/+source/criu
[6] https://github.com/canonical/crac-criu
[7] https://github.com/canonical/crac-criu/blob/crac/Makefile#L250
[8] https://github.com/cano...

Read more...

Revision history for this message
Pushkar Kulkarni (pushkarnk) wrote (last edit ):

I've proposed a new package here in favor of the other alternative of maintaining the openjdk/crac patches in our existing openjdk-17 source package. The openjdk/crac delta is quite huge [1]. The crac changes pervade through the Hotspot VM, the garbage collector and the standard library. It will be hard to maintain these patches on every quarterly openjdk security update. OTOH, it is fairly straightforward to maintain a different upstream repository hosting crac patches on top of the latest JDK 17.

[1] https://github.com/canonical/openjdk-17-crac/compare/master...crac

Changed in ubuntu:
assignee: nobody → Pushkar Kulkarni (pushkarnk)
Revision history for this message
Pushkar Kulkarni (pushkarnk) wrote :

Based on some feedback from vpa1977, I have split out crac-criu into a new package [1]. The new openjdk-17-crac package is now available at [2]. The source package is uploaded to [3].

[1] https://bugs.launchpad.net/ubuntu/+bug/2076037
[2] https://launchpad.net/~pushkarnk/+archive/ubuntu/crac
[3] https://code.launchpad.net/~pushkarnk/+git/openjdk-17-crac

Revision history for this message
Vladimir Petko (vpa1977) wrote :

Checked package from ppa: https://launchpad.net/~pushkarnk/+archive/ubuntu/crac-packages-4/+sourcepub/16409305/+listing-archive-extra
Source: https://code.launchpad.net/~pushkarnk/+git/openjdk-17-crac/+ref/main

Packaging review:
MUST:
- Package must meet Ubuntu versioning & Maintainer requirements [OK]
 Version: 17.0.13+0-0ubuntu1
 Maintainer: Pushkar Kulkarni <email address hidden>
- Package must match current Ubuntu (and Debian) packaging policies [OK/nit]
 - standards version can be bumped to 4.7.0 (can be done on upload)
- Package must build, install, run, remove, and purge cleanly [OK/nit]
  nit: crac-jdk suggests default-jre (which is probably ok)
  nit:
  $java --version
openjdk 17.0.12 2024-07-16
OpenJDK Runtime Environment (build 17.0.12+0-Ubuntu-0ubuntu1)
OpenJDK 64-Bit Server VM (build 17.0.12+0-Ubuntu-0ubuntu1, mixed mode, sharing)
  should be 17.0.13

SHOULD:
- Package should be lintian clean [nit]
upstream overrides:
P: openjdk-17-crac-dbg: renamed-tag library-in-debug-or-profile-should-not-be-stripped => stripped-library [usr/share/lintian/overrides/openjdk-17-crac-dbg:2]
P: openjdk-17-crac source: spelling-error-in-patch-description "allows to" "allows one to" [debian/patches/jdk-8334895-proposed.patch]

- Contents of debian/ should be sane [OK]
 Same as openjdk-17 except new overrides due to openjdk path hardcoded in lintian
 and crac-specific rules changes.
- Changelog should close a "needs-packaging" bug [OK]
- Package should follow
http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html[OK]
    nit: we may add d/upstream/metadata

Maintenance review:
MUST:
- Package must contain a watch file or get-orig-source rule [OK]
- If upstream is no more, the packager should consider adopting the
upstream package somewhere [N/A]
- Packages who implement get-orig-source for packages with watch files
get extra points [no extra points]
- Packaged version must not have any known security or critical bugs [OK]
 Upstream is receiving quarterly security patches.

SHOULD:
- Packaging scripts should be readable and readily comprehensible [OK]
- Upstream should be responsive, and maintain a bug tracker [OK]
    bugs.openjdk.org.
- Packaged version should be latest upstream [OK]
- Package should not be native without an approved spec [N/A]

Suitability review
MUST:
- Package must meet copyright / licensing requirements [OK]
- Non-native packages must have verifiable cryptographic path to
upstream source [OK]
- Package must be advocated by at least two members of ubuntu-dev (the
packager may count as one) [OK]
SHOULD:
- Package should work on a standard Ubuntu/Kubuntu/Xubuntu/etc. system [OK]
- Package should provide hints to system services (app-install-data,
menus, etc.) to ease installation and use [N/A]
- Package should provide Ubuntu-specific documentation for variances
in behaviour from upstream [Comments]
nit: more of upstream comment - we may want to update README.Debian for
openjdk-* packages. At the moment it references 9...
- Package should provide a Homepage: header in debian/control [OK]

Revision history for this message
Pushkar Kulkarni (pushkarnk) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.