Skip to content

mvsce: move mvsMF to 1.4.1 and read its level from /zosmf/info - #43

Merged
mgrossmann merged 2 commits into
mainfrom
issue-42-mvsmf-1.4.1
Nov 8, 2026
Merged

mgrossmann merged 2 commits into
mainfrom
issue-42-mvsmf-1.4.1

Conversation

@mgrossmann

Copy link
Copy Markdown
Contributor

Closes #42.

Summary

  • mvsMF 1.3.0 becomes 1.4.1 (Dockerfile and README table).
  • mvsMF 1.4.x registers the diagnostic endpoint /zosmf/test only in development builds. On a release it answers 404, so the image build failed its version probe. The setup check, the readiness probe of mvsce-target, the mvsce CI workflow and the README now read the level from GET /zosmf/info (zosmf_full_version). The setup check fails on a -dev version.
  • The setup check also asserts that /zosmf/restconsoles/v1/log answers 401 without a login and 200 for IBMUSER.
  • No JESSPOOL profile is defined. The class stays empty, so mvsMF 1.4.1 shows each user only its own jobs. The FTPD test 18 and the mvsMF JESSPOOL suite refuse a container whose PROFILES already has JESSPOOL lines, so the image must not define one.

Testing

Image built locally (mvsce:issue-42, BUILD_EXIT 0). One throwaway container started with mvsce-target up (local, no --host), shut down with mvsce-target down, and confirmed gone with mvsce-target list.

Against that container:

  • GET /zosmf/restconsoles/v1/log: 401 without a login, 200 for IBMUSER.
  • GET /zosmf/info: zosmf_full_version 1.4.1.
  • A job submitted as IBMUSER is listed with owner=* and owner=IBMUSER, status OUTPUT, CC 0000.
  • mbt test --mvs --target env, each on the release tag the image ships:
    • httpd v4.5.1: 1634 assertions passed, 0 failed
    • mvsmf v1.4.1: 4504 passed, 0 failed
    • ftpd v1.2.0: 170 passed, 0 failed
    • ufsd v1.4.0: 398 passed, 0 failed

Not covered: the mvsMF curl suites curl-consgate and curl-jesspool skipped themselves, because the mbt target has no second user (test2). They did not test anything here. The FTPD shell test test/test_ftpd.sh was not run.

Dependencies

None. #41 (the console route in HTTPPRM0 and the MVSMF.CONSOLE profile) is merged; this branch carries only this commit on top of main.

mvsMF 1.4.x registers the diagnostic endpoint /zosmf/test only in
development builds, so a release answers 404 there and the version probe
of the image build fails. The setup check, the readiness probe of
mvsce-target, the mvsce CI workflow and the README read the level from
GET /zosmf/info (zosmf_full_version) instead. The setup check also asserts
that the console route answers 401 without a login and 200 for IBMUSER.

The image defines no JESSPOOL profile: the FTPD and mvsMF suites that test
the class expect it empty on a clean container.

