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>> 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>
—
Mike Perez
On September 12, 2017 at 11:45:05, Mike Perez (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>
>
> 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://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
__________________________________________________________________________
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
