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 OpenStack-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 “#success <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’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’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.

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 “Dear Boss” letter and made a few edits for the PTG crowd. If you’re a contributor or developer who wasn’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]

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

SuccessBot Says

• dims [1] : Nova now has a python35 based CI job in check queue running Tempest tests (everything running on py35)
• markvoelker [2]: Newly published Foundation annual report starts off with interoperability right in the chairman’s note [3]
• Tell us yours via OpenStack IRC channels with message “#success <message>”
• All: [4]

Get Active in Upstream Training

• There is a continuous effort in helping newcomers join our community by organizing upstream contribution trainings [5][6] before every summit.
  • 1.5 – 2 days of hands-on steps of becoming an active OpenStack contributor.
• Like everything else, this is a community effort.
  • In preparation for the Boston summit and the upcoming PTG in Atlanta, we are looking for coaches and mentors to help us make the training better.
  • If you’re interested in helping contact:
    • Ildiko Vancsa IRC freenode at ildikov or email [7]
    • Kendall Nelson IRC freenode at diablo_rojo or email [8]
• Full thread: [9]

Project Team Gathering Coordination Tool

• No central scheduling, beyond assigned rooms to teams and days.
  • Each team arranges their time in their room.
  • List of etherpads [10]
• We still need centralized communication beyond each room:
  • An event IRC channel: #openstack-ptg on free node IRC
    • Do public service announcements
    • Pings from room to room.
  • An EtherCalc spreadsheet powered dynamic schedule with extra rooms available:
    • One fishbowl
    • A few dark rooms with projectors and screens (not all will have a/v equipment due to budget).
    • Infra is working on setting up EtherCalc
• Full thread: [11]

POST /api-wg/news

• API Guidelines proposed for freeze:
  • Add guidelines on usage of state vs. status [12]
  • Clarify the status values in versions [13]
  • Add guideline for invalid query parameters [14]
• Guidelines currently under review:
  • Add guidelines for boolean names [15]
  • Define pagination guidelines [16]
  • Add API capabilities discovery guideline [17 ]
• Full thread: [18]

Lots of Teams Without PTL Candidates

• We are reaching close to the end of the PTL nominations (Jan 29, 2017 23:45 UTC), but have projects that are leaderless:
• Community App Catalog
• Ec2 API
• Fuel
• Karbor
• Magnum
• Monasca
• OpenStackClient
• OpenStackUX
• Packaging Prm
• Rally
• RefStack
• Requirements
• Senlin
• Stable Branch Maintenance
• Vitrage
• Zun
• Full thread [19]

SuccessBot Says

• stevemar 1 : number of open keystone bugs < 100!
• morgan 2 : Good policy meeting, provided history and background that cleared up a lot of confusion
• Tell us yours via OpenStack IRC channels with message “#success <message>”
• All

FIPS Compliance

• Previous threads 3 have been discussing enabling Federal Information Processing Standards (FIPS).
• Various OpenStack projects make md5 calls. Not for security purposes, just hash generation, but even that blocks enabling FIPS.
• A patch has been proposed for newest versions of Python for users to set if these are used for security or not 4 .
  • Won’t land until next versions of Python, but in place for current RHEL and CentOS versions.
  • We will create a wrapper around md5 with a useforsecurity=False parameter to check the signature of hashlib.md5.
• Steps forward:
  • Create the wrapper
  • Replace all md5 calls in OpenStack projects with the wrapper.
• Unfortunately the patch 4 has stopped having progress since 2013. We should get that merged first.
  • Even if this did land, it would be a while before it was adopted, since it would land in Python 3.7.
• Full thread

Refreshing and Revalidating API Compatibility Guidelines

• In the last TC meeting 5 , a tag was in review for supporting API compatibility 6 .
• The tag evaluates projects by using the API guideline which is out of date 7.
  • A review has been posted to refresh these guidelines 8 .
  • API compatibility of overtime is a fundamental aspect of OpenStack interoperability. Not only do we need to get it it right, we need to make sure we understand it.
• Full thread

Base Services

• in open stack all components can assume that a number of external services won’t be present and available (e.g. A message queue, database).
• The Architecture working group has started this effort 9 .
• This proposal 10 is a prerequisite in order for us to have more strategic discussions with adding base services.
• Review the proposal and/or join the Architecture working group meeting 11
• Once solidified the technical committee will have a final discussion and approval.
• Full thread

Improving Vendor Discoverability

• In previous Technical Committee meetings, it was agreed that vendor discoverability needs to be improved.
• This is done today with the OpenStack Foundation marketplace 12 .
  • This is powered by the community driven project call driver log which is a big JSON file 13.
• Various people in the community did not know how the marketplace worked and we’re unhappy that the projects themselves weren’t owning it.
• The goal of this discussion is to have this process be more community driven than it is today.
• Suggestion: Split driver log into smaller JSON files that are inside each project to maintain.
  • Projects will set how they validate vendors into this list.
  • There’s a trend today for third party CI’s being a choice of validation 14.
• Full thread

Nominations for OpenStack PTLs Are Now Open!

• Will remain open until January 29, 2017 23:45 UTC.
• Candidates must submit a text file openstack/election repository 15
  • Filename convention is $cyclename/$projectname/$ircname.txt.
  • To be eligible, you need to have contributed an accepted patch to one of the corresponding program’s projects 16 during the Neutron-Ocata timeframe (April 11, 2016 00:00 UTC to January 23, 2017 23:59 UTC).
• Additional information about the nomination process 17
• Approved candidates will be listed 18.
• Electorate should confirm their email address in Gerrit 19 in Settings ←Contact Information ←Preferred Email prior to Jan 25, 2017 23:59 UTC.
• Full thread

The Process of Creating stable/ocata branches

• As previously mentioned 20, it’s possible for teams to setup stable branches when ready.
• The release team will not be automatically setting up branches this cycle.
  • The release liaison within teams will need to inform when ready.
  • The PTL or release liaison may request a new branch by submitting a patch to the openstack/releases repository specifying the tagged version to be used as the base of the branch.
• Guidelines for when projects should branch:
  • Projects using the cycle-with-milestone release model should include the request for their stable branch along with the RC1 tag request (target week is R-3 week, so use Feb 2 as the deadline)
  • Library projects should be branched with, or shortly after, their final release this week (use Jan 19 as the deadline)
  • I will branch the requirements repository shortly after all of the cycle-with-milestone projects have branched. After the   requirements repository is branched and the master requirements list is opened, projects that have not branched will be tested with Pike requirements as the requirements master branch advances and stable/ocata stays stable. Waiting too long to create the stable/ocata branch may result in broken CI jobs in either stable/ocata or master. Don’t delay any further than necessary.
  • Projects using the cycle-trailing release model should branch by R-0 (23 Feb). The remaining two weeks before the trailing deadline should be used for last-minute fixes, which will need to be backported into the branch to create the final release.
  • Other projects, including cycle-with-intermediary and independent  projects that create branches, should request their stable branch when they are ready to declare a final version and start working on Pike-related changes. This must be completed before the final release week, use 16 Feb as the deadline.
• See the README.rst file in openstack/releases for more details about how to format branch specifications.
• Full thread

Why Are Projects Trying To Avoid Barbican, Still?

• Some projects are wanting to implement their own secret storage to avoid Barbican or avoid adding a dependency on it.
  • Some developers are doing this to make the operator’s lives simpler.
• Barbican Positives:
  • Barbican has been around for a few years and deployed by several companies that have probably been audited for security purposes.
  • Most of the technology involved in Barbican is proven to be secure. This has been analyzed by the OpenStack’s own security group.
  • Doesn’t have a requirement on hardware TPM, so no hardware cost.
  • Several services provide the option of using Barbican, but not a hard requirement.
• Feedback of problems with Barbican:
  • Relying on something that cannot be guaranteed will be present in a deployment.
    • The base service 9 proposal could help with this.
  • OpenStack specific solution. Some companies are using solutions that integrate with other things:
    • Keywhiz 21 to work with Kubernetes and their existing systems.
  • Devstack plugin just sets up Barbican. It’s not actually configuring any existing services to use it.
  • No fixed key manager for testing. The Barbican team pushed back on maintaining this because it’s not secure.
  • API stability with version 2 ←3 changes were made without a deprecation path or guarantees.
  • Tokens are open ended for users. Keystone and Barbican need to be much closer.
• Castellan provides an abstraction for key management, but today only Barbican.
• Rackspace recently made Barbican available. Maybe it’s easier now to perform an HA deployment.
• Full thread

POST /api-wg/news

• New guidelines:
  • Accurate status code vs backwards compatibility 22
  • Fix no sample file in browser 23
• Guidelines proposed for freeze:
  • Add guidelines on usage of state vs. status 24
  • Clarify the status values in versions 25
  • Add guideline for invalid query parameters 26
• Under review:
  • Add guidelines for boolean names 27
  • Define pagination guidelines 28
  • Add API capabilities discovery guideline 29
• Full thread

Release Countdown for Week R-4 Jan 23-27

• Focus:
  • This week begins feature freeze for all milestone-based projects.
  • No feature patches should be landed after this point.
  • PTLs may grant exceptions
  • Soft string freeze begins.
    • Review teams should reject any modifications to user-facing strings.
  • Requirement freeze begins.
    • Only critical requirements and constraints changes will be allowed.
• Release Tasks:
  • Prepare final release and branch requests for all client libraries.
  • Review stable branches for unreleased changes and prepare those releases.
  • Milestone based projects should ensure that membership of $project-release gerri groups is up to date with the team who will finalize the project release.
• General Notes:
  • RC1 target week in R-3 is only one week after freeze.
• Important Dates:
  • Ocata 3 Milestone, with Feature and Requirements Freezes: 26 Jan
  • Ocata RC1 target: 2 Feb
  • Ocata Final Release candidate deadline: 16 Feb
  • Ocata release schedule 30
• Full thread

[1] – http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2017-01-18.log.html

[2] – http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2017-01-18.log.html

[3] – http://lists.openstack.org/pipermail/openstack-dev/2016-November/107035.html

[4] – http://bugs.python.org/issue9216

[5] – http://eavesdrop.openstack.org/meetings/tc/2017/tc.2017-01-17-20.00.log.html

[6] – https://review.openstack.org/#/c/418010/

[7] – http://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html

[8] – https://review.openstack.org/#/c/421846/

[9] – https://review.openstack.org/421956

[10] – https://review.openstack.org/421957

[11] – http://eavesdrop.openstack.org/#Architecture_Working_Group

[12] – https://www.openstack.org/marketplace/drivers/

[13] – http://git.openstack.org/cgit/openstack/driverlog/tree/etc/default_data.json

[14] – https://etherpad.openstack.org/p/driverlog-validation

[15] – http://governance.openstack.org/election/#how-to-submit-your-candidacy

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

[17] – https://governance.openstack.org/election/

[18] – https://governance.openstack.org/election/#pike-ptl-candidates

[19] – https://review.openstack.org

[20] – http://lists.openstack.org/pipermail/openstack-dev/2016-December/108923.html

[21] – https://github.com/square/keywhiz

[22] – https://review.openstack.org/#/c/422264/

[23] – https://review.openstack.org/#/c/421084/

[24] – https://review.openstack.org/#/c/411528/

[25] – https://review.openstack.org/#/c/411849/

[26] – https://review.openstack.org/417441

[27] – https://review.openstack.org/#/c/411529/

[28] – https://review.openstack.org/#/c/390973/

[29] – https://review.openstack.org/#/c/386555/

[30] – http://releases.openstack.org/ocata/schedule.html

SuccessBot Says

• dims 1: Rally running against Glance (Both Rally and Glance using py3.5).
• AJaegar 2: docs.openstack.org is served from the new Infra file server that is AFS based.
• jd 3: Gnocchi 3.1 will be shipped with an empty /etc and will work without any config file by default.
• cdent 4 : edleafe found narrowed down an important bug in gabbi.
• Tell us yours via OpenStack IRC channels with message “#success <message>”
• All

