Earlier  
Posted Nick Remark
#openstack-nova - 2019-03-20
22:05:24 cdent 2. change that test to do things differently (hard because the reference to the in ram sqlite database needs to be maintained)
22:05:53 cdent 3. change the placement fixture (on the placement side) to take a flag to register or not register opts
22:06:17 cdent 3 is probably the best choice in the long run, and won't take me long to do
22:06:27 efried why does the placement fixture need to register opts ever?
22:06:45 cdent because it has to use opts in order to start placement
22:06:49 efried I guess when tests go after opts, the defaults need to be there.
22:06:51 efried and that
22:07:10 cdent unfortunately the way oslo_config works, it has to know about stuff
22:07:15 cdent (good and bads to that)
22:07:28 efried 3 today, or should we 1 to unblock and then 3?
22:07:54 cdent the mode the fixture has now is "don't make the caller think, if possible"
22:08:06 cdent I'm happy with just 3 if everyone else is
22:08:19 cdent but if you want to unblock quicker, then 1 and then 3
22:08:40 efried yeah, let's merge 1 and you can put 3 on top and include unrevert in it?
22:09:13 cdent I wanted to be able to find a version of 2, but that test is already so hairy I don't think it is worth
22:09:14 cdent sure
22:09:33 cdent feel free to push the revert through
22:10:03 efried cdent, mriedem, melwitt: fast-approved https://review.openstack.org/#/c/645014/
22:10:44 efried and then mriedem respun and did same, neat
22:10:51 mriedem i added the bug tag
22:11:06 efried yup, ++
22:12:58 openstackgerrit Eric Fried proposed openstack/nova master: DNM: Trying a different strategy for tests https://review.openstack.org/645026
22:19:57 melwitt efried: ack, thanks
22:25:45 mriedem well now i'm depressed and have a 2 hour call in 3 hours so it's time to leave
22:35:40 NobodyCam anyone have any pointers to stacking down instances stuck in scheduling .. I set nova* to debug mode and don't see any errors jumping out
22:36:26 NobodyCam s/stracking/tracking
22:36:39 openstackgerrit Chris Dent proposed openstack/nova master: Don't register placement opts mutiple times in a test https://review.openstack.org/645033
22:37:37 cdent mriedem_away, efried ^ that fixes the nova side and depends-on the placement side fix
22:39:02 NobodyCam I do see this in the compute log:
22:39:04 NobodyCam Instance 7d8f61e6-155c-47a9-9d35-95939b29d487 has been scheduled to this compute host, the scheduler has made an allocation against this compute node but the instance has yet to start. Skipping heal of allocation: {u'resources': {u'MEMORY_MB': 1024, u'VCPU': 1, u'DISK_GB': 20}}. _remove_deleted_instances_allocations /openstack/venvs/nova-18.1.5.dev5/lib/python2.7/site-packages/nova/compute/resource_tracker.py:1355
23:16:22 aspiers cdent: OK, now you are not just ahead of me but downright telepathic. I was about to report that placement issue...
23:17:00 cdent aspiers: which one?
23:17:17 aspiers the option registering
23:17:38 cdent that's mriedem_away's psychic powers not mine
23:18:49 aspiers OK, so you just fixed it :)
23:19:12 aspiers Either way it's nice when things get fixed even before I get a chance to report them
23:19:17 aspiers haha
23:20:17 cdent it's all smoke and mirrors. There's an openstack cabal where people like efried, mriedem_away, me place latent bugs into the code that we can then fix quickly, making ourselves appear heroic and super insightful
23:20:40 aspiers That's dastardly cunning
23:21:04 cdent the chaos that you see isn't figuring out the solution for the bug, it's figuring out which bug, of the many that we have caused, is being revealed this time
23:21:30 aspiers I'd hope our govt was doing the same, but alas they're not
23:21:38 cdent heh
23:22:04 cdent it's...shocking
23:22:40 aspiers damn right
23:32:34 mriedem efried: cdent: thanks got both
23:55:38 mriedem sorrison: if you can't make the next nova meeting, you could add https://bugs.launchpad.net/nova/+bug/1819568 to the open discussion agenda as a potential specless blueprint
23:55:39 openstack Launchpad bug 1819568 in OpenStack Compute (nova) "RFE: network_data.json doesn't contain information about floating IPs" [Wishlist,Opinion]
#openstack-nova - 2019-03-21
03:29:03 openstackgerrit Ghanshyam Mann proposed openstack/nova-specs master: Spec for API policy updates https://review.openstack.org/547850
03:29:54 openstackgerrit Ghanshyam Mann proposed openstack/nova-specs master: Spec for API policy updates https://review.openstack.org/547850
04:55:22 openstackgerrit Yongli He proposed openstack/nova master: Clean up orphan instances https://review.openstack.org/627765
05:15:05 openstackgerrit Merged openstack/python-novaclient stable/stein: Update UPPER_CONSTRAINTS_FILE for stable/stein https://review.openstack.org/644182
05:15:05 openstackgerrit Merged openstack/python-novaclient stable/stein: Update .gitreview for stable/stein https://review.openstack.org/644181
05:42:34 openstackgerrit Merged openstack/os-vif stable/stein: Update .gitreview for stable/stein https://review.openstack.org/644034
07:51:22 kashyap sean-k-mooney: Hi, just saw the ping in the scrollback; there's a lot of text. Hope klindgren's problem is resolved :-)
08:00:22 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: libvirt: Use 'writeback' QEMU cache mode when 'none' is not viable https://review.openstack.org/641981
08:00:23 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: libvirt: vzstorage: Use 'writeback' QEMU cache mode https://review.openstack.org/643376
08:00:24 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: libvirt: smbfs: Use 'writeback' QEMU cache mode https://review.openstack.org/643377
08:04:05 kashyap efried: When you get a moment, lost yours / SylvainB's +2s & +W; appreciate if you can re-ACK|NACK it.
08:39:48 kashyap bauzas: ^ When you get a moment :-)
08:40:17 kashyap (It already had +W, just lost the ACK due to rebase)
09:24:03 kashyap bauzas: Docs will be fixed in a separate change
09:24:12 kashyap To not let the core patch be blocked
09:24:15 bauzas cool with me then
09:24:25 kashyap bauzas: Please see the review comments :-) MattR and MattB both agreed on the change
09:24:35 kashyap That to let this merge, and I fix the rest of the documenation
09:24:39 bauzas just comment and say you'll add a fup
09:24:49 bauzas sorry, fup == follow-up change
09:24:52 kashyap Yeah, it's actually added
09:24:58 kashyap bauzas: Also at the end of the commit message I noted as such
09:25:10 kashyap [quote]
09:25:11 kashyap Do the minimum required update to the `disk_cachemodes` config help text. (In a future patch, rewrite the cache modes documentation to fix confusing fragments and outdated information.)
09:25:15 kashyap [/quote
09:27:15 bauzas kashyap: sure, but I still feel we need to document in the relnote why we now recommend writeback as default
09:27:27 kashyap bauzas: Rel Note is also there
09:27:35 bauzas basically because modern OSes fsync
09:27:38 kashyap bauzas: The default depends on what file system one is using
09:27:59 bauzas but if operators are scary about that, they should just keep writethrough and not use default
09:28:13 bauzas kashyap: yup, but you're not telling it in the relnote
09:28:22 kashyap bauzas: The documentation fix follow right after that.
09:28:24 bauzas operators litterally have to load a lot of context
09:28:35 kashyap bauzas: No need for the operators to be "scary" here. There are lots of myths about cache modes
09:28:36 bauzas again, I'm talking about relnotes
09:28:50 kashyap Let me re-read it
09:29:14 bauzas tbc, my -1 is due to https://review.openstack.org/#/c/641981/13/releasenotes/notes/writeback-cache-mode-for-guests-a7e4d2806c956164.yaml@8
09:29:17 kashyap bauzas: Okay, saw your comment on the rel note -- again, not required to add your comment
09:29:46 kashyap bauzas: Really, that's not required. The guest OSes that don't fsync() are really really really horribly old and we don't support
09:30:10 bauzas kashyap: I mean, we're making an opinionated choice, right? If so, let's just capture it in the relnote
09:30:22 bauzas and not just in the commit msg, which is bad for operators
09:30:42 bauzas and technically, I accepted it as a fix, but this isn't really a fix
09:30:46 kashyap bauzas: Huh. That's what the rel note says
09:30:58 bauzas it's a performance improvement
09:30:59 kashyap bauzas: I don't follow you. What is not really a fix?
09:31:06 kashyap Well, it's both.
09:31:23 bauzas let's take an example
09:31:28 bauzas I have a car which is running
09:31:29 kashyap (1) Fixing wrong assumption in Nova; (2) And (1) brings performance improvement
09:31:41 bauzas for sure, the engine is running
09:32:01 bauzas but I can make sure that I can improve the engine by changing some, say, injector
09:32:23 bauzas that will possibly make my engine having trouble when I stop, for example, but that's depending on my driving
09:32:36 bauzas so, I like to know that I can improve my engine by changing my driving

Earlier   Later