| === CyberJacob is now known as CyberJacob|Away | ||
| jpds | Why does charm get ceph not work? | 04:17 |
|---|---|---|
| === 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 | ||
| 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? | 07:23 |
| === 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_ | ||
| raywang | hello, anyone knows how to upgrade the juju-core agent version from a deployed node? | 10:13 |
| 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:15 |
| 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:16 |
| jamespage | raywang, ah - OK - you have to jump through 1.12 first | 10:17 |
| jamespage | juju upgrade-juju --version 1.12 I think | 10:17 |
| jamespage | raywang, rogpeppe sent an email to the juju-dev ML about this | 10:18 |
| raywang | jamespage, error: invalid version "1.12" | 10:18 |
| 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:19 |
| 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:20 |
| jamespage | raywang, how did you get your tools into the MAAS environment in the first place? I've not tried that yet | 10:21 |
| raywang | jamespage, sorry, what do you mean by "get the tools into the maas environment?" :) | 10:27 |
| 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:28 |
| 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:29 |
| jamespage | fwiw there is work going on in the tool distribution area this cycle to make stuff like this a bit easier! | 10:30 |
| === marcoceppi_ is now known as marcoceppi | ||
| 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:13 |
| rogpeppe | jamespage: another possibility is to encode upgrade paths into the simplestreams data (or somewhere else external to the juju binary) | 11:14 |
| rogpeppe | raywang: if you've upgraded to juju-core tip, i suspect your installation might be broken now :-\ | 11:15 |
| 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 | 11:17 |
| === melmoth__ is now known as melmoth | ||
| kita | hi | 12:42 |
| kita | hi | 12:43 |
| geme | hi | 12:43 |
| kita | hi | 12:43 |
| 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:45 |
| jcastro_ | http://askubuntu.com/questions/327177/cannot-bootstrap-due-to-precise-images-in-regionone-with-arches-amd64-i386 | 12:46 |
| jcastro_ | geme, ^^^^^ | 12:46 |
| geme | thanks jcastro but juju image-metadata gives command not found | 12:50 |
| jcastro_ | juju-metadata generate-image | 12:51 |
| jcastro_ | try that | 12:51 |
| geme | command not found agian | 12:52 |
| geme | juju version 1.13.0 | 12:52 |
| geme | Should I install a different version ? | 12:54 |
| jcastro_ | hmmmm | 12:55 |
| jcastro_ | let me ask somebody here | 12:55 |
| geme | thanks | 12:55 |
| jcastro_ | hey mgz, any idea on this? ^^^ | 13:03 |
| jcastro_ | marcoceppi, ping | 13:05 |
| marcoceppi | jcastro_: pong | 13:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:14 |
| pavel | when does Mark Mims come back? | 13:15 |
| 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:16 |
| jcastro_ | geme, did you have the problem prior to 1.13? | 13:17 |
| jcastro_ | I am going to guess "no" | 13:17 |
| geme | jcastro, this is the 1st time that I've tried the juju-core version. Used python juju before | 13:20 |
| geme | jcastro, the default-image-id was a lot easier | 13:21 |
| 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:23 |
| jcastro_ | wait | 13:24 |
| jcastro_ | there's a ppa:juju/stable? | 13:24 |
| jcastro_ | why do the docs say /devel? | 13:24 |
| 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:25 |
| marcoceppi | jcastro_: yeah, nevermind. I have no idea where 1.12 was uploaded to. | 13:29 |
| jcastro_ | me either | 13:31 |
| jcastro_ | wtf | 13:31 |
| * jcastro_ fires off another email to the list. | 13:31 | |
| marcoceppi | pew pew! | 13:34 |
| geme | jcastro, juju-gui questions handled here or another topic ? | 13:39 |
| jcastro_ | geme, here too! | 13:40 |
| geme | jcastro, that's handy. Are there plans for juju-gui to handle local repository charms ? | 13:41 |
| 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:43 |
| 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:44 |
| jcastro_ | but hopefully something we can fix tomorrowish when the right people wake up | 13:45 |
| geme | jcastro, great - I'll reinstall in a couple of days | 13:47 |
| 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:54 |
| geme | jcastro, Are there plans for juju-gui to handle local repository charms ? | 13:59 |
| pavel | sinzui, thanks you so much, I would never figure this out on my own | 14:00 |
| sinzui | np, thank you for finding a bug. | 14:01 |
| geme | gary_poster, Are there plans for juju-gui to handle local repository charms ? | 14:11 |
| rick_h | geme: define 'handle'? | 14:11 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| gary_poster | geme does story one work for you? | 14:22 |
| 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:23 |
| 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:27 |
| gary_poster | geme, ah, yes. we're interested in that too, for a bit later. The upload story would be a sooner thing. | 14:35 |
| 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:40 |
| geme | being able to point the gui at multiple local charm stores would be very useful | 14:42 |
| 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:47 |
| geme | Great - I see the multi-charm-store case as giving the developer control of deployment instead of maybe devops. | 14:50 |
| === natefinch is now known as natefinch-afk | ||
| === CyberJacob is now known as CyberJacob|Away | ||
| kita | hi | 15:13 |
| kita | gsdsdhxz | 15:17 |
| marcoceppi | hi kita | 15:17 |
| === kita is now known as juju | ||
| juju | hi | 15:17 |
| juju | jh | 15:17 |
| juju | hi | 15:18 |
| === CyberJacob|Away is now known as CyberJacob | ||
| sidnei | noodles775: https://code.launchpad.net/~sidnei/charms/precise/avahi/trunk want to give it a try? | 15:26 |
| === CyberJacob is now known as CyberJacob|Away | ||
| 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:32 |
| 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:45 |
| 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:47 |
| 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:48 |
| pavel | or even on monday | 15:49 |
| pavel | sinzui, nope, yesterday and it didn't update yet | 15:49 |
| === CyberJacob|Away is now known as CyberJacob | ||
| === CyberJacob is now known as CyberJacob|Away | ||
| 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:55 |
| 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:58 |
| 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` | 15:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| === CyberJacob|Away is now known as CyberJacob | ||
| pavel | m_3, I will try, it won't be worst | 16:03 |
| m_3 | pavel: sure... with maybe a trivial new commit to make sure the store gets kicked | 16:04 |
| 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:05 |
| m_3 | s/it's/its/ /me needs coffee | 16:06 |
| pavel | ok, now I have brand new branch | 16:07 |
| pavel | will charmers meeting be held today? | 16:10 |
| 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:12 |
| 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:13 |
| tasdomas | hi | 16:58 |
| tasdomas | where can I find documentation on the upgrade-charm hook? | 16:58 |
| marcoceppi | tasdomas: we don't have an explicit docs about that hook yet, what questions do you have? | 17:02 |
| tasdomas | marcoceppi, just wanted to add it to a charm and wasn't sure, what context the hook is run under | 17:03 |
| === CyberJacob is now known as CyberJacob|Away | ||
| marcoceppi | if functions like any other hook, it's just triggered via `juju upgrade-charm` command | 17:04 |
| marcoceppi | tasdomas: most people simply symlink to the install hook as hooks are designed to be idempotent | 17:08 |
| marcoceppi | but it depends on what the process is for upgrading the charm/service | 17:10 |
| === natefinch-afk is now known as natefinch | ||
| tasdomas | marcoceppi, thanks | 17:18 |
| tasdomas | marcoceppi, what happens to relations when a charm is upgraded? They remain intact, right? | 17:18 |
| === CyberJacob|Away is now known as CyberJacob | ||
| === defunctzombie_zz is now known as defunctzombie | ||
| 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:48 |
| marcoceppi | m_3: have you ever used `relation-set --format=json` > | 17:54 |
| marcoceppi | ?* | 17:54 |
| m_3 | marcoceppi: nope | 18:27 |
| === tasdomas is now known as tasdomas_afk | ||
| 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:40 |
| 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:42 |
| 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:43 |
| marcoceppi | ahasenack: it's worked for me in 1.11.4 | 19:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| ahasenack | and I raised the point that the instance would still be up burning money | 19:51 |
| marcoceppi | ah | 19:51 |
| 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 | 20:49 |
| 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:02 |
| jreingol | marcoceppi: found a few errors in the docs i was using to set it up | 21:18 |
| jreingol | the maas url was wrong.. .its now http://localhost:5242 | 21:19 |
| jreingol | seems to be connecting now but gives error: Requested array, got <nil>. | 21:20 |
| jreingol | http://paste.ubuntu.com/5960394/ | 21:22 |
| marcoceppi | jreingol: I've not seen that error before. | 21:28 |
| jreingol | hahaha.... y do i always find the new ones | 21:32 |
| jreingol | thanks for the look though | 21:33 |
| marcoceppi | jreingol: what version of juju are you using (juju version) | 21:35 |
| === CyberJacob is now known as CyberJacob|Away | ||
| 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:43 |
| 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:45 | |
| 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:46 |
| 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:47 |
| jreingol | k... well thanks for the help | 21:48 |
| jreingol | yep... still happening | 21:50 |
| * jreingol wonders if provider-state is a maas problem | 21:50 | |
| 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 | 21:51 |
| === 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 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!