[libvirt] Two more libvirt GSOC ideas

[Daniel P. Berrangé]

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