[04:17] <jpds> Why does charm get ceph not work?
[07:23] <pavel> hello
[07:23] <pavel> can anybody help me to understand why on this http://manage.jujucharms.com/~pavel-pachkovskij/precise/rack doesn't update readme, metadata and config?
[10:13] <raywang> hello, anyone knows how to upgrade the juju-core agent version from a deployed node?
[10:15] <jamespage> raywang, from a deployed node?
[10:15] <jamespage> raywang, you just do it from the client - 'juju upgrade-juju'
[10:15] <raywang> jamespage, hi, yes, like bootstrapped node
[10:16] <raywang> 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] <jamespage> raywang, ah - OK - you have to jump through 1.12 first
[10:17] <jamespage> juju upgrade-juju --version 1.12  I think
[10:18] <jamespage> raywang, rogpeppe sent an email to the juju-dev ML about this
[10:18] <raywang> jamespage, error: invalid version "1.12"
[10:19] <jamespage> raywang, what cloud are you using?
[10:19] <raywang> jamespage, maas
[10:19] <jamespage> raywang, actually try '1.12.0'
[10:19] <jamespage> 1.12 does not exist - that was my bad sorry
[10:20] <raywang> jamespage, does it mean i have to upgrade to 1.12.0, and then 1.13.0?
[10:20] <jamespage> raywang, https://lists.ubuntu.com/archives/juju-dev/2013-August/001333.html
[10:20] <raywang> jamespage,    try 1.12.0 also not working     error: no matching tools available
[10:21] <jamespage> raywang, how did you get your tools into the MAAS environment in the first place? I've not tried that yet
[10:27] <raywang> jamespage, sorry, what do you mean by "get the tools into the maas environment?" :)
[10:28] <jamespage> raywang, so when you bootstrapped your environment did you use --upload-tools or did you use juju sync-tools
[10:28] <raywang> jamespage, ah, i see, i used --upload-tools option
[10:29] <jamespage> raywang, OK - so see the mailing list post - you can use the same with the upgrade-juju command
[10:29] <raywang> jamespage, ok, I will check it now, thanks for helping :)
[10:29] <jamespage> raywang, hey - no problem
[10:30] <jamespage> fwiw there is work going on in the tool distribution area this cycle to make stuff like this a bit easier!
[11:13] <rogpeppe> 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] <rogpeppe> jamespage: another possibility is to encode upgrade paths into the simplestreams data (or somewhere else external to the juju binary)
[11:15] <rogpeppe> raywang: if you've upgraded to juju-core tip, i suspect your installation might be broken now :-\
[11:17] <rogpeppe> 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] <rogpeppe> jamespage: i wrote some code ages ago to do that, but it was deemed premature
[12:42] <kita> hi
[12:43] <kita> hi
[12:43] <geme> hi
[12:43] <kita> hi
[12:45] <geme> 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] <jcastro_> http://askubuntu.com/questions/327177/cannot-bootstrap-due-to-precise-images-in-regionone-with-arches-amd64-i386
[12:46] <jcastro_> geme, ^^^^^
[12:50] <geme> thanks jcastro but juju image-metadata gives command not found
[12:51] <jcastro_> juju-metadata generate-image
[12:51] <jcastro_> try that
[12:52] <geme> command not found agian
[12:52] <geme> juju version 1.13.0
[12:54] <geme> Should I install a different version ?
[12:55] <jcastro_> hmmmm
[12:55] <jcastro_> let me ask somebody here
[12:55] <geme> thanks
[13:03] <jcastro_> hey mgz, any idea on this? ^^^
[13:05] <jcastro_> marcoceppi, ping
[13:05] <marcoceppi> jcastro_: pong
[13:06] <jcastro_> hey pavel has some questions about the charm testing framework
[13:06] <jcastro_> aka, can he use it yet
[13:06] <marcoceppi> it's not in a ppa anywhere atm, it's probably best to wait for release which is soon
[13:07] <pavel> marcoceppi, and does it make sense to write integration tests with old documentation?
[13:07] <pavel> marcoceppi, or it would be just waste of time?
[13:08] <marcoceppi> pavel: those tests _will_ always work in our testing environments. However, it's tedious to write good tests using the old documentation
[13:08] <pavel> 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] <marcoceppi> and the old methods/original methods of testing, which is what this framework I'm writing aims to fix
[13:09] <pavel> marcoceppi, then I think it would be better to wait for your framework, to provide relevant tests
[13:09] <marcoceppi> 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] <pavel> marcoceppi, btw, I've deployed discourse with Rack charm and wrote an article, I will publish it after release of charm
[13:10] <marcoceppi> pavel: awesome!
[13:10] <pavel> marcoceppi, problem is ... that we have foreman there and I can't know what should be restricted in the profile
[13:11] <marcoceppi> 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] <marcoceppi> gem*
[13:11] <pavel> 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] <pavel> with foreman you can run any process which may access different directories
[13:14] <geme>  jcastro_, any news re: juju image-metadata ?
[13:14] <jcastro_> https://lists.ubuntu.com/archives/juju/2013-August/002814.html
[13:14] <jcastro_> ^^^
[13:14] <jcastro_> I posted to the list because I don't seem to have it either and I'm on 1.13
[13:15] <pavel> when does Mark Mims come back?
[13:16] <geme> jcastro, thanks I'll keep an eye on the list
[13:16] <jcastro_> pavel, like 2 more days
[13:16] <pavel> jcastro_, so he'll be available from monday?
[13:16] <jcastro_> yeah
[13:17] <jcastro_> geme, did you have the problem prior to 1.13?
[13:17] <jcastro_> I am going to guess "no"
[13:20] <geme> jcastro, this is the 1st time that I've tried the juju-core version. Used python juju before
[13:21] <geme> jcastro, the default-image-id was a lot easier
[13:23] <marcoceppi> 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] <jcastro_> wait
[13:24] <jcastro_> there's a ppa:juju/stable?
[13:24] <jcastro_> why do the docs say /devel?
[13:25] <geme> ok, I'll give it a try
[13:25] <marcoceppi> 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] <jcastro_> marcoceppi, I don't see packages there
[13:25] <jcastro_> https://launchpad.net/~juju/+archive/stable
[13:29] <marcoceppi> jcastro_: yeah, nevermind. I have no idea where 1.12 was uploaded to.
[13:31] <jcastro_> me either
[13:31] <jcastro_> wtf
[13:31]  * jcastro_ fires off another email to the list.
[13:34] <marcoceppi> pew pew!
[13:39] <geme> jcastro, juju-gui questions handled here or another topic ?
[13:40] <jcastro_> geme, here too!
[13:41] <geme> jcastro, that's handy. Are there plans for juju-gui to handle local repository charms ?
[13:43] <sinzui> pavel,  your README.md has a unicode quote on line  116 "app’s"
[13:43] <sinzui> pavel, The immediate fix is to use an ascii quote
[13:44] <sinzui> I am reporting a bug that README.* can be utf-8 encoded.
[13:44] <jcastro_> geme, ok so the image generating thing appears to be a packaging bug
[13:45] <jcastro_> but hopefully something we can fix tomorrowish when the right people wake up
[13:47] <geme> jcastro, great - I'll reinstall in a couple of days
[13:54] <jcastro_> geme, I've got guys working on it as we speak
[13:54] <jcastro_> so it might be sooner
[13:54] <jcastro_> sorry for the problem! we messed that up. :-/
[13:59] <geme> jcastro, Are there plans for juju-gui to handle local repository charms ?
[14:00] <pavel> sinzui, thanks you so much, I would never figure this out on my own
[14:01] <sinzui> np, thank you for finding a bug.
[14:11] <geme> gary_poster, Are there plans for juju-gui to handle local repository charms ?
[14:11] <rick_h> geme: define 'handle'?
[14:14] <geme> rick_h, will juju-gui be able to list charms in a local repository and then deploy ?
[14:14] <gary_poster> 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] <gary_poster> ah
[14:14] <gary_poster> geme, we have talked about it.  We have two stories.
[14:15] <gary_poster> We can see how to do this one cleanly:
[14:15] <gary_poster> 1) You zip the charm
[14:15] <gary_poster> 2) You upload it
[14:15] <gary_poster> 3) You can now deploy it
[14:16] <gary_poster> We are less sure about this one:
[14:16] <gary_poster> 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] <gary_poster> 2) You can now deploy arbitrary charms from repo
[14:17] <gary_poster> That one has some issues that I forget at the moment
[14:17] <gary_poster> the first one is good for people simply deploying local charms
[14:18] <gary_poster> the second is good for people developing and deploying local charms
[14:18] <geme> So, the 1st is to upload a local charm into the public charm store ?
[14:18] <gary_poster> geme, no into local juju env
[14:18] <gary_poster> have to step away, back soon
[14:22] <gary_poster> geme does story one work for you?
[14:23] <geme> so local charms can be uploaded into the juju-gui ?
[14:23] <gary_poster> geme that would be the plan, yes.  (to be clear, you can't do it now)
[14:27] <geme> 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] <gary_poster> geme, ah, yes.  we're interested in that too, for a bit later.  The upload story would be a sooner thing.
[14:40] <geme> 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] <geme> being able to point the gui at multiple local charm stores would be very useful
[14:47] <gary_poster> 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] <geme> Great - I see the multi-charm-store case as giving the developer control of deployment instead of maybe devops.
[15:13] <kita> hi
[15:17] <kita> gsdsdhxz
[15:17] <marcoceppi> hi kita
[15:17] <juju> hi
[15:17] <juju> jh
[15:18] <juju> hi
[15:26] <sidnei> noodles775: https://code.launchpad.net/~sidnei/charms/precise/avahi/trunk want to give it a try?
[15:32] <sinzui> 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] <pavel> sinzui, but in revision there is '5'
[15:45] <pavel> sinzui, not 4
[15:45] <sinzui> ah
[15:45] <pavel> sinzui, and charm store doesn't see 5 revision either
[15:45] <sinzui> pavel, thank you. I will update the bug report
[15:45] <sinzui> right, the store only knows about 4 so manage.jujucharms only retrieved 4
[15:47] <pavel> sinzui, marcoceppi told that revision file is no more required
[15:47] <pavel> sinzui, so I've added it only on five number because of error message
[15:47] <pavel> sinzui, I thought that this was the issue
[15:47] <pavel> sinzui, maybe I have to remove it?
[15:48] <sinzui> pavel, I don't think it is either. Maybe the store is ingesting charms slower than manage.jujucharms.com
[15:48] <pavel> I think I pushed fifth revision yesterday
[15:49] <pavel> or even on monday
[15:49] <pavel> sinzui, nope, yesterday and it didn't update yet
[15:55] <m_3> sinzui, pavel: are you expecting changes in lp:charms/rack or lp:~pavel-pachkovskij/charms/precise/rack/trunk ?
[15:55] <pavel> sinzui, second
[15:55] <pavel> http://manage.jujucharms.com/~pavel-pachkovskij/precise/rack
[15:55] <m_3> ah, ok
[15:55] <m_3> separate issue then :)
[15:58] <pavel> 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] <sinzui> pavel, the store doesn't know about your recent work: http://pastebin.ubuntu.com/5959371/
[15:58] <pavel> sinzui, how could I fix this?
[15:59] <m_3> very strange
[15:59] <sinzui> I'm not sure yet. Maybe the store is ingesting slower that m.jc.com
[15:59] <pavel> I'm afraid it would be something very simple
[15:59] <m_3> 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] <pavel> 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] <sinzui> 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] <pavel> look like I broke something :D
[16:01] <m_3> pavel: no, that was probably broken during "promulgation"... so it wouldn't've been you
[16:01] <pavel> m_3, what if I remove branch and push again?
[16:01] <m_3> it's most likely not causing this problem
[16:02] <m_3> sinzui would know _lots_ more about it
[16:02] <pavel> sinzui, so what if I?
[16:02] <m_3> sinzui: nice.. yeah, that could be any number of things
[16:03] <pavel> m_3, I will try, it won't be worst
[16:04] <m_3> pavel: sure... with maybe a trivial new commit to make sure the store gets kicked
[16:05] <m_3> 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] <m_3> s/it's/its/   /me needs coffee
[16:07] <pavel> ok, now I have brand new branch
[16:10] <pavel> will charmers meeting be held today?
[16:12] <m_3> pavel: nope... people are out afaik
[16:12] <m_3> postponed to next week
[16:12] <pavel> m_3, ah... ok
[16:12] <pavel> m_3, do you have few minutes to chat about backups?
[16:13] <m_3> 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] <m_3> oh, it's short
[16:58] <tasdomas> hi
[16:58] <tasdomas> where can I find documentation on the upgrade-charm hook?
[17:02] <marcoceppi> tasdomas: we don't have an explicit docs about that hook yet, what questions do you have?
[17:03] <tasdomas> marcoceppi, just wanted to add it to a charm and wasn't sure, what context the hook is run under
[17:04] <marcoceppi> if functions like any other hook, it's just triggered via `juju upgrade-charm` command
[17:08] <marcoceppi> tasdomas: most people simply symlink to the install hook as hooks are designed to be idempotent
[17:10] <marcoceppi> but it depends on what the process is for upgrading the charm/service
[17:18] <tasdomas> marcoceppi, thanks
[17:18] <tasdomas> marcoceppi, what happens to relations when a charm is upgraded? They remain intact, right?
[17:48] <marcoceppi> 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] <tasdomas> marcoceppi, thanks
[17:54] <marcoceppi> m_3: have you ever used `relation-set --format=json` >
[17:54] <marcoceppi> ?*
[18:27] <m_3> marcoceppi: nope
[19:40] <ahasenack> jcastro: I just tried destroy-unit, and the underlying machine (openstack instance) is still alive
[19:40] <ahasenack> same for destroy-service
[19:40] <ahasenack> it's even still listed in juju-status
[19:42] <marcoceppi> ahasenack: is the unit in an error state?
[19:42] <ahasenack> marcoceppi: no, it was a plain ubuntu charm
[19:42] <marcoceppi> what version ubuntu?
[19:43] <marcoceppi> s/ubuntu/juju-core/
[19:43] <ahasenack> trunk, 1.13.1.1 currently
[19:43] <ahasenack> 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] <marcoceppi> ahasenack: it's worked for me in 1.11.4
[19:48] <ahasenack> marcoceppi: just destroy-unit and the instance would die soon?
[19:48] <marcoceppi> destroy-unit would remove the unit, then destroy-machine would remove the machine
[19:48] <ahasenack> well
[19:48] <ahasenack> destroy-machine or terminate-machine works
[19:48] <ahasenack> I was talking about destroy-unit only
[19:48] <marcoceppi> they're synonyms, *-machine
[19:48] <ahasenack> jcastro said it would terminate the machine, unless I misunderstood
[19:49] <marcoceppi> what is your expected outcome of destroy-unit?
[19:49] <ahasenack> remove the unit from the machine, leave the machine up
[19:49] <ahasenack> I filed a bug to add a --terminate flag to destroy-unit to optionally terminate the machine too
[19:49] <marcoceppi> ahasenack: yeah, from my understanding that works. Unless I'm confusing it with destroy-service
[19:50] <ahasenack> 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] <ahasenack> 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] <ahasenack> and I raised the point that the instance would still be up burning money
[19:51] <marcoceppi> ah
[20:49] <jreingol> can someone help me out... after juju install and using a maas env i keep getting the following error on bootstrap
[20:49] <jreingol> error: cannot create initial state file: gomaasapi: got error back from server: 400 BAD REQUEST
[21:02] <marcoceppi> 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] <jreingol> marcoceppi: found a few errors in the docs i was using to set it up
[21:19] <jreingol> the maas url was wrong.. .its now http://localhost:5242
[21:20] <jreingol> seems to be connecting now but gives error: Requested array, got <nil>.
[21:22] <jreingol> http://paste.ubuntu.com/5960394/
[21:28] <marcoceppi> jreingol: I've not seen that error before.
[21:32] <jreingol> hahaha.... y do i always find the new ones
[21:33] <jreingol> thanks for the look though
[21:35] <marcoceppi> jreingol: what version of juju are you using (juju version)
[21:43] <jreingol> 1.13.0-quantal-amd64
[21:43] <marcoceppi> jreingol: Okay this might be related to a few missing commands in 1.13
[21:43] <jreingol> erg
[21:43] <jreingol> what version would you recommend?
[21:45] <marcoceppi> 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] <jreingol> i used the devel ppa
[21:46] <marcoceppi> 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] <jreingol> should i remove all of it and go with the stable branch
[21:46] <jreingol> perfect
[21:47] <marcoceppi> 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] <marcoceppi> 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] <jreingol> k... well thanks for the help
[21:50] <jreingol> yep... still happening
[21:50]  * jreingol wonders if provider-state is a maas problem
[21:51] <marcoceppi> 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