OpenStack Developer Mailing list Digest June 10-16

Summaries

TC report 24 by Chris Dent 1
Release countdown for week R-10 and R-9, June 16-30 by Thierry 2
TC Status Update by Thierry 3.

Making Fuel a Hosted Project

Fuel originated from Mirantis as their OpenStack installer.
Approved as an official OpenStack project November 2015.
The goal was to get others involved to make one generic OpenStack installer.
In Mitaka and Newton it represented more commits than Nova.
While the Fuel team embraced open collaboration, it failed to attract other organizations.
Since October 2016 Fuel’s activity dropped from it’s main sponsor.

68% drop between 2016 and 2017.
Project hasn’t held a meeting for three months.
Activity dropped from ~990 commits/month (April 2016, August 2016) to 52 commits in April 2017 and 25 commits May 2017.

Full thread: 4

Moving Away from “big tent” Terminology

Back in 2014 our integrated release was not really integrated, too big to be installed by everyone, yet too small to accommodate the growing interest in other forms of “open infrastructure”.
Incubation process created catch-22’s.
Project structure reform 4 discussions switched us to a simpler model: project teams would be approved based on how well they’d it the OpenStack overall mission and community principles rather than maturity.

Nick named the big tent 5

It ended up mostly creating confusion due to various events and mixed messages which we’re still struggling with today.
This was discussed during a TC office hour in channel openstack-tc 6
There is still no agreement on how to distinguish official and unofficial projects. The feedback in this thread will be used to assist the TC+UC+Board sub group on better communicating what is OpenStack.
Full thread: 7

 
[1] – http://lists.openstack.org/pipermail/openstack-dev/2017-June/118314.html
[2] – http://lists.openstack.org/pipermail/openstack-dev/2017-June/118476.html
[3] – http://lists.openstack.org/pipermail/openstack-dev/2017-June/118480.html
[4] – https://governance.openstack.org/tc/resolutions/20141202-project-structure-reform-spec.html
[5] – http://inaugust.com/posts/big-tent.html
[6] – http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-06-15.log.html#t2017-06-15T13:00:53
[7] – http://lists.openstack.org/pipermail/openstack-dev/2017-June/thread.html#118368
#openstack #openstack-dev-digest
Quelle: openstack.org

OpenStack Developer Mailing List Digest June 3-9

SuccessBot Says

fungi 1: OpenStack general mailing list archives from Launchpad (July 2010 to July 2013) have been imported into the current general archive on lists.openstack.org.
andreaf 2: Tempest ssh validation running by default in the gate on master

etcd as a Base Service Update

Update to base service resolution from the TC 3.
Projects wanting to use etc v3 API grpc 4.
Projects that depend on eventlet, use the etcd3 v3 alpha HTTP API 5.
If you use too, there are two driver choices 67.
Oslo.cache driver 8.
Devstack uses etcd3 by default 9.
Cinder points to it 10.
Keystone using etcd3 for caching 11.
oslo.config to store configurations in etcd3 12.
Full thread: 13

Global Request ID Progress

oslo.context / oslo.middleware – everything DONE
devstack logging additional globalrequestid – DONE
cinder:

client supports globalrequestid – DONE
Cinder calls Nova with globalrequestid – TODO (waiting on Novaclient release)

Cinder calls Glance with globalrequestid – TODO

neutron:

client supports globalrequestid – IN PROGRESS (this landed, released, but the neutron client release had to be blocked for unrelated issues).

Neutron calls Nova with globalrequestid – TODO (waiting on Novaclient release)

nova:

Convert to oslo.middleware (to accept globalrequestid) – DONE
client supports globalrequestid – IN PROGRESS (waiting for release here 14)

Nova calls cinder with globalrequestid – DONE
Nova calls neutron with globalrequestid – TODO (waiting on working neutronclient release)

Nova calls Glance with global request id – IN PROGRESS (review needs final +2 here 15)

glance:

client supports globalrequestid – DONE
Glance supports setting globalrequestid – IN REVIEW 16 *(some debate on this).

Full thread: 17

Unreleased Libraries

Several teams with library deliverables that haven’t see any release this cycle:

glance-store
instack
pycadf
python-barbicanclient
python-congressclient
python-designateclient
python-searchlightclient
python-swiftclient
python-tackerclient
requestsexceptions

Full thread 18

POST /api-wg/news

Guidelines proposed for freeze:

