Open Stack

On 08/14/2014 10:54 AM, Matt Riedemann wrote:
>
>
> On 8/14/2014 3:47 AM, Daniel P. Berrange wrote:
>> On Thu, Aug 14, 2014 at 09:24:36AM +1000, Michael Still wrote:
>>> On Thu, Aug 14, 2014 at 3:09 AM, Dan Smith <dms at danplanet.com> wrote:
>>>>> I'm not questioning the value of f2f - I'm questioning the idea of
>>>>> doing f2f meetings sooo many times a year. OpenStack is very much
>>>>> the outlier here among open source projects - the vast majority of
>>>>> projects get along very well with much less f2f time and a far
>>>>> smaller % of their contributors attend those f2f meetings that do
>>>>> happen. So I really do question what is missing from OpenStack's
>>>>> community interaction that makes us believe that having 4 f2f
>>>>> meetings a year is critical to our success.
>>>>
>>>> How many is too many? So far, I have found the midcycles to be 
>>>> extremely
>>>> productive -- productive in a way that we don't see at the summits, 
>>>> and
>>>> I think other attendees agree. Obviously if budgets start limiting 
>>>> them,
>>>> then we'll have to deal with it, but I don't want to stop meeting
>>>> preemptively.
>>>
>>> I agree they're very productive. Let's pick on the nova v3 API case as
>>> an example... We had failed as a community to reach a consensus using
>>> our existing discussion mechanisms (hundreds of emails, at least three
>>> specs, phone calls between the various parties, et cetera), yet at the
>>> summit and then a midcycle meetup we managed to nail down an agreement
>>> on a very contentious and complicated topic.
>>
>> We thought we had agreement on v3 API after Atlanta f2f summit and
>> after Hong Kong f2f too. So I wouldn't neccessarily say that we
>> needed another f2f meeting to resolve that, but rather than this is
>> a very complex topic that takes a long time to resolve no matter
>> how we discuss it and the discussions had just happened to reach
>> a natural conclusion this time around. But lets see if this agreement
>> actually sticks this time....
>>
>>> I can see the argument that travel cost is an issue, but I think its
>>> also not a very strong argument. We have companies spending millions
>>> of dollars on OpenStack -- surely spending a relatively small amount
>>> on travel to keep the development team as efficient as possible isn't
>>> a big deal? I wouldn't be at all surprised if the financial costs of
>>> the v3 API debate (staff time mainly) were much higher than the travel
>>> costs of those involved in the summit and midcycle discussions which
>>> sorted it out.
>>
>> I think the travel cost really is a big issue. Due to the number of
>> people who had to travel to the many mid-cycle meetups, a good number
>> of people I work with no longer have the ability to go to the Paris
>> design summit. This is going to make it harder for them to feel a
>> proper engaged part of our community. I can only see this situation
>> get worse over time if greater emphasis is placed on attending the
>> mid-cycle meetups.
>>
>>> Travelling to places to talk to people isn't a great solution, but it
>>> is the most effective one we've found so far. We should continue to
>>> experiment with other options, but until we find something that works
>>> as well as meetups, I think we need to keep having them.
>>>
>>>> IMHO, the reasons to cut back would be:
>>>>
>>>> - People leaving with a "well, that was useless..." feeling
>>>> - Not enough people able to travel to make it worthwhile
>>>>
>>>> So far, neither of those have been outcomes of the midcycles we've 
>>>> had,
>>>> so I think we're doing okay.
>>>>
>>>> The design summits are structured differently, where we see a lot more
>>>> diverse attendance because of the colocation with the user summit. It
>>>> doesn't lend itself well to long and in-depth discussions about 
>>>> specific
>>>> things, but it's very useful for what it gives us in the way of
>>>> exposure. We could try to have less of that at the summit and more
>>>> midcycle-ish time, but I think it's unlikely to achieve the same level
>>>> of usefulness in that environment.
>>>>
>>>> Specifically, the lack of colocation with too many other projects has
>>>> been a benefit. This time, Mark and Maru where there from Neutron. 
>>>> Last
>>>> time, Mark from Neutron and the other Mark from Glance were there. If
>>>> they were having meetups in other rooms (like at summit) they wouldn't
>>>> have been there exposed to discussions that didn't seem like they'd 
>>>> have
>>>> a component for their participation, but did after all (re: nova and
>>>> glance and who should own flavors).
>>>
>>> I agree. The ability to focus on the issues that were blocking nova
>>> was very important. That's hard to do at a design summit when there is
>>> so much happening at the same time.
>>
>> Maybe we should change the way we structure the design summit to
>> improve that. If there are critical issues blocking nova, it feels
>> like it is better to be able to discuss and resolve as much as possible
>> at the start of the dev cycle rather than in the middle of the dev
>> cycle because I feel that means we are causing ourselves pain during
>> milestone 1/2.
>
> Just speaking from experience, I attended the Icehouse meetup before 
> my first summit (Juno in ATL) and the design summit sessions for Juno 
> were a big disappointment after the meetup sessions, basically because 
> of the time constraints. The meetups are nice since there is time to 
> really hash over a topic and you're not rushed, whereas with the 
> design summit sessions it felt like we'd be half way through the 
> allotted time before we really started talking about anything of use 
> and then shortly after that you'd be hearing "5 minutes left", and I 
> felt like very few of the design sessions were actually useful, or 
> things we've worked on in Juno, or at least high-priority/impact 
> things (v3 API being an exception there, that was a useful session).
I have seen what you describe, and have also been at sessions where 
there is active discussion for 15 minutes, all issues are resolved, and 
there is still a bunch of time left. The issue you cited could be 
addressed by accepting fewer topics and giving double or triple slots to 
topics that are important and expected to need a lot of discussion. The 
design summits are very useful for cores and newcomers alike and I would 
hate to see that fragmented by people deciding to not go to summits.

