)]}'
{"specs/mitaka/approved/manila-support-in-metadata-service.rst":[{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"48657f22445112a806fa658894f43cd696f9810b","unresolved":false,"context_lines":[{"line_number":68,"context_line":"  clients are already present."},{"line_number":69,"context_line":"* A single endpoint (shares.json) is added to the Nova metadata service."},{"line_number":70,"context_line":"  Accessing this endpoint calls the Manila client to list shares available to"},{"line_number":71,"context_line":"  the tenant context making the request."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"Alternatives"},{"line_number":74,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba8a016a_e34f71bc","line":71,"updated":"2015-11-23 11:39:43.000000000","message":"I agree that exposing this kind of info via the metadata service makes sense. It is the only mechanism that is agnostic to the choice of guest OS and/or hypervisor.\n\nYou will need to supply much more detail in this spec though. Any data we expose via the metadata service becomes an ABI that we need to preserve compatibility for long term, so must be carefully designed \u0026 understood to ensure future extensibility. Specifically you need to illustrate the JSON data format to be exposed, and provide a corresponding JSON schema for.","commit_id":"094c109a18eeb3ff38b84a061b70750c9338a29e"},{"author":{"_account_id":11865,"name":"Clinton Knight","email":"cknight@netapp.com","username":"cknight"},"change_message_id":"e89f6e7e5534ee7ee52d7b04ffca9fcc7d37de14","unresolved":false,"context_lines":[{"line_number":68,"context_line":"  clients are already present."},{"line_number":69,"context_line":"* A single endpoint (shares.json) is added to the Nova metadata service."},{"line_number":70,"context_line":"  Accessing this endpoint calls the Manila client to list shares available to"},{"line_number":71,"context_line":"  the tenant context making the request."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"Alternatives"},{"line_number":74,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9a8ffd7b_7a31090b","line":71,"in_reply_to":"ba8a016a_e34f71bc","updated":"2015-11-24 21:19:19.000000000","message":"In Patch Set 2, I have included a sample of the data returned, as well as a corresponding schema.","commit_id":"094c109a18eeb3ff38b84a061b70750c9338a29e"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"1da5272d70274e808dee3c60167d005a36ab4ce0","unresolved":false,"context_lines":[{"line_number":69,"context_line":"* A single endpoint (shares.json) is added to the Nova metadata service."},{"line_number":70,"context_line":"  Accessing this endpoint calls the Manila client to list shares available to"},{"line_number":71,"context_line":"  the tenant context making the request."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"Alternatives"},{"line_number":74,"context_line":"------------"},{"line_number":75,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_68b322ea","line":72,"updated":"2015-11-26 12:00:07.000000000","message":"After thinking about this some more, I think we have a gap that needs addressing before we consider this proposal.\n\nWith block devices, when you boot a guest you provide Nova with information about the block device mapping for the guest instance. There is currently no equivalent to this for filesystem shares. I think we need to provide this functionality before we then go to expose information to the guest OS.\n\nThere is another blueprint that is describing the API functionality for associating shares with Nova instance, that is tackling this problem\n\nhttps://review.openstack.org/#/c/249582/3/specs/mitaka/approved/fs-attach-detach.rst\n\nThat would be a prerequisite of this spec IMHO.","commit_id":"4aed7a53b64b6800772fb6cb18436a65482cea4f"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"25433aac70b848f3271bfa9f3b76d16c116e95bd","unresolved":false,"context_lines":[{"line_number":69,"context_line":"* A single endpoint (shares.json) is added to the Nova metadata service."},{"line_number":70,"context_line":"  Accessing this endpoint calls the Manila client to list shares available to"},{"line_number":71,"context_line":"  the tenant context making the request."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"Alternatives"},{"line_number":74,"context_line":"------------"},{"line_number":75,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_93a9c592","line":72,"in_reply_to":"9a8ffd7b_30456fb2","updated":"2015-11-26 16:38:14.000000000","message":"Once we add support to the metadata service for this, Nova is making a commitment to support this guest ABI thereafter. I\u0027m pretty wary of making such commitment before Nova formally represents this stuff in its DB and instance boot APIs, because I think it will complicate future work \u0026 nova version upgrades in this area if Nova does not have a record of what it is exposing to the guest in its DB from the start.","commit_id":"4aed7a53b64b6800772fb6cb18436a65482cea4f"},{"author":{"_account_id":11865,"name":"Clinton Knight","email":"cknight@netapp.com","username":"cknight"},"change_message_id":"02b7bec144d2d8cb9ac47762e56e4415aa31601a","unresolved":false,"context_lines":[{"line_number":69,"context_line":"* A single endpoint (shares.json) is added to the Nova metadata service."},{"line_number":70,"context_line":"  Accessing this endpoint calls the Manila client to list shares available to"},{"line_number":71,"context_line":"  the tenant context making the request."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"Alternatives"},{"line_number":74,"context_line":"------------"},{"line_number":75,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_30456fb2","line":72,"in_reply_to":"9a8ffd7b_5d160c4d","updated":"2015-11-26 16:25:35.000000000","message":"I\u0027m glad to work with Luis on the FSDM definition.  But why can\u0027t the metadata service solution be workable independent of the Nova attach/detach feature?  In Vancouver I demoed a CloudInit script that can query all available shares for the instance tenant and mount them.","commit_id":"4aed7a53b64b6800772fb6cb18436a65482cea4f"},{"author":{"_account_id":11865,"name":"Clinton Knight","email":"cknight@netapp.com","username":"cknight"},"change_message_id":"f15728c7c096725d0fb247cedef33947076e2a35","unresolved":false,"context_lines":[{"line_number":69,"context_line":"* A single endpoint (shares.json) is added to the Nova metadata service."},{"line_number":70,"context_line":"  Accessing this endpoint calls the Manila client to list shares available to"},{"line_number":71,"context_line":"  the tenant context making the request."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"Alternatives"},{"line_number":74,"context_line":"------------"},{"line_number":75,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_a0d5961c","line":72,"in_reply_to":"9a8ffd7b_68b322ea","updated":"2015-11-26 15:13:58.000000000","message":"The Manila team is fully supportive of both of these specs (if not completely aligned on the fine details), and we view them as complementary.  If we can define a minimal \u0027File System Device Mapping\u0027 structure that works for both of these solutions, that\u0027s obviously ideal.  I took a stab at that below, which is close to your comments in the other spec.","commit_id":"4aed7a53b64b6800772fb6cb18436a65482cea4f"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"10deada78512eb26374e9eea4dd077cdfd2fae43","unresolved":false,"context_lines":[{"line_number":69,"context_line":"* A single endpoint (shares.json) is added to the Nova metadata service."},{"line_number":70,"context_line":"  Accessing this endpoint calls the Manila client to list shares available to"},{"line_number":71,"context_line":"  the tenant context making the request."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"Alternatives"},{"line_number":74,"context_line":"------------"},{"line_number":75,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_5d160c4d","line":72,"in_reply_to":"9a8ffd7b_a0d5961c","updated":"2015-11-26 15:58:37.000000000","message":"Ok, but the first step I think needs to be accepting this File System Mapping in the nova instance boot API and recording it in the Nova database associated with the instance.  We can\u0027t simply query it directly from Manilla as we need to have the ability to specify extra per-instance data with it at boot time, for example the way in which it is exposed to the guest OS (nfs, vs virtio-9p vs something else).","commit_id":"4aed7a53b64b6800772fb6cb18436a65482cea4f"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"1da5272d70274e808dee3c60167d005a36ab4ce0","unresolved":false,"context_lines":[{"line_number":90,"context_line":"universally applicable, so the Manila team prefers to begin with one that"},{"line_number":91,"context_line":"would seem to have the most appeal and be most broadly implementable.  The"},{"line_number":92,"context_line":"solution proposed herein would work for all guest types and require minimal"},{"line_number":93,"context_line":"effort by deployers and tenants."},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"Data model impact"},{"line_number":96,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_c8e32ea3","line":93,"updated":"2015-11-26 12:00:07.000000000","message":"Again after thinking some more and talking with other people, i think we need to consider multiple solutions.\n\nThe proposed approach of making share information available via the metadata service, and having the tenant attached to a network that is shared with manilla is certainly workable as a generic solution.\n\nThe requirement to have a shared between between the guest and manilla though is going to be show stopper for some people from a security POV. As such it is inevitable that we\u0027ll need to have hypervisor-mediated attachments in the future. With KVM that would be virtio-nfs over vsock, or virtio-9p. Other hypervisors have equivalent solutions.\n\nSo while it is reasonable to start with the generic solution only, our design needs to bear in mind that we\u0027ll need to have a hypervisor mediated solution in the future.  This further re-inforces the need to have the instance shares mapping provided to Nova at instance boot time, via the API, in the same way we provide the Cinder block device mapping","commit_id":"4aed7a53b64b6800772fb6cb18436a65482cea4f"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"10deada78512eb26374e9eea4dd077cdfd2fae43","unresolved":false,"context_lines":[{"line_number":90,"context_line":"universally applicable, so the Manila team prefers to begin with one that"},{"line_number":91,"context_line":"would seem to have the most appeal and be most broadly implementable.  The"},{"line_number":92,"context_line":"solution proposed herein would work for all guest types and require minimal"},{"line_number":93,"context_line":"effort by deployers and tenants."},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"Data model impact"},{"line_number":96,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_da9762ea","line":93,"in_reply_to":"9a8ffd7b_002b4295","updated":"2015-11-26 15:58:37.000000000","message":"That should have said \"network\", eg\n\n\"The requirement to have a shared network between between the guest and manilla\"","commit_id":"4aed7a53b64b6800772fb6cb18436a65482cea4f"},{"author":{"_account_id":11865,"name":"Clinton Knight","email":"cknight@netapp.com","username":"cknight"},"change_message_id":"f15728c7c096725d0fb247cedef33947076e2a35","unresolved":false,"context_lines":[{"line_number":90,"context_line":"universally applicable, so the Manila team prefers to begin with one that"},{"line_number":91,"context_line":"would seem to have the most appeal and be most broadly implementable.  The"},{"line_number":92,"context_line":"solution proposed herein would work for all guest types and require minimal"},{"line_number":93,"context_line":"effort by deployers and tenants."},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"Data model impact"},{"line_number":96,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_002b4295","line":93,"in_reply_to":"9a8ffd7b_c8e32ea3","updated":"2015-11-26 15:13:58.000000000","message":"\u0027requirement to have a shared ??? between the guest and manila\u0027\n\nWas there a missing word there?  I\u0027m trying to understand the concern.\n\nBut no argument on hypervisor-mediated attachments, and we\u0027re grateful the Nova team is receptive.  We considered that early in Manila, but the Plan 9 stuff was just too immature.  The vsock work that the Red Hat guys are doing looks very promising.","commit_id":"4aed7a53b64b6800772fb6cb18436a65482cea4f"},{"author":{"_account_id":11865,"name":"Clinton Knight","email":"cknight@netapp.com","username":"cknight"},"change_message_id":"02b7bec144d2d8cb9ac47762e56e4415aa31601a","unresolved":false,"context_lines":[{"line_number":90,"context_line":"universally applicable, so the Manila team prefers to begin with one that"},{"line_number":91,"context_line":"would seem to have the most appeal and be most broadly implementable.  The"},{"line_number":92,"context_line":"solution proposed herein would work for all guest types and require minimal"},{"line_number":93,"context_line":"effort by deployers and tenants."},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"Data model impact"},{"line_number":96,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_b05b9ff5","line":93,"in_reply_to":"9a8ffd7b_da9762ea","updated":"2015-11-26 16:25:35.000000000","message":"FWIW, Manila supports isolated, per-tenant overlay networks via Neutron, which can alleviate security concerns.  But yes, others will prefer the planned hypervisor-mediated solution.","commit_id":"4aed7a53b64b6800772fb6cb18436a65482cea4f"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"556efd6631f6b4715635b6e5b426885a6f3a1549","unresolved":false,"context_lines":[{"line_number":116,"context_line":""},{"line_number":117,"context_line":"   GET /v2/\u003ctenant_id\u003e/shares/detail"},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"The returned data conforms to the following example::"},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"   {"},{"line_number":122,"context_line":"      \u0027shares\u0027: [{"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_dadb3e1a","line":119,"updated":"2015-11-25 09:42:39.000000000","message":"I really don\u0027t think we want to pass the manilla API data through to the guest unmodified like this. There is a bunch of information here that I think the guest OS has no business knowing about.\n\nThe guest OS should be given *only* the minimum information it requires in order to make use of the filesystem share.\n\nIn addition, looking to the future where we make use of virtio-9p or virtio-nfs to allow the filesystem to be accessed via a host channel, rather than over network, we are going to need to transform the data from Manilla before giving it to the guest. eg Manilla might expose NFS, but we would expose virtio-9p to the guest, and proxy that to NFS in the host.\n\nSo please write up a JSON schema dedicated for exposing info the guest in a portable manner","commit_id":"4aed7a53b64b6800772fb6cb18436a65482cea4f"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"10deada78512eb26374e9eea4dd077cdfd2fae43","unresolved":false,"context_lines":[{"line_number":116,"context_line":""},{"line_number":117,"context_line":"   GET /v2/\u003ctenant_id\u003e/shares/detail"},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"The returned data conforms to the following example::"},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"   {"},{"line_number":122,"context_line":"      \u0027shares\u0027: [{"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_dd843c5f","line":119,"in_reply_to":"9a8ffd7b_ba2dc3ff","updated":"2015-11-26 15:58:37.000000000","message":"So the FSDM data structure I described would be something used in the nova API and Nova database. This would certainly influence the data format we expose via the metadata service, but they would not be the exact same data. As an example at a Nova API level we would want the ID, and not the Locations data. Given an ID, Nova would query Manilla to get the actual locations data. Similar with Cinder, Nova gets a volume ID and queries Cinder to get info on how to access the volume.","commit_id":"4aed7a53b64b6800772fb6cb18436a65482cea4f"},{"author":{"_account_id":11865,"name":"Clinton Knight","email":"cknight@netapp.com","username":"cknight"},"change_message_id":"f15728c7c096725d0fb247cedef33947076e2a35","unresolved":false,"context_lines":[{"line_number":116,"context_line":""},{"line_number":117,"context_line":"   GET /v2/\u003ctenant_id\u003e/shares/detail"},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"The returned data conforms to the following example::"},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"   {"},{"line_number":122,"context_line":"      \u0027shares\u0027: [{"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_ba2dc3ff","line":119,"in_reply_to":"9a8ffd7b_dadb3e1a","updated":"2015-11-26 15:13:58.000000000","message":"Fair enough.  To continue the discussion, I\u0027ve pared the data back to the absolute minimum needed to make the solution work, so it\u0027s much easier to generalize to other mechanisms that might support the proposed endpoint.\n\nI think we can live with just four fields in the \u0027File System Device Mapping\u0027:\n\n* ID uniquely identifies the filesystem and can be used to auto-generate mount points.\n* Protocol tells the guest how to mount the share.  It could be nfs, cifs, virtio-nfs, etc.\n* Locations contains the protocol-specific data for mounting the share.  For NFS or CIFS it is a network path.  But it could just as easily be a local path, or a device path, etc.  Locations is an array because some network protocols expose a share on multiple paths, ordered by preference.\n* Metadata is user-provided info that allows a small measure of customization, such as specifying a mount point to use on the guest.","commit_id":"4aed7a53b64b6800772fb6cb18436a65482cea4f"}]}