On Wednesday, May 15, 2013 1:00:41 AM UTC-5, Alex Harvey wrote:On Wednesday, May 15, 2013 2:51:14 PM UTC+10, yersinia.spiros wrote:
Sorry for the top posting.
Imho, i think this is a question that could be asked on the git mailing
list.
Sorry, my question apparently isn't clear enough - this definitely isn't a
git question that can be answered at the git mailing list. I am interested
in both how you might configure a push-only solution from revision control
system to puppet masters, but more importantly, can Puppet be just as easy
to manage if I do this?
If you want your masters to rely on a revision control system for
manifests, data, or whatever, then it follows that the masters must be
permitted to access that system. If they may not do so across network
segments, then it follows that the repository must be hosted on the same
segment as the masters. It also follows that if the masters are on
different segments then you need some kind of cross-segment replication of
the revision-control repository.
Furthermore, git is probably not the best choice of revision-control system
for what I think you're asking. As I understand git operation (which is
imperfectly), you could certainly push changes to a remote repository, but
you would also need to pull from the repository side before those changes
would be available to other clients (such as the masters). This is
different from the more traditional approach of systems such as Subversion.
As far as how easy it is to manage your Puppet infrastructure, I don't
think I understand how you're partitioning subsystems. I would account
everything you're talking about as part of managing Puppet, and clearly,
operating under the constraints you describe is harder than operating
without them. On the other hand, if you postulate that the problem of
getting the needed code and data into an accessible repository is solved
and out of scope, then why would you suppose there would be any difference
between managing Puppet in your environment and managing it in a
less-constrained one?
John
