threads / discuss / 33735

offtopic: ppg design decisions - encapsulation

Subject: offtopic: ppg design decisions - encapsulation

## tl;dr

3 messages between May 6, 2013 and May 7, 2013.

replies: 2people: 2as markdown or json

Martin Langhoff· May 6, 2013, 15:34 UTC · lore

[ Unashamedly offtopic... asking here because I like git design and coding style, and ppg is drawing plenty of inspiration from the old git shell scripts. Please kindly flame me privately... ]

ppg is a wrapper around git to maintain and distribute Puppet configs, adding a few niceties.

Now, ppg will actuall manage two git repositories -- one for the puppet configs, the second one for ferrying back the puppet run results to the originating repo (were they get loaded in a puppet dashboard server for cute webbased reporting). The puppet config repo is a normally-behaved git repo. The "reports" repo is a bit of a hack -- never used directly by the user, it will follow a store-and-forward scheme, where I should trim old history or just use something other than git.

So I see two possible repo layouts:

- "Transparent, nested"
 .git/ # holding puppet configs, allows direct use of git commands
 .git/reports.git # nested inside puppet configs repo

- "Mediated, parallel"
 .ppg/puppet.git # all git commands must be wrapped
 .ppg/reports.git

My laziness and laisses-faire take on things drives to to use the transparent&nested approach. Let the user do anything in there directly with git.

OTOH, the mediated approach allows for more complete support, including sanity checks on commands that don't have hooks available. I already have a /usr/bin/ppg wrapper, which I could use to wrap all git commands, setting GIT_DIR=.ppg/puppet.git for all ops. It would force ops to be from the top of the tree (unless I write explicit support) and I would have to implement explicit. And it would break related tools that are not mediated via /usr/bin/git (gitk!).

Written this way, it seems to be a minimal lazy approach vs DTRT.

Am I missing any important aspect or option? Thoughts?

cheers,

m
--
 martin.langhoff@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff

John Keeping· May 6, 2013, 15:53 UTC · re: Martin Langhoff · lore

Re: offtopic: ppg design decisions - encapsulation

On Mon, May 06, 2013 at 11:34:28AM -0400, Martin Langhoff wrote:

Show 15 quoted lines

> [ Unashamedly offtopic... asking here because I like git design and
> coding style, and ppg is drawing plenty of inspiration from the old
> git shell scripts. Please kindly flame me privately... ]
> 
> ppg is a wrapper around git to maintain and distribute Puppet configs,
> adding a few niceties.
> 
> Now, ppg will actuall manage two git repositories -- one for the
> puppet configs, the second one for ferrying back the puppet run
> results to the originating repo (were they get loaded in a puppet
> dashboard server for cute webbased reporting). The puppet config repo
> is a normally-behaved git repo. The "reports" repo is a bit of a hack
> -- never used directly by the user, it will follow a store-and-forward
> scheme, where I should trim old history or just use something other
> than git.

I'm not sure I fully understand what the reports are, but it sounds like they are closely related to original configuration commits. If that is the case, have you considered using Git notes instead of a separate repository?

Martin Langhoff· May 7, 2013, 14:32 UTC · re: John Keeping · lore

Re: offtopic: ppg design decisions - encapsulation

On Mon, May 6, 2013 at 11:53 AM, John Keeping <john@keeping.me.uk> wrote:

> I'm not sure I fully understand what the reports are, but it sounds like
> they are closely related to original configuration commits.  If that is
> the case, have you considered using Git notes instead of a separate
> repository?

Interesting suggestion! I read up on git-notes.

Yes, reports are closely related to a commit -- it's a lot of the execution of puppet with that config on a client node. At the same time, we have one report per change deployment, per client -- with thousands of clients. So it will be a large dataset, and a transient one -- I intend to use git as a store-and-forward mechanism for the reports, and it is safe&sane to forget old reports.

I don't see much ease-of-expiry in the notes, so I guess I would have to write that myself, which complicates things a bit :-)

cheers,

m
--
 martin.langhoff@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff