Skip to content

Open Hour Agendas and Notes: 2020 11

Jump to bottom
Sage the Rage edited this page Dec 1, 2020 · 12 revisions

Open Hour meeting videos are available on YouTube.

2020-11-19 Open Hour Agenda

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

Meeting Notes 2020-11-19

Slides

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: https://gitlab.com/saltstack/open/salt-pkg/-/issues?label_name%5B%5D=Tiamat

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.

Retro

  • 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 were 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.

2020-11-12 Open Hour Agenda

Meeting Notes

General News

Point Release: Nov. 18th, Wed.

  • Fix or revert for the memory leak planned, with point-release on November 18th
  • There will be a community retrospective after the point release, during the Open Hour on Nov. 19th

Working groups, community calendar, and general community news and updates

  • All Zoom Meeting IDs will change date is TBA
  • Working Group Captains will be informed and any documentation will be updated
  • Community Calendar will be moving to Office 365 date is TBA
  • salt-users, salt-packagers, salt-announce will stay public Google Groups

Checkout the SaltStack community Google calendar for upcoming events and streams.

Do you want to get more involved in salt and the SaltStack community? Get involved:

Docs Working Group

Existing SEPs

All PRs in the SEPs repo represent open discussions on Salt Enhancement Proposals.

Discussion Q&A

From IRC: MTechnology: "Could someone /please/ reconsider the naming scheme? Dropping the .0 from .0 releases is a pain in the butt to deal with."

