openstack/ironic-inspector-specs
Code Issues Proposed changes
49ad09f260
ironic-inspector-specs/3387a4be54016ac6efdfb2c432cc85b790525063
Gerrit User 18653 f4b16b6846 Update patch set 6 
Patch Set 6:

(1 comment)

Patch-set: 6
2017-04-21 08:22:18 +00:00

922 lines
33 KiB
Plaintext
Raw Blame History

{
"comments": [
{
"key": {
"uuid": "7ffa3b31_7c3000e9",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 38,
"author": {
"id": 18653
},
"writtenOn": "2017-04-20T09:12:50Z",
"side": 1,
"message": "how about ``waiting(timeout) -\u003e error`` for the timeout handling below.",
"range": {
"startLine": 38,
"startChar": 0,
"endLine": 38,
"endChar": 40
},
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_4691f14d",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 40,
"author": {
"id": 18653
},
"writtenOn": "2017-04-20T09:12:50Z",
"side": 1,
"message": "I think the conceptual link between a task and the RPC is missing here. How about something like:\n\n An API request eventually becomes such a task.\n API request that are executed in the background can be considered asynchronous tasks.\n It is these tasks that allow splitting the service into the synchronous *API half* and the asynchronous, background *worker half*, the former creating tasks the latter consuming those.\n The communication of these service parts requires a medium, the *queue*, and together these three subjects comprise the `messaging queue paradigm \u003chttps://en.wikipedia.org/wiki/Message_queue\u003e`_.\n For the purpose of tasks handling in **inspector** it is essential the queue is *reliable* and doesn\u0027t loose messages.\n\n A reliable, *at-least-once* semantics messaging queue pattern lacking support in **oslo**, we decided to simulate the paradigm with the unreliable ``oslo.messaging.RPC:Cast`` [2]_ abstraction with tasks run-time protected by *timeout*.",
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_ad265014",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 40,
"author": {
"id": 13636
},
"writtenOn": "2017-04-20T10:38:28Z",
"side": 1,
"message": "Using timeout for died workers is not good idea, it would be hard to distinguish real timeout from crashes.\n\nAlso why do you pointing to `cast` only, as we could use both call and cast depending on endpoint.",
"parentUuid": "7ffa3b31_4691f14d",
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_5232c85f",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 40,
"author": {
"id": 18653
},
"writtenOn": "2017-04-20T11:41:05Z",
"side": 1,
"message": "\u003e Using timeout for died workers is not good idea, it would be hard to distinguish real timeout from crashes.\n\nNot really; in case of \"regular\" failures/errors caught, the error message won\u0027t be \u0027timeout\u0027. On the other hand, how would you call an error that happened because your patience with a never finishing task reached its limit?\n\nThe issue will be partially addressed by IPA retrying the processing. But yes, sometimes we\u0027ll have timeout because of network issues (or an unfortunately dying worker), but those will be really rare and can be just retried by the user. \n\n\u003e Also why do you pointing to `cast` only, as we could use both call and cast depending on endpoint.\n\nThe `call` being synchronous, what is the point in splitting it between API and Worker? The API can and should handle synchronous requests on its own.",
"parentUuid": "7ffa3b31_ad265014",
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_b501f608",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 40,
"author": {
"id": 13636
},
"writtenOn": "2017-04-20T12:45:11Z",
"side": 1,
"message": "I\u0027m going to track worker aliveness and don\u0027t rely on inspection timeout. Yeah, IPA may analyze error msg, but imo it shouldn\u0027t, instead it could send data periodically (not sure, but it could be done already) and inspector will decide what to do next.\n\nAs for `call` method, it could be used for `post /introspection`. API will call Worker, which creates new introspection task in db, spawns background thread and returns status to user. So user has response and inspector don\u0027t miss introspection task if there are rabbit issues, or no workers and so on.\nI\u0027d expect most user requests will use `call`, see ironic as example",
"parentUuid": "7ffa3b31_5232c85f",
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_e647d24b",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 40,
"author": {
"id": 18653
},
"writtenOn": "2017-04-20T14:00:59Z",
"side": 1,
"message": "\u003e I\u0027m going to track worker aliveness and don\u0027t rely on inspection timeout. \n\nI\u0027m not sure how to easily map which task belonged to the dying worker for the purpose of setting the error state.\n\n\u003e Yeah, IPA may analyze error msg, but imo it shouldn\u0027t, instead it could send data periodically (not sure, but it could be done already) and inspector will decide what to do next.\n\nIf the state was processing, the introspection would be set to error as we deliberately forbid reentracy on the processing state.\n\nBut I agree retrying based on the state\u0026error may be tricky to get right; my top-of-the-head idea:\n\n retries \u003d 3\n while retries:\n retries -\u003d 1\n try:\n node \u003d POST(data)@/v1/continue.response[\u0027uuid\u0027]\n except HTTPError(503):\n # service temporary unavailable\n sleep(3)\n continue\n \n while True:\n try:\n response \u003d GET@/v1/introspection/node:\n except HTTPError(503):\n sleep(3)\n continue\n \n state, error \u003d response[\u0027state\u0027], response[\u0027error\u0027]\n\n # relying on an eventual introspection error/timeout\n if state in {\u0027error\u0027, \u0027finished\u0027}:\n break\n\n sleep(30)\n\n if state \u003d\u003d \u0027error\u0027 \u0026\u0026 error \u003d\u003d \u0027Introspection timeout\u0027:\n # the inspector worker outage case\n continue\n\n if state \u003d\u003d \u0027finished\u0027:\n break\n\n # task neither finished nor possible to retry\n # due to a different error\n raise Error()\n\n else:\n # too many attempts\n raise Error()\n\n\u003e As for `call` method, it could be used for `post /introspection`. API will call Worker, which creates new introspection task in db, spawns background thread and returns status to user. So user has response and inspector don\u0027t miss introspection task if there are rabbit issues, or no workers and so on. I\u0027d expect most user requests will use `call`, see ironic as example\n\nThis would change the POST@/v1/introspection/\u003cnode\u003e endpoint semantics.\nIIRC it\u0027s async[1] and that should be the case as an long-running introspection procedure starts behind the scenes. The user or ironic should poll the GET@/v1/introspection/\u003cnode\u003e for the status instead.\n\n[1] https://github.com/openstack/ironic-inspector/blob/master/ironic_inspector/main.py#L234",
"parentUuid": "7ffa3b31_b501f608",
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_a3f1c797",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 45,
"author": {
"id": 18653
},
"writtenOn": "2017-04-20T09:12:50Z",
"side": 1,
"message": "s/an//",
"range": {
"startLine": 45,
"startChar": 41,
"endLine": 45,
"endChar": 43
},
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_c6cf4154",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 60,
"author": {
"id": 18653
},
"writtenOn": "2017-04-20T09:12:50Z",
"side": 1,
"message": "s/// as we chosen the cast already.",
"range": {
"startLine": 55,
"startChar": 0,
"endLine": 60,
"endChar": 17
},
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_d76b6db4",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 60,
"author": {
"id": 13636
},
"writtenOn": "2017-04-20T10:38:28Z",
"side": 1,
"message": "They will be both available, so it would be possible to use call anyway, also I think we could use `call` with spawn greenthread for /introspection request.\n\nok, I think we should describe all API endpoints here",
"parentUuid": "7ffa3b31_c6cf4154",
"range": {
"startLine": 55,
"startChar": 0,
"endLine": 60,
"endChar": 17
},
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_122680cf",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 60,
"author": {
"id": 18653
},
"writtenOn": "2017-04-20T11:41:05Z",
"side": 1,
"message": "please, see my previous response. I think optimizing synchronous requests into RPC isn\u0027t necessary as it won\u0027t help much in splitting the service. If needed, let\u0027s put it in a separate spec.",
"parentUuid": "7ffa3b31_d76b6db4",
"range": {
"startLine": 55,
"startChar": 0,
"endLine": 60,
"endChar": 17
},
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_c6262116",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 75,
"author": {
"id": 18653
},
"writtenOn": "2017-04-20T09:12:50Z",
"side": 1,
"message": "s/Message delivery/RPC reliability/",
"range": {
"startLine": 75,
"startChar": 0,
"endLine": 75,
"endChar": 16
},
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_bc3fa8b2",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 84,
"author": {
"id": 18653
},
"writtenOn": "2017-04-20T09:12:50Z",
"side": 1,
"message": "task request message",
"range": {
"startLine": 84,
"startChar": 10,
"endLine": 84,
"endChar": 17
},
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_fc72d0ac",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 84,
"author": {
"id": 18653
},
"writtenOn": "2017-04-20T09:12:50Z",
"side": 1,
"message": "s/whole/the/",
"range": {
"startLine": 84,
"startChar": 37,
"endLine": 84,
"endChar": 42
},
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_66f2ad72",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 85,
"author": {
"id": 18653
},
"writtenOn": "2017-04-20T09:12:50Z",
"side": 1,
"message": "an \"active\" state (starting, waiting, enrolling, processing).",
"range": {
"startLine": 85,
"startChar": 0,
"endLine": 85,
"endChar": 21
},
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_269dc509",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 85,
"author": {
"id": 18653
},
"writtenOn": "2017-04-20T09:12:50Z",
"side": 1,
"message": "the tasks hanging indefinitely,",
"range": {
"startLine": 85,
"startChar": 39,
"endLine": 85,
"endChar": 56
},
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_b9ad7aea",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 86,
"author": {
"id": 18653
},
"writtenOn": "2017-04-20T09:12:50Z",
"side": 1,
"message": "detect this condition by employing a *timeout* mechanism, expanding on current `introspection timeout handling \u003chttps://github.com/openstack/ironic-inspector/blob/master/ironic_inspector/node_cache.py#L851-#L889\u003e`_. This will require a ``timeout`` transition on all active introspection states.",
"range": {
"startLine": 86,
"startChar": 15,
"endLine": 86,
"endChar": 37
},
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_176b15f1",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 86,
"author": {
"id": 13636
},
"writtenOn": "2017-04-20T10:38:28Z",
"side": 1,
"message": "First, we could use existing `clean up`, but I wouldn\u0027t rely on timeout here which could be pretty big value, instead use existing coordination mechanisms.",
"parentUuid": "7ffa3b31_b9ad7aea",
"range": {
"startLine": 86,
"startChar": 15,
"endLine": 86,
"endChar": 37
},
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_95ea7a0c",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 86,
"author": {
"id": 18653
},
"writtenOn": "2017-04-20T11:41:05Z",
"side": 1,
"message": "relying on the clean-up is the easiest and most straightforward path, if a node isn\u0027t responding or a task is (rarely) hanging it doesn\u0027t make much difference. The whole introspection is async from **ironic**/user\u0027s pow. Of course we can have state-specific timeouts but I\u0027m unsure about the benefits vs the complication.",
"parentUuid": "7ffa3b31_176b15f1",
"range": {
"startLine": 86,
"startChar": 15,
"endLine": 86,
"endChar": 37
},
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_7bd8ff79",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 86,
"author": {
"id": 13636
},
"writtenOn": "2017-04-20T12:45:11Z",
"side": 1,
"message": "Yeah, it\u0027s the easiest way, but practice shows that operators don\u0027t want to wait timeout if something go wrong.",
"parentUuid": "7ffa3b31_95ea7a0c",
"range": {
"startLine": 86,
"startChar": 15,
"endLine": 86,
"endChar": 37
},
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_cc4e3737",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 86,
"author": {
"id": 18653
},
"writtenOn": "2017-04-20T14:03:19Z",
"side": 1,
"message": "shouldn\u0027t be too frequent for the operator to worry about ;)",
"parentUuid": "7ffa3b31_7bd8ff79",
"range": {
"startLine": 86,
"startChar": 15,
"endLine": 86,
"endChar": 37
},
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_666cc69b",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 86,
"author": {
"id": 18653
},
"writtenOn": "2017-04-21T08:22:18Z",
"side": 1,
"message": "More seriously, I think it\u0027s good to have a safety timeout mechanism in place to avoid having to resort to manually update the database to unblock stale tasks, that the operator might dislike more than a slower response.\n\nAlso please note if we adopt single timeout for the whole introspection procedure, manually triggered introspections will detect an outage within the timeout, including node boot, as we derive it from the started_at timestamp.\n\nDiscoveries will have longer time to spend in the processing state before declared stale\u0026timeout.\n\nAnother approach is to allow abort to happen in any active state.",
"parentUuid": "7ffa3b31_cc4e3737",
"range": {
"startLine": 86,
"startChar": 15,
"endLine": 86,
"endChar": 37
},
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_59a316b3",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 88,
"author": {
"id": 18653
},
"writtenOn": "2017-04-20T09:12:50Z",
"side": 1,
"message": "Furthermore, the current timeout handling ``node_cache.clean_up`` should be a `singleton periodic task \u003chttps://specs.openstack.org/openstack/ironic-inspector-specs/specs/HA_inspector.html#ha-singleton-periodic-task-decomposition\u003e`_.",
"range": {
"startLine": 86,
"startChar": 38,
"endLine": 88,
"endChar": 73
},
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_99751e35",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 91,
"author": {
"id": 18653
},
"writtenOn": "2017-04-20T09:12:50Z",
"side": 1,
"message": "Due to the unreliable nature of the employed RPC mechanism, supporting HA ...",
"range": {
"startLine": 90,
"startChar": 0,
"endLine": 91,
"endChar": 71
},
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_f99b0263",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 93,
"author": {
"id": 18653
},
"writtenOn": "2017-04-20T09:12:50Z",
"side": 1,
"message": ".",
"range": {
"startLine": 93,
"startChar": 4,
"endLine": 93,
"endChar": 5
},
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_390deaa0",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 95,
"author": {
"id": 18653
},
"writtenOn": "2017-04-20T09:12:50Z",
"side": 1,
"message": "could poll the introspection status. If the introspection times out (``state \u003d\u003d \u0027error\u0027 and error \u003d\u003d \u0027Introspection timeout\u0027``), IPA might retry posting the introspection data again.",
"range": {
"startLine": 93,
"startChar": 59,
"endLine": 95,
"endChar": 39
},
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_4dbeacd5",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 95,
"author": {
"id": 13636
},
"writtenOn": "2017-04-20T10:38:28Z",
"side": 1,
"message": "Yeah, I still think about this.\n\nActually I\u0027m not in favor of this, imo IPA shouldn\u0027t retry and know something about inspector internals.",
"parentUuid": "7ffa3b31_390deaa0",
"range": {
"startLine": 93,
"startChar": 59,
"endLine": 95,
"endChar": 39
},
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_750b6ed5",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 95,
"author": {
"id": 18653
},
"writtenOn": "2017-04-20T11:41:05Z",
"side": 1,
"message": "What happens in that rare case that IPA booted but the introspection timed out is we can be pretty sure inspector encountered some outage. On the other hand, if the error message isn\u0027t timeout, IPA must not retry.",
"parentUuid": "7ffa3b31_4dbeacd5",
"range": {
"startLine": 93,
"startChar": 59,
"endLine": 95,
"endChar": 39
},
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_7b347f93",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 95,
"author": {
"id": 13636
},
"writtenOn": "2017-04-20T12:45:11Z",
"side": 1,
"message": "I don\u0027t say that we shouldn\u0027t handle this case, I think inspector should care about it, not IPA.",
"parentUuid": "7ffa3b31_750b6ed5",
"range": {
"startLine": 93,
"startChar": 59,
"endLine": 95,
"endChar": 39
},
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_d92966e6",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 128,
"author": {
"id": 18653
},
"writtenOn": "2017-04-20T09:12:50Z",
"side": 1,
"message": "On the other hand,",
"range": {
"startLine": 128,
"startChar": 0,
"endLine": 128,
"endChar": 4
},
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_7c17e046",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 169,
"author": {
"id": 18653
},
"writtenOn": "2017-04-20T09:12:50Z",
"side": 1,
"message": "The Tooz DLM backend should be considered here too.",
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_7216e7f3",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 169,
"author": {
"id": 13636
},
"writtenOn": "2017-04-20T10:38:28Z",
"side": 1,
"message": "I don\u0027t consider DLM work of part of this work, it would work w/o it",
"parentUuid": "7ffa3b31_7c17e046",
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_b5ea16d5",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 169,
"author": {
"id": 18653
},
"writtenOn": "2017-04-20T11:41:05Z",
"side": 1,
"message": "I think leader election requires some Tooz DLM backend and that might need securing (can be Zookeeper for instance).",
"parentUuid": "7ffa3b31_7216e7f3",
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_bbbfa7a8",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 169,
"author": {
"id": 13636
},
"writtenOn": "2017-04-20T12:45:11Z",
"side": 1,
"message": "Yeah, it will. But it\u0027s separate feature, which we need to discuss, if decide to cover it by this spec, I\u0027m fine",
"parentUuid": "7ffa3b31_b5ea16d5",
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_7c16c0f3",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 185,
"author": {
"id": 18653
},
"writtenOn": "2017-04-20T09:12:50Z",
"side": 1,
"message": "Because of the ``POST@/v1/continue`` endpoint change, the IPA will have to be updated, with new configuration option ``continue_retries``.",
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_12444373",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 185,
"author": {
"id": 13636
},
"writtenOn": "2017-04-20T10:38:28Z",
"side": 1,
"message": "It is not requirements, old IPA still could be used",
"parentUuid": "7ffa3b31_7c16c0f3",
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_15d2ea00",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 185,
"author": {
"id": 18653
},
"writtenOn": "2017-04-20T11:41:05Z",
"side": 1,
"message": "yes, but the deployer should be advised to upgrade to benefit from the retry mechanism. Also most likely we won\u0027t be able to return the IPMI credentials anymore, that might be worth mentioning.",
"parentUuid": "7ffa3b31_12444373",
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_99e2be9f",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 186,
"author": {
"id": 18653
},
"writtenOn": "2017-04-20T09:12:50Z",
"side": 1,
"message": "missing the tooz DLM support for distributed leader election.",
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_59331615",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 197,
"author": {
"id": 18653
},
"writtenOn": "2017-04-20T09:12:50Z",
"side": 1,
"message": "might",
"range": {
"startLine": 197,
"startChar": 64,
"endLine": 197,
"endChar": 69
},
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_b987bab5",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 198,
"author": {
"id": 18653
},
"writtenOn": "2017-04-20T09:12:50Z",
"side": 1,
"message": "some additional services: the worker, the HAProxy, the messaging transport backend (RabbitMQ) and the Tooz DLM backend.",
"range": {
"startLine": 198,
"startChar": 7,
"endLine": 198,
"endChar": 24
},
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_b9757acd",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 200,
"author": {
"id": 18653
},
"writtenOn": "2017-04-20T09:12:50Z",
"side": 1,
"message": "and a local Tooz DLM backend.",
"range": {
"startLine": 200,
"startChar": 9,
"endLine": 200,
"endChar": 10
},
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_bc11e854",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 216,
"author": {
"id": 18653
},
"writtenOn": "2017-04-20T09:12:50Z",
"side": 1,
"message": "* Adopt the DLM leader election for the periodic clean-up task;\n\n* Add the ``timeout`` transition to all active introspection states;",
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_fcdf7037",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 218,
"author": {
"id": 18653
},
"writtenOn": "2017-04-20T09:12:50Z",
"side": 1,
"message": "* update IPA to match the changes at the ``POST@/v1/continue`` API endpoint",
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "7ffa3b31_b9233abd",
"filename": "specs/splitting-service-on-API-and-worker.rst",
"patchSetId": 6
},
"lineNbr": 232,
"author": {
"id": 18653
},
"writtenOn": "2017-04-20T09:12:50Z",
"side": 1,
"message": "s/kombu/messaging transport backend and a local DLM/",
"range": {
"startLine": 232,
"startChar": 70,
"endLine": 232,
"endChar": 75
},
"revId": "3387a4be54016ac6efdfb2c432cc85b790525063",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
}
]
}
View Git Blame Copy Permalink