[openstack-dev] [OpenStack][Dev] Changes coming to Product WG & Enterprise WG

[Barrett, Carol L]

After 35+ yrs in the Technology Industry, I have decided it's time for a 
change. I will be retiring from Intel on February 2nd.

OpenStack has been a highlight of my career and I owe much of that to you all. 
It's been a pleasure knowing and working with you.

Yih Leong Sun (aka Leong) will be taking on the Leadership role for the 
Enterprise WG and the co-leadership role of the Product Work Group, along with 
Shamail Tahir. You will see other folks taking on additional roles as part of 
my overall transition plan. I know you will help them in their new roles.

Best wishes for your continued success - I'll be cheering for OpenStack from 
the bleachers!

Carol Barrett


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [docs][upgrades] time to add official docs for upgrading services?

[Barrett, Carol L]

Yes, I think it’s time to create a specific guide for this. It’s a topic of 
high interest for Operators (current and future) and helping them to understand 
how to plan their deployment for upgradability (ideally non-disruptive 
upgrades) would be very valuable.
Carol

From: Steve Martinelli [mailto:s.martine...@gmail.com]
Sent: Thursday, November 17, 2016 5:37 PM
To: OpenStack Development Mailing List (not for usage questions) 
; openstack-d...@lists.openstack.org
Subject: [openstack-dev] [docs][upgrades] time to add official docs for 
upgrading services?

In the keystone docs we have notes about how to upgrade between releases [1], 
so does the nova team [2].

Is it time we create an official guides to [3] for this subject?

[1] http://docs.openstack.org/developer/keystone/upgrading.html
[2] http://docs.openstack.org/developer/nova/upgrade.html
[3] http://docs.openstack.org/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [UX] Results Presentation: Managing OpenStack Quotas within Production Environments

[Barrett, Carol L]

Danielle – I think this is good, but if you are not getting the level of 
participation you want…or commitment to follow-on actions, I would suggest you 
adopt a “go to them” strategy.

Thanks
Carol

From: Danielle Mundle [mailto:danielle.m.mun...@gmail.com]
Sent: Wednesday, September 21, 2016 7:42 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [UX] Results Presentation: Managing OpenStack Quotas 
within Production Environments

The OpenStack UX team will be giving a results presentation from a series of 
interviews intended to understand how operators manage quotas at scale as well 
as the pain points associated with that process.  The study was conducted by 
Danielle (IRC: uxdanielle) and included operators from CERN, Pacific Northwest 
National Laboratory, Workday, Intel and Universidade Federal de Campina Grande.

The presentation begins in ~20 minutes. WebEx information to join the session 
can be found at the top of the UX wiki page: 
https://wiki.openstack.org/wiki/UX#Results_Presentation:_Managing_OpenStack_Quotas_within_Production_Environments

Thanks for supporting UX research in the community!
--Danielle

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla][ptl] Self non-nomination for Kolla PTL for Ocata cycle

[Barrett, Carol L]

Steve - You did a great job leading the effort & appreciate your work on 
building a leadership pipeline for the project.
Best wishes
Carol

Sent from my iPhone

On Sep 12, 2016, at 12:09 PM, Steven Dake (stdake) 
mailto:std...@cisco.com>> wrote:

To the OpenStack Community,

Consider this email my self non-nomination for PTL of Kolla for
the coming Ocata release.  I let the team know in our IRC team meeting
several months ago I was passing the on baton at the conclusion of Newton,
but I thought the broader OpenStack community would appreciate the information.

I am super proud of what our tiny struggling community produced starting
3 years ago with only 3 people to the strongly emergent system that is Kolla
with over 467 total contributors [1] since inception and closing in on 5,000
commits today.

In my opinion, the Kolla community is well on its way to conquering the last
great challenge OpenStack faces: Making operational deployment management (ODM)
of OpenStack cloud platforms straight-forward, easy, and most importantly
cost effective for the long term management of OpenStack.

The original objective the Kolla community set out to accomplish, deploying
OpenStack in containers at 100 node scale has been achieved as proven by this
review [2].  In these 12 scenarios, we were able to deploy with 3
controllers, 100 compute nodes, and 20 storage nodes using Ceph for all
storage and run rally as well as tempest against the deployment.

Kolla is _No_Longer_a_Toy_ and _has_not_been_ since Liberty 1.1.0.

I have developed a strong leadership pipeline and expect several candidates
to self-nominate.  I wish all of them the best in the future PTL elections.

Finally, I would like to thank all of the folks that have supported Kolla’s
objectives.  If I listed the folks individually this email would be far too
long, but you know who you are :) Thank you for placing trust in my judgement.

It has been a pleasure to serve as your leader.

Regards
-steak

[1] http://stackalytics.com/report/contribution/kolla-group/2000
[2] https://review.openstack.org/#/c/352101/

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"

[Barrett, Carol L]

-Original Message-
From: Sean Dague [mailto:s...@dague.net] 
Sent: Wednesday, September 07, 2016 9:05 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] Timeframe for future elections & "Release 
stewards"

