Open Stack

On 18 March 2015 at 03:33, Duncan Thomas <duncan.thomas at gmail.com> wrote:

> On 17 March 2015 at 22:02, Davis, Amos (PaaS-Core) <
> amos.steven.davis at hp.com> wrote:
>
>> Ceph/Cinder:
>> LVM or other?
>> SCSI-backed?
>> Any others?
>>
>
> I'm wondering why any of the above matter to an application.
>

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).

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.

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.

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.

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.
-- 
Ian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150318/7b4b10d9/attachment.html>