<div dir="ltr">Jay, <div><br></div><div>All that you say exactly explains the reason why more and more companies are leaving OpenStack. </div><div><br></div><div>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. </div><div><br></div><div>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...</div><div><br></div><div>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...</div><div><br></div><div>We as a community can continue saying that the current OpenStack approach is the best 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... </div><div><br></div><div>I know this all sounds like a big change, but let's be honest current situation doesn't look healthy... </div><div>By the way, almost all successful projects in open source have benevolent dictator and everybody is OK with that's how things works... </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">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.</span></blockquote><div><br></div><div>I am writing here on my behalf (using my personal email, if you haven't seen), are we actually Open Source? or Enterprise Source? </div><div><br></div><div>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.....</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">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.</span></blockquote><div><br></div><div>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 ;) </div><div><br></div><div>- There is no sliver bullet in programming. For example, would Git or Linux be better if it was written using microservices approach? </div><div>- Mircroservices are obsolete you should use new hype thing called FaaS (I am just curios when these FaaS fellow are going to implement modules for FaaS and when they are going to understand that they will need actually everything development in programming languages (OOP, AOP, DI, ...) to glue these things;) ) </div><div>- I was talking about architectural changes, not a programming language, so it's sort of big type mismatch and logically wrong. However, what's wrong with Cobol? If you use right architecture and right algorithms it will definitely work better than implementation of program in any other language with wrong architecture and bad algorithms... so not sure that I understand this point/joke... </div><div><br></div><div><br></div><div>Best regards,</div><div>Boris Pavlovic </div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 13, 2017 at 10:44 AM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>On 09/12/2017 06:53 PM, Boris Pavlovic wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Mike,<br>
<br>
Great intiative, unfortunately I wasn't able to attend it, however I have some thoughts...<br>
You can't simplify OpenStack just by fixing few issues that are described in the etherpad mostly..<br>
<br>
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..<br>
</blockquote>
<br></span>
OpenStack is not a product. It's a collection of projects that represent a toolkit for various cloud-computing functionality.<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
*Simple things to improve: *<br>
/This is going to allow community to work together, and actually get feedback in standard way, and incrementally improve quality. /<span><br>
<br>
1) There should be one and only one:<br>
1.1) deployment/packaging(may be docker) upgrade mechanism used by everybody<br>
</span></blockquote>
<br>
Good luck with that :) The likelihood of the deployer/packager community agreeing on a single solution is zero.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
1.2) monitoring/logging/tracing mechanism used by everybody<br>
</blockquote>
<br></span>
Also close to zero chance of agreeing on a single solution. Better to focus instead on ensuring various service projects are monitorable and transparent.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
1.3) way to configure all services (e.g. k8 etcd way)<br>
</blockquote>
<br></span>
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.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
2) Projects must have standardize interface that allows these projects to use them in same way.<br>
</blockquote>
<br></span>
Give examples of services that communicate over *non-standard* interfaces. I don't know of any.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
3) Testing & R&D should be performed only against this standard deployment<br>
</blockquote>
<br></span>
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.<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
*Hard things to improve: *<span><br>
<br>
OpenStack projects were split in far from ideal way, which leads to bunch of gaps that we have now:<br>
1.1) Code & functional duplications: Quotas, Schedulers, Reservations, Health checks, Loggign, Tracing, ....<br>
</span></blockquote>
<br>
There is certainly code duplication in some areas, yes.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
1.2) Non optimal workflows (booting VM takes 400 DB requests) because data is stored in Cinder,Nova,Neutron....<br>
</blockquote>
<br></span>
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.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
1.3) Lack of resources (as every project is doing again and again same work about same parts)<br>
</blockquote>
<br></span>
Provide specific examples please.<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
What we can do:<br>
<br>
*1) Simplify internal communication *<span><br>
1.1) Instead of AMQP for internal communication inside projects use just HTTP, load balancing & retries.<br>
</span></blockquote>
<br>
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.<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
*2) Use API Gateway pattern *<span><br>
3.1) Provide to use high level API one IP address with one client<br>
3.2) Allows to significant reduce load on Keystone because tokens are checked only in API gateway<br>
3.3) Simplifies communication between projects (they are now in trusted network, no need to check token)<br>
</span></blockquote>
<br>
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.<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
*3) Fix the OpenStack split *<span><br>
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)<br>
</span></blockquote>
<br>
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.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
3.2) Somehow deal with defragmentation of resources e.g. VM Volumes and Networks data which is heavily connected.<br>
</blockquote>
<br></span>
How are these things connected?<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
*4) Don't be afraid to break things*<span><br>
Maybe it's time for OpenStack 2:<br>
<br></span>
* In any case most of people provide API on top of OpenStack for usage<br>
* In any case there is no standard and easy way to upgrade <br><span>
So basically we are not losing anything even if we do not backward compatible changes and rethink completely architecture and API.<br>
</span></blockquote>
<br>
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.<br>
<br>
-jay<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>
I know this sounds like science fiction, but I believe community will appreciate steps in this direction...<br>
<br>
<br>
Best regards,<br>
Boris Pavlovic<br>
<br></span><span>
On Tue, Sep 12, 2017 at 2:33 PM, Mike Perez <<a href="mailto:thingee@gmail.com" target="_blank">thingee@gmail.com</a> <mailto:<a href="mailto:thingee@gmail.com" target="_blank">thingee@gmail.com</a>>> wrote:<br>
<br>
Hey all,<br>
<br>
The session is over. I’m hanging near registration if anyone wants to<br>
discuss things. Shout out to John for coming by on discussions with<br>
simplifying dependencies. I welcome more packagers to join the<br>
discussion.<br>
<br>
<a href="https://etherpad.openstack.org/p/simplifying-os" rel="noreferrer" target="_blank">https://etherpad.openstack.org<wbr>/p/simplifying-os</a><br>
<<a href="https://etherpad.openstack.org/p/simplifying-os" rel="noreferrer" target="_blank">https://etherpad.openstack.or<wbr>g/p/simplifying-os</a>><br>
<br>
—<br>
Mike Perez<br>
<br>
<br>
On September 12, 2017 at 11:45:05, Mike Perez (<a href="mailto:thingee@gmail.com" target="_blank">thingee@gmail.com</a><br></span><div><div class="gmail-m_3341083664813374512h5">
<mailto:<a href="mailto:thingee@gmail.com" target="_blank">thingee@gmail.com</a>>) wrote:<br>
> Hey all,<br>
><br>
> Back in a joint meeting with the TC, UC, Foundation and The Board<br>
it was decided as an area<br>
> of OpenStack to focus was Simplifying OpenStack. This<br>
intentionally was very broad<br>
> so the community can kick start the conversation and help tackle<br>
some broad feedback<br>
> we get.<br>
><br>
> Unfortunately yesterday there was a low turn out in the<br>
Simplification room. A group<br>
> of people from the Swift team, Kevin Fox and Swimingly were nice<br>
enough to start the conversation<br>
> and give some feedback. You can see our initial ether pad work here:<br>
><br>
> <a href="https://etherpad.openstack.org/p/simplifying-os" rel="noreferrer" target="_blank">https://etherpad.openstack.org<wbr>/p/simplifying-os</a><br>
<<a href="https://etherpad.openstack.org/p/simplifying-os" rel="noreferrer" target="_blank">https://etherpad.openstack.or<wbr>g/p/simplifying-os</a>><br>
><br>
> There are efforts happening everyday helping with this goal, and<br>
our team has made some<br>
> documented improvements that can be found in our report to the<br>
board within the ether<br>
> pad. I would like to take a step back with this opportunity to<br>
have in person discussions<br>
> for us to identify what are the area of simplifying that are<br>
worthwhile. I’m taking a break<br>
> from the room at the moment for lunch, but I encourage people at<br>
13:30 local time to meet<br>
> at the simplification room level b in the big thompson room.<br>
Thank you!<br>
><br>
> —<br>
> Mike Perez<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe:<br>
<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br></div></div>
<<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@<wbr>lists.openstack.org?subject:un<wbr>subscribe</a>><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cg<wbr>i-bin/mailman/listinfo/opensta<wbr>ck-dev</a>><span><br>
<br>
<br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br>
</span></blockquote><div class="gmail-m_3341083664813374512HOEnZb"><div class="gmail-m_3341083664813374512h5">
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br></div></div>