I slightly disagree. I think there are 3 sets of users not 2... Operators, Tenant Users, and Tenant Application Developers.
Tenant Application Developers develop software that the Tenant Users deploy in their tenant. Most OpenStack developers consider the latter two to always be the same person. And it has made it very difficult to use for Tenant Users that aren't Tenant Application Developers to use OpenStack. Sometimes Tenant Users are pure ops, not devops. Sometimes they are not even traditional CS folks but physicists, biologists, etc. Thanks, Kevin ________________________________ From: Fei Long Wang [feil...@catalyst.net.nz] Sent: Thursday, October 12, 2017 4:16 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [all][tc] TC Candidates: what does an OpenStack user look like? That's one of the points I mentioned in my candidacy: whom we're building the software for. As a service maintainer and upstream developer of a public cloud based on OpenStack, I would say some times we're mixing the term 'users'. The user in OpenStack world includes operators and tenant users (developers or devops using the cloud). We have done a good job to get the feedback from operators with "user" survey, operators mailing list, etc. But we don't have a good way to hear the voices from those tenant users, including developers and devops. And that's very important for the near future of OpenStack. On 13/10/17 10:34, Emilien Macchi wrote: Replying on top of Mohammed, since I like his answer and want to add some comments. On Thu, Oct 12, 2017 at 12:07 PM, Mohammed Naser <mna...@vexxhost.com><mailto:mna...@vexxhost.com> wrote: [...] 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. I agree a lot with Mohammed here. I also like to think we build OpenStack to place it at the heart of all organizations consuming infrastructure at any scale or any architecture. It can be some pieces from OpenStack or a whole set of services working together. Also like he said, providing set of API, that are well known; I would add "stable APIs" (see discussions with Glare / Glance) and ensure some "perennity" for our end-users. Having talked with some users, some folks say "OpenStack becomes boring and we like it". Pursuing the discussion, they like to have long life API support and stability in how they operate. I think at a TC level we need to make sure we can both innovate and maintain this stability at a certain level. [...] -- Cheers & Best regards, Feilong Wang (王飞龙) -------------------------------------------------------------------------- Senior Cloud Software Engineer Tel: +64-48032246 Email: flw...@catalyst.net.nz<mailto:flw...@catalyst.net.nz> Catalyst IT Limited Level 6, Catalyst House, 150 Willis Street, Wellington --------------------------------------------------------------------------
__________________________________________________________________________ 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
