Open Hour 2022-MAY-19

May 19, 2022 - Alyssa Rock

Agenda

  • General updates and announcements
  • Community forum update
  • Test clinic report
  • Docs co-working session update
  • Q&A plus discussion

Open Hour YouTube playlist | Contact us! saltproject@vmware.com

General updates and announcements

Events

Community forum update

  • Today’s featured issue: scoping and you! What is the difference between the master vs. a minion on the master? We have a lot of community members getting confused about things that happen within the master and about what having a minion on the master means in practical terms.
  • The thing to keep in mind is that having a minion on the master has absolutely nothing to do with the actual master. Yes, it can run runners and what not, but the minion is still separate from the master. It is a completely separate minion.
  • What helped Wayne first grasp this concept is to keep in mind that, within Salt, we really try to abstract and automate things as much as we can and that Salt is highly aggressive about re-using things. So, if we have a need the minion to do something on the master, rather than highjack that, Salt says “let’s use it in the master.” It can get confusing, but if you understand the principle that if we can reuse, then Salt will reuse it, that helps.
  • People sometimes want to run grains within orchestration and find that they are not getting their master’s grains. That’s because the master doesn’t have any grains. The master’s grains are created by a submaster that lives within the master process.
  • Sometimes people have a custom grain and try to access it within pillar during an orchestration. You have to actually sync all of your modules and grains to the master even if you’ve synced them to the minion master. You must sync them to the master also. Using pillars in orchestration is not recommended. Better to actually query the minion for its pillars. Use the grains cache to access the grains.

Test clinics

  • Test clinics are held Tuesdays and Thursdays. Check the community calendar for times.
  • This week Wayne helped with https://github.com/saltstack/salt/pull/61918
    • This PR had to do with Openstack and ipv6. We discovered our approach doesn’t do the right thing for ipv6. We also refactored and improved the PR. We discovered that the PR predates python 3.3, but in that version of Python, we can offload all of that logic into Python, which handles the public vs. private space better. We should merge this PR in soon.
  • Wayne also helped with https://github.com/saltstack/salt/pull/62056
    • The context manager was causing some slight issues with checking to see what calls were actually made. So they worked on that and got it unlocked. It turned out we could specify a mock before we calling the mock manager. This might be surprising if you don’t know about how Python’s internals work.
  • Other than that, Wayne will get back to working on tests for the API returner.

Docs co-working session update

  • No Docs working group next Tuesday (May 24) while Alyssa is at the Write the Docs conference​
  • Starting May 31, the Docs working group is permanently shifting the meeting time back by an hour: Tuesdays 4p-5 MDT, 10p-11 UTC.​
  • Is there interest in starting an additional docs co-working session that is at a time friendly for EMEA? Maybe Wednesday or Thursday at 8a-9 MDT or 1 hour later, which would be 2p-3 UTC? If so, let Alyssa know you’re interested!

Q&A plus discussion

  • We started the Q and A by reading out some questions from the community in Slack that hadn’t been resolved yet.
  • Q: Am I doing something stupid or is this CVE still open CVE-2022-22941? –Enmanuel H
    • ​A: This is the one that was patched recently, so it shouldn’t still be open.
  • Q: Is it possible to add in some way a pillar as variable in a JSON file like in the example pictured below?
  • Thanks! –Monica Limachi
    • A: Orange Dog answered this outside of the thread, so check the Slack workspace. Thanks, Orange Dog!
  • Q: Can we get someone to approve the workflow on this PR? https://github.com/saltstack/salt/pull/62069
    • A: GitHub actions vs. Jenkins is the hangup here. We haven’t been able to get the workflow to work correctly here yet.
  • Q: Is there a 3005 schedule release update?
    • We are trying to get everything merged in by May 30, although that might need to be bumped a week. Then the tentative release date would be early July.
  • Q: The docs recommend using pillar to store all sorts of stuff, but I keep hearing conflicting information about only storing secrets in pillar. What really is the recommended approach?
    • At scale, it might be difficult to store random configuration in there when you start to get into hundreds of machines.
  • Q: Does it make sense to use branching instead of folders in gitfs?
    • Gitfs backends leak memory all over the place, so Wayne’s personal approach has been to keep things in Git but actually not allow Salt to care about the gitfs backend. Then, when you check into git, it tells Salt to update the repository locally. Or run a state to download the latest version. The way salt does gitfs lends itself strongly to monorepos, and is rather painful with multiple repos if you try to do branches.
  • Q: I’m having a lot of problems using Salt with vSphere.
    • Historically, this has to do with the fact that VMware and Salt are still fairly new to each other and are still learning how to get these tech stacks to work well with each other. It will take time and resources, but it will improve over time. Don’t forget you can always open a PR and fix them yourself!