Posted	Nick	Remark
#openstack-nova - 2019-05-28
01:15:42	openstackgerrit	Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (17) https://review.opendev.org/576344
01:16:08	openstackgerrit	Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (18) https://review.opendev.org/576673
01:16:25	openstackgerrit	Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (19) https://review.opendev.org/576676
01:21:42	openstackgerrit	Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (20) https://review.opendev.org/576689
01:22:13	openstackgerrit	Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (21) https://review.opendev.org/576709
01:22:35	openstackgerrit	Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (22) https://review.opendev.org/576712
01:23:08	openstackgerrit	Takashi NATSUME proposed openstack/nova master: Fix cleaning up console tokens https://review.opendev.org/637716
01:23:39	openstackgerrit	Takashi NATSUME proposed openstack/nova master: Remove mox in virt/test_block_device.py https://review.opendev.org/566153
01:26:09	openstackgerrit	Takashi NATSUME proposed openstack/python-novaclient master: Fix a description for config_drive parameter https://review.opendev.org/653683
01:26:39	openstackgerrit	Takashi NATSUME proposed openstack/nova master: Add a live migration regression test https://review.opendev.org/641200
01:56:59	openstackgerrit	guangchao.pan proposed openstack/nova stable/ocata: OpenDev Migration Patch https://review.opendev.org/661662
02:11:55	openstackgerrit	guangchao.pan proposed openstack/nova master: Add a name for the automatically created volume https://review.opendev.org/660096
02:27:38	openstackgerrit	Artom Lifshitz proposed openstack/nova master: Run revert resize tests in nova-live-migration https://review.opendev.org/653498
02:27:38	openstackgerrit	Artom Lifshitz proposed openstack/nova master: [WIP] Revert resize: wait for events according to hybrid plug https://review.opendev.org/644881
02:27:39	openstackgerrit	Artom Lifshitz proposed openstack/nova master: [DNM] use iptables in nova-multinode https://review.opendev.org/660782
03:10:23	openstackgerrit	Seyeong Kim proposed openstack/nova stable/queens: Share snapshot image membership with instance owner https://review.opendev.org/661667
04:40:26	Spencer_Yu	https://bugs.launchpad.net/nova/+bug/1830669
04:40:27	openstack	Launchpad bug 1830669 in OpenStack Compute (nova) "Telemetry service can not get right "operator" of nova resources from notification" [Undecided,New]
06:10:34	openstackgerrit	zhaixiaojun proposed openstack/nova master: Blacklist python-cinderclient 4.0.0 https://review.opendev.org/661578
06:38:54	openstackgerrit	Guo Jingyu proposed openstack/nova master: Define and catch QemuGuestAgentNotRunning for set-password failure https://review.opendev.org/661466
06:58:39	openstackgerrit	Guo Jingyu proposed openstack/nova master: Define and catch QemuGuestAgentNotRunning for set-password failure https://review.opendev.org/661466
07:39:55	openstackgerrit	Adrian Chiris proposed openstack/nova stable/stein: Allow driver to properly unplug VIFs on destination on confirm resize https://review.opendev.org/661495
07:49:58	openstackgerrit	Adrian Chiris proposed openstack/nova stable/rocky: Allow driver to properly unplug VIFs on destination on confirm resize https://review.opendev.org/661500
07:49:58	openstackgerrit	Adrian Chiris proposed openstack/nova stable/rocky: Move get_pci_mapping_for_migration to MigrationContext https://review.opendev.org/661499
07:57:57	kashyap	sean-k-mooney: I first checked in this channel where to put that doc, and was suggested the reference guide (doc/source/reference).
07:58:39	gibi	Spencer_Yu: replied in https://bugs.launchpad.net/nova/+bug/1830669
07:58:40	openstack	Launchpad bug 1830669 in OpenStack Compute (nova) "Telemetry service can not get right "operator" of nova resources from notification" [Undecided,New]
08:07:32	kashyap	sean-k-mooney: I think it actually belongs to the nova/doc/source/admin
08:13:56	openstackgerrit	Balazs Gibizer proposed openstack/nova master: pull out put_allocation call from _heal_* https://review.opendev.org/655459
08:13:56	openstackgerrit	Balazs Gibizer proposed openstack/nova master: Prepare _heal_allocations_for_instance for nested allocations https://review.opendev.org/637954
08:13:57	openstackgerrit	Balazs Gibizer proposed openstack/nova master: nova-manage: heal port allocations https://review.opendev.org/637955
08:22:19	openstackgerrit	Rodolfo Alonso Hernandez proposed openstack/os-vif stable/rocky: Prevent "qbr" Linux Bridge from replying to ARP messages https://review.opendev.org/655692
08:23:16	openstackgerrit	Rodolfo Alonso Hernandez proposed openstack/os-vif stable/queens: Prevent "qbr" Linux Bridge from replying to ARP messages https://review.opendev.org/655694
08:29:32	openstackgerrit	Kashyap Chamarthy proposed openstack/nova master: Document mitigation for Intel MDS security flaws https://review.opendev.org/661574
08:47:10	mrch_	this is funny, when you start an instance on a 100GB volume, fill it with >DATA< importatnt, its saved in ceph in raw, when you create a snapshot(in incance menu not volume) nova creates a 0Byte QCOW2 image snapshot and a volume snapshot (2x wtf?!), start instance from image snapshot and /var/lib/cinder/conversion/volume-XXXX will eat up your apinode root disk, thats dogsht isnt it? following is kind of decribing it, but volume to image
08:47:11	mrch_	is fixed already in rocky, vm on volume to image not, it produces raw: https://bugzilla.redhat.com/show_bug.cgi?id=1677054 Has anyone touched nova.conf qcow parameter and validated it:https://docs.openstack.org/nova/rocky/configuration/config.html
08:47:12	openstack	bugzilla.redhat.com bug 1677054 in openstack-glance "[osp 13]Creating images from cinder volumes with ceph backend is very inefficient" [Medium,New] - Assigned to cyril
09:00:25	ralonsoh	stephenfin, hi. How should I proceed here? https://github.com/openstack/os-vif/blob/stable/queens/tox.ini
09:00:42	ralonsoh	stephenfin, in Queens there is no CONSTRAINTS_OPT=-c {env:UPPER_CONSTRAINTS_FILE:https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt?h=stable/rocky}
09:01:17	ralonsoh	stephenfin, and https://review.opendev.org/#/c/655694/ is failing because of sphinx
09:02:26	ralonsoh	stephenfin, actually, in Queens, requirements doesn't have https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L431
09:10:20	sean-k-mooney	ralonsoh: stephenfin is at the cern openstackday
09:10:41	ralonsoh	sean-k-mooney, hahaha now I remember
09:10:43	sean-k-mooney	ralonsoh: are you not currently backporting that
09:10:56	sean-k-mooney	the upper constratits
09:11:13	ralonsoh	sean-k-mooney, no, I shouldn't because is useless
09:11:24	sean-k-mooney	no its not
09:11:51	ralonsoh	sean-k-mooney, I can't use queens/requirements because sphinx is not limited in this version
09:11:54	sean-k-mooney	why would the upper-constratints be useless
09:12:14	sean-k-mooney	then you need to update the requirements repo to limit it
09:12:44	ralonsoh	sean-k-mooney, OK, and then submit a patch only for queens/os-vif to include it
09:12:50	ralonsoh	sean-k-mooney, is that correct?
09:14:10	sean-k-mooney	ya so cap sphix in the requrement repo for stable queens and then backport https://github.com/openstack/os-vif/commit/96b5a11d35d74faf7c9866dceef66984dbcddae6
09:14:25	sean-k-mooney	actully i can go start backporting ^
09:14:51	sean-k-mooney	well if you dont get to it today
09:15:12	sean-k-mooney	i need to go do something first but we shoudl not be capping locally in os-vif
09:16:07	sean-k-mooney	ralonsoh: actully sphinx is already capped in queens
09:16:09	sean-k-mooney	https://github.com/openstack/requirements/blob/stable/queens/upper-constraints.txt#L365
09:16:23	sean-k-mooney	os-vif just need to use the constratis file
09:16:31	ralonsoh	sean-k-mooney, that's right
09:16:39	ralonsoh	sean-k-mooney, I don't need to modify requirements
09:16:56	sean-k-mooney	right just backport that patch
09:16:59	ralonsoh	sean-k-mooney, I'll submit a patch for os-vif today modifying tox.ini
09:17:01	sean-k-mooney	i whould have done that when i wrote it
09:17:05	ralonsoh	sean-k-mooney, thanks!
09:17:31	sean-k-mooney	can you submit it to all active stable brances
09:18:01	ralonsoh	sean-k-mooney, hahahaha
09:18:03	ralonsoh	sean-k-mooney, https://review.opendev.org/#/c/658780/
09:18:26	sean-k-mooney	right i had tought you had done this already
09:18:32	mrch_	anyone tapped into ^10:47
09:18:36	ralonsoh	sean-k-mooney, my short memory
09:20:46	sean-k-mooney	ralonsoh: it looks like you did not rebase ontop of the constratists fix when you updated https://review.opendev.org/#/c/655694/7
09:21:01	ralonsoh	sean-k-mooney, you are right
09:21:22	openstackgerrit	Rodolfo Alonso Hernandez proposed openstack/os-vif stable/queens: Prevent "qbr" Linux Bridge from replying to ARP messages https://review.opendev.org/655694
09:25:21	openstackgerrit	Balazs Gibizer proposed openstack/os-traits master: Add REPORT_PARENT_INTERFACE_NAME_FOR_SRIOV_NIC trait https://review.opendev.org/658852
09:30:05	gibi	lyarwood: hi! I've replied in https://review.opendev.org/#/c/512553/12//COMMIT_MSG@12 If we could agree with the way forward then I can redo the patch series
09:31:45	lyarwood	gibi: ack thanks, I'll check shortly
09:34:36	kashyap	lyarwood: Do you also have an opinion on the question I asked in the commit message: https://review.opendev.org/#/c/661574/ ("Document mitigation for Intel MDS security flaws")
09:34:42	kashyap	(Thanks for the review, BTW)
09:39:10	lyarwood	kashyap: replied, lets open another review for the meltdown doc if you already have something written.
09:39:42	kashyap	lyarwood: Yeah, it would be another change indeed. Just wanted to make sure if we _want_ to do it or not.
09:40:57	lyarwood	kashyap: I can't think why we wouldn't if you already have some text etc
09:41:14	lyarwood	gibi: replied, I'd be happy with that approach.
09:41:25	kashyap	lyarwood: Heh, yeah. (The text has been sitting there for a while)
09:43:09	gibi	lyarwood: thanks. I will re-shuffle the changes accordingly
12:33:25	openstackgerrit	Merged openstack/nova stable/stein: [stable-only] Improve the reno for consoleauth upgrade check https://review.opendev.org/661123
12:35:48	artom	cdent, you know, you'd think with an extensive portfolio of NFV customer who use NUMA but seldom participate upstream, you'd think RH would have a way of asking them en masse about their preferred use cases
12:36:23	cdent	one would hope so, but it seems hard for everyone, not just RH
12:37:46	artom	cdent, well, with the "upstream" operators, we can just send off a thing to the mailing list. It's not perfect, but it's a start
12:37:55	sean-k-mooney	we try to infer that based on the bugs that get reported but ya we dotn really have a good way of doing it
12:37:55	artom	To my knowledge, no such mechanism exists for our customers
12:38:27	cdent	one gets the impression that the number of operators actively engaged with email is ... limited
12:39:04	sean-k-mooney	there is proably some marketing list that you can opt in to get survays and such but i doubt that apporch would get much feedback
12:39:34	artom	I suspect the majority of operators are paying customers
12:39:43	artom	So they expect their provider to do that work for them
12:40:23	cdent	I'm worried in this instance that we are solving a real/legit problem in the wrong place, but I have nothing other than "feelings" to support that
12:41:02	artom	As we all
12:41:11	cdent	and I certainly don't have any internal customer stuff to support any of that: we continue to not expose any numa details
12:41:20	sean-k-mooney	was tehre a partical thing that propted this topic?
12:41:22	artom	And I suspect this isn't the first or last occurence of such problem solving

Earlier   Later