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)   4 6 9

26 Responses

0 votes

On 12/10/17 17:51, 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?

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.

Personally I do not think there is a single "user" persona we can use.

We have users that vary from "I used to use ESXi to get a server, now I
go to https://cloud.example.com/horizon and click "Create" to "I am
deploying a Kubernetes cluster, and I need a base IaaS for network,
compute and storage."

Because of how I have spent most of my time in OpenStack, I think I tend
to be biased towards "integrators" - people writing software that needs
to be generic, to work on a lot of different OpenStack clouds (e.g.
Kubernetes OpenStack Cloud Provider, installers for products that run in
different versions of OpenStack (in cloud) or tools like Terraform /
Ansible that interact with the APIs).

There is no one size / shape fits all OpenStack topology, and that
flexibility is why I can have OpenStack run reliably on a couple of
workstations, and others can scale it to hundreds of thousands of cores.
This unfortunately makes life difficult for people who try to be
generic, or write tools that manage "OpenStack" as a thing, instead of a
style / distro / implementation of OpenStack.


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 gr_at_ham.ie (620 points)  
0 votes

Zane,

Thanks for raising the discussion. We recently discuss a lot about what's
OpenStack, what OpenStack Foundation should be. I would like to list some
discussion I involved before [1]. OpenSack affects following people and
organizations. we should consider when we make decisions.

Q1: Who benefits from OpenStack? Who are the customers, users, etc?

1st tier (direct users) : Developers, Sys Admins, DevOps, Application
owners that want IaaS/PaaS resources

2nd tier (providers) catering to 1st directly :
2a (internal) : Enterprises and IT departments
2b (external) : IaaS/PaaS Providers, SaaS Providers, Enterprises,
Operators and CSPs

3rd tier catering to 2nd tier :
3a : Distribution Vendors and OpenStack Integrators
3b : Hardware vendors

[1] https://etherpad.openstack.org/p/ocata-12questions-exercise-board

2017-10-13 0:51 GMT+08:00 Zane Bitter zbitter@redhat.com:

