On Aug 27, 2014, at 5:27 PM, Doug Hellmann <d...@doughellmann.com> wrote:

> 
> On Aug 27, 2014, at 2:54 PM, Sean Dague <s...@dague.net> wrote:
> 
>> Note: thread intentionally broken, this is really a different topic.
>> 
>> On 08/27/2014 02:30 PM, Doug Hellmann wrote:>
>>> On Aug 27, 2014, at 1:30 PM, Chris Dent <chd...@redhat.com> wrote:
>>> 
>>>> On Wed, 27 Aug 2014, Doug Hellmann wrote:
>>>> 
>>>>> I have found it immensely helpful, for example, to have a written set
>>>>> of the steps involved in creating a new library, from importing the
>>>>> git repo all the way through to making it available to other projects.
>>>>> Without those instructions, it would have been much harder to split up
>>>>> the work. The team would have had to train each other by word of
>>>>> mouth, and we would have had constant issues with inconsistent
>>>>> approaches triggering different failures. The time we spent building
>>>>> and verifying the instructions has paid off to the extent that we even
>>>>> had one developer not on the core team handle a graduation for us.
>>>> 
>>>> +many more for the relatively simple act of just writing stuff down
>>> 
>>> "Write it down.” is my theme for Kilo.
>> 
>> I definitely get the sentiment. "Write it down" is also hard when you
>> are talking about things that do change around quite a bit. OpenStack as
>> a whole sees 250 - 500 changes a week, so the interaction pattern moves
>> around enough that it's really easy to have *very* stale information
>> written down. Stale information is even more dangerous than no
>> information some times, as it takes people down very wrong paths.
>> 
>> I think we break down on communication when we get into a conversation
>> of "I want to learn gate debugging" because I don't quite know what that
>> means, or where the starting point of understanding is. So those
>> intentions are well meaning, but tend to stall. The reality was there
>> was no road map for those of us that dive in, it's just understanding
>> how OpenStack holds together as a whole and where some of the high risk
>> parts are. And a lot of that comes with days staring at code and logs
>> until patterns emerge.
>> 
>> Maybe if we can get smaller more targeted questions, we can help folks
>> better? I'm personally a big fan of answering the targeted questions
>> because then I also know that the time spent exposing that information
>> was directly useful.
>> 
>> I'm more than happy to mentor folks. But I just end up finding the "I
>> want to learn" at the generic level something that's hard to grasp onto
>> or figure out how we turn it into action. I'd love to hear more ideas
>> from folks about ways we might do that better.
> 
> You and a few others have developed an expertise in this important skill. I 
> am so far away from that level of expertise that I don’t know the questions 
> to ask. More often than not I start with the console log, find something that 
> looks significant, spend an hour or so tracking it down, and then have 
> someone tell me that it is a red herring and the issue is really some other 
> thing that they figured out very quickly by looking at a file I never got to.
> 
> I guess what I’m looking for is some help with the patterns. What made you 
> think to look in one log file versus another? Some of these jobs save a 
> zillion little files, which ones are actually useful? What tools are you 
> using to correlate log entries across all of those files? Are you doing it by 
> hand? Is logstash useful for that, or is that more useful for finding 
> multiple occurrences of the same issue?
> 
> I realize there’s not a way to write a how-to that will live forever. Maybe 
> one way to deal with that is to write up the research done on bugs soon after 
> they are solved, and publish that to the mailing list. Even the retrospective 
> view is useful because we can all learn from it without having to live 
> through it. The mailing list is a fairly ephemeral medium, and something very 
> old in the archives is understood to have a good chance of being out of date 
> so we don’t have to keep adding disclaimers.

Matt’s blog post [1] is an example of the sort of thing I think would be 
helpful. Obviously one post isn’t going to make the reader an expert, but over 
time a few of these will impart some useful knowledge.

Doug

[1] 
http://blog.kortar.org/?p=52&draftsforfriends=cTT3WsXqsH66eEt6uoi9rQaL2vGc8Vde

> 
> Doug
> 
>> 
>>      -Sean
>> 
>> -- 
>> Sean Dague
>> http://dague.net
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to