[01:07] <hallyn> when i do a juju bootstrap with saucy targets, juju status hangs, and the /var/log/cloud-init-output.log file shows "
[01:07] <hallyn> The program 'juju-admin' is currently not installed. To run 'juju-admin' please ask your administrator to install the package 'juju'
[01:07] <hallyn> (but juju is installed, juju-admin is not)
[01:33] <davecheney> hallyn: i'm confused
[01:33] <davecheney> which are you running juju status ?
[01:34] <davecheney> and were are you observing output to /var/log/cloud-init-output.log ?
=== thumper is now known as thumper-afk
[02:00] <hallyn> davecheney: juju bootstrap from my laptop to ec2.  juju status from my laptop.  /var/log/cloud-init-output.log  from the bootstrap node
[02:01] <hallyn> is default-series: saucy supported?
[02:04] <davecheney> hallyn: yes, but not recommended
[02:04] <davecheney> only precise charms are used heavily
=== thumper-afk is now known as thumper
[02:17] <hallyn> davecheney: yeah, just tried precise, it worked.  i can work with that for now.  will look into the saucy bit later :(
[02:17] <hallyn> davecheney: thanks
[02:17]  * hallyn out
[02:23] <davecheney> hallyn: the simple fact is
[02:23] <davecheney> there are few (i'd almost say no) saucy charms
=== freeflying is now known as freeflying_away
=== freeflying_away is now known as freeflying
=== axw_ is now known as axw
=== CyberJacob|Away is now known as CyberJacob
[07:27] <synergy_> Help Help!!! :-)
[07:27] <synergy_>  Import of boot images started on all cluster controllers. Importing the boot images can take a long time depending on the available bandwidth.
[07:28] <synergy_> It's been almost 24 hours...
[07:29] <synergy_> BitMessage: BM-NB7JjF6C3KfsT7tK1v8QKJJLjBMPsFPs
[07:32] <synergy_> How long does it take to import boot images?
[07:43] <synergy_> Hello?
[08:06] <jamespage> synergy_, can be quiet here in the mornings :-)
[08:06] <jamespage> synergy_, which maas version?
[08:06] <gnuoy>  I'm doing a fresh deployment with juju on a MaaS cluster. I can bootstrap the juju env fine using a tag to specify the bootstrap node but when I try and deploy a charm I don;t see any physical servers getting allocated in the maas UI and after a minute os so juju reports "error: cannot run instances: gomaasapi: got error back from  server: 409 CONFLICT" as the agent state info for the new machine
[08:07] <gnuoy> I have 16 servers in the Ready state using juju-core  1.16 and maas 1.2+bzr1373+dfsg-0ubuntu1~12.04.2
[08:07] <gnuoy> maas.log shows: NodesNotAvailable: No matching node is available.
[08:08] <gnuoy> When bootstrapping I specified the bootstrap server using a maas tag if thats relevant
[08:42] <synergy_> I can check.
[08:45] <synergy_> juju-core (1.10.0.1-0Ubuntu1~ubuntu13.04.1)
[08:46] <synergy_> maas 13.04
[08:46] <synergy_> sorry, the juju is from my laptop...
[08:46] <synergy_> maas 13.04
[08:47] <synergy_> (came with Ubuntu Server 13.04).
[08:52] <jamespage> synergy_, hmm - that message might be a red herring; have you been able to commission and boot nodes?
[08:57] <jamespage> gnuoy, can you check that the servers are tagged correctly in maas - you can see that through the webui
[08:58] <gnuoy> jamespage, ~10 have tags and 4 do not
[08:58] <gnuoy> shouldn't maas just use an untagged server /
[08:58] <gnuoy> ?
[08:59] <jamespage> gnuoy, might be that the tag constraint for the bootstrap node is applying to all subsequent deploys of charms
[08:59] <jamespage> and I guess you only have one marked for bootstrap tag right?
[08:59] <gnuoy> thats correct
[09:00] <jamespage> gnuoy, OK - check juju get-constraints
[09:01] <gnuoy> tags=bootstrap
[09:01] <gnuoy> is that telling me it will only use servers with that tag ?
[09:01] <gnuoy> for all charms deployments not just for specifying the bootstrap node?
[09:08] <jamespage> gnuoy, yup
[09:08] <jamespage> you can unset the constraint
[09:10] <gnuoy> ok, I'll give that a try but I think this is a bug. I'm not trying to do anything exotic. Specify my smallest server as the bootstrap server and then deploy subsequent charms to any other server
[09:11] <gnuoy> jamespage, do that seem fair or am I missing the point ? ^
[09:13] <jamespage> gnuoy, the problem is that when you bootstrap an environment with --constraints, the constraints are applied environment wide
[09:13] <jamespage> unless you a) override then during charm deploy or b) unset them post bootstrap
[09:14] <gnuoy> jamespage, ok, how do I remove it post bootstrap ? juju set-constraints "tags=" ?
[09:14] <jamespage> hrm - probably
[09:15] <gnuoy> jamespage, that seems to have done the trick. thanks for all your help
[09:57] <FourDollars> Hi, I follow the instructions of https://juju.ubuntu.com/docs/getting-started.html on LXC local provider (Linux). But it failed after I upgrade to 1.16.0-0ubuntu1~ubuntu13.04.1~juju1. It does work on 1.14.
[10:11] <gnuoy> Does juju support booting  instances from a ceph volumes (on Openstack grizzly) ?
[10:27] <jamespage> gnuoy, yup
[10:27] <jamespage> the charms should support that
[10:28] <gnuoy> jamespage, its not a questions of the charms supporting it is it ? juju would need away of specifying a volume when bringing up the VMs ?
[10:28] <jamespage> gnuoy, oh - I see
[10:28] <jamespage> in which case no
[10:30] <gnuoy> jamespage, are there any plans to support it that you know of ?
[10:30] <jamespage> no idea -  sorry
[10:31] <gnuoy> ok, np
[10:43] <gnuoy> jamespage, does this mean that when using openstack the root volumes for your instances are always going to be the local disk on the compute host ?
[10:43] <jamespage> yes
[10:43] <gnuoy> thanks
=== freeflying is now known as freeflying_away
[12:26] <hallyn> davecheney: the charms aren't an issue.  a saucy host won't bootstrap.  There is a packaging issue in saucy juju
=== freeflying_away is now known as freeflying
[12:46] <adeuring> bac: could you please have a look at this MP: https://code.launchpad.net/~adeuring/charmworld/fix-config-yaml-linting/+merge/191391 ?
[12:47] <bac> adeuring: sure
[13:06] <bac> adeuring: i think you have a typo in the MP description s/charmworld tarball/charmtools tarball/.  Could you that just to avoid confusion?
[13:07] <adeuring> bac: argh... yes, that should be "charmtools tarball", soory
[13:07] <bac> adeuring: approved, thanks.
[13:07] <adeuring> bac: thanks!
=== stub1 is now known as stub
[14:03] <sidnei> marcoceppi: seems you're the one doing charm reviews this week? i got 3 that have been through multiple reviews over almost a year and should *really* get landed
[14:04] <marcoceppi> sidnei: yes, I'm on review this week and will be going through them today/tomorrow
[14:04] <marcoceppi> sidnei: link them here and I'll peak at them first
[14:04] <sidnei> https://code.launchpad.net/~sidnei/charms/precise/squid-reverseproxy/trunk/+merge/190500
[14:04] <sidnei> https://code.launchpad.net/~sidnei/charms/precise/apache2/trunk/+merge/190504
[14:04] <sidnei> https://code.launchpad.net/~sidnei/charms/precise/haproxy/trunk/+merge/190501
[14:05] <sidnei> have fun *wink*
[14:29] <jcastro> jamespage, I missed this: "Juju 1.16.0 is also available for Ubuntu Server 12.04 LTS in the Ubuntu Cloud Tools Archive."
[14:29] <jcastro> congratulations/thanks!
[14:30] <jcastro> jamespage, I added some bullets to the release notes, I miss anything major? https://wiki.ubuntu.com/SaucySalamander/ReleaseNotes
[15:46] <sinzui> bac, benji_ : https://bugs.launchpad.net/charmworld/+bug/1229179 is killing me with hate mail. I think the root problem is that routing doesn't know how to select tip when it does not find a version in the URL
[15:46] <_mup_> Bug #1229179: Revisionless bundle requests raise ValueError <oops> <charmworld:Triaged> <https://launchpad.net/bugs/1229179>
[15:47]  * bac looks
[15:47] <rick_h_> sinzui: just filed a bug for that on the charm side. Adding cards to the board for those.
[15:48] <bac> sinzui: i can confirm 'gui' is not a base-10 number!
[15:48] <rick_h_> :)
[15:48] <bac> thanks rick_h_ for the cards
[16:05] <arosales> Hello, we are getting kicked off for the weekly charm sync if anyone would like to join us
[16:06] <arosales> Taking notes @ http://pad.ubuntu.com/7mf2jvKXNa
[16:06] <arosales> Google G+ URL: https://plus.google.com/hangouts/_/683a5a7220f041d63d29ffd87cbe2e8a031ce20b?authuser=0&hl=en
[16:06] <arosales> also being brodcast @ ubuntuonair.com
[16:18] <marcoceppi> https://code.launchpad.net/~hazmat/charms/precise/hadoop/trunk/+merge/191278
[17:07] <jose> marcoceppi: have a min?
[17:07] <marcoceppi> jose: I will in about 30
[17:07] <jose> k
[17:41] <marcoceppi> jose: o/
[17:42] <jose> hey marcoceppi, I'm having a problem with this: http://paste.ubuntu.com/6246832/
[17:43] <marcoceppi> jose: try re-installing lxc
[17:43] <jose> will do
[17:43] <marcoceppi> jose: make sure juju-local package is also installed
[17:43] <jose> it is
[17:44] <jose> reinstalled lxc and same prob
[18:18] <hazmat> sidnei, have you used the lxc thin provisioning bits you added?
[18:18] <sidnei> hazmat: i have, locally. the patch hasn't landed in lxc yet, need to polish it a little bit.
[18:19] <sidnei> and of course the branches in juju didn't land either because of that.
[19:10] <gary_poster> omgponies, hey.  fwiw, I landed a fix for the gui problem that caused the deployer to be upset about subordinates in the exported file.  I'm trying to dupe your other gui issues now, using both gui 0.10.1 and trunk.  we should have a new release tomorrow with at least the first fix; we'll see on the second
[19:11] <omgponies> cool thanks :)
[20:56] <Guest62958> I have a problem with relation-joined or -changed not firing between services. In particular it's in my hue charm that i'm writing and trying to relate to hadoop namenode and jobtracker
[20:56] <Guest62958> I do see  hook.output DEBUG: Cached relation hook contexts on 'hive:122': ['jobtracker:120', 'namenode:119']
[20:56] <Guest62958> Not sure if something is preventing their hooks from firing
[20:56] <Guest62958> f I remove relation between hive and jobtracker, the -departed hook fires
[20:56] <Guest62958> but when I add the relation, no hooks fire whatsoever
[20:59] <Guest62958> Basically I can remove the relation
[20:59] <Guest62958>  relationworkflowstate: transition complete depart (state departed) {}
[21:00] <Guest62958> then when adding it again,  relationworkflowstate: transition start (None -> up) {}
[21:00] <Guest62958>  relationworkflowstate: transition complete start (state up) {}
[21:00] <Guest62958> but no hooks
[21:01] <Guest62958> Can someone help?
[21:01] <Guest62958> juju 0.6.1
[21:02] <davecheney> Guest62958: are your hooks executable ?
[21:05] <Guest62958> Hooks are symlinks to an executable file
[21:05] <Guest62958> They indeed work if I redeploy BOTH of the services
[21:06] <Guest62958> davecheney: But hadoop master gets somehow "stuck" and I can't get the relation hooks to fire on the existing node without bringing it down
[21:06] <Guest62958> So basically something happened to the relation state so that this particular service is prevented from firing hooks or something
[21:17] <davecheney> Guest62958: hmm
[21:17] <davecheney> i don't have any useful suggestions apart from upgrading to Juju 1.14.1
[21:17] <davecheney> but that is quite an upgade jump
[21:18] <Guest62958> yeah, can't do that any time soon. The machines in question are used b the development team...
[21:19] <Guest62958> davecheney: I did find an intersting detail about the problem though
[21:19] <Guest62958> there was a "service" in my environment that was called just hadoop (not hadoop-master or hadoop-slave)
[21:20] <Guest62958> but it was not up... not sure for what reason. and when I tested some stuff I accidentally tried to relate to i, rather than hadoop-master
[21:22] <Guest62958> When I destroyed that service, I got a bunch of fired repeated events  unit.lifecycle DEBUG: processing relations changed when i tried to create the relation from hue to master
[21:22] <Guest62958> as if something got released
[21:22] <Guest62958> from some stck queue
[21:22] <Guest62958> stuck*
[21:23] <marcoceppi> davecheney: 1.16.0 *
[22:47] <davecheney> hallyn: oh crap
[22:47] <davecheney> is there a bug for saucy not working ?
[22:47] <hallyn> davecheney: i didn't open one
[22:49] <hallyn> davecheney: you've reproduced?
[23:00] <davecheney> hallyn: no, i am childless
[23:01] <sidnei> lol
[23:31] <hallyn> davecheney: good to know :)  on a different note, have you run into the bug yourself?
[23:35] <davecheney> no, i did not attempt to reproduce
=== CyberJacob is now known as CyberJacob|Away