Jay Pipes wrote:
> I'm not quite following you... the API doesn't have anything to do with the > backend storage implementation, either in the 1.x or 2.0 API. > Could you elaborate a bit more so I understand what you are referring to here? What I am arguing is that the mapping of API-visible objects to persistent storage is not exactly an "API" question it is also not just an "internals" question. That is because any implementation of the 2.0 Image Service will be required to support images that had been stored under the prior version. Requiring users to export all their images from a 1.0 system and then re-import then under 2.0 would be a good way to make sure that 2.0 was never installed by any existing customer. And the same will be true if there is ever a need to design a 2.1 API. So how the API concepts map to persistent storage is a public interface question. We need to understand how these objects are made persistent, how previous persistent images are mapped to the new object model (when an attribute did not previously exist, what default will be applied?, etc.) And we need to supply the information so the next round can determine how to support the "old" 2.0 format. For example, Sun documented both the API for the ZFS file system and the on-disk format. The on-disk format has been very stable. Reading the 2.0 API it is abundantly clear that the on-disk format is going to have to be enhanced. This needs to be documented as a persistent interface, not as an implementation detail. This could be an appendix to the API or a totally separate document. But it is important to recognize that the on-disk formats are not subject to change without notice. Indeed, any implementation plan that enhances the formatting of persistent data should really detail how older data will be supported, whether it is an install time upgrade, a first-use upgrade or 'missing data will be interpreted as follows'. There are two additional reasons why this information deserves treatment above being an "implementation detail": * Images can be stored using Swift. Understanding the division of responsibility for providing multiple locations is important. When should Glance create multiple images and when should it rely on Swift to do so? You don't want a situation where either both do it or neither does. Hybrids might also make sense, such as Glance dealing with each site and Swift handling multiple replicas within each site. * OEMs need some information to size Swift and/or local storage to support Glance. This strikes me as being fairly resource neutral, but I shouldn't have to read the code to determine that. Users deserve a warning that "upgrading to Image Service 2.0 will increase the amount of image overhead by about 3%". _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
