Open Stack

Hi Zane,

Thank you for your question.  I think you're raising a critical
question which we must all come to (fairly relative) agreement to so
that we can all build OpenStack in the same direction.

On Thu, Oct 12, 2017 at 12:51 PM, Zane Bitter <zbitter at redhat.com> wrote:
> (Reminder: we are in the TC election campaigning period, and we all have the
> opportunity to question the candidates. The campaigning period ends on
> Saturday, so make with the questions.)
>
>
> In my head, I have a mental picture of who I'm building OpenStack for. When
> I'm making design decisions I try to think about how it will affect these
> hypothetical near-future users. By 'users' here I mean end-users, the actual
> consumers of OpenStack APIs. What will it enable them to do? What will they
> have to work around? I think we probably all do this, at least
> subconsciously. (Free tip: try doing it consciously.)
>
> So my question to the TC candidates (and incumbent TC members, or anyone
> else, if they want to answer) is: what does the hypothetical OpenStack user
> that is top-of-mind in your head look like? Who are _you_ building OpenStack
> for?

Ideally, I think that OpenStack should be targeted to become a core
infrastructure tool that's part of organizations all around the world
which can deliver both OpenStack-native services (think Nova for VMs,
Cinder for block storage) and OpenStack-enabled services (think Magnum
which deployed Kubernetes integrated with OpenStack, Sahara which
deploys Big Data software integrated with Swift).

This essentially makes OpenStack sit at the heart of the operations of
every organization (ideally!).  It also translates well with
OpenStack's goal of providing a unified set of APIs and interfaces
which are always predictable to do the operations that you expect them
to do.  With time, this will make OpenStack much more accessible, as
it becomes very easy to interact with as any individuals move from one
organization to another.

To put in shorter terms: We need to continue to build standardized
APIs, with simple and easy-to-use interfaces.  If we keep doing this
and we do it right, naturally, OpenStack will become more accessible,
therefore much easier to interact with because consuming OpenStack is
second nature.

It might be a big leap to say this, but making an HTTP request is the
last of any developers problem with the amount of interactions most of
us have done against HTTP endpoints.  If we do things right with
OpenStack, making an OpenStack request should be just as much of a
second nature inside most organizations.

The one thing that I'll close on which I find critical is ensuring
that everything is fully delivered.  As simple as it sounds, we should
not have any "manual" steps in any of the OpenStack processes or
requests.  If we do, then I believe we need to go back to the drawing
board and try again.  For example, an OpenStack project that deploys a
software *should not* have a manual process (or steps) to do after it
deploys a software.  Instead, it should be fully integrated.

> There's a description of mine in this email, as an example:
> http://lists.openstack.org/pipermail/openstack-dev/2017-October/123312.html
>
> To be clear, for me at least there's only one wrong answer ("person who
> needs somewhere to run their IRC bouncer"). What's important in my opinion
> is that we have a bunch of people with *different* answers on the TC,
> because I think that will lead to better discussion and hopefully better
> decisions.
>
> Discuss.

Thanks for your very interesting question once again. :)

> cheers,
> Zane.
>
> __________________________________________________________________________
> 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