I’m an undergraduate student at the University of Texas in Austin and myself along with a few other similarly experienced students want to develop a feature for lxd for a CS course on Virtualization. All of us have taken an undergraduate Operating Systems course previous to this. Our Virtualization class has focused on discussing how Virtual Machines and Containers are implemented and the mindsets behind each. We are looking for a project that would be reasonable to (mostly) complete in approximately one month of semester level time commitment. If anyone has any advice or project ideas, it would be greatly appreciated!!!
I’ve got a few candidates in mind that may work for this kind of time commitment.
I’m going to do a bit of cleanup on the relevant Github issues to make the work involved clearer and will post links here.
You mention that you’re looking for about a month of involvement but when would that be?
Most of the work I can think of would have to be done by end of year or end of January at the latest, is that something that’d work for you or should I be looking at feature work that we’re not committed to shipping in LXD 3.0?
The first feature is one that one of your classmates(?) reached out about separately.
That particular issue is very tricky as it requires some API changes and integrates with our storage and migration code, both of which are very complex and have a lot of corner cases.
@brauner may be able to give you a better idea of the complexity there. My understanding is that we have all the right low level pieces already but some refactoring would likely be needed to allow them to be re-used against an existing container.
Another one is one of my favorite pending feature requests:
This would allow for port forwarding between host and container and between protocols.
If you have an interest in pretty low level namespace and networking work, this would be a good fit.
It’s also not an easy one for sure and I’m sure we’d need to rethink some of the details along the way, but it would be a good one to understand how namespacing works in the Linux kernel and how to pass information across namespaces.
Another new device type we’ve discussed in the past is something like unix-hotplug.
This would have you learn about how devices work in Linux, deal with udev to track down the /dev nodes that get created when a USB device (or other type) is plugged in and then how to pass those into a container and properly clean things up when unplugged.
And one last one we have planned but were missing an issue for.
This one is about adding a new API for containers to get notifications when devices or configuration keys are changed so that the container can react to it.
And if you’re looking for something pretty easy as a starting point, you could look at this one:
This may be a good way to just learn about what files need updating when adding a new configuration key, what documentation needs changing, …
The only not trivial part of this one would be to have the change happen dynamically, removing/adding the path and mountpoint in running containers. But that’s something we can definitely help you with once you’ve got the rest of it figured out.
And another one that you already commented on which I’ve now provided a few more details on and that should also fit the bill as far as how much work would be involved I think.
Another thing was to add support for functional and arrow keys sent from Windows LXC client. But that is a long way down the rabbit hole to USB HID support in golang and reworking Linux terminal from 40 years back. Something with complexity of PhD in CS, but without any formulas.
As you said, right now supporting arrow keys on Windows looks like a massive effort involving raw access to keyboard input from Go. Given that our metrics right now show users of the Windows client at being less than a tenth of a percent of our userbase, I don’t think it should be a priority
I’m sure there are other Go projects that need this particular feature far more than we do and we can benefit from any work that they do on this once they sort it out.
