Join GitHub today
Allow multiple instances of Umpleonline to access common file store #1123
Currently UmpleIOnline is tied to its own local store. Using Docker it is possible to map some other store into a running image. However it would be good to generalize this so UmpleIOnline can be run on a set of servers to get lots of CPU throughput, with file saving happening in a common location.
The main issues regarding this that need to be resolved are:
b) Directories given a permanent URL would also need adjusting so they are not directly under ump following the same scheme.
c)Older directories should still be accessible.
d) The cleanup code that purges old tmpxxxx would need to be adapted.
e) Probably each server, on startup, could get a code that would become part of the yyy that it creates.
I've done some reading and some thinking, and I have an alternate idea: don't share UmpleOnline's data store, at least not literally.
What we can do instead is a little subtle, but may be rather effective. It may also be easier from a code point of view.
First, what I perceive to be the reasons for using distributed UmpleOnline:
My idea can achieve the above somewhat like this:
Why I think this is interesting/useful:
If you think this is an interesting avenue, I can clean it up and move it into a wiki for further discussion/refinement.
referenced this issue
Nov 14, 2017
referenced this issue
Nov 20, 2017
@TimLethbridge While working on the $filename refactoring, I checked up on the S3 mounts to make sure they supported some of the tricks I was doing and I have some bad news: the S3 approach will likely not work out very well. I think we both made a couple of assumptions about how S3 mounts work.
So this then leaves us with the question: what to do then? If we're ok with a system that by design choice will likely go no further than a single server with cloud storage without a complete 180, we can do that but it seems like that is a fairly large compromise to make. What are your thoughts?
Potential note of interest: the refactor is not trivial as I already have to go through and vet most of the file operations for assumptions like "../../ will get me to the root directory". Factoring in #1122 which is not pretty either (our code is more complex than I thought, consider for example temp folder generation), it might not actually be much harder to use a different storage medium if we want.
Also for what it's worth, if we don't want to do our own DBA, several SQL/NoSQL database hosting services exist.
@TimLethbridge here's the refactoring plan you requested: https://github.com/umple/umple/wiki/Refactoring-UmpleOnline's-storage-backend
The lines are not particularly granular, but should be generally representative. There may be a few changes to callsites of functions in compiler_config.php. Let me know if a more precise set would be useful.
I'm also interested in your thoughts on my interpretation of the interface UmpleOnline requires. Does anything seem off to you? Did I obviously miss something?
If all goes well, the proposed structure of my proposed marathon session is: