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