Return of the Architecture Working Group

• Meeting times Alternate, even weeks Thursday at 20:00UTC, odd weeks Thursday at 01:00UTC
• Currently two proposes:
  • “Base Services” proposal 5 recognizes components leveraging features from external services that OpenStack components can assume will be present. Two kinds:
    • Local (like a hypervisor on a compute node)
    • Global (like a database)
  • “Nova Compute API” proposal 6 breaking nova-compute out of Nova itself.
• Full thread

Restarting Service-types-authority / service catalog work

• In anticipation of having a productive time in Atlanta for the PTG, various patches have been refreshed 7.
• Two base IASS services aren’t in the list yet because of issues:
  • Neutron / network – discrepancy between common use of “network” and “networking” in the API reference URL. Other services in the list have the service-type and the URL name for the API reference are the same.
  • Cinder / volume – Moving forward from using volumev2 and volumev3 in devstack.
• Full thread

Feedback From Driver Maintainers About Future of Driver Projects

• Major observations
  • Yes drivers are an important part of OpenStack.
  • Discoverability of drivers needs to be fixed immediately.
  • It’s important to have visibility in a central place of the status of each driver.
  • Both driver developer and a high level person at a company should feel they’re part of something.
  • Give drivers access to publish to docs.openstack.org.
  • What constitutes a project was never for drivers. Drivers are part part of the project. Driver developers contribute to OpenStack by creating drivers.
• Discoverability:
  • Consensus: it is currently all over the place 8 9 10.
  • There should be CI results available.
  • Discoverability can be fixed independently of governance changes.
• Driver projects official or not?
  • Out-of-tree vendors have a desire to become “official” OpenStack projects.
  • Opinion: let driver projects become official without CI requirements.
  • Opinion: Do not allow drivers projects to become official, that doesn’t mean they shouldn’t easily be discoverable.
  • Opinion: We don’t need to open the flood gates of allowing vendors to be teams in the OpenStack governance to make the vendors developers happy.
  • Fact: This implies being placed under the TC oversight. It is a significant move that could have unintended side-effects, it is hard to reverse (kicking out teams we accepted is worse than not including them in the first place), and our community is divided on the way forward. So we need to give that question our full attention and not rush the answer.
  • Opinion: Consider driver log 11 an official OpenStack project to be listed under governance with a PTL, weekly meetings, and all that it required to allow the team to be effective in their mission of keeping the marketplace a trustworthy resource for learning about OpenStack driver ecosystem.
• Driver Developers:
  • Opinion: A driver developer that ONLY contributes to vendor specific driver code should not have the same influence as other OpenStack developers, voting for PTL, TC, and ATC status.
  • Opinion: PTLs should leverage the extra-atcs option in the governance repo.
• In-tree VS out-of-tree
  • Cinder has in-tree drivers, but also has out-of-tree drivers when their CI is not maintained or when minimum feature requirements are not met. They are marked as ‘not supported’ and have a single release to get things working before being moved out-of-tree.
  • Ironic has a single out-of-tree repo 12 — But also in-tree 13
  • Neutron has all drivers out-of-tree, with project names like: ‘networking-cisco’.
  • Many opinions on the “stick-based” approach the cinder team took.
  • Opinion: The in-tree vs out-of-tree argument is developer focused. Out-of-tree drivers have obvious benefits (develop quickly, maintain their own team, no need for a core to review the patch). But a vendor that is looking to make sure a driver is supported will not be searching git repos (goes back to discoverability).
  • Opinion: May be worth handling the projects that keep supported drivers in-tree differently that we handle projects that have everything out-of-tree.
• Full thread

POST /api-wg/news

• Guidelines currently under review:
  • Add guidelines on usage of state vs. status 14
  • Add guidelines for boolean names 15
  • Clarify the status values in versions 16
  • Define pagination guidelines 17
  • Add API capabilities discovery guideline 18
  • Add guideline for invalid query parameters 19
• Full thread

New Deadline for PTG Travel Support Program

• Help contributors that are not otherwise funded to join their project team gathering 20
• Originally the application acceptance was set to close January 15, but it’s now extended to the end-of-day Tuesday January 17th.
• Apply now if you need it! 21
• Submissions will be evaluated next week and grantees will be notified by Friday, January 20th.
• Register for the event 22 if you haven’t yet. Prices will increase on January 24 and February 14.
• If you haven’t already booked your hotel yet, do ASAP in the event hotel itself using the PTG room block. This helps us keep costs under control and helps share the most time with the event participants.
  • Closes January 27
  • Book now 23
• Full thread

Release Countdown For Week R-5

• Focus:
  • Feature work and major refactoring be starting to wrap up as we approach the the third milestone.
• Release Tasks:
  • stable/ocata branches will be created and configured with a small subset of the core review team. Release liaisons should ensure that these groups exist and the membership is correct.
• General Notes:
  • We will start the soft string freeze during R-4 (Jan 23-27) 24
  • Subscribe to the release calendar with your favorite calendaring software 25
• Important Dates:
  • Final release for non-client libraries: January 19
  • Ocata 3 milestone with feature and requirements freeze: January 26
  • Ocata release schedule 26
• Full thread

[1] – http://eavesdrop.openstack.org/irclogs/%23openstack-glance/%23openstack-glance.2017-01-09.log.html

[2] – http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2017-01-10.log.html

[3] – http://eavesdrop.openstack.org/irclogs/%23openstack-telemetry/%23openstack-telemetry.2017-01-11.log.html

[4] – http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-01-12.log.html

[5] – http://git.openstack.org/cgit/openstack/arch-wg/tree/proposals/base-services.rst

[6] – https://review.openstack.org/#/c/411527/1

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

[8] – http://docs.openstack.org/developer/cinder/drivers.html

[9] – http://docs.openstack.org/developer/nova/support-matrix.html

[10] – http://stackalytics.openstack.org/report/driverlog

[11] – http://git.openstack.org/cgit/openstack/driverlog

[12] – https://git.openstack.org/cgit/openstack/ironic-staging-drivers

[13] – http://git.openstack.org/cgit/openstack/ironic/tree/ironic/drivers

[14] – https://review.openstack.org/#/c/411528/

[15] – https://review.openstack.org/#/c/411529/

[16] – https://review.openstack.org/#/c/411849/

[17] – https://review.openstack.org/#/c/390973/

[18] – https://review.openstack.org/#/c/386555/

[19] – https://review.openstack.org/417441

[20] – http://www.openstack.org/ptg#tab_travel

[21] – https://openstackfoundation.formstack.com/forms/travelsupportptg_atlanta

[22] – https://pikeptg.eventbrite.com/

[23] – https://www.starwoodmeeting.com/events/start.action?id=1609140999&key=381BF4AA

[24] – https://releases.openstack.org/ocata/schedule.html#o-soft-sf

[25] – https://releases.openstack.org/schedule.ics

[26] – http://releases.openstack.org/ocata/schedule.html

SuccessBot Says

• Dims – Keystone now has Devstack based functional test with everything running under python3.5.
• Tell us yours via OpenStack IRC channels with message “#success <message>”
• All

Time To Retire Nova-docker

• nova-docker has lagged behind the last 6 months of nova development.
• No longer passes simple CI unit tests.
  • There are patches to at least get the unit tests work 1 .
• If the core team no longer has time for it, perhaps we should just archive it.
• People ask about it on ##openstack-nova about once or twice a year, but it’s not recommended as it’s not maintained.
• It’s believed some people are running and hacking on it outside of the community.
• The Sun project provides lifecycle management interface for containers that are started in container orchestration engines provided with Magnum.
• Nova-lxc driver provides an ability of treating containers like your virtual machines. 2
  • Not recommended for production use though, but still better maintained than nova-docker 3.
• Nova-lxd also provides the ability of treating containers like virtual machines.
• Virtuozzo which is supported in Nova via libvirt provides both a virtual machine and OS containers similar to LXC.
  • These containers have been in production for more than 10 years already.
  • Well maintained and actually has CI testing.
