[00:17] <marcoceppi> I found a weird regression
[00:17] <hazmat> marcoceppi, how so?
[00:18] <marcoceppi> in juju-0.7 I can do `rsync -avz -e "juju ssh -e <juju_env>" charm/0:/path/to/file ./` but that fails in juju-core (logging bug) since it's trying to parse everything after the unit is given in the command chain
[00:19] <sarnold> charm/0:/foo  works? wow
[00:21] <marcoceppi> sarnold: when you set -e to juju ssh, it does, it basically computes to something like this: juju ssh mysql/0 rsync --server --sender -vvlogDtprze.iLsf . "/var/log/juju/*"
[00:21] <sarnold> marcoceppi: very neat :)
[00:21] <marcoceppi> hazmat: not sure how likely this is to get fixed in core, looks like a discrepancy with the way arguments are parsed compared to 0.7
[00:22]  * marcoceppi considers a juju-rsync plugin as an alternative
[00:22] <hazmat> yeah.. if the latter form works i'd consider it an oddball
[00:22] <hazmat> ie rsync after the unit spec
[00:23] <marcoceppi> Should I not bother a bug report then? Given this appears to be "expected" behavior in juju-core?
[00:25] <hazmat> marcoceppi, for ssh compounding to the unit name to me seems like a non feature.. if it also applies to juju scp where the common form is host:/path then its worth a bug.. else not imo.
[00:26] <marcoceppi> hazmat: ack
[00:27] <hazmat> hmm
[00:27] <hazmat> marcoceppi, by charm/0 you met unit/0 ?
[00:28] <hazmat> ment
[00:28] <hazmat> marcoceppi, you ever head out to lost dogs?
[00:28] <marcoceppi> hazmat: yes, so something like mysql/0 - what I was saying is that rsync command works with 0.7 pyjuju but not juju-core
[00:28] <marcoceppi> hazmat: I live near it, but I've not traveled that way
[00:28] <marcoceppi> I hear they have good pizza and beer though
[00:30] <hazmat> marcoceppi, indeed they do.. and good sandwitches.. i hit them up on a regular basis.. was debating a journey out this evening
[00:31] <hazmat> marcoceppi, this form.. `rsync -avz -e "juju ssh -e <juju_env>" charm/0:/path/to/file ./` working isn't worth a bug.. it is if this one doesn't though imo..  juju ssh mysql/0 rsync --server --sender -vvlogDtprze.iLsf . "/var/log/juju/*"
[00:32] <hazmat> omg .. -vvlogDtprze.iLsf
[00:32] <marcoceppi> hazmat: the neither work because juju says: error: flag provided but not defined: --server
[00:33] <hazmat> marcoceppi, so the latter one is worth a bug.. anything after the unit/machine should be passed through to ssh
[00:33] <marcoceppi> hazmat: ah, that sounds lovely, if it was an invitation I sadly have plans tonight. Any other day I would be down for beer and sandwiches
[00:33] <marcoceppi> hazmat: ack, so i the latter is fixed, the former will also be repaired as the former expands to the latter
[00:33] <marcoceppi> s/so i/so if/
[00:34]  * marcoceppi files a bug
[00:34] <hazmat> marcoceppi, cool, and icc
[01:21] <dpb1> thumper: awesome, thanks
[01:31] <mwhudson> hmm
[01:32] <mwhudson> how do you deploy onto quantal?
[01:32] <thumper> mwhudson: whazzup?
[01:32] <thumper> mwhudson: simplest way is to set default series in environments.yaml
[01:32] <mwhudson> done that
[01:32] <thumper> you also need quantal charms
[01:32] <mwhudson> aah ok
[01:32] <mwhudson> and there aren't many?
[01:32] <thumper> right
[01:32] <thumper> most are lts only
[01:33] <thumper> I guess you could branch the precise charms locally
[01:33] <mwhudson> fun fun fun when the lts kernel doesn't boot with the firmware you are using
[01:33] <thumper> then use a local charm to push to quantal
[01:33]  * thumper waves his hands
[01:33] <thumper> then magic happens
[01:33] <thumper> sorry, not push
[01:33] <thumper> deploy local:foo
[01:34]  * mwhudson sighs
[01:34] <thumper> I don't know the details...
[01:34] <thumper> but seems possible
[01:34] <mwhudson> yeah, must be possible
[01:34] <thumper> with not too many hoops
[01:38] <marcoceppi> mwhudson: you can also deploy the precise version of a charm to a quantal environment (not recommended). I believe if you do juju deploy cs:precise/mysql with a quantal default-series you should get the precies charm on a quantal machine
[01:38]  * marcoceppi double checks
[01:38] <mwhudson> marcoceppi: don't bother, you don't
[01:38] <mwhudson> because that's what i did earlier
[01:38] <marcoceppi> mwhudson: juju-core or juju-0.7?
[01:39] <mwhudson> 0.7
[01:39] <mwhudson> because i'm deploying to armhf, see earlier :)
[01:39] <marcoceppi> ah, fun fun
[01:40] <marcoceppi> yeah, you're going to need to branch the charms, some thing like mkdir ~/charms/quantal; bzr branch lp:charms/mysql ~/charms/quantal/; juju deploy --repository ~/charms local:mysql; unfortuantely
[01:40] <marcoceppi> okay /me really needs to go
[01:41] <mwhudson> ta
[01:44] <sarnold> having done two (very simple) charms so far, it seemed like it'd be easy to have precise and quantal versions.. but now there's also raring, and soon saucy, all before the next lts.. On the one hand, having versions for all of those sounds a bit kind, on the other hand, doing the work to make them happen is enough work that I haven't yet...
[01:45] <sarnold> .. and I'd feel bad if someone found problems with e.g. a quantal version six months after I'd stopped even using it..
[01:46] <sarnold> is there a suggested best practice here?
[02:40] <mwhudson> would one expect juju (0.7) to survive the bootstrap node unexpectedly rebooting?
[02:41] <mwhudson> 2013-05-22 22:35:55,402: twisted@ERROR: Unhandled Error
[02:41] <mwhudson> Traceback (most recent call last):
[02:41] <mwhudson> Failure: zookeeper.NodeExistsException: node exists
[02:42] <mwhudson> in machine.log doesn't look good :(
[02:46] <sarnold> mwhudson: I think I heard that's not supported..
[02:46] <mwhudson> yay
[02:46]  * mwhudson runs destroy-environment
[02:46] <mwhudson> one more time can't hurt right?
[02:50] <sarnold> I assume they go to environment heaven, where the clouds are .. cloudy, and zookeepers have a lot of cool animals to tend
[04:50] <AskUbuntu> -bash: metrik@Metrik-Corp-Server1-MASS-Control:~/.juju$: No such file or directory | http://askubuntu.com/q/298941
[10:08] <mattyw> I keep getting the "cannot get latest charm revision: no charms found matching" when deploying a local charm, any idea how to debug this, I'm sure my yaml files are valid. It seems similar to this but I even get it when removing the symlinks I have https://bugs.launchpad.net/juju-core/+bug/1129319
[10:08] <_mup_> Bug #1129319: Local charm deployment not working if symlinks are used <juju-core:New> <https://launchpad.net/bugs/1129319>
[10:46] <hazmat> mattyw, perhaps there's an error on the charm itself
[10:46] <hazmat> mattyw, really simple go program to verify a charm.. http://paste.ubuntu.com/5693306/
[10:47] <mattyw> hazmat, looks like it was my metadata.yaml having an error
[10:47] <mattyw> hazmat, that's a great little tool thanks
[10:52] <mattyw> hazmat, it would be useful for that tool to be available in juju somehow - like a juju verify-charm command or a plugin
[10:57] <hazmat> mattyw, agreed.. plugins are a little problematic..
[10:58] <hazmat> for go ironically
[10:58] <hazmat> no compilation/distribution model
[11:07] <mattyw> it doesn't seem like doing juju destroy-service or juju remove-unit on a charm which has failed works, anyone else seen this?
[11:15] <sidnei> mattyw: you have to mark it as resolved first, so that the stop hook gets called
[11:15] <mattyw> sidnei, ok thanks
[11:25]  * hazmat prefers juju-deployer -T -W
[11:26]  * hazmat files a bug report for force
[11:28] <hazmat> bug 1089289 and bug 1183309 fwiw
[11:28] <_mup_> Bug #1089289: remove-unit --force <juju-core:Confirmed> <https://launchpad.net/bugs/1089289>
[11:28] <_mup_> Bug #1183309: destroy-service should have a force option <juju-core:New> <https://launchpad.net/bugs/1183309>
[12:22] <mattyw> marcoceppi, ping?
[12:22] <marcoceppi> mattyw: pong
[12:26] <mattyw> marcoceppi, thanks for the legacy_juju review, it's already in charm helpers as the juju-gui guys are using it as well, shall I still submit and MP to get it into the main part of helpers?
[12:27] <marcoceppi> mattyw: If the code already exists in the new charm-helpers project I wouldn't worry about it. If not, then I'd say open a merge request for it (if you're interested in seeing it live on)
[13:49] <mattyw> has anyone tried deploying the postgresql charm using juju-core? I'm seeing an error during it's call to relation-list saying -r isn't defined as a flag
[13:51] <marcoceppi> mattyw: it's a known bug in juju-core
[13:51] <marcoceppi> mattyw: https://bugs.launchpad.net/juju-core/+bug/1172895
[13:51] <_mup_> Bug #1172895: relation-list incompatibility with pyjuju: -r <juju-core:Fix Committed by fwereade> <https://launchpad.net/bugs/1172895>
[13:51] <mattyw> marcoceppi, ok cool, just wanted to know if I should be raising it or was it already captured
[13:52] <marcoceppi> mattyw: looks like it's actually targeted for the next patch release of juju-core, (1.10.1) not sure when that will be though
[14:30] <sinzui> hi ~charmers. I have a branch that needs review: https://code.launchpad.net/~sinzui/charms/precise/mongodb/restore-from-dump/+merge/165408
[14:30] <sinzui> maybe wedgwood should look at it ^ since webops want the feature
[14:32] <wedgwood> sinzui: did they?
[14:34] <wedgwood> sounds like something webops would ask for
[14:34] <wedgwood> I'll have a look today
[14:34] <sinzui> wedgwood, mthaddon reported the issue in regards to jujucharms.com
[14:35] <wedgwood> sinzui: I suppose I should say I'll *try* to get to it today. I've got a sprint next week that I'm prepping for. If I don't get to it today, it'll be a while.
[14:36] <mthaddon> sinzui: ftr, wedgwood is no longer in webops, is now in IS projects, but is obviously still involved in charm reviewing generally
[14:36] <sinzui> wedgwood, thank you for trying. Does this sprint involve updates to an elasticsearch charm (I saw a references to it in an rt)
[14:37] <sinzui> mthaddon, thank you. I did not know that
[14:37] <mthaddon> sinzui: we're in squads now, rotating between web0ps, projects and operations
[14:38] <sinzui> oh
[14:39] <wedgwood> sinzui: and next week's sprint regards that reorg. No elasticsearch work that I'm aware of
[14:40] <mthaddon> wedgwood: it may be one of the targets for paired juju programming, but I can't confirm that at the moment
[14:40] <sinzui> okay. I have a todo to update our version of the charm to release 0.90.0. Once done, I think I will propose it to replace the current charm as it addresses most of the issues that have been brought up about the current charm
[17:05] <paraglade> marcoceppi: look like I am not getting the SSL issue again but this time I am getting the error when tying to bootstrap an EC2 instance ( http://pastebin.ubuntu.com/5694293/ )
[17:05] <paraglade> did you happen to have a fix for this?
[17:06] <marcoceppi> paraglade: not this specific error, as I mentioned yesterday someone was having "similar" ssl issues, they reinstalled ca-certificates and that resolved it for them. I'm honestly not sure about this error as I've not encountered it in Juju before
[17:07] <marcoceppi> paraglade: outside of filing a bug, that would be my only suggestion :\
[17:07] <paraglade> ack
[17:08] <sarnold> paraglade: you could use strace or fatrace to try to find out _which_ file causes that error.
[17:09] <sarnold> paraglade: knowing that might get you to a point where you could investigate ..
[17:18]  * paraglade shakes head
[17:19] <paraglade> well turns out that I have some *.pem files in my .juju dir that juju does not like.  thanks sarnold strace helped.  I am now able to bootstrap.
[17:20] <sarnold> paraglade: woo! :)
[19:36] <bac> hi marcoceppi, there is a new team ~juju-gui-charmers that has ~juju-gui and ~charmers in it.  we'd like the branch of the GUI that team owns to be the official charm.  can you do that or is that an m_3 thing?
[19:46] <marcoceppi> bac: I should be able to, let me take a look
[19:46] <bac> thx
[19:59] <marcoceppi> bac: juju-gui has been re-promulgated to https://code.launchpad.net/~juju-gui-charmers/charms/precise/juju-gui/trunk
[19:59] <marcoceppi> I'm deleting the ~charmers branch
[19:59] <bac> marcoceppi: cool, thanks
[19:59] <bac> marcoceppi: not yet, please
[20:00] <marcoceppi> bac: ack, np
[20:00] <bac> marcoceppi: there is a bug i'm working with orange resolve.  they only look at ~charmer owned branches for the charm browser, not the official one
[20:00] <bac> marcoceppi: i'd like the ~charmers branch to remain until that bug is fixed
[20:01] <marcoceppi> bac: Oh, that's right. No problem - not sure how you'll want to handle keeping that update (if at all) but I'll leave that up to you
[20:01] <bac> marcoceppi: hopefully by resolving the bug v. soonish
[20:03] <bac> marcoceppi: the upside of this change is now ~charmers can push to that location, which was one of the motivations (he said stating the obvious).
[20:47] <m_3> bac: marcoceppi: the ~juju-gui team branch has been the official one used when `juju deploy juju-gui`
[20:47] <m_3> the problem is that jujucharms.com points only to ~charmers branches and needs to be fixed
[20:47] <m_3> there's a bug on that somewhere
[20:49] <m_3> marcoceppi: we can't delete the ~charmers stuff with all the junk stacked on top of it still... at least I don't know how to do that without getting lp help from #IS
[20:49] <bac> m_3, orange has a fix to that bug about to land.
[20:49] <bac> m_3, hmmm, hadn't considered stacking...
[20:49] <marcoceppi> m_3: yeah, I tried to delete it before bac said to wait, and was met with newman saying "no no no, you didn't say the magic word"
[20:51] <m_3> lp:charms/juju-gui was matching lp:~juju-gui/charms/precise/juju-gui/trunk and that was the one deployed by the CLI
[21:01] <hazmat> m_3, unfortunately the code base has changed so greatly from the version on jujucharms.com  i'm reluctant to do a quick fix..
[21:01] <hazmat> i guess its not the end of the world..
[21:17] <m_3> hazmat: yeah, that ones been sitting there for a while... I wanted to get together over UDS-time to hash out a decent soln
[21:20] <m_3> so current situation is that `juju deploy juju-gui` deploys lp:~juju-gui-charmers/charms/precise/juju-gui/trunk, but jujucharms.com still points to lp:~charmers/charms/precise/juju-gui/trunk
[21:23]  * m_3 back to talks
[22:18] <gary_poster> marcoceppi, very cool about juju-test.  I'll see if we can switch to it (may require switching our charm tests to juju core, which we ought to do anyway, but makes testing your work farther away)
[22:18] <marcoceppi> gary_poster: you can use juju-test with pyjuju :)
[22:19] <gary_poster> marcoceppi, oh cool!  I thought we would need the plugin stuff
[22:19] <marcoceppi> gary_poster: naw, if it's in the path, just run juju-test intead of juju test
[22:19] <gary_poster> awesome marcoceppi I'll pass that along
[22:19] <gary_poster> thanks
[22:20] <marcoceppi> gary_poster: plugins haven't even been "released" yet, they just landed in trunk yesterday
[22:20] <marcoceppi> gary_poster: no problem. I'm all ears to feedback, what sane defaults should be, etc. just let me know!
[22:20] <gary_poster> cool, will do :-)
[23:35] <arosales> marcoceppi, +1 on the testing progress. Thanks for the work and update.