+Redistribute Config
+~~~~~~~~~~~~~~~~~~~
+
+Current State and shortcomings
+++++++++++++++++++++++++++++++
+Currently LURedistributeConfig triggers a copy of the updated configuration
+file to all master candidates and of the ssconf files to all nodes. There are
+other files which are maintained manually but which are important to keep in
+sync. These are:
+
+- rapi SSL key certificate file (rapi.pem) (on master candidates)
+- rapi user/password file rapi_users (on master candidates)
+
+Furthermore there are some files which are hypervisor specific but we may want
+to keep in sync:
+
+- the xen-hvm hypervisor uses one shared file for all vnc passwords, and copies
+ the file once, during node add. This design is subject to revision to be able
+ to have different passwords for different groups of instances via the use of
+ hypervisor parameters, and to allow xen-hvm and kvm to use an equal system to
+ provide password-protected vnc sessions. In general, though, it would be
+ useful if the vnc password files were copied as well, to avoid unwanted vnc
+ password changes on instance failover/migrate.
+
+Optionally the admin may want to also ship files such as the global xend.conf
+file, and the network scripts to all nodes.
+
+Proposed changes
+++++++++++++++++
+
+RedistributeConfig will be changed to copy also the rapi files, and to call
+every enabled hypervisor asking for a list of additional files to copy. We also
+may want to add a global list of files on the cluster object, which will be
+propagated as well, or a hook to calculate them. If we implement this feature
+there should be a way to specify whether a file must be shipped to all nodes or
+just master candidates.
+
+This code will be also shared (via tasklets or by other means, if tasklets are
+not ready for 2.1) with the AddNode and SetNodeParams LUs (so that the relevant
+files will be automatically shipped to new master candidates as they are set).
+
+VNC Console Password
+~~~~~~~~~~~~~~~~~~~~
+
+Current State and shortcomings
+++++++++++++++++++++++++++++++
+
+Currently just the xen-hvm hypervisor supports setting a password to connect
+the the instances' VNC console, and has one common password stored in a file.
+
+This doesn't allow different passwords for different instances/groups of
+instances, and makes it necessary to remember to copy the file around the
+cluster when the password changes.
+
+Proposed changes
+++++++++++++++++
+
+We'll change the VNC password file to a vnc_password_file hypervisor parameter.
+This way it can have a cluster default, but also a different value for each
+instance. The VNC enabled hypervisors (xen and kvm) will publish all the
+password files in use through the cluster so that a redistribute-config will
+ship them to all nodes (see the Redistribute Config proposed changes above).
+
+The current VNC_PASSWORD_FILE constant will be removed, but its value will be
+used as the default HV_VNC_PASSWORD_FILE value, thus retaining backwards
+compatibility with 2.0.
+
+The code to export the list of VNC password files from the hypervisors to
+RedistributeConfig will be shared between the KVM and xen-hvm hypervisors.
+
+Disk/Net parameters
+~~~~~~~~~~~~~~~~~~~
+
+Current State and shortcomings
+++++++++++++++++++++++++++++++
+
+Currently disks and network interfaces have a few tweakable options and all the
+rest is left to a default we chose. We're finding that we need more and more to
+tweak some of these parameters, for example to disable barriers for DRBD
+devices, or allow striping for the LVM volumes.
+
+Moreover for many of these parameters it will be nice to have cluster-wide
+defaults, and then be able to change them per disk/interface.
+
+Proposed changes
+++++++++++++++++
+
+We will add new cluster level diskparams and netparams, which will contain all
+the tweakable parameters. All values which have a sensible cluster-wide default
+will go into this new structure while parameters which have unique values will not.
+
+Example of network parameters:
+ - mode: bridge/route
+ - link: for mode "bridge" the bridge to connect to, for mode route it can
+ contain the routing table, or the destination interface
+
+Example of disk parameters:
+ - stripe: lvm stripes
+ - stripe_size: lvm stripe size
+ - meta_flushes: drbd, enable/disable metadata "barriers"
+ - data_flushes: drbd, enable/disable data "barriers"
+
+Some parameters are bound to be disk-type specific (drbd, vs lvm, vs files) or
+hypervisor specific (nic models for example), but for now they will all live in
+the same structure. Each component is supposed to validate only the parameters
+it knows about, and ganeti itself will make sure that no "globally unknown"
+parameters are added, and that no parameters have overridden meanings for
+different components.
+
+The parameters will be kept, as for the BEPARAMS into a "default" category,
+which will allow us to expand on by creating instance "classes" in the future.
+Instance classes is not a feature we plan implementing in 2.1, though.
+
+Non bridged instances support
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Current State and shortcomings
+++++++++++++++++++++++++++++++
+
+Currently each instance NIC must be connected to a bridge, and if the bridge is
+not specified the default cluster one is used. This makes it impossible to use
+the vif-route xen network scripts, or other alternative mechanisms that don't
+need a bridge to work.
+
+Proposed changes
+++++++++++++++++
+
+The new "mode" network parameter will distinguish between bridged interfaces
+and routed ones.
+
+When mode is "bridge" the "link" parameter will contain the bridge the instance
+should be connected to, effectively making things as today. The value has been
+migrated from a nic field to a parameter to allow for an easier manipulation of
+the cluster default.
+
+When mode is "route" the ip field of the interface will become mandatory, to
+allow for a route to be set. In the future we may want also to accept multiple
+IPs or IP/mask values for this purpose. We will evaluate possible meanings of
+the link parameter to signify a routing table to be used, which would allow for
+insulation between instance groups (as today happens for different bridges).
+
+For now we won't add a parameter to specify which network script gets called
+for which instance, so in a mixed cluster the network script must be able to
+handle both cases. The default kvm vif script will be changed to do so. (Xen
+doesn't have a ganeti provided script, so nothing will be done for that
+hypervisor)
+