Add guideline about consuming endpoints from catalog 19.
Add support for historical service type aliases 20.
Describe the publication of service-types-authority data 21.

Guidelines Under Review

Microversions: add nextminversion field in version body 22.
A suite of several documents about doing version discovery 23
WIP: microversion architecture archival doc (very early; not yet ready for review) 24

Full thread: 25

TC Report 23

Chris Dent already does a wonderful summary 26.

Project Teams Gathering – Denver September 11-15th

What: Second Project Team Gathering
When: September 11-15
Where Denver Coloradoat the Renaissance Hotel 27
Schedule:

How long: PTG will run for 5 days Monday – Friday, September 11-15th
Inter-project team work: Monday – Tuesday
Single project meetings: Wednesday-Friday

Check with PTL’s before booking travel as some teams may not meet all three days.
Work in progress schedule 28
The OpenStack Foundation has reserved a block of discounted rooms at $149/night USD. Rooms will be available 27 until August 20 or until they sell out.
Check if you need a visa 29
Requests for invitation letters can be submitted here 30, and must be received by Friday, August 25, 2017.
Travel support program first round starts July 2nd. Apply now 31
Full thread: 32

[1] – http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2017-05-26.log.html
[2] – http://eavesdrop.openstack.org/irclogs/%23openstack-qa/%23openstack-qa.2017-05-28.log.html
[3] – https://governance.openstack.org/tc/reference/base-services.html
[4] – https://pypi.python.org/pypi/etcd3
[5] – https://pypi.python.org/pypi/etcd3gw
[6] – https://github.com/openstack/tooz/blob/master/setup.cfg#L29
[7] – https://github.com/openstack/tooz/blob/master/setup.cfg#L30
[8] – https://github.com/openstack/oslo.cache/blob/master/setup.cfg#L33
[9] – http://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/etcd3
[10] – http://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/cinder#n356
[11] – https://review.openstack.org/#/c/469621/
[12] – https://review.openstack.org/#/c/454897/
[13] – http://lists.openstack.org/pipermail/openstack-dev/2017-June/thread.html#117967
[14] – https://review.openstack.org/#/c/471323/
[15] – https://review.openstack.org/#/c/467242/
[16] – https://review.openstack.org/#/c/468443/
[17] – http://lists.openstack.org/pipermail/openstack-dev/2017-June/thread.html#117924
[18] – http://lists.openstack.org/pipermail/openstack-dev/2017-June/118146.html
[19] – https://review.openstack.org/#/c/462814/
[20] – https://review.openstack.org/#/c/460654/
[21] – https://review.openstack.org/#/c/462815/
[22] – https://review.openstack.org/#/c/446138/
[23] – https://review.openstack.org/#/c/459405/
[24] – https://review.openstack.org/#/c/444892/
[25] – http://lists.openstack.org/pipermail/openstack-dev/2017-June/118069.html
[26] – http://lists.openstack.org/pipermail/openstack-dev/2017-June/117950.html
[27] – http://www.marriott.com/meeting-event-hotels/group-corporate-travel/groupCorp.mi?resLinkData=the%20OpenStack%20Project%20Teams%20Gathering%5Edensa%60fntfnta%60149.00%60USD%60false%604%609/7/17%609/19/17%608/20/17&app=resvlink&stop_mobi=yes
[28] – https://docs.google.com/spreadsheets/d/1xmOdT6uZ5XqViActr5sBOaz_mEgjKSCY7NEWcAEcT-A/edit?usp=sharing
[29] – http://travel.state.gov/content/visas/en/general/visa-wizard.html
[30] – https://openstackfoundation.formstack.com/forms/visa_form_denver_ptg
[31] – https://openstackfoundation.formstack.com/forms/travelsupportptg_denver
[32] – http://lists.openstack.org/pipermail/openstack-dev/2017-June/118002.html
Quelle: openstack.org

OpenStack Developer Mailing List Digest May 20-26

SuccessBot Says

clarkb 1 : infra added city cloud to the pool of test nodes.
pabelanger 2 : opensuse-422-infracloud-chocolate-8977043 launched by nodepool.
All: 3

etcd 3.x as a Base Service

A devstack review 4 that adds a new etcd3 service.
Two options to enable the DLM use case with Tooz (for eventless based services) 5 6
Full thread: 7

Do We Want to be Publishing Binary Container Images?

During the Forum, the discussion on collaboration between various teams building or consuming container images.
Decide how to publish images from the various teams to docker hub or other container registries.
The community has refrained from publishing binary packages in other formats such as debs and RPMs. Instead we have left this to the responsibility of the downstream consumers to build production packages.
This would require more tracking of upstream issues (bugs, CVEs, etc) to ensure the images are updated as needed.

Given our security and stable team resources, this might not be a good idea at this time.

Kolla is interested in doing this for daily builds. Everything is licensed with ASL which gives no guarantees.

Even if you mark something to not be used in production, people still use it. Take the recent user survey with DevStack being used in production.
Kolla today publishes build instructions. Manually every release they provide built containers.
Built containers would run through our CI gate, so others don’t have to have a local CI build pipeline.

Things we publish to Pypi are different from this proposal:

The formats published by pypi are source formats (sdist) and developer friend but production ready format (wheel).
Most of our services are not packaged and published to PyPi. The libraries are to make them easy to consume in our CI.
The artifacts in PyPi contain references to dependencies, the dependencies are not built into the packages themselves.

Iterating on the infra-spec review for publishing to DockerHub has started 8
Full thread: 9

RFC Cross Project Request ID Tracking

In the logging Forum session, it was brought up how much effort operators are having to put into reconstructing flows for things like server boot when they go wrong.

Jumping from service to service, the request-id is reset to something new.
Being able to query in elastic search for the same request-id in communication between services would be useful.

There is a concern of trusting the request-id on the wire, because it’s coming from a random user.

We have a new concept of “service users” which are set of higher privilege services that we are using to wrap user requests.

Basic idea is:

services will optionally take an inbound X-OpenStack-Request-ID which we’ll strongly validate req-$uuid format.

They will continue to generate one as well.
When the context is built we’ll check the service user was involved, and if not, reset the request-id to the local generated one.
Both request-ids will be logged.

Python clients and callers will need to be augmented to pass the request-id in on requests.
Servers will opt into calling other services this way.

Oslo spec for this has been merged 10.
Full thread: 11

Can We Stop Global Requirements Update (Cont.)

Gnocchi has gate issues with Babel this time. Julien plans to remove all oslo dependencies over the next few months.
The project Cotyledon was presented at some summit ago as an alternative to oslo.service and getting rid of eventless. The library lives under the telemetry umbrella for now.

The project doesn’t live under oslo so that it’s encouraged for the greater python ecosystem to adopt and help maintain it.

Octavia is also using Cotyledon.
Full thread: 12

Revised Postgresql Deprecation Patch for Governance

In the Forum session we agreed to the following:

Explicitly warn in operator facing documentation Postresql is less supported than MySQL.
Sure is the process of investigating migration from Postgresql to Gallera for future versions of OpenStack products.
TC governance patch is updated 13.

Current sticking points:

It’s important that the operator community largely is already in one camp or not.
Future items listed that are harder are important enough to justify a strict trade off here.
It’s ok to have the proposal have a firm lean in tone, even though it’s set of concrete actions are pretty reversible and don’t commit to future removal of Postgresql.

What has been raised as being hard by an abstraction layer like SQLAlchemy:

OpenStack services taking a more active role in managing DBMS.

See Active or passive role with our database layer summary below for this discussion.

The ability to have zero down time upgrade for services such as Keystone.

Expand/contract with code and carefully dancing around the existence of two schema concepts simultaneously (e.g. Nova and Neutron).
This shouldn’t be a problem because we use alembic or sqlalchemy-migrate to abstract away ALTER TABLE types.
Expand/contract using server side triggers to reconcile the two schema. This is more difficult because there is no abstraction layer that exists in SQLAlchemy. It could be feasible to build one specific to OpenStack.

Consistent UTF-8 4 & 5 byte support in our APIs

Unicode itself only needs 4 bytes and that is as far as any database supports right now. This problem has been solved by SQLAlchemy well before Python 3 existed.

The requirement that Postgresql libraries are compiled for new users trying to just run unit tests.

New developers who aren’t concerned with Postgresql don’t have to run these tests.
OpenStack went all the way with Kilo using the native python-MySQL driver which required compiling.
This is OpenStack. We are the glue to thousands of c-compiled libraries and packages.

Consistency around case sensitivity collation.

MySQL is defaulting to case-insensitive.
Postgresql almost has no support for case-insensitive.
SQLAlchemy supports things like ilike().
String datatype in SQLAlchemy guarantees case-insensitive.

Top concerns that remain:

