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
