[libvirt] [RFC] new preferences requirement
Hi, all We have some new requirements of preferences, I listed which of them I known, and think is useful as follows: 1) for the path of x509 certificate and keys of client The path of x509 certificate and keys of client is hard coded in remote driver. e.g. /* Defaults for PKI directory. */ # define LIBVIRT_PKI_DIR SYSCONFDIR "/pki" # define LIBVIRT_CACERT LIBVIRT_PKI_DIR "/CA/cacert.pem" # define LIBVIRT_CLIENTKEY LIBVIRT_PKI_DIR "/libvirt/private /clientkey.pem" # define LIBVIRT_CLIENTCERT LIBVIRT_PKI_DIR "/libvirt/clientcert.pem" 2) for default default driver and subdriver for disk image Another requirement of new preference is default driver and subdriver for disk images, currently we use "phy" for "driver" in virsh, and "raw" for "subdriver" in qemu driver by default if user doesn't specify them, it causes bugs, though we could say to user "you should use options --driver and --subdriver", but these two options are optional. IMHO, the best solution for those bugs is to provide new preferences. 3) for default NIC and storage type "Chris Phillips" raised up the requirement not long ago: http://www.redhat.com/archives/libvirt-users/2010-November/msg00033.html ==================== Should we add these new preferences(if they are really neccessary) in qemu.conf? or create new config file, e.g. The approch Justin raised up an approch before: http://www.redhat.com/archives/libvir-list/2010-November/msg00651.html Though for Justin's approch, IMHO we'd better also to provide a default config file, e.g. "/etc/libvirt/client.conf". Any feedback is welcomed, thanks - Osier
On 01/12/2010, at 8:35 PM, Osier Yang wrote:
Should we add these new preferences(if they are really neccessary) in qemu.conf? or create new config file, e.g. The approch Justin raised up an approch before: http://www.redhat.com/archives/libvir-list/2010-November/msg00651.html
Though for Justin's approch, IMHO we'd better also to provide a default config file, e.g. "/etc/libvirt/client.conf".
Any feedback is welcomed, thanks
When thinking about this more, three levels of preference can be found in other applications, and _might_ be the right approach for us to take as well. 1) System wide Client preferences stored in a location that's applicable to all users. ie: /etc/libvirt.conf or similar We can't put it in the /etc/libvirt/ directory with the present permission structure, because /etc/libvirt/ is not world readable. Would need to be in a world readable location (/etc/ ?) or we could relax the perms of /etc/libvirt/ (prob not likely). 2) Per user preference ie: ~/.libvirt.conf or ~/.libvirt/client.conf or similar For a user to permanently override the above system wide defaults, in case their setup is different from everyone else on the system. 3) On the command line ie: $ virsh --some-new-option=foo For adhoc preference changes not to be stored in a pref file. The other category of user preferences that I think are important, is for the defaults of virsh. I strongly suspect people who use virsh a lot would like to change some of it's command defaults. Specifically having "--all" be the default for the *-list commands, having "--details" automatically be used for the storage list commands, and that kind of thing. That's my thinking so far anyway. :) Regards and best wishes, Justin Clift
On Wed, Dec 01, 2010 at 09:19:30PM +1100, Justin Clift wrote:
On 01/12/2010, at 8:35 PM, Osier Yang wrote:
Should we add these new preferences(if they are really neccessary) in qemu.conf? or create new config file, e.g. The approch Justin raised up an approch before: http://www.redhat.com/archives/libvir-list/2010-November/msg00651.html
Though for Justin's approch, IMHO we'd better also to provide a default config file, e.g. "/etc/libvirt/client.conf".
Any feedback is welcomed, thanks
When thinking about this more, three levels of preference can be found in other applications, and _might_ be the right approach for us to take as well.
Management of preferences belongs in application code, rather than libvirt. Library APIs need to have standard, predictable behaviour that apps can rely on in any deployment. We don't want that being changed globally for all applications by config files. Even if apps do want configuration data, we can't assume they want the data stored in configuration files. Any current GTK application will use GConf for any configuration, or in the future GSettings which has pluggable backends per OS platform.
1) System wide
Client preferences stored in a location that's applicable to all users.
ie: /etc/libvirt.conf or similar
We can't put it in the /etc/libvirt/ directory with the present permission structure, because /etc/libvirt/ is not world readable. Would need to be in a world readable location (/etc/ ?) or we could relax the perms of /etc/libvirt/ (prob not likely).
It is restricted because many of the files below /etc/libvirt contain passwords and/or other sensitive data, so it can't be opened. Regards, Daniel
On 02/12/2010, at 12:46 AM, Daniel P. Berrange wrote:
On Wed, Dec 01, 2010 at 09:19:30PM +1100, Justin Clift wrote:
On 01/12/2010, at 8:35 PM, Osier Yang wrote:
Should we add these new preferences(if they are really neccessary) in qemu.conf? or create new config file, e.g. The approch Justin raised up an approch before: http://www.redhat.com/archives/libvir-list/2010-November/msg00651.html
Though for Justin's approch, IMHO we'd better also to provide a default config file, e.g. "/etc/libvirt/client.conf".
Any feedback is welcomed, thanks
When thinking about this more, three levels of preference can be found in other applications, and _might_ be the right approach for us to take as well.
Management of preferences belongs in application code, rather than libvirt. Library APIs need to have standard, predictable behaviour that apps can rely on in any deployment. We don't want that being changed globally for all applications by config files.
Even if apps do want configuration data, we can't assume they want the data stored in configuration files. Any current GTK application will use GConf for any configuration, or in the future GSettings which has pluggable backends per OS platform.
Good point. Its a per client thing, and each client would store the preferences in the way that makes best sense for it. GConf for GTK things, something else for KDE, and a virsh appropriate approach for that if/when we get around to it.
On Wed, Dec 01, 2010 at 05:35:38PM +0800, Osier Yang wrote:
Hi, all
We have some new requirements of preferences, I listed which of them I known, and think is useful as follows:
1) for the path of x509 certificate and keys of client
The path of x509 certificate and keys of client is hard coded in remote driver. e.g.
/* Defaults for PKI directory. */ # define LIBVIRT_PKI_DIR SYSCONFDIR "/pki" # define LIBVIRT_CACERT LIBVIRT_PKI_DIR "/CA/cacert.pem" # define LIBVIRT_CLIENTKEY LIBVIRT_PKI_DIR "/libvirt/private /clientkey.pem" # define LIBVIRT_CLIENTCERT LIBVIRT_PKI_DIR "/libvirt/clientcert.pem"
We can't assume one set of certs/keys is suitable for all URIs, so making this a preference setting doesn't help. There needs to be a parameter in the URI to specify a cert/key name to override the defaults on a per-connection basis
2) for default default driver and subdriver for disk image
Another requirement of new preference is default driver and subdriver for disk images, currently we use "phy" for "driver" in virsh, and "raw" for "subdriver" in qemu driver by default if user doesn't specify them, it causes bugs, though we could say to user "you should use options --driver and --subdriver", but these two options are optional.
IMHO, the best solution for those bugs is to provide new preferences.
virsh is broken here. It shouldn't be setting the driver if the user doesn't specify it. The libvirt hypervisor specific drivers know the correct defaults if omitted, so virsh shouldn't try to guess this (wrongly) itself.
3) for default NIC and storage type
"Chris Phillips" raised up the requirement not long ago:
http://www.redhat.com/archives/libvirt-users/2010-November/msg00033.html
This doesn't belong in libvirt. See my reply in that thread.
====================
Should we add these new preferences(if they are really neccessary) in qemu.conf? or create new config file, e.g. The approch Justin raised up an approch before: http://www.redhat.com/archives/libvir-list/2010-November/msg00651.html
Though for Justin's approch, IMHO we'd better also to provide a default config file, e.g. "/etc/libvirt/client.conf".
Library APIs like libvirt shouldn't really rely on preference files, because such a file would silently change behaviour in ways that applications using the API may not expect. ie the preference may work nicely for one app/user of libvirt, but not for another app. Environment variables would cause similar problems too. Anything that needs to be configured should be configurable via the APIs or XML. Regards, Daniel
于 2010年12月01日 18:26, Daniel P. Berrange 写道:
On Wed, Dec 01, 2010 at 05:35:38PM +0800, Osier Yang wrote:
Hi, all
We have some new requirements of preferences, I listed which of them I known, and think is useful as follows:
1) for the path of x509 certificate and keys of client
The path of x509 certificate and keys of client is hard coded in remote driver. e.g.
/* Defaults for PKI directory. */ # define LIBVIRT_PKI_DIR SYSCONFDIR "/pki" # define LIBVIRT_CACERT LIBVIRT_PKI_DIR "/CA/cacert.pem" # define LIBVIRT_CLIENTKEY LIBVIRT_PKI_DIR "/libvirt/private /clientkey.pem" # define LIBVIRT_CLIENTCERT LIBVIRT_PKI_DIR "/libvirt/clientcert.pem"
We can't assume one set of certs/keys is suitable for all URIs, so making this a preference setting doesn't help. There needs to be a parameter in the URI to specify a cert/key name to override the defaults on a per-connection basis
yeah, reasonable, I didn't consider all of the drivers, will fix this problem with adding parameters for URI.
2) for default default driver and subdriver for disk image
Another requirement of new preference is default driver and subdriver for disk images, currently we use "phy" for "driver" in virsh, and "raw" for "subdriver" in qemu driver by default if user doesn't specify them, it causes bugs, though we could say to user "you should use options --driver and --subdriver", but these two options are optional.
IMHO, the best solution for those bugs is to provide new preferences.
virsh is broken here. It shouldn't be setting the driver if the user doesn't specify it. The libvirt hypervisor specific drivers know the correct defaults if omitted, so virsh shouldn't try to guess this (wrongly) itself.
will fix it.
3) for default NIC and storage type
"Chris Phillips" raised up the requirement not long ago:
http://www.redhat.com/archives/libvirt-users/2010-November/msg00033.html
This doesn't belong in libvirt. See my reply in that thread.
====================
Should we add these new preferences(if they are really neccessary) in qemu.conf? or create new config file, e.g. The approch Justin raised up an approch before: http://www.redhat.com/archives/libvir-list/2010-November/msg00651.html
Though for Justin's approch, IMHO we'd better also to provide a default config file, e.g. "/etc/libvirt/client.conf".
Library APIs like libvirt shouldn't really rely on preference files, because such a file would silently change behaviour in ways that applications using the API may not expect. ie the preference may work nicely for one app/user of libvirt, but not for another app. Environment variables would cause similar problems too. Anything that needs to be configured should be configurable via the APIs or XML.
good to known, thanks :-) - Osier
Regards, Daniel
On Wed, Dec 01, 2010 at 10:26:35AM +0000, Daniel P. Berrange wrote:
On Wed, Dec 01, 2010 at 05:35:38PM +0800, Osier Yang wrote:
Hi, all
We have some new requirements of preferences, I listed which of them I known, and think is useful as follows:
1) for the path of x509 certificate and keys of client
The path of x509 certificate and keys of client is hard coded in remote driver. e.g.
/* Defaults for PKI directory. */ # define LIBVIRT_PKI_DIR SYSCONFDIR "/pki" # define LIBVIRT_CACERT LIBVIRT_PKI_DIR "/CA/cacert.pem" # define LIBVIRT_CLIENTKEY LIBVIRT_PKI_DIR "/libvirt/private /clientkey.pem" # define LIBVIRT_CLIENTCERT LIBVIRT_PKI_DIR "/libvirt/clientcert.pem"
We can't assume one set of certs/keys is suitable for all URIs, so making this a preference setting doesn't help. There needs to be a parameter in the URI to specify a cert/key name to override the defaults on a per-connection basis
As much as I disliked adding long ugly filenames to the URI, I do not see any way around it now. A single client application may need to open two connections with different cert/key pairs, so a single client.conf or environment variables won't cut it.
On Thu, Dec 02, 2010 at 11:38:26PM +0200, Dan Kenigsberg wrote:
On Wed, Dec 01, 2010 at 10:26:35AM +0000, Daniel P. Berrange wrote:
On Wed, Dec 01, 2010 at 05:35:38PM +0800, Osier Yang wrote:
Hi, all
We have some new requirements of preferences, I listed which of them I known, and think is useful as follows:
1) for the path of x509 certificate and keys of client
The path of x509 certificate and keys of client is hard coded in remote driver. e.g.
/* Defaults for PKI directory. */ # define LIBVIRT_PKI_DIR SYSCONFDIR "/pki" # define LIBVIRT_CACERT LIBVIRT_PKI_DIR "/CA/cacert.pem" # define LIBVIRT_CLIENTKEY LIBVIRT_PKI_DIR "/libvirt/private /clientkey.pem" # define LIBVIRT_CLIENTCERT LIBVIRT_PKI_DIR "/libvirt/clientcert.pem"
We can't assume one set of certs/keys is suitable for all URIs, so making this a preference setting doesn't help. There needs to be a parameter in the URI to specify a cert/key name to override the defaults on a per-connection basis
As much as I disliked adding long ugly filenames to the URI, I do not see any way around it now. A single client application may need to open two connections with different cert/key pairs, so a single client.conf or environment variables won't cut it.
NB, I wasn't really suggesting adding the long filenames. Instead I'd suggest adding some cert "name" tag, and use that to formulate the filenames according to some pattern, eg $HOME/.libvirt/$name/cacert.pem $HOME/.libvirt/$name/clientcert.pem $HOME/.libvirt/$name/clientkey.pem Daniel
On Mon, Dec 06, 2010 at 10:32:21AM +0000, Daniel P. Berrange wrote:
On Thu, Dec 02, 2010 at 11:38:26PM +0200, Dan Kenigsberg wrote:
On Wed, Dec 01, 2010 at 10:26:35AM +0000, Daniel P. Berrange wrote:
On Wed, Dec 01, 2010 at 05:35:38PM +0800, Osier Yang wrote:
Hi, all
We have some new requirements of preferences, I listed which of them I known, and think is useful as follows:
1) for the path of x509 certificate and keys of client
The path of x509 certificate and keys of client is hard coded in remote driver. e.g.
/* Defaults for PKI directory. */ # define LIBVIRT_PKI_DIR SYSCONFDIR "/pki" # define LIBVIRT_CACERT LIBVIRT_PKI_DIR "/CA/cacert.pem" # define LIBVIRT_CLIENTKEY LIBVIRT_PKI_DIR "/libvirt/private /clientkey.pem" # define LIBVIRT_CLIENTCERT LIBVIRT_PKI_DIR "/libvirt/clientcert.pem"
We can't assume one set of certs/keys is suitable for all URIs, so making this a preference setting doesn't help. There needs to be a parameter in the URI to specify a cert/key name to override the defaults on a per-connection basis
As much as I disliked adding long ugly filenames to the URI, I do not see any way around it now. A single client application may need to open two connections with different cert/key pairs, so a single client.conf or environment variables won't cut it.
NB, I wasn't really suggesting adding the long filenames. Instead I'd suggest adding some cert "name" tag, and use that to formulate the filenames according to some pattern,
eg $HOME/.libvirt/$name/cacert.pem $HOME/.libvirt/$name/clientcert.pem $HOME/.libvirt/$name/clientkey.pem
(but make sure it works for homeless daemons, too)
participants (4)
-
Dan Kenigsberg -
Daniel P. Berrange -
Justin Clift -
Osier Yang