<div dir="ltr">On 18 March 2015 at 03:33, Duncan Thomas <span dir="ltr"><<a href="mailto:duncan.thomas@gmail.com" target="_blank">duncan.thomas@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">On 17 March 2015 at 22:02, Davis, Amos (PaaS-Core) <span dir="ltr"><<a href="mailto:amos.steven.davis@hp.com" target="_blank">amos.steven.davis@hp.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ceph/Cinder:<br>
LVM or other?<br>
SCSI-backed?<br>
Any others?<br></blockquote><div><br></div></span><div>I'm wondering why any of the above matter to an application. </div></div></div></div></blockquote><div><br></div><div>The Neutron requirements list is the same.  Everything you've listed details implementation details with the exception of shared networks (which are a core feature, and so it's actually rather unclear what you had in mind there).<br><br>Implementation details should be hidden from cloud users - they don't care if I'm using ovs/vlan, and they don't care that I change my cloud one day to run ovs/vxlan, they only care that I deliver a cloud that will run their application - and since I care that I don't break applications when I make under the cover changes I will be thinking carefully about that too. I think you could develop a feature list, mind, just that you've not managed it here.<br><br>For instance: why is an LVM disk different from one on a Netapp when you're a cloud application and you always attach a volume via a VM?  Well, it basically isn't, unless there are features (like for instance a minimum TPS guarantee) that are different between the drivers.  Cinder's even stranger here, since you can have multiple backend drivers simultaneously and a feature may not be present in all of them.<br><br>Also, in Neutron, the current MTU and VLAN work is intended to expose some of those features to the app more than they were previously (e.g. 'can I use a large MTU on this network?'), but there are complexities in exposing this in advance of running the application.  The MTU size is not easy to discover in advance (it varies depending on what sort of network you're making), and what MTU you get for a specific network is very dependent on the network controller (network controllers can choose to not expose it at all, expose it with upper bounds in place, or expose it and try so hard to implement what the user requests that it's not immediately obvious whether a request will succeed or fail, for instance).  You could say 'you can ask for large MTU networks' - that is a straightforward feature - but some apps will fail to run if they ask and get declined.<br><br>This is not to say there isn't useful work that could be done here, just that there may be some limitations on what is possible.<br>-- <br></div><div>Ian.<br></div></div></div></div>