blackboxsw | thanks powersj | 01:58 |
---|---|---|
smoser | blackboxsw, i followed up on ds-identify bug. | 13:41 |
smoser | adn the one other new one there. | 13:41 |
rharper | powersj: maybe we should enable a jenkins run with that nose-timer ? that's super nice to track every so often | 14:24 |
smoser | rharper, you have to add nose-timer to tox environment. | 14:31 |
smoser | not opposed to that happenting | 14:31 |
rharper | smoser: yeah; just figured that we don;'t all need to do that if we had a daily/weekly checkup via a special jenkins run | 14:32 |
rharper | either is fine | 14:32 |
smoser | its not really a huge deal to add it though | 14:32 |
smoser | compared to a pita for some jenkins job to kind of insert it. | 14:33 |
blackboxsw | morning folks | 14:35 |
smoser | o/ | 14:36 |
powersj | I'd like to get a job to track over all time and if it gets too high fail. | 14:36 |
powersj | Just for tox | 14:36 |
smoser | powersj, well, by design it needs to go up over time | 14:37 |
smoser | at least blackboxsw is bent on that happening. | 14:37 |
smoser | ie, total time is somewhat related to number of tests, and a goal is to increase number of tests. | 14:37 |
blackboxsw | yeah, I feel it's a failure if our tox runs don't take longer | 14:37 |
blackboxsw | :) | 14:37 |
rharper | I thought jenkins jobs were easy? some template and a bash script ? but smoser I think you're right in case someone wants to run it on their own; make it easy in our tox runs | 14:38 |
powersj | Yes but to go from 5 or 6 seconds to 20 is a little unexpected | 14:38 |
blackboxsw | as in, we didn't add more unit tests | 14:38 |
blackboxsw | agreed | 14:38 |
smoser | rharper, well,. figure out how to programatically | 14:38 |
smoser | a.) create the python3 tox environment | 14:38 |
blackboxsw | 5 to 20 seconds means a poorly written test | 14:38 |
smoser | b.) insert the nose package (pip install) | 14:38 |
* powersj relocates | 14:38 | |
smoser | c.) run tox -e py3 and and in the '--nose-timer' args without changing the default command or arguments thaat would noramlly run with | 14:39 |
smoser | across possible changes to the command in trunk | 14:39 |
smoser | it seemed easier to me to just have trunk add the --nose-timer and even run with it. | 14:39 |
smoser | and kind of... why *shouldnt* you be shown that the test you're adding is the slowest one | 14:40 |
powersj | we could also have it show only the top 10 slowest jobs | 14:59 |
rharper | smoser: +1 on showing you you're the slowest | 15:49 |
blackboxsw | bikeshed question-- datasource method names: | 16:01 |
blackboxsw | DS.get_instance_data -- crawls all instance metadata, userdata vendor data but makes no changes to the cached content | 16:02 |
blackboxsw | DS.refresh_instance_cache -- calls get_instance_data and applies it to the cache | 16:02 |
blackboxsw | any other/preferred naming suggestions? I know larsks had a suggestion about that | 16:02 |
blackboxsw | powersj: rharper smoser ^ any paint preference you want to throw on this shed when I rename them and standardize datasources? | 16:03 |
powersj | nope | 16:05 |
rharper | blackboxsw: generally I would expect get_instance_data to return cached data (unless you pass a nocache or something like that) we do that with the blkid bit (and blkid itself will auto cache unless you say otherwise) | 16:05 |
rharper | that is most callers are going to want what's in the cache; some callers are going to know they want to ignore the cache and pull fresh | 16:06 |
blackboxsw | good thought, I like the idea of a no_cache param too | 16:17 |
smoser | i think there are maybe 3 functions oon a datasource object related to metadata | 17:17 |
smoser | a.) crawl the metadata service, getting everything. return that data in a object that is datasource specific. | 17:18 |
smoser | (ie, the one on amazon doens't look like the one on openstack) | 17:18 |
smoser | b.) translate that data from 'a' into the "standard" format | 17:19 |
smoser | c.) update the datasource's cached values from 'b' | 17:20 |
smoser | blackboxsw, ^ | 18:51 |
blackboxsw | smoser: thanks for this. +1 on that thought. right so we might need an intemediary translate implemented that could handle raw -> standard/flattened from each datasource | 19:31 |
blackboxsw | merged powersj https://code.launchpad.net/~powersj/cloud-init/+git/cloud-init/+merge/330111 | 22:40 |
powersj | blackboxsw: thx!! | 22:42 |
blackboxsw | powersj: did you link that branch to a trello card? | 23:08 |
blackboxsw | if not I might attach it to https://trello.com/c/RYkSTMi8/319-ci-build-times-increasing | 23:09 |
powersj | blackboxsw: go for it | 23:09 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!