Re: Two more libvirt GSOC ideas

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Mar 12, 2018 at 03:25:48PM +0000, Daniel P. Berrangé wrote:
> 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.

I agree that it might not be enough and honestly I can't objectively say (yet)
whether something could or could not be an appropriate idea (with a sufficient
amount of work needed) for GSOC, that's why I asked, so thanks for input.
However, there's also something else to consider (not a deal breaker though),
given the success overall success ratio we have, maybe this could be a
candidate that someone can actually finish on time and merge upstream :P, but as
I said, just a different point of view.

>
> > #2
> > PROJECT:
> > Extend node device driver's API set
>
> This sounds like a viable idea - well defined scope and not too hard

I published ^this one. Also, I'm working on publishing another one, but I just
have to use the right words.

Thanks again,
Erik

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux