=== amithkk is now known as nicknametaken === nicknametaken is now known as amithkk === grapz is now known as grapz_afk === grapz_afk is now known as grapz === mbarnett` is now known as mbarnett === avoine is now known as avoine_ === avoine_ is now known as avoine [16:24] <_mup_> juju/trunk r454 committed by kapil.thangavelu@canonical.com [16:24] <_mup_> merge local-respect-series, local provider now respects environment series [r=bcsaller,jimbaker][f=914392] [16:33] hazmat: huh weird, I should have double checked that proposal before sending it to you [16:33] I'll redo it [17:00] When running against a local environment, 'juju ssh' requests the ubuntu user's password as the authorized_keys haven't been copied over. This doesn't occur when running against ec2. Any ideas? === fenris is now known as Guest17978 === koolhead17 is now known as koolhead17|zzZZ === avoine is now known as avoine_ [20:18] hazmat, SpamapS: i'm having trouble with juju on lxc not setting up the ubuntu user properly. it looks like the ubuntu users already exists when 'setup_users' is called, so it returns without populating the .ssh directory. is this a known problem? === tobin is now known as joshuaBRB [20:36] SpamapS: what time is the daily juju package built? looking at the recipes, but it's just "daily"... but they don't seem to be built at midnight UTC or midnight Boston [20:36] m_3_: you'd have to ask the launchpad guys .. I believe it is guaranteed to build at least once per day that has a delta though. [20:36] (trying to sync up testing updates) [20:37] m_3_: you probably just have to poll the ppa to see when the binaries are updated [20:37] well I guess it's ok for the tests to be 24hrs behind [20:37] oh [20:37] hmmmm... ok [20:37] thanks [20:37] SpamapS: hey clint did you see my question above? [20:39] bac: haven't seen that problem, but the lxc charm tests aren't run on the latest juju [20:39] bac: all was working fine wrt jujussh/lxc as of version... (looking) [20:39] m_3_: interesting. btw, i've tried today with the PPA version and the precise distro version. [20:40] bzr451 [20:40] m_3_: someone appears to be unexpectedly setting up the ubuntu user before setup_users is called. perhaps it needs to check for the existence of ~ubuntu/.ssh before deciding to bail. [20:41] m_3_: thanks [20:43] bac: I'll try to reproduce locally in a bit... usually lxc problems turn out to be network-related [20:45] pls verify your `virsh net-list --all` shows default active, and that `ip addr show` shjows virbr0 using 192.168.122.1, dnsmasq has 192.168.122.0/24, lxc guest can resolve names, etc [20:51] bac, why would the ubuntu user existing in the container beforehand? [20:51] its just a debootstrap === joshuaBRB is now known as tobin [20:59] m_3_: are you running your tests on precise btw? we should set that up so we can detect when the OS breaks juju [21:00] m_3_: may be harder than it sounds though.. as spawning a different AMI in a juju cluster is, I think, fairly difficult right now [21:15] SpamapS: that prompted the line of questioning above [21:16] SpamapS: sort of set up the charm expecting to run a set of testing services _per_ series [21:16] unfortunately that means an environment per series right now [21:17] but they'll be rolling up to ' charms' tabs in jenkins.qa.ubuntu.com [21:17] so it shouldn't be a problem [22:31] bac: oneiric checks out fine... precise should work tomorrow morning [22:31] ^^ (wrt juju lxc) [23:03] m_3_: what I really want is for a precise slave to join to the oneiric master testing box. [23:07] SpamapS: gotcha [23:13] m_3_: to do that one would have to reach into zk and tweak the series or image id [23:13] might even have to restart the provisioning agent.. I haven't looked close enough [23:13] SpamapS: opinion... is it better to have oneiric-{lxc,ec2}-charm-bitlbee or just have all providers contribute to an overall oneiric-charm-bitlbee test status? [23:14] we really need a juju setenv or something [23:14] m_3_: I like having more separate tests, because it becomes more scalable [23:15] SpamapS: since we're rolling up to a common external dashboard anyways... not sure the point of spending too much time trying to get oneiric n precise talking [23:17] the build publisher plugin can push results up to the mother ship (jenkins.qa.ubuntu.com) from separate envs [23:17] each env might have master and slaves... but all for a single series [23:18] kicking off tests doesn't have to be centralized.. especially if we're gonna base it on lp changeset info [23:29] * m_3_ really wished we had instance-type per service [23:29] m_3_: i just returned and am reading your previous comments. thanks for following up. [23:30] hazmat: i don't know why the ubuntu user already exists before getting to setup_users. just reporting what i discovered. [23:31] bac: np