A1) Do not surprise users late by them only finding out they are on less traveled once they are so deeply committed. It’s fine for users to choose the path, as long as they are informed they are going to need to be more self reliant.
A2) Do not prevent features like zero downtime in Keystone making forward progress with a MySQL only solution.

Orthogonal concerns:

B1) Postgresql was chosen by people in the past, maybe more than we realized, that’s real users we don’t want to throw under the bus. Whole sale delete is off the table. There’s no clear path off and missing data of who’s on it.
B2) The upstream code isn’t so irreparably changed (e.g. delete the SQLAlchemy layer) that it’s not possible to have alternative database backends.

The current proposal 13 addresses A1 and B1.
Full thread: 14

[1] – http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2017-05-24.log.html
[2] – http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2017-05-24.log.html
[3] – https://wiki.openstack.org/wiki/Successes
[4] – https://review.openstack.org/#/c/445432/
[5] – https://review.openstack.org/#/c/466098/
[6] – https://review.openstack.org/#/c/466109/
[7] – http://lists.openstack.org/pipermail/openstack-dev/2017-May/thread.html#117370
[8] – https://review.openstack.org/447524
[9] – http://lists.openstack.org/pipermail/openstack-dev/2017-May/thread.html#116677
[10] – https://review.openstack.org/#/c/464746/
[11] – http://lists.openstack.org/pipermail/openstack-dev/2017-May/thread.html#116619
[12] – http://lists.openstack.org/pipermail/openstack-dev/2017-May/thread.html#116736
[13] – https://review.openstack.org/#/c/427880/
[14] – http://lists.openstack.org/pipermail/openstack-dev/2017-May/thread.html#116642
Quelle: openstack.org

OpenStack Developer Mailing List Digest April 29 – May 5

POST /api-wg/news

Newly Published Guidelines

Create a set of API interoperability guidelines 1

Guidelines Current Under Review

Microversions: add nextminversion field in version body 2
A suite of five documents about version discovery 3
Support for historical service type aliases 4
WIP: microversion architecture archival document 5

Full thread: 6

Release countdown for week R-16 and R-15 May 8-9

Focus:

Pike feature development and completion of release goals.
Team members attending the Forum at the Boston summit should be focused in requirements gathering and collecting feedback from other parts of the community.

Actions:

Some projects still need to do Ocata stable point release.

aodh
barbican
congress
designate
freezer
glance
keystone
manila
mistral
sahara
searchlight
tricircle
trove
zaqar

Projects following intermediary-release models and haven’t done any:

aodh
bitfrost
ceilometer
cloud kitty[-dashboard]
ironic-python-agent
karbor[-dashboard]
magnum[-ui]
murano-agent
panko
senlin-dashboard
solum[-dashboard]
tacker[-dashboard]
virtage[-dashboard]

Independent projects that have not published anything for 2017:

solum
bandit
syntribos

Upcoming deadlines and dates:

Forum at OpenStack Summit in Boston: May 8-11
Pike-2 milestone 2: June 8

Full thread: 7

OpenStack moving both too fast and too slow at the same time

Drew Fisher makes the observation that the user survey 8 shows the same issue time and time again on page 18-19.

Things move too fast
No LTS release
Upgrades are scary for anything that isn’t N-1 ←N

The OpenStack community has reasonable testing in place to ensure that N-1 ←N upgrades work.
Page 18: “Most large customers move slowly and thus are running older versions, which are EOL upstream sometimes before they even deploy them.”
We’re unlikely to add more stable releases or work on them longer because:

We need more people to do the work. It has been difficult to attract contributors to this area.
Find a way to do that work that doesn’t hurt our ability to work on master.

We need older versions of the deployment platforms available in our CI to run automated tests.

Supported version of development tools setup tools and pip.
Supported versions of the various libraries and system-level dependencies like libvirt.

OpenStack started with no stable branches, where we were producing releases and ensuring that updates vaguely worked with N-1 ←N.
Distributions maintained their own stable branches.

It was suggested instead of doing duplicate effort, to share a stable branch.

The involvement of distribution packagers became more limited.
Today it’s just one person, who is currently seeking employment.

Maintaining stable branches has a cost.

Complex to ensure that stable branches actually keep working.
Availability of infrastructure resources.

OpenStack became more stable, so the demand for longer-term maintenance became stronger.

People expect upstream to provide it, not realizing that upstream is made of people employed by various organizations, and apparently this isn’t of interest to fund.

