WIP: Extend for upstream repos/archives/subcomponents

[noelmcloughlin]

Adapting the template-formula to handle installation of package/archives from an upstream repository will require extra configuration data. The following is my learnings from creating a newcloudfoundry-formula from template-formula.

New configuration data is needed in defaults.yaml updates and osfamilymap-

template:
  rootuser: root              ##needed for brew cmd.runs
  tmpdir: '/tmp/template' ##might be needed
  pkg_deps:                   ##general dependencies
    - curl
    - bzip2
    - gzip
  subcomponent:                    ###subcomponent of template
    pkg:                           ###package handling
      name: template-subcomponent
      use_upstream_repo: True      ###use of pkgrepo.managed (linux) or cmd.run brew tap (MacOS)
      use_upstream_archive: False. ###alternative to repos are archives

      archive:                     ###use by template.subcomponent.archive states
        source: https://packages.template.org/stable?release=linux64-binary&version=1.0.0&source=github-rel
        extracted:
          name: /usr/local/bin     
          source: /tmp/template/cf-cli.tgz.   ### sometimes salt cannot detect archive_format from above url (tbc).
          source_hash: 343j34kj34kl43jk43jk432j43j43kj43kj43lj3j4k3jk3j4k3j443j3
          extract_perms: False                ### whatever kwargs you need go here.
          overwrite: True
          trim_output: True
          enforce_toplevel: False
        installer: False                      ### if archive is an installer then we need to do more (future)
        binary: cf                            ### if archive is a binary we need to know its name (for clean states)
    repo:                         ###use by template.subcomponent.package.repo states
        managed:                  ###whatever kwargs you need go here.
          humanname: template-subcomponent
          name: template-subcomponent
          comments:
            - installed by salt
          gpgcheck: 1

New install and clean States are needed.

- template.package
- template.package.repo
- template.archive

I am documenting my learnings in this issue to share knowledge.

[daks]

link to #98

[myii]

@noelmcloughlin Thanks for opening this issue. In a conversation with @javierbertoli recently, we got around to discussing different use-case for the template-formula again, which was captured in #21:

• Add 'formula components' that can be reused in a formula as suggested by @javierbertoli, such as:
  • 'service-template'
  • 'pkg-template'
  • 'ini-config-template'
  • 'yaml-config-template'
  • Etc.

Part of the idea is to have useful templates for different situation, without having to strip out all the stuff you don't need, every time. So implementation-wise, it would probably be best to have different branches here, for the different types of formula. The main master branch would probably remain as a catch-all for all functionality but sharing the various features amongst the each branch as appropriate.

[noelmcloughlin]

Another approach would be to maintain a template formula family. These formulas are given a showcase status and PRs are carefully studied and discussed for best practice. The family should be small enough to manage but large enough to showcase usage patterns.

For example ....

1. template-formula Standard Template
2. prometheus-formula Derivative illustrating example of feature XXXX
3. systemd-formula Derivative illustrating example of feature YYYYY
4. cloudfoundry-formula Derivative illustrating example of feature Archive package handling.