OpenStack Developer Mailing List Digest January 7-13

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

OpenStack Developer Mailing List Digest December 31 – January 6

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

 

OpenStack Developer Mailing List Digest December 17-23

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/

OpenStack Developer Mailing List Digest December 10- 16

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

OpenStack Developer Mailing List Digest December 3 – 9

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

“Dear Boss, I want to attend the OpenStack Summit”

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]

OpenStack Developer Mailing List Digest November 26 – December 2

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]

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

OpenStack Developer Mailing List Digest November 18-25th

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/

OpenStack Developer Mailing List Digest November 5-18

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

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

 

OpenStack Developer Mailing List Digest October 29 to November 4

Cross Project Proprietary Driver Code Recap

  • At the Barcelona design summit there was a cross-project session on the challenge we’re running where to draw the line with proprietary driver code [1].
  • Option 1:
    • All libraries imported by the driver must be licensed such that they are redistributable by package maintainers and must be compatible with the Apache license [2].
    • Existing non-compliant driver code would need to be updated by Queens release.
    • Code that’s not imported at the driver runtime (CLIs, external binaries, remote application servers) are acceptable to not be redistributable.
  • Option 2:
    • Remove all drivers that are not completely open source and contained in the project repositories.
  • Option 3:
    • Require majority of the business logic is in the open source code.
    • Allow third party, non-redistributable libraries and CLIs that are used as more of an “RPC” type interface.
    • Reviewers should be able to review the driver and at least get some idea of the steps the driver is doing to perform requests.
  • Jeremy Stanley would like to take option 1 a step further and provide better guidance. We should recommend against drivers calling proprietary tools. Some vendors go this route because they already have a non-free CLI tool and avoid code cost duplication. Other vendors may do this to copy other vendors.
    • The desire of having things redistributable is so that downstream consumers of OpenStack are not beholden to vendors just to be able to use our (free!) software with hardware they have.
    • For example
      • Vendor decides to stop supporting a proprietary command line tool
      • You decide to stop paying support contracts to download that tool
      • Vendor disappears
  • Full thread

Ocata Release Management Communication

  • To the PTL’s or or volunteers filling in for a PTL:
  • Email
    • The “[release]” topic tag on the openstack-dev mailing list will be used for important messages.
    • Countdown email with updates on focus, tasks, and upcoming dates.
  • IRC
    • Be available on #openstack-release, especially during deadline periods. It’s up to you to configure an IRC bouncer to ensure this.
  • Written documentation
    • Read the Ocata cycle schedule [3].
    • Some projects have their own deadlines. Feel free to submit a patch to this schedule within the openstack/release repository.
  • The Ocata cycle overlaps with several major holidays. If you’re planning time off, please make sure your duties are covered by someone else on your team. Let the release team know about this so they’re not waiting for your +1.
  • Failing to follow through on a needed process step may block you from successfully meeting deadlines or releasing.
  • Releases milestones and deadlines are date-based, not feature based. When the date passes, so does the milestone. If you miss it, you miss it.
  • Full thread

Release Announcements

  • The release team at the Barcelona summit discussed how to improve release announcements as posting them to openstack-dev and openstack-announce has proven to be pretty noisy.
  • Proposed solution is to move these announcements to another mailing list. Choices are:
    • release-announce
    • release-announcements
  • Full thread

POST /api-wg/news

  • API guidelines that will be merged in one week if there is no further feedback:
    • Complex queries [4]
    • Specify time intervals based filtering queries [5]
    • Clarify why CRUD is not a great descriptor [6]
  • Guidelines under review:
    • Define pagination guidelines [7]
    • Add API capabilities discovery [8]
  • Full thread

Release Countdown for Week R-15

  • Focus:
    • Teams should be focusing on wrapping up incomplete work left over from the end of the Newton cycle.
    • Finalizing and announcing plans from the summit
    • Completing specs and blueprints
  • General notes:
    • Stable and independent releases have resumed.
    • We cut time out of the Ocala schedule before the first milestone. Ocata-1 will be during R-14.
  • Release actions:
    • Release liaisons should add their name and contact information to the wiki [9].
    • Release liaisons should configure their IRC clients to join #openstack-release.
    • Release liaisons should review the release models for all deliverables and make any updates with patches to openstack/governance before the first milestone.
    • PTLs should add their acknowledgement of the Ocala series community goal [10]
  • Important dates:
    • Ocata 1 Milestone: 17 Nov
    • Ocata release schedule [11]
  • Full thread