guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GSOC 2020] Draft of proposal


From: Alberto EFG
Subject: [GSOC 2020] Draft of proposal
Date: Fri, 27 Mar 2020 05:22:27 -0600
User-agent: mu4e 1.2.0; emacs 26.3

Hello, this is the draft of my proposal "GNU Guix: Syntax and semantics
of systemd units in the Shepherd"

Any feedback is welcomed :)


* Name
Alberto Eleuterio Flores Guerrero

* Email address
For Google: address@hidden
For GNU: address@hidden 

* Title: 
GNU Guix: Syntax and semantics of systemd units in the Shepherd

* Summary
The GNU Shepherd has a Scheme interface to define services, most importantly 
their dependencies and actions associated with them. The goal of this project 
is twofold. The first part consists in matching the semantics of systemd's 
.service unit files, more precisely a subset thereof (for instance, the 
DBus-related part may be omitted.) As part of this work, the Shepherd should be 
extended with kernel Control Groups (cgroup) support on systems that support 
it. The Shepherd should also be extended with a procedure to load a .service 
file and return a <service> object.

The second part will consist in implementing other types of systemd units, in 
particular systemd.socket activation and systemd.device.

* Benefits
Right now systemd is used by some of the biggest GNU/Linux distributions, this 
includes the FSF approved distributions Parabola, Trisquel and PureOS. It is 
pretty clear that systemd has the biggest user share of the Init systems 
(although systemd is more than just an init system). 

With this in mind, adding the ability to handle systemd unit files to the 
Shepherd will have this benefits:

1. Shepherd will be extended to have a bigger API than it currently has, making 
it more powerful. 
2. Users will be able to use their custom systemd unit files with little or no 
effort on Guix. This will also ease the work of migrating from most 
distributions to Guix. 
3. More distributions could be interested in adopting Shepherd as an 
alternative to systemd.

** Considerations
Systemd is a project outside of Guix and Shepherd, it has been under heavy 
development in recent years and the decisions by the developers are some times 
criticized. Changes might be expected and compatibility might be broken from 
time to time. 

I understand this, and that my project will require continuos development and 
manteinance after the end of Google Summer of Code, I am willing to work on 
this for as long as possible. 


* Objectives 
1. Extend GNU Shepherd capabilities to handle systemd.service files 
    1.1 Add the appropriate mechanisms to GNU Shepherd API according to the 
systemd.unit and systemd.service files.
    1.2 Extend GNU Shepherd with cgroup support.
    1.3 Add a library to parse systemd.service files and return an instance of 
the  <service> class.
2. Extend GNU Shepherd to handle other systemd.unit files, specifically 
systemd.socket and systemd.device
** Notes
All the implementations of systemd unit files and cgroups will be according to 
the Freedesktop specification.
https://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
https://www.freedesktop.org/software/systemd/man/systemd.unit.html
https://www.freedesktop.org/software/systemd/man/systemd.service.html

* Deliverables
1. The module service.scm should be extended for new methods and slots created 
to match the systemd semantics. Specifically for systemd.service, systemd.socet 
and systemd.device files.
2. Extend Shepherd to support cgroup.
3. A module written to parse systemd.unit files specifically systemd.service, 
systemd.socket and systemd.device 
4. The documentation for GNU Shepherd is written in the texinfo format in the 
file shepherd.texi, this file will be updated to reflect the changes and new 
capabilities of GNU Shepherd. 

* Plan
** Before announcements (Today - May 4) 
I would like to work during this period in my Scheme abilities, solve bugs for 
Shepherd and Guix, get familiar with the coding standards, environment setup 
and workflow. 
** Community Bonding Period (May 4 - June 1)
In case I get accepted to work on this project, I would use this time to:

1. Compare systemd and GNU Shepherd API's to have a clear understanding of the 
details of this project. 
2. Talk with my mentor about the design of the modules to be implemented during 
the project.
3. Become familiar with GNU Shepherd internals.
4. Work on my GOOPS abilities. 
** Coding (June 1 - August 24)
*** Period 1 (June 1 - June 29 )
1.  Extend GNU Shepherd to implement cgroup support on systems that support it.
2. Implement the missing mechanisms on GNU Shepherd of the systemd.service API.
*** Period 2 (July 1 - July 27)
3. Implement the missing mechanisms on GNU Shepherd of the systemd.socket API.
4. Implement the missing mechanisms on GNU Shepherd of the systemd.device API.
*** Period 3 (July 27- August 24)
1. Write a module to parse systemd.unit files and return them as a <service> 
object. 
2. Write documentation.
** After GSOC 
I would like to work on extending GNU Shepherd, improving the documentation, 
and making sure everything keeps working in case there are changes in systemd.

** How will everybody know whether things are on-track at the half-way 
evaluation point?
For my code repository I can set up a Gitlab or any git repository or send the 
code I write everyday to the mailing list. Whichever way my mentor feels is 
more appropriate.
** Other activities
Part of my school semester will overlap, although my school activities are 
mostly on weekends so it should not interfere with my work of GSOC.  

* Communication
I can communicate using the Mailing Lists of GNU Guix. I already had and I have 
sent a few patches already. 
I can communicate in IRC with the nickname Blackbeard and with the Matrix 
account @blackbeard:matrix.eunichx.us

* Qualification
**  Why did this project appeal to you?
- It is a GNU project
- I would love to work on a Scheme project.
- I am a user of both Guix System, and Guix package manager. Sometime in the 
past I installed GuixSD and thought "it would be easier for me to be able to 
use systemd files" because I didn't know how to use Shepherd. 
- I think this project could benefit users not used to Scheme and who want an 
easy way to enjoy the benefits of Guix without taking much of their time.

** How will you benefit from it?  
I will learn about GNU Shepherd internals and will be able to contribute more 
to GNU Guix and become better at programming, specially in Scheme. 
** Why are you particularly suited to work on this? 
I am not a Computer Science student and I might not be really qualified, 
however I particularly like Lisp, I am recognized as a small contributor in the 
Acknowledgments of the book "How to Design Programs 2 Edition" (as Alberto E. 
F. Guerrero) a book that teaches functional programming and test driven 
development in Racket. I am also a proficient Emacs user with a huge 
configuration and custom modes. 

I've also read and worked through Structure and Interpretation of Computer 
Programs, The Land of Lisp, among others. This means I can be an independent 
learner and I would enjoy working in this project. I've also sent a couple of 
patches to GNU Guix already and I try to help users on the #Guix IRC channel as 
much as I can.

** Background
In the personal side, I am a promoter of Software Freedom. I am a student of a 
master of Law of IT, because I want to promote and advocate for the human 
rights in the digital world, and I've even met Richard Stallman in person a few 
years ago when I assisted to one of his conferences in my country. 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]