Hi Zane, A few comments in line.
Thanks and Best Regards, Ildikó (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 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
