Hi Zane,

A few comments in line.

Thanks and Best Regards,
(IRC: ildikov)

> On 2017. Oct 13., at 21:21, Zane Bitter <zbit...@redhat.com> wrote:
> Replying to myself here, to avoid singling anyone in particular out. I want 
> to rephrase the question, because people are overwhelmingly either failing to 
> understand or refusing to answer it in the way I intended it.

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

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

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

> Not only because engineering trade-offs are a real thing, and some use cases 
> will *definitely* be excluded in order to better serve others, but because 
> the average user doesn't exist. If you design for the 'average' user then you 
> are designing for nobody, because nobody is the average user. We shouldn't be 
> designing for 'everybody' (aka nobody in particular), but for a large variety 
> of somebodies.
> As an example, look at the Keystone discussion that I linked below.
> - If you were designing Keystone for an individual user, you'd might just 
> have one account per tenant.
> - If you were designing Keystone for a team deploying semi-autonomous apps, 
> you might design a way for multiple agents to authenticate to each tenant.
> - If you were designing Keystone for 'everyone', you might have a matrix of 
> users, tenants and roles - the most generic solution, right? - and spend half 
> a decade polishing it without ever realising that individual users don't need 
> it and teams can't use it.
> One of these solutions works for both individuals and teams. The other two 
> only work for individuals. As an added bonus, one of those is also expensive 
> to develop and hard to operate. That's why we should design for someones, not 
> for 'everyone'. This is not a problem limited to Keystone - throughout 
> OpenStack we often fail to develop solutions that can actually be used by the 
> people whom we say we're building them for, IMHO.
> I'm not asking y'all to say that some group of end-users is unimportant even 
> though the question is trying to keep the bar extremely low by asking about 
> only one group. Nor am I asking y'all to say that operators are unimportant, 
> even though the question is *explicitly* *NOT* about operators.
> I'm asking if you can describe, to a modest level of detail, even one *end* 
> user persona for OpenStack that you're familiar enough with to be comfortable 
> advocating for on the TC.

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

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

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

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

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

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

> So far the answer I'm hearing mostly translates as 'no'. (Props to the folks 
> who did actually answer though!) Does anybody want to try again?
> cheers,
> Zane.
> On 12/10/17 12:51, Zane Bitter wrote:
>> In my head, I have a mental picture of who I'm building OpenStack for. When 
>> I'm making design decisions I try to think about how it will affect these 
>> hypothetical near-future users. By 'users' here I mean end-users, the actual 
>> consumers of OpenStack APIs. What will it enable them to do? What will they 
>> have to work around? I think we probably all do this, at least 
>> subconsciously. (Free tip: try doing it consciously.)
>> So my question to the TC candidates (and incumbent TC members, or anyone 
>> else, if they want to answer) is: what does the hypothetical OpenStack user 
>> that is top-of-mind in your head look like? Who are _you_ building OpenStack 
>> for?
>> There's a description of mine in this email, as an example:
>> http://lists.openstack.org/pipermail/openstack-dev/2017-October/123312.html
>> To be clear, for me at least there's only one wrong answer ("person who 
>> needs somewhere to run their IRC bouncer"). What's important in my opinion 
>> is that we have a bunch of people with *different* answers on the TC, 
>> because I think that will lead to better discussion and hopefully better 
>> decisions.
>> Discuss.
>> cheers,
>> Zane.
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-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

Reply via email to