--- doc/design-2.1.rst | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 51 insertions(+), 0 deletions(-)
diff --git a/doc/design-2.1.rst b/doc/design-2.1.rst index 2bc9810..36213d8 100644 --- a/doc/design-2.1.rst +++ b/doc/design-2.1.rst @@ -434,6 +434,57 @@ 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) +Introducting persistent UUIDs +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Current state and shortcomings +++++++++++++++++++++++++++++++ + +Some objects in the Ganeti configurations are tracked by their name +while also supporting renames. This creates an extra difficulty, +because neither Ganeti nor external management tools can then track +the actual entity, and due to the name change it behaves like a new +one. + +Proposed changes part 1 ++++++++++++++++++++++++ + +We will change Ganeti to use UUIDs for entity tracking, but in a +staggered way. In 2.1, we will simply add an âuuidâ attribute to each +of the instances, nodes and cluster itself. This will be reported on +instance creation for nodes, and on node adds for the nodes. It will +be of course avaiblable for querying via the OpQueryNodes/Instance and +cluster information, and via RAPI as well. + +Note that Ganeti will not provide any way to change this attribute. + +Upgrading from Ganeti 2.0 will add automatically uuids to all entities +missing them. + + +Proposed changes part 2 ++++++++++++++++++++++++ + +In the next release (e.g. 2.2), the tracking of objects will change +from the name to the UUID internally, and externally Ganeti will +accept both forms of identification; e.g. an RAPI call would be made +either against ``/2/instances/foo.bar`` or against +``/2/instances/bb3b2e42â¦``. + +Another change here is that node identification (during cluster +operations/queries like master startup, âam I the master?â and +similar) could be done via UUIDs which is more stable than the current +hostname-based scheme. + +Internal tracking refers to the way the configuration is stored; a +DRBD disk of an instance refers to the node name (so that IPs can be +changed easily), but this is still a problem for name changes; thus +these will be changed to point to the node name to ease renames. + +The advantages of this change (after the second round of changes), if +that node rename becomes trivial, whereas today node rename would +require a complete lock of all instances. + Automated disk repairs infrastructure ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- 1.6.3.3
