>> This is going to get horribly ugly when you add neutron into the mix, so
>> much so I'd consider this option a non-starter. If someone is using
>> openvswitch to create network overlays to isolate each tenant I can't
>> imagine this ever working.
>
> I'm not following here. Are this only needed
On Wed, 23 Oct 2013, Kyle Bader wrote:
>
> Option 1) The service plugs your filesystem's IP into the VM's
> network
> and provides direct IP access. For a shared box (like an NFS
> server)
> this is fairly straightforward and works well (*everything* has
> a
>
On 10/23/2013 01:47 PM, Dimitri Maziuk wrote:
On 10/23/2013 12:53 PM, Gregory Farnum wrote:
On Wed, Oct 23, 2013 at 7:43 AM, Dimitri Maziuk wrote:
On 2013-10-22 22:41, Gregory Farnum wrote:
...
Right now, unsurprisingly, the focus of the existing Manila developers
is on Option 1: it's less w
> Option 1) The service plugs your filesystem's IP into the VM's network
> and provides direct IP access. For a shared box (like an NFS server)
> this is fairly straightforward and works well (*everything* has a
> working NFS client). It's more troublesome for CephFS, since we'd need
> to include a
On 10/23/2013 12:53 PM, Gregory Farnum wrote:
> On Wed, Oct 23, 2013 at 7:43 AM, Dimitri Maziuk wrote:
>> On 2013-10-22 22:41, Gregory Farnum wrote:
>> ...
>>
>>> Right now, unsurprisingly, the focus of the existing Manila developers
>>> is on Option 1: it's less work than the others and supports
On Wed, Oct 23, 2013 at 7:43 AM, Dimitri Maziuk wrote:
> On 2013-10-22 22:41, Gregory Farnum wrote:
> ...
>
>> Right now, unsurprisingly, the focus of the existing Manila developers
>> is on Option 1: it's less work than the others and supports the most
>> common storage protocols very well. But a
On 2013-10-22 22:41, Gregory Farnum wrote:
...
Right now, unsurprisingly, the focus of the existing Manila developers
is on Option 1: it's less work than the others and supports the most
common storage protocols very well. But as mentioned, it would be a
pretty poor fit for CephFS
I must be mis
