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

  • 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

 

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

 

OpenStack Developer Mailing List Digest October 8-14

SuccessBot Says

  • loquacities: Newton docs are live on docs.openstack.org! Way to go docs team \o/
  • dhellmann: OpenStack Newton is officially released!
  • tristanC: 6 TC members elected for Ocata [1].
  • dulek: Cinder gate is now voting on basic rolling upgrades support. One step closer to get assert:supports-rolling-upgrade tag. 🙂
  • More

Thoughts on the TC Election Process

  • When deciding to run, candidates write a long thoughtful essay on their reasons for wanting to serve on the TC.
    • It is rare for anyone to ask follow-up question, or to challenge the candidates to explain their position more definitively.
    • Some people pick by names they are most familiar with and don’t read those candidacy posts.
    • It is believed that it’s rare for someone who hasn’t been a PTL of a large project to be elected.
    • An example of implicit bias, blind auditions for musical orchestras radically changing the selection results [2].
  • Proposal: have candidates self-nominate, but instead of a long candidacy letter, just state their interests in serving.
    • After nominations close, the election officials will assign each candidate with a  non-identifying label (e.g. random number).
    • Candidates will post their thoughts and positions and respond to questions from people.
    • Candidacy essay would be posted in the campaign period, instead of the nomination period. This will exclude biographical information.
    • Perhaps candidates can forward their responses to election officials, who will post them for the candidates and identify only by candidate number.
    • The voting form will only list the candidates’ numbers.
  • Thoughts on the proposal:
    • Not allowing people to judge peoples’ character introduces a fraud incentive. You can tell friends your number secretly. Their implicit bias will make them think this is morally ok, and make them more likely to vote for you.
    • It can be important to identify candidates. For some people, there’s a difference in what they say, and what they end up doing when left calling the shots.
    • Familiarity doesn’t necessarily equal bias. Trust is not bias.
    • A good example [2] of needing to know the speaker and words came out of the thread. Also a reason why anonymous elections for leaders are a bad idea and favor native English speakers.
  • We need several things:
    • Allow time between the nomination and the voting. Some candidates don’t announce until the last day or two. This doesn’t allow much time to get to know them.
    • How to deal with timezone differences. One candidate may post an answer early and get more reaction.
    • Reduce the effect of incumbency.
  • The comparison of orchestra auditions was brought up a couple of cycles ago as well, but could be a bad comparison. The job being asked of people was performing their instrument, and it turns out a lot of things not having to do with performing their instrument were biasing the results.
    • The job of the TC is:
      • Putting the best interests of OpenStack at heart.
      • Be effective in working with a diverse set of folks in our community to get things done.
      • To find areas of friction and remove them.
      • Help set the overall direction for the project that community accepts.
    • Writing a good candidacy email isn’t really good representation of those abilities. It’s the measure of writing a good candidacy email, in English.
  • Sean Dague hopes that when voters vote in the election that they are taking the reputation of individuals into account.
    • Look at the work they did across all of OpenStack.
    • How they got consensus on items.
    • What efforts they are able to get folks to rally around and move forward.
    • When they get stuck and get unstuck.
    • When they ask for help and/or admit they’re out of their element.
    • How they help new folks.
    • How they work with long timers.
    • It’s easy to dismiss it as a popularity contest, however, this is about evaluating the plausible promise that the individuals put forward. Not just ideas they have, but how likely they are to be able to bring them to fruition.
  • Full thread

API Workgroup News

  • API usability tests being conducted at the Barcelona summit [3].
  • Two lively discussions [4]:
    • Collecting and improving error messages across OpenStack.
    • Request semantics with regards to GET and body processing.
  • New guidelines:
    • Add a warning about JSON expectations [5].
  • Guidelines currently under review:
    • Specify time intervals based filtering queries [6].
  • Full thread

Project Teams Gathering from the Ops Perspective

  • The first PTG will be held February 20-24 in Atlanta, GA at the downtown Sheraton hotel.
  • Tickets are $100.
  • Group rate is $185/night.
  • Registration will go live in the next couple of weeks.
  • Horizontal/cross project teams will meet Monday and Tuesday.
  • Vertical projects will meet Wednesday through Friday.
  • There’s a lot of great planning happening around the PTG planning, however, it’s going take some time for operators to figure it out.
  • Tom Fifield gives some notes for the operators:
    • Check out the diagram on the PTG site [7].
      • We’re finally acknowledging a release cycle starts with planning. Now we’ll be finalizing a release, while planning another.
      • This puts the summit at the right place to get feedback and decent ideas from users.
    • The OpenStack summit is the place the entire community gets together.
      • The PTG doesn’t mean the summit becomes a marketing thing. The summit can also include:
        • Pre-spec brainstorming
        • Feedback with users
        • Be involved in strategic direction.
    • Don’t expect Ops at the PTG
      • The PTG has been designed for space to get stuff done. Unless a user is deep in code, they won’t be there. If you want feedback from users, use the summit.
  • For ops-focused teams like Kolla, participating at OpenStack summits and Ops mid cycles are essential. Not everyone has to go to every event though. These teams should organize who is going to what events.
  • If you’re going to the summit in Barcelona, Thierry and Erin from the OpenStack Foundation will be hosting informational presentation on the PTG [8].
  • Full thread

Next PTL/TC Elections Timeframes

  • At the last TC meeting, TC members discussed future election period, with consideration of the OpenStack Summit and Project Teams Gathering.
  • The TC charter which uses “Design Summit” and “Summit” interchangeably is no longer valid and requires change.
    • There was a focus on limiting the impact change to avoid the need to modify the Foundation bylaws [9].
    • PTL elections would continue to be organized around development cycle boundaries.
    • TC elections would continue to be organized relative to OpenStack Summit dates.
  • Full thread

Running Non-Devstack Jobs in Python Projects

  • Devstack is the common tool to deploy OpenStack in CI environments.
    • However, it doesn’t deploy OpenStack in production versus tools like Kolla, Fuel, TripleO, etc.
  • Things might (and did) break when deploying OpenStack outside of Devstack:
    • SSL was not tested. Some projects still don’t test with SSL enabled.
    • IPv6 is not tested everywhere.
    • Production scenarios with HA (HAproxy and/or Pacemaker) are not tested.
  • Proposal:
    • This is not about removing Devstack. The idea is to add more coverage in an interactive way.
    • Projects like TripleO and Heat have been added as CI jobs in the experimental pipeline.
    • A draft document about increasing coverage in different projects [10].
  • Finding a balance between enough testing and overusing infra resources is tricky.
    • Also anything that’s more complicated than unit tests has > 0% chance of failure.
  • Another proposal:
    • Running periodic testing and moving forward reference hashes everyday if tests pass.
      • Allows deployment tools to move forward automatically.
      • Quite close to master, but not tightly coupled into every change.
      • This is pretty much what the OpenStack-Ansible project does for its “integrated build”.
  • Full thread

 

[1] – http://lists.openstack.org/pipermail/openstack-dev/2016-October/105299.html

[2] – http://blog.leafe.com/bias/

[3] – https://wiki.openstack.org/wiki/UX#Participate_in_a_usability_study_being_conducted_at_the_Barcelona_Summit.21

[4] – http://eavesdrop.openstack.org/meetings/api_wg/

[5] – https://review.openstack.org/#/c/364460/

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

[7] – https://www.openstack.org/ptg

[8] – https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/17383/project-teams-gathering-101

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

[10] – https://docs.google.com/spreadsheets/d/1bLg-uEGrQXyRZ-FuR6pf1WT4XN0-6MrlfqEShI7xMxg/edit#gid=0

OpenStack Developer Mailing List Digest September 24-30

Candidate Proposals for TC are now open

  • Candidate proposals for the Technical committee (6 positions) are open and will remain open until 2016-10-01, 23:45 UTC.
  • Candidacies must submit a text file to the openstack/election repository [1].
  • Candidates for the Technical Committee can be any foundation individual member, except the seven TC members who were elected for a one year seat in April [2].
  • The election will be held from October 3rd through to 23:45 October 8th.
  • The electorate are foundation individual members that are committers to one of the official programs projects [3] over the Mitaka-Newton timeframe (September 5, 2015 00:00 UTC to September 4, 2016 23:59 UTC).
  • Current accepted candidates [4]
  • Full thread

Release countdown for week R-0, 3-7 October

  • Focus: Final release week. Most project teams should be preparing for the summit in Barcelona.
  • General notes:
    • Release management team will tag the final Newton release on October 6th.
      • Project teams don’t have to do anything. The release management team will re-tag the commit used in the most recent release candidate listed in openstack/releases.
    • Projects not following the milestone model will not be re-tagged.
    • Cycle-trailing projects will be skipped until the trailing deadline.
  • Release actions
    • Projects not follow the milestone-based release model who want stable/newton branches created should talk to the release team about their needs. Unbranched projects include:
      • cloudkitty
      • fuel
      • monasca
      • openstackansible
      • senlin
      • solum
      • tripleo
  • Important dates:
    • Newton final release: October 6th
    • Newton cycle-trailing deadline: October 20th
    • Ocata Design Summit: October 24-28
  • Full thread

Removal of Security and OpenStackSalt Project Teams From the Big Tent (cont.)

  • The change to remove Astara from the big tent was approval by the TC [4].
  • The TC has appointed Piet Kruithof as PTL of the UX team [5].
  • Based on the thread discussion [6] and engagements of the team, the Security project team will be kept as is and Rob Clark continuing as PTL [7].
  • The OpenStackSalt team did not produce any deliverable within the Newton cycle. The removal was approved by the current Salt team PTL and the TC [8].
  • Full thread

 

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

[2] – https://wiki.openstack.org/wiki/TC_Elections_April_2016#Results

[3] – http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=sept-2016-elections

[4] – https://review.openstack.org/#/c/376609/

[5] – http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-09-27-20.01.html

[6] – http://lists.openstack.org/pipermail/openstack-dev/2016-September/thread.html#104170

[7] – http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-09-27-20.01.html

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