| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-20 | |||
| 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 | |
| 09:33:07 | bauzas | kashyap: again, the relnote doesn't mention a bit about guest OSes | |
| 09:33:28 | bauzas | it's just litterally saying "heh, we're changing a default value" | |
| 09:33:48 | bauzas | there is no other contextual information | |
| 09:34:14 | bauzas | if you say "ok, I'm going to amend the relnote in a fup", fine with me | |
| 09:34:22 | bauzas | or I could just do it | |
| 09:34:36 | bauzas | but I just want to make sure operators know about the reasons we decided | |
| 09:34:55 | kashyap | bauzas: Mentioning guest OSes really confuses at this point. | |
| 09:35:09 | kashyap | If an operator has longer attention span, they will carefully read the documentation | |
| 09:35:49 | sean-k-mooney | kashyap: if it was just for perfromance we would not be changing the default however right | |
| 09:36:08 | sean-k-mooney | that is just a side benifit | |
| 09:36:11 | kashyap | Huh, who said it was just for performance? | |
| 09:36:33 | bauzas | kashyap: don't expect operators to load contect on every relnote | |
| 09:36:36 | bauzas | context* | |
| 09:36:51 | bauzas | it's a massive amount of information they have to digest | |