*** jrist has quit IRC | 01:58 | |
*** jrist has joined #ara | 02:12 | |
*** karimb has joined #ara | 08:50 | |
boxrick1 | I notice a new ARA version | 10:22 |
---|---|---|
boxrick1 | Also just pip upgrades easy without making the database blow up or anything, nice :) | 10:33 |
boxrick1 | I had a bit of poking around since the "all" pages can load quite slowly | 11:19 |
boxrick1 | I optimised my database, and its running on a lightning fast box with loads of RAM | 11:19 |
boxrick1 | Queries 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 IRC | 11:27 | |
boxrick1 | This is also with Threaded=True and in WSGI and multiple threads within Apache config | 11:34 |
*** jrist has joined #ara | 11:40 | |
*** karimb has quit IRC | 12:48 | |
dmsimard | boxrick1: 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 #ara | 13:16 | |
boxrick1 | dmsimard: Can't locate revision identified by '22aa8072d705' <--- After version upgrade | 13:25 |
boxrick1 | 2017-02-14 13:22:14,663 - ara - INFO - DB schema out of date, upgrading | 13:28 |
boxrick1 | But this is only for some users after upgrase | 13:29 |
boxrick1 | Upgrade* | 13:29 |
boxrick1 | Going to scrub everything and start fresh but it may be useful. | 13:29 |
boxrick1 | Ok seems the app version was inconsistent, so it kept running schema changes against the same database. | 13:33 |
dmsimard | boxrick1: 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 |
boxrick1 | Yea I thought as much | 13:53 |
boxrick1 | I wonder if it is worth version checking and making sure older versions don't try and update newer schemas in the future | 13:53 |
dmsimard | Right 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 migrations | 13:53 |
dmsimard | boxrick1: there ya go, thanks: https://storyboard.openstack.org/#!/story/2000867 | 13:55 |
boxrick1 | Cool looks good. | 14:51 |
openstackgerrit | Andreas Naf proposed openstack/ara master: basic auth functionality https://review.openstack.org/433703 | 15:20 |
*** tbielawa has joined #ara | 15:43 | |
*** karimb has quit IRC | 17:25 | |
*** myoung has quit IRC | 17:51 | |
*** tbielawa has quit IRC | 18:43 | |
*** myoung has joined #ara | 18:53 | |
*** openstackgerrit has quit IRC | 20:18 | |
dmsimard | Oh 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=all | 21:33 |
dmsimard | Give me that karma ! | 21:33 |
*** openstackgerrit has joined #ara | 22:17 | |
openstackgerrit | Hugh Saunders proposed openstack/ara master: Improve structure of junit output https://review.openstack.org/433952 | 22:17 |
hughsaunders | dmsimard: ^ 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 |
hughsaunders | dmsimard: ps upvoted ;-) | 22:25 |
dmsimard | hughsaunders: 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 |
dmsimard | As in, within the same playbook with multiple hosts | 22:28 |
dmsimard | Not necessarily across playbook runs with different throwaway nodes | 22:28 |
dmsimard | hughsaunders: going to double check with my ghetto npm junit viewer but lgtm | 22:31 |
hughsaunders | dmsimard: 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 |
hughsaunders | Jenkins however does have views for showing the history of a test, and thats what I want to enable with this patch | 22:32 |
* dmsimard installs npm on test vm *shudders* | 22:33 | |
hughsaunders | dmsimard: 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 |
dmsimard | yeah, openstack-ansible has very interesting runs | 22:34 |
dmsimard | I love it though, it's a good use case to work against | 22:34 |
hughsaunders | \o/ | 22:35 |
dmsimard | I eventually want to benchmark size + amount of files + static generation time after I'm done with the UI rework | 22:35 |
dmsimard | Last time I tried it was around 13k files | 22:35 |
dmsimard | (which makes no sense) | 22:36 |
*** cliles_ has joined #ara | 22:36 | |
hughsaunders | Current OSA run has recorded 7283 tasks, including 2849 skips. Certainly gives ara a workout. | 22:37 |
dmsimard | btw, one of the ultimate goals of ara | 22:37 |
dmsimard | is to implement it by default in zuul :) | 22:37 |
hughsaunders | :) | 22:37 |
dmsimard | and then you could have crazy task-level indexing in logstash or results in http://status.openstack.org/openstack-health/#/ by default | 22:38 |
hughsaunders | I know very little about frontend stuff, but could you squash all the static files with webpack or similar? | 22:38 |
dmsimard | I'm relying on flask-frozen which tl;dr just fires flask and crawls the entire app and then generates a file for every page | 22:39 |
dmsimard | but 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 |
dmsimard | it's not that heavy gzipped, just takes forever to generate | 22:39 |
dmsimard | due to the amount of pages it has to crawl and generate | 22:40 |
hughsaunders | Would be cool to have a single page app, with massive JSON blob that it can interpret, filter, sort etc. | 22:40 |
dmsimard | the 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 100MB | 22:40 |
dmsimard | have 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 app | 22:41 |
*** mnaser_ has joined #ara | 22:41 | |
*** mnaser_ has joined #ara | 22:41 | |
*** mnaser has quit IRC | 22:42 | |
*** cliles has quit IRC | 22:42 | |
*** mnaser_ is now known as mnaser | 22:42 | |
hughsaunders | Would 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 |
dmsimard | ghetto npm junit viewer is happy http://i.imgur.com/qkyEtPt.png | 22:45 |
dmsimard | hughsaunders: there's a review somewhere, it's tiny | 22:45 |
dmsimard | https://review.openstack.org/#/c/396324/ | 22:46 |
dmsimard | ah, crap, the logs have been pruned | 22:46 |
*** themurph has quit IRC | 22:46 | |
dmsimard | but it was like less than 10MB | 22:46 |
hughsaunders | dmsimard: that wouldn't be too bad to embed then, especially if the parsing was async. | 22:47 |
*** themurph has joined #ara | 22:47 | |
dmsimard | hughsaunders: close, 6MB: http://eavesdrop.openstack.org/irclogs/%23openstack-ansible/%23openstack-ansible.2016-11-15.log.html#t2016-11-15T18:51:33 | 22:47 |
dmsimard | hughsaunders: oh, yeah, by all means the database driven webapp is super lightweight and fast | 22:48 |
hughsaunders | dmsimard: can npm junit viewer show the output for successful tasks? | 22:48 |
hughsaunders | hmm, also that skipped task should have stdout as well as a skip message. | 22:49 |
dmsimard | hughsaunders: have no clue, I guess it shows whatever it has | 22:49 |
hughsaunders | dmsimard: well works for me in Jenkins.. | 22:49 |
dmsimard | hughsaunders: hang on | 22:50 |
dmsimard | hughsaunders: https://dmsimard.com/files/junit.html | 22:50 |
dmsimard | from saving to a file -> https://www.npmjs.com/package/junit-viewer | 22:51 |
hughsaunders | dmsimard: example of skip message vs stdout: https://snag.gy/cFTbjK.jpg | 22:57 |
hughsaunders | it 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 |
hughsaunders | laters | 23:01 |
openstackgerrit | Merged openstack/ara master: Improve structure of junit output https://review.openstack.org/433952 | 23:06 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!