Open Stack

Indeed, making a presentation at a summit isn't the best way to start a
dialog, so that's exactly why I've proposed the focus.



Perhaps what might have happened back in Portland is the TC takes the User
Survey results (even from the presentation), asks questions (as you have
below) if necessary, and presented some sort of status, plan or result back
to the community, possibly in Hong Kong. Perhaps we can kick start that
this time with a pair of sessions as Tim proposed that I'm certain will
expand well beyond the survey results.



Refreshing to hear that some issues are being looked at though.



Cheers

Tristan



*From:* jagman4000 at gmail.com [mailto:jagman4000 at gmail.com] *On Behalf Of *Joe
Gordon
*Sent:* Saturday, 28 December 2013 10:30 AM
*To:* Tristan Goode
*Cc:* openstack at lists.openstack.org
*Subject:* Re: [Openstack] Bringing focus to the Operators and Users at the
next summit







On Fri, Dec 27, 2013 at 8:04 AM, Tristan Goode <tristan at aptira.com> wrote:

I'm not at all discounting the DevOps conversation as ideally a continuous
cyclic dialog. There may well be wonderful continuous communication in Dev
land for OpenStack right now, but in Ops land it's certainly not middle or
start or end or anywhere, it's almost non-existent. This breakdown in the
DevOps cycle is evident in the fact that the feedback from the "OpenStack
User Survey" presented at the most recent summit was essentially unchanged
from the feedback of the previous summit and echoed much of the same
sentiment, so it's clear developers are not completing the DevOps cycle
here even when this information was presented in advance last time. The
attitude seems to be largely that if you have an issue then rather than
"complaining about it" you should write more code to fix the issue i.e. ops
should become dev so dev can remain doing what they like.



Until now, I have actually never seen a clear list of what operators said
in the user survey (were they presented to this mailing list or even better
the dev mailing list?). Making a presentation at the summit is hardly the
best way to start a dialog with developers.



But that aside, you brought up a interesting point that the developers are
not working on the list of issues gathered from the last user survey, I
don't think that's correct.  Based on the user survey results [0], here is
what we are doing and (to the best of my knowledge) and what next steps we
can take to address the comments raised:



User Survey Feedback:

* Simplify installation and configuration process

* Rolling migrations with N-1 compatibility

* Documentation-archive old content, end-user guide, problem guide, ...

* Security such as SSL options everywhere

* Horizon lacks latest feature support, admin functionality and more
attractive theme

* High availability out-of-the-box for OpenStack components and VM restart

* Active Directory integration





Simplify installation and configuration process: We now have an official
Deployment program (TripleO [1]) that should help address this.



Rolling migrations with N-1 compatibility:  I can only speak for nova, we
are trying to support this but it is hard and takes time. Although TripleO
is aiming at doing continuous deployment and doesn't require N-1
compatibility, rolling upgrades is also an essential item in the TripleO
Story.



Documentation-archive old content, end-user guide, problem guide:  I am not
sure what this is asking for exactly, but given more specific feedback I am
sure the great folks working on the docs team can help address these
concerns.



Security such as SSL options everywhere:  SSL isn't something we
necessarily want to bake directly into OpenStack, there are tools we would
rather use instead of rewriting SSL support directly, for example keystone
has a great document explaining how to set up SSL support using apache
HTTPD [2]. SSL everywhere is also an important piece for TripleO, so we
hope to have SSL support in OpenStack's official deployment program.



Horizon lacks latest feature support, admin functionality and more
attractive theme: I am not the right person to comment on Horizon, I don't
follow its development closely enough. But lacking latest feature support
may be a hard issue to address. As for admin functionality and a more
attractive theme, I imagine the Horizon team would be happy to have
conversations in these specific issues.



High availability out-of-the-box for OpenStack components and VM restart: I
am not sure what VM restart means, but HA is an important item for TripleO



Active Directory integration: I am not sure what this means exactly, but
this sounds like a blueprint to discuss with the keystone team.





In short, we, the developers, are aware of most of these issues and many of
them stem from the fact that OpenStack has never had an official deployment
story, so until now the story of how to run SSL, was simply use a reverse
proxy with SSL support. But that never was a great answer. WIth TripleO the
answer is, use TripleO.





best,

Joe



[0] The best list I found of the user survey results is slides 13 on
http://www.openstack.org/summit/portland-2013/session-videos/presentation/openstack-user-committee-update-and-survey-results



[1] https://wiki.openstack.org/wiki/TripleO



[2] http://docs.openstack.org/developer/keystone/apache-httpd.html









I'm trying to get user feedback solidly and right up front into the summit
because that's the only practical place to do it, for exactly the same
reason the design sessions are done at the summit. I'm not saying it's the
start, middle or end of the user feedback cycle, it's just a part but it's
as important part as the design session is to the development process. Not
only does trying to push this out to some other time and venue send a
message to customers who might want to participate, the sure to be less
attendance would dilute the input of Ops into the DevOps cycle and
prejudice those of us that can't afford to send people to more events than
the summits.



Cheers

Tristan







*From:* jagman4000 at gmail.com [mailto:jagman4000 at gmail.com] *On Behalf Of *Joe
Gordon
*Sent:* Saturday, 28 December 2013 12:37 AM
*To:* Tristan Goode
*Cc:* Mark Collier; openstack at lists.openstack.org


