On 12/10/17 15:07, Mohammed Naser wrote:
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 <zbit...@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.
I don't disagree with any of that, but I feel compelled to point out
that you managed to say quite a lot about what we should build without
once mentioning anything about who is going to use it, even though that
was explicitly the question.
I'm not trying to call you out specifically; in fact, I'm worried that
this may be a widespread problem in OpenStack, which is the reason I
asked the question in the first place.
cheers,
Zane.
__________________________________________________________________________
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
