2dd9454948
Patch Set 17: (1 comment) Patch-set: 17
808 lines
31 KiB
Plaintext
808 lines
31 KiB
Plaintext
{
|
||
"comments": [
|
||
{
|
||
"key": {
|
||
"uuid": "9ad45d7e_c3f11c03",
|
||
"filename": "specs/10.0/role-decomposition.rst",
|
||
"patchSetId": 17
|
||
},
|
||
"lineNbr": 26,
|
||
"author": {
|
||
"id": 8829
|
||
},
|
||
"writtenOn": "2016-08-10T15:53:30Z",
|
||
"side": 1,
|
||
"message": "This should be tags as nodes can have more any number of tags.",
|
||
"range": {
|
||
"startLine": 26,
|
||
"startChar": 52,
|
||
"endLine": 26,
|
||
"endChar": 55
|
||
},
|
||
"revId": "498fcb5105622d2a52eb2eda101734f97f4e79c3",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||
"unresolved": false
|
||
},
|
||
{
|
||
"key": {
|
||
"uuid": "9ad45d7e_724ab756",
|
||
"filename": "specs/10.0/role-decomposition.rst",
|
||
"patchSetId": 17
|
||
},
|
||
"lineNbr": 26,
|
||
"author": {
|
||
"id": 12559
|
||
},
|
||
"writtenOn": "2016-08-10T16:32:16Z",
|
||
"side": 1,
|
||
"message": "Done",
|
||
"parentUuid": "9ad45d7e_c3f11c03",
|
||
"range": {
|
||
"startLine": 26,
|
||
"startChar": 52,
|
||
"endLine": 26,
|
||
"endChar": 55
|
||
},
|
||
"revId": "498fcb5105622d2a52eb2eda101734f97f4e79c3",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||
"unresolved": false
|
||
},
|
||
{
|
||
"key": {
|
||
"uuid": "9ad45d7e_8360c4a6",
|
||
"filename": "specs/10.0/role-decomposition.rst",
|
||
"patchSetId": 17
|
||
},
|
||
"lineNbr": 39,
|
||
"author": {
|
||
"id": 8829
|
||
},
|
||
"writtenOn": "2016-08-10T15:53:30Z",
|
||
"side": 1,
|
||
"message": "Tags belong to nodes, not roles. The resolver will only care about the tags assigned to a node, not the role.",
|
||
"range": {
|
||
"startLine": 39,
|
||
"startChar": 30,
|
||
"endLine": 39,
|
||
"endChar": 36
|
||
},
|
||
"revId": "498fcb5105622d2a52eb2eda101734f97f4e79c3",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||
"unresolved": false
|
||
},
|
||
{
|
||
"key": {
|
||
"uuid": "9ad45d7e_d25a8329",
|
||
"filename": "specs/10.0/role-decomposition.rst",
|
||
"patchSetId": 17
|
||
},
|
||
"lineNbr": 39,
|
||
"author": {
|
||
"id": 12559
|
||
},
|
||
"writtenOn": "2016-08-10T16:32:16Z",
|
||
"side": 1,
|
||
"message": "wiped out \"role\u0027s\"",
|
||
"parentUuid": "9ad45d7e_8360c4a6",
|
||
"range": {
|
||
"startLine": 39,
|
||
"startChar": 30,
|
||
"endLine": 39,
|
||
"endChar": 36
|
||
},
|
||
"revId": "498fcb5105622d2a52eb2eda101734f97f4e79c3",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||
"unresolved": false
|
||
},
|
||
{
|
||
"key": {
|
||
"uuid": "9ad45d7e_2b7485fb",
|
||
"filename": "specs/10.0/role-decomposition.rst",
|
||
"patchSetId": 17
|
||
},
|
||
"lineNbr": 43,
|
||
"author": {
|
||
"id": 8797
|
||
},
|
||
"writtenOn": "2016-08-09T22:46:57Z",
|
||
"side": 1,
|
||
"message": "a",
|
||
"range": {
|
||
"startLine": 43,
|
||
"startChar": 14,
|
||
"endLine": 43,
|
||
"endChar": 17
|
||
},
|
||
"revId": "498fcb5105622d2a52eb2eda101734f97f4e79c3",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||
"unresolved": false
|
||
},
|
||
{
|
||
"key": {
|
||
"uuid": "9ad45d7e_66e050fb",
|
||
"filename": "specs/10.0/role-decomposition.rst",
|
||
"patchSetId": 17
|
||
},
|
||
"lineNbr": 43,
|
||
"author": {
|
||
"id": 12559
|
||
},
|
||
"writtenOn": "2016-08-10T15:49:42Z",
|
||
"side": 1,
|
||
"message": "Done",
|
||
"parentUuid": "9ad45d7e_2b7485fb",
|
||
"range": {
|
||
"startLine": 43,
|
||
"startChar": 14,
|
||
"endLine": 43,
|
||
"endChar": 17
|
||
},
|
||
"revId": "498fcb5105622d2a52eb2eda101734f97f4e79c3",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||
"unresolved": false
|
||
},
|
||
{
|
||
"key": {
|
||
"uuid": "9ad45d7e_4983dd04",
|
||
"filename": "specs/10.0/role-decomposition.rst",
|
||
"patchSetId": 17
|
||
},
|
||
"lineNbr": 77,
|
||
"author": {
|
||
"id": 15692
|
||
},
|
||
"writtenOn": "2016-08-09T11:51:39Z",
|
||
"side": 1,
|
||
"message": "Vote for this solution. Explicit is better than implicit. Disadvantage is not so special and critical.",
|
||
"revId": "498fcb5105622d2a52eb2eda101734f97f4e79c3",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||
"unresolved": false
|
||
},
|
||
{
|
||
"key": {
|
||
"uuid": "9ad45d7e_374dff6c",
|
||
"filename": "specs/10.0/role-decomposition.rst",
|
||
"patchSetId": 17
|
||
},
|
||
"lineNbr": 123,
|
||
"author": {
|
||
"id": 8797
|
||
},
|
||
"writtenOn": "2016-08-09T22:46:57Z",
|
||
"side": 1,
|
||
"message": "I\u0027m for approach 2, where we also use this approach to \u0027upgrade\u0027 roles to tags, in that if a role has no tag then it automatically uses the role name as it\u0027s tag, and the same logic is used to \u0027upgrade\u0027 the tasks. This way we can completely remove the role resolver as they are converted. \n\nNow that isn\u0027t to say that we should not prefer to be explicit with fully supported roles/tags, but we have too diverse of a community/plugin that we should impose this on them",
|
||
"revId": "498fcb5105622d2a52eb2eda101734f97f4e79c3",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||
"unresolved": false
|
||
},
|
||
{
|
||
"key": {
|
||
"uuid": "9ad45d7e_234ab8ac",
|
||
"filename": "specs/10.0/role-decomposition.rst",
|
||
"patchSetId": 17
|
||
},
|
||
"lineNbr": 123,
|
||
"author": {
|
||
"id": 8829
|
||
},
|
||
"writtenOn": "2016-08-10T15:53:30Z",
|
||
"side": 1,
|
||
"message": "I am also for this approach. Making roles into a container of tags seems more flexible. Falling back to resolving tasks by roles is also very simple in this case.",
|
||
"parentUuid": "9ad45d7e_374dff6c",
|
||
"revId": "498fcb5105622d2a52eb2eda101734f97f4e79c3",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||
"unresolved": false
|
||
},
|
||
{
|
||
"key": {
|
||
"uuid": "9ad45d7e_35cdc966",
|
||
"filename": "specs/10.0/role-decomposition.rst",
|
||
"patchSetId": 17
|
||
},
|
||
"lineNbr": 123,
|
||
"author": {
|
||
"id": 8786
|
||
},
|
||
"writtenOn": "2016-08-10T16:34:56Z",
|
||
"side": 1,
|
||
"message": "Guys, we need to be explicit and provide a backward compatible way for things, so that we can merge changes to library gradually. So I am for approach #1. I suggest we add an extension here and produce additional tags if you want using this extension",
|
||
"parentUuid": "9ad45d7e_234ab8ac",
|
||
"revId": "498fcb5105622d2a52eb2eda101734f97f4e79c3",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||
"unresolved": false
|
||
},
|
||
{
|
||
"key": {
|
||
"uuid": "9ad45d7e_e83fd884",
|
||
"filename": "specs/10.0/role-decomposition.rst",
|
||
"patchSetId": 17
|
||
},
|
||
"lineNbr": 123,
|
||
"author": {
|
||
"id": 8829
|
||
},
|
||
"writtenOn": "2016-08-10T17:24:54Z",
|
||
"side": 1,
|
||
"message": "Can you expand on the ways in which this approach is backwards-incompatible? I\u0027m not clear on the issues.",
|
||
"parentUuid": "9ad45d7e_35cdc966",
|
||
"revId": "498fcb5105622d2a52eb2eda101734f97f4e79c3",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||
"unresolved": false
|
||
},
|
||
{
|
||
"key": {
|
||
"uuid": "9ad45d7e_664839cd",
|
||
"filename": "specs/10.0/role-decomposition.rst",
|
||
"patchSetId": 17
|
||
},
|
||
"lineNbr": 123,
|
||
"author": {
|
||
"id": 6677
|
||
},
|
||
"writtenOn": "2016-08-10T17:44:13Z",
|
||
"side": 1,
|
||
"message": "I also think that the option #1 is preferable as more explicit. In that case, you don\u0027t have to mix \u0027role\u0027 and \u0027tags\u0027 fields in TagResolver and keep better data separation. In future, it will be easier to just get rid of RoleResolver without touching TagResolver whatsoever.",
|
||
"parentUuid": "9ad45d7e_35cdc966",
|
||
"revId": "498fcb5105622d2a52eb2eda101734f97f4e79c3",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||
"unresolved": false
|
||
},
|
||
{
|
||
"key": {
|
||
"uuid": "9ad45d7e_1c9d450a",
|
||
"filename": "specs/10.0/role-decomposition.rst",
|
||
"patchSetId": 17
|
||
},
|
||
"lineNbr": 123,
|
||
"author": {
|
||
"id": 8797
|
||
},
|
||
"writtenOn": "2016-08-10T20:50:46Z",
|
||
"side": 1,
|
||
"message": "I think the solution here is simple, every task that has role key should have role name added to tags list, every role name should have automatic tag (or explicit defined also) from role side. This way tasks that aren\u0027t converted to roles are automatically upgraded and use tags. If you upgrade the task, you add tag and remove role, seems simple enough. It allows for good backwards compat, removes the need to maintain RoleResolver, and encourages us to be Implicit. I don\u0027t see the problem with it.",
|
||
"parentUuid": "9ad45d7e_664839cd",
|
||
"revId": "498fcb5105622d2a52eb2eda101734f97f4e79c3",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||
"unresolved": false
|
||
},
|
||
{
|
||
"key": {
|
||
"uuid": "9ad45d7e_669d5459",
|
||
"filename": "specs/10.0/role-decomposition.rst",
|
||
"patchSetId": 17
|
||
},
|
||
"lineNbr": 123,
|
||
"author": {
|
||
"id": 6677
|
||
},
|
||
"writtenOn": "2016-08-12T17:25:53Z",
|
||
"side": 1,
|
||
"message": "It looks like we\u0027re more or less on the same page here. I just think it\u0027s important to separate RoleResolver form TagResolver in terms of data fields they consume.",
|
||
"parentUuid": "9ad45d7e_1c9d450a",
|
||
"revId": "498fcb5105622d2a52eb2eda101734f97f4e79c3",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||
"unresolved": false
|
||
},
|
||
{
|
||
"key": {
|
||
"uuid": "9ad45d7e_51836898",
|
||
"filename": "specs/10.0/role-decomposition.rst",
|
||
"patchSetId": 17
|
||
},
|
||
"lineNbr": 211,
|
||
"author": {
|
||
"id": 8797
|
||
},
|
||
"writtenOn": "2016-08-09T22:46:57Z",
|
||
"side": 1,
|
||
"message": "we are adding this to the release meta. Is this still part of the role definition or is this elsewhere?",
|
||
"range": {
|
||
"startLine": 208,
|
||
"startChar": 0,
|
||
"endLine": 211,
|
||
"endChar": 24
|
||
},
|
||
"revId": "498fcb5105622d2a52eb2eda101734f97f4e79c3",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||
"unresolved": false
|
||
},
|
||
{
|
||
"key": {
|
||
"uuid": "9ad45d7e_c05d9f48",
|
||
"filename": "specs/10.0/role-decomposition.rst",
|
||
"patchSetId": 17
|
||
},
|
||
"lineNbr": 211,
|
||
"author": {
|
||
"id": 12559
|
||
},
|
||
"writtenOn": "2016-08-10T15:49:42Z",
|
||
"side": 1,
|
||
"message": "updated",
|
||
"parentUuid": "9ad45d7e_51836898",
|
||
"range": {
|
||
"startLine": 208,
|
||
"startChar": 0,
|
||
"endLine": 211,
|
||
"endChar": 24
|
||
},
|
||
"revId": "498fcb5105622d2a52eb2eda101734f97f4e79c3",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||
"unresolved": false
|
||
},
|
||
{
|
||
"key": {
|
||
"uuid": "9ad45d7e_49a0fd43",
|
||
"filename": "specs/10.0/role-decomposition.rst",
|
||
"patchSetId": 17
|
||
},
|
||
"lineNbr": 229,
|
||
"author": {
|
||
"id": 15692
|
||
},
|
||
"writtenOn": "2016-08-09T11:51:39Z",
|
||
"side": 1,
|
||
"message": "I propose to remove this ability because for now tag-task mapping is performing through yaml file and end-user doesn\u0027t have an ability to create his own fully functional tags via API in any way. Also that thing will bring some mess with tag validation.",
|
||
"revId": "498fcb5105622d2a52eb2eda101734f97f4e79c3",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||
"unresolved": false
|
||
},
|
||
{
|
||
"key": {
|
||
"uuid": "9ad45d7e_9119608b",
|
||
"filename": "specs/10.0/role-decomposition.rst",
|
||
"patchSetId": 17
|
||
},
|
||
"lineNbr": 229,
|
||
"author": {
|
||
"id": 8797
|
||
},
|
||
"writtenOn": "2016-08-09T22:46:57Z",
|
||
"side": 1,
|
||
"message": "this may be needed in the context of setting instances. on the same thread, I\u0027m not sure why we should prevent creating tags that don\u0027t come from roles. While tasks don\u0027t do things with that now, someone may create one that can take advantage of this, and I don\u0027t see why nailgun should restrict it. This is especially true to me if we are storing all of the registered tags and then using them for validation.",
|
||
"parentUuid": "9ad45d7e_49a0fd43",
|
||
"revId": "498fcb5105622d2a52eb2eda101734f97f4e79c3",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||
"unresolved": false
|
||
},
|
||
{
|
||
"key": {
|
||
"uuid": "9ad45d7e_0f9b6073",
|
||
"filename": "specs/10.0/role-decomposition.rst",
|
||
"patchSetId": 17
|
||
},
|
||
"lineNbr": 229,
|
||
"author": {
|
||
"id": 12559
|
||
},
|
||
"writtenOn": "2016-08-10T15:49:42Z",
|
||
"side": 1,
|
||
"message": "Lets leave this point as it is. Moreover it\u0027s now a big deal to make a proper validation based on core tags.",
|
||
"parentUuid": "9ad45d7e_9119608b",
|
||
"revId": "498fcb5105622d2a52eb2eda101734f97f4e79c3",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||
"unresolved": false
|
||
},
|
||
{
|
||
"key": {
|
||
"uuid": "9ad45d7e_2354781f",
|
||
"filename": "specs/10.0/role-decomposition.rst",
|
||
"patchSetId": 17
|
||
},
|
||
"lineNbr": 229,
|
||
"author": {
|
||
"id": 8829
|
||
},
|
||
"writtenOn": "2016-08-10T15:53:30Z",
|
||
"side": 1,
|
||
"message": "I have already done some work to introduce an API for tagging https://review.openstack.org/#/c/341678/2. There has been some discussion around using the existing node labeling functionality versus adding a new tag API. I can restore the above patchset and continue work from there if it\u0027s decided that tags will be used instead of node labels.",
|
||
"parentUuid": "9ad45d7e_9119608b",
|
||
"revId": "498fcb5105622d2a52eb2eda101734f97f4e79c3",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||
"unresolved": false
|
||
},
|
||
{
|
||
"key": {
|
||
"uuid": "9ad45d7e_631f906c",
|
||
"filename": "specs/10.0/role-decomposition.rst",
|
||
"patchSetId": 17
|
||
},
|
||
"lineNbr": 231,
|
||
"author": {
|
||
"id": 8829
|
||
},
|
||
"writtenOn": "2016-08-10T15:53:30Z",
|
||
"side": 1,
|
||
"message": "Can you please elaborate on this point? I don\u0027t fully understand it.",
|
||
"revId": "498fcb5105622d2a52eb2eda101734f97f4e79c3",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||
"unresolved": false
|
||
},
|
||
{
|
||
"key": {
|
||
"uuid": "9ad45d7e_b501b907",
|
||
"filename": "specs/10.0/role-decomposition.rst",
|
||
"patchSetId": 17
|
||
},
|
||
"lineNbr": 231,
|
||
"author": {
|
||
"id": 12559
|
||
},
|
||
"writtenOn": "2016-08-10T16:32:16Z",
|
||
"side": 1,
|
||
"message": "I talked about tags coming with release. It\u0027s base set of tags and its deletion may cause deployment failures.",
|
||
"parentUuid": "9ad45d7e_631f906c",
|
||
"revId": "498fcb5105622d2a52eb2eda101734f97f4e79c3",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||
"unresolved": false
|
||
},
|
||
{
|
||
"key": {
|
||
"uuid": "9ad45d7e_74193588",
|
||
"filename": "specs/10.0/role-decomposition.rst",
|
||
"patchSetId": 17
|
||
},
|
||
"lineNbr": 232,
|
||
"author": {
|
||
"id": 8797
|
||
},
|
||
"writtenOn": "2016-08-09T22:46:57Z",
|
||
"side": 1,
|
||
"message": "please elaborate on the storage, and validation process we will use for tags, are we constantly looking up the tags out of the roles meta, or are we storing the registered tags and validating out of that table?",
|
||
"revId": "498fcb5105622d2a52eb2eda101734f97f4e79c3",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||
"unresolved": false
|
||
},
|
||
{
|
||
"key": {
|
||
"uuid": "9ad45d7e_8fb9107c",
|
||
"filename": "specs/10.0/role-decomposition.rst",
|
||
"patchSetId": 17
|
||
},
|
||
"lineNbr": 232,
|
||
"author": {
|
||
"id": 12559
|
||
},
|
||
"writtenOn": "2016-08-10T15:49:42Z",
|
||
"side": 1,
|
||
"message": "I have described storage process in \u0027Data model\u0027 section.\nValidation process is described in \u0027Nailgun\u0027 section - \u0027Pre-deployment checker should check that all pre-defined tags have been assigned to nodes and show info message to the user\u0027",
|
||
"parentUuid": "9ad45d7e_74193588",
|
||
"revId": "498fcb5105622d2a52eb2eda101734f97f4e79c3",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||
"unresolved": false
|
||
},
|
||
{
|
||
"key": {
|
||
"uuid": "9ad45d7e_944e6e6d",
|
||
"filename": "specs/10.0/role-decomposition.rst",
|
||
"patchSetId": 17
|
||
},
|
||
"lineNbr": 308,
|
||
"author": {
|
||
"id": 8797
|
||
},
|
||
"writtenOn": "2016-08-09T22:46:57Z",
|
||
"side": 1,
|
||
"message": "I still don\u0027t see any resolution about what groups are for, and their relation between tags, tasks, and roles going forward.",
|
||
"range": {
|
||
"startLine": 308,
|
||
"startChar": 6,
|
||
"endLine": 308,
|
||
"endChar": 26
|
||
},
|
||
"revId": "498fcb5105622d2a52eb2eda101734f97f4e79c3",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||
"unresolved": false
|
||
},
|
||
{
|
||
"key": {
|
||
"uuid": "9ad45d7e_ec125556",
|
||
"filename": "specs/10.0/role-decomposition.rst",
|
||
"patchSetId": 17
|
||
},
|
||
"lineNbr": 308,
|
||
"author": {
|
||
"id": 12559
|
||
},
|
||
"writtenOn": "2016-08-10T15:49:42Z",
|
||
"side": 1,
|
||
"message": "Groups it\u0027s entity what was introduced for tasks aggregation, also, you can consider it like intermediate link between task and role.\nFor example:\n - id: controller-group\n type: group\n roles: [controller]\n tasks: [controller-task-wo-group]\n - id: controller-task-w-group\n type: puppet\n groups: [controller-group]\n - id: controller-task-wo-group\n type: puppet\n\nSo, when you are adding new task you can specify role or group(what has list of roles) to connect it with specific role. Also, group has \u0027tasks\u0027 field where you can specify list of tasks what should be run for this group(for list of roles defined in group). This tasks will be run even if they have no this group in \u0027groups\u0027 field. In provided example \n\u0027controller-task-w-group\u0027 and \u0027controller-task-wo-group\u0027 tasks will be run for role controller.\n\nWe have already decided that we are not going to introduce additional groups to not make intermediate relation \u0027task -\u003e group -\u003e tag\u0027, so, lets close this discussion around groups.",
|
||
"parentUuid": "9ad45d7e_944e6e6d",
|
||
"range": {
|
||
"startLine": 308,
|
||
"startChar": 6,
|
||
"endLine": 308,
|
||
"endChar": 26
|
||
},
|
||
"revId": "498fcb5105622d2a52eb2eda101734f97f4e79c3",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||
"unresolved": false
|
||
},
|
||
{
|
||
"key": {
|
||
"uuid": "9ad45d7e_1939d7f2",
|
||
"filename": "specs/10.0/role-decomposition.rst",
|
||
"patchSetId": 17
|
||
},
|
||
"lineNbr": 308,
|
||
"author": {
|
||
"id": 8797
|
||
},
|
||
"writtenOn": "2016-08-10T20:50:46Z",
|
||
"side": 1,
|
||
"message": "Done",
|
||
"parentUuid": "9ad45d7e_ec125556",
|
||
"range": {
|
||
"startLine": 308,
|
||
"startChar": 6,
|
||
"endLine": 308,
|
||
"endChar": 26
|
||
},
|
||
"revId": "498fcb5105622d2a52eb2eda101734f97f4e79c3",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||
"unresolved": false
|
||
},
|
||
{
|
||
"key": {
|
||
"uuid": "9ad45d7e_749f7ab4",
|
||
"filename": "specs/10.0/role-decomposition.rst",
|
||
"patchSetId": 17
|
||
},
|
||
"lineNbr": 325,
|
||
"author": {
|
||
"id": 8797
|
||
},
|
||
"writtenOn": "2016-08-09T22:46:57Z",
|
||
"side": 1,
|
||
"message": "the changes to nailgun need to be able to model how we will be able to deal with instancing clusters. While this is outside of the library scope, we must have thought about it here",
|
||
"range": {
|
||
"startLine": 322,
|
||
"startChar": 0,
|
||
"endLine": 325,
|
||
"endChar": 69
|
||
},
|
||
"revId": "498fcb5105622d2a52eb2eda101734f97f4e79c3",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||
"unresolved": false
|
||
},
|
||
{
|
||
"key": {
|
||
"uuid": "9ad45d7e_638030c1",
|
||
"filename": "specs/10.0/role-decomposition.rst",
|
||
"patchSetId": 17
|
||
},
|
||
"lineNbr": 325,
|
||
"author": {
|
||
"id": 12559
|
||
},
|
||
"writtenOn": "2016-08-10T15:49:42Z",
|
||
"side": 1,
|
||
"message": "so, I propose following workflow for such things:\n* if you need you can write extension what may automatically expand set of tags assigning to node during the role\u0027s assignment\n* as we have API for tags developer may create any tag and assign it to the node\n* to implement approach based on node\u0027s tags on fuel-library side for collecting nodes for particular \u0027instance\u0027. For example, we have following hash for nodes:\n\nnode-1:\n tags: [\u0027corosync:1\u0027, \u0027mysql:2\u0027]\nnode-2:\n tags: [\u0027corosync:2\u0027, \u0027mysql:1\u0027]\nnode-3:\n tags: [\u0027corosync:2\u0027, \u0027mysql:2\u0027]\n\nso, when we are running mysql manifest on the some of the nodes we should do something like this:\n#########\nmy_node_name \u003d hiera(\u0027my_node_name\u0027)\nmysql_nodes \u003d get_mysql_nodes_in_my_cluster(my_node_name)\n##########\n\nFunction `get_mysql_nodes_in_my_cluster` should lookup \u0027mysql:*\u0027 tag from the node\u0027s tags and find nodes with the same \u0027instance\u0027 tag. For example, for the \u0027mysql\u0027 instance and \u0027node-1\u0027 it should return \u0027node-1\u0027 \u0026 \u0027node-3\u0027 nodes.",
|
||
"parentUuid": "9ad45d7e_749f7ab4",
|
||
"range": {
|
||
"startLine": 322,
|
||
"startChar": 0,
|
||
"endLine": 325,
|
||
"endChar": 69
|
||
},
|
||
"revId": "498fcb5105622d2a52eb2eda101734f97f4e79c3",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||
"unresolved": false
|
||
},
|
||
{
|
||
"key": {
|
||
"uuid": "9ad45d7e_d9645f23",
|
||
"filename": "specs/10.0/role-decomposition.rst",
|
||
"patchSetId": 17
|
||
},
|
||
"lineNbr": 325,
|
||
"author": {
|
||
"id": 8797
|
||
},
|
||
"writtenOn": "2016-08-10T20:50:46Z",
|
||
"side": 1,
|
||
"message": "\u003e if you need you can write extension what may automatically expand set of tags assigning to node during the role\u0027s assignment \n\na) What would we need the extension for? \n\n\u003e as we have API for tags developer may create any tag and assign it to the node\n\nb) ok, how does this instance declaration take effect then\n\n\u003e to implement approach based on node\u0027s tags on fuel-library side for collecting nodes for particular \u0027instance\u0027. For example, we have following hash for nodes:\n\nc) So we will support tag:instance by default? and forward part of tag will be used for task resolving while latter is for functions to collect?\n\nInstead of string splitting should we have tags be k/v like labes?",
|
||
"parentUuid": "9ad45d7e_638030c1",
|
||
"range": {
|
||
"startLine": 322,
|
||
"startChar": 0,
|
||
"endLine": 325,
|
||
"endChar": 69
|
||
},
|
||
"revId": "498fcb5105622d2a52eb2eda101734f97f4e79c3",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||
"unresolved": false
|
||
},
|
||
{
|
||
"key": {
|
||
"uuid": "9ad45d7e_ebafa47a",
|
||
"filename": "specs/10.0/role-decomposition.rst",
|
||
"patchSetId": 17
|
||
},
|
||
"lineNbr": 325,
|
||
"author": {
|
||
"id": 12559
|
||
},
|
||
"writtenOn": "2016-08-11T12:46:34Z",
|
||
"side": 1,
|
||
"message": "a) What would we need the extension for?\n\nto make an ability to assign specific tags to the node during the role\u0027s assignment(produce default set of tags-instances from the box and assign it to\nthe node based on assigned role).\n\nb) ok, how does this instance declaration take effect then\n\nThese \u0027instance\u0027 tags will not be considered during the tasks resolution, as we are not going to resolve tasks using these tags, but, this tags\nwill be included into node\u0027s deployment info(yaml file) and may be used for filtering of nodes on puppet side.\n\nc1) So we will support tag:instance by default? \n\n\u0027tag:instance\u0027 tags can be added via API by user or third party application. As we have API for tag\u0027s addition we can create tags with any name(it\u0027s just string). \n\nс2) and forward part of tag will be used for task resolving while latter is for functions to collect?\n\nCorrect. \u0027Instance\u0027 tags will be used in puppet manifests to collect node\u0027s ips what belongs to similar instance with current node.\n\nd) Instead of string splitting should we have tags be k/v like labes?\n\n`tag` entity was introduced to be assigned on group of nodes(like a role). Let\u0027s consider case when we are assigning \u0027cluster\u0027 tag on two node: metadata of this tag should be different for this nodes if they are belonging to different instances, but, we have only ONE meta information for this tag(what lives in release or cluster like a \u0027has_primary\u0027, etc.). So, tags is just list of strings in the node\u0027s \u0027tags\u0027 field what is not storing any node-specific info. Moreover, it\u0027s not a big difference from code point of view to calculate \u0027instances\u0027 using regexp or look up it from some hash.",
|
||
"parentUuid": "9ad45d7e_d9645f23",
|
||
"range": {
|
||
"startLine": 322,
|
||
"startChar": 0,
|
||
"endLine": 325,
|
||
"endChar": 69
|
||
},
|
||
"revId": "498fcb5105622d2a52eb2eda101734f97f4e79c3",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||
"unresolved": false
|
||
},
|
||
{
|
||
"key": {
|
||
"uuid": "9ad45d7e_4085e257",
|
||
"filename": "specs/10.0/role-decomposition.rst",
|
||
"patchSetId": 17
|
||
},
|
||
"lineNbr": 325,
|
||
"author": {
|
||
"id": 8797
|
||
},
|
||
"writtenOn": "2016-08-11T15:31:04Z",
|
||
"side": 1,
|
||
"message": "please annotate c1,c2 in spec",
|
||
"parentUuid": "9ad45d7e_ebafa47a",
|
||
"range": {
|
||
"startLine": 322,
|
||
"startChar": 0,
|
||
"endLine": 325,
|
||
"endChar": 69
|
||
},
|
||
"revId": "498fcb5105622d2a52eb2eda101734f97f4e79c3",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||
"unresolved": false
|
||
},
|
||
{
|
||
"key": {
|
||
"uuid": "9ad45d7e_6f8285c9",
|
||
"filename": "specs/10.0/role-decomposition.rst",
|
||
"patchSetId": 17
|
||
},
|
||
"lineNbr": 325,
|
||
"author": {
|
||
"id": 12559
|
||
},
|
||
"writtenOn": "2016-08-11T20:07:36Z",
|
||
"side": 1,
|
||
"message": "Done",
|
||
"parentUuid": "9ad45d7e_4085e257",
|
||
"range": {
|
||
"startLine": 322,
|
||
"startChar": 0,
|
||
"endLine": 325,
|
||
"endChar": 69
|
||
},
|
||
"revId": "498fcb5105622d2a52eb2eda101734f97f4e79c3",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||
"unresolved": false
|
||
},
|
||
{
|
||
"key": {
|
||
"uuid": "9ad45d7e_bf242baf",
|
||
"filename": "specs/10.0/role-decomposition.rst",
|
||
"patchSetId": 17
|
||
},
|
||
"lineNbr": 341,
|
||
"author": {
|
||
"id": 8797
|
||
},
|
||
"writtenOn": "2016-08-09T22:46:57Z",
|
||
"side": 1,
|
||
"message": "Still un-resolved here; how do we account for updating tags between minor releases (and we add more tags between them). My thought is that we simply need to be able to evaluate current roles, and get a list of tags that would be applied to nodes as an output. Operator can determine what they want to do. Validator would warn based on lack of assignment of new tags",
|
||
"range": {
|
||
"startLine": 341,
|
||
"startChar": 0,
|
||
"endLine": 341,
|
||
"endChar": 4
|
||
},
|
||
"revId": "498fcb5105622d2a52eb2eda101734f97f4e79c3",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||
"unresolved": false
|
||
},
|
||
{
|
||
"key": {
|
||
"uuid": "9ad45d7e_d7f1cd02",
|
||
"filename": "specs/10.0/role-decomposition.rst",
|
||
"patchSetId": 17
|
||
},
|
||
"lineNbr": 341,
|
||
"author": {
|
||
"id": 12559
|
||
},
|
||
"writtenOn": "2016-08-10T18:42:28Z",
|
||
"side": 1,
|
||
"message": "Current approach for application of MU is custom deployment graph(described there https://review.openstack.org/#/c/342110/ ). So, it seems that deployment graph should consider changes in tags between minor releases.",
|
||
"parentUuid": "9ad45d7e_bf242baf",
|
||
"range": {
|
||
"startLine": 341,
|
||
"startChar": 0,
|
||
"endLine": 341,
|
||
"endChar": 4
|
||
},
|
||
"revId": "498fcb5105622d2a52eb2eda101734f97f4e79c3",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||
"unresolved": false
|
||
},
|
||
{
|
||
"key": {
|
||
"uuid": "9ad45d7e_7c5d6114",
|
||
"filename": "specs/10.0/role-decomposition.rst",
|
||
"patchSetId": 17
|
||
},
|
||
"lineNbr": 341,
|
||
"author": {
|
||
"id": 8797
|
||
},
|
||
"writtenOn": "2016-08-10T20:50:46Z",
|
||
"side": 1,
|
||
"message": "That\u0027s not what I mean, that will happen with the graph, the problem is that the old nodes won\u0027t all of the tags that the new graph may need. So what will happen when resolving where they run? do they not get run? does it fall back to the role serializer (I think no, because they have tags task). This to me just adds more need for implicit fallback of tags to role argument. on the other side, did we update roles/release to know that there are new tags too?\n\nMy point is that we need to think more about how we are handling transitions between minor versions of the release bundle\n\nFor now, just change this to TBD (To be determined) it is clearly not none",
|
||
"parentUuid": "9ad45d7e_d7f1cd02",
|
||
"range": {
|
||
"startLine": 341,
|
||
"startChar": 0,
|
||
"endLine": 341,
|
||
"endChar": 4
|
||
},
|
||
"revId": "498fcb5105622d2a52eb2eda101734f97f4e79c3",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||
"unresolved": false
|
||
},
|
||
{
|
||
"key": {
|
||
"uuid": "9ad45d7e_71ea7e75",
|
||
"filename": "specs/10.0/role-decomposition.rst",
|
||
"patchSetId": 17
|
||
},
|
||
"lineNbr": 341,
|
||
"author": {
|
||
"id": 12559
|
||
},
|
||
"writtenOn": "2016-08-11T14:29:18Z",
|
||
"side": 1,
|
||
"message": "Ok. Will change it.",
|
||
"parentUuid": "9ad45d7e_7c5d6114",
|
||
"range": {
|
||
"startLine": 341,
|
||
"startChar": 0,
|
||
"endLine": 341,
|
||
"endChar": 4
|
||
},
|
||
"revId": "498fcb5105622d2a52eb2eda101734f97f4e79c3",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||
"unresolved": false
|
||
},
|
||
{
|
||
"key": {
|
||
"uuid": "9ad45d7e_af70fd0b",
|
||
"filename": "specs/10.0/role-decomposition.rst",
|
||
"patchSetId": 17
|
||
},
|
||
"lineNbr": 341,
|
||
"author": {
|
||
"id": 12559
|
||
},
|
||
"writtenOn": "2016-08-11T20:07:36Z",
|
||
"side": 1,
|
||
"message": "Done",
|
||
"parentUuid": "9ad45d7e_71ea7e75",
|
||
"range": {
|
||
"startLine": 341,
|
||
"startChar": 0,
|
||
"endLine": 341,
|
||
"endChar": 4
|
||
},
|
||
"revId": "498fcb5105622d2a52eb2eda101734f97f4e79c3",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||
"unresolved": false
|
||
}
|
||
]
|
||
} |