Open Stack

Inlining with KF> 
________________________________________
From: Thierry Carrez [thierry at openstack.org]
Sent: Tuesday, July 17, 2018 7:44 AM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [tc] [all] TC Report 18-26

Finally found the time to properly read this...

Zane Bitter wrote:
> [...]
> We chose to add features to Nova to compete with vCenter/oVirt, and not
> to add features the would have enabled OpenStack as a whole to compete
> with more than just the compute provisioning subset of EC2/Azure/GCP.

Could you give an example of an EC2 action that would be beyond the
"compute provisioning subset" that you think we should have built into
Nova ?

KF> How about this one... https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html :/
KF> IMO, its lack really crippled the use case. I've been harping on this one for over 4 years now...

> Meanwhile, the other projects in OpenStack were working on building the
> other parts of an AWS/Azure/GCP competitor. And our vague one-sentence
> mission statement allowed us all to maintain the delusion that we were
> all working on the same thing and pulling in the same direction, when in
> truth we haven't been at all.

Do you think that organizing (tying) our APIs along [micro]services,
rather than building a sanely-organized user API on top of a
sanely-organized set of microservices, played a role in that divide ?

KF> Slightly off question I think. A combination of microservice api's + no api team to look at the api's as a whole allowed use cases to slip by.
KF> Microservice api might have been ok with overall shepards. Though maybe that is what you were implying with 'sanely'?

> We can decide that we want to be one, or the other, or both. But if we
> don't all decide together then a lot of us are going to continue wasting
> our time working at cross-purposes.

If you are saying that we should choose between being vCenter or AWS, I
would definitely say the latter. But I'm still not sure I see this issue
in such a binary manner.

KF> No, he said one, the either, or both. But the lack of decision allowed some teams to prioritize one without realizing its effects to others.

KF> There are multiple vCenter replacements in opensource world. For example, oVirt. Its alreay way better at it then Nova.
KF> There is not a replacement for AWS in the opensource world. The hope was OpenStack would be that, but others in the community did not agree with that vision.
KF> Now that the community has changed drastically, what is the feeling now? We must decide.
KF> Kubernetes has provided a solid base for doing cloudy things. Which is great. But the organization does not care to replace other AWS/Azure/etc services because there are companies interested in selling k8s on top of AWS/Azure/etc and integrate with the other services they already provide.
KF> So, there is an Opportunity in the opensource community still for someone to write an opensource AWS alternative. VM's are just a very small part of it.

KF> Is that OpenStack, or some other project?

Imagine if (as suggested above) we refactored the compute node and give
it a user API, would that be one, the other, both ? Or just a sane
addition to improve what OpenStack really is today: a set of open
infrastructure components providing different services with each their
API, with slight gaps and overlaps between them ?

Personally, I'm not very interested in discussing what OpenStack could
have been if we started building it today. I'm much more interested in
discussing what to add or change in order to make it usable for more use
cases while continuing to serve the needs of our existing users. And I'm
not convinced that's an either/or choice...

KF> Sometimes it is time to hit the reset button because you either:
 a> you know something more then you did when you built that is really important
 b> the world changed and you can no longer going on the path you were
 c> the technical debt has grown very large and it is cheaper to start again

KF> OpenStacks current architectural implementation really feels 1.0ish to me and all of those reasons are relevant.
KF> I'm not saying we should just blindly hit the reset button. but I think it should be discussed/evaluated . Leaving it alone may have too much of a dragging effect on contribution.

KF> I'm also not saying we leave existing users without a migration path either. Maybe an OpenStack 2.0 with migration tools would be an option.

KF> OpenStacks architecture is really hamstringing it at this point. If it wants to make progress at chipping away at AWS, it can't be trying to build on top of the very narrow commons OpenStack provides at present and the boiler plate convention of 1, start new project 2, create sql databse, 3, create rabbit queues, 5, create api service, 6 create scheduler service, 7, create agents, 9, create keystone endpoints, 10, get it wrapped in 32 different deployment tools, 11, etc

Thanks,
Kevin
--
Thierry Carrez (ttx)

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev