| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-24 | |||
| 20:55:56 | sdague | zzzeek: yeh, but that isn't used in the NoDBTestCase | |
| 20:57:39 | zzzeek | sdague: if mriedem wants to give me code I can re-familiarize with everything and what nova looks like today and get his test to run | |
| 20:58:40 | zzzeek | sdague: i had a lot of ideas for fixing nova's DB fixtures and a lot of what is in oslo_db today is based around being able to do that w/ maximum flexibility | |
| 21:00:13 | sdague | zzzeek: sure, I don't know where that stands. All I've got is the code I abandoned, that used the old fixture that he linked https://review.openstack.org/#/c/283364/6/nova/tests/functional/regressions/test_bug_1538011.py | |
| 21:00:54 | sdague | the preamble that gets to the point of being able to run migration.db_sync(database='main') | |
| 21:01:04 | sdague | is kind of what needs to be figured out | |
| 21:01:17 | mriedem | i'm close | |
| 21:01:27 | zzzeek | sdague: are these the tests you want to run? | |
| 21:01:31 | mriedem | no | |
| 21:02:13 | mriedem | things have changed quite a bit from that patch | |
| 21:02:19 | sdague | mriedem: ok | |
| 21:03:40 | zzzeek | sdague: the fixture would include GeneratesSchema as a mixin and implement the generate_schema_migrations(engine) method, wher you pass that engine into migration.db_sync(database='main', engine=engine) IIRC how you had that in your test suite already | |
| 21:04:05 | sdague | right, I think the trick was getting the engine allocated | |
| 21:04:12 | zzzeek | sdague: err GeneratesSchemaFromMigrations | |
| 21:04:45 | zzzeek | sdague: yeah this happens in your existing test suite somehwere. or maybe the patch I had included a small tweak to allow it. guess i have to find it | |
| 21:05:38 | zzzeek | sdague mriedem here we are https://review.openstack.org/#/c/349057/ | |
| 21:06:07 | mriedem | heh well i'm getting closer Table 'frkgzoinub.flavors' doesn't exist | |
| 21:06:13 | mriedem | looks like it didn't run the migrations properly | |
| 21:06:50 | sdague | mriedem: you have to run them manually | |
| 21:07:56 | zzzeek | mriedem sdague look at generate_schema_migrations in https://review.openstack.org/#/c/349057/2/nova/tests/fixtures.py | |
| 21:09:29 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Fix instance lookup in hide_server_addresses extension https://review.openstack.org/467772 | |
| 21:09:36 | mriedem | zzzeek: sdague: ^ is the start | |
| 21:10:35 | sdague | mriedem: cool, yeh, that looks kind of what I'd expect | |
| 21:11:24 | sdague | mriedem: I can play in the morning, I need to start working on dinner here | |
| 21:12:11 | zzzeek | mriedem: I can work on using all the newest patterns in just this one test if you want | |
| 21:12:44 | openstackgerrit | Dan Smith proposed openstack/nova master: Fix live migration devstack hook for multicell environment https://review.openstack.org/458537 | |
| 21:12:45 | openstackgerrit | Dan Smith proposed openstack/nova master: Target cell on local delete https://review.openstack.org/464059 | |
| 21:14:01 | mriedem | zzzeek: that's fine if you want, we'll actually have two db's to sync | |
| 21:14:05 | mriedem | the api db and the main db | |
| 21:14:18 | mriedem | not sure how that's going to work here | |
| 21:14:52 | zzzeek | mriedem: in one test ? | |
| 21:15:02 | mriedem | yeah | |
| 21:15:11 | zzzeek | mriedem: here's why oslo.db is so complicated :) | |
| 21:15:38 | mriedem | https://github.com/openstack/nova/blob/master/nova/test.py#L273 | |
| 21:15:41 | mriedem | that sets up the api db, | |
| 21:15:52 | mriedem | and then 2 cells mappings, which are really 2 dbs | |
| 21:15:54 | mriedem | with the same schema | |
| 21:15:58 | mriedem | so we really have 3 dbs per test | |
| 21:16:11 | mriedem | https://github.com/openstack/nova/blob/master/nova/test.py#L317 | |
| 21:16:22 | openstackgerrit | Matt Rabe proposed openstack/nova master: Query deleted instance records during _destroy_evacuated_instances https://review.openstack.org/467774 | |
| 21:16:29 | zzzeek | mriedem: I shoved dozens of weird nova use cases into this and that...hmm actually I can do that. one fixture per DB | |
| 21:17:45 | zzzeek | mriedem: so the test would create three schemas on one MySQL server ? | |
| 21:18:00 | zzzeek | err three databases | |
| 21:23:09 | mriedem | yeah | |
| 21:23:19 | mriedem | nova_api, nova_cell0 and nova | |
| 21:23:37 | mriedem | schema for the first is 'api' and 'main' for the latter 2 | |
| 21:38:29 | jose-phillips | someone know | |
| 21:38:42 | jose-phillips | if i can update a metadata from a vm with a post command? | |
| 21:38:47 | jose-phillips | to the metadata address? | |
| 21:40:11 | mriedem | update in the config drive? | |
| 21:40:22 | mriedem | config drive is static after you've created the server | |
| 21:40:30 | jose-phillips | no i m mean | |
| 21:40:32 | jose-phillips | for example | |
| 21:40:39 | jose-phillips | i want to update a metadata called last-login | |
| 21:41:02 | jose-phillips | the question is if i can perform the update of these metadata from this address http://169.254.169.254/openstack/latest/meta_data.json | |
| 21:41:05 | jose-phillips | on each v | |
| 21:41:05 | jose-phillips | m | |
| 21:41:14 | mriedem | no | |
| 21:41:21 | mriedem | metadata API is read-only | |
| 21:41:30 | mriedem | you can change the metadata on the server via the compute REST API | |
| 21:41:44 | mriedem | https://developer.openstack.org/api-ref/compute/#server-metadata-servers-metadata | |
| 21:41:55 | jose-phillips | got it | |
| 21:42:05 | jose-phillips | i was thinking if i can doint from there as a post | |
| 21:42:25 | jose-phillips | my idea is track the last time activity on each server | |
| 21:42:55 | jose-phillips | so i will send this information to a intermediate server and this server will going to update the metadata then. | |
| 21:43:04 | jose-phillips | with nova api | |
| 21:45:31 | openstackgerrit | Ed Leafe proposed openstack/nova master: Have scheduler claim resources https://review.openstack.org/463993 | |
| 21:45:31 | openstackgerrit | Ed Leafe proposed openstack/nova master: Pass the number of hosts to return explicitly https://review.openstack.org/465767 | |
| 21:45:32 | openstackgerrit | Ed Leafe proposed openstack/nova master: Remove selecting host based on host_subset_size https://review.openstack.org/465174 | |
| 21:45:32 | openstackgerrit | Ed Leafe proposed openstack/nova master: Make the method to put allocations public https://review.openstack.org/464086 | |
| 21:45:33 | openstackgerrit | Ed Leafe proposed openstack/nova master: Don't delete allocation if instance being scheduled https://review.openstack.org/460177 | |
| 21:45:33 | openstackgerrit | Ed Leafe proposed openstack/nova master: Pass a list of instance UUIDs to scheduler https://review.openstack.org/465171 | |
| 21:45:34 | openstackgerrit | Ed Leafe proposed openstack/nova master: Return multiple hosts from select_destinations https://review.openstack.org/465768 | |
| 22:04:57 | zzzeek | mriedem: this test case https://review.openstack.org/#/c/467772/1/nova/tests/functional/test_servers.py seems to use just one database right now? I'd need to see how that cell logic relates the UUID to a database, and I'd set up a fixture per-DB which will each make a new anonymous per-test schema | |
| 22:05:42 | zzzeek | mriedem: but...i would need to find some time. let me know if I can just show you around the API and maybe build a less-nova-ish proof of concept | |
| 22:22:41 | openstackgerrit | Ildiko Vancsa proposed openstack/nova master: WIP/POC Implement new attach Cinder flow https://review.openstack.org/330285 | |
| 22:37:43 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Enable cold migration with target host(1/2) https://review.openstack.org/408955 | |
| 22:39:26 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Enable cold migration with target host(2/2) https://review.openstack.org/408964 | |
| 22:40:04 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Add functional tests for cold migration to same host https://review.openstack.org/414926 | |
| 22:40:28 | openstackgerrit | Takashi NATSUME proposed openstack/python-novaclient master: Microversion 2.46 - Enable cold migration with target host https://review.openstack.org/406707 | |
| 22:40:49 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: api-ref: Add parameters in cold migrate action https://review.openstack.org/410042 | |
| 23:36:31 | openstackgerrit | Claudiu Belu proposed openstack/nova master: POC: tests: autospecs all the mock.patch usages https://review.openstack.org/447505 | |
| 23:47:59 | mriedem | zzzeek: it would eventually need to use at least the nova_api db and the nova (cell) db | |
| 23:48:03 | mriedem | the instance is going to live in the cell db | |
| 23:48:34 | mriedem | i'm not starting enough services for the actual instance create to work yet, | |
| 23:48:57 | mriedem | but it seems the schema migrations aren't getting run anyway because when i try to create/start the services, like nova-api, it's blowing up because the services table doesn't exist yet | |
| 23:53:04 | mriedem | i'm getting a little further, if i sync the 'main' db i can start services, but w/o syncing the api db i don't have flavors to create a server | |
| 23:53:37 | mriedem | trying to sync the api db fails with http://paste.openstack.org/show/610607/ | |
| 23:53:46 | mriedem | i assume b/c i'm using the wrong engine | |
| 23:55:49 | gmann | mriedem: yea, that was hide server address cfg and policy deprecation things which i will be pushing spec for that | |
| 23:56:06 | gmann | mriedem: got the issues with instance id. | |
| 23:56:34 | gmann | alex_xu: thanks for help. i will push doc and other things | |
| 23:56:49 | mriedem | gmann: working on that here https://review.openstack.org/#/c/467772/ | |
| 23:57:07 | mriedem | the code fix for this bug is easy, but we're trying to write a functional test to recreate it using mysql as the backend | |
| #openstack-nova - 2017-05-25 | |||
| 00:00:03 | gmann | mriedem: yea. nice. we will use resp.obj['server']['id'] to fetch instance right ? | |
| 00:01:08 | gmann | mriedem: also we would not need instance there once we deprecate and remove the CONF.api.hide_server_address_states | |
| 00:01:26 | gmann | but thats long term things may be next release as it need spec | |
| 00:01:38 | mriedem | gmann: yes that's the fix | |
| 00:02:05 | mriedem | so the plan is to just remove the config option and always hide 'addresses' when the vm_state is 'building'? | |
| 00:03:22 | gmann | mriedem: yea, but on spec we can discuss more VM states if addresses is not ready during those | |