OpenStack Developer Mailing List Digest March 18-24

SuccessBot Says

  • Yolanda [1]: Wiki problems have been fixed, it’s up and running
  • johnthetubaguy [2]: First few patches adding real docs for policy have now merged in Nova. A much improved sample file [3].
  • Tell us yours via OpenStack IRC channels with message “#success <message>”
  • All: [4]

Release Naming for R

  • It’s time to pick a name for our “R” release.
  • The assoicated summit will be in Vancouver, so the geographic location has been chosen as “British Colombia”.
  • Rules:
    • Each release name must start with the letter of the ISO basic Latin alphabet following the initial letter of the previous release, starting with the initial release of “Austin”. After “Z”, the next name should start with “A” again.
    • The name must be composed only of the 26 characters of the ISO basic Latin alphabet. Names which can be transliterated into this character set are also acceptable.
    • The name must refer to the physical or human geography of the region encompassing the location of the OpenStack design summit for the corresponding release. The exact boundaries of the geographic region under consideration must be declared before the opening of nominations, as part of the initiation of the selection process.
    • The name must be a single word with a maximum of 10 characters. Words that describe the feature should not be included, so “Foo City” or “Foo Peak” would both be eligible as “Foo”.
  • Full thread [5]

Moving Gnocchi out

  • The project Gnocchi which has been tagged independent since it’s inception has potential outside of OpenStack.
  • Being part of the big tent helped the project be built, but there is a belief that it restrains its adoption outside of OpenStack.
  • The team has decided to move it out of OpenStack [6].
    • In addition out of the OpenStack infrastructure.
  • Gnocchi will continue thrive and be used by OpenStack such as Ceilometer.
  • Full thread [7]

POST /api-wg/news

  • Guides under review:
    • Define pagination guidelines (recently rebooted) [8]
    • Create a new set of api stability guidelines [9]
    • Microversions: add next_min_version field in version body [10]
    • Mention max length limit information for tags [11]
    • Add API capabilities discovery guideline [12]
    • WIP: microversion architecture archival doc (very early; not yet ready for review) [13]
  • Full thread [14]

 

OpenStack Developer Mailing List Digest March 11-17

SuccessBot Says

  • Dims [1]: Nova now has a python35 based CI job in check queue running Tempest tests (everything running on py35)
  • jaypipes [2]: Finally got a good functional test created that stresses the Ironic and Nova integration and migration from Newton to Ocata.
  • Lbragstad [3]: the OpenStack-Ansible project has a test environment that automates rolling upgrade performance testing
  • annegentle [4]: Craig Sterrett and the App Dev Enablement WG: New links to more content for the appdev docs [5]
  • jlvillal [6]: Ironic team completed the multi-node grenade CI job
  • Tell us yours via OpenStack IRC channels with message “#success <message>”
  • All: [7]

Pike Release Management Communication

  • The release liaison is responsible for:
    • Coordinating with the release management team.
    • Validating your team release team requests.
    • Ensure release cycle deadlines are met.
    • It’s encouraged to nominate a release liaison. Otherwise this tasks falls back to the PTL.
  • Ensure the releaase liaison has time and ability to handle the communication necessary.
    • Failing to follow through on a needed process step may block you from meeting deadlines or releasing as our milestones are date-based, not feature-based.
  • Three primary communication tools:
    • Email for announcements and asynchronous communication
      • “[release]” topic tag on the openstack-dev mailing list.
      • This includes the weekly release countdown emails with details on focus, tasks, and upcoming dates.
    • IRC for time sensitive interactions
      • With more than 50 teams, the release team relies on your presence in the freenode #openstack-release channel.
    • Written documentation for relatively stable information
      • The release team has published the schedule for the Pike cycle [8]
      • You can add the schedule to your own calendar [9]
  • Things to do right now:
    • Update your release liaisons [10].
    • Make sure your IRC and email address listed in projects.yaml [11].
  • Update your mail filters to look for “[release]” in the subject line.
  • Full thread [12]

OpenStack Summit Boston Schedule Now Live!

  • Main conference schedule [13]
  • Register now [14]
  • Hotel discount rates for attendees [15]
  • Stackcity party [16]
  • Take the certified OpenStack Administrator exam [17]
  • City guide of restaurants and must see sites [18]
  • Full thread [19]

Some Information About the Forum at the Summit in Boston

  • “Forum” proper
    • 3 medium sized fishbowl rooms for cross-community discussions.
    • Selected and scheduled by a committee formed of TC and UC members, facilitated by the Foundation staff members.
    • Brainstorming for topics [20]
  • “On-boarding” rooms
    • Two rooms setup classroom style for projects teams and workgroups who want to on-board new team members.
    • Examples include providing introduction to your codebase for prospective new contributors.
    • These should not be tradiitonal “project intro” talks.
  • Free hacking/meetup spaces
    • Four to five rooms populated with roundtables for ad-hoc discussions and hacking.
  • Full thread [21]

 

The Future of the App Catalog

  • Created early 2015 as a market place of pre-packaged applications [22] that you can deploy using Murano.
  • This has grown to 45 Glance images, 13 Heat templates and 6 Tosca templates. Otherwise did not pick up a lot of steam.
  • ~30% are just thin wrappers around Docker containers.
  • Traffic stats show 100 visits per week, 75% of which only read the index page.
  • In parallel, Docker developed a pretty successful containerized application marketplace (Docker Hub) with hundreds or thousands regularly updated apps.
    • Keeping the catalog around makes us look like we are unsuccessfully trying to compete with that ecosystem, while OpenStack is in fact complimentary.
  • In the past, we have retired projects that were dead upstream.
    • The app catalog is however has an active maintenance team.
    • If we retire the app catalog, it would not be a reflection on that team performance, but that the beta was arguably not successful in build an active market place and a great fit from a strategy perspective.
  • Two approaches for users today to deploy docker apps in OpenStack:
    • Container-native approach using “docker run” after using Nova or K8s cluster using Magnum.
    • OpenStack Native approach “zun create nginx”.
  • Full thread [23][24]

ZooKeeper vs etcd for Tooz/DLM

  • Devstack defaults to ZooKeeper and is opinionated about it.
  • Lots of container related projects are using etcd [25], so do we need to avoid both ZooKeeper and etcd?
  • For things like databases and message queues, it’s more than time for us to contract on one solution.
    • For DLMs ZooKeepers gives us mature/ featureful angle. Etcd covers the Kubernetes cooperation / non-java angle.
  • OpenStack interacts with DLM’s via the library Tooz. Tooz today only supports etcd v2, but v3 is planned which would support GRPC.
  • The OpenStack gate will begin to default to etcd with Tooz.
  • Full thread [26]

Small Steps for Go

  • An etherpad [27] has been started to begin tackling the new language requirements [28] for Go.
  • An golang-commons repository exists [29]
  • Gopher cloud versus having a golang-client project is being discussed in the etherpad. Regardless we need support for os-client-config.
  • Full thread [30]

POST /api-wg/news

  • Guidelines under review:
    • Add API capabilities discovery guideline [31]
    • Refactor and re-validate API change guidelines [32]
    • Microversions: add next_min_version field in version body [33]
    • WIP: microversion architecture archival doc [34]
  • Full thread [35]

Proposal to Rename Castellan to oslo.keymanager

  • Castellan is a python abstraction to different keymanager solutions such as Barbican. Implementations like Vault could be supported, but currently is not.
  • The rename would emphasize the Castellan is an abstraction layer.
    • Similar to oslo.db supporting MySQL and PostgreSQL.
  • Instead of oslo.keymanager, it can be rolled into the oslo umbrella without a rename. Tooz sets the precedent of this.
  • Full thread [36]

Release Countdown for week R-23 and R-22

  • Focus:
    • Specification approval and implementation for priority features for this cycle.
  • Actions:
    • Teams should research how they can meet the Pike release goals [37][38].
    • Teams that want to change their release model should do so before end of Pike-1 [39].
  • Upcoming Deadlines and Dates
    • Boston Forum topic formal submission period: March 20 – April 2
    • Pike-1 milestone: April 13 (R-20 week)
    • Forum at OpenStack Summit in Boston: May 8-11
  • Full thread [40]

Deployment Working Group

  • Mission: To collaborate on best practices for deploying and configuring OpenStack in production environments.
  • Examples:
    • OpenStack Ansible and Puppet OpenStack have been collaborating on Continuous Integration scenarios but also on Nova upgrades orchestration
    • TripleO and Kolla share the same tool for container builds.
    • TripleO and Fuel share the same Puppet OpenStack modules.
    • OpenStack and Kubernetes are interested in collaborating on configuration management.
    • Most of tools want to collect OpenStack parameters for configuration management in a common fashion.
  • Wiki [41] has been started to document how the group will work together. Also an etherpad [42] for brainstorming.

 

Helping PTG attendees and other developers get to the OpenStack Summit

Although the OpenStack design events have changed, developers and operators still have a critical perspective to bring to the OpenStack Summits. At the PTG, a common whisper heard in the hallways was, “I really want to be at the Summit, but my [boss/HR/approver] doesn’t understand why I should be there.” To help you out, we took our original “Dear Boss” letter and made a few edits for the PTG crowd. If you’re a contributor or developer who wasn’t able to attend the PTG, with a few edits, this letter can also work for you. (Not great with words? Foundation wordsmith Anne can help you out–anne at openstack.org)

 

Dear [Boss],

 

I would like to attend the OpenStack Summit in Boston, May 8-11, 2017. At the Pike Project Team Gathering in Atlanta (PTG), I was able to learn more about the new development event model for OpenStack. In the past I attended the Summit to participate in the Design Summit, which encapsulated the feedback and planning as well as design and development of creating OpenStack releases. One challenge was that the Design Summit did not leave enough time for “head down” work within upstream project teams (some teams ended up traveling to team-specific mid-cycle sprints to compensate for that). At the Pike PTG, we were able to kickstart the Pike cycle development, working heads down for a full week. We made great progress on both single project and OpenStack-wide goals, which will improve the software for all users, including our organization.

 

Originally, I––and many other devs––were under the impression that we no longer needed to attend the OpenStack Summit. However, after a week at the PTG, I see that I have a valuable role to play at the Summit’s “Forum” component. The Forum is where I can gather direct feedback and requirements from operators and users, and express my opinion and our organization’s about OpenStack’s future direction. The Forum will let me engage with other groups with similar challenges, project desires and solutions.

 

While our original intent may have been to send me only to the PTG, I would strongly like us to reconsider. The Summit is still an integral part of the OpenStack design process, and I think my attendance is beneficial to both my professional development and our organization. Because of my participation in the PTG, I received a free pass to the Summit, which I must redeem by March 14.      

 

Thank you for considering my request.
[Your Name]

The OpenStack Summit is returning to Vancouver in May 2018

Back by popular demand, the OpenStack Summit is returning to Vancouver, Canada from May 21-24, 2018. Registration, sponsorship opportunities and more information for the 17th OpenStack Summit will be available in the upcoming months. 

Can’t wait until 2018? Brush up on your OpenStack skills in 2017 by registering to attend the OpenStack Summit Boston, May 8-11 and marking your calendar for the OpenStack Summit Sydney, November 6-8.

For news on new and upcoming OpenStack Summits, visit openstack.org/summit. 

Photos from the 2015 OpenStack Summit Vancouver

 

 

 

User Group Newsletter February 2017


Welcome to 2017! We hope you all had a lovely festive season. Here is our first edition of the User Group newsletter for this year.

AMBASSADOR PROGRAM NEWS

2017 sees some new arrivals and departures to our Ambassador program. Read about them here.

 

WELCOME TO OUR NEW USER GROUPS

We have some new user groups which have joined the OpenStack community.

Bangladesh

Ireland – Cork

Russia – St Petersburg

United States – Phoenix, Arizona

Romania – Bucharest

