On Thu, Oct 17, 2013 at 06:15:57PM -0400, R P Herrold wrote:

Eyal Edri mentioned in IRC this morning (to me) that he had opened a couple of puppet tickets on infra matters -- and so I resolved to look on for 'easyfix' fruit to commit for puppet to apply

[ BTW, I solved getting a commit of a trivial gix up to gerrit earlier today as to a vdsm typo, so I think I have write access to git with ssh keying working. Checking the CI server dashboard, I see a broken build, but it seems to be for reasons other than my patch (which should have not have caused any new damag)e: http://gerrit.ovirt.org/#/c/20277/ As I am not certain, however, I decided I should stop further work on that front ]

But I fear my Google Fu has deserted me today. A Google search of: site:www.ovirt.org puppet

_should_ link me into find the details of the puppet management details for the oVirt infrastructure ... but (putting to side dead ends as to plug-ins for oVirt to Puppet, which are out of scope), about the most promising I can find is

http://www.ovirt.org/Infrastructure_Puppet_details

which is not really helpful

Argument: site:gerrit.ovirt.org puppet

does not help either

I _think_ this is the proper trailhead:

http://gerrit.ovirt.org/gitweb?p=infra-puppet.git

and so I have a checkout of the repository to poke through

But for the life of me, I cannot find a writeup or overview of the puppet workflow for infrastructure management

Does someone have an outline, or pointer into the wiki?

You are absolutely right that we're lacking in the documentation. Part of it is because we want to change how it's done now, but a short walk through before I go away for a couple of days. First of all, you clone the repo (and you got the correct URL): git clone --recursive git://gerrit.ovirt.org/infra-puppet.git Then you make the changes as you normally would. I recommend creating topic branches. When you've committed (with sign-off), you should submit the patches to gerrit. I highly recommend git-review for this, but you already figured this out for vdsm. Then it should be reviewed. Once it's merged, comes the tricky part. The deployment to production is manual. Trivial, but manual. What I've done, is adding a remote production git remote add production puppet@foreman.ovirt.org:puppet git fetch production # To get the references Then check out the production branch, merge master and push it git checkout production # Should base on production/production git merge master git push I should note that currently only my SSH key is (manually) added to puppet@foreman.ovirt.org/~puppet/.ssh/authorized_keys. Since dcaro has +2 permissions, I'd recommend him to add his until we sort out the r10k deployment (See http://gerrit.ovirt.org/19141 for that). For actually writing the patches, I'm afraid we have little to nothing in place to make your life easier. There is no testing environment, no rspec-puppet based unit tests, no rspec-system based system tests. Not even a simple rake task to validate the syntax[1]. What I can recommend you is puppet-lint and puppet parser validate. If you're a vim user, syntastic (https://github.com/scrooloose/syntastic) does this for you if it's available every time you save. If this is lacking any info or something is unclear, please do ask. I should be back monday, but I can't promise how late or if I'll make the meeting. [1]: If you are going to write tests, I did publish a WIP module which has very little classes and should be a good example: https://github.com/ekohl/puppet-profile_foreman

On Thu, Oct 17, 2013 at 06:15:57PM -0400, R P Herrold wrote:

Eyal Edri mentioned in IRC this morning (to me) that he had opened a couple of puppet tickets on infra matters -- and so I resolved to look on for 'easyfix' fruit to commit for puppet to apply

[ BTW, I solved getting a commit of a trivial gix up to gerrit earlier today as to a vdsm typo, so I think I have write access to git with ssh keying working. Checking the CI server dashboard, I see a broken build, but it seems to be for reasons other than my patch (which should have not have caused any new damag)e: http://gerrit.ovirt.org/#/c/20277/ As I am not certain, however, I decided I should stop further work on that front ]

No harm done by you. We experience way too many false test failures. In your case, a timeout on http://jenkins.ovirt.org/job/vdsm_unit_tests_gerrit/5035/ and a missing output file on http://jenkins.ovirt.org/job/vdsm_unit_tests_gerrit_el/4151 ERROR: testStop (remoteFileHandlerTests.PoolHandlerTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/jenkins/workspace/vdsm_unit_tests_gerrit/tests/remoteFileHandlerTests.py", line 69, in testStop procPath)) File "/home/jenkins/workspace/vdsm_unit_tests_gerrit/vdsm/storage/remoteFileHandler.py", line 184, in callCrabRPCFunction rawLength = self._recvAll(LENGTH_STRUCT_LENGTH, timeout) File "/home/jenkins/workspace/vdsm_unit_tests_gerrit/vdsm/storage/remoteFileHandler.py", line 150, in _recvAll raise Timeout() Timeout Recording test results No test report files were found. Configuration error? Build step 'Publish JUnit test result report' changed build result to FAILURE Finished: FAILURE Why is vdsm_unit_tests_gerrit_el looking for JUnit test result? I do not see this step on the last successful run of http://jenkins.ovirt.org/job/vdsm_unit_tests_gerrit_el/4139/console