fuel-specs/3f8648848d4309c3b840ac33a8ca15bb7a34a4b6
Gerrit User 12559 9db07c1776 Update patch set 27
Patch Set 27:

(1 comment)

Patch-set: 27
Reviewer: Gerrit User 12559 <12559@4a232e18-c5a9-48ee-94c0-e04e7cca6543>
Label: Verified=0
2016-11-02 11:12:00 +00:00

75 lines
6.2 KiB
Plaintext

{
"comments": [
{
"key": {
"uuid": "ba5da102_8df73558",
"filename": "specs/10.0/role-decomposition.rst",
"patchSetId": 27
},
"lineNbr": 40,
"author": {
"id": 10391
},
"writtenOn": "2016-11-02T09:11:07Z",
"side": 1,
"message": "I\u0027m concerns about these ones. If we are going this way, tag is nothing but a role. In that case, why do we need a new entity at all? All we need is to introduce more roles and rewrite tasks to use them as well as make possible to define roles for cluster. I want to emphasize again: we *do not* need tags in this case. Let\u0027s adopt roles instead. If we don\u0027t do this we will end up with a lot of bugs and misunderstanding since it won\u0027t be clear:\n\n* what should happen to assigned tags if original role (the one that brings tags to node) moved to another node?\n* what should happen if assigned role is changed and now has another list of tags?\n* what should happen if user manually move one tag from host A to host, and then move the original role (the one that brings this tag) from host A to host C? should be reintroduce this tag on host C? or maybe we need to reintroduce it once again? should we keep it on host C?\n\nAnd so on and so forth. I have a lot of questions here. Trying to solve them will introduce even more complexity and confusion. That\u0027s why I don\u0027t understand why we are trying to write role replacements. On the other hand, I see benefits of using \"tags\" in a slightly another way. To me tags is not a role replacement, it\u0027s a deployment unit. We should not assign tags to nodes. Instead, we need to get a list of tags based on assigned roles. If one wants to change deployment, he/she just need to move tags from one role to another. And in that case, we don\u0027t need tags assign/unassign operations for nodes.\n\nPlease, tell me where I\u0027m wrong and what I missed?",
"range": {
"startLine": 39,
"startChar": 0,
"endLine": 40,
"endChar": 28
},
"revId": "3f8648848d4309c3b840ac33a8ca15bb7a34a4b6",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "ba5da102_feb13502",
"filename": "specs/10.0/role-decomposition.rst",
"patchSetId": 27
},
"lineNbr": 40,
"author": {
"id": 8786
},
"writtenOn": "2016-11-02T10:11:47Z",
"side": 1,
"message": "Igor, first of all we have a concept that roles of the node cannot be changed.\n\nSecondly, the whole idea is that we want to make services composition dynamic by stripping some of the services off the predefined roles.\n\nSo the idea is the following:\n1. Role is a preset of tags\n2. 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.\n3. 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. User will need to assign something like 10 roles onto each node instead of assigning only one of them, while the main use case is to unassign/reassign only a couple of them.\n\nSo 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.",
"parentUuid": "ba5da102_8df73558",
"range": {
"startLine": 39,
"startChar": 0,
"endLine": 40,
"endChar": 28
},
"revId": "3f8648848d4309c3b840ac33a8ca15bb7a34a4b6",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "ba5da102_ae2cec99",
"filename": "specs/10.0/role-decomposition.rst",
"patchSetId": 27
},
"lineNbr": 40,
"author": {
"id": 12559
},
"writtenOn": "2016-11-02T11:12:00Z",
"side": 1,
"message": "Igor, see my answers below.\n\n1. what should happen to assigned tags if original role (the one that brings tags to node) moved to another node?\n\nAll tags placed in role metadata(\u0027tags\u0027 field) will be unassigned from current node and assigned to another node. This is needed to support old role\u0027s based approach.\n\n2. what should happen if assigned role is changed and now has another list of tags?\n\nI think it\u0027s only validation issue. We can check that role is already assigned on some nodes and user should unassign this role before changing tags list belongs to this role.\n\n3.\n a) what should happen if user manually move one tag from host A to host C?\n\nExample: Role \u0027controller\u0027 produces tags: [\u0027mysql\u0027, \u0027neutron\u0027]; role \u0027compute\u0027 produces tags: [\u0027test\u0027].\nHost A - roles: [\u0027controller\u0027], tags: [\u0027mysql\u0027, \u0027neutron\u0027]. Host B - roles: [\u0027compute\u0027], tags: [\u0027test\u0027].\nUser want to move mysql tag from host A to host B. \u0027mysql\u0027 tag will be unassigned from host A and assigned on the host B.\nHost A - roles: [\u0027controller\u0027], tags: [\u0027neutron\u0027]. Host B - roles: [\u0027compute\u0027], tags: [\u0027test\u0027, \u0027mysql\u0027].\n\n b) and then move the original role (the one that brings this tag) from host A to host C?\n\nRole controller produces tags - [\u0027mysql\u0027, \u0027neutron\u0027], so, handler will try ti assign these tags to Host B, but, as we are using \u0027set\u0027 structure during the tags assignment then duplicated assignment is not expected as well.\nHost B - roles: [\u0027controller\u0027, \u0027compute\u0027], tags: [\u0027test\u0027, \u0027mysql\u0027, \u0027neutron\u0027].",
"parentUuid": "ba5da102_feb13502",
"range": {
"startLine": 39,
"startChar": 0,
"endLine": 40,
"endChar": 28
},
"revId": "3f8648848d4309c3b840ac33a8ca15bb7a34a4b6",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
}
]
}