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. > 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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev