Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-03-01
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 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:15:37 cfriesen bauzas: bug 1669054 has been opened to track the issue
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
17:22:15 andymccr which means that the approach for upgrades doesn't work for greenfield
17:22:19 mriedem map_cell0 creates a cell_mappings record in the nova_api db
17:22:35 andymccr so then should api_db sync fail if cell0 doesn't exist yet?
17:22:37 mriedem andymccr: tripleo?
17:22:42 andymccr mriedem: OpenStack-Ansible
17:22:49 andymccr although im sure the tripleo ppl have already figured this one out :P
17:22:50 mriedem do you already have flavors created?
17:23:02 mriedem yes owalsh hit the same thing
17:23:05 mriedem in tripleo
17:23:14 mriedem and we relaxed something in the api db schema migration
17:23:17 andymccr mriedem: in testing, no - in practice yes
17:23:47 cfriesen bauzas: I don't think changing reset_forced_destinations() is sufficient by itself given how we handle ignore_hosts in ConductorManager.rebuild_instance().
17:24:20 mriedem andymccr: assuming you have this change? https://github.com/openstack/nova/commit/f781409f366904362b36bb8047fc371c17301c5e
17:24:52 melwitt I thought upgrade scenario meant not a greenfield?
17:25:26 mriedem yeah i'm confused
17:25:27 melwitt like, you're upgrading a deployment that already has a api db with a schema in it
17:25:36 mriedem if you've synced the api db in newton, you have the cell mappings table and can run map_cell0
17:25:44 mriedem to create an entry in the cell_mappings table in the nova_api db
17:26:06 andymccr mriedem: melwitt: sure but the issue is the process is then diff for greenfield vs upgrade, which means i need to have 2 code paths to manage 1 thing

Earlier   Later