)]}'
{"specs/newton/approved/fs-attach-detach.rst":[{"author":{"_account_id":18788,"name":"Emile Snyder","email":"emsnyder@ebay.com","username":"emilesnyder"},"change_message_id":"931becbe3540ee17b8076fca550c6b4c2d89d5f9","unresolved":false,"context_lines":[{"line_number":61,"context_line":""},{"line_number":62,"context_line":"* Client needed to communicate with the Manila service."},{"line_number":63,"context_line":"* State saved in Nova database showing instance share attach state."},{"line_number":64,"context_line":"* Additional Nova config option to specify possible host to VM export "},{"line_number":65,"context_line":"  methods."},{"line_number":66,"context_line":"* Additional actions to the Nova action endpoint to attach, detach, and list"},{"line_number":67,"context_line":"  shares associated with specified instances."}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a122d0e_08c84521","line":64,"updated":"2016-04-27 17:25:28.000000000","message":"Is this something that needs to be explicitly configured in Nova deployment? I looked at image_type example Zhiteng pointed me at, and in that case it is configuration that Nova needs in order to talk to an external system.\n\nHere, what can be provided just depends on what software is present on the HV (do we have cephfs.ko, or ceph-fuse, or nfs-ganesha, or ... etc etc.)\n\nIs the primary purpose so that clients know which protocol/transport they can request the HV use to export shares to guest instances? But then they would need to be looking at host config for the instance they want to attach share to...","commit_id":"eca497c24a5b8a23b68eea104c4facdb0f8f106c"},{"author":{"_account_id":18788,"name":"Emile Snyder","email":"emsnyder@ebay.com","username":"emilesnyder"},"change_message_id":"1256d1ea9adf99e807d8cb78037a162a6d201309","unresolved":false,"context_lines":[{"line_number":61,"context_line":""},{"line_number":62,"context_line":"* Client needed to communicate with the Manila service."},{"line_number":63,"context_line":"* State saved in Nova database showing instance share attach state."},{"line_number":64,"context_line":"* Additional Nova config option to specify possible host to VM export "},{"line_number":65,"context_line":"  methods."},{"line_number":66,"context_line":"* Additional actions to the Nova action endpoint to attach, detach, and list"},{"line_number":67,"context_line":"  shares associated with specified instances."}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a122d0e_33e932b8","line":64,"in_reply_to":"1a122d0e_08c84521","updated":"2016-04-27 18:07:18.000000000","message":"I spoke too quickly, I see how the imagebackend code in general makes sense after reading more carefully.","commit_id":"eca497c24a5b8a23b68eea104c4facdb0f8f106c"},{"author":{"_account_id":18788,"name":"Emile Snyder","email":"emsnyder@ebay.com","username":"emilesnyder"},"change_message_id":"931becbe3540ee17b8076fca550c6b4c2d89d5f9","unresolved":false,"context_lines":[{"line_number":101,"context_line":""},{"line_number":102,"context_line":"Just as information about a Cinder volume integration with an instance is"},{"line_number":103,"context_line":"saved in the *block device mapping* (BDM) data structure, a new"},{"line_number":104,"context_line":"*filesystem mapping* (FSM) structure would need to be created."},{"line_number":105,"context_line":"This structure would be largely based on the current"},{"line_number":106,"context_line":"``nova.objects.BlockDeviceMapping`` class and its types."},{"line_number":107,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a122d0e_08004500","line":104,"updated":"2016-04-27 17:25:28.000000000","message":"In general I am leaning toward replacing \"filesystem\" with \"share\" everywhere; it seems more precise (we are talking specifically about Manila \u0027share\u0027s, not filesystems in general.) Opinions on the naming convention?","commit_id":"eca497c24a5b8a23b68eea104c4facdb0f8f106c"},{"author":{"_account_id":18788,"name":"Emile Snyder","email":"emsnyder@ebay.com","username":"emilesnyder"},"change_message_id":"931becbe3540ee17b8076fca550c6b4c2d89d5f9","unresolved":false,"context_lines":[{"line_number":112,"context_line":""},{"line_number":113,"context_line":".. code:: python"},{"line_number":114,"context_line":""},{"line_number":115,"context_line":"    class FileSystemDeviceType(Enum):"},{"line_number":116,"context_line":"        \"\"\""},{"line_number":117,"context_line":"        Represents possible device_type values"},{"line_number":118,"context_line":"        for a FileSystemMapping."}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a122d0e_8821f54f","line":115,"updated":"2016-04-27 17:25:28.000000000","message":"Is this supposed to convey more information than the share_proto field from the Manila share information? If so, what? If not... do we really need it?","commit_id":"eca497c24a5b8a23b68eea104c4facdb0f8f106c"},{"author":{"_account_id":18788,"name":"Emile Snyder","email":"emsnyder@ebay.com","username":"emilesnyder"},"change_message_id":"931becbe3540ee17b8076fca550c6b4c2d89d5f9","unresolved":false,"context_lines":[{"line_number":148,"context_line":"            \u0027instance_uuid\u0027: fields.UUIDField(),"},{"line_number":149,"context_line":"            \u0027instance\u0027: fields.ObjectField(\u0027Instance\u0027, nullable\u003dTrue),"},{"line_number":150,"context_line":"            \u0027device_type\u0027: fields.FileSystemDeviceTypeField(nullable\u003dTrue),"},{"line_number":151,"context_line":"            \u0027mount_point\u0027: fields.StringField(nullable\u003dTrue),"},{"line_number":152,"context_line":"            \u0027share_id\u0027: fields.StringField(nullable\u003dTrue),"},{"line_number":153,"context_line":"            \u0027connection_info\u0027: fields.StringField(nullable\u003dTrue),"},{"line_number":154,"context_line":"        }"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a122d0e_68c29986","line":151,"updated":"2016-04-27 17:25:28.000000000","message":"I think this name is too ambiguous, but I\u0027m not sure what to use instead. Existing examples below seem to indicate values like \"/net/myshare\", which I at first took to mean the path it should get mounted at inside the guest. But that doesn\u0027t make any sense, as the guest is free to mount it wherever they want.\n\nThen I was thinking this was intended to correspond to the path being exported by the host (assuming host is using NFS to re-export to guest,) so maybe something like /shares/$instance_id/$share_id would be more appropriate in example.)\n\nBut for 9P export I think it would correspond more to the $mount_tag referenced, eg, in http://wiki.qemu.org/Documentation/9psetup\n\nI\u0027m not sure what name captures both uses most clearly.","commit_id":"eca497c24a5b8a23b68eea104c4facdb0f8f106c"},{"author":{"_account_id":18788,"name":"Emile Snyder","email":"emsnyder@ebay.com","username":"emilesnyder"},"change_message_id":"931becbe3540ee17b8076fca550c6b4c2d89d5f9","unresolved":false,"context_lines":[{"line_number":150,"context_line":"            \u0027device_type\u0027: fields.FileSystemDeviceTypeField(nullable\u003dTrue),"},{"line_number":151,"context_line":"            \u0027mount_point\u0027: fields.StringField(nullable\u003dTrue),"},{"line_number":152,"context_line":"            \u0027share_id\u0027: fields.StringField(nullable\u003dTrue),"},{"line_number":153,"context_line":"            \u0027connection_info\u0027: fields.StringField(nullable\u003dTrue),"},{"line_number":154,"context_line":"        }"},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"        @base.remotable"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a122d0e_a8d5d1e5","line":153,"updated":"2016-04-27 17:25:28.000000000","message":"Need more detail about what exactly goes here? More structure?","commit_id":"eca497c24a5b8a23b68eea104c4facdb0f8f106c"},{"author":{"_account_id":18788,"name":"Emile Snyder","email":"emsnyder@ebay.com","username":"emilesnyder"},"change_message_id":"931becbe3540ee17b8076fca550c6b4c2d89d5f9","unresolved":false,"context_lines":[{"line_number":253,"context_line":"  {"},{"line_number":254,"context_line":"      \"share_attach\": {"},{"line_number":255,"context_line":"          \"share_id\": \"15e59938-07d5-11e1-90e3-e3dffe0c5983\","},{"line_number":256,"context_line":"          \"mount_point\": \"/net/mymount\","},{"line_number":257,"context_line":"      }"},{"line_number":258,"context_line":"  }"},{"line_number":259,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a122d0e_e8bb49c2","line":256,"updated":"2016-04-27 17:25:28.000000000","message":"I don\u0027t think we want this as an input. I think we want to specify what host\u003c-\u003eguest protocol \u0026 transport should be used (either directly, or by referencing some \"share export type\" configuration) and then the backend should fill this out as appropriate in the list shares response.\n\nWhatever is decided here, should be same (or array of same) up in create endpoint too, I think.","commit_id":"eca497c24a5b8a23b68eea104c4facdb0f8f106c"},{"author":{"_account_id":18788,"name":"Emile Snyder","email":"emsnyder@ebay.com","username":"emilesnyder"},"change_message_id":"931becbe3540ee17b8076fca550c6b4c2d89d5f9","unresolved":false,"context_lines":[{"line_number":281,"context_line":"| os-extended-           | plain      | csapi:dict  | Attached shares,      |"},{"line_number":282,"context_line":"| shares:shares_attached |            |             | if any                |"},{"line_number":283,"context_line":"+------------------------+------------+-------------+-----------------------+"},{"line_number":284,"context_line":""},{"line_number":285,"context_line":"Detach Share storage"},{"line_number":286,"context_line":"^^^^^^^^^^^^^^^^^^^^"},{"line_number":287,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a122d0e_28e9c1b7","line":284,"updated":"2016-04-27 17:25:28.000000000","message":"Give example JSON response, especially if we have more records here that  aren\u0027t passed in in the attach endpoint.","commit_id":"eca497c24a5b8a23b68eea104c4facdb0f8f106c"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6ec42a4bf5cfe93e56bed03bd9f25bb114c74e45","unresolved":false,"context_lines":[{"line_number":52,"context_line":""},{"line_number":53,"context_line":"In **hypervisor mediated access** hypervisors access Manila shares via a"},{"line_number":54,"context_line":"non-guest-accessible network, and expose the shares to the guests via a"},{"line_number":55,"context_line":"local mechanism such as libvirt/9p or virtio-vsock/NFS. This type of access"},{"line_number":56,"context_line":"is not possible without tighter Nova integration."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"Use Cases"}],"source_content_type":"text/x-rst","patch_set":5,"id":"bab6814e_4b71bd75","line":55,"range":{"start_line":55,"start_character":24,"end_line":55,"end_character":34},"updated":"2016-05-20 14:51:13.000000000","message":"I believe we\u0027ve reached agreement already that supporting 9p is not something we want to do, right? The libvirt people have objected (strenuously) and I object to the requirement to mount the filesystem on the host.","commit_id":"491955f8daee1ab2d220bb78843a4c2f3f498f81"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"455495aa879356b3b6a6a2666cd442a51eaa520d","unresolved":false,"context_lines":[{"line_number":52,"context_line":""},{"line_number":53,"context_line":"In **hypervisor mediated access** hypervisors access Manila shares via a"},{"line_number":54,"context_line":"non-guest-accessible network, and expose the shares to the guests via a"},{"line_number":55,"context_line":"local mechanism such as libvirt/9p or virtio-vsock/NFS. This type of access"},{"line_number":56,"context_line":"is not possible without tighter Nova integration."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"Use Cases"}],"source_content_type":"text/x-rst","patch_set":5,"id":"bab6814e_778bbb68","line":55,"range":{"start_line":55,"start_character":24,"end_line":55,"end_character":34},"in_reply_to":"bab6814e_3c563a5c","updated":"2016-05-20 16:53:20.000000000","message":"There\u0027s no intention to delete 9p from libvirt or QEMU upstream codebase. The issue is more subtle than that. The QEMU 9p code is essentially unmaintained at this point. While it works ok in terms of what it aimed todo, it isn\u0027t that great, particularly its permissioning model - since QEMU runs as an isolated user account, QEMU can\u0027t write any files except those writable by the \"qemu\" user. It might be ok for read-only use cases, but pretty sucky as a general pupose passthrough solution. Because of these issues, and in general the lack of desire to maintain yet another guest filesystem driver, there\u0027s no 9p support in RHEL distros. So even if we added it to openstack, its pretty worthless for all these reasons.\n\nThe virtio-vsock approach is much more appealing because it requires no new guest filesystem to be supported (it\u0027ll just use NFS), the host filesystem backend is potentially separate from QEMU (so isn\u0027t restricted by QEMU process permissions) and since it doesn\u0027t require much code in QEMU, ongoing maint work is minimal compared to 9p. The only issue is vsock-nfs isn\u0027t finished yet :-(","commit_id":"491955f8daee1ab2d220bb78843a4c2f3f498f81"},{"author":{"_account_id":18788,"name":"Emile Snyder","email":"emsnyder@ebay.com","username":"emilesnyder"},"change_message_id":"b1bf2af508c258181afa4496306f6acf46ee0d3b","unresolved":false,"context_lines":[{"line_number":52,"context_line":""},{"line_number":53,"context_line":"In **hypervisor mediated access** hypervisors access Manila shares via a"},{"line_number":54,"context_line":"non-guest-accessible network, and expose the shares to the guests via a"},{"line_number":55,"context_line":"local mechanism such as libvirt/9p or virtio-vsock/NFS. This type of access"},{"line_number":56,"context_line":"is not possible without tighter Nova integration."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"Use Cases"}],"source_content_type":"text/x-rst","patch_set":5,"id":"bab6814e_b964fc21","line":55,"range":{"start_line":55,"start_character":24,"end_line":55,"end_character":34},"in_reply_to":"bab6814e_4b71bd75","updated":"2016-05-20 16:38:03.000000000","message":"Sorry, I wasn\u0027t aware of the libvirt objections to 9p; mostly I had seen stuff from the ceph side. So is libvirt wanting to remove 9p support entirely?","commit_id":"491955f8daee1ab2d220bb78843a4c2f3f498f81"},{"author":{"_account_id":18788,"name":"Emile Snyder","email":"emsnyder@ebay.com","username":"emilesnyder"},"change_message_id":"2af33342eba9625331eab3867bed1be0e87b94fc","unresolved":false,"context_lines":[{"line_number":52,"context_line":""},{"line_number":53,"context_line":"In **hypervisor mediated access** hypervisors access Manila shares via a"},{"line_number":54,"context_line":"non-guest-accessible network, and expose the shares to the guests via a"},{"line_number":55,"context_line":"local mechanism such as libvirt/9p or virtio-vsock/NFS. This type of access"},{"line_number":56,"context_line":"is not possible without tighter Nova integration."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"Use Cases"}],"source_content_type":"text/x-rst","patch_set":5,"id":"bab6814e_ad2cb699","line":55,"range":{"start_line":55,"start_character":24,"end_line":55,"end_character":34},"in_reply_to":"bab6814e_778bbb68","updated":"2016-05-20 17:26:47.000000000","message":"That all makes sense to me. I\u0027ll update to make clear that 9p is just a POC backend option while waiting for vsock-nfs to land.\n\nBut that said, it seems like structuring the nova share-attach to be able to use different backends is a useful way to go even if, of the 2 existing options, one kind of sucks and the other isn\u0027t done yet.","commit_id":"491955f8daee1ab2d220bb78843a4c2f3f498f81"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"1b4efff4d66e71bdab5dcc26dd551c8aec6f4d9d","unresolved":false,"context_lines":[{"line_number":52,"context_line":""},{"line_number":53,"context_line":"In **hypervisor mediated access** hypervisors access Manila shares via a"},{"line_number":54,"context_line":"non-guest-accessible network, and expose the shares to the guests via a"},{"line_number":55,"context_line":"local mechanism such as libvirt/9p or virtio-vsock/NFS. This type of access"},{"line_number":56,"context_line":"is not possible without tighter Nova integration."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"Use Cases"}],"source_content_type":"text/x-rst","patch_set":5,"id":"bab6814e_3c563a5c","line":55,"range":{"start_line":55,"start_character":24,"end_line":55,"end_character":34},"in_reply_to":"bab6814e_b964fc21","updated":"2016-05-20 16:44:15.000000000","message":"No, I don\u0027t know anything about wanting to remove it. It was more objection to representing the 9p support as anything other than a toy.","commit_id":"491955f8daee1ab2d220bb78843a4c2f3f498f81"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6ec42a4bf5cfe93e56bed03bd9f25bb114c74e45","unresolved":false,"context_lines":[{"line_number":119,"context_line":"There are various possible mechanisms for exposing filesystems"},{"line_number":120,"context_line":"to guests, including:"},{"line_number":121,"context_line":""},{"line_number":122,"context_line":"* mounting on hypervisor and exposing via virtfs"},{"line_number":123,"context_line":"* having qemu access filesystem (e.g. using libcephfs) and expose over virtfs"},{"line_number":124,"context_line":"* mounting on hypervisor and exposing via knfsd+VSOCK"},{"line_number":125,"context_line":"* having nfs-ganesha access filesystem (e.g. using libcephfs) and expose"}],"source_content_type":"text/x-rst","patch_set":5,"id":"bab6814e_8bec45f4","line":122,"updated":"2016-05-20 14:51:13.000000000","message":"I don\u0027t think we should do this.","commit_id":"491955f8daee1ab2d220bb78843a4c2f3f498f81"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6ec42a4bf5cfe93e56bed03bd9f25bb114c74e45","unresolved":false,"context_lines":[{"line_number":123,"context_line":"* having qemu access filesystem (e.g. using libcephfs) and expose over virtfs"},{"line_number":124,"context_line":"* mounting on hypervisor and exposing via knfsd+VSOCK"},{"line_number":125,"context_line":"* having nfs-ganesha access filesystem (e.g. using libcephfs) and expose"},{"line_number":126,"context_line":"  NFS to guests via VSOCK"},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"All of these mechanisms should be hidden from Nova, using appropriate"},{"line_number":129,"context_line":"changes in libvirt.  For example, where an NFS daemon is involved, it"}],"source_content_type":"text/x-rst","patch_set":5,"id":"bab6814e_0bb7b5f5","line":126,"updated":"2016-05-20 14:51:13.000000000","message":"My understanding was that the VSOCK stuff is not done, ready, or exposed to us yet. Is that right? You don\u0027t list it as a dependency on the spec, but I thought that was the major blocking thing?","commit_id":"491955f8daee1ab2d220bb78843a4c2f3f498f81"},{"author":{"_account_id":18788,"name":"Emile Snyder","email":"emsnyder@ebay.com","username":"emilesnyder"},"change_message_id":"b1bf2af508c258181afa4496306f6acf46ee0d3b","unresolved":false,"context_lines":[{"line_number":123,"context_line":"* having qemu access filesystem (e.g. using libcephfs) and expose over virtfs"},{"line_number":124,"context_line":"* mounting on hypervisor and exposing via knfsd+VSOCK"},{"line_number":125,"context_line":"* having nfs-ganesha access filesystem (e.g. using libcephfs) and expose"},{"line_number":126,"context_line":"  NFS to guests via VSOCK"},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"All of these mechanisms should be hidden from Nova, using appropriate"},{"line_number":129,"context_line":"changes in libvirt.  For example, where an NFS daemon is involved, it"}],"source_content_type":"text/x-rst","patch_set":5,"id":"bab6814e_990ad888","line":126,"in_reply_to":"bab6814e_0bb7b5f5","updated":"2016-05-20 16:38:03.000000000","message":"You are correct, the VSOCK stuff is not done yet.","commit_id":"491955f8daee1ab2d220bb78843a4c2f3f498f81"},{"author":{"_account_id":2750,"name":"Sean Dague","email":"sean@dague.net","username":"sdague"},"change_message_id":"7dab816cafe04192b6836209cc98e3fe9e4d4481","unresolved":false,"context_lines":[{"line_number":132,"context_line":"Nova would not be aware.  Nova would not communicate directly with any"},{"line_number":133,"context_line":"extra software: it would send filesystem mappings to libvirt using the"},{"line_number":134,"context_line":"\u003cfilesystem\u003e tag in domain XML, and libvirt would handle convering this"},{"line_number":135,"context_line":"to the proper actions on the hypervisor node."},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"The various access mechanisms may have different behaviours in the face"},{"line_number":138,"context_line":"of failures such as service crashes or network outages, ranging from stalling"}],"source_content_type":"text/x-rst","patch_set":5,"id":"bab6814e_85b65fda","line":135,"updated":"2016-05-18 19:48:56.000000000","message":"what version of libvirt supports this? libvirt is managing a ganesha instance?","commit_id":"491955f8daee1ab2d220bb78843a4c2f3f498f81"},{"author":{"_account_id":18788,"name":"Emile Snyder","email":"emsnyder@ebay.com","username":"emilesnyder"},"change_message_id":"d13a6d0a4f3b2be8bed950383f55ea7327f4e77d","unresolved":false,"context_lines":[{"line_number":132,"context_line":"Nova would not be aware.  Nova would not communicate directly with any"},{"line_number":133,"context_line":"extra software: it would send filesystem mappings to libvirt using the"},{"line_number":134,"context_line":"\u003cfilesystem\u003e tag in domain XML, and libvirt would handle convering this"},{"line_number":135,"context_line":"to the proper actions on the hypervisor node."},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"The various access mechanisms may have different behaviours in the face"},{"line_number":138,"context_line":"of failures such as service crashes or network outages, ranging from stalling"}],"source_content_type":"text/x-rst","patch_set":5,"id":"bab6814e_7ea148a9","line":135,"in_reply_to":"bab6814e_85b65fda","updated":"2016-05-18 23:26:11.000000000","message":"Sorry, the \"should be hidden from Nova\" and \"appropriate changes in libvirt\" were meant to indicate that it isn\u0027t done there yet, but implementation would be at that level, not requiring Nova changes.","commit_id":"491955f8daee1ab2d220bb78843a4c2f3f498f81"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6ec42a4bf5cfe93e56bed03bd9f25bb114c74e45","unresolved":false,"context_lines":[{"line_number":410,"context_line":"to mount the shares on the host. This could be relatively low risk (using a"},{"line_number":411,"context_line":"a userspace client to access the share, and re-exporting it via userspace"},{"line_number":412,"context_line":"NFS server) to relatively higher risk (using a kernel module client to access"},{"line_number":413,"context_line":"the share, where a bug could have impacts on all guests running on the host.)"},{"line_number":414,"context_line":""},{"line_number":415,"context_line":"Notifications impact"},{"line_number":416,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"bab6814e_ebd19158","line":413,"updated":"2016-05-20 14:51:13.000000000","message":"I don\u0027t think that we should add any more situations where the host mounts something on behalf of the instance.","commit_id":"491955f8daee1ab2d220bb78843a4c2f3f498f81"}]}