Current stable branch model is kind of useless in only supporting stable branches for one year. Two potential outcomes:

The OpenStack community still thinks there is a lot of value in doing this work upstream, in which organizations should invest resources in making that happen.
The OpenStack community thinks this is better handled downstream, and we should get rid of them completely.

For people attending the summit, there will be an on-boarding session for the stable team 9
Matt Riedemann did a video 10 ether pad 11 and slides 12 on the stable work. In the end, it was determined the cost of doing it didn’t justify the dream on, lack of resources to do it.
Full thread: 13

 
[1] – https://review.openstack.org/#/c/421846/
[2] – https://review.openstack.org/#/c/446138/
[3] – https://review.openstack.org/#/c/459405/
[4] – https://review.openstack.org/#/c/460654/3
[5] – https://review.openstack.org/444892
[6]  – http://lists.openstack.org/pipermail/openstack-dev/2017-May/116374.html
[7] – http://lists.openstack.org/pipermail/openstack-dev/2017-May/116401.html
[8] – https://www.openstack.org/assets/survey/April2017SurveyReport.pdf
[9] – https://www.openstack.org/summit/boston-2017/summit-schedule/events/18694/infraqarelease-mgmtregsstable-project-onboarding
[10] – https://www.openstack.org/videos/video/openstack-stable-what-it-actually-means-to-maintain-stable-branches
[11] – https://etherpad.openstack.org/p/stable-branch-eol-policy-newton
[12] – https://docs.google.com/presentation/d/1k0mCHwRZ3_Z8zJw_WilsuTYYqnUDlY2PkgVJLz_xVQc/edit?usp=sharing
[13] – http://lists.openstack.org/pipermail/openstack-dev/2017-May/thread.html#116298
Quelle: openstack.org

User Group Newsletter March 2017

User Group Newsletter March 2017
 
BOSTON SUMMIT UPDATE
Exciting news! The schedule for the Boston Summit in May has been released. You can check out all the details on the Summit schedule page.
Travelling to the Summit and need a visa? Follow the steps in this handy guide, 
If you haven’t registered, there is still time! Secure your spot today! 
 
HAVE YOUR SAY IN THE SUPERUSER AWARDS!

The OpenStack Summit kicks off in less than six weeks and seven deserving organizations have been nominated to be recognized during the opening keynotes. For this cycle, the community (that means you!) will review the candidates before the Superuser editorial advisors select the finalists and ultimate winner. See the full list of candidates and have your say here. 
 
COMMUNITY LEADERSHIP CHARTS COURSE FOR OPENSTACK
About 40 people from the OpenStack Technical Committee, User Committee, Board of Directors and Foundation Staff convened in Boston to talk about the future of OpenStack. They discussed the challenges we face as a community, but also why our mission to deliver open infrastructure is more important than ever. Read the comprehensive meeting report here.
 
NEW PROJECT MASCOTS
Fantastic new project mascots were released just before the Project Teams Gathering. Read the the story behind your favourite OpenStack project mascot via this superuser post. 
 
WELCOME TO OUR NEW USER GROUPS
We have some new user groups which have joined the OpenStack community.
Spain- Canary Islands
Mexico City &; Mexico
We wish them all the best with their OpenStack journey and can’t wait to see what they will achieve! Looking for your local group? Are you thinking of starting a user group? Head to the groups portal for more information.
 
LOOK OUT FOR YOUR FELLOW STACKERS AT COMMUNITY EVENTS
OpenStack is participating in a series of upcoming Community events this April.
April 3: Open Networking Summit Santa Clara, CA

OpenStack is sponsoring the Monday evening Open Source Community Reception at Levi Stadium
ldiko Vancsa will be speaking in two sessions:
Monday, 9:00-10:30am on &;The Interoperability Challenge in Telecom and NFV Environments&;, with EANTC Director Carsten Rossenhovel and Chris Price, room 207
Thursday, 1:40-3:30pm, OpenStack our Mini-Summit, topic &8220;OpenStack:Networking Roadmap, Collaboration and Contribution&8221; with Armando Migliaccio and Paul Carver from AT&T; Grand Ballroom A&B

 
April 17-19: DockerCon, Austin, TX

Openstack will be in booth

 
April 19-20: Global Open Source Summit, Beijing, China

