SuccessBot Says

• Ttx: Design Summit placeholder sessions pushed to the Austin official schedule.
• Pabelanger: Launched our first ubuntu-xenial job with node pool!
• Mriedem: Flavors are now in the Nova API database.
• sridhar_ram: First official release of Tacker 0.3.0 for Mitaka is released!
• Dhellmann: we have declared Mitaka released, congratulations everyone!
• Tristanc: 54 PTL and 7 TC members elected for Newton.
• Ajaeger: docs.openstack.org is ready for Mitaka – including new manuals and links to release notes.
• Tell us yours via IRC with a message “#success [insert success]”.
• All

Mitaka Release Is Out!

• Great work everyone!
• Read more about our 13th release! [1]
• See release notes from projects for new features, bug fixes, upgrade notes. [2]

Recently Accepted API-WG Guidelines

• Version discover guideline for API microversions [3]
• Client interaction guideline for API microversions [4]
• Versioning guideline for API microversions [5]
• Unexpected attribute guideline [6]
• Full thread

Results of the Technical Committee Election

• Davanum Srinivas (dims)
• Flavio Percoco (flaper87)
• John Garbutt (johnthetubaguy)
• Matthew Treinish (mtreinish)
• Mike Perez (thingee)
• Morgan Fainberg (morgan)/(notmorgan)
• Thierry Carrez (ttx)
• Full results [7]
• Full thread

Cross-Project Session Schedule

• Schedule posted [8].
• If there’s a session you’re interested in, but can’t attend because of conflicting reasons, consider getting the conversation going early on the OpenStack Developer mailing list.
• Full thread

SuccessBot Says

• Tonyb: Dims fixed the Routes 2.3 API break 🙂
• pabelanger: migration from devstack-trusty to ubuntu-trusty complete!
• Tell us yours via IRC with a message “#success [insert success]”.
• All

Voting for the Technical Committee Election Is Now Open

• We are selecting 7 TC members.
• Confirmed candidates [1]
• You are eligible to vote if you are a Foundation individual member [2] that also committed to one of the official projects [3] during the Liberty and Mitaka development.
• Important dates:
  • Election open: 2015-04-01 00:00 UTC
  • Election close: 2015-04-07 23:59 UTC
• More details on the election [4]
• Full thread

Release Process Changes For Official Projects

• The release team worked on automation for tagging and documenting [5] focusing on the projects with the release:managed tag.
• Second phase is to expand to all projects.
• The release team will be updating gerrit ACLs for projects to ensure they can handle releases and branching.
• Instead of tagging releases and then recording them in the release repository, all official teams can use the release repo to request new releases.
• If you’re not familiar with the release process, review the README file in the openstack/releases repo [6].
• Full thread

Service Catalog TNG Work in Mitaka … Next Steps

• Mitaka included fact finding
• public / admin / internal url
  • Notion of an internal url is used in many deployments because there is a belief it means there is no change for data transfer.
  • Some deployments make these all the same and use the network to ensure that internal connections hit internal interfaces.
  • Next steps:
    • We need a set of user stories built from what we currently have.
• project_id optional in projects – good progress
  • project_id is hard coded into many urls for projects without any useful reason.
  • Nova demonstrated removing this in micro version 2.18.
  • A patch [7] is up for devstack to enable this.
  • Next steps:
    • Get other projects to remove project_id from their urls.
• Service types authority
  • We agreed we needed a place to recognize service types [8].
  • The assumption that there might be a single URL which describes an API for a service is not an assumption we fulfill even for most services.
  • This bump led to [9] some shifted effort on API reference to RST work.
  • Next steps:
    • Finish API documentation conversion work.
    • Review patches for service type authority repo [10]
• Service catalog TNG Schema
  • We have some early work setting up a schema based on the known knowns, and leaving some holes for the known unknowns until we get a few of these locked down (types / allowed urls).
  • Next steps:
    • Review current schema.
• Weekly Meetings
  • The team has been meeting weekly in #openstack-meeting-cp until release crunch and people got swamped.
  • The meeting will be on hiatus for now until after Austin summit, and then start back up after the week of getting back.
