Earlier  
Posted Nick Remark
#openstack-nova - 2019-04-01
09:51:31 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (15) https://review.openstack.org/576031
09:51:39 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (16) https://review.openstack.org/576299
09:51:51 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (17) https://review.openstack.org/576344
09:52:00 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (18) https://review.openstack.org/576673
09:52:06 openstackgerrit Stephen Finucane proposed openstack/nova master: tests: Stub out privsep modules https://review.openstack.org/648747
09:52:07 openstackgerrit Stephen Finucane proposed openstack/nova master: tests: Stub out os_vif https://review.openstack.org/648748
09:57:17 openstackgerrit Boxiang Zhu proposed openstack/nova-specs master: Add host and hypervisor_hostname flag to create server https://review.openstack.org/645458
10:13:45 openstackgerrit Stephen Finucane proposed openstack/nova stable/queens: Fail to live migration if instance has a NUMA topology https://review.openstack.org/629597
10:13:45 openstackgerrit Stephen Finucane proposed openstack/nova stable/queens: [stable-only] Add report_ironic_standard_resource_class_inventory option https://review.openstack.org/620111
10:13:46 openstackgerrit Stephen Finucane proposed openstack/nova stable/queens: fix up numa-topology live migration hypervisor check https://review.openstack.org/648939
10:16:26 stephenfin bauzas: Any chance you could look at these two trivial fixes? https://review.openstack.org/#/c/648748/ https://review.openstack.org/#/c/648747/
10:16:50 kashyap stephenfin: If you have time this week: https://review.openstack.org/#/c/645814/ (Add "CPU selection with hypervisor consideration" spec)
10:17:50 kashyap Also appreciate a critical eye from the "native English speaker" point of view. /me already spent far too much time (is there such a thing?) with words. :-)
10:18:57 sean-k-mooney kashyap: wordsmithing
10:19:16 kashyap sean-k-mooney: Yeah, I enjoy it :-)
10:19:23 kashyap Also your feedback is appreciated, too. If you have time.
10:33:20 kashyap Unrelated: Is it really frowned upon to rename a (previously-approved) blueprint (with a spec), when re-proposing?
10:34:12 kashyap (I didn't file the blueprint, but the name bothers me.)
10:34:42 kashyap This is the BP: https://blueprints.launchpad.net/nova/+spec/cpu-model-selection
10:34:50 kashyap And my suggested "diff" is:
10:34:55 kashyap - cpu-model-selection
10:34:56 kashyap + allow-a-list-of-cpu-models
10:34:57 sean-k-mooney i dont think so if the new name makes more sense
10:35:23 sean-k-mooney on the other hand it goes slightly beyond https://github.com/openstack/nova-specs#previously-approved-specifications
10:35:37 kashyap Probably I'll quit editing it. As I don't want to break others bookmarks
10:36:06 kashyap I don't really dislike it _that_ much, and can slightly grudgingly live with it. :D
10:36:39 sean-k-mooney you could jsut file a new blueprint and update the old one to say its superceed by the new one
11:05:19 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (19) https://review.openstack.org/576676
11:05:27 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (20) https://review.openstack.org/576689
11:05:37 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (21) https://review.openstack.org/576709
11:05:47 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (22) https://review.openstack.org/576712
11:26:04 sean-k-mooney efried: fyi this https://blueprints.launchpad.net/nova/+spec/consistent-use-of-network-events is the blueprint to track teh nova side of the neutron spec https://review.openstack.org/#/c/645173/
11:48:15 openstackgerrit Surya Seetharaman proposed openstack/nova-specs master: Support adding the reason behind a server lock https://review.openstack.org/638629
12:19:02 bauzas stephenfin: I'll take a look
13:09:00 openstackgerrit sean mooney proposed openstack/nova master: make lower-constraints env use lower-constraints https://review.openstack.org/645392
13:09:10 efried sean-k-mooney: ack, thanks.
13:09:40 efried sean-k-mooney: Are you wanting it targeted for train?
13:10:26 sean-k-mooney the blueprint i think so yes but that will likely depend on the conversation at the PTG.
13:11:09 sean-k-mooney we (nova and neutorn) could decide that it was not a priority for train but it is techdebt i would like to resovle eventually
13:12:00 sean-k-mooney efried: by the way im hoping we can merge either cdents lower constratints fix https://review.openstack.org/#/c/622972 or mine https://review.openstack.org/645392 sooner rather then later
13:12:18 efried sean-k-mooney: I'll mark the bp series goal for train then.
13:12:31 cdent sean-k-mooney: what's the essential difference?
13:12:39 cdent (between mine and yours)
13:14:06 sean-k-mooney cdent: i thihk at this point they are more or less the same although you remove a test i didnt need too
13:14:59 sean-k-mooney cdent: also your's has a better commit message but it does not have the close bug line "Closes-Bug: #1822575" for the bug i opened to track it
13:15:00 openstack bug 1822575 in OpenStack Compute (nova) "lower-constraints are not used in gate job" [Undecided,In progress] https://launchpad.net/bugs/1822575 - Assigned to sean mooney (sean-k-mooney)
13:15:33 sean-k-mooney cdent: im fine to abandon min in favor of yours as long as one of them is merged
13:18:53 efried They do seem to differ a fair bit in the updates to l-c
13:19:01 sean-k-mooney they do
13:19:09 efried and requirements.txt
13:19:37 sean-k-mooney i tried to make as few chagnes as i coudl initally but ended up pulling in some of the changes cdent had made.
13:19:59 efried sean-k-mooney: You're not thinking to backport this to stein, are you?
13:20:35 sean-k-mooney efried: no. we could but if we did the lower constraitn version change would have to be different
13:20:54 sean-k-mooney well we proably should backport somthing but it cant be exactly the same
13:21:07 efried backporting requirements changes is messy under the best of circumstances; I would think we should avoid doing it at all unless there's a really good reason.
13:21:50 sean-k-mooney efried: well what i was planning to do was backport the tox change only and see if it worked on stable*
13:22:16 sean-k-mooney the older the branch the more likely it will
13:22:26 efried but not stein
13:22:49 sean-k-mooney stein need some of the version bumps or the unitest wont work
13:23:51 sean-k-mooney for example oslo.messaging 7.0.0 is need for the mocking of RPC calls to work properly
13:24:55 sean-k-mooney were as branches that test with ubuntu-xenial dont ned the psycopg2 bump as i think they wont have postgresql 10.3
13:27:22 efried sean-k-mooney: I'm asking thode about it in -requirements.
13:27:28 efried cdent also ^
13:27:37 efried sean-k-mooney: meanwhile, would you please ack https://review.openstack.org/#/c/647512/ for me?
13:27:57 efried mriedem: have you started looking at the lm job yet?
13:28:14 mriedem efried: i didn't see any bug reported for it
13:28:33 efried Yeah, I haven't opened one or looked into it at all, just noticed (on my bug mail on my phone) that it's failing 100% since like Friday.
13:28:40 sean-k-mooney if by ack you mean +1 ill review it now but yes i think this is the more complete fix for the patch i abandoned
13:28:43 efried just didn't want to start digging if you were already in there
13:28:58 mriedem efried: first morning back from vacation so no i'm not on it
13:29:05 efried sean-k-mooney: Yes, that's what I'm looking for, since you had already started to think about the solution previously.
13:30:40 efried mriedem: ack. I could actually use a brief tutorial on how you do the triage here. You seem to have a system for identifying when failures started and registering the signature of the problem somewhere (e-r?).
13:30:42 efried if you have time.
13:30:52 mriedem efried: i'd need a link to a failing job first
13:30:53 efried teach me to fish, in other words
13:31:04 efried mriedem: stand by
13:31:12 efried (but any patch from the past three days)
13:31:19 mriedem ok http://logs.openstack.org/00/641200/7/check/nova-live-migration/d55c8ab/
13:31:27 efried https://review.openstack.org/#/c/648653/
13:31:46 mriedem looks like this is the problem http://logs.openstack.org/00/641200/7/check/nova-live-migration/d55c8ab/job-output.txt.gz#_2019-04-01_11_12_47_685033
13:31:51 mriedem Multiple possible networks found, use a Network ID to be more specific. (HTTP 409) (Request-ID: req-6c6a7e2b-6e5a-4ff4-ba6a-a3aaa8d8f83a)
13:32:18 mriedem which probably means https://github.com/openstack-dev/devstack/commit/0d4c9c9fa37c6f47523359044e5f65629321ff6d
13:33:23 mriedem so if i take "Multiple possible networks found, use a Network ID to be more specific" from that nova-live-migration console log and dump it in logstash, i bet it starts around 3/29
13:35:34 efried clearly I don't know how to use logstash
13:35:45 mriedem http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22Multiple%20possible%20networks%20found%2C%20use%20a%20Network%20ID%20to%20be%20more%20specific%5C%22%20AND%20tags%3A%5C%22console%5C%22%20AND%20build_name%3A%5C%22nova-live-migration%5C%22&from=7d
13:36:08 mriedem so the message filter is part of the message above, excluding anything unique like a request id
13:36:09 mriedem or timestamp
13:36:19 mriedem the 'tags' is the file the message is in, so 'console' in this case
13:36:40 mriedem and i threw build_name in there, which we don't normally do, but figured i would to avoid noise from falst negatives in functional jobs or something
13:36:47 mriedem *false
13:37:18 efried how did you get it to span the correct time frame?
13:37:32 mriedem anyway, my guess is https://review.openstack.org/#/c/601433/ because (1) devstack creates the networks we're using here and (2) it doesn't fail for tempest because tempest always provides a specific nic when creating a server, but in the evacuate tests in nova-live-migration we don't
13:37:46 mriedem used the dropdown at the top right
13:38:20 mriedem https://wiki.openstack.org/wiki/BootstrappingHour/Debugging_Gate is old but might be relevant still
13:38:27 efried Cool. So now a bug needs to be opened, and then registered in e-r?
13:38:31 mriedem yeah
13:39:19 efried how did you get from the error message to the patch? Did you just happen to know about that devstack change?
13:40:50 mriedem i didn't, but i know that devstack creates the network we use in testing,
13:41:06 mriedem so assumed that because we're now failing on ambiguous network errors, someone started creating a 2nd network in devstack
13:41:10 mriedem lo and behold someone did

Earlier   Later