)]}'
{"specs/backlog/approved/instance-tasks.rst":[{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"d37c6e058d746bb51f9a20b1afafc5de3751e64f","unresolved":false,"context_lines":[{"line_number":49,"context_line":"   logic for what to do spread across multiple modules.  However it\u0027s not"},{"line_number":50,"context_line":"   always clear that there aren\u0027t dead ends in the state machine or states that"},{"line_number":51,"context_line":"   can\u0027t be reached.  If the logic for various actions could be pulled into"},{"line_number":52,"context_line":"   task modules we could more easily create proper state machines for them."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"2. In conjunction with the above idea tasks should be the mechanism of change"},{"line_number":55,"context_line":"   within Nova.  Right now we send an instance to a method like rebuild() and"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ba15a1d1_be1a1a6d","line":52,"updated":"2015-09-14 15:55:57.000000000","message":"For this it may be useful to look at what ironic has used https://pypi.python.org/pypi/automaton for (a state-machine library in oslo); http://docs.openstack.org/developer/ironic/dev/states.html and https://github.com/openstack/ironic/blob/master/ironic/common/states.py (something like this could help formalize the state machine in nova?)","commit_id":"47e9ff590fa0695282f47a6a4c0065dfdf7267b8"},{"author":{"_account_id":2271,"name":"Michael Still","email":"mikal@stillhq.com","username":"mikalstill"},"change_message_id":"23631c474a64aa6352656a2dc2aeea352517c92d","unresolved":false,"context_lines":[{"line_number":49,"context_line":"   logic for what to do spread across multiple modules.  However it\u0027s not"},{"line_number":50,"context_line":"   always clear that there aren\u0027t dead ends in the state machine or states that"},{"line_number":51,"context_line":"   can\u0027t be reached.  If the logic for various actions could be pulled into"},{"line_number":52,"context_line":"   task modules we could more easily create proper state machines for them."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"2. In conjunction with the above idea tasks should be the mechanism of change"},{"line_number":55,"context_line":"   within Nova.  Right now we send an instance to a method like rebuild() and"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_2ba4d0b7","line":52,"in_reply_to":"ba15a1d1_be1a1a6d","updated":"2015-11-30 05:39:55.000000000","message":"I agree this is useful, but I am not sure we should require a tweak of the backlog spec to include it.","commit_id":"47e9ff590fa0695282f47a6a4c0065dfdf7267b8"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"d37c6e058d746bb51f9a20b1afafc5de3751e64f","unresolved":false,"context_lines":[{"line_number":56,"context_line":"   that contains the logic for rebuild.  What I envision instead is sending the"},{"line_number":57,"context_line":"   task object via RPC and having it drive the state changes on an instance."},{"line_number":58,"context_line":"   Ultimately conductor/compute could just have a single method like"},{"line_number":59,"context_line":"   execute_task_on_instance(task, instance).  That\u0027s a bit unrealistic but that"},{"line_number":60,"context_line":"   could be the general concept."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"3. Actions on instances should be able to be stopped and resumed.  This is"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ba15a1d1_3e5cca24","line":59,"updated":"2015-09-14 15:55:57.000000000","message":"+1 I like it :)","commit_id":"47e9ff590fa0695282f47a6a4c0065dfdf7267b8"},{"author":{"_account_id":10584,"name":"Min Pae","username":"sputnik13","inactive":true},"change_message_id":"e16452840f71600b0d2740a8d9dc2fc827bc1760","unresolved":false,"context_lines":[{"line_number":56,"context_line":"   that contains the logic for rebuild.  What I envision instead is sending the"},{"line_number":57,"context_line":"   task object via RPC and having it drive the state changes on an instance."},{"line_number":58,"context_line":"   Ultimately conductor/compute could just have a single method like"},{"line_number":59,"context_line":"   execute_task_on_instance(task, instance).  That\u0027s a bit unrealistic but that"},{"line_number":60,"context_line":"   could be the general concept."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"3. Actions on instances should be able to be stopped and resumed.  This is"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ba15a1d1_3eedaa8b","line":59,"in_reply_to":"ba15a1d1_3e5cca24","updated":"2015-09-14 16:16:19.000000000","message":"+1","commit_id":"47e9ff590fa0695282f47a6a4c0065dfdf7267b8"},{"author":{"_account_id":10584,"name":"Min Pae","username":"sputnik13","inactive":true},"change_message_id":"e16452840f71600b0d2740a8d9dc2fc827bc1760","unresolved":false,"context_lines":[{"line_number":59,"context_line":"   execute_task_on_instance(task, instance).  That\u0027s a bit unrealistic but that"},{"line_number":60,"context_line":"   could be the general concept."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"3. Actions on instances should be able to be stopped and resumed.  This is"},{"line_number":63,"context_line":"   important for being able to restart services.  If the state of a task can be"},{"line_number":64,"context_line":"   persisted then when a service restarts it could pick up and resume the task."},{"line_number":65,"context_line":"   This implies that tasks should be idempotent, which is unlikely, or that"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ba15a1d1_feff3232","line":62,"updated":"2015-09-14 16:16:19.000000000","message":"+1","commit_id":"47e9ff590fa0695282f47a6a4c0065dfdf7267b8"},{"author":{"_account_id":10584,"name":"Min Pae","username":"sputnik13","inactive":true},"change_message_id":"e16452840f71600b0d2740a8d9dc2fc827bc1760","unresolved":false,"context_lines":[{"line_number":63,"context_line":"   important for being able to restart services.  If the state of a task can be"},{"line_number":64,"context_line":"   persisted then when a service restarts it could pick up and resume the task."},{"line_number":65,"context_line":"   This implies that tasks should be idempotent, which is unlikely, or that"},{"line_number":66,"context_line":"   they should have checkpoints."},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"4. A future idea could be to strip nova-compute to being a tasks worker which"},{"line_number":69,"context_line":"   has very little logic in it and is mostly responsible for pulling tasks from"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ba15a1d1_3ea4ca55","line":66,"updated":"2015-09-14 16:16:19.000000000","message":"Taskflow fits nicely in to this requirement...  just saying...","commit_id":"47e9ff590fa0695282f47a6a4c0065dfdf7267b8"},{"author":{"_account_id":10584,"name":"Min Pae","username":"sputnik13","inactive":true},"change_message_id":"e16452840f71600b0d2740a8d9dc2fc827bc1760","unresolved":false,"context_lines":[{"line_number":67,"context_line":""},{"line_number":68,"context_line":"4. A future idea could be to strip nova-compute to being a tasks worker which"},{"line_number":69,"context_line":"   has very little logic in it and is mostly responsible for pulling tasks from"},{"line_number":70,"context_line":"   a queue.  This moves us closer to a place where multiple nova-computes could"},{"line_number":71,"context_line":"   be running for a single hypervisor just pulling work from multiple"},{"line_number":72,"context_line":"   conductors.  Then nova-compute would not be a single point of failure.  This"},{"line_number":73,"context_line":"   idea has not been discussed within the community and is simply something"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ba15a1d1_d141ff3a","line":70,"updated":"2015-09-14 16:16:19.000000000","message":"Simple is almost always easier to scale.  In that sense simplifying nova-compute will most assuredly lead to better scalability as log as the tasks can also scale.\n\nTasks that can be checkpointed, paused, and resumed in a fine grained way should also allow for better scalability if said fine grained tasks are truly idempotent since it should be feasible to distribute such tasks.","commit_id":"47e9ff590fa0695282f47a6a4c0065dfdf7267b8"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"f3c600a068998bda4ca3bdf43b346b878fa97bd9","unresolved":false,"context_lines":[{"line_number":77,"context_line":""},{"line_number":78,"context_line":"The early work on tasks was focused on introducing the concept at the API"},{"line_number":79,"context_line":"level.  The idea was to get the interface in place and then rework the Nova"},{"line_number":80,"context_line":"internals to match that concept.  There\u0027s some merit to that approach but this"},{"line_number":81,"context_line":"can be done differently as well.  The focus could start on the internals of"},{"line_number":82,"context_line":"Nova and getting that framework in place and then exposing it in the API once"},{"line_number":83,"context_line":"the details are understood.  The main advantage I saw to working on the API"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ba15a1d1_51bacfe2","line":80,"updated":"2015-09-14 16:18:55.000000000","message":"I\u0027d prefer the focus on internal-only tasks, vs API exposed ones, its probably easier to start internally, vs committing to a whole new REST API at the same time as refactoring internally. Making it easier to get inertia is IMHO (by starting small/internally) I think would help this effort, vs making the change so big that it \u0027scares\u0027 people away.","commit_id":"47e9ff590fa0695282f47a6a4c0065dfdf7267b8"},{"author":{"_account_id":5511,"name":"Nikola Dipanov","email":"ndipanov@redhat.com","username":"ndipanov"},"change_message_id":"97315c0a57c0cae608f598be0e48ae152574800d","unresolved":false,"context_lines":[{"line_number":77,"context_line":""},{"line_number":78,"context_line":"The early work on tasks was focused on introducing the concept at the API"},{"line_number":79,"context_line":"level.  The idea was to get the interface in place and then rework the Nova"},{"line_number":80,"context_line":"internals to match that concept.  There\u0027s some merit to that approach but this"},{"line_number":81,"context_line":"can be done differently as well.  The focus could start on the internals of"},{"line_number":82,"context_line":"Nova and getting that framework in place and then exposing it in the API once"},{"line_number":83,"context_line":"the details are understood.  The main advantage I saw to working on the API"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a1a9d01_eab30ae8","line":80,"in_reply_to":"ba15a1d1_51bacfe2","updated":"2015-10-01 16:16:37.000000000","message":"+100 - I would go even further and say that this should never be in a user facing API and that having a single API that is supposed to be consumed by humans using, humans operating, robots operating, and robots using the cloud is the source of most of our problems. \n\nTasks IMHO do not belong anywehere near end users - this is information that they cannot possibly act upon, and thus don\u0027t care about it. The CRUD that completely ignores the complexity behind is actually exactly what we want our users to see. Better error reporting within reason - sure, but not much more than that. This can feed off of tasks.\n\nAutomation on the other hand can use a ton of details (like which host the task is stuck on, way more data around the state etc.) to make better decisions, they should be using a completely different set of primitives to talk to the system.\n\nI actually believe we should exposing different API\u0027s to code, admins and users with a completely different set of resources and actions, and different stability guarantees.","commit_id":"47e9ff590fa0695282f47a6a4c0065dfdf7267b8"},{"author":{"_account_id":10584,"name":"Min Pae","username":"sputnik13","inactive":true},"change_message_id":"e16452840f71600b0d2740a8d9dc2fc827bc1760","unresolved":false,"context_lines":[{"line_number":94,"context_line":"conductor before something like TaskFlow looks like a good fit.  My suggestion"},{"line_number":95,"context_line":"would be to work on iterating towards a task model within Nova and if the"},{"line_number":96,"context_line":"solution starts to look like a fit for TaskFlow then that discussion can"},{"line_number":97,"context_line":"happen.  In other words let\u0027s not change Nova to fit TaskFlow but use TaskFlow"},{"line_number":98,"context_line":"if it fits in Nova."},{"line_number":99,"context_line":""},{"line_number":100,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"ba15a1d1_515e4fea","line":97,"updated":"2015-09-14 16:16:19.000000000","message":"+1 for evolutionary change.  Even if Taskflow isn\u0027t used in its entirety, things like creating \"tasks\" that can be paused and resumed are basic capabilities that Taskflow already provides out of the box which could be leveraged without adopting Taskflow 100%.  It probably doesn\u0027t make a lot of sense to reinvent anything Taskflow already does for the sake of not adopting Taskflow.","commit_id":"47e9ff590fa0695282f47a6a4c0065dfdf7267b8"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"9de99a31db80f51f1b7148df1c20766380d391a0","unresolved":false,"context_lines":[{"line_number":95,"context_line":"would be to work on iterating towards a task model within Nova and if the"},{"line_number":96,"context_line":"solution starts to look like a fit for TaskFlow then that discussion can"},{"line_number":97,"context_line":"happen.  In other words let\u0027s not change Nova to fit TaskFlow but use TaskFlow"},{"line_number":98,"context_line":"if it fits in Nova."},{"line_number":99,"context_line":""},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"Finally, instance faults and instance-actions should be deprecated by"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ba15a1d1_fbff4432","line":98,"updated":"2015-09-14 15:51:51.000000000","message":"+1 use taskflow where it fits and/or helps (vs. the other way around); although there is no need to fix \u0027all\u0027 of nova first IMHO, just use taskflow where it may/can help, and use taskflow at whatever \u0027comfort level\u0027 the nova people are comfortable with. This seems to be the common way of integrating it into projects that already exists (vs. new projects which can approach this kind of integration differently).","commit_id":"47e9ff590fa0695282f47a6a4c0065dfdf7267b8"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"84dc0fa8de52495ab8d66f44e49e41407a055024","unresolved":false,"context_lines":[{"line_number":95,"context_line":"would be to work on iterating towards a task model within Nova and if the"},{"line_number":96,"context_line":"solution starts to look like a fit for TaskFlow then that discussion can"},{"line_number":97,"context_line":"happen.  In other words let\u0027s not change Nova to fit TaskFlow but use TaskFlow"},{"line_number":98,"context_line":"if it fits in Nova."},{"line_number":99,"context_line":""},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"Finally, instance faults and instance-actions should be deprecated by"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ba15a1d1_1e8306ce","line":98,"in_reply_to":"ba15a1d1_fbff4432","updated":"2015-09-14 16:05:54.000000000","message":"Perhaps a plan of action can be developed?\n\n1) Refactor the state machine?\n\n2) Cut off pieces of that state machine into tasks.\n\nUse taskflow or other oslo libraries (automaton) as needed/where helpful...","commit_id":"47e9ff590fa0695282f47a6a4c0065dfdf7267b8"}]}