Excerpts from Fox, Kevin M's message of 2017-03-11 21:31:40 +0000: > 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. >
You're right. This type of rejection is not O-K IMO, because this is consumers of Nova with a real use case, asking for real features that simply cannot be implemented anywhere except inside Nova. Perhaps the climate has changed, and this effort can be resurrected. > 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. > I'm not sure I agree. One can very simply inject needed credentials into a running VM and have it interact with the cloud APIs. However, there is a deficiency that affects all VM users that might make this a more desirable option. There's a lack of a detailed policy management piece. What I'd really like to inject is an API key that can only do the 2 things my app needs (like, scale up load balancer, or allocate and attach a volume to itself). Roles are just too opaque for that to really work well these days. __________________________________________________________________________ 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
