| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-12 | |||
| 13:41:10 | andreas_s | mriedem: yes, it is running cinder - but sometimes the backup related tests all fail - I haven't yet figured out why this is the case.. | |
| 13:41:41 | mriedem | andreas_s: no, i mean, is the CI also running against cinder changes? | |
| 13:41:47 | mriedem | or just nova | |
| 13:41:52 | andreas_s | mriedem: ah - no. just nova | |
| 13:42:02 | mriedem | andreas_s: ok, so nova changes don't care about the results of volume api only tests | |
| 13:42:04 | kaisers | kashyap: looking at recent NFS CI test they seem to hit the same issue: http://logs.openstack.org/27/511427/2/check/gate-tempest-dsvm-full-devstack-plugin-nfs-nv/bf61d5b/console.html | |
| 13:42:08 | mriedem | nor image or object storage or identity api tests | |
| 13:42:26 | mriedem | andreas_s: so you could just whitelist the zkvm ci, which only runs against nova changes, to only run the tempest.api.compute tests | |
| 13:42:32 | kashyap | kaisers: Okay, please write a comment in the bug with the log from NFS as plain text attachment | |
| 13:42:37 | kashyap | As these URLs will expire | |
| 13:42:40 | andreas_s | mriedem: no scenario tests? | |
| 13:43:08 | kaisers | kashyap: will do | |
| 13:43:11 | mriedem | andreas_s: you could probably run the scenario tests, but some of them don't touch nova at all i don't think, like some of the advanced networking ones | |
| 13:43:39 | mriedem | andreas_s: so maybe just whitelist tempest.api.compute and tempest.scenario for now | |
| 13:43:44 | mriedem | that should help reduce some of the noise and the load | |
| 13:43:44 | andreas_s | mriedem: skipping storage related things will definitively help to stabilize the voting pattern... | |
| 13:44:06 | andreas_s | mriedem: ok, will do, thanks for the suggestion | |
| 13:44:19 | mriedem | np, thanks for being responsive | |
| 13:49:01 | mriedem | oomichi: are schema validation errors handled separately from the expected_errors decorator in this change? https://review.openstack.org/#/c/509039/ | |
| 13:49:28 | mriedem | ah i guess it is | |
| 13:50:10 | dansmith | mriedem: so on that accepted thing, | |
| 13:50:22 | mriedem | uh oh | |
| 13:50:31 | dansmith | mriedem: I think that was improperly baking rt-level behavior into the db layer | |
| 13:50:33 | dansmith | mriedem: way before placement of course | |
| 13:50:43 | mriedem | nikola's patch? | |
| 13:50:49 | dansmith | I don't think that just because it was intentional back then means it makes sense now | |
| 13:50:51 | dansmith | yeah | |
| 13:51:05 | mriedem | i meant to go dig into the linked bug but forgot | |
| 13:52:04 | kaisers | kashyap: I've to run in a min, I'll follow up on this irc log and the bug ticket when i'm back on... | |
| 13:52:30 | kashyap | kaisers: Sure; it's best if we hash it out on the bug, too. As others can catch up on the context | |
| 13:52:41 | mriedem | dansmith: it was related to bug https://bugs.launchpad.net/nova/+bug/1417667 | |
| 13:52:42 | openstack | Launchpad bug 1417667 in OpenStack Compute (nova) "migration/evacuation/rebuild/resize of instance with NUMA topology needs to recalculate NUMA topology" [Medium,In progress] | |
| 13:52:46 | mriedem | but, that's an epic thing | |
| 13:52:48 | mriedem | so who knows | |
| 13:52:57 | mriedem | https://review.openstack.org/#/q/topic:bug/1417667+(status:open+OR+status:merged) | |
| 13:52:59 | mriedem | jesus | |
| 13:53:19 | dansmith | hmm. not sure about that | |
| 13:53:25 | mriedem | heh, "this numa feature we added doens't work, it's a bug, so let's fix it with a billion patches" | |
| 13:53:26 | bhagyashris | johnthetubaguy, mriedem: thank you :) | |
| 13:55:23 | efried | sdague (cc mordred) Regarding barbican affordance in bp/use-ksa-adapter-for-endpoints -- I've been looking into it, and I don't think Nova is the right place to tackle it. Would like to discuss when you have a few. | |
| 13:56:44 | efried | (mriedem ^ if it turns out to be the case that we don't do that, would a spec update be necessary/desirable?) | |
| 13:57:59 | mriedem | efried: if the spec says you're going to do it for barbican too and you don't, then amending the spec is fine | |
| 13:58:14 | efried | alex_xu I think Jay is on quasi-vacation | |
| 13:58:17 | efried | mriedem ack | |
| 13:58:42 | alex_xu | efried: ah, thanks, when he is back? | |
| 13:58:46 | mriedem | dansmith: i don't really see anything in that series of nikola's changes, anything obvious at least, that warrants the need for including 'accepted' in that not-in-progress list, so i assume it was just something he noticed while going through that stuff | |
| 13:59:01 | efried | Waidaminute... alex_xu comes back and jaypipes is gone.... Has anyone ever actually seen them in the same place at the same time? | |
| 13:59:06 | dansmith | mriedem: yeah seems unrelated | |
| 13:59:23 | mriedem | efried: i have actually | |
| 13:59:25 | efried | alex_xu Not totally sure. Couple weeks? But he's been checking in spottily | |
| 13:59:40 | efried | mriedem Yeah, I did at the PTG. Just being hilariously funny. | |
| 13:59:42 | mriedem | talking about trusted filters and traits | |
| 14:00:23 | alex_xu | efried: ok...thanks | |
| 14:00:39 | efried | alex_xu You looking for SQL brainstorm collab? | |
| 14:00:56 | efried | on traits stuff | |
| 14:01:19 | alex_xu | efried: yea, I rewrite the trait patch as Jay suggested, want to get jay take a look whether it is he expected | |
| 14:01:34 | bauzas | mriedem: sorry, was around | |
| 14:01:48 | bauzas | mriedem: so, no, VMware is no longer using more than one node | |
| 14:01:50 | efried | alex_xu Cool. I have to admit, the way you had it before was pretty baffling to me, though I'm definitely not an expert. | |
| 14:02:04 | efried | alex_xu Which patch? | |
| 14:02:13 | alex_xu | efried: here is one https://review.openstack.org/#/c/479766/10 | |
| 14:02:17 | efried | ... | |
| 14:02:51 | alex_xu | yea, the sql is complex, but as jay said, do that in the python also complex... | |
| 14:03:58 | alex_xu | efried: the original one is https://review.openstack.org/#/c/489206/ | |
| 14:04:32 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] add coverage for update of standard resource class https://review.openstack.org/511485 | |
| 14:04:37 | efried | alex_xu We decided to call it 'required' in GET /allocation_candidates, 对吧 ? | |
| 14:05:05 | efried | alex_xu I'm not completely up on the flow; is it getting translated from 'required' to 'traits' at some point? | |
| 14:05:08 | alex_xu | efried: yes, I will rename it | |
| 14:05:16 | efried | okay, cool | |
| 14:05:28 | alex_xu | efried: 酷 | |
| 14:05:51 | efried | :) | |
| 14:07:33 | mriedem | bauzas: want to have a pass at this spec? https://review.openstack.org/#/c/501017/ | |
| 14:07:42 | mriedem | i'm going to try and go through spec reviews today | |
| 14:09:51 | openstackgerrit | Dan Smith proposed openstack/nova master: Make migration uuid hold allocations for migrating instances https://review.openstack.org/506420 | |
| 14:09:51 | openstackgerrit | Dan Smith proposed openstack/nova master: Refactor resource tracker to account for migration allocations https://review.openstack.org/506419 | |
| 14:09:52 | openstackgerrit | Dan Smith proposed openstack/nova master: Make live migration hold resources with a migration allocation https://review.openstack.org/507638 | |
| 14:11:15 | bauzas | mriedem: sure, I already looked at that one and I remember the PTG discussion | |
| 14:11:18 | mriedem | sdague: is this looking ok for the file injection deprecation plan? https://review.openstack.org/#/c/509013/ | |
| 14:17:03 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Confirm that empty resources query causes 400 https://review.openstack.org/511488 | |
| 14:20:43 | mriedem | hongbin: re https://bugs.launchpad.net/nova/+bug/1690439 | |
| 14:20:44 | openstack | Launchpad bug 1690439 in neutron "[RFE] Deal with NetworkAmbiguous error" [Wishlist,Triaged] | |
| 14:21:04 | mriedem | hongbin: i'm not aware of anyone working on adding a 'default' flag to neutron networks when there are multiple available to the tenant and one isn't specified during server create, | |
| 14:21:33 | mriedem | arguably we could add a config option to nova to let operators say something like, default to public shared=True network or default to private tenant network | |
| 14:26:12 | sdague | mriedem: that seems sane | |
| 14:30:23 | mriedem | sdague: cool | |
| 14:30:38 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Confirm that empty resources query causes 400 https://review.openstack.org/511488 | |
| 14:31:50 | hongbin | mriedem: o/ | |
| 14:31:57 | andreas_s | mriedem: just FYI - I will do the filter change in the zkvm CI by tomorrow - I first want to check if the new regex is working in our test environment before applying it... | |
| 14:32:57 | hongbin | mriedem: it sounds like there are two options and people don't have consensus of which one is preferrable ? | |
| 14:35:54 | gibi | mriedem, sdague, stephenfin: Can we somehow choose one of this two compeeting solutions? https://review.openstack.org/#/c/507253/ and https://review.openstack.org/#/c/507239/ | |
| 14:37:31 | mriedem | gibi: you'll have to find an impartial 3rd party moderator | |
| 14:37:54 | gibi | dansmith: ^^ could you help us? | |
| 14:38:00 | sdague | make dansmith pick one :) | |
| 14:38:18 | sdague | I'm fine with whatever he picks | |
| 14:38:25 | dansmith | why do I have to pick? | |
| 14:38:40 | dansmith | oh because mriedem weaseled out | |
| 14:38:43 | dansmith | ffs | |
| 14:39:15 | gibi | and because we like your decisions | |
| 14:40:56 | dansmith | well, tbh, I feel like mriedem's is easier for me to wrap my brain around.. while I get it's less OO, it's much easier for me to find those for a test that sets them then tons of object hierarchy, like we have with the integrated tests | |
| 14:43:36 | gibi | based on the silence I think there is no objection | |