SuccessBot Says

• clarkb 1 : infra added city cloud to the pool of test nodes.
• pabelanger 2 : opensuse-422-infracloud-chocolate-8977043 launched by nodepool.
• All: 3

etcd 3.x as a Base Service

• A devstack review 4 that adds a new etcd3 service.
• Two options to enable the DLM use case with Tooz (for eventless based services) 5 6
• Full thread: 7

Do We Want to be Publishing Binary Container Images?

• During the Forum, the discussion on collaboration between various teams building or consuming container images.
• Decide how to publish images from the various teams to docker hub or other container registries.
• The community has refrained from publishing binary packages in other formats such as debs and RPMs. Instead we have left this to the responsibility of the downstream consumers to build production packages.
• This would require more tracking of upstream issues (bugs, CVEs, etc) to ensure the images are updated as needed.
  • Given our security and stable team resources, this might not be a good idea at this time.
• Kolla is interested in doing this for daily builds. Everything is licensed with ASL which gives no guarantees.
  • Even if you mark something to not be used in production, people still use it. Take the recent user survey with DevStack being used in production.
  • Kolla today publishes build instructions. Manually every release they provide built containers.
  • Built containers would run through our CI gate, so others don’t have to have a local CI build pipeline.
• Things we publish to Pypi are different from this proposal:
  • The formats published by pypi are source formats (sdist) and developer friend but production ready format (wheel).
  • Most of our services are not packaged and published to PyPi. The libraries are to make them easy to consume in our CI.
  • The artifacts in PyPi contain references to dependencies, the dependencies are not built into the packages themselves.
• Iterating on the infra-spec review for publishing to DockerHub has started 8
• Full thread: 9

RFC Cross Project Request ID Tracking

• In the logging Forum session, it was brought up how much effort operators are having to put into reconstructing flows for things like server boot when they go wrong.
  • Jumping from service to service, the request-id is reset to something new.
  • Being able to query in elastic search for the same request-id in communication between services would be useful.
• There is a concern of trusting the request-id on the wire, because it’s coming from a random user.
  • We have a new concept of “service users” which are set of higher privilege services that we are using to wrap user requests.
• Basic idea is:
  • services will optionally take an inbound X-OpenStack-Request-ID which we’ll strongly validate req-$uuid format.
    • They will continue to generate one as well.
    • When the context is built we’ll check the service user was involved, and if not, reset the request-id to the local generated one.
    • Both request-ids will be logged.
  • Python clients and callers will need to be augmented to pass the request-id in on requests.
  • Servers will opt into calling other services this way.
• Oslo spec for this has been merged 10.
• Full thread: 11

Can We Stop Global Requirements Update (Cont.)

• Gnocchi has gate issues with Babel this time. Julien plans to remove all oslo dependencies over the next few months.
• The project Cotyledon was presented at some summit ago as an alternative to oslo.service and getting rid of eventless. The library lives under the telemetry umbrella for now.
  • The project doesn’t live under oslo so that it’s encouraged for the greater python ecosystem to adopt and help maintain it.
• Octavia is also using Cotyledon.
• Full thread: 12

Revised Postgresql Deprecation Patch for Governance

• In the Forum session we agreed to the following:
  • Explicitly warn in operator facing documentation Postresql is less supported than MySQL.
  • Sure is the process of investigating migration from Postgresql to Gallera for future versions of OpenStack products.
  • TC governance patch is updated 13.
• Current sticking points:
  • It’s important that the operator community largely is already in one camp or not.
  • Future items listed that are harder are important enough to justify a strict trade off here.
  • It’s ok to have the proposal have a firm lean in tone, even though it’s set of concrete actions are pretty reversible and don’t commit to future removal of Postgresql.
• What has been raised as being hard by an abstraction layer like SQLAlchemy:
  • OpenStack services taking a more active role in managing DBMS.
    • See Active or passive role with our database layer summary below for this discussion.
  • The ability to have zero down time upgrade for services such as Keystone.
    • Expand/contract with code and carefully dancing around the existence of two schema concepts simultaneously (e.g. Nova and Neutron).
    • This shouldn’t be a problem because we use alembic or sqlalchemy-migrate to abstract away ALTER TABLE types.
    • Expand/contract using server side triggers to reconcile the two schema. This is more difficult because there is no abstraction layer that exists in SQLAlchemy. It could be feasible to build one specific to OpenStack.
  • Consistent UTF-8 4 & 5 byte support in our APIs
    • Unicode itself only needs 4 bytes and that is as far as any database supports right now. This problem has been solved by SQLAlchemy well before Python 3 existed.
  • The requirement that Postgresql libraries are compiled for new users trying to just run unit tests.
    • New developers who aren’t concerned with Postgresql don’t have to run these tests.
    • OpenStack went all the way with Kilo using the native python-MySQL driver which required compiling.
    • This is OpenStack. We are the glue to thousands of c-compiled libraries and packages.
  • Consistency around case sensitivity collation.
    • MySQL is defaulting to case-insensitive.
    • Postgresql almost has no support for case-insensitive.
    • SQLAlchemy supports things like ilike().
    • String datatype in SQLAlchemy guarantees case-insensitive.
• Top concerns that remain:
  • A1) Do not surprise users late by them only finding out they are on less traveled once they are so deeply committed. It’s fine for users to choose the path, as long as they are informed they are going to need to be more self reliant.
  • A2) Do not prevent features like zero downtime in Keystone making forward progress with a MySQL only solution.
