Open Hour 2020-DEC-17

Agenda

  • General updates
  • Docs Clinic Today
  • Existing SEPs
  • Discussion and Q&A

Meeting Notes

This is the last Open Hour of the year! We get back to it on January 7th, 2021!

General Updates

  • Bugfix releases yesterday!
    • 3001.4
    • 3000.6
    • 2019.2.8
    Notice that there isn’t a new 3002.x release. This is because the fix is already included in 3002.2!
  • Salt Project branding: Posted in community slack, would love feedback!
  • Remaining videos from SaltConf20 are getting posted to YouTube

Docs Clinic Today

Streaming on Twitch: twitch.tv/saltstackinc

FOSDEM 2021 Online: Call For Participation

There is a Call For Participation (CFP) for the Infrastructure Management DevRoom, with a deadline of December 31st, 2020. We highly encourage people of the Salt community to apply.

Snippet from the site:

The devroom will normally run on Saturday 6 February 2021.

The Infra Management Devroom is a devroom for developers, system engineers, SRE, system administrators and all practitioners of Infrastructure as Code or Infrastructure Management.

We are looking for any topic relating to Infrastructure, including but not limited to Configuration Management, Infrastructure Orchestration, Infrastructure Management, Infrastructure Automation, and Infrastructure Monitoring.

Existing SEPs

All PRs in SEPs repo here: Salt Enhancement Proposals

Community Feedback/Thoughts on SEPs

SEP 26: Pkg Salt with Tiamat

Question: What is the purpose/mission of the Community Advisory Board?

The purpose/mission of the Community Advisory Board is to give a more formalized voice to the community through regular and revolving representation that the core team can sync with on issues and developments within the community. This will not minimize the voice of those in the community who are not on the board. The board members will be tasked with staying abreast of issues that arise within community slack and other places to filter and highlight those concerns. The responsibilities and purpose will evolve and adjust over time.

For the related SEP discussion: SEP 27 – Create Community Advisory Board

Discussion and Q&A

Work on pepper

Randy Thompson is working on a fork, upgrading pepper to Python 3.6+

salt-api rewrite in FastAPI

Randy Thompson is working on a FastAPI implementation/rewrite!

Question: Is there a better alternative to heavy pillar usage for minion configurations?

Are there any plans to make a minion-based configuration system available that can take the load off master-side pillar? The difficulty I keep seeing being talked about is people overusing pillar because there’s no simple alternative.

The huge amount of non-secret data that people put into pillar, because it’s easy to target. But there’s no alternative that can match and merge on the minion. We have to write complex map.jinja for every different use case.

Grains come from the minion, this is config from the master.

Why not give the minion their own pillar_top.sls for example, that simply reads from the fileserver and transparently does it all.

So we’d still need to have map.jinja to merge secrets and non-secrets?

  • @baby-gnu from the Formulas Working Group has been working on something similar to this and has a prototype in the openssh-formula. See the documentation for map.jinja for merging secrets (from pillars) with non-secrets (from the filesystem):
  • SDB should also be looked at as another way of storing and retrieving data.
    • Lookups in sdb should be faster than reading from pillars directly anyway since it’s just a datastore.
    • Maybe an expansion of SDB’s capabilities is needed if it currently doesn’t support the use case here? An SDB module which reads from a pillar-esque top file could be helpful.

This may require a new SEP, or and expansion/extension of the documentation if existing features may support what’s needed.