Kevin, just one comment inline below. On Thu, Jun 22, 2017 at 3:33 PM, Fox, Kevin M <kevin....@pnnl.gov> wrote:
> No, I'm not necessarily advocating a monolithic approach. > > I'm saying that they have decided to start with functionality and accept > whats needed to get the task done. Theres not really such strong walls > between the various functionality, rbac/secrets/kublet/etc. They don't > spawn off a whole new project just to add functionality. they do so only > when needed. They also don't balk at one feature depending on another. > > rbac's important, so they implemented it. ssl cert management was > important. so they added that. adding a feature that restricts secret > downloads only to the physical nodes need them, could then reuse the rbac > system and ssl cert management. > > Their sigs are more oriented to features/functionality (or catagories > there of), not as much specific components. We need to do X. X may involve > changes to components A and B. > > OpenStack now tends to start with A and B and we try and work backwards > towards implementing X, which is hard due to the strong walls and unclear > ownership of the feature. And the general solution has been to try and make > C but not commit to C being in the core so users cant depend on it which > hasn't proven to be a very successful pattern. > > Your right, they are breaking up their code base as needed, like nova did. > I'm coming around to that being a pretty good approach to some things. > starting things is simpler, and if it ends up not needing its own whole > project, then it doesn't get one. if it needs one, then it gets one. Its > not by default, start whole new project with db user, db schema, api, > scheduler, etc. And the project might not end up with daemons split up in > exactly the way you would expect if you prepoptomized breaking off a > project not knowing exactly how it might integrate with everything else. > > Maybe the porcelain api that's been discussed for a while is part of the > solution. initial stuff can prototyped/start there and break off as needed > to separate projects and moved around without the user needing to know > where it ends up. > > Your right that OpenStack's scope is much grater. and think that the > commons are even more important in that case. If it doesn't have a solid > base, every project has to re-implement its own base. That takes a huge > amount of manpower all around. Its not sustainable. > > I guess we've gotten pretty far away from discussing Trove at this point. > Please keep the conversation going. > > Thanks, > Kevin > ________________________________________ > From: Jay Pipes [jaypi...@gmail.com] > Sent: Thursday, June 22, 2017 10:05 AM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect > Trove > > On 06/22/2017 11:59 AM, Fox, Kevin M wrote: > > My $0.02. > > > > That view of dependencies is why Kubernetes development is outpacing > OpenStacks and some users are leaving IMO. Not trying to be mean here but > trying to shine some light on this issue. > > > > Kubernetes at its core has essentially something kind of equivalent to > keystone (k8s rbac), nova (container mgmt), cinder (pv/pvc/storageclasses), > heat with convergence (deployments/daemonsets/etc), barbican (secrets), > designate (kube-dns), and octavia (kube-proxy,svc,ingress) in one unit. Ops > dont have to work hard to get all of it, users can assume its all there, > and devs don't have many silo's to cross to implement features that touch > multiple pieces. > > I think it's kind of hysterical that you're advocating a monolithic > approach when the thing you're advocating (k8s) is all about enabling > non-monolithic microservices architectures. > > Look, the fact of the matter is that OpenStack's mission is larger than > that of Kubernetes. And to say that "Ops don't have to work hard" to get > and maintain a Kubernetes deployment (which, frankly, tends to be dozens > of Kubernetes deployments, one for each tenant/project/namespace) is > completely glossing over the fact that by abstracting away the > infrastructure (k8s' "cloud provider" concept), Kubernetes developers > simply get to ignore some of the hardest and trickiest parts of operations. > > So, let's try to compare apples to apples, shall we? > > It sounds like the end goal that you're advocating -- more than anything > else -- is an easy-to-install package of OpenStack services that > provides a Kubernetes-like experience for application developers. > > I 100% agree with that goal. 100%. > > But pulling Neutron, Cinder, Keystone, Designate, Barbican, and Octavia > back into Nova is not the way to do that. You're trying to solve a > packaging and installation problem with a code structure solution. > > In fact, if you look at the Kubernetes development community, you see > the *opposite* direction being taken: they have broken out and are > actively breaking out large pieces of the Kubernetes repository/codebase > into separate repositories and addons/plugins. And this is being done to > *accelerate* development of Kubernetes in very much the same way that > splitting services out of Nova was done to accelerate the development of > those various pieces of infrastructure code. > > > This core functionality being combined has allowed them to land features > that are really important to users but has proven difficult for OpenStack > to do because of the silo's. OpenStack's general pattern has been, stand up > a new service for new feature, then no one wants to depend on it so its > ignored and each silo reimplements a lesser version of it themselves. > > I disagree. I believe the reason Kubernetes is able to land features > that are "really important to users" is primarily due to the following > reasons: > > 1) The Kubernetes technical leadership strongly resists pressure from > vendors to add yet-another-specialized-feature to the codebase. This > ability to say "No" pays off in spades with regards to stability and focus. > > 2) The mission of Kubernetes is much smaller than OpenStack. If the > OpenStack community were able to say "OpenStack is a container > orchestration system", and not "OpenStack is a ubiquitous open source > cloud operating system", we'd probably be able to deliver features in a > more focused fashion. > > > The OpenStack commons then continues to suffer. > > > > We need to stop this destructive cycle. > > > > OpenStack needs to figure out how to increase its commons. Both > internally and externally. etcd as a common service was a step in the right > direction. > > > > I think k8s needs to be another common service all the others can rely > on. That could greatly simplify the rest of the OpenStack projects as a lot > of its functionality no longer has to be implemented in each project. > > I don't disagree with the goal of being able to rely on Kubernetes for > many things. But relying on Kubernetes doesn't solve the "I want some > easy-to-install infrastructure" problem. Nor does it solve the types of > advanced networking scenarios that the NFV community requires. > > > We also need a way to break down the silo walls and allow more cross > project collaboration for features. I fear the new push for letting > projects run standalone will make this worse, not better, further > fracturing OpenStack. > > Perhaps you are referring to me with the above? As I said on Twitter, > "Make your #OpenStack project usable by and useful for things outside of > the OpenStack ecosystem. Fewer deps. Do one thing well. Solid APIs." > > I don't think that the above leads to "further fracturing OpenStack". I > think it leads to solid, reusable components. > > Best, > -jay > > > Thanks, > > Kevin > > ________________________________________ > > From: Thierry Carrez [thie...@openstack.org] > > Sent: Thursday, June 22, 2017 12:58 AM > > To: openstack-dev@lists.openstack.org > > Subject: Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect > Trove > > > > Fox, Kevin M wrote: > >> [...] > >> If you build a Tessmaster clone just to do mariadb, then you share > nothing with the other communities and have to reinvent the wheel, yet > again. Operators load increases because the tool doesn't function like > other tools. > >> > >> If you rely on a container orchestration engine that's already cross > cloud that can be easily deployed by user or cloud operator, and fill in > the gaps with what Trove wants to support, easy management of db's, you get > to reuse a lot of the commons and the users slight increase in investment > in dealing with the bit of extra plumbing in there allows other things to > also be easily added to their cluster. Its very rare that a user would need > to deploy/manage only a database. The net load on the operator decreases, > not increases. > > > > I think the user-side tool could totally deploy on Kubernetes clusters > > -- if that was the only possible target that would make it a Kubernetes > > tool more than an open infrastructure tool, but that's definitely a > > possibility. I'm not sure work is needed there though, there are already > > tools (or charts) doing that ? > > > > For a server-side approach where you want to provide a DB-provisioning > > API, I fear that making the functionality depend on K8s would make > > TroveV2/Hoard would not only depend on Heat and Nova, but also depend on > > something that would deploy a Kubernetes cluster (Magnum?), which would > > likely hurt its adoption (and reusability in simpler setups). Since > > databases would just work perfectly well in VMs, it feels like a > > gratuitous dependency addition ? > > > > We generally need to be very careful about creating dependencies between > > OpenStack projects. On one side there are base services (like Keystone) > > that we said it was alright to depend on, but depending on anything else > > is likely to reduce adoption. Magnum adoption suffers from its > > dependency on Heat. If Heat starts depending on Zaqar, we make the > > problem worse. I understand it's a hard trade-off: you want to reuse > > functionality rather than reinvent it in every project... we just need > > to recognize the cost of doing that. > > > > -- > > Thierry Carrez (ttx) > > > > ____________________________________________________________ > ______________ > > 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 >
__________________________________________________________________________ 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