(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-Octo
ber/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

--
ChangBo Guo(gcb)
Community Director @EasyStack


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 ChangBo_Guo (4,540 points)   3 5
0 votes

Zane, thanks for the question.

Let me answer from the perspective of an OpenStack user (I work for
Verizon) and from a developer (both now, and in the past as part of
Tesora). OpenStack has multiple different users:

  • Deployers: People who deploy OpenStack and operate a cloud environment.

  • Product Companies: This is a broad collective of things like
    solutions providers, distribution providers; companies that don't
    operate OpenStack but write and sell software that others can operate
    in their OpenStack deployment, and are participants in the OpenStack
    community/ecosystem.

  • End Users: People who consume OpenStack services (offered by
    deployers). This is particularly important in the case of PaaS
    projects (like Trove which I work on).

To me, the first (Deployers) and the third (End Users) are top of mind
because that is who we should be building for. I work in a team that
represents these two constituencies, we operate OpenStack and consume
the services of OpenStack.

Thanks,

-amrith

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?

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 amrith.kumar_at_gmai (3,580 points)   2 3
0 votes

On Thu, Oct 12, 2017 at 5: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?

Unlike a few years ago we don't walk so much in the dark anymore.
We now know a lot of our users because:
- some are contributors to OpenStack. OpenStack developers but not only.
With
contributors to OpenStack I don't mean only code, but any kind of
contribution,
like presenting and discussing use cases at the PTG, at the forum or on
the
mailing list, providing feedback, ideas, resources and even motivation.
- some are adjacent communities that depend on or collaborate with
OpenStack.
- some answer our user survey.

So who am I building OpenStack for?

  • For OpenStack developers, since I work mostly on QA and CI
  • For the users that are closer to the OpenStack community. I don't want to
    focus
    on hypothetical users that don't care to talk to the OpenStack community.
    Consistency across projects in they way they different projects are
    built, tested,
    deployed, operated, documented and consumed is important for this type of
    users.
  • I build it to be a good software for everyone to use. I care about
    usability, good
    documentation, stable APIs, proper logging features that
    make it a good software for anyone to invest their time on.

Faithfully,

Andrea Frittoli (andreaf)

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 Andrea_Frittoli (5,920 points)   1 2 3
0 votes

I used to be able to say "my OpenStack background is in Operations" but
that isn't strictly true anymore. I've now spent the majority of my time
doing what is considered 'developer' work. One thing is for certain though,
I have never stopped building OpenStack for what I see as the "hypothetical
OpenStack user".

The majority of these users in my experince are actually small-to-medium
businesses. While the large companies of the world certainly drive alot of
OpenStack, the users that I see are much smaller than that. Small 5-10 node
clusters. That is who I am building OpenStack for. That happens to also be
the group that I am in personally, as thats what I run at my house.

Most of my focus is on lowering the bar to use services to give these
small-to-medium businesses the least amount of work to do to gain access to
almost everything OpenStack has to offer with a very small operational
overhead for the team. My personal experince with this is currently it can
take a small team months to get a working openstack deployment, and then
simply maintaining that deployment will consume the rest of thier time.
This leads to OpenStack deployments that are years out of date on an island
that has no real upgrade path anymore and a general sense that "OpenStack
is bad" internally. I am building OpenStack for users so that this stops
happening.

Thanks,
SamYaple

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?

There's a description of mine in this email, as an example:
http://lists.openstack.org/pipermail/openstack-dev/2017-Octo
ber/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 Sam_Yaple (3,560 points)   3 3
0 votes

Replying to myself here, to avoid singling anyone in particular out. I
want to rephrase the question, because people are overwhelmingly either
failing to understand or refusing to answer it in the way I intended it.

Most of the candidates are essentially saying that the answer is 'everyone'.

I'm glad that we have such a bunch of next-level geniuses running for
the TC that they are able to analyse the needs of all 7 billion people
and evaluate every decision they make against all of them in real time.
Me, I'm just an ordinary guy who can only hold a few things in his head
at once, so I just try to focus on those and collaborate with people who
have different perspectives to make sure that a range of needs are
covered. This is kind of the founding principle of the Open Source
(note: not Free Software) movement, actually. None of us is as smart as
all of us (present company excepted, apparently). So it's good, but
somewhat surprising that y'all are still here, given that you would be
guaranteed insta-billionaires if you went out and started a proprietary
software company.

All sarcasm aside though, 'everyone' is a BS non-answer. It's the
politician's answer.

Not only because engineering trade-offs are a real thing, and some use
cases will definitely be excluded in order to better serve others, but
because the average user doesn't exist. If you design for the 'average'
user then you are designing for nobody, because nobody is the average
user. We shouldn't be designing for 'everybody' (aka nobody in
particular), but for a large variety of somebodies.

As an example, look at the Keystone discussion that I linked below.
- If you were designing Keystone for an individual user, you'd might
just have one account per tenant.
- If you were designing Keystone for a team deploying semi-autonomous
apps, you might design a way for multiple agents to authenticate to each
tenant.
- If you were designing Keystone for 'everyone', you might have a matrix
of users, tenants and roles - the most generic solution, right? - and
spend half a decade polishing it without ever realising that individual
users don't need it and teams can't use it.

One of these solutions works for both individuals and teams. The other
two only work for individuals. As an added bonus, one of those is also
expensive to develop and hard to operate. That's why we should design
for someones, not for 'everyone'. This is not a problem limited to
Keystone - throughout OpenStack we often fail to develop solutions that
can actually be used by the people whom we say we're building them for,
IMHO.

I'm not asking y'all to say that some group of end-users is unimportant
even though the question is trying to keep the bar extremely low by
asking about only one group. Nor am I asking y'all to say that operators
are unimportant, even though the question is explicitly NOT about
operators.

I'm asking if you can describe, to a modest level of detail, even one
end user persona for OpenStack that you're familiar enough with to be
comfortable advocating for on the TC.

So far the answer I'm hearing mostly translates as 'no'. (Props to the
folks who did actually answer though!) Does anybody want to try again?

cheers,
Zane.

On 12/10/17 12:51, Zane Bitter wrote:
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
responded Oct 13, 2017 by Zane_Bitter (21,640 points)   4 6 9
0 votes