On 09/07/2016 11:43 AM, Thierry Carrez wrote:
> Hi everyone,
> 
> As you probably know by now, starting with the Boston event in 2017, 
> the Summit will happen further away from the release day and more 
> around the middle of the next development cycle. You can find more 
> info on the rationale for that at [1] and [2] if interested, this is 
> not the topic of this email.
> 
> One interesting side-effect is that since the timing of the election 
> period (for PTL and TC positions) is defined in the TC charter[3] 
> relative to the *Summit*, it means that (unless we change this) we'll 
> now run elections to renew PTL and TC positions in the middle of the 
> cycle. Crazy, right ? That's what I first thought. But after 
> discussing it with various people, this is not as crazy as it sounds.
> 
> First, the current election timing is not perfect -- we change PTLs in 
> the middle of the design summit prep, with old PTLs making Design 
> Summit space requests that will affect their successor. It's not as if 
> there was a perfect timing for doing elections.
> 
> Second, release cycles are longer than 6 months. They actually start a 
> few months before actual development starts, with discussions on next 
> cycle priorities and Design Summit prep. They continue a few months 
> after release, with critical stable branch backports and communication 
> about landed features. So they are one year-long, overlapping cycles 
> (like explained on the diagram at [4]). With that in mind, the PTL/TC 
> election actually would happen just before the start of the start of 
> the requirements-gathering pre-development phase of the next 
> development cycle, which makes a lot of sense.
> 
> Now, the main drawback of holding elections in the middle of a 
> development cycle is that you don't want to introduce a discontinuity 
> in leadership in that development cycle. To mitigate that, we propose 
> the introduction of a new role, the "release steward", which would be 
> attached to the release cycle. That person (who may or may not double 
> as
> PTL) would be responsible for a complete release cycle on a given 
> project team, from requirements gathering phase to post-release 
> bugfix-backport phase. A sort of per-cycle release liaison on steroids.
> 
> Since development cycles overlap, there would be two active release 
> stewards at all times. This would help with the awkward situation 
> where the PTL ends up having to think about the next cycle and prepare 
> the Design Summit (or PTG) while still being knee-deep juggling with 
> feature freeze exceptions, getting the current release out of the 
> door, and coordinating early critical fixes stable backports. Those 
> two jobs could be held by two different people.
> 
> Now, some teams (especially those doing intermediary releases) may 
> want to use the same super-human to handle everything (PTL, release 
> steward,
> release+1 steward), and some others might use two or three humans to
> spread the load. That's up to them. But once designated by the 
> newly-elected PTL, the release steward would be responsible for the 
> full release cycle and would not be displaced by the next PTL 6 months later.
> One year being a long time, if a steward needs to step down, the 
> currently-active PTL would appoint someone else to finish the job.
> 
> With this new concept I think we can get the best of both worlds, and 
> keep the election period as currently defined in the charter (rather 
> than having to change it). The PTLs we will elect in the coming weeks 
> won't be renewed before April, 2017 -- while Pike development will 
> start in February.
> 
> I know this can all be a bit confusing, so feel free to reach out to 
> me with questions on this.
> 
> [1] http://www.openstack.org/ptg
> [2] http://www.openstack.org/ptg/ptgfaq/
> [3]
> http://governance.openstack.org/reference/charter.html#election-for-pt
> l-seats
> [4]
> http://www.openstack.org/themes/openstack/images/summit-ptg-timeline-r
> evised.png
> 

> I think another option would be to run the PTL election early, but just don't 
> have the turn over happen until the master release opens up. The current 
> transition period is > > > 
> actually quite short as noted by the comments around how design summit 
> planning happens. Having the PTL-next elected half way through the cycle, but 
> having PTL current > 
> still > own landing the current release actually provides a lot more 
> transition time.
>
>   -Sean

I had a similar thought to Sean's, with a few changes. Why not have a PTL own 
the release from start to finish, with the PTL for the next release getting 
elected as above. In this model, it would probably be advisable (or a 
guideline) that a PTL not run for 2 cycle

Re: [openstack-dev] [all] Proposal: Architecture Working Group

[Barrett, Carol L]

> On Jun 21, 2016, at 2:56 AM, Thierry Carrez  wrote:
> 
> Chris Dent wrote:
>> On Mon, 20 Jun 2016, Doug Wiegley wrote:
>>> On Jun 21, 2016, at 2:19 PM, Carol Barrett  
>>> wrote:
>>> So, it sounds like you've just described the job of the TC. And they 
>>> have so far refused to define OpenStack, leading to a series of 
>>> derivative decisions that seem ... inconsistent over time.
>> 
>> Thanks for writing down what I was thinking. I agree that OpenStack 
>> needs some architectural vision, direction, leadership, call it what 
>> you will. Every time I've voted for the _Technical_ Committee that 
>> leadership is what I've wanted my vote to be creating.
> 
> The TC is a representative body which is elected to make top-down decisions 
> on OpenStack. However, as much as our community loves the idea of "technical 
> leadership" and "vision", they hate the top-down decisions that come with it 
> (especially when that top-down decision doesn't go their way). They prefer 
> bottom-up consensus.
> 
> So I'd argue that you need both. You need the TC whenever a hard call has to 
> be made, but in order to minimize the number of those hard calls (and favor 
> consensus building) you also need working groups to build a bottom-up 
> reasonable way forward.

>>This reads very strange to me, as I'd expect a group of technical leaders to 
>>both make hard calls *and* to be able to build consensus on overall direction 
>>and vision. They're >>two sides of the same coin. What is it about our 
>>process that means the TC can't build consensus on direction, but can only 
>>impose its will? I expect you didn't mean it to >>sound that way, though. Is 
>>the workload too high on the bookkeeping to prevent the vision building? Are 
>>we too afraid of the implications of defining 'what is openstack?', >>and 
>>what it might mean to existing projects and the community? I'd think that in 
>>the long-run, it'd prevent seemingly unrelated topics from seeming to go 
>>sideways so >>often, and prevent a lot of these "hard calls".

+1. Making decisions is an element of being a leader. As a community, I believe 
we need this role filled.

>>But, I'm also on the fringe that is very ready to call the "big tent" a 
>>failed experiment in attempting to avoid hard calls, too.

> 
>> It may be that an architecture working group can provide some 
>> guidance that people will find useful. Against the odds I think those 
>> of us in the API-WG have actually managed to have a positive 
>> influence. We've not shaken things down to the foundations from which 
>> a great a glorious future may be born -- a lot of compromises have 
>> been made and not everybody wants to play along -- but things are 
>> going in the right direction, for some people, in some projects.
>> Maybe a similar thing can happen with architecture.
> 
> That is my hope. I see the API WG and the Architecture WG as groups of 
> experts in specific domains preparing recommendations and long-term plans. 
> They don't have authority to force them onto projects. Ideally projects adopt 
> them because they see them as the right way to do things.
> 
> And for the very few things that the TC deems necessary for OpenStack and 
> where bottom-up didn't get it in a specific project (if all else fails), the 
> TC can make a top-down request to a project to do things a certain way. The 
> project can them either comply or reject the TC oversight and become an 
> unofficial project.

>>Don't get me wrong, I welcome this initiative. I find it mildly disconcerting 
>>that the folks that I thought we were electing to fill this role will instead 
>>be filled by others, but the vacuum does need to be filled, and I thank Clint 
>>for stepping up.
+1. I appreciate Clint making this proposal. I think a cohesive, consistent 
architecture across OpenStack is crucial to our long term efficiency and 
sustaining a high rate of innovation.

Thanks,
Carol


> 
> --
> Thierry Carrez (ttx)
> 
> __
>  OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Newton midcycle planning

[Barrett, Carol L]

Hi Folks - I'm looking into the options for Intel to host in Hillsboro Oregon. 
Stay tuned for more details.
Thanks
Carol

-Original Message-
From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com] 
Sent: Tuesday, April 12, 2016 9:05 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] Newton midcycle planning



