Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-03-01
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
17:04:21 sneti thanks johnthetubaguy
17:10:22 mriedem sdague: i want to reuse your FakeResponse thing https://github.com/openstack/nova/blob/master/nova/tests/unit/test_identity.py#L25
17:10:27 mriedem but need to adjust the nonzero
17:10:36 mriedem to be True for status_code < 400
17:10:49 mriedem to match requests.Response https://github.com/kennethreitz/requests/blob/v2.12.5/requests/models.py#L658
17:10:53 mriedem sdague: you ok with that?
17:15:37 cfriesen bauzas: bug 1669054 has been opened to track the issue
17:15:37 openstack bug 1669054 in OpenStack Compute (nova) "RequestSpec.ignore_hosts from resize is reused in subsequent evacuate" [Undecided,New] https://launchpad.net/bugs/1669054
17:16:36 sdague mriedem: sure
17:18:18 andymccr what is the correct order for nova-manage (api_db/db sync & cell_v2 commands) in an upgrade? i'm running into an issue where greenfield works, but upgrades don't unless the order is slightly different
17:19:44 andymccr or rather - is there an order that works for both upgrades and greenfield? :)
17:20:24 mriedem andymccr: https://docs.openstack.org/developer/nova/cells.html#setup-of-cells-v2
17:20:32 mriedem and https://docs.openstack.org/developer/nova/cells.html#step-by-step-for-common-use-cases
17:21:32 andymccr mriedem: those docs only cover the cell setup bits - which is working fine afaict. the issue im running into is that in greenfield i have to have done an api_db sync before i can do the cell_v2 map_cell0 - otherwise it fails because certain tables are missing in the nova_api database
17:22:05 andymccr but in an upgrade scenario (from a non-cell_v2 --> cell_v2 deploy, or say N->O) if i run the api_db sync before the cell exists it will bomb saying that the cell needs to exist
17:22:10 mriedem yes you need the api db synced to get the cell mapping model

Earlier   Later