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:unsubscribe>
<http://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>
<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://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
