From Fedora Project Wiki

GSoC 2016- Automatic Atomic Host Updates

Contact Information

  • Email Address: sacredlight2709@gmail.com

Questions to answer

Why do you want to work with the Fedora Project?

Fedora was the first Linux Distribution I used after hearing about Linux when I joined my Diploma in Computer Engineering Course. Since then, Fedora has been my primary OS for almost 7 years now. Fedora helped me understand how concepts like OS, Networks, Memory Management, etc. are actually implemented while I was learning them as a part of my Engineering Curriculum. I feel very grateful to Fedora and the Fedora Community with whom I could learn so much and I want to work with Fedora so that I can use the skills I have developed for giving back to the community with whom I grew up.

Do you have any past involvement with the Fedora Project or another open-source project as a contributor?

Yes, I have contributed to CernVM technology by CERN as a part of GSoC 2014.

Have you participated in GSoC in the past? If so, what year(s) and which organization(s)?

GSoC 2014 - Project: Streamline CernVM Contextualization Plugins, Organization: CERN-SFT

Do you plan to continue contributing to the Fedora Project after GSoC? If yes, what sub-project(s) are you interested with?

Yes, I would like to keep contributing to Fedora all year round, even after GSoC. I am interested in Automatic Atomic Host Updates and the Anerist project.

Why should we choose you over other applicants?

Having prior GSoC experience I am aware of the process, the efforts needed and I am familiar with the teamwork involved while working with the community and project mentors. I also have the passion and determination to learn and successfully complete the mentioned project. Specific to the Project, I have the both the required skills and the bonus skills mentioned for the project and the work is similar to my project at CERN.

Proposal Description

Overview and The Need

To implement a service that automatically upgrades the system when a new image is available. If the system is not restarting correctly, the rollback to the previous working version. The rollback is a necessary mechanism to be implemented because if an automatic update fails, we need to rollback to the previous OSTree. The related issues have been open in the rpm-ostree git repository since more than a year (#177,#44,#147) and implementing this project shall solve them.

Any relevant experience you have

Relevant Experience:

  • GSoC 2014 - CERN- SFT, Project: Streamlining CernVM Contextualization Plugins (Languages: Shell, Python, C | Technologies: Public Clouds, Virtualization, Kernel Development)
  • Taken the Artificial Intelligence, Machine Learning and Image Processing Courses during the degree in Computer Engineering(Language- Python 3).
  • Completed Udacity's Machine Learning Engineer Nanodegree (Language- Python 2.7).
  • Engineering Degree Capstone Project - Business Intelligence - Data Driven Hedging (R Language, Forecasting and Machine Learning)
  • Basic Experience with Google Tensorflow Python API
  • Good Problem Solving and Debugging Skills.

How do you intend to implement your proposal

I shall implement the proposal as per the timeline given below along with weekly documentation of the work. If the automatic upgrade mechanism is to be implemented, then we also need an automatic rollback mechanism which will identify if an upgrade is successful or not and rollback if necessary. There are various tools which can be used to determine if the rollback is necessary or not like- systemd timer, sanity checks, reading the kernel ring buffers for boot messages, journalctl. These can detect failures which could trigger a rollback. Initially I will use these tools to decide which one aptly determines that an upgrade has failed or not. Then if the rollback (atomic host rollback) is be performed, the error messages or the cause of the rollback shall be logged.

A rough timeline for your progress

The summer coding period spans for about 12 weeks which I would like to plan as follows:

  • Community Bonding Period: Gather as much information as possible about the current issues and the needs of the project.
  • Week 1-5: Implement the basic solution and test it to check if it functions as per the requirements.
    • Week 1: Implement a Daemon process or write a cron job which will detect if new updates are available and fire the [ sudo atomic host upgrade command ]
    • Week 2: Check different tools (e.g. systemd timer, sanity checks, reading the kernel ring buffers for boot messages, journalctl) and compare which ones better identify a rollback scenario, i.e., detects a failed upgrade automatically. Document the pros and cons of each tool for future use. Select a couple of the best ones.
    • Week 3-4: Implement the basic automatic upgrade mechanism: Implement the upgrade failure detection mechanism, for e.g. systemd timer for automatic host upgrades. This mechanism should detect if the system is able to successfully boot after an upgrade and if not, then the rollback command should be fired.
    • Week 5: Integrate automatic rollback mechanism: Once the code for detecting a boot failure is in place, automatic rollback can be implemented by writing a script that fires the [ atomic host rollback ] command.
  • Week 6-7: Implement the complete Automatic rollback mechanism which works in most of the known conditions.
  • Week 8-9: Implement logging for boot failures which can be accessed after a rollback
  • Week 10: Modify the code for production environment and conduct tests to find out if there are any bugs. Integrate the code with Fedora.
    • Finalize the Code and restructure if needed to follow Fedora's coding standards.
    • Integrate with Fedora and run more tests.
    • Collaborate more with the community to know if any additional changes are needed and implement them.
  • Week 11,12: Make any new changes if needed or suggested by the community and documentation. One week of buffer time in case any unforeseen delays take place.
    • Changes if suggested by community and Code clean-up.
    • Report writing for GSoC final submission.
    • Buffer time for unforeseen delays.

Final deliverable

Expected outcomes:

  • Automated updates integrated into Fedora Atomic Host
  • Learn how RPM-OStree packaging and images work
  • Develop ability to contribute to Atomic Host
Retrieved from "https://fedoraproject.org/w/index.php?title=GSOC_2016/Student_Application_gaya2709&oldid=440739"