Open Stack

On 02/06/2016 01:27 PM, Tim Bell wrote:
>
> I think it shows the evolution of OpenStack that we can now look at the end users (through user committee teams such as the API working group).
>
> For many releases, the operators have worked hard to provide a stable cloud for their users within the constraints of what can be achieved with the software.
>
> We are now able to include the end user on the basis of a stable cloud service. We should not ignore the effort this has taken to get to this point (and calling out operators who have significantly invested is unproductive).

Terribly sorry - I did not mean for that to come across as calling 
anyone out. If anything I was using examples of operators I happen to 
like a lot. I was more trying to point out that the initial set of users 
were people like Cern and Vexxhost (as you mention) - but now that we 
are in a position to consider their respective users, we should do so.

Absolutely no negative thoughts towards the operators in any way. We 
would not be here without them. From a project/developer perspective 
though, there is a difference between writing software only for the 
operators, and in writing software for both them and their users. One 
results in a cloud-construction-kit, and I'm sure we can all agree that 
we've at times skewed too much towards writing a bag of parts that one 
could use to make a cloud. I think, given the feedback and input we've 
gotten from our operators, we are in a place where making sure that we 
consider the end users is both viable and essential.

A specific example of the difference here is the original Image v2 
upload work vs. the recent work that the Glance team has done in making 
the new image upload API design. The current task oriented v2 image 
upload code is very much the result of how to enable deployers to make a 
particular set of deployment decisions but failed to take the end-user 
experience in to account. The new work that started last cycle and came 
in to shape at the Mitaka summit started with the same set of deployer 
use cases but added concern for how those different deployer decisions 
might surface to the end user.

It is for that reason that I believe that underscoring the importance of 
both classes of 'user' in our mission is essential. Both classes are 
essential to our effort, but it's easy to fall into the trap of only 
considering one or the other.

Again - massive apologies for coming across as anything other than 
glowingly positive towards the contributions from our deployers - and 
for making it seem I was calling two of them out negatively. I could not 
be filled any  more with anything other than love and respect for both 
of them, and for all the rest of the operators out there.

> Tim
>
>
>
>
>
> On 06/02/16 17:04, "Monty Taylor" <mordred at inaugust.com> wrote:
>
>> On 02/06/2016 09:58 AM, Allison Randal wrote:
>>> On 02/05/2016 08:32 AM, Sean Dague wrote:
>>>> They are statements of 'How'. They are not statements of 'What'. And
>>>> while they may be accurate most 'How' should not exist in a mission
>>>> statement. It's the same reason we don't put 'in Python' in our mission
>>>> statement. Except, they are even worse that that, because they are
>>>> filler words that are so vague as to sound important but not give anyone
>>>> in the project clarity as to what they are doing. Relevant technologies
>>>> is what exactly? And is it the same answer yesterday as today?
>>>
>>> To carry this forward a bit, the purpose of a mission statement is to
>>> outline 'What' an organization is trying to achieve, the 'How' part
>>> belongs in some other document. There has been some discussion recently
>>> on OpenStack Values, and a document outlining those would be the right
>>> place to include things like "approach development as a continuous
>>> process of evolution", "integrate with established technologies as they
>>> gain traction", and "avoid prejudice against ideas from other
>>> development communities or traditions".
>>>
>>>> """
>>>> To produce a ubiquitous Open Source Cloud Computing platform. It should
>>>> be easy to use, simple to implement, work well at all scales, be
>>>> interoperable between instances, and meet the needs of both public and
>>>> private clouds.
>>>> """
>>>
>>> +1 for clarity and conciseness.
>>>
>>> I really liked Doug's emphasis on users and operators, so I'd work that
>>> back in: "...meet the needs of users and operators of both public and
>>> private clouds".
>>
>> ++ - that was one of the main things that was missing before. The idea
>> that OpenStack users include the end-users of the clouds being run by
>> the operators rather than OpenStack's user's being the operators is an
>> important thing to call out. We've actually focused very strongly on the
>> Operator as the primary user so far, and it shows.
>>
>> I think it's worth calling out and is not just a 'how' - because the
>> shape of things would be very different if we only considered Cern and
>> Vexxhost as our users and not the transitive set of their users as well.
>>
>>
>> _______________________________________________
>> Foundation mailing list
>> Foundation at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation