Upgrade maven plugin versions inside kogito-runtimes

Inside kogito runtimes (kogito-build-no-bom-parent/pom.xml).  , upgrade versions for
maven-jar-plugin -> 3.2.0
maven-source-plugin -> 3.2.1
This will lead to build failure due to missing java.module.name property in some modules, that should be fixed
e.g.
  <properties>
    <java.module.name>org.kie.kogito.common.workitems</java.module.name>
  </properties>

Needed by https://github.com/apache/incubator-kie-issues/issues/820
Requires

https://github.com/apache/incubator-kie-issues/issues/825
https://github.com/apache/incubator-kie-issues/issues/826

https://github.com/apache/incubator-kie-kogito-runtimes/pull/3355

Fixed by https://github.com/apache/incubator-kie-kogito-runtimes/pull/3355


Fail to build file-tree-viewer

Hi,
I fail hard building a file-tree viewer.
The idea is to build a nested ListView, but the first nesting does not get expanded:

Do you have any ideas? I could share the source, if it is really necessary (Or just share the module where I defined my helper type).

ListView is currently a work-in-progress, and still has some severe limitations: for instance, it can only contain views that are 1-line high (it was mostly intended for forms). :(
A more general-purpose GridView is planned~ish.
In the meantime, you can either:

Not nest listviews, but add "indented" items to the main list view.
Write a custom view for file tree navigation
Show the nested tree in a separate listview in a popup (or in a separate panel)

Small heads up, I'm currently working on a tree view implementation :)
It isn't 100% there just yet but should be finished within the next few days.
The view is generic over anything that implements fmt::Display + fmt::Debug but you'll have to handle any advanced stuff yourself as the API is really low level (insert, remove, collapse operations are all based on row indices).
There's also a file viewer example which lazily loads an inserts the directory contents once they are unfolded by the user :)
As stated above still WIP, so expect panics and dead kittens for the time being.


Update to use @sentry/browser, remove raven-js

I'm curious if sentry is something that needs to be imported and initialized in a special way instead of being a part of the webpack bundle.
I once had a Next.js app that was silently crashing on the client-side on some old Android devices – that happened because Intl was not polyfiled. Finding the bug was only possible because I had google analytics script, which sent a custom event on window.onerror (the users just saw a static server-rendered websites). Should Sentry be something that's fetched from CDN like in good old days?


Thread safety

Codecov Report

Merging #10 into master will decrease coverage by 0.41%.
The diff coverage is 100%.

@@            Coverage Diff            @@
##           master     #10      +/-   ##
=========================================
- Coverage   97.81%   97.4%   -0.42%
=========================================
  Files          18      18
  Lines         688     693       +5
=========================================
+ Hits          673     675       +2
- Misses         15      18       +3

Flag
Coverage Δ

#ios
?

#macos
97.25% <100%> (-0.28%)
:arrow_down:

#tvos
97.4% <100%> (-0.42%)
:arrow_down:

Impacted Files
Coverage Δ

Sources/Conditions/ExclusivityManager.swift
100% <100%> (ø)
:arrow_up:

Sources/Operations/DelayOperation.swift
100% <100%> (ø)
:arrow_up:

Sources/AdvancedOperation.swift
98.86% <100%> (-0.37%)
:arrow_down:

Sources/AdvancedBlockOperation.swift
88.23% <0%> (-11.77%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d536e2a...003f8d9. Read the comment docs.


probability generator js first pass

added all the baseline code for the building of data tables, did not include the code for reading the names in, only the code for turning names into probability data points in arrays

Its a little hard to tell what you added since you pulled from my branch that is currently in PR (and it hasn't been merged yet). I would add something in your description that says "Don't merge until PR#3 is merged", and also something stating which files specifically you modified in this PR. Once #3 is merged I will give this PR a deeper look.


[Performance] Fix NightHawk load generator

Notes for Reviewers
This PR fixes #
Signed commits

[ ] Yes, I signed my commits.

@Abhishek-kumar09 The results with NightHawk are not being rendered on UI, UI is crashing.
Will you look at the UI?
Since for all 3 load generators, we transform the o/p in a similar way, UI should have been able to do that.
Let me know if this is a backend issue.


Improve OpenSSF Scorecard checks

Summary
Closely related to #9769 and #11953
Can see our scores for OpenSSF Scorecard from the badge link here: https://api.securityscorecards.dev/projects/github.com/argoproj/argo-workflows
Overall Score: 6.5
  Scorecard JSON output, pretty-printed
{
  "date": "2023-10-16",
  "repo": {
    "name": "github.com/argoproj/argo-workflows",
    "commit": "165f57fd1b40256cdd41c41cf3fc2b9e4664c9fe"
  },
  "scorecard": {
    "version": "v4.13.0-21-g8eaf0d76",
    "commit": "8eaf0d7647a3f50d80615812c72a277fd568fb6d"
  },
  "score": 6.5,
  "checks": [
    {
      "name": "Maintained",
      "score": 10,
      "reason": "30 commit(s) out of 30 and 18 issue activity out of 30 found in the last 90 days -- score normalized to 10",
      "details": null,
      "documentation": {
        "short": "Determines if the project is \"actively maintained\".",
        "url": "https://github.com/ossf/scorecard/blob/8eaf0d7647a3f50d80615812c72a277fd568fb6d/docs/checks.md#maintained"
      }
    },
    {
      "name": "Code-Review",
      "score": 10,
      "reason": "all changesets reviewed",
      "details": null,
      "documentation": {
        "short": "Determines if the project requires human code review before pull requests (aka merge requests) are merged.",
        "url": "https://github.com/ossf/scorecard/blob/8eaf0d7647a3f50d80615812c72a277fd568fb6d/docs/checks.md#code-review"
      }
    },
    {
      "name": "License",
      "score": 10,
      "reason": "license file detected",
      "details": [
        "Info: License file found in expected location: LICENSE:1",
        "Info: FSF or OSI recognized license: LICENSE:1"
      ],
      "documentation": {
        "short": "Determines if the project has defined a license.",
        "url": "https://github.com/ossf/scorecard/blob/8eaf0d7647a3f50d80615812c72a277fd568fb6d/docs/checks.md#license"
      }
    },
    {
      "name": "CII-Best-Practices",
      "score": 5,
      "reason": "badge detected: passing",
      "details": null,
      "documentation": {
        "short": "Determines if the project has an OpenSSF (formerly CII) Best Practices Badge.",
        "url": "https://github.com/ossf/scorecard/blob/8eaf0d7647a3f50d80615812c72a277fd568fb6d/docs/checks.md#cii-best-practices"
      }
    },
    {
      "name": "Branch-Protection",
      "score": -1,
      "reason": "internal error: error during branchesHandler.setup: internal error: githubv4.Query: Resource not accessible by integration",
      "details": null,
      "documentation": {
        "short": "Determines if the default and release branches are protected with GitHub's branch protection settings.",
        "url": "https://github.com/ossf/scorecard/blob/8eaf0d7647a3f50d80615812c72a277fd568fb6d/docs/checks.md#branch-protection"
      }
    },
    {
      "name": "Signed-Releases",
      "score": 8,
      "reason": "5 out of 5 artifacts are signed or have provenance",
      "details": [
        "Warn: release artifact v3.5.0 does not have provenance: https://api.github.com/repos/argoproj/argo-workflows/releases/124999540",
        "Info: signed release artifact: argo-workflows-cli-checksums.sig: https://api.github.com/repos/argoproj/argo-workflows/releases/assets/130455044",
        "Warn: release artifact v3.5.0-rc2 does not have provenance: https://api.github.com/repos/argoproj/argo-workflows/releases/121928138",
        "Info: signed release artifact: argo-workflows-cli-checksums.sig: https://api.github.com/repos/argoproj/argo-workflows/releases/assets/126960660",
        "Warn: release artifact v3.4.11 does not have provenance: https://api.github.com/repos/argoproj/argo-workflows/releases/120364554",
        "Info: signed release artifact: argo-workflows-cli-checksums.sig: https://api.github.com/repos/argoproj/argo-workflows/releases/assets/125063416",
        "Warn: release artifact v3.5.0-rc1 does not have provenance: https://api.github.com/repos/argoproj/argo-workflows/releases/117361096",
        "Info: signed release artifact: argo-workflows-cli-checksums.sig: https://api.github.com/repos/argoproj/argo-workflows/releases/assets/121637664",
        "Warn: release artifact v3.4.10 does not have provenance: https://api.github.com/repos/argoproj/argo-workflows/releases/117350773",
        "Info: signed release artifact: argo-workflows-cli-checksums.sig: https://api.github.com/repos/argoproj/argo-workflows/releases/assets/121631838"
      ],
      "documentation": {
        "short": "Determines if the project cryptographically signs release artifacts.",
        "url": "https://github.com/ossf/scorecard/blob/8eaf0d7647a3f50d80615812c72a277fd568fb6d/docs/checks.md#signed-releases"
      }
    },
    {
      "name": "Security-Policy",
      "score": 10,
      "reason": "security policy file detected",
      "details": [
        "Info: security policy file detected: SECURITY.md:1",
        "Info: Found linked content: SECURITY.md:1",
        "Info: Found disclosure, vulnerability, and/or timelines in security policy: SECURITY.md:1",
        "Info: Found text in security policy: SECURITY.md:1"
      ],
      "documentation": {
        "short": "Determines if the project has published a security policy.",
        "url": "https://github.com/ossf/scorecard/blob/8eaf0d7647a3f50d80615812c72a277fd568fb6d/docs/checks.md#security-policy"
      }
    },
    {
      "name": "Dangerous-Workflow",
      "score": 10,
      "reason": "no dangerous workflow patterns detected",
      "details": null,
      "documentation": {
        "short": "Determines if the project's GitHub Action workflows avoid dangerous patterns.",
        "url": "https://github.com/ossf/scorecard/blob/8eaf0d7647a3f50d80615812c72a277fd568fb6d/docs/checks.md#dangerous-workflow"
      }
    },
    {
      "name": "Pinned-Dependencies",
      "score": -1,
      "reason": "internal error: error parsing shell code: Dockerfile.windows:1:5: (( can only be used to open an arithmetic cmd",
      "details": null,
      "documentation": {
        "short": "Determines if the project has declared and pinned the dependencies of its build process.",
        "url": "https://github.com/ossf/scorecard/blob/8eaf0d7647a3f50d80615812c72a277fd568fb6d/docs/checks.md#pinned-dependencies"
      }
    },
    {
      "name": "Token-Permissions",
      "score": 0,
      "reason": "detected GitHub workflow tokens with excessive permissions",
      "details": [
        "Info: topLevel 'contents' permission set to 'read': .github/workflows/changelog.yaml:9",
        "Warn: jobLevel 'contents' permission set to 'write': .github/workflows/changelog.yaml:16: Verify which permissions are needed and consider whether you can reduce them. (High effort)",
        "Info: topLevel 'contents' permission set to 'read': .github/workflows/ci-build.yaml:17",
        "Info: topLevel 'contents' permission set to 'read': .github/workflows/dependabot-reviewer.yml:6",
        "Warn: jobLevel 'contents' permission set to 'write': .github/workflows/dependabot-reviewer.yml:13: Verify which permissions are needed and consider whether you can reduce them. (High effort)",
        "Warn: topLevel 'contents' permission set to 'write': .github/workflows/docs.yaml:16: Visit https://app.stepsecurity.io/secureworkflow/argoproj/argo-workflows/docs.yaml/master?enable=permissions\nTick the 'Restrict permissions for GITHUB_TOKEN'\nUntick other options\nNOTE: If you want to resolve multiple issues at once, you can visit https://app.stepsecurity.io/securerepo instead. (Low effort)",
        "Warn: no topLevel permission defined: .github/workflows/pr.yaml:1: Visit https://app.stepsecurity.io/secureworkflow/argoproj/argo-workflows/pr.yaml/master?enable=permissions\nTick the 'Restrict permissions for GITHUB_TOKEN'\nUntick other options\nNOTE: If you want to resolve multiple issues at once, you can visit https://app.stepsecurity.io/securerepo instead. (Low effort)",
        "Info: topLevel 'contents' permission set to 'read': .github/workflows/release.yaml:20",
        "Warn: jobLevel 'contents' permission set to 'write': .github/workflows/release.yaml:278: Verify which permissions are needed and consider whether you can reduce them. (High effort)",
        "Info: topLevel 'contents' permission set to 'read': .github/workflows/sdks.yaml:8",
        "Warn: jobLevel 'packages' permission set to 'write': .github/workflows/sdks.yaml:15: Verify which permissions are needed and consider whether you can reduce them. (High effort)",
        "Warn: jobLevel 'contents' permission set to 'write': .github/workflows/sdks.yaml:16: Verify which permissions are needed and consider whether you can reduce them. (High effort)",
        "Info: topLevel 'contents' permission set to 'read': .github/workflows/snyk.yml:11"
      ],
      "documentation": {
        "short": "Determines if the project's workflows follow the principle of least privilege.",
        "url": "https://github.com/ossf/scorecard/blob/8eaf0d7647a3f50d80615812c72a277fd568fb6d/docs/checks.md#token-permissions"
      }
    },
    {
      "name": "SAST",
      "score": 0,
      "reason": "SAST tool is not run on all commits -- score normalized to 0",
      "details": [
        "Warn: 0 commits out of 30 are checked with a SAST tool",
        "Warn: CodeQL tool not detected"
      ],
      "documentation": {
        "short": "Determines if the project uses static code analysis.",
        "url": "https://github.com/ossf/scorecard/blob/8eaf0d7647a3f50d80615812c72a277fd568fb6d/docs/checks.md#sast"
      }
    },
    {
      "name": "Fuzzing",
      "score": 0,
      "reason": "project is not fuzzed",
      "details": [
        "Warn: no OSSFuzz integration found: Follow the steps in https://github.com/google/oss-fuzz to integrate fuzzing for your project.\nOver time, try to add fuzzing for more functionalities of your project. (High effort)",
        "Warn: no OneFuzz integration found: Follow the steps in https://github.com/microsoft/onefuzz to start fuzzing for your project.\nOver time, try to add fuzzing for more functionalities of your project. (High effort)",
        "Warn: no GoBuiltInFuzzer integration found: Follow the steps in https://go.dev/doc/fuzz/ to enable fuzzing on your project.\nOver time, try to add fuzzing for more functionalities of your project. (Medium effort)",
        "Warn: no PythonAtherisFuzzer integration found: Follow the steps in https://github.com/google/atheris to enable fuzzing on your project.\nOver time, try to add fuzzing for more functionalities of your project. (Medium effort)",
        "Warn: no CLibFuzzer integration found: Follow the steps in https://llvm.org/docs/LibFuzzer.html to enable fuzzing on your project.\nOver time, try to add fuzzing for more functionalities of your project. (Medium effort)",
        "Warn: no CppLibFuzzer integration found: Follow the steps in https://llvm.org/docs/LibFuzzer.html to enable fuzzing on your project.\nOver time, try to add fuzzing for more functionalities of your project. (Medium effort)",
        "Warn: no SwiftLibFuzzer integration found: Follow the steps in https://google.github.io/oss-fuzz/getting-started/new-project-guide/swift-lang/ to enable fuzzing on your project.\nOver time, try to add fuzzing for more functionalities of your project. (Medium effort)",
        "Warn: no RustCargoFuzzer integration found: Follow the steps in https://rust-fuzz.github.io/book/cargo-fuzz.html to enable fuzzing on your project.\nOver time, try to add fuzzing for more functionalities of your project. (Medium effort)",
        "Warn: no JavaJazzerFuzzer integration found: Follow the steps in https://github.com/CodeIntelligenceTesting/jazzer to enable fuzzing on your project.\nOver time, try to add fuzzing for more functionalities of your project. (Medium effort)",
        "Warn: no ClusterFuzzLite integration found: Follow the steps in https://github.com/google/clusterfuzzlite to integrate fuzzing as part of CI.\nOver time, try to add fuzzing for more functionalities of your project. (High effort)",
        "Warn: no HaskellPropertyBasedTesting integration found: Use one of the following frameworks to fuzz your project:\nQuickCheck: https://hackage.haskell.org/package/QuickCheck\nhedgehog: https://hedgehog.qa/\nvalidity: https://github.com/NorfairKing/validity\nsmallcheck: https://hackage.haskell.org/package/smallcheck\nhspec: https://hspec.github.io/\ntasty: https://hackage.haskell.org/package/tasty (High effort)",
        "Warn: no TypeScriptPropertyBasedTesting integration found: Use fast-check: https://github.com/dubzzz/fast-check (High effort)",
        "Warn: no JavaScriptPropertyBasedTesting integration found: Use fast-check: https://github.com/dubzzz/fast-check (High effort)"
      ],
      "documentation": {
        "short": "Determines if the project uses fuzzing.",
        "url": "https://github.com/ossf/scorecard/blob/8eaf0d7647a3f50d80615812c72a277fd568fb6d/docs/checks.md#fuzzing"
      }
    },
    {
      "name": "Binary-Artifacts",
      "score": 10,
      "reason": "no binaries found in the repo",
      "details": null,
      "documentation": {
        "short": "Determines if the project has generated executable (binary) artifacts in the source repository.",
        "url": "https://github.com/ossf/scorecard/blob/8eaf0d7647a3f50d80615812c72a277fd568fb6d/docs/checks.md#binary-artifacts"
      }
    },
    {
      "name": "Packaging",
      "score": 10,
      "reason": "publishing workflow detected",
      "details": [
        "Info: GitHub/GitLab publishing workflow used in run https://api.github.com/repos/argoproj/argo-workflows/actions/runs/6540276280: .github/workflows/ci-build.yaml:36"
      ],
      "documentation": {
        "short": "Determines if the project is published as a package that others can easily download, install, easily update, and uninstall.",
        "url": "https://github.com/ossf/scorecard/blob/8eaf0d7647a3f50d80615812c72a277fd568fb6d/docs/checks.md#packaging"
      }
    },
    {
      "name": "Vulnerabilities",
      "score": 0,
      "reason": "17 existing vulnerabilities detected",
      "details": [
        "Warn: Project is vulnerable to: GO-2022-0646",
        "Warn: Project is vulnerable to: GHSA-67hx-6x53-jw92",
        "Warn: Project is vulnerable to: GHSA-q8gg-vj6m-hgmj",
        "Warn: Project is vulnerable to: GHSA-w573-4hg7-7wgq",
        "Warn: Project is vulnerable to: GHSA-3wcq-x3mq-6r9p",
        "Warn: Project is vulnerable to: GHSA-74fj-2j2h-c42q",
        "Warn: Project is vulnerable to: GHSA-pw2r-vq6v-hr8c",
        "Warn: Project is vulnerable to: GHSA-43f8-2h32-f4cj",
        "Warn: Project is vulnerable to: GHSA-f4c9-cqv8-9v98",
        "Warn: Project is vulnerable to: GHSA-896r-f27r-55mw",
        "Warn: Project is vulnerable to: GHSA-f8q6-p94x-37v3",
        "Warn: Project is vulnerable to: GHSA-hrpp-h998-j3pp",
        "Warn: Project is vulnerable to: GHSA-p8p7-x288-28g6",
        "Warn: Project is vulnerable to: GHSA-72xf-g2v4-qvf3",
        "Warn: Project is vulnerable to: GHSA-g78m-2chm-r7qv",
        "Warn: Project is vulnerable to: GHSA-j8xg-fqg3-53r7",
        "Warn: Project is vulnerable to: GHSA-6fc8-4gx4-v693"
      ],
      "documentation": {
        "short": "Determines if the project has open, known unfixed vulnerabilities.",
        "url": "https://github.com/ossf/scorecard/blob/8eaf0d7647a3f50d80615812c72a277fd568fb6d/docs/checks.md#vulnerabilities"
      }
    }
  ]
}

More specifically, here's a few scores to improve:

[ ] Branch Protection - Score: -1

This currently gets an error: internal error: error during branchesHandler.setup: internal error: githubv4.Query: Resource not accessible by integration. I don't think we can actually improve this as it requires an admin PAT to check that branch protection is set properly. Unless there's something new with the branch rules feature that allows them to be checked publicly

EDIT: Ok actually it turns out rulesets are publicly viewable, so changing to those may make this check pass

[ ] Signed Releases - Score: 8

We need to add provenance to our releases, which should also get us to SLSA Level 3. I'll probably file a separate issue for this to summarize some of the work for that that I've started on and collabbed with CD and SIG Security folks on

[ ] Pinned Dependencies - Score: -1

This is actually giving an error, not sure why though: internal error: error parsing shell code: Dockerfile.windows:1:5: (( can only be used to open an arithmetic cmd

I believe it's erroring on parsing Windows PowerShell; it likely assumes Linux shell and therefore can't parse the Windows commands properly
EDIT: Asked about this in CNCF #security-slam Slack, hoping there's a way to ignore it maybe? Or maybe it should auto-detect Windows PowerShell

Our dependencies for JS and Go are all pinned, but I think we could improve Dockerfiles by using digests and GitHub Actions by using SHAs (as both have mutable tags, so a SemVer number could just be arbitrarily changed by an attacker)

[x] Token Permissions - Score: 0

These just need some tiny modifications so that top-level is always read-only and only jobs that need them specify other permissions. We have some GH Action Workflows that are just one job, so this just makes those more secure in case another job were to be added.
EDIT: Completed in #12035

[ ] SAST - Score: 0

Should just add a CodeQL Workflow to our GH Actions, similar to Argo CD

[ ] Fuzzing - Score: 0

Easier said than done and possibly the most difficult one on the list. That being said, CNCF and Ada Logics had already added some fuzz tests during their security audit for CNCF graduation. This is something we are missing in Argo CD as well -- I detailed a good bit here: https://github.com/argoproj/argo-cd/pull/11146#issuecomment-1763503353

[x] Vulnerabilities - Score: 0

We may need to add an osv-scanner.toml to mark some of these as not impacting / ignored.
EDIT: UI deps (which is all but one) completed in #12036 and #12058

For Go deps, see https://github.com/argoproj/pkg/pull/529. We could potentially ignore this with osv-scanner.toml as we don't use the vulnerable functionality, but I decided to update instead since it was straightforward enough and should be done eventually anyway

Use Cases
OpenSSF is being pushed by Google and CNCF and is also part of CLOMonitor checks that are similarly pushed. We have badges for these already, so we should strive to improve our scores on them.
We should also aim to have a more secure, trusted supply chain, which OpenSSF checks help us to achieve.

Message from the maintainers:
Love this enhancement proposal? Give it a 👍. We prioritise the proposals with the most 👍.

Some results are in and after #12035, #12036, and #12058, our Overall Score is now 8.3! Nearly 2 points higher 🙂


[BUG]: AttributeError: 'ColossalAIStrategy' object has no attribute 'prepare'

🐛 Describe the bug
上周我跑过单机的benchmark_gpt_dummy.py都是正常的，今天同步了最近的更新后，跑benchmark_gpt_dummy.py或者train_prompts.py都会报object has no attribute 'prepare'这个错误
Environment
No response

Thanks for your feedback .
Suggest you to do 'pip instal . ' in Chatgpt file , after you update the code.

I'm going to close this issue, if you have any problems about this issue ,please reopen it. Thanks.


Coverage notebooks

Changes
measure code coverage in notebooks
Related Issues
Closes #264

the individual coverage reports are in place (doc/tutorials) but are not being recognized by the codecov action. Eventually these needs to be converted and merged into a single xml file?

nice to see notebook coverage 👍
since this currently runs in the docs context it might be difficult to merge the different coverage reports
maybe we could integrate it in the pytest action instead using nbval ?
maybe only use a single pytest setup of the matrix to run the "full" test suite including notebooks?

nbval is used to perform regression tests for notebooks (e.g. compare the output stored in the notebook with the actual execution results). Eventually one can turn this feature completely off. I will check it out.

yes we don't need the output comparison, so should py.test --nbval-lax be enough https://github.com/computationalmodelling/nbval/#execution

I put the coverage measurement in the docs job in order not to increase the testing time, since the notebooks are executed in docs as well. I'm pretty sure that codecov will pick this up correctly, once I sort out the mistake about the missing files.
Using nbval on the other hand has the advantage of an already well established infrastructure.

I tried hard not to have a pyproject.toml file in addition to setup.cfg but that's fine if this makes it simpler somehow 😉

using a pyproject.toml file to declare the build system (e.g. setuptools_scm gets installed before accessing the version number), somehow the picked up package structure is faulty, as it only contains the very top level, but not split up modules like vis and trans.

I think this should be ready to go. The coverage actually decreases now, because I removed some "pragma: no cover" for tools, which actually can now be tested. I can also try to invoke them in the tutorials at a suitable spot.

I tried hard not to have a pyproject.toml file in addition to setup.cfg but that's fine if this makes it simpler somehow wink

May I know why did you want to avoid it?

I tried hard not to have a pyproject.toml file in addition to setup.cfg but that's fine if this makes it simpler somehow wink

May I know why did you want to avoid it?

Just trying to keep everything in one place as much as possible to avoid duplications

my final suggestion would be to only run the notebooks and coverage report/action on a single os (and python version) to save a little time on the slower runs, like so:
      - name: run pytest on notebooks (append coverage)
        if: (matrix.os == 'ubuntu-latest') && (matrix.py == '3.8')
        run: |
          pytest -n2 --dist loadscope --nbval --current-env --cov=weldx --cov-append tutorials/
          echo "Exited with '$?'"

      - name: coverage xml (combination is performed by pytest-cov)
        if: (matrix.os == 'ubuntu-latest') && (matrix.py == '3.8')
        run: coverage xml

      - name: codecov.io
        if: (matrix.os == 'ubuntu-latest') && (matrix.py == '3.8')
        uses: codecov/codecov-action@v1

what do you think @vhirtham @marscher ?

I also set the default mutiprocessing option to -n auto, I think this is reasonable for local runs as well, what do you think @marscher ?
09dd241d7546fd673cf1b6e2769df3e7b6931655

I agree, we should run this only the "latest" configuration to save resources.

Scared about what happens to the coverage afterward, but we can probably remove - "weldx/visualization/*" from the codecov.yml too

Scared about what happens to the coverage afterward, but we can probably remove - "weldx/visualization/*" from the codecov.yml too 😨

only one way to find out .. f5c582c58cddbc71d6cedf1328f84156dc14dcc3 😉

What is your concern here? Do you consider "coverage" only unit tested code and therefore an integration test like the notebooks are not in this scope?

What is your concern here? Do you consider "coverage" only unit tested code and therefore an integration test like the notebooks are not in this scope?

Think you missed the irony. 😉 I have no concerns. I just wanted to point out, that the visualization package is (was) still ignored due to the codecov.yml and that the coverage will further plummet after removing the corresponding lines 😛


Format of string in console.

Hi, i have a little problem with the format output in console. this is my output.
[2015-12-10 14:44:59.071] AppDelegate.application(_:didFinishLaunchingWithOptions:):24 [fg200,200,200;VERBOSE[;: Nothing really happened

i have installed XcodeColors and use the las version of SwiftyBeaver (Manually)

That looks like XcodeColors is not working. Can you reinstall the latest version of it and try again.

Thanks, yes, some happen with XcodeColors colors


[flash_ctrl] RMA Questions

I have a few open questions on the RMA Functionality of the Flash Controller
Firstly, on the whole it seems to operate as expected.  Once RMA is entered, the Flash is Erased and then overwritten (as viewed in the waves, and our test for this feature.  This is good news.
Question 1 - DUT Status after RMA Request
Spec says: -
"Unlike the seed phase, after the RMA phase, the flash controller does not grant
control back to software as the system is expected to reboot after an RMA
attempt."
Testplan Says: -
Perform RMA entry request and check afterwards that software has no granted access.
I have observed that after the RMA has completed and  acknowledged, MOST of the Flash Ctrl registers ARE available (can be read at least), there are only access issues when accessing the CONTROL Register and the FIFO locations.
I thought I would try this to see what happened.  So what is meant by the spec is that after RMA the 'Flash Contents' are not granted to Software' .. just to confirm?
If I attempt to program the CONTROL register after RMA I get a TestBench error.
Probaby a question for the Veification Guys:-
The current TB (mostly inherited), using the TL code, etc), when I try to access the CONTROL register I get a bus access error, which is fine, except that I don't want the test to fail immediately, I want to check the error that has occured.  The autofail mechanism seems inbuilt, I was wondering if there was anyway of turning this off temporarily via the test?
I have also seen errors from the scoreboard after reset (after RMA and attempted access), in that the scoreboard has an outstanding transaction pending that was never sent by the DUT due to the access restriction.
I am trying out a few ideas of my own, but was wondering if anyone else knew of this?

I have a few open questions on the RMA Functionality of the Flash Controller
Firstly, on the whole it seems to operate as expected. Once RMA is entered, the Flash is Erased and then overwritten (as viewed in the waves, and our test for this feature. This is good news.
Question 1 - DUT Status after RMA Request
Spec says: - "Unlike the seed phase, after the RMA phase, the flash controller does not grant control back to software as the system is expected to reboot after an RMA attempt."
Testplan Says: - Perform RMA entry request and check afterwards that software has no granted access.
I have observed that after the RMA has completed and acknowledged, MOST of the Flash Ctrl registers ARE available (can be read at least), there are only access issues when accessing the CONTROL Register and the FIFO locations.
I thought I would try this to see what happened. So what is meant by the spec is that after RMA the 'Flash Contents' are not granted to Software' .. just to confirm?

Thank you for bringing this point up. The part about the system no longer being accessible is actually not accomplished by the flash. When doing an RMA transition, the system sequence is as follows:
lc_ctrl -> flash_ctrl -> otp_ctrl.
So the life cycle controller makes the request, the flash controller wipes the contents and finally the otp controller does the RMA transition.  Once the transition is made, the life cycle controller renders the system inoperable.  However the flash controller itself does not do anything at the moment.  Let me enhance this to at least make the flash memory inaccessible so there is something you can test against.

If I attempt to program the CONTROL register after RMA I get a TestBench error.

actually i am somewhat surprised you're even getting an error when accessing CONTROL.  Can you push whatever you have so I can run it and examine?

Probaby a question for the Veification Guys:-
The current TB (mostly inherited), using the TL code, etc), when I try to access the CONTROL register I get a bus access error, which is fine, except that I don't want the test to fail immediately, I want to check the error that has occured. The autofail mechanism seems inbuilt, I was wondering if there was anyway of turning this off temporarily via the test?
I have also seen errors from the scoreboard after reset (after RMA and attempted access), in that the scoreboard has an outstanding transaction pending that was never sent by the DUT due to the access restriction.
I am trying out a few ideas of my own, but was wondering if anyone else knew of this?

Hi Tim
Thanks for the reply.
I have checked in a version of my test repositry
The reposirty branch is
https://github.com/TimEwins/opentitan/tree/host_crl_hw_if2
What this test does is
Reset
Intitialise
Erase
Program (data1)
Read (data1)
RMA Request
Check SW has no access to the Flash (CONTROL Reg)
Reset
Read (data2) .. compare data2 != data1
What happens after the RMA Request is completed, is that I program ADDR, and then the CONTROL register. I then poll/wait for completion.  This times out (assumed this means no access granted).  I trap this event, but then after reset I get an error (from the TL Driver) saying that there is an outstanding transaction (i.e I requested something, but it didn't happen)
This is kind of what I expected.
In advance of any potential RTL changes, just clearing down that Driver issue would fix this.
The command to run is
./util/dvsim/dvsim.py hw/ip/flash_ctrl/dv/flash_ctrl_sim_cfg.hjson -i host_ctrl_hw_if --tool xcelium -v h --fixed-seed 1 --max-parallel 1 --purge --verbosity m
The test takes about 12 mins to run
The output to console is
UVM_INFO @ 687926867 ps: (host_ctrl_hw_if_vseq.sv:146) uvm_test_top.env.virtual_sequencer [uvm_test_top.env.virtual_sequencer.host_ctrl_hw_if_vseq] RMA REQUEST
UVM_INFO @ 687926867 ps: (flash_ctrl_base_vseq.sv:638) uvm_test_top.env.virtual_sequencer [uvm_test_top.env.virtual_sequencer.host_ctrl_hw_if_vseq] RMA Request Start
UVM_INFO @ 687926867 ps: (flash_ctrl_base_vseq.sv:639) uvm_test_top.env.virtual_sequencer [uvm_test_top.env.virtual_sequencer.host_ctrl_hw_if_vseq] RMA Seed : 0x037a7efc
UVM_INFO @<PHONE_NUMBER>07 ps: (flash_ctrl_base_vseq.sv:653) uvm_test_top.env.virtual_sequencer [uvm_test_top.env.virtual_sequencer.host_ctrl_hw_if_vseq] RMA Request Complete
UVM_INFO @<PHONE_NUMBER>07 ps: (host_ctrl_hw_if_vseq.sv:325) uvm_test_top.env.virtual_sequencer [DEBUG] --> Attempting to READ Flash
UVM_INFO @<PHONE_NUMBER>47 ps: (flash_ctrl_base_vseq.sv:693) uvm_test_top.env.virtual_sequencer [DEBUG] --> POLLING ...
UVM_INFO @<PHONE_NUMBER>47 ps: (flash_ctrl_base_vseq.sv:701) uvm_test_top.env.virtual_sequencer [DEBUG] --> STARTING TIMEOUT
UVM_INFO @<PHONE_NUMBER>47 ps: (flash_ctrl_base_vseq.sv:703) uvm_test_top.env.virtual_sequencer [DEBUG] --> Timeout Occurred, Expected
UVM_INFO @<PHONE_NUMBER>47 ps: (host_ctrl_hw_if_vseq.sv:340) uvm_test_top.env.virtual_sequencer [DEBUG] --> Timeout Seen - Flash Not Accessible By Software, Expected, PASS
UVM_INFO @<PHONE_NUMBER>47 ps: (host_ctrl_hw_if_vseq.sv:167) uvm_test_top.env.virtual_sequencer [uvm_test_top.env.virtual_sequencer.host_ctrl_hw_if_vseq] RESET
UVM_ERROR @<PHONE_NUMBER>79 ps: (tl_host_driver.sv:64) [uvm_test_top.env.m_tl_agent_flash_ctrl_core_reg_block.driver] Check failed cfg.a_source_pend_q.size() == 0 (1 [0x1] vs 0 [0x0])
UVM_INFO @<PHONE_NUMBER>79 ps: (uvm_report_catcher.svh:705) [UVM/REPORT/CATCHER]

@TimEwins i'll take a look at the test, but it sounds like what you're pointing out is a DV driver issue correct..?

@weicaiyang pointed out the transaction timeout is because a csr transaction is immediately issued after calling apply_reset. He suggested we switch to dut_init since it has built in delays. I'm trying that now, will report back later. So far the behavior here seems consistent.
One thing I'm not sure how we're going to check.. the rma process randomly programs each word and verifies it. If there was a hardware bug there (ie we don't actually program, or we don't actually read), this higher level testing won't check it. Need to think a bit about how to check it, may need to add an SVA instead.

hmm.. @weicaiyang it seems like even with the extra delay it's still failing. I need to have a closer look to make sure I put it in the right place.  Will get back to this later.

hmm.. @weicaiyang it seems like even with the extra delay it's still failing. I need to have a closer look to make sure I put it in the right place. Will get back to this later.

LMK if you want me to take a look as well.

@tjaychen "DV driver issue" it did look that way, but I will investigate your suggestion about the reset today

@tjaychen
"One thing I'm not sure how we're going to check.. the rma process randomly programs each word and verifies it. If there was a hardware bug there (ie we don't actually program, or we don't actually read), this higher level testing won't check it. Need to think a bit about how to check it, may need to add an SVA instead"
The way I am doing this is as follows ...
// Initialise
// Loop {
//   Erase Partitions(#)
//   Program Partitions(#)
//   Read Partitions(#) (Check Read == Written)
//  DO RMA REQUEST (Flash is Erased, and programmed with 'random' data.
//   Check Software has NO Access to the FLASH (not able to read flash)
//   Reset DUT
//   Initialise (again)
//   Read Partitions# (Check Read !== Written Previously - Data MISMATCH Expected
//     (additionally check Data Read is not all 1's, i.e Erased but not overwritten
// }
// #(Creator, Owner, Isolation, Data0, Data1)
There is a 'possibility' of a match in the last compare, as a value of '1 and/or a match is theoretically possible (but very unlikely), so I have added a threshold to the pass (small)
Ideally, but probably over the top is to compare the RMA wiped values with the scrambled data, using the seed to the algorithm to calculate what would be expected.  I think this maybe too much ?
Perhaps an SVA would be appropriate here to help prove the inner FSM is doing the right thing?

yeah i think SVA is probably the better approach, I will look into adding it.

@tjaychen @weicaiyang @rswarbrick
Hi .. I changed my test to use 'dut_init' rather than 'apply_reset' and I too see the same issue.
I think basically that at hard rest, the transaction queues need to be cleared.  This would stop this error from happening.
I have also tried adding delay, moving operations around and even setting CONTROL.START back to 0 after the timeout, but I keep getting the same error message.
UVM_ERROR @<PHONE_NUMBER>19 ps: (tl_host_driver.sv:64) [uvm_test_top.env.m_tl_agent_flash_ctrl_core_reg_block.driver] Check failed cfg.a_source_pend_q.size() == 0 (1 [0x1] vs 0 [0x0])
UVM_INFO @<PHONE_NUMBER>19 ps: (uvm_report_catcher.svh:705) [UVM/REPORT/CATCHER]
Which I believe is a mismatch between transactions in and out of the driver/scoreboard?
@rswarbrick Are you suggesting this is a known issue, or just for reference?
As this issue is stalling the completion of this test, and there is a real need to press on with other tests, I intend to checkin what I have so far, and then we will have to revisit this when resolved.

@TimEwins do you have any idea where the queue item is coming from? When I looked at this (admittedly a couple of days ago) it looked like before the reset pulse, all the tlul transactions were complete (as far as I could tell).
In fact, there was a small time gap between the last tlul transaction and the last reset pulse, so I'm not sure where it's coming from.  Is there any way for you to dump out which transactions it thinks is still "pending"?

Hi Tim
I think the issue (if it is an issue) is within the Verification domain (in the TL driver code somewhere)
The last write to the flash before the error was to the control register, the transaction times out, status is not returned in a sufficient time (which is expected as the RMA has just happened), I then RESET the TB and DUT.  But for some reason (?) when the TB and DUT come out of reset, it thinks there is a miissing transaction somewhere.
the 'error' is coming from tl_host_driver.sv (line 654) ... which is checking that the queue cfg.a_source_pend_q.size() =0, but its a '1'.
If this queue were cleared by reset, then the flag would not raise.
I think this is the behaviour here, but perhaps its like that for a reason ?
I am obviously happy to try other methods

@TimEwins do you see this timed out transaction in the waves though?
Because when i looked, there was no pending a_valid directed at flash_ctrl.  All the transactions that went to flash_ctrl had been acknowledged, that's why I find it odd.

@tjaychen Thanks .. I will take another look

the 'error' is coming from tl_host_driver.sv (line 654) ... which is checking that the queue cfg.a_source_pend_q.size() =0, but its a '1'.

This may be because you kill the sequence when a CSR access is ongoing, which causes a deadlock in RAL and we can never issue a new access to this CSR. Also a pending source ID is stuck at the cfg.a_source_pend_q.
I check your branch and find below codes that you kill the CSR access, which may cause the UVM_ERROR.
    fork

      begin  // Poll Status Bit
        `uvm_info("DEBUG", "--> POLLING ...", UVM_LOW)
        while (status == 0) begin
          csr_rd(.ptr(ral.op_status), .value(data));
         status = get_field_val(ral.op_status.done, data);
        end
      end

      begin  // Timeout - Expected
        `uvm_info("DEBUG", "--> STARTING TIMEOUT", UVM_LOW)
        #(timeout_ns);
        `uvm_info("DEBUG", "--> Timeout Occurred, Expected", UVM_LOW)
        status = 1;
      end

    join_any
    disable fork;

you can change join_any to join and remove disable fork, so that once the timeout thread is done, the polling loop will be exited gracefully as status is set to 1.

@weicaiyang that's what i was originally thinking too. But I don't see another tlul transaction triggered to flash while the reset occurs.
Are you saying it's possible for the transaction to have been registered in DV but not yet shown up in waves?

I see the point you are making ..... graceful exit ... yes, its not the write to fifo that is locking up, its the polling of the status .. I'll try this solution .... unless anything else gets added here in the meantime

@weicaiyang that's what i was originally thinking too. But I don't see another tlul transaction triggered to flash while the reset occurs.
Are you saying it's possible for the transaction to have been registered in DV but not yet shown up in waves?

This problem won't be shown in the waves as DUT and driver process correctly.
It's just the sequence that gets stuck.
A CSR read sequence looks like this.
// CIP base saves the source ID
cfg.a_source_pend_q.push_back(source_id);

// UVM RAL side
semaphore.get(); // lock the seq
do_read(); // send item to driver and wait for rsp
semaphore.put(); // unlock the seq

// CIP base
cfg.a_source_pend_q.delete(id); // delete the completed source id

If we kill the seq in the middle of do_read, RAL is in deadlock, and a_source_pend_q has a ID that won't be removed.

sounds good, thanks for explaining @weicaiyang

@TimEwins just wanted to check-in to see if there's anything gated on me for this issue?

sounds good. I just wanted to make sure you were not waiting on something.
On Wed, Feb 2, 2022 at 9:52 AM TimEwins @.***> wrote:

@tjaychen https://github.com/tjaychen I don't think so Tim, I have a PR
candidate scheduled for checkin .. but I have been working on the other PR
#10513 https://github.com/lowRISC/opentitan/pull/10513 today.
—
Reply to this email directly, view it on GitHub
https://github.com/lowRISC/opentitan/issues/10343#issuecomment-1028200355,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAH2RSSKNPHPAOKWQZ2OLNTUZFVNLANCNFSM5MY7LVQQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID:
@.***>

Leaving this open until I do the PR for the RMA Tests.

We can close this Issue now


Update hardware-feature-levels.md

Shader Model line needed updating for Shader Model 6.

@walbourn : Thanks for your contribution! The author(s) have been notified to review your proposed change.


[BUG] XAML-Designer-Exception

Describe the bug

After upgrading to 10.5.31 I get ArgumentException: Don't know how to detect when Mocks.{name of view} is activated/deactivated, you may need to implement IActivationForViewFetcher in all my views in the designer.
Steps To Reproduce
I created a sample repo that reproduces the issue.
If you build the project & try to use the XAML-Designer with TestUserControl.xaml the designer will throw an exception like the one below under "screenshots".
Expected behavior
XAML-Designer should not throw an exception
Screenshots

Environment

OS: Windows 10 Pro

Additional context

After a few tests, it appears that this only happens with UserControl.
I think the issue appears if you have a base class for your UserControls and you call this.WhenActivated(....) in its constructor.
So in order to reproduce the issue, just create a UserControlBase<TViewModel> implementing IViewFor<TViewModel> or inheriting ReactiveUserControl<TViewModel> and call this.WhenActivated(...) in its constructor.
Create a FooUserControl : UserControlBase<FooViewModel> & rebuild.
You should see the exception in the XAML designer.

This will be fixed by #2272


Document required IAM permissions for operations

First of all, I want to thank all the developers here for this project. It's really great help!
I'd like to ask to improve the documentation to mention permissions required by s3fs operations.
#532 shows that they can be surprising sometimes.
I have
"Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:ListBucket",
                "s3:CreateBucket"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:s3:::bucket",
                "arn:aws:s3:::bucket/*",

and still can't save a file 🤷

If you figure it out, it would indeed make a good addition to the docs. You should look at the specific request that is being denied and compare against the API doc pages which ought to state what you need, e.g., this for CreateMultipartUpload: https://docs.aws.amazon.com/AmazonS3/latest/API/API_CreateMultipartUpload.html

@rafalkrupinski try PutObject* and GetObject*

It seems that writing a file requires ListBucketV2 grant to the bucket and PutObject to the path, at least for a small file (no multipart). I had both grants. Problem was in code that was granting the permissions (https://github.com/aws/aws-cdk/issues/22060). Workaround was to create a separate policy.
S3FS could use the documentation of required grants anyway, so I'm not closing the issue :)

In the meantime, in case anyone stumbles across this issue, it seems this one is also required:
        {
            "Action": [
                "s3:ListAllMyBuckets"
            ],
            "Effect": "Allow",
            "Resource": "*"
        }

Hopefully no one else looses as much time as I did on that one

I don't have it and it works :)

Some of these depend on what you are doing! ListAllMyBuckets would get used when you do fs.ls("") to get a list of buckets associated with your account. If you already know which bucket(s) to use, you never need that.

@martindurant Sorry, I didn't get that you're referring to the problem of documenting the required privileges, and not just the particular problem I've encountered 🤷🏻

I am in complete agreement with you, the privileges should be documented as well as we are able. I'm just saying that not all of them are needed by a user, depending on the situation, so that documentation needs to be carefully written. Would you like to have a go?

We do not test against read AWS S3 at all, but against a local server provided by moto. That means we are not able to fully test the permissioning model at all.


[ENH] Improve the error message for struct size change

Opening an issue in cython due to a discussion in NumPy.
The currently ValueError when the size of a struct changed (i.e. shrank), is pretty confusing for users.  In the case of NumPy we added (basically private) fields to the end of the ndarray struct.  This is perfectly ABI compatible so long there are no subclasses involved.  (Subclassing ndarray in cython does not work at all, so nobody is doing it.)
Some projects incorrectly compile against a newer NumPy versions and release older wheels:  For them, this is annoying to track down, but I think they are happy to learn.  But it seems even some end-users run into it occsionally (since they write their own cython modules).
For NumPy, a solution would be if we could call import_array() before the size check, since I believe that already raises the error correctly (assuming we bump the C-API feature version).
In general, I am not sure what best to do.  Maybe just adding additional information saying that typically you should compile using the oldest support version?  Or maybe we could add some special feature to end a class definition with a __variable_private__ so that cython can decide to only complain if someone actually subclasses that specific class?

Or maybe the fix is to change the behaviour of size_check ignore to completely ignore the size so long it is still larger than the fields already imported in cython?  The behaviour when a subclass is actually created should probably remain as it is (or even be more strict!)

Given https://github.com/cython/cython/issues/4827, I'm wondering if we should have some way for the user to specify an "expected size" that overrides sizeof:
cdef extern from *:
   ctypedef class mod.cls [object PySomethingObject expected_size 100]:
      pass

There's quite a few classes which don't quite do what we expect with size (bytes for example, although that's special-cased within Cython anyway).
For Numpy it might let you specify the minimum size that you know is OK from backwards compatibility.
The danger is that everyone uses it as a way to ignore legitimate errors, and then posts bugs reports about asking why their program is crashing (see the  enum { __pyx_check_sizeof_voidp = 1 / (int)(SIZEOF_VOID_P == sizeof(void*)) check...).

Or maybe we could add some special feature to end a class definition with a __variable_private__ so that cython can decide to only complain if someone actually subclasses that specific class?

The cython.final decorator should do some of that I think. Not sure if it can be applied to extern types


WIP: Develop

Pull Request Test Coverage Report for Build 927

3 of 9 (33.33%)  changed or added relevant lines in 2 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage increased (+0.05%) to 75.568%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/controllers/cron.controller.ts
1
7
14.29%

Files with Coverage Reduction
New Missed Lines
%

src/controllers/cron.controller.ts
1
51.02%

Totals

Change from base Build 920:
0.05%

Covered Lines:
1681

Relevant Lines:
2115

💛  - Coveralls


Running as daemon

Just installed blackbird and would prefer to have it running as a service.
If you are interested to have it running as service I could look into that.

Hi @nordicgit70,
Thank you. What would be the advantage for a trading system like this one?

Hi,
the application already acts as service, as it runs headless without a UI.
making it a daemon would allow stop/start/restart/reload control.
it would run in the background managed by Linux run-levels.
e.g. automatic stop-start, without user involvement
//

This has to work under windows too if you're going to add this feature.

You could use nohup for the time being.


Make a github action to regularly build Mkdocs pages

Currently there is an action to deploy the existing pages to gh-pages, but the html pages are not updated if any changes are made in the markdown or rst files.  There should be a gh action to run sphinx-build -b html docs/source docs/html and commit/push the changes.
This was first mentioned in this issue by Nathan.

We have a github action that are building mkdocs pages


add Client interface

I added a few comments and also +1 to Andrew's comment of moving the list to the constructor of SearchServlet.


publishDiagnostics messages don't include the document version

Describe the bug
The publishDiagnostics messages don't contain the optional version field as outlined in the spec. This field is useful for checking if diagnostics are still relevant (= their version is the same as the document version). Sadly, it seems lua-language-server doesn't include this field.
Backstory: I'm writing a plugin for NeoVim to defer showing diagnostics until after a write. Since diagnostics may be received after a write (but belong to the document state from before the write), I check the version field to see if the diagnostics should be displayed immediately, or if they should be set aside until the next write.
For lua-language-server this isn't possible due to the version field being left out. This means that if you save a file super fast (or it takes lua-language-server longer to produce diagnostics) after making a change, not all diagnostics are displayed.
To Reproduce

Produce diagnostics
Note that the version field isn't included

Expected behavior
The version field is included, and points to the version of the document at the time the diagnostics were produced.
Environment (please complete the following information):

OS: Linux
Client: NeoVim
Version: 2.4.4

@sumneko Thanks! :tada:

@sumneko It seems that with the 2.5.1 release this is no longer working, as diagnostics are not including the version anymore. For example:
{
  diagnostics = { {
      code = "lowercase-global",
      message = "Global variable in lowercase initial, Did you miss `local` or misspell it?",
      range = {
        end = {
          character = 32,
          line = 222
        },
        start = {
          character = 9,
          line = 222
        }
      },
      severity = 3,
      source = "Lua Diagnostics."
    } },
  uri = "file:///home/yorickpeterse/Projects/general/dotfiles/dotfiles/.config/nvim/lua/dotfiles/completion.lua"
}

Please open a new issue, thank you!


Testing flux framework basic

Hey @wardharold ! I've taken a preliminary look at the setup and was able to do the builds, but on the terraform "basic" example when I tried to init my basic.vars:
data.terraform_remote_state.iam: Reading...
data.terraform_remote_state.storage: Reading...
data.terraform_remote_state.network: Reading...
╷
│ Error: Unable to find remote state
│
│   with data.terraform_remote_state.network,
│   on state.tf line 15, in data "terraform_remote_state" "network":
│   15: data "terraform_remote_state" "network" {
│
│ No stored state was found for the given workspace in the given backend.
╵
╷
│ Error: Unable to find remote state
│
│   with data.terraform_remote_state.iam,
│   on state.tf line 23, in data "terraform_remote_state" "iam":
│   23: data "terraform_remote_state" "iam" {
│
│ No stored state was found for the given workspace in the given backend.
╵
╷
│ Error: Unable to find remote state
│
│   with data.terraform_remote_state.storage,
│   on state.tf line 31, in data "terraform_remote_state" "storage":
│   31: data "terraform_remote_state" "storage" {
│
│ No stored state was found for the given workspace in the given backend.
╵

I've never used terraform before, so I'm sure I forgot something, although I was following the instructions in the README!
For the higher level thinking about this setup for experiments, I have some questions:

image base: We've done most of our experiments (and thus have containers for the Flux Operator) on ubuntu bases. Would it be possible to tweak the build for Flux to give an option to use rocky linux or ubuntu?
Filesystem having NFS will be great, but I think for our most basic vanilla experiments, maybe running LAMMPS that doesn't require a filesystem, we would want to have the setup without it.

We would want the comparison to be as close as possible, e.g., running at least on the same base, and possibly (after looking at the setup) we want to do the first set of experiments without any kind of additional filesystem.
Have a good weekend!

Indeed I did not! I'll try again today.

@wkharold I continued the tutorial (well I started fresh) and modified the original command to not build arm:
# An example without arm (and smaller instance sizes)
./build-images.sh -z us-central1-a -x n2-standard-4 -m e2-standard-2

And then I made the foundations folder, and cd'd into basic, and here is the current error - it seems to want to do arm anyway?
module.cluster.module.compute_nodes["gffw-compute-a"].data.google_compute_zones.available: Reading...
module.cluster.module.login_nodes["gffw-login"].data.google_compute_zones.available: Read complete after 0s [id=projects/llnl-flux/regions/us-central1]
module.cluster.module.management_node.data.google_compute_image.fluxfw_manager_image: Read complete after 0s [id=projects/llnl-flux/global/images/flux-fw-manager-v1680546033]
module.cluster.module.compute_nodes["gffw-compute-a"].data.google_compute_image.fluxfw_compute_x86_64_image: Read complete after 0s [id=projects/llnl-flux/global/images/flux-fw-compute-x86-64-v1680547638]
module.cluster.module.compute_nodes["gffw-compute-a"].data.google_compute_zones.available: Read complete after 1s [id=projects/llnl-flux/regions/us-central1]
╷
│ Error: error retrieving image information: googleapi: Error 404: The resource 'projects/llnl-flux/global/images/family/flux-fw-compute-arm64' was not found, notFound
│
│   with module.cluster.module.compute_nodes["gffw-compute-a"].data.google_compute_image.fluxfw_compute_arm64_image,
│   on ../../modules/compute/main.tf line 15, in data "google_compute_image" "fluxfw_compute_arm64_image":
│   15: data "google_compute_image" "fluxfw_compute_arm64_image" {
│
╵
╷
│ Error: error retrieving image information: googleapi: Error 404: The resource 'projects/llnl-flux/global/images/family/flux-fw-login-x86-64' was not found, notFound
│
│   with module.cluster.module.login_nodes["gffw-login"].data.google_compute_image.fluxfw_login_x86_64_image,
│   on ../../modules/login/main.tf line 15, in data "google_compute_image" "fluxfw_login_x86_64_image":
│   15: data "google_compute_image" "fluxfw_login_x86_64_image" {
│
╵

Is building arm required?

Nope. It's totally optional. Just nuke that group of nodes, or set the count to 0.

Or, better, make a copy of the basic.tfvars.example and modify it appropriately.

But, it also looks like the x86_64 images didn't get built.
You don't have to build ARM images but you do need

management node image [-m]
login node image [-l]
a flavor of compute node [-a | -x]
So, something like
./build-images.sh -z us-central1-a -m e2-standard-8 -l e2-standard8 -x n2-standard-16

Okay fixed the build! But where is arm coming in for the basic.tfars? I don't see any mention of it here:
manager_machine_type = "e2-standard-2"
manager_name_prefix  = "gffw"
manager_scopes       = [ "cloud-platform" ]

login_node_specs = [
    {
        name_prefix  = "gffw-login"
        machine_arch = "x86-64"
        machine_type = "e2-standard-4"
        instances    = 1
        properties   = []
        boot_script  = null
    },
]
login_scopes = [ "cloud-platform" ]

compute_node_specs = [
    {
        name_prefix  = "gffw-compute-a"
        machine_arch = "x86-64"
        machine_type = "n2-standard-4"
        gpu_type     = null
        gpu_count    = 0
        compact      = false
        instances    = 2
        properties   = []
        boot_script  = null
    },
]
compute_scopes = [ "cloud-platform" ]

Ah! It's happening in tf/modules/compute/main.tf. I need to think about how to handle the situation where people don't care about ARM. For now, you'll need to build an ARM image even if you don't use it.

okay doing the rebuild for arm - one high level observation of this setup is that it's hugely costly in terms of upfront time to get things running. E.g., I've spent a few days on it now with just buildings (and filestore) so let's keep in mind how this could be streamlined a bit!

okay I'm in! How did you want to start flux? I think the main devs use systemd. I don't see that it's been started when I login:
$ flux resource list
flux-resource: ERROR: [Errno 2] Unable to connect to Flux: No such file or directory

But it's installed!
[sochat1_llnl_gov@gffw-login-001 ~]$ which flux
/usr/local/bin/flux

I found this:
$ sudo cat /etc/flux/login/first-boot.sh
#!/bin/bash

for cs in $(ls /etc/flux/login/conf.d/*.sh | sort -n); do . $cs; done

systemctl enable --now flux

But it must not be working as expected. Testing it out...
sudo systemctl enable --now flux
$ flux resource list
flux-resource: ERROR: [Errno 2] Unable to connect to Flux: No such file or directory

OK so the command likely ran and it just is having this issue. It looks like your systemd script is just hitting those .conf.d files, which (as far as I can tell) are mostly about setting up NFS
$ cat /etc/systemd/system/flux-config-login.service
[Unit]
Wants=systemd-hostnamed
After=systemd-hostnamed
Wants=network-online.target
After=network-online.target
ConditionPathExists=!/var/lib/flux-login-configured

[Service]
Type=oneshot
ExecStartPre=/bin/bash -c 'while [[ "$(hostname)" =~ "packer" ]]; do sleep 1; done'
ExecStart=/etc/flux/login/first-boot.sh
ExecStartPost=/usr/bin/touch /var/lib/flux-login-configured
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

okay I found the directory with configuration stuffs:
$ sudo ls /usr/local/etc/flux
imp  rc1  rc1.d  rc3  rc3.d  security  shell  system

And then when I try starting the flux service, I get this command:
[sochat1_llnl_gov@gffw-login-001 local]$ systemctl status flux
Failed to get properties: Transport endpoint is not connected

This looks to be related to the mount for the filesystem? This might be one you can debug (or we could debug together) I don't know much about Filestore. https://stackoverflow.com/questions/24966676/transport-endpoint-is-not-connected
When I comment out the line in flux.service that (I think) requires this mount:
#ExecStartPre=/usr/bin/loginctl enable-linger flux

I get a bit further. Now there is some issue starting:
[sochat1_llnl_gov@gffw-login-001 local]$ sudo systemctl status flux
● flux.service - Flux message broker
   Loaded: loaded (/usr/lib/systemd/system/flux.service; enabled; vendor preset: disabled)
   Active: activating (auto-restart) (Result: exit-code) since Tue 2023-04-04 21:31:30 UTC; 12ms ago
  Process: 6063 ExecStart=/bin/bash -c    XDG_RUNTIME_DIR=/run/user/$UID    DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$UID/bus>
  Process: 6059 ExecStartPre=/usr/bin/bash -c systemctl start user@$(id -u flux).service (code=exited, status=0/SUCCESS)
 Main PID: 6063 (code=exited, status=1/FAILURE)

Apr 04 21:31:30 gffw-login-001 systemd[1]: flux.service: Main process exited, code=exited, status=1/FAILURE
Apr 04 21:31:30 gffw-login-001 systemd[1]: flux.service: Failed with result 'exit-code'.

And for that I think I found the issue - via journalctl:
resource.err[0]: error decoding exclude set gffw-manager-001: invalid targets: invalid>

in reference to this part of your broker's config file system.toml:
# Point to resource definition generated with flux-R(1).
# Uncomment to exclude nodes (e.g. mgmt, login), from eligibility to run jobs.
[resource]
path = "/usr/local/etc/flux/system/R"
- exclude = "gffw-manager-001"
+ # exclude = "gffw-manager-001"

You have a manager node? What is that for? We don't usually need anything beyond the main broker (what could be a login node) and then the workers. When I comment out that exclude, the broker is still failing to start, and I'm not sure why. I have to hop into a meeting (and it's expensive to keep this running) but I'll keep it up for this next hour hoping to hear from you with something to look at ! I'm wondering if your design has an extra component, we might want to step back and remove the manager node all together - it would help to better understand what you are using it for.
And another note - the state directory and run directories need to be owned by the flux instance owner (typically the flux user). I haven't checked if you did that yet.

Looking now.  I have a few minutes before I get called away.

You shouldn't have to hack the flux.service. All the flux directories should be chownd correctly during the image build.
The management node runs all the essential services. You can dispense with a login node if you want to reduce your foot print. As long as you have connectivity between nodes they should be able to register.
Try doing a systemctl restart flux on the manager node. Also journalctl -u flux.service should give us some info.
Finally before you login to the manager or login node do a gcloud compute instances list to see if everything you expect is up and running.

If you've got the nodes you expect to see. gcloud compute ssh gffw-login-001 and then cat /etc/fstab if that looks reasonable, mount. You should see mounts from gffw-manager-001 and a mount for /home from the filestore instance.

NAME                ZONE           MACHINE_TYPE    PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP  STATUS
gffw-compute-a-001  us-central1-a  n2-standard-16               <IP_ADDRESS>                 RUNNING
gffw-login-001      us-central1-a  e2-standard-4                <IP_ADDRESS>                 RUNNING
gffw-manager-001    us-central1-a  e2-standard-8                <IP_ADDRESS>                 RUNNING```

```flux resource list
     STATE PROPERTIES NNODES   NCORES    NGPUS NODELIST
      free x86-64,e2       1        2        0 gffw-login-001
      free n2,x86-64       1        8        0 gffw-compute-a-001
 allocated                 0        0        0
      down                 0        0        0 ```

```sudo journalctl -u flux.service
-- Logs begin at Tue 2023-04-04 22:55:27 UTC, end at Tue 2023-04-04 23:00:14 UTC. --
Apr 04 22:55:59 gffw-login-001 systemd[1]: Starting Flux message broker...
Apr 04 22:56:00 gffw-login-001 systemd[1]: Started Flux message broker.
Apr 04 22:56:02 gffw-login-001 flux[2162]: broker.info[1]: start: none->join 0.199287s
Apr 04 22:56:02 gffw-login-001 flux[2162]: broker.info[1]: parent-ready: join->init 0.201987ms
Apr 04 22:56:02 gffw-login-001 flux[2162]: broker.info[1]: configuration updated
Apr 04 22:56:03 gffw-login-001 flux[2162]: broker.info[1]: rc1.0: running /usr/local/etc/flux/rc1.d/01-sched-fluxion
Apr 04 22:56:03 gffw-login-001 flux[2162]: broker.info[1]: rc1.0: running /usr/local/etc/flux/rc1.d/02-cron
Apr 04 22:56:04 gffw-login-001 flux[2162]: broker.info[1]: rc1.0: /usr/local/etc/flux/rc1 Exited (rc=0) 1.9s
Apr 04 22:56:04 gffw-login-001 flux[2162]: broker.info[1]: rc1-success: init->quorum 1.89447s
Apr 04 22:56:04 gffw-login-001 flux[2162]: broker.info[1]: quorum-full: quorum->run 0.105973ms```

gcloud compute ssh gffw-compute-a-001 --zone us-central1-a

wkharold_wkh_altostrat_com@gffw-compute-a-001 ~]$ cat /etc/fstab

#
# /etc/fstab
# Created by anaconda on Mon Mar  6 18:23:43 2023
#
# Accessible filesystems, by reference, are maintained under '/dev/disk/'.
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
#
# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.
 --
Apr 04 22:56:01 gffw-compute-a-001 systemd[1]: Starting Flux message broker...
Apr 04 22:56:02 gffw-compute-a-001 systemd[1]: Started Flux message broker.
Apr 04 22:56:02 gffw-compute-a-001 flux[4711]: broker.info[2]: start: none->join 0.159126s
Apr 04 22:56:02 gffw-compute-a-001 flux[4711]: broker.info[2]: parent-ready: join->init 0.095046ms
Apr 04 22:56:02 gffw-compute-a-001 flux[4711]: broker.info[2]: configuration updated
Apr 04 22:56:03 gffw-compute-a-001 flux[4711]: broker.info[2]: rc1.0: running /usr/local/etc/flux/rc1.d/01-sched-fluxion
Apr 04 22:56:03 gffw-compute-a-001 flux[4711]: broker.info[2]: rc1.0: running /usr/local/etc/flux/rc1.d/02-cron
Apr 04 22:56:03 gffw-compute-a-001 flux[4711]: broker.info[2]: rc1.0: /usr/local/etc/flux/rc1 Exited (rc=0) 0.6s
Apr 04 22:56:03 gffw-compute-a-001 flux[4711]: broker.info[2]: rc1-success: init->quorum 0.62698s
Apr 04 22:56:03 gffw-compute-a-001 flux[4711]: broker.info[2]: quorum-full: quorum->run 0.040215ms

journalctl -u flux.service should really tell the story of what's going awry.

Try doing a systemctl restart flux on the manager node. Also journalctl -u flux.service should give us some info.

Yep those are the exact commands I used to get the original debug info. I'm going to log out and follow the steps as you suggested!
$ gcloud compute instances list
NAME                ZONE           MACHINE_TYPE   PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP  STATUS
gffw-compute-a-001  us-central1-a  n2-standard-4               <IP_ADDRESS>               RUNNING
gffw-compute-a-002  us-central1-a  n2-standard-4               <IP_ADDRESS>               RUNNING
gffw-login-001      us-central1-a  e2-standard-4               <IP_ADDRESS>               RUNNING
gffw-manager-001    us-central1-a  e2-standard-2               <IP_ADDRESS>               RUNNING

My setup is different here - I chose two compute nodes and 1 login, 1 manager, and of smaller sizes than your demo (which they were huge!) Now ssh-ing into the login node...
$ gcloud compute ssh --zone "us-central1-a" "gffw-login-001"  --tunnel-through-iap --project "${PROJECt}"

#
# /etc/fstab
# Created by anaconda on Mon Mar  6 18:23:43 2023
#
# Accessible filesystems, by reference, are maintained under '/dev/disk/'.
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
#
# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.
#
UUID=9bd2062d-d31f-4ec4-a11d-72ebc298c688 /                       xfs     defaults        0 0
UUID=FABA-0B0B          /boot/efi               vfat    defaults,uid=0,gid=0,umask=077,shortname=winnt 0 2
gffw-manager-001.c.llnl-flux.internal:/usr/local/etc/flux/imp /usr/local/etc/flux/imp nfs defaults,hard,intr,_netdev 0 0
gffw-manager-001.c.llnl-flux.internal:/usr/local/etc/flux/security /usr/local/etc/flux/security nfs defaults,hard,intr,_netdev 0 0
gffw-manager-001.c.llnl-flux.internal:/usr/local/etc/flux/system /usr/local/etc/flux/system nfs defaults,hard,intr,_netdev 0 0
gffw-manager-001.c.llnl-flux.internal:/etc/munge /etc/munge nfs defaults,hard,intr,_netdev 0 0
<IP_ADDRESS>:/home /home nfs defaults,hard,intr,_netdev 0 0

And mount:
$ mount

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime,seclabel)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs (rw,nosuid,seclabel,size=8082652k,nr_inodes=2020663,mode=755)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,seclabel)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,seclabel,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,seclabel,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime,seclabel)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,cpuset)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,memory)
cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,rdma)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,blkio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,perf_event)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,net_cls,net_prio)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,cpu,cpuacct)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,hugetlb)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,pids)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,freezer)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,devices)
none on /sys/kernel/tracing type tracefs (rw,relatime,seclabel)
configfs on /sys/kernel/config type configfs (rw,relatime)
/dev/sda2 on / type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota)
selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,seclabel,pagesize=2M)
debugfs on /sys/kernel/debug type debugfs (rw,relatime,seclabel)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=40,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=19144)
mqueue on /dev/mqueue type mqueue (rw,relatime,seclabel)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
/dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,errors=remount-ro)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
gffw-manager-001.c.llnl-flux.internal:/usr/local/etc/flux/imp on /usr/local/etc/flux/imp type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=<IP_ADDRESS>,local_lock=none,addr=<IP_ADDRESS>,_netdev)
gffw-manager-001.c.llnl-flux.internal:/usr/local/etc/flux/security on /usr/local/etc/flux/security type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=<IP_ADDRESS>,local_lock=none,addr=<IP_ADDRESS>,_netdev)
gffw-manager-001.c.llnl-flux.internal:/usr/local/etc/flux/system on /usr/local/etc/flux/system type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=<IP_ADDRESS>,local_lock=none,addr=<IP_ADDRESS>,_netdev)
gffw-manager-001.c.llnl-flux.internal:/etc/munge on /etc/munge type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=<IP_ADDRESS>,local_lock=none,addr=<IP_ADDRESS>,_netdev)
<IP_ADDRESS>:/home on /home type nfs (rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=<IP_ADDRESS>,mountvers=3,mountport=2050,mountproto=tcp,local_lock=none,addr=<IP_ADDRESS>,_netdev)
tmpfs on /run/user/992 type tmpfs (rw,nosuid,nodev,relatime,seclabel,size=1620392k,mode=700,uid=992,gid=989)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)

