Earlier  
Posted Nick Remark
#openstack-nova - 2020-04-21
17:11:42 ajitha from pip only not from apt
17:11:57 stephenfin okay, can you paste the full traceback (paste.openstack.org)
17:12:00 stephenfin ?
17:12:49 ajitha sure
17:12:56 ajitha thanks
17:13:04 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Fix the followup comment of policy doc https://review.opendev.org/721322
17:21:50 ajitha stephenfin: http://paste.openstack.org/show/792492/
17:22:21 ajitha paste.openstack didnt allow to paste the complete log..
17:22:26 gmann stephenfin: fixed the comment in this to compare those. merging the same in original patch now https://review.opendev.org/721322
17:25:16 stephenfin ajitha: I suspect you're hitting https://github.com/pypa/pip/issues/988
17:26:27 stephenfin and unfortunately I don't have any easy answers, you need something to install oslo.config >= 3.1.0 before 3.0.3 gets installed
17:26:36 ajitha manual devstack execution works fine with an error throwing as ERROR: nova 20.1.0.dev1681 has requirement oslo.policy>=3.1.0, you'll have oslo-policy 3.0.3 which is incompatible... but it skips that and devstack gets completed. and while executing devstack-gate jenkins job, devstack gets error at the above point
17:27:33 stephenfin We're not hitting that in the nova gate so I suspect it's something to do with a plugin that's installing a package that depends on oslo.config < 3.1.0
17:27:43 stephenfin a plugin in your CI environment, that is
17:28:48 stephenfin the folks on #openstack-infra might be more help; they're well used to dealing with pip's brokenness /o\
17:29:00 ajitha thank you.
17:29:08 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add docs and releasenotes for BP policy-defaults-refresh https://review.opendev.org/720129
17:29:10 ajitha it works with py3.6 too??
17:30:01 stephenfin the gate? yeah, I don't think this is a py3.6 issue
17:30:11 stephenfin it's a pip issue, I'd say
17:30:28 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add docs and releasenotes for BP policy-defaults-refresh https://review.opendev.org/720129
17:32:28 ajitha stephenfin : thanks. The error is throwing in the manual devstack execution(./stack.sh) but it skips and complete the devstack.. In case of devstack-gate, it just stops at that point
18:15:54 gmann stephenfin: gibi this is ready now - https://review.opendev.org/#/c/720129/11
#openstack-nova - 2020-04-22
02:43:35 gmann seems like nova-next is failing on multiple network issue on new stable rescue tests. pushed the fix on tempest side - https://review.opendev.org/#/c/721767/
03:49:02 openstackgerrit sean mooney proposed openstack/nova master: Delete ARQs by UUID if Cyborg ARQ bind fails. https://review.opendev.org/716186
04:53:08 openstackgerrit sean mooney proposed openstack/nova master: cyborg evacuate support https://review.opendev.org/715326
05:00:12 openstackgerrit sean mooney proposed openstack/nova master: cyborg evacuate support https://review.opendev.org/715326
05:00:12 openstackgerrit sean mooney proposed openstack/nova master: Delete ARQs by UUID if Cyborg ARQ bind fails. https://review.opendev.org/716186
07:26:37 bauzas good morning Nova
07:33:39 aarents 'morning
08:22:02 openstackgerrit Sylvain Bauza proposed openstack/nova master: Ussuri 21.0.0 prelude section https://review.opendev.org/721548
08:22:20 bauzas last iteration of prelude ^
09:57:24 openstackgerrit Merged openstack/os-resource-classes master: Cleanup py27 support https://review.opendev.org/719351
10:42:28 gibi lyarwood: hi! do you still plan to have a stable release this week?
10:43:39 kashyap lyarwood: I have this open, will check this today: https://zuul.opendev.org/t/openstack/build/8011a4c1b08e4b9d921660d0c5c2505d
10:43:45 kashyap The virt-preview + Q35 job failure
10:47:15 zigo elod: Should you recheck https://review.opendev.org/711233 ?
10:47:26 zigo The errors look like unrelated.
10:56:39 elod zigo: thanks, yes they seem unrelated, I've initiated the recheck
10:57:16 elod zigo: could you test perhaps the patch somewhere?
11:00:38 lyarwood gibi: yup sorry just on a call, back in 10
11:01:37 gibi lyarwood: no prob
11:09:00 zigo elod: I can yes.
11:09:15 zigo elod: Also, I have tons of warning like this one: "Instance d459e746-ac99-448b-9e44-890fbfdcb6f0 has been moved to another host hostB(hostB). There are allocations remaining against the source host that might need to be removed: {u'resources': {u'VCPU': 1, u'MEMORY_MB': 512, u'DISK_GB': 1}}."
11:09:25 zigo elod: Can this also be due to the same problem ?
11:10:20 zigo elod: Also, I'm unsure how to reproduce the failed migration though ...
11:10:38 zigo That's kind of needed if I want to test your patch, no?
11:14:32 lyarwood gibi: back, so yeah I did want to propose something for each supported branch. I'll get something posted later today for Train and work back from there.
11:14:36 lyarwood elod: ^ FYI
11:14:56 lyarwood kashyap: ack thanks, I've not had a chance to look through it all yet, I assume there's f31 failures in there tbh.
11:25:10 elod lyarwood: thanks for doing that! is there anything waiting for review and then merged before the relese?
11:27:00 lyarwood elod: not for stable/train
11:27:05 elod lyarwood: and of course I can also try to prepare the release patches if needed (do we need other than that for the release?)
11:27:23 lyarwood looks like we have a few things in stable/stein
11:27:34 lyarwood elod: if you have bandwidth then please feel free to do so for train
11:27:57 kashyap lyarwood: Nod
11:28:47 elod lyarwood: sure, I'll do that now
11:28:54 lyarwood awesome thanks elod
11:32:35 elod zigo: hmmm, interesting. I have to check that. About reproduction: there are steps in the bug report but I think that not everything are needed, but haven't looked at it yet.
11:33:30 sean-k-mooney alex_xu: by the way i dont know why https://review.opendev.org/#/c/662264/ that show up as last updted 2 days ago i have not touch it since i abandonded it last august and there has been no update to it in the last 2 days
11:37:59 sean-k-mooney alex_xu: my best guess is someone removed there name form the review list or something like that.
11:45:40 openstackgerrit Qiu Fossen proposed openstack/nova master: The instance is volume backed and power state is PAUSED,shelve the instance failed https://review.opendev.org/711609
11:55:29 gibi lyarwood, elod: thanks a lot!
12:05:02 openstackgerrit Kashyap Chamarthy proposed openstack/nova-specs master: Make Q35 machine type the default for x86 https://review.opendev.org/631154
12:05:18 kashyap lyarwood: --^ For your "copious free time" :)
12:05:39 kashyap lyarwood: I also threw you under the "liaoson bus" without asking checking in first with you ...
12:17:20 sean-k-mooney kashyap: im not actully sure we shoudl be doing that vs the hw:profile concept
12:17:48 kashyap sean-k-mooney: Well, is there something up for the hw:profile thing?
12:18:00 kashyap sean-k-mooney: And why not? 'pc' will be dead _anyway_
12:18:04 sean-k-mooney no not yet
12:18:07 kashyap And we'll be doing the operators a disservice
12:18:12 kashyap I know; not at least for 5 years
12:18:19 sean-k-mooney kashyap: because we can potentailly break people on upgrade
12:18:29 sean-k-mooney its the same reason libvirt did not change the default
12:18:58 kashyap Well, the discussion there is _far_ more nuanced; libvirt is different - it gives the nuts and bolts
12:19:23 kashyap I actually had a few paragraphs of text in the spec (but deleted), they were about:
12:19:34 sean-k-mooney kashyap: there are other factors but that does not demish the fact that we have many fo the same constratints
12:19:54 kashyap ... whether Nova shold make the 'policy' decision. I wrote an example, etc. But cut it out after I saw the recommendations from the QEMU/KVM/libvirt folks over the year
12:20:28 kashyap sean-k-mooney: Yeah, I'm aware of why libvirt did it; I've even linked to it in a previous edition of the commit message
12:20:36 kashyap (The exact change of libvirt and its reasoning)
12:20:50 kashyap sean-k-mooney: I'm typing fast, as I need to have lunch and head out for some air, been cooped up long
12:20:56 kashyap But will catch here later
12:21:46 sean-k-mooney ok but as it stand while i think we shoudl make q35 our default in osp in not sure if we shoudl chagne the code to do that
12:23:47 kashyap sean-k-mooney: Before I head out:
12:23:49 kashyap I'm also open for this:
12:23:56 kashyap - A Nova CI job with 'q35' passes
12:24:11 kashyap - TripleO flips the default from 'pc' --> 'q35'
12:24:12 openstackgerrit Takashi Natsume proposed openstack/nova master: Fix list rendering in the accelerator support doc https://review.opendev.org/721846
12:24:14 sean-k-mooney kashyap: lyarwood is working to make nova-next do that
12:24:34 kashyap sean-k-mooney: Yes, I investigated the failures yesterday and posted a Tempest one-liner for the failing test
12:24:39 kashyap All linked in the spec
12:24:42 sean-k-mooney the ci job and then ya the plan as far as i understood for osp was to change the default in ooo
12:25:05 kashyap sean-k-mooney: Yes, TripleO upstream has this posted: https://review.opendev.org/#/c/716526/
12:25:11 kashyap It is waiting on the Nova CI
12:25:22 sean-k-mooney ah cool
12:25:40 sean-k-mooney im reading your spec now. go have lunch :)
12:26:43 kashyap sean-k-mooney: Thanks. :) Likewise
12:33:14 bauzas gibi: can I hold the bugs lock again ?
12:33:44 openstack Launchpad bug 1874032 in OpenStack Compute (nova) "nova-compute become stuck when doing IO on busy file system" [Undecided,New]
12:33:44 bauzas aarents: thanks for reporting https://bugs.launchpad.net/nova/+bug/1874032

Earlier   Later