ironic-inspector-specs/4ede6253a130b488b9fdc5748133bccab8952e01

{
  "comments": [
    {
      "key": {
        "uuid": "3f79a3b5_e58e24d0",
        "filename": "specs/configurable-introspection-data-store.rst",
        "patchSetId": 3
      },
      "lineNbr": 66,
      "author": {
        "id": 24828
      },
      "writtenOn": "2018-09-26T07:06:44Z",
      "side": 1,
      "message": "I am a bit concerned with the default suffix, it may cause name conflicts in the future, maybe we just follow the way as swift storage backend, use suffix as part of the naming, so two db fields would be enough.\n\nopinions?",
      "range": {
        "startLine": 66,
        "startChar": 13,
        "endLine": 66,
        "endChar": 41
      },
      "revId": "4ede6253a130b488b9fdc5748133bccab8952e01",
      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
      "unresolved": false
    },
    {
      "key": {
        "uuid": "3f79a3b5_960d2491",
        "filename": "specs/configurable-introspection-data-store.rst",
        "patchSetId": 3
      },
      "lineNbr": 66,
      "author": {
        "id": 10239
      },
      "writtenOn": "2018-09-26T09:16:59Z",
      "side": 1,
      "message": "Do we actually need to support various different suffixes? I wonder if we should change the calls to accept (processed\u003dTrue) and change this field to a boolean. The swift implementation would still use suffixes as part of the name.",
      "parentUuid": "3f79a3b5_e58e24d0",
      "range": {
        "startLine": 66,
        "startChar": 13,
        "endLine": 66,
        "endChar": 41
      },
      "revId": "4ede6253a130b488b9fdc5748133bccab8952e01",
      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
      "unresolved": false
    },
    {
      "key": {
        "uuid": "3f79a3b5_783aa4e6",
        "filename": "specs/configurable-introspection-data-store.rst",
        "patchSetId": 3
      },
      "lineNbr": 66,
      "author": {
        "id": 24828
      },
      "writtenOn": "2018-09-27T02:11:12Z",
      "side": 1,
      "message": "There is no need as far as I can see, I just don\u0027t want to block roads for other possibilities. From the view of arch design, I think a flexible bottom layer can better host changes in the upper layer.\n\nSo we need to decide which way to take:\n\n* unchanged\n* two fields, name + data (which is I preferred)\n* change \"suffix\" to a boolean field \"processed\"",
      "parentUuid": "3f79a3b5_960d2491",
      "range": {
        "startLine": 66,
        "startChar": 13,
        "endLine": 66,
        "endChar": 41
      },
      "revId": "4ede6253a130b488b9fdc5748133bccab8952e01",
      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
      "unresolved": false
    },
    {
      "key": {
        "uuid": "3f79a3b5_40280aed",
        "filename": "specs/configurable-introspection-data-store.rst",
        "patchSetId": 3
      },
      "lineNbr": 66,
      "author": {
        "id": 10239
      },
      "writtenOn": "2018-09-27T08:22:54Z",
      "side": 1,
      "message": "I won\u0027t block any of these options, but I vote for #3.",
      "parentUuid": "3f79a3b5_783aa4e6",
      "range": {
        "startLine": 66,
        "startChar": 13,
        "endLine": 66,
        "endChar": 41
      },
      "revId": "4ede6253a130b488b9fdc5748133bccab8952e01",
      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
      "unresolved": false
    },
    {
      "key": {
        "uuid": "3f79a3b5_3d2bacea",
        "filename": "specs/configurable-introspection-data-store.rst",
        "patchSetId": 3
      },
      "lineNbr": 122,
      "author": {
        "id": 10239
      },
      "writtenOn": "2018-09-27T14:58:06Z",
      "side": 1,
      "message": "I talked to TripleO folks (who are potential consumers of this spec), and they would highly prefer a migration path. What if we embed an optional migration procedure into the dbsync command? like\n\n ironic-inspector-dbsync migrate-data\n\n(will take swift creds from [swift] in inspector.conf and put stuff in database for known nodes). WDYT?",
      "revId": "4ede6253a130b488b9fdc5748133bccab8952e01",
      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
      "unresolved": false
    },
    {
      "key": {
        "uuid": "3f79a3b5_0cb559d0",
        "filename": "specs/configurable-introspection-data-store.rst",
        "patchSetId": 3
      },
      "lineNbr": 122,
      "author": {
        "id": 24828
      },
      "writtenOn": "2018-09-28T01:37:01Z",
      "side": 1,
      "message": "Thanks for bring it up, I lost this after PS1. This is something can do, but have you considered about a standalone script? I am just feeling a db migration depends on external resources sounds unfamiliar, not a typical case.\n\nI don\u0027t know, in my case there is no such migration (we only need to decouple with swift), so I accept any reasonable needs from potential users.",
      "parentUuid": "3f79a3b5_3d2bacea",
      "revId": "4ede6253a130b488b9fdc5748133bccab8952e01",
      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
      "unresolved": false
    },
    {
      "key": {
        "uuid": "3f79a3b5_8dd63926",
        "filename": "specs/configurable-introspection-data-store.rst",
        "patchSetId": 3
      },
      "lineNbr": 122,
      "author": {
        "id": 10239
      },
      "writtenOn": "2018-09-28T13:25:12Z",
      "side": 1,
      "message": "The problem with throwing something in \"tools\" (for example) is that such things are usually not packaged (and thus not delivered to end users). But I\u0027m not talking about a DB migration in a strict sense, but rather about a new command of ironic-inspector-dbsync.\n\nWe could even create a completely new command (maybe that\u0027s what you meant - then sorry for confusion), something like ironic-inspector-data-migrate. As long as we ship it as a script installed in $PREFIX/bin (rather than just something in the tarball), it\u0027s fine.",
      "parentUuid": "3f79a3b5_0cb559d0",
      "revId": "4ede6253a130b488b9fdc5748133bccab8952e01",
      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
      "unresolved": false
    }
  ]
}