And journal (this reproduces what I started debugging above - the "exclude" section needed to be commented out:
-- Logs begin at Tue 2023-04-04 21:02:43 UTC, end at Tue 2023-04-04 23:21:07 UTC. --
Apr 04 21:03:15 gffw-login-001 systemd[1]: Starting Flux message broker...
Apr 04 21:03:16 gffw-login-001 systemd[1]: Started Flux message broker.
Apr 04 21:03:17 gffw-login-001 flux[2149]: broker.info[0]: start: none->join 0.236477s
Apr 04 21:03:17 gffw-login-001 flux[2149]: broker.info[0]: parent-none: join->init 0.055992ms
Apr 04 21:03:19 gffw-login-001 flux[2149]: resource.err[0]: error decoding exclude set gffw-manager-001: invalid targets: invalid hosts: gffw-manager-001: Invalid argument
Apr 04 21:03:19 gffw-login-001 flux[2149]: resource.crit[0]: module exiting abnormally
Apr 04 21:03:19 gffw-login-001 flux[2149]: broker.err[0]: rc1.0: flux-module: broker.insmod: Invalid argument
Apr 04 21:03:19 gffw-login-001 flux[2149]: broker.err[0]: rc1.0: /usr/local/etc/flux/rc1 Exited (rc=1) 1.8s
Apr 04 21:03:19 gffw-login-001 flux[2149]: broker.info[0]: rc1-fail: init->shutdown 1.79859s
Apr 04 21:03:19 gffw-login-001 flux[2149]: broker.info[0]: children-none: shutdown->finalize 0.076882ms
Apr 04 21:03:19 gffw-login-001 flux[2149]: broker.info[0]: rc3.0: running /usr/local/etc/flux/rc3.d/01-sched-fluxion
Apr 04 21:03:21 gffw-login-001 flux[2149]: broker.info[0]: rc3.0: /usr/local/etc/flux/rc3 Exited (rc=0) 1.3s
Apr 04 21:03:21 gffw-login-001 flux[2149]: broker.info[0]: rc3-success: finalize->goodbye 1.34671s
Apr 04 21:03:21 gffw-login-001 flux[2149]: broker.info[0]: goodbye: goodbye->exit 0.084419ms
Apr 04 21:03:21 gffw-login-001 systemd[1]: flux.service: Main process exited, code=exited, status=42/n/a
Apr 04 21:03:21 gffw-login-001 systemd[1]: flux.service: Failed with result 'exit-code'.

Do you see anything that sticks out?

I'll also note when I comment out the exclude line, I still see flux-module: broker.insmod: Invalid argument so those are separate bugs.

Hmmm, just to make your set up match mine try uncommenting the exclude line

When I restore that line and daemon-reload and flux restart and then status, I see:
● flux.service - Flux message broker
   Loaded: loaded (/usr/lib/systemd/system/flux.service; enabled; vendor preset: disabled)
   Active: activating (auto-restart) (Result: exit-code) since Tue 2023-04-04 23:29:27 UTC; 2s ago
  Process: 15261 ExecStart=/bin/bash -c    XDG_RUNTIME_DIR=/run/user/$UID    DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$UID/bus    /usr/local/bin/flux broker    --config-pa>
  Process: 15257 ExecStartPre=/usr/bin/bash -c systemctl start user@$(id -u flux).service (code=exited, status=0/SUCCESS)
  Process: 15255 ExecStartPre=/usr/bin/loginctl enable-linger flux (code=exited, status=0/SUCCESS)
 Main PID: 15261 (code=exited, status=1/FAILURE)

and the journal logs (at the bottom) aren't very helpful:
Apr 04 23:28:19 gffw-login-001 systemd[1]: flux.service: Main process exited, code=exited, status=1/FAILURE
Apr 04 23:28:19 gffw-login-001 systemd[1]: flux.service: Failed with result 'exit-code'.
Apr 04 23:28:24 gffw-login-001 systemd[1]: flux.service: Service RestartSec=5s expired, scheduling restart.
Apr 04 23:28:24 gffw-login-001 systemd[1]: flux.service: Scheduled restart job, restart counter is at 1360.
Apr 04 23:28:24 gffw-login-001 systemd[1]: Stopped Flux message broker.
Apr 04 23:28:24 gffw-login-001 systemd[1]: Starting Flux message broker...
Apr 04 23:28:24 gffw-login-001 systemd[1]: Started Flux message broker.
Apr 04 23:28:24 gffw-login-001 systemd[1]: flux.service: Main process exited, code=exited, status=1/FAILURE
Apr 04 23:28:24 gffw-login-001 systemd[1]: flux.service: Failed with result 'exit-code'.
Apr 04 23:28:30 gffw-login-001 systemd[1]: flux.service: Service RestartSec=5s expired, scheduling restart.
Apr 04 23:28:30 gffw-login-001 systemd[1]: flux.service: Scheduled restart job, restart counter is at 1361.
Apr 04 23:28:30 gffw-login-001 systemd[1]: Stopped Flux message broker.
Apr 04 23:28:30 gffw-login-001 systemd[1]: Starting Flux message broker...

Apr 04 23:34:21 gffw-login-001 systemd[1]: Starting Flux message broker...
-- Subject: Unit flux.service has begun start-up
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit flux.service has begun starting up.
Apr 04 23:34:21 gffw-login-001 systemd[1]: Started Flux message broker.
-- Subject: Unit flux.service has finished start-up
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit flux.service has finished starting up.
--
-- The start-up result is done.
Apr 04 23:34:21 gffw-login-001 flux[15730]: broker: rundir /run/flux is not owned by instance owner: Operation not permitted
Apr 04 23:34:21 gffw-login-001 systemd[1]: flux.service: Main process exited, code=exited, status=1/FAILURE
Apr 04 23:34:21 gffw-login-001 systemd[1]: flux.service: Failed with result 'exit-code'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- The unit flux.service has entered the 'failed' state with result 'exit-code'.
Apr 04 23:34:23 gffw-login-001 sudo[15732]: sochat1_llnl_gov : TTY=pts/0 ; PWD=/home/sochat1_llnl_gov ; USER=root ; COMMAND=/bin/journalctl -xe
Apr 04 23:34:23 gffw-login-001 systemd[1]: Started Session 28 of user root.
-- Subject: Unit session-28.scope has finished start-up
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit session-28.scope has finished starting up.
--
-- The start-up result is done.
Apr 04 23:34:23 gffw-login-001 systemd-logind[1732]: New session 28 of user root.
-- Subject: A new session 28 has been created for user root
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Documentation: https://www.freedesktop.org/wiki/Software/systemd/multiseat
--
-- A new session with the ID 28 has been created for the user root.
--
-- The leading process of the session is 15732.
Apr 04 23:34:23 gffw-login-001 sudo[15732]: pam_unix(sudo:session): session opened for user root by sochat1_llnl_gov(uid=0)

Ah yes, the Marie Kondo method of software development and debugging - does this system log give me joy?
I think we might be in trouble with that one @wkharold because it's a very low bar for something in programming to give me joy! :laughing:

And boom! I think this is what I mentioned above? This bit:
Apr 04 23:34:21 gffw-login-001 flux[15730]: broker: rundir /run/flux is not owned by instance owner: Operation not permitted
Apr 04 23:34:21 gffw-login-001 systemd[1]: flux.service: Main process exited, code=exited, status=1/FAILURE
Apr 04 23:34:21 gffw-login-001 systemd[1]: flux.service: Failed with result 'exit-code'.

@wkharold does that give us joy (or a potential fix to your build recipes?)

It gives us something to go on;

wkharold_wkh_altostrat_com@gffw-manager-001 ~]$ ls -la /run | grep flux
drwxr-xr-x.  2 flux    flux      60 Apr  4 22:55 flux

