4 ms·

Doesn't surprise me the slightest to be honest. Having worked on a customized fork of OpenStack that used a pure L3 networking model I know that you are set for

by jpgvm 12y ago

Doesn't surprise me the slightest to be honest. Having worked on a customized fork of OpenStack that used a pure L3 networking model I know that you are set for pain the moment you don't want to run everything on a single Ethernet segment. It doens't help that the Neutron data-model at the time that I was working on in (say 12 months ago or so) was terrible and basically impossible to scale/make to perform. Inevitably you were then stuck with the deprecated and janky nova-network interface. Which while efficient and fast was also old and missing tons of stuff - meaning more monkey patching and janking around. Not to mention the fact that because of it's deprecation many completely ridiculous bugs befell it in later releases. (Grizzly and onwards basically) TBH I am so disillusioned with the project I hope I don't have to work in or around it again.

cdent 12y ago
The networking situation has improved in Juno and Kilo, but yeah: One often gets the impression with OpenStack that there's so much attention being paid to new stuff that none of the existing stuff (even recently new) is ever brought to a state of stability and usefulness.
ewindisch 12y ago
> TBH I am so disillusioned with the project I hope I don't have to work in or around it again. You're not the first I've heard this from, nor do I suspect the last. The problem isn't that the code is bad as much as it is that the climate often makes it impossible to fix it. Review queues are weeks or months long. The article makes a good point about the necessary man hours to work on OpenStack. I've seen code removed not because it didn't have a maintainer, but because 200 lines of code didn't have 3-5 full time developers. Insanity persists and money talks. Looking back, I'd say that OpenStack Nova in the beginning was never this bad. It may not have been the best thing ever, because it wasn't, but no code needs to be terribly great in the beginning. The beginning of a project needs good process more than it needs good code, and OpenStack didn't establish this well enough, early enough. OpenStack never had a solid, centralized architectural vision. Anyone that attempted to contribute architecturally was essentially ejected. Those that flushed millions into controlling the process and millions more into building adhoc features got their way. I mistakenly advocated early for wrangling control from Rackspace. The increased influence gained by individual contributors was quickly dwarfed by large corporate influences. I'm still involved with OpenStack, but far less than I had been in the past. Mostly, I prefer to see myself peripherally involved where I might improve the lives of those trapped in that ecosystem, either to help them deal with the pains they've inflicted upon themselves, or to escape them entirely.
- nl 12y ago
  The problem isn't that the code is bad as much as it is that the climate often makes it impossible to fix it. Lots of the code isn't great either.
hueving 12y ago
Considering that the neutron core is entirely L2 abstractions with an L3 plugin on top of it, it's not really surprising that you had issue with a pure L3 model.

by jpgvm 12y ago

cdent 12y ago

The networking situation has improved in Juno and Kilo, but yeah: One often gets the impression with OpenStack that there's so much attention being paid to new stuff that none of the existing stuff (even recently new) is ever brought to a state of stability and usefulness.

ewindisch 12y ago

> TBH I am so disillusioned with the project I hope I don't have to work in or around it again. You're not the first I've heard this from, nor do I suspect the last. The problem isn't that the code is bad as much as it is that the climate often makes it impossible to fix it. Review queues are weeks or months long. The article makes a good point about the necessary man hours to work on OpenStack. I've seen code removed not because it didn't have a maintainer, but because 200 lines of code didn't have 3-5 full time developers. Insanity persists and money talks. Looking back, I'd say that OpenStack Nova in the beginning was never this bad. It may not have been the best thing ever, because it wasn't, but no code needs to be terribly great in the beginning. The beginning of a project needs good process more than it needs good code, and OpenStack didn't establish this well enough, early enough. OpenStack never had a solid, centralized architectural vision. Anyone that attempted to contribute architecturally was essentially ejected. Those that flushed millions into controlling the process and millions more into building adhoc features got their way. I mistakenly advocated early for wrangling control from Rackspace. The increased influence gained by individual contributors was quickly dwarfed by large corporate influences. I'm still involved with OpenStack, but far less than I had been in the past. Mostly, I prefer to see myself peripherally involved where I might improve the lives of those trapped in that ecosystem, either to help them deal with the pains they've inflicted upon themselves, or to escape them entirely.

nl 12y ago
The problem isn't that the code is bad as much as it is that the climate often makes it impossible to fix it. Lots of the code isn't great either.

hueving 12y ago

Considering that the neutron core is entirely L2 abstractions with an L3 plugin on top of it, it's not really surprising that you had issue with a pure L3 model.