Interesting, now I like this thread more. Back to the original question
"what does an OpenStack user look like?", I'd like to translate it as
"what does a cloud user look like?". Unless we want to limit "OpenStack"
as a software for VPS service. IMHO, the cloud user is developers, who
can use the services provided by the cloud platform to fully automate
their services/products. But unfortunately, we're still far away from
that, especially given Zaqar's adoption is still low :(

On 14/10/17 08:21, Zane Bitter wrote:
Replying to myself here, to avoid singling anyone in particular out. I
want to rephrase the question, because people are overwhelmingly
either failing to understand or refusing to answer it in the way I
intended it.

Most of the candidates are essentially saying that the answer is
'everyone'.

I'm glad that we have such a bunch of next-level geniuses running for
the TC that they are able to analyse the needs of all 7 billion people
and evaluate every decision they make against all of them in real
time. Me, I'm just an ordinary guy who can only hold a few things in
his head at once, so I just try to focus on those and collaborate with
people who have different perspectives to make sure that a range of
needs are covered. This is kind of the founding principle of the Open
Source (note: not Free Software) movement, actually. None of us is as
smart as all of us (present company excepted, apparently). So it's
good, but somewhat surprising that y'all are still here, given that
you would be guaranteed insta-billionaires if you went out and started
a proprietary software company.

All sarcasm aside though, 'everyone' is a BS non-answer. It's the
politician's answer.

Not only because engineering trade-offs are a real thing, and some use
cases will definitely be excluded in order to better serve others,
but because the average user doesn't exist. If you design for the
'average' user then you are designing for nobody, because nobody is
the average user. We shouldn't be designing for 'everybody' (aka
nobody in particular), but for a large variety of somebodies.

As an example, look at the Keystone discussion that I linked below.
- If you were designing Keystone for an individual user, you'd might
just have one account per tenant.
- If you were designing Keystone for a team deploying semi-autonomous
apps, you might design a way for multiple agents to authenticate to
each tenant.
- If you were designing Keystone for 'everyone', you might have a
matrix of users, tenants and roles - the most generic solution, right?
- and spend half a decade polishing it without ever realising that
individual users don't need it and teams can't use it.

One of these solutions works for both individuals and teams. The other
two only work for individuals. As an added bonus, one of those is also
expensive to develop and hard to operate. That's why we should design
for someones, not for 'everyone'. This is not a problem limited to
Keystone - throughout OpenStack we often fail to develop solutions
that can actually be used by the people whom we say we're building
them for, IMHO.

I'm not asking y'all to say that some group of end-users is
unimportant even though the question is trying to keep the bar
extremely low by asking about only one group. Nor am I asking y'all to
say that operators are unimportant, even though the question is
explicitly NOT about operators.

I'm asking if you can describe, to a modest level of detail, even one
end user persona for OpenStack that you're familiar enough with to
be comfortable advocating for on the TC.

So far the answer I'm hearing mostly translates as 'no'. (Props to the
folks who did actually answer though!) Does anybody want to try again?

cheers,
Zane.

On 12/10/17 12:51, Zane Bitter wrote:

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

--
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 Oct 13, 2017, at 2:21 PM, Zane Bitter zbitter@redhat.com wrote:

All sarcasm aside though, 'everyone' is a BS non-answer. It's the politician's answer.

Not only because engineering trade-offs are a real thing, and some use cases will definitely be excluded in order to better serve others, but because the average user doesn't exist. If you design for the 'average' user then you are designing for nobody, because nobody is the average user. We shouldn't be designing for 'everybody' (aka nobody in particular), but for a large variety of somebodies.

I wish all candidates, not just TC candidates, got follow-up questions like this. Bravo, Zane!

-- Ed Leafe


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 Ed_Leafe (11,720 points)   1 3 6
0 votes

Hi Zane,

A few comments in line.

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

On 2017. Oct 13., at 21:21, Zane Bitter zbitter@redhat.com wrote:

Replying to myself here, to avoid singling anyone in particular out. I want to rephrase the question, because people are overwhelmingly either failing to understand or refusing to answer it in the way I intended it.

