=== harlowja is now known as harlowja_away === alexpilotti_ is now known as alexpilotti [15:12] cmiN, and claudiupopa happy to have you all here. === harlowja_away is now known as harlowja === harlowja is now known as harlowja_away === harlowja_away is now known as harlowja [20:10] harlowja: around ? [20:10] yo [20:10] sup [20:10] why would/should i like to use testr [20:10] versus something else. [20:10] i personally would say don't, lol [20:10] i personally don't like it :-P [20:11] it does running tests in parallel better [20:11] so lets say that you were suggesting something... what would you suggest ? [20:11] but its output imho suck [20:11] just nose ? [20:11] ya, i still think its adeqaute; although pytest is supposedly nice also (although i haven't used it) [20:12] http://pytest.org/latest/ [20:12] i just don't like testr and its creation of weirdly formatted files that are hard to undersetand [20:13] crap like http://logs.openstack.org/10/148810/1/check/gate-taskflow-python27/8b0c041/subunit_log.txt.gz [20:13] but maybe thats really more subunits fault; but testr seems to use it so i'll blame testr, lol [20:14] so imho testr brings in alot of other projects (which sorta sux) [20:14] testttools, subunit, testr... [20:16] i think nose though is sorta dying/not updated anymore [20:16] nm, thats a lie, ha [21:50] harlowja: https://github.com/cloud-init/cloud-init [21:50] fyi. initial stub directory tree. [21:50] now to make something actually work . :) [22:01] woot [22:02] looks good to me, ship it [22:02] Is that replacing the bzr repository at lp:cloud-init? [22:02] i thinks so [22:03] Spiffy. [22:05] now i guess is the question of how do we want this to operate? will this be a daemon that is connected into systemd events (and modules get triggered on events?) [22:05] or will it retain the CLI activation? [22:05] (or both or other...) [22:06] You mean, for a next-generation version of cloud-init? [22:06] ya [22:06] *since afaik thats what the above will become [22:07] Huh. I would argue for not linking it too tightly to systemd, so that it is easy to support it in other environment (other linux distros/freebsd/solaris/etc). [22:07] Unless the goal is really to make it only-distributions-running-systemd sort of thing. [22:08] i hope not, but it would seem like for linux responding to events (network plugged, reset the network information, new-metadata-arrived or something...) would be an approach [22:08] guess it depends on where we want to go here :-P [22:09] Sure. So we can design cloud-init to make that easy through systemd units that run various command lines. [22:09] Things I want: [22:09] - cache metadata from the cloud provider, and then provide a query interface [22:09] - stop masking exceptions, which makes it really hard to debug things [22:10] sure, seems reasonable [22:12] larsks add stuff to https://etherpad.openstack.org/p/cloud-init-next if u want [22:12] Ooo, shiny. [22:12] *if u haven't already [22:14] Are the stackforge suggestions yours? [22:14] i don't think so, ha [22:14] but might be :-P [22:14] Because that seems like a really good idea, too. [22:15] nah, spelling is to good to be mine [22:15] so def not mine, lol [22:15] btw, metadata is already cached locally [22:16] http://cloudinit.readthedocs.org/en/latest/topics/dir_layout.html [22:16] the metadata should be pickled into 'datasource' there (which is the datasource object) [22:16] maybe not as visible as it could be though [22:16] Yeah. [22:16] And picke is awful python-specific. [22:16] Providing a cli for querying it might help, though. [22:17] sure [22:17] reminds me of https://code.launchpad.net/~harlowja/cloud-init/query-back-duo :-P [22:17] from back in the day, ha [22:18] or https://code.launchpad.net/~harlowja/cloud-init/query-tool-is-back ha [22:18] didn't know there was 2 of those, lol [22:18] Nice. [22:18] The cirros cloud-init stuff does provide a query tool, which is nifty. [22:18] cool [22:18] cubswin [22:18] lol [22:19] blame smoser for that password, lol