*Subject:* Re: [Openstack] Bringing focus to the Operators and Users at the
next summit




On Dec 27, 2013 4:24 AM, "Tristan Goode" <tristan at aptira.com> wrote:
>
> I'm having trouble seeing these great points of insight here other than
it seems to indicate that the design summit format could be improved.
Distilling this down to "We developers are all too busy at the summit, why
don’t you users go get your own thing" suggests that perhaps it's time for
a review of the summit format.
>

I think that's missing a key point, there is much more to this then
evaluating the summit format. The summit is the middle of a long
development dialog not the beginning or the end. Getting more operator
feedback to the developers shouldn't just happen at the summits, it should
be a continuous process just like openstack planning and development. So we
need some way for operators and developers to have a continuous dialog.
Developers communicate today on: IRC, email and launchpad and lastly in
person twice a year at the design summit.

>
>
> After all it does say "users" and "developers" on the summit logo.
>
>
>
>
>
>
>
> From: Mark Collier [mailto:mark at collierclan.net]
> Sent: Tuesday, 24 December 2013 12:30 AM
> To: Sean Dague
>
> Cc: openstack at lists.openstack.org
> Subject: Re: [Openstack] Bringing focus to the Operators and Users at the
next summit
>
>
>
> Thanks Sean. You and Thierry have made great points on this thread that I
think give people more insight into the process and timing required to
really impact the releases.
>
> I've fallen into the trap many times of thinking we can solve any problem
in the world during the 10 days a year we are all together, but in the end
its only 10 days. No matter how you organize them, they don't any get
longer.
>
> So +1 for some activities well before the summit to gather input. I think
Tim's suggestion makes a ton of sense.
>
> IMHO we should also avoid the trap of thinking that for gatherings to be
valuable "everyone has to be there". That's what leads back to thinking the
summit weeks are the answer to everything. As Tim said, it's quite likely
operators are experiencing a lot of the same pain points, so what is needed
is critical mass and action, not every known user in one room
(unrealistic). Perhaps with some online components where operators that
couldn't make a meetup can weigh in (and give a weighted priority to a
list?)
>
> On Dec 23, 2013 6:35 AM, "Sean Dague" <sean at dague.net> wrote:
>>
>> On 12/22/2013 12:49 PM, Rob_Hirschfeld at Dell.com wrote:
>> > I’d like to repeat a suggestion at the Design Summit wrap up – it’s a
>> > bit different, so patience…
>> >
>> >
>> >
>> > My suggestion was to insert a day “break” into the four day Design
>> > Summit for users/operations.  Effectively, we’d have a four day design
>> > summit with Monday+Tuesday  - break for user/ops conf –
>> > Thursday+Friday.  This would allow the developers and PTLs to join in
>> > the conference parts of the summit without needed a distinct event.
>> > The regular non-design conference could be held Tuesday-Thursday so
>> > there’s a specific overlap day when 100% of the community would be
together.
>> >
>> >
>> >
>> > I felt like this allows ideas from the summit to be socialized with
>> > users/operator before we commit to them.  I also felt that it makes the
>> > developers more accessible.  Finally, it creates a break/reflection
from
>> > the intensity of the design.
>> >
>> >
>> >
>> > To recap, 4 day design, 3 day user/ops conference spanning 5 days.
>>
>> Honestly I'd be pretty -1 on that idea. There is a certain momentum that
>> builds inside the design summit sessions that 2 hard context switches
>> like that would really hurt. If you've ever spent time in the Nova track
>> you can see this in spades.
>>
>> I think one of the missing things for folks that don't spend all their
>> time in Design Summit is realizing that DS is really the *middle* of the
>> conversation, not that start of one. I actually think this is where
>> folks new to design summit tend to flail a little be in their sessions.
>> My goals for design summit, and my tracks, were set weeks in advance,
>> and there was very little new here, it was mostly about working through
>> the sticky details on things we largely were already working on, and
>> exposing some of that work to a wider audience which drags in new
>> volunteers. So the User / Ops day at Summit is far too late to impact
>> that release cycle.
>>
>> That interaction needs to come 3+ weeks before Design Summit to be
>> effective on that cycle. Because if it's later than that, it's just too
>> much to digest at a point where the plates are already overflowing. The
>> key developers are already about 200% booked at Summits at this point,
>> which is actually why *more* OpenStack PTLs spoke at LinuxCon NA this
>> year than at OpenStack Summit HK. For instance, I only wandered out side
>> of Design Summit twice, when I was on stage. And I didn't even get a
>> chance to go to any of the public parties, as I was booked every single
>> night at summit - weeks in advance.
>>
>> So I think that all those folks are pretty open to getting more engaged
>> with Users / Ops (I know I am), but the existing Summit structure isn't
>> going to allow that. Making people 250% booked at Summit isn't going to
>> really be a successful way to handle this.
>>
>> I'm far more positive on something mid cycle, preferably at other
>> conferences that we expected there to be OpenStack folks at to begin
with.
>>
>>         -Sean
>>
>> --
>> Sean Dague
>> Samsung Research America
>> sean at dague.net / sean.dague at samsung.com
>> http://dague.net
>>
>>
>> _______________________________________________
>> 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/20131228/f91865de/attachment.html>