Skip to content

Open Hour Agendas and Notes: 2020 08

Jump to bottom
Derek Ardolf edited this page Nov 4, 2024 · 31 revisions

Open Hour meeting videos are available on YouTube. Starting with the August 20, 2020 video, there are timestamps to mark where each topic begins.

2020-08-27

Agenda and Video link

Housekeeping items

  • Twitch is being used for Triage,Test Clinics, and R&D please find SaltStack's Twitch channel: https://www.twitch.tv/saltstackinc
  • Core team focus on tech debt and ZMQ, potential SEPs, new contributor greeting bot, orientation tools, Docs Jam, PyTest Blog Post
  • Add stamps to the videos on YouTube
  • Doc Jam Wednesday 2020-OCT-07 and docs clinic Wednesday 2020-09-30
  • Events

Meeting Notes

  • SaltConf 2020-OCT-29 Call for Speakers saltproject.io many topics and want community proposals, more details to come!

  • PR Cleanup calculation of template sls/tpl context (https://github.com/saltstack/salt/pull/58238)

    • within templates there are many variables available, several have not been documented
    • some of these variables have been recommended
    • some odd behavior or seemed like a bug, but since lacking docs this was only speculation
    • this PR adds tests for what things should look like and documentation
    • if you are using these and if this PR breaks anything, please let us know! we do not want to break anyone's states, Community Slack, IRC, mailing lists, or open a PR
    • Thank you for also adding documentation!!
    • Author of the PR - Michael, had a hard time getting this bug resolved because there was no documentation
    • Learning from this? PR Template has a checkbox for docs and when reviewed the reviewer needs to review the documentation well with each PR, automation to look for documentation on PRs for changes or that there should be docs changes.
    • Integration: doc strings, decorator since code change and docs were in different places - yes, we have looked into this, it is slightly complicated as-is today, but we would like to see this happen some how - how do we be hyper-diligent if it is in an .rst file elsewhere, we could still do this
    • Documentation for execution modules doesn't link to the source code - if we added that would it help? YES
    • Contributing Guide looking at the 5 different sources and want to make one source of truth, looking at this in Magnesium, will likely iterate over several releases
    • As a first time contributor, difficultly and didn't know how to set up environment in order to submit a PR, installation didn't work how I expected, but would like an out-of-the-box details, requirements, and documentation; examples like make-test or a docker container that has everything -- yes, we should provider this and make it very clear and accessible

  • Brand new SEP: Support checking/modifying the return of state.module.run (https://github.com/saltstack/salt/issues/58114) please check it out, please go read it and give comments

  • Cassandra will be moderating SEPs going forward

Q&A

  • Q: single repo for modules and ratings? or formulas? A: we have discussed this for modules, but does not exist, yet. Rating doesn't exist, but there is the salt-formulas repo, and currently all modules exist in the salt repo, plus custom modules. Discussed not doing this, but only a high level. Pop is trying to do this differently.
  • Q: Is there a Working Group on Pop projects like idem? A: we would like to see Working Groups for each of these projects, yes, there are lots of benefits to do this for a larger Pop Working Group. Needs a captain, schedule, and communication.

2020-08-20

Agenda and Video Link

  • Salt news and updates
  • Switch to PyTest
  • Working Groups: leadership changes, inactive groups, and suggested new groups
  • Open discussion and questions
  • Video: Salt Community Open Hour 2020-08-20

Salt News and Updates

Community Manager Cassandra Faris

  • Cassandra is speaking on "Business & Tech: A Communication Guide" at Code PaLOUsa on August 27.
  • Upcoming online tech conferences that may be of interest: GetWITIt (September 29-October 1) and cdCOn (Linux Foundation, October 7-8).
  • Core Team focus for the week:
    • Development: Planned tech debt issues.
    • Community: Working on the new contributor greeting and orientation process.
  • In the coming weeks, Salt will switch to PyTest as the only test runner because runtests.py is reaching its end of life. A blog post is live on the community site.

Switch to PyTest

SaltStack Engineer Pedro Algarvio
Discussion begins at 2:39 on the video

  • Why are we switching to PyTest?
    • runtests.py served us well, but every time the Salt test suite got a new sub-directory, runtests.py had to be updated in order to pick up those new tests. Often enough, those tests or sub-directories, would be added and never actually run on the CI pipelines because the needed updates to runtests.py were lacking.
    • PyTest is a testing framework that focuses on code reusability through fixtures and is good at giving insight when tests fail. Overall, it's a more powerful testing tool than the custom testrunner we had been using. Finally, this means that the testing suite can be maintained by the whole community vs. maintaining testrunner internally.
  • Additional details:
    • We are migrating some slow tests to PyTest.
    • Community members are already using PyTest.
    • SaltStack is making overall changes to the testing process.
  • So far, feedback about the switch to PyTest is positive.

Working Groups: Leadership Changes, Inactive Groups, and Suggested New Groups

Community Manager Cassandra Faris
Discussion begins at 10:40 on the video

  • What are Working Groups?
    • A Working Group is a small group of individuals who come together with a common goal and work towards achieving that goal within a predetermined amount of time.
    • In addition to having repos, each group decides how best to track their own projects.
    • They are a way for Salt community members to lead Salt projects and be part of the development process.
    • They provide a place where people can contribute to the Salt Open project within their area of interest. Currently, Working Groups exist for Cloud, Documentation, Formulas, MacOS, SSH, Testing, and Windows.
    • Anyone is welcome to join a Working Group. All they have to do is show up to a meeting.
    • Working Groups meet once or twice a month. The meeting schedule is on the Salt Community Events Calendar. Videos from the meetings are uploaded to YouTube for future reference.
  • How is a Working Group formed?
    • Working Groups are led by a captain who volunteers to lead the group and run its meetings.
    • Anyone who has an idea for a Working Group should contact Cassandra. She will help with scheduling and other logistics.
    • Working Groups are most successful when they have a focus and goals.
    • In the last 6 months, community members have suggested and started Working Groups for Formulas and Documentation.
  • Working Group changes
    • Windows: Shane Lee has stepped away from leading. Markus Kramer is now the leader.
    • Networking and SSH: These haven't been active for several months.
  • New Working Group suggestion: Kubernetes
    • This could be short term and have a specific focus. It's currently in the backlog and has been for some time.
    • Kubernetes is gaining traction in the broader tech community because people want to simplify their automation. Salt has a good implementation for working with Kubernetes. There are areas where that implementation needs updated, which is something a Working Group could do.
    • We want to make sure that what's in Salt aligns with Kubernetes as well as work with it in idem.
  • New Working Group suggestion: Triage
    • It would focus on learning how the triage process works.
    • Triage is a good way to learn Salt and how people are using it.
    • Community suggestions for improving triage are encouraged.
    • We stream the triage process on Twitch Tuesdays at 12:00pm MT/6:00pm UTC.
  • Documentation Working Group
    • If you have suggestions for areas to improve documentation, please join the group.
    • This group is helping plan a Documentation Jam that will run similar to the PR Jam.
  • Testing Working Group
    • If there's interest, we could organize a Testing Jam.
  • How should we handle inactive Working Groups?
    • If a group needs deactivated or paused, it should be added to the repo and opened to discussion.
    • Deactivating Working Groups isn't permanent.
  • Open Working Group Discussion
    • Contributor Question: Is there a formal process for changing leadership?
      • There isn't one now. The tenure for leadership could be tied to release cycles.
      • After every new release cycle, the Working Groups should evaluate their priorities and leadership to decide if anything needs changed. This can be an Open Hour topic.
    • Contributor Suggestion: Heist is under-documented. Does this belong to SSH, Documentation, or somewhere else?
      • The documentation doesn't get deep enough.
      • Multiple groups could work together and collaborate.

Open Discussion and Questions

Salt Community and Core Team

  • There were no general questions. The group continued discussing Working Groups until Open Hour ended.

2020-08-13

  • Salt news and updates
  • Release process and strategy FAQs
  • Open discussion and questions

Salt News and Updates

Community Manager Cassandra Faris

  • Meetup speakers and topics are needed. If you're interested in speaking or know of a good speaker, contact Cassandra.
  • Triage is streamed on Twitch every Tuesday at 12:00pm MT/6:00pm UTC.
  • Working Group and Open Hour YouTube videos and August Open Hour notes are now up-to-date.

Dedicated Topic: Release Process and Strategy FAQs

SaltStack SVP of Engineering, Moe Anderson

Thank you to SaltStack UX Designer Serena Jolley for creating these notes in realtime

Salt Open vision, mission, goals, commitment

  • Vision: To establish the community-built Salt Open software as the leading platform for Infrastructure Automation and Management
  • Mission: The Salt Open core team unites a global open source community to collaborate, build, secure, deliver, maintain, and promote Salt.
    • Driver for this team is to and from the community
    • Has been used on a global scale
  • Values:
    • Communication - We seek community participation. We are open and transparent
    • Action - We act decisively and proactively, embracing what we learn from both our successes and our mistakes. We understand our mistakes and work to avoid repeating them.
    • Teamwork - We add value to the Salt community by helping each other solve problems to create quality human and digital experiences. We arbitrate for the benefit of the community
    • Fun+Respect - We respect and value inclusivity in our global community and strive to recognize, understand, and respond to its needs. We have fun working on this exciting project.
  • Salt Core team: Bryce, Cassandra (community manager), Chad, Daniel (leads the work on many of our more critical upgrades), Derek (Dedicated documentation writer), Dmitry, Frode, Gareth, Jarom (dedicated SRE), Joe (Windows expertise), Kirill (seasoned SRE and test engineer), Megan (senior developer), Pedro (senior member of the team, built much of our test infrastructure), Sage (release manager), Shane (Windows expertise), Tyler (works diligently on Salt Cloud), Wayne (keeps track of release quality), Tom (our founder), Moe (overall management)
  • Goals:
    • Merge fast and confidently
    • Give community more of a say in work and direction
    • Understand what is going on
    • Improve quality and code base stability
    • Ease and accelerate onboarding

Process: today's reality vs. tomorrow's ambition

  • Level Set: The Salt Method
  • Personas: Our method is anchored in our Personas that represent our users. We consider our community contributor persona, Chloe, as a first-class persona. Chloe represents everyone in our community
  • Salt Method phases:
    • Idea>>Concept>>Design>Code>Validate>Package>Promote>Deliver
    • Design to develop
      • Wireframe/ design testing
      • Prototype and MVP iteration testing
    • Development to delivery:
      • Code dev elopement feature work and fix defects
      • Validation and QA
      • Packaging and Certification, documentation is completed
      • Beta testing
    • Principles for Quality Assurance
      • Iterative process that's more than just code testing
      • User feedback, design reviews, and MVP playbacks
      • Successful test runs are prerequisites to PR submission or merge
      • Migration testing occurs at package phase
      • Stop pipelines if test suite is failing
      • Performance Test occurs as part of package phase
      • Security testing is split between code analysis (throughout the release) and Pen testing
    • Automated test standards
      • PullRequest Test flow view
      • Test Suite Flow
      • Test Run Diagram
    • Issue flow
      • Reporting issues: If something is critical and prevents you from using Salt, but is not listed as critical based on the algorithm, please tag someone in it so we can make sure it gets looked at.
    • Security Testing - what are we changing?
      • CVE's get their own release
      • Conducting annual pen testing
      • Complete code audit performed every one to two years
      • Security mailing lists

Open Discussion and Questions

  • How can a user update on a stable release cadence?
    • Published cadence (Feb, Jun, Oct) for Salt Open and Enterprise Product suite
    • Support updates: Mar-May, Jul-Sep, Nov
    • Content or new extensions: Feb-Nov
  • What did the release label SEP actually do? How do we decide to implement SEPs in light of community objections?
    • Simplify labeling
    • Learn and follow established standards
    • SEP are intended to solve an issue. SEPs garner feedback from across spectrum, not intended for individual veto.
    • Broad reaction to an SEP
    • SEPs can be promoted by any member of the community
    • We'll establish community advisory board - let us know if you want to be a part of it - this board will discuss and promote issues
  • Q: Regarding the Salt Open - it sounds great but some time before I asked if Salt Core Team plans to write a docs about multi-syndic configuration that is implemented but undocumented. And the answer was "no" and basically idea was to "if you want something like this - we have a Salt Enterprise". I could understand that if feature wasn't implemented but it's implemented already! I still very confused by this. Issue for the reference: https://github.com/saltstack/salt/issues/18751
    • Moe will look into this particular issue
  • Q: There was a comment in Slack that it was impossible to use any major Salt release in a while without waiting for .1 release. Do you think Salt could benefit from spending a whole major release cycle for bug fixing only?
    • Moving away from the perception that a release is only stable in a .1 or .2 release
    • Currently talking about dedicating a full release to just addressing bugs to try and work through the backlog
  • Q: How do we use GitHub labels to gain insight into the release status and blockers?
    • We don't effectively use GH labels today
    • We're working to change that through use of project boards, milestones, and an overhaul of our labelling system. We plan to implement those changes gradually and throughout the magnesium release cycle
  • Q: Why does Salt want only one point release between each feature release? Why did we change to the single branch? What, if any, CI/CD pipeline does Salt have? How can we improve Triage?
    • We are not restricted to one point release
    • Change to single branch ensures we avoid branching challenges of the past, reduce maintenance burden and streamlines the contribution process. It is a critical step toward where we are heading with building an automated release foundation
    • We have a CI/CD pipeline
    • Triage requires a review and improvement cycle
  • Q: Could you please clarify your statement about “never doing releases with critical bugs”? For example, the most recent release (3001.1) was released with critical bugs, such as #57543 which appear to be labeled as “Magnesium”. Do you mean by your statement that you’re only referring to regressions or do you mean all critical bugs?
    • Meant regressions. If something is considered to be critical, we need to discuss/address them but this is meant to be high priority issues that have a large impact.
    • Constantly analyzing how critical bugs don't get looked at and added - if something falls off the board we want to look into why.
    • Need to publish taxonomy in our labels and get more rigid on what the Critical label means.
  • Q: How can a contributor understand the big picture plan so they can contribute more? What is our product strategy? What is the release plan and schedule?
    • Big Picture: we are going to hold more frequent communication by Alex/Tom.
    • Release plans and schedule are published on the wiki
    • Suggestion by Max Arnold to hold public retro will be implemented. We will hold first post the next release cycle
  • Q: Do non-critical bugs only get fixed with feature releases? If so, what happens when it makes someone unable to use Salt for months? Why continue adding features when there are still bugs and we keep introducing more without resolving them? Do we release when they have outstanding bugs that are labeled as Critical? What does it matter if you release now and get a bunch of critical bugs fixed, and then release again in 4 weeks and fix more things?
    • Bugs can be fixed in any release. We prioritized based on impact. Issue that stop usage should be labelled correctly so we address them as top priority
    • Low effort PR pulls to address bugs needs to be flagged to be addressed (part of triage and new board system)

2020-08-06

  • Salt news and updates
  • Sodium Point release: status update and what's included
  • PR Jam recap
  • Contributor Guide: planned updates and discussion of what to include
  • Open discussion and questions

Salt News and Updates

Community Manager Cassandra Faris

  • The next several Open Hours will have a featured topic based on community conversations and frequently asked questions
    • August 6: Salt Contributor Guide and documentation
    • August 13: Release process and strategy
    • August 20: Future Working Group plans
  • We're looking for meetup speakers. The topics can be on how you're using Salt as well as general SecOps and DevOps topics. Contact Cassandra if you have an idea for a talk or want to be part of a panel discussion.
  • The newest addition to our Twitch is Tuesday Triage. Log in to follow along and learn at 12:00pm MT/6:00pm UTC.

Sodium Point Release: Status Update and What's Included

SaltStack Project Manager Sage Robins

  • The point release is scheduled to be out on August 6 by 3:00pm MT/9:00pm UTC.
  • The release was delayed because the development team found a problem where the Salt API wasn't starting. This release was delayed to a bug found late in the RC process that caused Salt-api to fail to start. While fixing the bug, the team found a problem with the manual process and made a mistake in not getting all PRs labeled for the Point Release, causing the additional delay.
  • We've been working toward more tests to packages prior to releases. This is an area of focus for the Magnesium release.
  • Release highlights
    • Bugfix release
    • It fixes many Python 3 and Salt call issues

PR Jam Recap

Community Manager Cassandra Faris

  • Our first PR Jam was a success! We cleaned out the backlog and determined that some things in it were redundant or no longer needed. This allowed us to focus on the things that are needed. Moving forward, a smaller backlog will make it easier to manage PRs and take care of them more quickly. We set out with a goal to port 50 of the ~248 PRs in the backlog. When the event wrapped up, we'd ported 123 PRs.
  • PR Jam Stats
    • Average Number of Participants: 15
    • Average Number of New Contributors: 1
    • Total Number of Hours on Zoom: 27
    • Total Number of Hours on Twitch: 20
    • Total Number of PRs Ported Today: 123
  • We wrapped up with an excellent retrospective and some talks and discussion about the future of Salt. We plan to do a Documentation Jam in early September and hold additional PR Jams in the future. Thank you to all who participated!

Contributor Guide: Planned Updates and Discussion of What to Include

SaltStack Project Manager Sage Robins and Technical Writers Alyssa Rock and Derek Ardolf

  • Docs Jam
    • The Docs Jam will focus on getting use case examples detailed on modules that people are using every day. We want to create documentation around that.
    • The other thing we need is documentation to tell people how to contribute to the doc strings within modules. That's ultimately what gets rendered into documentation on the docs site.
  • Documentation areas of improvement
    • Pillar usage (whether and how to use pillars) is something that needs documented more specifically. There is an open issue regarding docs clarification and feedback is welcomed. The issue is here: https://github.com/saltstack/salt/issues/56116.
    • Walkthrough and beginners' guides.
  • Anyone who is interested is welcome to attend the Documentation Working Group every two weeks at 12pm MT/6pm UTC. Full details are on the Salt Community Events Calendar.

Open Discussion and Questions

Community and Core Team

  • Contributor Question: When will the new Community Wiki come out?
    • The wiki and community site are the 2 main sources of community information. The community site is more for blogs and events.
    • The wiki is going to be the place to go for Open Hour notes and release information. A goal for Magnesium is to organize the wiki better before it grows. Research on how to organize GitHub wikis is needed.
    • Contributor Comment: "Keeping the core documentation in the codebase makes a lot of sense. A wiki would allow you to push the use case documentation out to end users more easily, more articles than manuals"
  • Contributor Question: The man pages are updated as part of the release process and shouldn't be updated on PRs. Why do we have store them in the SaltStack repo vs. building them when man (manual) pages are needed?
    • History: Five years ago, when building docs, we had issues with Sphinx's different versions and decided to create one source of documentation. The docs repo was to be this source. This avoided the problems that came with building docs in all different versions of Sphinx.
    • Man pages are built every release. There is always a PR for those updated pages. There may not be a good reason for storing them into the repo. Sage is going to look into whether we need to continue this.
  • Contributor Question: How can someone contribute use cases?
    • We haven't decided anything yet, but will have a better idea after the August 13 Documentation Working Group meeting.
    • We would like to include those use cases for the Docs Jam.
  • Contributor Question: How do we do integration testing?
    • Overview: We currently have a limited subset of tests that run on PRs. These are the fastest and make up 80-90% of our test cases. We have periodic branch builds that run against the master branch. There are future plans to improve the test suite and end-to-end process.
    • We use three main test types. Here are some basic definitions that give us a shared frame of reference.
      • Unit: Testing one function in isolation (no network or disc calls) and tells what's going on internal to Salt. The goal is to get a reasonable level of confidence that we're not breaking code on PRs. These tests aren't going to check underlying systems.
      • Functional: Narrow, focused tests that make a networking or disc call. Still relatively fast because they're doing something simple and don't require a master or minion.
      • Integration: Test end-to-end, spinning up a master and minion to test in a full Salt environment. They are slower than the other two types of tests and don't run on every PR due to setup time. They provide a high-level perspective of real world scenarios.
    • Bring testing questions to the Testing Clinic Twitch streams on Tuesdays at 1:00pm MT/7:00pm UTC and Thursday at 11:00am MT/5:00pm UTC with SaltStack Engineer Wayne Werner. This provides a hands-on, supported opportunity to write tests.
Clone this wiki locally