On 4/11/2016 5:54 PM, Michael Still wrote:
> On Tue, Apr 12, 2016 at 6:49 AM, Matt Riedemann 
> mailto:mrie...@linux.vnet.ibm.com>> wrote:
>
> A few people have been asking about planning for the nova midcycle
> for newton. Looking at the schedule [1] I'm thinking weeks R-15 or
> R-11 work the best. R-14 is close to the US July 4th holiday, R-13
> is during the week of the US July 4th holiday, and R-12 is the week
> of the n-2 milestone.
>
> R-16 is too close to the summit IMO, and R-10 is pushing it out too
> far in the release. I'd be open to R-14 though but don't know what
> other people's plans are.
>
> As far as a venue is concerned, I haven't heard any offers from
> companies to host yet. If no one brings it up by the summit, I'll
> see if hosting in Rochester, MN at the IBM site is a possibility.
>
>
> Intel at Hillsboro had expressed an interest in hosting the N 
> mid-cycle last release, so they might still be an option? I don't 
> recall any other possible hosts in the queue, but its possible I've missed 
> someone.
>
> Michael
>
> --
> Rackspace Australia
>
>
> __
>  OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

Tracy Jones is also looking into whether or not VMware could host in Palo Alto 
again.

-- 

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [election][tc] TC Candidacy for Carol Barrett

[Barrett, Carol L]

Hi - I am announcing my candidacy for the OpenStack Technical Committee for the 
upcoming term.



Currently, I am a Data Center Software Planner at Intel. I have been an active 
member in the community since 2013, working with Community teams to understand 
market needs and bring that information to the Community (in the form of specs, 
blueprints, prototypes and user stories) and developing materials to speed 
planning for, and adoption of OpenStack (multi-release roadmaps, Reference 
Architectures, Customer Testimonials, Evaluation and Deployment guides, etc).



As a TC member, I will work to support our success by utilizing my areas of 
expertise. Specifically, you can expect me to:

1) Collaborate to more tightly integrate requirements from our Markets into the 
Specification, Design and Development processes across projects.

2) Establish a mechanism for tracking the implementation of specifications and 
communicating progress and plans to our Markets and ecosystem.

3) Foster discussion on the future direction for our Community and our 
software. What's the vision of the Data Center of the Future? What is needed to 
realize that? How do we make sure that OpenStack is the preferred Cloud 
Platform in this future environment?

4) Work to ensure we have a thriving community that welcomes all comers and 
supports them to become contributing members and leaders.



We have a lot of opportunity for growth and success. I would like to join the 
TC to help our Community realize this potential.



Thank you for your consideration

Carol Barrett



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OpenStack-Dev][sahara] Community roadmap update

[Barrett, Carol L]

All - Thanks for reviewing the 100' view Sahara slide in yesterday's team 
meeting.  I made the updates we discussed and have posted the updated (and 
hopefully final) slide for you to check here: 
https://docs.google.com/presentation/d/1-iGE2LJRs7X5KXABuWOzbekQbQI0JT27QTK7A_RGZkw/edit?usp=sharing

Pls let me know if you have any comments or suggetions.

Appreciate your help,
Carol


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] summarizing the cross-project summit session on Mitaka themes

[Barrett, Carol L]

I'm a bit confused as to the role of Themes today. If they emerge as a result 
of Project plans, then it seems like documentation, not trying to provide input 
to set priorities/directions for Projects.

Doug: Can you clarify this for me?

My interest is to provide input to Project planning, and agree with Thierry,a 
discussion these ahead of the design summit activities would be valuable to 
this end.

Thanks
Carol

-Original Message-
From: Thierry Carrez [mailto:thie...@openstack.org] 
Sent: Monday, November 09, 2015 4:52 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] summarizing the cross-project summit session 
on Mitaka themes

Doug Hellmann wrote:
> One thing I forgot to mention in my original email was the discussion 
> about when we would have this themes conversation for the N cycle.
> I had originally hoped we would discuss the themes online before the 
> summit, and that those would inform decisions about summit sessions. 
> Several other folks in the room made the point that we were unlikely 
> to come up with a theme so surprising that we would add or drop a 
> summit session from any existing planning, so having the discussion in 
> person at the summit to add background to the other sessions for the 
> week was more constructive.

So I was stuck in Design Summit 101 during this session and couldn't attend. 
Saying that discussing common themes before summit planning is unlikely to 
change design summit session contents strikes me as odd.
That's equivalent to saying that the right themes are picked anyway.
That may be the case for some projects, but certainly not the case for all 
projects, otherwise we wouldn't be having that discussion to begin with...

Personally I think we need to have the cycle themes discussion before the 
design summit so that it can really influence what gets discussed there and 
ends up in real action items. Adding background at the last minute to 
already-decided session topics is just not enough to trigger real progress in 
those key areas.

Why can't we have that discussion on the ML in the second half of the cycle, 
between the midcycle sprints and the summit planning ?

--
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Future of telco working group and weekly meeting reminder

[Barrett, Carol L]

Steve - Thanks for the update. Look forward to seeing the User Stories in the 
Repo and coming up to speed on them. If you have priorities around them, that 
would be good to know too as look for commonalities between these stories, the 
existing user stories and new ones under development.
Carol

-Original Message-
From: Steve Gordon [mailto:sgor...@redhat.com] 
Sent: Wednesday, November 18, 2015 5:11 AM
To: Shamail
Cc: OpenStack Development Mailing List (not for usage questions); product-wg; 
openstack-operators
Subject: Re: [Product] [nfv][telco][product] Future of telco working group and 
weekly meeting reminder

- Original Message -
> From: "Shamail" 
> To: "Steve Gordon" 
> 
> Hi Steve,
> 
> > On Nov 18, 2015, at 6:39 AM, Steve Gordon  wrote:
> > 
> > Hi all,
> > 
> > Back in Vancouver [1] we began discussing the growing overlap 
> > between OPNFV requirements projects and the current mission of the telco 
> > working group.
> > During this period the product working group, also in part focused 
> > on recording and prioritizing user stories, has also been hitting its 
> > straps.
> > As we have recently lost a couple of core members of the telco 
> > working group particularly on the technical side due to role changes 
> > etc. I think it is time to roll its activities into these efforts.
> > 
> > With that in mind I would like to propose:
> > 
> > * Submitting the existing telcowg-usecases to the 
> > openstack-user-stories repository
> > * Engaging within the product working group (assuming they will have 
> > us ;)) as owners of these user stories
> This is a very similar model to what the enterprise WG did recently as well.
> Please let me know if I can do anything to help with the transition of 
> the user stories.
> > 
> > There is of course still a need to actually *implement* the 
> > requirements exposed by these user stories but I am hopeful that 
> > together we can work through a common process for this rather than 
> > continuing to attack it separately. I would personally still like to 
> > see greater direct engagement from service providers, but it seems 
> > like OPNFV and/or the OpenStack User Committee [2] itself might be the 
> > right place for this going forward.
> > 
> > I'd like to discuss this proposal further in the weekly meeting. 
> > This week's Telco Working Group meeting is scheduled for Wednesday 
> > the 18th at
> > 1400 UTC. As always the agenda etherpad is here:
> > 
> >   https://etherpad.openstack.org/p/nfv-meeting-agenda
> Would it make sense for someone else (besides yourself :)) from the 
> Product WG to join this session for Q&A as well?

The more the merrier as they say... ;)

-Steve

___
Product-wg mailing list
product...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] summarizing the cross-project summit session on Mitaka themes

[Barrett, Carol L]

Doug - Thanks for leading the session and this summary. What is your view on 
next steps to establish themes for the N-release? And specifically around 
rolling upgrades (my personal favorite).

Thanks
Carol

-Original Message-
From: Doug Hellmann [mailto:d...@doughellmann.com] 
Sent: Friday, November 06, 2015 1:11 PM
To: openstack-dev
Subject: [openstack-dev] [all] summarizing the cross-project summit session on 
Mitaka themes

At the summit last week one of the early cross-project sessions tried to 
identify some common “themes” or “goals” for the Mitaka cycle. I proposed the 
session to talk about some of the areas of work that all of our teams need to 
do, but that fall by the wayside when we don't pull the whole community 
together to focus attention on them. We had several ideas proposed, and some 
lively discussion about them. The notes are in the etherpad [1], and I will try 
to summarize the discussion here.

1. Functional testing, especially of client libraries, came up as a result of a 
few embarrassingly broken client releases during Liberty.  Those issues were 
found and fixed quickly, but they exposed a gap in our test coverage.

2. Adding tests useful for DefCore and similar interoperability testing was 
suggested in part because of our situation in Glance, where many of the 
image-related API tests actually talk to the Nova API instead of the Glance 
API. We may have other areas where additional tests in tempest could eventually 
find their way into the DefCore definition, ensuring more interoperability 
between deployed OpenStack clouds.

3. We talked for a while about being more opinionated in things like 
architecture and deployment dependencies. I don’t think we resolved this one, 
but I’m sure the discussion fed into the DLM discussion later that day in a 
separate session.

4. Improving consistency of quota management across projects came up.  We’ve 
talked in the past about a separate quota management library or service, but no 
one has yet stepped up to spearhead the effort to launch such a project.

5. Rolling upgrades was a very popular topic, in the room and on the product 
working group’s priority list. The point was made that this requires a shift in 
thinking about how to design and implement projects, not just some simple code 
changes that can be rolled out in a single cycle. I know many teams are looking 
at addressing rolling upgrades.

6. os-cloud-config support in clients was raised. There is a cross-project spec 
at https://review.openstack.org/#/c/236712/ to cover this.

7. "Fixing existing things as a priority over features” came up, and has been a 
recurring topic of discussion for a few cycles now.
The idea of having a “maintenance” cycle where all teams was floated, though it 
might be tough to get everyone aligned to doing that at the same time.  
Alternately, if we work out a way to support individual teams doing that we 
could let teams schedule them as they feel they are useful. We could also 
dedicate more review time to maintenance than features, without excluding 
features entirely.
There seemed to be quite a bit of support in the room for the general idea, 
though making it actionable will take some more thought.

8. Mike Perez is working with teams to increase our third-party CI for 
vendor-specific drivers and other deployment choices. This theme wouldn’t 
necessarily apply to every team, but there was a lot of support for it.

9. Training more contributors to debug gate issues came up late in the session. 
Anita Kuno has taken up this challenge, and has started collecting useful 
resources in a mailing list thread, the archives for which are split across 2 
months, so see both [2] and [3] if you missed it in your email client.

10. We wrapped up with a short discussion of making sure we have all the 
necessary cross-project liaisons in place to ensure good communication and 
coordination. Liaisons for Mitaka are listed in 
https://wiki.openstack.org/wiki/CrossProjectLiaisons

[1] https://etherpad.openstack.org/p/mitaka-crossproject-themes
[2] http://lists.openstack.org/pipermail/openstack-dev/2015-October/077913.html
[3] http://lists.openstack.org/pipermail/openstack-dev/2015-November/078173.html

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] naming N and O releases nowish

[Barrett, Carol L]

Monty - Thanks for the background, it brings a viewpoint I hadn't considered.

