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/

Updates

• Release schedule clarification after Ocata [5]
• Nova placement/resource providers [6][12]
• Stuart McLaren stepping down from glance core [8]

Allowing Teams Based on Vendor-specific Drivers (cont) [1]

• Narrowed down options at last TC meeting to following [2]:
  • Soft black (option 2): default option, had no negative feedback, represents the current status quo
  • Soft white (option 4): had some positive feedback, folks liked it’s simple solution
  • Grey (option 5): had the most positive feedback, but also the least amount of detail
• Other options’ patches are being abandoned
• Leaning towards an amended version of the ‘Grey’ proposal [10]

Community Goals for Pike (cont.) [3]

• Need feedback [4]
• Keep using openstack/governance for documenting goals
  • Make sure to include guides
  • Consider prioritization as it may not be possible to complete all the goals in the release
  • Think about splitting larger goals to things that can be accomplished in a single release
• Involving users/operators through the Product WG and start face to face discussions on the Forums

Python changes in OpenStack CI [7]

• Python3.4 on a Trusty VM for older branches: stable/liberty and stable/mitaka
• Python3.5 on a Xenial VM for newer branches: stable/newton and master
  • Python3.4 testing is disabled for these
  • ACTION:
    • Projects should enable voting for Python3.5 jobs or add them if they don’t exist yet
    • Projects should remove Python3.4 jobs if they run only on master

Golang Technical Requirements [15]

• Activities to adopt Go into OpenStack are ongoing
• Areas need more discussion
  • Common Libraries
  • Dependency Management
    • Candidates are govendor, glide and godep
  • Release Deliverables
    • Tags and/or build artifacts?
    • AUTHORS and ChangeLog files can be autogenerated
• Oaktree has golang bindings and contains generated files

Upgrade readiness check in Nova [11]

• New, separate service
• Checks the system state and indicates how much it is ready to start the Ocata upgrade (success, warning, error)

Self-service branch management [13]

• Through openstack/releases repo
• Specify your needs in a patch [14] and the rest is automated after it’s merged
• New stable branch creation is best to happen close to the end of the cycle, when the bug fixing and stabilization activities are slowing down

Architectural discussion about nova-compute interactions [16]

• How do Nova, Neutron and Cinder interact with nova-compute
• Should nova-compute become a standalone shared service? [9]

[1] http://lists.openstack.org/pipermail/openstack-dev/2016-November/108074.html

[2] http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-12-06-20.02.log.txt

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

[4] https://etherpad.openstack.org/p/community-goals

[5] http://lists.openstack.org/pipermail/openstack-dev/2016-December/108689.html

[6] http://lists.openstack.org/pipermail/openstack-dev/2016-December/108707.html

[7] http://lists.openstack.org/pipermail/openstack-dev/2016-December/108821.html

[8] http://lists.openstack.org/pipermail/openstack-dev/2016-December/108840.html

[9] https://review.openstack.org/#/c/411527/

[10] https://review.openstack.org/403829

[11] http://lists.openstack.org/pipermail/openstack-dev/2016-December/109060.html

[12] http://lists.openstack.org/pipermail/openstack-dev/2016-December/109085.html

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

[14] http://git.openstack.org/cgit/openstack/releases/tree/README.rst#n63

[15] http://lists.openstack.org/pipermail/openstack-dev/2016-December/108875.html

[16] http://lists.openstack.org/pipermail/openstack-dev/2016-December/109044.html

Updates:

• Nova placement/resource providers update with some discussions on aggregates and API [4]
• New Nova core reviewer: Stephen Finucane [8]
• Project mascots are all around the mailing list, search for “logo” in the subject to find them
• Status update on unsupported Ironic drivers [10]
• The DefCore Committee is now called Interop Working Group [11]

Creating a New IRC Meeting Room [9]

• Create a new channel: #openstack-meeting-5
• Generally recommend project teams to use the meeting channels on Freenode
• Let projects use their channels for the meetings, but only if the channel is logged
• As a next step limit the official meeting rooms for official projects and have non-official projects using their own IRC channels

Neutron Trunk port feature

• Clarifying some usability aspects [1]
• Performance measurements [2]

Ocata Bugsmash Day [3]

• Thanks to Huawei and Intel and all the attendees to make it happen
• Let’s keep the tradition and grow the event further if we can

PTG Travel Support Program [5][6]

• Deadline of the first phase is this week
• Phase two deadline is January 15th
• Also reminding you to register to the event if you can come, but haven’t done it yet [7]

Finish test job transition to Ubuntu Xenial [12]

• Merged at last! [13]
• A lot of experimental and non votings jobs had to be updated
• Changes to Master no longer run on trusty
• Might have missed things still, so keep a look out