so, what happens if you chown flux:flux /run/flux

We get slightly further, and hit the same bug (about the manager name)
-- The start-up result is done.
Apr 04 23:40:24 gffw-login-001 sudo[16306]: pam_unix(sudo:session): session closed for user root
Apr 04 23:40:24 gffw-login-001 systemd[1]: session-28.scope: Succeeded.
-- Subject: Unit succeeded
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- The unit session-28.scope has successfully entered the 'dead' state.
Apr 04 23:40:24 gffw-login-001 systemd-logind[1732]: Session 28 logged out. Waiting for processes to exit.
Apr 04 23:40:24 gffw-login-001 systemd-logind[1732]: Removed session 28.
-- Subject: Session 28 has been terminated
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Documentation: https://www.freedesktop.org/wiki/Software/systemd/multiseat
--
-- A session with the ID 28 has been terminated.
Apr 04 23:40:24 gffw-login-001 flux[16315]: broker.info[0]: start: none->join 9.0782ms
Apr 04 23:40:24 gffw-login-001 flux[16315]: broker.info[0]: parent-none: join->init 0.051834ms
Apr 04 23:40:24 gffw-login-001 flux[16315]: kvs.info[0]: restored KVS from checkpoint on 2023-04-04T23:38:49Z
Apr 04 23:40:24 gffw-login-001 flux[16315]: resource.err[0]: error decoding exclude set gffw-manager-001: invalid targets: invalid hosts: gffw-manager-001: Invalid argument
Apr 04 23:40:24 gffw-login-001 flux[16315]: resource.crit[0]: module exiting abnormally
Apr 04 23:40:24 gffw-login-001 flux[16315]: broker.err[0]: rc1.0: flux-module: broker.insmod: Invalid argument
Apr 04 23:40:24 gffw-login-001 flux[16315]: broker.err[0]: rc1.0: /usr/local/etc/flux/rc1 Exited (rc=1) 0.2s
Apr 04 23:40:24 gffw-login-001 flux[16315]: broker.info[0]: rc1-fail: init->shutdown 0.162412s
Apr 04 23:40:24 gffw-login-001 flux[16315]: broker.info[0]: children-complete: shutdown->finalize 58.4018ms
Apr 04 23:40:24 gffw-login-001 flux[16315]: broker.info[0]: rc3.0: running /usr/local/etc/flux/rc3.d/01-sched-fluxion
Apr 04 23:40:24 gffw-login-001 flux[16315]: broker.info[0]: rc3.0: /usr/local/etc/flux/rc3 Exited (rc=0) 0.2s
Apr 04 23:40:24 gffw-login-001 flux[16315]: broker.info[0]: rc3-success: finalize->goodbye 0.202531s
Apr 04 23:40:24 gffw-login-001 flux[16315]: broker.info[0]: goodbye: goodbye->exit 0.06147ms
Apr 04 23:40:24 gffw-login-001 systemd[1]: flux.service: Main process exited, code=exited, status=42/n/a
Apr 04 23:40:24 gffw-login-001 systemd[1]: flux.service: Failed with result 'exit-code'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel

If you haven't defined that host under the list of resources, I don't think it would be needed in exclude. But I'm not fully understanding the role of the manager so I might be off!

OK, one last thing (I have two grandchildren and a wife looking daggers at me ...)
What's in /usr/local/etc/flux/system/conf.d/system.toml?

I commented out the exclude line (in that file) and we are in business!
[sochat1_llnl_gov@gffw-login-001 ~]$ sudo systemctl status flux
● flux.service - Flux message broker
   Loaded: loaded (/usr/lib/systemd/system/flux.service; enabled; vendor preset: disabled)
   Active: active (running) since Tue 2023-04-04 23:44:12 UTC; 19s ago
  Process: 16471 ExecStartPre=/usr/bin/bash -c systemctl start user@$(id -u flux).service (code=exited, status=0/SUCCESS)
  Process: 16469 ExecStartPre=/usr/bin/loginctl enable-linger flux (code=exited, status=0/SUCCESS)
 Main PID: 16475 (flux-broker-0)
    Tasks: 18 (limit: 101032)
   Memory: 9.2M
   CGroup: /system.slice/flux.service
           └─16475 broker --config-path=/usr/local/etc/flux/system/conf.d -Scron.directory=/usr/local/etc/flux/system/cron.d -Srundir=/run/flux -Sstatedir=/var/lib/flux -Sloca>

Apr 04 23:44:12 gffw-login-001 flux[16475]: job-manager.info[0]: restart: checkpoint.job-manager not found
Apr 04 23:44:12 gffw-login-001 flux[16475]: broker.info[0]: rc1.0: running /usr/local/etc/flux/rc1.d/01-sched-fluxion
Apr 04 23:44:12 gffw-login-001 flux[16475]: sched-fluxion-resource.warning[0]: create_reader: allowlist unsupported
Apr 04 23:44:12 gffw-login-001 flux[16475]: sched-fluxion-resource.info[0]: populate_resource_db: loaded resources from core's resource.acquire
Apr 04 23:44:12 gffw-login-001 flux[16475]: broker.info[0]: rc1.0: running /usr/local/etc/flux/rc1.d/02-cron
Apr 04 23:44:13 gffw-login-001 flux[16475]: broker.info[0]: rc1.0: /usr/local/etc/flux/rc1 Exited (rc=0) 0.8s
Apr 04 23:44:13 gffw-login-001 flux[16475]: broker.info[0]: rc1-success: init->quorum 0.756899s
Apr 04 23:44:13 gffw-login-001 flux[16475]: broker.info[0]: online: gffw-login-001 (ranks 0)
Apr 04 23:44:13 gffw-login-001 flux[16475]: broker.info[0]: quorum-full: quorum->run 0.101158s
Apr 04 23:44:13 gffw-login-001 flux[16475]: broker.info[0]: online: gffw-login-001,gffw-compute-a-[001-002] (ranks 0-2)

