<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 16, 2016 at 10:10 AM, Flavio Percoco <span dir="ltr"><<a href="mailto:flavio@redhat.com" target="_blank">flavio@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 16/05/16 00:23 -0700, Clint Byrum wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Excerpts from Nikhil Komawar's message of 2016-05-14 17:42:16 -0400:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
<br>
Lately I have been involved in discussions that have resulted in giving<br>
a wrong idea to the approach I take in operating the (Glance) team(s).<br>
While my approach is consistency, coherency and agility in getting<br>
things done (especially including the short, mid as well as long term<br>
plans), it appears that it wasn't something evident. So, I have decided<br>
to write this email so that I can collectively gather feedback and share<br>
my thoughts on the right(eous) approach.<br>
<br>
</blockquote>
<br>
I find it rather odd that you or anyone believes there is a "right"<br>
approach that would work for over 1500 active developers and 200+<br>
companies.<br>
<br>
We can definitely improve upon the aspects of what we have now, by<br>
incremental change or revolution. But I doubt we'll ever have a<br>
community that is "right" for everyone.<br>
</blockquote>
<br>
<br></span>
Right! To that let's also add we have a bunch of smaller communities within our<br>
OpenStack big tent. Each one of these teams might requires a different approach.<br>
<br>
[snip]<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
We are developing something that is usable, operationally friendly and<br>
that it's easier to contribute & maintain but, many strong influencers<br>
are missing on the most important need for OpenStack -- efficient way of<br>
communication. I think we have the tools and right approach on paper and<br>
we've mandated it in the charter too, but that's not enough to operate<br>
things. Also, many people like to work on the assumption that all the<br>
tools of communication are equivalent or useful and there are no<br>
side-effects of using them ever. I strongly disagree. Please find the<br>
reason below:<br>
<br>
</blockquote>
<br>
I'd be interested to see evidence of anyone believing something close<br>
to that, much less "many people".<br>
<br>
I do believe people don't take into account everyone's perspective and<br>
communication style when choosing how to communicate. But we can't really<br>
know all of the ways anything we do in a distributed system affects all<br>
of the parts. We can reason about it, and I think you've done a fine job<br>
of reasoning through some of the points. But you can't know, nor can I,<br>
and I don't think anyone is laboring under the illusion that they can<br>
know this.<br>
</blockquote>
<br></span>
This is a good point and I believe it may explode into several smaller<br>
discussions. I'll try to light the bomb:<br>
<br>
- We used to be a community that assumed good faith about people, proposals,<br>
 etc. Have I been genuine enough to believe this is still true? I certainly<br>
 work under this *assumption* unless I things stink really bad and even then,<br>
 I'd try to work around the issue without unecessary finger-pointing.<br>
<br>
- We've always been a multi-cultural community company-wise, tz-wise,<br>
 culturally-wise, language-wise, etc. These is super hard to coordinate and<br>
 finding a right solution for everyone is even harder. For example, depending<br>
 the communication medium you might have a bad/good impact on non-native<br>
 English speakers. Spending enough time understanding people's perspective is<br>
 critical to avoid the frustration of non-native English speakers. Asking dumb<br>
 questions that translate to "I don't get your English" when things are utterly<br>
 clear doesn't help, really.<br>
<br>
- Is picking the communication tool based on people's preferences rather than<br>
 based on the technical issue they are meant to solve the right thing to do?<br>
 I'm sorry if this is missing part of your point but I believe each one of the<br>
 tools we have are meant to ease specific communication issues for specific<br>
 cases. That is to say, I agree not all mediums are equivalent but I do think<br>
 there must be a preferred medium for "whenever you don't know where to send<br>
 $X". To me, that's the ML.<br>
<br>
<br>
[snip]<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[1] <a href="https://en.wikipedia.org/wiki/Conway's_law" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Conway's_law</a><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
* So, what can be the blocker?<br>
<br>
Nothing, but working with these assumptions is really the blocker. That<br>
is exactly why many people in their feedback say we have a "people<br>
problem" in OpenStack. But it's not really the people problem, it is the<br>
assumption problem.<br>
<br>
Assumptions are very very bad:<br>
<br>
With 'n' problems in a domain and 'm' people working on all those<br>
problems, individually, we have the assumption problem of the order of<br>
O((m*e)^n) where you can think of 'e' as the convergence factor.<br>
Convergence factor being the ability of a group to come to an agreement<br>
of the order of 'agree to agree', 'agree to disagree' (add percentages<br>
to each for more granularity). There is also another assumption (for the<br>
convergence factor) that everyone wants to work in the best interest of<br>
solving the problems in that domain.<br>
<br>
<br>
</blockquote>
<br>
rAmen brother. We can't assume to know the motivations of anyone, though<br>
we can at least decide how much to trust what people say. So if they say<br>
that they're interested in solving the problems in a domain, I certainly<br>
will give them space to prove that right or wrong.<br>
</blockquote>
<br></span>
Ok, let me see if I can put this in a way it doesn't sound bad. Bear with me.<br>
<br>
Sometimes, when it comes to keeping communications healthy/going in<br>
multi-cultural communities, it's better to have a bit of "assumption". Depending<br>
on the problem's space, topic, etc, it might be healthier to assume some things<br>
on specific points than keep poking with the same questions (structured<br>
differently) which just end up frustrating folks. I guess my point is, there's a<br>
time and space for every discussion/question. Unfortunately, I believe we don't<br>
spend enough time understanding this and we as well sometimes disagree on what's<br>
the right time/space to discuss things.<br>
<br>
Hope the above makes (some) sense. As a general thing, I prefer to assume good<br>
faith, it truly makes my life simpler.<br>
<br>
[snip]<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Also, one very important thing that I keep hearing: "I do not like<br>
that" without any other information, as an argument to disregard<br>
technical proposals. I think it is very disruptive and irrational way to<br>
express arguments. We are not buying flowers in OpenStack, we need to<br>
keep rationality in check when we express our opinions. It reduces<br>
convergence factor and increases dubiety among the developers &<br>
reviewers. Then we have a ecosystem where people do not understand why<br>
we do things the way we do it. We should not stop businesses just<br>
because someone doesn't like something, please no. Lack of rationale can<br>
actually do that.<br>
<br>
<br>
</blockquote>
<br>
+1! Qualify or quantify your objections, but please don't just give us<br>
your unfiltered opinions.<br>
</blockquote>
<br></span>
++<br>
<br>
[snip]<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As a counterpoint, I think we mostly need more understanding of our<br>
distributed nature, and to let go of the idea that we can control any<br>
of it. To anyone involved I say: Wield your influence, and measure your<br>
success, but don't expect 1500 people to do what you tell them to do,<br>
because they might just have 1500 different ideas of what you actually<br>
meant.<br>
</blockquote>
<br></span>
This! This! and again, THIS!<br>
<br>
Thank y'all,<br>
Flavio<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
@flaper87<br>
Flavio Percoco<br>
</font></span><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><div class="gmail_default" style="font-family:monospace,monospace">​Hey,</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Maybe not related, but maybe it is.  After spending the past couple of hours trying to help a customer with a Glance issue I'm a bit... well annoyed with Glance.  I'd like to chime in on this thread.  I'm honesty not entirely sure what the goal of the thread is, but honestly there's something rather important to me that I don't really seem to see being called out.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Is there any way we could stop breaking the API and it's behaviors?  Is there any way we can fix some of the issues with respect to how things work when folks configure multiple Glance repos?</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Couple of examples:</div><div class="gmail_default" style="font-family:monospace,monospace">1. switching from "is_public=true" to "visibility=public"</div><div class="gmail_default" style="font-family:monospace,monospace">        </div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_default" style="font-family:monospace,monospace">Ok, cool, I'm sure there's great reasons, but it really sucks when folks update their client and now none of their automation works any longer</div></div></blockquote><div class="gmail_extra"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">2. making virtual_size R/O</div><div class="gmail_default" style="font-family:monospace,monospace">        </div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_default" style="font-family:monospace,monospace">So for some time this was a property that folks could use to set the size of an image needed for things like volume creation, cloning etc.  At some point though it was decided "this should be read only", ok... well again all sorts of code is now broken, including code in Cinder.​  It also seems there's no way to set it, so it's always there and just Null.  It looked like I would be able to set it during image-create maybe... but then I hit number 3.</div></div></blockquote><div class="gmail_extra"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">3. broken parsing for size and virtual_size</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_default" style="font-family:monospace,monospace">I just started looking at this one and I'm not sure what happened here yet, but it seems that these inputs aren't being parsed any more and are now raising an exception due to trying to stuff a string into an int field in the json schema.</div></div></blockquote><font face="monospace, monospace"><div><font face="monospace, monospace"><br></font></div><div class="gmail_default" style="display:inline">​So I think if the project wants to move faster that's great, but please is theres any chance to value backwards compatibility just a bit more?​  I'm sure I'm going to get flamed for this email, and the likely response will be "you're doing it wrong".  I guess if I'm the only one that has these sorts of issues then alright, I deserve the flames, and maybe somebody will enlighten me on the proper ways of using Glance so I can be happier and more in tune with my Universe.</div></font><div><font face="monospace, monospace"><div class="gmail_default" style="display:inline"><br></div></font></div><div><font face="monospace, monospace"><div class="gmail_default" style="display:inline">Thanks,</div></font></div><div><font face="monospace, monospace"><div class="gmail_default" style="display:inline">John</div></font></div></div>