=== CyberJacob is now known as CyberJacob|Away
=== StoneTable is now known as aisrael
=== nottrobin_ is now known as nottrobin
=== mbarnett` is now known as mbarnett
=== Guest18526 is now known as wallyworld
davecheneythumper: State.StateServingInfo checks for a StateServingInfo doc04:13
davecheneyor more specifically a doc that will marshal into that type04:13
davecheneythen checks if doc.Port == 0 and takes that as a not found signal04:13
davecheneyit does this because state.Open inserts an empty document into that collection ...04:13
thumperright ...04:14
davecheneythumper: can you think of a reason not to change this to04:15
davecheneynot insert the doc if there is nothing to insert04:15
davecheneythen use ErrNotFound as the sentital for the document not being found ?04:15
* thumper looks at it now...04:16
thumperI'm guessing because it is always expected to be there (for some value of there)04:18
thumpermakes it easy to set by just calling update04:18
thumperisn't there an Upsert?04:18
thumperdavecheney: I think with a change to use upsert, I think the behaviour could be changed04:27
davecheneyfuk this nosql bullshit04:27
davecheneyok, that'll have to stay as broken as it is today04:29
davecheneyfunc (st *State) SetStateServingInfo(info StateServingInfo) error {04:29
davecheney        if info.StatePort == 0 || info.APIPort == 0 ||04:29
davecheney                info.Cert == "" || info.PrivateKey == "" {04:29
davecheney^ we only consider these four fields to be important04:29
davecheneyany others can be nil and are not consdiered 'empty'04:29
thumperdavecheney: perhaps #juju-dev a better channel... users probably don't care :-)04:32
davecheneyi'm in there wrong channel04:38
=== uru_ is now known as urulama
=== CyberJacob|Away is now known as CyberJacob
=== urulama is now known as urulama-afk
=== jamespag` is now known as jamespage
pittihello all10:22
=== robinbowes is now known as yo61
pittidid anyone succeed with using juju-local in utopic? it was my third attempt this morning, and now it fails to build containers10:25
pittiI filed bug 1363832 this morning10:25
mupBug #1363832: [utopic] fails to build containers <amd64> <apport-bug> <utopic> <juju-core (Ubuntu):New> <https://launchpad.net/bugs/1363832>10:25
pittiI wonder if it's generally broken, or something on my system is special10:25
=== bloodearnest_ is now known as bloodearnest
=== gsamfira1 is now known as gsamfira
=== jam2 is now known as jam1
bloodearnesthas any one else observed juju invoking config-changed at random on a deployed environment?12:05
bloodearnestWe only noticed because it fails as a configured auth token has expired12:06
pittidid anyone succeed with using juju-local in utopic? it was my third attempt this morning, and now it fails to build containers14:03
pittiI filed bug 1363832 this morning14:03
mupBug #1363832: [utopic] fails to build containers <amd64> <apport-bug> <utopic> <juju-core (Ubuntu):New> <https://launchpad.net/bugs/1363832>14:03
pittiI wonder if it's generally broken, or something on my system is special14:03
htmljuju? i cant even figure out how to get it to work-ish14:05
=== html is now known as johnny_number_5
hazmatbloodearnest, at random?.. it gets called in a  few places14:44
hazmatbloodearnest, it called before start, and after upgrade, and whenever the config changes, and if the machine is rebooted.14:44
bloodearnesthazmat: as in, after a long period of no juju activity, with no human stimulus14:44
hazmatfwereade, ^14:45
bloodearnesthazmat: havn't been able to reliably reproduce14:45
bloodearnesthazmat: but I've seen it on local provider, and jjo's seen it a few times in prodstack14:45
hazmatpitti, i haven't seen that.. i filed a separate issue about the default containers defaulting to trusty (or more specifically latest lts) instead of precise.14:46
hazmatpitti, are there any other containers on the machine from juju? its hard to tell if its having issues starting the template container or the actual container14:47
pittihazmat: no, before there were only a few completely unrelated containers14:48
pittihazmat: it tried to create a juju-trusty-lxc-template but failed14:48
pittiI lxc-destroy'ed that after each failed attempt14:48
hazmati should really polish up my juju lxc scripts.. simplifies the interaction much more (nothing on the host).14:50
hazmatpitti, could you manually start the template container? ie lxc-start -d -n juju-trusty-lxc-template14:50
pittihazmat: well no, there is nothing in that container14:51
pittihazmat: it created a /var/log/juju/ (empty), and that's it14:51
hazmatpitti, that's strange.. the cloud image template might have some cache issues as well, if it also fails if you manually do lxc-create -t ubuntu-cloud -- -r trusty .. i'd try to clearing out the appropriate series dir in /var/cache/lxc14:52
pittihazmat: there is no other juju related contianer14:53
hazmatpitti, and re env settings.. you have juju get-env | grep lxc shows -> lxc-clone-aufs: false ?14:53
pittihazmat: so if juju deploy is supposed to merely clone an existing container, that would explain why it fails14:53
pittihazmat: but then bootstrap ought to have failed14:54
hazmatpitti, yup.. it setups a template container, and clones for the actual unit14:54
pitti(I pointed that out in the bug report -- bootstrap does *not* create any container)14:54
hazmatif your on btrfs.. it uses a snapshot automatically if /var/lib/lxc is btrfs14:54
pittino, plain ext414:54
hazmatpitti, yeah.. bootstrap does nothing14:54
pittiso where does the template container come from?14:54
pittiif bootstrap doesn't create it, and deploy expects it?14:54
hazmatpitti, its all async the first time a machine is requested needed14:54
hazmatpitti, deploy will do it inline14:54
hazmatthis is a long standing issue imo cause it has to download.. a full image and its doing it without giving feedback14:55
hazmatie. at min we should be showing more info on status when its doing stuff in the background for the image dl14:55
pittiwell, a "full image" is something like 60 MB or so?14:55
pittiat least that's the rough size of stgraber's pre-built LXC templates14:56
hazmatbootstrap can't quite do it, cause we don't know what series will need to be created14:56
pittithat should download in a minute; I waited > 10 mins14:56
pittihazmat: ok, thanks for explaining the workflow14:56
pittiI suppose I'll set it up again and this time just let it sit there for really long14:56
pittibut it showed a lot of error messages and there was no active process, it seemed quite dead/failed to me14:56
hazmatpitti, no.. its bigger.. ~220mb14:56
pittiuh, wow14:57
hazmatpitti, its the image off cloud-images.ubuntu.com its downloading .. not the mystery images off linux-containers.org14:57
pittiah, that; but even that just takes 3 mins or so for me14:57
hazmatpitti, you can see the image it downloads  @ /var/cache/lxc/cloud-$series per the ubuntu-cloud-template source14:58
hazmatpitti, the actual error message is the failure to start the container, so i'm wondering if you manually create a container does it work14:58
hazmatwith the ubuntu-cloud lxc template14:59
pittiok, /scratch/juju set up again, bootstrap is done14:59
pitti$ juju get-env | grep lxc14:59
pitticontainer: lxc14:59
pittilxc-clone-aufs: false14:59
pittihazmat: ^ FTR14:59
pittihazmat: I just changed root-dir and default-release, nothing else14:59
hazmatif the manual creating an lxc with the cloud template doesn't work, that's the primary issue and i'd suggest wiping /var/cache/lxc/cloud* as a likely cause.15:00
pittiso I don't have anything juju-ish in /scratch/lxc/ which15:00
pittijust my unrelated other containers15:00
* pitti runs juju deploy juju-gui15:00
pittithat exists and doesn't change size (185 MB)15:01
pitti/var/cache/lxc/cloud-precise/ubuntu-12.04-server-cloudimg-amd64-root.tar.gz also exists and doesn't change size (238 MB)15:01
fwereadebloodearnest, we do call config-changed on somewhat slim pretexts, but not *at random*15:02
pittihazmat: tail -f /scratch/juju/log/* doesn't show anything either15:02
pittiand ps aux no processses that are more recent than 2 hours ago15:03
pittiso something in the template container creation goes pear-shaped15:03
hazmatpitti, to sanity check can you manually create a container using the cloud template?15:03
pittihazmat: well, I'd need a cloud template container first :) (that's the very bug)15:04
pittihow do I craete that?15:04
pittifrom /var/cache/lxc/cloud-trusty/ubuntu-14.04-server-cloudimg-amd64-root.tar.gz15:04
hazmatsudo lxc-create -n myprecise -t ubuntu-cloud -- -r precise -S ~/.ssh/id_rsa.pub15:04
hazmatsudo lxc-start -d -n myprecise15:04
pittihazmat: no, see above -- there *is* no ubuntu-cloud container -- creating that is the thing that fails15:05
hazmatpitti, lxc has different templates for creating a container15:05
pittithe only thing that was created in all this was the empty juju-trusty-lxc-template15:05
hazmatpitti, per contents of /usr/share/lxc/templates/15:05
pittihazmat: ah sorry, ignore me15:05
pitticreate -t, not clone15:05
pittifailed to get https://cloud-images.ubuntu.com/query/precise/server/daily-dl.current.txt15:06
pittiThere is no download available for release=precise, stream=daily, arch=amd6415:06
pittihazmat: that smells like something then15:07
hazmatthat's wierd that link resolves15:07
hazmatand it should be defaulting to release stream not daily15:08
bloodearnestfwereade: at random == our perception :)15:09
hazmatoh.. i wonder if it goes to daily cause your on an unreleased.. smarts of some form15:10
hazmatpitti, it sounds like the bug may apply to the lxc templates then if the underlying lxc tools aren't working15:11
bloodearnestfwereade: other than after start/upgrade/reboot, or an actual honest-to-goodness config-change, are there any more scenarios that it might be?15:11
pittihazmat: reaading /usr/share/lxc/templates/lxc-ubuntu-cloud it seems to default to "tryreleased" and falls back to "daily" if that fails15:15
pitti$ ubuntu-cloudimg-query trusty released amd6415:16
pittifailed to get https://cloud-images.ubuntu.com/query/trusty/server/released-dl.current.txt15:16
pittihazmat: ^ that might explain it further15:16
pittiso that fails, and it falls back to "daily"15:16
hazmatpitti, that link resolves though..15:16
hazmatpitti, that link works for me15:17
hazmatpitti, as does the cli15:17
pittihazmat: yes, for me too (in the browser)15:17
* pitti adds a cloud-utils task then15:18
pittihazmat: does wget work for you?15:19
pittihazmat: it fails because the certificate can't be checked15:19
pittiand it's calling wget without --no-check-certificate (quite rightly so)15:19
fwereadebloodearnest, I *think* those should be the only cases (plus agent restart, not quite a reboot necessarily)15:20
fwereadebloodearnest, is it possible something's bouncing the agent?15:20
pittihazmat: ok, thanks muchly for your help! I'll go on prod our cloud folks15:20
bloodearnestfwereade: that sounds a likely candidate, will try to check next time it happens15:22
pittihazmat: if wget works for you on that URL, it'd be interesting if you are running trusty or utopic15:23
pittihazmat: wget does work for me in trusty, but apparently got stricter in utopic15:24
bloodearnestfwereade: what's the rationale behind running config-changed after reboot/restart?15:24
fwereadebloodearnest, heh15:24
fwereadebloodearnest, we don't track what version of the config you've seen15:25
fwereadebloodearnest, I have no idea what inspired that approach15:25
fwereadebloodearnest, but fixing it has not been especially high on my list15:25
hazmatpitti, cert issues on trusty then?15:26
hazmator perhaps tls negotiation15:26
pittihazmat: or wget just simply didn't default to checking the cert for https:// on trusty yet15:26
pittiwhich is more likely15:26
fwereadebloodearnest, (and since we *do* run it on reboot I worry a bit that not doing so will subtly break some charms that have accidentally come to depend on it)15:26
pittihazmat: I pinged smoser about it in #u-devel15:26
bloodearnestfwereade: ack, it was a bug in our charm that made us discover it, just wanted to know why it was happening15:27
pittihazmat: I hacked ubuntu-cloudimg-query and will now re-try juju15:27
* pitti also adds --no-check-certificate to the ubuntu-cloud LXC template and tries again15:32
pittihazmat: ah, now I have a juju-trusty-lxc-template, a running martin-local-machine-1, and we are as far as agent-state-info: 'hook failed: "install"'15:35
pittihazmat: that's a whole lot of progress :)15:35
hazmatpitti, awesome15:36
pittiapt-get install failed15:37
hazmatpitti, ugh.. dns issues in container?15:43
hazmatpitti, or are you getting checksum mismatch?15:43
pittiI wish it would contain apt's error messages15:43
hazmatpitti, lxc-attach -n your-container-name  && and apt-get install15:44
pittihazmat: yep, that's my next step15:44
hazmatpitti, actually better alternative15:44
hazmatis juju debug-hooks unit-name15:44
hazmatand then juju resolved --retry15:44
hazmat+ unit-name15:44
hazmatpitti, if you like your containers in clouds.. with across host networking.. this is something fun i put together over the weekend. http://bazaar.launchpad.net/~hazmat/charms/trusty/rudder/trunk/view/head:/readme.txt15:45
pitti# cat /etc/apt/apt.conf.d/42-juju-proxy-settings15:45
pittiAcquire::http::Proxy "";15:45
pittinow, that wouldn't work, my dear juju15:46
hazmatit should be pointing to the bridge address15:46
hazmatand now we're back to juju bugs ;-)15:47
pittihazmat: thanks for pointing out teh debug stuff15:48
hazmatpitti, np15:48
pittihazmat: filed and updated bug 136406915:49
mupBug #1364069: local provider must transform localhost in apt proxy address <amd64> <apport-bug> <utopic> <juju-core (Ubuntu):New> <https://launchpad.net/bugs/1364069>15:49
pittiresolved --retry still fails, but I need to run now; more tomorrow :)15:49
hazmatthats the one downside of using my own juju lxc scripts.. i don't get to experience the pain of local provider15:50
hazmatpitti, cheers15:50
=== utlemmin` is now known as utlemming
=== utlemming_away is now known as utlemming
=== utlemming_away is now known as utlemming
=== arosales is now known as roslaes
=== roslaes is now known as arosales
=== scuttle|` is now known as scuttlemonkey

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!