$ flux resource list
     STATE PROPERTIES NNODES   NCORES    NGPUS NODELIST
      free x86-64,e2       1        2        0 gffw-login-001
      free n2,x86-64       2        4        0 gffw-compute-a-[001-002]
 allocated                 0        0        0
      down                 0        0        0

and
$ flux mini run -n 4 hostname
gffw-login-001
gffw-login-001
gffw-compute-a-001
gffw-compute-a-001

We might want to install the latest release too - we are deprecating "flux mini" (because it's terrible!) so you could just do flux run or flux submit etc.

And here is the full working file:
$ sudo cat /usr/local/etc/flux/system/conf.d/system.toml
# Flux needs to know the path to the IMP executable
[exec]
imp = "/usr/local/libexec/flux/flux-imp"

# Allow users other than the instance owner (guests) to connect to Flux
# Optionally, root may be given "owner privileges" for convenience
[access]
allow-guest-user = true
allow-root-owner = true

# Point to shared network certificate generated flux-keygen(1).
# Define the network endpoints for Flux's tree based overlay network
# and inform Flux of the hostnames that will start flux-broker(1).
[bootstrap]
curve_cert = "/usr/local/etc/flux/system/curve.cert"

default_port = 8050
default_bind = "tcp://eth0:%p"
default_connect = "tcp://%h:%p"

hosts = [{ host="gffw-login-001,gffw-compute-a-[001-002]"}]

# Speed up detection of crashed network peers (system default is around 20m)
[tbon]
tcp_user_timeout = "2m"

# Point to resource definition generated with flux-R(1).
# Uncomment to exclude nodes (e.g. mgmt, login), from eligibility to run jobs.
[resource]
path = "/usr/local/etc/flux/system/R"
#exclude = "gffw-manager-001"

# Remove inactive jobs from the KVS after one week.
[job-manager]
inactive-age-limit = "7d"

Oh! One more thing cat /usr/local/etc/flux/system/R
The error is claiming that the manager node doesn't exist so maybe it didn't get into the resource definition?

[wkharold_wkh_altostrat_com@gffw-manager-001 ~]$ sudo cat /usr/local/etc/flux/system/R
{"version": 1, "execution": {"R_lite": [{"rank": "0", "children": {"core": "0-3"}}, {"rank": "1", "children": {"core": "0-1"}}, {"rank": "2", "children": {"core": "0-7"}}], "starttime": 0.0, "expiration": 0.0, "nodelist": ["gffw-manager-001,gffw-login-001,gffw-compute-a-001"], "properties": {"e2": "1", "x86-64": "1-2", "n2": "2", "manager": "0"}}}

Yep it's not there:
$ cat /usr/local/etc/flux/system/R
{"version": 1, "execution": {"R_lite": [{"rank": "1-3", "children": {"core": "0-1"}}], "starttime": 0.0, "expiration": 0.0, "nodelist": ["gffw-login-001,gffw-compute-a-[001-002]"], "properties": {"e2": "1", "x86-64": "1-3", "n2": "2-3"}}}

For design, I think generally we might want to be more conservative. There is technically nothing that requires a special manager node - that sounds like the MPI operator or similar. The login node can also serve as index 0 / the broker and perform management tasks.

We found the bug! :bug: :lady_beetle:
insert joy!

OK if I shut everything down now?

Yup, I have no idea why the manager node didn't show up but if it's not there sadness will ensue.
Most of what I did comes from the flux-framework docs for a system instance; we might want to check with Tom re: the need for a manager node - something has to run the various management services.

 I know make clean for the foundation will take care of filestore but I'm not sure how to do it for an example.

The code that creates the resources is in /etc/flux/manager/conf.d/01-system.sh
something in there failed at first boot
terraform destroy -var-file basic.tfvars

should bring it all down

and now I have to log off myself lest I be disowned by my grandsons ...
many thanks for your patience and tenacity!

Thank you!! I'm really excited we got this working - more later this week! :partying_face:

@wkharold is there an example for Flux that sets up the cluster with a mount to an existing cloud storage? One of our workflows has a ton of data that needs to be staged from Globus, and getting it onto new Filestore instances each time would be an extra (lengthy!) step. Most researchers, I would argue, will also have existing data in Google Storage they want to connect to to use (and the Filestore use case is more rare my guess would be).

It looks like installing gcsfuse on the compute nodes, so that you could easily mount a GCS volume, got left out of the updates I did last week. I'll get that in forthwith.

I tried to get this working this weekend - in your email! Taking a break for the rest of today to work on other stuffs. Thanks @wkharold !

And here is the kind of thing I'm running into, when I shell into an instance and see gcsfuse isn't installed, and then try to install it (to manually test creating the mount):
$ sudo dnf install gcsfuse
Last metadata expiration check: 1:01:50 ago on Sun 16 Apr 2023 11:29:13 PM UTC.
Dependencies resolved.
=================================================================================================================
 Package                     Architecture           Version                        Repository               Size
=================================================================================================================
Installing:
 gcsfuse                     x86_64                 0.42.3-1                       gcsfuse                  13 M
Installing dependencies:
 fuse                        x86_64                 2.9.7-16.el8                   baseos                   82 k
 fuse-common                 x86_64                 3.3.0-16.el8                   baseos                   21 k

Transaction Summary
=================================================================================================================
Install  3 Packages

Total download size: 13 M
Installed size: 31 M
Is this ok [y/N]: y
Downloading Packages:
                                          [===                                 ] ---  B/s |   0  B     --:-- ETA
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Error downloading packages:
  Curl error (7): Couldn't connect to server for https://mirrors.rockylinux.org/mirrorlist?arch=x86_64&repo=BaseOS-8 [Failed to connect to mirrors.rockylinux.org port 443: Connection timed out]

That's further than some of the other instance types get - at least it shows that gcsfuse is found and installable! The other error I see says that all mirrors are tried and failed (and I suspect we haven't added the right source in this case).