• Full thread

Oh Swagger, Where Art Thou?

• Previously it has been communicated of the move from WADL to Swagger for API reference information.
• It has been discovered that Swagger doesn’t match all of our current API designs.
• There is a compute server reference documentation patch [11] using Sphinx, RST to do a near copy of the API reference page.
  • There is consensus with Nova-API team, API working group and others to go forward with this.
• We can still find uses for Swagger for some projects that match the specification really well.
• Swagger for example doesn’t support
• Showing the changes between micro
• Projects that have /actions resource allow multiple differing request bodies.
• A new plan is coming, but for now the API reference and WADL files will remain in the api-site repository.
• There will be a specification and presentation in the upstream contributor’s track about Swagger as a standard [12].
• Full thread

Cross-Project Summit Session Proposals Due

• When: April 2^nd
• Where: etherpad [13]
• Full thread

The Plan For the Final Week of the Mitaka Release

• We are approaching the final week of Mitaka release cycle.
• Important dates:
  • March 31^st was the final day for requesting release candidates for projects following the milestone release model.
  • April 1^st is the last day requesting full releases for service projects following the intermediary release model.
  • April 7^th the release team will tag the most recent release candidate for each milestone.
  • The release team will reject or postpone requests for new library releases and new service release candidates by default.
  • Only truly critical bug fixes which cannot be fixed post-release will be determined by the release team.
• Full thread

[1] – https://wiki.openstack.org/wiki/TC_Elections_April_2016#Confirmed_Candidates

[2] – http://www.openstack.org/community/members/

[3] – http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml

[4] – https://wiki.openstack.org/wiki/TC_Elections_April_2016

[5] – http://specs.openstack.org/openstack-infra/infra-specs/specs/centralize-release-tagging.html

[6] – http://git.openstack.org/cgit/openstack/releases/tree/README.rst

[7] – https://review.openstack.org/#/c/233079/

[8] – http://lists.openstack.org/pipermail/openstack-dev/2016-February/thread.html#85748

[9] – http://lists.openstack.org/pipermail/openstack-dev/2016-March/090659.html

[10] – https://review.openstack.org/#/q/project:openstack/service-types-authority

[11] – https://review.openstack.org/#/c/292420

[12] – https://www.openstack.org/summit/austin-2016/summit-schedule/events/7723

[13] – https://etherpad.openstack.org/p/newton-cross-project-sessions

SuccessBot Says

• redrobot: The Barbican API guides is now being published. [1]
• jroll: ironic 5.1.0 released as the basis for stable/mitaka.
• ttx: All RC1s up for milestones-driven projects.
• zara: storyboard.openstack.org sends emails now!
• noggin143: my first bays running on CERN production cloud with Magnum.
• sdague: Grenade upgraded to testing stable/liberty -> stable/mitaka and stable/mitaka -> master.
• Tell us yours via IRC with a message “#success [insert success]”.
• All

PTL Election Conclusion and Results

• Results are in, congrats to everyone! [2]
• Appointed PTLs by the TC for leaderless Projects [3]:
  • EC-API: Alex Andrelevine
  • Stable Branch Maintenance: Tony Breeds
  • Winstackers: Claudiu Belu
• Full thread

Candidate Proposals for Technical Committee Positions Are Now Open

• Important dates:
  • Nominations open: 2016-03-25 00:00 UTC
  • Nominations close: 2016-03-31 23:59 UTC
  • Election open: 2015-04-01 00:00 UTC
  • Election close: 2015-04-07 23:59 UTC
• More details on the election [4]
• Full thread

Release countdown for week R-1, Mar 27 – Apr 1

• Focus:
  • Project teams following the cycle-with-milestone model should be testing their release Candidates.
  • Project teams following the cycle-with-intermediary model should have at least one Mitaka release and determine if another release is needed before the end of the Mitaka cycle.
  • All projects should be working on release-critical-bugs.
• General Notes:
  • Global-requirements list is still frozen.
  • If you need to change a dependency for release-critical-bug fix, provide enough details in the change request.
  • Master branches for all projects following cycle-with-milestone are open for Newton development work.
• Release Actions:
  • Projects following cycle-with-intermediary without clear indication of cutting their final release:
    • bifrost
    • magnum
    • python-searchlightclient
    • senlin-dashboard
    • solum-infra-guestagent
    • os-win
    • cloudkitty
    • tacker
  • These projects should contact the release team or submit a release request to the releases repository as soon as possible. Please submit a request by Wednesday or Thursday at the latest.
    • After March 31st, feature releases will be counted as part of Newton cycle.
  • The release team will have reduced availability between R1 and summit due to travel. Use the dev mailing list to contact the team and include “[release]” in the subject.
• Full thread

Bots and Their Effects: Gerrit, IRC, other

• Bots are very handy for doing repetitive tasks.
• These require require permissions to execute certain actions, require maintenance to ensure they operate as expected and do create output which is music to some and noise to others
• From an infra meeting [5], this is what has been raised so far:
  • Permissions: having a bot on gerrit with +2 +A is something we would like to avoid
  • “unsanctioned” bots (bots not in infra config files) in channels shared by multiple teams (meeting channels, the -dev channel)
  • Forming a dependence on bots and expecting infra to maintain them ex post facto (example: bot soren maintained until soren didn’t)
  • Causing irritation for others due to the presence of an echoing bot which eventually infra will be asked or expected to mediate
  • Duplication of features, both meetbot and purplebot log channels and host the archives in different locations
  • Canonical bot doesn’t get maintained
• It’s possible bots that infra currently maintains have features that folks are unaware of.
• Bots that +2 reviews and approve them can be a problem when taking into account of schedules, outages, gate issues, etc.
• The Success bot for example is and added feature that takes advantage of the already existing status bot.
• What are the reasons that people end up writing their own bots instead of contributing to the existing infrastructure bots when applicable?
• Full thread

Semantic Version On Master Branches After Release Candidates

• The release team assumes three options someone would choose when installing things:
  • Tagged versions from any branch.
    • Clear, and always produces deployments that are reproduceable, with versions distinct and increasing over time.
  • Untagged versions on a stable branch.
  • Untagged versions on the master branch
    • Options 2 and 3 are something around release cycle boundaries.
    • Produce the same version numbers in different branches for a short period of time.
    • The release team felt it was extremely unlikely that anyone would mix option 2 and 3, because that will make upgrades difficult.
• Some distributions want to package things that are not tagged as releasable by contributors.
  • Consumers
    • They are in their development cycles and want/need to keep up with trunk throughout the whole cycle.
    • A lot of changes are introduced in a cycle with new features, deprecations, removals, non-backwards compatibility etc. With these continually provided up-to-date packages, they are able to test them right away.
  • It’s a lot of work to package things, and distributions want to do it quickly.
    • If distributions started packaging OpenStack only when the official stable release would be out, it would take distributions several weeks/months to get a stable package out.
    • Projects that use packages to deploy are then delayed for their own release to test these packages their consuming. (e.g. TripleO, Packstack, Kolla, Puppet-OpenStack).
• Full thread

Our Install Guides Only Cover Defcore – What About Big Tent?

• Until recently, projects like Manila [6] and Magnum have been accepted in the install guides, but we’re having issues initially because they aren’t considered by the defcore working group.
  • With expansion of projects coming from big tent, the documentation team has projects requesting their install documentation to be accepted.
  • The documentation team today maintain and verifies the install documentation for each release can be a lot of work with the already accepted OpenStack projects.
• Goals:
  • Make install guides easy to contribute for projects in the big tent.
  • Not end up having the documentation team maintain all projects install documentation.
  • As an operator, I should be able to easily discover install documentation for projects in the big tent.
  • With accessible install documentation projects can hopefully have:
    • Improved adoption
    • More stable work from bug reports with people actually able to install and test the project.
• Proposal: Install documentation can live in a project’s repository so they can maintain and update.
  • Have all these documentation sources rendered to one location for easy discoverability .
• Full thread