We wish them all the best with their OpenStack journey and can’t wait to see what they will achieve!

Looking for a your local group? Are you thinking of starting a user group? Head to the groups portal for more information.


MAY 2017 OPENSTACK SUMMIT

We’re going to Boston for our first summit of 2017!!

You can register and stay updated here.

Consider it your pocket guide for all things Boston summit. Find out about the featured speakers, make your hotel bookings, find your FAQ and read about our travel support program.

 

NEW BOARD OF DIRECTORS
The community has spoken! A new board of directors has been elected for 2017.
Read all about it here. 


MAKE YOUR VOICE HEARD!
Submit your response the latest OpenStack User Survey!
All data is completely confidential. Submissions close on the 20th of February 2017.
You can complete it here. 

CONTRIBUTING TO UG NEWSLETTER

If you’d like to contribute a news item for next edition, please submit to this etherpad.
Items submitted may be edited down for length, style and suitability.
This newsletter is published on a monthly basis. 

Tags:

Supporting our global community

OpenStack is a global open source community. The OpenStack Foundation serves members in 180 countries focused on advancing the capabilities and accessibility of open infrastructure everywhere. We fundamentally believe diversity and collaboration are a powerful force for innovation, and it has been amazing to see the product of tens of thousands of people around the world over the last 6+ years.

Lauren, Mark and I disagree with the executive order issued by President Trump that targets individuals from 7 countries. The order restricts the travel and movement of people in a discriminatory way that  results in a restriction on access to talent and ideas. It is still unclear how the policies will play out and be enforced, but we will be watching, advocating for and supporting our community members to the best of our ability.

This executive order will not impact the governance of the Foundation or the way the community operates globally. We will continue to support user groups and community members that are active in the seven countries named by the executive order, alongside our 120+ user groups around the world. However, we have two scheduled events in the United States within the next six months that will attract a global audience: the PTG (Project Teams Gathering) in Atlanta, Feb 20-24, a smaller event that will bring together hundreds of upstream contributors, and the OpenStack Summit in Boston, May 8-11, our larger event that happens every six months.

This executive order could impact some community members ability to travel to Atlanta and Boston, but unfortunately it is too late at this point to change the location of these events. The following three OpenStack Summits, however, are now scheduled to occur outside of the United States. The next Summit will be in November 2017 in Sydney, Australia and we are working to finalize the details so we can announce the following two Summit locations soon.

We’ve already heard from one community member, Mohammed Naser, who is concerned that his plans to travel from Canada to Atlanta to attend the PTG may be restricted, simply because he a dual citizen of Canada and Iraq.  Mohammed has been contributing code to OpenStack since 2011 and is the CEO and Founder of Vexxhost. Blocking his travel would serve no purpose and rob the community of a valuable contributor during an important event. If you are concerned about the impact or have any questions, please don’t hesitate to reach out to me at [email protected]

Political actions like this highlight the importance of our collective values. The Four Opens, the founding principles of our community, exist to ensure the free flow of talent and ideas, across geographic, national, organizational or other lines that might divide us. We believe in humanity. We believe in opportunity. We believe in the power of collaboration across borders, and we will continue to carry forward our mission.

Jonathan Bryce
Mark Collier
Lauren Sell

This blog post has now been translated into Korean by Sungjin Kang, a member of the OpenStack community in Korea.

OpenStack Developer Mailing List Digest January 21-27

SuccessBot Says

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

Get Active in Upstream Training

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

Project Team Gathering Coordination Tool

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

POST /api-wg/news

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

Lots of Teams Without PTL Candidates

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

OpenStack Developer Mailing List Digest January 14-20

SuccessBot Says

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

FIPS Compliance

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

Refreshing and Revalidating API Compatibility Guidelines

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

Base Services

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

Improving Vendor Discoverability

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

Nominations for OpenStack PTLs Are Now Open!

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

The Process of Creating stable/ocata branches

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

Why Are Projects Trying To Avoid Barbican, Still?

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

POST /api-wg/news

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

Release Countdown for Week R-4 Jan 23-27

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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