Open Stack

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.Fox at 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 [jaypipes at gmail.com]
> Sent: Friday, July 15, 2016 8:17 AM
> To: openstack-dev at 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.hayes at hpe.com]
> > Sent: Thursday, July 14, 2016 12:21 PM
> > To: OpenStack Development Mailing List (not for usage questions);
> > openstack-tc at 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-request at 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-request at 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-
> request at 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-
> request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev