Open Stack

Hi Rob,

That is slightly different: from logical point of view that are
different schemas indeed, however they all map to the same DB schema,
so we do not have any issues with upgrades. There are some limitations
on the schema modifications as well, and being able to work with
multiple versions of the same artifact type is supported from the
beginning and works quite well.
--
Regards,
Alexander Tivelkov


On Mon, Feb 16, 2015 at 9:50 PM, Robert Collins
<robertc at robertcollins.net> wrote:
> On 17 February 2015 at 03:31, Alexander Tivelkov <ativelkov at mirantis.com> wrote:
>> Hi Client,
>>
>> Thanks for your input.
>>
>> We actually support the scenarios you speak about, yet in a slightly
>> different way.  The authors of the Artifact Type (the plugin
>> developers) may define their own custom field (or set of fields) to
>> store their "sequence" information or any other type-specific
>> version-related metadata. So, they may use generic version field
>> (which is defined in the base artifact type) to store their numeric
>> version - and use their type-specific field for local client-side
>> processing.
>
> That sounds scarily like what Neutron did, leading to a different
> schema for every configuration. The reason Clint brought up Debian
> version numbers is that to sort them in a database you need a custom
> field type - e.g.
> http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/database/schema/launchpad-2209-00-0.sql#L25
> . And thats quite a burden :)
>
> We've had fairly poor results with the Neutron variation in schemas,
> as it tightly couples things, making upgrades that change plugins
> super tricky, as well as making it very hard to concurrently support
> multiple plugins. I hope you don't mean you're doing the same thing :)
>
> -Rob
>
> --
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Converged Cloud
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev