openstack
/
fuel-specs
Code Issues Proposed changes
fuel-specs/3f8648848d4309c3b840ac33a8c...

267 lines
15 KiB
Plaintext
Raw Blame History

{
"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
},
{
"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
},
{
"key": {
"uuid": "ba5da102_5e701772",
"filename": "specs/10.0/role-decomposition.rst",
"patchSetId": 27
},
"lineNbr": 40,
"author": {
"id": 8749
},
"writtenOn": "2016-11-03T18:13:57Z",
"side": 1,
"message": "Agree that having both roles and tags with special rules of interaction between those will definitely create a lot of confusion and uncertainty. Also roles must not be static and many users require that.\n\nAnother concern is we already have \"Component\" entity in Nailgun, with dependencies and some basic validation, what you are describing looks like \"Component\" which is more granular entity than Role.\n\nI\u0027m probably ok with having a role represented as a set of tasks to simplify UX, but it MUST be deterministic, during the flow I shouldn\u0027t start removing tags from the node, when it has assigned role, which has the task, otherwise during life-time of your cluster, roles will tell you nothing about the node and it will be a complete mess. If role is a helper to set tags/tasks, it should have filtration mechanism, based on which, we can determine which tasks to include, see how selectors mechanism is done in Kubernetes [1]. When user wants to remove a tag (i.e. set of tasks) from the cluster, he must go and fix tags selector for the role.\n\n[1] http://kubernetes.io/docs/user-guide/labels/",
"parentUuid": "ba5da102_b193405a",
"range": {
"startLine": 39,
"startChar": 0,
"endLine": 40,
"endChar": 28
},
"revId": "3f8648848d4309c3b840ac33a8ca15bb7a34a4b6",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "ba5da102_3d9b6c67",
"filename": "specs/10.0/role-decomposition.rst",
"patchSetId": 27
},
"lineNbr": 179,
"author": {
"id": 8749
},
"writtenOn": "2016-11-03T18:13:57Z",
"side": 1,
"message": "It should be something like:\n\n - node_id: node-1:\n tags: [\u0027corosync:1\u0027, \u0027mysql:2\u0027]",
"range": {
"startLine": 178,
"startChar": 0,
"endLine": 179,
"endChar": 37
},
"revId": "3f8648848d4309c3b840ac33a8ca15bb7a34a4b6",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "ba5da102_5d70200b",
"filename": "specs/10.0/role-decomposition.rst",
"patchSetId": 27
},
"lineNbr": 231,
"author": {
"id": 8749
},
"writtenOn": "2016-11-03T18:13:57Z",
"side": 1,
"message": "Here I stopped understanding the tags. So tag\u0027s name is controller? Reading information from above, I thought tags is mechanism which allows to granularly assign tasks to nodes.",
"range": {
"startLine": 231,
"startChar": 6,
"endLine": 231,
"endChar": 16
},
"revId": "3f8648848d4309c3b840ac33a8ca15bb7a34a4b6",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "ba5da102_5d0f4036",
"filename": "specs/10.0/role-decomposition.rst",
"patchSetId": 27
},
"lineNbr": 242,
"author": {
"id": 8749
},
"writtenOn": "2016-11-03T18:13:57Z",
"side": 1,
"message": "Hm, where is primary key id?",
"revId": "3f8648848d4309c3b840ac33a8ca15bb7a34a4b6",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "ba5da102_f82bc27f",
"filename": "specs/10.0/role-decomposition.rst",
"patchSetId": 27
},
"lineNbr": 246,
"author": {
"id": 8749
},
"writtenOn": "2016-11-03T18:13:57Z",
"side": 1,
"message": "Also where is a human readable name?",
"revId": "3f8648848d4309c3b840ac33a8ca15bb7a34a4b6",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "ba5da102_586bceb6",
"filename": "specs/10.0/role-decomposition.rst",
"patchSetId": 27
},
"lineNbr": 285,
"author": {
"id": 8749
},
"writtenOn": "2016-11-03T18:13:57Z",
"side": 1,
"message": "If it\u0027s tag creation it must be a POST request with all required data not in GET, but in the body of POST request.\n\nMake sure that it\u0027s follows openstack api guide\n\nhttp://specs.openstack.org/openstack/api-wg/guidelines/pagination_filter_sort.html#filtering",
"revId": "3f8648848d4309c3b840ac33a8ca15bb7a34a4b6",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "ba5da102_b8b30a4c",
"filename": "specs/10.0/role-decomposition.rst",
"patchSetId": 27
},
"lineNbr": 326,
"author": {
"id": 8749
},
"writtenOn": "2016-11-03T18:13:57Z",
"side": 1,
"message": "Why is it expected? Why adding tags would break plugins? Plugins rely on dependencies which as far as I understand won\u0027t be removed.",
"range": {
"startLine": 326,
"startChar": 5,
"endLine": 326,
"endChar": 13
},
"revId": "3f8648848d4309c3b840ac33a8ca15bb7a34a4b6",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
}
]
}
View Git Blame Copy Permalink