The great thing about this community that it consists of hundreds of individuals with their own experiences, expertise and view points. This also means that you will get interpretations of and answers to your question that reflect those which also helps with observing the problem space from multiple aspects to ensure that we come up with a good solution together by the end. This includes reiterating on the problem as well as it is often hard to express it for the first try to include all the aspects that’s required for others to interpret it the same way.

Most of the candidates are essentially saying that the answer is 'everyone'.

I'm glad that we have such a bunch of next-level geniuses running for the TC that they are able to analyse the needs of all 7 billion people and evaluate every decision they make against all of them in real time. Me, I'm just an ordinary guy who can only hold a few things in his head at once, so I just try to focus on those and collaborate with people who have different perspectives to make sure that a range of needs are covered. This is kind of the founding principle of the Open Source (note: not Free Software) movement, actually. None of us is as smart as all of us (present company excepted, apparently). So it's good, but somewhat surprising that y'all are still here, given that you would be guaranteed insta-billionaires if you went out and started a proprietary software company.

All sarcasm aside though, 'everyone' is a BS non-answer. It's the politician's answer.

All sarcasm aside, it’s a generic answer to a generic question. On the other hand ‘everyone' also represents a mindset of thinking about the aspect that someone will use your feature when you design the API to it, which should be a starting point and not the failing/ending point of the discussion.

Not only because engineering trade-offs are a real thing, and some use cases will definitely be excluded in order to better serve others, but because the average user doesn't exist. If you design for the 'average' user then you are designing for nobody, because nobody is the average user. We shouldn't be designing for 'everybody' (aka nobody in particular), but for a large variety of somebodies.

As an example, look at the Keystone discussion that I linked below.
- If you were designing Keystone for an individual user, you'd might just have one account per tenant.
- If you were designing Keystone for a team deploying semi-autonomous apps, you might design a way for multiple agents to authenticate to each tenant.
- If you were designing Keystone for 'everyone', you might have a matrix of users, tenants and roles - the most generic solution, right? - and spend half a decade polishing it without ever realising that individual users don't need it and teams can't use it.

One of these solutions works for both individuals and teams. The other two only work for individuals. As an added bonus, one of those is also expensive to develop and hard to operate. That's why we should design for someones, not for 'everyone'. This is not a problem limited to Keystone - throughout OpenStack we often fail to develop solutions that can actually be used by the people whom we say we're building them for, IMHO.

I'm not asking y'all to say that some group of end-users is unimportant even though the question is trying to keep the bar extremely low by asking about only one group. Nor am I asking y'all to say that operators are unimportant, even though the question is explicitly NOT about operators.

I'm asking if you can describe, to a modest level of detail, even one end user persona for OpenStack that you're familiar enough with to be comfortable advocating for on the TC.

To answer your more specific question, let me pick a Telecom operator to advocate for. Please don’t get mislead by the word ‘operator’ here, it is the term what the industry uses in that sector and they are representing one group of our users.

A Telecom operator has various requirements and challenges when it comes to cloud and open source and especially the two together. They are by definition looking for a solution that follows standards and guidelines defined by various Standards Development Organizations (SDO’s), which already puts a challenge on the API design and the people also who do the design and development activities. Especially in an open source environment, where let’s face it, we usually don’t really care however there are exceptions.

They are also looking for a cloud solution that fits their traditional and many times legacy needs, which means on-boarding Telecom applications and different Virtual Network Functions (VNF’s) on top of the IaaS layer that is not designed to be cloud native but rather moved into a virtual machine from the physical hardware. We all know that is from evil, but we also need to accept that re-implementing all those applications as a preparation activity for moving into a cloud environment is not realistic, therefore we need to understand how we can best support their transformation process.

They also have more complex needs when it comes to networking then a regular user in other parts of the industry or even the average, ‘everyone’, person. They would like to use different protocols like MLPS or BGP, they need more flexibility than a Layer 2 domain or would like to use technologies like Vector Packet Processing (VPP) when it comes to switching and routing and they would like to plug-in their choice of an SDN controller and leverage the full functionality that it provides in their OpenStack environment.

And most importantly even today they need help with expressing their use cases, needs and requirements due to the vocabulary they are using with the acronyms I tried to resolve in the previous paragraphs. Where having an open minded community is very important so we can help and guide them on how to ask the specific question to get the answer they expect.

