Update patch set 5
Patch Set 5: Code-Review-1 (20 comments) Patch-set: 5 Label: Code-Review=-1
This commit is contained in:
Gerrit User 7585
Gerrit Code Review
parent
2442bb76a3
commit
d6ad29e75e
|
|
@ -244,6 +244,24 @@
|
|||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "3ae8d1ca_bb86d5b7",
|
||||
"filename": "specs/juno/tuskar-rest-api.rst",
|
||||
"patchSetId": 5
|
||||
},
|
||||
"lineNbr": 56,
|
||||
"author": {
|
||||
"id": 7585
|
||||
},
|
||||
"writtenOn": "2014-05-28T11:46:57Z",
|
||||
"side": 1,
|
||||
"message": "Actually heat is not sending noEcho attributes on the wire. It replaces them by *** placeholder, so we can\u0027t access any passwords from Heat.\n\nWe should be also discussing if we need to access all the passwords. AFAIK we only need credentials for a special Tuskar(or TripleO) user, that will have rights to do limited stuff with overcloud (access keystone catalog, ceilometer stats, etc.). And we need user with admin rights for os-cloud-config.\n\nFor heat stack-update, we don\u0027t need to access the passwords, heat will handle that.\n\nSo do we need to store all the params just for planning purposes?",
|
||||
"parentUuid": "3ae8d1ca_c04ae282",
|
||||
"revId": "e19645628b53601fe3803c2edb6296d03e8a811f",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "3ae8d1ca_d77394af",
|
||||
|
|
@ -314,6 +332,59 @@
|
|||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "3ae8d1ca_66abd4d8",
|
||||
"filename": "specs/juno/tuskar-rest-api.rst",
|
||||
"patchSetId": 5
|
||||
},
|
||||
"lineNbr": 90,
|
||||
"author": {
|
||||
"id": 7585
|
||||
},
|
||||
"writtenOn": "2014-05-28T11:46:57Z",
|
||||
"side": 1,
|
||||
"message": "@lifeless I believe the role data will be associated to flavor, which is just passed as a parameter to heat. Do we need to duplicate that information here? -1 to duplication",
|
||||
"parentUuid": "5adbc538_d012c557",
|
||||
"revId": "e19645628b53601fe3803c2edb6296d03e8a811f",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "3ae8d1ca_e19c2e6c",
|
||||
"filename": "specs/juno/tuskar-rest-api.rst",
|
||||
"patchSetId": 5
|
||||
},
|
||||
"lineNbr": 90,
|
||||
"author": {
|
||||
"id": 7585
|
||||
},
|
||||
"writtenOn": "2014-05-28T11:46:57Z",
|
||||
"side": 1,
|
||||
"message": "So just to be clear. The role represents provider resource. Before we deploy it, all we can access from the template is interface (parameters). That I would say belongs to Role detail.\nAfter deploy, it will be represented by Heat Nested Stack, so we will get additional info from there. It should have relation by the Provider Resource name.\n\nIn cloud detail, it should be ok to just have list of roles added, but there needs to be 2 references. One to actual template(e.g. UUID in glance), other the Provider Resource name.\n\nI would like to see list of all provider resources, like HOT soft. configs, etc. We need to list all the templates and let user to upload the missing templates. Roles are just the \u0027special ones\u0027.",
|
||||
"parentUuid": "3ae8d1ca_43417c38",
|
||||
"revId": "e19645628b53601fe3803c2edb6296d03e8a811f",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "3ae8d1ca_c6c82877",
|
||||
"filename": "specs/juno/tuskar-rest-api.rst",
|
||||
"patchSetId": 5
|
||||
},
|
||||
"lineNbr": 98,
|
||||
"author": {
|
||||
"id": 7585
|
||||
},
|
||||
"writtenOn": "2014-05-28T11:46:57Z",
|
||||
"side": 1,
|
||||
"message": "btw. is this a free form parameter? If not it has to follow Heat Spec of parameters.",
|
||||
"revId": "e19645628b53601fe3803c2edb6296d03e8a811f",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "5adbc538_b02539ad",
|
||||
|
|
@ -349,6 +420,41 @@
|
|||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "3ae8d1ca_0113dab8",
|
||||
"filename": "specs/juno/tuskar-rest-api.rst",
|
||||
"patchSetId": 5
|
||||
},
|
||||
"lineNbr": 118,
|
||||
"author": {
|
||||
"id": 7585
|
||||
},
|
||||
"writtenOn": "2014-05-28T11:46:57Z",
|
||||
"side": 1,
|
||||
"message": "Well if you will try to access Heat Stack without permissions it will fail. So we should at least catch the exception correctly, later we can fine tune it.",
|
||||
"parentUuid": "3ae8d1ca_c39bccc7",
|
||||
"revId": "e19645628b53601fe3803c2edb6296d03e8a811f",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "3ae8d1ca_c1e572a9",
|
||||
"filename": "specs/juno/tuskar-rest-api.rst",
|
||||
"patchSetId": 5
|
||||
},
|
||||
"lineNbr": 124,
|
||||
"author": {
|
||||
"id": 7585
|
||||
},
|
||||
"writtenOn": "2014-05-28T11:46:57Z",
|
||||
"side": 1,
|
||||
"message": "I believe that is how other APIs work. Calling list, I get list of full objects( though I saw the flag somewhere.)\nAs a first version I would rather expect to get a list of full objects, so we don\u0027t have to make call per row in UI.",
|
||||
"revId": "e19645628b53601fe3803c2edb6296d03e8a811f",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "3ae8d1ca_625e80eb",
|
||||
|
|
@ -402,6 +508,41 @@
|
|||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "3ae8d1ca_6c2655b9",
|
||||
"filename": "specs/juno/tuskar-rest-api.rst",
|
||||
"patchSetId": 5
|
||||
},
|
||||
"lineNbr": 146,
|
||||
"author": {
|
||||
"id": 7585
|
||||
},
|
||||
"writtenOn": "2014-05-28T11:46:57Z",
|
||||
"side": 1,
|
||||
"message": "noo hostname :-) relative paths are used, hostnames are in keystone",
|
||||
"parentUuid": "3ae8d1ca_a38de07d",
|
||||
"revId": "e19645628b53601fe3803c2edb6296d03e8a811f",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "3ae8d1ca_8c41e13b",
|
||||
"filename": "specs/juno/tuskar-rest-api.rst",
|
||||
"patchSetId": 5
|
||||
},
|
||||
"lineNbr": 170,
|
||||
"author": {
|
||||
"id": 7585
|
||||
},
|
||||
"writtenOn": "2014-05-28T11:46:57Z",
|
||||
"side": 1,
|
||||
"message": "you want to start with empty stack and then update it? \nNever tried to create an empty stack. Is this actually needed?",
|
||||
"revId": "e19645628b53601fe3803c2edb6296d03e8a811f",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "3ae8d1ca_5455c21b",
|
||||
|
|
@ -437,6 +578,41 @@
|
|||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "3ae8d1ca_4cac39a1",
|
||||
"filename": "specs/juno/tuskar-rest-api.rst",
|
||||
"patchSetId": 5
|
||||
},
|
||||
"lineNbr": 178,
|
||||
"author": {
|
||||
"id": 7585
|
||||
},
|
||||
"writtenOn": "2014-05-28T11:46:57Z",
|
||||
"side": 1,
|
||||
"message": "Why do we need to create an empty stack? I guess creating empty stack will not take that much time, though wrapping it like this just feels bad.\n\n\u0027Not take that much time\u0027 must be less than API will timeout btw. Can you be sure heat will be always kind like this?",
|
||||
"parentUuid": "3ae8d1ca_e3d52844",
|
||||
"revId": "e19645628b53601fe3803c2edb6296d03e8a811f",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "3ae8d1ca_ccc4c942",
|
||||
"filename": "specs/juno/tuskar-rest-api.rst",
|
||||
"patchSetId": 5
|
||||
},
|
||||
"lineNbr": 182,
|
||||
"author": {
|
||||
"id": 7585
|
||||
},
|
||||
"writtenOn": "2014-05-28T11:46:57Z",
|
||||
"side": 1,
|
||||
"message": "so this will highly depend on UI jaromir will present, we should focus on dealing with multiple API calls on the API side. So the Juno UI should be designed the way we don\u0027t need it.",
|
||||
"revId": "e19645628b53601fe3803c2edb6296d03e8a811f",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "3ae8d1ca_f71fb007",
|
||||
|
|
@ -472,6 +648,24 @@
|
|||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "3ae8d1ca_0c907142",
|
||||
"filename": "specs/juno/tuskar-rest-api.rst",
|
||||
"patchSetId": 5
|
||||
},
|
||||
"lineNbr": 189,
|
||||
"author": {
|
||||
"id": 7585
|
||||
},
|
||||
"writtenOn": "2014-05-28T11:46:57Z",
|
||||
"side": 1,
|
||||
"message": "Well this is gonna be stack name, so it has to be unique. Then in CLI you can use both name or UUID, in API I am not sure.",
|
||||
"parentUuid": "3ae8d1ca_23471021",
|
||||
"revId": "e19645628b53601fe3803c2edb6296d03e8a811f",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "5adbc538_d0400538",
|
||||
|
|
@ -507,6 +701,24 @@
|
|||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "3ae8d1ca_6cd735c2",
|
||||
"filename": "specs/juno/tuskar-rest-api.rst",
|
||||
"patchSetId": 5
|
||||
},
|
||||
"lineNbr": 204,
|
||||
"author": {
|
||||
"id": 7585
|
||||
},
|
||||
"writtenOn": "2014-05-28T11:46:57Z",
|
||||
"side": 1,
|
||||
"message": "@lifeless, this will all highly depend on Heat. If heat is doing the name-spacing, we should do too. But I am not sure it does.\n\nCause cloud name\u003d\u003dheat stack name, right?",
|
||||
"parentUuid": "3ae8d1ca_a317a0ec",
|
||||
"revId": "e19645628b53601fe3803c2edb6296d03e8a811f",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "5adbc538_305f6910",
|
||||
|
|
@ -559,6 +771,24 @@
|
|||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "3ae8d1ca_e7699e8c",
|
||||
"filename": "specs/juno/tuskar-rest-api.rst",
|
||||
"patchSetId": 5
|
||||
},
|
||||
"lineNbr": 231,
|
||||
"author": {
|
||||
"id": 7585
|
||||
},
|
||||
"writtenOn": "2014-05-28T11:46:57Z",
|
||||
"side": 1,
|
||||
"message": "Nooo. All operations from heat must be checked. Right now we don\u0027t check it and it is just a huge mess full of zombies. This has to be implemented properly with e.g. taskflow.",
|
||||
"parentUuid": "3ae8d1ca_e38d2833",
|
||||
"revId": "e19645628b53601fe3803c2edb6296d03e8a811f",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "3ae8d1ca_d7b554ce",
|
||||
|
|
@ -594,6 +824,24 @@
|
|||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "3ae8d1ca_5c822450",
|
||||
"filename": "specs/juno/tuskar-rest-api.rst",
|
||||
"patchSetId": 5
|
||||
},
|
||||
"lineNbr": 236,
|
||||
"author": {
|
||||
"id": 7585
|
||||
},
|
||||
"writtenOn": "2014-05-28T11:46:57Z",
|
||||
"side": 1,
|
||||
"message": "This would mean we would have to prepare the UI so it can display standalone Heat and there is optional Tuskar Extension. Cause when the delete fails, you would have just stack without cloud there. \n\nAll the operations that are packed into Tuskar, should be handled via Tuskar. So either you update, delete or create via Tuskar, Tuskar should handle all the states properly via some workflow abstraction (taskflow). Otherwise we should not proxy the operation via Tuskar.",
|
||||
"parentUuid": "3ae8d1ca_039a1463",
|
||||
"revId": "e19645628b53601fe3803c2edb6296d03e8a811f",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "3ae8d1ca_a2440875",
|
||||
|
|
@ -699,6 +947,24 @@
|
|||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "3ae8d1ca_dc4634bf",
|
||||
"filename": "specs/juno/tuskar-rest-api.rst",
|
||||
"patchSetId": 5
|
||||
},
|
||||
"lineNbr": 301,
|
||||
"author": {
|
||||
"id": 7585
|
||||
},
|
||||
"writtenOn": "2014-05-28T11:46:57Z",
|
||||
"side": 1,
|
||||
"message": "I agree the state is not appropriate here, we can check state of the provider resource once it has been deployed.\n\nSo I think having a simple flag \u0027maybe something was changed\u0027 as first version is fine. As a second version I would like to see actual comparing of what was changed and appropriate message ( obviously we will have problem with passwords, when Heat doesn\u0027t expose them, we can\u0027t compare them ). So it covers also case when you change something and then revert it.\n\nWe can do the basic checks also in UI, like showing which roles are new, that some parameter has changed, etc.",
|
||||
"parentUuid": "3ae8d1ca_e6529612",
|
||||
"revId": "e19645628b53601fe3803c2edb6296d03e8a811f",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "3ae8d1ca_1d9fdd60",
|
||||
|
|
@ -734,6 +1000,24 @@
|
|||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "3ae8d1ca_1c9b3c19",
|
||||
"filename": "specs/juno/tuskar-rest-api.rst",
|
||||
"patchSetId": 5
|
||||
},
|
||||
"lineNbr": 307,
|
||||
"author": {
|
||||
"id": 7585
|
||||
},
|
||||
"writtenOn": "2014-05-28T11:46:57Z",
|
||||
"side": 1,
|
||||
"message": "Yeah I agree, this should not make any asynchronous call on the background, so blocking should be fine.",
|
||||
"parentUuid": "3ae8d1ca_6665a6e0",
|
||||
"revId": "e19645628b53601fe3803c2edb6296d03e8a811f",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "3ae8d1ca_dd7bb527",
|
||||
|
|
@ -786,6 +1070,24 @@
|
|||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "3ae8d1ca_af1a0c15",
|
||||
"filename": "specs/juno/tuskar-rest-api.rst",
|
||||
"patchSetId": 5
|
||||
},
|
||||
"lineNbr": 365,
|
||||
"author": {
|
||||
"id": 7585
|
||||
},
|
||||
"writtenOn": "2014-05-28T11:46:57Z",
|
||||
"side": 1,
|
||||
"message": "Well, we will always show both tuskar state and heat state\n\nSo tuskar just says if there are any new changes, that has not been sent to heat and heat says what is the state of deployment. I guess this combination should be enough.",
|
||||
"parentUuid": "3ae8d1ca_66acc6ee",
|
||||
"revId": "e19645628b53601fe3803c2edb6296d03e8a811f",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "3ae8d1ca_3d1d79be",
|
||||
|
|
@ -821,6 +1123,24 @@
|
|||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "3ae8d1ca_cfe2f89e",
|
||||
"filename": "specs/juno/tuskar-rest-api.rst",
|
||||
"patchSetId": 5
|
||||
},
|
||||
"lineNbr": 376,
|
||||
"author": {
|
||||
"id": 7585
|
||||
},
|
||||
"writtenOn": "2014-05-28T11:46:57Z",
|
||||
"side": 1,
|
||||
"message": "So in this case, I would actually like to see the status here.\n\nIt should be workflow abstraction of\n1.stack deploy (one api call)\n2. initializing (multiple api calls)\n\nSo we should track the status of Tuskar Cloud properly here. If it fails e.g. initializing neutron, you should be able to just retry it from that point.\n\nIf it won\u0027t be done this way, Tuskar should not proxy the Heat calls at all. Just provide template and environment file to user.",
|
||||
"parentUuid": "3ae8d1ca_c6e91a1c",
|
||||
"revId": "e19645628b53601fe3803c2edb6296d03e8a811f",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "3ae8d1ca_bd81894c",
|
||||
|
|
@ -856,6 +1176,24 @@
|
|||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "3ae8d1ca_923e53b7",
|
||||
"filename": "specs/juno/tuskar-rest-api.rst",
|
||||
"patchSetId": 5
|
||||
},
|
||||
"lineNbr": 434,
|
||||
"author": {
|
||||
"id": 7585
|
||||
},
|
||||
"writtenOn": "2014-05-28T11:46:57Z",
|
||||
"side": 1,
|
||||
"message": "This heavily depends on parameter consolidation, which hasn\u0027t been discussed yet. Cause you should be able to even add the same version of compute twice. \n\nE.g. to model something like amazon c1 and c3. Only thing that can differ will be the hardware, so you will need to deploy the same role but with the different flavor e.g.\n\nCould you start the parameter consolidation discussion upstream and then edit this?",
|
||||
"parentUuid": "3ae8d1ca_46f98ac7",
|
||||
"revId": "e19645628b53601fe3803c2edb6296d03e8a811f",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "5adbc538_907cbd74",
|
||||
|
|
@ -943,6 +1281,24 @@
|
|||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "3ae8d1ca_72962796",
|
||||
"filename": "specs/juno/tuskar-rest-api.rst",
|
||||
"patchSetId": 5
|
||||
},
|
||||
"lineNbr": 463,
|
||||
"author": {
|
||||
"id": 7585
|
||||
},
|
||||
"writtenOn": "2014-05-28T11:46:57Z",
|
||||
"side": 1,
|
||||
"message": "+1 to not blocking, I guess I raised a question why we need to create empty stack in the first place.",
|
||||
"parentUuid": "3ae8d1ca_06dea23f",
|
||||
"revId": "e19645628b53601fe3803c2edb6296d03e8a811f",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "5adbc538_b0f8d9e6",
|
||||
|
|
|
|||
Loading…
Reference in New Issue