[01:23] <b1tbkt> silly question but shouldn't my maas/juju nodes contain a juju executable?
[01:26] <sarnold> b1tbkt: I think the 'juju' executable is just for the human-controlled machine; I think the others are controlled by agents called something more like juju-agent ..
[01:28] <b1tbkt> 'locate juju' with an updatedb db yields nothing
[01:28] <b1tbkt> on naything except machine 0
[01:35] <sarnold> b1tbkt: how about a find /usr -name '*juju*' ? I like locate, but between never being sure what is visible to it, what it indexes, and how often, I tend to like an explicit 'find' when looking for things...
[01:36] <sarnold> well, rather, when _troubleshooting_ I prefer to use 'find'.
[01:37] <b1tbkt> root@10-10-21-23:~# find / -name juju*
[01:37] <b1tbkt> root@10-10-21-23:~#
[01:37] <sarnold> well that is odd :)
[01:38] <sarnold> b1tbkt: does this machine show up in 'juju status'? or is still an unprovisioned node?
[01:38] <b1tbkt> i can ssh into the boxes with native ssh ubuntu@[IP] but juju ssh is always 'waiting for maching to come up'
[01:38] <b1tbkt> yes, it shows up in juju status
[01:39] <b1tbkt> agent-state: not-started
[01:42] <b1tbkt> the agent should natively be a part of the maas isos, no? or does juju deploy the agent itself?
[01:42] <sarnold> b1tbkt: I'm used to juju deploying the agent, but I've not yet tried maas
[01:43] <b1tbkt> if juju normally deploys it then maas shouldn't interfere in any way
[03:16] <freeflying> hi all, where can I find the source of juju's doc https://juju.ubuntu.com/docs/, are they under juju's trunk? or some other place?
[03:19] <sarnold> freeflying: http://askubuntu.com/questions/52063/how-do-i-contribute-documentation-to-juju
[03:19] <mfisch> freeflying: l... nm!
[03:20] <freeflying> sarnold: mfisch awesome, thanks :)
[03:28] <mfisch> marcoceppi: still awake ?
[12:37] <ahasenack> hi guys, I can't seem to juju bootstrap using juju-core and canonistack (openstack), I get "error: no tools available". I was just able to bootstrap on ec2, though
[12:38] <ahasenack> 2013/04/25 09:37:19 INFO environs: reading tools with major version 1
[12:38] <ahasenack> 2013/04/25 09:37:19 INFO environs: falling back to public bucket
[12:38] <ahasenack> 2013/04/25 09:37:19 ERROR command failed: no tools available
[12:41] <mgz> I haven't got creds on whatever the bucket we have on canonistack is, so they've not been updated. you can copy the tools from ec2 to your own container.
[12:44] <ahasenack> I have no idea how to do that, nor what "tools" are. I'm coming from pyjuju
[12:44] <ahasenack> who has those creds?
[12:45] <marcoceppi> mgz: how is this tools thing handled for private clouds that we don't have access to in order to upload the tools?
[12:45]  * marcoceppi thinks of documenting how to upload tools
[12:46] <ahasenack> marcoceppi: good point
[12:46] <ahasenack> marcoceppi: like, someone from Company downloads juju and wants to try it with their own openstack deployment, it won't work out of the box, right?
[12:47] <marcoceppi> ahasenack: I'm not sure, trying to figure that out :) It sounds like there's something you can do based on mgz's response. I'm just not sure what that /thing/ is
[12:47] <ahasenack> sounds like there is a hardcoded path somewhere, path to a bucket
[12:48] <ahasenack> maybe s/hardcoded/control-bucket/
[12:48] <ahasenack> but that's unique for each one of us, right, it's random
[12:53] <marcoceppi> ahasenack: it sounds like each "provider" has a global bucket maintained by the core team. If the tools arent' there it looks in your own bucket specified in the environments.yaml
[12:54] <ahasenack> I tried --upload-tools, but it requires something else
[12:55] <ahasenack> so I checked out "juju-core" from lp:
[12:55] <ahasenack> https://pastebin.canonical.com/89978/
[12:55] <ahasenack> time to read the README ;)
[12:57] <ahasenack> hm, the checkout needs to be in $GOPATH
[12:59] <ahasenack> is the goal to have the tools available as normal ubuntu packages at some point?
[13:02] <ahasenack> hm, make still explodes
[13:30] <ahasenack> hmm, I have a silli question: does the charm directory have to match the charm name in metadata.yaml?
[13:31] <ahasenack> like, I have ~/charms/precise/keystone-ha
[13:31] <ahasenack> but the charm name in keystone-ha/metadata.yaml is just keystone
[13:31] <ahasenack> I can't seem to deploy it, juju complains about not finding the charm
[13:34] <ahasenack> ah, never mind, got it, I was missing the <release> directory
[13:46] <orospakr> hmm, is there an example out there (perhaps in the charm store?) of a charm that uses chef(-solo) for config and provisioning?  it seems like at least a little bit of glue is required, and I wouldn't mind being able to crib off someone! ;)
[14:31] <dpb_> Hi all -- how well does jitsu work with juju-core?
[14:37] <jcastro> marcoceppi: check out the post from bjorn on the mailing list
[14:37] <jcastro> dpb_: it does not, but the core team is real responsive
[14:37] <jcastro> so we plan on rolling in things people want relatively quickly
[14:37] <dpb_> jcastro: should I file a bug report?
[14:38] <jcastro> I think a tracking bug wouldn't hurt
[14:38] <jcastro> mramm: what do you think?
[14:38] <ahasenack> wasn't jitsu always a "temporary tool", with things that would eventually make it into core?
[14:38] <ahasenack> might make more sense to file a specific feature request against core instead of asking to "port" jitsu to juju-core
[14:39] <marcoceppi> jcastro: yeah going to make an au post on it. make sure it find its way in to the docs
[14:39] <jcastro> ack
[14:40]  * marcoceppi needs to test first
[15:05] <AskUbuntu> How can I copy Juju tools for use in my deployment? | http://askubuntu.com/q/285395
[15:06] <mgz> marcoceppi: is that still borked for you?
[15:07] <jcastro> it's still borked for one guy
[15:07] <jcastro> I think he's just writing up a question to FAQ/link
[15:07] <mgz> that was what I suspected,
[15:07] <jcastro> I also only just now noticed that this was mentioned in the release notes and I totally missed that.
[15:07] <marcoceppi> mgz: what castro said
[15:07] <mgz> but didn't want to accuse him of reputation farming :)
[15:08] <jcastro> ok so mgz
[15:08] <jcastro> moving forward
[15:08] <jcastro> people who set up internal clouds
[15:08] <jcastro> will they need to sync as part of the initial set up?
[15:08] <mgz> people are still having issues, but I'm not clear on the contexts of all of them...
[15:08] <jcastro> or will this be automated at some point?
[15:09] <mgz> jcastro: there's logic to copy tools from a public location to your personal container in your tenant
[15:09] <jcastro> ok if this next guy still has a problem, I will ask him to file a bug and we can dig in
[15:09] <mgz> I need to recheck what circumstances everything gets triggered in though
[15:09] <jcastro> yeah
[15:09] <ahasenack> right now ec2 seems to have the tools correctly
[15:09] <jcastro> I am just wondering where in the instructions we add that.
[15:09] <mgz> because there were quite a few changes across development and I'm now really confused about the current state :P
[15:09] <ahasenack> I bootstrapped a couple of hours ago with the latest version from the ppa
[15:10] <ahasenack> sync-tools isn't working for me, though
[15:15] <dpb_> mramm: what should I do for jitsu?  file a bug to have it ported?  File feature requests in juju-core?
[15:17] <jcastro> marcoceppi: are you working on an answer or want me to chip in for that tools question?
[15:17] <marcoceppi> jcastro: if you have an answer, go for it. I've been playing around trying to replicate the error so I can post the solution
[15:18] <jcastro> hmm
[15:18] <jcastro> so is it supposed to be just "juju sync" or what?
[15:18] <robbiew> jcastro: is it a known bug that "juju status <servicename>" doesn't work? e.g. juju status wordpress, should show me the status of all units in the wordpress ser
[15:18] <robbiew> only asking to know if I should file a bug or not
[15:19]  * robbiew using juju-core in 13.04....\o/
[15:19] <ahasenack> jcastro: see juju@, I posted a similar question there
[15:19] <jcastro> I think that's a known bug
[15:19] <ahasenack> jcastro: sync-tools, but it didn't work for me just now
[15:19] <jcastro> right
[15:20] <jcastro> and would a random person's openstack have access to that url?
[15:20] <ahasenack> in s3 it's public afaik
[15:20] <ahasenack> so the idea is to copy it from the aws bucket into your private cloud's bucket
[15:20] <ahasenack> that's what I understood sync-tools does
[15:20] <jcastro> nod
[15:22] <robbiew> jcastro: ack..good ;)
[15:22] <ahasenack> with the caveat "Due to some internal limitations, you have to have Ec2 credentials to do
[15:22] <ahasenack> this (our ec2 code requires creds even though the bucket is public)."
[15:35] <wkharold> just installed 13.04, doing the Juju Getting Started, want to use LXC, setup an environments.yaml stanza that uses 'type: local', juju bootstrap sez 'unknown provider type "local"'
[15:35] <wkharold> pls tell me LXC will be supported ...
[15:37] <mgz> wkharold: `apt-get install juju`, juju-core will support local lxc deployments, but not in this release
[15:38] <mgz> the good news is you can continue using juju for local charm testing, and deploy those charms with juju-core if you wish
[16:01] <wkharold> mgz: tnx
[16:02] <jcastro> Daviey: hey, I'd like to update all the websites/AU questions/docs about how to install Juju from backports
[16:03] <jcastro> right now it's all pointing to the PPA.
[16:03] <jcastro> But I've not done backports before, what are the steps?
[16:03] <Daviey> jcastro: Desktop, it should be enabled by default.
[16:03] <Daviey> Server, i believe it is aswell.
[16:04] <Daviey> However, it's possible people might have disabled it.
[16:04] <jcastro> ok so on a clean install
[16:04] <jcastro> and I apt-get install juju-core
[16:04] <Daviey> For most people, it's just a simple case of sudo apt-get install juju-core
[16:04] <jcastro> over time I'll get backports
[16:04] <jcastro> ok so other than that, it's just the same as distro
[16:04] <jcastro> other than a link to how to reenable backports on a server if they explicitly turned it off
[16:04] <jcastro> anything else?
[16:05] <Daviey> jcastro: Usually, you have to specific juju-core/raring-backports .. his ISN'T required because it's not in a primary pocket aswell
[16:05] <jcastro> ok so as far as the instructions are concerned, same commands as distro
[16:06] <Daviey> jcastro: https://help.ubuntu.com/community/UbuntuBackports#Enabling_Backports
[16:06]  * jcastro nods
[16:06] <jcastro> ok I'll update everything now then, thanks
[16:07] <Daviey> jcastro: "If you previously disabled Backports, or the apt-get command doesn't find juju-core - it is most likely you need to enable it by.."
[16:07] <jcastro> right
[16:09] <jcastro> Daviey: when do you anticipate the backport landing in 12.04?
[16:12] <Daviey> jcastro: I wouldn't like to comment.
[16:12] <jcastro> days, weeks, or months would be good enough?
[16:12] <Daviey> hopefully soon
[16:12] <jcastro> because otherwise I need to write version specific instructions
[16:13] <Daviey> I'd suggest ~3 weeks, which should leave some bounce room.
[16:13] <Daviey> I am not in the Ubuntu backports team, so i can't be more firm.
[16:13] <jcastro> close enough, thanks.
[16:17] <jcastro> Daviey: is pyju in backports as well?
[16:19] <Daviey> no
[16:20] <Daviey> jcastro: https://wiki.ubuntu.com/RaringRingtail/ReleaseNotes#Juju useful?
[16:21] <jcastro> hah, yeah
[16:21] <jcastro> thanks
[16:23] <mgz> release notes there are pretty neat
[17:24] <mramm> dpb_: file feature requests for juju-core
[17:25] <mramm> or for tools to go alongside juju-core that do what jitsu did
[17:29] <dpb_> ok
[17:29] <dpb_> mramm: thx
[17:29] <jcastro> marcoceppi: check out manage.jujucharms.com and see if that works for you
[17:29] <jcastro> might need to wait for DNS
[17:30] <marcoceppi> jcastro: it loads for me. What should I expect?
[17:30] <mramm> we are also experamenting with a python API to talk directly to the juju state server over a websocket, so that some jitsu-ike commands can still be written in python
[17:31] <jcastro> marcoceppi: a UI to be able to score charms, etc.
[17:31] <mramm> hazmat has a very experimental branch up on launchpad already
[17:31] <mramm> https://pypi.python.org/pypi/jujuclient/0.0.1
[17:32] <marcoceppi> jcastro: I just see the charmworld
[17:33] <jcastro> do you see a login button on the right?
[17:33] <hazmat> mramm, its not that experimental..
[17:33] <hazmat> mramm, i mean the gui and landscape have been using it for months..
[17:34] <hazmat> oh. that one
[17:34] <hazmat> python websocket confusion
[17:34] <mramm> right
[17:34] <mramm> it is like 2 days old ;)
[17:34] <hazmat> mramm, i want agents in python too
[17:35] <mramm> hazmat: interesting
[17:35] <marcoceppi> jcastro: yeah, and I logged in, but no idea what/where to go from there
[17:36] <jcastro> I was just making sure it resolved for you
[17:39] <marcoceppi> jcastro: ah, cool
[17:39] <mramm> hazmat: new kinds of agents, or replacing machine and unit agents with python?
[17:40] <mramm> I think there are quite a few advantages to the core agents being a self contained binary
[17:43] <jcastro> marcoceppi: we should have the new UI for managing ratings, etc tomorrow
[17:43] <marcoceppi> jcastro: awesome
[17:47] <jcastro> mramm: arosales: ok instructions all updated everywhere and pushed, just waiting for the RT response, last bit will be to announce to the mailing list.
[17:47] <arosales> jcastro, thanks :-)
[17:52] <mramm> jcastro: rock and roll!
[17:52] <dpb_> mramm: https://bugs.launchpad.net/juju-core/+bug/1172814, https://bugs.launchpad.net/juju-core/+bug/1172811
[17:52] <_mup_> Bug #1172814: Need a way to run an end-to-end test on a juju environment. <juju-core:New> <https://launchpad.net/bugs/1172814>
[17:52] <_mup_> Bug #1172811: Need a way to watch juju-core environements <juju-core:New> <https://launchpad.net/bugs/1172811>
[17:55] <arosales> jcastro, m_3: other charmers. Your guys' thoughts on adding lp:charms & lp:charm-tools to to lp:juju-project?
[17:55] <jcastro> didn't know we had -project
[17:55] <arosales> re the juju-dev list thread subj="juju-project
[17:56] <arosales> jcastro, I think Danilo _just_ added it
[17:57] <jcastro> I haven't gotten the mail yet
[17:58] <arosales> jcastro, https://lists.ubuntu.com/archives/juju-dev/2013-April/000943.html
[17:59] <jcastro> that seems pretty straightforward and beneficial
[18:11] <jcastro> arosales: mramm: forgot to eat lunch, bbi ~30. The RT for the website is #61095 if you want to follow along
[18:11] <_mup_> Bug #61095: Crash trying to open tomboy preferences <tomboy (Ubuntu):Invalid> <https://launchpad.net/bugs/61095>
[18:13] <marcoceppi> arosales: I'm not sure if charms would work as it's already it's own distro, but charm-tools would be a good idea
[18:17] <arosales> marcoceppi, ya may not want to mess with lp:charms since it it is tied to the charm store.
[18:21] <marcoceppi> We don't have a rabbitmq charm?
[18:21] <hazmat> mramm, new kind
[18:21] <hazmat> marcoceppi, we do
[18:22] <marcoceppi> hazmat: "rabbit" in charmworld returns nothing
[18:22] <ahasenack> rabbitmq-server probably
[18:22] <hazmat> http://jujucharms.com/charms/precise/rabbitmq-server
[18:22] <marcoceppi> odd
[18:22] <hazmat> marcoceppi, substring searching needs ie. rabbit*
[18:22] <hazmat> needs star
[18:22] <marcoceppi> hazmat: Ah, didn't realize it needed wildcard for searches
[18:22] <marcoceppi> thanks
[18:24] <hazmat> marcoceppi, rabbitmq would work as well.. its tokenizing.
[18:32] <ahasenack> hi, what's the right update-alternatives command to switch back to juju-core? The command from the release notes isn't working
[18:32] <ahasenack> https://wiki.ubuntu.com/RaringRingtail/ReleaseNotes#Juju
[18:32] <ahasenack> $ sudo update-alternatives --set juju /usr/lib/juju-1.10.0/bin/juju
[18:32] <ahasenack> update-alternatives: error: alternative /usr/lib/juju-1.10.0/bin/juju for juju not registered; not setting
[18:36] <mgz> ahasenack: just run `update-alternatives --config juju` and pick from the list
[18:36] <mgz> I'm guessing the version number change has messed with it... really it should be 1.10 only or something
[18:36] <ahasenack> mgz: doesn't work
[18:37] <ahasenack> $ sudo update-alternatives --config juju
[18:37] <ahasenack> There is only one alternative in link group juju (providing /usr/bin/juju): /usr/lib/juju-0.7/bin/juju
[18:37] <ahasenack> Nothing to configure.
[18:37] <ahasenack> mgz: I'm using juju-core from the ppa, is the distro one different?
[18:39] <mgz> it is.
[18:39] <mgz> (for now)
[18:39] <ahasenack> ok, that explains it
[18:39] <ahasenack> so the ppa one for now can't coexist with the py one
[18:44] <mramm> we will update the PPA package recipe to match the release soon
[18:46] <ahasenack> ok
[18:53] <jcastro> marcoceppi: nice work on those icons!
[18:53] <marcoceppi> cant' wait to see them in the UI
[18:58] <arosales> marcoceppi, +1, thanks for knocking those out
[19:01] <jcastro> marcoceppi: ~20 minutes is what rick tells me for the site to update
[19:32] <jcastro> mramm: arosales: RT pushed through, we're now all up to date doc wise.
[19:32] <jcastro> at least until like tomorrow or whenever you guys decide to switch over to PPA builds. :p
[19:58] <arosales> jcastro, thanks I see that @ https://juju.ubuntu.com/get-started/
[20:03] <mramm> jcastro: I think we will just push "supported" updates into the backports repository
[20:03] <mramm> and use the PPA for development releases
[20:03] <jcastro> I like that
[20:03] <mramm> so we should not have to change the docs
[20:04] <jcastro> indeed
[20:04] <jcastro> in hindsight
[20:04] <jcastro> we should have done this for the previous releases too
[20:04] <mramm> agreed
[20:04] <jcastro> but whatever
[20:04] <mramm> it is what it is
[20:04] <jcastro> the ships are ablaze as you have ordered my conquistador.
[20:04] <mramm> haha
[20:04] <mramm> was watching the game of thrones last night -- you win or you die
[20:05] <mramm> ;)
[20:05] <jcastro> I just posted to the list to see if there's any other major transition issues people would like to see handled
[20:05] <jcastro> heya marcoceppi
[20:05] <marcoceppi> heya jcastro
[20:05] <jcastro> a follow up mail to mine wrt. the status of charm-tools with 1.10.x would probably help
[20:05] <jcastro> let people know that those tools are all set to go
[20:06] <jcastro> mramm: we've had some issues with juju sync not working for some people wrt. getting the tools in their buckets
[20:06] <jcastro> ahasenack: is yours still broken?
[20:06] <marcoceppi> jcastro: Well, they only really live in PPA, the distro version won't have the pretty new charm create in it
[20:07] <mramm> well, we should just mention that, and how to enable them.
[20:07] <ahasenack> jcastro: I can deploy on aws without any hack, and on canonistack after I set that public tools url in the environments file
[20:07] <ahasenack> jcastro: I haven't tried sync-tools anymore since this morning, when it didn't work
[20:07] <mramm> as for sync-tools -- any bugs on that will get very high priority
[20:08] <ahasenack> I get this: http://pastebin.ubuntu.com/5602223/
[20:08] <jcastro> mramm: ok so in the case of this guy: http://askubuntu.com/questions/284846/juju-doesnt-bootstrap-due-to-error-command-failed-no-tools-available-error
[20:08] <mramm> is there a bug filed for that?
[20:08] <jcastro> how do people get the tools on their own internal openstack?
[20:08] <ahasenack> mramm: sync? no, I emailed the list about it because I wasn't sure I was using it correctly
[20:09] <mramm> ok
[20:09] <jcastro> or do they put our canonistack url in their environments.yaml? (that can't be right)
[20:09] <mramm> they should be able to sync them into local buckets
[20:09] <mramm> until the tools were in the right place in amazon that would not work
[20:09] <ahasenack> that was my understanding. That the source is always aws, and the target is what you say with -e
[20:10] <mramm> but it should work now
[20:10] <mramm> if not, that's a critical bug which should be addressed ASAP
[20:10] <ahasenack> can someone else try?
[20:10] <mramm> even if the solution is just to provide a workaround script that does the copy
[20:11] <mramm> and a real fix pushed in an update release
[20:11] <jcastro> does anyone have the URL to the s3 bucket?
[20:11] <jcastro> the release notes only mention canonistack and hp cloud
[20:12] <ahasenack> it's hardcoded in juju, you shouldn't need it
[20:12] <ahasenack> it's in the code, I mean
[20:12] <ahasenack> (or so I think)
[20:13] <ahasenack> oh, for a workaround script
[20:14] <ahasenack> jcastro: https://s3.amazonaws.com/juju-dist/tools/juju-1.10.0-precise-amd64.tgz?Expires=1682453601&Signature=zak2C4ARkuqMDG24lxQwVPNhpQc%3D&AWSAccessKeyId=AKIAIE2BLLQVB4JVA6RQ
[20:14] <ahasenack> but that was locally generated, probably with my credentials
[20:14] <jcastro> nod
[20:14] <ahasenack> meaning, not good for a blog post
[20:14] <ahasenack> I got it with juju sync-tools -e canonistack -v
[20:14] <ahasenack> the -v showed it
[20:15] <ahasenack> but I can actually download it, it works (wget, web browser)
[20:16] <sidnei> removing all the query params works too
[20:16] <ahasenack> ah, good
[20:16] <ahasenack> ok, I remember now
[20:16] <ahasenack> they said that juju requires creds, even though it's a public bucket
[20:18] <jcastro> ok so for a normal openstack user
[20:18] <jcastro> just "juju sync-tools" is the answer?
[20:19] <ahasenack> hm, here is another command line incompatibility
[20:19] <ahasenack> 2013/04/25 20:17:51 INFO worker/uniter: HOOK error: flag provided but not defined: -r
[20:19] <ahasenack> 2013/04/25 20:17:51 INFO worker/uniter: HOOK subprocess.CalledProcessError: Command '['relation-list', '-r', 'swift-storage:2']' returned non-zero exit status 2
[20:19] <sidnei> jcastro: it should be, but it requires you to have valid aws credentials
[20:19] <ahasenack> jcastro: I think so, bar that "use of closed network connection" bug
[20:19] <ahasenack> and what sidnei said
[20:20] <mwhudson> juju bootstrap (pointed at a maas install) fails with "error: no tools available"
[20:20] <mwhudson> any ideas?
[20:21] <ahasenack> mwhudson: raring? which version of the package?
[20:21] <mwhudson> ahasenack: no, precise
[20:21] <mwhudson> from https://launchpad.net/~juju/+archive/devel/+packages
[20:21] <ahasenack> mwhudson: 1.10.0 something?
[20:21] <mwhudson> yeah, i think so
[20:22] <ahasenack> 1.10.0-1~1189~raring1 is what I have (raring)
[20:22] <mwhudson> 1.10.0-1~1189~precise1
[20:22] <ahasenack> I was having that tools error earlier today and some days ago
[20:22] <ahasenack> mwhudson: and the default-series you are targeting? precise too?
[20:22] <mwhudson> um
[20:23] <mwhudson> yes
[20:25] <ahasenack> mwhudson: I don't know then, should be the same I have deployed right now in aws. precise, 64 bits, 1.10.0
[20:25] <ahasenack> maybe with maas it behaves differently, was it working "before", for some definition of before?
[20:25] <mwhudson> no, this is a new install
[20:25] <mwhudson> i sort of had it working with juju-py
[20:25] <ahasenack> ah, ok, so many variables
[20:25] <ahasenack> mramm: https://bugs.launchpad.net/juju-core/+bug/1172895, fyi
[20:25] <_mup_> Bug #1172895: relation-list incompatibility with pyjuju: -r <juju-core:New> <https://launchpad.net/bugs/1172895>
[20:26] <mramm> ahasenack: for the command line tool incompatibility type things, or anything else you find -- feel free to file bugs.   Even if they are just temporary issues or you don't know if they are reproducable -- we should be able to handle that with our bug triage process.
[20:26] <mramm> ahasenack: perfect!
[20:26] <ahasenack> thanks
[20:28] <mramm> ahasenack: I added the relation list issue to the immediate dev queue
[20:28] <ahasenack> mramm: nice
[20:28] <ahasenack> someone fixed a similar issue earlier today with --log-level vs -l
[20:29] <mramm> Frank was just working on that stuff, so I think it should be fresh in his mind
[20:29] <ahasenack> mramm: https://bugs.launchpad.net/juju-core/+bug/1172717 it says "merged", but the bug is open and the review request still pending
[20:29] <mramm> ok, I'll look into it
[20:30] <ahasenack> probably something to do with the rietveld integration (if I spelled that correctly)
[20:31] <mramm> yea, we don't have it all wired up to automatically close things in LP
[20:32] <mwhudson> ahasenack: you said you had the same problem, and now you don't?
[20:32] <mwhudson> did you do anything to fix it, or did it just go away?
[20:33] <ahasenack> mwhudson: it just disappeared, they uploaded the right set of tools to that public amazon bucket
[20:33] <mwhudson> ah
[20:34] <ahasenack> mwhudson: try sourcing aws creds, I think juju requires those even though the s3 bucket is public
[20:34] <mwhudson> where do i put s3 creds in the set up for a maas environment?
[20:34] <ahasenack> mwhudson: I'm just guessing now, but try sourcing them in your shell for starters
[20:34] <mwhudson> oh right
[20:35] <ahasenack> mwhudson: and re-run the command with -v, might have more useful output
[20:35] <mwhudson> tried that:)
[20:35] <mwhudson> mwhudson@lava-leg01:~$ juju -v bootstrap
[20:35] <mwhudson> 2013/04/25 21:32:12 INFO environs: reading tools with major version 1
[20:35] <mwhudson> 2013/04/25 21:32:12 INFO environs: falling back to public bucket
[20:35] <mwhudson> 2013/04/25 21:32:12 ERROR command failed: no tools available
[20:35] <mwhudson> error: no tools available
[20:35] <mwhudson> mwhudson@lava-leg01:~$
[20:35] <ahasenack> ok :(
[20:35] <ahasenack> did you source the aws creds in that run?
[20:35] <mwhudson> no
[20:36] <mwhudson> trying to find some, haven't used aws in a while ...
[20:36] <ahasenack> that's the "public bucket" bit I believe
[20:36] <jcastro> imbrandon: ping
[20:36] <mwhudson> ahasenack: i forget, how do you even set AWS creds?
[20:37] <ahasenack> mwhudson: EC2_SECRET_KEY, EC2_ACCESS_KEY,
[20:37] <ahasenack> I think that's it
[20:37] <mwhudson> oh right
[20:38] <ahasenack> you grab them from the aws console somewhere
[20:38] <ahasenack> EC2_URL too, but probably not needed in this case
[20:38] <ahasenack> https://ec2.us-east-1.amazonaws.com is mine
[20:38]  * mwhudson finds the right bit of his .bashrc
[20:42] <mwhudson> no difference
[20:47] <mwhudson> mwhudson@lava-leg01:~$ juju -v sync-tools
[20:47] <mwhudson> 2013/04/25 21:46:20 INFO environs/ec2: opening environment "juju-public"
[20:47] <mwhudson> 2013/04/25 21:46:20 ERROR failed to initialize the official bucket environment
[20:47] <mwhudson> 2013/04/25 21:46:20 ERROR command failed: environment has no access-key or secret-key
[20:47] <mwhudson> error: environment has no access-key or secret-key
[20:48] <mwhudson> ^ this looks like the sort of thing you were saying?
[20:50] <ahasenack> hm, yeah
[20:50] <ahasenack> but you got it when you *used* the aws creds? :)
[20:51] <mwhudson> no
[20:51] <mwhudson> but!
[20:51] <mwhudson> i have now fond
[20:51] <mwhudson> *found
[20:51] <mwhudson> http://bazaar.launchpad.net/~goamz/goamz/trunk/view/head:/aws/aws.go
[20:51] <ahasenack> you didn't specify an env above
[20:51] <ahasenack> -e
[20:51] <mwhudson> which tells me which env vars to set :/
[20:51] <ahasenack> AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY
[20:52] <ahasenack> to tell you the truth, I have both sets :)
[20:52] <ahasenack> EC2_* and AWS_*
[20:52] <mwhudson> yeah, different tools look at different vars i think :(
[20:53] <mwhudson> ok, that's doing something
[20:53] <mwhudson> however
[20:53] <mwhudson> it only seemed to copy i386 and amd64 tools and i'm going to be deploying armhf...
[20:53] <mwhudson> so i guess that's going to be another problem
[20:54] <ahasenack> it is :)
[20:54] <ahasenack> ok, but this is important
[20:54] <ahasenack> you had to set the aws creds
[20:54] <mwhudson> yes
[20:54] <ahasenack> even when not using aws
[20:54] <mwhudson> and then run sync-tools
[20:54] <ahasenack> what did it output this time?
[20:54] <mwhudson> (i don't know if bootstrap would have worked, to be fair)
[20:55] <mwhudson> ahasenack: http://paste.ubuntu.com/5602338/
[20:55] <ahasenack> cool!
[20:55] <ahasenack> I haven't gotten that far yet with canonistack
[20:55] <ahasenack> mwhudson: so you were using juju before with armhf, right?
[20:56] <ahasenack> pyjuju I mean
[20:56] <mwhudson> yeah
[20:56] <ahasenack> jcastro: ^^^ pastebin, a sample of sync-tools working after exporting aws creds
[20:56] <mwhudson> but i didn't get it quite working either
[20:56] <ahasenack> mwhudson: ok, I don't know if this will work with arm, I'm thinking "mongodb on arm...?"
[20:56] <mwhudson> i got it bootstrapped
[20:57] <mwhudson> this time
[20:57] <mwhudson> bootstrap completed quickly
[20:57] <mwhudson> and status is now just hanging
[20:58] <ahasenack> bootstrap is more like a request
[20:58] <ahasenack> when it comes back, it doesn't mean it's done, just that the request was made
[20:58] <ahasenack> juju status hangs because the bootstrap isn't actually done yet
[20:58] <ahasenack> it could return saying that, I think, but it doesn't and there was an almost-flame-war on the mailing list about this once ;)
[20:59] <mwhudson> heh
[21:00] <jcastro> marcoceppi: ^^ see the pastebin for a possible answer for that question
[21:00] <mwhudson> i would be very surprised if this bootstrap ever succeeds
[21:00] <ahasenack> mwhudson: this is bootstrapping via maas, right?
[21:00] <mwhudson> yeah
[21:00] <marcoceppi> jcastro: excellent thanks
[21:00] <ahasenack> without having tools built for armhf :)
[21:00] <mwhudson> yes
[21:01] <ahasenack> yeah, you might need to ssh into that node to see what is going on, /var/log/juju
[21:01] <ahasenack> if it's up already
[21:01] <marcoceppi> jcastro: btw, merge request for icon.svg that I've sat on for a while is up: https://code.launchpad.net/~marcoceppi/charm-tools/icon-template/+merge/161020
[21:01] <mwhudson> and if my juju-py experience is anything to go by, it will be asking maas for a amd64 node
[21:01] <mwhudson> which it doesn't have
[21:01] <jcastro> marcoceppi: ooh nice
[21:01] <mwhudson> ah well
[21:01] <mwhudson> a node is allocated
[21:02] <jcastro> m_3: or negronjl, got time to check out marco's mp?
[21:02] <negronjl> jcastro: give me a link and I'll check it out ...
[21:02] <mwhudson> so maybe juju-core doesn't have *that* problem
[21:02] <marcoceppi> negronjl: https://code.launchpad.net/~marcoceppi/charm-tools/icon-template/+merge/161020
[21:02] <negronjl> marcoceppi, I'm on it
[21:02] <marcoceppi> negronjl: thanks!
[21:03] <negronjl> marcoceppi, 1313 lines!!!
[21:03] <marcoceppi> negronjl: Most of it is just template stuff!!
[21:03] <negronjl> marcoceppi, sigh ... I'll review it :/ ... j/k
[21:03] <marcoceppi> There's like 5 copies of the same SVG in it
[21:04] <mwhudson> ahasenack: part of the fun is that maas allocating a node is a netinstall
[21:04] <mwhudson> so it takes a while
[21:04] <ahasenack> :)
[21:04] <ahasenack> mwhudson: I'm eod, will peek back in in about 3h
[21:05] <mwhudson> ahasenack: thanks for the hints so far
[21:05] <ahasenack> good luck
[21:05] <mwhudson> ahasenack: is there a bug for this 'requires creds' thing?
[21:05] <marcoceppi> negronjl: if it makes it easier, the only thing that I added is in scripts/lib/proof.py
[21:06] <ahasenack> mwhudson: no, we were just talking about it here during the day
[21:06] <mwhudson> ok
[21:06] <negronjl> marcoceppi, I was j/k .. reiewing it now
[21:06] <marcoceppi> negronjl: Ah, thanks
[21:06] <ahasenack> mwhudson: it seems to be known by the developers, as it was in the release notes, but maybe the implication for sync-tools isn't
[21:10] <negronjl> marcoceppi, Approved and Merged.
[21:10] <jcastro> \o/
[21:10] <marcoceppi> negronjl: \o/ thanks!
[21:10] <negronjl> marcoceppi, np
[22:51] <dpb_`> Hi all -- someone have a clue what's going wrong with this lxc ubuntu deploy on top of raring? http://paste.ubuntu.com/5602655/  looks like somehow python3 is being used?  But I don't see how, /usr/bin/python is showing 2.7, etc.
[22:52] <sarnold> dpb_`: hrm, I thought that had been fixed
[22:52] <sarnold> dpb_`: https://bugs.launchpad.net/ubuntu/+source/juju/+bug/1130809
[22:52] <_mup_> Bug #1130809: lxc scripts break when user has PYTHONPATH set <apparmor> <apport-crash> <i386> <raring> <juju:Incomplete> <juju (Ubuntu):Fix Released by gz> <lxc (Ubuntu):Invalid> <https://launchpad.net/bugs/1130809>