On Thu, Jan 23, 2014 at 08:10:19AM -0500, Brian Proffitt wrote: Last time we tried to share credentials, we had problems with it. Any luck with it Karsten? In the short term we can clone the git repository somewhere, you can write the patches and we push it. Maybe we can use gerrit.ovirt.org for this? I don't know how public it can be. Maybe there are hardcoded configurations? In the longer term we could look if the entire source can be made public. Openshift provides environment variables which can be used to remove any hardcoded configuration.

Thanks to all for the assist. Rich just sent me the how to, and apparently, I need to ssh into the actual server to pull the git repo of Bitergia's data into the web server, set up the alias in the conf file, and add a cron job to pull the git data down daily. So, is that do-able? Or would it be easier for someone on the team to set this up? Thanks, BKP ----- Original Message ----- From: "Karsten Wade" <kwade(a)redhat.com&gt; To: infra(a)ovirt.org Sent: Thursday, January 23, 2014 12:12:35 PM Subject: Re: oVirt.org Access Needed -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/23/2014 05:33 AM, Ewoud Kohl van Wijngaarden wrote: This email is helping, sorry we didn't start with this discussion here all together. I've been having trouble adding other people to the admin as members via OpenShift. There is a level of control that only people in the admin group have, and up until about 6 or 9 months ago it could only be one person. That was changed, but there appears to be some bug in my ability to add people, either via the WebUI or the CLI tool. I've asked on #openshift but haven't started a forum thread (yet.) However, I'm not sure that level of access is what Brian needs. I did load in his sshkey, and that should be good enough to pull down the repo and do the changes the Bitergia app (MetricsGrimoire, right?) need done. Brian, I'll email you the link to grab the git repo (it may be on the wiki, too, not sure if we're keeping that private, no real need to beyond obscurity.) Then you need to get the basics on committing and making changes go live. Meanwhile, I'll continue fixing the multiple admins situation somehow. :) Also, if needed, we can do the near-unthinkable and share the single admin account *gasp*. I set it up as quaid(a)ovirt.org because there was no other shared admin ability at that time. We may be on the way there already, and +1 for opening the source entirely to use project tools to get contributions and fixes. Then committers can approve them through. - - Karsten - -- Karsten 'quaid' Wade .^\ CentOS Engineering Manager http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 _______________________________________________ Infra mailing list Infra(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/infra

The data Bitergia is collecting for oVirt, Gluster, and RDO is part of a dashboard project that these teams have been working on for some time now, and the end results are finally ready to post to the oVirt community to get their feedback. What you found in [1] is something that we want to host locally on ovirt.org, using a daily cron job that will pull the cached data from Bitergia's git repo found at [2]. This has already been done by Rich Bowen at RDO, and the results are at [3]. There is no urgency for this task. I did talk to Karsten about it a while back, but my mention of it on the [infra] list is really my first effort to get this going. As you requested, the guidelines sent to me by Rich were: 1) Checkout the [Bitergia] git repo somewhere - anywhere - on the web server. Ensure that the directory is permission +rx so that Apache can descend into the directory and read the files. 2) git pull every morning with a cron job: 0 4 * * * cd /var/redhat-rdo-dashboard/browser && git pull origin master (Not sure about the time - if you can tell about what time every day they push the updates, that would make better timing. I haven't done that yet, so I'm probably a day behind. I should check.) 3) Point Apache at it: Alias /stats /var/redhat-rdo-dashboard/browser <Directory /var/redhat-rdo-dashboard> Options FollowSymLinks Order allow,deny Allow from all DirectoryIndex index.html </Directory> 4) Restart httpd and you should be golden. That'll crate a URI of /stats for that content. Let me know if you have any additional questions. Peace, Brian [1] http://bitergia.com/projects/redhat-ovirt-dashboard/browser/ [2] https://github.com/Bitergia/redhat-ovirt-dashboard [3] http://openstack.redhat.com/stats/ ----- Original Message ----- From: "R P Herrold" <herrold(a)owlriver.com&gt; To: "Brian Proffitt" <bproffit(a)redhat.com&gt; Cc: "oVirt infrastructure ML" <infra(a)ovirt.org&gt; Sent: Thursday, January 23, 2014 3:30:18 PM Subject: 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/

Hi Russ, On 01/23/2014 08:30 PM, R P Herrold wrote: The dashboard is using the Metrics Grimoire, and various tools associated with the project for mailing list, gerrit, Bugzilla, etc. stats: http://metricsgrimoire.github.io/ It's all open source, but the specific configuration files used for oVirt are not published at this point. It's generated daily from data pulled from data sources. Cheers, Dave. -- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13

