On Thu, Apr 04, 2019 at 10:17:10AM +0100, Daniel P. Berrangé wrote: > On Wed, Apr 03, 2019 at 03:52:50PM +0200, Pavel Hrdina wrote: > > We will call this function multiple times so it makes sense to cache the > > result so we don't have to call libvirt APIs every time we will check > > what security features are available on the host. > > > > Signed-off-by: Pavel Hrdina <phrdina@xxxxxxxxxx> > > --- > > virtinst/domcapabilities.py | 11 ++++++++--- > > 1 file changed, 8 insertions(+), 3 deletions(-) > > Arguably you can cache the entire capabilities API call for virt-install > since it won't change in the lifetime if a short virt-install > invokation and even if it does change you likely want virt-install to > have a consistent view of capabilities throughout its execution. We do the entire capabilities caching as well, the host capabilities are cached per connection and domain capabilities are cached per guest and refreshed if something changes like QEMU binary, machine type, etc. This adds caching of the baseline API call. > For virt-manager though being more dynamic is possibly more desirable > given its long life. > > Reviewed-by: Daniel P. Berrangé <berrange@xxxxxxxxxx> > > > 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 :| > > _______________________________________________ > virt-tools-list mailing list > virt-tools-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/virt-tools-list
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
