settingsLogin | Registersettings

[openstack-dev] [all][tc] TC Candidates: what does an OpenStack user look like?

0 votes

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

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.

cheers,
Zane.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Oct 18, 2017 in openstack-dev by Zane_Bitter (21,640 points)   3 5 9

26 Responses

0 votes

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@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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 12, 2017 by Mohammed_Naser (3,860 points)   1 3
0 votes

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 mnaser@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.

[...]
--
Emilien Macchi


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 12, 2017 by emilien_at_redhat.co (36,940 points)   2 5 8
0 votes

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 mnaser@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: flwang@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 12, 2017 by Fei_Long_Wang (4,460 points)   3 3
0 votes

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 [feilong@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 mnaser@vexxhost.commnaser@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: flwang@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 12, 2017 by Fox,_Kevin_M (29,360 points)   1 3 4
0 votes

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@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 13, 2017 by Zane_Bitter (21,640 points)   3 5 9
0 votes

We're on the same page. I was just not sure if I should go to far away
given we're even mixing all the 'users' now. And I think it's related to
the other point I mentioned in my candidacy: Constellation. User could
be defined by user case, which is the constellation here composed by
different services.

On 13/10/17 12:43, Fox, Kevin M wrote:
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 [feilong@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 mnaser@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: flwang@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Cheers & Best regards,
Feilong Wang (王飞龙)


Senior Cloud Software Engineer
Tel: +64-48032246
Email: flwang@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 13, 2017 by Fei_Long_Wang (4,460 points)   3 3
0 votes

On 12/10/17 19:43, Fox, Kevin M wrote:
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.

I hoped you would chime in with this point, because it's a great example
of the kind of thing that is not top-of-mind for me unless prompted.
That's why we need diverse voices who are thinking about different users
to come together and apply their collective experience.

It goes without saying that you have my vote if you ever want to run for
the TC ;)

cheers,
Zane.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 13, 2017 by Zane_Bitter (21,640 points)   3 5 9
0 votes

On Thu, Oct 12, 2017 at 8:15 PM, Zane Bitter zbitter@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@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@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 13, 2017 by Mohammed_Naser (3,860 points)   1 3
0 votes

On Thu, Oct 12, 2017 at 12:51:10PM -0400, Zane Bitter 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?

For me, my 'OpenStack user' is the developers of the OpenStack project. While a
developer might not be directly consuming the OpenStack API, the tooling they
use to contribute to OpenStack does. This is the main reason why I enjoy working
on the Project Infrastructure team.

It provides a feedback loop back into the project, to take real world issues
with OpenStack (eg: scaling, multi-cloud, python clients, APIs, you name it) and
hopefully make themself back into the hands of developers. It doesn't always
work out that way, but is still a great process to have.

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.

cheers,
Zane.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 13, 2017 by pabelanger_at_redhat (6,560 points)   1 1 2
0 votes

Hi All,

Let me reflect to the question in the subject first where I would like to stick to the word ‘user’ and keep my answer simple. I think an OpenStack user is/looks like as an average person.

To give a longer explanation, in my view when we are designing our user-facing API’s we need to keep in mind that we don’t know who is going to use them BUT let that be an application developer, a researcher or even a person who seeks for a place for their IRC-bouncer, so anyone who interacts with them, should be equally able to do so without a PhD degree, the history of the development process of a particular functionality, without the need to read the code first and so forth.

The above statement is applicable in any given period of time, meaning to provide a consistent and consistently pleasant and functional environment from release to release.

To answer the follow up question on 'Who are you building OpenStack for?’ I would mention operators as well, who need to deal with deploying, configuring, troubleshooting and managing the daily operational tasks regardless of the location, nature and size of an OpenStack deployment.

I think as in many cases when this topic comes up it’s more of a social than a technical challenge.

To continue on that aspect, when I’m involved in a feature design and development activity I like to imagine that I will be the one, who will operate the service and use the newly introduced functionality. It helps much to avoid decisions that sacrifices the operator and user experience in favor of faster and easier design and implementation. I also like to encourage the fellow community members to do the same and also to play with what we are producing to get the first hand experience.

If the intention is there and we have the right mindset the technology will help us in the technical implications like automation, maintainability, complexity, documentation and so forth.

Thanks and Best Regards,
Ildikó
(IRC: ildikov)

On 2017. Oct 12., at 18:51, Zane Bitter zbitter@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?

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.

cheers,
Zane.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 13, 2017 by Ildiko_Vancsa (2,220 points)   1 2
...