[1] http://lists.openstack.org/pipermail/openstack-dev/2016-December/108530.html

[2] http://lists.openstack.org/pipermail/openstack-dev/2016-December/108460.html

[3] http://lists.openstack.org/pipermail/openstack-dev/2016-December/108538.html

[4] http://lists.openstack.org/pipermail/openstack-dev/2016-December/108395.html

[5] http://lists.openstack.org/pipermail/openstack-dev/2016-December/108645.html

[6] https://openstackfoundation.formstack.com/forms/travelsupportptg_atlanta

[7] https://pikeptg.eventbrite.com/

[8] http://lists.openstack.org/pipermail/openstack-dev/2016-December/108520.html

[9] http://lists.openstack.org/pipermail/openstack-dev/2016-December/108360.html

[10] http://lists.openstack.org/pipermail/openstack-dev/2016-December/108624.html

[11] http://lists.openstack.org/pipermail/openstack-dev/2016-December/108673.html

[12] http://lists.openstack.org/pipermail/openstack-dev/2016-November/106906.html

[13] https://review.openstack.org/#/c/348078

Want to attend the OpenStack Summit Boston but need help with the right words for getting your trip approved? While we won’t write the whole thing for you, here’s a template to get you going. It’s up to you to decide how the Summit will help your team, but with free workshops and trainings, technical sessions, strategy talks and the opportunity to meet thousands of likeminded Stackers, we don’t think you’ll have a hard time finding an answer.

Dear [Boss],

I would like to attend the OpenStack Summit in Boston, May 8-11, 2017. The OpenStack Summit is the largest open source conference in North America, and the only one where I can get free OpenStack training, learn how to contribute code upstream to the project, and meet with other users to learn how they’ve been using OpenStack in production. The Summit is an opportunity for me to bring back knowledge about [Why you want to attend! What are you hoping to learn? What would benefit your team?] and share it with our team, while helping us get to know similar OpenStack-minded teams around the world (think 60+ countries and nearly 1,200 companies represented).

If I register before mid-March, I get early bird pricing–$600 USD for 4 days (plus an optional day of training). Early registration also allows me to RSVP for trainings and workshops as soon as they open (they always sell out!), or sign up to take the Certified OpenStack Administrator exam onsite.

At the OpenStack Summit Austin last year, over 7,800 attendees heard case studies from Superusers like AT&T and China Mobile, learned how teams are using containers and container orchestration like Kubernetes with OpenStack, and gave feedback to Project Teams about user needs for the upcoming software release. You can browse past Summit content at openstack.org/videos to see a sample of the conference talks.

The OpenStack Summit is the opportunity for me to expand my OpenStack knowledge, network and skills. Thanks for considering my request.

[Your Name]

Updates

• Nova Resource Providers update [2]
• Nova blueprints update [16]
• OpenStack-Ansible deploy guide live! [6]

The Future of OpenStack Needs You [1]

• Need more mentors to help run Upstream Trainings at the summits
• Interested in doing an abridged version at smaller more local events
• Contact ildikov or diablo_rojo on IRC if interested

New project: Nimble [3]

• Interesting chat about bare metal management
• The project name is likely to change

Community goals for Pike [4]

• As Ocata is a short cycle it’s time to think about goals for Pike [7]
• Or give feedback on what’s already started [8]

Exposing project team’s metadata in README files (Cont.) [9]

• Amrith agrees with the value of Flavio’s proposal that a short summary would be good for new contributors
• Will need a small API that will generate the list of badges
  • Done- as a part of governance
  • Just a graphical representation of what’s in the governance repo
  • Do what you want with the badges in README files
• Patches have been pushed to the projects initiating this change

Allowing Teams Based on Vendor-specific Drivers [10]

• Option 1: https://review.openstack.org/403834 – Proprietary driver dev is unlevel
• Option 2: https://review.openstack.org/403836 – Driver development can be level
• Option 3: https://review.openstack.org/403839 – Level playing fields, except drivers
• Option 4:  https://review.openstack.org/403838 – Stop requiring a level playing field
• Option 5:  https://review.openstack.org/403829 – Establish a new “driver team” concept
  • Thierry prefers this option
• Option 6: https://review.openstack.org/403830 – Add resolution requiring teams to accept driver contributions
  • One of Flavio’s preferred options
• Option 7: https://review.openstack.org/403826 – Add a resolution allowing teams based on vendor-specific drivers
  • Flavio’s other preferred option

Cirros Images to Change Default Password [11]

• New password: gocubsgo
• Not ‘cubswin:)’ anymore

Destructive/HA/Fail-over scenarios

• Discussion started about adding end-user focused test suits to test OpenStack clusters beyond what’s already available in Tempest [12]
• Feedback is needed from users and operators on what preferred scenarios they would like to see in the test suite [5]
• You can read more in the spec for High Availability testing [13] and the user story describing destructive testing [14] which are both on review