>From a roadmap point of view, as we're working toward communicating the 
>direction for OpenStack project development across 3 releases (Liberty, 
>Mitake, N-Release), I think it would better to have a name for N, rather than 
>using N-Release.  

Thanks
Carol

-Original Message-
From: Monty Taylor [mailto:mord...@inaugust.com] 
Sent: Wednesday, October 07, 2015 3:22 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tc] naming N and O releases nowish

On 10/07/2015 09:24 AM, Sean Dague wrote:
> On 10/07/2015 08:57 AM, Thierry Carrez wrote:
>> Sean Dague wrote:
>>> We're starting to make plans for the next cycle. Long term plans are 
>>> getting made for details that would happen in one or two cycles.
>>>
>>> As we already have the locations for the N and O summits I think we 
>>> should do the naming polls now and have names we can use for this 
>>> planning instead of letters. It's pretty minor but it doesn't seem 
>>> like there is any real reason to wait and have everyone come up with 
>>> working names that turn out to be confusing later.
>>
>> That sounds fair. However the release naming process currently states[1]:
>>
>> """
>> The process to chose the name for a release begins once the location 
>> of the design summit of the release to be named is announced and no 
>> sooner than the opening of development of the previous release.
>> """
>>
>> ...which if I read it correctly means we could pick N now, but not O. 
>> We might want to change that (again) first.
>>
>> [1] http://governance.openstack.org/reference/release-naming.html
>
> Right, it seems like we should change it so that we can do naming as 
> soon as the location is announced.
>
> For projects like Nova that are trying to plan things more than one 
> cycle out, having those names to hang those features on is massively 
> useful (as danpb also stated). Delaying for bureaucratic reasons just 
> seems silly. :)

So, for what it's worth, I remember discussing this when we discussed the 
current process, and the change you are proposing was one of the options put 
forward when we talked about it.

The reason for not doing all of them as soon as we know them was to keep a 
sense of ownership by the people who are actually working on the thing. 
Barcelona is a long way away and we'll all likely have rage quit by then, 
leaving the electorate for the name largely disjoint from the people working on 
the release.

Now, I hear you - and I'm not arguing that position. (In fact, I believe my 
original thought was in line with what you said here) BUT - I mostly want to 
point out that we have had this discussion, the discussion was not too long 
ago, it covered this point, and I sort of feel like if we have another 
discussion on naming process people might kill us with pitchforks.

Monty


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] naming N and O releases nowish

[Barrett, Carol L]

Is there any reason we can't change that process to align with the longer term 
planning that's happening around these things? 
Thanks
Carol
-Original Message-
From: Thierry Carrez [mailto:thie...@openstack.org] 
Sent: Wednesday, October 07, 2015 5:58 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tc] naming N and O releases nowish

Sean Dague wrote:
> We're starting to make plans for the next cycle. Long term plans are 
> getting made for details that would happen in one or two cycles.
> 
> As we already have the locations for the N and O summits I think we 
> should do the naming polls now and have names we can use for this 
> planning instead of letters. It's pretty minor but it doesn't seem 
> like there is any real reason to wait and have everyone come up with 
> working names that turn out to be confusing later.

That sounds fair. However the release naming process currently states[1]:

"""
The process to chose the name for a release begins once the location of the 
design summit of the release to be named is announced and no sooner than the 
opening of development of the previous release.
"""

...which if I read it correctly means we could pick N now, but not O. We might 
want to change that (again) first.

[1] http://governance.openstack.org/reference/release-naming.html

--
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [election][TC] TC Candidacy

[Barrett, Carol L]

Mike - Congrats on your new position! Looking forward to working with you.
Carol

-Original Message-
From: Mike Perez [mailto:thin...@gmail.com] 
Sent: Wednesday, September 30, 2015 1:55 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [election][TC] TC Candidacy

Hi all!

I'm announcing my candidacy for a position on the OpenStack Technical Committee.

On October 1st I will be employed by the OpenStack Foundation as a 
Cross-Project Developer Coordinator to help bring focus and support to 
cross-project initiatives within the cross-project specs, Def Core, The Product 
Working group, etc.

I feel the items below have enabled others across this project to strive for 
quality. If you would all have me as a member of the Technical Committee, you 
can help me to enable more quality work in OpenStack.

* I have been working in OpenStack since 2010. I spent a good amount of my time
  working on OpenStack in my free time before being paid full time to work on
  it. It has been an important part of my life, and rewarding to see what we
  have all achieved together.

* I was PTL for the Cinder project in the Kilo and Liberty releases for two
  cross-project reasons:
  * Third party continuous integration (CI).
  * Stop talking about rolling upgrades, and actually make it happen for
operators.

* I led the effort in bringing third party continuous integration to the
  Cinder project for more than 60 different drivers. [1]
  * I removed 25 different storage drivers from Cinder to bring quality to the
project to ensure what was in the Kilo release would work for operators.
I did what I believed was right, regardless of whether it would cost me
re-election for PTL [2].
  * In my conversations with other projects, this has enabled others to
follow the same effort. Continuing this trend of quality cross-project will
be my next focus.

* During my first term of PTL for Cinder, the team, and much respect to Thang
  Pham working on an effort to end the rolling upgrade problem, not just for
  Cinder, but for *all* projects.
  * First step was making databases independent from services via Oslo
versioned objects.
  * In Liberty we have a solution coming that helps with RPC versioned messages
to allow upgrading services independently.

* I have attempted to help with diversity in our community.
  * Helped lead our community to raise $17,403 for the Ada Initiative [3],
which was helping address gender-diversity with a focus in open source.
  * For the Vancouver summit, I helped bring in the ally skills workshops from
the Ada Initiative, so that our community can continue to be a welcoming
environment [4].

* Within the Cinder team, I have enabled all to provide good documentation for
  important items in our release notes in Kilo [5] and Liberty [6].
  * Other projects have reached out to me after Kilo feeling motivated for this
same effort. I've explained in the August 2015 Operators midcycle sprint
that I will make this a cross-project effort in order to provide better
communication to our operators and users.

* I started an OpenStack Dev List summary in the OpenStack Weekly Newsletter
  (What you need to know from the developer's list), in order to enable others
  to keep up with the dev list on important cross-project information. [7][8]

* I created the Cinder v2 API which has brought consistency in
  request/responses with other OpenStack projects.
  * I documented Cinder v1 and Cinder v2 API's. Later on I created the Cinder
API reference documentation content. The attempt here was to enable others
to have somewhere to start, to continue quality documentation with
continued developments.

Please help me to do more positive work in this project. It would be an honor 
to be member of your technical committee.


Thank you,
Mike Perez

Official Candidacy: https://review.openstack.org/#/c/229298/2
Review History: https://review.openstack.org/#/q/reviewer:170,n,z
Commit History: https://review.openstack.org/#/q/owner:170,n,z
Stackalytics: http://stackalytics.com/?user_id=thingee
Foundation: https://www.openstack.org/community/members/profile/4840
IRC Freenode: thingee
Website: http://thing.ee


[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2015-January/054614.html
[2] - 
https://review.openstack.org/#/q/status:merged+project:openstack/cinder+branch:master+topic:cinder-driver-removals,n,z
[3] - 
http://lists.openstack.org/pipermail/openstack-dev/2014-October/047892.html
[4] - http://lists.openstack.org/pipermail/openstack-dev/2015-May/064156.html
[5] - 
https://wiki.openstack.org/wiki/ReleaseNotes/Kilo#OpenStack_Block_Storage_.28Cinder.29
[6] - 
https://wiki.openstack.org/wiki/ReleaseNotes/Liberty#OpenStack_Block_Storage_.28Cinder.29
[7] - 
http://www.openstack.org/blog/2015/09/openstack-community-weekly-newsletter-sept-12-18/
[8] - 
http://www.openstack.org/blog/2015/09/openstack-weekly-community-newsletter-sept-19-25/

_

[openstack-dev] [election] TC] TC Candidacy

[Barrett, Carol L]

I am writing to announce my candidacy a position on the TC.

I am not your typical candidate, which is one reason that I am asking for your 
vote. I have a technical background, with over a decade of software development 
experience. I have a marketing background, with over a decade of Technology, 
Product and Brand marketing experience. I have a business development 
background and have been an entrepreneur. I have been a product manager and a 
software planner. It's this combination of experiences that I have accumulated 
during my almost 35 years in the technology industry that I believe will enable 
me to provide unique value as a member of the TC.

I have been an active member in the community since 2013, working with 
Community teams to understand market-segment needs and/or barriers to their 
deployment of OpenStack and bringing that information to the Community in the 
form of specs, blueprints, prototypes and user stories (Win The Enterprise WG, 
Enterprise WG, Product WG). These teams have brought resources to develop these 
capabilities (one example is improving upgrade capabilities through versioned 
objects implementation) and have been able to close gaps resulting in expanding 
Enterprise deployments of OpenStack.

I believe that a diverse Community will enable us to develop more innovative 
software that will meet the needs of global markets. I work with both the 
Diversity Working Group and the Women of OpenStack to help strengthen the 
diversity of our Community.

As a TC member, I will work to support our success by utilizing my 
project/program management experience. Specifically, I will:
1)  Tap the collective market knowledge within our Community to identify 
innovative capabilities that will define the defacto cloud computing platform 
of the future.
2)  Work to bring projects together to define and implement cross-project 
capabilities and initiatives.
3)  Support the development of a multi-release roadmap definition and 
communication process.

As cross-project coordination needs expand and concepts like big tent stretch 
our capabilities, I believe that my skill-sets, experiences, and values align 
well with the emerging needs within our community.

I would appreciate the opportunity to further my contributions to our Community 
and thank you for your consideration.

Carol Barrett


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Foundation Board] [OpenStack] OpenStack Diversity Working Group - Meeting Information

[Barrett, Carol L]

Roland – Thanks for your comments. Hope you can join us to help move this 
effort forward.
Carol

From: Roland Chan [mailto:rol...@aptira.com]
Sent: Tuesday, June 16, 2015 4:44 PM
To: Barrett, Carol L
Cc: Greenberg, Suzy M; foundation-bo...@lists.openstack.org; 
openst...@lists.openstack.org; OpenStack Development Mailing List (not for 
usage questions); commun...@lists.openstack.org
Subject: Re: [Foundation Board] [OpenStack] OpenStack Diversity Working Group - 
Meeting Information


I'd say meeting time accessibility is not an interest, it's a non-negotiable 
requirement. Unconscious bias creates exclusion and all that.

This group must lead by example, and it would be sad for the first step to be a 
misstep.

Roland

On 17/06/2015 8:36 AM, "Barrett, Carol L" 
mailto:carol.l.barr...@intel.com>> wrote:
The initial meeting for this work group will be: Friday,  June 19, 2015 at 
18:00 UTC, on IRC: #openstack-meeting

The Agenda is:

• Introductions

• Mission Discussion and definition of Diversity

• Discuss proposal to engage a Consultant/Coach to assist this work 
group

• Review proposed work plan, gather feedback, and owners

• Next Steps

o   Meeting Frequency

o   Interest/Need for alternating times to make the meetings globally accessible

Moving forward we’ll use the 
foundat...@lists.openstack.org<mailto:foundat...@lists.openstack.org> mail list 
for work group discussions and meeting communications.

Thanks
Carol


From: Sousou, Imad [mailto:imad.sou...@intel.com<mailto:imad.sou...@intel.com>]
Sent: Tuesday, June 09, 2015 1:28 PM
To: 
openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>; 
community-ow...@lists.openstack.org<mailto:community-ow...@lists.openstack.org>;
 openst...@lists.openstack.org<mailto:openst...@lists.openstack.org>
Subject: [openstack-dev] OpenStack Diversity Working Group

Stackers – We’re happy to announce the creation of a Diversity Working Group. 
The genesis for this work group was a discussion at the May meeting of the 
OpenStack Board of Directors ahead of the Vancouver Summit.

The Board is committed to fostering an inclusive and welcoming place for all 
people to collaborate to drive innovation and design cutting-edge data center 
capabilities, while finding the best answers to our most pressing challenges. 
To achieve this, the Board formed this Work Group to determine what actions are 
required to fulfill this commitment. Three Board members volunteered to work 
with community members in this Work Group and bring updates/requests to the 
Board for discussion and action on a regular basis, starting with the July 
meeting.

If you’re interested in joining this effort, please:

• Join the Foundation mail list to participate in discussions and shape 
the direction: click 
here<http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation>

• Visit the wiki page for this work group to learn more about the 
charter: click here<https://wiki.openstack.org/wiki/Diversity>

• Plan to join the kick-off IRC meeting and let us know what day/times 
work for you by accessing the Doodle here: click 
here<http://doodle.com/z85c23dtexx8qzq7>

We will send out the results of the Doodle to the mail list and look forward to 
working with you to foster a strong and diverse community.

Thanks
Imad Sousou (Intel), Egle Sigler (Rackspace), Kavit Munshi (Aptira)








___
Foundation-board mailing list
foundation-bo...@lists.openstack.org<mailto:foundation-bo...@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation-board
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OpenStack] OpenStack Diversity Working Group - Meeting Information

[Barrett, Carol L]

The initial meeting for this work group will be: Friday,  June 19, 2015 at 
18:00 UTC, on IRC: #openstack-meeting

The Agenda is:

* Introductions

* Mission Discussion and definition of Diversity

* Discuss proposal to engage a Consultant/Coach to assist this work 
group

* Review proposed work plan, gather feedback, and owners

* Next Steps

o   Meeting Frequency

o   Interest/Need for alternating times to make the meetings globally accessible

Moving forward we'll use the 
foundat...@lists.openstack.org mail list 
for work group discussions and meeting communications.

Thanks
Carol


From: Sousou, Imad [mailto:imad.sou...@intel.com]
Sent: Tuesday, June 09, 2015 1:28 PM
To: openstack-dev@lists.openstack.org; community-ow...@lists.openstack.org; 
openst...@lists.openstack.org
Subject: [openstack-dev] OpenStack Diversity Working Group

Stackers - We're happy to announce the creation of a Diversity Working Group. 
The genesis for this work group was a discussion at the May meeting of the 
OpenStack Board of Directors ahead of the Vancouver Summit.

The Board is committed to fostering an inclusive and welcoming place for all 
people to collaborate to drive innovation and design cutting-edge data center 
capabilities, while finding the best answers to our most pressing challenges. 
To achieve this, the Board formed this Work Group to determine what actions are 
required to fulfill this commitment. Three Board members volunteered to work 
with community members in this Work Group and bring updates/requests to the 
Board for discussion and action on a regular basis, starting with the July 
meeting.

If you're interested in joining this effort, please:

* Join the Foundation mail list to participate in discussions and shape 
the direction: click 
here

* Visit the wiki page for this work group to learn more about the 
charter: click here

* Plan to join the kick-off IRC meeting and let us know what day/times 
work for you by accessing the Doodle here: click 
here

We will send out the results of the Doodle to the mail list and look forward to 
working with you to foster a strong and diverse community.

Thanks
Imad Sousou (Intel), Egle Sigler (Rackspace), Kavit Munshi (Aptira)







__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Openstack Diversity Working Group

[Barrett, Carol L]

The Doodle time zone doesn't seem to be appearing in the local timebased upon 
the viewer.

Sorry - The time zone is US/Pacific time (UTC-7), you'll need to do your own 
conversion.

Thanks
Carol

From: Sousou, Imad [mailto:imad.sou...@intel.com]
Sent: Tuesday, June 09, 2015 11:34 AM
To: foundat...@lists.openstack.org; openst...@lists.openstack.org; 
commun...@lists.openstack.org; foundation-bo...@lists.openstack.org; 
openstack-dev@lists.openstack.org
Subject: [OpenStack Foundation] Openstack Diversity Working Group

Stackers - We're happy to announce the creation of a Diversity Working Group. 
The genesis for this work group was a discussion at the May meeting of the 
OpenStack Board of Directors ahead of the Vancouver Summit.

The Board is committed to fostering an inclusive and welcoming place for all 
people to collaborate to drive innovation and design cutting-edge data center 
capabilities, while finding the best answers to our most pressing challenges. 
To achieve this, the Board formed this Work Group to determine what actions are 
required to fulfill this commitment. Three Board members volunteered to work 
with community members in this Work Group and bring updates/requests to the 
Board for discussion and action on a regular basis, starting with the July 
meeting.

If you're interested in joining this effort, please:

* Join the Foundation mail list to participate in discussions and shape 
the direction: click 
here

* Visit the wiki page for this work group to learn more about the 
charter: click here

* Plan to join the kick-off IRC meeting and let us know what day/times 
work for you by accessing the Doodle here: click 
here

We will send out the results of the Doodle to the mail list and look forward to 
working with you to foster a strong and diverse community.

Thanks
Imad Sousou (Intel), Egle Sigler (Rackspace), Kavit Munshi (Aptira)







__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OpenStack][Product Work Group] [Enterprise][API][Telco][Dev] [Security][Operators][Marketing][User Committee] Cross-Project Vancouver Work Session

[Barrett, Carol L]

The Product Work Group has formed to listen and aggregate feedback on the 
desired capabilities for the OpenStack platform from Customers, Users and the 
Developer Community (including PTLs).  Using this feedback we intent to help 
PTLs and Contributors resolve issues that are either of strategic importance or 
have broad implications across OpenStack services that will help 
customers/users be successful with adoption by removing barriers to 
adoption/operation.

  To achieve this goal, we are striving to create a multi-release OpenStack 
roadmap based upon the aggregated information through an open, transparent, 
cross-community collaboration.

In a working session at the Vancouver Summit, we'd like to refine and finalize 
our approach to creating this roadmap. This session will be on Monday, May 18th 
 3:40 - 4:40 in Room 212. We'd like to understand what work groups, user groups 
or community members are interested in joining us for this session. Please go 
to this etherpad (https://etherpad.openstack.org/p/ProductWG_xProjectSession)  
to tell us who you are and what you're area of interest is and help shape the 
agenda for the session.

You can find more information about the Product work group here: 
https://wiki.openstack.org/wiki/ProductTeam

We look forward to meeting with you in Vancouver.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] etherpad.openstack.org upgraded

[Barrett, Carol L]

I can't get any get any etherpads to load. How do I do a hard reset?
Thanks

-Original Message-
From: Clark Boylan [mailto:cboy...@sapwetik.org] 
Sent: Monday, April 13, 2015 4:29 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] etherpad.openstack.org upgraded

Just letting everyone know I just upgraded etherpad.openstack.org to the latest 
etherpad-lite version to address CVE-2015-3297.

If you see any javascript load errors you may need to do a hard refresh of your 
etherpads (sorry about this, I will have to figure out a way to invalidate 
cached js automagically for you next time).

This should give us plenty of time to burn the server in before next months 
summit. If you do notice any performance weirdness or other bugs please do let 
us know so we can get them fixed prior to the summit.

Thank you for your patience,
Clark

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] The scope of OpenStack wiki [all]

[Barrett, Carol L]

I understand that you're moving content out of the wiki, which I think will be 
fine, as long as the wiki provides links to the new content location. Is that 
the intention?
Carol

-Original Message-
From: Thierry Carrez [mailto:thie...@openstack.org] 
Sent: Friday, January 09, 2015 1:36 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] The scope of OpenStack wiki [all]

Stefano Maffulli wrote:
> The wiki served for many years the purpose of 'poor man CMS' when we 
> didn't have an easy way to collaboratively create content. So the wiki 
> ended up hosting pages like 'Getting started with OpenStack', demo 
> videos, How to contribute, mission, to document our culture / shared 
> understandings (4 opens, release cycle, use of blueprints, stable 
> branch policy...), to maintain the list of Programs, meetings/teams, 
> blueprints and specs, lots of random documentation and more.
> 
> Lots of the content originally placed on the wiki was there because 
> there was no better place. Now that we have more mature content and 
> processes, these are finding their way out of the wiki like:
> 
>   * http://governance.openstack.org
>   * http://specs.openstack.org
>   * http://docs.openstack.org/infra/manual/
> 
> Also, the Introduction to OpenStack is maintained on 
> www.openstack.org/software/ together with introductory videos and 
> other basic material. A redesign of openstack.org/community and the 
> new portal groups.openstack.org are making even more wiki pages obsolete.
> 
> This makes the wiki very confusing to newcomers and more likely to 
> host conflicting information.

One of the issues here is that the wiki also serves as a default starting page 
for "all things not on www.openstack.org" (its main page is a list of relevant 
links). So at the same time we are moving authoritative content out of the wiki 
to more appropriate, version-controlled and peer-reviewed sites, we are still 
relying on the wiki as a reference catalog or starting point to find those more 
appropriate sites. That is IMHO what creates the confusion on where the 
authoritative content actually lives.

So we also need to revisit how to make navigation between the various web 
properties of OpenStack more seamless and discoverable, so that we don't rely 
on the wiki starting page for that important role.

> I would propose to restrict the scope of the wiki to things that 
> anything that don't need or want to be peer-reviewed. Things like:
> 
>   * agendas for meetings, sprints, etc
>   * list of etherpads for summits
>   * quick prototypes of new programs (mentors, upstream training) 
> before they find a stable home (which can still be the wiki)

+1 -- I agree on the end goal... Use the wiki a bit like we use
etherpads or pastebins, and have more appropriate locations for all of our 
reference information. It will take some time but we should move toward that.

--
Thierry Carrez (ttx)

___
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] [Telco Work Group][Ecosystem & Collateral Team] Meeting information

[Barrett, Carol L]

The Ecosystem and Collateral team of the Telco Work Group is meeting on Tuesday 
12/9 at 8:00 Pacific Time.

If you're interested in collaborating to accelerate Telco adoption of OpenStack 
through ecosystem engagements and development of collateral (case studies, 
reference architectures, etc), pls join.

Call details: Access: (888) 875-9370, Bridge: 3; PC: 7053780
Etherpad for meeting notes: 
https://etherpad.openstack.org/p/12_9_TWG_Ecosystem_and_Collateral

Thanks
Carol

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Win The Enterprise Work Group Update

[Barrett, Carol L]

I want to provide the community an update on the Win The Enterprise work group 
that came together in a BoF session in Atlanta.

The work group led a discussion with the OpenStack Board at their 7/22 meeting 
on the findings of our analysis of Enterprise IT requirements gaps. A summary 
of the presentation and next steps can be found here: 
https://drive.google.com/file/d/0BxtM4AiszlEySmJwMHpDTGFDZHc/edit?usp=sharing

Based upon the analysis and discussion, the actions for the work group are:
1)  Form a Deployment team to take on the Deployment oriented requirements 
that came up from the different teams. This team will have both Technical and 
Marketing members.
a.  Please let me know if you're interested in joining
2)  Form a Monitoring team to take on the Monitoring oriented requirements 
that came up from the different teams. This team will have both Technical and 
Marketing members.
a.  Please let me know if you're interested in joining
  For Technical gaps, we need to assess final accepted Juno blueprints 
versus requirements and develop additional blueprints through community 
participation and implementation support to bring into the Kilo Design Summit
3)  For Documentation gaps, we need to work with either existing 
documentation teams or the Marketing team to create.
4)  For Marketing Perceptions, we need to create a content and collateral 
plan with owners and execute.

Our goals are:
1)  Prepare and intercept the Kilo Design Summit pre-plannning and sessions 
in Paris with new BPs that implement the requirements
2)  Intercept Paris Summit Analyst and Press outreach plans with content 
addressing top perception issues
3)  Complete the needed documentation/collateral ahead of the Paris summit
4)  Target the Enterprise IT Strategy track in Paris on the key Enterprise 
IT requirements to address documentation gaps, and provide how-to info for 
deployments.

Call to Action: Please let me know if you want to be involved in any of the 
work group activities. Lots of opportunities for you to help advance OpenStack 
adoption in this segment!

If you have any questions or want more info, pls get in touch.
Carol Barrett
Intel Corp
+1 503 712 7623



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev