December 2017 - Foundation-board - lists.openinfra.dev

OpenStack Summit Vancouver: Sponsor Sales Open
by Mark Collier 15 Dec '17

15 Dec '17

All, I wanted to make you aware that today we launched the sponsorship contract for the Vancouver Summit, happening May 21 - 25, 2018. Quite a few companies have already claimed a spot. Since booth selection is done in order the signed contracts are received, we always encourage companies to move fast :) Find the prospectus and sponsorship agreement here: https://www.openstack.org/summit/vancouver-2018/sponsors/ You’ve probably noticed the OpenStack Summits have covered more than OpenStack for a while. The event has really evolved to become the home of open infrastructure collaboration, driven by user demand. You’ll see us increasing our focus on “Open Infrastructure” at the Summits in 2018, which means a greater breadth of technologies, including new projects like Kata Containers and the integration work with things like Kubernetes. Content will align with the Strategic Focus areas we've defined for the Foundation, including datacenter cloud technologies, edge computing, container infrastructure, CI/CD and machine learning. We’re also working to make the Berlin contract available soon because we’ve had a lot of initial demand. Looking forward to seeing everyone in Dublin soon for the PTG, and again in Vancouver in May! Mark

1 0

Kata Containers launch update
by Claire Massey 08 Dec '17

08 Dec '17

Hi everyone, This week we unveiled Kata Containers, the first project we are piloting under the Container Infrastructure strategic focus area. We wanted to let you know the launch and activities at KubeCon have been very positive and well received. Initially, the project has given the Foundation the opportunity to engage with new companies in the industry who have not historically supported OpenStack and help build bridges across the cloud native community. In the first 36 hours, we had more than 14,000 pageviews on katacontainer.io, nearly 100K impressions on Twitter, and lots of activity on WeChat. A few highlights from the press: TechCrunch Intel and Hyper partner with the OpenStack Foundation to launch the Kata Containers project <https://techcrunch.com/2017/12/05/intel-and-hyper-partner-with-the-openstac…> eWeek OpenStack Launches Kata Containers Project to Improve Security <http://www.eweek.com/cloud/openstack-launches-kata-containers-project-to-im…> SDx Central OpenStack Launches Open Source ‘Kata Containers’ Project <https://www.sdxcentral.com/articles/news/openstack-launches-open-source-kat…> And supportive tweets from influencers in the Kubernetes and OpenStack communities: https://twitter.com/jessfraz/status/938087837303525382 <https://twitter.com/jessfraz/status/938087837303525382> https://twitter.com/MayaKaczorowski/status/938182876507660289 <https://twitter.com/MayaKaczorowski/status/938182876507660289> https://twitter.com/LachlanEvenson/status/938057796548825089 <https://twitter.com/LachlanEvenson/status/938057796548825089> Thank you to the organizations who are supporting the launch of Kata Containers: 99cloud, AWcloud, Canonical, China Mobile, City Network, CoreOS, Dell/EMC, EasyStack, Fiberhome, Google, Intel, Huawei, Hyper.sh, JD.com, Mirantis, NetApp, Red Hat, SUSE, Tencent, Ucloud, UnitedStack and ZTE. We’re starting to plan 2018 activities for Kata Containers and the container infrastructure area. If your organization is interested in getting involved, please let me know. Thanks, Claire

1 0

Fwd: [OpenStack Foundation] Upstream Long Term Support Releases (was Fwd: [openstack-dev] Developer Mailing List Digest November 11-17)
by Jonathan Bryce 05 Dec '17

05 Dec '17

I wanted to highlight this email the Dims sent to the Foundation mailing list. I know many of your companies have expressed interest in longer support terms and this is the opportunity to get involved and help make that a reality. If you want to join efforts around it, I’d suggest either reaching out on the Foundation mailing list or to Dims directly. I’m also happy to answer any questions. Thanks! Jonathan > Begin forwarded message: > > From: Davanum Srinivas <davanum(a)gmail.com> > Subject: [OpenStack Foundation] Upstream Long Term Support Releases (was Fwd: [openstack-dev] Developer Mailing List Digest November 11-17) > Date: November 17, 2017 at 8:31:17 AM CST > To: foundation(a)lists.openstack.org > > Dear Board, > > In the last OpenStack Board meeting, LTS was one of the "big" needs > that was brought up for the health of OpenStack going forward. Please > see the summary below and the etherpad of discussion/proposal at > https://etherpad.openstack.org/p/LTS-proposal > > So far folks from RedHat have added their name (at the bottom of the > etherpad) for getting an effort off the ground. > > I am looking for more folks from the Board, our Platinum and Gold > sponsors to help evangelize this inside their own organizations and > help us move this forward. > > Looking forward to hearing from you all. > > Thanks, > Dims > > ---------- Forwarded message ---------- > From: Mike Perez <thingee(a)gmail.com> > Date: Fri, Nov 17, 2017 at 5:16 AM > Subject: [openstack-dev] Developer Mailing List Digest November 11-17 > To: openstack-dev(a)lists.openstack.org > Cc: openstack-operators(a)lists.openstack.org, user-committee(a)lists.openstack.org > > > Contribute to the Dev Digest by summarizing OpenStack Dev List thread: > > * https://etherpad.openstack.org/p/devdigest > * http://lists.openstack.org/pipermail/openstack-dev/ > > HTML version: https://www.openstack.org/blog/2017/11/developer-mailing-list-digest-novemb… > > Summaries > ========= > * POST /api-sig/news [0] > * Release countdown for week R-14, November 18-24 [1] > [0] - http://lists.openstack.org/pipermail/openstack-dev/2017-November/124633.html > [1] - http://lists.openstack.org/pipermail/openstack-dev/2017-November/124631.html > > > Upstream Long Term Support Releases > =================================== > The Sydney Summit had a very well attended and productive session [0] about to > go about keeping a selection of past releases available and maintained for long > term support (LTS). > > In the past the community has asked for people who are interested in old > branches being maintained for a long time to join the Stable Maintenance team > with the premise that if the stable team grew, it could support more branches > for longer periods. This has been repeated for about years and is not working. > > This discussion is about allowing collaboration on patches beyond end of life > (EOL) and enable whoever steps up to maintain longer lived branches to come up > with a set of tests that actually match their needs with tests that would be > less likely to bitrot due to changing OS/PYPI substrate. We need to lower > expectations of what we're likely to produce will get more brittle the older > the branch gets. Any burden created by taking on more work is absorbed by > people doing the work, as does not unduly impact the folks not interested in > doing the work. > > The idea is to continue the current stable policy more or less as it is. > Development teams take responsibility of a couple of stable branches. At some > point what we now call an EOL branch, instead of deleting it we would leave it > open and establish a new team of people who want to continue to main that > branch. It's anticipated the members of those new teams are coming mostly from > users and distributors. Not all branches are going to attract teams to maintain > them, and that's OK. > > We will stop tagging these branches so the level of support they provide are > understood. Backports and other fixes can be shared, but to consume them, a > user will have to build their own packages. > > Test jobs will run as they are, and the team that maintain the branch could > decide how to deal with them. Fixing the jobs upstream where possible is > preferred, but depending on who is maintaining the branch, the level of support > they are actually providing and the nature of the breakage, removing individual > tests or whole jobs is another option. Using third-party testing came up but is > not required. > > Policies for the new team being formed to maintain these older branches is > being discussed in an etherpad [2]. > > Some feedback in the room expressed they to start one release a year who's > branch isn't deleted after a year. Do one release a year and still keep N-2 > stable releases around. We still do backports to all open stable branches. > Basically do what we're doing now, but once a year. > > Discussion on this suggestion extended to the OpenStack SIG mailing list [1] > suggesting that skip-release upgrades are a much better way to deal with > upgrade pain than extending cycles. Releasing every year instead of a 6 months > means our releases will contain more changes, and the upgrade could become more > painful. We should be release often as we can and makes the upgrades less > painful so versions can be skipped. > > We have so far been able to find people to maintain stable branches for 12-18 > months. Keep N-2 branches for annual releases open would mean extending that > support period to 2+ years. If we're going to do that, we need to address how > we are going to retain contributors. > > When you don't release often enough, the pressure to get a patch "in" > increases. Missing the boat and waiting for another year is not bearable. > > > [0] - https://etherpad.openstack.org/p/SYD-forum-upstream-lts-releases > [1] - http://lists.openstack.org/pipermail/openstack-sigs/2017-November/000149.ht… > [2] - https://etherpad.openstack.org/p/LTS-proposal > > -- > Mike Perez (thingee) > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > -- > Davanum Srinivas :: https://twitter.com/dims > _______________________________________________ > Foundation mailing list > Foundation(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

1 0