)]}'
{"specs/newton/approved/expose-quiesce-unquiesce-api.rst":[{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"aad56bd98ebaa2f20fe7972113d112a2c9e4c252","unresolved":false,"context_lines":[{"line_number":132,"context_line":"1. Usually Nova API will manipulate one VM per action. One proposal is"},{"line_number":133,"context_line":"   to expose quiesce, unquiesce single API action on multiple VMs in order,"},{"line_number":134,"context_line":"   this will break Nova API fasion and leads to implementation complexity,"},{"line_number":135,"context_line":"   especially under cells deployment."},{"line_number":136,"context_line":"2. Another proposal is to make quiesce, unquiesce API work in \"sync.\" way"},{"line_number":137,"context_line":"   due to the short execution time of the quiesce,unquiesce. \"sync\""},{"line_number":138,"context_line":"   implementation is not the fasion in web service and Nova API."}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa0719c6_c919418a","line":135,"range":{"start_line":135,"start_character":20,"end_line":135,"end_character":25},"updated":"2016-03-23 15:29:00.000000000","message":"I assume you mean cells v1 deployments, which we\u0027ve ruled out won\u0027t get support for this API since cells v1 is feature frozen.","commit_id":"59b25cc44107fcbb4dcfc461f55126a61061f279"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"683ac699aab535ea20cf09e7d3e0953e3655ed23","unresolved":false,"context_lines":[{"line_number":183,"context_line":"Notifications impact"},{"line_number":184,"context_line":"--------------------"},{"line_number":185,"context_line":""},{"line_number":186,"context_line":"None"},{"line_number":187,"context_line":""},{"line_number":188,"context_line":"Other end user impact"},{"line_number":189,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa0719c6_8e229950","line":186,"updated":"2016-03-23 20:44:03.000000000","message":"Given this has comments about notifications being sent in the new versioned notification style, this section needs updating:\n\nhttps://review.openstack.org/#/c/248989/","commit_id":"59b25cc44107fcbb4dcfc461f55126a61061f279"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"fb4da2f4b8e7c6848cc94473118266aa9da81eb1","unresolved":false,"context_lines":[{"line_number":183,"context_line":"Notifications impact"},{"line_number":184,"context_line":"--------------------"},{"line_number":185,"context_line":""},{"line_number":186,"context_line":"None"},{"line_number":187,"context_line":""},{"line_number":188,"context_line":"Other end user impact"},{"line_number":189,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa0719c6_7208c0da","line":186,"in_reply_to":"fa0719c6_8e229950","updated":"2016-03-24 01:14:36.000000000","message":"Hi, thanks for the review, as the new versioned notification for notify_about_instance_usage will be a really big change since a large number of actions uses that, I was hoping this can be done separately of this BP, what should I write here?","commit_id":"59b25cc44107fcbb4dcfc461f55126a61061f279"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"4ccc04c2383c06fb5acb88d4c9980d6214d8e07b","unresolved":false,"context_lines":[{"line_number":175,"context_line":""},{"line_number":176,"context_line":"* Microversion"},{"line_number":177,"context_line":"    * A new microversion will be added for this API."},{"line_number":178,"context_line":""},{"line_number":179,"context_line":"Security impact"},{"line_number":180,"context_line":"---------------"},{"line_number":181,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"1a122d0e_4f4f0392","line":178,"updated":"2016-05-05 08:35:25.000000000","message":"So in the code we have modified the server state, so its UNKNOWN for old API calls, and QUESED for new API calls.\n\nWe should include this detail in here.","commit_id":"7790b81204ef4e2bd17f3f66e8e59b8a40e37524"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"4ccc04c2383c06fb5acb88d4c9980d6214d8e07b","unresolved":false,"context_lines":[{"line_number":187,"context_line":"A notification about quiesce and unquiesce will be added. Nova"},{"line_number":188,"context_line":"is going to support versioned notifications and the refactor of"},{"line_number":189,"context_line":"notifications is going in orders according to notification subteam\u0027s"},{"line_number":190,"context_line":"plan. The notification added in this BP will be in old non-versioned"},{"line_number":191,"context_line":"notifications and will be modified afterwards in other patch."},{"line_number":192,"context_line":""},{"line_number":193,"context_line":"Other end user impact"},{"line_number":194,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":10,"id":"1a122d0e_cf22f3b8","line":191,"range":{"start_line":190,"start_character":6,"end_line":191,"end_character":61},"updated":"2016-05-05 08:35:25.000000000","message":"We have now banned new old-style notifications. That will need to be re-worked.","commit_id":"7790b81204ef4e2bd17f3f66e8e59b8a40e37524"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"f98d75404844b12a6e7f07157c5c09c5f60e78b3","unresolved":false,"context_lines":[{"line_number":193,"context_line":"As Nova is going to support versioned notifications and the refactor of"},{"line_number":194,"context_line":"notifications is going in orders according to notification subteam\u0027s"},{"line_number":195,"context_line":"plan.The notification about quiesce and unquiesce will be added in a"},{"line_number":196,"context_line":"separate patch once the refactor of related notification is done."},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"Other end user impact"},{"line_number":199,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":11,"id":"1a122d0e_7e638eb1","line":196,"updated":"2016-05-05 09:02:16.000000000","message":"+1","commit_id":"7f54b2b4f9f83113151917af366402f78cbd8319"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"f0b01577338e7a68a5baabc31395a5d09f96d347","unresolved":false,"context_lines":[{"line_number":19,"context_line":"Currently Nova provides single VM snapshot API (createImage), which will"},{"line_number":20,"context_line":"take a consistency snapshot of a VM and regarding volumes, and will quiesce"},{"line_number":21,"context_line":"unquiesce VM automatically with guest agent support. This method is good"},{"line_number":22,"context_line":"for single VM consistency snapshot, but there\u0027s no way to make consistency"},{"line_number":23,"context_line":"snapshot for an application which consists of multiple VMs."},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"Use Cases"},{"line_number":26,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":12,"id":"dab17558_db8fb2ca","line":23,"range":{"start_line":22,"start_character":36,"end_line":23,"end_character":59},"updated":"2016-05-12 21:56:55.000000000","message":"Have you seen:\n\nhttps://developer.ibm.com/open/disaster-recovery-for-cloud-dragon/\n\nhttps://github.com/os-cloud-storage/openstack-workload-disaster-recovery\n\n?\n\nWhat does that do that this doesn\u0027t, or vice-versa? I\u0027d really like to avoid orchestrating this type of thing within Nova.","commit_id":"08e474e8132c844a01957376ec874b8ff055917a"},{"author":{"_account_id":11819,"name":"Chaoyi Huang","email":"joehuang@huawei.com","username":"joehuang"},"change_message_id":"502684cfd71c227238dddfb4d2bf7a1e1a23a07f","unresolved":false,"context_lines":[{"line_number":19,"context_line":"Currently Nova provides single VM snapshot API (createImage), which will"},{"line_number":20,"context_line":"take a consistency snapshot of a VM and regarding volumes, and will quiesce"},{"line_number":21,"context_line":"unquiesce VM automatically with guest agent support. This method is good"},{"line_number":22,"context_line":"for single VM consistency snapshot, but there\u0027s no way to make consistency"},{"line_number":23,"context_line":"snapshot for an application which consists of multiple VMs."},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"Use Cases"},{"line_number":26,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":12,"id":"dab17558_e4364de6","line":23,"range":{"start_line":22,"start_character":36,"end_line":23,"end_character":59},"in_reply_to":"dab17558_15e74213","updated":"2016-05-13 03:06:26.000000000","message":"Except Zhengyu\u0027s comment. I also have some comment:\nThanks to mention Dragon project, but Dragon project also uses OpenStack API to do the disaster recovery, so there is still no consistency guarantee on application level. If we do application snapshot by single VM consistency image one by one, no guarantee for a group of VMs which need to boot correctly in disaster recovery site, for their images are created in different time. For example, if the App is consisted of (VM1, VM2, VM3). At time 1, create VM1 consistency image, the App state is state-1 of (VM1, VM2, VM3); Then application is resumed to run after the VM1 image created, and new data will be received, and App state will be changed. At time 2, the App state will be changed to state-2 of (VM1, VM2, VM3), if we create VM2 consistency image at time 2, in fact, VM2 image can only work with state-2 VM1 and VM3, but not state-1 VM1. Many applications will have boot issue if these VMs snapshot were done under different system state, just like today\u0027s you can not talk to yesterday\u0027s me, it\u0027s in different state\u0026time space. NFV is only one area need application level consistency snapshot. commVault and other companies( sorry forget the name) also need this feature for disaster recovery when I give a lightening talk In Austin summit.","commit_id":"08e474e8132c844a01957376ec874b8ff055917a"},{"author":{"_account_id":11819,"name":"Chaoyi Huang","email":"joehuang@huawei.com","username":"joehuang"},"change_message_id":"01d15a06166ab64eff30cc18e6c2756d41fa2e64","unresolved":false,"context_lines":[{"line_number":19,"context_line":"Currently Nova provides single VM snapshot API (createImage), which will"},{"line_number":20,"context_line":"take a consistency snapshot of a VM and regarding volumes, and will quiesce"},{"line_number":21,"context_line":"unquiesce VM automatically with guest agent support. This method is good"},{"line_number":22,"context_line":"for single VM consistency snapshot, but there\u0027s no way to make consistency"},{"line_number":23,"context_line":"snapshot for an application which consists of multiple VMs."},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"Use Cases"},{"line_number":26,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":12,"id":"dab17558_b5f708d2","line":23,"range":{"start_line":22,"start_character":36,"end_line":23,"end_character":59},"in_reply_to":"dab17558_6b9faf5f","updated":"2016-05-16 02:30:30.000000000","message":"First, the disaster recovery is mainly the action in the infrastructure level in case of catastrophic failures (flood, earthquake, propagating software fault), the cloud service provider recover the infrastructure and the applications without the help from each application owner: you can not just recover the OpenStack, then send notification to all applications\u0027 owners, to ask them to restore their appliations by their own.\n\nThe second, this requirement is not to make OpenStack bend over NFV, although this requirement was asked from OPNFV at first, it\u0027s general requirement to have applicaiton level consistency snapshot.For example, just using OpenStack itself as the application running in the cloud, we can deploy different DB for differnt service, i.e. Nova has its own mysql server nova-db-VM, Neutron has its own mysql server neutron-db-VM. In fact, I have seen in some production to divide the db for Nova/Cinder/Neutron to different DB server for scalability purpose. We know that there are interaction between Nova and Neutron when booting a new VM, during the VM booting period, some data will be in the memory cache of the nova-db-VM/neutron-db-VM, if we just create snapshot of the volumes of nova-db-VM/neutron-db-VM in Cinder, the data which has not been flushed to the disk will not be in the snapshot of the volumes. We cann\u0027t make sure when these data in the memory cache will be flushed, then there is random possibility that the data in the snapshot is not consistent as what happened as in the virtual machines of nova-db-VM/neutron-db-VM.In this case, Nova/Neutron may boot in the disaster recovery site successfully, but some port information may be crushed for not flushed into the neutron-db-VM when doing snapshot.\n\nThe third, for those applications which can decide the data and checkpoint should be replicated to disaster recovery site, this is the third option discussed and described in our analysis: https://git.opnfv.org/cgit/multisite/tree/docs/requirements/multisite-vnf-gr-requirement.rst. But unfortuanelty in Cinder, after the volume replication V2.1 is developed, the tenant granularity volume replication is still being discussed, and still not on single volume level. And just like what have mentioned in the first point, both application level and infrastrcture level are needed, for you can\u0027t only expect that asking each application owners to do recovery after disaster recovery of a site\u0027s OpenStack: applications usually can deal with the data generated by it, but for the configuration change\u0027s protection, it\u0027s out of scope of application. There are several options for disaster recovery, but doesn\u0027t mean one option can fit all.","commit_id":"08e474e8132c844a01957376ec874b8ff055917a"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"cf7d297f6524d46cf869853bad72a172a303cd91","unresolved":false,"context_lines":[{"line_number":19,"context_line":"Currently Nova provides single VM snapshot API (createImage), which will"},{"line_number":20,"context_line":"take a consistency snapshot of a VM and regarding volumes, and will quiesce"},{"line_number":21,"context_line":"unquiesce VM automatically with guest agent support. This method is good"},{"line_number":22,"context_line":"for single VM consistency snapshot, but there\u0027s no way to make consistency"},{"line_number":23,"context_line":"snapshot for an application which consists of multiple VMs."},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"Use Cases"},{"line_number":26,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":12,"id":"dab17558_15e74213","line":23,"range":{"start_line":22,"start_character":36,"end_line":23,"end_character":59},"in_reply_to":"dab17558_db8fb2ca","updated":"2016-05-13 01:50:43.000000000","message":"Hi, thanks for the information, actually, the main idea here is the ability to stop the data generation(transmission) of a group of instances(upper layer services) according to a certain order and take a consistency snapshot of all the instances, and then start them again in reverse order(or any order we desired). The Dragon project is a very good project for DR, but it uses Nova API to do the work, that means it depend on nova\u0027s ability, but the current nova cannot provide this kind of ability, otherwise we can just call the existing API to perform the action we want. It is not that we use this API to let Nova perform the DR we want, the main idea here is to let nova provide the API so that projects like Dragon can perform more type of DR jobs. So, I think we should expose this API, so that services like Dragon can use this API to perform more advanced DR jobs.\n\nAnd as we write in the spec, the use case that driving this is mainly NFV scenario, in which the data generation(transmission) is massive and the order of freeze and unfreeze instances(services) really matters. And after we expose this API, we can use services like Dragon to perform the DR jobs we want automatically using this API.","commit_id":"08e474e8132c844a01957376ec874b8ff055917a"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"23eaa6c8bc80f28befb8a8dc7aa7631dca93da2c","unresolved":false,"context_lines":[{"line_number":19,"context_line":"Currently Nova provides single VM snapshot API (createImage), which will"},{"line_number":20,"context_line":"take a consistency snapshot of a VM and regarding volumes, and will quiesce"},{"line_number":21,"context_line":"unquiesce VM automatically with guest agent support. This method is good"},{"line_number":22,"context_line":"for single VM consistency snapshot, but there\u0027s no way to make consistency"},{"line_number":23,"context_line":"snapshot for an application which consists of multiple VMs."},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"Use Cases"},{"line_number":26,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":12,"id":"dab17558_6b9faf5f","line":23,"range":{"start_line":22,"start_character":36,"end_line":23,"end_character":59},"in_reply_to":"dab17558_e4364de6","updated":"2016-05-13 14:14:50.000000000","message":"First, I don\u0027t buy into the argument that OpenStack needs to bend over backwards to accommodate legacy NFV telco applications to use OpenStack. If OpenStack bends to every demand of the NFV community, then what motivation do these telcos have to re-write their legacy applications to work with OpenStack in a cloud-native way? If they have something working today, great, they can keep using that. If they want to use OpenStack, great, but re-write the applications to work with it.\n\nFor example, why can\u0027t these applications be performing their own data checkpoints in the case of an unexpected outage (which should be expected, planned for and built into the application)? So when there is a failure, the application can rollback to the prior checkpoint and continue working.\n\nThis isn\u0027t simply about exposing a call through to the virt driver to quiesce an instance, it\u0027s also introducing new state modeling that Nova needs to handle, and we already have a ton of that in Nova which complicates a lot of the task flows.\n\nAnd as Dan Smith pointed out, this is currently only something that a single virt driver is providing, so going from cloud to cloud it\u0027s not interoperable. The only way a cloud that doesn\u0027t support this, like Rackspace, would be to disable it in policy so a user gets an error when trying to use it.\n\nThis just adds a lot of new complexity to Nova which we\u0027ve pushed back on in the past since it can be done outside of Nova. And repeating over and over that NFV needs it doesn\u0027t make that a good justification - there are lots of things that NFV needs/wants and has gotten into Nova and we have a massive load of technical debt for it already, see:\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2016-May/093594.html","commit_id":"08e474e8132c844a01957376ec874b8ff055917a"},{"author":{"_account_id":21420,"name":"Gage Hugo","email":"gagehugo@gmail.com","username":"ghugo"},"change_message_id":"77a0c0dbd02810c6dcbad022af0093e545fc68c5","unresolved":false,"context_lines":[{"line_number":94,"context_line":"operation and with guest agent installed and enbaled."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"This BP mainly focuses on Nova-API part to expose the API, nova.virt"},{"line_number":97,"context_line":"driver.py has already provided the interface \u0027quiesce\u0027 \u0027unquiesce\u0027,  some"},{"line_number":98,"context_line":"other hypervisor drivers may support this feature now or in the future, it"},{"line_number":99,"context_line":"should be out of the scope of this BP."},{"line_number":100,"context_line":""}],"source_content_type":"text/x-rst","patch_set":12,"id":"dab17558_00db871c","line":97,"range":{"start_line":97,"start_character":68,"end_line":97,"end_character":69},"updated":"2016-05-12 21:25:54.000000000","message":"Extra whitespace here","commit_id":"08e474e8132c844a01957376ec874b8ff055917a"},{"author":{"_account_id":2750,"name":"Sean Dague","email":"sean@dague.net","username":"sdague"},"change_message_id":"fa0c57cfdfeda1538a4fbf2a045f6c72c08abde3","unresolved":false,"context_lines":[{"line_number":124,"context_line":"as other operation."},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"No matter in quiesced or ERROR state, the admin reset VM state action will"},{"line_number":127,"context_line":"take the VM to desired state."},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"Alternatives"},{"line_number":130,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":12,"id":"bab6814e_4d727c4a","line":127,"updated":"2016-05-20 12:10:16.000000000","message":"Can you provide the matrix of which hypervisors could and could not support quiesce? And what that call looks like to each of them.\n\nIf this is a single hypervisor, exposing it on the API is something we don\u0027t want to do until there are capabilities API (which is really 2 or 3 cycles out). If it is multiple, that makes it easier to consider sooner.","commit_id":"08e474e8132c844a01957376ec874b8ff055917a"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"a35adf58779e38317122ab9f64cc80980c2fe24c","unresolved":false,"context_lines":[{"line_number":128,"context_line":""},{"line_number":129,"context_line":"Alternatives"},{"line_number":130,"context_line":"------------"},{"line_number":131,"context_line":"1. Usually Nova API will manipulate one VM per action. One proposal is"},{"line_number":132,"context_line":"   to expose quiesce, unquiesce single API action on multiple VMs in order,"},{"line_number":133,"context_line":"   this will break Nova API style and leads to implementation complexity."},{"line_number":134,"context_line":"2. Another proposal is to make quiesce, unquiesce API synchronous due to the"},{"line_number":135,"context_line":"   short execution time of these operations. \"Sync\" implementation is not"},{"line_number":136,"context_line":"   fashionable right now in web service and Nova API."}],"source_content_type":"text/x-rst","patch_set":12,"id":"dab17558_7b1cc577","line":133,"range":{"start_line":131,"start_character":3,"end_line":133,"end_character":73},"updated":"2016-05-12 22:29:46.000000000","message":"Why couldn\u0027t you change this to put the VMs in a server group and then snapshot that server group so it\u0027s all atomic rather than one by one managed by the caller?","commit_id":"08e474e8132c844a01957376ec874b8ff055917a"},{"author":{"_account_id":11819,"name":"Chaoyi Huang","email":"joehuang@huawei.com","username":"joehuang"},"change_message_id":"502684cfd71c227238dddfb4d2bf7a1e1a23a07f","unresolved":false,"context_lines":[{"line_number":128,"context_line":""},{"line_number":129,"context_line":"Alternatives"},{"line_number":130,"context_line":"------------"},{"line_number":131,"context_line":"1. Usually Nova API will manipulate one VM per action. One proposal is"},{"line_number":132,"context_line":"   to expose quiesce, unquiesce single API action on multiple VMs in order,"},{"line_number":133,"context_line":"   this will break Nova API style and leads to implementation complexity."},{"line_number":134,"context_line":"2. Another proposal is to make quiesce, unquiesce API synchronous due to the"},{"line_number":135,"context_line":"   short execution time of these operations. \"Sync\" implementation is not"},{"line_number":136,"context_line":"   fashionable right now in web service and Nova API."}],"source_content_type":"text/x-rst","patch_set":12,"id":"dab17558_84e82118","line":133,"range":{"start_line":131,"start_character":3,"end_line":133,"end_character":73},"in_reply_to":"dab17558_7b1cc577","updated":"2016-05-13 03:06:26.000000000","message":"Matt, this a great suggestion. Currently server group only supports anti-affinity and affinity policy for scheduling purpose, and Nova does\u0027t support operation on server group, if Nova would like to introduce mechanism for a group of VMs operation ( may be adding new policy in server group and and introduce server group based operation ), I admit it\u0027s more like a \"cloudy\" behavior","commit_id":"08e474e8132c844a01957376ec874b8ff055917a"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"6af79ee60993931ecb28d4ca676ecdb16b671ca3","unresolved":false,"context_lines":[{"line_number":193,"context_line":""},{"line_number":194,"context_line":"As Nova is going to support versioned notifications and the refactor of"},{"line_number":195,"context_line":"notifications is going in orders according to notification subteam\u0027s"},{"line_number":196,"context_line":"plan.The notification about quiesce and unquiesce will be added in a"},{"line_number":197,"context_line":"separate patch once the refactor of related notification is done."},{"line_number":198,"context_line":""},{"line_number":199,"context_line":"Other end user impact"}],"source_content_type":"text/x-rst","patch_set":12,"id":"1a122d0e_08a4dca3","line":196,"range":{"start_line":196,"start_character":4,"end_line":196,"end_character":7},"updated":"2016-05-05 11:41:38.000000000","message":"Nit: need an extra space here.","commit_id":"08e474e8132c844a01957376ec874b8ff055917a"}]}