)]}'
{"specs/kilo/approved/detach-service-from-computenode.rst":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e6582bdd362e36f63ccb56e8457b72ef25ebb989","unresolved":false,"context_lines":[{"line_number":42,"context_line":"of adding a new field called \u0027host\u0027 for compute_nodes and a unique constraint"},{"line_number":43,"context_line":"on (host, hypervisor_hostname). Also, service_id field will be removed from"},{"line_number":44,"context_line":"compute_nodes table and object, SQLA relationship on service will be deleted"},{"line_number":45,"context_line":"and Service object will no longer have a compute_node field."},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"REST API impact"},{"line_number":48,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"baa201ad_434d44c3","line":45,"updated":"2014-10-08 14:37:02.000000000","message":"You can\u0027t just remove those things from the object without bumping the major version (which I don\u0027t think we should do).\n\nThe id field can remain unused, so that would be my recommendation since I doubt it\u0027s actually used anywhere high up.\n\nThe .compute_node field needs to remain for older clients. Can we synthesize something there to satisfy their need, even though the strict relationship doesn\u0027t exist in the database?","commit_id":"c4988c9c658953d97f8abead0eed893493dbee4d"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"c43bf72594b3af03d7246e3bc56c7d404eeae288","unresolved":false,"context_lines":[{"line_number":42,"context_line":"of adding a new field called \u0027host\u0027 for compute_nodes and a unique constraint"},{"line_number":43,"context_line":"on (host, hypervisor_hostname). Also, service_id field will be removed from"},{"line_number":44,"context_line":"compute_nodes table and object, SQLA relationship on service will be deleted"},{"line_number":45,"context_line":"and Service object will no longer have a compute_node field."},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"Alternatives"},{"line_number":48,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baa201ad_526df3ca","line":45,"updated":"2014-10-09 09:32:31.000000000","message":"Sorry, I missed this one, can\u0027t the compute_node just be lazy loaded from the DB, so we don\u0027t need to bump the object major version?","commit_id":"8189af1f11125dbd1edff3e049af31fdc198097b"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"83fd4d505213940bc5f425e9c5bd9828a6cf6f46","unresolved":false,"context_lines":[{"line_number":42,"context_line":"of adding a new field called \u0027host\u0027 for compute_nodes and a unique constraint"},{"line_number":43,"context_line":"on (host, hypervisor_hostname). Also, service_id field will be removed from"},{"line_number":44,"context_line":"compute_nodes table and object, SQLA relationship on service will be deleted"},{"line_number":45,"context_line":"and Service object will no longer have a compute_node field."},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"Alternatives"},{"line_number":48,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baa201ad_90ccb48c","line":45,"in_reply_to":"baa201ad_526df3ca","updated":"2014-10-09 10:35:06.000000000","message":"Sorry, missed Dan\u0027s point on previous patchset, considering it for lazy-loading now","commit_id":"8189af1f11125dbd1edff3e049af31fdc198097b"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"cf5bed64f9cacadc7b3e85ffe35b149cbbf4b5db","unresolved":false,"context_lines":[{"line_number":60,"context_line":"DB migrations will ensure that :"},{"line_number":61,"context_line":""},{"line_number":62,"context_line":" - host will be populated at upgrade using Service.host table thanks to"},{"line_number":63,"context_line":"   existing service_id"},{"line_number":64,"context_line":""},{"line_number":65,"context_line":" - service_id will be populated at downgrade using host information that"},{"line_number":66,"context_line":"   matches Service.host"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baa201ad_0ed443ea","line":63,"updated":"2014-10-08 15:01:14.000000000","message":"So I think we really want to use an expand an contract idea here, to reduce downtime for this migration.\n\nCan\u0027t we just add the extra column, and get the objects to do the data update? Leave the drop until we get a contract mechanism in place?\n\nBut given how this data is updated, maybe just don\u0027t populate the new column, just do that on the next update?","commit_id":"8189af1f11125dbd1edff3e049af31fdc198097b"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"855f5bbcf772236d3af97e37267243389971e4c8","unresolved":false,"context_lines":[{"line_number":60,"context_line":"DB migrations will ensure that :"},{"line_number":61,"context_line":""},{"line_number":62,"context_line":" - host will be populated at upgrade using Service.host table thanks to"},{"line_number":63,"context_line":"   existing service_id"},{"line_number":64,"context_line":""},{"line_number":65,"context_line":" - service_id will be populated at downgrade using host information that"},{"line_number":66,"context_line":"   matches Service.host"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baa201ad_defae673","line":63,"in_reply_to":"baa201ad_0ed443ea","updated":"2014-10-08 16:15:39.000000000","message":"Well, I iterated over many patches when implementing this, and none of them had the Jenkins DB migration check (aka. formerly TurboHipster) complaining about long delays. See my patch series, you should find this as acceptable.\n\nI thought about it previously, and I think the migration cost is really small compared to the tech debt we could leave by creating a contract within the ComputeNode object (btw., RT still uses conductor for getting the nodes, not the object way)","commit_id":"8189af1f11125dbd1edff3e049af31fdc198097b"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"c43bf72594b3af03d7246e3bc56c7d404eeae288","unresolved":false,"context_lines":[{"line_number":60,"context_line":"DB migrations will ensure that :"},{"line_number":61,"context_line":""},{"line_number":62,"context_line":" - host will be populated at upgrade using Service.host table thanks to"},{"line_number":63,"context_line":"   existing service_id"},{"line_number":64,"context_line":""},{"line_number":65,"context_line":" - service_id will be populated at downgrade using host information that"},{"line_number":66,"context_line":"   matches Service.host"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baa201ad_b210df4e","line":63,"in_reply_to":"baa201ad_26a4c449","updated":"2014-10-09 09:32:31.000000000","message":"I guess even without cells, they are not going to be too big. Cool.","commit_id":"8189af1f11125dbd1edff3e049af31fdc198097b"},{"author":{"_account_id":100,"name":"Johannes Erdfelt","email":"johannes@erdfelt.com","username":"johannes.erdfelt"},"change_message_id":"542158e602651f6a17b0db9bf999087cdfd0a98f","unresolved":false,"context_lines":[{"line_number":60,"context_line":"DB migrations will ensure that :"},{"line_number":61,"context_line":""},{"line_number":62,"context_line":" - host will be populated at upgrade using Service.host table thanks to"},{"line_number":63,"context_line":"   existing service_id"},{"line_number":64,"context_line":""},{"line_number":65,"context_line":" - service_id will be populated at downgrade using host information that"},{"line_number":66,"context_line":"   matches Service.host"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baa201ad_26a4c449","line":63,"in_reply_to":"baa201ad_defae673","updated":"2014-10-08 20:56:35.000000000","message":"The compute_nodes table for the largest deploys is likely only in the 4 digit range.\n\nFor instance, in our largest cell, adding/dropping a column only took .1 seconds.\n\nI don\u0027t think we need to add that extra dependency to this spec.","commit_id":"8189af1f11125dbd1edff3e049af31fdc198097b"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"3af1fbc367c0bf03ae2417091941ee70ea2ddb78","unresolved":false,"context_lines":[{"line_number":61,"context_line":"DB migrations will ensure that :"},{"line_number":62,"context_line":""},{"line_number":63,"context_line":" - host will be populated at upgrade using Service.host table thanks to"},{"line_number":64,"context_line":"   existing service_id"},{"line_number":65,"context_line":""},{"line_number":66,"context_line":" - service_id will be populated at downgrade using host information that"},{"line_number":67,"context_line":"   matches Service.host"}],"source_content_type":"text/x-rst","patch_set":3,"id":"baa201ad_4be22b02","line":64,"updated":"2014-10-14 15:06:36.000000000","message":"So the DB migration is going to replace the id field with a hostname? Why is that better? Can you show the code for the actual migration?","commit_id":"db713c34d87c6f94639b223e5d5960042a644ff8"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"ca5b99797effd42a08abb4025a5231c3d0c7bb3a","unresolved":false,"context_lines":[{"line_number":61,"context_line":"DB migrations will ensure that :"},{"line_number":62,"context_line":""},{"line_number":63,"context_line":" - host will be populated at upgrade using Service.host table thanks to"},{"line_number":64,"context_line":"   existing service_id"},{"line_number":65,"context_line":""},{"line_number":66,"context_line":" - service_id will be populated at downgrade using host information that"},{"line_number":67,"context_line":"   matches Service.host"}],"source_content_type":"text/x-rst","patch_set":3,"id":"baa201ad_b1b3ef4b","line":64,"in_reply_to":"baa201ad_4be22b02","updated":"2014-10-15 07:54:13.000000000","message":"Well, in the problem description, I stated that we need to keep a (host, node) tuple for mentioning a node. In compute_nodes, that tuple was actually (service_id, node) but there was no unique index on that, and it required a FK on service.id for ensuring consistency.\n\nHere, we propose to remove that service_id which actually creates confusion by a host field which is the nova-compute service hostname. I don\u0027t think it\u0027s bikeshedding, but cleans up a dependency which was not necessary.\n\nSee https://review.openstack.org/126372 for the implementation (this BP is having a patch series)","commit_id":"db713c34d87c6f94639b223e5d5960042a644ff8"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"3af1fbc367c0bf03ae2417091941ee70ea2ddb78","unresolved":false,"context_lines":[{"line_number":67,"context_line":"   matches Service.host"},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"When implementing these migrations, TurboHipster (aka. DB DataSets migration"},{"line_number":70,"context_line":"check) showed no problems with these upgrade and downgrade paths in terms of "},{"line_number":71,"context_line":"delay."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"REST API impact"}],"source_content_type":"text/x-rst","patch_set":3,"id":"baa201ad_cbd61b27","line":70,"updated":"2014-10-14 15:06:36.000000000","message":"Whitespace :)","commit_id":"db713c34d87c6f94639b223e5d5960042a644ff8"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"ca5b99797effd42a08abb4025a5231c3d0c7bb3a","unresolved":false,"context_lines":[{"line_number":67,"context_line":"   matches Service.host"},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"When implementing these migrations, TurboHipster (aka. DB DataSets migration"},{"line_number":70,"context_line":"check) showed no problems with these upgrade and downgrade paths in terms of "},{"line_number":71,"context_line":"delay."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"REST API impact"}],"source_content_type":"text/x-rst","patch_set":3,"id":"baa201ad_f1881773","line":70,"in_reply_to":"baa201ad_cbd61b27","updated":"2014-10-15 07:54:13.000000000","message":"Argh.","commit_id":"db713c34d87c6f94639b223e5d5960042a644ff8"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"3af1fbc367c0bf03ae2417091941ee70ea2ddb78","unresolved":false,"context_lines":[{"line_number":69,"context_line":"When implementing these migrations, TurboHipster (aka. DB DataSets migration"},{"line_number":70,"context_line":"check) showed no problems with these upgrade and downgrade paths in terms of "},{"line_number":71,"context_line":"delay."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"REST API impact"},{"line_number":74,"context_line":"---------------"},{"line_number":75,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"baa201ad_6b760f40","line":72,"updated":"2014-10-14 15:06:36.000000000","message":"Presumably there will be more details about the object model impact here, as well as what you\u0027re planning to do to avoid breaking Juno clients?","commit_id":"db713c34d87c6f94639b223e5d5960042a644ff8"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"ca5b99797effd42a08abb4025a5231c3d0c7bb3a","unresolved":false,"context_lines":[{"line_number":69,"context_line":"When implementing these migrations, TurboHipster (aka. DB DataSets migration"},{"line_number":70,"context_line":"check) showed no problems with these upgrade and downgrade paths in terms of "},{"line_number":71,"context_line":"delay."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"REST API impact"},{"line_number":74,"context_line":"---------------"},{"line_number":75,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"baa201ad_317fff67","line":72,"in_reply_to":"baa201ad_6b760f40","updated":"2014-10-15 07:54:13.000000000","message":"Sure, can put more details there","commit_id":"db713c34d87c6f94639b223e5d5960042a644ff8"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"3af1fbc367c0bf03ae2417091941ee70ea2ddb78","unresolved":false,"context_lines":[{"line_number":76,"context_line":"In order to preserve API stability, we will still provide service information"},{"line_number":77,"context_line":"when querying compute nodes but this extra information will be on a"},{"line_number":78,"context_line":"case-by-case basis thanks to an extra flag passed to the DB API asking to join"},{"line_number":79,"context_line":"service and compute_nodes tables on service.host \u003d\u003d compute_nodes.host"},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"No changes in the API model."},{"line_number":82,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"baa201ad_aba1d7aa","line":79,"updated":"2014-10-14 15:06:36.000000000","message":"Won\u0027t that be slow? Doing a string compare instead of an integer? As above, I\u0027m not sure what we\u0027ve gained by moving to the string (although I\u0027m sure I\u0027m missing something).","commit_id":"db713c34d87c6f94639b223e5d5960042a644ff8"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"ca5b99797effd42a08abb4025a5231c3d0c7bb3a","unresolved":false,"context_lines":[{"line_number":76,"context_line":"In order to preserve API stability, we will still provide service information"},{"line_number":77,"context_line":"when querying compute nodes but this extra information will be on a"},{"line_number":78,"context_line":"case-by-case basis thanks to an extra flag passed to the DB API asking to join"},{"line_number":79,"context_line":"service and compute_nodes tables on service.host \u003d\u003d compute_nodes.host"},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"No changes in the API model."},{"line_number":82,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"baa201ad_51c5638c","line":79,"in_reply_to":"baa201ad_aba1d7aa","updated":"2014-10-15 07:54:13.000000000","message":"This API endpoint is admin-only and the comparison is limited by a VARCHAR(255) compared to an INTEGER. There is no clear penalty to me. See also above for the explanation why moving to a string instead of an ID.","commit_id":"db713c34d87c6f94639b223e5d5960042a644ff8"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"3af1fbc367c0bf03ae2417091941ee70ea2ddb78","unresolved":false,"context_lines":[{"line_number":132,"context_line":"* Make service info optional when querying compute nodes"},{"line_number":133,"context_line":"* Remove query by service_id on compute_nodes"},{"line_number":134,"context_line":"* Modify calls for getting service info instead of looking at the compute"},{"line_number":135,"context_line":"  object directly"},{"line_number":136,"context_line":"* Remove service_id field from compute_nodes and service relationship"},{"line_number":137,"context_line":""},{"line_number":138,"context_line":"Dependencies"}],"source_content_type":"text/x-rst","patch_set":3,"id":"baa201ad_0baf4395","line":135,"updated":"2014-10-14 15:06:36.000000000","message":"Hmm, I don\u0027t think I understand this work item. Can you explain?","commit_id":"db713c34d87c6f94639b223e5d5960042a644ff8"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"ca5b99797effd42a08abb4025a5231c3d0c7bb3a","unresolved":false,"context_lines":[{"line_number":132,"context_line":"* Make service info optional when querying compute nodes"},{"line_number":133,"context_line":"* Remove query by service_id on compute_nodes"},{"line_number":134,"context_line":"* Modify calls for getting service info instead of looking at the compute"},{"line_number":135,"context_line":"  object directly"},{"line_number":136,"context_line":"* Remove service_id field from compute_nodes and service relationship"},{"line_number":137,"context_line":""},{"line_number":138,"context_line":"Dependencies"}],"source_content_type":"text/x-rst","patch_set":3,"id":"baa201ad_71c26786","line":135,"in_reply_to":"baa201ad_0baf4395","updated":"2014-10-15 07:54:13.000000000","message":"Will rewrite it","commit_id":"db713c34d87c6f94639b223e5d5960042a644ff8"},{"author":{"_account_id":1849,"name":"Joe Gordon","email":"joe.gordon0@gmail.com","username":"jogo"},"change_message_id":"099350e7af64d9ac8885f13df34301ae34df1851","unresolved":false,"context_lines":[{"line_number":16,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":17,"context_line":""},{"line_number":18,"context_line":"There is no good reason to keep a dependency in between a service, which is the"},{"line_number":19,"context_line":"representation of the message bus and a compute_node, which is a collection of"},{"line_number":20,"context_line":"resources for the solely use of the scheduler. It also creates a dependency"},{"line_number":21,"context_line":"in the internals of the Scheduler, while it is useless for it."},{"line_number":22,"context_line":"The only reason why such a dependency exists is because there is a 1:N"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9aa7fdbe_4b28069a","line":19,"updated":"2014-10-27 21:36:07.000000000","message":"I am having trouble figuring out what the problem is based on this description. After reading the bug report I think I have a clearer picture, but this section needs some work.\n\n\n\n\n\"The fact that they are related to each other means that the resource tracker ends up needing to \"find\" its compute node record by first looking up the service record for the \u0027compute\u0027 topic and the host for the resource tracker, and then grabs the first compute_node record that is related to the service record that matches that query. There is no reason to do this in the resource tracker ... other than the fact that right now the compute_node table has a service_id field and a relation to the services table. But this relationship is contrived and is not needed AFAICT.\"\nhttps://bugs.launchpad.net/nova/+bug/1357491\n\nSo this blueprint is about cleaning up things related to the resource tracker then.","commit_id":"db1d51caa4a0ac825d45bbd6a849b433db38d926"},{"author":{"_account_id":4573,"name":"yunhong-jiang","email":"yunhong.jiang@intel.com","username":"yunhong-jiang"},"change_message_id":"f728fde88cde2b65b9e5c8ddd90337ac47b09154","unresolved":false,"context_lines":[{"line_number":16,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":17,"context_line":""},{"line_number":18,"context_line":"There is no good reason to keep a dependency in between a service, which is the"},{"line_number":19,"context_line":"representation of the message bus and a compute_node, which is a collection of"},{"line_number":20,"context_line":"resources for the solely use of the scheduler. It also creates a dependency"},{"line_number":21,"context_line":"in the internals of the Scheduler, while it is useless for it."},{"line_number":22,"context_line":"The only reason why such a dependency exists is because there is a 1:N"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a890539_983126a5","line":19,"in_reply_to":"5a890539_80d1bbcf","updated":"2014-11-10 17:52:36.000000000","message":"Hi, Bauza, thanks for raising the difference of \u0027service\u0027 and \u0027host\u0027 and it\u0027s an interesting point of view. But I really can\u0027t understand that a compute node will have a relationship with the host. Take XenAPI as example, the compute service runs in a virtual machine, and the \u0027host\u0027, IIUC, is in fact the *virtual machine* running the compute service. Do you think the compute nodes has any relationship with the *host/virtual machine* ?\n\nIMHO, The compute nodes are attached to the corresponding compute manager, instead of the host, with 1:N relationship. And the relationship of the compute nodes and compute manager is resource/resource manager. The relationship of \u0027service\u0027 and \u0027manager\u0027 in Nova is vague and we can usually think they are same.","commit_id":"db1d51caa4a0ac825d45bbd6a849b433db38d926"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"643c0e5f296dec079b2d4e3f4ef70d2318d6ac88","unresolved":false,"context_lines":[{"line_number":16,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":17,"context_line":""},{"line_number":18,"context_line":"There is no good reason to keep a dependency in between a service, which is the"},{"line_number":19,"context_line":"representation of the message bus and a compute_node, which is a collection of"},{"line_number":20,"context_line":"resources for the solely use of the scheduler. It also creates a dependency"},{"line_number":21,"context_line":"in the internals of the Scheduler, while it is useless for it."},{"line_number":22,"context_line":"The only reason why such a dependency exists is because there is a 1:N"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a890539_80d1bbcf","line":19,"in_reply_to":"7a8c0949_9247ea4a","updated":"2014-11-10 10:26:01.000000000","message":"Yunhong, I think you made a confusion in between the notion of \"service\" and the notion of \"host\".\n\nAs it was explained in the bugfile previously, the service is purely a software notion, where it means that the RPC manager is up-and-ready. On the other hand, we have compute *nodes* which are attached in a one-to-many relationship to a physical *host*. I agree with the fact that a service is mapped to only one host, so the 1:N relationship can also be service-to-nodes but it makes no sense from a conceptual logic : what we call resources are related to what we can consume or meter : a service is not this of this kind, compared to an host.","commit_id":"db1d51caa4a0ac825d45bbd6a849b433db38d926"},{"author":{"_account_id":4573,"name":"yunhong-jiang","email":"yunhong.jiang@intel.com","username":"yunhong-jiang"},"change_message_id":"4682a65861621804851471060fa22e750cbc3166","unresolved":false,"context_lines":[{"line_number":16,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":17,"context_line":""},{"line_number":18,"context_line":"There is no good reason to keep a dependency in between a service, which is the"},{"line_number":19,"context_line":"representation of the message bus and a compute_node, which is a collection of"},{"line_number":20,"context_line":"resources for the solely use of the scheduler. It also creates a dependency"},{"line_number":21,"context_line":"in the internals of the Scheduler, while it is useless for it."},{"line_number":22,"context_line":"The only reason why such a dependency exists is because there is a 1:N"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7a8c0949_9247ea4a","line":19,"in_reply_to":"9aa7fdbe_4b28069a","updated":"2014-11-07 00:34:26.000000000","message":"I totally agree that we don\u0027t need do as current resource tracker, but I\u0027m not sure if this is related to the Service/ComputeNode relationship and if we should go further to remove that relationship. From history, I think it\u0027s because  changeset 885cf094 does not change the resource_tracker code cleanly. That changeset should instead add db api to fetch compute_node based on host/nodename.\n\nI think the compute node *DO* depends on the service. The logic is, one service with \u0027compute\u0027 topic manages multiple compute nodes and spawn/destroy/resize the instances running on these compute nodes. The FK and the dependency is an envision of such 1:N relationship. For example, if a compute service is dead, all the corresponding compute nodes should be invalid immediately, or, soon with the final consistent model. For example, if the service is deleted, when resource tracker want to update the compute_node with new information, the foreign key will make sure the update fail, however, with this spec, the update will success, that means the compute node will continue update even though the compute service is dead. That\u0027s not good IMHO. \n\nTaken the compute node as a \u0027resources for the solely use of scheduler\u0027 is because of the 1:N mapping, and the whole architect confusion caused by the 1:N mapping!\n\nTo clean the code in resource tracker, I\u0027d suggest to add API to the compute_node object to get a compute_node based on host/hypervisor_hostname. In fact, it\u0027s really strange and bogus that with the 1:N mapping, we are using the get_by_service_id() to get compute_node, instead of compute_node_list, and we have db.compute_node_get_by_service_idO() instead of compute_node*S*_get_by_service_id(). This\u0027s another example of the chaos of the 1:N mapping. \n\nI have a patch at https://review.openstack.org/#/c/103759/ adding API to fetch compute node based on host/hypervisor_hostname, although I\u0027m not selling my patch :)","commit_id":"db1d51caa4a0ac825d45bbd6a849b433db38d926"},{"author":{"_account_id":1849,"name":"Joe Gordon","email":"joe.gordon0@gmail.com","username":"jogo"},"change_message_id":"099350e7af64d9ac8885f13df34301ae34df1851","unresolved":false,"context_lines":[{"line_number":27,"context_line":"Use Cases"},{"line_number":28,"context_line":"---------"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"N/A"},{"line_number":31,"context_line":""},{"line_number":32,"context_line":"Project Priority"},{"line_number":33,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9aa7fdbe_2ba2e24a","line":30,"updated":"2014-10-27 21:36:07.000000000","message":"Developers are people too. The user in this use case should be the developers.","commit_id":"db1d51caa4a0ac825d45bbd6a849b433db38d926"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"643c0e5f296dec079b2d4e3f4ef70d2318d6ac88","unresolved":false,"context_lines":[{"line_number":27,"context_line":"Use Cases"},{"line_number":28,"context_line":"---------"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"N/A"},{"line_number":31,"context_line":""},{"line_number":32,"context_line":"Project Priority"},{"line_number":33,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a890539_e0feff37","line":30,"in_reply_to":"9aa7fdbe_2ba2e24a","updated":"2014-11-10 10:26:01.000000000","message":"Ack. Will provide a short mention of what I consider as an use-case for developers.","commit_id":"db1d51caa4a0ac825d45bbd6a849b433db38d926"},{"author":{"_account_id":1849,"name":"Joe Gordon","email":"joe.gordon0@gmail.com","username":"jogo"},"change_message_id":"099350e7af64d9ac8885f13df34301ae34df1851","unresolved":false,"context_lines":[{"line_number":33,"context_line":"----------------"},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"This work is related to the effort of reducing technical debt."},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"Proposed change"},{"line_number":38,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":39,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"9aa7fdbe_6b006a34","line":36,"updated":"2014-10-27 21:36:07.000000000","message":"I agree this would fit under technical debt. As of now we don\u0027t have any defined priorities. So the phrasing here should reflect that. \n\n  No priorities are defined, but this would fit under the effort to reduce technical debt.","commit_id":"db1d51caa4a0ac825d45bbd6a849b433db38d926"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"643c0e5f296dec079b2d4e3f4ef70d2318d6ac88","unresolved":false,"context_lines":[{"line_number":33,"context_line":"----------------"},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"This work is related to the effort of reducing technical debt."},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"Proposed change"},{"line_number":38,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":39,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a890539_609a0f16","line":36,"in_reply_to":"9aa7fdbe_6b006a34","updated":"2014-11-10 10:26:01.000000000","message":"Will mention the \u0027scheduler\u0027 priority as it\u0027s now defined.","commit_id":"db1d51caa4a0ac825d45bbd6a849b433db38d926"},{"author":{"_account_id":6062,"name":"jichenjc","email":"jichenjc@cn.ibm.com","username":"jichenjc"},"change_message_id":"b5dabb5db229221a752cf7b1d4c5e0251debbffb","unresolved":false,"context_lines":[{"line_number":59,"context_line":"to Service.host field)."},{"line_number":60,"context_line":"DB migrations will ensure that :"},{"line_number":61,"context_line":""},{"line_number":62,"context_line":" - host will be populated at upgrade using Service.host table thanks to"},{"line_number":63,"context_line":"   existing service_id and a unique key will be set on"},{"line_number":64,"context_line":"   (host, hypervisor_hostname)"},{"line_number":65,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"9aa7fdbe_0d752963","line":62,"updated":"2014-10-28 09:02:09.000000000","message":"table -\u003e field","commit_id":"db1d51caa4a0ac825d45bbd6a849b433db38d926"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"643c0e5f296dec079b2d4e3f4ef70d2318d6ac88","unresolved":false,"context_lines":[{"line_number":59,"context_line":"to Service.host field)."},{"line_number":60,"context_line":"DB migrations will ensure that :"},{"line_number":61,"context_line":""},{"line_number":62,"context_line":" - host will be populated at upgrade using Service.host table thanks to"},{"line_number":63,"context_line":"   existing service_id and a unique key will be set on"},{"line_number":64,"context_line":"   (host, hypervisor_hostname)"},{"line_number":65,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a890539_c08823c9","line":62,"in_reply_to":"9aa7fdbe_0d752963","updated":"2014-11-10 10:26:01.000000000","message":"Done","commit_id":"db1d51caa4a0ac825d45bbd6a849b433db38d926"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"eb9bfeedfe49e5a4adf2fec37fc2f1b8fa5ec64e","unresolved":false,"context_lines":[{"line_number":43,"context_line":"----------------"},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"This blueprint is part of the \u0027scheduler\u0027 refactoring effort, defined as a 3rd"},{"line_number":46,"context_line":"priority for the Kilo release."},{"line_number":47,"context_line":""},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5a890539_b869c7fa","line":46,"updated":"2014-11-17 17:29:37.000000000","message":"technically thats not a strict order, but we can fix this up later.","commit_id":"f9f90c67706fd8fb6b90021b98669491ace0c6d6"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"45c886b04271cc163bb0638e36d758aec77c8bc8","unresolved":false,"context_lines":[{"line_number":43,"context_line":"----------------"},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"This blueprint is part of the \u0027scheduler\u0027 refactoring effort, defined as a 3rd"},{"line_number":46,"context_line":"priority for the Kilo release."},{"line_number":47,"context_line":""},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5a890539_47fd49b0","line":46,"in_reply_to":"5a890539_b869c7fa","updated":"2014-11-18 10:14:45.000000000","message":"Ack, will amend this a bit.","commit_id":"f9f90c67706fd8fb6b90021b98669491ace0c6d6"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"eb9bfeedfe49e5a4adf2fec37fc2f1b8fa5ec64e","unresolved":false,"context_lines":[{"line_number":76,"context_line":"   (host, hypervisor_hostname)"},{"line_number":77,"context_line":""},{"line_number":78,"context_line":" - service_id will be populated at downgrade using host information that"},{"line_number":79,"context_line":"   matches Service.host"},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"There is no sense to keep a specific ID while the tuple (host, node) is"},{"line_number":82,"context_line":"identified as the source of truth for idenfifying compute nodes."}],"source_content_type":"text/x-rst","patch_set":6,"id":"5a890539_b81e276e","line":79,"updated":"2014-11-17 17:29:37.000000000","message":"I think we agreed no more data migrations during kilo, so we need to do this in objects :(","commit_id":"f9f90c67706fd8fb6b90021b98669491ace0c6d6"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"45c886b04271cc163bb0638e36d758aec77c8bc8","unresolved":false,"context_lines":[{"line_number":76,"context_line":"   (host, hypervisor_hostname)"},{"line_number":77,"context_line":""},{"line_number":78,"context_line":" - service_id will be populated at downgrade using host information that"},{"line_number":79,"context_line":"   matches Service.host"},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"There is no sense to keep a specific ID while the tuple (host, node) is"},{"line_number":82,"context_line":"identified as the source of truth for idenfifying compute nodes."}],"source_content_type":"text/x-rst","patch_set":6,"id":"5a890539_e7fb95be","line":79,"in_reply_to":"5a890539_b111cf5e","updated":"2014-11-18 10:14:45.000000000","message":"Ad discussed per IRC, I agree with you, will update the spec by saying that service_id will be updated thanks to the ComputeNode object itself","commit_id":"f9f90c67706fd8fb6b90021b98669491ace0c6d6"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"241355ae728437c41b896c91d394220d7889720c","unresolved":false,"context_lines":[{"line_number":76,"context_line":"   (host, hypervisor_hostname)"},{"line_number":77,"context_line":""},{"line_number":78,"context_line":" - service_id will be populated at downgrade using host information that"},{"line_number":79,"context_line":"   matches Service.host"},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"There is no sense to keep a specific ID while the tuple (host, node) is"},{"line_number":82,"context_line":"identified as the source of truth for idenfifying compute nodes."}],"source_content_type":"text/x-rst","patch_set":6,"id":"5a890539_b111cf5e","line":79,"in_reply_to":"5a890539_b19e3db7","updated":"2014-11-18 09:32:52.000000000","message":"Sorry, I thought the data migration plan was well known now, but clearly we hadn\u0027t actually got consensus on that.\n\nThe first example of the objects doing data migrations is here:\nhttp://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/flavor-from-sysmeta-to-blob.html#other-deployer-impact\n\nIts because live upgrades is a priority, we can\u0027t do any data migrations in kilo. We can do schema migrations, thats fine.","commit_id":"f9f90c67706fd8fb6b90021b98669491ace0c6d6"},{"author":{"_account_id":100,"name":"Johannes Erdfelt","email":"johannes@erdfelt.com","username":"johannes.erdfelt"},"change_message_id":"cdfe1307e0cc039b66627b24ddfa6db736f61cfa","unresolved":false,"context_lines":[{"line_number":76,"context_line":"   (host, hypervisor_hostname)"},{"line_number":77,"context_line":""},{"line_number":78,"context_line":" - service_id will be populated at downgrade using host information that"},{"line_number":79,"context_line":"   matches Service.host"},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"There is no sense to keep a specific ID while the tuple (host, node) is"},{"line_number":82,"context_line":"identified as the source of truth for idenfifying compute nodes."}],"source_content_type":"text/x-rst","patch_set":6,"id":"5a890539_b19e3db7","line":79,"in_reply_to":"5a890539_b61b937f","updated":"2014-11-17 21:24:34.000000000","message":"FWIW, my work is on online schema migrations, not data migrations. I\u0027m not as familiar with the work on data migrations, but IIRC the high level idea is to have the object code migrate data on read.","commit_id":"f9f90c67706fd8fb6b90021b98669491ace0c6d6"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"ddd907889ba80076814118cdb63ffa6b9ae30682","unresolved":false,"context_lines":[{"line_number":76,"context_line":"   (host, hypervisor_hostname)"},{"line_number":77,"context_line":""},{"line_number":78,"context_line":" - service_id will be populated at downgrade using host information that"},{"line_number":79,"context_line":"   matches Service.host"},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"There is no sense to keep a specific ID while the tuple (host, node) is"},{"line_number":82,"context_line":"identified as the source of truth for idenfifying compute nodes."}],"source_content_type":"text/x-rst","patch_set":6,"id":"5a890539_b61b937f","line":79,"in_reply_to":"5a890539_b81e276e","updated":"2014-11-17 21:20:56.000000000","message":"Seriously ?! Do you have some pointer to give me for having more context ?\nI guess this is related to Johannes\u0027s work on online data migrations, but I need to understand what\u0027s acceptable and what\u0027s not.","commit_id":"f9f90c67706fd8fb6b90021b98669491ace0c6d6"}]}