@mgrossmann mgrossmann left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Review of a5a376d (head of #43).

Verified

  • mvsce/Dockerfile:80: MVSMF_VERSION=1.4.1; the README table at line 292 matches.
  • The switch from /zosmf/test?fn=version to /zosmf/info: mvsMF 1.4.1 ships /zosmf/test in development builds only (mvsMF docs/books/guide/ug-install.typ:398-401 at v1.4.1, "A release does not ... Use /zosmf/info to check a release"). zosmf_full_version is the documented field, and a development build ends in -dev (ug-first.typ:100-102). The -dev check in check_mvsmf is therefore a real guard, not a guess. /zosmf/info answers 401 without a credential (ug-install.typ:340), so every probe in this PR authenticates. All four probes (setup check, mvsce-target line 504, mvsce.yml line 92, Makefile line 22) are changed consistently; no /zosmf/test is left in the mvsce path.
  • mvsce/setup_mvsce.py:1063-1082 (check_console_route): the route in HTTPPRM0 (line 150) is AUTH=TOKEN RES=FACILITY:MVSMF.CONSOLE, the profile from #41 permits READ to IBMUSER only, and mvsMF 1.4.1 checks the same profile itself. 401 without a login and 200 for IBMUSER are the right expectations. urlopen raises HTTPError on 401, so the first branch is correct; fail() raises SystemExit, which is not caught by except HTTPError.
  • JESSPOOL decision (no profile): ftpd/test/test_ftpd.sh:3028-3029 on main fails with "PROFILES already has JESSPOOL lines; the test needs a clean container", and mvsMF tests/curl-jesspool.sh:245 at v1.4.1 does the same; tests/curl-consgate.sh:328 does it for MVSMF.CONSOLE. An image with pre-defined JESSPOOL profiles would break both suites, so leaving the class empty is the right call for a test image. The consequence (each user sees only its own jobs, administrators included, mvsMF docs/jesspool.md) is stated in the README at line 383.
  • Commit message: what and why, in English, one commit on top of main, no stack (#41 is merged).
  • Consumers: none of httpd, mvsmf, ftpd, ufsd has a workflow that uses mvsce-target (git grep -l mvsce origin/main -- .github/workflows is empty in all four), so this PR cannot break a CI of theirs. The local suite runs in the PR description cover the four projects on the tags the image ships.

Suggestion (not blocking)

  • mvsce/setup_mvsce.py:1067 and :1076: only HTTPError is caught. A URLError or a socket timeout (HTTPD gone between check_mvsmf and this check) would end the build with a traceback instead of fail(), so no log and printer tail and no herc.kill(). check_mvsmf catches Exception for exactly this reason; the same here would keep the diagnostics uniform. Unlikely on a build that just passed check_mvsmf, hence a suggestion.

Not in this PR, follow-ups

  • tk5/Dockerfile:30 still pins mvsMF 1.3.0 and tk5/setup_tk5.py:632 and .github/workflows/tk5.yml:88 still probe /zosmf/test?fn=version. Correct for 1.3.0; the day the TK5 image moves to 1.4.x it needs the same change. I open a separate issue for it.
  • The mvsMF suites curl-jesspool and curl-consgate skip on this image because the mbt target has no second user (MVSMF_USER2). The image never had one, so this is not a regression of this PR, but it means the two suites that test exactly what changed in 1.4.0 do not run here. Separate issue.

CI (Build mvsce, amd64 and arm64) is still running on a5a376d at the time of this review; the merge waits for it.

APPROVE

@mgrossmann mgrossmann left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Review of dd109bd (head of #43), after the APPROVE on a5a376d.

Verified

  • .github/workflows/mvsce.yml:120: the level check now matches "zosmf_full_version":"<level>", the compact form /zosmf/info returns. git grep '"version"' over the workflow, the Makefile and mvsce/ finds nothing else that still expects the old field. CI is green on both architectures (amd64 and arm64, 18:10 UTC).

Must fix

  • Commit message of dd109bd: the Co-Authored-By trailer names a tool and must not be in this repository's history (project rule: nothing of the kind in commits, code, docs or PR texts). A --merge keeps the commit as it is, so it has to be amended before the merge: reword the commit to drop the trailer (the first two paragraphs are fine as they are) and force-push the feature branch. CI runs again on the new head; the merge follows when it is green.

CHANGES REQUESTED

/zosmf/info reports the level as zosmf_full_version, compact JSON, so the
check against "version" failed on arm64 after the greeting and banner.
@mgrossmann
mgrossmann force-pushed the issue-42-mvsmf-1.4.1 branch from dd109bd to 78d29b7 Compare November 8, 2026 18:12

@mgrossmann mgrossmann left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Review of 78d29b7 (head of #43), after CHANGES REQUESTED on dd109bd.

Verified

  • git diff dd109bd 78d29b7 is empty: the tree is the one reviewed before; only the commit message changed.
  • Both commit messages (a5a376d, 78d29b7) say what and why in English and carry no trailer.
  • CI Build mvsce is green on 78d29b7 for amd64 and arm64 (18:21 UTC); mergeable, CLEAN.

APPROVE

@mgrossmann
mgrossmann merged commit c479a1f into main Nov 8, 2026
3 checks passed
@mgrossmann
mgrossmann deleted the issue-42-mvsmf-1.4.1 branch November 8, 2026 18:54
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.

mvsce: move mvsMF to 1.4.1 (JESSPOOL and MVSMF.CONSOLE profiles)

1 participant