Mike Perez will be delivering an OpenStack keynote

 
OPENSTACK DAYS: DATES FOR YOUR CALENDAR
We have lots of upcoming OpenStack Days coming up:
Upcoming OpenStack Days
June 1: Australia
June 5: Israel
June 7: Budapest
June 26: Germany Enterprise (DOST)
Read further information about OpenStack Days from this website. You’ll find a FAQ, see highlights from previous events and an extensive toolkit for hosting an OpenStack Day in your region. 
 
CONTRIBUTING TO UG NEWSLETTER
If you’d like to contribute a news item for next edition, please submit to this etherpad.
Items submitted may be edited down for length, style and suitability.
This newsletter is published on a monthly basis.
 
 
 
Quelle: openstack.org

OpenStack Developer Mailing List Digest March 18-24

SuccessBot Says

Yolanda [1]: Wiki problems have been fixed, it&;s up and running
johnthetubaguy [2]: First few patches adding real docs for policy have now merged in Nova. A much improved sample file [3].
Tell us yours via OpenStack IRC channels with message “ <message>”
All: [4]

Release Naming for R

It&8217;s time to pick a name for our “R” release.
The assoicated summit will be in Vancouver, so the geographic location has been chosen as “British Colombia”.
Rules:

Each release name must start with the letter of the ISO basic Latin alphabet following the initial letter of the previous release, starting with the initial release of &;Austin&;. After &8220;Z&8221;, the next name should start with &8220;A&8221; again.
The name must be composed only of the 26 characters of the ISO basic Latin alphabet. Names which can be transliterated into this character set are also acceptable.
The name must refer to the physical or human geography of the region encompassing the location of the OpenStack design summit for the corresponding release. The exact boundaries of the geographic region under consideration must be declared before the opening of nominations, as part of the initiation of the selection process.
The name must be a single word with a maximum of 10 characters. Words that describe the feature should not be included, so &8220;Foo City&8221; or &8220;Foo Peak&8221; would both be eligible as &8220;Foo&8221;.

Full thread [5]

Moving Gnocchi out

The project Gnocchi which has been tagged independent since it&8217;s inception has potential outside of OpenStack.
Being part of the big tent helped the project be built, but there is a belief that it restrains its adoption outside of OpenStack.
The team has decided to move it out of OpenStack [6].

In addition out of the OpenStack infrastructure.

Gnocchi will continue thrive and be used by OpenStack such as Ceilometer.
Full thread [7]

POST /api-wg/news

Guides under review:

Define pagination guidelines (recently rebooted) [8]
Create a new set of api stability guidelines [9]
Microversions: add next_min_version field in version body [10]
Mention max length limit information for tags [11]
Add API capabilities discovery guideline [12]
WIP: microversion architecture archival doc (very early; not yet ready for review) [13]

Full thread [14]

 
Quelle: openstack.org

OpenStack Developer Mailing List Digest March 11-17

SuccessBot Says

Dims [1]: Nova now has a python35 based CI job in check queue running Tempest tests (everything running on py35)
jaypipes [2]: Finally got a good functional test created that stresses the Ironic and Nova integration and migration from Newton to Ocata.
Lbragstad [3]: the -Ansible project has a test environment that automates rolling upgrade performance testing
annegentle [4]: Craig Sterrett and the App Dev Enablement WG: New links to more content for the appdev docs [5]
jlvillal [6]: Ironic team completed the multi-node grenade CI job
Tell us yours via OpenStack IRC channels with message “ <message>”

All: [7]

Pike Release Management Communication

The release liaison is responsible for:

Coordinating with the release management team.
Validating your team release team requests.
Ensure release cycle deadlines are met.
It&;s encouraged to nominate a release liaison. Otherwise this tasks falls back to the PTL.

Ensure the releaase liaison has time and ability to handle the communication necessary.

Failing to follow through on a needed process step may block you from meeting deadlines or releasing as our milestones are date-based, not feature-based.

Three primary communication tools:

Email for announcements and asynchronous communication

“[release]” topic tag on the openstack-dev mailing list.
This includes the weekly release countdown emails with details on focus, tasks, and upcoming dates.

IRC for time sensitive interactions

With more than 50 teams, the release team relies on your presence in the freenode openstack-release channel.

Written documentation for relatively stable information

The release team has published the schedule for the Pike cycle [8]
You can add the schedule to your own calendar [9]

Things to do right now:

Update your release liaisons [10].
Make sure your IRC and email address listed in projects.yaml [11].

Update your mail filters to look for “[release]” in the subject line.
Full thread [12]

