{"thread":{"id":"33735","subject":"offtopic: ppg design decisions - encapsulation","startedAt":"2013-05-06T15:34:28Z","lastAt":"2013-05-07T14:32:15Z","messageCount":3,"participants":["Martin Langhoff","John Keeping"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"216508","messageId":"CACPiFCL+cd1vmqj6JEj84L5rDvHGxDgo+zGw5__ard6-sumipA@mail.gmail.com","threadId":"33735","inReplyTo":null,"subject":"offtopic: ppg design decisions - encapsulation","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2013-05-06T15:34:28Z","receivedAt":"2013-05-06T15:34:28Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"[ Unashamedly offtopic... asking here because I like git design and\ncoding style, and ppg is drawing plenty of inspiration from the old\ngit shell scripts. Please kindly flame me privately... ]\n\nppg is a wrapper around git to maintain and distribute Puppet configs,\nadding a few niceties.\n\nNow, ppg will actuall manage two git repositories -- one for the\npuppet configs, the second one for ferrying back the puppet run\nresults to the originating repo (were they get loaded in a puppet\ndashboard server for cute webbased reporting). The puppet config repo\nis a normally-behaved git repo. The \"reports\" repo is a bit of a hack\n-- never used directly by the user, it will follow a store-and-forward\nscheme, where I should trim old history or just use something other\nthan git.\n\nSo I see two possible repo layouts:\n\n- \"Transparent, nested\"\n .git/ # holding puppet configs, allows direct use of git commands\n .git/reports.git # nested inside puppet configs repo\n\n- \"Mediated, parallel\"\n .ppg/puppet.git # all git commands must be wrapped\n .ppg/reports.git\n\nMy laziness and laisses-faire take on things drives to to use the\ntransparent&nested approach. Let the user do anything in there\ndirectly with git.\n\nOTOH, the mediated approach allows for more complete support,\nincluding sanity checks on commands that don't have hooks available. I\nalready have a /usr/bin/ppg wrapper, which I could use to wrap all git\ncommands, setting GIT_DIR=.ppg/puppet.git for all ops. It would force\nops to be from the top of the tree (unless I write explicit support)\nand I would have to implement explicit. And it would break related\ntools that are not mediated via /usr/bin/git (gitk!).\n\nWritten this way, it seems to be a minimal lazy approach vs DTRT.\n\nAm I missing any important aspect or option? Thoughts?\n\ncheers,\n\n\n\nm\n--\n martin.langhoff@gmail.com\n -  ask interesting questions\n - don't get distracted with shiny stuff  - working code first\n ~ http://docs.moodle.org/en/User:Martin_Langhoff\n"},{"id":"216511","messageId":"20130506155353.GF25912@serenity.lan","threadId":"33735","inReplyTo":"CACPiFCL+cd1vmqj6JEj84L5rDvHGxDgo+zGw5__ard6-sumipA@mail.gmail.com","subject":"Re: offtopic: ppg design decisions - encapsulation","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-05-06T15:53:53Z","receivedAt":"2013-05-06T15:53:53Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Mon, May 06, 2013 at 11:34:28AM -0400, Martin Langhoff wrote:\n> [ Unashamedly offtopic... asking here because I like git design and\n> coding style, and ppg is drawing plenty of inspiration from the old\n> git shell scripts. Please kindly flame me privately... ]\n> \n> ppg is a wrapper around git to maintain and distribute Puppet configs,\n> adding a few niceties.\n> \n> Now, ppg will actuall manage two git repositories -- one for the\n> puppet configs, the second one for ferrying back the puppet run\n> results to the originating repo (were they get loaded in a puppet\n> dashboard server for cute webbased reporting). The puppet config repo\n> is a normally-behaved git repo. The \"reports\" repo is a bit of a hack\n> -- never used directly by the user, it will follow a store-and-forward\n> scheme, where I should trim old history or just use something other\n> than git.\n\nI'm not sure I fully understand what the reports are, but it sounds like\nthey are closely related to original configuration commits.  If that is\nthe case, have you considered using Git notes instead of a separate\nrepository?\n"},{"id":"216614","messageId":"CACPiFCLtYKsXQ-aoPadJxkB5phQ+j2PAfHnDTJK6B85mcfRF_g@mail.gmail.com","threadId":"33735","inReplyTo":"20130506155353.GF25912@serenity.lan","subject":"Re: offtopic: ppg design decisions - encapsulation","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2013-05-07T14:32:15Z","receivedAt":"2013-05-07T14:32:15Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On Mon, May 6, 2013 at 11:53 AM, John Keeping <john@keeping.me.uk> wrote:\n> I'm not sure I fully understand what the reports are, but it sounds like\n> they are closely related to original configuration commits.  If that is\n> the case, have you considered using Git notes instead of a separate\n> repository?\n\nInteresting suggestion! I read up on git-notes.\n\nYes, reports are closely related to a commit -- it's a lot of the\nexecution of puppet with that config on a client node. At the same\ntime, we have one report per change deployment, per client -- with\nthousands of clients. So it will be a large dataset, and a transient\none -- I intend to use git as a store-and-forward mechanism for the\nreports, and it is safe&sane to forget old reports.\n\nI don't see much ease-of-expiry in the notes, so I guess I would have\nto write that myself, which complicates things a bit :-)\n\ncheers,\n\n\nm\n--\n martin.langhoff@gmail.com\n -  ask interesting questions\n - don't get distracted with shiny stuff  - working code first\n ~ http://docs.moodle.org/en/User:Martin_Langhoff\n"}]}