Tuesday, 2017-02-14

*** jrist has quit IRC01:58
*** jrist has joined #ara02:12
*** karimb has joined #ara08:50
boxrick1I notice a new ARA version10:22
boxrick1Also just pip upgrades easy without making the database blow up or anything, nice :)10:33
boxrick1I had a bit of poking around since the "all" pages can load quite slowly11:19
boxrick1I optimised my database, and its running on a lightning fast box with loads of RAM11:19
boxrick1Queries are basically instant, but the APP usage spikes up to 100% of a single core when you load that page, even doing 3 simultaneous loads it doesn't go a above 1 core. So I suspect everything is single threaded ?11:22
*** jrist has quit IRC11:27
boxrick1This is also with Threaded=True and in WSGI and multiple threads within Apache config11:34
*** jrist has joined #ara11:40
*** karimb has quit IRC12:48
dmsimardboxrick1: how many playbooks are there ? Even the "all playbooks" page will eventually be paginated, just haven't done it yet.12:51
*** karimb has joined #ara13:16
boxrick1dmsimard: Can't locate revision identified by '22aa8072d705' <--- After version upgrade13:25
boxrick12017-02-14 13:22:14,663 - ara - INFO - DB schema out of date, upgrading13:28
boxrick1But this is only for some users after upgrase13:29
boxrick1Upgrade*13:29
boxrick1Going to scrub everything and start fresh but it may be useful.13:29
boxrick1Ok seems the app version was inconsistent, so it kept running schema changes against the same database.13:33
dmsimardboxrick1: that looks like one of the nodes running ARA wasn't upgraded and the schema had already been upgraded by a node (or the other way around)13:53
boxrick1Yea I thought as much13:53
boxrick1I wonder if it is worth version checking and making sure older versions don't try and update newer schemas in the future13:53
dmsimardRight now database migrations are done automatically from a user experience simplicity standpoint but I could make that configurable so that advanced use cases can control their migrations13:53
dmsimardboxrick1: there ya go, thanks: https://storyboard.openstack.org/#!/story/200086713:55
boxrick1Cool looks good.14:51
openstackgerritAndreas Naf proposed openstack/ara master: basic auth functionality  https://review.openstack.org/43370315:20
*** tbielawa has joined #ara15:43
*** karimb has quit IRC17:25
*** myoung has quit IRC17:51
*** tbielawa has quit IRC18:43
*** myoung has joined #ara18:53
*** openstackgerrit has quit IRC20:18
dmsimardOh hey, I posted about the release of ARA in /r/ansible and it's on the frontpage of all-time top posts :D https://www.reddit.com/r/ansible/top/?sort=top&t=all21:33
dmsimardGive me that karma !21:33
*** openstackgerrit has joined #ara22:17
openstackgerritHugh Saunders proposed openstack/ara master: Improve structure of junit output  https://review.openstack.org/43395222:17
hughsaundersdmsimard: ^ Improvements based on a few days usage of junit output. Main problem is that I want to compare tasks across jobs, but I run most jobs on throw away nodes. If the node name is in the test name, then jenkins sees each task/test as unique, rather than multiple instances of the same task/test.22:21
hughsaundersdmsimard: ps upvoted ;-)22:25
dmsimardhughsaunders: hm, good point -- I guess it also makes sense if you have multiple hosts running the same tasks too, right ? You want to compare the results across your hosts.22:27
dmsimardAs in, within the same playbook with multiple hosts22:28
dmsimardNot necessarily across playbook runs with different throwaway nodes22:28
dmsimardhughsaunders: going to double check with my ghetto npm junit viewer but lgtm22:31
hughsaundersdmsimard: Yeah, though current situation works for that use case, as jenkins doesn't have any built in logic to compare across hosts, so you'd have to do it by looking through the results.22:32
hughsaundersJenkins however does have views for showing the history of a test, and thats what I want to enable with this patch22:32
* dmsimard installs npm on test vm *shudders*22:33
hughsaundersdmsimard: I experimented with adding the full result to every task, but I was catting the junit.xml file into the log for debug, and ended up with 1.6GB of jenkins console log, after a openstack-ansible + rpc deploy -_-22:34
dmsimardyeah, openstack-ansible has very interesting runs22:34
dmsimardI love it though, it's a good use case to work against22:34
hughsaunders\o/22:35
dmsimardI eventually want to benchmark size + amount of files + static generation time after I'm done with the UI rework22:35
dmsimardLast time I tried it was around 13k files22:35
dmsimard(which makes no sense)22:36
*** cliles_ has joined #ara22:36
hughsaundersCurrent OSA run has recorded 7283 tasks, including 2849 skips. Certainly gives ara a workout.22:37
dmsimardbtw, one of the ultimate goals of ara22:37
dmsimardis to implement it by default in zuul :)22:37
hughsaunders:)22:37
dmsimardand then you could have crazy task-level indexing in logstash or results in http://status.openstack.org/openstack-health/#/ by default22:38
hughsaundersI know very little about frontend stuff, but could you squash all the static files with webpack or similar?22:38
dmsimardI'm relying on flask-frozen which tl;dr just fires flask and crawls the entire app and then generates a file for every page22:39
dmsimardbut when you have 7.5k tasks, it means it has to generate result pages for those 7.5k tasks, pages that filter the tasks by those tasks, etc.22:39
dmsimardit's not that heavy gzipped, just takes forever to generate22:39
dmsimarddue to the amount of pages it has to crawl and generate22:40
hughsaundersWould be cool to have a single page app, with massive JSON blob that it can interpret, filter, sort etc.22:40
dmsimardthe UI rework will have less "pages" to generate but I can't go overboard or users like openstack-ansible will end up with a single page that'll be like 100MB22:40
dmsimardhave to find a good middle ground we'll be happy with, above that, will just have to tell folks to use the dynamic database driven app22:41
*** mnaser_ has joined #ara22:41
*** mnaser_ has joined #ara22:41
*** mnaser has quit IRC22:42
*** cliles has quit IRC22:42
*** mnaser_ is now known as mnaser22:42
hughsaundersWould be interesting to know how big the sqlite database is after an osa run. My current jenkins job blats the db after each playbook to allow incremental result posting and prevent double reporting of tasks.22:45
dmsimardghetto npm junit viewer is happy http://i.imgur.com/qkyEtPt.png22:45
dmsimardhughsaunders: there's a review somewhere, it's tiny22:45
dmsimardhttps://review.openstack.org/#/c/396324/22:46
dmsimardah, crap, the logs have been pruned22:46
*** themurph has quit IRC22:46
dmsimardbut it was like less than 10MB22:46
hughsaundersdmsimard: that wouldn't be too bad to embed then, especially if the parsing was async.22:47
*** themurph has joined #ara22:47
dmsimardhughsaunders: close, 6MB: http://eavesdrop.openstack.org/irclogs/%23openstack-ansible/%23openstack-ansible.2016-11-15.log.html#t2016-11-15T18:51:3322:47
dmsimardhughsaunders: oh, yeah, by all means the database driven webapp is super lightweight and fast22:48
hughsaundersdmsimard: can npm junit viewer show the output for successful tasks?22:48
hughsaundershmm, also that skipped task should have stdout as well as a skip message.22:49
dmsimardhughsaunders: have no clue, I guess it shows whatever it has22:49
hughsaundersdmsimard: well works for me in Jenkins..22:49
dmsimardhughsaunders: hang on22:50
dmsimardhughsaunders: https://dmsimard.com/files/junit.html22:50
dmsimardfrom saving to a file -> https://www.npmjs.com/package/junit-viewer22:51
hughsaundersdmsimard: example of skip message vs stdout: https://snag.gy/cFTbjK.jpg22:57
hughsaundersit looks like the npm app doesn't encode all the data, because in the junit_info dict, most of the tasks have messages: {values: [], ... }. The skipped task has a populated values list.23:00
hughsaunderslaters23:01
openstackgerritMerged openstack/ara master: Improve structure of junit output  https://review.openstack.org/43395223:06

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!