Issue617 refactor service with history 2 #652
Conversation
This commit introduces the concept of separate worker and web server processes. The worker is a distinct docker container that is respnsible for carrying out a simulation. The web server is within a separate container is only responsible for serving http requests. A redis database is used to communicate between the worker and web server. The web server and worker may scale indpendently and it is expected that a deployment would involve many workers to manage multiple simultaneous simulations/tests. This commit is organized such that it adds to the existing boptest project layout, but it does not disturb any of the existing project layout. The worker depends on and makes extensive use of the existing boptest libraries, especially those APIs in testcase.py as well as the forecast and kpi source code directories. Currently the web api presented by the web server is conceptually equilvant, but not api compatiable with the existing boptest/master API. A future commit will resolve this difference. To test this commit: cd <project-root> docker-compose build docker-compose up web worker After starting the services defined by docker-compose, a web application should be viewable in the browser at http://localhost * There is a graphql https://graphql.org api viewable at http://localhost/graphql * This architecture depends on bulk file storage such as Amazon S3. In development mode a mino https://min.io container stands in for S3, and is available at http://localhost:9000. From this interface it is possible to view raw file (test case) uploads and simulation files. The default authentication can be found in the .env file that is included in this commit * A forecast API has been added, which was not previously available in Alfalfa
Working (although incomplete) twoday example
Update API and add example controller
There is global attribution at the project root
Use redis messages to generate results as they are requested, instead of the very time consuming approach of computing them on every step
Remove some unwanted Alfalfa isms
|
@EttoreZ @javiarrobas @terrancelu92 This PR is ready for beta testing. Can you checkout the branch FYI @kbenne |
* Within worker, add logs when a message is received and immediatly after a response has been sent. * Include HOSTNAME in the test metadata that is stored in Redis. For a K8s deployment, HOSTNAME will correspond to the name of the pod running the test. This will make it possible to retreive worker logs for a misbehaving test. * When a test is complete, the worker and the associated logs, may no longer exist, however the logs will still be available in the log file contained within the test payload that is pushed to long term storage. * These changes pertain to worker, however there is an existing log message within the web implementation that logs when a message is sent to the worker, but no response is received. Additionally, each message between web and worker is given a unique ID, therefore with all of this togethor there will be breadcrumbs if a message is dropped.
* The default message timeout is now 20 minutes, and the value is configurable using the BOPTEST_MESSAGE_TIMEOUT environment variable.
The message subscription timeout is now configured as BOPTEST_MESSAGE_TIMEOUT + 60 seconds
service/README.md
Outdated
There was a problem hiding this comment.
I suggest merging this one with the README.md at the root directory.
There was a problem hiding this comment.
Ok, but what do you think about in the API request table, somehow having some separation in the requests specific to user/namespace-specific test cases from those to select from the public IBPSA test cases and other functional API requests (e.g. /advance, /results, etc.)? Because I think of those as more advanced user type things that I don't want people to get confused about when just starting to try BOPTEST with our public test cases.
I could propose something.
service/version.txt
Outdated
There was a problem hiding this comment.
I think we don't need to track the service version anymore after it is merged.
There was a problem hiding this comment.
Agreed. I can make a commit to remove this. I think we might need to coordinate some changes in the web server where the /version endpoint is implemented.
There was a problem hiding this comment.
@kbenne Ok, please make a commit to take care of this.
|
I've been trying to deploy it myself locally. It seems that upon calling
Would it be possible to specify just one testcase instead of provisioning multiple? When working locally, we typically want to interact with just one test case. If we select just one test case to deploy we could save some time and resources. |
|
Another suggestion is to pin all Dockerfile images to EDIT: Now that I think of it, this may not be needed for images other than |
I'm not sure why some of the testcases are not provisioned. From your log it does appear to be true, but I would double check by calling the The default provision command which is invoked by |
I'm double checking with the Notice that it gets stuck with
My guess is that it does get stuck in the |
@javiarrobas Hm, will need to look into this. Provisioning actually doesn't start running (or initializing) any of the test cases. All it's doing is copying the FMU files into the Service's storage for when a request to start a test case is received, the FMU is loaded into the worker, upon which then the initialization happens per previous method of local deployment (e.g. with testcase.py). EDIT, I feel like I ran into this problem before and I need to look back in my notes. EDIT2, actually, I read the issue more closely - that it's for some reason appending "test_" to the beginning for multizone_residential_hydronic. This I'm not sure I've seen. Need to look still. |
This is for #617 and #671 and in place of #622. It does everything from #622, but merges the Service architecture in a way to include the nrel/boptest-service git history.