Fiche de suivi - CoCass

Week 1: January 25th - January 31th

• Getting familiar with Docker (for some of the group members)
• Fix Docker's DNS issue using public network (wifi-campus/eduroam)
• Contacting our supervisors
• First thoughts on this project, what we could do
• Redaction of specifications, creation of architecture diagrams
• Create scripts that start/stop containers automatically (some modifications still need to be done)

Week 2: February 1st - February 7th

• Manage and limit space disk usage of each container, limit resources allocation at containers' launch.
  • CPU and memory allocation: ok
  • Docker doesn't seem to implement easy way to limit container's disk usage: implementing a watchdog (script) which will check container's disk usage and stop those that exceed a limit
• Think about restricted access to Docker containers: for the moment, providers are admin and can easily access containers
• See how instances can easily give their network information to coordinator
• Get familiar with Shinken and study the possibilities
• Specification of technologies used
• End of specification redaction + feedback from tutors
• Start to work on Meteor-AngularJS tutorials
• Configure a personal VM for the frontend & setup meteor-angular on it

Week 3: February 8th - February 14th

• Objective for this week: get a prototype that contains a basic front-end which makes it possible to launch remote Docker instance.
• Container deployment:
  • Deploy all containers on the same network: that allows us to connect to the instances from the coordinator
  • Create user on host: will be used to connect ourselves in ssh from coordinator instance to host and launch deployment scripts
  • Create script that totally automatizes user creation, images creation and build, coordinator's and shinken's containers launch
• At the end of the week, the prototype is working: we can launch an instance an a provider machine from the front-end. We still need to establish and test the connection between a client and his instance. We have a good cornerstone of our project yet.

Week 4: February 15th - February 21st

• Try to establish a connection between a client and his container
• Continue client/provider's web page development on front-end
• Start editing help page
• Correct some responsive effects on the site
• Container deployment:
  • Implement bandwidth restriction
  • Create script that automatically set client public key in container's authorized_keys file, modify some script to automatically delete client public key in coordinator's authorized_keys file
• Start to study and set up Rabbitmq (publish from provider to front-end for example)

Week 5: February 22nd - February 28th (Vacation)

• Update wiki/help page, work on some responsive issues on the website
• Establish script that automatically create SSH-jump config for the client
• Work on foreign keys and database (front-end side)
• Continue front-end development
• Establish rabbitmq on both front-end side and provider side

Week 6: February 29th - March 6th

• Container's deployment:
  • Modify coordinator Dockerfile to install nodejs
  • Create a cron job that will run a command every 30 seconds: that command will be used to send the file that contains container's information to rabbitmq server
  • Modify coordinator to set up 2 users: one for the front-end and one for the clients. Each one will contain only the public key they need in authorized_keys' file
  • Modify startProvider script to check is ssh-server is installed and running on provider, and change default port (22 to 22000)
  • Modify watchdog functioning: up to now, the script was just checking if each instance was respecting a limit. Now its behaviour allows us to have different disk usage for each instance. Now we use a cron job, we won't need anymore to launch the script by ourselves
  • Change monitoring system: we found an other monitoring system for Docker called cAdvisor which gives us enough informations about containers.

• Frontend dev:
  • Generate a proper & unique instance name : <username>-<provider_domain_name>-<num_instance_user_at_provider> eg. : toto-domain1-0
  • Add form to modify provider machines informations
  • Fix warning "CSS file deliver as html file" by Meteor
  • Add README to explain how to use scripts, how files are organized (for github branch : frontendWebui , docker , master )
  • Improve user feedback (notifications) on errors/success
  • Proper parameters to start/stop instances
  • Add username field in profile
  • Resolve bugs occurring when the machines allocate resources from a different user

• Test and feedback:
  • Set up the main test: container deployment and access to instance from the client
  • Some permissions on coordinator instance needed to be changed
  • SSH default configuration needed to be changed to: disable root login and authentication by password
  • Connection from client to his instance is working

=> The main development phase is finished since we have a working base. We still need to improve some things, eventually develop some advanced functionalities during the last two weeks.

Week 7: March 7th - March 13th

• Finish creating the flyer
• Write report for our last MPI course
• End of Rabbitmq set up on front-end
• Test complete loop:
  • Create profile
  • Set required information (ssh public key)
  • As a provider, give settings of the provided machine
  • As a client, ask for an instance
  • As a client connect to the instance (ssh)
  • Check that Rabbitmq is correctly tracing back information about containers/instances
• Add a rating system which will be used to give a mark to providers.
• Start preparing the presentation

Week 8: March 14th - March 17th

• Finish presentation preparation
• Fix some bugs:
  • Start instances if they already exist
  • Stop instances and no longer remove them in order to be reused/started again
  • Really remove client instances running on provider when he choose to not be available
  • Others minor fixes

Useful links

Network related

• SSH Jump Host