search

React-Automation-Studio / React-Automation-Studio

React Automation Studio is a new software platform to enable the control of large scientific equipment through EPICS.
Other
64 stars 18 forks source link

Suggestion: Develop a roadmap for RAS #72

Open fuse-energy-dev opened 2 years ago

fuse-energy-dev commented 2 years ago

Hi @wduckitt, Josh here. Thanks for the chat the other day.

After talking, it occurred to me that a roadmap might be a good idea, given what we discussed about the different contributors. That said, I'm very interested in being part of that as it would help push things in the right direction, whatever that might be.

hanak commented 2 years ago

Thank you for creating the issue. Reading the message, it feels there are some thoughts already. Would there be a chance to share those so that others may contribute?

fuse-energy-dev commented 2 years ago

Thank you for creating the issue. Reading the message, it feels there are some thoughts already. Would there be a chance to share those so that others may contribute?

@hanak Thanks for your patience. I was away on a much needed holiday.

Yes, I do have some and I know that @wduckitt has his own plans, per our chat. But I will speak to my ideas and if there is merit perhaps we can move forward in some way.

My main beef is scalability. I also have issues with the the boilerplate project and wonder if there isn't a better, more scaleable way.

  1. Play to RAS's strength: portability. Release as a package or packages instead of having the interface code (React.js, etc) with the IOC code (EPICS).
  2. Simplify the mono-repo a little. I believe some of the things can be simplified. Will save details for another time.
  3. Base docker images with different support options. Like a "fully loaded" (opinionated), a standard, and a barebones, zero-support modules EPICS base)
  4. Full documentation of all default environment variables
  5. State Machine IOC example image: PySMLib for a python based SM, and/or SNCSEQ SM examples
  6. Use service like snyk to manage vulnerability scans for RAS, (it provides the hotfix, patch PRs for projects linked to the service, we just have to do the checks and tests on builds
  7. Use CI/CD like Jenkins to build and test images and interfaces (see 6. as it is directly related).
  8. Improved Generalization documentation
  9. Multi-arch support: I have used multi-architecture builds using emulation for both amd64 and arm64, using Dockerx and moby buildkit images. I have found that having base images built for different architectures at the ready has been most useful for spinning up new instances on different hosts. Our system is distributed over amd64 hosts and Raspberry Pi 4s.
  10. Provide example/simulation DBs and configs for dummy hardware. What do I mean: you can generalize most hardware to a few functions, as @wduckitt has done with the demos with the beamline hardware. What about other standard hardware? This could be a "contributors corner" kind of thing.

I also think that there are some really amazing work being done by the folks at Bluesky Project. What I love is that every experimental campaign for us, the data is displayed in a Jupyter notebook, or set of them, while the operator either uses commands in the notebook, or with connected UIs. Right now, it appears that QT5 for python is the preferred framework. I think that RAS could make a strong play here. Browser native. Distributed. Reproducible.