=== CyberJacob is now known as CyberJacob|Away [04:17] Why does charm get ceph not work? === julianwa is now known as julian_lunch === defunctzombie is now known as defunctzombie_zz === julian_lunch is now known as julianwa === CyberJacob|Away is now known as CyberJacob === defunctzombie_zz is now known as defunctzombie === CyberJacob is now known as CyberJacob|Away [07:23] hello [07:23] can anybody help me to understand why on this http://manage.jujucharms.com/~pavel-pachkovskij/precise/rack doesn't update readme, metadata and config? === defunctzombie is now known as defunctzombie_zz === gnuyoga_ is now known as gnuyoga === CyberJacob|Away is now known as CyberJacob === axw is now known as axw_ [10:13] hello, anyone knows how to upgrade the juju-core agent version from a deployed node? [10:15] raywang, from a deployed node? [10:15] raywang, you just do it from the client - 'juju upgrade-juju' [10:15] jamespage, hi, yes, like bootstrapped node [10:16] jamespage, i use juju-core 1.11.4 while I bootstrapped, but i just recently upgrade the client to 1.13. and can't not deploy any service node, so I'm expecting to upgrade the juju-core's agent from bootstrapped server [10:17] raywang, ah - OK - you have to jump through 1.12 first [10:17] juju upgrade-juju --version 1.12 I think [10:18] raywang, rogpeppe sent an email to the juju-dev ML about this [10:18] jamespage, error: invalid version "1.12" [10:19] raywang, what cloud are you using? [10:19] jamespage, maas [10:19] raywang, actually try '1.12.0' [10:19] 1.12 does not exist - that was my bad sorry [10:20] jamespage, does it mean i have to upgrade to 1.12.0, and then 1.13.0? [10:20] raywang, https://lists.ubuntu.com/archives/juju-dev/2013-August/001333.html [10:20] jamespage, try 1.12.0 also not working error: no matching tools available [10:21] raywang, how did you get your tools into the MAAS environment in the first place? I've not tried that yet [10:27] jamespage, sorry, what do you mean by "get the tools into the maas environment?" :) [10:28] raywang, so when you bootstrapped your environment did you use --upload-tools or did you use juju sync-tools [10:28] jamespage, ah, i see, i used --upload-tools option [10:29] raywang, OK - so see the mailing list post - you can use the same with the upgrade-juju command [10:29] jamespage, ok, I will check it now, thanks for helping :) [10:29] raywang, hey - no problem [10:30] fwiw there is work going on in the tool distribution area this cycle to make stuff like this a bit easier! === marcoceppi_ is now known as marcoceppi [11:13] jamespage: we've been discussin it, but haven't decided on anything concrete yet. one possibility that's been mooted is to allow upgrades only between adjacent even-numbered minor releases [11:14] jamespage: another possibility is to encode upgrade paths into the simplestreams data (or somewhere else external to the juju binary) [11:15] raywang: if you've upgraded to juju-core tip, i suspect your installation might be broken now :-\ [11:17] jamespage: i'd also like to make the upgrade process a little more reliable by having the client switch versions only when it's sure that the new version can connect to the state ok [11:17] jamespage: i wrote some code ages ago to do that, but it was deemed premature === melmoth__ is now known as melmoth [12:42] hi [12:43] hi [12:43] hi [12:43] hi [12:45] I'm attempting to use juju-core 1.13.0 on a private openstack instance and I'm trying to generate the image metadata using juju image-metadada BUT the command doesn't exist [12:46] http://askubuntu.com/questions/327177/cannot-bootstrap-due-to-precise-images-in-regionone-with-arches-amd64-i386 [12:46] geme, ^^^^^ [12:50] thanks jcastro but juju image-metadata gives command not found [12:51] juju-metadata generate-image [12:51] try that [12:52] command not found agian [12:52] juju version 1.13.0 [12:54] Should I install a different version ? [12:55] hmmmm [12:55] let me ask somebody here [12:55] thanks [13:03] hey mgz, any idea on this? ^^^ [13:05] marcoceppi, ping [13:05] jcastro_: pong [13:06] hey pavel has some questions about the charm testing framework [13:06] aka, can he use it yet [13:06] it's not in a ppa anywhere atm, it's probably best to wait for release which is soon [13:07] marcoceppi, and does it make sense to write integration tests with old documentation? [13:07] marcoceppi, or it would be just waste of time? [13:08] pavel: those tests _will_ always work in our testing environments. However, it's tedious to write good tests using the old documentation [13:08] marcoceppi, I have only three features undone with rack charm: backups, testing and apparmor profile and all of them are totally unclear for me [13:08] and the old methods/original methods of testing, which is what this framework I'm writing aims to fix [13:09] marcoceppi, then I think it would be better to wait for your framework, to provide relevant tests [13:09] pavel: the apparmor profiles are pretty straight forward to write as I understand it, while I finish writing this testing framework that might be a good place to focus next [13:09] marcoceppi, btw, I've deployed discourse with Rack charm and wrote an article, I will publish it after release of charm [13:10] pavel: awesome! [13:10] marcoceppi, problem is ... that we have foreman there and I can't know what should be restricted in the profile [13:11] pavel: doesn't most everything run as the user under the rvm directories? (with the exception of a few extra things globally installed as a gme)? [13:11] gem* [13:11] marcoceppi, as I understand apparmor is something like permissions based on process, but when we talk about rack charm user may want to do all kind of stuff with server [13:11] with foreman you can run any process which may access different directories [13:14] jcastro_, any news re: juju image-metadata ? [13:14] https://lists.ubuntu.com/archives/juju/2013-August/002814.html [13:14] ^^^ [13:14] I posted to the list because I don't seem to have it either and I'm on 1.13 [13:15] when does Mark Mims come back? [13:16] jcastro, thanks I'll keep an eye on the list [13:16] pavel, like 2 more days [13:16] jcastro_, so he'll be available from monday? [13:16] yeah [13:17] geme, did you have the problem prior to 1.13? [13:17] I am going to guess "no" [13:20] jcastro, this is the 1st time that I've tried the juju-core version. Used python juju before [13:21] jcastro, the default-image-id was a lot easier [13:23] jcastro_: it's in 1.11.4 and by proxy in 1.12.0 - geme maybe try 1.12 (ppa:juju/stable) until this is resolved? [13:24] wait [13:24] there's a ppa:juju/stable? [13:24] why do the docs say /devel? [13:25] ok, I'll give it a try [13:25] jcastro_: because up until a week ago stable was 1.10 and 1.10 was not nearly as awesome compared to 1.11 [13:25] marcoceppi, I don't see packages there [13:25] https://launchpad.net/~juju/+archive/stable [13:29] jcastro_: yeah, nevermind. I have no idea where 1.12 was uploaded to. [13:31] me either [13:31] wtf [13:31] * jcastro_ fires off another email to the list. [13:34] pew pew! [13:39] jcastro, juju-gui questions handled here or another topic ? [13:40] geme, here too! [13:41] jcastro, that's handy. Are there plans for juju-gui to handle local repository charms ? [13:43] pavel, your README.md has a unicode quote on line 116 "app’s" [13:43] pavel, The immediate fix is to use an ascii quote [13:44] I am reporting a bug that README.* can be utf-8 encoded. [13:44] geme, ok so the image generating thing appears to be a packaging bug [13:45] but hopefully something we can fix tomorrowish when the right people wake up [13:47] jcastro, great - I'll reinstall in a couple of days [13:54] geme, I've got guys working on it as we speak [13:54] so it might be sooner [13:54] sorry for the problem! we messed that up. :-/ [13:59] jcastro, Are there plans for juju-gui to handle local repository charms ? [14:00] sinzui, thanks you so much, I would never figure this out on my own [14:01] np, thank you for finding a bug. [14:11] gary_poster, Are there plans for juju-gui to handle local repository charms ? [14:11] geme: define 'handle'? [14:14] rick_h, will juju-gui be able to list charms in a local repository and then deploy ? [14:14] geme, agree with rick_h's question :-) we can show the ones that you deploy from the command line. You want to deploy local from GUI? If so, is this in a developer use case or a deloyer/user case? [14:14] ah [14:14] geme, we have talked about it. We have two stories. [14:15] We can see how to do this one cleanly: [14:15] 1) You zip the charm [14:15] 2) You upload it [14:15] 3) You can now deploy it [14:16] We are less sure about this one: [14:16] 1) You run something locally (some program we provide) and configure it to find your local repo and to talk to the GUI [14:17] 2) You can now deploy arbitrary charms from repo [14:17] That one has some issues that I forget at the moment [14:17] the first one is good for people simply deploying local charms [14:18] the second is good for people developing and deploying local charms [14:18] So, the 1st is to upload a local charm into the public charm store ? [14:18] geme, no into local juju env [14:18] have to step away, back soon [14:22] geme does story one work for you? [14:23] so local charms can be uploaded into the juju-gui ? [14:23] geme that would be the plan, yes. (to be clear, you can't do it now) [14:27] The use case I'm interested in is the ability to connect to any project charm store / repository - so that a project can view all available services that can be deployed [14:35] geme, ah, yes. we're interested in that too, for a bit later. The upload story would be a sooner thing. [14:40] gary_poster, that sounds good. We see that projects may need to use a composite service catalog comprising of generic and project specific charms [14:42] being able to point the gui at multiple local charm stores would be very useful [14:47] geme, cool. I will prioritize the charm upload story for a bit sooner if I can, and communicate the multiple-charm-store interest as well. thanks for feedback. [14:50] Great - I see the multi-charm-store case as giving the developer control of deployment instead of maybe devops. === natefinch is now known as natefinch-afk === CyberJacob is now known as CyberJacob|Away [15:13] hi [15:17] gsdsdhxz [15:17] hi kita === kita is now known as juju [15:17] hi [15:17] jh [15:18] hi === CyberJacob|Away is now known as CyberJacob [15:26] noodles775: https://code.launchpad.net/~sidnei/charms/precise/avahi/trunk want to give it a try? === CyberJacob is now known as CyberJacob|Away [15:32] pavel, I see you pushed a fix for the README.md, but you did not increment the revision file. That might be a problem. The juju store only sees the 4th revision so far. So while http://manage.jujucharms.com/~pavel-pachkovskij/precise/rack shows it found your branch with new data, the store doesn't see juju revision 5 yet http://manage.jujucharms.com/search?search_text=rack [15:45] sinzui, but in revision there is '5' [15:45] sinzui, not 4 [15:45] ah [15:45] sinzui, and charm store doesn't see 5 revision either [15:45] pavel, thank you. I will update the bug report [15:45] right, the store only knows about 4 so manage.jujucharms only retrieved 4 [15:47] sinzui, marcoceppi told that revision file is no more required [15:47] sinzui, so I've added it only on five number because of error message [15:47] sinzui, I thought that this was the issue [15:47] sinzui, maybe I have to remove it? [15:48] pavel, I don't think it is either. Maybe the store is ingesting charms slower than manage.jujucharms.com [15:48] I think I pushed fifth revision yesterday [15:49] or even on monday [15:49] sinzui, nope, yesterday and it didn't update yet === CyberJacob|Away is now known as CyberJacob === CyberJacob is now known as CyberJacob|Away [15:55] sinzui, pavel: are you expecting changes in lp:charms/rack or lp:~pavel-pachkovskij/charms/precise/rack/trunk ? [15:55] sinzui, second [15:55] http://manage.jujucharms.com/~pavel-pachkovskij/precise/rack [15:55] ah, ok [15:55] separate issue then :) [15:58] m_3, my issue is that I can't deploy with cs:~pavel-pachkovskij/rack/trunk because it doesn't update, though if I pull it locally it works. My guess is that issue is with readme file [15:58] pavel, the store doesn't know about your recent work: http://pastebin.ubuntu.com/5959371/ [15:58] sinzui, how could I fix this? [15:59] very strange [15:59] I'm not sure yet. Maybe the store is ingesting slower that m.jc.com [15:59] I'm afraid it would be something very simple [15:59] sinzui: I notice a stacking problem with the official branch... not sure if that's a red herring or not... `bzr info lp:charms/rack` [16:00] bzr: ERROR: Parent not accessible given base "bzr+ssh://bazaar.launchpad.net/+branch/charms/rack/" and relative path "../../../../../~pavel-pachkovskij/charms/precise/rack/trunk/" [16:00] There is a report of a missing revision in logs. It does mention your id, but it is not clear which charm branch is the issue [16:00] look like I broke something :D [16:01] pavel: no, that was probably broken during "promulgation"... so it wouldn't've been you [16:01] m_3, what if I remove branch and push again? [16:01] it's most likely not causing this problem [16:02] sinzui would know _lots_ more about it [16:02] sinzui, so what if I? [16:02] sinzui: nice.. yeah, that could be any number of things === CyberJacob|Away is now known as CyberJacob [16:03] m_3, I will try, it won't be worst [16:04] pavel: sure... with maybe a trivial new commit to make sure the store gets kicked [16:05] sinzui: any way to infer the problem branch you mention based on it's position in the log? I'm happy to dig if you send me a pointer or snippet of the log [16:06] s/it's/its/ /me needs coffee [16:07] ok, now I have brand new branch [16:10] will charmers meeting be held today? [16:12] pavel: nope... people are out afaik [16:12] postponed to next week [16:12] m_3, ah... ok [16:12] m_3, do you have few minutes to chat about backups? [16:13] pavel: sure... I see an email about it in my inbox, but haven't caught up yet... first day back from vacation [16:13] * m_3 reading now [16:13] oh, it's short [16:58] hi [16:58] where can I find documentation on the upgrade-charm hook? [17:02] tasdomas: we don't have an explicit docs about that hook yet, what questions do you have? [17:03] marcoceppi, just wanted to add it to a charm and wasn't sure, what context the hook is run under === CyberJacob is now known as CyberJacob|Away [17:04] if functions like any other hook, it's just triggered via `juju upgrade-charm` command [17:08] tasdomas: most people simply symlink to the install hook as hooks are designed to be idempotent [17:10] but it depends on what the process is for upgrading the charm/service === natefinch-afk is now known as natefinch [17:18] marcoceppi, thanks [17:18] marcoceppi, what happens to relations when a charm is upgraded? They remain intact, right? === CyberJacob|Away is now known as CyberJacob === defunctzombie_zz is now known as defunctzombie [17:48] tasdomas: therelations remain, and the relation data does too, but just becareful you don't overwrite config files that have values derived from relations [17:48] marcoceppi, thanks [17:54] m_3: have you ever used `relation-set --format=json` > [17:54] ?* [18:27] marcoceppi: nope === tasdomas is now known as tasdomas_afk [19:40] jcastro: I just tried destroy-unit, and the underlying machine (openstack instance) is still alive [19:40] same for destroy-service [19:40] it's even still listed in juju-status [19:42] ahasenack: is the unit in an error state? [19:42] marcoceppi: no, it was a plain ubuntu charm [19:42] what version ubuntu? [19:43] s/ubuntu/juju-core/ [19:43] trunk, 1.13.1.1 currently [19:43] tbh, I never saw juju destroy-unit or destroy-service actually taking down machines, I was surprised when jcastro said it would nowadays [19:47] ahasenack: it's worked for me in 1.11.4 [19:48] marcoceppi: just destroy-unit and the instance would die soon? [19:48] destroy-unit would remove the unit, then destroy-machine would remove the machine [19:48] well [19:48] destroy-machine or terminate-machine works [19:48] I was talking about destroy-unit only [19:48] they're synonyms, *-machine [19:48] jcastro said it would terminate the machine, unless I misunderstood [19:49] what is your expected outcome of destroy-unit? [19:49] remove the unit from the machine, leave the machine up [19:49] I filed a bug to add a --terminate flag to destroy-unit to optionally terminate the machine too [19:49] ahasenack: yeah, from my understanding that works. Unless I'm confusing it with destroy-service [19:50] with co-location it's a bit trickier, it would have to know that no other units are there [19:50] * marcoceppi pokes local deployment [19:50] marcoceppi: I know it works. I was speaking to jcastro the other day about his blog post where he was talking about colocation and expanding and shrinking the cloud, and his example had only destroy-unit, no terminate-machine [19:51] and I raised the point that the instance would still be up burning money [19:51] ah [20:49] can someone help me out... after juju install and using a maas env i keep getting the following error on bootstrap [20:49] error: cannot create initial state file: gomaasapi: got error back from server: 400 BAD REQUEST [21:02] jreingol: what does your environments.yaml file look like? Can you also run `juju bootstrap -v` and put the output in paste.ubuntu.com? [21:18] marcoceppi: found a few errors in the docs i was using to set it up [21:19] the maas url was wrong.. .its now http://localhost:5242 [21:20] seems to be connecting now but gives error: Requested array, got . [21:22] http://paste.ubuntu.com/5960394/ [21:28] jreingol: I've not seen that error before. [21:32] hahaha.... y do i always find the new ones [21:33] thanks for the look though [21:35] jreingol: what version of juju are you using (juju version) === CyberJacob is now known as CyberJacob|Away [21:43] 1.13.0-quantal-amd64 [21:43] jreingol: Okay this might be related to a few missing commands in 1.13 [21:43] erg [21:43] what version would you recommend? [21:45] jreingol: I'd recommend 1.12 but there currently isn't a ppa for it. It should be sorted soon [21:45] * marcoceppi checks [21:46] i used the devel ppa [21:46] jreingol: actually, it's been uploaded to ppa:juju/stable already, if you remove the /devel ppa and add that one you should be able to get juju-core 1.12 [21:46] should i remove all of it and go with the stable branch [21:46] perfect [21:47] jreingol: at least until the next devel release, which should sort out the missing commands issue if this is indeed affected by that [21:47] if you get the same error in stable you'll want to open a bug for sure, if not, i'd still recommend opening a bug with the output you pasted and letting them know it works in 1.12 [21:48] k... well thanks for the help [21:50] yep... still happening [21:50] * jreingol wonders if provider-state is a maas problem [21:51] jreingol: thanks, there's definitely something else going on. A bug would be the next best step. The core devs would be able to point you in the right direction === CyberJacob|Away is now known as CyberJacob === tasdomas_afk is now known as tasdomas === CyberJacob is now known as CyberJacob|Away === tasdomas is now known as tasdomas_afk