On Tue, Sep 22, 2015 at 01:32:49PM -0400, Jason Dillaman wrote:

> > > * rbd mirror pool enable <pool-name>
> > >         This will, by default, ensure that all images created in this
> > >         pool have exclusive lock, journaling, and mirroring feature bits
> > >         enabled.
> > > 
> > > * rbd mirror pool disable <pool-name>
> > >         This will clear the default image features for new images in this
> > >         pool.
> > 
> > Will 'rbd mirror pool enable|disable' change behaviour only for newly
> > created images in the pool or will enable|disable mirroring for
> > existent images too?
>
> Since the goal is to set default pool behavior, it would only apply
> to newly created images.  You can enable/disable on specific images
> using the 'rbd mirror image enable/disable' commands.

In this case the commands look a little confusing to me, as from their
names I would rather think they enable/disable mirror for existent
images too. Also, I don't see a command to check what current
behaviour is. And, I suppose it would be useful if we could configure
other default features for a pool (exclusive-lock, object-map, ...)
Also, I am not sure we should specify <pool-name> this way, as it is
not consistent with other rbd commands. By default rbd operates on
'rbd' pool, which can be changed by --pool option. So what do you
think if we have something similar to 'rbd feature' commands?

  rbd [--pool <pool>] default-feature enable <feature>
  rbd [--pool <pool>] default-feature disable <feature>
  rbd [--pool <pool>] default-feature show [<feature>]

(If <feature> is not specified in the last command, all features are
shown).

Similarly, it might be useful to have 'rbd feature show' command:

  rbd feature show <image-spec> [<feature>]

BTW, where do you think these default feature flags will be stored?
Storing in pg_pool_t::flags I suppose is the easiest but it looks like
a layering violation.

-- 
Mykola Golub
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to