[openstack-dev] [tc][all] Big tent? (Related to Plugins for all)

Michael Still mikal at stillhq.com
Mon Jul 18 17:13:57 UTC 2016


On 16 Jul 2016 1:27 PM, "Thomas Herve" <therve at redhat.com> wrote:
>
> On Fri, Jul 15, 2016 at 8:36 PM, Fox, Kevin M <Kevin.Fox at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160719/4835f245/attachment.html>


More information about the OpenStack-dev mailing list