| === CyberJacob is now known as CyberJacob|Away | ||
| danob | marcoceppi: sorry for late response. I just deploy a apache2 charm and what should i do to see "it works" default page if i hit public address of apache2 unit? | 00:34 |
|---|---|---|
| jcastro_ | you need to expose the service first | 00:37 |
| jcastro_ | juju expose apache2 | 00:37 |
| marcoceppi | danob: you need to provide a vjost template | 00:39 |
| danob | jcastro_: i exposed it :) | 00:40 |
| jcastro_ | oh nm, don't listen to me | 00:40 |
| danob | marcoceppi: how do i do that, i dont know :) | 00:41 |
| danob | marcoceppi: can you point me a doc, how to? | 00:42 |
| marcoceppi | danob: check the charm readme? | 00:42 |
| jcastro_ | http://manage.jujucharms.com/charms/precise/apache2 | 00:43 |
| jcastro_ | scroll down ^^^ | 00:44 |
| === sarnold_ is now known as sarnold | ||
| iamveen | Has anyone successfully boostrapped juju on a vagrant/virtualbox guest? It never works for me. There always seems to be problems looking up the architecture or ubuntu release. | 01:50 |
| iamveen | I want to like juju, but It's so incredibly frustrating at this point. | 01:53 |
| marcoceppi | iamveen: What do you mean vagrant/virtualbox? How are you trying to bootstrap these? | 02:11 |
| === edu-afk is now known as edamato | ||
| iamveen | I bring up an ubuntu host in vagrant, then use the "null" provider, then run juju bootstrap | 02:15 |
| sarnold | is there still a null provider? I thought it was renamed 'ssh' ages ago... | 02:16 |
| iamveen | oh really... I could swear the docs still refer to null | 02:17 |
| sarnold | can you contact your other hosts from within the vangrant guest? | 02:17 |
| iamveen | let me check | 02:17 |
| axw | there is, it's called "manual" now. iamveen, which version of juju are you using? | 02:17 |
| axw | iamveen: it's still called null in the released version | 02:17 |
| iamveen | 1.16.6 on OSX | 02:17 |
| sarnold | aww man, I thght 'null' was such a bad name it only lived for a month or so. darn. :) | 02:17 |
| sarnold | bugger the name made it to release.. | 02:17 |
| axw | iamveen: the 1.16.x version of the null provider is pretty alpha, I would highly recommend trying 1.17.3 | 02:18 |
| axw | there have been many bug fixes | 02:18 |
| iamveen | This page still says to use "null" - https://juju.ubuntu.com/docs/config-manual.html | 02:18 |
| axw | yep - it will be changed when 1.18 is released | 02:19 |
| sarnold | iamveen: sorry, it's my mistake. I thought the name 'null' was killed before release.. | 02:19 |
| iamveen | ah | 02:19 |
| === mwhudson is now known as zz_mwhudson | ||
| iamveen | is that not available via brew? | 02:19 |
| axw | iamveen: sorry, I don't know about juju packaging on OS X. You may have to build from source... | 02:20 |
| iamveen | k | 02:20 |
| iamveen | thanks guys | 02:20 |
| iamveen | I'll give that a shot | 02:20 |
| iamveen | Is there a preferred ubuntu release for hosts? | 02:21 |
| === zz_mwhudson is now known as mwhudson | ||
| axw | precise still has the most charms, AFAIK | 02:22 |
| sarnold | iamveen: precise is probably your best bet; most charms, most support | 02:23 |
| iamveen | cool, thanks | 02:23 |
| iamveen | okay, 0.17.3 works much better | 02:47 |
| iamveen | 1.17.3 even | 02:48 |
| sarnold | cool! | 02:51 |
| === edamato is now known as edu-afk | ||
| === timrc is now known as timrc-afk | ||
| === mwhudson is now known as zz_mwhudson | ||
| === timrc-afk is now known as timrc | ||
| === timrc is now known as timrc-afk | ||
| danob | marcoceppi: its working now ;) | 04:58 |
| danob | jcastro_: thanks :) | 04:59 |
| === CyberJacob|Away is now known as CyberJacob | ||
| === CyberJacob is now known as CyberJacob|Away | ||
| === freeflying is now known as freeflying_away | ||
| === freeflying_away is now known as freeflying | ||
| === wrtp is now known as rogpeppe | ||
| === rogpeppe1 is now known as rogpeppe | ||
| === rogpeppe1 is now known as rogpeppe | ||
| noodles775 | Anyone able to do a charm-helpers review? https://code.launchpad.net/~michael.nelson/charm-helpers/include-relations-for-type/+merge/205087 | 10:39 |
| noodles775 | marcoceppi: ^^ Do you know who is around to review charm-helper branches these days? | 10:44 |
| * noodles775 checks the revision history. | 10:44 | |
| JoshStrobl | hey marcoceppi, when you get the time, mind reviewing the following pull request and accepting it upstream if it LGTY? https://github.com/juju/plugins/pull/7 | 11:00 |
| JoshStrobl | also, marcoceppi, Q regarding my charm. I modified the config-changed file so it properly uninstall / installs apache2 and/or nginx (depending on the config-get engine). nginx doesn't have a service file, so it returns as an unrecognized service when you call service nginx start or /etc/init.d/nginx start. Any recommendations? | 11:04 |
| === jacekn_ is now known as jacekn | ||
| === timrc-afk is now known as timrc | ||
| marcoceppi | JoshStrobl: uh, nginx does/should have an init file | 12:41 |
| marcoceppi | noodles775: I, and a few others, are | 12:42 |
| JoshStrobl | marcoceppi: hmm | 12:46 |
| noodles775 | marcoceppi: ok. Let me know if you won't have time to look at that branch and I'll try to persuade someone else :) | 12:50 |
| marcoceppi | noodles775: it's in the review-queue so I have to look at it sometime ;) | 12:58 |
| noodles775 | marcoceppi: sure, but I've only just pushed an update, it's been in the review queue for a few weeks (not your issue - just that I feel I need to find someone rather than just leave it there). | 13:00 |
| marcoceppi | noodles775: ack, turns out it wasn't in the review-queue after all, I'm going to make sure ~charmers get assigned to reviews for these so it will in the meantime | 13:01 |
| noodles775 | Ah - the default ~charm-helpers isn't correct? | 13:02 |
| marcoceppi | noodles775: yeah, I thought it was ~charmers, which would put it in our review queue | 13:02 |
| marcoceppi | noodles775: why change the dict keys to _? | 13:02 |
| noodles775 | marcoceppi: because in a jinja2 template (which ansible and saltstack use) you can't do mydict.my-key.value, only mydict.my_key.value | 13:03 |
| marcoceppi | noodles775: ah, okay - I assumed as much but wanted to make sure | 13:03 |
| JoshStrobl | and not longer afk...in a sense | 13:08 |
| JoshStrobl | marcoceppi: Regarding nginx: Still doesn't explain why it server nginx start claims the service doesn't exist. | 13:09 |
| JoshStrobl | *why service | 13:09 |
| marcoceppi | JoshStrobl: http://paste.ubuntu.com/6999673/ really not sure | 13:13 |
| JoshStrobl | marcoceppi: I'll go ahead and look into it further on my end | 13:15 |
| JoshStrobl | Wouldn't surprise me if it is a bug my charm :D | 13:15 |
| JoshStrobl | config-get x would be the appropriate call during something like an install script to get the setting value, correct? | 13:39 |
| === psivaa is now known as psivaa-lunch | ||
| marcoceppi | JoshStrobl: it could be done during the install hook, but make sure you implement logic in config-changed that handles that config value as well - or just have all the config managment stuff in config-changed and the install hook be very light | 13:43 |
| JoshStrobl | marcoceppi: So would the appropriate line for getting the value be: x='config-get y', x=${'config-get y'}? | 13:44 |
| JoshStrobl | example, for my charm: preferredEngine='config-get engine' | 13:45 |
| marcoceppi | well, you'll want to use `` not '' | 13:46 |
| marcoceppi | either $(config-get <key>) or `config-get <key>` | 13:46 |
| JoshStrobl | alrighty | 13:46 |
| * JoshStrobl is still newish to bash scripting | 13:46 | |
| marcoceppi | np | 13:47 |
| Ming_ | want to try Juju GUI 1.0 It requires Juju 1.17.3. How do I install it? repository is pap:juju/develop? | 13:54 |
| Kauko | Hi, I just heard about juju and I have to say it looks amazing! Saw that there's an IRC channel and thought I'd join and ask some questions | 14:02 |
| Kauko | How does juju work with AWS Elastic Beanstalk? Not sure if this is a stupid question since I'm not totally sure if I completely understand how juju works yet :P | 14:02 |
| Kauko | I found some examples of using juju on normal ec2 instances, but I'd really like to use elastic beanstalk since it has some great features | 14:03 |
| Kauko | is there any difference between deploying on elastic beanstalk vs ec2? | 14:04 |
| marcoceppi | Kauko: currently juju doesn't support beanstalk to my knowledge | 14:04 |
| Kauko | ah, thats a damn shame | 14:04 |
| marcoceppi | Kauko: currently, it generalizes clouds to give you the ability to drive different cloud envionments from the same tool | 14:04 |
| marcoceppi | Juju is like beanstalk, but for more than just Amazon | 14:05 |
| jamespage | marcoceppi, got a charm branch for mysql on trusty I can steal? looking to deprecate the use of my hacked one in our lab :-) | 14:05 |
| marcoceppi | as a very crude comparison | 14:05 |
| marcoceppi | jamespage: not yet, but I should have one by Friday | 14:05 |
| jamespage | \o/ | 14:05 |
| marcoceppi | just finishing the tests for mysql | 14:05 |
| jamespage | all nice and in python? | 14:05 |
| Kauko | marcoceppi: Yeah I think I understand what you mean. It | 14:06 |
| marcoceppi | jamespage: not entirely rewritten yet, there's still a few outstanding merges I want to get in before starting down that road | 14:06 |
| Kauko | It's a shame it doesn't support beanstalk though, I kind of need the versioning, deployment etc features beanstalk can give me | 14:06 |
| marcoceppi | Kauko: could you elaborate a bit? Juju might have some comperable features | 14:07 |
| Kauko | kk, just give me a moment, I'll need to look through the beanstalk features first! ;) | 14:07 |
| Kauko | actually off the top of my head I can say that we need to be able to deploy different versions of our app (so that we can have beta, stable, prev_stable) | 14:09 |
| JoshStrobl | hmm, mkdir -p /var/www/ fails on the install script with the Vagrant precise vagrant box, yet worked during testing on my old Ubuntu Server VM. | 14:09 |
| marcoceppi | Kauko: cool, you can do that in juju | 14:09 |
| JoshStrobl | *Vagrant precise box | 14:09 |
| marcoceppi | JoshStrobl: is that the local provider on Vagrant, or just using the manual provider? | 14:09 |
| JoshStrobl | Even tried with sudo and it failed. | 14:09 |
| JoshStrobl | local provider | 14:09 |
| JoshStrobl | juju deploy --repository ~/charms local:metis | 14:10 |
| Kauko | marcoceppi: oh! Also beanstalk scales automatically, and it should be pretty easy to deploy using scripts (we want CI) | 14:10 |
| Kauko | marcoceppi: can juju do this too? | 14:10 |
| marcoceppi | Kauko: so, we don't have "autoscaling" yet (on the roadmap) but you can scale, and juju has a full websocket API so you can have tools do scaling for you automatically. Otherwise, using CI to deploy and drive juju environemnts is pretty straight forward, either via the CLI or by connecting to the bootstrap node directly with the API | 14:11 |
| JoshStrobl | marcoceppi: To be more exact, https://juju.ubuntu.com/docs/config-vagrant.html > precise-server-cloudimg-amd64-juju-vagrant-disk1.box | 14:12 |
| Kauko | marcoceppi: hmm ok, cool. Any idea when we could expect to have autoscaling? 1 month, 1 year, 5 years? :) It's a feature that would be really good for me since I'm new with these things, and would prefer to spend my time thinking about other stuff :P | 14:13 |
| marcoceppi | Kauko: I'm not sure, but we'd probably see traction towards the fall of this year | 14:14 |
| JoshStrobl | marcoceppi: Line 184 & 185 of http://paste.ubuntu.com/6999928/. | 14:15 |
| marcoceppi | JoshStrobl: it seems to work there? | 14:16 |
| JoshStrobl | Well, sudo mkdir -p and mkdir -p don't output any errors (otherwise the script would fail), unzip extracts properly, yet when you try to cd /var/www the directory doesn't exist, nor any contents. | 14:16 |
| JoshStrobl | compared it to the same code in the old install script, no changes that'd cause it. | 14:17 |
| JoshStrobl | I'll pastebinit the install script so you can see | 14:18 |
| marcoceppi | JoshStrobl: line 208 seems to show that /var/www exists and zip extracts to it | 14:18 |
| JoshStrobl | marcoceppi: Indeed, hence my confusion. | 14:19 |
| JoshStrobl | http://paste.ubuntu.com/6999943/ | 14:19 |
| JoshStrobl | Ignore the use of sudo, I added those in to see if it'd make a difference and nope | 14:19 |
| marcoceppi | JoshStrobl: are you looking on the vagrant box or on the LXC container in the vagrant box? | 14:19 |
| JoshStrobl | it is on machine 1: instance-id: vagrant-local-machine-1...is it's local FS stored elsewhere? | 14:20 |
| JoshStrobl | If so, then please facepalm me :D | 14:20 |
| JoshStrobl | series: precise, agent-state: started on machine 1. | 14:20 |
| marcoceppi | JoshStrobl: right, you're running `juju ssh metis/0` (in the Vagrant box) then looking in /var/www | 14:21 |
| JoshStrobl | marcoceppi: I'm ssh'd into the Vagrant via `vagrant ssh`. Any difference? | 14:21 |
| marcoceppi | JoshStrobl: yeah, you need to go /one/ layer deeper | 14:22 |
| JoshStrobl | lemme guess, need to ssh into 1? | 14:22 |
| JoshStrobl | ah | 14:22 |
| marcoceppi | after vagrant ssh, run juju ssh metis/0 | 14:22 |
| marcoceppi | JoshStrobl: yeah, the Vagrant box acts as a new machine which has the local provider on it | 14:22 |
| JoshStrobl | you are completely right... | 14:22 |
| JoshStrobl | I ssh'd in, went to /var/www/ and it's there. | 14:22 |
| marcoceppi | so you can use it as a clean/pristine box to spin up LXC containers, destroy, recreate, etc | 14:22 |
| marcoceppi | also useful if you don't have an Ubuntu/Linux machine and want to use the local provider | 14:23 |
| JoshStrobl | Yea. On my VM I always deployed it locally, guessing that particular machine was the host (machine 0), so whenever I looked in /var/www I expected it there, didn't even think about ssh'ing into the machine. | 14:23 |
| JoshStrobl | that'd also explain the service issues | 14:24 |
| JoshStrobl | since it was on a different machine | 14:24 |
| JoshStrobl | yep | 14:24 |
| JoshStrobl | did service nginx status and voila, it is there | 14:24 |
| JoshStrobl | marcoceppi, I don't know what I'd do without ya man :D | 14:25 |
| marcoceppi | happy to help! | 14:26 |
| JoshStrobl | Just let me know when I start driving you insane. | 14:26 |
| Kauko | marcoceppi: thanks for your help! | 14:28 |
| === psivaa-lunch is now known as psivaa | ||
| === freeflying is now known as freeflying_away | ||
| cargill | hi, I'm still trying to get tests running on vagrant (local provider), but the tests seem to fail (log at http://pastebin.ubuntu.com/7000435/) | 16:06 |
| lazyPower | cargill: what are you using to run the tests? A vagrant provisioner statement? | 16:09 |
| cargill | the 'juju test' command inside the vagrant box | 16:10 |
| lazyPower | is this in the juju quickstart vagrant box? | 16:11 |
| lazyPower | Ah, ok - i see the issue. 1.16.5 does not support sudoless bootstrapping and has an issue running tests against the local provider. | 16:11 |
| cargill | ah, are the latest vagrant boxes set up with 1.17 or still 1.16? | 16:15 |
| marcoceppi | cargill: probably 1.17, not entirely sure | 16:21 |
| * marcoceppi isn't sure how often they get refreshed | 16:21 | |
| JoshStrobl | Not sure about later versions, but the latest precise build has 1.16.6. guessing 1.17 hasn't been backported or 1.17 hasn't been backported | 16:23 |
| marcoceppi | JoshStrobl: we don't backport to precise, I think that the vagrant boxes only have ppa:juju/stable enabled. You need to also enable ppa:juju/devel to get 1.17 releases | 16:24 |
| JoshStrobl | Meh, it's not a priority to me :P I'm content with ppa:juju/stable. | 16:26 |
| JoshStrobl | What other "features" besides sudoless bootstrapping does 1.17.x bring? | 16:27 |
| lazyPower | a ton of fixes to the local provider experience | 16:27 |
| lazyPower | https://launchpad.net/juju-core/+milestone/1.17.3 | 16:27 |
| lazyPower | release notes are here ^ | 16:27 |
| cargill | ok, so tests do not work on stable with local? Just changing the repo to /devel and updating will work on precise? | 16:28 |
| lazyPower | cargill: correct. That should be all you need to do to get tests running with the local provider. | 16:28 |
| cargill | complete absence of tests has been the only thing preventing me from raising a merge proposal for a while... | 16:29 |
| JoshStrobl | lazyPower: Oh...erm...yea maybe I should start using 1.17.3 :D | 16:29 |
| lazyPower | JoshStrobl: i started working on a community maintained vagrantfile, its kind of a precursor for some functionality marcoceppi and I are working on to enhance the cross platform charmer story | 16:31 |
| lazyPower | if you're interested in what i've done - and note, its got a serious drawback of working on top of a 801 mb (yikes!) boxfile | 16:31 |
| lazyPower | https://github.com/chuckbutler/juju-vagrant -- this is specific to tests. If you pull the cloud image and update to juju 1.17.3 it should cut down the boxfile size, and give you similar results | 16:32 |
| lazyPower | ymmv however, as i haven't tested it. | 16:32 |
| JoshStrobl | lazyPower: I'll take a look at it :) | 16:38 |
| lazyPower | cool! :) Issues/pull requests welcome | 16:38 |
| lazyPower | if you get a functional upgrade from the cloud image, feel free to submit your work. I'd love to see what you did | 16:39 |
| cargill | hmm, and there we go again, I've wiped the vagrant box, started over and I get "The box 'JujuQuickstart' could not be found" | 16:39 |
| lazyPower | cargill: vagrant box list | 16:39 |
| lazyPower | can you pastebin that for me? | 16:39 |
| cargill | vagrant box list $ JujuQuickStart (virtualbox) | 16:39 |
| lazyPower | Casing on the S | 16:39 |
| lazyPower | it appears we haev an issue on the docs. I'll get a patch in a pull request. TY for calling that out cargill | 16:40 |
| cargill | oh yes, so the name I set must match the one in the image? | 16:40 |
| JoshStrobl | Yes, it is case sensitive. | 16:41 |
| lazyPower | Correct, whatever you import the boxname as must match your vagrant init | 16:41 |
| cargill | ah, hmm, that explains a couple of things, lazyPower, thank you very much! | 16:42 |
| lazyPower | marcoceppi https://github.com/juju/docs/pull/6 | 16:44 |
| JoshStrobl | I also recommend you saving the .box file locally. It makes doing a vagrant box add much faster when you have it fetch the box locally rather than via http | 16:44 |
| cargill | JoshStrobl: that's what I do :) | 16:45 |
| JoshStrobl | Yea after re-adding / destroying Vagrant boxes a few times, felt it would be smart to save the box file locally :D | 16:45 |
| lazyPower | You do now that once its cached you dont need to remove it unless you're upgrading right? | 16:46 |
| cargill | a note about the online docs, could they perhaps include the section name in the <title>? | 16:46 |
| dpb1 | marcoceppi: I'm hitting another case where I need an environment variable passed through for juju-test. Any chance we could reconsider allowing all environment to be passed through? | 16:46 |
| lazyPower | if it appears in vagrant box list, it will use that copy of the box for each subsequent spin up. | 16:46 |
| lazyPower | cargill: What do you mean? | 16:46 |
| lazyPower | oh you mean the title tag | 16:46 |
| marcoceppi | dpb1: which one | 16:46 |
| cargill | the title of https://juju.ubuntu.com/docs/config-LXC.html is Uju documentation | 16:47 |
| cargill | yes | 16:47 |
| cargill | s/Uju/Juju/ | 16:47 |
| dpb1 | marcoceppi: test specific. we have an env var used to skip certain tests. | 16:47 |
| Ursinha | hi all, is it possible to set machine constraints on the yaml file? instead of using juju set-constraints --service foobar ? | 16:48 |
| dpb1 | marcoceppi: do you know why it was a design decision to zero out the environment? I don't see other test tools doing that. | 16:48 |
| marcoceppi | dpb1: because it runs on a lightweight environment, so it can't rely on people using env variables that are set on their system and theirs only | 16:49 |
| dpb1 | marcoceppi: could I introduce an argument to allow the environment to be preserved? | 16:51 |
| lazyPower | Ursinha: yep. heres an example: http://paste.ubuntu.com/7000694/ | 16:51 |
| Ursinha | lazyPower: awesome, thank you very much. I've read the docs but couldn't find it, maybe I was searching in the wrong place. | 16:52 |
| lazyPower | Ursinha: I fired up a juju-gui and modeled it, then exported my bundle. | 16:52 |
| lazyPower | Thats how i've been writing my deployment YAML's for the last few weeks. | 16:52 |
| Ursinha | interesting. | 16:53 |
| lazyPower | Ursinha: https://juju.ubuntu.com/docs/charms-bundles.html | 16:53 |
| lazyPower | Juju bundles are a first class citizen in the juju ecosystem - it makes deploying complex configurations trivial | 16:54 |
| Ursinha | lazyPower: this is great! thanks for the pointers :) | 16:54 |
| lazyPower | Happy to help :) | 16:55 |
| Ursinha | I was wondering if I could set the constraint in the environment configuration file, do you know if that's possible? to ensure all instances created on that env would follow the constraints | 16:55 |
| Ursinha | let's say I have env01, and want all machines created on that env to have mem=4000 | 16:56 |
| lazyPower | Ursinha: i'm not aware of any env based configuration like that. Doesn't mean it doesn't exist, i just dont know about it. | 16:57 |
| Ursinha | lazyPower: thanks anyway, you provided great information :) | 17:00 |
| dpb1 | Ursinha: no, you can't currently set constraints in the environments.yaml file. Once you bootstrap, you can provide make a "default" like you are wanting though. See: https://juju.ubuntu.com/docs/charms-constraints.html for more info. | 17:00 |
| dpb1 | Ursinha: btw, the "bundles" that you have been discussing provide options for setting constraints on each service. | 17:01 |
| Ursinha | dpb1: I read these docs but couldn't find a way to do that in the conf file though, but thanks :) | 17:01 |
| Ursinha | dpb1: yes, I saw that. was wondering if I could set environment constraints, hence my last question :) | 17:02 |
| dpb1 | Ursinha: ya, not possible. I was checking for a bug/enhancement request, but can't find it. | 17:03 |
| Ursinha | I have two environments to deploy, one is nice, other not so nice, so one of them might require more tight constraints then the other, so configuring the service wouldn't be ideal | 17:03 |
| Ursinha | dpb1: I can file a bug, if that helps | 17:03 |
| marcoceppi | dpb1: maybe, I was considering a "passthrough" option to supply which env variables you want to pass through | 17:03 |
| marcoceppi | dpb1: what's the environment variable though? | 17:04 |
| dpb1 | Ursinha: https://bugs.launchpad.net/juju-core/+bug/1228311 | 17:04 |
| _mup_ | Bug #1228311: Specify default constraints <constraints> <improvement> <papercut> <juju-core:Triaged> <https://launchpad.net/bugs/1228311> | 17:04 |
| dpb1 | Ursinha: knew it was out there somewhere. :) | 17:04 |
| Ursinha | dpb1: awesome! thanks :) | 17:05 |
| dpb1 | marcoceppi: in this case... "SKIP_SLOW_TESTS", very specific to this charm, of course. | 17:05 |
| marcoceppi | dpb1: yeah, so that wouldn't work in our charm automated tests, but I can see how it would be helpful to you though | 17:06 |
| dpb1 | marcoceppi: well, I can throw up an MP if you would like, won't take me too much time. If you would rather it append to the whitelist rather than just allow everything through, let me know. | 17:06 |
| ahasenack | marcoceppi: do you really take down the environment between tests in the tests/ directory? | 17:06 |
| ahasenack | marcoceppi: I mean, I know juju-test does it, but do you really want it to? Do you use it that way? | 17:06 |
| marcoceppi | dpb1: something like --preserve-envs "comma,seperated,list,of,envs,to,add,to,whitelist" might work | 17:06 |
| marcoceppi | ahasenack: yes | 17:07 |
| ahasenack | marcoceppi: that's super expensive | 17:07 |
| dpb1 | marcoceppi: ok.. I'll throw something up (and a bug to start) | 17:07 |
| marcoceppi | ahasenack: right, there was/is an option (not sure if it's released yet) that will do only one bootstrap for all tests | 17:07 |
| ahasenack | marcoceppi: ok, but why would you (a generic "you", not you you) prefer to destroy the environment between tests against the same charm? | 17:07 |
| marcoceppi | ahasenack: well, not all tests would use the same base? What if a previous test fails - you wouldn't want to preserve that environment for the next test run, etc | 17:08 |
| marcoceppi | if you consider each test a userstory, having a potentially "dirty" environment from the last test run could influence that test file test run | 17:09 |
| ahasenack | yeah, bad tests do that | 17:09 |
| ahasenack | but re-deploying is expensive most of the time, not the exception | 17:09 |
| ahasenack | anyway, that just makes me put everything in one file under tests/ | 17:10 |
| ahasenack | since the deployment takes between 10-15min | 17:10 |
| lazyPower | ahasenack: i've got a complex mongodb deployment amulet test that takes approx 12 minutes to run. | 17:10 |
| marcoceppi | ahasenack: however, some people write tests that can safely cascade (ie do cleanup) so there's a flag that can be used to only setup bootstrap once | 17:10 |
| marcoceppi | ahasenack: that way, if your test files know how to clean up the deployment, etc, you can use multiple test files with the same boostrap | 17:10 |
| marcoceppi | I try to include as many options as possible for people to write tests that work for them | 17:11 |
| ahasenack | marcoceppi: is that in the package yet? | 17:11 |
| marcoceppi | ahasenack: let me check | 17:11 |
| lazyPower | its not as bad as you would think. I feel its cost of knowing that clean environment is going to perform as expected, and any post deployment op checking should be done within the given configuration. | 17:11 |
| lazyPower | at least for now until the post-deployment command patch lands | 17:11 |
| marcoceppi | ahasenack: not yet, it will be the "--one-bootstrap" flag though in the next release of charm-tools | 17:12 |
| ahasenack | marcoceppi: ok, thanks | 17:12 |
| lazyPower | I just ran into a new issue i haven't seen before | 17:20 |
| lazyPower | bootstrapping on HPCloud | 17:20 |
| lazyPower | ERROR bootstrap failed: rc: 1 | 17:20 |
| lazyPower | seems to have been temporary | 17:25 |
| dpb1 | marcoceppi: https://code.launchpad.net/~davidpbritton/charm-tools/preserve-environment/+merge/208439 | 17:40 |
| cargill | hmm, upgrading to 1.17 does not really help (from a fresh precise vagrant box, installed amulet, charm-tools, destroyed evn local, switched to /devel, upgraded juju, run juju test -e local, and it still thinks the env is already bootstrapped...) | 17:44 |
| mgz | cargill: what have you got in ~/.juju/environments/ ? | 17:44 |
| cargill | have no touched that | 17:44 |
| mgz | cargill: yhr point is you might need to :) | 17:45 |
| cargill | local.jenv | 17:45 |
| cargill | should I remove it? | 17:45 |
| mgz | okay, so try moving that out of the way, and rego | 17:45 |
| cargill | moved local.jenv elsewhere, still the same: ERROR environment is already bootstrapped | 17:46 |
| mgz | can you run with --debug and pastebin? | 17:49 |
| cargill | --debug on juju test does not really do anything | 17:50 |
| lazyPower | cargill: give me a moment to catch up and I'll give it a go | 17:51 |
| cargill | hmm: "verbose is deprecated with the current meaning, use show-log" | 17:54 |
| cargill | juju show-log: "ERROR unrecognized command: juju show-log" | 17:54 |
| mgz | --show-log | 17:54 |
| cargill | ah | 17:54 |
| mgz | but you really just want `juju --debug COMMAND ....` | 17:55 |
| cargill | well, there is no difference in what "sudo juju --debug test -e local" and "sudo juju test -e local" output | 17:56 |
| cargill | ah, when not using sudo, I get one message more: "error: flag provided but not defined: -y" | 17:57 |
| mgz | cargill: just proposed https://codereview.appspot.com/68180045 which should make that flag hint clearer | 18:03 |
| mgz | cargill: on the actual issue, is it related to the test being run at all? if you just have an empty tests/ dir does it still complain? | 18:06 |
| cargill | with tests/ empty it refuses to run before anything else | 18:08 |
| mgz | how about with a file in there that's basically a noop? | 18:08 |
| mgz | (I'm not actually sure where the test command in implemented or what it does exactly) | 18:09 |
| cargill | as soon as there is a file with +x: "ERROR environment is already bootstrapped" | 18:12 |
| cargill | but the environment does not exist anymore and juju destroy-environment local cannot really do anything: "ERROR state/api: websocket.Dial wss://10.0.3.1:17070/: dial tcp 10.0.3.1:17070: connection refused" | 18:13 |
| cargill | ok, the environment actually might partly be with destroying environments as well? If I set up another environment, then try to use it, I get the following http://pastebin.ubuntu.com/7001148/ | 18:19 |
| cargill | s/environment/problem/ | 18:20 |
| marcoceppi | dpb1: lgtm, I have another release of charm-tools landing before friday, this will be in that release | 18:24 |
| === timrc is now known as timrc-afk | ||
| cargill | I'll need to go soon, should I report this under juju-core or elsewhere? | 18:29 |
| lazyPower | marcoceppi: cargill is getting strange output from juju test, sounds like a charm-tools bug more so than juju right? | 18:33 |
| * marcoceppi reads scroll back | 18:33 | |
| lazyPower | cargill: i got a bit preoccupied. I'll continue working with vagrant and the current quickstart vagrant box. ping me when you're around next and i'll follow up | 18:33 |
| marcoceppi | lazyPower: cargill it looks like the version of juju you're using doesn't support the -y flag for destroy-environment | 18:34 |
| marcoceppi | butttt, you have 1.17.3 so.... | 18:34 |
| marcoceppi | not sure what is going on there. | 18:34 |
| marcoceppi | cargill: when you run juju test, use this combination instead `juju test -v -e another` | 18:36 |
| marcoceppi | and then post the output | 18:36 |
| cargill | marcoceppi: when I run "juju destroy-environment -y local" I get a failure and this "ERROR no CA certificate in environment configuration" | 18:37 |
| * marcoceppi makes sure there's no weird regression in 1.17.3 | 18:37 | |
| marcoceppi | cargill: interesting | 18:37 |
| cargill | with "juju destroy-environment -y --force another" two lines of "ERROR exit status 1" | 18:37 |
| cargill | after that "juju --debug test -e another" gives "ERROR cannot use 37017 as state port, already in use" | 18:38 |
| marcoceppi | cargill: can you file a bug against charm-tools about destroy-environment needs to continue even if the destroy command fails? | 18:38 |
| marcoceppi | cargill: oh | 18:38 |
| marcoceppi | try sudo juju destroy-environment | 18:38 |
| cargill | just one line of the same | 18:38 |
| cargill | and no change in juju test result/output | 18:39 |
| cargill | I can start over but that's what I've just done twice, so either I'm doing something wrong with the upgrade or somewhere else | 18:40 |
| cargill | and this is a vagrant box I've downloaded today as well to make sure nothing else is funky | 18:41 |
| marcoceppi | cargill: well, the upgrade goes from needing sudo to not needing sudo | 18:41 |
| marcoceppi | which is likely causing all sorts of permission issues | 18:41 |
| dpb1 | marcoceppi: excellent | 18:42 |
| === timrc-afk is now known as timrc | ||
| === psivaa is now known as psivaa-afk | ||
| cargill | well, what I've done: get the vagrant box running, install amulet, charm-tools, sudo destroy evn local, switch repo to /devel, upgrade juju, run juju test -e local, and only then started with all sorts of stuff | 18:44 |
| cargill | to try and get it running based on the error messages and suggestions here | 18:45 |
| marcoceppi | cargill: I think we may just need to use a fresh box that has 1.17 installed | 18:45 |
| marcoceppi | lazyPower: did you poke at that saucy->trusty cloudimg thing? just curious | 18:46 |
| lazyPower | I'm actually working that now | 18:46 |
| lazyPower | i have a new branch brewing on the vagrant repository for it | 18:46 |
| cargill | is there one for vagrant? I'm on debian and just debootstrapping ubuntu does not seem juju compatible, looks like it needs some upstart magic | 18:47 |
| cargill | and my init is not upstart | 18:47 |
| cargill | or maybe something with cgroups | 18:48 |
| === CyberJacob|Away is now known as CyberJacob | ||
| lazyPower | cargill: there's a juju quickstart vagrant image. I have a working unit for test execution that is homebrewed with veewee, the box size again is 801mb though | 18:48 |
| lazyPower | so its a hefty size hit for test execution, right now i'm working through getting our current quickstart image patched to work as a testing appliance so you dont need to leave your native OS for running quick tests during your devel cycle. | 18:49 |
| cargill | I don't mind the box size as long as it's happy with 1GiB of RAM, have only 4 available and just firefox is already hogging 1.5 of that :) | 18:50 |
| lazyPower | https://github.com/chuckbutler/juju-vagrant | 18:50 |
| lazyPower | i welcome all bugs, patches, complaints, etc. | 18:51 |
| lazyPower | its an active WIP | 18:51 |
| cargill | "STOP If you haven't installed charm-tools on your development machine": does that mean it needs an ubuntu host? | 18:52 |
| lazyPower | only if you want to use the generators | 18:52 |
| lazyPower | its for charm add tests | 18:53 |
| lazyPower | but not strictly required | 18:53 |
| cargill | so running this in $CHARM_DIR will start testing that charm, and if a debugger/shell/... kicks in during the test, I will be able to control that as well? | 19:01 |
| cargill | lazyPower: ok, I need to run now, the image is still downloading, so I'll see where it is in the morning, should be here until ~5 GMT tomorrow, is that still early morning for you? | 19:11 |
| lazyPower | It is. | 19:12 |
| lazyPower | however, my bnc catches all messages. so feel free to ping me here if you need anything. | 19:13 |
| lazyPower | and the github issue tracker works equally as well :) | 19:13 |
| cargill | ok, thanks for your help | 19:13 |
| lazyPower | anytime. Let me know how you get along with the box. it hasn't been tested on debian yet. | 19:13 |
| lazyPower | also, quick note, can you tell me what version of vagrant you will be using? | 19:14 |
| cargill | I just need to get going on the charm tests, which have been nothing but pain so far :) if this gets them going, I'll be glad to help getting it work | 19:17 |
| cargill | lazyPower: Vagrant 1.4.3 | 19:17 |
| lazyPower | cargill: i'm using it for my charm testing, which seems to be going well. So i'm happy to help you get them going. | 19:17 |
| lazyPower | awesome, thats recent | 19:17 |
| lazyPower | +1 should be g2g after the box is downloaded | 19:17 |
| cargill | +1? | 19:17 |
| lazyPower | it gets my stamp of approval | 19:18 |
| cargill | ah, great, see you | 19:18 |
| lazyPower | take care | 19:18 |
| lazyPower | marcoceppi: after running do-dist-upgrade (which took 22 minutes from start to finish in the box w/ 1gb of memory) - it seems to have solved the shared folder issue, however exporting the box yields a 1.9GB vmdk | 19:38 |
| marcoceppi | lazyPower: bahhhhh | 19:38 |
| lazyPower | so its not an ideal solution | 19:38 |
| dpb1 | Hi, in 1.17+, how can increase verbosity of the juju logging? It seems to leave out DEBUG now by default | 19:38 |
| lazyPower | seems like we are riding the right path with the build. I'm going to keep poking around until I find a way to reduce the overall size of that box. | 19:38 |
| lazyPower | i've found some scripts that will help trim it down and optimize it, but I dont thin ki'll get one as small as the cloud images unless someone wants to share the secret sauce | 19:39 |
| lazyPower | and we wont be waiting that long until the new cloud images get pressed for trusty, so it may just be beneficial to wait | 19:39 |
| marcoceppi | lazyPower: we should gang up on utlemming and find out when there will be trusty cloud images | 19:39 |
| lazyPower | rabble rabble rabble! | 19:39 |
| === cmagina_ is now known as cmagina | ||
| === freeflying_away is now known as freeflying | ||
| === freeflying_away is now known as freeflying | ||
| === zz_mwhudson is now known as mwhudson | ||
| === smoser` is now known as smoser | ||
| === hatch_ is now known as hatch | ||
| danob_ | i am getting this error "ERROR cannot get latest charm revision: charm not found in "/carh/path": local:precise/charmname" my charm do not have any revision file in it | 22:00 |
| danob_ | i am getting this with charm proof "I: relation website has no hooks" | 22:05 |
| danob_ | i do not need any relation | 22:06 |
| danob_ | can i make a charm with out any relation hook? | 22:06 |
| === CyberJacob is now known as CyberJacob|Away | ||
| danob_ | marcoceppi: https://bugs.launchpad.net/juju-core/+bug/1129319 will this bug resolve if i use hard link temporally | 22:14 |
| _mup_ | Bug #1129319: Local charm deployment not working if symlinks are used <juju-core:Fix Released by fwereade> <https://launchpad.net/bugs/1129319> | 22:14 |
| danob_ | _mup_: will hard link work? | 22:16 |
| danob_ | _mup_: hard link has the same problem (bug) | 22:22 |
| === danob_ is now known as danob | ||
| marcoceppi | danob: I think hardlinks should work | 22:24 |
| danob | marcoceppi: I just tried its not working :( | 22:25 |
| danob | marcoceppi: will this bug fix within next update? | 22:27 |
| marcoceppi | it's fix released, as of 1.13.0 | 22:27 |
| marcoceppi | so it should be working, if there's a regression a new bug should be opened | 22:27 |
| danob | marcoceppi: i am getting this "I: relation website has no hooks" with charm proof, is this is the reason? | 22:32 |
| marcoceppi | danob: no, the I is informational, saying you might need to have a hook, but it's not a blocker and can be ingored | 22:33 |
| danob | marcoceppi: hmm :) my juju-core version is 1.16.6 | 22:36 |
| danob | marcoceppi: then why i am getting this error "ERROR cannot get latest charm revision: charm not found in "/carh/path": local:precise/charmname" ? need help | 22:37 |
| === thumper is now known as thumper-gym | ||
| danob | marcoceppi: this is my debug output https://gist.github.com/anonymous/47255921f3d123f646e0 | 23:23 |
| marcoceppi | danob: does /home/danob/juju/localcharms/xxxx exist? where xxx is your charm? | 23:31 |
| danob | marcoceppi: yes my charm :) | 23:32 |
| danob | marcoceppi: it exists | 23:33 |
| danob | marcoceppi: i mean i am hiding my charm name by xxxx | 23:34 |
| danob | marcoceppi: though it just test charm | 23:36 |
| marcoceppi | danob: right, so is there a revision file in that charm? | 23:37 |
| danob | no | 23:37 |
| marcoceppi | OH | 23:37 |
| marcoceppi | danob: in localcharms, create a precise directory | 23:37 |
| marcoceppi | danob: then put the charm in that | 23:37 |
| marcoceppi | then run the command again | 23:37 |
| marcoceppi | that should fix it | 23:37 |
| danob | marcoceppi: ok | 23:38 |
| danob | marcoceppi: no getting same ERROR | 23:43 |
| marcoceppi | danob: create a revision file in the charm and put a 0 in it | 23:43 |
| danob | marcoceppi: my command is $juju deploy --repository=. local:oxrp | 23:43 |
| danob | ok | 23:43 |
| marcoceppi | and where is "." ? | 23:46 |
| marcoceppi | like . should be localcharms directory | 23:46 |
| danob | marcoceppi: yes it is in localcharm | 23:47 |
| danob | marcoceppi: revision file created in ixrp charm dir | 23:50 |
| danob | marcoceppi: inside it i place 0 | 23:51 |
| danob | marcoceppi: oh man it is working worked | 23:53 |
| danob | marcoceppi: thank you very much :) | 23:53 |
| danob | marcoceppi: thanks man :) | 23:53 |
| marcoceppi | danob: np, I'll file a bug that if there's not a revision file, juju should create one on first deploy | 23:54 |
| danob | marcoceppi: my first ixrp charm is deploying :) | 23:54 |
| danob | marcoceppi: yes report it, will be awesome | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!