Wayne was able to catpure most of the real time conversation in IRC

  • wayne: There's a lot of administriva, and we need people/help to get those SEPs to that point
  • sage: there's a lot of opportunity for improving visibility about where in the process
  • MTecknology: I'll bring that up :)
  • sage: I saw that request in IRC... I think we have a reason we decided to do that?
  • wayne: Not that I'm aware of - at least 3000 vs 3000.0 - a big reason we changed was a huge change vs the date-based
  • gareth: clarification - is the ask just to do 3003.0 vs. 3003?
  • wayne: yes (at least IIUC)
  • pedro: We do use 3000.0 on the bootstrap script to pin to minor versions, but that doesn't change the actual Salt version
  • Barney: MTecknology what's the problem with the lack of .0?
  • pedro: (it's actually a workaround for not having the .0 in the version number)
  • sage: we may need more information about the why/pain points to make a different decision

From IRC: lordcirth__: It is rather inconsistent to not write the .0 Though I've not had a specific technical problem as a result - yet. From IRC: Edgan: I could see if he is trying to break the version down into it's components he would have to have to have a if minor_version == '' then don't .{{ minor_version }} But if you treat it like a single string, {{ version }}, you wouldn't have this problem.

(general discussion)

  • Pedro: we are PEP 440 compliant (with the version)
  • Sage: Maybe we just need some more communications around it
  • dwoz: prefers continuing to do things as we are today (i.e. major, then major.patch)
  • wayne: I don't see a compelling reason to not add the .0, at least if there's a reason it causes some pain.
  • sage: I'll check to see if there's any confusion around the versioning
  • Sage: On working groups - we've discussed some more specific project plan/documentation around the working groups
  • sage: We've also looked at forming a kubernetes WG (discussion around Kubernetes WG, w/gareth)
  • sage: I have some discussions next week with VMWare kubernetes groups next week, that would be super exciting to get some more things going with that

From IRC: myii- waynew: Here's one situation where the lack of .0 is a pain: https://gitlab.com/saltstack-formulas/infrastructure/salt-image-builder/-/blob/master/.gitlab-ci.yml#L100-108. # Handle version number when installing a .0 release with git, where the .0 is not present in the version number in PyPI (https://pypi.org/project/salt/#history) ^ Bootstrap handles 3002.0 fine for stable but not for git. (stable vs. git-based installations).

  • gareth: does this go back to the discussion we had in the past?(discussion, not really)
  • sage: I think we can just discuss where we are today, and maybe where we need to move forward?
  • sage: do we need a SEP?
  • dwoz: I'd love bryce's take, we can probably go back and fix old ones
  • sage: that would be a big change, needs communication
  • dwoz: probably not worth doing it retroactively
  • gareth: opening a SEP - would we have arguments /against/ adding the .0?
  • sage: I think this is good for a SEP, we should also do blog post & other communication
  • megan: we will need to add some code changes

From IRC: MTecknology: I got distracted... I don't know specifics about many of the issues, but part of it is indeed breaking it down into it's components. $current_employer considers it a violation of policy for everything to not have the exact same version. I would expect whole string matching to be sufficient, but apparently it's causing a problem for many home-grown scripts. I've heard (2nd hand) that this is a problem for some home-grown scripts at other companies as well. It's also just confusing. Sometimes "3002" means "3002.0" and other times it means "3002.x". Even the current repo layout, it's not obvious what means what.

2020-11-05 Open Hour Agenda

Notes

General News

SaltConf20 Recap

  • Very positive feedback and turnout for the conference
  • SaltConf20 videos should be available by this weekend

If anyone has content they would love to share with the community, inspired by SaltConf20 or otherwise, we'd love to hear! Please reach out to Janae on the Salt Community Slack, or via email: ???

  • Randy Thompson said he'd love to talk and present more on Tiamat

Point Release: Nov. 18th, Wed.

  • Fix for the memory leak planned, with point-release on November 18th
  • There will be a community retrospective after the point release, during the Open Hour on Nov. 19th

CVE Release

CVE-release Feedback

What's the best release method going forward, for an open-source project?

This was a messy release due to discovering a new CVE in the process of preparing an initial release fixing some of the CVEs. There was also the timing around the acquisition, and on timelines where SaltStack provides CVE fixes early to SaltStack Enterprise customers so that they have time to apply fixes before public releases/announcements.

Ideas

  • Provide impacted libraries or components of Salt, without giving details on the nature of the CVE.
    • This can help provide users of Salt a heads up on what to secure/review before release, to ensure best practices and security hardening is in place.
  • Salt has leaned toward saying little before CVE release, in order to not tip off bad actors. This is a topic that is heavily debated. Salt has followed the philosophy that we only release public information once the fix is publicly released.
  • With this release being salt-api related, it may be a good idea to make/keep salt-api as a separate, standalone project outside of salt itself.
  • In the world of tech today, there has become a large focus on using APIs. salt-api should be revisited, rewritten, and likely separated from salt. Randy Thompson suggested a rewrite of it with FastAPI, or even a pop-focused approach to the development of it.
  • How do we provide release candidates in a fashion that gains further adoption? The first major release, before point release, seems to be generally considered the Release Candidate. This leads to people waiting to upgrade until the point release, due to the expectation that the initial release will be buggy.
  • We need more smoketests/functional tests. We have plenty of unit tests, but we don't have easy ways to run the latest version of salt with several states, execution module calls, etc. in a demo/test salt environment that stands up with the latest and greatest.
  • What is fuzzing was introduced against salt in tests to help reveal problems?

Third-party Security Audits of Salt

SaltStack has recently been acquired by VMware, and we are are deploying auditing tools created and used internally by VMware. VMware will be assisting, moving forward, with continual security audits, scans, and checks mandated by VMware. We now have full access to the internal security suite and teams internally at VMware, and this will result in better security posture with the Salt project.

Working groups, community calendar, and general community

SEP for an Advisory Board for Salt: SEP 27: Create Community Advisory Board

If people are interested in starting a new group like a Security Working Group, which could also collab with a Testing Working Group? Would you like to join a working group that is working on these sort of problems? Please reach out to [email protected]

Checkout the SaltStack community Google calendar for upcoming events and streams.

Do you want to get more involved in salt and the SaltStack community? Get involved:

The Documentation Group, and Docs Clinics

Existing SEPs

All PRs in the SEPs repo represent open discussions on Salt Enhancement Proposals.

Clone this wiki locally