Open Stack

I'm arguing the opposite. It should be a requirement to use the OpenStack Secret Store.

Instead, we're trying to make it optional and either reimplementing large swaths of it in individual projects to make it optional, or skip security all together.

If it wasn't optional, then:
 * Keystone could rely on it being there for password hashing
 * Magnum can rely on it for security.
 * lbaas can rely on it
 * App developers can rely on it being there
 * ...

Same with Zaqar. It was a requirement then,
 * Guest agents of heat, sahara, mangum, trove, etc could all rely on it being there and wouldn't have to deal with workarounds
 * Horizon could rely on it being there for dynamic ui
 * App developers can rely on it being there.

Yes, it seems like more work for an operator to have to install "one more thing", but the savings it provides by not having to do that "one more thing" in 7 different projects pays for it.

Rather then focus on sharing code by adding required project dependencies, we're just implementing things in each project to workaround the lack thereof in a general project and then everyone suffers for it.

Thanks,
Kevin

________________________________________
From: Hongbin Lu [hongbin.lu at huawei.com]
Sent: Friday, July 15, 2016 10:41 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for all)

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

__________________________________________________________________________
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