On Thu, Mar 05, 2009 at 09:58:46AM +0100, Daniel Veillard wrote:
On Wed, Mar 04, 2009 at 11:03:17AM +0100, Chris Lalancette wrote:
These are all just minor auth credentials/acl config tasks that the admin has to deal with for normal remote usage already, so I don't see that they present a particular problem for migration
Yes, they are certainly all solvable from the admin's point-of-view, so they are not show stoppers. The thing is that I think admins will have a difficult time discovering what the problems are when migration doesn't work for them. There are just so many combinations that it's very easy for the admin to get one of them wrong, and then it may be difficult to figure out exactly what they need to do to get it working. On the other hand, having a dedicated channel makes it relatively easy; if the admin is having problems, then the answer is going to be "open port XYZ on the destination", and that will usually solve the problem.
From my POV, I think getting the auth fixed is a matter of installing proper files on a machine and of the responsability of the sysadmins basically and purely within their realm. On the other hand opening a new port is a decision involving network admins and security, it's not the same scope within a company with strict policies. I would really stay with the existing RPC model and avoid the requirement of adding a new open port, from a pure sysadmin "upgrade" perspective this can turn into a nightmare,
We've discussed this further on IRC and decided that if we need to get a better authentication system for migration, then we should extend the server RPC auth call to return a choice of multiple auth schemes. So, for example, we could allow normal virsh cients to run SASL/TLS, and for migration to run a one-time-key. The REMOTE_AUTH_LIST rpc command already allows for this struct remote_auth_list_ret { remote_auth_type types<REMOTE_AUTH_TYPE_LIST_MAX>; }; we currently just always return a 1 element list. We can easily add more auth options to the list without breaking existing clients too. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|