| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-01 | |||
| 15:13:41 | mriedem | sileht: did nova-manage db sync run after the cell0 db was mapped? | |
| 15:13:54 | mriedem | i.e. run nova-manage cell_v2 map_cell0 and then run nova-manage db sync | |
| 15:13:56 | sileht | mriedem, we just setup devstack | |
| 15:14:05 | sileht | mriedem, it should do it for us, no ? | |
| 15:14:20 | mriedem | well let's see | |
| 15:14:38 | sileht | mriedem, here: http://logs.openstack.org/10/439510/4/check/gate-telemetry-dsvm-integration-gnocchi-ubuntu-xenial/07bd989/logs/devstacklog.txt.gz#_2017-03-01_14_07_18_983 | |
| 15:14:39 | mriedem | nova_cell0 is created here http://logs.openstack.org/10/439510/4/check/gate-telemetry-dsvm-integration-gnocchi-ubuntu-xenial/07bd989/logs/devstacklog.txt.gz#_2017-03-01_13_57_36_563 | |
| 15:14:52 | mriedem | map_cell0 is called here http://logs.openstack.org/10/439510/4/check/gate-telemetry-dsvm-integration-gnocchi-ubuntu-xenial/07bd989/logs/devstacklog.txt.gz#_2017-03-01_14_07_18_983 | |
| 15:15:18 | mriedem | nova-manage db sync is called here http://logs.openstack.org/10/439510/4/check/gate-telemetry-dsvm-integration-gnocchi-ubuntu-xenial/07bd989/logs/devstacklog.txt.gz#_2017-03-01_13_57_36_581 | |
| 15:15:28 | mriedem | so db sync was called before map_cell0 | |
| 15:15:36 | mriedem | so the cell0 db schema isn't migrated | |
| 15:15:52 | sileht | mriedem, so it's a devstack bug ? | |
| 15:15:58 | mriedem | "WARNING: cell0 mapping not found - not syncing cell0." | |
| 15:16:15 | mriedem | sileht: if it were, i'd think all of the jobs would be broken | |
| 15:16:46 | sileht | mriedem, our gate is mostly broken, most of the time we got the error, but sometimes it passes | |
| 15:16:46 | dims | mriedem : tools/discover_hosts.sh does not run in their case | |
| 15:17:00 | dims | mriedem : so they don't run "nova-manage cell_v2 discover_hosts --verbose" | |
| 15:17:20 | sileht | dims, do we miss something in project-config ? | |
| 15:17:49 | dims | sileht : remember this one - http://git.openstack.org/cgit/openstack-dev/devstack/commit/tools/discover_hosts.sh?id=5c6aa56e11b2dc79adc70154187d3a029e8e0976 | |
| 15:18:17 | mriedem | dims: this isn't a multinode job so i don't think they need discover_hosts as long as simple_cell_setup is getting run | |
| 15:18:21 | sileht | dims, yes, but that was for another job | |
| 15:18:27 | mriedem | which is does here http://logs.openstack.org/10/439510/4/check/gate-telemetry-dsvm-integration-gnocchi-ubuntu-xenial/07bd989/logs/devstacklog.txt.gz#_2017-03-01_14_07_22_457 | |
| 15:18:37 | dansmith | missing cell0 means we're not even getting to discover hosts | |
| 15:18:42 | dims | ah, ignore me then | |
| 15:18:46 | mriedem | sileht: so someone else had a similar sounding issue with using a devstack plugin | |
| 15:18:55 | mriedem | where it was getting called in the wrong order, i think it was shade | |
| 15:19:14 | mriedem | mordred: remember that thing where a devstack plugin was being called from post-stack or test hooks or something? | |
| 15:19:24 | mriedem | so n-api was up before cell0 was synce | |
| 15:19:28 | mriedem | *synced | |
| 15:19:30 | openstackgerrit | Ed Leafe proposed openstack/nova master: placement: ironic inventory reporting https://review.openstack.org/437602 | |
| 15:19:50 | edleafe | jaypipes: ^^ fixed the pep8, and took the liberty of changing the name | |
| 15:20:14 | sileht | mriedem, oh maybe because each time a project that add a new wsgi vhost to apache, it is restarted | |
| 15:20:28 | asettle | mriedem: you are the lucky receiver of the table update; https://wiki.openstack.org/wiki/CrossProjectLiaisons#Documentation (this is where we keep all our liaisons) | |
| 15:21:00 | mordred | mriedem: yah | |
| 15:21:05 | mordred | mriedem: that was a lot of fun | |
| 15:21:31 | mriedem | mordred: remember the details? sounds like gnocchi jobs might be doing the same | |
| 15:21:51 | mriedem | http://logs.openstack.org/10/439510/4/check/gate-telemetry-dsvm-integration-gnocchi-ubuntu-xenial/07bd989/logs/devstack-gate-post_test_hook.txt.gz | |
| 15:22:00 | mordred | yah ... one sec, lemme find our fix patch | |
| 15:22:32 | mordred | mriedem: https://review.openstack.org/#/c/427390/ | |
| 15:22:57 | mordred | so for us "start_nodepool" needs to not happen until the cloud is actually, you know, up and running | |
| 15:23:06 | mordred | we do that in test-config now | |
| 15:23:36 | mordred | sileht: ^^ | |
| 15:23:41 | mriedem | sileht: so the gnocchi test hook might be trying to hit nova-api at the wrong point in the bring up sequence | |
| 15:24:06 | mordred | yah. that's what we were trying to do - nova was not happy about it | |
| 15:24:21 | mriedem | also https://review.openstack.org/#/c/427392/ | |
| 15:24:26 | mriedem | ^ still needs to go in | |
| 15:24:42 | mriedem | and i think would help here, but there is still likely a bug in the consuming plugin | |
| 15:25:08 | sileht | mriedem, we start ceilometer and gnocchi during the extra step, not the the post-config | |
| 15:26:55 | mriedem | i've got to run to a meeting, bbiab | |
| 15:33:43 | alex_xu | jaypipes: sorry, I can't make a hangout, baby is sleeping. everybody just keep quiet... | |
| 15:36:35 | dims | alex_xu : :) | |
| 15:36:43 | jaypipes | alex_xu: k, no worries. let's comment on the patch, ok? | |
| 15:36:55 | jaypipes | edleafe: cool, thanks. I'm fixing up dansmith's PS5 comments now. | |
| 15:37:45 | alex_xu | jaypipes: that is ok for me, or you want to discuss on the irc, i still wake up | |
| 15:38:34 | jaypipes | alex_xu: k. | |
| 15:39:24 | jaypipes | alex_xu: so I don't actually think we should have a separate GET /traits/namespace REST API endpoint. And I think that GET /traits?namespace=* should be GET /traits?starts_with=XXX | |
| 15:40:47 | alex_xu | jaypipes: ok, i guess i remember the wrong one | |
| 15:41:33 | alex_xu | jaypipes: so you expect GET/traits?starts_with=CUSTOM:GPU, that is just a prefix, not really a namespace defined in the os-traits? | |
| 15:42:07 | jaypipes | alex_xu: yes, exactly. | |
| 15:42:48 | alex_xu | jaypipes: sorry, may i ask what is the point between the choice of "namespaces=*" and "starts_with"? | |
| 15:47:26 | alex_xu | dims: i also type the keyboard softly... | |
| 15:47:39 | dims | awwwww alex_xu | |
| 15:50:24 | jaypipes | alex_xu: actually, I think GET /traits?name=starts_with:XXX would be more in-line with the API WG filtering guidelines? https://github.com/openstack/api-wg/blob/master/guidelines/pagination_filter_sort.rst | |
| 15:51:14 | jaypipes | alex_xu: I know that there isn't a guideline specifically for prefix matching, but the other filter guidelines are similar. name=in:X,Y, start=ge:2017-01-01, etc | |
| 15:52:02 | jaypipes | alex_xu: in this case, all we're doing is a prefix match. There's really nothing about namespaces that is specific to the query. | |
| 15:52:15 | mriedem | +1 to /traits?name=starts_with:XXX | |
| 15:52:50 | mriedem | we have something like this today: GET /resource_providers?resources=VCPU:2,MEMORY_MB:1024,DISK_GB:50 | |
| 15:53:02 | mriedem | and | |
| 15:53:03 | mriedem | /resource_providers?member_of=in:{agg1_uuid},{agg2_uuid},{agg3_uuid} | |
| 15:53:04 | jaypipes | alex_xu: and doing it this way would allow us, for example, to do something like GET /traits?name=contains:GPU or something similar, whereas you couldn't do that with namespace=XXX | |
| 15:54:01 | alex_xu | jaypipes: contains:GPU just should have bad performance even with db index? | |
| 15:55:24 | jaypipes | alex_xu: yes, absolutely, but that doesn't mean people won't find it useful ;) | |
| 15:56:16 | jaypipes | alex_xu: in any case, my point is that if we do name=starts_with:XXX, then we keep our API more in-line with the API WG recommendations and leave our options open in future to how users can query the placement API. Agree? | |
| 15:56:37 | alex_xu | jaypipes: yes, i agree | |
| 15:58:44 | alex_xu | jaypipes: mriedem, wait, the current proposal have a API "GET /traits?tratis=a,b,c", it is ok with "GET /traits?traits=start_with:xxx"? | |
| 16:02:18 | mriedem | what are the semantics of traits=a,b,c? | |
| 16:02:30 | mriedem | is that an in? | |
| 16:02:41 | mriedem | traits in (a, b, c) or an intersection? | |
| 16:02:52 | alex_xu | mriedem: yes | |
| 16:02:57 | mriedem | or is that, give me details about traits a, b, and c? | |
| 16:03:13 | jaypipes | mriedem: yup, traits?name=in:a,b,c | |
| 16:03:27 | jaypipes | IN == ANY() | |
| 16:03:36 | alex_xu | ah...name=in: | |
| 16:03:46 | mriedem | yeah we have that for resource_providers already | |
| 16:03:53 | mriedem | for finding resource providers in a given set of aggregates | |
| 16:04:03 | mriedem | /resource_providers?member_of=in:{agg1_uuid},{agg2_uuid},{agg3_uuid} | |
| 16:04:26 | mriedem | bauzas at one point had something similar for getting resource providers by name | |
| 16:04:45 | alex_xu | jaypipes: mriedem I think i got all that point now | |
| 16:05:27 | alex_xu | i will update the spec and validate more, mriedem jaypipes thanks | |
| 16:05:40 | jaypipes | alex_xu: cool, thanks Alex! | |
| 16:05:57 | alex_xu | jaypipes: np | |
| 16:06:20 | mriedem | alex_xu: jaypipes: this was the change for RPs i was thinking of https://review.openstack.org/#/c/407630/ | |
| 16:06:36 | mriedem | GET: /resource_providers?name=in:$ENVIRON['RP_NAME'],foobar | |
| 16:06:55 | mriedem | so in that example, it's looking for RPs by name where one exists and one doesn't (foobar doesn't) | |
| 16:07:37 | mriedem | alex_xu: also, now that i'm looking at that change and it reminds me, | |
| 16:07:44 | mriedem | the resource provider name doesn't exclude commas | |
| 16:07:58 | alex_xu | mriedem: ":" is a specical for trait | |
| 16:08:01 | mriedem | so when you define a schema for trait name, make sure it does not allow commas | |
| 16:08:19 | mriedem | because name=in:a,b,c would be broken parsing if the trait name has a comma in it | |
| 16:08:48 | alex_xu | mriedem: the trait is like HW:X86:CPU:AVX, with ":" is probably ok | |