Also, while I was glad I was able to attend the neutron mid-cycle, IMO 
it is a reach to say that all those companies spending $$$ on OpenStack 
would happily accept their travel budgets being close to doubled. Many 
globally distributed companies have all the same issues internally and 
have found hangout/teleconference type solutions not quite as good as 
face to face but much better than just email and irc.

  -David



>
> Maybe that's just me, but honestly if I had to choose which to go to 
> between a meetup and the summit, I'd pick the mid-cycle meetup.
>
> I don't think any travel should be *required* to be a member of the 
> core team, but I do think the meetups are more productive than the 
> summit, so I'm just agreeing with danpb here that it seems the design 
> sessions should be restructured somehow.
>
>>
>>>>> As I explain in the rest of my email below I'm not advocating
>>>>> getting rid of mid-cycle events entirely. I'm suggesting that
>>>>> we can attain a reasonable % of the benefits of f2f meetings
>>>>> by doing more formal virtual meetups and so be more efficient
>>>>> and inclusive overall.
>>>>
>>>> I'd love to see more high-bandwidth mechanisms used to have 
>>>> discussions
>>>> in between f2f meetings. In fact, one of the outcomes of this last
>>>> midcycle was that we should have one about APIv3 with the folks that
>>>> couldn't attend for other reasons. It came up specifically because we
>>>> made more progress in ninety minutes than we had in the previous eight
>>>> months (yes, even with a design summit in the middle of that).
>>>>
>>>> Expecting cores to be at these sorts of things seems pretty reasonable
>>>> to me, given the usefulness (and gravity) of the discussions we've 
>>>> been
>>>> having so far. Companies with more cores will have to send more or 
>>>> make
>>>> some hard decisions, but I don't want to cut back on the meetings 
>>>> until
>>>> their value becomes unjustified.
>>>
>>> I think this gets to the crux of the original email -- we are
>>> increasingly needing cores to understand the overall direction nova is
>>> going. You could argue for example that our failure to land many high
>>> priority blueprints in Juno is because cores aren't acting in
>>> coordinated a manner. So, we're attempting to come up with ways to
>>> improve coordination.
>>
>> Having mid-cycle meetups where only a subset of cores will attend 
>> doesn't
>> feel like an great way to improve the coordination between /all/ cores.
>>
>> Regards,
>> Daniel
>>
>