[arm64] Discourage or prevent installation of Rockons that are not available on the machines architecture #2191
Comments
|
@mcbridematt This is a most welcome addition and excellent preparatory work. Also way too many No entries there !! But enough Yes entries for sure. Re:
Yes I think that's the way to go, along with some automation if we can. And add to our Rock-on pull request template that we favour multi arch images and to add the new proposed element (see below):
I think we are agreed on this, it's going to be confusing if folks see Rock-ons available in one instance and not in another, different arch, instance. I'm sort of favouring a Rock-on definition extension myself. I know it's hard coded and potentially a maintenance wack-a-mole, but if we used something like your script to 'monitor' the JSON element re architecture with current state of the image referenced we might be able to have periodic updates of this automated, or just flagged as in need of update. But back to the point, I think it would be good to have the install button greyed out for non compatible options and some text indicating it's "Not (arch-here) compatible" type thing when the JSON element doesn't contain the instance machine architecture. That way a user still has all the info and links to report this incompatibility/unavailable nature to the docker authors say. And if we make the new JSON element optional it eases this features introduction, ie we don't have to back port to all definitions. But given your preparatory work here it may not be all that bad, but still, it would make for a more robust solution. @FroggyFlox as your the main Rock-ons management code contributor, this design decision would be in your ball park as it goes. Personally I'd favour a retro fit of a new arch element that lists compatible architectures and we add code that can handle this element not being found that defaults to 'finding' x86_64. That way we play safe and reduce the transition work by only having o update say aarch64 compatible Rock-ons first. Nice script by the way, thanks for sharing it. I could add the like of this to our backend management systems to flag changes in compatibility re the proposed element drifting from reality, We might even pop this in as a GitHub Action. Bit of a scatty arrangement all in but would work and would be fairly quick to setup, which is important in this case as arm64 is important to our immediate future and Rock-ons are a key element of Rockstor's bag. Comments on how we best proceed are most welcome. But lets keep things as simple as possible as it needs to be 'doable' with a limited human resource. Hence the simple additional JSON element idea as likely once an image is arm64 available it's likely to stay that way in virtually all cases. |
|
Thanks a lot, indeed, @mcbridematt ! @phillxnet , thanks for all your details as well... I'll try to bring some additional input on that. I agree with you that hiding an incompatible rock-on would lead to more problems than anything. Similarly, we need to keep compatibility in rock-on definition current rock-on definition files. I do concur with the idea of providing a feedback on the UI itself:
Regarding how to do it:
|
I'm not sure if it is just me, but 'docker manifest' does seem to take quite a while to grab the manifest information for each container image (about 5-10 seconds according to my stopwatch, on two different systems), so it may not be practical to run the architecture discovery on the 'client' (Rockstor install) side. There might be a faster way to do it (given there is no such delay when pulling arm versions of multi-arch images) but I'm not familiar enough with the Docker ecosystem to know. I agree indicating architecture availability in the JSON would be the best way. A year or two ago I would have suggested allowing a per-architecture container image override (allowing someone to recompile and rehost ARM versions OR cases where arm64 images are distributed as :arm64 tags) but I think there is enough momentum with multi-arch that the gap will narrow organically. |
|
@mcbridematt & @FroggyFlox Re
So we seem agreed that this would be pushing our luck, plus we have an outstanding 'sloppiness' where we pull docker info from our own repo way too often, apparently on each page refresh in some place. So we should really track that one down first and I doubt docker hub will like each and every one of our clients polling all our Rock-ons info and as stated, it just doesn't look practical from the observed timings (or polite really). So if we are, apparently, agreed on a Rock-on JSON extension that is optional, so we can piecemeal add it retrospectively to our growing list of Rock-ons, how fancies taking this one on. I'm afraid I wont be able to do it myself for a bit however as I've got a verging on unhealthy backlog to sort our re-release out. So if anyone fancies having a go at this, with the UI as indicated by @FroggyFlox with the basic function of blocking Rock-ons install by architecture, where that arch can be extended, but starting with allowing all on x86_64 and checking first if the JSON definition has AArch64 (our only other architecture planned currently) but with the capability to extend to other architectures, then that would be dandy. The most obvious additional JSON element in the Rock-on definition I'm thinking would be an Array so we can interpret in Python as a list and do a simple platform.machine() member check. But as this is a do-ocracy (within reason) the implementation is down to the doer :). What ever works, and fits nicely into the existing format, and is robust really. But that would seem to be the most basic approach and getting a working minimum implementation based on an extendable format looks like a plan. Once the format is sorted I can do some 'leg work' on retro fitting if need be. And if we are in the future able to retrieve reliable, and politely (with negligible overhead) the image definition, then we can always deprecate the JSON element and go a new way. |
|
@mcbridematt @FroggyFlox As of rockstor/rockon-registry#266 |
|
@mcbridematt @FroggyFlox & @Hooverdan96 Noting for context here that as from @Hooverdan96 work here: pr: '309 align architecture tags' rockstor/rockon-registry#310 All existing and future Rock-ons have their at-time-of-publish architecture compatibility within their description. I'll try and update the above table shortly, as we now have around 80 Rock-ons with the vast majority arm64 as well as amd64 compatible. |
|
Just wanted to raise the profile of this issue again. @Hooverdan96 clarification in descriptions is a step in the right direction, along with asserting this expectation in our README.md, but we have a little more to do on this front. Likely explicitly identifying via the Rock-on definition is my thinking. Allowing then for insertion in description (or better) and enabling an auto filter to show only compatible Rock-ons. |
|
would that be best done by introducing a separate tag in the json (with the subsequent database changes, views)? If yes, we should probably bundle that with discussions like exposing the image version tag (I unfortunately have a hard time finding where I/we logged this discussion some time ago) to reduce e.g. having explicit postgresql (or other db Rock-ons) for each version, but the user being able to pick up a version during install. Not sure there are other tags that were requested for other reasons ... I would assume in general, the effort would be less adding multiple (agreed upon) at one time vs. separating them all out? Though, also considering the one PR for one issue ... well, in any case, wanted to throw that out there, since we're so capacity constrained as it is. |
|
@Hooverdan96 Re:
Yes, that was my thinking. But I think introducing more changes that are just in-the-area are an over-stretch/scope creep really. Easier to manage smaller chunck was my thinking. And in this case we just have to transfer our descriptions to json tags. However @mcbridematt python script is curious: but again this could be used off-line as it were to just update this repo. Maybe by way off a GitHub task: once we have the new tag in place that is. The related but tangential question of latest/etc is I think best approached seperately as it's mostly unrelated, but not entirely of course as some docker tag may have arm64 and another not: but currently we have nothing to inform the Web-UI what to address other than the excellent description additions you did more recently. So just moving them to an official tag and is complex enough given backward compatibility: but you have now normalized them all so we could just do a stip of description if an arch tag is provided: to avoid duplication and enable older Rockstors to benefit from your prior description work. |
The good news is that Rock-ons work happily on arm64 as long as the containers used have multi-arch manifests.
If not, the user may not find this out until they attempt to install a Rockon.
If the published Docker image only has a v1 (non-multiarch) manifest then Docker will pull the image regardless and the user will be greeted by an "exec-format-error".
(Edit to further clarify: Docker will pull the correct image for the machines architecture, if one exists. So you can do
docker run -i -t opensuse/leapand get the correct container for your system. The problem is that if the Docker registry only has a v1 (non-multiarch) image then it will go ahead, pull and attempt to run it)(Sidenote: If a user really wants to run an x86 container on their arm64 system, or vice versa, they can use qemu-binfmt emulation)
Some possible ways this could be tackled:
For example, LinuxServer.io now publishes multi-arch images and would be an alternative for some applications where the official images do not support arm64.
(Users may wonder why a Rockon is missing)
I wrote up a script to check which Rockons will work on arm64:
https://gist.github.com/mcbridematt/54d51ed813e6910b9244ce3c7d149e51
(This doesn't have to be run on an arm64 system - it merely checks the manifests to see if an arm64 container is published)
The text was updated successfully, but these errors were encountered: