Kfox> Responding to this inline. Sorry, its outlook. Not my choice. :/ -----Original Message----- From: Thomas Herve [mailto:the...@redhat.com] Sent: Saturday, July 16, 2016 1:22 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for all)
On Fri, Jul 15, 2016 at 8:36 PM, Fox, Kevin M <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. kfox> The problem with making it optional, is it's a chicken and the egg problem. Everyone makes it optional, so they all have to implement fallback code. Operators see its optional, so they don't deploy the optional stuff as that's "more work". Users can't depend on it, since its not there on most systems. They don't tend to ask for it to be installed. Then the new project never gains any traction. It's a vicious cycle. > 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. kfox> The problem is, it's a hard thing to solve, and I believe the current organization of OpenStack provides significant barrier to solving it. I've tried for years to solve it, and have basically given up. This is part of the big tent issue. I'm moving more and more stuff that requires Instance Users to non OpenStack systems, which will be a majority of my workload at some point if things continue. This is the kind of thing OpenStack is really suffering from right now, and will only get worse as it continues to be swept under the rug. > 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. Kfox> I both agree and disagree. OpenSource projects have long lived or died by good or bad governance. Take the OpenCore governance model. That one's fresh enough in our minds we still remember it. It is OpenSource.... but has had some major drawbacks and people discovered the drawbacks of it after the fact. Kfox> OpenSource licensing has "pressure" built into it. Some "require" you to keep the source open, or at minimal, "pressure" you to keep it open to reduce the effort of maintaining your own fork. This is a tradeoff devs often make for their users. Kfox> Yeah, I get you don't want to pressure folks in the wrong way in OpenSource as developers usually can just wonder off and do something else. I agree with that. Kfox> Your right, Its really up to the developers at the end of the day. Do they listen to their users, and bow to the "pressure" from them, or risk their projects user base dwindling to be only the developers themselves. They may be just fine with that. In that case, great. Kfox> But that's why we elect a TC. We elect a set of folks to govern the project as a whole, and try and come up with the right balance of user issues and developer issues and try and keep the project healthy. I believe that balance is out of whack right now. That we're very focused on the individual project developers and not so much the users as a whole. I'm open to being wrong, and/or discussion on how to better the situation. Thanks, Kevin -- Thomas __________________________________________________________________________ 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
