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 [cl...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Reply via email to