Events discussion [15]

• Efforts to remove duplicated functionality from OpenStack in the sense of providing event information to end-users (Zaqar, Aodh)
• It is also pointed out that the information in events can be sensitive which needs to be handled carefully

[1] http://lists.openstack.org/pipermail/openstack-dev/2016-November/108084.html

[2] http://lists.openstack.org/pipermail/openstack-dev/2016-November/107982.html

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

[4] http://lists.openstack.org/pipermail/openstack-dev/2016-November/108167.html

[5] http://lists.openstack.org/pipermail/openstack-dev/2016-November/108062.html

[6] http://lists.openstack.org/pipermail/openstack-dev/2016-November/108200.html

[7] https://etherpad.openstack.org/p/community-goals

[8] https://etherpad.openstack.org/p/community-goals-ocata-feedback

[9] http://lists.openstack.org/pipermail/openstack-dev/2016-November/107966.html

[10] http://lists.openstack.org/pipermail/openstack-dev/2016-November/108074.html

[11] http://lists.openstack.org/pipermail/openstack-dev/2016-November/108118.html

[12] http://lists.openstack.org/pipermail/openstack-dev/2016-November/108062.html

[13] https://review.openstack.org/#/c/399618/

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

[15] http://lists.openstack.org/pipermail/openstack-dev/2016-November/108070.html

[16] http://lists.openstack.org/pipermail/openstack-dev/2016-November/108089.html

Updates:

• Nova placement/resource provider work [4]
• New release-announce list and other changes to openstack-announce [5]
• Formal Discussion of Documenting Upgrades[6]
• Stewardship Working Group description/update [7]
• OpenStack Liberty has reached EOL [8]
• Switching test jobs from Ubuntu Trusty to Xenial on the gate is happening on December 6th [9]

A Continuously Changing Environment:

• We have core developers who’ve been around for a long while stepping down and giving the opportunity to the “next generation” to take on the responsibility of leadership
• Thank you for your presence, for teaching and for showing other contributors a good example by embracing open source and OpenStack
  • Andrew Laski (Nova): “As I’ve told people many times when they ask me what it’s like to work on an open source project like this: working on proprietary software exposes you to smart people but you’re limited to the small set of people within an organization, working on a project like this exposed me to smart people from many companies and many parts of the world. I have learned a lot working with you all. Thanks.”
  • Carl Baldwin (Neutron): “This is a great community and I’ve had a great time participating and learning with you all.”
  • Marek Denis (Keystone): “It’s been a great journey, I surely learned a lot and improved both my technical and soft skills.”
• Thank you for all your hard work!

Community goals for Ocata:

• Starting with the Newton, our community commits to release goals in order to provide the minimum level of consistency and user experience and to improve certain areas OpenStack-wide [1]
• The goal is to remove all remaining incubated Oslo code in Ocata[2][3]

Unit Test Setup Changes [10]:

• Attempt to remove DB dependency from the unit test jobs
  • Special DB jobs still exist to provide workaround where needed along with a script in ‘tools/test-setup.sh’
• Long term goal is for projects to not use the -db jobs anymore, new changes for them should not be accepted.

Project Info in README Files [11]

• Increase visibility of fundamental project information that is already available on the governance web site [12]
• Badges are automatically generated as part of the governance CI [13]
• Every project is strongly recommended to use this new system to provide information about
  • The project’s state (in Big Tent or not, etc.)
  • Project tags
  • Project capabilities

[1] http://governance.openstack.org/goals/index.html

[2] http://governance.openstack.org/goals/ocata/remove-incubated-oslo-code.html

[3] https://www.youtube.com/watch?v=tW0mJZe6Jiw

[4] http://lists.openstack.org/pipermail/openstack-dev/2016-November/107600.html

[5] http://lists.openstack.org/pipermail/openstack-dev/2016-November/107629.html

[6] http://lists.openstack.org/pipermail/openstack-dev/2016-November/107570.html

[7] http://lists.openstack.org/pipermail/openstack-dev/2016-November/107712.html

[8] http://lists.openstack.org/pipermail/openstack-dev/2016-November/107184.html

[9] http://lists.openstack.org/pipermail/openstack-dev/2016-November/106906.html

[10] http://lists.openstack.org/pipermail/openstack-dev/2016-November/107784.html

[11] http://lists.openstack.org/pipermail/openstack-dev/2016-November/107966.html

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

[13] https://review.openstack.org/#/c/391588/

SuccessBot Says

• mriedem: We’re now running neutron by default in Ocata CI jobs [1].
• stevemar: fernet token format is now the default format in keystone! thanks lbragstad samueldmq and dolphm for making this happen!
• Ajaegar: developer.openstack.org is now hosted by OpenStack infra.
• Tonyb: OpenStack requirements on pypi [2] is now a thing!
• All

