Open Stack

On Wed, Mar 23, 2016 at 2:33 PM, Vega Cai <luckyvega.g at gmail.com> wrote:
>
>
> On 22 March 2016 at 12:09, Shinobu Kinjo <shinobu.kj at gmail.com> wrote:
>>
>> Thank you for your comment (inline for my message).
>>
>> On Tue, Mar 22, 2016 at 11:53 AM, Vega Cai <luckyvega.g at gmail.com> wrote:
>> > Let me try to explain some.
>> >
>> > On 22 March 2016 at 10:09, Shinobu Kinjo <shinobu.kj at gmail.com> wrote:
>> >>
>> >> On Tue, Mar 22, 2016 at 10:22 AM, joehuang <joehuang at huawei.com> wrote:
>> >> > Hello, Shinobu,
>> >> >
>> >> > Yes, as what you described here, the "initialize" in "core.py" is
>> >> > used
>> >> > for unit/function test only. For system integration test( for
>> >> > example,
>> >> > tempest ), it would be better to use mysql like DB, this is done by
>> >> > the
>> >> > configuration in DB part.
>> >>
>> >> Thank you for your thought.
>> >>
>> >> >
>> >> > From my point of view, the tricircle DB part could be enhanced in the
>> >> > DB
>> >> > model and migration scripts. Currently unit test use DB model to
>> >> > initialize
>> >> > the data base, but not using the migration scripts,
>> >>
>> >> I'm assuming the migration scripts are in "tricircle/db". Is it right?
>> >
>> >
>> > migration scripts are in tricircle/db/migrate_repo
>> >>
>> >>
>> >> What is the DB model?
>> >> Why do we need 2-way-methods at the moment?
>> >
>> >
>> > DB models are defined in tricircle/db/models.py. Models.py defines
>> > tables in
>> > object level, so other modules can import models.py then operate the
>> > tables
>> > by operating the objects. Migration scripts defines tables in table
>> > level,
>> > you define table fields, constraints in the scripts then migration tool
>> > will
>> > read the scripts and build the tables.
>>
>> Dose "models.py" manage database schema(e.g., create / delete columns,
>> tables, etc)?
>
>
> In "models.py" we only define database schema. SQLAlchemy provides
> functionality to create tables based on schema definition, which is
> "ModelBase.metadata.create_all". This is used to initialized the in-memory
> database for tests currently.
>>
>>
>> > Migration tool has a feature to
>> > generate migration scripts from DB models automatically but it may make
>> > mistakes sometimes, so currently we manually maintain the table
>> > structure in
>> > both DB model and migration scripts.
>>
>> Is *migration tool* different from bot DB models and migration scripts?
>
>
> Migration tool is Alembic, a lightweight database migration tool for usage
> of SQLAlchemy:
>
> https://alembic.readthedocs.org/en/latest/
>
> It runs migration scripts to update database schema. Each database version
> has one migrate script. After defining "upgrade" and "downgrade" method in
> the script, you can update your database from one version to another
> version. Alembic isn't aware of DB models defined in "models.py", users need
> to guarantee the version of database and the version of "models.py" match.
>
> If you create a new database, both "ModelBase.metadata.create_all" and
> Alembic can be used. But Alembic can also be used to update an existing
> database to a specific version of schema.

Thank you for your additional explanation.
Those inputs save my life.

Cheers,
S

>>
>>
>> >>
>> >>
>> >> > so the migration scripts can only be tested when using devstack for
>> >> > integration test. It would better to using migration script to
>> >> > instantiate
>> >> > the DB, and tested in the unit test too.
>> >>
>> >> If I understand you correctly, we are moving forward to using the
>> >> migration scripts for both unit and integration tests.
>> >>
>> >> Cheers,
>> >> Shinobu
>> >>
>> >> >
>> >> > (Also move the discussion to the openstack-dev mail-list)
>> >> >
>> >> > Best Regards
>> >> > Chaoyi Huang ( joehuang )
>> >> >
>> >> > -----Original Message-----
>> >> > From: Shinobu Kinjo [mailto:skinjo at redhat.com]
>> >> > Sent: Tuesday, March 22, 2016 7:43 AM
>> >> > To: joehuang; khayam.gondal; zhangbinsjtu; shipengfei92; newypei;
>> >> > Liuhaixia; caizhiyuan (A); huangzhipeng
>> >> > Subject: Using in-memory database for unit tests
>> >> >
>> >> > Hello,
>> >> >
>> >> > In "initialize" method defined in "core.py", we're using *in-memory*
>> >> > strategy making use of sqlite. AFAIK we are using this solution for
>> >> > only
>> >> > testing purpose. Unit tests using this solution should be fine for
>> >> > small
>> >> > scale environment. But it's not good enough even it's for testing.
>> >> >
>> >> > What do you think?
>> >> > Any thought, suggestion would be appreciated.
>> >> >
>> >> > [1]
>> >> >
>> >> > https://github.com/openstack/tricircle/blob/master/tricircle/db/core.py#L124-L127
>> >> >
>> >> > Cheers,
>> >> > Shinobu
>> >> >
>> >> >
>> >> > __________________________________________________________________________
>> >> > 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
>> >>
>> >>
>> >>
>> >> --
>> >> Email:
>> >> shinobu at linux.com
>> >> GitHub:
>> >> shinobu-x
>> >> Blog:
>> >> Life with Distributed Computational System based on OpenSource
>> >>
>> >>
>> >> __________________________________________________________________________
>> >> 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
>> >
>> >
>> >
>> >
>> > __________________________________________________________________________
>> > 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
>> >
>>
>>
>>
>> --
>> Email:
>> shinobu at linux.com
>> GitHub:
>> shinobu-x
>> Blog:
>> Life with Distributed Computational System based on OpenSource
>>
>> __________________________________________________________________________
>> 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
>
>
>
> __________________________________________________________________________
> 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
>



-- 
Email:
shinobu at linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource