Re: [openstack-dev] [Ceilometer] Need help with Alembic...
Jay - It looks there is an error in the migration script that causes it to abort: AttributeError: 'ForeignKeyConstraint' object has no attribute 'drop' My guess is the migration runs on the first test, creates event types table fine, but exits with the above error, so migration is not complete. Thus every subsequent test tries to migrate the db, and notices that event types already exists. -john On 8/26/13 1:15 PM, Jay Pipes jaypi...@gmail.com wrote: I just noticed that every single test case for SQL-driver storage is executing every single migration upgrade before every single test case run: https://github.com/openstack/ceilometer/blob/master/ceilometer/tests/db.py #L46 https://github.com/openstack/ceilometer/blob/master/ceilometer/storage/imp l_sqlalchemy.py#L153 instead of simply creating a new database schema from the models in the current source code base using a call to sqlalchemy.MetaData.create_all(). This results in re-running migrations over and over again, instead of having dedicated migration tests that would test each migration individually, as is the case in projects like Glance... Is this intentional? Best, -jay On 08/26/2013 02:59 PM, Sandy Walsh wrote: I'm getting the same problem with a different migration (mine is complaining that a column already exists) http://paste.openstack.org/show/44512/ I've compared it to the other migrations and it seems fine. -S On 08/26/2013 02:34 PM, Jay Pipes wrote: Hey all, I'm trying to figure out what is going wrong with my code for this patch: https://review.openstack.org/41316 I had previously added a sqlalchemy-migrate migration script to add an event_type table, and had that working, but then was asked to instead use Alembic for migrations. So, I removed the sqlalchemy-migrate migration file and added an Alembic migration [1]. Unfortunately, I am getting the following error when running tests: OperationalError: (OperationalError) table event_type already exists u'\nCREATE TABLE event_type (\n\tid INTEGER NOT NULL, \n\tdesc VARCHAR(255), \n\tPRIMARY KEY (id), \n\tUNIQUE (desc)\n)\n\n' () The migration adds the event_type table. I've seen this error occur before when using SQLite due to SQLite's ALTER TABLE statement not allowing the rename of a column. In the sqlalchemy-migrate migration, I had a specialized SQLite migration upgrade [2] and downgrade [3] script, but I'm not sure how I am supposed to handle this in Alembic. Could someone help me out? Thanks, -jay [1] https://review.openstack.org/#/c/41316/16/ceilometer/storage/sqlalchemy/ alembic/versions/49036dfd_add_event_types.py [2] https://review.openstack.org/#/c/41316/14/ceilometer/storage/sqlalchemy/ migrate_repo/versions/013_sqlite_upgrade.sql [3] https://review.openstack.org/#/c/41316/14/ceilometer/storage/sqlalchemy/ migrate_repo/versions/013_sqlite_downgrade.sql ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev smime.p7s Description: S/MIME cryptographic signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ceilometer] Adding TraitType Storage Model
Hi - After discussion with Jay Pipes about this bug (https://bugs.launchpad.net/ceilometer/+bug/1211015), I'd like to split out a new TraitType table in the storage layer, and remove the UniqueName table. A TraitType is the name of the trait and the data type (i.e., string, int, floatĀ). I'd like to get some input on this change - maybe it's over kill? Here is my rationale for adding this table: 1) The current query to return all trait names is slow, as stated in the bug report. 3) All instances of event X will have the same traits, and all instances of a trait have the same trait type name and data type. I think it is cleaner to model this relationship in the db with an explicit TraitType table. 2) The api needs a model for trait types in order to fulfill the /v2/event_types/Foo/trait_type query. This call will return the set of trait names and data types, but no trait data. Related patches: sqlalchemy layer: https://review.openstack.org/#/c/42407/ (not sure the migration is correct) storage layer: https://review.openstack.org/#/c/41596/ Thanks! -john smime.p7s Description: S/MIME cryptographic signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ceilometer] Nova_tests failing in jenkins
Hi - The nova_tests are failing for a couple of different Ceilometer reviews, due to 'module' object has no attribute 'add_driver'. This review (https://review.openstack.org/#/c/41316/) had nothing to do with the nova_tests, yet they are failing. Any clue what's going on? Apologies if there is an obvious answer - I've never encountered this before. Thanks, -john smime.p7s Description: S/MIME cryptographic signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Event API Access Controls
Hi Julien, On 8/5/13 2:04 AM, Julien Danjou jul...@danjou.info wrote: On Sat, Aug 03 2013, Herndon, John Luke (HPCS - Ft. Collins) wrote: Hi John, Hello, I'm currently implementing the event api blueprint[0], and am wondering what access controls we should impose on the event api. The purpose of the blueprint is to provide a StackTach equivalent in the ceilometer api. I believe that StackTach is used as an internal tool which end with no access to end users. Given that the event api is targeted at administrators, I am currently thinking that it should be limited to admin users only. However, I wanted to ask for input on this topic. Any arguments for opening it up so users can look at events for their resources? Any arguments for not doing so? You should definitely use the policy system we has in Ceilometer to check that the user is authenticated and has admin privileges. We already have such a mechanism in ceilometer.api.acl. I don't see any point to expose raw operator system data to the users. That could even be dangerous security wise. This plans sounds good to me. We can enable/disable the event api for users, but is there a way to restrict a user to viewing only his/her events using the policy system? Or do we not need to do that? -john -- Julien Danjou // Free Software hacker / freelance consultant // http://julien.danjou.info smime.p7s Description: S/MIME cryptographic signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ceilometer] Event API Access Controls
Hello, I'm currently implementing the event api blueprint[0], and am wondering what access controls we should impose on the event api. The purpose of the blueprint is to provide a StackTach equivalent in the ceilometer api. I believe that StackTach is used as an internal tool which end with no access to end users. Given that the event api is targeted at administrators, I am currently thinking that it should be limited to admin users only. However, I wanted to ask for input on this topic. Any arguments for opening it up so users can look at events for their resources? Any arguments for not doing so? PS -I'm new to the ceilometer project, so let me introduce myself. My name is John Herndon, and I work for HP. I've been freed up from a different project and will be working on ceilometer. Thanks, looking forward to working with everyone! -john 0: https://blueprints.launchpad.net/ceilometer/+spec/specify-event-api smime.p7s Description: S/MIME cryptographic signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
