| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-01-14 | |||
| 15:16:19 | dansmith | "opened a pro forma bug....against his will" | |
| 15:18:03 | efried | yeah yeah | |
| 15:18:07 | openstack | Launchpad bug 1858877 in OpenStack Compute (nova) "Silent wasted storage with multiple RBD backends" [Wishlist,Confirmed] | |
| 15:18:07 | efried | dansmith: this one rite? https://bugs.launchpad.net/nova/+bug/1858877 | |
| 15:18:18 | dansmith | yar | |
| 15:18:23 | efried | Since artom points to an actual document saying we should close as Invalid, Ima do that. | |
| 15:18:29 | efried | and artom, yeah, do same with yours. | |
| 15:18:30 | dansmith | lol | |
| 15:18:38 | artom | efried, well, wikis are fickle things | |
| 15:18:47 | efried | I was looking for any excuse | |
| 15:18:58 | artom | I could edit that to say every time a wishlist is filed, we need to call POTUS and get his approval | |
| 15:19:11 | efried | I think if we get to 100 open bugs, the stay-puft marshmallow man shows up or something. | |
| 15:19:20 | efried | Then we have to cross the streams, marshmallow everywhere, big mess. | |
| 15:19:24 | gibi | stephenfin: I'm +2 on https://review.opendev.org/#/c/696516/ based on your answers | |
| 15:19:42 | stephenfin | gibi: thanks | |
| 15:19:47 | artom | efried, follow-up question then - if we close wishlist items as invalid, how do we expect folks to file them? | |
| 15:20:01 | efried | blueprints, right? | |
| 15:20:07 | artom | You're asking me? | |
| 15:20:30 | gibi | stephenfin: regarding the rename in https://review.opendev.org/#/c/696745/ I can be convinced both ways so I'm not voting now, sorry | |
| 15:20:46 | dansmith | yes, my point about my bug was that "nova does not support $thing" is not a bug, it's a feature request, hence blueprint at some point | |
| 15:20:54 | dansmith | however, we don't file blueprints for things we may or may not do in the future | |
| 15:21:05 | dansmith | (nor should we) | |
| 15:21:05 | stephenfin | gibi: All good. Comes down to dansmith in that case | |
| 15:21:09 | efried | Right, there seems to be a process gap there. | |
| 15:21:18 | dansmith | why? | |
| 15:21:23 | artom | IOW, if you have a feature request but aren't prepared to work on it yourself or pay someone to do it, your sool? | |
| 15:21:25 | efried | if there's a closed/wishlist bug, how do we ever "find" it and make a blueprint out of it. | |
| 15:21:25 | artom | *you're | |
| 15:21:26 | dansmith | we don't need to enumerate everything nova doesn't do, right? | |
| 15:22:02 | efried | of course, but a way to track "something nova doesn't do, but probably should, but nobody's going to work on it right now, but we don't really want to forget about it and *never* do it" | |
| 15:22:35 | efried | dansmith: I think your bug is a good example. You said it's something we probably want to do soonish. But who's gonna remember? | |
| 15:22:50 | artom | I mean, given the project/community dynamics, it'd be reasonable to say "sorry, if you want a thing but can't commit resources, it'll realistically never get done." | |
| 15:22:56 | artom | Not very welcoming, but reasonable | |
| 15:23:52 | dansmith | efried: if putting together that list is actually going to form a backlog that we chew through, then sure, but history tells me it will just become a wasteland of every crazy thing anyone ever thought of once | |
| 15:24:16 | dansmith | if it was a cultivated list that was pruned to just the things we do actually want to do then sure, but.. closed wishlist bugs are not that :) | |
| 15:26:10 | openstack | Launchpad bug 1858877 in OpenStack Compute (nova) "Silent wasted storage with multiple RBD backends" [Wishlist,Invalid] | |
| 15:26:10 | efried | okay, well, I closed https://bugs.launchpad.net/nova/+bug/1858877 as invalid, so artom you have a recent precedent as well as instructions from the wiki. Go forth and close. | |
| 15:26:27 | dansmith | stephenfin: I saw lots of mentions as my backscroll flowed in this morning.. if you want me to look at something specific, please relink me | |
| 15:30:30 | stephenfin | dansmith: https://review.opendev.org/#/c/696745/ (see last comment) | |
| 15:31:35 | dansmith | oh jesus | |
| 15:32:38 | dansmith | I still would rather it not change, mostly for selfish reasons, but I'm sure I'm the only one (left) that feels that way | |
| 15:32:39 | dansmith | so please just don't make me review it | |
| 15:38:43 | stephenfin | :D | |
| 15:38:51 | stephenfin | fair | |
| 15:40:08 | stephenfin | I know the refactoring impact is still present, but does the use of a 'nova.network.neutron' module (vs. 'nova.network.api') resolve your other concerns at least? | |
| 15:40:45 | stephenfin | iiuc that was mriedem's primary concern (that people would see nova.network.api and think we were talking abut nova-network) | |
| 15:46:48 | dansmith | it's better in terms of the confusion, yeah | |
| 15:48:51 | efried | lyarwood: removed -2, but left -1 for discrepancy with the spec. Honestly don't know which would be better tho. | |
| 15:56:38 | lyarwood | efried: ack yeah apologies I totally forgot to update this in the spec after switching here. I really don't mind tbh so I'll just change this back to COMPUTE_RESCUE_BFV to avoid editing the spec. | |
| 15:58:27 | openstackgerrit | Lee Yarwood proposed openstack/os-traits master: Add COMPUTE_RESCUE_BFV trait https://review.opendev.org/694033 | |
| 16:09:46 | efried | lyarwood: I honestly want thought put into which is better, actually. | |
| 16:10:10 | efried | We don't need to belabor it, but avoiding editing one patch or the other shouldn't be the reason. | |
| 16:10:38 | lyarwood | efried: yeah that's fair, well an actual reason to switch back to COMPUTE_RESCUE_BFV would be that it would allow additional traits to be added in the future | |
| 16:11:32 | lyarwood | sorry I mean additional rescue traits, COMPUTE_RESCUE_FOO etc | |
| 16:11:42 | efried | that's my point: do we want to add more COMPUTE_RESCUE_* traits, or do we want to add more COMPUTE_BFV_* traits? | |
| 16:12:03 | efried | okay, so COMPUTE_RESCUE_BFV is actually preferred. I can dig that. | |
| 16:14:04 | efried | lyarwood: +2 | |
| 16:14:08 | lyarwood | efried: thanks | |
| 16:14:45 | openstackgerrit | Dan Smith proposed openstack/nova master: Add NovaEphemeralObject class for non-persistent objects https://review.opendev.org/702049 | |
| 16:15:42 | efried | stephenfin: +A on the precommit gizmo, sorry for the delay. And thanks for the vTPM spec approval \o/ | |
| 16:30:27 | sean-k-mooney | efried: is the blueprint/spec approval deadline m2? | |
| 16:32:05 | sean-k-mooney | im just looking at my downstream feature backlog and i might file one more blueprint for this cycle to add viommu support to th elibvirt driver. it will just be a small change like the vpmu change but just tring to figure out when i need to decided if im going to file it | |
| 16:34:02 | sean-k-mooney | i want to finish the image metadata prefiltering work first but the viommu feature is tecnically more useful to end customers | |
| 16:49:27 | efried | sean-k-mooney: spec freeze 2/13 https://wiki.openstack.org/wiki/Nova/Ussuri_Release_Schedule yes. At that point I'll probably ask us to do a scrub to prioritize whatever's been Definition:Approved and drop some things off the bottom. | |
| 16:50:00 | sean-k-mooney | ya i was execpting there to be a scrub | |
| 16:51:25 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Remove extra instance.save() calls related to qos SRIOV ports https://review.opendev.org/702261 | |
| 16:51:26 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Use common server create function for qos func tests https://review.opendev.org/701353 | |
| 16:52:21 | sean-k-mooney | my main two feature that were important for this cycle have already merged so the rest are less imporant. i want to finish stuff i have started before doing new stuff too so im lean to not filing another blueprint but i also know its will be trivail to do | |
| 16:53:05 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Enable live migration with qos ports https://review.opendev.org/699066 | |
| 18:18:47 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Use COMPUTE_SAME_HOST_COLD_MIGRATE trait during migrate https://review.opendev.org/695220 | |
| 20:12:24 | efried | dansmith: old, simple, should be an easy +A: https://review.opendev.org/#/c/694806/ | |
| 20:23:11 | dustinc | new behavior: since the no-op entry gets removed during validation, the $COMPUTE_NODE value gets used when merging | |
| 20:23:11 | dustinc | old behavior: if using uuid=$COMPUTE_NODE you could exempt individual providers from the $COMPUTE_NODE entry during merge step by adding specific no-op entries for them | |
| 20:23:11 | dustinc | I realized that there was an unintended change in functionality and am not sure if it is worth worrying about or not | |
| 20:23:11 | dustinc | efried: I was working on moving checks for no-op providers from the merge step to the validation step as you suggested here https://review.opendev.org/#/c/676029/31/nova/compute/provider_config.py@199 | |
| 20:24:48 | dustinc | the old behavior was not specifically intended or documented, but might actually be useful to someone | |
| 20:25:36 | efried | dustinc: interesting, glad we caught it before we landed this rather than later when somebody *was* relying on it and we yanked the rug. We should noodle whether we want to allow that or not. | |
| 20:26:06 | efried | I'm going to say: for now, we should explicitly document (wherever we're going to document this thing) that no-op stanzas will be ignored completely and have no effect. | |
| 20:26:19 | efried | which means the new way you're doing the check will be the right way. | |
| 20:26:48 | efried | "ignored completely" with a warning (which I guess isn't ignored completely, but you get the idea) | |
| 20:39:05 | dustinc | Sounds good to me, I want to push what I have so will go that route for now | |
| 21:25:59 | openstackgerrit | Eric Fried proposed openstack/nova master: nova-net: Kill it https://review.opendev.org/696518 | |
| 21:49:34 | openstackgerrit | Dustin Cowles proposed openstack/nova master: Provider Config File: YAML file loading and schema validation https://review.opendev.org/673341 | |
| 21:49:35 | openstackgerrit | Dustin Cowles proposed openstack/nova master: Provider Config File: Functions to merge provider configs to provider tree https://review.opendev.org/676522 | |
| 21:49:35 | openstackgerrit | Dustin Cowles proposed openstack/nova master: Provider Config File: Function to further validate and retrieve configs https://review.opendev.org/676029 | |
| 21:49:36 | openstackgerrit | Dustin Cowles proposed openstack/nova master: Provider Config File: Enable loading and merging of provider configs https://review.opendev.org/693460 | |
| 22:06:25 | Sundar | Hello all, in release notes like https://github.com/openstack/nova/blame/master/releasenotes/notes/image-precaching-d46506568fefa1ea.yaml, what is the id that gets added at the end? | |
| 22:23:20 | dansmith | Sundar: don't hand-create them | |
| 22:23:38 | dansmith | Sundar: tox -evenv reno new some-short-name-of-thing | |
| 22:24:58 | Sundar | dansmith: do I use that to create a file which I then 'git add'? | |
| 22:25:05 | dansmith | Sundar: yes | |
| 22:25:11 | Sundar | Thanks | |
| 22:31:17 | openstackgerrit | Merged openstack/nova master: Avoid spurious error logging in _get_compute_nodes_in_db https://review.opendev.org/695453 | |
| 23:10:25 | efried | dustinc: finished reviewing the provider config series. Getting close, nice work. | |
| 23:12:49 | dustinc | efried: thanks, checking it out now.. | |
| 23:16:48 | efried | aaand I'm out | |
| #openstack-nova - 2020-01-15 | |||
| 01:34:51 | brinzhang | Sunda: just use "reno new < some-short-name-of-thing>" under the project also can create the releasenote file, that depend-on reno packages, so you should installed in your env. | |
| 01:35:56 | brinzhang | Sundar | |
| 01:41:29 | brinzhang | Sundar: creating releasenote guide:https://docs.openstack.org/reno/latest/user/usage.html#creating-new-release-notes | |
| 01:55:38 | openstackgerrit | Merged openstack/nova master: Print help if nova-manage subcommand is not specified https://review.opendev.org/694806 | |