Open Stack

On Tue, Sep 12, 2017 at 3:53 PM, Boris Pavlovic <boris at pavlovic.me> 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..

This is exactly how one gets started, though, by dragging the
skeletons to light. I, too, was unable to attend due to scheduling,
but as PTL of a project complicated by years of tech debt, before even
being an anointed OpenStack project, this topic is of particular
interest to me.

>
> 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..

I agree and disagree with what you say here. Shrinking use cases
misses the mark an order of magnitude or three. However, focusing on
the outcome is exactly what needs to happen for everyone to walk away
with the warm fuzzies, upstream and downstream alike.

>
> 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

You keep using that word. This feels like a "you can have it any color
you like, so long as it's black" argument. This is great for
manufacturing tangible products that sit on a shelf somewhere. Not so
much for a collection of software, already well into the maturation
phase, that is the collective output of hundreds, nay, thousands of
minds. What you propose almost never happens in practice, as nice as
it sounds. The outcome is significantly more important than what
people to do get there. I hereby refer to XKCD rule #927 on the topic
of standards, only partly in jest.

>
> 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, ....

Yup. Large software projects have some duplication, it's natural and
requires occasional love. It takes people to actively battle the tech
debt, and not everyone has the luxury of a fully dedicated team.

> 1.2) Non optimal workflows (booting VM takes 400 DB requests) because data
> is stored in Cinder,Nova,Neutron....

SQL is SQL, though, so I don't see what you're getting at. I'm sure
some things need some tuning and queries need some optimization, but I
hung up my DBA hat years ago.

> 1.3) Lack of resources (as every project is doing again and again same work
> about same parts)

I read that last part to mean people and not so much technical
limitations. If I've correctly read things with my corporate lens on,
that's a universal pain that is felt by nearly every specialized field
of work, and OpenStack is by no means unique. Downstream consumers of
OpenStack code are only willing to financially support so many
specialists, and they can support more than the Foundation. If the
problem is people, convince more people to contribute, since we're
remaking the universe.

>
> What we can do:
>
> 1) Simplify internal communication
> 1.1) Instead of AMQP for internal communication inside projects use just
> HTTP, load balancing & retries.

In my experiences, AMQP has mostly sat there in the background, until
someone comes along and touches it. We haven't touched the
openstack-ops-messaging cookbook beyond testing enhancements and
deprecations in at least a cycle because it just works. Retries just
mask an underlying problem. With my operator hat on, I don't want my
client to try N times if the service is intermittently failing.

>
> 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)

I don't see this as being something to beholden OpenStack development
teams to implement and maintain, even if people pay for this
functionality or implement it on their own. That's more of a use case,
not a feature request.

>
> 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)

No, please, just... no. A monolithic architecture is fine for dev, but
it falls apart prematurely in the lifecycle when you throw the spurs
to it.

> 3.2) Somehow deal with defragmentation of resources e.g. VM Volumes and
> Networks data which is heavily connected.

That's for the implementation phase, not development. You can put
volume storage and VMs on the same machine, if you want/need to do so.
This smells like... another use case!

>
>
> 4) Don't be afraid to break things
> Maybe it's time for OpenStack 2:

Blue polka dots with green stripes! With a racing stripe! And a
whipped pony on top.

>
> 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.

Quis custodiet ipsos custodes? Who ensures the usage APIs align with
the service APIs align with the architecture? What happens when one
group responsible for one API doesn't talk to the other because their
employers changed directions? I'm not convinced an "incremental" all
the things approach can benefit anyone, particularly one that demands
more of people.

>
>
> I know this sounds like science fiction, but I believe community will
> appreciate steps in this direction...

I'm going to invoke PHK here and show my roots: *ahem* Quality happens
only when someone is responsible for it. A dramatic sweeping change
from one extreme to the other is just being along for the ride when
the pendulum swings. It's not time to throw in the towel on OpenStack
quite yet. We're all looking for an agreeable positive outcome that
will benefit all of our employers and their customers, but it doesn't
work to profess a Grand Unified Way when there needn't necessarily be
one. I thought there needed to be one, on my flight back from Boston.

Then I ran for PTL a third cycle. :)

>
>
> 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
>
>
>
> __________________________________________________________________________
> 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
>



-- 
Best,
Samuel Cassiba