Looking at the number of options for image properties, it would seem that a blacklist would be in order. I would be in favour for ‘standard’ images which support fsfreeze to support guest agent and that some of the NUMA properties not be available for end user images, but still for system ones.
How about a list of delegated properties for images which could override the default flavor settings ? Tim On 20/07/16 00:40, "Daniel Russell" <dani...@hostworks.com.au> wrote: Hi Daniel, Fair enough. I don't personally understand your stance against having a configuration option to specifically disable guest agent but imagine there would be advantages to having a more generic implementation that can handle more use-cases (any property instead of just a specific property). I imagine there will need to be a nova scheduler component to it as well (Or we might schedule an instance on a hypervisor that is configured not to allow it). Is there a blueprint or spec for this kind of thing yet? I can help put one together if there is interest but the implementation is probably for more seasoned developers. Regards, Dan. -----Original Message----- From: Daniel P. Berrange [mailto:berra...@redhat.com] Sent: Tuesday, 19 July 2016 6:39 PM To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [glance][nova] Globally disabling hw_qemu_guest_agent support On Tue, Jul 19, 2016 at 12:51:07AM +0000, Daniel Russell wrote: > Hi Erno, > > For the size of team I am in I think it would work well but it feels > like I am putting the security of Nova in the hands of Glance. Yep, from an architectural pov it is not very good. Particularly in a multi-hypervisor compute deployment you can have the situation where yoyu want to allow a property for one type of hypervisor but forbid it for another. What we really need is the exact same image property security restrictions implemented by nova-compute, so we can setup compute nodes to blacklist certain properties. > > What I was more after was a setting in Nova that says 'this hypervisor > does not allow guest sockets and will ignore any attempt to create > them', 'this hypervisor always creates guest sockets regardless of > your choice', 'this hypervisor will respect whatever you throw in > hw_qemu_guest_agent with a default of no', or 'this hypervisor will > respect whatever you throw in hw_qemu_guest_agent with a default of > yes'. It feels like a more appropriate place to control and manage that kind > of configuration. Nope, there's no such facility right now - glance property protection is the only real option. I'd be very much against adding a lockdown which was specific to the guest agent too - if we did anything it would be to have a generic property protection model in nova that mirrors what glance supports. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
