Open Stack

My two cents:

> I think if OpenStack wants to gain back some of the steam it had before, it needs to adjust to the new world it is living in. This means:
>  * Consider abolishing the project walls. They are driving bad architecture (not intentionally but as a side affect of structure)

As long as there is no walled garden, everything should be done in a
modular way. I don't think having separated nova from cinder prevented
some contributions, quite the contrary. (Optionally, watch [1]).
I am not familiar with the modularity and ease of contribution in k8s,
so the modularity could be there in a different form.

[1]: https://www.youtube.com/watch?v=xYkh1sAu0UM

>  * focus on the commons first.

Good point.

>  * simplify the architecture for ops:

Good point, but I don't see how code, org structure, or project
classification changes things here.

>  * come up with an architecture team for the whole, not the subsystem. The whole thing needs to work well.

Couldn't that be done with a group TC sponsored?

>  * encourage current OpenStack devs to test/deploy Kubernetes. It has some very good ideas that OpenStack could benefit from. If you don't know what they are, you can't adopt them.

Good idea.

>
> And I know its hard to talk about, but consider just adopting k8s as the commons and build on top of it. OpenStack's api's are good. The implementations right now are very very heavy for ops. You could tie in K8s's pod scheduler with vm stuff running in containers and get a vastly simpler architecture for operators to deal with. Yes, this would be a major disruptive change to OpenStack. But long term, I think it would make for a much healthier OpenStack.

Well, I know operators that wouldn't like k8s and openstack components
on top. If you're talking about just a shim between k8s concepts and
openstack apis, that sounds like a good project : p

>> I've also argued in the past that all distro- or vendor-specific
>> deployment tools (Fuel, Triple-O, etc [3]) should live outside of
>> OpenStack because these projects are more products and the relentless
>> drive of vendor product management (rightfully) pushes the scope of
>> these applications to gobble up more and more feature space that may or
>> may not have anything to do with the core OpenStack mission (and have
>> more to do with those companies' product roadmap).
>
> I'm still sad that we've never managed to come up with a single way to
> install OpenStack. The amount of duplicated effort expended on that
> problem is mind-boggling. At least we tried though. Excluding those
> projects from the community would have just meant giving up from the
> beginning.

Well, I think it's a blessing and a curse.

Sometimes, I'd rather have only one tool, so that we all work on it, and
not dilute the community into small groups.

But when I started deploying OpenStack years ago, I was glad I could
find a community way to deploy it using <company technology of choice>,
and not <another new technology forced on me, not working with our
current processes>.
So for me, I am glad (what became) OpenStack-Ansible existed and I am
glad it still exists.

The effort your are talking about is not purely duplicated:
- Example: whether openstack-ansible existed or not, people used to
Ansible would still prefer deploying openstack with Ansible
  than with puppet or chef (because of their experience) if not
relying on a vendor. In that case, they would probably create
  their own series of playbooks. (I've seen some). That's the real waste, IMO.
- Deployments projects talk to each other.

Talking about living outside OpenStack, where would, for you,
OpenStack-Ansible, the puppet modules, or OpenStack-Chef be?
For OSA, I consider our community now as NOT vendor specific, as many
actors are now playing with it.
We've spent a considerable effort in outreaching and ensuring everyone
can get involved.
So we should be in openstack/ right? But what about 4 years ago? Every
project starts with a sponsor.

I am not sure a classification (is it outside, is it inside
openstack/?) matters in this case.

>
> I think Thierry's new map, that collects installer services in a
> separate bucket (that may eventually come with a separate git namespace)
> is a helpful way of communicating to users what's happening without
> forcing those projects outside of the community.

Side note: I'd be super happy if OpenStack-Ansible could be on that bucket!

Cheers,
JP (evrardjp)