On Wed, 29 Jan 2014, Dave Neary wrote: so, not packaged -- looking at: http://metricsgrimoire.github.io/, it in turns points to https://github.com/metricsgrimoire with nine component sub-parts (one the web presence and so it may be ignored here), so ... to work packaging ... Setting to teasing the packaging task apart in a CentOS 6 environment, the first [Bicho] pulls in Requires for: python-storm (epel * ) python-beautifulsoup (in Fedora) --seemingly also called: python-BeautifulSoup python-feedparser (epel) python-dateutil base OS * I get consistent local 'make test' failures when the mocker checks DB connectivity, on each of the 19 available python-storm candidates when trying a rebuild from SRPM. I will be filing a bug I do not see any open bug on this package, but then neither I do see that the package went through the expected accessioning review in the Fedora process either [1] After about 1.5 hr work, I have a rough initial packaging done of 'Bicho' -- there is none of the setup doco there yet, and the spec file is ... rough --- I also pushed the generating script (a 'README') to: ftp://ftp.owlriver.com/pub/local/ORC/Bicho/ But obviously doing the remaining ones is in order (this the release exteriorly of the 'README' to re-point at the other seven (let me know, anyone, if such work is done, and where I might pull a revised 'README', and it will save me doing it) If there is confidential information to abstract out [I see that DB credentials are mentioned in the setup documentation] into placefolders that puppet completes, I certainly understand, but the rest should be boiler plate. Seeing a worked example or puppet recipes will speed matters Wonder why it was sluggish. There is a caution in Bicho that it is quite aggressive in pulling content out of bug trackers, and that one has to take steps to slow it down so it does not get banned -- Russ herrold [1] http://red.ht/1aKw8k5

Perhaps I am a bit confused... what is needed here is a cron job that pulls static information from a git repo into a folder on the web server on a daily basis.. and then an alias that points to the browser.html file in that cloned repo via a URL like ovirt.org/stats. This is static content, no packages are being installed on the ovirt.org web server, just data. This is a long-running project to set up a dashboard that the community needs to see so I can get proper feedback about it. If there is a formal ticket process that I have missed, forgive me. I was informed that making this request on this list was the proper way to go. Thanks, Brian ----- Original Message ----- From: "R P Herrold" <herrold(a)owlriver.com&gt; To: "Dave Neary" <dneary(a)redhat.com&gt; Cc: "oVirt infrastructure ML" <infra(a)ovirt.org&gt; Sent: Thursday, January 30, 2014 7:05:03 PM Subject: Re: oVirt.org Access Needed On Wed, 29 Jan 2014, Dave Neary wrote: so, not packaged -- looking at: http://metricsgrimoire.github.io/, it in turns points to https://github.com/metricsgrimoire with nine component sub-parts (one the web presence and so it may be ignored here), so ... to work packaging ... Setting to teasing the packaging task apart in a CentOS 6 environment, the first [Bicho] pulls in Requires for: python-storm (epel * ) python-beautifulsoup (in Fedora) --seemingly also called: python-BeautifulSoup python-feedparser (epel) python-dateutil base OS * I get consistent local 'make test' failures when the mocker checks DB connectivity, on each of the 19 available python-storm candidates when trying a rebuild from SRPM. I will be filing a bug I do not see any open bug on this package, but then neither I do see that the package went through the expected accessioning review in the Fedora process either [1] After about 1.5 hr work, I have a rough initial packaging done of 'Bicho' -- there is none of the setup doco there yet, and the spec file is ... rough --- I also pushed the generating script (a 'README') to: ftp://ftp.owlriver.com/pub/local/ORC/Bicho/ But obviously doing the remaining ones is in order (this the release exteriorly of the 'README' to re-point at the other seven (let me know, anyone, if such work is done, and where I might pull a revised 'README', and it will save me doing it) If there is confidential information to abstract out [I see that DB credentials are mentioned in the setup documentation] into placefolders that puppet completes, I certainly understand, but the rest should be boiler plate. Seeing a worked example or puppet recipes will speed matters Wonder why it was sluggish. There is a caution in Bicho that it is quite aggressive in pulling content out of bug trackers, and that one has to take steps to slow it down so it does not get banned -- Russ herrold [1] http://red.ht/1aKw8k5 _______________________________________________ Infra mailing list Infra(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/infra

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Brian, On 01/23/2014 07:24 PM, Brian Proffitt wrote: One would not do it that way for OpenShift. It is possible to add a cron cartridge, but I don't believe it's possible to update a subdirectory with it. It seems to me like the way to do this is either: 1. Add the cron job on resources.ovirt.org, pull down the files regularly onto that server, and add a new vhost stats.ovirt.org that points there. 2. Pull the files down onto a local server, git add & push them to OpenShift (not recommended to do this automatically, I think) 3. Create a dedicated gear for this on OpenShift and figure out (with the OpenShift guys) how to pull the files down regularly & serve them from the gear 4. Maybe a dedicated instance on oVirt in AlterWay (we have a lab available to us) where we regularly pull down the data via cronjob? It's static content, so maybe it doesn't need to be served through OpenShift. Cheers, Dave. - -- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13