Puppet - Puppet Labs

1

After

2

1

[discussion](http://mail.madstop.com/pipermail/puppet-users/2007-November/005308.html)

3

1

on the mailing list and IRC,

4

1

5

1

    WARNING: `DavidSchmitt`:trac: is not a valid TracLink

6

1

7

1

volunteered to spear-head a "Common Modules Project". This page

8

1

describes possible workflows with such a central repository. This

9

1

page is currently in alpha status. Tests, Edits or Feedback on the

10

1

mailing list highly appreciated! The plan is to wrap the git

11

1

commands into some frontend script to manage the various action,

12

1

when the workflows received a bit testing in real live.

13

1

Currently, that central repository is the one detailed [[Complete

14

1

Configuration]] , managed by David. It could eventually be folded

15

1

into

16

1

[modules.reductivelabs.com](http://modules.reductivelabs.com/).

17

1

18

1

Contents

19

1

20

1

-   [[Common\_Modules#definitions|Common Modules]]

21

1

    -   [[Common\_Modules#roles|Common Modules]]

22

1

    -   [[Common\_Modules#branches|Common Modules]]

23

1

24

1

-   [[Common\_Modules#repositories|Common Modules]]

25

1

-   [[Common\_Modules#configuration|Common Modules]]

26

1

-   [[Common\_Modules#common-modules-workflow|Common Modules]]

27

1

    -   [[Common\_Modules#upstream-release-and-development|Common

28

1

        Modules]]

29

1

    -   [[Common\_Modules#contribution|Common Modules]]

30

1

    -   [[Common\_Modules#usage|Common Modules]]

31

1

    -   [[Common\_Modules#usage-integrating-new-release|Common

32

1

        Modules]]

33

1

34

1

35

1

# Definitions

36

1

37

1

First, let's put aside some vocabulary issues.

38

1

39

1

## Roles

40

1

41

1

Responsible:

42

1

coalesces and publishes contributions to a given module

43

1

Contributor:

44

1

adds value to a given module by contributing patches, testing,

45

1

documentation

46

1

User:

47

1

uses a published module

48

1

## Branches

49

1

50

1

Development:

51

1

Anything goes. Here new stuff can be tested. Configurations are

52

1

only deployed manually in restricted environments.

53

1

Testing:

54

1

Finished development is first deployed to a staging area. From here

55

1

test hosts and second-line systems receive their configuration.

56

1

While nothing should break, this stage is used to catch slip-ups.

57

1

Production:

58

1

After a burn-in in Testing, modules can be pushed to Production.

59

1

Here nothing should happen anymore.

60

1

# Repositories

61

1

62

1

Each repository contains a single module, thus collapsing the

63

1

notions of repositories and modules. Within a repository, multiple

64

1

branches can exist. Deploying a branch means checking out the files

65

1

into a working directory. Using git, every checkout is a working

66

1

repository too.

67

1

68

1

To reduce confusion, there should be one branch per environment.

69

1

Here is how I (David Schmitt) set up my repos. My modules all go to

70

1

/srv/puppet/module-$environment/ on my puppetmaster.

71

1

72

1

Creating the repositories:

73

1

74

1

    MODULENAME=newmodule

75

1

    for i in production development; do

76

1

       mkdir -p /srv/puppet/modules-$i/$MODULENAME

77

1

       ( cd /srv/puppet/modules-$i/$MODULENAME; git-init )

78

1

    done

79

1

80

1

Setting up the development repository:

81

1

82

1

    cd /srv/puppet/modules-development/$MODULENAME

83

1

    mkdir manifests

84

1

    touch manifests/init.pp

85

1

    git add manifests/init.pp

86

1

    git-commit -m 'empty module'

87

1

    git-checkout --no-track -b development

88

1

    git-checkout -b production

89

1

    git-branch -d master

90

1

    git-config --add remote.publish.url ssh://david@git.black.co.at/srv/git/module-$MODULENAME

91

1

    git-config --add remote.production.url /srv/puppet/modules-production/$MODULENAME

92

1

    git-checkout development

93

1

    git-push production production # prime the production repo

94

1

95

1

Now I can start adding stuff and committing them to the development

96

1

branch, running puppetd --test --environment=development now

97

1

receives the new changes.

98

1

99

1

If I'm satisfied with my current level of testing I can merge the

100

1

work done into my production branch:

101

1

102

1

    git-push . development:production

103

1

104

1

Since working in the production branch is a big No-No, this should

105

1

always be a fast-forward merge, which just adjusts the tip of the

106

1

branch to the current status.

107

1

108

1

Finally this can be pushed into the production environment and

109

1

publish it on my webpage:

110

1

111

1

    git-push production

112

1

    git-push publish

113

1

114

1

Again, working in the production repo is a even bigger No-No, so

115

1

this should work always. Also, I didn't show the creating of the

116

1

repo on my webhost, but that is really straight forward (just use

117

1

git::repo and git::web::export from my git module ;)

118

1

119

1

Having only a small installation, one staging area is good enough.

120

1

Other people might be interested in more complicated structures

121

1

like multiple staging and developing areas. Multiple, staggered

122

1

staging areas can be achieved by simply adding more top-level

123

1

directories and chaining them together with more remote.\*.url

124

1

config entries. git-push(1) has a list of all valid repository

125

1

URLs.

126

1

127

1

# Configuration

128

1

129

1

[This needs 0.24 or later]

130

1

131

1

To setup the environments, add these values to your puppet.conf:

132

1

133

1

    [main]

134

1

    # This is the default environment for all clients

135

1

    environment=production

136

1

137

1

    [puppetmasterd]

138

1

    # specify allowed environments

139

1

    environments=production,testing,development

140

1

141

1

    # configure environments

142

1

    [development]

143

1

    modulepath=$confdir/modules-development:/usr/share/puppet/modules

144

1

145

1

    [testing]

146

1

    modulepath=$confdir/modules-testing:/usr/share/puppet/modules

147

1

148

1

    [production]

149

1

    modulepath=$confdir/modules-production:/usr/share/puppet/modules

150

1

151

1

For detailed Configuration Issues see: [[Using Multiple

152

1

Environments]]

153

1

154

1

# Common Modules Workflow

155

1

156

1

[todo: review

157

1

[http://wiki.procode.org/cgi-bin/wiki.cgi/StGIT\_Tutorial](http://wiki.procode.org/cgi-bin/wiki.cgi/StGIT_Tutorial)

158

1

for contributor/user usage]

159

1

160

1

## "Upstream" Release and Development

161

1

162

1

-   one of the responsibles publishes module to public repo with

163

1

    branches master (production), testing and development

164

1

165

1

## Contribution

166

1

167

1

-   contributor clones repo locally

168

1

-   contributor commits local changes and publishes them (repo or

169

1

    patch)

170

1

-   responsible integrates submitted changes

171

1

-   contributor tests modules' various branches

172

1

173

1

## Usage

174

1

175

1

[This needs 0.24 or later]

176

1

177

1

-   user clones repo to

178

1

    $localdatadir/puppet/modules-development/$modulename

179

1

-   local changes are committed and tested there, using puppetd

180

1

    --test --environment development --noop

181

1

-   good modifications are pushed to

182

1

    $localdatadir/modules-production/$modulename

183

1

184

1

## Usage, integrating new release

185

1

186

1

[This needs 0.24 or later]

187

1

188

1

-   user clones repo to

189

1

    $localdatadir/puppet/modules-development/$modulename

190

1

-   local changes can be committed there to branch "development"

191

1

-   testing against branch "development", using puppetd --test

192

1

    --environment development --noop

193

1

-   create production branch and apply local changes: "git checkout

194

1

    -b production origin/master && git merge development"

195

1

-   testing against branch "production", still in -development,

196

1

    again using puppetd --test --environment development --noop but

197

1

    with a different checkout

198

1

-   modifications are pulled to

199

1

    $localdatadir/modules-production/$modulename

200

1

-   git checkout development => further changing/testing cycles

201

1

202

1

After new upstream release:

203

1

204

1

-   git rebase origin/master development; after resolving conflicts

205

1

    now the development branch should be ready to test/fix up and then

206

1

    merge into production as above [ this breaks if the repo is used

207

1

    locally to push onto the production working directory, use merge

208

1

    instead. For better upstream cooperation, perhaps use a separate

209

1

    repo/branch to prepare patches by cherry-picking them and creating

210

1

    new commits ]