• A proposal to remove it 4 .
• Full thread

Community Goals For Pike

• A few months ago the community started identifying work for OpenStack-wide goals to “achieve visible common changes, push for basic levels of consistency and user experience, and efficiently improve certain areas where technical debt payments have become to high – across all OpenStack projects.”
• First goal defined 5 to remove copies of incubated Oslo code.
• Moving forward in Pike:
  • Collect feedback of our first iteration. What went well and what was challenging?
  • Etherpad for feedback 6
• Goals backlog 7
  • New goals welcome
  • Each goal should be achievable in one cycle. If not, it should be broken up.
  • Some goals might require documentation for how it could be achieved.
• Choose goals for Pike
  • What is really urgent? What can wait for six months?
  • Who is available and interested in contributing to the goal?
• Feedback was also collected at the Barcelona summit 8
• Digest of feedback:
  • Most projects achieved the goal for Ocata, and there was interest in doing it on time.
  • Some confusion on acknowledging a goal and doing the work.
  • Some projects slow on the uptake and reviewing the patches.
  • Each goal should document where the “guides” are, and how to find them for help.
  • Achieving multiple goals in a single cycle wouldn’t be possible for all team.
• The OpenStack Product Working group is also collecting feedback for goals 9
• Goals set for Pike:
  • Split out Tempest plugins 10
  • Python 3 11
• TC agreeements from last meeting:
  • 2 goals might be enough for the Pike cycle.
  • The deadline to define Pike goals would be Ocata-3 (Jan 23-27 week).
• Full thread

POST /api-wg/news

• Guidelines current review:
  • Add guidelines on usage of state vs. status 12
  • Add guidelines for boolean names 13
  • Clarify the status values in versions 14
  • Define pagination guidelines 15
  • Add API capabilities discovery guideline 16
• Full thread

SuccessBot Says

• AJaeger: We’ve now got the first Deployment guide published for Newton, see http://docs.openstack.org/project-deploy-guide/newton/ . Congrats to OpenStack Ansible team!
• clarkb: OpenStack CI has moved off of Ubuntu Trusty and onto Ubuntu Xenial for testing Newton and master.
• ihrachys: first oslo.privsep patch landed in Neutron.
• dulek: Cinder now supports ZeroMQ messaging!
• All

Release Countdown for Week R-8, 26-30 December

• Feature work and major refactoring should be well under way as we pass the second milestone.
• Focus:
  • Deadline for non-client library releases is R-5 (19 Jan).
    • Feature freeze exceptions are not granted for libraries.
• General Notes:
  • Project teams should identify contributors that have a significant impact this cycle who not otherwise qualify for ATC status.
  • Those names should be added to the governance repository for consideration as ATC.
  • The list needs to be approved by the TC by 20 January to qualify for contributor discounts codes for the event.
  • Submit these by 5 January
• Important Dates:
  • Extra ATCs deadline: 5 January
  • Final release of non-client libraries: 19 January
  • Ocata 3 Milestone, with Feature and Requirements freezes: 26 January
• Ocata release schedule [1]
• Full thread

Storyboard Lives

• There is movement to still move to Storyboard as our task tracker.
• To spread awareness, some blog posts have been made about it, and it’s capabilities:
  • General over and decision to move from Launchpad [2].
  • Next post will focus on compare and contrast of Launchpad and Storyboard.
• If you want to hear about something in particular in the blog posts, let the team know on #storyboard IRC channel on Freenode.
• Attend their weekly meeting [3].
• Try out Storyboard in the sandbox [4].
• Storyboard documentation [5]
• Full thread

[1] – http://releases.openstack.org/ocata/schedule.html

[2] – https://storyboard-blog.sotk.co.uk/why-storyboard-for-openstack.html

[3] – https://wiki.openstack.org/wiki/StoryBoard

[4] – https://storyboard-dev.openstack.org/

[5] – http://docs.openstack.org/infra/storyboard/