However I would like to still note that when it comes to a solution to a particular problem or use case and we defined the functionality we still need to keep in mind that in some cases a human being will use it even if he/she work for a Telecom operator. The design of the API needs to be user friendly on the functionality level but also ergonomic when it comes to naming, defining options or designing a dashboard that’s easy to use and understand.

So far the answer I'm hearing mostly translates as 'no'. (Props to the folks who did actually answer though!) Does anybody want to try again?

cheers,
Zane.

On 12/10/17 12:51, Zane Bitter wrote:

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

Excerpts from Zane Bitter's message of 2017-10-13 15:21:14 -0400:

Replying to myself here, to avoid singling anyone in particular out. I
want to rephrase the question, because people are overwhelmingly either
failing to understand or refusing to answer it in the way I intended it.

Most of the candidates are essentially saying that the answer is 'everyone'.

I'm glad that we have such a bunch of next-level geniuses running for
the TC that they are able to analyse the needs of all 7 billion people
and evaluate every decision they make against all of them in real time.
Me, I'm just an ordinary guy who can only hold a few things in his head
at once, so I just try to focus on those and collaborate with people who
have different perspectives to make sure that a range of needs are
covered. This is kind of the founding principle of the Open Source
(note: not Free Software) movement, actually. None of us is as smart as
all of us (present company excepted, apparently). So it's good, but
somewhat surprising that y'all are still here, given that you would be
guaranteed insta-billionaires if you went out and started a proprietary
software company.

All sarcasm aside though, 'everyone' is a BS non-answer. It's the
politician's answer.

Blaming the respondents for answering a imprecisely worded question
in a way other than it was intended? We can do better.

Your original question "Who are you building OpenStack for?" was
much more vague than the rephrasing below that specifically asks
about advocacy. Even the rewritten question can be answered
legitimately using several different personas by people with a bit
of experience. I have worked at a public cloud provider and two
distributors with a wide range of customers, and I use OpenStack
clouds myself. I hope that all of that background feeds into my
contributions.

Not only because engineering trade-offs are a real thing, and some use
cases will definitely be excluded in order to better serve others, but
because the average user doesn't exist. If you design for the 'average'
user then you are designing for nobody, because nobody is the average
user. We shouldn't be designing for 'everybody' (aka nobody in
particular), but for a large variety of somebodies.

As an example, look at the Keystone discussion that I linked below.
- If you were designing Keystone for an individual user, you'd might
just have one account per tenant.
- If you were designing Keystone for a team deploying semi-autonomous
apps, you might design a way for multiple agents to authenticate to each
tenant.
- If you were designing Keystone for 'everyone', you might have a matrix
of users, tenants and roles - the most generic solution, right? - and
spend half a decade polishing it without ever realising that individual
users don't need it and teams can't use it.

Or you might conclude that the real problem isn't in the identity
service data model, but in the services that don't yet have an
operation to transfer ownership of resources when a user is
deactivated.

One of these solutions works for both individuals and teams. The other
two only work for individuals. As an added bonus, one of those is also
expensive to develop and hard to operate. That's why we should design
for someones, not for 'everyone'. This is not a problem limited to
Keystone - throughout OpenStack we often fail to develop solutions that
can actually be used by the people whom we say we're building them for,
IMHO.

I'm not asking y'all to say that some group of end-users is unimportant
even though the question is trying to keep the bar extremely low by
asking about only one group. Nor am I asking y'all to say that operators
are unimportant, even though the question is explicitly NOT about
operators.

I'm asking if you can describe, to a modest level of detail, even one
end user persona for OpenStack that you're familiar enough with to be
comfortable advocating for on the TC.

So far the answer I'm hearing mostly translates as 'no'. (Props to the
folks who did actually answer though!) Does anybody want to try again?

We have, so far, maintained an air of civility during "campaign season".
Let's try to stick to that, please.

Doug

cheers,
Zane.

On 12/10/17 12:51, Zane Bitter wrote:

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
responded Oct 14, 2017 by Doug_Hellmann (87,520 points)   3 4 9
...