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

[Adam Lawson]

"Right, so we all agree that what we *don't* want is TC candidates saying
"I'm here to represent the interests of user community X against those of
evil user community Y", all of the X users voting for X candidates and not
Y candidates, and then the elected X members voting to block anything that
only benefits Y, and vice-versa."

Interestingly (and without wanting to derail the overall subject) but this
is precisely what is done by a certain individuals seeking a seat on the
board of directors. And the funny thing is that while the board of
directors is not about representing one bloc of geography, campaigning on
that issue is very effective. The tactic is gratuitous but I guess some
people highly prioritize board membership as an achievement rather than a
service to the community.

/soapbox

//adam

On Oct 18, 2017 11:11 AM, "Zane Bitter"  wrote:

> On 17/10/17 14:16, Doug Hellmann wrote:
>
>> Excerpts from Zane Bitter's message of 2017-10-16 18:10:20 -0400:
>>
>>> On 14/10/17 11:47, Doug Hellmann wrote:
>>>
 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.

>>>
>>> Yes, that's great. I think most people would agree that there's a
>>> threshold somewhere between 'several' and 'infinity' beyond which we've
>>> crossed over into platitudes though.
>>>
>>
>> Maybe. On the other hand, TC members aren't elected to represent
>> specific constituencies, so there's something to be said for taking each
>> case as it comes and considering the users impacted by that case.
>>
>
> Right, so we all agree that what we *don't* want is TC candidates saying
> "I'm here to represent the interests of user community X against those of
> evil user community Y", all of the X users voting for X candidates and not
> Y candidates, and then the elected X members voting to block anything that
> only benefits Y, and vice-versa. Obviously every step of that process is an
> unmitigated disaster.
>
> So of course each TC member should consider the all of the users impacted
> by any decision on a case-by-case basis. However, even if we're only
> thinking purely about reactive decision-making, it's still often not easy
> to know *which* users are impacted by any particular decision unless you
> have someone in the room who has a deep familiarity with that use case.
> That's why I'd like to see candidates saying something like "I spend a lot
> of time thinking about user community X and if anything came up that
> affected their use cases I'm pretty sure I'd spot it". So that I can vote
> to optimise the diversity of Xs represented, where X might be e.g. web
> developers, devops teams, scientific researchers, vSphere migrants,
> multi-cloud users, NFV, the next Facebook/Twitter/Snapchat/Netflix,
> mobile app or IoT backend developers, kubernetes users, or something I
> haven't even thought of.
>
> Possible tangent: I've always enjoyed this article (about the Sapir-Whorf
> hypothesis): http://www.nytimes.com/2010/08/29/magazine/29language-t.html
> tl;dr Anybody can think about anything, regardless of the language they
> speak (i.e. Sapir-Whorf is wrong). But there are things in every language
> that you can't *not* think about, and they're different for different
> languages.
>
> I want to maximise the set of things the TC, collectively, can't not think
> about.
>
> Suffice to say that nobody should take my example here as anything more
>>> than a rationale for the importance of user-centred design.
>>>
>>
>> How much "design" do you think the TC is doing as a governance group?
>>
>
> It varies between different levels of abstraction.
>
> At the code level, none.
>
> At the level of setting the broad technical direction of the project, not
> as much as I'd like. But y'all did pass https://governance.openstack.o
> rg/tc/resolutions/20170317-cloud-applications-mission.html for me
> (thanks!) so definitely not nothing. There are other less-directly-relevant
> examples like adding etcd to the list of base services too.
>
> At the level of deciding what projects OpenStack consists of, and
> therefore what sort of cloud you can build with it (that is to say, what
> you can _use_ it for)... that's _entirely_ within the TC's purview.
>
> At an even higher level of abstraction, deciding what OpenStack is and
> what the Foundation is for, the TC has at least a significant role in
> giving input to the board and delegated authority to make decisions in some
> areas. Notably, discussions at this level often occur face-to-face at
> TC-only events, or at board meetings where non-members aren't entitled to
> speak, and which few people can and even fewer people do attend. (I've
> given up a few Sunday afternoons before OpenStack Summits 

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

[Zane Bitter]

On 17/10/17 14:16, Doug Hellmann wrote:

Excerpts from Zane Bitter's message of 2017-10-16 18:10:20 -0400:

On 14/10/17 11:47, Doug Hellmann wrote:

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.


Yes, that's great. I think most people would agree that there's a
threshold somewhere between 'several' and 'infinity' beyond which we've
crossed over into platitudes though.


Maybe. On the other hand, TC members aren't elected to represent
specific constituencies, so there's something to be said for taking each
case as it comes and considering the users impacted by that case.


Right, so we all agree that what we *don't* want is TC candidates saying 
"I'm here to represent the interests of user community X against those 
of evil user community Y", all of the X users voting for X candidates 
and not Y candidates, and then the elected X members voting to block 
anything that only benefits Y, and vice-versa. Obviously every step of 
that process is an unmitigated disaster.


So of course each TC member should consider the all of the users 
impacted by any decision on a case-by-case basis. However, even if we're 
only thinking purely about reactive decision-making, it's still often 
not easy to know *which* users are impacted by any particular decision 
unless you have someone in the room who has a deep familiarity with that 
use case. That's why I'd like to see candidates saying something like "I 
spend a lot of time thinking about user community X and if anything came 
up that affected their use cases I'm pretty sure I'd spot it". So that I 
can vote to optimise the diversity of Xs represented, where X might be 
e.g. web developers, devops teams, scientific researchers, vSphere 
migrants, multi-cloud users, NFV, the next 
Facebook/Twitter/Snapchat/Netflix, mobile app or IoT backend developers, 
kubernetes users, or something I haven't even thought of.


Possible tangent: I've always enjoyed this article (about the 
Sapir-Whorf hypothesis): 
http://www.nytimes.com/2010/08/29/magazine/29language-t.html
tl;dr Anybody can think about anything, regardless of the language they 
speak (i.e. Sapir-Whorf is wrong). But there are things in every 
language that you can't *not* think about, and they're different for 
different languages.


I want to maximise the set of things the TC, collectively, can't not 
think about.



Suffice to say that nobody should take my example here as anything more
than a rationale for the importance of user-centred design.


How much "design" do you think the TC is doing as a governance group?


It varies between different levels of abstraction.

At the code level, none.

At the level of setting the broad technical direction of the project, 
not as much as I'd like. But y'all did pass 
https://governance.openstack.org/tc/resolutions/20170317-cloud-applications-mission.html 
for me (thanks!) so definitely not nothing. There are other 
less-directly-relevant examples like adding etcd to the list of base 
services too.


At the level of deciding what projects OpenStack consists of, and 
therefore what sort of cloud you can build with it (that is to say, what 
you can _use_ it for)... that's _entirely_ within the TC's purview.


At an even higher level of abstraction, deciding what OpenStack is and 
what the Foundation is for, the TC has at least a significant role in 
giving input to the board and delegated authority to make decisions in 
some areas. Notably, discussions at this level often occur face-to-face 
at TC-only events, or at board meetings where non-members aren't 
entitled to speak, and which few people can and even fewer people do 
attend. (I've given up a few Sunday afternoons before OpenStack Summits 
that I could have spent exploring exciting foreign cities to watch the 
joint TC-Board meeting, but the probability of my manager giving my 
budget for a special trip to a board meeting to just listen is exactly 
zero.) I'm not complaining about that, but it does make it important 
that TC members themselves are capable of representing a wide range of 
interests - it's not always the case that expertise will be pulled in 
from the wider community automatically.


Anyway, those are all design problems in my view.

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

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

[Doug Hellmann]

Excerpts from Zane Bitter's message of 2017-10-16 18:10:20 -0400:
> On 14/10/17 11:47, Doug Hellmann wrote:
> > 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.
> 
> I honestly didn't feel it was an imprecisely worded question - I 
> included an example, and carefully defined things such as "By 'users' 
> here I mean end-users, the actual consumers of OpenStack APIs". 
> Nevertheless, I have no problem admitting that I was wrong. Allowing for 
> that possibility was the reason I rephrased the question.
> 
> > Your original question "Who are _you_ building OpenStack for?" was
> > much more vague than the rephrasing below that specifically asks
> > about advocacy.
> 
> I agree, reading your and Ildiko's and James's responses it's now clear 
> to me that this was the root of the problem. It was too easy to 
> interpret this as the entirety of the question, rather than just a glib 
> way of summing up the actual question immediately preceding it, the 
> paragraph of exposition before that, and the example that followed. I 
> regret muddying the waters by tacking it on the end.
> 
> > 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.
> 
> Yes, that's great. I think most people would agree that there's a 
> threshold somewhere between 'several' and 'infinity' beyond which we've 
> crossed over into platitudes though.

Maybe. On the other hand, TC members aren't elected to represent
specific constituencies, so there's something to be said for taking each
case as it comes and considering the users impacted by that case.

> 
> >> 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.
> 
> Sure, although note that Keystone itself would have to be one of those 
> services - you'd have to be able to transfer ownership of trusts for it 
> to work.

Sure. I think changing ownership is a new concept across the board.

> 
> Suffice to say that nobody should take my example here as anything more 
> than a rationale for the importance of user-centred design.[1] 

How much "design" do you think the TC is doing as a 

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

[Zane Bitter]

On 14/10/17 11:47, Doug Hellmann wrote:

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.


I honestly didn't feel it was an imprecisely worded question - I 
included an example, and carefully defined things such as "By 'users' 
here I mean end-users, the actual consumers of OpenStack APIs". 
Nevertheless, I have no problem admitting that I was wrong. Allowing for 
that possibility was the reason I rephrased the question.



Your original question "Who are _you_ building OpenStack for?" was
much more vague than the rephrasing below that specifically asks
about advocacy.


