We need to be able to override the certs on container run time.

Finish script to dynamically populate hosts file based on user ids list

Move all the config related functions to a single bash script that we can source from anywhere else so we can query the config easily

We need to be able to append the extra config to the frontend proxy command, so need to provide extra docker command param just as the usual editor/webserver containers

• Add option in config file
• Pass option on the upstart launchContainer scripts to the cloud_frontend_proxy service

Config / logic could be greatly simplified by leveraging docker compose, and using linking between containers, since most of the logic would be taken care of by docker-compose.

• Whatever variables are external can be provided to docker compose through env files
• No upstart logic for each of the services needed, just fire docker-compose
• frontend proxy gets linked to each of the containers through docker compose, so no need to find/set ports manually

Right now, changes to the user config can only take effect by restarting the entire sandbox environment, which is not ideal. We need a method to relaunch the main docker container (excluding the auth container), without killing the frontend cloud proxy. Since the docker container names are linked to users by convention this should be relatively straightforward

TODO

• Check upstart/launch_containers logic to see how containers get launched for each of the users. The methods launchWebserver && launchAuthentication are useful. The current loop logic could be extracted out to a per user method, then the logic is not duplicate and we can reuse the method for individual relaunching. We also need a stop method to stop the previous containers.

We need to be able to add config blocks on top of the standard cloud-development rules, such as load balancer health check responses, etc.

• Allow to provide a folder w/ extra config files
• Move that folder inside the /etc/nginx/extra on runtime and include that folder inside the nginx config

There is some problem with the webserver not being readable

with fallback to localhost if BASE_HOSTNAME is not provided

We append cloud-webserver- to all images on build but also on deploy. This breaks being able to deploy from external docker images, so we need to remove them, it's unnecessary since it can be added into each of the user's configs anyways.

Finish script to launch all containers for all users based on configuration

• Check why the mapping fails.

Once it's working:

• Rewrite vhost generator to use user/configuration class if possible through symlinks
• Restricts containers to listen only on the docker0 interface instead of everywhere

Idea is to have github-repo.ISSUE/tag

Github Webhooks:

• Hooks on pull request open/close to talk to the cloud-development server (in addition to a preconfigured tag).
• Hooks on pull request updates (so we can reupdate the deployment when a commit comes)
• Pushes to the github issue for posting update comments (so we can eventually display the deployed server url)

Nodejs Webhook Server

Nodejs webhook listener server

• Runs an nodejs docker container server that listens to the git webhooks (needs secret key)

New user creation / deletion

Folders:

• For creation: Clones from a preconfigured base user to a new folder for the new user (user will go by pull-request number)
  • we might have to use github authentication or password since google auth callback subdomains don't accept callbacks
  • Runs a preconfigured script on the repo folder that needs to be provided (on the base folder) that takes the git commit and will bring the repo folder to a working state. We need to provide a placeholder <PR_NUMBER> that will be substituted in the script
• For deletion it'll simply remove the folder and that's it.

User:

Need to create/remove the new user list based on the github repo/issue and map to the correct folders.

• Reads configuration from predefined github "users" (so container commands can be added)
• Dynamically maps folder to the new folder

Initialization

• Launch the webserver/auth combo for a single user (or destroy it if it's the delete command). We can reuse code from the launchContainers script
• Reinitialize the cloud-frontend-proxy from within the server, and it should work since the configuration will be rebuilt using the list of users.

Update: Easier for now

Otherwise for now we can use the cloudDevelopment stop/start service for reinitializing the whole stack

Instead of hardcoding 8080 as the starting port for automatic deployment, make it customizable thorugh the config.

http://askubuntu.com/questions/518048/upstart-multiple-parameters

for handling dynamic upstart script

Plus add git ssh key functionality to the cloudbox so users can use git within cloudbox.

We need methods to easily modify the configuration programatically. The current getters are

getUserWebserver
getUserWebserverPort
getUserWebserverVolume
getUserWebserverDockerCMDExtras

so we need

• setUserWebserver
• setUserWebserverPort
• setUserWebserverVolume
• setUserWebserverDockerCMDExtras

all methods take the as first parameter and as second

Please add some screenshots of codeboxIDE to get a better idea what this is about.

https://github.com/InstantWebP2P/peer-vnc
http://kanaka.github.io/noVNC/noVNC/vnc.html

Instead of running a native cloud editor, we might be able to get away for simple editing to use a vnc based application