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