| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-08-22 | |||
| 20:14:06 | kbringard | ^^ | |
| 20:14:08 | cburgess | kbringard What version of versionedobjects do we have? | |
| 20:14:20 | kbringard | when we're running this it's stable/ocata | |
| 20:14:50 | cburgess | We are checking that out from git and building it in a venv or using something RedHat provided? | |
| 20:15:03 | kbringard | python-oslo-versionedobjects-lang-1.21.0-1.el7ost.noarch | |
| 20:15:03 | kbringard | python-oslo-versionedobjects-1.21.0-1.el7ost.noarch | |
| 20:15:14 | kbringard | vanilla Rh package | |
| 20:15:24 | dansmith | it's likely a timeutils thing not an o.vo thing right? | |
| 20:15:53 | cburgess | Good point | |
| 20:15:58 | cburgess | We use oslo.timeutiles to do the conversion | |
| 20:16:21 | cburgess | kbringard so what version of oslo_utils do we have? | |
| 20:16:52 | kbringard | python-oslo-utils-3.22.0-1.el7ost.noarch | |
| 20:16:52 | kbringard | python-oslo-utils-lang-3.22.0-1.el7ost.noarch | |
| 20:17:49 | kbringard | my initial thought was if we maybe don't have enough test coverage? | |
| 20:17:58 | cburgess | kbringard netwon was constrained to 3.16.1 | |
| 20:18:01 | kbringard | like, the default flavors we used to create had NULL for all those guys | |
| 20:18:07 | kbringard | and that all works | |
| 20:18:42 | kbringard | so I'm wondering if this has just been a bug that we'd not caught before, and if no one was doing these migrations (or said anything when they did) then maybe we just never discovered it before? | |
| 20:18:51 | cfriesen_ | mriedem: did you want me to do a fix for the live migration cell restriction on top of your fix at https://review.openstack.org/#/c/49603 ? | |
| 20:19:02 | cfriesen_ | mriedem: or were you going to propose a patch for that? | |
| 20:22:32 | mriedem | cfriesen_: wrong link? i've got a patch though | |
| 20:22:36 | mriedem | just finishing unit tests | |
| 20:22:57 | cfriesen_ | mriedem: gah, I meant https://review.openstack.org/#/c/496031 | |
| 20:23:11 | cfriesen_ | anyways, cool | |
| 20:23:23 | mriedem | and yes it's on top of that series | |
| 20:23:27 | mriedem | to avoid merge conflicts | |
| 20:27:29 | cfriesen_ | mriedem: looking at that commit, in the future if we pass "skip-filters" to the scheduler wouldn't we also want to skip the initial placement checks? (since they're essentially what used to be filters) Presumably the "claim resources on destination" step would fail though. | |
| 20:28:58 | mriedem | cfriesen_: tbd | |
| 20:29:09 | mriedem | cfriesen_: conductor already essentially does the RamFilter | |
| 20:29:15 | mriedem | which is replaced by Placement's check on MEMORY_MB | |
| 20:29:30 | mriedem | so the thing that would be different would be filtering, via placement, on VCPU and DISK_GB | |
| 20:29:37 | cfriesen_ | mriedem: I think that should be pulled out since it was probably legacy code from before we ran the scheduler filters | |
| 20:29:49 | mriedem | ? | |
| 20:30:02 | cfriesen_ | having conductor do the memory check, I mean | |
| 20:30:09 | mriedem | pretty sure that was added in 2.30 | |
| 20:30:25 | cfriesen_ | guess I didn't review that patch | |
| 20:30:30 | mriedem | because that happens in the force host flow | |
| 20:30:36 | mriedem | which doesn't call select_destinations | |
| 20:30:50 | cfriesen_ | ah, sure. in the force flow it makes sense | |
| 20:31:27 | mriedem | actually looks like you're right | |
| 20:31:32 | mriedem | https://review.openstack.org/#/c/29077/ | |
| 20:31:35 | mriedem | that's way old | |
| 20:31:55 | cfriesen_ | I was just thinking that in the force case you could skip the placement checks and filters in the scheduler and just jump right to the resource claim. | |
| 20:32:43 | mriedem | predates select_destinations | |
| 20:32:45 | mriedem | goes back to havana | |
| 20:33:08 | mriedem | so yeah that ram check probably shouldn't even be in conductor | |
| 20:34:20 | cfriesen_ | arguably it makes sense in the current flow since it's a critical resource...hard to overcommit ram the way you can with cpu | |
| 20:58:45 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Restrict live migration to same cell https://review.openstack.org/496419 | |
| 20:58:55 | mriedem | cfriesen_: dansmith: there is the live migration restricted to same cell fix ^ | |
| 22:05:30 | cfriesen_ | mriedem: you're a machine with all these fixes. :) | |
| 22:07:04 | mriedem | all these 2 fixes | |
| 22:08:36 | cfriesen_ | is there a way to query the hosts in a cell? | |
| 22:08:54 | cfriesen_ | don't see anything in the api-ref | |
| 22:10:51 | cfriesen_ | where I'm going with this is...how does the admin know which hosts are part of the same cell? | |
| 22:20:53 | mriedem | cfriesen_: https://docs.openstack.org/nova/latest/user/cells.html#faqs | |
| 22:21:43 | mriedem | we probably need another cli in queens for that | |
| 22:21:54 | mriedem | or build on list_cells | |
| 22:33:04 | cfriesen_ | mriedem: okay, makes sense | |
| 22:36:34 | cfriesen_ | mriedem: would we need a spec for nova-manage? (does it count as a public API?) | |
| 22:57:04 | mriedem | nope | |
| 23:37:11 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove source node allocation after live migration completes https://review.openstack.org/496032 | |
| 23:37:12 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Restrict live migration to same cell https://review.openstack.org/496419 | |
| 23:37:13 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Allocate resources on forced dest host during live migration https://review.openstack.org/496031 | |
| #openstack-nova - 2017-08-23 | |||
| 00:04:06 | cali_boxer | hello all, | |
| 00:04:19 | cali_boxer | i am having an issue with nova-scheduler | |
| 00:04:38 | cali_boxer | it's reporting system has more free space than dataabase expected | |
| 00:04:49 | cali_boxer | this is on os liberty redhat 7.2 | |
| 00:05:19 | cali_boxer | i cannot create stacks as the server creation fails | |
| 00:05:49 | cali_boxer | i can create independent os images without an issue | |
| 01:22:05 | openstackgerrit | Naichuan Sun proposed openstack/nova master: xenapi: cached images should be cleaned up by time https://review.openstack.org/465954 | |
| 01:53:19 | openstackgerrit | Alex Xu proposed openstack/nova master: placement: ensure RP maps to those RPs that share with it https://review.openstack.org/480379 | |
| 02:06:01 | clarkb | dansmith: mriedem for tomorrow in reviewing https://review.openstack.org/#/c/491955/1 I noticed that the cell1 cond logs are slightly off whihc confuses os-loganalyze and will result in no lines being indexed for that service if we try indexing them as is | |
| 02:20:32 | alex_xu | gmann: the no-more-extension in queens https://etherpad.openstack.org/p/api-no-more-extensions-pike | |
| 02:21:08 | gmann | alex_xu, hi | |
| 02:21:27 | alex_xu | gmann: hi, i'm thinking of whether we have sample file for json-schema | |
| 02:21:53 | gmann | alex_xu, yea | |
| 02:22:20 | gmann | alex_xu, i will push 1 or 2 patch for each item as sample | |
| 02:22:33 | gmann | and based on that we can discuss those in PTG | |
| 02:22:36 | alex_xu | gmann: cool, thanks | |
| 02:23:01 | gmann | alex_xu, do you think we should add BP also or after PTG feedback? | |
| 02:23:40 | alex_xu | gmann: we can add one now | |
| 02:23:46 | gmann | alex_xu, ok | |
| 02:23:47 | alex_xu | gmann: do you want to create one? | |
| 02:24:15 | gmann | alex_xu, ok, i will push remaining things there with adding sample patches | |
| 02:24:33 | alex_xu | gmann: thanks! | |
| 02:25:15 | alex_xu | gmann: are you interesting on taking look at how to add sample file for json-schema? | |
| 02:25:50 | alex_xu | gmann: that can be used to avoid the bug like this https://bugs.launchpad.net/nova/+bug/1658571 | |
| 02:25:52 | openstack | Launchpad bug 1658571 in OpenStack Compute (nova) "Microversion 2.37 break 2.32 usage" [High,Fix released] - Assigned to Artom Lifshitz (notartom) | |
| 02:26:49 | gmann | alex_xu, yea that will be nice. | |
| 02:27:07 | artom | A long time ago I started https://review.openstack.org/#/c/430352/ in relation to that bug | |
| 02:27:32 | artom | It needs a massive amount of manual sample fixing to eventually work though :( | |
| 02:28:24 | gmann | artom, ohk, even i was thinking to run a gate job with 'latest' but not all tempest test will pass and it will need lot of refactoring | |
| 02:28:59 | artom | gmann, mine is just for api sample tests, to start with at least | |
| 02:29:08 | gmann | yea | |
| 02:29:59 | artom | I just got discouraged by the, like, 150 failing tests that 2.latest created, and the need to manually go and either skip or fix each one | |
| 02:30:47 | gmann | most of them need capping of microversion | |
| 02:31:55 | gmann | anyways we can think more on this. may be simple set of mandatory element of schema and test them with latest | |
| 02:32:03 | gmann | alex_xu, you have any other idea on this | |
| 02:33:36 | alex_xu | gmann: artom i'm just thinking of the API sample tests also generate all the json-schema to a sample file, then we validate the jsons-schema whether is changed unexpected | |
| 02:34:51 | artom | alex_xu, I'm not sure I follow (it may have something to do with it being 22:30 here) | |