No, Magnum still uses Barbican as an optional dependency, and I believe nobody has proposed to remove Barbican entirely. I have no position about big tent but using Magnum as an example of "projects are not working together" is inappropriate.
Best regards, Hongbin > -----Original Message----- > From: Fox, Kevin M [mailto:kevin....@pnnl.gov] > Sent: July-15-16 2:37 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins > for all) > > 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. > > 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. > > 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. > > I could write a very long description about the state of being an > OpenStack App developer too that touches on all the problems with > getting a consistent target and all the cross project communication > issues there of. But thats probably for some other time. > > Thanks, > Kevin > > ________________________________________ > From: Jay Pipes [jaypi...@gmail.com] > Sent: Friday, July 15, 2016 8:17 AM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins > for all) > > Kevin, can you please be *specific* about your complaints below? Saying > things like "less project communication" and "projects not working > together because of fear of adding dependencies" and "worse user > experience" are your personal opinions. Please back those opinions up > with specific examples of what you are talking about so that we may > address specific things and not vague ideas. > > Also, the overall goal of the Big Tent, as I've said repeatedly and > people keep willfully ignoring, was *not* to "make the community more > inclusive". It was to replace the inconsistently-applied-by-the-TC > *subjective* criteria for project applications to OpenStack with an > *objective* list of application requirements that could be > *consistently* reviewed by the TC. > > Thanks, > -jay > > On 07/14/2016 01:30 PM, Fox, Kevin M wrote: > > I'm going to go ahead and ask the difficult question now as the > answer is relevant to the attached proposal... > > > > Should we reconsider whether the big tent is the right approach going > forward? > > > > There have been some major downsides I think to the Big Tent approach, > such as: > > * Projects not working together because of fear of adding extra > dependencies Ops don't already have > > * Reimplementing features, badly, over and over again in different > projects instead of standardizing something. > > * More projects being created due to politics and not technical > reasons. > > * Less cross project communication > > * Greater Operator pain at trying to assemble a more loose > confederation of projects into something useful. > > * General pushing off more and more work to Operators/Users to deal > with. > > * Worse User experience as cross project issues aren't being > addressed. > > * Previously incubated projects such as Nova, Swift, etc getting a > disproportionate say in things as they have a greater current user base, > and its increasingly hard now for new projects to gain any traction. > > * Much less community pressure on projects to work together to > elevate everyone. Architectural decisions are now made at individual > project level with little done at the OpenStack level. > > * etc... > > > > The overall goal of the Big Tent was to make the community more > inclusive. That I think has mostly happened. Which is good. But It also > seems to have fractured the community more into insular islands and > made the system harder for our operators/users. Which is bad. > > > > Maybe the benefits outweigh the drawbacks. I'm not sure. But I think > its probably time to consider if it has been a net positive and should > be further refined to try and address some of these problems, or a net > negative and different approaches be explored. > > > > Thanks, > > Kevin > > ________________________________________ > > From: Hayes, Graham [graham.ha...@hpe.com] > > Sent: Thursday, July 14, 2016 12:21 PM > > To: OpenStack Development Mailing List (not for usage questions); > > openstack...@lists.openstack.org > > Subject: [openstack-dev] [tc][all] Plugins for all > > > > I just proposed a review to openstack/governance repo [0] that aims > to > > have everything across OpenStack be plugin based for all cross > project > > interaction, or allow all projects access to the same internal APIs > > and I wanted to give a bit of background on my motivation, and how it > > came about. > > > > Coming from a smaller project, I can see issues for new projects, > > smaller projects, and projects that may not be seen as "important". > > > > As a smaller project trying to fit into cross project initiatives, > > (and yes, make sure our software looks at least OK in the Project > > Navigator) the process can be difficult. > > > > A lot of projects / repositories have plugin interfaces, but also > have > > project integrations in tree, that do not follow the plugin interface. > > This makes it difficult to see what a plugin can, and should do. > > > > When we moved to the big tent, we wanted as a community to move to a > > flatter model, removing the old integrated status. > > > > Unfortunately we still have areas when some projects are more equal - > > there is a lingering set of projects who were integrated at the point > > in time that we moved, and have preferential status. > > > > A lot of the effects are hard to see, and are not insurmountable, but > > do cause projects to re-invent the wheel. > > > > For example, quotas - there is no way for a project that is not nova, > > neutron, cinder to hook into the standard CLI, or UI for setting > > quotas. They can be done as either extra commands (openstack dns > quota > > set --foo bar) or as custom panels, but not the way other quotas get > > set. > > > > Tempest plugins are another example. Approximately 30 of the 36 > > current plugins are using resources that are not supposed to be used, > > and are an unstable interface. Projects in tree in tempest are at a > > much better position, as any change to the internal API will have to > > be fixed before the gate merges, but other out of tree plugins are in > > a place where they can be broken at any point. > > > > None of this is meant to single out projects, or teams. A lot of the > > projects that are in this situation have inordinate amounts of work > > placed on them by the big-tent, and I can emphasize with why things > > are this way. These were the examples that currently stick out in my > > mind, and I think we have come to a point where we need to make a > > change as a community. > > > > By moving to a "plugins for all" model, these issues are reduced. > > It undoubtedly will cause more, but it is closer to our goal of > > Recognizing all our community is part of OpenStack, and differentiate > > projects by tags. > > > > This won't be a change that happens tomorrow, next week, or even next > > cycle, but think as a goal, we should start moving in this direction > > as soon as we can, and start building momentum. > > > > Thanks, > > > > Graham > > > > 0 - https://review.openstack.org/342366 > > > > > ______________________________________________________________________ > > ____ 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 > > > > _______________________________________________________________________ > ___ > 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 __________________________________________________________________________ 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