SuccessBot Says

• Bknudson: we got rid of keystone CLI [in favor of OpenStack Client]
• jrichli: it has been shown that Swift encryption can pass all functional tests.
• Bauzas: only a very few Nova changes were missing a reno file, the team is now super-trained on getting them.
• Odyssey4me: OpenStack-Ansible now has a Designate role ready for testing [1].
• ttx: Glance is the first project to issue RC1!
• Mugsie: mlavalle completed the Nova/Neutron/Designate DNS Integration along with docs + clients.
• Odyssey4me: OpenStack-Ansible has released Kilo 11.2.11. It’s the first time that we’ve used the release team for a release and we love it!
• Odyssey4me: OpenStack-Ansible Liberty 12.0.8 has been released.
• Tell us yours via IRC with a message “#success [insert success]”.
• All Successes

Current PTL Election Status

• Important dates:
  • Election open: 2016-03-18 00:00 UTC
  • Election close: 2016-03-24 23:59 UTC
• Projects with only one candidate: 41
• Projects with no PTL candidates:
  • EC2-API
  • Stable Branch Maintenance
  • Winstackers
• The TC will appoint a new PTL for projects without a candidate [2]
• Confirmed Candidates [3]

Quotas – Service vs. Library

• There is a spec for cross-project Quota work [4] that is seeking feedback to move ahead as a service or library.
• Service:
  • New project to manage quotas for all projects that use the service.
  • It will be responsible for handling the enforcement, management and DB upgrades of the quotas logic for all.
  • However, all projects would have a big dependency on this one service.
• Library – two ways:
  • Does not deal with database models
    • Maybe a ABC or even a few standard implementation vectors that can be imported into a project space.
    • The project will have it’s own API for quotas and the drivers will enforce different types (e.g. flat quota driver or hierarchical quota driver) with custom/project
    • Project maintains it’s own DB and upgrades.
  • A library that has models for DB tables that the project can import from.
    • Projects will have a handy outline of what the tables should look like.
    • Project has it’s own API and implements drivers in-tree by importing this semi-defined structure.
    • Project maintains it’s own upgrades but will be somewhat influenced by the common repo.
• Or just avoid all this simply give guidelines.
• A service has been proposed in the past with projects like Boson [5].
• Tim Bell raises initially a library would be good.
  • If we can’t agree on a library, we’re unlikely to agree on a service.
  • Would allow for consistent implementation of nested and user quotas.
• For projects like Trove that need a consistent lock on quotas of all projects, there are race condition issues for projects like Nova that need to be solved first.
• The main issue with doing a library that was raised in a previous summit was how to tie in database table management with the existing tables owned by a project. While this is not impossible to solve, we need to think about which tools can help with that.
• Full thread

SuccessBot Says

• Ajaeger: All jobs moved from bare-trusty to ubuntu-trusty.
• Clarkb: Infra is running logstash 2.0 now
• Tell us yours via IRC with a message “#success [insert success]”.
• All Successes

Cross-Project

• API guidelines ready for review:
  • Header non proliferation [1]
  • Client interaction guideline for microversions [2]

Election Season, PTL and TC

• PTL elections:
  • Important dates:
    • Nominations open: 2016-03-11 00:00 UTC
    • Nominations close: 2016-03-17 23:59 UTC
    • Election open: 2016-03-18 00:00 UTC
    • Election close: 2016-03-24 23:59 UTC
  • Every project team must elect a PTL every 6 months.
  • More info and how to submit your candidacy [3].
• TC elections:
  • Important dates:
    • Nominations open: 2016-03-25 00:00 UTC
    • Nominations close: 2016-03-31 23:59 UTC
    • Election open: 2016-04-01 00:00 UTC
    • Election close: 2016-04-07 23:59 UTC
  • Under the rules of the TC charter [4] we renew 7 TC seats. Seats are valid for one year.
  • More info and how to submit your candidacy [5].
• Full thread

The stable:follows-policy Tag Is Official, Projects Need To Start Applying For It

• This is official in the governance documents [6].
• Projects that follow the stable branch policy [7] should start applying.
• Full thread

Release Countdown For Week R-3, March 14-18

• Focus:
  • Projects teams following cycle-with-milestone model:
    • Preparing their first Mitaka release candidate this week.
    • This should be tagged using (X.Y.Z.0rc1) as soon as the pressure to unfreeze master is stronger than the cost of backporting bugfixes.
    • The release team will create stable branches from the release candidate tag points.
  • Project teams following the cycle-with-intermediary model
    • Ensure you have at least one mitaka release.
    • Determine if you need another release before the end of the Mitaka cycle.
  • All feature freeze exceptions that haven’t landed at this point should wait until Newton.
• General Notes:
  • The global requirements list is frozen. If you need to change a dependency, for a bug fix, please provide enough detail in the change request to allow the requirements review team to evaluate the change.
  • User-facing strings are frozen to allow the translation team time to finish their work.
• Release Actions:
  • The release team has started creating the stable/mitaka branches for libraries.
  • Follow-up on the mailing list thread [8] to acknowledge and approve the version number to use to create the branch.
    • This only includes projects with release:managed tag.
    • Other projects can post on the thread of request their own branches.
• Important Dates:
  • RC target week: R-1, March 28 – April 1
  • Mitaka final release: April 4-8
  • Mitaka release schedule [9].
• Full thread

Reminder: WSME Is Not Being Actively Maintained

• Chris Dent and Lucas Gomes have been actively verifying bug fixes and keeping things going with WSME, but are no longer interested or have the time to continue. It was also found it never really reached a state where any of the following are true:
  • The WSME code is easy to understand and maintain.
  • WSME provides correct handling of HTTP (notably response status and headers).
  • WSME has an architecture that is suitable for creating modern Python-based web applications.
• There’s a suggestion for the 24 different OpenStack projects that are using it to move to something else.
• One big reason for choosing WSME earlier was that it had support for both XML and JSON without application code needing to do anything explicitly.
  • The community has decided to stop providing XML API support and some other tools have been used instead to provide parsing and validation features similar to WSME:
    • JSONSchema
    • Voluptuous
• Full thread

SuccessBot Says

• ttx: Mitaka-3 is done.
• Odyssey4me: OpenStack-Ansible Liberty 12.0.7 is released [1].
• johnthetubaguy: Nova is down to four pending blueprints for feature freeze now [2], sort of one day left. Better than it was this morning at least.
• Russellb: Got a set of OVS flows working in OVN that applies security group changes immediately to existing connections.
• Tell us yours via IRC with a message “#success [insert success]”.
• All

Cross-Project

• Quotas and Nested Quotas Working group
  • Meeting [3]
  • Spec [4]

Outreachy May-Aug 2016: Call For Funding and Mentors

• Outreachy [5] helps people from groups underrepresented in free and open source software get involved by matching interns with established mentors in the upstream community.
• We have 10 volunteer mentors for OpenStack this next cycle (May 23-August 23 2016).
  • Learn more and apply to be a mentor [6]
• Potential sponsors have reached out, but we need more due to the increase in applicants.
  • Each intern is $6,500 for the three-month program.
  • The OpenStack Foundation has confirmed participation.
  • Learn more and apply to be a sponsor [7].
• Regardless, help spread the world!
• Full thread

Changing Microversion Headers

• The API working group would like to change the format of headers used for microversions to make them more future proof before too many projects are using them.
  • Proposed guideline [8].
• This came up in another guide for header non-proliferation [9].
• After plenty of discussions, and with projects already deploying microversions (Nova, Ironic, Manila) the proposal is change basic from:
  • X-OpenStack-Nova-API-Version: 2.11
  • OpenStack-Compute-API-Version: 2.11
• To:
  • OpenStack-API-Version: compute 2.11
• This allows us to use one header name for multipel services and avoids some of the problems described in the header non-proliferation guideline [9].
• Full thread

OpenStack Contributor Awards

