You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The front end is almost in a state where it could be easily moved to App Engine. This would save us from having to maintain the process on a virtual machine and bring other benefits of App Engine such as auto-scaling. There are a few issues to sort out:
Figure out how to read nearcore git repository. When scheduling runs, the front end needs to access the nearcore repository. More specifically, the commit message and contents of the nightly directory of a given sha / head of master branch. Currently this is easy; the repository is cloned and updated whenever new run needs to be scheduled. If front end was moved to App Engine we’d need to figure out how to deal with that. Cloning the entire repository each time new run is scheduled would introduce latency to the call and keeping the repository isn’t that great of an option when storage is ephemeral.
Migrate from apsscheduler to App Engine Cron service. This shouldn’t be too complicated.
Use App Engine credentials to access Cloud Storage.
Use App Engine credentials to access Cloud SQL. If I understand App Engine correctly each app automatically gets credentials to authenticate as itself and those can be used to gain access to other Google Cloud services. This would simplify configuration.
Make the switch.
The text was updated successfully, but these errors were encountered:
The front end is almost in a state where it could be easily moved to App Engine. This would save us from having to maintain the process on a virtual machine and bring other benefits of App Engine such as auto-scaling. There are a few issues to sort out:
nightly
directory of a given sha / head of master branch. Currently this is easy; the repository is cloned and updated whenever new run needs to be scheduled. If front end was moved to App Engine we’d need to figure out how to deal with that. Cloning the entire repository each time new run is scheduled would introduce latency to the call and keeping the repository isn’t that great of an option when storage is ephemeral.The text was updated successfully, but these errors were encountered: