On Sat, Aug 13, 2016 at 5:18 PM, Alex Elder <elder@xxxxxxxx> wrote:
> On 08/12/2016 01:40 PM, Kamble, Nitin A wrote:
>>> It would make this a lot easier if we started generating a unique UUID
>>> >>> for the image and each snapshot at image/snapshot creation time. Jason?
>>> >>>
>>>>
>>>> Image UUID seems like the right direction.
>
> Yes. It's not a snapshot you want, but the basic image, regardless
> of the state of its content. It needs to be created at image
I'm not sure I follow. We need to have an identifier for each mappable
entity - that's images (HEADs) and snapshots.
> creation time, and no matter how many times the image grows or
> shrinks, or how the cluster gets reorganized along the way, that
> UUID uniquely defines the image (and it ought not to be possible,
> as a rule, to *change* an image's UUID). Coping an entire image
Why? IMO it shouldn't be any different from a filesystem UUID - a user
should be able to create an image (snapshot) with the specified UUID,
change it at any time and maybe even clear it (allowing clear makes
older images a non-issue). We already have an unchangeable pool-wide
ID for ourselves, this is aimed at users and they should be in full
control here.
> (or cloning) would require a new UUID (as has been said).
>
> I think the UUID should be defined independent of the cluster as
> well. In that case, there may be a reason to think about a "move"
> operation, where it an image is transferred to a new cluster, with
> the new one retaining the original UUID and the old one going away.
By default, it would be a randomly-generated UUID. What I had meant
when I said "we can couple it with a cluster UUID too" was that we can
export a cluster UUID along with an image UUID.
Thanks,
Ilya
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
