Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-01-14
15:10:28 lyarwood efried: ack, I'll do that now.
15:10:46 efried lyarwood: when was the blueprint set to Definition:Approved and by whom?
15:11:20 efried (I thought there used to be a History button, but I must be thinking of something else)
15:11:51 efried sean-k-mooney: yes, cyborg series should be rebased to use root_required
15:12:33 efried okay, I think I'm caught up
15:12:35 lyarwood efried: I'm not sure about https://blueprints.launchpad.net/nova/+spec/virt-rescue-stable-disk-devices but https://blueprints.launchpad.net/nova/+spec/virt-bfv-instance-rescue for this change and spec still needs approval
15:13:28 lyarwood efried: ah found the email, MattR approved virt-rescue-stable-disk-devices
15:13:44 efried FYI nova, we've merged merged https://review.opendev.org/#/c/701792/ which should get rid of the "multiple possible networks" tempest errors we've been seeing a lot of lately. If you see more of them, let me know, cause the fix should be simple.
15:13:46 efried stephenfin: ^
15:14:01 efried "we've merged merged"? #uncaffeinated
15:14:15 artom Question about bug triage
15:14:28 artom " Close as "invalid" if it is a support request or feature request." from https://wiki.openstack.org/wiki/Nova/BugTriage
15:14:30 artom Is that a thing we do?
15:14:35 efried lyarwood: would you mind adding a note for that. But... why are there two blueprints? (I haven't actually *read* anything, so maybe it's obvious, but lead me by the nose here)
15:14:56 efried artom: this actually came up last week and I didn't consult that wiki page.
15:14:56 openstack Launchpad bug 1859403 in OpenStack Compute (nova) "The instance needs to supports dongle devices" [Wishlist,New]
15:14:56 artom Specifically about https://bugs.launchpad.net/nova/+bug/1859403
15:15:29 openstackgerrit Lee Yarwood proposed openstack/os-traits master: Add COMPUTE_BFV_RESCUE trait https://review.opendev.org/694033
15:15:36 artom I set it to wishlist, is that it? Or since we know what it is (wishlist), we can set it to Triaged as well to remove it from filters/lists
15:15:39 efried dansmith opened a pro forma bug for something, trying to remember...
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)

Earlier   Later