Jay, OK, I'll bite.
This doesn't sound like a constructive discussion. Bye Bye. Best regards, Boris Pavlovic On Thu, Sep 14, 2017 at 8:50 AM, Jay Pipes <jaypi...@gmail.com> wrote: > OK, I'll bite. > > On 09/13/2017 08:56 PM, Boris Pavlovic wrote: > >> Jay, >> >> All that you say exactly explains the reason why more and more companies >> are leaving OpenStack. >> > > All that I say? The majority of what I was "saying" was actually asking > you to back up your statements with actual proof points instead of making > wild conjectures. > > Companies and actually end users care only about their things and how can >> they get their job done. They want thing that they can run and support >> easily and that resolves their problems. >> > > No disagreement from me. That said, I fail to see what the above statement > has to do with anything I wrote. > > They initially think that it's a good idea to take a OpenStack as a >> Framework and build sort of product on top of it because it's so open and >> large and everybody uses... >> > > End users of OpenStack don't "build sort of product on top". End users of > OpenStack call APIs or use Horizon to launch VMs, create networks, volumes, > and whatever else those end users need for their own use cases. > > Soon they understand that OpenStack has very complicated operations >> because it's not designed to be a product but rather framework and that the >> complexity of running OpenStack is similar to development in house solution >> and as time is spend they have only few options: move to public cloud or >> some other private cloud solution... >> > > Deployers of OpenStack use the method of installing and configuring > OpenStack that matches best their cultural fit, experience and level of > comfort with underlying technologies and vendors (packages vs. source vs. > images, using a vendor distribution vs. going it alone, Chef vs. Puppet vs. > Ansible vs. SaltStack vs. Terraform, etc). The way they configure OpenStack > services is entirely dependent on the use cases they wish to support for > their end users. And, to repeat myself, there is NO SINGLE USE CASE for > infrastructure services like OpenStack. Therefore there is zero chance for > a "standard deployment" of OpenStack becoming a reality. > > Just like there are myriad ways of deploying and configuring OpenStack, > there are myriad ways of deploying and configuring k8s. Why? Because > deploying and configuring highly distributed systems is a hard problem to > solve. And maintaining and operating those systems is an even harder > problem to solve. > > We as a community can continue saying that the current OpenStack approach >> is the best >> > > Nobody is saying that the current OpenStack approach is the best. I > certainly have never said this. All that I have asked is that you actually > back up your statements with proof points that demonstrate how and why a > different approach to building software will lead to specific improvements > in quality or user experience. > > and keep loosing customers/users/community, or change something >> drastically, like bring technical leadership to OpenStack Foundation >> that is going to act like benevolent dictator that focuses OpenStack >> effort on shrinking uses cases, redesigning architecture and moving >> to the right direction... >> > > What *specifically* is the "right direction" for OpenStack to take? > Please, as I asked you in the original response, provide actual details > other than "we should have a monolithic application". Provide an argument > as to how and why *your* direction is "right" for every user of OpenStack. > > When you say "technical leadership", what specifically are you wanting to > see? > > >> I know this all sounds like a big change, but let's be honest current >> situation doesn't look healthy... >> By the way, almost all successful projects in open source have benevolent >> dictator and everybody is OK with that's how things works... >> > > Who is the benevolent dictator of k8s? Who is the benevolent dictator of > MySQL? Of PostgreSQL? Of etcd? > > You have a particularly myopic view of what "successful" is for open > source, IMHO. > > Awesome news. I will keep this in mind when users (like GoDaddy) ask >> Nova to never break anything ever and keep behaviour like scheduler >> retries that represent giant technical debt. >> >> I am writing here on my behalf (using my personal email, if you haven't >> seen), are we actually Open Source? or Enterprise Source? >> >> More over I don't think that what you say is going to be an issue for >> GoDaddy, at least soon, because we still can't upgrade, because it's NP >> complete problem (even if you run just core projects), which is what my >> email was about, and I saw the same stories in bunch of other companies..... >> > > You continue to speak in hyperbole and generalizations. What > *specifically* about your recommendations will improve the upgrade ability > and story for OpenStack? > > Yes, let's definitely go the opposite direction of microservices and >> loosely coupled domains which is the best practices of software >> development over the last two decades. While we're at it, let's >> rewrite OpenStack projects in COBOL. >> >> I really don't want to answer on this provocation, because it shifts the >> focus from major topic. But I really can't stop myself ;) >> >> - There is no sliver bullet in programming. For example, would Git or >> Linux be better if it was written using microservices approach? >> > > I am fully aware that there is no silver bullet in programming. That was > actually my entire point. It is you that continues to espouse various > opinions that imply that there *is* some sort of silver bullet solution to > OpenStack's problems. > > You imply that monolithic architecture will magically solve problems > inherent in highly distributed systems. > > You imply that having a benevolent dictator will magically result in a > productized infrastructure platform that meets everyone's needs. > > And you imply that using a single deployment/packaging solution (Docker) > will magically solve all issues with upgrades. > > Please answer the questions in my original response with some specific > details. > > Thanks > -jay > > Best regards, >> Boris Pavlovic >> >> >> On Wed, Sep 13, 2017 at 10:44 AM, Jay Pipes <jaypi...@gmail.com <mailto: >> jaypi...@gmail.com>> wrote: >> >> On 09/12/2017 06:53 PM, Boris Pavlovic wrote: >> >> Mike, >> >> Great intiative, unfortunately I wasn't able to attend it, >> however I have some thoughts... >> You can't simplify OpenStack just by fixing few issues that are >> described in the etherpad mostly.. >> >> TC should work on shrinking the OpenStack use cases and moving >> towards the product (box) complete solution instead of pieces of >> bunch barely related things.. >> >> >> OpenStack is not a product. It's a collection of projects that >> represent a toolkit for various cloud-computing functionality. >> >> *Simple things to improve: * >> /This is going to allow community to work together, and actually >> get feedback in standard way, and incrementally improve quality. / >> >> 1) There should be one and only one: >> 1.1) deployment/packaging(may be docker) upgrade mechanism used >> by everybody >> >> >> Good luck with that :) The likelihood of the deployer/packager >> community agreeing on a single solution is zero. >> >> 1.2) monitoring/logging/tracing mechanism used by everybody >> >> >> Also close to zero chance of agreeing on a single solution. Better >> to focus instead on ensuring various service projects are >> monitorable and transparent. >> >> 1.3) way to configure all services (e.g. k8 etcd way) >> >> >> Are you referring to the way to configure k8s services or the way to >> configure/setup an *application* that is running on k8s? If the >> former, then there is *not* a single way of configuring k8s >> services. If the latter, there isn't a single way of configuring >> that either. In fact, despite Helm being a popular new entrant to >> the k8s application package format discussion, k8s itself is >> decidedly *not* opinionated about how an application is configured. >> Use a CMDB, use Helm, use env variables, use confd, use whatever. >> k8s doesn't care. >> >> 2) Projects must have standardize interface that allows these >> projects to use them in same way. >> >> >> Give examples of services that communicate over *non-standard* >> interfaces. I don't know of any. >> >> 3) Testing & R&D should be performed only against this standard >> deployment >> >> >> Sorry, this is laughable. There will never be a standard deployment >> because there are infinite use cases that infrastructure supports. >> *Your* definition of what works for GoDaddy is decidedly different >> from someone else's definition of what works for them. >> >> *Hard things to improve: * >> >> OpenStack projects were split in far from ideal way, which leads >> to bunch of gaps that we have now: >> 1.1) Code & functional duplications: Quotas, Schedulers, >> Reservations, Health checks, Loggign, Tracing, .... >> >> >> There is certainly code duplication in some areas, yes. >> >> 1.2) Non optimal workflows (booting VM takes 400 DB requests) >> because data is stored in Cinder,Nova,Neutron.... >> >> >> Sorry, I call bullshit on this. It does not take 400 DB requests to >> boot a VM. Also: the DB is not at all the bottleneck in the VM >> launch process. You've been saying it is for years with no >> justification to back you up. Pointing to a Rally scenario that >> doesn't reflect a real-world usage of OpenStack services isn't useful. >> >> 1.3) Lack of resources (as every project is doing again and >> again same work about same parts) >> >> >> Provide specific examples please. >> >> What we can do: >> >> *1) Simplify internal communication * >> 1.1) Instead of AMQP for internal communication inside projects >> use just HTTP, load balancing & retries. >> >> >> Prove to me that this would solve a problem. First describe what the >> problem is, then show me that using AMQP is the source of that >> problem, then show me that using HTTP requests would solve that >> problem. >> >> *2) Use API Gateway pattern * >> 3.1) Provide to use high level API one IP address with one client >> 3.2) Allows to significant reduce load on Keystone because >> tokens are checked only in API gateway >> 3.3) Simplifies communication between projects (they are now in >> trusted network, no need to check token) >> >> >> Why is this a problem for OpenStack projects to deal with? If you >> want a single IP address for all APIs that your users consume, then >> simply deploy all the public-facing services on a single set of web >> servers and make each service's root endpoint be a subresource on >> the root IP/DNS name. >> >> *3) Fix the OpenStack split * >> 3.1) Move common functionality to separated internal services: >> Scheduling, Logging, Monitoring, Tracing, Quotas, Reservations >> (it would be even better if this thing would have more or less >> monolithic architecture) >> >> >> Yes, let's definitely go the opposite direction of microservices and >> loosely coupled domains which is the best practices of software >> development over the last two decades. While we're at it, let's >> rewrite OpenStack projects in COBOL. >> >> 3.2) Somehow deal with defragmentation of resources e.g. VM >> Volumes and Networks data which is heavily connected. >> >> >> How are these things connected? >> >> *4) Don't be afraid to break things* >> Maybe it's time for OpenStack 2: >> >> * In any case most of people provide API on top of OpenStack >> for usage >> * In any case there is no standard and easy way to upgrade >> So basically we are not losing anything even if we do not >> backward compatible changes and rethink completely architecture >> and API. >> >> >> Awesome news. I will keep this in mind when users (like GoDaddy) ask >> Nova to never break anything ever and keep behaviour like scheduler >> retries that represent giant technical debt. >> >> -jay >> >> I know this sounds like science fiction, but I believe community >> will appreciate steps in this direction... >> >> >> Best regards, >> Boris Pavlovic >> >> On Tue, Sep 12, 2017 at 2:33 PM, Mike Perez <thin...@gmail.com >> <mailto:thin...@gmail.com> <mailto:thin...@gmail.com >> <mailto:thin...@gmail.com>>> wrote: >> >> Hey all, >> >> The session is over. I’m hanging near registration if >> anyone wants to >> discuss things. Shout out to John for coming by on >> discussions with >> simplifying dependencies. I welcome more packagers to join >> the >> discussion. >> >> https://etherpad.openstack.org/p/simplifying-os >> <https://etherpad.openstack.org/p/simplifying-os> >> <https://etherpad.openstack.org/p/simplifying-os >> <https://etherpad.openstack.org/p/simplifying-os>> >> >> — >> Mike Perez >> >> >> On September 12, 2017 at 11:45:05, Mike Perez >> (thin...@gmail.com <mailto:thin...@gmail.com> >> <mailto:thin...@gmail.com <mailto:thin...@gmail.com>>) >> wrote: >> > Hey all, >> > >> > Back in a joint meeting with the TC, UC, Foundation and >> The Board >> it was decided as an area >> > of OpenStack to focus was Simplifying OpenStack. This >> intentionally was very broad >> > so the community can kick start the conversation and >> help tackle >> some broad feedback >> > we get. >> > >> > Unfortunately yesterday there was a low turn out in the >> Simplification room. A group >> > of people from the Swift team, Kevin Fox and Swimingly >> were nice >> enough to start the conversation >> > and give some feedback. You can see our initial ether >> pad work here: >> > >> > https://etherpad.openstack.org/p/simplifying-os >> <https://etherpad.openstack.org/p/simplifying-os> >> <https://etherpad.openstack.org/p/simplifying-os >> <https://etherpad.openstack.org/p/simplifying-os>> >> > >> > There are efforts happening everyday helping with this >> goal, and >> our team has made some >> > documented improvements that can be found in our report >> to the >> board within the ether >> > pad. I would like to take a step back with this >> opportunity to >> have in person discussions >> > for us to identify what are the area of simplifying that >> are >> worthwhile. I’m taking a break >> > from the room at the moment for lunch, but I encourage >> people at >> 13:30 local time to meet >> > at the simplification room level b in the big thompson >> room. >> Thank you! >> > >> > — >> > Mike Perez >> >> ______________________________ >> ____________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> <http://openstack-dev-requ...@lists.openstack.org?subject:un >> subscribe> >> <http://OpenStack-dev-request@ >> lists.openstack.org?subject:unsubscribe >> <http://openstack-dev-requ...@lists.openstack.org?subject:un >> subscribe>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> >> <http://lists.openstack.org/cg >> i-bin/mailman/listinfo/openstack-dev >> <http://lists.openstack.org/cgi-bin/mailman/listinfo/opensta >> ck-dev>> >> >> >> >> >> ____________________________________________________________ >> ______________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> <http://openstack-dev-requ...@lists.openstack.org?subject:un >> subscribe> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> <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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> <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