• The Foundation would like introduce some informal quirky awards to recognize the extremely valuable work that we all do to make Openstack excel.
• With many different areas to celebrate, there are a few main chunks of the community that need a little love:
  • Those who might not be aware that they are valued, particularly new contributors
  • Those who are the active glue that binds the community together
  • Those who share their hard-earned knowledge with others and mentor
  • Those who challenge assumptions, and make us think
• Nominate someone who you think is deserving of an awards [10]!
• Full thread

Status Of Python 3 In OpenStack Mitaka

• 13 services were ported to Python 3 during the Mitaka cycle: Cinder, Glance, Heat, Horizon, etc.
• 9 services still need to be ported
• Next Milestone: Functional and integration tests
• “Ported to Python 3” means that all unit tests pass on Python 3.4 which is verified by a voting gate job. It is not enough to run applications in production with Python 3. Integration and functional tests are not run on Python 3 yet.
• Read the full status post [11] by Victor Stinner.
• Join Freenode channel #openstack-python3 to discuss and help out!
• Full thread

Audience for Release Notes

• We have 3 potential audiences for release notes:
  • Developers consuming libraries or other code directly.
  • Deployers and operators.
  • End-users.
• Two kinds of documentation being discussed:
  • Reno [1] for release notes [2]
    • Keep in mind the audience is *not* someone who is necessarily going to be looking at code or writing apps based on libraries we produce..
    • Highlight information that deployers and operators will need, like changes to configuration options or service behaviors.
    • Describe REST API changes that an end-user may need to know about.
  • In-tree developer documentation [3] for Developers.
    • Internal details, library API changes, etc. — any changes the deployer is not going to see.
• The two sets of documentation are meant for different purposes, so we need to think about what information we publish in each.
• Full thread [4]

A Proposal to Separate the Design Summit

Today

• Since the beginning, we’ve had face to face time at Design Summits to discuss development cycles to set goals and organize the work for the upcoming 6 months.
• A more traditional conference took place at the same time to ensure interaction between upstream and downstream parts of our community.

Current Issues

• For developers:
  • Difficult to focus on upstream work with so many distractions coming from the conference.
  • As a result the summit is less productive, and we form midcycles to fill our focus.
• For companies:
  • Flying all their developers to expensive cities and conference hotels for the summit is pretty costly. – The goals of the summit location reaching out to users everywhere does not necessarily align with the goals of the design summit location.
  • Not enough time to build products on top of the recent release.

• Not enough time for users to try out the new release to have feedback.
• Finding venues that can accommodate both events is becoming increasingly complicated.

How to Split up the events

• The first event would be for upstream technical contributors of OpenStack.
  • Held in a simpler, scaled-back setting that would let all OpenStack project teams meet in separate rooms, but in a co-located event that would make it easy to have ad-hoc cross-project discussions.
  • It would be held in closer to the centers of mass of contributors, in less-expensive locations.
  • It would happen a couple of weeks /before/ the previous cycle release. There is a lot of overlap between cycles. Work on a cycle starts at the previous cycle feature freeze, while there is still 5 weeks to go. Most people switch full-time to the next cycle by RC1. Organizing the event just after that time lets us organize the work and kickstart the new cycle at the best moment. It also allows us to use our time together to quickly address last-minute release-critical issues if such issues arise.
• The second event would be the main downstream business conference.
  • This includes high-end keynotes, marketplace, and break out sessions.
  • Organized two or three months /after/ the release, to give time downstream users to deploy and build products on top of the release.
  • This will better allow us to gather feedback on the recent release, a gather requirements for the next cycle.
  • A subset of contributors who would like to participate in sessions can collect and relay feedback to other team members (similar to the operators midcycle meetups).
• The split should reduce the number of midcycle events, however, if they’re still needed, they could happen at the conference event (which is in the middle of the cycle).
• The split means that we need to stagger the events and cycles. We have a long time between Barcelona and the Q1 Summit in the US, so the idea would be to use that long period to insert a smaller cycle (Ocata) with a release early March, 2017 and have the first specific contributors event at the start of the P cycle, mid-February, 2017. With the already-planned events in 2016 and 2017 it is the earliest we can make the transition. We’d have a last, scaled-down design summit in Barcelona to plan the shorter cycle.
• Operators midcycle will still continue to happen.