OpenStack Summit Boston Schedule Now Live!

Main conference schedule [13]
Register now [14]
Hotel discount rates for attendees [15]
Stackcity party [16]
Take the certified OpenStack Administrator exam [17]
City guide of restaurants and must see sites [18]
Full thread [19]

Some Information About the Forum at the Summit in Boston

“Forum” proper

3 medium sized fishbowl rooms for cross-community discussions.
Selected and scheduled by a committee formed of TC and UC members, facilitated by the Foundation staff members.
Brainstorming for topics [20]

“On-boarding” rooms

Two rooms setup classroom style for projects teams and workgroups who want to on-board new team members.
Examples include providing introduction to your codebase for prospective new contributors.
These should not be tradiitonal “project intro” talks.

Free hacking/meetup spaces

Four to five rooms populated with roundtables for ad-hoc discussions and hacking.

Full thread [21]

 
The Future of the App Catalog

Created early 2015 as a market place of pre-packaged applications [22] that you can deploy using Murano.
This has grown to 45 Glance images, 13 Heat templates and 6 Tosca templates. Otherwise did not pick up a lot of steam.
~30% are just thin wrappers around Docker containers.
Traffic stats show 100 visits per week, 75% of which only read the index page.
In parallel, Docker developed a pretty successful containerized application marketplace (Docker Hub) with hundreds or thousands regularly updated apps.

Keeping the catalog around makes us look like we are unsuccessfully trying to compete with that ecosystem, while OpenStack is in fact complimentary.

In the past, we have retired projects that were dead upstream.

The app catalog is however has an active maintenance team.
If we retire the app catalog, it would not be a reflection on that team performance, but that the beta was arguably not successful in build an active market place and a great fit from a strategy perspective.

Two approaches for users today to deploy docker apps in OpenStack:

Container-native approach using “docker run” after using Nova or K8s cluster using Magnum.
OpenStack Native approach “zun create nginx”.

Full thread [23][24]

ZooKeeper vs etcd for Tooz/DLM

Devstack defaults to ZooKeeper and is opinionated about it.
Lots of container related projects are using etcd [25], so do we need to avoid both ZooKeeper and etcd?
For things like databases and message queues, it&8217;s more than time for us to contract on one solution.

For DLMs ZooKeepers gives us mature/ featureful angle. Etcd covers the Kubernetes cooperation / non-java angle.

OpenStack interacts with DLM&8217;s via the library Tooz. Tooz today only supports etcd v2, but v3 is planned which would support GRPC.
The OpenStack gate will begin to default to etcd with Tooz.
Full thread [26]

Small Steps for Go

An etherpad [27] has been started to begin tackling the new language requirements [28] for Go.
An golang-commons repository exists [29]
Gopher cloud versus having a golang-client project is being discussed in the etherpad. Regardless we need support for os-client-config.
Full thread [30]

POST /api-wg/news

Guidelines under review:

Add API capabilities discovery guideline [31]
Refactor and re-validate API change guidelines [32]
Microversions: add next_min_version field in version body [33]
WIP: microversion architecture archival doc [34]

Full thread [35]

Proposal to Rename Castellan to oslo.keymanager

Castellan is a python abstraction to different keymanager solutions such as Barbican. Implementations like Vault could be supported, but currently is not.
The rename would emphasize the Castellan is an abstraction layer.

Similar to oslo.db supporting MySQL and PostgreSQL.

Instead of oslo.keymanager, it can be rolled into the oslo umbrella without a rename. Tooz sets the precedent of this.
Full thread [36]

Release Countdown for week R-23 and R-22

Focus:

Specification approval and implementation for priority features for this cycle.

Actions:

Teams should research how they can meet the Pike release goals [37][38].
Teams that want to change their release model should do so before end of Pike-1 [39].

Upcoming Deadlines and Dates

Boston Forum topic formal submission period: March 20 &; April 2
Pike-1 milestone: April 13 (R-20 week)
Forum at OpenStack Summit in Boston: May 8-11

Full thread [40]

Deployment Working Group

Mission: To collaborate on best practices for deploying and configuring OpenStack in production environments.
Examples:

OpenStack Ansible and Puppet OpenStack have been collaborating on Continuous Integration scenarios but also on Nova upgrades orchestration
TripleO and Kolla share the same tool for container builds.
TripleO and Fuel share the same Puppet OpenStack modules.
OpenStack and Kubernetes are interested in collaborating on configuration management.
Most of tools want to collect OpenStack parameters for configuration management in a common fashion.

