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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
