[openstack-dev] [tc][appcat] The future of the App Catalog

Fox, Kevin M Kevin.Fox at pnnl.gov
Fri Mar 10 23:45:06 UTC 2017


So, this is the kind of thinking I'm talking about... OpenStack today is more then just IaaS in the tent. Trove (DBaaS), Sahara (Hadoop,Spark,etc aaS), Zaqar (Messaging aaS) and many more services. But they seem to be treated as second class citizens, as they are not "IaaS".

> Why should it strive to be anything except an excellent building block
for other technologies?

You misinterpret my statement. I'm in full agreement with you. The above services should be excellent building blocks too, but are suffering from lack of support from the IaaS layer. They deserve the ability to be excellent too, but need support/vision from the greater community that hasn't been forthcoming.

I agree with you, we should embrace the container folks and not treat them as separate. I think thats critical if we want to allow things like Sahara or Trove to really fulfil their potential. This is the path towards being an OpenSource AWS competitor, not just for being able to request vm's in a cloudy way.

I think that looks something like:
OpenStack Advanced Service (trove, sahara, etc) -> Kubernetes -> Nova VM or Ironic Bare Metal.

Not what we have today:
OpenStack Advanced Service -> Nova VM or Ironic Bare Metal

due to the focus on the api's of VM's being only for IaaS and not for actually running cloud software on.

I'm sorry if that sounds a bit confusing. Its hard to explain. I can try and elaborate if you want. Zane's posting here does help explain it a little:
http://www.zerobanana.com/archive/2015/04/24#a-vision-for-openstack

The other alternative is to clearly define OpenStack to be just IaaS, and kick all the non IaaS stuff out of the tent. (I do not prefer this). It will hurt in the short term but long tern could be better for those projects then the current status quo as new opportunities for switching base dependencies will present themselves and no longer will be hamstrung by those that feel their use case isn't important or think that the existing api's are "good enough" to handle the use case.

Thanks,
Kevin
 
________________________________________
From: Clint Byrum [clint at fewbar.com]
Sent: Friday, March 10, 2017 2:43 PM
To: openstack-dev
Subject: Re: [openstack-dev] [tc][appcat] The future of the App Catalog

Excerpts from Fox, Kevin M's message of 2017-03-10 20:47:55 +0000:
> Just because the market hasn't immediately shifted from IaaS to containers doesn't mean it won't happen eventually, and that google's wrong in their push for containers over IaaS. It took a long time (still ongoing) to move from physical machines to vm's. The same parallel will happen with containers I believe. We're at least a few years out from it becoming more common place. That doesn't mean folks can assume it will always be the way it is, and the "market has spoken". "The only constants are death and taxes." :)
>
> Your right in the assertion k8s needs a place to run, but that doesn't necessarily mean OpenStack, unless we help integrate it and make it a great place to run it.
>
> I'm glad the IaaS stuff in OpenStack suits your needs. Thats great. It hasn't served a great number of users needs though, and has been at least misleading folks into believing it will for a number of years. If we want it to just be an IaaS, lets free up those users to move on elsewhere.
>
> Does OpenStack intend just to be an IaaS in a few years or something else?
>

Why should it strive to be anything except an excellent building block
for other technologies?

Containers have a community and there's no reason we should think of that
as separate from us. We're friends, and we overlap when it makes sense.

All the container tech that I see out there still needs computers /
disks / networks to run on. OpenStack is a pretty decent way to chop your
computers up and give fully automated control of all aspects of them to
multiple tenants.  What else would you want it to do that isn't already
an aspect of Kubernetes, CloudFoundry, etc.?

__________________________________________________________________________
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



More information about the OpenStack-dev mailing list