Wiki [41] has been started to document how the group will work together. Also an etherpad [42] for brainstorming.

 
Quelle: openstack.org

Helping PTG attendees and other developers get to the OpenStack Summit

Although the OpenStack design events have changed, developers and operators still have a critical perspective to bring to the OpenStack Summits. At the PTG, a common whisper heard in the hallways was, &;I really want to be at the Summit, but my [boss/HR/approver] doesn&;t understand why I should be there.&; To help you out, we took our original &8220;Dear Boss&8221; letter and made a few edits for the PTG crowd. If you&8217;re a contributor or developer who wasn&8217;t able to attend the PTG, with a few edits, this letter can also work for you. (Not great with words? Foundation wordsmith Anne can help you out&;anne at openstack.org)
 
Dear [Boss],
 
I would like to attend the OpenStack Summit in Boston, May 8-11, 2017. At the Pike Project Team Gathering in Atlanta (PTG), I was able to learn more about the new development event model for OpenStack. In the past I attended the Summit to participate in the Design Summit, which encapsulated the feedback and planning as well as design and development of creating OpenStack releases. One challenge was that the Design Summit did not leave enough time for “head down” work within upstream project teams (some teams ended up traveling to team-specific mid-cycle sprints to compensate for that). At the Pike PTG, we were able to kickstart the Pike cycle development, working heads down for a full week. We made great progress on both single project and OpenStack-wide goals, which will improve the software for all users, including our organization.
 
Originally, I––and many other devs––were under the impression that we no longer needed to attend the OpenStack Summit. However, after a week at the PTG, I see that I have a valuable role to play at the Summit’s “Forum” component. The Forum is where I can gather direct feedback and requirements from operators and users, and express my opinion and our organization’s about OpenStack’s future direction. The Forum will let me engage with other groups with similar challenges, project desires and solutions.
 
While our original intent may have been to send me only to the PTG, I would strongly like us to reconsider. The Summit is still an integral part of the OpenStack design process, and I think my attendance is beneficial to both my professional development and our organization. Because of my participation in the PTG, I received a free pass to the Summit, which I must redeem by March 14.      
 
Thank you for considering my request.
[Your Name]
Quelle: openstack.org

The OpenStack Summit is returning to Vancouver in May 2018

Back by popular demand, the OpenStack Summit is returning to Vancouver, Canada from May 21-24, 2018. Registration, sponsorship opportunities and more information for the 17th OpenStack Summit will be available in the upcoming months. 
Can’t wait until 2018? Brush up on your OpenStack skills in 2017 by registering to attend the OpenStack Summit Boston, May 8-11 and marking your calendar for the OpenStack Summit Sydney, November 6-8.

For news on new and upcoming OpenStack Summits, visit openstack.org/summit. 

Photos from the 2015 OpenStack Summit Vancouver
 
 
 
Quelle: openstack.org

User Group Newsletter February 2017

Welcome to 2017! We hope you all had a lovely festive season. Here is our first edition of the User Group newsletter for this year.

AMBASSADOR PROGRAM NEWS
2017 sees some new arrivals and departures to our Ambassador program. Read about them here.
 
WELCOME TO OUR NEW USER GROUPS
We have some new user groups which have joined the community.
Bangladesh
Ireland &; Cork
Russia &8211; St Petersburg
Phoenix &8211; United States
Romania &8211; Bucharest
We wish them all the best with their OpenStack journey and can’t wait to see what they will achieve!
Looking for a your local group? Are you thinking of starting a user group? Head to the groups portal for more information.

MAY 2017 OPENSTACK SUMMIT
We’re going to Boston for our first summit of 2017!!
You can register and stay updated here.
Consider it your pocket guide for all things Boston summit. Find out about the featured speakers, make your hotel bookings, find your FAQ and read about our travel support program.
 
NEW BOARD OF DIRECTORS
The community has spoken! A new board of directors has been elected for 2017.
Read all about it here. 

MAKE YOUR VOICE HEARD!
Submit your response the latest OpenStack User Survey!
All data is completely confidential. Submissions close on the 20th of February 2017.
You can complete it here. 

CONTRIBUTING TO UG NEWSLETTER
If you’d like to contribute a news item for next edition, please submit to this etherpad.
Items submitted may be edited down for length, style and suitability.
This newsletter is published on a monthly basis. 
Quelle: openstack.org