Open Hour 2020-MAY-21
- Salt news and updates
- Closing SEP: Python version support
- New SEP: Move unsupported releases to a separate URL
- Feedback Item of the Week: CVE in salt_rc packages
- Community-Requested Topic: New distribution support policy
- Open discussion and questions
- Thanks to community for suggested topics and conversation about previous and unsupported releases Sodium Release timeline: May 22 is the PR deadline. All PRs need passing tests-
- Meetups back in place starting with SaltStack Germany UG with Elias Probst speaking on SaltStack Between Guardrails
- YouTube uploads being updated
- Community Wiki Page Updates: Changed title on Open Hour notes, moved most recent notes to top, created About the Open Hour page
- Open Hour timeline
- Agendas published on Tuesdays
- If a contributor requests a topic, they’ll be notified when the topic is going to be covered in an Open Hour so they don’t miss their request
Cassandra Faris and Wayne Werner
- SEP: https://github.com/saltstack/salt-enhancement-proposals/pull/26
- When Python brings something to end of life, we’ll stop supporting it. This SEP makes that policy official.
- The only impact on Sodium will be on Python 3.4 which we’re not supporting
- SEP: ttps://github.com/saltstack/salt-enhancement-proposals/pull/28
- The goal is to make it explicit that someone is at risk of installing an unsupported version
- Much like Ubuntu and Debian move unsupported releases to another site, we are going to do the same thing
- Any time a major release goes out of support, we’ll move anything from that release to the archive website
- Any time a point release is affected by a CVE, we’ll move it to the archive site
- PyPI’s old releases will move to a SaltStack hosted location
- This SEP has an expedited timeline due to CVE-related urgency. It takes effect on June 1
- Previously when Salt has had RCs, they available to download on the repo.saltstack.com directory. Those RCs were out-of-date. We usually leave them up until there’s another RC. In this case, we removed them because they had CVE issues
- When Salt releases Sodium, we’ll update the page with the latest RCs
Sebastien Blaisot and Core Team
- Background: Each time a user deploys a new server, the first thing they want available on the server is a Salt minion because it’s the start to deploy anything else on a new server. Can Salt packages be available as soon as a new version comes out? How can the community help make Salt packages available earlier?
- When Core releases a RC, they test it internally. The more testing they get from the community, the more stable Salt will be which will lead to quicker releases
- Core Team is in the process of moving packaging to Salt Bin (Salt’s single binary distribution /directory) which should make it faster to target and support newer OS versions. It simplifies dependency management.
- Suggestion: Create a SEP to discuss how to get this into an automated pipeline with Salt Bin
- Salt Bin should allow us to create self-contained versions that have fixes to allow for a specific operating system before it’s back into the main version of Salt. The result will be faster releases. Self-containment allows less hassle in dealing with dependencies.
Community and Core Team
- Question: Is the change to Salt bin happening for Sodium?
- The current SaltStack Enterprise version uses Salt bin to create packages that get bundled into the installer. It uses GitLab and has pipelines set up to leverage Salt bin. This creates improvements and simplifications when bundling necessary dependencies
- For SSE upgrade questions, contact firstname.lastname@example.org
- During this Open Hour, a community member requested a deep dive on Salt bin. That deep dive will be part of the May 28 Open Hour agenda
- Question: How is the work on test suite improvement going?
- The plan was to switch to PyTest by Sodium. Due to the CVE and related support, we don’t have quite enough time to do that by Feature Freeze
- Currently there’s one additional PR that makes changes to PyTest. Users should be able to run PyTest going forward
- We’ve identified test suite performance issues and marked some tests as slow. This gives helps PRs passing/not passing status sooner which makes merging faster.
- Going forward, we’ll address the slow tests by verifying their validity and rewriting them
- If you’re interested in helping with tests, reach out to the Core Team who can help with setup
- Testing Working Group is working to help us run the test suite in 60 minutes or less