Public Release

[rstyd]

Hey all,

Here is a list of issues we should look at before the release.
Note: Boxes are for project board only not completion, we'll do that in the issues.
Checked box means it is on the project board.

• * Decide on a due date (Pat)

• Make release issue/project board (Pat)

  • * Populate with cards/issues from this discussion
  • * Add pertinent existing issues to board.

• Correctness and Stability

  • Need to throughly test code and fix any issues.
  • Need a fail safe for scenarios such as WFM, TM, scheduler, etc failing.
  • * Test matrix

• Testing

  • Look at the code coverage of our current test suite and see if we need to add any additional tests.
  • * Once we have a public repo, we can setup CI for free using Github actions. (Jake)

• Task Manager templating functionality should be documented

  • * Alternatively get rid of templates and add options for #SBATCH or #BSUB directives

• Workflow IDs

  • * We had discussed changing the workflow IDs to make them more readable. Currently we’re using UUIDs.
  • I did a little bit of googling and found this page with a nice discussion about IDs: https://gnugat.github.io/2018/06/15/short-identifier.html.
    • I like their idea of using the first few characters of a SHA256 hash the same way that git does.

• Code quality

  • Fix messy code. Remove todos and such from code. Make sure all code passes pylama checks.
    • * Divy up modules
  • (Low Priority) Need to ensure the code has a consistent style. In the future, we might want to make a simple style guide to ensure consistent style across contributions.
    • Document Style Guide

• CLI Client

  • * The CLI client needs to be improved. The current version is annoying to deal with so a better solution would avoid user friction.
  • Agree to what we want

• Documentation

  • * Write user facing documentation for BEE. This will most likely use sphinx. (Pat)
  • Users need to know
    • How to run beeflow
    • How to clean up BEE stuff

• Packaging

  • * Need to choose a packaging method for users to install BEE.
    • Probably pip?
  • Need to choose a packaging method for users to install BEE.
  • Binary for client

• Versioning

  • Tim: Don't get bogged down by Feynman using major versions. use date in some fashion
  • Make a version issue

• * MPI Support (Jake/Pat)
  * Slurm support for release
  * LSF post release?
• * Wiki should be moved
• * Look over branches
  *purge unnecessary carefully; some may have information about related topics (such as cwl or machine learning)
• * Someone needs to look over moving BEE_Private to BEE (Pat) Talk to reidpr and MEJ

---

• Multiple Workflow Support (Next milestone)
  • Currently we can only run one workflow at a time. Need to add multi workflow handling capabilities.
    • The task manager and scheduler should handle this just fine as currently implemented.
    • The WFM will need to maintain a list of currently running workflows and their associated GDBs.
      • This will require asynchronous task queueing in the future to make the process more efficient.
• Will we have a BEE module for LANL customers on the HPC clusters/Darwin? (Post release)
• Improved Scheduler Support (Post release)
  • We’re not making the best use of the scheduler at the moment. We need to use it more and find a non-trivial test case. (Jake was working on fake workflows a while ago.) (Vasp from Steven) (BLAS?)
  • • Will we have a BEE module for LANL customers on the HPC clusters/Darwin? (Post release)

[trandles-lanl]

RE: Multiple Workflow Support - when it comes to the graphical client I might be good to implement this by using a new tab per workflow.