=== andrewsmedina_ is now known as andrewsmedina === hspencer is now known as hspencer[gym] [04:59] <_mup_> Bug #928624 was filed: cached unit public addresses are problematic when public ip address changes < https://launchpad.net/bugs/928624 > === fenris is now known as Guest55400 === Guest55400 is now known as ejat [05:58] hi, how do i "de bootstrap" juju ? [05:59] or, how do i tell juju that new systems are available for it to use ? [06:50] SpamapS: how to expose the services .. already run juju expose services .. the web services not appear in browser http://paste.ubuntu.com/833602/ [06:58] or can someone help me with that ? === asavu_ is now known as asavu === nijaba_ is now known as nijaba === grapz is now known as grapz_afk === grapz_afk is now known as grapz === chuck_ is now known as zul [13:22] Hi all! I need some help with two issues. I'm trying to use juju charms. I would like to use hadoop-master and hadoop-slave formulas from https://code.launchpad.net/~charmers/. Apparently all is working fine with juju because I can use the mysql and mediawiki charms normally. But, with the hadoop charms the problem is that the service stops at some point. [13:22] So, I've tried https://juju.ubuntu.com/docs/write-charm.html#debugging-hooks to debug. I could connect to instance and run the install script from charm manually. When I run the script manually at the instance, I get no error! But with juju deploy I get some errors. [13:22] Are there some test to do? === grapz is now known as grapz_afk === grapz_afk is now known as grapz === asavu_ is now known as asavu [15:07] * hazmat yawns [16:16] hi all [16:35] SpamapS, hazmat, hi. two questions about units. (1) if you are talking to a unit, is there a way to identify that other unit uniquely? (2) Can you have different units with different configuration? I'm guessing no, but that's kinda limiting. [16:36] For question 1, I'm interested particularly in relation-changed and relation-joined [16:39] gary_poster: I don't understand question 1 , but for question 2, that would violate the point of juju.. two separate configurations of a service are two separate services. [16:41] gary_poster, 1) the unit is passed to hooks 2) the units can coordinate among themselves if they need different state (a leader vs slave), but they share the same service configuration, [16:41] gary_poster: can you perhaps provide a more concrete example of what it is you want to do? [16:43] SpamapS, for 2, ok, let's step back to use case then. for the case of a build slave connecting to a build master, you will want to have multiple build slaves each running different tests. Having different charms for each kind of test config that might run would be annoying--not very lightweight for something that should be lightweight [16:44] hazmat, so for 1, does unit-get refer to the one on the other side? It seemed like it was talking about itself. If not unit-get, how do we get that unit? [16:45] gary_poster: right, so each build slave is then its own instantiation of each charm as service1, service2, with different config settings. [16:45] gary_poster: so you'd juju deploy build-slave slave-config1 --config config1.yaml [16:45] gary_poster: so you'd juju deploy build-slave slave-config2 --config config2.yaml [16:46] SpamapS, ah! ok. perfect thanks [16:46] gary_poster: note that the master needs to be smart about relationships with > 1 service. Some charms don't do that (like haproxy) [16:46] 1) the local unit id is available as an environment variable ($JUJU_UNIT_NAME) to all hooks, and unit-get refers to information about the local unit [16:47] SpamapS, can you point us to a master that is smart about that kind of multi-relation? [16:47] the remote unit that triggered a local hook execution is available in the env as JUJU_REMOTE_UNIT [16:47] I mean, a charm [16:48] hazmat, got it, https://juju.ubuntu.com/docs/charm.html#hook-environment thanks & sorry for not seeing it [16:48] gary_poster, np [16:50] i've been playing with this same topic (build slaves), i ended up having the slaves register with the master with an identity and local env information, and have the master divy out work appropriately to different queues (distro release, arch, etc) which the categorized slaves listen to.. but thats all application level [16:50] * hazmat goes back to reviews [16:50] SpamapS, am I right that in your deploy example you would set up a relation between the master and slave-config1, right? [16:52] gary_poster: mysql is very smart about that [16:52] gary_poster: it creates a database based on the related service name. [16:53] hazmat, yeah, that's cool. We need to have a custom environment in some cases, so being able to control that at a service level is nice. Otherwise when the work is divvied out, all of a sudden you have a lot of environment prep work that needs to be done. having it done once would be good. [16:53] hazmat: please.. tell me you didn't rewrite jenkins [16:53] in scala [16:53] blindfolded [16:53] ;) [16:53] SpamapS, of course not ;-) i used go [16:53] heh [16:53] although i was tempted by clojure [16:53] * SpamapS knows hazmat is a code ninja [16:54] yay clojure! [16:55] SpamapS, awesome, thanks, will look. FWIW, we do have one small bug we think we have encountered: setting a relation value on a master and then retrieving that relation's value on the next relation-changed on the master fails to get the value we just set. [16:55] I'll file a bug. [16:56] coming up with a small charm to dupe may take a bit. [16:57] gary_poster: relation-get does not fetch the values you just set [16:57] gary_poster: relation-set exposes it to the other side of the relation. [16:57] Not even in (immediately) subsequent hook [16:57] ? [16:57] gary_poster: and it is not flushed and exposed to the other side of the relation until the hook that called relation-set exits [16:58] transactional-ish--I had figured, yes [16:59] gary_poster: so if you are seeing that changed is executed on the other side of a relation without the values you just relation-set .. its possible something else caused changed to be executed [16:59] gary_poster: changed is *always* executed once... and you have to write changd hooks tolerant of not having any values yet [17:01] SpamapS, here's scenario: service 1 sets relation value in relation with service 2; service 2 gets value and does other stuff, including changing the relation again; service 1 is therefore re-called with a relation-changed, and wants to see if it has already told service 2 that value, so it checks with relation-get. IIUC, that last usage is unsupported? [17:02] (in the last step, if we have not told service 2 a value, we generate a new one) [17:02] (which is why juju doesn't save us from ourselves) [17:03] gary_poster: ah, I see the confusion [17:04] gary_poster: there are *two* buckets of values there [17:04] gary_poster: service1/0 has values, and service2/0 has values [17:05] ah, and the twain don't meet [17:05] gary_poster: Because relation-get and relation-set are context sensitive, you can't look at your own values. [17:05] SpamapS, gotcha. Thank you [17:06] gary_poster: if you need to avoid repeating an action, keep track of state locally. If you're worried about endless loops of changed hooks with the same values.. you don't have to. Hooks are only fired when the values actually change. [17:07] SpamapS, yeah, we'll do it locally thanks. We were changing (generating) the values, which is why we had a problem === koolhead17 is now known as koolhead17|zzZZ === hspencer is now known as hspencer[afk] [17:52] !jenkins [17:52] SpamapS did you mean me? Unknown command '' [17:52] Use '!jenkins help' to get help! [18:12] hazmat: figured out the problem with the jenkins test failing [18:12] hazmat: juju can't run its tests from a tree with any spaces in it [18:12] [pid 446] execve("/var/lib/jenkins/jobs/juju", ["/var/lib/jenkins/jobs/juju", "tests/workspace/bin/unit-get", "private-address"], [/* 9 vars */]) = -1 ENOENT (No such file or directory) === koolhead17|zzZZ is now known as koolhead17 [18:15] koolhead17: go to sleep! [18:16] SpamapS: i can once done with the tiny piece :) [18:30] <_mup_> Bug #929030 was filed: Test suite fails when run from within a directory with spaces in its name < https://launchpad.net/bugs/929030 > [18:41] OK here's something odd [18:42] in relation-joined on slave we set a value in the relation [18:42] and that never gets in the log of the master [18:43] gary_poster: no guarantees it won't be set by then [18:43] oh wait [18:43] I read that wrong [18:44] gary_poster: are you sure the changed hook didn't execute again on the master? [18:47] SpamapS, it executed twice...ah nm. We were called but made an error, and expected to see the value in the master logs. our error, sorry. [18:49] gary_poster: its ok.. the juju dance can be a bit dizzying at first.. :) [18:49] :-) [19:07] SpamapS, huh? [19:07] that's seriously odd [19:07] and worth a bug [19:11] hazmat: ^^ 929030 [19:12] hazmat: I'm now tumbling down the twisted spawnProcess rabbit hole to see if it is doing something stupid with the PATH [19:17] hazmat: you showed me once how to run the test suite under pdb [19:22] * koolhead17 whistling juju juju loudly !! [19:22] SpamapS, ./test -b [19:23] SpamapS, you have to target a particular test, it catches on all errors (even caught ones) [19:23] yeah thats cool [19:23] SpamapS, alternatively just adding import pdb; pdb.set_trace() anywhere [19:23] oh, that sounds better [19:23] but if you hit a yield the stack is gone [19:24] so you want it as close to the point of inspection as possible [19:24] hazmat: I think its actually create_hook's fault.. its creating a shell script but not escaping the spaces [19:25] ye olde "not escaping the spaces" scurvy dog.. YAR [19:25] Argh! [19:25] #!/bin/sh [19:25] /var/lib/jenkins/jobs/juju tests/workspace/bin/relation-get --format=json - [19:25] yup [19:30] simple fix actually.. phew [19:33] Project juju tests build #4: STILL FAILING in 1 hr 30 min: http://ec2-23-20-64-9.compute-1.amazonaws.com:8080/job/juju%20tests/4/ [19:34] Project juju tests build #5: ABORTED in 1 min 11 sec: http://ec2-23-20-64-9.compute-1.amazonaws.com:8080/job/juju%20tests/5/ [19:35] hazmat: http://paste.ubuntu.com/834350/ [19:35] hazmat: build #6 should pass.. its applied on the jenkins box. :) [19:41] Project juju tests build #6: STILL FAILING in 7 min 5 sec: http://ec2-23-20-64-9.compute-1.amazonaws.com:8080/job/juju%20tests/6/ [19:44] SpamapS, lgtm [20:17] SpamapS: thanks for thjenkins plugins... I'll pull those into charmtester as well [20:27] good day all, [20:28] i'm trying to spin up some ubuntu orchestra/juju [20:28] i have orchestra/cobbler running [20:29] juju bootstrap fails to see my active systems [20:29] cobbler list shows these systems [20:29] systems: node064 node066 systems: node064 node066 [20:30] juju bootstrap errors with [20:30] 2012-02-08 15:29:58,775 ERROR Could not find any Cobbler systems marked as available and configured for network boot. [21:59] <_mup_> juju/unit-stop r423 committed by kapil.thangavelu@canonical.com [21:59] <_mup_> clean up stop spec [22:01] michael_tn, have you setup the orchestra classes in environments.yaml and assigned machines to the $available-mgmt-class [22:02] juju will use machines only that have the available-mgmt-class applied and are setup for netboot i think. [22:07] hazmat: yes thats how it works [22:19] Project juju tests build #7: STILL FAILING in 6 min 38 sec: http://ec2-23-20-64-9.compute-1.amazonaws.com:8080/job/juju%20tests/7/ [22:29] Project juju tests build #8: STILL FAILING in 6 min 55 sec: http://ec2-23-20-64-9.compute-1.amazonaws.com:8080/job/juju%20tests/8/ [22:29] Clint Byrum: [trivial][r=hazmat] Fix running of test suite inside sub-dirs that have spaces or other special shell chars [22:30] http://paste.ubuntu.com/834557/ [22:30] hazmat: ^^ .. that test seems to have a race in it [22:30] # Do this as late as possible to prevent zk background logging [22:30] # from causing problems. [22:31] That race seems to be hitting quite often on my little m1.small [22:32] I'm a little confused why it sets LOG_LEVEL_INFO .. [22:33] * hazmat pokes at the source [22:33] bzr log -c 146.2.1 [22:33] ask bzr, and ye shall receive. ;) [22:35] hazmat: seems like LOG_LEVEL_ERROR would be more appropriate given that the warnings are not fatal.. [22:39] hazmat: its really hard to understand at all what that test even wants to be doing [22:39] SpamapS, there's a race from when it sets the log level to when the operation is done [22:39] SpamapS, that test can be removed imo [22:39] hazmat: it seems like that test is testing txzookeeper, not juju. ;) [22:39] its hard to test without adding a new method to the zk bindings [22:40] its trying to test a juju cli default behavior [22:40] That behavior being.. return no output after removing a unit? [22:40] So we could also just filter out all ZK log messages. Right? [22:40] SpamapS, by default we do [22:41] SpamapS, that test basically sets it to a level that would log, and then invokes juju since juju will set it to disabled, but there's a race between the two that is outside tests control [22:42] and then it tries to verify that nothing was logged, but that fails since between juju cli being run and the activation of logging, the zk extension/binding io thread does some logging [22:43] all we really want is to verify self.assertEqual(zookeeper.get_debug_level(), 0) but that method doesn't exist [22:43] hazmat: so its almost by definition a non-deterministic test because the logging is not forced. [22:43] SpamapS, yes, the io thread is outside of python's control.. its basically setting up a fail scenario, and then trying to assert it didn't fail, but there is a window for failure [22:45] SpamapS, we could minimize the window by moving the mocker.replay call up, but there will always be a window with that test, and frankly its a test i'd be fine with yanking.. alternatively we patch and upstream the new method call onto the bindings [22:46] hazmat: I'm +1 on just removing the test [22:47] hazmat: and opening a bug on python-zookeeper to add the call [22:47] SpamapS, sounds good to me [22:47] or is that even further up, to libzookeeper itself? [22:47] * hazmat checks [22:48] Project juju tests build #9: STILL FAILING in 6 min 53 sec: http://ec2-23-20-64-9.compute-1.amazonaws.com:8080/job/juju%20tests/9/ [22:48] SpamapS, its libzookeeper as well [22:49] argh, no JIRA in launchpad still. Bummer. [22:54] SpamapS, ah.. we could just mock it [22:55] that would work well [22:55] <_mup_> Bug #929187 was filed: juju.control.tests.test_remove_unit.ControlRemoveUnitTest.test_zookeeper_logging_default is non-deterministic and should be removed < https://launchpad.net/bugs/929187 > [22:55] mock the zookeeper calls? [22:56] hazmat: you want to take that? [22:56] hazmat: I know I could do it, but I'm not so good w/ recording stuff for mocker. :-P [22:56] so its juju add-unit wordpress will add extra unit but juju add-unit wordpress --n=5 [22:56] add 5 units all toagther [22:56] koolhead17: right [23:01] SpamapS, http://paste.ubuntu.com/834593/ [23:01] Multiple charms can provide the same service and can be easily switched. Does it mean charm like mysql and pgsql doing same [23:01] bcsaller, jimbaker could you look over this trivial ^ [23:02] hazmat, looking [23:02] hazmat: oh snap :) [23:02] hazmat: I constantly forget about replace. :) [23:03] SpamapS, it still feels a little suspect, mocker matching is a little magic, it doesn't execute just once, nor just twice, but some schrodinger cat polystate [23:03] jimbaker, thanks [23:04] hazmat, +1, the right approach given this nondeterminism [23:05] hazmat: I'll give you a bug #, since I already started writing it up [23:05] hazmat: err, actually its 929187 [23:05] saved already [23:27] SpamapS: yay!! am finally done!! :) [23:36] hazmat: ping [23:37] SpamapS: ping [23:38] niemeyer: a-ding-dong? :) pong [23:42] SpamapS: :-) [23:42] SpamapS: Was wondering about the boolean stuff [23:42] SpamapS: Do you know if it's made its life into juju yet? [23:45] niemeyer: looks like no, according to bug #885551 [23:45] <_mup_> Bug #885551: config.yaml should have boolean types < https://launchpad.net/bugs/885551 > [23:45] SpamapS: Cool, thanks [23:45] SpamapS: I've just run another import round in the repository [23:45] niemeyer: much cleaner I hope [23:46] SpamapS: A lot.. thanks for that [23:46] SpamapS: It still has the boolean stuff [23:46] niemeyer: mostly m_3's doing :) [23:46] SpamapS: and includes just a few new items related to symlinks [23:46] 126 charms total [23:46] Well.. unique URLs [23:46] niemeyer: I was just polishing up an edit to charm proof that checks for non-relative symlinks [23:47] niemeyer: seems like eventually your code should supersede charm proof [23:47] 22 issues only [23:47] SpamapS: I hope this becomes "juju publish" [23:47] though perhaps there is value in having a second implementation of the known rules. [23:48] SpamapS: Yeah, I think there will always be room for a lint tool [23:48] SpamapS: Since you can recommend conventions there [23:48] SpamapS: The repository is black-or-white