• Orthogonal concerns:
  • B1) Postgresql was chosen by people in the past, maybe more than we realized, that’s real users we don’t want to throw under the bus. Whole sale delete is off the table. There’s no clear path off and missing data of who’s on it.
  • B2) The upstream code isn’t so irreparably changed (e.g. delete the SQLAlchemy layer) that it’s not possible to have alternative database backends.
• The current proposal 13 addresses A1 and B1.
• Full thread: 14

[1] – http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2017-05-24.log.html

[2] – http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2017-05-24.log.html

[3] – https://wiki.openstack.org/wiki/Successes

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

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

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

[7] – http://lists.openstack.org/pipermail/openstack-dev/2017-May/thread.html#117370

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

[9] – http://lists.openstack.org/pipermail/openstack-dev/2017-May/thread.html#116677

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

[11] – http://lists.openstack.org/pipermail/openstack-dev/2017-May/thread.html#116619

[12] – http://lists.openstack.org/pipermail/openstack-dev/2017-May/thread.html#116736

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

[14] – http://lists.openstack.org/pipermail/openstack-dev/2017-May/thread.html#116642

POST /api-wg/news

• Newly Published Guidelines
  • Create a set of API interoperability guidelines 1
• Guidelines Current Under Review
  • Microversions: add nextminversion field in version body 2
  • A suite of five documents about version discovery 3
  • Support for historical service type aliases 4
  • WIP: microversion architecture archival document 5
• Full thread: 6

Release countdown for week R-16 and R-15 May 8-9

• Focus:
  • Pike feature development and completion of release goals.
  • Team members attending the Forum at the Boston summit should be focused in requirements gathering and collecting feedback from other parts of the community.
• Actions:
  • Some projects still need to do Ocata stable point release.
    • aodh
    • barbican
    • congress
    • designate
    • freezer
    • glance
    • keystone
    • manila
    • mistral
    • sahara
    • searchlight
    • tricircle
    • trove
    • zaqar
  • Projects following intermediary-release models and haven’t done any:
    • aodh
    • bitfrost
    • ceilometer
    • cloud kitty[-dashboard]
    • ironic-python-agent
    • karbor[-dashboard]
    • magnum[-ui]
    • murano-agent
    • panko
    • senlin-dashboard
    • solum[-dashboard]
    • tacker[-dashboard]
    • virtage[-dashboard]
  • Independent projects that have not published anything for 2017:
    • solum
    • bandit
    • syntribos
  • Upcoming deadlines and dates:
    • Forum at OpenStack Summit in Boston: May 8-11
    • Pike-2 milestone 2: June 8
  • Full thread: 7

OpenStack moving both too fast and too slow at the same time

• Drew Fisher makes the observation that the user survey 8 shows the same issue time and time again on page 18-19.
  • Things move too fast
  • No LTS release
  • Upgrades are scary for anything that isn’t N-1 ←N
    • The OpenStack community has reasonable testing in place to ensure that N-1 ←N upgrades work.
    • Page 18: “Most large customers move slowly and thus are running older versions, which are EOL upstream sometimes before they even deploy them.”
    • We’re unlikely to add more stable releases or work on them longer because:
  • We need more people to do the work. It has been difficult to attract contributors to this area.
  • Find a way to do that work that doesn’t hurt our ability to work on master.
• We need older versions of the deployment platforms available in our CI to run automated tests.
  • Supported version of development tools setup tools and pip.
  • Supported versions of the various libraries and system-level dependencies like libvirt.
• OpenStack started with no stable branches, where we were producing releases and ensuring that updates vaguely worked with N-1 ←N.
• Distributions maintained their own stable branches.
  • It was suggested instead of doing duplicate effort, to share a stable branch.
    • The involvement of distribution packagers became more limited.
    • Today it’s just one person, who is currently seeking employment.
• Maintaining stable branches has a cost.
  • Complex to ensure that stable branches actually keep working.
  • Availability of infrastructure resources.
• OpenStack became more stable, so the demand for longer-term maintenance became stronger.
  • People expect upstream to provide it, not realizing that upstream is made of people employed by various organizations, and apparently this isn’t of interest to fund.
• Current stable branch model is kind of useless in only supporting stable branches for one year. Two potential outcomes:
  • The OpenStack community still thinks there is a lot of value in doing this work upstream, in which organizations should invest resources in making that happen.
  • The OpenStack community thinks this is better handled downstream, and we should get rid of them completely.
• For people attending the summit, there will be an on-boarding session for the stable team 9
• Matt Riedemann did a video 10 ether pad 11 and slides 12 on the stable work. In the end, it was determined the cost of doing it didn’t justify the dream on, lack of resources to do it.
• Full thread: 13

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

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

[3] – https://review.openstack.org/#/c/459405/

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

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

[6]  – http://lists.openstack.org/pipermail/openstack-dev/2017-May/116374.html

[7] – http://lists.openstack.org/pipermail/openstack-dev/2017-May/116401.html

[8] – https://www.openstack.org/assets/survey/April2017SurveyReport.pdf

[9] – https://www.openstack.org/summit/boston-2017/summit-schedule/events/18694/infraqarelease-mgmtregsstable-project-onboarding

[10] – https://www.openstack.org/videos/video/openstack-stable-what-it-actually-means-to-maintain-stable-branches

[11] – https://etherpad.openstack.org/p/stable-branch-eol-policy-newton

[12] – https://docs.google.com/presentation/d/1k0mCHwRZ3_Z8zJw_WilsuTYYqnUDlY2PkgVJLz_xVQc/edit?usp=sharing

[13] – http://lists.openstack.org/pipermail/openstack-dev/2017-May/thread.html#116298

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]

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.

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]

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

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]