On 5/5/2017 11:36 AM, Alex Schultz wrote:
The cell v2 initial implementation was neither usable or stable (for my definition of stable). Yea you could say 'but it's a work and progress' and I would say, why is it required for the end user then? If I wanted to I could probably go back and go through every project and point out when a feature was added yet we still have a pile of outstanding issues. As Chris Friesen pointed out in his reply email, there are things out there are specifics if you go looking. You have to understand that as I'm mainly dealing with having to actually deploy/configure the software, when I see 'new project X' that does 'cool new things Y, Z' it makes me cringe. Because it's just added complexity for new features that who knows if they are actually going to be consumed by a majority of end users. I see a lot of new features for edge cases while the core functionally (insert the most used project configuration) still have awkward deployment, configuration and usability issues. But those aren't exciting so people don't want to work on them...
We've talked about bug-fix only stability releases before and there is never enough support to do that.
If I had a "go talk to x" every time I have to say no to someone's blueprint after we do spec freeze it would make my life much easier and less depressing.
My first release as PTL in Newton I really wanted to focus in fixing bugs, technical debt, docs, broken features, testing gaps, etc. That's still a main focus of mine, but the constant grind of feature requests and pressure is going to make you change priorities sometimes. So I've accepted that Nova is going to approve somewhere around 70 blueprints per release (and merge less than that, but that's another problem), and we just have to be better about requiring the docs/tests at the time that the feature is added, before the code is merged, and follow up with people that said they'd deliver those things.
We've also been pretty aggressive about deprecating a lot of old busted API and legacy code in Nova over the last couple of years. I'm sure there is a camp of people that would never want us to remove anything no matter how busted or not tested it is, or how only one virt driver supports that feature. If you want to get an idea about the horrible mess of resource tracking and complexity that goes into scheduling in Nova, attend Jay Pipes' talks on Placement at the summit (or watch the videos afterward). There are still gremlins in there that are news to me today.
And yes, Ocata sucked. We lost our main cells v2 driver (alaski), we lost two core reviewers for the entire release basically (danpb was re-assigned off openstack, sdague was laid off from HPE and was looking for another job), and I personally was looking for a job and interviewing with companies for about 4 months, just trying to continue working upstream in some fashion. Several people put a lot of attention and care into the in-tree placement and cells v2 docs, but we dropped the ball on the install guide for those. I've admitted that before and I'll admit it again if it makes anyone feel any better.
We didn't anticipate some of the issues that TripleO would have with deployment changes. I appreciate all of the work that Emilien put into working with us on raising those issues and being patient while we worked through them. The Kolla team was/is also a pleasure to work with, mostly because I don't hear from them. :)
Big changes are hard to get right. We've also put a hell of a lot of effort into keeping rolling upgrades in mind when working on any of this stuff, but I don't know if anyone has ever acknowledged that, or appreciated it, maybe because if it's not something to complain about it's not worth mentioning.
Anyway, you'll never hear me disagree that I'd love to put less of a focus on new features and instead focus on hardening the things we already have, but when push comes to shove it's not easy justifying the time you spend (if you're lucky enough to even pick what you want to work on at any given time) on stuff like that. For example, I don't hear anyone asking me every other day in IRC to fix the mess that is the shelve feature.
It's also unfair to say that the rest of us who don't work in deployment projects think or care about users, be those end users of the cloud, or the operators. I'd say we put a lot of thought into how something we're working on is going to be consumed and try to make that as painless as possible. It doesn't always end up that way, or maybe isn't appreciated for the alternatives we didn't take. It's easy to throw stones from the outside.
I don't have a nice way to wrap this up. I'm depressed and just want to go outside. I don't expect pleasant replies to my rant, so I probably won't reply again after this anyway since this is always a never-ending back and forth which just leaves everyone bitter.
-- Thanks, Matt __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
