Open Stack

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