Earlier  
Posted Nick Remark
#openstack-nova - 2019-03-20
11:14:12 cdent yeah, fine, I tried to delete that code ! :)
11:14:21 mdbooth cdent: Yeah, if you could move that out of the way...
11:14:28 aspiers sean-k-mooney: yeah, I'm gonna ask infra about that
11:14:32 aspiers https://httpd.apache.org/docs/2.4/caching.html
11:14:57 sean-k-mooney well in generaly what is the point of allowing cdns to cache logs.openstack.org
11:15:18 sean-k-mooney the browser sure but i dont hink we can do one without the other
11:15:23 sean-k-mooney maybe we can
11:15:34 cdent mdbooth: i'll do it on saturday, with a tps repoert
11:16:21 sean-k-mooney aspiers: actully its proably fine to cache it so if they want to update it it proably wont have any negitive impact
11:16:35 aspiers right, because the paths are unique
11:16:36 sean-k-mooney most logs on logs.openstack.org never get read anyway
11:16:50 cdent they could relatively easily have a last-modified header
11:16:57 cdent which would at least allow a conditional get
11:17:16 sean-k-mooney yep each run is a new file even for the same patch so you will never get cached old data where the content on the server has changed
11:20:41 kashyap mdbooth: Want to give your final ACK/NACK on this: https://review.openstack.org/#/c/641981/
11:22:30 mdbooth kashyap: "This improves performance without compromising data integrity". You could stick that in a politician's stump speech alongside mom and apple pie.
11:22:47 kashyap LOL
11:23:02 kashyap mdbooth: If you prefer a different phrasing, I'm open to critique
11:23:22 mdbooth kashyap: Absolutely not. It's straight to the point.
11:23:24 kashyap aspiers: (Thanks for your remark on that trade-off of: readability vs. indirection. I've bookmarked the talk :-))
11:23:44 kashyap mdbooth: Okay, I get lunch then. Thanks for looking! Appreciate your time.
11:24:17 kashyap aspiers: (I'm largely with you on it, as I was also feeling uneasy that method becoming longer and longer.)
11:24:23 aspiers kashyap: :)
12:02:25 openstackgerrit Merged openstack/os-resource-classes master: Update master for stable/stein https://review.openstack.org/644030
12:05:01 openstackgerrit Merged openstack/os-traits master: Update master for stable/stein https://review.openstack.org/644033
12:29:23 openstackgerrit Merged openstack/os-resource-classes stable/stein: Update .gitreview for stable/stein https://review.openstack.org/644028
12:30:20 openstackgerrit Merged openstack/os-traits stable/stein: Update .gitreview for stable/stein https://review.openstack.org/644031
12:30:40 openstackgerrit Merged openstack/os-resource-classes stable/stein: Update UPPER_CONSTRAINTS_FILE for stable/stein https://review.openstack.org/644029
12:36:52 openstackgerrit Merged openstack/os-traits stable/stein: Update UPPER_CONSTRAINTS_FILE for stable/stein https://review.openstack.org/644032
12:46:02 kashyap mdbooth: You are right. That whole documentation mess needs fixing. I'll hold my nose and get that going.
12:46:39 kashyap mdbooth: And on that fated IBM article from the past ... look, I apparently "debunked" it as far as 2014: https://www.redhat.com/archives/libvirt-users/2014-August/msg00060.html ("Behavior of disk caching with qcow2 disks")
13:21:30 openstackgerrit Merged openstack/nova master: Move slight bonkers IP management to privsep. https://review.openstack.org/624592
13:25:33 bauzas efried: FWIW, I'd have loved to have time for reviewing https://review.openstack.org/#/c/644412/ but fortunately, it's not merged yet
13:29:11 efried bauzas: I knew it was going to hang on in the queue for a while, but we're also a bit tight for time so I didn't want it not to merge because we forgot to +W it.
13:29:37 efried I didn't mean to cut anyone out, sorry.
13:29:42 bauzas no worries
13:30:06 bauzas just for the next release, we open the prelude change 2 days before and we leave it there at least some time
13:30:14 efried noted, thank you.
13:39:08 aspiers kashyap: https://review.openstack.org/#/c/644554/ is ready for review
13:39:41 aspiers efried: anyone else I should add to review for that? ^^
13:39:46 openstackgerrit Matthew Booth proposed openstack/nova master: Eventlet monkey patching should be as early as possible https://review.openstack.org/626952
13:43:14 mdbooth It's going to be revised in a second ;)
13:43:35 mdbooth Line length violations after I indented everything and forgot to rerun pep8
13:45:02 efried aspiers: Dunno. Maybe bauzas would like to look :)
13:45:30 bauzas I can
13:45:49 efried thanks bauzas. Should be an easy one, just a refactor (and an extra log)
13:46:01 aspiers and extra tests!! \o/
13:46:40 openstackgerrit Matthew Booth proposed openstack/nova master: Eventlet monkey patching should be as early as possible https://review.openstack.org/626952
13:46:43 mdbooth Ok, ^^^ is the one. Really.
13:46:59 mdbooth stephenfin: How do you feel about the sphinx bodge in ^^^ ?
13:47:30 stephenfin mdbooth: It's necessarily awful
13:47:42 mdbooth stephenfin: Why thank you
13:47:48 stephenfin :)
13:47:57 kashyap aspiers: Looks good to me.
13:48:08 aspiers kashyap: thanks
13:48:57 mdbooth If there's any other way which doesn't involve moving entry points, and therefore impacting deployment tooling, I'd do that instead.
13:49:15 mdbooth It's kinda icky, but it's the best I can think of.
13:50:32 stephenfin mdbooth: It'll do for 6 months, I imagine
13:50:41 stephenfin at which point we should be aiming to rip that all out
13:51:13 mdbooth stephenfin: Yarp.
13:51:20 efried that's a new one on me, thanks mdbooth
13:51:27 mdbooth efried: dirty hack that works
13:51:42 mdbooth efried: Code I'm not proud of
13:51:44 sean-k-mooney mdbooth: is the bodge hardcoding OS_NOVA_DISABLE_EVENTLET_PATCHING in the conf.py
13:52:06 mdbooth sean-k-mooney: Both that, and requiring it at all
13:55:11 mdbooth Wait, I think I just did think of a better way
13:55:13 sean-k-mooney i was going to leave a review comment but honestly my tastae for anyting in this patch can be adressed in train. assuming this works and the gate is happy i think this is good enough for stien
13:55:44 efried mriedem: Care to re-wordsmith https://review.openstack.org/#/c/644412/4/releasenotes/notes/stein-prelude-b5fe92310e1e725e.yaml@57 ? Or I can take a stab at it, but you know the reward for good work...
13:55:46 mdbooth Ok, there's another version coming which eliminates that.
13:55:50 sean-k-mooney condtionally setining it if not set instead of hardcoding
13:56:05 sean-k-mooney e.g. by usign the defualt valude on the get call
13:56:10 mdbooth We originally did: from nova import utils; utils.monkey_patch()
13:56:52 mdbooth Oh, wait. I got excited too early.
13:56:55 mdbooth It doesn't work.
13:57:41 sean-k-mooney well provied v11 which is currently up works that is proably good enough for now
13:57:44 mdbooth I was thinking that explicitly executing monkey_patch() from the importing module bought us something, but of course it doesn't because it's still executed at import time.
13:57:54 mdbooth ...which is why I removed that in the first place.
13:58:02 sean-k-mooney ah ya
14:02:09 mriedem efried: replied
14:02:16 mriedem tl;dr i don't think it's worth re-writing
14:07:23 efried mriedem: I seem to be having a hard time conveying what I think the reader is going to care about here. And maybe it's because they really won't care about it.
14:08:09 efried mriedem: The release notes are about more than the upgrade process itself, aren't they?
14:08:42 mriedem yeah, major new features and such
14:08:48 mriedem and highlighting major upgrade impacts,
14:08:51 efried I mean,
14:09:16 efried I guess if you're going to go switch on the QoS feature, you'll read the docs for that and... not be surprised when multiple providers appear.
14:09:45 mriedem sure, but those already using vgpu + libvirt might never enable qos
14:09:54 mriedem so i'd rather not conflate the features
14:10:57 cdent efried: do people poke placement? is that a thing?
14:11:00 efried right, so I was focusing not on the specific features and more on the structural change they have in common. A structural change that operators may notice
14:11:36 efried cdent: Based on conversations overheard with vexxhost and cern folks, it seems like they do.
14:12:06 cdent dunno about vexxhost but my experience with cern it is with regard to what the service is doing, not the count of resource providers
14:12:08 efried ...and precisely because the features otherwise seem unrelated, this prelude would be a good place to write about the thing that ties them together.
14:12:09 mriedem cdent: they do when shit goes wrong and they are trying to debug
14:12:29 mriedem so how about,
14:12:33 efried yeah, so when they do that and oh crap there's suddenly two or more providers for my host, that must be wrong, freak out
14:12:35 cdent yes, and all of that has little to with reading a release notes prelude, I would have thought. that's what I'm trying to understand
14:13:11 efried if they read the prelude, ever, they might remember in the back of their head that this might possibly be a normal thing, and dig further before pushing the red button.
14:13:14 cdent if you can grep for 'resource provider' anywhere in the release notes then that's enough
14:13:43 cdent yeah, the "ever" is key, and why I think it is to "go back to release notes after something weird happened"

Earlier   Later