No, they are treated as second class citizens. Take Trova again as an example. The underlying OpenStack infrastructure does not provide a good security solution for Trove's use case. As its more then just IaaS. So they have spent years trying to work around it on one way or another, each with horrible trade offs.
For example they could fix an issue by: 1. Run the service vm in the users tenant where it belongs. Though, currently the user has permissions to reboot the vm, login through the console and swipe any secrets that are on the vm and make it much harder for the cloud admin to administer. 2. Run the vm in a "trove" tenant. This fixes the security issue but breaks the quota model of OpenStack. Users with special host aggregate access/flavors can't work with this model. For our site, we can't use Trove at all at the moment, even though we want to. Because option 2 doesn't work for us, and option 1 currently has a glaring security flaw in it. One of the ways I saw Trove try to fix it was to get a feature into Nova called "Service VM's". VMs owned by the user but not fully controllable by them but from some other OpenStack service on their behalf. This, IMO is the right way to solve it. There are a lot of advanced services that need this functionality. But it seems to have been rejected, as "users don't need that"... Which is true, only if you only consider the IaaS use case. The problems of these other OpenStack services are being rejected as second class problems, not primary ones. I'm sure other sites are avoiding other OpenStack advanced services for similar reasons. its not just that Operators don't want to deploy it, or that Users are not asking for it. Let me try and explain Zane's post in a sligtly different way... maybe that would help... So, say you had an operating system. It had the ability to run arbitrary programs if the user started an executable via the keyboard/mouse. But had no ability for an executable to start another executable. How useful would that OS be? There would be no shell scripts. No non monolithic applications. It would be sort of functional, but would be hamstrung. OpenStack is like that today. Like the DOS operating system. Programs are expected to be pretty self contained and not really talk back to the Operating System its running on, nor a way to discover other programs running on the same system. Nor really for a script running on the Operating System to start other programs, chaining them together in a way thats more useful then the sum of their parts. The current view is fine if you need is just a container to run a traditional OS in. Its not if you are trying to build an application that spans things. There have been several attempts at fixing this, in Heat, in Murano, in the App Catalog, but plumbing they rely on isn't really supportive of it, as they believe the use case really is just launching a VM with an OS in it is really the important thing to do, and the job's done. For the Applications Catalog to be successful, it needs the underlying cloud to have enough functionality among a common set of cloud provided services to allow applications developers to write cloud software that is redistributable and consumable by the end user. Its failed because the infrastructure just isn't there. The other advanced services are suffering from it too. Thanks, Kevin ________________________________________ From: Clint Byrum [cl...@fewbar.com] Sent: Friday, March 10, 2017 6:20 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 23:45:06 +0000: > 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". > It's not that they're second class citizens. It's that their community is smaller by count of users, operators, and developers. This should not come as a surprise, because the lowest common denominator in any user base will always receive more attention. > > 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. > You say it like there's some over arching plan to suppress parts of the community and there's a pack of disgruntled developers who just can't seem to get OpenStack to work for Trove/Sahara/AppCatalog/etc. We all have different reasons for contributing in the way we do. Clearly, not as many people contribute to the Trove story as do the pure VM-on-nova story. > 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. > That's a great idea. However, AFAICT, Nova is _not_ standing in Trove, Sahara, or anyone else's way from doing this. Seriously, try it. I'm sure it will work. And in so doing, you will undoubtedly run into friction from the APIs. But unless you can describe that _now_, you have to go try it and tell us what broke first. And then you can likely submit feature work to nova/neutron/cinder to make it better. I don't see anything in the current trajectory of OpenStack that makes this hard. Why not just do it? The way you ask, it's like you have a team of developers just sitting around shaving yaks waiting for an important OpenStack development task. The real question is why aren't Murano, Trove and Sahara in most current deployments? My guess is that it's because most of our current users don't feel they need it. Until they do, Trove and Sahara will not be priorities. If you want them to be priorities _pay somebody to make them a priority_. > 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. > The above is an unfounded and unsupported claim. What _exactly_ would you want Nova/Neutron/Cinder's API to do differently to support "cloud software" better? Why is everyone dodging that question? Name one specific change and how it would actually be consumed. I personally think it's just the general frustration that comes at this stage of maturity of a project. There's a contraction of hype, lower investment in general, and everyone is suppressing their panic and trying to reason about what we can do to make it better, but nobody actually knows. Meanwhile, our users and operators need us to keep making things better. Some are even _paying us_ to make things better. > 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 > Honest, I don't understand the reality that Zane's vision is driving at in that post. More Zaqar? Why not just do that? What's standing in the way? > 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. > Why would we kick out perfectly healthy pieces of software that want to be OpenStack-native? Nobody is saying that IaaS clouds aren't well complimented by native higher level projects. But in the app catalog case, there's little consumption, and waning contribution, so it's worth considering whether its continued maintenance and existence is a drain on the overall community. Sounds like it is, and we'll probably need to shut it down, and direct those efforts to liasing with outside projects and services like Dockerhub, Heroku, Bitnami, etc. Forgive me if I sound reactive. I just want to remind everyone that this is a do-ocracy. You can say what you want the vision to be all you want, you can also ask for a vision, but you can't _really_ change anything here on the mailing list. You have to write a spec, get it landed, and do the work. I think you'll be surprised how little resistance you get if you go ahead and _JFDI_. __________________________________________________________________________ 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
