| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-01 | |||
| 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 | |
| 16:09:17 | mriedem | well we'd have to split on the first : in the name=in:a,b,c case | |
| 16:09:25 | mriedem | so you split on : and get a,b,c | |
| 16:09:35 | mriedem | so we could have name=in:HW:X86:CPU:AVX,foo | |
| 16:09:41 | alex_xu | mriedem: yea | |
| 16:09:47 | mriedem | split on the first : and get HW:X86:CPU:AVX,foo | |
| 16:09:57 | mriedem | and then split on , to get (HW:X86:CPU:AVX, foo) | |
| 16:10:10 | mriedem | but my point is, make sure the schema for creating a trait in the API excludes commas :) | |
| 16:10:27 | mriedem | alex_xu: couldn't we just do _ instead of : | |
| 16:10:29 | mriedem | for the trait name? | |
| 16:10:38 | mriedem | then it would match resource classes | |
| 16:12:14 | alex_xu | mriedem: we could, I didn't have any critical point for can't use "_" | |
| 16:12:35 | alex_xu | jaypipes: ^ do you have anything in mind? | |
| 16:13:35 | mriedem | i tend to think we should be consistent | |
| 16:13:36 | cfriesen | do the capabilities exposed in self.driver.capabilities in the ComputeManager get exposed to the scheduler filters? (I'm wondering if we can use self.driver.capabilities['supports_migrate_to_same_host'] to avoid scheduling to the same compute node if it's not supported. | |
| 16:13:46 | mriedem | because we have the whole _ for image metadata and : for flavor extra specs today | |
| 16:13:49 | mriedem | which is kind of a confusing mess | |
| 16:14:10 | mriedem | cfriesen: i believe so yes, the capabilities filter | |
| 16:14:13 | mriedem | it's right in the name | |
| 16:15:10 | alex_xu | mriedem: yes, agree with you, actually i'm trying to match the resource class, I changed the trait name from lower-case to capitals | |
| 16:15:40 | jaypipes | mriedem: sure, we can use _ instead of : | |
| 16:15:43 | jaypipes | alex_xu: ^ | |
| 16:16:05 | alex_xu | jaypipes: mriedem cool, thanks | |
| 16:24:40 | mriedem | cfriesen: ComputeCapabilitiesFilter | |
| 16:24:41 | mriedem | i think | |
| 16:26:03 | andreykurilin | mriedem: hi! Your patch (https://review.openstack.org/#/c/437145/) broke functional-mitaka job. At least it is the first patch with red job result. | |
| 16:27:27 | zioproto | dansmith, are you here ? | |
| 16:27:40 | mriedem | andreykurilin: hmm, those tests must be based on microversion or something | |
| 16:28:34 | andreykurilin | mriedem: two tests are "legacy" | |
| 16:29:12 | mriedem | weird, how did that test even pass on master? | |
| 16:29:22 | mriedem | https://github.com/openstack/python-novaclient/blob/master/novaclient/tests/functional/v2/legacy/test_fixedips.py#L31 | |
| 16:29:28 | mriedem | that's calling a CLI that doesn't exist anymore | |
| 16:29:58 | mriedem | it was skipped for master http://logs.openstack.org/45/437145/2/check/gate-novaclient-dsvm-functional-neutron-ubuntu-xenial/aad02a1/testr_results.html.gz | |