Earlier  
Posted Nick Remark
#openstack-nova - 2019-08-09
13:23:03 mriedem got another queens backport that needs +W https://review.opendev.org/#/c/669126/
13:23:12 artom mriedem, didn't know Elizabeth was in jail...
13:24:46 mriedem i'm missing the reference
13:25:11 cdent artom: the life of a royal is constant imprisonment and suffering, don't ya know
13:26:09 mriedem oh queens release day, i see
13:27:47 lyarwood mriedem: ack done
13:27:54 mriedem can you hit these as well? https://review.opendev.org/#/q/topic:bug/1837955+branch:stable/queens
13:28:03 lyarwood sure thing
13:28:21 gibi based on the joke it is definitely Friday!
13:28:50 mriedem could use a stable core on these as well https://review.opendev.org/#/q/topic:bug/1764556+branch:stable/queens
13:28:53 mriedem johnthetubaguy: ^?
13:32:14 mriedem another queens backport https://review.opendev.org/#/c/672161/2
13:35:08 openstackgerrit Matt Riedemann proposed openstack/nova stable/queens: Fix type error on call to mount device https://review.opendev.org/669629
13:36:11 mriedem and https://review.opendev.org/#/c/669629/
13:38:03 openstackgerrit Matt Riedemann proposed openstack/nova stable/queens: Disable limit if affinity(anti)/same(different)host is requested https://review.opendev.org/659247
13:38:28 openstackgerrit Matt Riedemann proposed openstack/nova stable/queens: Disable limit if affinity(anti)/same(different)host is requested https://review.opendev.org/659247
13:46:24 finucannot aspiers: So apparently I can't access lxml documentation because it's Friday and that's not allowed (try navigating to lxml.de)
13:48:26 mordred the code is self-documenting?
13:48:46 finucannot I guess it _has_ to be
13:49:55 mriedem you can get to https://lxml.de/tutorial.html
13:50:21 mriedem https://lxml.de/api/index.html
13:50:29 finucannot Ah, sweet
13:50:32 finucannot mriedem++
13:50:33 mriedem that'll be $5 please
13:51:48 finucannot Darn, I'm fresh out of dollar bills. Crying shame, that
13:52:34 mriedem i'll take 5 eu
13:53:00 finucannot Britain refuses to take even one
13:53:21 mriedem boris has it under control
13:54:14 mriedem polite muttering i'm sure
14:04:33 aspiers mriedem: no swear-words in this channel please
14:05:29 frickler mriedem: I commented on https://bugs.launchpad.net/nova/+bug/1669468 earlier with what I think would be the reason for about 50% failure rate, but I'm not sure at which place to fix it
14:05:29 openstack Launchpad bug 1669468 in OpenStack Compute (nova) "tempest.api.compute.servers.test_novnc.NoVNCConsoleTestJSON.test_novnc fails intermittently in neutron multinode nv job" [Medium,Confirmed]
14:15:02 melwitt frickler: I think your assessment sounds probable. I think I could find where to fix it, I've done a few changes to console settings in devstack in the past
14:16:10 mriedem sorry, on a call now but will take a look later
14:19:21 cdent good article belmoreira . I made a couple of suggested edits. It seems like "The provider_tree "deepcopy" should be re-evaluated" is the big takeaway. Based on my recent posting it _might_ make sense to add a __copy__ to provider tree
14:27:00 openstackgerrit Matt Riedemann proposed openstack/nova stable/queens: Disable limit if affinity(anti)/same(different)host is requested https://review.opendev.org/659247
14:38:25 openstackgerrit Merged openstack/nova stable/queens: Stabilize unshelve notification sample tests https://review.opendev.org/674636
14:45:22 mriedem need a stable core for this queens one as well https://review.opendev.org/#/c/666862/
14:47:44 dansmith mriedem: I can just +W that because the only conflict was a test yeah?
14:47:57 openstackgerrit Matt Riedemann proposed openstack/nova stable/queens: Fix double word hacking test https://review.opendev.org/665790
14:48:07 dansmith (as in without looking very hard)
14:58:29 mriedem dansmith: yeah
15:03:47 finucannot aspiers, sean-k-mooney: We're touching an awful lot of the same code between the amd-sev-libvirt-support, image-metadata-prefiltering and cpu-resources specs. I forsee a lot of merge conflicts, but also a chance to share best practices
15:04:03 finucannot aspiers, sean-k-mooney: Especially around the scheduler pre-filter stuff. Lots of comments left on both series
15:08:52 mriedem dansmith: since you just went through these for rocky, if you have a minute https://review.opendev.org/#/q/topic:bug/1764556+branch:stable/queens
15:08:55 mriedem i'm trying to flush queens for the release
15:13:08 aspiers finucannot: I feel like libvirt/driver.py and test_driver.py are horrendously big and could do with splitting up somehow
15:13:22 melwitt otherwise I can do those, I meant to but was watching the rocky change land first. I should have pre-reviewed
15:14:06 finucannot aspiers: Aye, it regularly crashes the flake8 process in syntastic (Vim plugin). I don't even know where to start though
15:14:10 artom mriedem, you're going for a royal flush?
15:14:21 mriedem no, 4 of a kind
15:14:33 mriedem shoot the moon
15:14:52 artom groaning \o/
15:15:16 mriedem this is the current +2'ed list of queens changes https://review.opendev.org/#/q/status:open+project:openstack/nova+branch:stable/queens+label:Code-Review=2
15:15:18 mriedem if that helps
15:21:58 dansmith mriedem: that service too old set looked like a clean pick from the previous yeah?
15:22:28 dansmith makes sense I guess since most of the change is the added and then modified tests
15:23:34 mriedem yup no conflicts
15:29:37 belmoreira thanks cdent
15:32:19 mriedem melwitt: are you working on a patch for bug 1669468? otherwise i can throw one up quick to see if it explodes.
15:32:19 openstack bug 1669468 in OpenStack Compute (nova) "tempest.api.compute.servers.test_novnc.NoVNCConsoleTestJSON.test_novnc fails intermittently in neutron multinode nv job" [Medium,Confirmed] https://launchpad.net/bugs/1669468
15:33:04 melwitt mriedem: I was planning to but haven't looked yet. if you have something to try, go ahead
15:33:39 mriedem btw i've got most of the tests in https://review.opendev.org/#/c/675218/ fixed but there are 2 failing for some yet unknown reason https://review.opendev.org/#/c/675218/
15:34:33 melwitt ack
15:41:22 openstackgerrit Merged openstack/nova stable/queens: fix cellv2 delete_host https://review.opendev.org/672690
15:41:29 openstackgerrit Merged openstack/nova stable/queens: Add functional regression test for bug 1837955 https://review.opendev.org/673567
15:41:29 openstack bug 1837955 in OpenStack Compute (nova) queens "MaxRetriesExceeded sometime fails with messaging exception" [Medium,In progress] https://launchpad.net/bugs/1837955 - Assigned to Matt Riedemann (mriedem)
15:42:13 openstackgerrit Merged openstack/nova stable/queens: libvirt: flatten rbd images when unshelving an instance https://review.opendev.org/668123
15:46:05 mriedem frickler: melwitt: this might have been the regression https://review.opendev.org/#/c/672493/6
15:46:33 mriedem heh, and test_novnc failed on that change http://logs.openstack.org/93/672493/6/check/tempest-multinode-full/2e30174/testr_results.html.gz
15:46:42 mriedem but the tempest-multinode-full job is non-voting in devstack so no one noticed
15:47:22 melwitt ah, yeah looks like it
15:47:26 mriedem that explains the recent up-tick in this failing all of a sudden again
15:52:41 cdent ah, melwitt, we're around at the same time. I was tasked yesterday with checking with you (and others) about the urgency/priority of consumer types so we can determine if we need to push harder o nit
15:55:43 melwitt cdent: I wouldn't say it's "urgent" but definitely something important. the earliest we could integrate it in nova is U though
15:56:08 melwitt and I expect the integration to be pretty involved
16:03:09 openstackgerrit Merged openstack/nova stable/queens: Cleanup when hitting MaxRetriesExceeded from no host_available https://review.opendev.org/673576
16:05:17 finucannot mriedem: What's the difference between 'filter_by(foo == False)' and 'filter_by(foo == false())' in the context of SQLAlchemy?
16:05:45 openstackgerrit Matt Riedemann proposed openstack/nova stable/queens: doc: Fix a parameter of NotificationPublisher https://review.opendev.org/670226
16:07:11 mriedem my understanding is that false() can be implemented by underlying db translation layers, e.g. ibm_db_sa, to translate what false means, so if the boolean type is an int (0 or 1) rather than False/True
16:07:17 mriedem but, it's a question for zzzeek really
16:07:39 mriedem https://docs.sqlalchemy.org/en/13/core/sqlelement.html?highlight=false#sqlalchemy.sql.expression.false
16:07:51 mriedem "A backend which does not support true/false constants will render as an expression against 1 or 0:"
16:08:11 finucannot I was looking at that (linked to it in a review) but didn't get whether we needed it or not
16:08:24 finucannot I guess MySQL, Postgres and SQLite all support the constants
16:08:29 mriedem for mysql/pg i don't think it's a problem
16:08:30 mriedem yeah
16:08:42 finucannot fair. Much of a muchness so
16:08:46 mriedem https://www.postgresql.org/docs/9.1/datatype-boolean.html
16:11:31 mriedem how do i know? because older versions of db2, when i needed to care, used 0/1 for booleans
16:11:52 mriedem boolean booleans were for gen-x'ers and their ilk
16:12:48 finucannot flashbacks to writing embedded C with Acme crap proprietary compilers back in uni
16:15:02 mriedem but did you wear a uni in uni? https://photos.app.goo.gl/fu4qRMpbNGtbTDfU6
16:16:40 mriedem dansmith: i think https://bugs.launchpad.net/nova/+bug/1839621 is where you come in and say # in the password has to be encoded
16:16:40 openstack Launchpad bug 1839621 in OpenStack Compute (nova) "Inappropriate split of transport_url string" [Undecided,New]
16:17:39 finucannot Much to my dismay, no, I did not
16:22:56 cdent thanks melwitt, I got your response out of the logs. Had a power outage just then.
16:24:54 cdent melwitt: so from your perpective getting the funcitonality done in placement before U starts up would be helpful
16:27:36 melwitt cdent: I don't think it's critical, but I feel like the question would be better answered by someone like tssurya, who is planning to consume the changes
16:27:59 cdent melwitt: she was involved in the earlier discussions and was hoping for more input from you

Earlier   Later