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 [[email protected]]
Sent: Friday, July 15, 2016 8:17 AM
To: [email protected]
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 [[email protected]]
> Sent: Thursday, July 14, 2016 12:21 PM
> To: OpenStack Development Mailing List (not for usage questions);
> [email protected]
> 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: [email protected]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: [email protected]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
