Open Stack

Yes please, the sooner something can be planned the better. The gap between
development and operations is growing bigger every release.


On Fri, Dec 20, 2013 at 1:46 PM, Tim Bell <Tim.Bell at cern.ch> wrote:

>
> How about we do a mid-summit user/operator boot camp (like the programs
> do, i.e. February or so) where:
>
> - we get some operators and users (i.e. those that run and those that
> consume) OpenStack together
> - we describe our pain points (as Tom would say
> curse/desk-slam/white-board)
> - we prepare a set of blueprints and corresponding representatives to
> explain them to the development community
> - we identify cross-project issues and take them to the TC
>
> My experience is that there is significant overlap between us all so it is
> not necessary to have everyone there, especially if we solicit input before
> through the ambassadors etc.
>
> Tim
>
> On 20 Dec 2013, at 07:55, Tristan Goode <tristan at aptira.com> wrote:
>
> > I guess the simplest meaning is "all those that are not committing code
> to
> > the OpenStack code base"? :D
> >
> >
> >> -----Original Message-----
> >> From: Everett Toews [mailto:everett.toews at RACKSPACE.COM]
> >> Sent: Wednesday, 18 December 2013 1:54 AM
> >> To: Tristan Goode
> >> Cc: Tom Fifield; <openstack at lists.openstack.org>
> >> Subject: Re: [Openstack] Bringing focus to the Operators and Users at
> > the next
> >> summit
> >>
> >> Hi Tristan,
> >>
> >> Can you clarify what you meant by Users in your subject line?
> >>
> >> I took it to mean application developers (i.e. the developers writing
> > applications on
> >> top of OpenStack) and possibly application operators (i.e. the operators
> > deploying
> >> applications on top of OpenStack). They seem to have gotten lost in the
> > discussion
> >> here.
> >>
> >> Ultimately, OpenStack is being built for them. As I believe was your
> > original intent,
> >> they need a voice in such a forum too. I realize that even less
> > application developers
> >> are likely to attend the summit than operators.
> >>
> >> However we still need to encourage their involvement and make a place
> > for them.
> >> We also need to encourage operators to gather feedback from their
> > application
> >> developers about their experiences developer on top of OpenStack as I'm
> > sure the
> >> operations folk get an occasional ear full from them. ;)
> >>
> >> Thanks,
> >> Everett
> >>
> >> P.S. Just to be clear...because we have a lot of overlapping
> > terminology.
> >>
> >> application developers = the developers writing applications on top of
> > OpenStack
> >> application operators = the operators deploying applications on top of
> > OpenStack
> >> [OpenStack] developers = the developers writing OpenStack [OpenStack]
> > operators
> >> = the developers deploying OpenStack
> >>
> >>
> >> On Dec 17, 2013, at 3:24 AM, Tristan Goode wrote:
> >>
> >>> Perfect stated Tom. Thank you.
> >>>
> >>>> -----Original Message-----
> >>>> From: Tom Fifield [mailto:tom at openstack.org]
> >>>> Sent: Tuesday, 17 December 2013 11:23 AM
> >>>> To: openstack at 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.gordon0 at gmail.com]
> >>>>> *Sent:* 16 December 2013 18:38
> >>>>> *To:* Tristan Goode
> >>>>> *Cc:* openstack at 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 <tristan at aptira.com
> >>>>> <mailto:tristan at 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:sean at dague.net <mailto:sean at dague.net>]
> >>>>>> Sent: Saturday, 14 December 2013 3:02 AM
> >>>>>> To: openstack at lists.openstack.org
> >>>>>   <mailto:openstack at 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.macdonald at gmail.com
> >>>>>   <mailto:kyle.macdonald at gmail.com>
> >>>>>>> <mailto:kyle.macdonald at gmail.com
> >>>> <mailto:kyle.macdonald at gmail.com>>]
> >>>>>>> *Sent:* Thursday, 12 December 2013 7:02 PM
> >>>>>>> *To:* Tristan Goode
> >>>>>>> *Cc:* openstack at lists.openstack.org
> >>>>>   <mailto:openstack at lists.openstack.org>
> >>>>>>> <mailto:openstack at lists.openstack.org
> >>>>>   <mailto:openstack at 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
> >>> <tristan at aptira.com
> >>>>>   <mailto:tristan at aptira.com>
> >>>>>>> <mailto:tristan at aptira.com <mailto:tristan at 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 at lists.openstack.org
> >>>>>   <mailto:openstack at lists.openstack.org>
> >>>>>>>   <mailto:openstack at lists.openstack.org
> >>>>>   <mailto:openstack at 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 at lists.openstack.org
> >>>>>   <mailto:openstack at 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 at lists.openstack.org
> >>>>>   <mailto:openstack at 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 at 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 at 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 at 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 at 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 at lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20131220/934115c8/attachment.html>