Voiced Concerns and Answers:

• This creates two events instead of one. Creates community split, with developers skipping the main and non-developers not providing any feedback to the contributor specific event.
  • There will still be a lot of strategic discussions at the main event.
  • This is where we look at the N-1 release and start drawing plans and cross-project themes for the N+1 release.
  • We don’t need every developer there, but we still need a significant chunk of them, with every team represented, so that we can have those strategic and cross-project discussions.
  • Someone who wants to keep touch with development could still make only one trip, so it’s not expected for the communities to be split. We’d still all be represented in the main event.
• Losing the main summit as an excuse to fund developers’ travel. Some developers are only sent to the Design summit because the main event is happening at the same time.
  • If you have to pretend to attend the Summit to be able to attend the Design Summit instead, there is deception involved. You should a talk with your employer on where the most value lies for you in attending which event.
  • The Foundation also has the Travel support program to cover the gaps [5].
• The fear of US-centricity (translating from “closer to the centers of mass of contributors”). This makes travel cost cheaper at the expense of making it more costly for non-US parts of our community.
  • The goal is “minimize and *balance* travel costs for existing contributors”. There will still be some continent rotation involved, but we need to balance cost and fair.
• The lost of midcycle spirit. Some people really like the midcycles as they stand: separated small events where only your small team is around. The split appears to reduce the likelihood, the need, or the funding for such events.
  • While the hope is the proposed format will let us fulfill all our team socialization needs, it’s true that there will be other people around, and it will feel a lot less exclusive and special.
  • The trade-off is that having people all together encourages cross-project work and breaks silos.
• Full thread [6]

OpenStack Operators

• Takeaways from the OpenStack Mid-Cycle Ops Meetup: first time’s the charm [1]
• OpenStack Upgrading Tutorial: 11 pitfalls and solutions [2]

“No Open Core” in 2016 (continuing)

• Continuing with discussions on Poppy in particular, Doug Hellmann raises that the Poppy team has done everything we’ve asked. The governance currently emphasizes on the social aspects of the project and community interactions. Tell the Poppy team they “are not OpenStack” even though they followed things is distressing.
• Sean Dague mentions that solutions like Neutron have an open source solution. It may needed some work, but at least there was one open source solution for testing.
• Dean Troyer brings up how we have things like Cinder with commerical products as storage drivers. Even without those storage drivers though, Cinder is still useful.
• Poppy’s open source implementation option, OpenCDN is currently an abandoned project.
• Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-February/085855.html

Upgrade Implications of Lots of Content in paste.ini

• A set of Cross-origin resource sharing (CORS) patches came out recently [3], that adds a ton of content to paste.ini.
• Paste.ini is a config that operators can change.
  • Large amounts of complicated things in there which may change in future releases is really problematic.
  • Deprecating content also is a challenge.
  • Why aren’t these options just the defaults of the CORS middlware?
    • Some projects like Ironic did request to not have headers prescribed, for eample, if Ironic is using something other than Keystone, different allowed headers would be required.
    • However, Keystone is defcore, so the default should be useful there first. Then be flexible to other auth options can go on top.
• Where do we go from here?
  • Option 1: Implement as is, keep things consistent, fix them in Newton.
    • This is not fixable in Newton as it requires deprecating out for the next three releases.
  • Option 2: Try to fix it in Mitaka 2 of CORS middleware setting defaults and projects having the ability to override [4].
    • This will require patches against a bunch of projects [5]. Who can help?
• Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-February/086746.html

[1] – http://superuser.openstack.org/articles/takeaways-from-the-openstack-mid-cycle-ops-meetup-first-time-s-the-charm

[2] – http://superuser.openstack.org/articles/openstack-upgrading-tutorial-11-pitfalls-and-solutions

[3] – https://review.openstack.org/#/c/265415/1

[4] – http://docs.openstack.org/developer/oslo.config/generator.html#modifying-defaults-from-other-namespaces

[5] – http://governance.openstack.org/reference/projects/index.html