{"id":36688377,"url":"https://github.com/converged-computing/flex-archspec","last_synced_at":"2026-01-12T11:16:59.025Z","repository":{"id":213869264,"uuid":"734891047","full_name":"converged-computing/flex-archspec","owner":"converged-computing","description":"Use fluxion Go bindings to request a machine architecture (under development)","archived":false,"fork":false,"pushed_at":"2023-12-23T19:50:28.000Z","size":25,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":2,"default_branch":"main","last_synced_at":"2025-09-10T05:37:02.440Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/converged-computing.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null}},"created_at":"2023-12-22T23:34:41.000Z","updated_at":"2023-12-22T23:35:40.000Z","dependencies_parsed_at":"2023-12-23T22:00:07.665Z","dependency_job_id":"bf1759fa-0985-4a3c-9815-92e63463cc32","html_url":"https://github.com/converged-computing/flex-archspec","commit_stats":null,"previous_names":["converged-computing/flex-archspec"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/converged-computing/flex-archspec","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/converged-computing%2Fflex-archspec","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/converged-computing%2Fflex-archspec/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/converged-computing%2Fflex-archspec/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/converged-computing%2Fflex-archspec/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/converged-computing","download_url":"https://codeload.github.com/converged-computing/flex-archspec/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/converged-computing%2Fflex-archspec/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28338970,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-12T10:58:46.209Z","status":"ssl_error","status_checked_at":"2026-01-12T10:58:42.742Z","response_time":98,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.5:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2026-01-12T11:16:58.159Z","updated_at":"2026-01-12T11:16:59.016Z","avatar_url":"https://github.com/converged-computing.png","language":"Go","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Flex Archspec\n\n\u003e Determine compatibility of your system with a container specification.\n\nContext: The [OCI compatibility working group](https://github.com/opencontainers/wg-image-compatibility) is designing a new artifact to determine container image compatibility with a host environment of interest. We would want to be able to represent a specific compatibility artifact as a graph. Starting with [Archspec](https://github.com/archspec) is a logic route in that we can locate our micro-architecture of interest in the tree, and then determine if it is compatible with some container.\n\n**Important** For current development, archspec json metadata requires a git submodule. I had to manually cd into the go directory where it was added and ensure it was cloned. E.g.,\n\n```bash\ngo get github.com/archspec/archspec-go\n# Your commit path may be different here\ncd /home/vscode/go/pkg/mod/github.com/archspec/archspec-go\\@v0.0.0-20231117085542-f806bb25b479/archspec\nsudo git clone https://github.com/archspec/archspec-json json\n```\n\nThis is reflected in [this issue](https://github.com/archspec/archspec-go/issues/13).\n\n## Design\n\n### Overview\n\nThe Flux Framework \"flux-sched\" or fluxion project provides modular bindings in different languages for intelligent,\ngraph-based scheduling. When we extend fluxion to a tool or project that warrants logic of this type, we call this a flex!\nThus, the project here demonstrates flex-archspec, or using fluxion to match some system request to what we know in the archspec graph. E.g.,\n\n\u003e Do you have an x86 system with this compiler option?\n\nThis is a simple use case that doesn't perfectly reflect the OCI container use case, but we need to start somewhere! For this very basic setup we are going to:\n\n1. Load the machines into a JSON Graph (called JGF).\n2. Try doing a query against system metadata\n\nThere will eventually be a third component - a container image specification, for which we need to include somewhere here. I am starting simple! \n\nUpdate: I have the graph loaded (and valid) and now need some help with understanding how it's traversed (e.g., and how to best query what I've represented, and if what I've represented is correct).\n\n\n### Concepts\n\nFrom the above, the following definitions might be useful.\n\n - **[Flux Framework](https://flux-framework.org)**: a modular framework for putting together a workload manager. It is traditionally for HPC, but components have been used in other places (e.g., here, Kubernetes, etc). It is analogous to Kubernetes in that it is modular and used for running batch workloads.\n - **[fluxion](fluxion)**: refers to [flux-framework/flux-sched](https://github.com/flux-framework/flux-sched) and is the scheduler component or module of Flux Framework. There are bindings in several languages, and specifically the Go bindings (server at [flux-framework/flux-k8s](https://github.com/flux-framework/flux-k8s)) assemble into the project \"fluence.\"\n - **flex** is an out of tree tool, plugin, or similar that uses fluxion to flexibly schedule or match some kind of graph-based resources. This project is an example of a flex!\n\n## Usage\n\n### Build\n\nThis demonstrates how to build the bindings. You will need to be in the VSCode developer container environment, or produce the same\non your host. Note that we are currently relying on several WIP branches (or need/suggest changes to fluxion or Go bindings):\n\n- We currently are using [this commit](https://github.com/researchapps/flux-sched/commit/0f33b17f6e792c14a262609d71f4ea5f32cb3ebb) that is a fork of [milroy's work](https://github.com/flux-framework/flux-sched/pull/1120) to ensure the module name matches what is added to go.mod.\n- That branch also has added better error parsing as shown in [this issue](https://github.com/flux-framework/flux-sched/issues/1128)\n\nWhen this is merged / the work is done, we will update to flux-framework/flux-sched. Below shows the make command that builds our final binary!\n\n```bash\nmake\n```\n```console\n# This needs to match the flux-sched install and latest commit, for now we are using a fork of milroy's branch\n# that has a go.mod updated to match the org name\n# go get -u github.com/researchapps/flux-sched/resource/reapi/bindings/go/src/fluxcli@86f5bb331342f2883b057920cf58e2c042aef881\ngo mod tidy\nmkdir -p ./bin\nGOOS=linux CGO_CFLAGS=\"-I/opt/flux-sched/resource/reapi/bindings/c\" CGO_LDFLAGS=\"-L/usr/lib -L/opt/flux-sched/resource -lfluxion-resource -L/opt/flux-sched/resource/libjobspec -ljobspec_conv -L//opt/flux-sched/resource/reapi/bindings -lreapi_cli -lflux-idset -lstdc++ -lczmq -ljansson -lhwloc -lboost_system -lflux-hostlist -lboost_graph -lyaml-cpp\" go build -ldflags '-w' -o bin/archspec src/cmd/main.go\n```\n\nThe output is generated in bin:\n\n```bash\n$ ls bin/\narchspec\n```\n\n### Run\n\nLet's provide a \nYou can provide your request for ice cream (e.g., icecream.yaml) and the description of the graph (in graphml). Note that we need shared libs on the path:\n\n```bash\nexport LD_LIBRARY_PATH=/usr/lib:/opt/flux-sched/resource:/opt/flux-sched/resource/reapi/bindings:/opt/flux-sched/resource/libjobspec\n```\n\n#### Ask for an ARM machine\n\n```bash\n./bin/archspec -spec ./examples/arm-machine.yaml\n```\n```console\n Match policy: first\n Load format: JSON Graph Format (JGF)\n\n✨️ Init context complete!\n💻️   Request: ./examples/arm-machine.yaml\n\n😍️ Your Machine Arch is Satisfiable!\nNumber: 1\n  Spec:\n{\"graph\": {\"nodes\": [{\"id\": \"63\", \"metadata\": {\"type\": \"arm\", \"basename\": \"arm\", \"name\": \"arm\", \"id\": 63, \"uniq_id\": 63, \"rank\": -1, \"exclusive\": true, \"unit\": \"\", \"size\": 1, \"paths\": {\"containment\": \"/machine/arm\"}}}, {\"id\": \"0\", \"metadata\": {\"type\": \"machine\", \"basename\": \"machine\", \"name\": \"machine\", \"id\": 0, \"uniq_id\": 0, \"rank\": -1, \"exclusive\": false, \"unit\": \"\", \"si\n```\n\nWhat I need to understand how to represent next is to query for an arbitrary attribute. E.g., right now I can't add something that would ask for a specific arm machine. The label in this selection seems to be relevant for labeling a spot in the graph (to count later). I need this because (as a user) I can't predict this path:\n\n```\n/machine/cannonlake46/cascadelake56/icelake\n```\n\nBut I could say \"give me a machine that is labeled with `power10le` and then it could query some graph like:\n\n```\n# The stars indicate any level of searching down machines\n/machine/*/*/label=icelake\n```\n\nI don't think this is possible to represent yet. We won't always have a nice structure like `/cluster/node/core` but, for example, multiple kinds of cores. For that example, the problem is that the user doesn't know the intermediate core names to \nquery, they just have the one they see at the bottom.\n\n#### Ask for an ARM machine \n\n#### Debugging\n\nBy default, we save the JGF to a temporary json file (and remove it), but to save to one you can later inspect the graph:\n\n```bash\n./bin/archspec -spec ./examples/machine.yaml --file ./machine-graph.json\n```\n\nNote that I'm including the example [machine-graph.json](machine-graph.json) for inspection - I suspect there is a detail wrong about the structure (and how I'm querying) and will need to look closer at the details.\n\n\n### Issues that need Work\n\n1. I can't query and ask for a custom attribute of interest\n2. Labels are confusing - they are in the JGF but in the jobspec seem to be a different thing to distinguish groups (to count)\n3. I don't have a way to search through an arbitrary level of machines in the graph to find one (at some level) with an attribute of interest.\n4. I'm forced to bi-directionally define every parent -\u003e child (target) with both containments (in and contains)\n\n## License\n\nHPCIC DevTools is distributed under the terms of the MIT license.\nAll new contributions must be made under this license.\n\nSee [LICENSE](https://github.com/converged-computing/cloud-select/blob/main/LICENSE),\n[COPYRIGHT](https://github.com/converged-computing/cloud-select/blob/main/COPYRIGHT), and\n[NOTICE](https://github.com/converged-computing/cloud-select/blob/main/NOTICE) for details.\n\nSPDX-License-Identifier: (MIT)\n\nLLNL-CODE- 842614\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fconverged-computing%2Fflex-archspec","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fconverged-computing%2Fflex-archspec","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fconverged-computing%2Fflex-archspec/lists"}