Update patch set 27

Patch Set 27:

(2 comments)

Patch-set: 27

3f8648848d4309c3b840ac33a8ca15bb7a34a4b6

@@ -70,6 +70,54 @@
       "revId": "3f8648848d4309c3b840ac33a8ca15bb7a34a4b6",
       "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
       "unresolved": false
+    },
+    {
+      "key": {
+        "uuid": "ba5da102_b193405a",
+        "filename": "specs/10.0/role-decomposition.rst",
+        "patchSetId": 27
+      },
+      "lineNbr": 40,
+      "author": {
+        "id": 10391
+      },
+      "writtenOn": "2016-11-03T09:04:01Z",
+      "side": 1,
+      "message": "@Viacheslav,\n\nThanks for the feedback. My point didn\u0027t mean to say \"we don\u0027t know what to do in these cases\". We obviously do, that\u0027s not a problem to do something in order to protect consistency. The point was, all these behavioural choices is not clear and implicit. And good UX transparency in behaviour. Ops should not need to carefully learn the design spec in order to understand what will happen in these corner cases. The UX should be transparent and explicit.",
+      "parentUuid": "ba5da102_ae2cec99",
+      "range": {
+        "startLine": 39,
+        "startChar": 0,
+        "endLine": 40,
+        "endChar": 28
+      },
+      "revId": "3f8648848d4309c3b840ac33a8ca15bb7a34a4b6",
+      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
+      "unresolved": false
+    },
+    {
+      "key": {
+        "uuid": "ba5da102_b1498033",
+        "filename": "specs/10.0/role-decomposition.rst",
+        "patchSetId": 27
+      },
+      "lineNbr": 40,
+      "author": {
+        "id": 10391
+      },
+      "writtenOn": "2016-11-03T09:04:01Z",
+      "side": 1,
+      "message": "@Vladimir,\n\nThanks for the responses. Here\u0027s my feedback on this:\n\n\u003e 2. The main use case is to do a slight change, e.g. unassign db/amqp services from the controller and assign it to another node. This means that majority of nodes will still have roles assigned, e.g. computes, and only some of the controllers will have a slight divergence from the originating role.\n\nThat\u0027s completely crazy if controllers are different and introduces a lot of confusions. It\u0027s ok to change definition of controller, and say, for instance, that it should not include DB anymore. That makes sense. On the other hand, I don\u0027t think that *implicitly* patching one of the controllers do not have DB, while the others will have - that is not why most users will expect.\n\n\u003e Having everything as a role would not be efficient as there will be too much roles which will clutter the UI/CLI output and make the UX terrible.\n\nIt\u0027s already terrible UX as long as you push users to assign tags It doesn\u0027t matter whether you assign million roles or million tags.\n\n\u003e So the whole idea of tags is related to the fact that we need to have separation between the \u0027default preset\u0027 which is a role and actually serves for business logic or UI purpose and a service assignment entity which is a tag.\n\nI completely agree on this except that we\u0027ve got to have precisely one mechanism to define what node is going to contain. So far we have roles, but we didn\u0027t have any possibility to easily construct new roles from pre-defined set of tasks (i.e. make a detached-database role or something like that) due to the fact that deployment tasks are tied to roles. But now that\u0027s not longer truth. We have tags, that allows us to construct roles from tags as ops want, and then assign these brand new roles to the nodes.",
+      "parentUuid": "ba5da102_feb13502",
+      "range": {
+        "startLine": 39,
+        "startChar": 0,
+        "endLine": 40,
+        "endChar": 28
+      },
+      "revId": "3f8648848d4309c3b840ac33a8ca15bb7a34a4b6",
+      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
+      "unresolved": false
     }
   ]
 }