The current incarnation of the Instance User spec: https://review.openstack.org/#/c/222293/
Thanks, Kevin ________________________________ From: Michael Still [mi...@stillhq.com] Sent: Monday, July 18, 2016 10:13 AM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for all) On 16 Jul 2016 1:27 PM, "Thomas Herve" <the...@redhat.com<mailto:the...@redhat.com>> wrote: > > On Fri, Jul 15, 2016 at 8:36 PM, Fox, Kevin M > <kevin....@pnnl.gov<mailto:kevin....@pnnl.gov>> wrote: > > Some specific things: > > > > Magnum trying to not use Barbican as it adds an addition dependency. See > > the discussion on the devel mailing list for details. > > > > Horizon discussions at the summit around wanting to use Zaqar for dynamic > > ui updates instead of polling, but couldn't depend on a non widely deployed > > subsystem. > > > > Each Advanced OpenStack Service implementing a guest controller > > communication channel that are incompatible with each other and work around > > communications issues differently. This makes a lot more pain for Ops to > > debug or architect a viable solution. For example: > > * Sahara uses ssh from the controllers to the vms. This does not play well > > with tenant networks. They have tried to work around this several ways: > > * require every vm to have a floating ip. (Unnecessary attack surface) > > * require the controller to be on the one and only network node (Uses > > ip netns exec to tunnel. Doesn't work for large clouds) > > * Double tunnel ssh via the controller vm's. so some vms have fips, > > some don't. Better then all, but still not good. > > * Trove uses Rabbit for the guest agent to talk back to the controllers. > > This has traffic going the right direction to work well with tenant > > networks. > > * But Rabbit is not multitenant so a security risk if any user can get > > into any one of the database vm's. > > Really, I believe the right solution is to use a multitenant aware message > > queue so that the guest agent can pull in the right direction for tenant > > networks, and not have the security risk. We have such a system already, > > Zaqar, but its not widely deployed and projects don't want to depend on > > other projects that aren't widely deployed. > > While I agree using Barbican/Zaqar for those would be fantastic, this > is easily solved: just optionally depend on it. Heat provides features > that use Zaqar, which are not just present when Zaqar is not there. > For example, if people in the Trove project were convinced that Zaqar > was the best solution to their problem, I think they would find a way > to provide an implementation using it. I don't think they are, though. > Whatever the reasons may be. > > > The lack of Instance Users has caused lots of projects to try and work > > around the lack thereof. I know for sure, Mangum, Heat, and Trove work > > around the lack. I'm positive others have too. As an operator, it makes me > > have to very carefully consider all the tradeoffs each project made, and > > decide if I can accept the same risk they assumed. Since each is different, > > thats much harder. > > Instance users would be nice. Nobody just provided a good solution. I > know you tried, but I don't think you succeeded. We need a good > implementation, easy to understand, and maybe this will move forward. I think I need a more complete definition of instance users to know what you're talking about here. Is this the instance locking stuff Bruno proposed a while ago? > > I'm sure there are more examples. but I hope you get I'm not just trying to > > troll. > > > > The TC did apply inconsistant rules on letting projects in. That was for > > sure a negative before the big tent. But it also provided a way to apply > > pressure to projects to fix some of the issues that multiple projects face, > > and that plague user/operators and raise the whole community up, and that > > has fallen to the wayside since. Which is a big negative now. Maybe that > > could be bolted on top of the Big Tent I don't know. > > So I think that's the root of the issue here. You assume we can > "pressure" people do something you think is right. But that's not how > opensource works. You either implement the solution to your problem, > or convince someone else, but you don't force anybody. I think that's > what the TC recognized and changed, to the correct path. Could project > be better integrated, so that we have a more coherent "product"? Sure. > But you don't achieve that with more governance and processes. > > -- > Thomas > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Michael
__________________________________________________________________________ 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