We got this basic setup working - closing issue!


Added FromStr implementation for Oid

As discussed previously, adding a FromStr implementation for Oid.  Implementation is only valid for types that can be converted from Vec<u8> (which includes Bytes).  Should work for custom byte containers, so long as they provide a converter from Vec<u8>
mkoid will output one comma too many, but rustc doesn't actually care about an extra trailing comma.

Sure - I just pushed a merge commit

Again, thank you for the PR!
Given the low frequency of changes, I’ll make a release as well.


Minor bug fixes and modmail replies allowed.

Minor bug fixes and modmail replies allowed.
#1 epoch time is not 1440 * days its 86400*days.
#2 dont log tickets from automod or reddit itself.
#3 removed a few semi colons
Also added support to allow replies directly from the ticketing system
into modmail.  System exited if it was unable to update the ticket to
remove the custom field data as it could result in a loop that would
cause infinite replies to reddit (a bad thing).

if automod makes no tickets then we will still have to check modmail for
its messages?
On Thu, Apr 9, 2015 at 1:45 AM erocs<EMAIL_ADDRESS>wrote:

Merged #2 https://github.com/Civcraft/modmail_ticketmanager/pull/2.
—
Reply to this email directly or view it on GitHub
https://github.com/Civcraft/modmail_ticketmanager/pull/2#event-276881833
.

