Open Stack

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.

cheers,
Zane.