Open Stack

On Thu, Oct 12, 2017 at 8:15 PM, Zane Bitter <zbitter at redhat.com> wrote:
> 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 <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.
>
>
> 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.
>

You're raising a very good point here.  However, I think that this is
a very hard question to answer, because there is no single profile of
OpenStack user.  We should aim to be as agnostic and as open as
possible.  The reason why is because I imagine infrastructure as a
core component, a building block to help organization reach their
internal goals.

At the end of the day, I'd even go as far as comparing to to
electricity.  The end-user can vary from many different ways, but if
we do our best at delivering it in a predictable and standardized way,
we'll see people take it and create many different things out of it in
ways that we would never imagine people would be using OpenStack.

The idea of an open standard, if properly architected, can generate
amazing ideas that are beyond what we could ever imagine (see: edge
computing and OpenStack's role in that).

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