Open Stack

"Walter A. Boring IV" <walter.boring at hp.com> wrote on 05/20/2013 09:30:57
PM:
> On 05/18/2013 03:14 PM, Duncan Thomas wrote:
> > On 15 May 2013 06:22, John Griffith <john.griffith at solidfire.com>
wrote:
> >
> >> What I had in mind for Cinder, was the addition of of a
property/column in
> >> the Volume object.  This would be a Read Only flag.  The use casehere
would
> >> be that a tenant could take a volume that they've populated with data
and
> >> set it to R/O explicitly.  This would mean providing an API call to
enabled
> >> setting and clearing of this flag of course.
> > This seems like a useful feature
> >
> >> In addition, I'd like to modify the cinder attach code, so that if for
> >> example a volume is "in use" attached to an instance, and a subsequent
> >> attach was requested, rather than failing stating that the volume must
be
> >> available, we allow the attach however set it as Read Only.  This
would be
> >> the default behavior, if we get to a point where we are interested in
> >> multiple attach R/W (which is quite frankly rather scary to me) I
would
> >> propose that there explicit settings a user must request to do
> this and that
> >> it's done via extension or disabled by default via the cinder.conf
file.
> > I think that doing a read-only attach rather than failing the attach
> > by default is a /really/ bad idea... for most filesystems, that mount
> > is going to be entirely useless if there is a R/W mount in existance,
> > and it is going to lead to read corruption in surprising ways. The
> > current behaviour is far in preference to that.
> >
> > Any form of multi-attach should only happen if specifically requested,
> > and come with 'here be dragons' warnings...
> I agree with this as well.   I think it's a bad idea to default to read
> only.
> It's a safer bet to only do read only mount if requested.


Agree as well.

Thanks,
Avishay