=== scuttle|afk is now known as scuttlemonkey === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === fuzzy__ is now known as Ponyo === mup_ is now known as mup === liam_ is now known as Guest3630 [10:38] Hi, lads. When using amulet, how can I ennumerate/enlist/get/fetch all the deployed units? [11:16] jamespage, got a sec for https://code.launchpad.net/~gnuoy/charms/trusty/openstack-dashboard/1420708/+merge/249303 ? [11:17] gnuoy, what does -t do? [11:17] jamespage, it creates a default pin at priority 990 using the specified release string [11:18] otherwise precise/universe has priority over precise-updates/cloud-tools/main [11:19] and python-six doesn't upgrade [11:22] gnuoy, remind me what the default priority is? [11:22] jamespage, http://paste.ubuntu.com/10171980/ [11:23] gnuoy, hmm - don't we want the version from precise-icehouse though? [11:23] jamespage, argh, ok, I'll be back.... [11:37] jamespage, mp updated [11:38] gnuoy, looks ok - but I'd probably just add python-six to packages [11:38] and install in one hit [11:39] I was keeping it seperate so it could be removed later since, as you say, the root cause is a pkg dep error [11:39] but I don't feel strongly [11:47] jamespage, adding it to packages won't work [11:47] as it's filtered on installed packages [11:48] gnuoy, ah yes - of course [11:48] gnuoy, +1 [11:48] ta [12:26] jamespage: new charmhelper unitdata.py landed might be useful if you need to keep state in charms [13:28] Mmike: there's a dictionary of all units in the topolgy exposed by d.sentry.units [13:29] d being your deployment object [13:29] exit [14:58] lazyPower, ok how do I find the test results for the mariadb charm? [15:14] tvansteenburgh, is there a way to see charm test results for one individual charm over time? [15:15] jcastro: http://reports.vapour.ws/charm-summary/meteor [15:15] ah, was in the wrong section then,t hanks === scuttle|afk is now known as scuttlemonkey [15:39] marcoceppi, we should probably decide what we'll deploy @ SCALE [15:39] * marcoceppi nods [15:56] rick_h_, were there any conclusion wrt bundle inheritance? [15:57] *s [15:58] whit: that what was being asked for was more bundle composition vs inheritance and there's some work with core folks to see if we can think about bundles in a way that would allow that [15:59] rick_h_, composition works though I would imagine better support for what deployer does now would be less churn [15:59] but with so few users [15:59] * whit shrugs [16:00] whit: these were just the feedback there. What they hoped to accomplish wasn't really something inheritance could do [16:00] whit: so it was decided just going back and adding inheritance via the bundle definition wasn't going to solve it either === Guest25083 is now known as rcj === roadmr is now known as roadmr_afk === kadams54 is now known as kadams54-away [20:18] Is the m3.small too small for the bootstrap node? Or why is the m1.small the default, but m3.small (which is the recommended transition from m1.small) not an option? http://paste.ubuntu.com/10177609/ [20:23] noodles775: https://bugs.launchpad.net/juju-core/+bug/1373516 ? [20:23] Bug #1373516: Switch default instance type from m1.small to t2.small/m3.medium for EC2 provider

[20:24] lazyPower, https://launchpad.net/ubuntu/vivid/+source/mariadb-5.5 [20:24] we have it for ppc64le [20:24] oh nice [20:24] my search foo stinks apparently [20:24] so all that needs to happen is add a config option [20:24] it took me a while to find it [20:24] http://packages.ubuntu.com/search?keywords=mariadb&searchon=names&suite=utopic§ion=all === kadams54-away is now known as kadams54 [20:24] that site doesn't show ppc64le [20:24] oh boo :( [20:24] Thanks jrwren [20:27] Is there a convention for managing pip download caches in charms? Have source tarballs in files/ so perhaps there? === roadmr_afk is now known as roadmr [21:47] blr: you could cache them anywhere in teh charm, I don't think there's any one convention defined [21:48] marcoceppi: yep, ended up adding a pip-cache directory under files which the deploy make target updates now. thanks [22:02] stokachu, ping [22:05] mwenning: pong [22:06] stokachu, a customer just pinged me - he's trying to to run an openstack install using a 14.10 LDS server, 14.04 MAAS and 14.04 target machines. [22:06] cool [22:07] stokachu, his machines name the NIC interface as 'p1p1' - this causes an error when it tries to create juju-br0 [22:07] ever heard of this? [22:07] yea there is another bug on gh where it was reported [22:07] not sure its an installer issue though [22:07] groovy, what's the bug # [22:07] mwenning: https://github.com/Ubuntu-Solutions-Engineering/openstack-installer/issues/349 [22:07] :-) [22:07] should probably create a launchpad bug against juju [22:08] That was my next question... [22:08] i haven't looked that far into it so i dont know who to start with first [22:08] i would assume juju if its configuring the br0 network before a network device rename takes place [22:09] but that poster never got back to me [22:09] ok, do you want to create the bug or me? [22:10] mwenning: go for it if its from a customer [22:10] ill subscribe the team to it [22:10] and work with juju guys to reproduce [22:10] stokachu, ok. I'm gonna get some data from him, I'll ping you when I get the bug written up [22:11] mwenning: cool, get a sosreport of his system too [22:11] attach to the bug [22:11] mwenning: thanks [22:13] ah, yes. does that pull everything in or do you need other stuff? for example maas wants a tar of /etc/maas/*, etc [22:13] mwenning: it should pull maas data in as well [22:13] it checks if its installed and acts on that [22:13] stokachu, groovy, will do [22:13] cool man [22:20] mwenning stokachu I think you can outline some of the bridge stuff in juju config [22:20] * marcoceppi greps through go src code === Guest82007_ is now known as Viperz28 === kadams54 is now known as kadams54-away [22:46] marcoceppi: cool i need to take a look at that [22:46] marcoceppi: has something to do with udev device renaming