| _mup_ | juju/trunk r385 committed by kapil.thangavelu@canonical.com | 00:05 |
|---|---|---|
| _mup_ | merge unit-info-cli [r=fwereade,niemeyer][f=863816] | 00:05 |
| _mup_ | Allow units to obtain their public and private addresses in a provider | 00:05 |
| _mup_ | independent fashion | 00:05 |
| _mup_ | Bug #867991 was filed: local provider needs documentation <juju:In Progress by hazmat> < https://launchpad.net/bugs/867991 > | 00:09 |
| _mup_ | Bug #867993 was filed: Code/module docs seem to use "j" instead of juju <juju:New> < https://launchpad.net/bugs/867993 > | 00:12 |
| jimbaker | hazmat, here is the master-customize.log: http://pastebin.ubuntu.com/702511/ | 00:17 |
| jimbaker | i tried going against the latest in unit-info-cli, no changes i could see | 00:18 |
| hazmat | interesting | 00:18 |
| jimbaker | in terms of the log or juju status' | 00:18 |
| hazmat | jimbaker, what's the output of > host archive.ubuntu.com192.168.122.1 | 00:19 |
| hazmat | whoops space between those | 00:19 |
| hazmat | jimbaker, it looks like a network connectivity problem | 00:19 |
| jimbaker | hazmat, here's the output: http://pastebin.ubuntu.com/702516/ | 00:20 |
| hazmat | jimbaker, one more.. what's the output of sudo cat /var/lib/lxc/yourusername-yourenvname-0-template/rootfs/etc/resolvconf/run/resolv.conf | 00:21 |
| jimbaker | hazmat, nameserver 192.168.122.1 | 00:22 |
| hazmat | jimbaker, odd | 00:23 |
| hazmat | everything sounds like its correct | 00:23 |
| hazmat | jimbaker, aha | 00:23 |
| jimbaker | hazmat, ? | 00:23 |
| jimbaker | (if you want i can give you a login to this box) | 00:24 |
| hazmat | jimbaker, so oneiric is still in beta so old packages aren't per se kept around | 00:24 |
| hazmat | jimbaker, you'll need to update manually your lxc cache | 00:24 |
| jimbaker | hazmat, ok | 00:24 |
| hazmat | so it has the latest oneiric packages | 00:24 |
| hazmat | jimbaker, $ sudo chroot /var/cache/lxc/oneiric/rootfs-i386/ | 00:25 |
| hazmat | jimbaker, $ apt-get update && apt-get upgrade | 00:25 |
| hazmat | that should fix things, else the pkg cache was ref'ing non existant packages upstream i bet | 00:26 |
| jimbaker | ok, doing that, but against amd64 :) | 00:26 |
| * hazmat heads out for a dog walk | 00:26 | |
| hazmat | bbiab | 00:26 |
| jimbaker | hazmat, makes sense, this would explained those bad refs in master-customize.log | 00:26 |
| hazmat | jimbaker, also you can update your juju-origin to lp:juju/trunk if you want.. its all committed now | 00:27 |
| jimbaker | hazmat, sounds good | 00:28 |
| hazmat | jimbaker, that work for you? | 00:56 |
| niemeyer | hazmat: Man! | 01:14 |
| niemeyer | hazmat: wtf is happy with unit-get! | 01:14 |
| hazmat | niemeyer, :-) | 01:14 |
| * niemeyer dances around the chair | 01:14 | |
| hazmat | niemeyer, cool, i'm out going to go enjoy some down time | 01:14 |
| niemeyer | hazmat: Enjoy it :) | 01:15 |
| hazmat | niemeyer, sent out some mails to the list inviting additional local provider testing | 01:15 |
| niemeyer | I'm going down too | 01:15 |
| niemeyer | hazmat: Superbsome | 01:15 |
| * niemeyer => poweroff | 01:17 | |
| jimbaker | hazmat, hmmm, the upgrade was successful of the lxc cache. looks like i have a networking issue, the agent logs (which i finally have) just report zk errors about network is unreachable | 01:51 |
| jimbaker | (agent logs for mysql/0, wordpress/0) | 01:51 |
| jimbaker | the other detail is that the master-customize.log was not touched. is that only used in the event of an error? | 01:52 |
| jcastro | hazmat: oh nice, I'll try local/LXC as soon as the build is finished | 02:10 |
| jcastro | hazmat: I've been looking forward to this. | 02:10 |
| jcastro | anyone try the local provider? I'm having some problems getting the environment right | 02:49 |
| jimbaker | jcastro, i have tried the local provider several times, but yet to get it running | 02:52 |
| jcastro | I'm not even getting past the environments.yaml bits | 02:52 |
| jimbaker | jcastro, this is my environments.yaml for lxc: http://pastebin.ubuntu.com/702557/ | 02:54 |
| jimbaker | jcastro, for me it's failing in the network at this point | 02:55 |
| jcastro | "error: internal error Network is already in use by interface virbr0" | 02:56 |
| jcastro | look familiar? | 02:56 |
| jimbaker | jcastro, i have seen that. one thing to try (hate to tell you it) is to reboot your computer | 02:56 |
| jcastro | hah, awesome. | 02:56 |
| jimbaker | the initial lxc networking for whatever reason didn't come up properly until i did this | 02:57 |
| jimbaker | jcastro, before doing that, might as well make sure you upgrade the pkg cache | 02:57 |
| jimbaker | see above, approx 2.5 hours ago | 02:57 |
| jcastro | ah | 02:59 |
| jcastro | jimbaker: woo! status works | 03:00 |
| jimbaker | jcastro, cool, but the provisioning agent runs on your machine, so it's not indicative of the lxc bits | 03:01 |
| jimbaker | (other than using local of course) | 03:01 |
| jcastro | ah | 03:02 |
| jimbaker | i just got past that just now, the fragility was in the package cache | 03:02 |
| jcastro | they show up in status, but their state is still null | 03:02 |
| jimbaker | jcastro, do something like $ ps -ef | grep juju - verify you see unit agents for mysql/0 and wordpress/0 (or whatever stack you are attempting) | 03:04 |
| jcastro | doesn't look like it, just one for zookeeper itself, which I assume is the provisioning one | 03:05 |
| jimbaker | jcastro, yes, you will have one zookeeper instance as part of the provisioning setup | 03:07 |
| jimbaker | jcastro, so check for the existence of master-customize.log - this will be in the data dir, owned by root | 03:08 |
| jimbaker | jcastro, ideally you will have logs for each of service units there too, a container log (for lxc debugging) and the unit.log itself | 03:09 |
| jcastro | all the log dirs are empty | 03:09 |
| jimbaker | jcastro, ok, so you are seeing something else wrong (and i assume you did the reboot) | 03:10 |
| jcastro | yeah | 03:10 |
| jcastro | the bootstrap runs, completes, no errors | 03:10 |
| jcastro | jimbaker: ok heading to bed, openstack conf tomorrow, I will certainly try on the plane. :) | 03:12 |
| jimbaker | bootstrap really means nothing unfortunately - and status is less useful here | 03:12 |
| jimbaker | well, of node 0 | 03:13 |
| jcastro | yeah it looks like it thinks it's firing off things, but they're not happening | 03:13 |
| jcastro | at first I was like "wow, this is fast." | 03:13 |
| jcastro | but it doesn't appear to be actually doing anything, heh | 03:13 |
| jimbaker | i think it might actually be fast, but yeah, still waiting to get it to work | 03:13 |
| jimbaker | ok, enjoy the conf! | 03:13 |
| jcastro | i feel like we're close! | 03:13 |
| jimbaker | i think so too, there are some basic setup doc issues, possibly ones that can be scripted, to make it work, i suspect i just have one more to go through | 03:14 |
| hazmat | /me catches up | 03:20 |
| hazmat | surprised rebooting is needed | 03:20 |
| hazmat | jcastro, its all async same as other providers so its fast to execute commands | 03:21 |
| hazmat | but takes a few moments for reality | 03:21 |
| hazmat | jcastro, planes are probably a problem, network connectivity is needed for non cached package installs | 03:22 |
| hazmat | jimbaker, so the lxc cache update didn't solve the issue for you? | 03:24 |
| _mup_ | juju/remove-sec-grp-do-not-ignore-exception r383 committed by jim.baker@canonical.com | 03:25 |
| _mup_ | Merged trunk | 03:25 |
| hazmat | jimbaker, the master customize log is updated only after the complete run, u should use ps | grep lxc to verify that | 03:28 |
| hazmat | ps uax | 03:28 |
| hazmat | oh... no.. gluster acquired | 03:28 |
| _mup_ | juju/trunk r386 committed by jim.baker@canonical.com | 03:38 |
| _mup_ | merge remove-sec-grp-do-not-ignore-exception [r=niemeyer][f=863510] | 03:38 |
| _mup_ | Simplified logic for removing security groups to ensure any exceptions | 03:38 |
| _mup_ | are not ignored by being consumed by the Twisted reactor. | 03:38 |
| jimbaker | hazmat, i got further with the lxc cache update | 04:10 |
| jimbaker | but now i'm seeing this networking issue | 04:10 |
| jimbaker | hazmat, so in the unit.log files (in my case mysql/0, wordpress/0), i'm seeing this repeated: Network is unreachable | 04:14 |
| jimbaker | so something is wrong w/ the virtual network setup | 04:14 |
| xerxas | Hi all ! | 09:46 |
| xerxas | is juju well suited for my use case: | 09:46 |
| xerxas | I want to launch a complete infrastructure with 1 command, and service knowing one each other address | 09:46 |
| xerxas | and , also , I want to specify a list of packages to install on each nodes , and some sed commands | 09:47 |
| xerxas | is chef-solo better for doing this ? or cloudformation (I'm working on EC2) | 09:47 |
| TeTeT | xerxas: from my reading I think juju can do that for you - but keep in mind it is under development. Not sure if you want to base any production sites on it right now | 09:49 |
| xerxas | TeTeT: you mean, if I want to make live my infrastructure ? | 09:52 |
| xerxas | If I'm adding unit afterwards ? | 09:53 |
| TeTeT | xerxas: adding units should work nicely, if the charm allows for it. What is your schedule for going productive? | 09:53 |
| xerxas | now ;) | 09:54 |
| xerxas | what's the simplest way de provision ec2 infrastructure (not instances, but infrastructures !) | 09:55 |
| xerxas | cloud-init seems ok for instances, is cloud-formation the cloud-init of infrastructure ? | 09:55 |
| kim0 | xerxas: actually I'd say juju is exactly what you need, and is the simplest way going forward | 09:58 |
| kim0 | xerxas: it's just that it's alpha quality right now | 09:59 |
| xerxas | kim0: why ? | 09:59 |
| kim0 | because it does what you described :) | 09:59 |
| xerxas | kim0: I don't mind if it's alpha or not, if it boots my 3 instances, setup a rabbitmq on one , et create a config file on a second one containing my rabbitmq server ip address | 09:59 |
| xerxas | kim0: ;) | 09:59 |
| xerxas | kim0: this is maybe why I'm asking here ;) | 10:00 |
| xerxas | ahh , also, question , I tested juju ... but | 10:00 |
| xerxas | juju client, needs to be ubuntu , as juju "controller" and , juju booted intances ? | 10:00 |
| kim0 | xerxas: no client can be osx too | 10:00 |
| xerxas | by controller I mean the instance where zookeeper is installed | 10:00 |
| kim0 | or other linux | 10:01 |
| xerxas | kim0: nice, I'm running osx ;) | 10:01 |
| kim0 | cool | 10:01 |
| xerxas | but the rest needs to be ubuntu | 10:01 |
| kim0 | xerxas: I think it's available on some osx repo | 10:01 |
| kim0 | can't remmeber what osx folks use to install cli tools :) | 10:01 |
| xerxas | brew | 10:01 |
| kim0 | yes that's it | 10:01 |
| xerxas | and easy_install ;) | 10:01 |
| TeTeT | wasn't there fink back in the day? | 10:01 |
| TeTeT | which was a lot like apt | 10:01 |
| kim0 | think brew it is now | 10:02 |
| xerxas | TeTeT: fink is useless know | 10:02 |
| TeTeT | been 6 years since I worked with osx ... | 10:02 |
| xerxas | brew is git based, easy formula (which is metadata for building packages) writing , social ... | 10:02 |
| xerxas | been 6 years I had a ubuntu based desktop ;) | 10:03 |
| kim0 | xerxas: here is a rabbitmq charm: https://code.launchpad.net/~charmers/charm/oneiric/rabbitmq-server/trunk | 10:03 |
| xerxas | but never left ubuntu on the server ;) | 10:03 |
| kim0 | xerxas: good choice ;) | 10:03 |
| xerxas | and will never (you're doing good work , guys ! ) | 10:03 |
| xerxas | kim0: thx for the url | 10:03 |
| kim0 | xerxas: so one instance is rabbitmq, what are the other two ? | 10:03 |
| xerxas | some daemon I wrote in python consuming messages | 10:04 |
| kim0 | ah cool! | 10:04 |
| xerxas | one will have some lxc container | 10:04 |
| xerxas | containers | 10:04 |
| jamespage | morning - anyone tried using the LXC local provider yet? | 10:04 |
| kim0 | xerxas: sounds like a cool project! | 10:04 |
| xerxas | anyway, my python daemon have a configuration file and in that configuration file I have an ip address, the one of the rabbitmq server | 10:05 |
| xerxas | (more precisely, one of rabbitmq-s server, because we might have several of them ... ) | 10:05 |
| kim0 | xerxas: I'd love to write an article about that project when you get it running .. keep me in the loop :) | 10:05 |
| TeTeT | jamespage: it's on my plate for later this week | 10:09 |
| kim0 | TeTeT: is it already working fine ? | 10:19 |
| TeTeT | kim0: I don't know yet, this I why I'd love to test it | 10:33 |
| kim0 | yeah | 10:33 |
| * HarryPanda can't get local charm repositories working anymore | 11:14 | |
| hazmat | good morning | 11:15 |
| HarryPanda | `charm create test /root/charms && juju deploy --repository /root/charms/ local:test` = no dice | 11:16 |
| hazmat | HarryPanda, you need to use a series (like 'oneiric') as additional directory in the repository from the base to the charm.. | 11:17 |
| hazmat | HarryPanda, ie.. so looking at the example formulas that come with juju.. its examples/oneiric/wordpress | 11:18 |
| HarryPanda | aah, I haven't been keeping up with the changelog | 11:18 |
| hazmat | HarryPanda, yeah.. that was recent | 11:20 |
| * HarryPanda got confused about store.juju.ubuntu.com etc. | 11:20 | |
| hazmat | there was a mail out to the list about the chance | 11:20 |
| hazmat | HarryPanda, its basically a charm repository.. its not active yet | 11:20 |
| hazmat | HarryPanda, yeah.. its a bit confusing on the error message | 11:20 |
| hazmat | fwereade, ^ | 11:20 |
| hazmat | jamespage, haven't gotten any new feedback yet | 11:21 |
| jamespage | hazmat, hey - I had a go based on your posting to juju@l.u.c | 11:22 |
| hazmat | jamespage, cool, how'd it go? | 11:22 |
| jamespage | hit a few errors - the environments.yaml entry wanted a type and admin-secret entry as well ( so I had a guess) | 11:23 |
| hazmat | jamespage, doh.. yeah | 11:23 |
| hazmat | jamespage, late night emails.. bad | 11:24 |
| hazmat | jamespage, and then? | 11:24 |
| hazmat | jamespage, fwiw admin-secret is anything you want it to be | 11:24 |
| jamespage | I appear to have a running environment! | 11:25 |
| jamespage | I've not deployed anything yet - you caught me as I was typing juju bootstrap --environment.... | 11:25 |
| * HarryPanda is slowly getting our full stack running on a mix of vmware+orchestra, ec2 and lxc :) | 11:25 | |
| hazmat | jamespage, cool.. the real work happens when you first deploy a charm.. and it starts creating lxc containers.. | 11:26 |
| hazmat | HarryPanda, fun | 11:26 |
| jamespage | hazmat, OK about to try that | 11:27 |
| hazmat | jamespage, its async to the cli, so giving progress on it is a little hard, you can ps aux | grep lxc to watch it happen, or tail the log file in data-dir/machine-agent.log | 11:27 |
| jamespage | hazmat: hmm - not sure the machine agent started | 11:36 |
| jamespage | http://paste.ubuntu.com/702702/ | 11:38 |
| hazmat | jamespage, hmm.. haven't seen that one | 11:39 |
| hazmat | jamespage, can you try bootstrapping with the verbose flag? ie. juju -v bootstrap | 11:39 |
| hazmat | jamespage, that should give the traceback | 11:40 |
| HarryPanda | jamespage: I'm getting the same | 11:40 |
| HarryPanda | local/agent.py:59, changed JUJU_ORIGIN=%s to JUJU_ORIGIN=ppa | 11:40 |
| jamespage | hazmat: http://paste.ubuntu.com/702706/ | 11:41 |
| hazmat | dah | 11:41 |
| hazmat | foobar | 11:41 |
| hazmat | jamespage, thanks | 11:41 |
| jamespage | np - want me to raise a bug? | 11:41 |
| hazmat | jamespage, i think its a trivial, i can commit it to trunk, just double checking | 11:42 |
| hazmat | i was verifying this with a juju-origin defined in my environments.yaml.. but i didn't test without one | 11:42 |
| hazmat | yeah.. niemeyer mentioned he'd changed the interface on this function, but i forget | 11:43 |
| jamespage | hazmat: hmm - might also be better to depend on zookeeper rather than zookeeperd as the local provider starts its own instance | 11:46 |
| jamespage | saves a running java process which is always a good thing | 11:46 |
| hazmat | jamespage, good point.. libzookeeper-java should have what we need | 11:47 |
| jamespage | yep | 11:47 |
| jamespage | keen to test this as I have seen panics running Java stuff under lxc with openstack | 11:49 |
| jamespage | might disappear as a result tho :-) | 11:49 |
| hazmat | jamespage, we don't require any java under lxc.. but noted | 11:54 |
| hazmat | fwereade, http://paste.ubuntu.com/702712/ | 11:54 |
| hazmat | could i get a +1 on that trivial | 11:54 |
| jamespage | hazmat, well juju does not - but charms might... | 11:54 |
| hazmat | jamespage, yup | 11:55 |
| hazmat | no cassandra might hurt | 11:55 |
| * hazmat sheds a tear over gluster's acquisition | 11:55 | |
| HarryPanda | redhat? 0.o | 11:56 |
| fwereade | hazmat: sorry, I'm not quite following the paste | 11:59 |
| fwereade | hazmat: well, just the first bit | 12:01 |
| fwereade | hazmat: I guess, the packages need to change, so... you change the packages | 12:01 |
| fwereade | hazmat: consider my confusion withdrawn | 12:01 |
| fwereade | hazmat: +1 | 12:02 |
| hazmat | fwereade, yeah.. let me repaste.. the origin handling changed, but i made it to a branch copy by accident | 12:03 |
| jamespage | hazmat: getting there - I now have a running lxc container - however its not showing up as started yet | 12:06 |
| jamespage | I can log into it using SSH | 12:08 |
| hazmat | fwereade, updated diff.. http://paste.ubuntu.com/702715/ | 12:08 |
| hazmat | fwereade, does a couple of things, logs juju origin when starting machine agent, fixes the handling for juju origin to reflect new return signature from get_default_origin, changes the package dep from zookeeperd to libzookeeper-java | 12:09 |
| fwereade | hazmat: cool; have a much-happier +1 :) | 12:11 |
| HarryPanda | jamespage: what's the 'state' for the service unit? | 12:12 |
| jamespage | HarryPanda: null | 12:13 |
| jamespage | I can see the failsafe upstart configuration waiting for network interfaces to come up within the lxc instance | 12:13 |
| jamespage | http://paste.ubuntu.com/702719/ | 12:14 |
| _mup_ | juju/trunk r388 committed by kapil.thangavelu@canonical.com | 12:14 |
| _mup_ | [trivial] require libzookeeper-java not zookeeperd, update handling of get_default_origin, log origin used [r=fwereade] | 12:14 |
| hazmat | jamespage, interesting i never noticed that b4 re waiting for network within the container | 12:17 |
| hazmat | jamespage, sadly it happens on my laptop.. sort of destroys any value to making boot faster | 12:18 |
| hazmat | jamespage, the unit agent gets started via upstart.. it should have a symlink to its log at $data-dir/units/$unit-name/unit.log | 12:19 |
| hazmat | the link will be broken if the unit agent never started | 12:22 |
| hazmat | HarryPanda, where you get to with the origin=ppa change? | 12:24 |
| HarryPanda | hazmat: enough to get it working so I could deploy stuff | 12:25 |
| HarryPanda | I will re-checkout after lunch | 12:25 |
| hazmat | HarryPanda, cool, and you see the units with state: started in juju status? | 12:25 |
| hazmat | HarryPanda, cheers | 12:25 |
| hazmat | lxc-ls shows the containers, the output is a bit odd, it will list it twice if its running, once if its defined but not running | 12:26 |
| * hazmat regen's the ppa | 12:27 | |
| * HarryPanda still has a lot of catching up to do in the meantime, like puppet integration | 12:29 | |
| hazmat | jamespage, can you pastebin your $data-dir/units/master-customize.log | 12:31 |
| jamespage | hazmat: http://paste.ubuntu.com/702724/ | 12:36 |
| hazmat | jamespage, nice.. looks good | 12:37 |
| hazmat | jamespage, but your unit agents aren't starting? | 12:37 |
| jamespage | not within the instance | 12:38 |
| hazmat | jamespage, do you have any output in $data-dir/units/$unit-name/unit.log or is it a broken link? | 12:39 |
| jamespage | hazmat, broken link ATM | 12:40 |
| jamespage | this instance is stalled waiting for the network interface to start | 12:40 |
| jamespage | so I don't the right run-level has been initiated yet | 12:40 |
| hazmat | jamespage, if your able to ssh into the unit, you can try manually starting the agent using its upstart file as a guideline /etc/init/$unit-name-unit-agent.conf | 12:41 |
| hazmat | jamespage, hmm.. i haven't seen that one before re network start wait in the container, except on the host | 12:41 |
| * hazmat doesn't understand why oneiric is waiting on network config | 12:42 | |
| jamespage | hazmat: so I did a sudo start xxx on the unit agent | 12:42 |
| jamespage | now showing as started | 12:42 |
| hazmat | jamespage, cool | 12:43 |
| jamespage | hazmat; adding another unit has resulted in another stalled lxc instance - bah! | 12:43 |
| hazmat | humbug | 12:45 |
| hazmat | jamespage, had you used lxc before today?.. i'm just wondering if destroying the env, and clearing out the lxc cache would help /var/cache/lxc/oneiric/* | 12:46 |
| hazmat | its been at least week since i did that myself | 12:46 |
| jamespage | hazmat, hmm - I can try that | 12:46 |
| hazmat | jamespage, alternatively you can try manually chroot into the cache and upgrade it.. but if i remember the bug correctly its pretty temperamental wrt to package install/upgrade/removal | 12:47 |
| * hazmat will bbiab | 12:58 | |
| niemeyer | Morning all! | 13:01 |
| rog | niemeyer: hiya | 13:05 |
| jamespage | hazmat, looks like /etc/rcS.d/S07resolvconf is blocking - which is stopping the rest of the lxc instance from coming up OK | 13:12 |
| niemeyer | rog: Yo | 13:15 |
| niemeyer | jamespage: Hey James | 13:15 |
| niemeyer | jamespage: Very interesting ideas in your testing charms post | 13:15 |
| jamespage | niemeyer, morning | 13:15 |
| jamespage | thanks | 13:15 |
| niemeyer | jamespage: Still digesting them | 13:15 |
| jamespage | niemeyer, I did a bit of refactoring yesterday based of sabdfl's comments | 13:16 |
| niemeyer | jamespage: We have a test suite continuously running at wtf.labix.org ATM, and it made me ponder if we could do more there | 13:16 |
| jamespage | the charm-tester is now a bit more clever and less implicit | 13:16 |
| jamespage | niemeyer, that might be good | 13:16 |
| jamespage | niemeyer, whats driving the testing ATM? | 13:22 |
| niemeyer | jamespage: A few trivial scripts.. the whole thing is in lp:juju/ftests if you'd like to check it out | 13:22 |
| niemeyer | fwereade: ping | 13:26 |
| fwereade | niemeyer: pong | 13:26 |
| fwereade | niemeyer: it's turned out *much* easier than I expected | 13:26 |
| niemeyer | fwereade: Oh, that's so great to hear | 13:26 |
| niemeyer | fwereade: I went to sleep a bit concerned yesterday imagining if we'd have to go back | 13:27 |
| fwereade | niemeyer: didn't stop me trying to do it wrong earlier, ofc, but you should have a fresh MP in a short while | 13:27 |
| niemeyer | fwereade: Woohay! | 13:27 |
| fwereade | niemeyer: yeah, it's a great relief :) | 13:27 |
| fwereade | niemeyer: and then the auto-update on top of that should be almost trivial | 13:27 |
| fwereade | niemeyer: EOD or before | 13:28 |
| * fwereade crosses fingers | 13:28 | |
| niemeyer | fwereade: Superb.. I'm hopeful we can close down the client side for fixes only today still | 13:28 |
| niemeyer | SpamapS: ^ | 13:28 |
| jamespage | hazmat: so it looks like plymount --ping is hanging forever; hence why the failsafe config is kicking in | 13:32 |
| * jamespage scratches his head | 13:33 | |
| SpamapS | niemeyer: if you guys can give me the revision to upload I will start some builds and tests | 13:52 |
| niemeyer | SpamapS: Sounds great.. we just need the stuff fwereade is punching on right now | 13:53 |
| SpamapS | niemeyer: here is r381's build failures btw https://launchpadlibrarian.net/81962870/buildlog_ubuntu-oneiric-i386.juju_0.5%2Bbzr381-1juju1~oneiric1_FAILEDTOBUILD.txt.gz | 13:54 |
| hazmat | haven't seen those | 13:56 |
| hazmat | jamespage, lame.. dhcp should just work | 13:57 |
| jamespage | hazmat, I think it kinda is - however plymouth --ping is hanging when it tries to configure its logging | 13:57 |
| hazmat | jamespage, we can prepopulate resolvconf/resolv.conf.d/base like we did before but for the container startup, straight dhcp should just work | 13:57 |
| * hazmat does a man plymouth | 13:58 | |
| hazmat | hmm.. undocumented | 13:58 |
| hazmat | jamespage, so plymouth --ping sounds like it just pings upstart | 13:59 |
| hazmat | from its help | 13:59 |
| jamespage | its the thing that multiplexes all of the output from init scripts and upstart | 13:59 |
| * hazmat is out of his element | 13:59 | |
| hazmat | ah | 13:59 |
| jamespage | I've pinged hallyn_ - he might have some ideas esp. with regards to why its borked in a lxc container | 14:00 |
| hazmat | jamespage, great, just sent some updated instructions to the list and noted the plymouth hangs | 14:01 |
| * hazmat resets his lxc cache | 14:02 | |
| * hazmat really needs to find a 7mm ssd | 14:03 | |
| fwereade | niemeyer: about "breaking" changes | 14:20 |
| fwereade | niemeyer: it's ok to just commit something that will not work with existing agents deployed from an older branch... or is it? | 14:21 |
| niemeyer | fwereade: *TODAY* it is.. tomorrow, it's not. :-) | 14:21 |
| fwereade | heh, good :) | 14:21 |
| mdeslaur | hey guys, you should get the juju mailing list added here: https://lists.ubuntu.com/ | 14:22 |
| mdeslaur | it's kind of hard to find if you don't know what it's called | 14:22 |
| hazmat | mdeslaur, good point | 14:26 |
| _mup_ | Bug #868391 was filed: Juju mailing list should be listed on lists.ubuntu.com <juju:New> < https://launchpad.net/bugs/868391 > | 14:27 |
| hazmat | mdeslaur, at the moment the easiest way to find the ml is from the section at the bottom of juju.ubuntu.com | 14:27 |
| mdeslaur | hazmat: yes, thanks | 14:28 |
| niemeyer | rog: Great stuff indeed in update-server-interface man, thanks! | 14:33 |
| niemeyer | rog: I've sent a few comments/suggestions, but pretty superficial stuff | 14:33 |
| rog | niemeyer: good, i'm, erm, relieved you like it :-) | 14:33 |
| rog | don't you hate it when you know you've made some changes somewhere, but you can't find them anywhere? makes me wonder what else i'm also missing :-) | 14:37 |
| fwereade | niemeyer: how would you like really-isolate-formula-revisions? stacked branch on isolate-formula-revisions, both set to needs review? | 14:40 |
| hazmat | jamespage, works for me ootb with a clean lxc cache | 14:40 |
| hazmat | fwiw | 14:40 |
| hazmat | jcastro, ping | 14:40 |
| rog | niemeyer: ah, i've just realised that update-server-interface is several revisions ago. | 14:41 |
| niemeyer | rog: Well, please do the suggested changes in the version that is up for review, and let's merge it as is | 14:41 |
| niemeyer | rog: Then you can push a separate branch with the new content | 14:41 |
| rog | niemeyer: i thought you were reviewing factor-out-service ... | 14:41 |
| niemeyer | rog: Nope.. reviewing this now | 14:41 |
| niemeyer | rog: Please do the changes in the specific revision that was actually reviewed so we can merge it | 14:42 |
| rog | niemeyer: will do. | 14:42 |
| niemeyer | fwereade: Hmmm | 14:42 |
| niemeyer | fwereade: Not sure I understand your question | 14:42 |
| niemeyer | fwereade: You have a review on the previous branch.. what is happening with it? | 14:43 |
| fwereade | niemeyer: the trivials are fixed in that branch; the big one is fixed in the stacked branch | 14:43 |
| fwereade | niemeyer: the actual changes are trivial but widespread | 14:43 |
| fwereade | niemeyer: I'm just as happy to merge back into the original branch, or to add a new MP | 14:44 |
| fwereade | niemeyer: whatever's easiest for you to review | 14:44 |
| niemeyer | fwereade: Please just push it all on that single branch.. I'll have to review it jointly either way since the prior one has blockers without the follow up | 14:44 |
| fwereade | niemeyer: ok, cool | 14:44 |
| niemeyer | rog: Just added a [10] comment now that I've figured a detail in the follow up branch | 14:48 |
| rog | niemeyer: one thing that concerns me about doing kill(pid, 0) is that it's system-specific. but i guess we're tied to linux anyway. | 14:49 |
| niemeyer | rog: Yeah.. I'm not very concerned about WIndows to be honest :) | 14:50 |
| niemeyer | rog: The way to fix that would be to add something in the Process interface itself | 14:50 |
| niemeyer | rog: IsRunning or whatever | 14:50 |
| SpamapS | rog: server side linux is a good bet. clients may be OS X or something else. | 14:50 |
| niemeyer | rog: But that's not something I worry about myself.. I'll let the Windows folks worry about it | 14:51 |
| rog | this is client-side too, right? i'm also slightly concerned that some users may get EPERM even though the process is actually running. | 14:51 |
| rog | i'm not too au fait with modern unixy capability stuff | 14:52 |
| niemeyer | rog: If they get EPERM, that's great.. it's not their process and they shouldn't be fiddling with it | 14:59 |
| * rog nods. | 15:00 | |
| jamespage | hazmat: I have something to try - I have plymouth in debug mode on my laptop for another issue - might be causing problems | 15:04 |
| SpamapS | cd | 15:10 |
| rog | niemeyer: hmm, there's a problem with checking if server process is actually running: what do you do if the pid.txt file exists, but there's no running server? you'll have to remove or rewrite the pid.txt file, but then you no longer get the nice race-free create semantics that you've got currently, so two concurrent callers could start two servers at once. | 15:15 |
| fwereade | niemeyer: btw, https://code.launchpad.net/~fwereade/juju/isolate-formula-revisions/+merge/78164 is ready for another look | 15:17 |
| jamespage | hazmat: that fixed it - for some reason having plymouth:debug as a kernel boot options breaks the in-instance plymouth | 15:21 |
| niemeyer | fwereade: Ok, let me see how's lunch looking like here | 15:33 |
| niemeyer | fwereade: I'll review it either right now or right after lunch | 15:33 |
| niemeyer | rog: I don't get the problem.. if the pid file exists and there's no server running, there's simply no server running? | 15:34 |
| rog | niemeyer: yes, but there's a problem if two processes are both trying to start a server at the same time in the same directory | 15:34 |
| rog | niemeyer: currently that situation is dealt with fine | 15:34 |
| niemeyer | rog: One of them will fail because the port number won't be available | 15:35 |
| rog | niemeyer: but the wrong pid might end up in the pid file | 15:35 |
| hazmat | jamespage, awesome! | 15:36 |
| * niemeyer thinks | 15:36 | |
| rog | niemeyer: my current thought is that we should still return an error, but that the error should reflect our knowledge of whether the server is or isn't currently running | 15:36 |
| hazmat | kill(pid,0) should work on osx i would think | 15:37 |
| rog | hazmat: yeah, it should. | 15:37 |
| rog | hazmat: i was more thinking of windows. | 15:38 |
| hazmat | ah, i don't think anyone cares about that in practice for juju ;-) | 15:38 |
| niemeyer | rog: Please ignore the concurrency issues for now and just proceed as we discussed | 15:38 |
| rog | e.g. "server is currently running" vs "server was terminated abnormally. Remove /.../pid.txt to force a start" | 15:38 |
| niemeyer | rog: We can use actual file locking to sort the problem out, but that's really not for this branch | 15:39 |
| rog | niemeyer: oh yeah, another thought: does anyone use shared filesystems these days? | 15:39 |
| rog | niemeyer: 'cos that'll break it too. | 15:39 |
| niemeyer | rog: I don't know, but that's not a problem to worry about now either | 15:40 |
| hazmat | niemeyer, latest tip should work with the go branches in review? | 15:41 |
| niemeyer | hazmat: It should | 15:44 |
| * hazmat compiles tip and dives in for a review | 15:44 | |
| niemeyer | fwereade: Ok, I'll have lunch before finishing your review.. will be back ASAP and dive into it directly | 15:52 |
| fwereade | niemeyer: cool, the auto-upgrade itself is simple, and works AFAICT, but testing it is a bit tedious | 15:52 |
| hazmat | fwereade, should be much faster with local provider ;-) | 15:53 |
| fwereade | hazmat: it's just *writing* the tests that's bugging me :) | 15:53 |
| hazmat | fwereade, ah | 15:54 |
| jimbaker | hazmat, i tried the latest (trunk r388), still seeing the same networking issues | 15:55 |
| jimbaker | i'm going to just reboot this box and see if that helps | 15:55 |
| hazmat | jimbaker, yeah.. bcsaller is as well | 15:55 |
| hazmat | jimbaker, rebooting won't do anything for this | 15:55 |
| bcsaller | hazmat: last I heard that was about virbr0 errors for jimbaker, thats not what I'm getting | 15:56 |
| jimbaker | hazmat, ok, it was the ultimate solution for the first time, but definitely welcome any ideas | 15:56 |
| hazmat | i'm clearing out my apt-cacher-ng cache, and trying again, already cleared out the lxc cache and it worked fine.. so afaics i shouldn't have anything cached localy | 15:56 |
| hazmat | jimbaker, your not getting virbr0 errors anymore are you? | 15:56 |
| jimbaker | hazmat, no | 15:56 |
| hazmat | bcsaller, so i cleared out lxc cache, apt-cacher-ng cache, and it works for me.. | 15:57 |
| jimbaker | i'm just getting network connectivity issues between the lxc instances (mysql/0, wordpress/0) and zk | 15:57 |
| SpamapS | hazmat: we may want to add a juju-local-dev metapackage with all those extra deps | 15:57 |
| hazmat | SpamapS, perhaps.. bootstrap will fail and tell you whats missing though | 15:57 |
| bcsaller | hazmat: yeah, thats expected, right. Its stale cached data that makes the issue | 15:57 |
| SpamapS | hazmat: think upgrades | 15:58 |
| SpamapS | hazmat: if we add more of those, or don't need more of those, we can help users add/remove them automatically :) | 15:59 |
| hazmat | SpamapS, yeah.. but that puts the extra dep everywhere | 15:59 |
| hazmat | SpamapS, including machines deploying units | 15:59 |
| hazmat | SpamapS, ie require java ;-) | 15:59 |
| hazmat | i'd rather avoid that | 16:00 |
| SpamapS | hazmat: which is why we put it as juju-local-dev, which is only a Suggests of juju | 16:00 |
| hazmat | SpamapS, ah. true that, yeah.. that sounds fine to me.. i think niemeyer objected last time around on that, but if your up for doing it.. sounds good | 16:01 |
| SpamapS | hazmat: its a distro choice really. :) | 16:01 |
| hazmat | SpamapS, well then i leave it to some anonymous distro person ;-) | 16:02 |
| jamespage | slightly frustratingly my local lxc instances are not picking up any dns resolvers... | 16:12 |
| jamespage | weird | 16:12 |
| bcsaller | hazmat: ^^ | 16:12 |
| hazmat | bcsaller, why would dnsmasq need to be specified explicitly in the container if its dhcp based | 16:17 |
| bcsaller | hazmat: maybe if the resolvconf package isn't installed, I don't know the details, it might be a matter of competing systems there | 16:18 |
| hazmat | bcsaller, so what do you have in resolv.conf of the master template? | 16:18 |
| koolhead17 | SpamapS: hey | 16:21 |
| jimbaker | hazmat, finally the lxc containers came up after cleaning the caches (i assume /var/cache/lxc, /var/cache/apt-cacher-ng), but i'm still getting Network is unreachable in the unit logs: http://pastebin.ubuntu.com/702840/ | 16:24 |
| niemeyer | fwereade: Diving in again | 16:25 |
| hazmat | jimbaker, do you have zookeeper running in the host? | 16:27 |
| hazmat | sounds like it on a different port then what the unit agents expect | 16:28 |
| jimbaker | hazmat, it was started by the local provider | 16:29 |
| jimbaker | with this setting: clientPort=53699 | 16:30 |
| hazmat | interesting | 16:34 |
| hazmat | jimbaker, what ip address does the lxc instance have? | 16:34 |
| hazmat | lxc-ls .. grab container name.. and ping dnsmasq... host container-name 192.168.122.1 | 16:35 |
| hazmat | jamespage, what do you end up with in resolv.conf of the container? is it empty? | 16:40 |
| jamespage | hazmat, it had the resolvconf header but no configuration | 16:40 |
| hazmat | bcsaller, yeah.. perhaps we need both | 16:41 |
| hazmat | i find it extremely odd that we don't pick up the dns server from dhcp | 16:41 |
| jimbaker | hazmat, not clear what you mean here... | 16:41 |
| hazmat | jimbaker, the container has an ip address, the easiest way to discover it (if the unit agents aren't connecting) is to query the dnsmasq with the container name | 16:42 |
| jimbaker | i have consulted the man page/other howtos on dnsmasq. in any event, i can see the containers with lxc-ls | 16:43 |
| jimbaker | hazmat, ok, i was getting confused about things ;) just use standard tools | 16:44 |
| jimbaker | hazmat, do we actually setup dnsmasq with the local provider? | 16:45 |
| hazmat | jimbaker, no its from libvirt | 16:45 |
| hazmat | i need to grab some lunch | 16:45 |
| hazmat | bcsaller, i guess the way to verify re dns is to add it to both run/resolv.conf and resolv.conf.d/base | 16:46 |
| hazmat | bbiab | 16:46 |
| jimbaker | hazmat, i do have dnsmasq running. in any event, we can debug more when you get back | 16:46 |
| niemeyer | hazmat: Please ping me when you're bakc | 16:49 |
| niemeyer | SpamapS: ping | 16:49 |
| niemeyer | fwereade: ping | 16:59 |
| fwereade | niemeyer: pong | 16:59 |
| niemeyer | fwereade: Looks fantastic | 17:00 |
| niemeyer | fwereade: I'm pretty surprised as well | 17:00 |
| fwereade | niemeyer: yeah, totally unexpected | 17:00 |
| niemeyer | fwereade: We should try to get a +1 from hazmat as well given this is such a core concept | 17:01 |
| niemeyer | fwereade: I have just a few trivials for you meanwhile | 17:02 |
| fwereade | niemeyer: sounds good; sounds good | 17:02 |
| niemeyer | fwereade: Sent | 17:03 |
| fwereade | niemeyer: cheers | 17:03 |
| niemeyer | fwereade: Is there anything else in the pipe I can help you with while you take a look at these? | 17:03 |
| fwereade | niemeyer: try previewing lp:~fwereade/juju/always-upgrade-local | 17:04 |
| fwereade | niemeyer: just pushed it | 17:04 |
| niemeyer | fwereade: I'm on it | 17:04 |
| fwereade | niemeyer: pretty sure it works, was just setting up a local provider to try to verify a bit faster | 17:04 |
| niemeyer | fwereade: Awesome | 17:04 |
| fwereade | niemeyer: re: caching in a private attribute, the idea was that CharmDirectory instances should still report the correct revision even if they're up-revisioned mid-flow | 17:09 |
| fwereade | niemeyer: on balance, that might not actually be necessary | 17:09 |
| fwereade | niemeyer: because that *should* only happen via set_revision (or at __init__ time) | 17:09 |
| niemeyer | fwereade: Yeah, I think that's the exception, so I'd rather delay the behavior until necessary | 17:10 |
| niemeyer | fwereade: Opening the file all the time feels bad given we don't depend on this behavior today | 17:10 |
| fwereade | niemeyer: in which case... yep, I'll just call it once, will simplify everything I think | 17:11 |
| fwereade | niemeyer: cheers | 17:11 |
| fwereade | niemeyer: others look good, ta | 17:11 |
| niemeyer | fwereade: Thanks! | 17:11 |
| niemeyer | fwereade: http://paste.ubuntu.com/702861/ | 17:18 |
| fwereade | niemeyer: [1] yep, clearer | 17:19 |
| fwereade | niemeyer: [2] ambivalent; I'm not sure local bundles are common enough to be a major worry | 17:20 |
| fwereade | niemeyer: it feels like the same class of issue as "what if the local repo is not writable" | 17:21 |
| niemeyer | fwereade: They're not.. but if we don't take care of this case, it'll explode and render upgade-charm non-useful with bundles | 17:21 |
| fwereade | niemeyer: hm, true | 17:21 |
| niemeyer | fwereade: Different case, I think | 17:21 |
| fwereade | niemeyer: fair enough | 17:22 |
| fwereade | niemeyer: offhand, is there a non-isinstance way to tell the difference? | 17:22 |
| niemeyer | fwereade: Nope, I think isinstance is the way to go | 17:27 |
| kim0 | hey folks .. is this plymouth thing blocking local deployment, do can I play already | 17:29 |
| kim0 | lxc deployment I mean | 17:29 |
| hazmat | /me is back | 17:44 |
| hazmat | niemeyer, ping | 17:44 |
| hazmat | fwereade, so the charms have revision directly on them now.. the callback into the metadata stuff was wierd.. | 17:44 |
| * hazmat checks out the branch latest | 17:45 | |
| hazmat | kim0, try it out | 17:48 |
| kim0 | cool will | 17:48 |
| hazmat | kim0, it was a issue to jamespage setup he had plymouth in debug mode | 17:49 |
| fwereade | hazmat: yeah, the idea was to avoid changing the charm state format | 17:53 |
| fwereade | hazmat: turns out, revision was never actually used from charm state | 17:53 |
| fwereade | hazmat: (well, it was, but it came from charm_url, and we only touched metadata.revision to assert they were the same) | 17:53 |
| hazmat | fwereade, cool | 17:54 |
| hazmat | fwereade, so the branch looks good to me, the only thing is the file contents should be stripped before attempting to int() | 17:54 |
| hazmat | fwereade, if people hand edit it, editors are want to do wonky things | 17:55 |
| fwereade | hazmat: >>> int(" \t27\n \r\n ") | 17:55 |
| fwereade | 27 | 17:55 |
| fwereade | hazmat: but still, no actual dsagreement | 17:56 |
| hazmat | interesting | 17:56 |
| fwereade | hazmat: explicit has occasionally been postulated to be superior to implicit, after all ;) | 17:56 |
| hazmat | i definitely remember that not working at some point | 17:56 |
| hazmat | oh well, relic of the past | 17:57 |
| fwereade | so, hazmat, can I count that as an approve? | 18:04 |
| hazmat | fwereade, yeah.. i'm just wondering about the extra zipfile construction in get revision on the bundle, i guess its fine since its cached, but we have the zip file already in init | 18:04 |
| hazmat | fwereade, +1 | 18:05 |
| fwereade | hazmat: and we always call get_revision in __init__, too | 18:05 |
| fwereade | hazmat: I'll just fix that and merge then | 18:05 |
| fwereade | hazmat: cheers | 18:05 |
| hazmat | fwereade, cool | 18:06 |
| niemeyer | Woohay | 18:11 |
| rog | see y'all tomorrow | 18:15 |
| hazmat | rog have a good one | 18:17 |
| niemeyer | rog: Cheers! | 18:19 |
| niemeyer | fwereade: I'm writing an email to the list warning about this change | 18:21 |
| fwereade | niemeyer: tyvm | 18:25 |
| jimbaker | hazmat, so i just wanted to continue with you on the local provider debugging | 18:30 |
| jimbaker | hazmat, whenever it's a good time, just ping me | 18:30 |
| niemeyer | fwereade: Hey! | 18:31 |
| niemeyer | fwereade: One thought just occurred to me | 18:31 |
| fwereade | niemeyer: go on | 18:31 |
| niemeyer | fwereade: While writing the email | 18:31 |
| niemeyer | fwereade: Rather than erroring out with a missing revision file, we should create one with revision 1 automatically | 18:31 |
| niemeyer | fwereade: In a charm directory | 18:32 |
| fwereade | niemeyer: good plan | 18:32 |
| fwereade | niemeyer: 0 maybe? | 18:32 |
| niemeyer | fwereade: Sounds good.. I'm a fan of zero indexing as well ;-) | 18:32 |
| fwereade | niemeyer: or is that just too look-at-me-I'm-a-*programmer*? | 18:32 |
| niemeyer | fwereade: LOL | 18:32 |
| niemeyer | fwereade: Maybe.. but memory initialized to zero by default is such a great idea! I'm sure we can't go wrong in this case either. ;-D | 18:33 |
| fwereade | niemeyer: anyway, sounds good, I'll pastbin you a trivial shortly, just fixing up the always-upgrade-local branch | 18:33 |
| hazmat | i thought it was backwards compatible already? | 18:40 |
| hazmat | only on invalid content of the metadata file would it error | 18:41 |
| hazmat | jimbaker, ping | 18:44 |
| fwereade | niemeyer: http://paste.ubuntu.com/702915/ | 18:46 |
| niemeyer | hazmat: It's backwards compatible, but it's a significant change in structure that deserves a ntoe | 18:46 |
| niemeyer | note | 18:46 |
| fwereade | hazmat: it is backwards compatible; this is a distinct case, where you create a charm and never even consider the possibility of needing a revision | 18:47 |
| hazmat | sounds good | 18:47 |
| niemeyer | hazmat: Otherwise people will get a crazy warning that makes no sense after an unknown point in time | 18:47 |
| jimbaker | hazmat, hi | 18:47 |
| niemeyer | fwereade: Hmmm.. that's not quite it I think | 18:48 |
| niemeyer | fwereade: There's an important difference between a revision file not being present and it containing unexpected content | 18:48 |
| hazmat | yeah | 18:48 |
| fwereade | niemeyer: ...very good point | 18:48 |
| * fwereade looks shifty | 18:49 | |
| hazmat | its more of a preamble to the method if not os.path.exists(revision_path) | 18:49 |
| niemeyer | fwereade: Don't worry.. you can look shifty for the next few months without any damage to your image given how late it is there and how much you've been pushing :) | 18:49 |
| hazmat | jimbaker, so to continue the epic, our heroes where last trying to figure out why they couldn't get to the zoo | 18:49 |
| niemeyer | LOL | 18:50 |
| hazmat | fwereade, and it also has to play nice with the backwards compatible stuff, ie. what might already be in the metadata | 18:50 |
| * niemeyer puts that in the quotes page | 18:50 | |
| hazmat | fwereade, bringing shifty back into style ;-) | 18:51 |
| fwereade | :D | 18:51 |
| hazmat | jimbaker, where you able to get the container address? | 18:51 |
| jimbaker | hazmat, not certain what the procedure for that should be | 18:52 |
| hazmat | jimbaker, query the dnsmasq server | 18:52 |
| hazmat | jimbaker, is it running? | 18:52 |
| hazmat | bcsaller, where you able to try out adding the dnsmasq server to base in addition to run/resolv.conf? | 18:52 |
| jimbaker | hazmat, dnsmasq is running | 18:52 |
| jimbaker | hazmat, with this range reported from ps, --dhcp-range 192.168.122.2,192.168.122.254 | 18:53 |
| jimbaker | so that looks as expected | 18:53 |
| hazmat | jimbaker, lxc-ls -> list of containers.. pick container name of unit... query dnsmasq on its listen address typically 192.168.122.1 | 18:53 |
| jimbaker | hazmat, hmm, i missing something in my knowledge of how something like this is setup; would the query be like this: dig -b 192.168.122.1 jbaker-desktop-wordpress-0 | 18:55 |
| jimbaker | (yes, its listen address is 192.168.122.1, according to ps) | 18:55 |
| hazmat | dig @192.168.122.1 jbaker-desktop-wordpress-0 | 18:56 |
| hazmat | or less verbosely | 18:56 |
| hazmat | host jbaker-desktop-wordpress-0 192.168.122.1 | 18:57 |
| jimbaker | hazmat, now makes perfect sense, but dnsmasq doesn't have the address: http://pastebin.ubuntu.com/702926/ | 18:59 |
| fwereade | hazmat, niemeyer: http://paste.ubuntu.com/702927/ | 18:59 |
| fwereade | slightly less trivial now but just barely qualifies IMO | 19:00 |
| hazmat | fwereade, that seems sensible.. basically only in the absence of revision set it | 19:01 |
| hazmat | i was wondering about transparently doing migrations for folks, but that's probably icky, they'll see the warning | 19:02 |
| hazmat | fwereade, +1 | 19:02 |
| niemeyer | fwereade: Put this within the try: if result >= 0:\n return result | 19:03 |
| niemeyer | fwereade: as a follow up you'll notice you can unify the branches | 19:03 |
| hazmat | jimbaker, odd indeed. what's the output of > brctrl show and virsh net-list --all | 19:03 |
| hazmat | jimbaker, its like you have a different bridge setup | 19:03 |
| niemeyer | fwereade: It all looks good though, +1 | 19:04 |
| hazmat | jimbaker, for any active on virsh net-list.. can you paste virsh net-dumpxml network-name | 19:04 |
| jimbaker | http://pastebin.ubuntu.com/702932/ | 19:05 |
| jimbaker | hazmat, i don't have brctrl installed. is that a problem? | 19:05 |
| fwereade | niemeyer: re try: in get_revision? | 19:05 |
| niemeyer | fwereade: yeah | 19:05 |
| jimbaker | in terms of not having some useful bridging utils installed? | 19:05 |
| fwereade | niemeyer: that won't error on revisions < 0 | 19:05 |
| hazmat | jimbaker, no its just a bridge management tool.. | 19:06 |
| hazmat | although i thought libvirt used it | 19:06 |
| jimbaker | hazmat, just checking ;) | 19:06 |
| niemeyer | fwereade: It will if you tweak the branches below | 19:06 |
| jimbaker | hazmat, definitely could install bridge-utils shortly | 19:06 |
| niemeyer | fwereade: You'll need a single raise and won't have to define the spurious message upfront | 19:06 |
| fwereade | niemeyer: ...oh, *branches*, not branches | 19:06 |
| hazmat | jimbaker, do you have libvirt-bin installed? | 19:06 |
| niemeyer | fwereade: LOL | 19:06 |
| * fwereade looks shifty again | 19:06 | |
| niemeyer | fwereade: Yeah, sorry :-) | 19:06 |
| hazmat | jimbaker, bridge-utils is a dep of it | 19:06 |
| jimbaker | hazmat, i do, but apparently an upgrade is available | 19:07 |
| jimbaker | hazmat, enjoying the oneiric edge for sure | 19:07 |
| hazmat | jimbaker, right.. but you should have brctrl.. its a dependency for libvirt-bin | 19:07 |
| jimbaker | hazmat, certainly strange | 19:07 |
| jimbaker | hazmat, the upgrade of libvirt-bin did not install bridge-utils/brctrl, so don't know why the dependency is not being honored (or different here) | 19:09 |
| jimbaker | hazmat, sorry, it was just suggesting bridge-utils be installed for missing brctrl, but i do have it | 19:10 |
| jimbaker | (the bridge-utils package) | 19:10 |
| hazmat | jimbaker, okay... so output of brctrl show would be helpful... also do you have other virtualization packages (vmware, virtualbox, etc) on the machine? | 19:11 |
| jimbaker | hazmat, no other virtualization installed on this box | 19:11 |
| hazmat | jimbaker, cool | 19:11 |
| jimbaker | hazmat, still looking for a package with brctrl | 19:11 |
| hazmat | jimbaker, so the brctrl output and the virsh net-dumpxml default output are next | 19:11 |
| hazmat | jimbaker, sorry its brctl | 19:12 |
| jimbaker | hazmat, virsh net-dumpxml default: http://pastebin.ubuntu.com/702935/ | 19:12 |
| jimbaker | hazmat, brctl show: http://pastebin.ubuntu.com/702936/ | 19:13 |
| hazmat | jimbaker, so all that looks good.. time to check the container config | 19:14 |
| jimbaker | hazmat, sounds good | 19:15 |
| fwereade | niemeyer: and at last: https://code.launchpad.net/~fwereade/juju/always-upgrade-local/+merge/78306 | 19:15 |
| hazmat | jimbaker, can you pastebin sudo cat /var/lib/lxc/jbaker-desktop-wordpress-0/config | 19:15 |
| fwereade | niemeyer: already addressed the points you brought up before | 19:15 |
| niemeyer | fwereade: Cool, looking! | 19:16 |
| jimbaker | hazmat, here is is: http://pastebin.ubuntu.com/702937/ | 19:16 |
| niemeyer | Oops | 19:18 |
| niemeyer | fwereade: http://wtf.labix.org/ | 19:19 |
| niemeyer | fwereade: Looks like it never came up.. not sure if it's a hiccup or if it's actually broken for unknown reasons | 19:20 |
| niemeyer | I'll kick it and run it again | 19:20 |
| fwereade | niemeyer: blech, I'll verify here | 19:21 |
| niemeyer | fwereade: +1 on the change | 19:23 |
| niemeyer | fwereade: 390 is already on the pipeline running | 19:30 |
| niemeyer | fwereade: Let's see.. | 19:30 |
| fwereade | niemeyer, something is screwed up, the cloud-init scripts fall over | 19:33 |
| fwereade | niemeyer, but I don't *think* this was me... | 19:33 |
| fwereade | 2011-10-05 19:24:02,144 - cc_apt_update_upgrade.py[WARNING]: Failed to install packages: ['bzr', 'byobu', 'tmux', 'pyt | 19:34 |
| fwereade | hon-setuptools', 'python-twisted', 'python-argparse', 'python-txaws', 'python-zookeeper', 'default-jre-headless', 'zoo | 19:34 |
| fwereade | keeper', 'zookeeperd'] | 19:34 |
| fwereade | niemeyer: I'm seeing a lot of 403s trying to talk to http://us-east-1.ec2.archive.ubuntu.com | 19:35 |
| hazmat | jimbaker that's just wacky | 19:36 |
| jimbaker | hazmat, how so? ;) | 19:36 |
| hazmat | jimbaker, everything looks good | 19:36 |
| jimbaker | hazmat, ahh. maybe i should try the reboot. just this once | 19:36 |
| fwereade | niemeyer: does that sound familiar in any way? | 19:36 |
| hazmat | reboot is for windows and kernel upgrades (/me shake fist at oracle for buying ksplice) | 19:37 |
| jimbaker | hazmat, i know, i know | 19:37 |
| niemeyer | fwereade: I've heard something about a name change yeah | 19:37 |
| niemeyer | fwereade: What's strange is that the wtf broke in that specific revision | 19:37 |
| fwereade | niemeyer: theories regarding what I did received gratefully... :/ | 19:38 |
| jimbaker | it's an act of desperation. but is everyone else who's tried the local provider seen it work? | 19:38 |
| hazmat | jimbaker, not afaik, i think jamespage and bcsaller had it fail on a different network issue (dns wasn't working) | 19:39 |
| niemeyer | fwereade: The previous revision looks suspicious | 19:39 |
| niemeyer | fwereade: 388 | 19:39 |
| niemeyer | fwereade: But that'd mean something in wtf got the revision wrong somehow | 19:39 |
| niemeyer | fwereade: Which isn't impossible | 19:39 |
| bcsaller | hazmat: I'm testing a small diff to juju-create that I think fixed everything here | 19:39 |
| hazmat | bcsaller, writing both base and run/resolv.conf ? | 19:40 |
| fwereade | niemeyer: hm, that went in a good while ago, and all it hits is providers.local... I thought unused providers weren't even imported? | 19:40 |
| bcsaller | hazmat: yeah, http://pastebin.ubuntu.com/702946/ w/ the apt-get update after the cache is in place | 19:41 |
| niemeyer | fwereade: True.. | 19:41 |
| niemeyer | fwereade: It could be something in Oneiric itself too | 19:42 |
| niemeyer | fwereade: I'll rollback wtf to 388, and make it test everything again from there | 19:42 |
| fwereade | niemeyer: cheers | 19:42 |
| hazmat | bcsaller, that's slightly dangerous.. if the environment is long running, it will hit the same problem during a beta cycle.. but ok | 19:42 |
| niemeyer | fwereade: If 388 changes to broken, it might not be your revision | 19:42 |
| * fwereade feels slightly hopeful | 19:42 | |
| niemeyer | fwereade: Your merge log message are not following the convention, btw | 19:43 |
| hazmat | bcsaller, its bewildering though to me, its like dhcp isn't being respected, we shouldn't have to manuall setup dns for a dhcp setup | 19:43 |
| niemeyer | fwereade: Do a "bzr log" on trunk to see the difference | 19:44 |
| bcsaller | hazmat: I haven't verified it resolvconf is messing that up, /etc/dhcp/dhclient-enter-hooks.d/resolvconf makes me think it should be working as well | 19:44 |
| SpamapS | niemeyer: pong! | 19:45 |
| fwereade | niemeyer: damn, I'm sorry, I thought I'd retrained myself right | 19:46 |
| bcsaller | hazmat: another issue, the way wp is coming up now its only addressable by IP, I'll look at adding an alias with the assigned name and see if that fixes it | 19:46 |
| hazmat | bcsaller, that's not really a problem its only resolvable by the browser by ip | 19:47 |
| hazmat | bcsaller, that's irrelevant imo | 19:47 |
| niemeyer | fwereade: No worries, it's just important because it's hard to tell what was merged from e.g. http://bazaar.launchpad.net/~juju/juju/trunk/revision/389 | 19:47 |
| bcsaller | not a deal breaker, no | 19:47 |
| niemeyer | SpamapS: Hey man | 19:47 |
| niemeyer | SpamapS: Was going to ask you for some reviewing, but we already pushed it forward | 19:47 |
| niemeyer | fwereade: 388 is churning | 19:48 |
| fwereade | niemeyer: the "mfrom: (348.8.15 isolate-formula-revisions)" on that page gives us as much information as does the summary line, surely? | 19:49 |
| fwereade | niemeyer: but I'll try to force myself to keep to the standard anyway | 19:50 |
| fwereade | niemeyer: that's sort of good news and sort of bad news | 19:50 |
| _mup_ | juju/ftests r12 committed by gustavo@niemeyer.net | 19:50 |
| _mup_ | - Fixed butler so it doesn't jump revisions. | 19:50 |
| _mup_ | - Compute the waterfall after every revision. | 19:50 |
| niemeyer | fwereade: Indeed | 19:53 |
| niemeyer | fwereade: Hadn't noticed it to be honest | 19:53 |
| fwereade | hazmat: do you have a moment for a review of https://code.launchpad.net/~fwereade/juju/always-upgrade-local/+merge/78306? | 19:55 |
| hazmat | fwereade, sure | 19:55 |
| SpamapS | niemeyer: ahh ok. :) | 20:02 |
| jimbaker | hazmat, so one useful aspect of doing the reboot is looking at this scenario: what happens to the lxc containers? bootstrap reports it's still bootstrapped, but status fails | 20:03 |
| hazmat | jimbaker, their down | 20:05 |
| hazmat | they don't autostart | 20:05 |
| hazmat | phone bbiam | 20:05 |
| jimbaker | hazmat, exactly. is there a way to restart them? | 20:05 |
| jimbaker | hazmat, later | 20:05 |
| hazmat | jimbaker, lxc-start -n name-of-container | 20:07 |
| jimbaker | hazmat, sounds good. so we can support that later in some sort of automatic way i guess | 20:07 |
| hazmat | jimbaker, i believe there are mechanisms to autostart them as well | 20:07 |
| hazmat | jimbaker, but the zk and machine agent are down as well | 20:08 |
| jimbaker | hazmat, in any event, the reboot did nothing (as expected) | 20:08 |
| hazmat | jimbaker, so on reboot you'll need to destroy and bootstrap | 20:08 |
| hazmat | the env | 20:08 |
| hazmat | for now | 20:08 |
| jimbaker | hazmat, correct, that's why juju status failed so badly | 20:08 |
| jimbaker | hazmat, which is fine for now | 20:08 |
| hazmat | jimbaker, absolutely, we're not touching the host this release with local provider | 20:09 |
| hazmat | outside of the minimum needed to work (lxc containers) | 20:10 |
| jimbaker | hazmat, unless you have any more ideas, i'm going to put off getting local provider running. hopefully jamespage, bcsaller, and others have better luck | 20:10 |
| hazmat | jimbaker, well, we havent done anything since its been rebooted | 20:10 |
| bcsaller | jimbaker: with the small patch I posted a short while ago its working fine for me again | 20:10 |
| jimbaker | bcsaller, what was that? | 20:10 |
| hazmat | jimbaker, destroy-environment and bootstrap & deploy | 20:10 |
| hazmat | jimbaker, the issue your seeing is different than the patch which fixes some dns resolver issues | 20:11 |
| jimbaker | hazmat, yes, i did that, and units were started, but the network issue is still there | 20:11 |
| bcsaller | http://pastebin.ubuntu.com/702946/ | 20:11 |
| niemeyer | Uh oh | 20:11 |
| hazmat | jimbaker, so you still have units unable to connect to zk? | 20:11 |
| jimbaker | hazmat, correct, exact same issue in the unit.log (s) | 20:12 |
| hazmat | jimbaker, i'm not entirely out of ideas yet ;-) | 20:12 |
| niemeyer | hazmat, SpamapS: AMBER CODE | 20:12 |
| jimbaker | hazmat, ok, then let's try them out | 20:12 |
| hazmat | niemeyer, ready and waiting | 20:12 |
| niemeyer | EC2 deployment is broken | 20:12 |
| niemeyer | and it doesn't look like something we did | 20:12 |
| niemeyer | Something probably changed in Oneiric in the last few hours | 20:13 |
| hazmat | jimbaker, confirming (netstat -al) that zk is listening on a localhost with port known to the agents | 20:13 |
| niemeyer | 388 was passing moments ago, and is now broken | 20:13 |
| hazmat | jimbaker, i'm going to swtich off to the ec2 issue | 20:13 |
| hazmat | niemeyer, debugging | 20:13 |
| niemeyer | fwereade: Looks unrelated to your changed indeed | 20:13 |
| hazmat | niemeyer, could be a bad image | 20:13 |
| niemeyer | fwereade: Do you have more details that could help us pinpoint the bug | 20:13 |
| niemeyer | ? | 20:13 |
| niemeyer | fwereade: (from your test run) | 20:14 |
| jimbaker | hazmat, definitely is priority | 20:14 |
| hazmat | jimbaker, but if you could confirm that info it would be helpful | 20:14 |
| hazmat | jimbaker, did you mention early i could get a login to that machine? | 20:14 |
| jimbaker | hazmat, yes, i will create one for you | 20:15 |
| fwereade | niemeyer: sorry, not really: the only other thing I verified was that even bzr wasn't installed | 20:15 |
| niemeyer | fwereade, hazmat: Maybe one of the packages is missing (or has been renamed) | 20:15 |
| hazmat | so if the ec2 repos are changing names | 20:15 |
| hazmat | niemeyer, i'm firing up an ec2 environment more info in a few | 20:15 |
| niemeyer | hazmat: From your log: [trivial] require libzookeeper-java not zookeeperd | 20:16 |
| niemeyer | hazmat: Shouldn't that be done to the EC2 provider as well? | 20:17 |
| hazmat | niemeyer, no.. they don't install this stuff.. that's for running it on the host | 20:17 |
| niemeyer | Ok | 20:17 |
| * niemeyer checks the list of packages | 20:18 | |
| niemeyer | Looks ok | 20:22 |
| niemeyer | smoser: Hey! | 20:23 |
| niemeyer | smoser: Were the AMIs updated today by any chance? | 20:23 |
| smoser | niemeyer, utlemming updated them. https://lists.ubuntu.com/archives/ubuntu-cloud/2011-October/thread.html | 20:29 |
| niemeyer | smoser: What should I be looking for there? | 20:30 |
| hazmat | niemeyer, so i get the same traceback that fwereade got | 20:31 |
| niemeyer | hazmat: What's the traceback? | 20:31 |
| smoser | Refreshed UEC Images of 10.04 LTS (Lucid Lynx) [20110930] | 20:31 |
| hazmat | smoser, niemeyer http://paste.ubuntu.com/702970/ | 20:31 |
| smoser | Refreshed Cloud Images of 10.10 (Maverick Meerkat) [20111001] | 20:31 |
| smoser | Refreshed UEC Images of 11.04 LTS (Natty Narwhal) [20111003] | 20:31 |
| niemeyer | smoser: We're using the Oneiric images | 20:32 |
| smoser | the dailies? | 20:32 |
| hazmat | dailies | 20:32 |
| smoser | they're updated every day | 20:32 |
| niemeyer | smoser: I'll ping utl* about it | 20:32 |
| niemeyer | smoser: Oh, ok | 20:32 |
| niemeyer | Hmm | 20:32 |
| niemeyer | What the heck.. what's a Pangolin? | 20:32 |
| smoser | hazmat, you have the cloud-init-output.log now | 20:33 |
| smoser | pastebin that | 20:33 |
| hazmat | smoser, sure | 20:33 |
| smoser | /var/log/cloud-init-output.log (i think that is the path we used) | 20:33 |
| smoser | apt just failed, either archive issue or package failure | 20:33 |
| hazmat | smoser, what's the cli for pastebin called? | 20:33 |
| hazmat | got it | 20:34 |
| hazmat | smoser, http://paste.ubuntu.com/702972/ | 20:34 |
| hazmat | smoser, and http://paste.ubuntu.com/702973/ | 20:34 |
| hazmat | woah.. that second one is fubar | 20:34 |
| hazmat | forbidden on the repo? | 20:34 |
| smoser | yeah | 20:34 |
| hazmat | wtf | 20:35 |
| smoser | i'm asking in #is | 20:36 |
| niemeyer | Ugh.. that explains a ton | 20:36 |
| niemeyer | I'll stop the waterfall for the moment | 20:39 |
| niemeyer | fwereade: Thanks for your help on this issue, and sorry for the false alarm | 20:39 |
| niemeyer | fwereade: Is that last branch in? | 20:40 |
| _mup_ | juju/ftests r13 committed by gustavo@niemeyer.net | 20:41 |
| _mup_ | Fixed authorized_keys handling in ec2-setup.sh when moving ~/.ssh away | 20:41 |
| _mup_ | so that the user can still log in. | 20:41 |
| niemeyer | hazmat, smoser: Thanks for debugging this as well folks | 20:41 |
| niemeyer | I'll step down for a cup of coffee.. biab | 20:41 |
| hazmat | niemeyer, np | 20:41 |
| hazmat | that sounds like a good idea | 20:41 |
| fwereade | niemeyer, sorry, got pulled away for a while | 20:48 |
| fwereade | hazmat: I presume the weirdness has prevented you from taking a look at that branch? | 20:49 |
| hazmat | fwereade, it has, also trying to debug local provider on jim's machine | 20:50 |
| hazmat | fwereade, many beautiful butterflies.. i'll stop and have a look now | 20:50 |
| fwereade | hazmat, only if you don't know who *isn't* horribly busy atm, who I could hit up instead? | 20:51 |
| niemeyer | fwereade: Man, I feel bad that we're holding you back still.. that must have been a long day for you | 20:56 |
| fwereade | niemeyer, don't worry about it | 20:56 |
| statik | heya hazmat, whats the path to the daily ppa that I should use to try out the local provider awesomeness you posted about? | 20:57 |
| hazmat | statik, ppa:juju/pkgs | 20:57 |
| statik | ah ok, I didn't realize that was daily | 20:58 |
| statik | thx | 20:58 |
| hazmat | bcsaller, +1 on that patch btw | 20:58 |
| hazmat | jimbaker, i'm going to pause on debugging this and switch back to a review for a bit | 20:59 |
| SpamapS | lkja;lkj | 21:01 |
| fwereade | hm, niemeyer, just noticed a minor lurking bug in the deploy/upgrade changes: the error when --repository is needed but not included is entirely unhelpful | 21:02 |
| fwereade | niemeyer: worth a minor to raise FileNotFound from resolve(), or possibly LocalCharmRepository.__init__()? | 21:03 |
| niemeyer | fwereade: How does it look like? | 21:03 |
| fwereade | niemeyer: NoneType has no attribute .endswith IIRC | 21:03 |
| niemeyer | fwereade: Ouch :-) | 21:03 |
| fwereade | niemeyer: hm, it's not quite FileNotFound though | 21:03 |
| niemeyer | fwereade: It's CharmNotFound I guess | 21:04 |
| fwereade | niemeyer: not even quite that, if anything it's RepositoryNotFound ;) | 21:04 |
| niemeyer | fwereade: Hmm | 21:05 |
| fwereade | niemeyer: or, really, RepsitoryNotSpecified | 21:05 |
| niemeyer | fwereade: Yeah, but only if the charm is local:, and if it's not yet in the env | 21:06 |
| hazmat | fwereade, what's the leapfrog do? | 21:06 |
| hazmat | rev 0 to rev 2? | 21:06 |
| niemeyer | fwereade: and the problem is similar if the repository is provided, but the specific charm isn't there | 21:06 |
| fwereade | hazmat: bumps to deployed+1, which is a jump of >1 from the one in the repo | 21:07 |
| hazmat | fwereade, ah cool | 21:07 |
| fwereade | hazmat: if yu can think of a beeter name I'm all ears :) | 21:07 |
| * fwereade peers suspiciously at his keyboard | 21:07 | |
| fwereade | it's the tools, I tell you! | 21:07 |
| fwereade | niemeyer: I feel like the arg parser is really the right place to catch it | 21:08 |
| fwereade | niemeyer: at the moment anyway | 21:09 |
| niemeyer | fwereade: I can't see how the arg parser is related to this | 21:09 |
| niemeyer | fwereade: This is highly contextual.. | 21:09 |
| fwereade | niemeyer: that might change once we actually can specify a repo in the environment | 21:09 |
| niemeyer | fwereade: "if not repository_path and charm is local and charm not in environment: raise foo" | 21:09 |
| fwereade | niemeyer: maybe, but it's connected: the reason the bug exists is because the "repository" arg is no longer required | 21:10 |
| niemeyer | fwereade: Sure.. that's quite expected given that we just removed it | 21:10 |
| niemeyer | fwereade: We just need to consider the case where it's not there and raise an error | 21:10 |
| niemeyer | fwereade: We can do that tomorrow, though, in a bug fix | 21:11 |
| niemeyer | fwereade: with you relaxed ;-) | 21:11 |
| hazmat | fwereade, review in one minor, but very awesome | 21:11 |
| fwereade | hazmat: cool, thanks | 21:11 |
| fwereade | niemeyer: sounds like a plan | 21:12 |
| niemeyer | fwereade: Please just file a bug about this so you can sort it out later | 21:12 |
| fwereade | niemeyer: will do, I meant "tomorrow" sounds like a plan :) | 21:12 |
| niemeyer | fwereade: Awesome, thank you! | 21:12 |
| hazmat | SpamapS, m_3 .. fwereade has answered the common desire of all formula authors.. auto incrementing versions on upgrade | 21:16 |
| hazmat | negronjl, ^ | 21:16 |
| m_3 | ah nice | 21:16 |
| SpamapS | \o/ !!! | 21:17 |
| SpamapS | 21:17 | |
| _mup_ | Bug #868729 was filed: deploy and upgrade-charm give unhelpful errors when repository not specified <juju:New> < https://launchpad.net/bugs/868729 > | 21:25 |
| fwereade | ...and that's it for me, nn all | 21:26 |
| niemeyer | fwereade: Woohay! | 21:28 |
| niemeyer | fwereade: Have a restful night! :) | 21:28 |
| hazmat | niemeyer, bcsaller, jimbaker just a heads up, i'm moving over not in progress bugs to the next milestone | 22:45 |
| bcsaller | hazmat: k | 22:46 |
| niemeyer | hazmat: Awesome.. if you find anything interesting on the way that could deserve some attention, please raise a flag | 22:46 |
| hazmat | jimbaker, this one is a duplicate afaics https://bugs.launchpad.net/juju/+bug/846055 | 22:48 |
| _mup_ | Bug #846055: Occasional error when shutting down a machine from security group removal <juju:New> < https://launchpad.net/bugs/846055 > | 22:48 |
| hazmat | perhaps not | 22:48 |
| jimbaker | hazmat, that's a txaws parsing issue, when we separate out the related bug 863510 | 22:57 |
| _mup_ | Bug #863510: destory-environment errors and hangs forever <juju:Fix Released by jimbaker> < https://launchpad.net/bugs/863510 > | 22:57 |
| hazmat | jimbaker, this one also seems closed afaics https://bugs.launchpad.net/juju/+bug/824222 | 22:57 |
| _mup_ | Bug #824222: juju bootstrap should be more robust <juju:Triaged by jimbaker> < https://launchpad.net/bugs/824222 > | 22:57 |
| hazmat | jimbaker, i only see tracebacks when in verbose mode | 22:57 |
| jimbaker | hazmat, yes, that's correct | 22:58 |
| hazmat | jimbaker, and this one is fixed? https://bugs.launchpad.net/juju/+bug/802678 | 22:58 |
| jimbaker | hazmat, so let's definitely close that one. i think we could consider expected errors vs not, but that can be in the next milestone | 22:58 |
| _mup_ | Bug #802678: Update watch_ports <juju:Confirmed for jimbaker> < https://launchpad.net/bugs/802678 > | 22:58 |
| hazmat | bcsaller, i assume statusd isn't getting merged in the next day or so? | 23:00 |
| bcsaller | hazmat: no | 23:00 |
| jimbaker | hazmat, the test has gone away | 23:00 |
| jimbaker | hazmat, let me see where it lives now, if at all | 23:00 |
| jimbaker | hazmat, let's mark that as fix released, the current test is very close to what is the attached patch as would fail when repeated | 23:05 |
| jimbaker | it doesn't now | 23:05 |
| hazmat | well its invalid at this point | 23:05 |
| jimbaker | sure, that works too | 23:06 |
| jimbaker | hazmat, are we planning on doing jenkins for ec2 functional testing? i thought wtf covered it | 23:06 |
| hazmat | jimbaker, fair enough.. feel free to mark it wont fix | 23:07 |
| jimbaker | hazmat, ok | 23:07 |
| hazmat | kim0, ping.. just curious about the orchestra docs | 23:08 |
| jimbaker | hazmat, what do you think of bug 697093 - this purely seems to be an artifact of our testing setup | 23:08 |
| _mup_ | Bug #697093: Ensemble command should return nonzero status code for errors <cli> <juju:New> < https://launchpad.net/bugs/697093 > | 23:08 |
| jimbaker | (at the very least i need to update the description/summary accordingly) | 23:09 |
| hazmat | jimbaker, oh.. perhaps | 23:11 |
| hazmat | jimbaker, yeah... ideally we could test for status codes, but if i'm reading that right, we're really just testing the mocks not the actual exit codes | 23:11 |
| * hazmat calls it a night | 23:11 | |
| hazmat | cheers | 23:11 |
| jimbaker | hazmat, yeah, it would be nice to get it right, but tricky for sure | 23:12 |
| jimbaker | worthwhile for florence however | 23:12 |
| jimbaker | hazmat, enjoy! | 23:12 |
| hazmat | niemeyer, as far as interesting bugs we might want to still consider for eureka.. https://bugs.launchpad.net/juju/+bug/814987 and https://bugs.launchpad.net/juju/+bug/828326 the latter is a new feature though | 23:13 |
| _mup_ | Bug #814987: config-changed hook is retried on 'resolved' even when --retry is not passed <juju:New> < https://launchpad.net/bugs/814987 > | 23:13 |
| _mup_ | Bug #828326: need to be able to retrieve a service config or schema from the cli <juju:In Progress by hazmat> < https://launchpad.net/bugs/828326 > | 23:13 |
| hazmat | re the first one.. actually the issue i'm interested isn't really the about config-hooks, but that install error retries are broken | 23:14 |
| hazmat | for getting to a working state | 23:14 |
| niemeyer | hazmat: Why are they broken? | 23:14 |
| hazmat | niemeyer, because the automatic transition from install to start doesn't happen | 23:14 |
| hazmat | afaicr | 23:15 |
| hazmat | after the error recovery | 23:15 |
| hazmat | the unit just stays in the installed state | 23:15 |
| niemeyer | hazmat: Ugh | 23:16 |
| niemeyer | hazmat: Ok | 23:16 |
| niemeyer | hazmat: Sounds like something that would be nice to get done indeed, if we find some spare time | 23:17 |
| niemeyer | I'll kick off the wtf | 23:55 |
| niemeyer | Hopefully the repositories are back already | 23:55 |
| niemeyer | Uh oh.. Steve Jobs is no more.. :( | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!