I agree, reading your and Ildiko's and James's responses it's now clear 
to me that this was the root of the problem. It was too easy to 
interpret this as the entirety of the question, rather than just a glib 
way of summing up the actual question immediately preceding it, the 
paragraph of exposition before that, and the example that followed. I 
regret muddying the waters by tacking it on the end.



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.


Yes, that's great. I think most people would agree that there's a 
threshold somewhere between 'several' and 'infinity' beyond which we've 
crossed over into platitudes though.



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.


Sure, although note that Keystone itself would have to be one of those 
services - you'd have to be able to transfer ownership of trusts for it 
to work.


Suffice to say that nobody should take my example here as anything more 
than a rationale for the importance of user-centred design.[1] 
Specifically, nobody should take it, or anything else that fits in 3 
sentences, as a prescription for the successful design of an identity 
management service - a topic which is vast, complex, intricate, and at 
times highly unintuitive.


cheers,
Zane.

[1] https://en.wikipedia.org/wiki/User-centered_design

__
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

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

[James Bottomley]

On Thu, 2017-10-12 at 12:51 -0400, Zane Bitter wrote:
> 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 fundamental misconception in the way you just asked the
question: in any open source project the question "who am I building
this for?" and "who is my target end user?" aren't necessarily the
same.

The honest answer to "who am I building this open source project for?"
should always be "me".  There's nothing magical about this: all open
source/free software projects are driven by developer enthusiasm.  If
the reason you're in the project isn't something inside yourself (like
fascination with some aspect of the code or need to use it personally)
then you're unlikely to be a good contributor.  The principle is
actually universal: having been an engineering manager in industry I
know that if someone is only in the project for the paycheque then I
need to replace them ASAP with someone who's actually fascinated by
some aspect of the project because the productivity of the latter will
be way higher.  It's the most annoying aspect of Engineering Project
Management: engineers aren't fungible resources, they have enthusiasms
that have to be engaged.

There's a corollary to this that allows you to test the health of your
project: "If I weren't being paid to do this, would I still do it?".
 The majority answer for a healthy project should be "yes".  There's no
industrial counterpart here because if they don't pay you, you don't
get access to the code base.

The question of who is the end user is usually either "me" because you
have a use for the project or more likely "I don't know" because you
care mostly about the engineering aspects.  That's not to say that some
contributors can't get fascinated by user problems because it does
happen; however, it's not usually the majority.

User base tends to come about because of goal alignment: once a project
has a reasonable number of committers, feature addition becomes more a
matter of negotiation, but these negotiations tend to produce better
code and a set of common goals (the aligned goals of the contributors).
 Industrial contributors are attracted if some of the project goals
align reasonably with business goals and it looks like contribution
from the industry partner could achieve further alignment.  One of the
key goals of Industry is to get paid by consumers, so the Industrial
contributors tend to bring along the users (Again Industry does this by
canvassing end user requirements and seeing what the alignment with the
project is and whether it could be improved.  They don't do this for
"community" they do it because they make more money if the alignment is
better).  By the way, this pragmatic goal alignment without necessarily
sharing any philosophical belief in "code freedom" is the main
difference between open source and free software.

That's not to say every successful open source/free software project
has to have a large user base.  The Linux Desktop would be a classic
example here: excluding mobile, it's a complete failure in terms of
world domination of user base.  However, in terms of "built by geeks
for geeks" it's very much alive and healthy ... just look at the OS
running on laptops at any Linux conference, for instance.

James


__
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

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

[Colleen Murphy]

On Fri, Oct 13, 2017 at 9:21 PM, 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-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.
>>
>
> What an interesting thread this has been. Thanks to Doug for speaking up -
it's unfair to pose a very general question, say "there are no wrong
answers", and then call everyone out for getting the answer wrong.

It's still a good question, though, since it was designed to expose the
fact that most of us are building clouds for operators, not 

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

[Doug Hellmann]

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 

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

[Ildiko Vancsa]

Hi Zane,

A few comments in line.

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


> On 2017. Oct 13., at 21: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.

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 

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

[Ed Leafe]

On Oct 13, 2017, at 2:21 PM, Zane Bitter  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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[feilong]

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 

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

[Zane Bitter]

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

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

[Sam Yaple]

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

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

[Andrea Frittoli]

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


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

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

[Amrith Kumar]

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

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

[ChangBo Guo]

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 :

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

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

[Graham Hayes]

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



signature.asc
Description: OpenPGP digital signature
__
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

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

[Ildiko Vancsa]

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

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

[Paul Belanger]

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

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

[Mohammed Naser]

On Thu, Oct 12, 2017 at 8:15 PM, Zane Bitter  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  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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Zane Bitter]

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

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

[Fei Long Wang]

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 [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> 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
> 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

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

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

[Zane Bitter]

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

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

[Fox, Kevin M]

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

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

[Fei Long Wang]

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

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

[Emilien Macchi]

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

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

[Mohammed Naser]

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

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

[Zane Bitter]

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