Project

General

Profile

Feature #6855

Package Calamari variant of Salt minion

Added by John Spray over 10 years ago. Updated almost 10 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
Backend (packaging/deployment)
Target version:
-
% Done:

0%

Source:
other
Tags:
Backport:
Reviewed:
Affected Versions:

Description

I don't want to use upstream the upstream Salt minion as is, because if the end user happens to be using salt themselves:

- they would be pointing it at another server
- they might want an older or newer version than we want.

To that end, we should build our own packages with a different filesystem prefix, something like /opt/calamari.

Nice to have: build packages with esky so that we can use salt's magic upgrade feature:
http://docs.saltstack.com/topics/tutorials/esky.html
http://docs.saltstack.com/ref/configuration/minion.html#frozen-build-update-settings

calamari-salt.tar.gz (33.1 KB) John Spray, 01/02/2014 10:33 AM

History

#1 Updated by John Spray over 10 years ago

  • Category set to Backend (packaging/deployment)

#2 Updated by John Spray about 10 years ago

Status update: I messed with packaging far enough to build an ubuntu precise calamari-salt package which is essentially the salt python module installed in a venv + the minion init scripts from salt's packaging. That's attached here (make dpkg to get it built).

I'm thinking about removing this from the 2.0 scope though: this is packaging overhead, and we don't have a huge amount of spare packaging resource right now. Currently wip-2.0 is just using a stock salt minion: to substitute the calamari-salt variant, simply include it in calamari/repobuild makefile, then modify SALT_PACKAGE and SALT_CONFIG_PATH in calamari_web.views.bootstrap.

#3 Updated by John Spray about 10 years ago

  • translation missing: en.field_story_points set to 5.0

#4 Updated by John Spray about 10 years ago

  • Assignee deleted (John Spray)

#5 Updated by John Spray about 10 years ago

  • Target version changed from v1.2 Backlog to v1.2-dev8

#6 Updated by Ian Colle almost 10 years ago

  • Target version deleted (v1.2-dev8)

#7 Updated by John Spray almost 10 years ago

  • Status changed from New to Rejected

I don't think we would want to do this any more. Now that Calamari is open source, the preferred approach to deal with this sort of thing would be:

  • ideally if someone is already using salt we would just install calamari on the same server as their salt master
  • if a salt master for calamari is needed, it would be better to extend upstream salt-minion to be able to obey two masters.

Also available in: Atom PDF