[GSOC 2020] Draft of proposal

2020-03-27 Thread Alberto EFG
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: alberto...@gmail.com
For GNU: alberto...@posteo.mx 

* 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  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   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  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 

[GSOC 2020] Final proposal

2020-03-29 Thread Alberto EFG
Hello, this is my final proposal for GSoC, there is still time to do
some changes in case anyone has feedback, otherwise this is it :)



proposal-final.pdf
Description: Adobe PDF document


Re: [GSOC 2020] Final proposal

2020-03-30 Thread Alberto EFG

Ricardo Wurmus writes:

> Hi Alberto,
>
>> Hello, this is my final proposal for GSoC, there is still time to do
>> some changes in case anyone has feedback, otherwise this is it :)
>
> Thank you for this thorough proposal!
>
> For 8.5 it would be good to provide criteria that allow us to evaluate
> your progress.  Being able to look at the code is obviously a
> precondition, but what we really want to know is what features will have
> to have been completed (and to what degree) at the time of the
> evaluation.
>
> For some of the deliverables and goals it would be good to see a little
> more detail if possible.  You mention systemd.device and systemd.socket
> files, but I can’t imagine what your goals with regards to the Shepherd
> are — is it to implement a similar feature (what exactly would that
> be?), or support for reading these files…?

Thank you so much for all the feedback!! I add my proposal with the
suggested changes.

I tried to be more specific with the goals, and the milestones. I added
a section, so number 8.5 is now 8.6, however I tried to be more specific
in the timeline than in 8.5.

Ludovic told me to focus my main goal on improving Shepherd internals,
rather than the systemd unit files parsing as that would be the "icing on
the cake", I hope that it is reflected on my proposal.

There is still a really short amount of time for last minute changes,
but this will probably be it.


proposal-final.pdf
Description: Adobe PDF document