Open Hour 2020-NOV-19

January 23, 2021 - slangadmin


  • General news and updates
  • Existing SEPs
  • Retrospective Form link
  • Brief Q&A

Meeting Notes 2020-11-19


General news and updates

  • 3002.2 Releases yesterday!
  • Zoom Meeting IDs will change starting with December 1st
  • Community Calendar will be moving to Office 365 also on December 1st

Docs Clinic Today

Existing SEPs

  • Tom describes we will be moving to inclusive language as per internal direction from VMware and this SEP will take some time, but it will take a long time to get started and to endure the longevity of this change SEP 28
  • It will take some time to change master through out the code base and likely we will change the master branch name as well.
  • How is the SEP process going (Gareth)?
  • SEP 26 any update with this – it needs to be merged (admin tasks), and you can see more details in the salt-pkg repo in gitlab:

POLL! We want to hear from you! In this comment in SEP 26 Pedro has a two question poll, please read and give us feed back in the comment you can click on the response you want to vote for.

Sage to send this to the salt-users mailing list and general announcements – also sent 2020-DEC-01 to salt-users, salt-packagers and here in the meeting notes.


  • What is going well?
  • What could be better and how?
  • How will we improve?
  • Tom: We were shell shocked with the April 29th CVE and this new Salt-API was critical in it’s own scope, we could have presented it a better way. We haven’t had CVEs that where as sever in the past, doesn’t necessarily mean it will expose liabilities, and we need to communicate it better. We will try to find better balance there.
  • Kirill: When we can we expect a stable release or should we expect to wait for the point release. (Sage) hitting release dates, we use to place more value on stability and now we are moving towards hitting closer to dates as well as stability. Also looking at RC process or the release candidate process. (Wayne) how do we get the community to test the RC and reporting issues back to us and fix those in RC timeframe. (Sage) Lab environment or use-case scenarios, bug bounties or available environments to test. (Bryce) 2 rounds RCs – would that make a difference? (Dwoz) we have been missing our RC dates and making the process really 4 weeks. (Barney) have stats on how many, Bryce could get some data (Sage) want to communicate these numbers and in the past we have been surprised how low the numbers are. (Gareth) we brought this up last week and Sage you brought it, again and I agree we don’t believe many community members can test an RC and give us their state files, their use cases or give them an environment. Testing more before a release. (Sage) environment that is just to see features, play around or even a beta of features or change has value. (Barney) very useful (Wayne) Hands on lab in VMware, interesting if we could use that with salt (Sage) that usually production applications, but yes the same idea (Wayne) cannot test an RC, but will install a newer version and have stability issues or will find critical issues, and how to unwind? Rollback maybe not a full lab environment, but have a full rollback set of criteria, (Sage) best practice for salt? (Barney) stated fact that masters should be at a higher version than your minions – since masters are more critical. Too hard to do this. Is this still fundamentally the case? (Tom) Generally speaking we do not use that unless for a fallback situation – shouldn’t have a capability issues between backwards capability. (Barney) if it isn’t master version to minion version – make this more known. Test RCs on your minions is still valuable and acceptable. (Tom) incredibly helpful insight. (Sage) as we are putting out the RCs this likely needs to be more visible and communicated better. Sage to take an action item on this , good practice, but not critical and if you have only minions that is still very valuable test case scenario. (Sage) we are often surprised how salt is being used. (Shane) a note in the RC communication (Sage) yep.
  • Comment: It isn’t a paradox that a release is stable. (Sage) language around what we call everything such as branch called master, or stable, or main, etc. Thinking that we also need change what we call stability and thought of this first and in the forefront of our culture. Environment like a development that is known to be unstable or what is latest for testing and here are known issues and here is the timeframe or schedule, and separate production ready, stable release or stable environment. (Tom) we have nightly builds, those should be tested and (Sage) we are working on making that reality, those need to be in an environment. Getting this to DONE, more complete instead of always innovation, nightly builds, Tiamat packages, and testing. (Gareth) Docker images are available for master and minion, nightly builds of those as well, and that would give the community a way to test as well. Formalize that process and easier for people to use <Sage to expose these ideas to the community in a better way.(Barney) SaltStack hasn’t use salt internally and with going to VMware is that changing and then eat your own dog food? (Tom) VMware calls this Champagne-ing, funny word, but yes we do have this started and we don’t have much we can detail at the moment, but this coming. Training many internal VMware employees Salt.
  • (Sage) this meeting has been amazing and grown to be a good avenue of communication, it isn’t perfect, but we made a large leap towards better with this meeting.
  • (Bryce) weekly builds (Sage) we will detail in the Friday meeting and will communicate details soon.
  • (Sage and Tom) missing teammate Dmitry, sensitive topic, YES, we miss him tremendously and it simply didn’t work out with the merger and hope that he will still work with him in the community and have nothing but praise for him and his work and want to work with him in the future. We will be growing. Still integrating within VMware and then we will be growing the team.