Perfect stated Tom. Thank you. > -----Original Message----- > From: Tom Fifield [mailto:t...@openstack.org] > Sent: Tuesday, 17 December 2013 11:23 AM > To: openstack@lists.openstack.org > Subject: Re: [Openstack] Bringing focus to the Operators and Users at the next > summit > > On 17/12/13 02:55, Tim Bell wrote: > > > > > > Specifying something as a bug needs to determine things like 'what > > component should this be addressed in' and describing the desired > > behaviour. Many of the comments from the survey describe the pain > > points, rather than the solutions. Upgrading is difficult, no > > mechanism to auto restart VMs on other hypervisors, monitoring > > frameworks, inconsistent options in command line tools and APIs, . > > equally, missing functional gaps do not fall well into the bug system. > > > > > > > > I have received the feedback from operators when raising issues that > > they get the response 'contributions are welcome'. Running an > > openstack cloud can be non-trivial, especially the big ones, and there > > is a need to appreciate that this effort is a significant part of the > > OpenStack community effort (along with the blogs, the documentation > > updates, the summit presentations). > > > > > > > > I personally have a different proposal to Tristan (although I like > > his). my proposal is that each program should have a session dedicated > > to user/operator needs at the start. Between the UC, the volunteers > > to look at the survey comments and the user group ambassadors, we > > should be able to put together a set of pain points to be considered > > for the next release. solutions are up to the design teams. > > While I think that having such a session in each program fits well with "our" (being > "the developers'") mentality and/or schedule, I feel that it does not suit with that of > operators. > > This is because, as an operator, you typically don't just have problems or feedback > with one project. > > Looking through the survey comments, it's likely that if those kind of operators were > attending summits, they'd have to attend a high fraction of every such session. > > In addition, points of pain can often be about the integration between services, the > consistency between them, or whole-of-project issues. Like the fact our python > clients all have different import lines, or the way DNS works between Nova and > Neutron, and so on. > > > The conversation of late has been leaning towards a happy scenario where > "operators" and "developers" come together in a session and the former presents > their concerns to the latter, who promptly go away and Fix All The Things. > > To be frank, having been on the "operator" side of the fence, and participating in all > of the frequent cursing, desk-slamming, whiteboard-workarounding, nagios-alert- > spam-receiving it takes to run an OpenStack cloud ... I'm not sure we can let > "operators" loose in such a session without some kind of filter - it might put > "developers" off helping if we descent into full sysadmin rant :) But we do need to > get that feedback through somehow. > > I have full appreciation for the session that the swift team ran with the LINE guys at > Hong Kong - that was seriously awesome to hear about and we should be doing > more of it. Though, I believe some of the value came from the fact that it was an > individual user stepping through their entire requirements. Challenging the > assumptions. Quite different from a torrent of people in a room :) > > > The survey comments we've got are good, as is the plan Tim has put together to > wrangle them into a format where they perhaps can be taken to developers as bugs, > or blueprints - as Joe suggested. However, due to the nature of the survey, they are > most often brief, and surface-level. > > I believe what "getting Operators in a room" can achieve for us is providing that > same kind of feedback, but with far greater depth than can be achieved by a 200 > pixel survey box. > > A scenario I'd propose is to arrange something where we: > 1. allow the full-descent into sysadmin rant, where people feel comfortable to air > each and every grievance they've had with any part of OpenStack, recording all of > this (in a manipulable, written format minus > cursing) > 2. refuel our sysadmins with [beverage], while a small team attempts to wrangle the > mass of comment into something that can be discussed 3. bring back in the fearless > operators, then have a more structured discussion about which items are really the > big ones - and dive deeper into those so a full understanding is had of use- > cases/'whys'/'whats' > > > at the conclusion of this session, we clean it up a bit and can pass it on to our super- > awesome "developers", who probably haven't had time to make it to this multi-hour > session, but will subsequently bow in awe of all of the awesome suggestions and > people who love their work :) > > For thoroughness, this passing-to could happen at session-per-program as > suggested, or in some other asynchronous way. > > > Regards, > > > > Tom > > > > > > > > Tim > > > > > > > > *From:*Joe Gordon [mailto:joe.gord...@gmail.com] > > *Sent:* 16 December 2013 18:38 > > *To:* Tristan Goode > > *Cc:* openstack@lists.openstack.org > > *Subject:* Re: [Openstack] Bringing focus to the Operators and Users > > at the next summit > > > > > > > > > > > > > > > > On Sun, Dec 15, 2013 at 10:36 PM, Tristan Goode <tris...@aptira.com > > <mailto:tris...@aptira.com>> wrote: > > > > I'm trying to establish a feedback loop "because" we (Operators, > > Users, etc) > > need to better present our actual real world, evidence based > > Operator, User, > > > > and even other input like Sales and Marketing experiences back > > into the > > > > development teams. Much of this does and will come from the great > > work of > > the UC, the User surveys, and especially the folks that have > > volunteered to > > analyse the survey results. I'm hoping to build on the survey > > analysis and > > collaboratively and constructively focus that to present a blueprint or > > roadmap with a "whole of OpenStack" scope. We can dig deeper into > > the user > > survey feedback and break beyond the bounds of the limited format of the > > user survey to seed the discussion. For me, the most valuable session in > > Hong Kong was the discussion led by Tim of the user survey. It was > > however, > > all too short. > > > > > > > > Do you have any examples of what kind of feedback you would like to > > pass on to developers (I was unable to attend Tim's discussion of the > > user survey)? Also just playing devils advocate here, but why not use > > our bug system to provide feedback? > > > > > > > > > > > > > -----Original Message----- > > > From: Sean Dague [mailto:s...@dague.net <mailto:s...@dague.net>] > > > Sent: Saturday, 14 December 2013 3:02 AM > > > To: openstack@lists.openstack.org > > <mailto:openstack@lists.openstack.org> > > > Subject: Re: [Openstack] Bringing focus to the Operators and Users > > at the > > > next > > > summit > > > > > > So not that I don't think this is a worth while thing, because I > > think it > > > is. But instead > > > of jumping to the solution of a User Day, it might be useful to > > figure out > > > what's > > > attempting to be solved. > > > > > > Is it? > > > > > > 1) get Users together to share best practices among themselves? > > Because > > > lots of > > > people have learned things, and want to bootstrap others. > > > > > > 2) get Users and Operators together to share best practices among > > > themselves? > > > Because ... > > > > > > 3) get Vendors and Users and Operators together? Because ... > > > > > > 4) get Developers and Users and Operators together? Because .... > > > > > > I think if you start with defining the Because ... part, then the > > needed > > > parties, then > > > the odds of this being successful and useful to folks goes way up. > > It also > > > would give > > > people attending a reasonable expectation of what they are going > > to get > > > out of it. > > > > > > Because it would be a shame to set up #1, if most people thought > > they were > > > getting > > > #4 (which is basically what Lorin was proposing with his adopt a > > developer > > > idea), > > > then people being disappointed that they didn't get what they > > thought they > > > were > > > getting. > > > > > > The design summit works pretty well for the development community > > because > > > of > > > how narrowly it is scoped. So a critical mass in each of those > > rooms knows > > > when it's > > > getting off track and how to pull it back to something actionable > > at the > > > end. > > > > > > -Sean > > > > > > On 12/13/2013 06:05 AM, Tristan Goode wrote: > > > > I guess what I'm trying to say by "Users and Operators" covers > > > > carriers and telcos. By User I mean folks that consume OpenStack > > > > resources and by Operator I mean folks that supply OpenStack > > > > resources. Maybe all can be called Users but whatever one calls it, > > > > what I mean basically is Non-Developers actually working on and with > > > > OpenStack. :) > > > > > > > > > > > > > > > > Cheers > > > > > > > > Tristan > > > > > > > > > > > > > > > > *From:*Kyle MacDonald [mailto:kyle.macdon...@gmail.com > > <mailto:kyle.macdon...@gmail.com> > > > > <mailto:kyle.macdon...@gmail.com > <mailto:kyle.macdon...@gmail.com>>] > > > > *Sent:* Thursday, 12 December 2013 7:02 PM > > > > *To:* Tristan Goode > > > > *Cc:* openstack@lists.openstack.org > > <mailto:openstack@lists.openstack.org> > > > > <mailto:openstack@lists.openstack.org > > <mailto:openstack@lists.openstack.org>> > > > > *Subject:* Re: [Openstack] Bringing focus to the Operators and Users > > > > at the next summit > > > > > > > > > > > > > > > > Tristan > > > > > > > > I like this idea and agree it should be a priority. I do suggest the > > > > focus area be expanded (or a second focus day) to accommodate > > carriers > > > > and telcos and their operations needs (they are real operators). > > > > > > > > > > > > > > > > There is a ton of work being done by the leading telco's around NFV > > > > and SDN (many in emerging use cases) using OpenStack. I can very > > > > easily see "operations" being a killer issue and something that > > should > > > > be more broadly addressed. Last summit the forum for that track of > > > > discussions was by a vendor - next summit this area should be made > > > > more neutral and inclusive. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kyle > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Dec 11, 2013, at 10:55 PM, Tristan Goode <tris...@aptira.com > > <mailto:tris...@aptira.com> > > > > <mailto:tris...@aptira.com <mailto:tris...@aptira.com>>> wrote: > > > > > > > > G'day OpenStackLand, > > > > > > > > > > > > > > > > I have an idea for the next summit to put forward... > > > > > > > > > > > > > > > > Like we have the various project design summit session days > > at the > > > > summits, I think it'd be really useful to have an Operators and > > > > Users day at the very start of the next summit (and > > hopefully all of > > > > them in future if it works out). So far at the last 4 > > summits I've > > > > attended, from the users and operators point of view we've > > had a rag > > > > tag bunch of disconnected panels and 40 minute sessions that > > really > > > > don't get anywhere much and don't make it to any sort of plan or > > > > worthwhile result. This proposed "Operators and Users" day > > will be > > > > run like the design summit session days where all of us that > > have to > > > > deal with the consequences of the software development of this > > > > project sit in a room and work the issues. The goal is to > > present > > > > real world, evidence based Operator, User, and even other > > input like > > > > Sales and Marketing experiences back into the development teams. > > > > Maybe we might even have our own "Operators and Users" > > lounge too. > > > > :-P > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers > > > > > > > > Tristan > > > > > > > > > > > > > > > > _______________________________________________ > > > > Mailing list: > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > > Post to : openstack@lists.openstack.org > > <mailto:openstack@lists.openstack.org> > > > > <mailto:openstack@lists.openstack.org > > <mailto:openstack@lists.openstack.org>> > > > > Unsubscribe : > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > > > > > > > > > > > > > > _______________________________________________ > > > > Mailing list: > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > > Post to : openstack@lists.openstack.org > > <mailto:openstack@lists.openstack.org> > > > > Unsubscribe : > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > > > > > > > > > > > -- > > > Sean Dague > > > http://dague.net > > > > _______________________________________________ > > Mailing list: > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > Post to : openstack@lists.openstack.org > > <mailto:openstack@lists.openstack.org> > > Unsubscribe : > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > > > > > > > > > > _______________________________________________ > > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > Post to : openstack@lists.openstack.org > > Unsubscribe : > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > > > _______________________________________________ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
