Re: oVirt.org Access Needed

On Thu, 23 Jan 2014, Brian Proffitt wrote: Could you please forward those instructions into the infra ML, so the list members can see how it was set up? and so to some questions for clarification: Is 'bitergia' and its sub-parts packaged into a form that has landed in Fedora, or ... where ? I found the demo instance pointed to to be very sluggish and loady on my local browser, but did not run down why yet with a local install I spent some time looking for a way to retrieve the sources to do a local setup, and was not able to find them. Are they under a FOSS license? Is that linked instance pulling real time stats from live servers or from cached details? If the former, infra probably need to get an understanding as to the load effects, as the ovirt infrastructure lacks spare capacity in terms of memory, and in some cases in terms of network bandwidth. No surprises there as it has been reported in infra meetings, and in the Wednesday 'sync' but ... 'do-able' and 'done right' probably are different here. The demo instance shows it _can_ be done, but ... /me looks for a soapbox and puts on an infra 'hat': unpackaged tools are 'magical' magical is a problem Unpackaged tools are un-vetted in a traceable manner as to License. Unpackaged tools in a remote VCS can simply disappear, be invisibly compromised, or go through an API change, or otherwise become NON re-deployable in the future. A start-up vendor can close its doors and disappear, re-license, take down archives, ... . Entropy happens all the time The discipline of packaging prevents many of these problems from gaining a toe-hold, by forcing retrieval of a version, which may be checked against published md5sums (sha, whatever); gets a review (by human eyes); and gets replication of the build process by a non-human auto-builder. If there is a good 'make test', it also has a sample set of configs to read and confirm function of ... Ones which ** require ** a manual [woops -- magical ;) ] content deployment from git from instructions conveyed in a non-public channel (or: unrolling a tarball, running some tool which untraceably solves dependencies, such as 'cpan' or 'npm' to get a point in time image which may be broken tomorrow when one goes to re-deploy it) are broken. It may be pulling in encumbered matter (eg: a patent problem like the old: 'gif', or 'rar'). An undocumented manual configuration / setup process is inherently fragile New non-packaged matter needs explain the path it will follow to move to being packaged. In the interim, it needs the rigor of being documented software 'engineering'. One road to that documentation of process is for it to be done via a VCS checking, and a puppet CO in deployment, just like management of configurations, and re-doable and relocatable via puppet Also, I do not find that this 'bitergia' facility has a tracking bug asking that it be installed [1] [2] If there is an urgency to attain it, today is the first it has been mentioned publicly The approach of 'undocumented' except via back channel communication (digging through IRC logs, digging through email archives, whatever) is a broken one. The result can turn into a subject to a single point of outage when the manual maker of the tool is off line or unavailable otherwise Turning to process for 'infra', it seems to me a person proposing something should be able to point to a solution which has it 'solved' in demonstration with a puppet recipe that is checked into a testing branch of the infra git, which recipes handle building that a testing instance, and then managing its configuration (and so, when re-pointed to 'live', takes it live) -- Russ herrold [1] https://fedorahosted.org/ovirt/report/1?page=1&asc=0&sort=created [2] http://bitergia.com/projects/redhat-ovirt-dashboard/browser/