)]}'
{"specs/containers-service.rst":[{"author":{"_account_id":11536,"name":"hongbin","email":"hongbin034@gmail.com","username":"hongbin"},"change_message_id":"1e8e5e9756f9b95ae9fd57f22e21999da378756b","unresolved":false,"context_lines":[{"line_number":44,"context_line":"   security isolation between applications is nice-to-have but not critical."},{"line_number":45,"context_line":"   Isolation is desired primarily for simplified management of the execution"},{"line_number":46,"context_line":"   environment for each application."},{"line_number":47,"context_line":"2. App Portability. End-user wants to create a single container image, and"},{"line_number":48,"context_line":"   deploy the same image to multiple hosting environments, including OpenStack."},{"line_number":49,"context_line":"   Other environments may include local servers, dedicated servers, private"},{"line_number":50,"context_line":"   clouds, and public clouds. Switching environments requires passing database"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3a961159_7139dcd7","line":47,"updated":"2014-12-17 04:38:19.000000000","message":"Alternatively, end-user could live migrate a running container to other hosting environments, including OpenStack, EC2 or other clouds.","commit_id":"f2c4c3eafcb5f89adfc9fa77d363c97756c445dd"},{"author":{"_account_id":6348,"name":"xu-haiwei","email":"hai-xu@xr.jp.nec.com","username":"xu-haiwei"},"change_message_id":"fcb905ad0cfde2b53bb47cb48f99fa5c8df03f4b","unresolved":false,"context_lines":[{"line_number":53,"context_line":"   without changing the container image."},{"line_number":54,"context_line":"3. Docker Compatibility. End-user has a Dockerfile used to build an application"},{"line_number":55,"context_line":"   and its runtime environment and dependencies in a Docker container image. "},{"line_number":56,"context_line":"   They want an easy way to run the Docker resulting image on an OpenStack "},{"line_number":57,"context_line":"   cloud."},{"line_number":58,"context_line":"4. LXC Compatibility. End-user wants an easy way to remotely create multiple"},{"line_number":59,"context_line":"   LXC containers within a single Nova instance."}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_97a8c278","line":56,"updated":"2014-11-21 08:33:56.000000000","message":"Trailing white space should be deleted.","commit_id":"f2c4c3eafcb5f89adfc9fa77d363c97756c445dd"},{"author":{"_account_id":11536,"name":"hongbin","email":"hongbin034@gmail.com","username":"hongbin"},"change_message_id":"1e8e5e9756f9b95ae9fd57f22e21999da378756b","unresolved":false,"context_lines":[{"line_number":65,"context_line":"   on a given Nova instance, and when more need to be created. They want to"},{"line_number":66,"context_line":"   simply create and remove containers, and allow the appropriate resource"},{"line_number":67,"context_line":"   scheduling to happen automatically."},{"line_number":68,"context_line":"7. Platform Integration. Cloud operator already has an OpenStack cloud, and"},{"line_number":69,"context_line":"   wants to add a service/application centric management system on top."},{"line_number":70,"context_line":"   Examples of such systems are Cloud Foundry, Kubernetes, Apache Mesos, etc."},{"line_number":71,"context_line":"   The selected system is already Docker compatible. Allow this cloud operator"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3a961159_d1e37031","line":68,"updated":"2014-12-17 04:38:19.000000000","message":"8. Overlay network. End-users may want to build an overlay network that connects their containers. The overlay network should be independent of the underlying neutron network that connects the hosts (or called nodes), and end-users should be able to manage the overlay network provisioned by themselves (e.g. doing SDN). Magnum could provides APIs for end-users to build the overlay network they specified, and dynamically modify the network topology (e.g. add/remove container to/from the network).\n\nIt seems that most of the core developers prefer to connect containers to the underlying neutron network. Drawbacks are (i) it is hard to extend the container network to other tenant/region/cloud due to separation of management domain, and (ii) end-users are not able to manage the container network. Compared to it, I think the overlay network approach is more flexible in the end-user points of view.\n\n9. Multi-region/multi-cloud support. End-users may want to deploy their applications to multiple regions/clouds, and dynamically relocate their applications across different regions/clouds. Magnum could help them to provision nodes from multiple regions/clouds, and run containers on top of them. Magnum could also provides APIs to relocate container (e.g. live migration) between nodes regardless of the underlying infrastructure.","commit_id":"f2c4c3eafcb5f89adfc9fa77d363c97756c445dd"},{"author":{"_account_id":11536,"name":"hongbin","email":"hongbin034@gmail.com","username":"hongbin"},"change_message_id":"e71c962b69a8583340f840bebe098bf8a2895f28","unresolved":false,"context_lines":[{"line_number":65,"context_line":"   on a given Nova instance, and when more need to be created. They want to"},{"line_number":66,"context_line":"   simply create and remove containers, and allow the appropriate resource"},{"line_number":67,"context_line":"   scheduling to happen automatically."},{"line_number":68,"context_line":"7. Platform Integration. Cloud operator already has an OpenStack cloud, and"},{"line_number":69,"context_line":"   wants to add a service/application centric management system on top."},{"line_number":70,"context_line":"   Examples of such systems are Cloud Foundry, Kubernetes, Apache Mesos, etc."},{"line_number":71,"context_line":"   The selected system is already Docker compatible. Allow this cloud operator"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7a016987_ecc81157","line":68,"in_reply_to":"1aca2d91_9db055df","updated":"2015-05-22 05:22:15.000000000","message":"The Magnum team discussed that in the Vancoucor summit this week. I think we agreed that connecting container to the underlying neutron network is the direction, but we need to investigate how to achieve that.","commit_id":"f2c4c3eafcb5f89adfc9fa77d363c97756c445dd"},{"author":{"_account_id":13900,"name":"Accela Zhao","email":"accelazh@gmail.com","username":"accelazh"},"change_message_id":"c98d1d44bc4a195384b1ebca8f486256bec514bb","unresolved":false,"context_lines":[{"line_number":65,"context_line":"   on a given Nova instance, and when more need to be created. They want to"},{"line_number":66,"context_line":"   simply create and remove containers, and allow the appropriate resource"},{"line_number":67,"context_line":"   scheduling to happen automatically."},{"line_number":68,"context_line":"7. Platform Integration. Cloud operator already has an OpenStack cloud, and"},{"line_number":69,"context_line":"   wants to add a service/application centric management system on top."},{"line_number":70,"context_line":"   Examples of such systems are Cloud Foundry, Kubernetes, Apache Mesos, etc."},{"line_number":71,"context_line":"   The selected system is already Docker compatible. Allow this cloud operator"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1aca2d91_9db055df","line":68,"in_reply_to":"3a961159_d1e37031","updated":"2015-05-20 06:37:09.000000000","message":"Container level overlay network managed by Magnum is an interesting point. However would this double the complexity of Openstack network management, and split Neutron who\u0027s overall in charge of network?\n\nAs for drawback (i) and (ii), if we connect container to the underlying neutron network, is it possible to unify the management of both VM and container networks, so that (i) and (ii) are avoided?","commit_id":"f2c4c3eafcb5f89adfc9fa77d363c97756c445dd"},{"author":{"_account_id":6348,"name":"xu-haiwei","email":"hai-xu@xr.jp.nec.com","username":"xu-haiwei"},"change_message_id":"fcb905ad0cfde2b53bb47cb48f99fa5c8df03f4b","unresolved":false,"context_lines":[{"line_number":115,"context_line":"   2.1. Fill them sequentially until full."},{"line_number":116,"context_line":"   2.2. Remove them automatically when they become empty."},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"The above orchestration will be implemented using Heat. This requires some "},{"line_number":119,"context_line":"kind of hypervisor painting (such as host aggregates) for security reasons."},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"The diagram below offers an overview of the system architecture. The OSC box"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_b7ddbe16","line":118,"updated":"2014-11-21 08:33:56.000000000","message":"ditto.","commit_id":"f2c4c3eafcb5f89adfc9fa77d363c97756c445dd"},{"author":{"_account_id":6348,"name":"xu-haiwei","email":"hai-xu@xr.jp.nec.com","username":"xu-haiwei"},"change_message_id":"fcb905ad0cfde2b53bb47cb48f99fa5c8df03f4b","unresolved":false,"context_lines":[{"line_number":274,"context_line":""},{"line_number":275,"context_line":"Contemplated features (in subsequent release cycles):"},{"line_number":276,"context_line":""},{"line_number":277,"context_line":"* Notify the end user each time a Nova instance is created or deleted by "},{"line_number":278,"context_line":"  the Containers service, if (s)he has registered for such notifications."},{"line_number":279,"context_line":"* Notify the user each on CRUD of containers containing start and end"},{"line_number":280,"context_line":"  notifications. (compute.container.create/delete/etc)"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_d7e08ace","line":277,"updated":"2014-11-21 08:33:56.000000000","message":"ditto.","commit_id":"f2c4c3eafcb5f89adfc9fa77d363c97756c445dd"}]}
