Hello, "Less project communication" and "projects not working together because of fear of adding dependencies" is not so true, I think. In my opinion, Big Tent projects are always open for integrating with each other, and we are doing great job for making integration points much stronger. Since you pointed out Sahara on your messages, I'll iterate with examples success stories of integration with other projects related to sahara.
1. Since kilo/liberty we did a great job of integrating with Heat for deploying infrastructure for clusters, and now have fully removed all places where we were relying on our own implementation of the engine for deploying clusters, instances and so on (code name direct engine.) 2. Since liberty/mitaka we are integrated with Barbican for improved secret storage solution, and now we’ve implemented that by using the castellan library. 3. Using manila shares for datasources; 4. Around liberty/mitaka sahara produced our CLI as an OpenStack Client plugin; 5. Now we are working on integrating with designate for dns purposes. The general problem of projects is resources that we have in our teams and current goals we are going to reach. For example, for sahara our current prio is really stable image generation, on making much more stable integration tests with really good coverage of deployment clusters, work on preparing baremetal clusters, and securing clusters. And finally let me clarify something regarding Zaqar for using remote operations. Sahara and Zaqar (correct me if i'm wrong) became integrated at almost the same time, so that means that sahara was not able to rely on Zaqar properly. And we are still open to integrating sahara with Zaqar for remote operations. But it's not real priority for us right now because there are plugins which don't rely on a lot of ssh operations (like Ambari or Cloudera: these plugins are almost entirely relying on interacting with managers via APIs), and a requirement of having a few floating ips is not so strict even for huge deployments. On Fri, Jul 15, 2016 at 9:36 PM, Fox, Kevin M <kevin....@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. > > 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 > -- Best Regards, Vitaly Gridnev, Project Technical Lead of OpenStack DataProcessing Program (Sahara) Mirantis, Inc
__________________________________________________________________________ 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