Registration Open For the Project Teams Gathering

• The first OpenStack Project Teams Gathering event geared toward existing upstream team members, providing a venue for those project teams to meet, discuss and organize the development work for the Pike release.
• Where: Atlanta, GA
• When: The week of February 20, 2017
• Register and get more info [3]
• Read the FAQ for any questions. If you still have questions, contact Thierry (ttx) over IRC on free node, or email foundation staff at [email protected].
• Full thread

Follow up on Barcelona Review Cadence Discussions

• Summary of concerns were Nova is a complex beast. Very few people know even most of it well.
• There are areas in Nova where mistakes are costly and hard to rectify later.
• Large amount of code does not merge quickly.
• Barrier of entry for Nova core is very high.
• Subsystem maintainer model has been pitched [4].
• Some believe this is still worth giving a try again in attempt to merge good code quickly.
• Nova today uses a list of experts [5] to sign off on various changes today.
• Nova PTL Matt Riedemann’s take:
  • Dislikes the constant comparison of Nova and the Linux kernel. Lets instead say all of OpenStack is the Linux Kernel, and the subsystems are Nova, Cinder, Glance, etc.
  • The bar for Nova core isn’t as high as some people make it out to be:
    • Involvement
    • Maintenance
    • Willingness to own and fix problems.
    • Helpful code reviews.
  • Good code is subjective. A worthwhile and useful change might actually break some other part of the system.
• Nova core Jay Pipes is supportive of the proposal of subsystems, but with a commitment to gathering data about total review load, merge velocity, and some kind of metric to assess code quality impact.
• Full thread

Embracing New Languages in OpenStack

• Technical Committee member Flavio Percoco proposes a list of what the community should know/do before accepting a new language:
  • Define a way to share code/libraries for projects using the language
    • A very important piece is feature parity on the operator.
    • Oslo.config for example, our config files shouldn’t change because of a different implementation language.
    • Keystone auth to drive more service-service interactions through the catalog to reduce the number of things an operator needs to configure directly.
    • oslo.log so the logging is routed to the same places and same format as other things.
    • oslo.messaging and oslo.db as well
  • Work on a basic set of libraries for OpenStack base services
  • Define how the deliverables are distributed
  • Define how stable maintenance will work
  • Setup the CI pipelines for the new language
    • Requirements management and caching/mirroring for the gate.
  • Longer version of this [6].
• Previous notes when the Golang discussion was started to work out questions [7].
• TC member Thierry Carrez says the most important in introducing the Go should not another way for some of our community to be different, but another way for our community to be one.
• TC member Flavio Percoco sees part of the community wide concerns that were raised originated from the lack of an actual process of this evaluation to be done and the lack of up front work, which is something trying to be addressed in this thread.
• TC member Doug Hellmann request has been to demonstrate not just that Swift needs Go, but that Swift is willing to help the rest of the community in the adoption.
  • Signs of that is happening, for example discussion about how oslo.config can be used in the current version of Swift.
• Flavio has started a patch that documents his post and the feedback from the thread [8]
• Full thread

API Working Group News

• Guidelines that have been recently merged:
  • Clarify why CRUD is not a great descriptor [9]
  • Add guidelines for complex queries [10]
  • Specify time intervals based filtering queries [11]
• Guidelines currently under review:
  • Define pagination guidelines [12]
  • WIP add API capabilities discovery guideline [13]
  • Add the operator for “not in” to the filter guideline [14]
• Full thread

OakTree – A Friendly End-user Oriented API Layer

• The OpenStack summit results of the Interop Challenge shown on stage was awesome. 17 different people from 17 different clouds ran the same workload!
• One of the reasons it worked is because they all used the Ansible modules we wrote based on the Shade library.
  • Shade contains business logic needed to hide vendor difference in clouds.
  • This means that there is a fantastic OpenStack interoperability story – but only if you program in Python.
• OakTree is a gRPC-based APO service for OpenStack that is based on the Shade library.
• Basing OakTree on Shade gets not only the business logic, Shade understands:
  • Multi-cloud world
  • Caching
  • Batching
  • Thundering herd protection sorted to handle very high loads efficiently.
• The barrier to deployers adding it to their clouds needs to be as low as humanly possible.
• Exists in two repositories:
  • openstack/oaktree [15]
  • openstack/oaktreemodel [16]
• OakTree model contains the Protobuf definitions and build scripts to produce Python, C++ and Go code from them.
• OakTree itself depends on python OakTree model and Shade.
  • It can currently list and search for flavors, images, and floating ips.
  • A few major things that need good community design listed in the todo.rst [17]
• Full thread