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/

OpenStack Developer Mailing List Digest September 17-23

Announcing firehose.openstack.org

  • A MQTT based unified message bus for infra services.
  • This allows a single place to go for consuming messages of events from infra services.
  • Two interfaces for subscribing to topics:
    • MQTT protocol on the default port
    • Websockets over port 80
  • Launchpad and gerrit events are the only things currently sending message to firehose, but the plan is to expand this.
  • An example [1] of gerritbot on the consuming side, which has support for subscribing to gerrit event stream over MQTT.
  • A spec giving details on firehose [2].
  • Docs on firehose [3].
  • Full thread

Release countdown for week R-1, 26-30

  • Focus: All teams should be working on release-critical bugs before the final release.
  • General
    • 29th September is the deadline for the new release candidates or release from intermediary projects.
    • Quiet period to follow before the last release candidates on 6th October.
  • Release actions:
    • Projects not following the milestone-based release model who want a stable/newton branch created should talk to the release team.
    • Watch for translation patches and merge them quickly to ensure we have as many user-facing strings translated as possible in the release candidates.
      • If your project has already been branched, make sure those patches are applied to the stable branch.
    • Liaisons for projects with independent deliverables should import the release history by preparing patches to openstack/release.
  • Important Dates:
    • Newton last RC, 29 September
    • Newton final release, 6 October
    • Newton release schedule [4]
  • Full thread

Removal of Security and OpenStackSalt Project Teams From the Big Tent

  • The Security and OpenStackSalt projects are without PTLs. Projects leaderless default to the Technical Committee for decision of what to do with the project [5]. Majority of the Technical Committee has agreed to have these projects removed.
  • OpenStackSalt is a relatively new addition to the Big Tent, so if they got their act together, they could be reproposed.
  • We still need to care about security., and we still need a home for the vulnerability management team (VMT). The suggested way forward is to have the VMT apply to be its own official project team, and have security be a working group.
  • The Mitaka PTL for the Security mentions missing the election date, but provides some things the team has been working on:
    • Issuing Security Notes for Glance, Nova, Horizon, Bandit, Neutron and Barbican.
    • Updating the security guide (the book we wrote on securing OpenStack)
    • Hosting a midcycle and inducting new members
    • Supporting the VMT with several embargoed and complex vulnerabilities
    • Building up a security blog
    • Making OpenStack the biggest open source project to ever receive the Core
    • Infrastructure Initiative Best Practices Badge
    • Working on the OpenStack Security Whitepaper
    • Developing CI security tooling such as Bandit
  • One of the Technical Committee members privately received information that explains why the security PTL was not on top of things. With ~60 teams around there will always be one of two that miss, but here we’re not sure it passes the bar of “non-alignment with the community” that would make the security team unfit to be an official OpenStack Team.
  • Full thread

[1] – http://git.openstack.org/cgit/openstack-infra/gerritbot/commit/?id=7c6e57983d499b16b3fabb864cf3b

[2] – http://specs.openstack.org/openstack-infra/infra-specs/specs/firehose.html

[3] – http://docs.openstack.org/infra/system-config/firehose.html

[4] – http://releases.openstack.org/newton/schedule.html

[5] – http://docs.openstack.org/project-team-guide/open-community.html#technical-committee-and-ptl-elections

OpenStack Developer Mailing List Digest September 10-16

Nominations for OpenStack PTLs Are Now Open

  • Will remain open until September 18 23:45 UTC
  • Submit a text file to the openstack/election repository [1].
    • File name convention: $cycle_name/$project_name/$ircname.txt
  • In order to be an elgible candidate (and be allowed to vote) you need to have contributed an accepted patch to one of the program projects during the Mitaka-Newton timeframe.
  • Additional information [2].
  • Approved candidates [3]
  • Elections will start at September 19, 2016 00:00 UTC until September 25 23:45 UTC
  • Full thread

Ocata Design Summit – Proposed Slot Allocation

  • Proposed slot allocation for project teams at the Ocata design summit in Barcelona [4] based on requests current PTLs have made and adjusted for limit space available.
  • Kendall Nelson and Thierry will start laying out those sessions over the available rooms and time slots.
  • Communicated constraints (e.g. Manila not wanting to overlap with Cinder) should be communicated to Thierry asap.
  • If you don’t plan to use all of your slots, let Thierry know so they can be given to a team that needs them.
  • Start working with your team on content you’d like to cover at the summit and warm up those etherpads!
  • Full thread

OpenStack Principles

  • A set of OpenStack principles is proposed [5] to accurately capture existing tribal knowledge as a prerequisite for being able to have an open and productive discussions about changing it.
  • Last time majority of the Technical Committee were together, it was realized that there were a set of unspoken assumptions carried and used to judge things.
    • These are being captured to empower everyone to actually be able challenge and discuss them.
  • The principles were started by various TC members who have governance history and know these principles. This was in attempt to document this history to commonly asked questions. These are not by any means final, and the community should participate in discussing them.
  • Full thread

API Working Group News

  • Recently merged guidelines
    • URIs [6]
    • Links [7]
    • Version string being parsable [8]
  • Guidelines Under review
    • Add a warning about JSON expectations. [9]
  • Full thread

 

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

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

[3] – http://governance.openstack.org/election/#ocata-ptl-candidates

[4] – http://lists.openstack.org/pipermail/openstack-dev/2016-September/103560.html

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

[6] – https://review.openstack.org/322194

[7] – https://review.openstack.org/354266

[8] – https://review.openstack.org/346846

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

 

OpenStack Developer Mailing List Digest July 23 to August 5

Equal Chances For All Projects

  • A proposal [1] in the OpenStack governance repository that aims to have everything across OpenStack be plugin based, or allow all projects access to the same internal APIs.
  • Some projects have plugin interfaces, but also have project integrations in tree. Makes it difficult to see what a plugin can, and should do.
  • With the big tent, we wanted to move to a flatter model, removing the old integrated status.
  • Examples:
    • Standard command line interface or UI for setting quotas, it’s hard for projects that aren’t Nova, Neutron or Cinder.
      • Quotas in Horizon for example are set in “admin → quotas”, but plugins can’t be in here.
      • OpenStack Client has “openstack quota set –instances 10” for example.
      • Steve Martinelli who contributes to OpenStack Client has verified that this is not by design, but lack of contributor resources).
    • Tempest plugins using unstable resources (e.g. setting up users, projects for running tests on). Projects in tree have the benefit of any change having to pass gate before it merges.
      • Specification to work towards addressing this [2].
      • The stable interface still needs work work in increasing what it exposes to plugins. This requires a bit of work and is prioritized by the QA team.
        • All tests in Tempest consume the stable interface.
      • Since a lot of plugins use the unstable interfaces, the QA team is attempting to maintain backwards compatibility until a stable version is available, which is not always an option.
      • Tempest.lib [3] is what’s considered the “stable interface”
  • Given the amount of in progress work for the examples given, there doesn’t seem a disagreement with the overall goal to warrant a global rule or policy.
  • An existing policy exists [4] with how horizontal teams should work with all projects.
  • Full thread and continued thread

Establishing Project-wide Goals

  • An outcome from the leadership training session that members of the Technical Committee participated in was setting community-wide goals for accomplishing specific technical tasks to get projects synced up.
  • There is a change to the governance repository [5] that sets the expectations of what makes a good goal and how teams are meant to approach working on them.
  • Two goals proposed:
    • Support Python 3.5 [6]
    • Switch to Oslo libraries [7]
  • The Technical Committee wants to set a reasonable number of small goals for a release. Not invasive top-down design mandates that teams would want to resist.
    • Teams could possibly have a good reason for not wanting or being able to fulfill a goal. It just needs to be documented and not result in being removed from the big tent.
  • Full thread

API Working Group News

  • Cinder is lookig into exposing resource capabilities.
  • Guidelines under review:
    • Beginning set of guidelines for URIs [10]
    • Add description of pagination parameters [11]
  • Full thread

Big Tent?

  • Should we consider the big tent is the right approach because of some noticed downsides:
    • Projects not working together because of fear of adding extra dependencies.
    • Reimplementing features, badly, instead of standardizing.
    • More projects created due to politics, not technical reasons.
    • Less cross-project communication.
    • Operator pain in assembling loose projects.
    • Architectural decisions made at individual project level.
  • Specific examples:
    • Magnum trying not to use Barbican.
    • Horizon discussions at the summit wanting to use Zaqar for updates instead of polling, but couldn’t depend on a non-widely deployed subsystem.
    • Incompatible virtual machine communication:
      • Sahara uses ssh, which doesn’t play well with tenant networks.
      • Trove uses rabbit for the guest agent to talk back to the controller.
  • The overall goal of big tent was to make the community more inclusive, and these issues pre-date big tent.
  • The only thing that can really force people to adopt a project is DefCore, but that comes with a major chicken and egg problem.
  • What’s not happening today is a common standard that everything can move towards. Clint Byrum’s proposal on an Architecture working group might be a way forward.
  • The Technical Committee is a balancing act of trying to provide this, but not interfere too much with a project in which members may not have specific experience with the project’s domain.
  • Sahara has had some success with integration with other projects.
    • Kilo/Liberty integrating with Heat for deploying clusters.
    • Liberty/Mitaka integrated Barbican.
    • Using Manila shares for datasources.
    • Liberty/Mitaka added Sahara support in OpenStack Client.
    • In progress, support with Designate.
  • Full thread

 

[1] – https://review.openstack.org/342366

[2] – http://specs.openstack.org/openstack/qa-specs/specs/tempest/client-manager-refactor.html

[3] – http://docs.openstack.org/developer/tempest/overview.html#library
[4] – http://governance.openstack.org/resolutions/20141202-project-structure-reform-spec.html#impact-for-horizontal-teams

[5] – https://review.openstack.org/349068

[6] – https://review.openstack.org/349069

[7] – https://review.openstack.org/349070

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

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

[10] – https://review.openstack.org/#/c/322194/

[11] – https://review.openstack.org/190743

Technical Committee Highlights July 17, 2016

This update is dedicated to our recent in-person training for the Technical Committee and additional community leaders.

Reflections on our Leadership Training Workshop

In mid-July 2016, 20 members of the OpenStack community including Technical Committee members current and past, PTLs current and past, other Community members and additional supporting facilitators met for a 2 day training class at ZingTrain in Ann Arbor Michigan. The ZingTrain team, joined by founder Ari Weinzweig, inspirational IT manager Tim Root, and various members of the Zingerman’s servant leaders shared a unique approach to business that matches OpenStack’s quite well.

Read more »

OpenStack Developer Mailing List Digest July 2-22

SuccessBot Says

  • Notmyname: the 1.5 year long effort to get at-rest encryption in openstack swift has been finished. at-rest crypto has landed in master
  • stevemar: API reference documentation now shows keystone’s in-tree APIs!
  • Samueldemq: Keystone now supports Python 3.5
  • All

Troubleshooting and ask.openstack.org

  • Keystone team wants to do troubleshooting documents.
  • Ask.openstack.org might be the right forum for this, but help is needed:
    • Keystone core should be able to moderate.
    • A top level interface than just tags. The page should have a series of questions and links to the discussions for that question.
  • There could also be a keystone-docs repo that would have:
    • FAQ troubleshooting
    • Install guides
    • Unofficial blog posts
    • How-to guides
  • We don’t want a static troubleshooting guide. We want people to be able to ask questions and link them to answers.
  • Full thread

Leadership Training Recap and Steps Forward

  • Colette Alexander has successfully organized leadership training in Ann Arbor, Michigan.
  • 17 people from the community attended. 8 of them from the TC.
  • Subjects:
    • servant leadership
    • Visioning
    • Stages of learning
    • Good practices for leading organizational change.
  • Reviews and reflections from the training have been overwhelmingly positive and some blogs started to pop up [1].
  • A smaller group of the 17 people after training met to discuss how some ideas presented might help the OpenStack community.
    • To more clearly define and accomplish that work, a stewardship working group has been proposed [2].
  • Because of the success, and 5 TC members weren’t able to attend, Colette is working to arrange a repeating offer.
  • Thanks to all who attended and the OpenStack Foundation who sponsored the training for everyone.
  • Full thread

Release Countdown For Week R-12, July 11-15

  • Focus:
    • Major feature work should be well under way as we approach the second milestone.
  • General notes:
    • We freeze release libraries between the third milestone and final release.
      • Only emergency bug fix updates are allowed during that period.
      • Prioritize any feature work that includes work in libraries.
  • Release actions:
    • Official projects following any of the cycle-based release models should propose beta 2 tags for their deliverables by July 14.
    • Review stable/liberty stable/mitaka branches for needed releases.
  • Important dates:
    • Newton 2 milestone: July 14
    • Library release freeze date starting R-6, Aug 25
    • Newton 3 milestone: September 1
  • Full thread

The Future of OpenStack Documentation

  • Current central documentation
    • Consistent structure
    • For operators and users
    • Some less technical audience use this to evaluate with various other cloud infrastructure offerings.
  • Project documentation trends today:
    • Few are contributing to central documentation
    • More are becoming independent with their own repository documentation.
    • An alarming number just don’t do any.
  • A potential solution: Move operator and user documentation into individual project repositories:
    • Project developers can contribute code and documentation in the same patch.
    • Project developers can work directly or with a liaison documentation team members to improve documentation during development.
    • The documentation team primarily focuses on organization/presentation of documentation and assisting projects.
  • Full thread

 

[1] – http://www.tesora.com/openstack-tc-will-not-opening-deli/

[2] – https://review.openstack.org/#/c/337895/

 

Get a high COA score. Win a Chromebook.

Are you ready to show off your OpenStack skills? The COA high score contest has begun! July 18th through September 11th, COA exam takers with the highest score each week will win a Chromebook from the OpenStack Foundation.

 

Entry is easy:

  1. Go to openstack.org/coa and read the exam materials
  2. Register and schedule your exam!

 

That’s it!
Winners will be notified via email. See the full contest rules below. Good luck!

 

Certified OpenStack Administrator Exam Contest

The Certified OpenStack Administrator Exam Contest (the “Contest”) is designed to encourage eligible individuals (“Entrant(s)” or “You”) to take the Certified OpenStack Administrator Exam (the “Exam”). OpenStack will choose the winner, and the prize will be awarded in accordance with these Official Rules (these “Rules”).

  1. BINDING AGREEMENT: In order to enter the Contest, you must agree to the Rules. Therefore, please read these Rules prior to entry to ensure you understand and agree. You agree that submission of an entry in the Contest constitutes agreement to these Rules. You may not submit an entry to the Contest and are not eligible to receive the prize described in these Rules unless you agree to these Rules. These Rules form a binding legal agreement between you and OpenStack with respect to the Contest.
  2. ELIGIBILITY: To be eligible to enter the Contest, an Entrant must be 18 years of age or older and eligible to take the Exam as set forth in the Exam Handbook (available for download on the Exam Website.  Contest is void where prohibited by law. Employees, directors, and officers of OpenStack and their immediate families (parents, siblings, children, spouses, and life partners of each, regardless of where they live) and members of the households (whether related or not) of such individuals are ineligible to participate in this Contest.
  3. SPONSOR: The Contest is sponsored by OpenStack Foundation (“OpenStack” or “Sponsor”), a Delaware non-stock, non-profit corporation with principal place of business at 1214 West 6th Street, Suite 205 Texas, Austin, TX 78703, USA.
  4. CONTEST PERIOD: The Contest begins on July 18, 2016 when posted to The OpenStack Blog (http://www.openstack.org/blog) and ends on September 11, 2016 11:59 Central Time (CT) Zone (“Contest Period”). All dates are subject to change.
  5. HOW TO ENTER: To enter the Contest, visit the Exam website located at https://www.openstack.org/coa (“Exam Website”) during the Contest Period, click “Get Started,” and follow the prompts to purchase and take the Exam.  You will be automatically entered into the Contest by completing the Exam during the Contest Period.  If you start but do not complete the Exam during the Contest Period, you will not be entered into the Contest. If you do not pass the exam, you will not be entered to win.  Additional entry information is available on The OpenStack Blog.  If you wish to opt out of the Contest, please email us at [email protected] LIMIT ONE (1) ENTRY PER ENTRANT. Subsequent entries will be disqualified.
  6. TAKING THE EXAM: To enter the Contest, you must complete the Exam.  You understand that in addition to these Rules, you must comply with all terms, conditions, rules, and requirements set by OpenStack and the Exam administrators for the Exam.  Information regarding the Exam is available on the Exam Website and in the Exam Handbook.
  7. SCORING: Exams will be scored in accordance with the Exam Handbook, available for download on the Exam Website.  The winner will be the individual that achieves the highest score on the Exam. In the event of a tie, the individual who completed the Exam in the shortest amount of time will be the winner.  For the purposes of the tie-breaker, Exam time will be measured from initial commencement of the Exam to final submission.  Time from purchase of Exam to commencement of Exam will not be considered.
  8. PRIZE: One winner will be selected.  The winner will receive a Toshiba Chromebook 2 – 2015 Edition (CB35-C3350) with an approximate retail value of $350 US Dollars.
  9. TAXES: AWARD OF PRIZE TO POTENTIAL WINNER IS SUBJECT TO THE EXPRESS REQUIREMENT THAT THEY SUBMIT TO OPENSTACK ALL DOCUMENTATION REQUESTED BY OPENSTACK TO PERMIT IT TO COMPLY WITH ALL APPLICABLE STATE, FEDERAL AND LOCAL TAX REPORTING. TO THE EXTENT PERMITTED BY LAW, ALL TAXES IMPOSED ON PRIZES ARE THE SOLE RESPONSIBILITY OF THE WINNER. In order to receive a prize, potential winner must submit tax documentation requested by OpenStack or otherwise required by applicable law, to OpenStack or a representative for OpenStack or the relevant tax authority, all as determined by applicable law. The potential winner is responsible for ensuring that they comply with all the applicable tax laws and filing requirements. If the potential winner fails to provide such documentation or comply with such laws, the prize may be forfeited and OpenStack may, in its sole discretion, select an alternate potential winner.
  10. GENERAL CONDITIONS: All federal, state and local laws and regulations apply. OpenStack reserves the right to disqualify any Entrant from the Contest if, in OpenStack’s sole discretion, it reasonably believes that the Entrant has attempted to undermine the legitimate operation of the Contest or Exam by cheating, deception, or other unfair playing practices or annoys, abuses, threatens or harasses any other entrants, or OpenStack. OpenStack retains all rights in the OpenStack products and services and entry into this Contest will in no case serve to transfer any OpenStack intellectual property rights to the Entrant.
  11. PRIVACY: Entrants agree and acknowledge that personal data submitted with an entry, including name and email address may be collected, processed, stored and otherwise used by OpenStack for the purposes of conducting and administering the Contest. All personal information that is collected from Entrants is subject to OpenStack’s Privacy Policy, located at http://www.openstack.org/privacy. Individuals submitting personal information in connection with the Contest have the right to request access, review, rectification or deletion of any personal data held by OpenStack in connection with the Contest by sending an email to OpenStack at [email protected] or writing to: Compliance Officer, OpenStack Foundation, P.O. Box 1903, Austin, TX 78767.
  12. PUBLICITY: By entering the Contest, Entrants agree to participate in any media or promotional activity resulting from the Contest as reasonably requested by OpenStack at OpenStack’s expense and agree and consent to use of their name and/or likeness by OpenStack. OpenStack will contact Entrants in advance of any OpenStack-sponsored media request.
  13. WARRANTY AND INDEMNITY: Entrants warrant that they will take the Exam in compliance with all terms, conditions, rules, and requirements set forth on the Exam Website and in the Exam Handbook. To the maximum extent permitted by law, Entrant indemnifies and agrees to keep indemnified Sponsor at all times from and against any liability, claims, demands, losses, damages, costs and expenses resulting from any act, default or omission of the Entrant and/or a breach of any warranty set forth herein. To the maximum extent permitted by law, Entrant agrees to defend, indemnify and hold harmless Sponsor from and against any and all claims, actions, suits or proceedings, as well as any and all losses, liabilities, damages, costs and expenses (including reasonable attorney’s fees) arising out of or accruing from: (i) any misrepresentation made by Entrant in connection with the Contest or Exam; (ii) any non-compliance by Entrant with these Rules; (iii) claims brought by persons or entities other than the parties to these Rules arising from or related to Entrant’s involvement with the Contest; (iv) acceptance, possession, misuse or use of any prize or participation in any Contest-related activity or participation in the Contest; (v) any malfunction or other problem with The OpenStack Blog or Exam Website in relation to the entry and participation in the Contest or completion of the Exam by Entrant; (vii) any error in the collection, processing, or retention of entry or voting information in relation to the entry and participation in the Contest or completion of the Exam by Entrant; or (viii) any typographical or other error in the printing, offering or announcement of any prize or winners in relation to the entry and participation in the Contest or completion of the Exam by Entrant.
  14. ELIMINATION: Any false information provided within the context of the Contest by Entrant concerning identity, email address, or non-compliance with these Rules or the like may result in the immediate elimination of the entrant from the Contest.
  15. INTERNET AND DISCLAIMER: OpenStack is not responsible for any malfunction of The OpenStack Blog or Exam Website or any late, incomplete, or mis-graded Exams due to system errors, hardware or software failures of any kind, lost or unavailable network connections, typographical or system/human errors and failures, technical malfunction(s) of any network, cable connections, satellite transmissions, servers or providers, or computer equipment, traffic congestion on the Internet or at The OpenStack Blog or Exam Website, or any combination thereof. OpenStack is not responsible for the policies, actions, or inactions of others, which might prevent Entrant from entering, participating, and/or claiming a prize in this Contest. Sponsor’s failure to enforce any term of these Rules will not constitute a waiver of that or any other provision. Sponsor reserves the right to disqualify Entrants who violate the Rules or interfere with this Contest in any manner. If an Entrant is disqualified, Sponsor reserves the right to terminate that Entrant’s eligibility to participate in the Contest.
  16. RIGHT TO CANCEL, MODIFY OR DISQUALIFY: If for any reason the Contest is not capable of running as planned, OpenStack reserves the right at its sole discretion to cancel, terminate, modify or suspend the Contest. OpenStack further reserves the right to disqualify any Entrant who tampers with the Exam process or any other part of the Contest, Exam, The OpenStack Blog, or Exam Website. Any attempt by an Entrant to deliberately damage any web site, including the The OpenStack Blog or Exam Website, or undermine the legitimate operation of the Contest or Exam is a violation of criminal and civil laws and should such an attempt be made, OpenStack reserves the right to seek damages from any such Entrant to the fullest extent of the applicable law.
  17. FORUM AND RECOURSE TO JUDICIAL PROCEDURES: These Rules shall be governed by, subject to, and construed in accordance with the laws of the State of Texas, United States of America, excluding all conflict of law rules. If any provision(s) of these Rules are held to be invalid or unenforceable, all remaining provisions hereof will remain in full force and effect. Exclusive venue for all disputes arising out of the Rules shall be brought in the state or federal courts of Travis County, Texas, USA and you agree not to bring an action in any other venue. To the extent permitted by law, the rights to litigate, seek injunctive relief or make any other recourse to judicial or any other procedure in case of disputes or claims resulting from or in connection with this Contest are hereby excluded, and Entrants expressly waive any and all such rights.
  18. WINNER’S LIST: The winner will be announced on The OpenStack Blog.  You may also request a list of winners after December 1, 2016 by sending a self-addressed stamped envelope to:

OpenStack Inc.

Attn: Contest Administrator

P.O. Box 1903

Austin, Texas 78767

(Residents of Vermont need not supply postage).

 

OpenStack turns 6: Community focuses on collaboration, growth

July 19 marks the 6th birthday of OpenStack, and we’re celebrating with the entire OpenStack community during July! OpenStack is an integration engine for diverse cloud technologies, fostering collaboration among emerging communities, and none of it would be possible without the quickly growing, global OpenStack community. There are now more than 54,000 community members, over 80 global user groups across 179 countries and more than 600 supporting companies. We think that deserves a worldwide celebration!

OS_6th_Sticker_Blue OS_6th_Sticker_White OS_6th_Sticker_GrayOS_6th_Sticker_A

 

We’ve invited all our user groups to celebrate with us. This month, more than 45 OpenStack birthday parties will be thrown all over the world – celebrating the OpenStack community!  We encourage everyone to find a birthday party in your area and join your fellow community members to toast each other on another great year! Don’t forget to share your pictures and memories using #OpenStack6Bday.

Coming soon! Check out SuperuserTV’s live interviews with user group coordinators around the word about how they are planning on celebrating Open Stack’s 6th Birthday!

Find a local celebration in your area:
Argentina – July 28
Atlanta, Georgia – July 21
Baden-Württemberg, Germany – TBD
Belgium – July 5
Brazil – July 16
Central Florida – July 19
Colorado – July 28
Durban – July 8
Frankfurt, Germany – TBD
Greece – July 13
Guadalajara, Mexico – July 15
Guatemala – July 21
Hong Kong – July 12
Italy – July 18
Japan – July 6-7
Kazan, Russia – July 28
Kentucky – July 28
Los Angeles – July 28
Malaysia – August 10
Manchester, UK – July 27
Minnesota – July 25
Morocco – July 29
Munich – July 19
Nairobi – July 16
New York City – July 13
Nigeria – July 8
North Carolina – July 21
Northern Virginia (NOVA) – July 28
Pakistan – July 27
Paris, France – July 5
Philadelphia, Pennsylvania – July 28
Romania – July 14
Philippines – July 22
San Francisco, California – July 14**
South Korea – July 21
St. Louis, Missouri – July 21
Sweden – July 6
Switzerland – July 7
Thailand – July 27-28 (tutorials); July 29 (launch party)
Toulouse, France – July 4
Tunisia – July 28
Turkey – July 13
Vietnam – July 30
Virginia – July 18
Washington DC – July 18