Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-03-01
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
16:50:40 bauzas So lots of lags
16:51:23 bauzas cfriesen: Wazzup?
16:51:45 cfriesen bauzas: I think there's a bug in the handling of ignore_hosts. We set it on resize if CONF.allow_resize_to_same_host is False, then we save the RequestSpec and use the same RequestSpec on a subsequent rebuild/evacuate
16:52:31 cfriesen we reset force_hosts/force_nodes, but not ignore_hosts
16:53:15 bauzas Mmmm
16:53:39 bauzas Looks like a miss indeed
16:54:02 bauzas cfriesen : patch it up in the object helper then
16:54:19 cfriesen in reset_forced_destinations() ?
17:00:36 dtp is there a cells meeting today?
17:01:33 bauzas cfriesen: yup
17:01:43 dansmith oops
17:02:01 bauzas cfriesen: But I need to dig into code
17:02:29 bauzas Because I remember a similar issue that I fixed
17:03:12 sneti johnthetubaguy, can you please review this when you have time: https://review.openstack.org/#/c/396420/
17:03:54 johnthetubaguy sneti: ah, yes, opened that, hopefully will get there soon

Earlier   Later