[04:57] <ianous> Hello. Anyone here?
[05:00] <thumper> ianous: kinda
[05:00] <thumper> but just EODing
[05:01] <thumper> there are others who are around though
[05:01] <thumper> just ask your questions :)
[05:01] <thumper> or say hi
[05:01] <ianous> At this hour...I'm suprised someone's actually here.
[05:02] <lifeless> ianous: 6pm ?
[05:03] <ianous> It's 7 am here...
[05:03] <lifeless> ianous: welcome to the globe
[05:03] <ianous> *gasps*
[05:03] <lifeless> I know, right!
[05:03] <ianous> it's actually nice but I have no idea what timetables people are usually around here.
[05:04] <ianous> You know..peak hours and sorts
[05:05] <ianous> Anyone knows btw about using private openstacks with juju? I"m trying to get behind the logic with generate-image and public puckets and all.
[05:05] <ianous> And I feel kinda lost
[11:04] <noodles775> marcoceppi: Have you seen this error in amulet before? As if it's got the 2.x urllib module loaded... http://paste.ubuntu.com/6837138/
[11:08] <marcoceppi> noodles775: yes, this was an issue I think I patched in trunk
[11:09] <noodles775> marcoceppi: cool, I'll run with trunk again. Thanks.
[11:10] <marcoceppi> noodles775: yeah, sorry about that it'll be released with that patch this week
[11:34] <mramm> frankban: you around?
[11:35] <hazmat> jamespage, i heard you mentioned that deployer is incompatible with 1.17 which isn't true afaics, what's that about?
[11:35] <jamespage> hazmat, "state watcher was stopped" ?
[11:36] <jamespage> hazmat, sometime during a deployment, the deployer exits
[11:36] <hazmat> jamespage, that's fixed in juju-core trunk
[11:36] <jamespage> with that error message
[11:36] <jamespage> hazmat, ok - so is juju-deployer compatible with any released version of juju?
[11:36] <Beret> hazmat, http://pastebin.ubuntu.com/6837352/
[11:36] <Beret> ok
[11:36] <frankban> mramm: yes I am
[11:37] <hazmat> jamespage, well that issue can appear with 1.17 .. 1.17.1 has the fix though.
[11:37] <jamespage> hazmat, ah - ok - nuding that through now
[11:37] <mramm> hazmat: ok
[11:37] <hazmat> and that issue can appear with 1.16.5.. i can try for a work-around.
[11:37] <mramm> hazmat: I that's the thing that was causing the relations not to be added on some of our demos
[11:38] <mramm> and why we have been pushing forward to 1.17.1 this morning
[14:17] <ev> marcoceppi: is amulet breaking with include-base64 a problem you're aware of? We ran into this: https://code.launchpad.net/~doanac/ubuntu-ci-services-itself/amulet-unit-config-fix/+merge/203729
[14:18] <marcoceppi> ev: I didn't know there was a base64 include option in deployer
[14:19] <marcoceppi> amulet has no idea about this feature, could you file a bug? I can probably get a fix out this week
[14:31] <noodles775> marcoceppi: Having trunk amulet on the pythonpath is enough for running tests manually, but not for running via juju test? Do you know what I need there? http://paste.ubuntu.com/6838092/
[14:31] <marcoceppi> noodles775: yeah, PYTHONPATH isn't pushed in to the testing environment. I'll add that to the whitelist good catch
[14:32] <ev> marcoceppi: Chris Johnston is on it now
[14:35] <marcoceppi> noodles775: I've got a patch for that landing in charm-tools now, but I'll have to roll a release of charm-tools for the new test
[14:35] <marcoceppi> proably won't land until later tonight
[14:35] <noodles775> marcoceppi: Great - thanks. No rush here, I can keep running tests manually :)
[15:02] <cjohnston> marcoceppi: bug #1274142
[15:05] <marcoceppi> cjohnston: ta!
[15:11] <tomixxx> hi is juju fully installed an a node if i can read : "cloud-init boot finished at Wed,...... +0000. Up 136.3 seconds" ?
[15:19] <tomixxx> plz help, i have now isntalled juju, do i have to deploy services on my maas-server or on the juju-node?
[15:20] <tomixxx> if i hit "juju deploy mysql" on the maas-server no answer is prompted from the terminal
[15:20] <tomixxx> on my node, i can see "cloud1 login:"
[15:28] <tomixxx> if i enter juju status it prints me nothing.... i get simply no terminal output...
[15:28] <tomixxx> does someone know what the problem is ? :(
[15:37] <marcoceppi> tomixxx: what does the output of juju status look like, please put it in paste.ubuntu.com
[15:38] <tomixxx> there is nothing, only the black background after hitting "enter"
[15:38] <tomixxx> one of my nodes show me "cloud1 login:" but i dont know what username and passwort is need here...
[15:39] <tomixxx> do i have to enter "juju status" on the maas-server-terminal or on the node?
[15:40] <marcoceppi> tomixxx: you enter juju status from where you ran juju bootstrap
[15:40] <tomixxx> marcoeppi: ok, that is the maas-server then
[15:40] <marcoceppi> tomixxx: can you please run `juju version` then `juju status --debug` and add the outputs to paste.ubuntu.com?
[15:41] <tomixxx> marcoceppi: ok
[15:43] <tomixxx> http://pastebin.ubuntu.com/6838480
[15:48] <marcoceppi> tomixxx: did you run sudo bootstrap or just bootstrap?
[15:48] <marcoceppi> sudo juju bootstrap* or just juju bootstrap*
[15:48] <tomixxx> only "juju  bootstrap"
[15:48] <marcoceppi> tomixxx: okay, good
[15:49] <marcoceppi> tomixxx: can you `ssh cloud1.master`
[15:49] <marcoceppi> err
[15:50] <marcoceppi> tomixxx: can you `ssh ubuntu@cloud1.master`
[15:50] <tomixxx> it says "could not resolve hostname cloud.master: name or service not known"
[15:57] <marcoceppi> tomixxx: do you have dns running on your maas node?
[15:57] <marcoceppi> tomixxx: paste initctl list | grep maas
[15:58] <tomixxx> marcoceppi: pastebin.ubuntu.com/6838547
[15:59] <tomixxx> marcoeppi: i have set the interface of the cluster-controller to be managed "dhcp and dns"
[16:00] <tomixxx> btw, i have replaced the host name of the nodes from the suggested one (i guess it was 10.0.0.100-00 or sth like that) to "cloud1", "cloud2" and so one
[16:01] <tomixxx> but this should not be a problem, i guess
[16:01] <marcoceppi> tomixxx: this sounds like a networking/dns issue with maas. Can you ssh direclty in to the ip address?
[16:02] <tomixxx> you mean i should try "ssh ubuntu@10.0.0.100.master"?
[16:02] <marcoceppi> no, 10.0.0.100, if that's the IP address it's allocated
[16:02] <tomixxx> kk
[16:02] <tomixxx> seems to work, it asks me "Are you sure you want to continue connecting (yes/no)?"
[16:03] <tomixxx> and in front it says "The authenticity of host '10.0.0.100' cant be established. ECDSA key fingerprint is xx:xx:..
[16:05] <tomixxx> should i say "yes" ?
[16:10] <jcastro> hey the queue doesn't look so bad today
[16:12] <tomixxx> hmm
[16:12] <tomixxx> when i open head in "resolv.conf.d" there is nothing in the file
[16:13] <tomixxx> then i have a file called "original" with search ... and nameserver ... entries
[16:13] <tomixxx> maybe, sometime in past, i have modified head for some reason?
[16:13] <tomixxx> could this cause the problem?
[16:35] <tomixxx> marcoceppi: are u still here?
[16:36] <marcoceppi> tomixxx: yes, one second
[16:36] <tomixxx> k
[16:50] <tomixxx> marcoceppi: i have to go now. But i will be here tomorrow again. if u have some hint for me, you can send me a private message. would appreciate it!
[18:27] <roaksoax> hi all
[18:27] <roaksoax> so I deployed a charm from the charm store
[18:28] <roaksoax> and now I need to upgrade the charm from a local repository
[18:28] <roaksoax> how can I do that?
[18:30] <roaksoax> marcoceppi: thoughts?
[18:31] <roaksoax> roaksoax@pursue:~/test$ juju upgrade-charm --repository . local:hacluster
[18:31] <roaksoax> error: invalid service name "local:hacluster"
[18:31] <marcoceppi> roaksoax: you can run --switch
[18:32] <marcoceppi> juju upgrade-charm --switch --repository . local:hacluster
[18:32] <marcoceppi> roaksoax: it's very hulk smashish in that it ignores revisions all together
[18:36] <roaksoax> marcoceppi: ok cool, thanks!
[18:36] <roaksoax> marcoceppi: roaksoax@pursue:~/test$ juju upgrade-charm --switch --repository . local:haclsuter
[18:36] <roaksoax> error: unrecognized args: ["local:haclsuter"]
[18:37] <roaksoax> marcoceppi: got it
[18:38] <roaksoax> roaksoax@pursue:~/test$ juju upgrade-charm --switch local:hacluster hacluster
[18:50] <jcastro> hey lazyPower
[18:50] <jcastro> I saw you touching owncloud
[18:50] <jcastro> I think the install hook needs an update btw
[18:50] <jcastro> last I checked the version was woefully out of date
[18:50] <lazyPower> yeah
[18:51] <lazyPower> its not providing a version identifier
[18:51] <lazyPower> Already in my notes, currently on hold while i review OpenMRS
[18:51] <jcastro> ack
[18:52] <lazyPower> i may tag it, and after the audit branch it and give it some upgrade lovin
[19:05] <jcastro> lazyPower, I have this thing where I wish all charms had version options in config
[19:07] <lazyPower> The picky part of that is if the charm installs from upstream, how do you validate the hash when someone chooses a newer version?
[19:07] <jcastro> yeah
[19:07] <lazyPower> mbruzek and I are actually in a conversation about this as we speak
[19:08] <jcastro> http://download.owncloud.com/download/repositories/xUbuntu_12.04/all/
[19:08] <jcastro> in this case you could config the enterprise version
[19:09] <jcastro> the .org stuff has an opensuse build system repo, so there's kind of like 3 options
[19:11] <mbruzek> Hi jcastro I want more details on how you would implement a version option.
[19:12] <mbruzek> So the 1.9.7 version of OpenMRS is current, I got a review comment that I need to cryptographically verify the file I download
[19:12] <mbruzek> Any newer version we would not be able to verify.  Is that OK?
[19:13] <jcastro> yeah that's a good question
[19:13] <sarnold> why not?
[19:13]  * jcastro sees what marco did in phpmyadmin
[19:14] <jcastro> https://github.com/charms/phpmyadmin/blob/master/bin/parse_upstream
[19:14] <jcastro> heh
[19:14] <lazyPower> his comment at the top of the file is priceless
[19:15] <lazyPower> marco++
[19:16]  * mbruzek is checking if there is a hash to verify against
[19:16] <sarnold> oh jeeze; preg_replace(.../e)
[19:17] <mbruzek> sarnold, was that to me?
[19:17] <lazyPower> nope, for marco's parser
[19:17] <lazyPower> line 10
[19:17] <jcastro> sarnold, the entire thing is glorious
[19:17] <sarnold> mbruzek: it is my wailing, gnashing of teeth, and rending asunder my clothing
[19:18] <sarnold> please tell me we don't ship that
[19:18] <jcastro> lazyPower, wait until you start to find that there are plenty of upstreams that don't sign their releases at all, depressing.
[19:18] <lazyPower> sarnold, http://sideshowsito.com/hulk_smash_loki.gif
[19:18] <sarnold> lazyPower: yes please :)
[19:19] <lazyPower> i feel like that line is about as useful as goto, in specific contexts, very acceptable, but comes with such a stigma that most developers choose to stray away from it.
[19:19] <lazyPower> and as much as it may be hated, its useful in this context
[19:20] <jcastro> https://bugs.launchpad.net/charm-tools/+bug/1274255
[19:20] <sarnold> lazyPower: when the context appears to be "load random content from the internet and then proceed to execute it", it's hard for me to be too sympathetic
[19:20] <jcastro> anyone have issues with this?
[19:21] <rick_h_> jcastro: doing that will block ingestion
[19:21] <jcastro> so I was thinking maybe a good idea would be for config to pass along a URL to an upstream source?
[19:21] <rick_h_> jcastro: so any charm without a cateogry will not get updated until touched
[19:21] <jcastro> rick_h_, what do you mean?
[19:21] <jcastro> oh, as in, you use charm-tools as part of the ingestion process and that would break stuff
[19:21] <rick_h_> jcastro: if charm proof makes that an error, no charm without a category can get updated in the store. They'll go into an error state
[19:22] <jcastro> rick_h_, would doing this post-audit make more sense then?
[19:22] <rick_h_> jcastro: yes, in order for a charm to get past ingestion it needs to pass proof without errors
[19:22] <rick_h_> jcastro: +1
[19:22] <rick_h_> jcastro: it's a warning and should be part of getting 'recommended' but not required as an error imo
[19:22] <rick_h_> policy vs proof basically
[19:23] <jcastro> rick_h_, I've updated the bug, feel free to add on
[19:23] <rick_h_> jcastro: cool
[19:25] <lazyPower> sarnold, ah, i was looking into attack vectors utilizing preg_replace, i see where you're coming from now
[19:41] <ev> hazmat: does juju-deployer not support ;revno= in bzr branches? Doesn't seem to work
[20:18] <jcastro> hey sinzui
[20:18] <jcastro> are there backport-for-12.04 plans for the 1.18.x series?
[20:20] <sinzui> jcastro, We make backports, but I don't know what the SRU policy will be.
[20:21] <sinzui> jcastro, there might be blockers such as switching juju to juju-monogo and gccgo
[20:21] <jcastro> ok I will ask around
[20:23] <hazmat> ev re deployer revision support.. syntax is   lp:bzr@revno
[20:23] <hazmat> ev, also works for git repos
[21:44] <modelife> hi
[21:52] <ev> hazmat: star! Thanks!
[21:56] <perrito666> fwereade: hi
[21:56] <fwereade> perrito666, heyhey
[21:56] <perrito666> you caught me online :p