[02:54] <sebas5384> someone there?
[02:55] <sebas5384> :)
[11:55] <didrocks> hum, is it me or juju debug-hooks is broken (on local provider), using the stable ppa?
[13:39] <lazyPower> didrocks: i can't say i'm seeing the same behavior. I've been in debug hooks for the last 40 minutes working with the wordpress charm
[13:40] <didrocks> lazyPower: are you using a local provider?
[13:40] <lazyPower> i am, but i just verified i'm not on -stable. i'm running the 1.19 series :(
[13:40] <didrocks> ah, that might explain
[13:40] <didrocks> I have an install hook at fail
[13:40] <lazyPower> when you debug-hooks in what do you see? just a plain jane tmux screen?
[13:41] <didrocks> exactly, running as root with like: root@didrocks-local-machine-5:~#
[13:41] <lazyPower> thats expected
[13:41] <didrocks> I ran beforehand: $ juju debug-hooks vanilla/0 install
[13:42] <didrocks> hum, isn't the prompt modified?
[13:42] <lazyPower> did you attempt to resolved -r teh hook?
[13:42] <lazyPower> you need to re-run the failed hook to regain the hook context that you're looking for
[13:42] <didrocks> lazyPower: ah, so I debug-hooks
[13:42] <didrocks> and from outside
[13:42] <didrocks> I do resolved -r?
[13:43] <lazyPower> yeah, that's something we mentioned at our last sprint is it would be nice to do all that from within the debug-hooks session rather than open yet another terminal and re-execute the failed hook
[13:43] <lazyPower> but for now, thats the workflow. yep yep
[13:44] <didrocks> lazyPower: indeed, that works!
[13:44] <lazyPower> cheers! :)
[13:44] <didrocks> thanks a lot, I probably misread the documentation :)
[13:45] <lazyPower> didrocks: keep that in mind as you go through the process and file any bugs for things that are unclear to you. We can always use the feedback of fresh eyes.
[13:45] <didrocks> lazyPower: right, I may amend and propose a pull request after rerunning the debug hooks one
[13:45] <didrocks> I wasn't expecting it to work like that at all
[13:46] <lazyPower> thanks :) I look forwarding to ack'ing your PR
[13:46] <didrocks> yw! thanks to you :)
[13:47] <rbasak> sinzui: make-release-tarball.bash is giving me: "godeps: cannot parse "/home/ubuntu/juju-core/juju-release-tools/tmp.s9oYZdPuOc/RELEASE/src/launchpad.net/juju-core/dependencies.tsv": cannot find directory for "github.com/errgo/errgo": not found in GOPATH" today.
[13:47] <rbasak> sinzui: any help, please? This worked last week.
[13:48] <rbasak> I see that github.com/errgo/errgo does appear to exist, and the commit hash mentioned is one behind HEAD.
[13:49] <rick_h_> rbasak: that was moved to github this last week I believe
[13:50] <rbasak> rick_h_: I'm using the 1.18 branch. "./make-release-tarball.bash 2291 lp:juju-core/1.18" worked last week, but doesn't work now (so dependencies.tsv hasn't changed I guess?)
[13:50] <rbasak> 2293 is current which is what I was attempting to start with, but since that failed with the same message, It tried 2291 instead.
[13:52] <rick_h_> rbasak: yea not sure. I just know in the last week in trunk that moved over to github and the dep is relocated. github.com/juju/errgo in trunk
[13:52] <lazyPower> natefinch: I'm having trouble reproducing https://bugs.launchpad.net/charms/+source/wordpress/+bug/1317644 I issued a request for more info if you have time.
[13:52] <_mup_> Bug #1317644: Can't install wordpress on local provider with trusty host <wordpress (Juju Charms Collection):Incomplete by lazypower> <https://launchpad.net/bugs/1317644>
[13:52] <rick_h_> rbasak: so I'm betting they pulled the old location in errgo/errgo
[13:52] <rick_h_> rbasak: oh hmm, maybe not https://github.com/errgo/errgo
[13:53] <rick_h_> rbasak: so ignore me, no idea. Just know there's been some stuff crossing the commit wire right around your trouble
[13:53] <sinzui> rbasak, when that happens, the juju devs have broken juju.
[13:53] <rbasak> sinzui: but I tried the old revision that previously worked
[13:53] <natefinch> lazyPower: I'll try to repro it again today... can't right now.
[13:54] <lazyPower> ack. Thanks for taking another look natefinch
[13:54] <sinzui> rbasak, CI doesn't see it broken though? yes, and the devs delete/move repos and GO knows that is bad
[13:55] <sinzui> rbasak, get the latest scripts from lp:juju-release-tools which may have a fix
[13:55] <rbasak> sinzui: I only checked out the branch ten minutes ago.
[13:57] <sinzui> rick_h_, that project was removed a few weeks ago, I asked the developers to put it back
[13:58] <sinzui> rbasak, I suspect the issue is caused when "go get" get the current packages for juju, then then the script pins the juju to the older revision, which has a different set of packages that were not gotten.
[13:59] <sinzui> rbasak, which branch and revision are you building?
[13:59] <rbasak> sinzui: is that a bug in the script then?
[13:59] <rbasak> sinzui: "./make-release-tarball.bash 2291 lp:juju-core/1.18"
[13:59] <rbasak> (2292 and 2293 also fail)
[14:05] <sebas5384> hello :)
[14:06] <rbasak> sinzui: I filed https://bugs.launchpad.net/juju-release-tools/+bug/1320891
[14:06] <_mup_> Bug #1320891: make-release-tarball.bash fails with godeps failure <juju-release-tools:New> <https://launchpad.net/bugs/1320891>
[14:06] <sinzui> rbasak, I am still building that to identify the issue
[14:07] <rbasak> OK, thanks
[14:07] <sinzui> ah, developers moved errgo to juju/errgo
[14:07] <sinzui> they broke the build
[14:07]  * sinzui ponders a shim
[14:08] <rbasak> sinzui: but CI is still green?
[14:08] <sinzui> CI wont break until a developer commits to 1.18, then they would see the deps are wrong
[14:09] <rbasak> Perhaps CI should run periodically then, for processes that have external dependencies?
[14:09] <sinzui> rbasak, They landing bot has deps manages by people, so there would be an undetected mismatch between  dependencies.tsv and what GO sees
[14:10] <sinzui> rbasak, the devs are supposed to tell me when they fuck this up, otherwise I make them fix a critical bug
[14:10] <rbasak> sinzui: it sounds like this should really be in the CI loop, so it doesn't need your manual intervention. Should I file a bug for that?
[14:10] <sinzui> no
[14:11] <sinzui> rbasak, I have 9 months of work. I wont get to it because the devs have to fix the regressions they introduce
[14:11] <sinzui> They can always avoid the regression by tell me.
[14:12] <sinzui> rbasak, I am adding a shim now
[14:22] <sinzui> rbasak, pull again to get the fix
[14:24] <rbasak> Trying...
[14:29] <rbasak> sinzui: that worked. Thanks!
[14:49] <mhall119> jcastro: ping
[14:53] <jcastro> mhall119, yo!
[14:56] <mhall119> jcastro: hey, I'm setting up the new Ubuntu Online Summit, which will be a mix of UDS, Developer Week and Open Week
[14:56] <jcastro> ok
[14:56] <mhall119> I've combined most of the development tracks from previous vUDS into a single "Platform Development" track, including core cloud stuff
[14:57] <jcastro> ok
[14:57] <jcastro> so you need content from us I take it?
[14:57] <mhall119> jono suggested we could have a DevOps track too, to focus on the consumers of the cloud, woudl you guys be willing to lead that?
[14:58] <jcastro> for sure
[14:58] <jcastro> I just need dates, # of slots, etc and I can get to work
[14:58] <mhall119> June 10-12
[14:58] <mhall119> as many slots/hour as you need
[14:58] <mhall119> 1400 UTC to 2000 UTC
[14:58] <jcastro> ok
[14:58] <jcastro> Are they hour slots or shorter?
[15:00] <mhall119> still an hour
[15:03] <mhall119> jcastro: I'll give you 2 rooms for now, so 2 slots per hour
[15:03] <mhall119> I can easily add more rooms if you need them
[15:05] <jcastro> ack, let me know when summit opens up
[15:08] <mhall119> jcastro:
[15:08] <mhall119> http://summit.ubuntu.com/uos-1406/
[15:08] <mhall119> LP sprint is https://launchpad.net/sprints/uos-1406 for filing BPs
[15:08] <jcastro> ok
[15:08] <mhall119> note that it's 'uos' not 'uds' now
[15:08] <jcastro> mhall119, do we have an announcement email I can copy and paste with all the info?
[15:09] <mhall119> jcastro: only http://www.jonobacon.org/2014/04/03/ubuntu-online-summit-dates/ I still need to update the docs on uds.u.c to point ot the new name and tracks
[15:09] <jcastro> ack
[19:03] <stub> jcastro: Do charms that support both precise and trusty need to be pushed to separate precise and trusty branches, or just one or t'other? Also curious about merge proposals and stopping divergence if multiple branches in LP.
[19:04] <jcastro> stub, it is my understanding that the multiple branches is a workaround until Juju supports series itself
[19:05] <jcastro> but I lost track of the conversation on series and who is winning that argument, heh
[19:05] <jcastro> but if you support both already then I would say don't push it
[19:05] <jcastro> marcoceppi, WDYT? ^^^
[19:05] <stub> I won't do anything  until it is made clear :)
[19:11] <marcoceppi> stub: so, postgresql has been promulgated for both trusty and precise, for example
[19:11] <marcoceppi> because it had tests and they succeeded
[19:12] <marcoceppi> but they're now in two different branches, the trusty and precise versions
[19:12] <marcoceppi> stub: I'm working on a tool that will fix this sync issue, should be ready later this week
[19:12] <marcoceppi> as a stop gap for several things that will hopefully land in core and the store this cycle
[19:14] <stub> I can manually sync in worst case. Did the syslog tests actually pass? I thought it was broken, and I couldn't find any documentation on the syslog interface to know how to fix it and needed to poke people.
[19:15] <marcoceppi> stub: I ran the integration tests that were in the charm, whatever those test worked
[19:15] <stub> Cool. Maybe I did get it right then :)
[19:16] <stub> pasted the right magic incantations from the rsyslog 'docs'
[22:54] <syannalfo> juju --debug -v status
[22:54] <syannalfo> 2014-05-19 22:53:20 INFO juju.cmd supercommand.go:302 running juju-1.18.3-trusty-amd64 [gc]
[22:54] <syannalfo> 2014-05-19 22:53:20 DEBUG juju api.go:179 no cached API connection settings found
[22:54] <syannalfo> 2014-05-19 22:53:20 DEBUG juju.provider.maas environprovider.go:30 opening environment "maas".
[22:54] <syannalfo> 2014-05-19 22:53:20 ERROR juju.cmd supercommand.go:305 Unable to connect to environment "maas".
[22:54] <syannalfo> Please check your credentials or use 'juju bootstrap' to create a new environment.
[22:55] <syannalfo> Attempting to connect to ntexc.maas:22
[22:55] <syannalfo> Attempting to connect to 192.168.0.101:22
[22:55] <syannalfo> 2014-05-19 02:14:52 ERROR juju.provider.common bootstrap.go:123 bootstrap failed: waited for 10m0s without being able to connect: /var/lib/juju/nonce.txt does not exist
[22:55] <syannalfo> Stopping instance...
[22:55] <syannalfo> Bootstrap failed, destroying environment
[22:55] <syannalfo> Please help... :-( I have been at this for days
[22:59] <syannalfo> My nodes are in ready state
[23:00] <davecheney> syannalfo: can you ssh to either of those addresses directly ?
[23:01] <syannalfo> please hold while i try
[23:02] <syannalfo> no - i need my bub keys on the nodes?
[23:02] <syannalfo> err public
[23:02] <syannalfo> I can not ssh into the nodes
[23:05] <syannalfo> my environments.yaml has the maas-oauth though
[23:05] <davecheney> it is because of permissoins
[23:05] <davecheney> or because those names do not resolve or are not routable ?
[23:06] <syannalfo> both names ping ok
[23:06] <syannalfo> hostnames that is
[23:06] <syannalfo> ping edmgh.maas
[23:06] <syannalfo> PING 192-168-0-104.maas (192.168.0.104) 56(84) bytes of data.
[23:06] <syannalfo> 64 bytes from 192-168-0-104.maas (192.168.0.104): icmp_seq=1 ttl=64 time=1.12 ms
[23:06] <syannalfo> etc
[23:06] <davecheney> syannalfo: thta is not the machine juju is trying to contact
[23:07] <syannalfo> juju should be trying to contact MAAS right?
[23:07] <syannalfo> not the nodes
[23:07] <davecheney> syannalfo: no
[23:07] <davecheney> juju configures one of your maas notes as a bootstrap now
[23:07] <davecheney> note
[23:07] <davecheney> node
[23:07] <davecheney> that node runs the database and api server
[23:08] <davecheney> at that point all juju commands talk to that machine
[23:08] <davecheney> which will itself talk to maas if required
[23:09] <syannalfo> ok - so juju gets the dns names of the nodes from maas... then talks to the nodes and procures on of the nodes for itself
[23:09] <syannalfo> one
[23:10] <syannalfo> ok - so why is it not communicating ?
[23:10] <syannalfo> does the user ubuntu have to be able to log into the nodes?
[23:11] <syannalfo> I am using my own name as the administrator on my maas box
[23:12] <syannalfo> so i can not connect to the nodes without setting up a keyboard and monitor on each node and setting up ssh keys
[23:12] <syannalfo> and users
[23:12] <syannalfo> is that right?
[23:15] <syannalfo> Attempting to connect to ntexc.maas:22 (as who?)
[23:15] <syannalfo> juju?
[23:19] <davecheney> always the ubuntu user