[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] <jcastro> hazmat: huh weird, I should have double checked that proposal before sending it to you
[16:33] <jcastro> I'll redo it
[17:00] <bac> 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?
[20:18] <bac> 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?
[20:36] <m_3_> 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] <SpamapS> 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] <m_3_> (trying to sync up testing updates)
[20:37] <SpamapS> m_3_: you probably just have to poll the ppa to see when the binaries are updated
[20:37] <m_3_> well I guess it's ok for the tests to be 24hrs behind
[20:37] <m_3_> oh
[20:37] <m_3_> hmmmm... ok
[20:37] <m_3_> thanks
[20:37] <bac> SpamapS: hey clint did you see my question above?
[20:39] <m_3_> bac: haven't seen that problem, but the lxc charm tests aren't run on the latest juju
[20:39] <m_3_> bac:  all was working fine wrt jujussh/lxc as of version... (looking)
[20:39] <bac> m_3_: interesting.  btw, i've tried today with the PPA version and the precise distro version.
[20:40] <m_3_> bzr451
[20:40] <bac> 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] <bac> m_3_: thanks
[20:43] <m_3_> bac: I'll try to reproduce locally in a bit... usually lxc problems turn out to be network-related
[20:45] <m_3_> 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] <hazmat> bac, why would the ubuntu user existing in the container beforehand?
[20:51] <hazmat> its just a debootstrap
[20:59] <SpamapS> 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] <SpamapS> 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] <m_3_> SpamapS: that prompted the line of questioning above
[21:16] <m_3_> SpamapS: sort of set up the charm expecting to run a set of testing services _per_ series
[21:16] <m_3_> unfortunately that means an environment per series right now
[21:17] <m_3_> but they'll be rolling up to '<series> charms' tabs in jenkins.qa.ubuntu.com
[21:17] <m_3_> so it shouldn't be a problem
[22:31] <m_3_> bac: oneiric checks out fine... precise should work tomorrow morning
[22:31] <m_3_> ^^ (wrt juju lxc)
[23:03] <SpamapS> m_3_: what I really want is for a precise slave to join to the oneiric master testing box.
[23:07] <m_3_> SpamapS: gotcha
[23:13] <SpamapS> m_3_: to do that one would have to reach into zk and tweak the series or image id
[23:13] <SpamapS> might even have to restart the provisioning agent.. I haven't looked close enough
[23:13] <m_3_> 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] <SpamapS> we really need a juju setenv or something
[23:14] <SpamapS> m_3_: I like having more separate tests, because it becomes more scalable
[23:15] <m_3_> 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] <m_3_> the build publisher plugin can push results up to the mother ship (jenkins.qa.ubuntu.com) from separate envs
[23:17] <m_3_> each env might have master and slaves... but all for a single series
[23:18] <m_3_> 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] <bac> m_3_: i just returned and am reading your previous comments.  thanks for following up.
[23:30] <bac> hazmat: i don't know why the ubuntu user already exists before getting to setup_users.  just reporting what i discovered.
[23:31] <m_3_> bac: np