[openstack-dev] [ptg] Simplification in OpenStack
Boris Pavlovic
boris at pavlovic.me
Tue Sep 12 22:53:36 UTC 2017
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..
*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
1.2) monitoring/logging/tracing mechanism used by everybody
1.3) way to configure all services (e.g. k8 etcd way)
2) Projects must have standardize interface that allows these projects to
use them in same way.
3) Testing & R&D should be performed only against this standard deployment
*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, ....
1.2) Non optimal workflows (booting VM takes 400 DB requests) because data
is stored in Cinder,Nova,Neutron....
1.3) Lack of resources (as every project is doing again and again same work
about same parts)
What we can do:
*1) Simplify internal communication *
1.1) Instead of AMQP for internal communication inside projects use just
HTTP, load balancing & retries.
*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)
*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)
3.2) Somehow deal with defragmentation of resources e.g. VM Volumes and
Networks data which is heavily 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.
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 <thingee at 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
>
> —
> Mike Perez
>
>
> On September 12, 2017 at 11:45:05, Mike Perez (thingee at 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
> >
> > 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170912/e36ad945/attachment.html>
More information about the OpenStack-dev
mailing list