openstack
/
heat-specs
Code Issues Proposed changes
heat-specs/047472c9fd87bac6e5e4df99419...

239 lines
9.5 KiB
Plaintext
Raw Blame History

{
"comments": [
{
"key": {
"uuid": "3f1d235d_d7c77e45",
"filename": "specs/pike/support-rolling-upgrades.rst",
"patchSetId": 6
},
"lineNbr": 14,
"author": {
"id": 8833
},
"writtenOn": "2017-06-29T06:12:49Z",
"side": 1,
"message": "you can remove this.",
"range": {
"startLine": 14,
"startChar": 8,
"endLine": 14,
"endChar": 11
},
"revId": "047472c9fd87bac6e5e4df99419ca8216b68bb65",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "3f1d235d_d7f53e85",
"filename": "specs/pike/support-rolling-upgrades.rst",
"patchSetId": 6
},
"lineNbr": 15,
"author": {
"id": 8833
},
"writtenOn": "2017-06-29T06:12:49Z",
"side": 1,
"message": "Thee is only one tag for rolling upgrade, Isn\u0027t it?",
"range": {
"startLine": 15,
"startChar": 17,
"endLine": 15,
"endChar": 58
},
"revId": "047472c9fd87bac6e5e4df99419ca8216b68bb65",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "3f1d235d_d7689e22",
"filename": "specs/pike/support-rolling-upgrades.rst",
"patchSetId": 6
},
"lineNbr": 88,
"author": {
"id": 8833
},
"writtenOn": "2017-06-29T06:12:49Z",
"side": 1,
"message": "I don\u0027t think we leverage oslo versionedobjects at all. We just have an object layer which is redundant.",
"range": {
"startLine": 87,
"startChar": 0,
"endLine": 88,
"endChar": 20
},
"revId": "047472c9fd87bac6e5e4df99419ca8216b68bb65",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "3f1d235d_ee1d0310",
"filename": "specs/pike/support-rolling-upgrades.rst",
"patchSetId": 6
},
"lineNbr": 88,
"author": {
"id": 22406
},
"writtenOn": "2017-06-29T08:52:27Z",
"side": 1,
"message": "Yes, you\u0027re right. The blueprint says it was implemented [1], but when I investigated on it: no tag version, no do_compatible method...just an object layer.\n\nBut with the defined strategy, using a new rabbitmq vhost, it doesn\u0027t affect the rolling upgrade too much. So, we can fill the status as \"Implemented\", with some lines to explain about the actual implementation. Is this ok? :)\n\n[1] https://blueprints.launchpad.net/heat/+spec/versioned-objects",
"parentUuid": "3f1d235d_d7689e22",
"range": {
"startLine": 87,
"startChar": 0,
"endLine": 88,
"endChar": 20
},
"revId": "047472c9fd87bac6e5e4df99419ca8216b68bb65",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "3f1d235d_fa6821bb",
"filename": "specs/pike/support-rolling-upgrades.rst",
"patchSetId": 6
},
"lineNbr": 93,
"author": {
"id": 8833
},
"writtenOn": "2017-06-29T06:12:49Z",
"side": 1,
"message": "I think we do have some issues here:\n\n1. When upgrading from from newton-\u003eocata,\n\nWe\u0027ve added a new table \u0027resource_properties_data\u0027 in ocata[1]. Instead of storing properties data in both \u0027resource\u0027 and \u0027event\u0027 tables, we now store them in the new table.\n\nFor new engines, we \u0027only\u0027 write to the new location, but read from both old and new locations, which is great.\n\nBut old engine would read from/write to old location. So when the rolling upgrade is in progress, old engine would not be able to see data written by new engine. That\u0027s the reason I stopped working on it in Ocata.\n\n2. When upgrading from ocata-\u003epike:\n\nI think we\u0027ve added/adding a new functionality to store resolved attributes in \u0027resource_properties_data\u0027 which resulted in some schema changes[2]. \n\nHowever, AFAIK, old engines would not have any issue as they would work fine without the resolved attributes stored in db. \n\nUnless we plan to add db changes like we did in ocata, we can probably go ahead with this. Though we can\u0027t make changes like ocata anymore. \n\n[1] https://github.com/openstack/heat/commit/d80c23f40978fdf0e92a141da85ca9a7ed77efc2\n\n[2] https://github.com/openstack/heat/commit/9ebbd1e6f1140467041220f9f72d5e3c7fe03b2f",
"range": {
"startLine": 92,
"startChar": 0,
"endLine": 93,
"endChar": 77
},
"revId": "047472c9fd87bac6e5e4df99419ca8216b68bb65",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "3f1d235d_cefc8740",
"filename": "specs/pike/support-rolling-upgrades.rst",
"patchSetId": 6
},
"lineNbr": 93,
"author": {
"id": 22406
},
"writtenOn": "2017-06-29T08:52:27Z",
"side": 1,
"message": "Oh, thanks for the explanation, I got it. The rolling upgrade from newton to ocata would make DB is inconsistency, because of adding new table. The old engines would not be able to get any data written by the new engine. Ocata to Pike would work fine (with the commit [2] - add a foreign key to resource table, relate with resource_properties_data table). Do I get it right?\n\nSo if we don\u0027t plan to add db changes like Ocata, everything will be fine when upgrading from Ocata to Pike.\n\nWhat should I write? Can you give me some recommendations? It\u0027ll be great!",
"parentUuid": "3f1d235d_fa6821bb",
"range": {
"startLine": 92,
"startChar": 0,
"endLine": 93,
"endChar": 77
},
"revId": "047472c9fd87bac6e5e4df99419ca8216b68bb65",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "3f1d235d_7ad1b157",
"filename": "specs/pike/support-rolling-upgrades.rst",
"patchSetId": 6
},
"lineNbr": 116,
"author": {
"id": 8833
},
"writtenOn": "2017-06-29T06:12:49Z",
"side": 1,
"message": "Implemented? I assume we would require a gate job for this. Last I looked at it, I could not find any reference (how other projects are doing it). May be we can have a kolla/ansible based gate job which would be easy.",
"range": {
"startLine": 116,
"startChar": 3,
"endLine": 116,
"endChar": 30
},
"revId": "047472c9fd87bac6e5e4df99419ca8216b68bb65",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "3f1d235d_c96241d9",
"filename": "specs/pike/support-rolling-upgrades.rst",
"patchSetId": 6
},
"lineNbr": 116,
"author": {
"id": 22406
},
"writtenOn": "2017-06-29T08:52:27Z",
"side": 1,
"message": "Yes, we have Grenade gate for Upgrade Gating. Depend on [1], I think it is enough to fill this with Implemented status.\n\nLike you say, having a Kolla/Ansible based gate job will be great. I am trying to find the way to do it, hope I can finish it ASAP. It can be the additional work. \n\n[1] https://github.com/openstack/development-proposals/blob/master/development-proposals/proposed/rolling-upgrades.rst",
"parentUuid": "3f1d235d_7ad1b157",
"range": {
"startLine": 116,
"startChar": 3,
"endLine": 116,
"endChar": 30
},
"revId": "047472c9fd87bac6e5e4df99419ca8216b68bb65",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "3f1d235d_29e1b5ff",
"filename": "specs/pike/support-rolling-upgrades.rst",
"patchSetId": 6
},
"lineNbr": 116,
"author": {
"id": 8833
},
"writtenOn": "2017-06-29T09:05:30Z",
"side": 1,
"message": "The current grenade job does not do rolling upgrade. It\u0027s not even a multi-node job. I assume this is one of the requirements[1] (read the last bullet), we would need to test it in the gate before even applying for the tag, unless TC is lenient about it. \n\n[1] https://governance.openstack.org/tc/reference/tags/assert_supports-rolling-upgrade.html#requirements",
"parentUuid": "3f1d235d_c96241d9",
"range": {
"startLine": 116,
"startChar": 3,
"endLine": 116,
"endChar": 30
},
"revId": "047472c9fd87bac6e5e4df99419ca8216b68bb65",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "3f1d235d_5bff1467",
"filename": "specs/pike/support-rolling-upgrades.rst",
"patchSetId": 6
},
"lineNbr": 116,
"author": {
"id": 22406
},
"writtenOn": "2017-06-29T09:28:30Z",
"side": 1,
"message": "I got it. I know a patch set about this job [1]\n\nAbout the Kolla based gate job, I will ask my colleague for more information. He is Kolla core reviewer.\n\n[1] https://review.openstack.org/#/c/449295/",
"parentUuid": "3f1d235d_29e1b5ff",
"range": {
"startLine": 116,
"startChar": 3,
"endLine": 116,
"endChar": 30
},
"revId": "047472c9fd87bac6e5e4df99419ca8216b68bb65",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
}
]
}
View Git Blame Copy Permalink