Yes, I was pondering that too. Do we want all of those issues opened?
On Apr 9, 2015 7:20 AM, "ttk2"<EMAIL_ADDRESS>wrote:

if automod makes no tickets then we will still have to check modmail for
its messages?
On Thu, Apr 9, 2015 at 1:45 AM erocs<EMAIL_ADDRESS>wrote:

Merged #2 https://github.com/Civcraft/modmail_ticketmanager/pull/2.
—
Reply to this email directly or view it on GitHub
<
https://github.com/Civcraft/modmail_ticketmanager/pull/2#event-276881833>
.

—
Reply to this email directly or view it on GitHub
https://github.com/Civcraft/modmail_ticketmanager/pull/2#issuecomment-91245861
.

I am not sure. I dont think we want to have to check both places though.
On Thu, Apr 9, 2015, 12:19 PM erocs<EMAIL_ADDRESS>wrote:

Yes, I was pondering that too. Do we want all of those issues opened?
On Apr 9, 2015 7:20 AM, "ttk2"<EMAIL_ADDRESS>wrote:

if automod makes no tickets then we will still have to check modmail for
its messages?
On Thu, Apr 9, 2015 at 1:45 AM erocs<EMAIL_ADDRESS>wrote:

Merged #2 https://github.com/Civcraft/modmail_ticketmanager/pull/2.
—
Reply to this email directly or view it on GitHub
<
https://github.com/Civcraft/modmail_ticketmanager/pull/2#event-276881833

.

—
Reply to this email directly or view it on GitHub
<
https://github.com/Civcraft/modmail_ticketmanager/pull/2#issuecomment-91245861
.

—
Reply to this email directly or view it on GitHub
https://github.com/Civcraft/modmail_ticketmanager/pull/2#issuecomment-91279254
.


Update the /examples. No new release

Codecov Report

Merging #33 (46162c7) into dev (f53572a) will decrease coverage by 0.40%.
The diff coverage is n/a.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@            Coverage Diff             @@
##              dev      #33      +/-   ##
==========================================
- Coverage   82.35%   81.96%   -0.40%
==========================================
  Files           5        5
  Lines         255      255
==========================================
- Hits          210      209       -1
- Misses         45       46       +1

Impacted Files
Coverage Δ

src/test.jl
94.94% <0.00%> (-1.02%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


v1alpha1, v1alpha2 no matches for KeptnApp and examples code mismatch

This issue is more to help others who may come across this while the specs are stabilising between versions:
I've installed KLT following current 0.4.1 instructions with ArgoCD: https://github.com/agardnerIT/klt-argocd/blob/main/lifecycle-toolkit.yaml
Now I create a KeptnApp based on the current podtatohead example code which specifies spec version v1alpha2.
one or more objects failed to apply, reason: resource mapping not found for name: "fib3r-app" namespace: "default" from "/dev/shm/2484545736": no matches for kind "KeptnApp" in version "lifecycle.keptn.sh/v1alpha2" ensure CRDs are installed first.
Then I revert to v1alpha1 and sync fails with a different error:
one or more objects failed to apply (dry run)
error validating data: ValidationError(KeptnApp.spec): unknown field "revision" in sh.keptn.lifecycle.v1alpha1.KeptnApp.spec

Now remove the revision line and it syncs correctly.
TLDR:

v1alpha1 does not support revision keyword
v2alpha2 does support revision
Current release 0.4.1 uses v1alpha1
Current examples on main are out-of-sync with releases and use v1alpha2

Hey @agardnerIT, if you want to use v1alpha2 you should install a master build since it is not yet released.
You can do that by looking at the latest CI run on main. There you can download scheduler-manifest and keptn-lifecycle-operator-manifest.