Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-03-01
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
16:30:13 mriedem oh i know why
16:30:36 mriedem we're using neutron on master, but nova-net on mitaka
16:30:43 andreykurilin oh
16:30:48 mriedem yeah https://github.com/openstack/python-novaclient/blob/master/novaclient/tests/functional/v2/legacy/test_fixedips.py#L26
16:30:50 mriedem i'll push a fix quick
16:30:53 mriedem good catch
16:31:07 andreykurilin mriedem: thanks
16:31:28 andreykurilin mriedem: what about making mitaka-functional job voting?
16:33:25 mriedem we could...
16:33:35 mriedem I haven't put any thought into it
16:34:25 mriedem bbiab
16:40:48 dims thorst : Anyone around to merge this PR and cut a release for pypowervm? https://github.com/powervm/pypowervm/pull/1
16:41:20 thorst dims: Yeah, we're working on getting a new rev of that. It'd be pypowervm 1.0.0.4.1 to take in the new req. adreznec is working on it.
16:41:33 dims great thanks thorst and adreznec
16:41:42 adreznec dims: thorst Yep, just working on that now
16:41:43 thorst thx for letting us know!
16:42:58 cfriesen bauzas, you around?
16:43:15 openstackgerrit Jay Pipes proposed openstack/nova master: placement: ironic inventory reporting https://review.openstack.org/437602
16:43:51 jaypipes dansmith: finally addressed your PS5 coments ^. thanks for your patience.
16:44:36 dansmith jaypipes: will look in a bit
16:50:35 bauzas cfriesen: yup but with terrible connection

Earlier   Later