On Mon, Mar 12, 2018 at 04:18:35PM +0100, Erik Skultety wrote:
Hi,
I'd like to add 2 more GSOC ideas to our wiki page, but I'd like to get some
opinions whether you think these might even be appropriate GSOC project
candidates.
#1
PROJECT:
Support wildcard with log filters
SUMMARY:
Enhance the log filters format to allow specifying a wildcard, i.e. <level>:*
DESCRIPTION:
Currently, libvirt admin interface allows (among other things) runtime tuning
of daemon log settings with the exception of setting the global log priority.
The main reason for not having an API to get/set the global log priority is that
the same effect that setting global log level would have can be achieved with
using log filters only which in terms of logging control provide us with more
granularity. However, in order to achieve the same effect using filters only,
one would end up with a filter similar to this:
1:access 1:daemon 1:conf 1:cpu 1:libvirt 1:locking 1:logging 1:network
1:nwfilter 1:util
Therefore, we should enhance the format of a filter to allow us to simply use
the following instead:
1:* other_filters
I think this is too small a bit of work - it is more like a bite-sized task for
new-contributors.
#2
PROJECT:
Extend node device driver's API set
SUMMARY:
Modify the existing set (adjust/add) of APIs for node device driver in order to
provide similar functionality (conceptually) to other drivers.
DESCRIPTION:
The node device driver is responsible for host device management. In most
cases, this means that we're simply just report device's capabilities and track
its lifetime. This is enough for physical host devices, however, there are a
few other virtualization features like NFV, NPIV, and MDEV where libvirt should
also be able to create such virtual devices. Currently, libvirt is only able to
create transient (temporary config) NPIV/vHBA devices, so besides having support
for creating virtual functions and mediated devices on feature-capable physical
device we also need to be able to store persistent configuration of such virtual
devices.
Besides extending the existing set of APIs, this will also require a certain
amount of refactor of our current code base. Not all of the changes mentioned
above are absolutely necessary to finish the project successfully.
This sounds like a viable idea - well defined scope and not too hard
Regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|