<div dir="ltr">Here's a possibly relevant use case for this discussion:<div><br><div>1) Running Icehouse OpenStack</div></div><div>2) Keystone reports v3.0 auth capabilities</div><div>3) If you actually use the v3.0 auth, then any nova call that gets passed through to cinder fails due to the code in Icehouse being unable to parse the 3.0 service catalog format</div><div><br></div><div>Due to the limited ability to interrogate OpenStack and determine what is running, we have to auth with v3, and then make a volume related nova call and see if it fails. Afterward we can go down code paths to work around the OS bugs in the presumed version. If a more robust API for determining the running components and their capabilities were available, this would be an easier situation to deal with.</div><div><br></div><div>The main point of this is that a capabilities API requires an absolute flawless implementation to be sufficient. It fails if a capability is reported as available, but the implementation in that particular release has a bug. The version of implementation code also needs to be exposed through the API for consumers to be able to know when issues are present and work around them.</div><div><br></div><div>-Andrew</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 18, 2015 at 1:38 PM, Ian Wells <span dir="ltr"><<a href="mailto:ijw.ubuntu@cack.org.uk" target="_blank">ijw.ubuntu@cack.org.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="">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></span><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"><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><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></span><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.<span class="HOEnZb"><font color="#888888"><br>-- <br></font></span></div><span class="HOEnZb"><font color="#888888"><div>Ian.<br></div></font></span></div></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Andrew Mann<div>DivvyCloud Inc.</div><div><a href="http://www.divvycloud.com" target="_blank">www.divvycloud.com</a></div></div></div>
</div>