)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"05753ca9af222b6227517cc14af27f1e1492b993","unresolved":false,"context_lines":[{"line_number":6,"context_line":""},{"line_number":7,"context_line":"Add no-db-scheduler spec"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Change-Id: Ib9fb944323fce66eb15eeb3feeb5ffa83b7c481e"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"9ad9bd40_510c60ed","line":9,"updated":"2014-05-06 15:27:49.000000000","message":"Please reference the blueprint here to get the nice link to this change.","commit_id":"ea2233eda768e94b19fe777bbe7381006e8fa0a7"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"0406bdc86d503f3dee8f6b8ec41ece6560b4b6c3","unresolved":false,"context_lines":[{"line_number":6,"context_line":""},{"line_number":7,"context_line":"Add no-db-scheduler spec"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Change-Id: Ib9fb944323fce66eb15eeb3feeb5ffa83b7c481e"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"3ae8d1ca_be48785c","line":9,"in_reply_to":"9ad9bd40_510c60ed","updated":"2014-05-28 13:27:21.000000000","message":"please also set the correct topic name for Gerrit","commit_id":"ea2233eda768e94b19fe777bbe7381006e8fa0a7"}],"specs/juno/no-db-scheduler.rst":[{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"1cc8612bef49bc5dd6409ce826573927c4d98461","unresolved":false,"context_lines":[{"line_number":14,"context_line":"scheduler in Nova:"},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"* New features that impact scheduling have to either store their data in one"},{"line_number":17,"context_line":"  Text column (compute_nodes.stats) or add new colums to compute_node table"},{"line_number":18,"context_line":"  itself (which requires new migrations). This limits opportunities for"},{"line_number":19,"context_line":"  cross-project scheduling as it makes scheduler bound to DB schema."},{"line_number":20,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"3ae8d1ca_8de4780e","line":17,"updated":"2014-05-28 13:25:46.000000000","message":"nit : compute_nodes (with \u0027s\u0027), columNs","commit_id":"ea2233eda768e94b19fe777bbe7381006e8fa0a7"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"1cc8612bef49bc5dd6409ce826573927c4d98461","unresolved":false,"context_lines":[{"line_number":16,"context_line":"* New features that impact scheduling have to either store their data in one"},{"line_number":17,"context_line":"  Text column (compute_nodes.stats) or add new colums to compute_node table"},{"line_number":18,"context_line":"  itself (which requires new migrations). This limits opportunities for"},{"line_number":19,"context_line":"  cross-project scheduling as it makes scheduler bound to DB schema."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"* Current implementation uses one big request to DB to retrieve all data about"},{"line_number":22,"context_line":"  compute nodes that resides there. These requests becomes a performance"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3ae8d1ca_ed609c37","line":19,"updated":"2014-05-28 13:25:46.000000000","message":"Well, you don\u0027t mention either bp/extensible-resource-tracking or bp/utilization-aware-scheduling which allow to decouple DB schema and objects to store.\n\nAll this concern doesn\u0027t necessarly require to store in other way than SQL, we can imagine (as you mention) an extra big JSON field in DB.","commit_id":"ea2233eda768e94b19fe777bbe7381006e8fa0a7"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"1cc8612bef49bc5dd6409ce826573927c4d98461","unresolved":false,"context_lines":[{"line_number":20,"context_line":""},{"line_number":21,"context_line":"* Current implementation uses one big request to DB to retrieve all data about"},{"line_number":22,"context_line":"  compute nodes that resides there. These requests becomes a performance"},{"line_number":23,"context_line":"  bottleneck in large enough deployments."},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"Problem description"},{"line_number":26,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3ae8d1ca_8dd8f8f0","line":23,"updated":"2014-05-28 13:25:46.000000000","message":"IMHO, this motivation is the only one for the no-db rationale","commit_id":"ea2233eda768e94b19fe777bbe7381006e8fa0a7"},{"author":{"_account_id":5441,"name":"Andrew Laski","email":"andrew@lascii.com","username":"alaski"},"change_message_id":"b20f3664bf27c3a5d100646f9313b857b7e7874d","unresolved":false,"context_lines":[{"line_number":20,"context_line":""},{"line_number":21,"context_line":"* Current implementation uses one big request to DB to retrieve all data about"},{"line_number":22,"context_line":"  compute nodes that resides there. These requests becomes a performance"},{"line_number":23,"context_line":"  bottleneck in large enough deployments."},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"Problem description"},{"line_number":26,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3ae8d1ca_bed4c320","line":23,"in_reply_to":"3ae8d1ca_8dd8f8f0","updated":"2014-05-29 18:31:08.000000000","message":"I agree with Sylvain.  And this is somewhat alleviated by the caching scheduler that\u0027s in the tree, though it has some other issues it needs to work out.","commit_id":"ea2233eda768e94b19fe777bbe7381006e8fa0a7"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"1cc8612bef49bc5dd6409ce826573927c4d98461","unresolved":false,"context_lines":[{"line_number":28,"context_line":"Currently DB is used for scheduler in these steps:"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"* once in a minute (by default) every compute node updates its state in"},{"line_number":31,"context_line":"  database in compute_nodes tables in on JSON blob;"},{"line_number":32,"context_line":"* every time a new instance is to be scheduled, DB is queried for all existing"},{"line_number":33,"context_line":"  nodes and all their parameters;"},{"line_number":34,"context_line":"* after that scheduler selects appropriate host for a VM from aquired list."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3ae8d1ca_2dde0440","line":31,"updated":"2014-05-28 13:25:46.000000000","message":"nit : compute_nodes table (without \u0027s\u0027) \n\nnit : s/in on/with a/ JSON blob","commit_id":"ea2233eda768e94b19fe777bbe7381006e8fa0a7"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"1cc8612bef49bc5dd6409ce826573927c4d98461","unresolved":false,"context_lines":[{"line_number":32,"context_line":"* every time a new instance is to be scheduled, DB is queried for all existing"},{"line_number":33,"context_line":"  nodes and all their parameters;"},{"line_number":34,"context_line":"* after that scheduler selects appropriate host for a VM from aquired list."},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"Flexibility of scheduler"},{"line_number":37,"context_line":"------------------------"},{"line_number":38,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"3ae8d1ca_6d772cd5","line":35,"updated":"2014-05-28 13:25:46.000000000","message":"there are also other objects which are accessed thru DB (aggregates, instance groups). Scheduler driver and manager are also using Nova states, etc. which are stored in DB. See bp/isolate-scheduler-db for it that\u0027s worth mentioning it","commit_id":"ea2233eda768e94b19fe777bbe7381006e8fa0a7"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"05753ca9af222b6227517cc14af27f1e1492b993","unresolved":false,"context_lines":[{"line_number":39,"context_line":"The main problem in direct storing of schedulling data in DB is limiting data"},{"line_number":40,"context_line":"available for scheduling to one project. For example, user might want to deploy"},{"line_number":41,"context_line":"VMs near existing Cinder volumes. This requires scheduler to hold information"},{"line_number":42,"context_line":"from different projects which is not possible with a single DB schema."},{"line_number":43,"context_line":""},{"line_number":44,"context_line":"Upcoming performance issues"},{"line_number":45,"context_line":"---------------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9ad9bd40_6e8183c2","line":42,"updated":"2014-05-06 15:27:49.000000000","message":"This is why we are creating Gantt project and splitting out the scheduler","commit_id":"ea2233eda768e94b19fe777bbe7381006e8fa0a7"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"1cc8612bef49bc5dd6409ce826573927c4d98461","unresolved":false,"context_lines":[{"line_number":39,"context_line":"The main problem in direct storing of schedulling data in DB is limiting data"},{"line_number":40,"context_line":"available for scheduling to one project. For example, user might want to deploy"},{"line_number":41,"context_line":"VMs near existing Cinder volumes. This requires scheduler to hold information"},{"line_number":42,"context_line":"from different projects which is not possible with a single DB schema."},{"line_number":43,"context_line":""},{"line_number":44,"context_line":"Upcoming performance issues"},{"line_number":45,"context_line":"---------------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3ae8d1ca_883e26b7","line":42,"in_reply_to":"9ad9bd40_6e8183c2","updated":"2014-05-28 13:25:46.000000000","message":"Indeed, scope of no-db sched doesn\u0027t have to include that","commit_id":"ea2233eda768e94b19fe777bbe7381006e8fa0a7"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"05753ca9af222b6227517cc14af27f1e1492b993","unresolved":false,"context_lines":[{"line_number":47,"context_line":"compute_nodes table is mainly being accessed from two places:"},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"* every compute node issues an UPDATE once every minute (by default);"},{"line_number":50,"context_line":"* scheduler does global SELECT for all records for every VM boot request."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"One problem is a heavy load on one table: for 10000 of compute nodes the first"},{"line_number":53,"context_line":"part alone would produce hundreds of UPDATE requests per second while the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9ad9bd40_4e675f4d","line":50,"updated":"2014-05-06 15:27:49.000000000","message":"This can now happen periodically, to reduce the load.","commit_id":"ea2233eda768e94b19fe777bbe7381006e8fa0a7"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"05753ca9af222b6227517cc14af27f1e1492b993","unresolved":false,"context_lines":[{"line_number":51,"context_line":""},{"line_number":52,"context_line":"One problem is a heavy load on one table: for 10000 of compute nodes the first"},{"line_number":53,"context_line":"part alone would produce hundreds of UPDATE requests per second while the"},{"line_number":54,"context_line":"second one would generate a lot of unnecessary DB-\u003ePython traffic."},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"Proposed change"},{"line_number":57,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9ad9bd40_6ecfc329","line":54,"updated":"2014-05-06 15:27:49.000000000","message":"you can turn down the frequency, but that creates other problems.","commit_id":"ea2233eda768e94b19fe777bbe7381006e8fa0a7"},{"author":{"_account_id":5441,"name":"Andrew Laski","email":"andrew@lascii.com","username":"alaski"},"change_message_id":"b20f3664bf27c3a5d100646f9313b857b7e7874d","unresolved":false,"context_lines":[{"line_number":51,"context_line":""},{"line_number":52,"context_line":"One problem is a heavy load on one table: for 10000 of compute nodes the first"},{"line_number":53,"context_line":"part alone would produce hundreds of UPDATE requests per second while the"},{"line_number":54,"context_line":"second one would generate a lot of unnecessary DB-\u003ePython traffic."},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"Proposed change"},{"line_number":57,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3ae8d1ca_7e04fbbf","line":54,"in_reply_to":"9ad9bd40_6ecfc329","updated":"2014-05-29 18:31:08.000000000","message":"Another solution to this particular issue would be to have updates only happen when there is actually a change on the compute node.  Or split these messages so that there\u0027s a small periodic heartbeat, an update when there\u0027s a change, and infrequently send a full update to help with consistency.\n\nI think that\u0027s a good change to make regardless, so I would like to know how this proposal would work with something like that.","commit_id":"ea2233eda768e94b19fe777bbe7381006e8fa0a7"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"1cc8612bef49bc5dd6409ce826573927c4d98461","unresolved":false,"context_lines":[{"line_number":52,"context_line":"One problem is a heavy load on one table: for 10000 of compute nodes the first"},{"line_number":53,"context_line":"part alone would produce hundreds of UPDATE requests per second while the"},{"line_number":54,"context_line":"second one would generate a lot of unnecessary DB-\u003ePython traffic."},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"Proposed change"},{"line_number":57,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":58,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"3ae8d1ca_2310d300","line":55,"updated":"2014-05-28 13:25:46.000000000","message":"Performance tuning can be improved thanks to deployment options like Galera, HAProxy or MEMORY engines for Slaves. The real problem with performance comes with INSERT/UPDATE, not SELECT, so the effort should port on how to produce stats to the scheduler, not how to access them.","commit_id":"ea2233eda768e94b19fe777bbe7381006e8fa0a7"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"05753ca9af222b6227517cc14af27f1e1492b993","unresolved":false,"context_lines":[{"line_number":61,"context_line":"1. use schedulers\u0027 memory as a primary storage for scheduling-related"},{"line_number":62,"context_line":"   parameters and synchronize them through external backend;"},{"line_number":63,"context_line":"2. abstract out pushing data to scheduler to one RCP call which in future can"},{"line_number":64,"context_line":"   be called from different projects;"},{"line_number":65,"context_line":"3. store all data required for scheduling in one JSON for each node (avoid"},{"line_number":66,"context_line":"   limiting the data that can be used by DB schema) - mostly done by"},{"line_number":67,"context_line":"   https://blueprints.launchpad.net/nova/+spec/compute-node-stats-as-resource-tracker-extension"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9ad9bd40_2e977bed","line":64,"updated":"2014-05-06 15:27:49.000000000","message":"This is being done as part of the blueprint scheduler-lib :\nhttps://blueprints.launchpad.net/nova/+spec/scheduler-lib\n\nhow does this relate?","commit_id":"ea2233eda768e94b19fe777bbe7381006e8fa0a7"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"1cc8612bef49bc5dd6409ce826573927c4d98461","unresolved":false,"context_lines":[{"line_number":61,"context_line":"1. use schedulers\u0027 memory as a primary storage for scheduling-related"},{"line_number":62,"context_line":"   parameters and synchronize them through external backend;"},{"line_number":63,"context_line":"2. abstract out pushing data to scheduler to one RCP call which in future can"},{"line_number":64,"context_line":"   be called from different projects;"},{"line_number":65,"context_line":"3. store all data required for scheduling in one JSON for each node (avoid"},{"line_number":66,"context_line":"   limiting the data that can be used by DB schema) - mostly done by"},{"line_number":67,"context_line":"   https://blueprints.launchpad.net/nova/+spec/compute-node-stats-as-resource-tracker-extension"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3ae8d1ca_a30303b7","line":64,"in_reply_to":"9ad9bd40_2e977bed","updated":"2014-05-28 13:25:46.000000000","message":"Agreed, this has not to be part of the no-db scope","commit_id":"ea2233eda768e94b19fe777bbe7381006e8fa0a7"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"1cc8612bef49bc5dd6409ce826573927c4d98461","unresolved":false,"context_lines":[{"line_number":64,"context_line":"   be called from different projects;"},{"line_number":65,"context_line":"3. store all data required for scheduling in one JSON for each node (avoid"},{"line_number":66,"context_line":"   limiting the data that can be used by DB schema) - mostly done by"},{"line_number":67,"context_line":"   https://blueprints.launchpad.net/nova/+spec/compute-node-stats-as-resource-tracker-extension"},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"These steps provide the following benefits:"},{"line_number":70,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"3ae8d1ca_43b15ff7","line":67,"updated":"2014-05-28 13:25:46.000000000","message":"I think that this effort should be tackled elsewhere, and no-db should only focus on how to keep 1:1 matching with current DB impl.\n\nIf some efforts have to be done on which data to store (and its type), then no-db should have a dependency on it.","commit_id":"ea2233eda768e94b19fe777bbe7381006e8fa0a7"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"05753ca9af222b6227517cc14af27f1e1492b993","unresolved":false,"context_lines":[{"line_number":64,"context_line":"   be called from different projects;"},{"line_number":65,"context_line":"3. store all data required for scheduling in one JSON for each node (avoid"},{"line_number":66,"context_line":"   limiting the data that can be used by DB schema) - mostly done by"},{"line_number":67,"context_line":"   https://blueprints.launchpad.net/nova/+spec/compute-node-stats-as-resource-tracker-extension"},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"These steps provide the following benefits:"},{"line_number":70,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"9ad9bd40_eea7534e","line":67,"updated":"2014-05-06 15:27:49.000000000","message":"What more is to be done here?","commit_id":"ea2233eda768e94b19fe777bbe7381006e8fa0a7"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"1cc8612bef49bc5dd6409ce826573927c4d98461","unresolved":false,"context_lines":[{"line_number":71,"context_line":"1. With this step we avoid re-requesting data for all nodes for each scheduling"},{"line_number":72,"context_line":"   operation. Each host state is updated rather rare (once in a minute by"},{"line_number":73,"context_line":"   default) so there\u0027s no reason to fetch mostly-static data from DB. We should"},{"line_number":74,"context_line":"   fetch data for hosts that provided new data since our last request instead."},{"line_number":75,"context_line":"2. Using one single RPC call to scheduler instead of a number of direct DB"},{"line_number":76,"context_line":"   calls allows us to decouple scheduler from Nova and allow in future other"},{"line_number":77,"context_line":"   projects to send their data to one central scheduler."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3ae8d1ca_c3c1ef2f","line":74,"updated":"2014-05-28 13:25:46.000000000","message":"that should be managed by the memcache driver, not explicitely in the code so that it would be transparent to the scheduler.\n\nI mean, scheduler should access hostState thru an API, but depending on if DB or memcache, it would be a full query or an incremental one.","commit_id":"ea2233eda768e94b19fe777bbe7381006e8fa0a7"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"1cc8612bef49bc5dd6409ce826573927c4d98461","unresolved":false,"context_lines":[{"line_number":74,"context_line":"   fetch data for hosts that provided new data since our last request instead."},{"line_number":75,"context_line":"2. Using one single RPC call to scheduler instead of a number of direct DB"},{"line_number":76,"context_line":"   calls allows us to decouple scheduler from Nova and allow in future other"},{"line_number":77,"context_line":"   projects to send their data to one central scheduler."},{"line_number":78,"context_line":"3. The first part allows to store any strucrured data in schedulers so that"},{"line_number":79,"context_line":"   different projects can provide their data that can be used for scheduling"},{"line_number":80,"context_line":"   without need to provide any schema updates."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3ae8d1ca_e388ab24","line":77,"updated":"2014-05-28 13:25:46.000000000","message":"this should not be addressed here","commit_id":"ea2233eda768e94b19fe777bbe7381006e8fa0a7"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"1cc8612bef49bc5dd6409ce826573927c4d98461","unresolved":false,"context_lines":[{"line_number":89,"context_line":""},{"line_number":90,"context_line":"* Records"},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"  All data is stored in impersonal records consiting of ID and some JSON data."},{"line_number":93,"context_line":"  In our case one record represents current state of compute node."},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"* Updates"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3ae8d1ca_030af789","line":92,"updated":"2014-05-28 13:25:46.000000000","message":"could you please detail the JSON data ?","commit_id":"ea2233eda768e94b19fe777bbe7381006e8fa0a7"},{"author":{"_account_id":8328,"name":"Mike Spreitzer","email":"mspreitz@us.ibm.com","username":"mspreitz"},"change_message_id":"89a8ef7a40b5e077e3a4edacfd613680601cd8a7","unresolved":false,"context_lines":[{"line_number":96,"context_line":""},{"line_number":97,"context_line":"  Update represents the act of updating one record and holds ID of updated"},{"line_number":98,"context_line":"  record and a timestamp. Updates also provide a token - a monotonic increasing"},{"line_number":99,"context_line":"  integer that differs for each update. Token is backend-dependent."},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"* Namespaces"},{"line_number":102,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_cf2d5f48","line":99,"updated":"2014-06-03 06:13:38.000000000","message":"Why do we need both a token and a timestamp?  Would just one of those suffice?","commit_id":"ea2233eda768e94b19fe777bbe7381006e8fa0a7"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"1cc8612bef49bc5dd6409ce826573927c4d98461","unresolved":false,"context_lines":[{"line_number":105,"context_line":"  \"nova-hoststate\" namespace is used."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"These models can be stored in any backend. Initial implementation proposes 2"},{"line_number":108,"context_line":"backends: SQLAlchemy and Memcached."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"Wherever the data is needed to be read or written, Synchronizer object is"},{"line_number":111,"context_line":"instantiated. It\u0027s initialized with a namespace name and a backend class. It"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3ae8d1ca_433b1f3a","line":108,"updated":"2014-05-28 13:25:46.000000000","message":"why providing another SQLA backend while we already have another one ?\n\nI can\u0027t see the interest of storing atomic records in SQLA with regards to performance (or you want to shard ?)","commit_id":"ea2233eda768e94b19fe777bbe7381006e8fa0a7"},{"author":{"_account_id":8328,"name":"Mike Spreitzer","email":"mspreitz@us.ibm.com","username":"mspreitz"},"change_message_id":"89a8ef7a40b5e077e3a4edacfd613680601cd8a7","unresolved":false,"context_lines":[{"line_number":118,"context_line":"For every operation internal state is synchronized with backend."},{"line_number":119,"context_line":"Synchronization process consits of the following steps:"},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"* latest fetched update\u0027s token is compared with the latest update\u0027s token"},{"line_number":122,"context_line":"  stored in the namespace;"},{"line_number":123,"context_line":"* if there are new updates, appropriate records are fetched from the backend"},{"line_number":124,"context_line":"  (note that the record will be fetched once even if there\u0027re a number of new"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_2fe24303","line":121,"updated":"2014-06-03 06:13:38.000000000","message":"Clearer wording would be something like: \"The token of the Synchronizer\u0027s most recently fetched update is compared with the token of the latest update stored in the namespace\".","commit_id":"ea2233eda768e94b19fe777bbe7381006e8fa0a7"},{"author":{"_account_id":8328,"name":"Mike Spreitzer","email":"mspreitz@us.ibm.com","username":"mspreitz"},"change_message_id":"89a8ef7a40b5e077e3a4edacfd613680601cd8a7","unresolved":false,"context_lines":[{"line_number":121,"context_line":"* latest fetched update\u0027s token is compared with the latest update\u0027s token"},{"line_number":122,"context_line":"  stored in the namespace;"},{"line_number":123,"context_line":"* if there are new updates, appropriate records are fetched from the backend"},{"line_number":124,"context_line":"  (note that the record will be fetched once even if there\u0027re a number of new"},{"line_number":125,"context_line":"  updates for it);"},{"line_number":126,"context_line":"* in case of some error (e.g. token sequence is broken or backend got flushed),"},{"line_number":127,"context_line":"  a timer is set to flush all state in 1 minute (by default) to allow hosts to"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_afc4935f","line":124,"updated":"2014-06-03 06:13:38.000000000","message":"If updates are being overtaken this means the Synchronizers are synchronizing less frequently than compute nodes are sending updates, so each synchronization will fetch a record for every host --- at which point this scheme has lost its main advantage.","commit_id":"ea2233eda768e94b19fe777bbe7381006e8fa0a7"},{"author":{"_account_id":8328,"name":"Mike Spreitzer","email":"mspreitz@us.ibm.com","username":"mspreitz"},"change_message_id":"89a8ef7a40b5e077e3a4edacfd613680601cd8a7","unresolved":false,"context_lines":[{"line_number":125,"context_line":"  updates for it);"},{"line_number":126,"context_line":"* in case of some error (e.g. token sequence is broken or backend got flushed),"},{"line_number":127,"context_line":"  a timer is set to flush all state in 1 minute (by default) to allow hosts to"},{"line_number":128,"context_line":"  report their new state in the mean time;"},{"line_number":129,"context_line":"* once in a while (10 seconds by default) all old updates are purged from"},{"line_number":130,"context_line":"  backend."},{"line_number":131,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_4fcb0f53","line":128,"updated":"2014-06-03 06:13:38.000000000","message":"The meaning of these words is not quite clear to me.  I presume \"case of some error\" refers to the Synchronizer\u0027s token being more recent than the backend\u0027s; I presume that would happen if the backend had lost its memory.  In this case, which agents flush what and when?  What does a Synchronizer do in the interim before all the hosts make new reports of state?","commit_id":"ea2233eda768e94b19fe777bbe7381006e8fa0a7"},{"author":{"_account_id":8328,"name":"Mike Spreitzer","email":"mspreitz@us.ibm.com","username":"mspreitz"},"change_message_id":"89a8ef7a40b5e077e3a4edacfd613680601cd8a7","unresolved":false,"context_lines":[{"line_number":126,"context_line":"* in case of some error (e.g. token sequence is broken or backend got flushed),"},{"line_number":127,"context_line":"  a timer is set to flush all state in 1 minute (by default) to allow hosts to"},{"line_number":128,"context_line":"  report their new state in the mean time;"},{"line_number":129,"context_line":"* once in a while (10 seconds by default) all old updates are purged from"},{"line_number":130,"context_line":"  backend."},{"line_number":131,"context_line":""},{"line_number":132,"context_line":"After synchronization get_all method returns data from internal state while put"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_2f49638b","line":129,"updated":"2014-06-03 06:13:38.000000000","message":"I presume you are thinking that the updates are kept in order to implement the functionality of finding the records updated since a given Synchronizer\u0027s token.  If this is so, you are not justified in purging updates based on time; the backend needs to purge only updates that it knows each Synchronizer has seen.  If the population of Synchronizers is configured or otherwise fairly stable, then the backend can simply keep track of the latest token presented by each backend; the oldest of those is the most recent update that can be purged.  Don\u0027t thank me, Rich Golding wrote this in the fall of 1992 in Computing Systems 5(4):379--405.\n\nHowever, you could do away with Updates if you simply store token or timestamp in each record.  What a Synchronizer wants is SELECT * FROM records WHERE token/timestamp \u003e mylast.  Yeah, you\u0027d want some auxiliary data structure to make that select fast --- that is, if you\u0027re implementing the database yourself.  But the index is not part of the data model, it is part of the implementation of making that query fast.","commit_id":"ea2233eda768e94b19fe777bbe7381006e8fa0a7"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"75b198a9c9f116096e1e79d69f56f39e5d7aca4a","unresolved":false,"context_lines":[{"line_number":134,"context_line":""},{"line_number":135,"context_line":"Alternatives"},{"line_number":136,"context_line":"------------"},{"line_number":137,"context_line":""},{"line_number":138,"context_line":"Fanout all host states to all schedulers"},{"line_number":139,"context_line":"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\""},{"line_number":140,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"3ae8d1ca_21f4565a","line":137,"updated":"2014-05-28 08:59:55.000000000","message":"Please consider this:\nhttp://kafka.apache.org/\n\nIt appears to implement much of the memcache work that was controversial.","commit_id":"ea2233eda768e94b19fe777bbe7381006e8fa0a7"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"1cc8612bef49bc5dd6409ce826573927c4d98461","unresolved":false,"context_lines":[{"line_number":140,"context_line":""},{"line_number":141,"context_line":"Compute nodes can fanout their state to all schedulers but it would put a"},{"line_number":142,"context_line":"significant load to message queue while still requiring to store states in DB"},{"line_number":143,"context_line":"to bootstrap new scheduler nodes."},{"line_number":144,"context_line":""},{"line_number":145,"context_line":"Data model impact"},{"line_number":146,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3ae8d1ca_237d336f","line":143,"updated":"2014-05-28 13:25:46.000000000","message":"An alternative could be to put most of the information necessary for scheduling in either request_spec or filter_property so that the RPC payload wouldn\u0027t be too much high.","commit_id":"ea2233eda768e94b19fe777bbe7381006e8fa0a7"},{"author":{"_account_id":8328,"name":"Mike Spreitzer","email":"mspreitz@us.ibm.com","username":"mspreitz"},"change_message_id":"89a8ef7a40b5e077e3a4edacfd613680601cd8a7","unresolved":false,"context_lines":[{"line_number":140,"context_line":""},{"line_number":141,"context_line":"Compute nodes can fanout their state to all schedulers but it would put a"},{"line_number":142,"context_line":"significant load to message queue while still requiring to store states in DB"},{"line_number":143,"context_line":"to bootstrap new scheduler nodes."},{"line_number":144,"context_line":""},{"line_number":145,"context_line":"Data model impact"},{"line_number":146,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_72ab50d6","line":143,"updated":"2014-06-03 06:13:38.000000000","message":"Bootstrap is a separable issue.  Your preferred solution uses the idea of soft state that is reloaded when lost, you could use that approach here too.","commit_id":"ea2233eda768e94b19fe777bbe7381006e8fa0a7"},{"author":{"_account_id":5441,"name":"Andrew Laski","email":"andrew@lascii.com","username":"alaski"},"change_message_id":"b20f3664bf27c3a5d100646f9313b857b7e7874d","unresolved":false,"context_lines":[{"line_number":140,"context_line":""},{"line_number":141,"context_line":"Compute nodes can fanout their state to all schedulers but it would put a"},{"line_number":142,"context_line":"significant load to message queue while still requiring to store states in DB"},{"line_number":143,"context_line":"to bootstrap new scheduler nodes."},{"line_number":144,"context_line":""},{"line_number":145,"context_line":"Data model impact"},{"line_number":146,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3ae8d1ca_fe9acb61","line":143,"in_reply_to":"3ae8d1ca_237d336f","updated":"2014-05-29 18:31:08.000000000","message":"This alternative only addresses the issue of RPC updates from computes, and I proposed another alternative to that above.  You don\u0027t list any alternative options for the issue of one giant db query, although the caching driver is one alternative, and surely there are others.","commit_id":"ea2233eda768e94b19fe777bbe7381006e8fa0a7"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"1cc8612bef49bc5dd6409ce826573927c4d98461","unresolved":false,"context_lines":[{"line_number":159,"context_line":"---------------"},{"line_number":160,"context_line":""},{"line_number":161,"context_line":"None with default SQL backend. Memcached backend would need to be secured"},{"line_number":162,"context_line":"separately."},{"line_number":163,"context_line":""},{"line_number":164,"context_line":"Notifications impact"},{"line_number":165,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3ae8d1ca_23e9b380","line":162,"updated":"2014-05-28 13:25:46.000000000","message":"which kind of security aspects Memcache has to take over ?","commit_id":"ea2233eda768e94b19fe777bbe7381006e8fa0a7"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"1cc8612bef49bc5dd6409ce826573927c4d98461","unresolved":false,"context_lines":[{"line_number":175,"context_line":"------------------"},{"line_number":176,"context_line":""},{"line_number":177,"context_line":"Performance benefit for large deployments (~10k nodes), no penalty for smaller"},{"line_number":178,"context_line":"clouds."},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"Other deployer impact"},{"line_number":181,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3ae8d1ca_8351a764","line":178,"updated":"2014-05-28 13:25:46.000000000","message":"if you\u0027re saying that you need to access sequential updates for getting an HostState, it could be less effective for smaller deployments than just doing a SELECT on a full HostState","commit_id":"ea2233eda768e94b19fe777bbe7381006e8fa0a7"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"1cc8612bef49bc5dd6409ce826573927c4d98461","unresolved":false,"context_lines":[{"line_number":180,"context_line":"Other deployer impact"},{"line_number":181,"context_line":"---------------------"},{"line_number":182,"context_line":""},{"line_number":183,"context_line":"SQLAlchemy backend merely requires migrations to be run."},{"line_number":184,"context_line":""},{"line_number":185,"context_line":"Memcached backend would require deploying memcached alongside Nova and"},{"line_number":186,"context_line":"configure synchronizer to use its endpoints."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3ae8d1ca_a39303f9","line":183,"updated":"2014-05-28 13:25:46.000000000","message":"We need to keep 1:1 matching between \"old\" SQLA and \"new\" SQLA DBs, if we say that whole no-db sched is optional.\nThat\u0027s risky because we don\u0027t have a single source of truth for SQL queries","commit_id":"ea2233eda768e94b19fe777bbe7381006e8fa0a7"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"1cc8612bef49bc5dd6409ce826573927c4d98461","unresolved":false,"context_lines":[{"line_number":183,"context_line":"SQLAlchemy backend merely requires migrations to be run."},{"line_number":184,"context_line":""},{"line_number":185,"context_line":"Memcached backend would require deploying memcached alongside Nova and"},{"line_number":186,"context_line":"configure synchronizer to use its endpoints."},{"line_number":187,"context_line":""},{"line_number":188,"context_line":"Developer impact"},{"line_number":189,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3ae8d1ca_83ad2734","line":186,"updated":"2014-05-28 13:25:46.000000000","message":"how do you ensure that memcache and SQL are in sync ?\n\nWhat happens if a deployer wants to change its backend and move from Memcache to SQLA ?\n\nWhat happens if a deployer wants to rollback from no-db to the regular compute_nodes table?","commit_id":"ea2233eda768e94b19fe777bbe7381006e8fa0a7"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"05753ca9af222b6227517cc14af27f1e1492b993","unresolved":false,"context_lines":[{"line_number":184,"context_line":""},{"line_number":185,"context_line":"Memcached backend would require deploying memcached alongside Nova and"},{"line_number":186,"context_line":"configure synchronizer to use its endpoints."},{"line_number":187,"context_line":""},{"line_number":188,"context_line":"Developer impact"},{"line_number":189,"context_line":"----------------"},{"line_number":190,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"9ad9bd40_b14ccc43","line":187,"updated":"2014-05-06 15:27:49.000000000","message":"Its quite a change to DB traffic patterns, etc.\n\nI feel this should be optional, can we make that clear here?\n\nPlease describe what extra nodes will have a database, and how to run the migrations there, and how they related to the other nova DB tables?","commit_id":"ea2233eda768e94b19fe777bbe7381006e8fa0a7"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"1cc8612bef49bc5dd6409ce826573927c4d98461","unresolved":false,"context_lines":[{"line_number":188,"context_line":"Developer impact"},{"line_number":189,"context_line":"----------------"},{"line_number":190,"context_line":""},{"line_number":191,"context_line":"None"},{"line_number":192,"context_line":""},{"line_number":193,"context_line":"Implementation"},{"line_number":194,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3ae8d1ca_c37e4fae","line":191,"updated":"2014-05-28 13:25:46.000000000","message":"DB changes have to be duplicated during the transition, or even later if we say it\u0027s optional","commit_id":"ea2233eda768e94b19fe777bbe7381006e8fa0a7"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"1cc8612bef49bc5dd6409ce826573927c4d98461","unresolved":false,"context_lines":[{"line_number":212,"context_line":"Dependencies"},{"line_number":213,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":214,"context_line":""},{"line_number":215,"context_line":"For memcached backend python-memcached is required."},{"line_number":216,"context_line":""},{"line_number":217,"context_line":"Testing"},{"line_number":218,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3ae8d1ca_233c53e2","line":215,"updated":"2014-05-28 13:25:46.000000000","message":"well, I think there are various blueprints that no-db is potentially requiring to be implemented","commit_id":"ea2233eda768e94b19fe777bbe7381006e8fa0a7"}]}