[00:33] using PPA, is 'instance-state' meant to reach the 'started' state, or stop at 'provisioned' ? [00:40] adam_g, started [00:41] robbiew, cool, good to know thanks [00:43] hazmat: hmm. at least the bootstrap node of this new environment only made it as far as 'provisioned' with orchestra,but seems otherwise fine [00:43] adam_g, hmm. [00:45] adam_g, looking at the orchestra provider, it looks like its either 'provisioned' or 'pending' [00:45] so no 'started' staet.. [00:45] probably worth a trivial for consistency [00:46] except its not really checking that the machine is started [00:46] hazmat: right, i knew it hit 'provisioned' as soon as it finishes its preseeded install. thought it went to 'started' in the past, though, after first boot [00:48] adam_g, apparently not.. does orchestra provide that info? [00:48] the code reads.. state = "pending" if d["netboot_enabled"] else "provisioned" [00:48] not sure what other info is available from cobbler wrt to the actual state [00:50] interesting yet another cobbler fork.. http://code.google.com/p/madhatter/ [00:53] i don't see anything more appropriate for actual status looking over the internal data struct.. https://github.com/cobbler/cobbler/blob/master/cobbler/item_system.py [00:54] cobbler only knows that it has been setup for pxe boot [00:54] and can be asked what the power state is *if* it has power control setup [00:54] SpamapS: hey, my mini proliant came in [00:54] you want one [00:54] it is SO cute. [00:55] I think everyone should have one [00:57] I know what the charm contest winners can put their gift card towards [01:01] those mini proliants are great [01:01] and cheap [01:13] adam_g: but are they energy efficient? [01:15] oo 150W [01:15] two PCI slots so you could turn it into a little RADIUS box === Furao_ is now known as Furao === al-maisan is now known as almaisan-away === TheMue_ is now known as TheMue [08:38] hi, can i get some help with a charm? i have a db-relation-joined hook with postgresql, and seems that my hook hasn't been called. If i debug and call it manually my charm is working, if not, seems that the code isn't triggered === almaisan-away is now known as al-maisan [09:25] hi m_3, are you available? i found a problem in the openerp&postgres hooks [10:12] <_mup_> juju/trunk r521 committed by kapil.thangavelu@canonical.com [10:12] <_mup_> [trivial] merge provider-error status fix [a=bac][r=hazmat] === al-maisan is now known as almaisan-away [12:03] hi, what's correct way of restarting a service in a juju charm? [12:03] i have something like that: [12:03] # restart service [12:03] service openerp-core start || service openerp-core restart [12:04] however, it doesn't seem to be stopping openerp-core, it says that the process doesn't exist. If i find it manually using a ps -ef, do a kill and start the service, then works [12:17] hi, need help with a juju charm, i'm having problems restarting a service [12:26] yolanda: where does your restart part of you gem look for the pid of the process and is that pid stored there when startet through your charm? [12:26] sc-rm, there is an openerp-core service, that is started on the install hook [12:26] and in the db-relation-changed, i try to restart it [12:27] because i need some changes to be applied on a config file [12:28] yolanda: How is it started in the start hook? [12:28] err, in the install hoook* [12:28] youlanda: so openrp-core is a standard script in the init.d ? aka you are able to do /etc/init.d/openrp-core start|stop|restart and it works? [12:29] sc-rm, yes [12:30] the service is started automatically when installed the package [12:30] however, do i need to also provide an start hook that starts the service? or if it's done in the install is enough? [12:30] youlanda: okay, but if you log into that machine are you then able to do /etc/init.d/openrp-core stop and the process stops? [12:35] sc-rm, not at first try, if i do it it says that the process doesn't exist, but i can do a "ps -ef | grep openerp" and kill it [12:35] then if i do the service openerp-core start it works, and after that i can restart correctly [12:36] seems that there is some problem between install and db-config-changed hooks [12:36] youlanda: ahe, there is the problem, the way the service is started is not storing the pid in the same place as the start script expect it to be located [12:37] the openrp-core script in init.d is that something you created and is it public accessible? [12:42] sc-rm, the openerp-core is a package that we are writing for openerp 6.1 version [12:42] i can send you the url for you to check it [12:53] sc-rm, code for the package is here: https://code.launchpad.net/~openerp-community/openerp-tools/yolanda.robla-openerp-core [13:10] sc-rm, any idea? === almaisan-away is now known as al-maisan [13:46] hi, any help with the openerp start script, please? i'm just blocked with that, only i need to restart service correctly to finish the charm [13:46] youlanda: it seems okay to me, if you do install do you then see the same pid in /var/run/openerp-server.pid as when doing ps ? [13:47] let me test [14:17] sc-rm, pid is the same in /var/run/openerp-server.pid as the ps [14:22] Can I use environment variables in environments.yaml? E.g. for secret keys? [14:22] sc-rm, but when i run the db-relation-changed hook, i see different pid in /var/run/openerp-server.pid and in ps [14:22] so i'm not able to kill old process and start new [14:27] sc-rm, i found some problem. I have this line in my db-relation-changed hook: service openerp-core start || service openerp-core restart [14:27] when i run it, pid in ps remains the same, but pid in /var/run/openerp-server.pid changes [14:27] and process isn't restarte [14:27] restarted [14:36] yolanda: it should not be: service openerp-core start && service openerp-core restart [14:36] because you want to restart only if the start doesn't worked [14:36] yes [14:37] well, the start should not work because process should be already started by the last step [14:37] oh no, your right [14:38] my logic fail in the morning [14:39] avoine, the probem i face is that when i do it, pid in ps isn't changed, but pid in /var/run/openerp-server.pid changes [14:40] hmm .. did anubody see a "ERROR Invalid SSH key" upon sudo juju status -e oneiric-aws? The bootstrap command finished successfully [14:40] anybody even [14:40] sems that the process isn't restarting correctly, but if i kill process by hand and then run it, it starts to behave correctly, and also starts/stops correctly [14:41] al-maisan: do you have either an id_rsa.pub or id_dsa.pub in your .ssh folder? [14:41] yolanda: maybe a permission problem [14:41] marcoceppi: I have a symbolic link as follows: " id_rsa.pub -> juju_rsa.pub" [14:41] in ~/.ssh [14:42] avoine, the process is running as openerp user, perhaps is that? [14:42] but it's the same also if i run as root [14:42] al-maisan: that error is usually indicative of your public key not be copyied to the bootstrap [14:42] yolanda: if it's an upstart script it should not be a problem [14:43] marcoceppi: removed the symbolic links and renamed the files, trying again [14:43] yes it is [14:43] al-maisan: if it works, what you can do then is add just juju_rsa.pub to authorized-keys in the stanza if you wish to segregate it from your standard id_rsa [14:44] yolanda: have you try start openerp-core || restart openerp-core just in case [14:44] marcoceppi: will try [14:45] avoine, unknown job [14:45] hum [14:46] hmm .. marcoceppi .. made no difference .. still getting "ERROR Invalid SSH key" [14:46] al-maisan: are you using the juju PPA? [14:46] I am on 12.04 and using the juju package [14:47] marcoceppi: I also get this: http://pastebin.ubuntu.com/924951/ [14:47] is that normal? [14:48] al-maisan: yes [14:52] hmm .. no luck .. I get the "ERROR Invalid SSH key" no matter what I try [14:53] .. and I am supposed to demo this in 2 hours :-P [14:55] marcoceppi: I see that jdstrand had a similar problem http://irclogs.ubuntu.com/2012/03/22/%23juju.txt [14:55] al-maisan: can you log in to ec2 get the address for the bootstrap and try to ssh -vv ubuntu@ec2url ? [14:55] will try [14:56] debug1: connect to address 50.19.3.207 port 22: Connection refused [14:57] al-maisan: that looks like a bug, but it might already be fixed in the PPA [14:58] I am running Version: 0.5+bzr504-0ubuntu1 [14:58] should I install from the PPA? [14:58] Try the ppa, and add "origin: ppa" to the environments stanza you're using [14:58] al-maisan, can you pastebin the console output from the instance? [14:58] *in the interest of getting it ready for your demo* [14:59] I try "ec2-get-console-output i-84af18e3" [14:59] Only getting: [14:59] i-84af18e3 [14:59] 2012-04-11T14:59:12+0000 [14:59] quietsch ~ $ [15:00] ignore the last line please [15:01] OK .. upgraded to 0.5+bzr519-1juju5~precise1 [15:01] al-maisan: make sure to update your environments.yaml file to use ppa as well [15:01] yup [15:13] monring. is there a way to juju ssh into the bootstrap host? I apparently need to run some lxc apt updates [15:13] yagey: juju ssh 0 [15:14] marcoceppi: when I try to connect to the instance from the aws web page it says: "Instance is not associated with a Key Pair. " [15:14] that's what I hoped. ^Cyagey@yagey-VirtualBox:/tmp$ juju ssh 0 2012-04-11 08:13:51,250 INFO Connecting to machine 0 at localhost ssh: connect to host localhost port 22: Connection refused [15:15] marcoceppi: "juju ssh 0" gets me into the aws instance.. [15:15] al-maisan: does juju status work? [15:16] yes! [15:16] now it works [15:16] al-maisan: success! you should be good to go for your demo [15:16] yeah !! [15:16] yagey: have you restarted since the last time you tried to connect? [15:16] marcoceppi: thanks for your help! [15:17] rebooted? I'm using lxc, won't that kill the bootstrap instance? [15:19] yagey: it will, I was just making sure you haven't [15:19] marcoceppi: I think I know what went wrong all the time: I was using *sudo* with juju all the time :-P [15:20] al-maisan: ah! that would probably be the reason, good to know it wasn't a bug *bug* :) [15:20] yeah .. sorry for the noise :-/ [15:22] my mongo install is failing with: 2012-04-11 08:09:56,966 Machine:0: twisted ERROR: The following packages have unmet dependencies: 2012-04-11 08:09:56,966 Machine:0: twisted ERROR: ubuntu-minimal : Depends: netcat-openbsd but it is not going to be installed - any suggestions please? [15:39] how about this one? juju deploy tomcat7 Invalid options specification: options.multicast.type: expected 'string', got 'boolean' 2012-04-11 08:39:14,215 ERROR Invalid options specification: options.multicast.type: expected 'string', got 'boolean' [15:44] yagey: one of your charms isn't updated properly. [15:44] Or the tomcat7 isn't updated. Let me check it [15:46] Interesting, which version of juju are you using yagey? [15:49] whichever apt-get installed [15:50] how can I tell? [15:52] dpkg -l | grep juju [15:52] dpkg -l | grep juju ii ensemble 0.5+bzr398-0ubuntu1 transition package for rename to juju ii juju 0.5+bzr398-0ubuntu1 next generation service orchestration system [15:55] that's a pretty old version of juju, I don't think it has the updated types since boolean was added later [15:55] which is why it's saying expected string when it got boolean for the multicast configuration option in tomcat7 [15:56] ok. upgrade from the ppa? [15:56] upgrading juju from that version to latest will likely break your current deployment though [15:56] so if you're okay with re-boostrapping then yes === al-maisan is now known as almaisan-away [16:33] SpamapS: ok so you have a conf file in /etc , you change a value of that conf , should you not place the whole tested conf in the charm vs potentially untested conf with sed vaules changed after install when the maintainer of a package changes values [16:35] like the example given is 8 months from now the maintainer changes a default value, i would think just as in package management you would not want that default value altomaticly propigated to the charm untill its been tested against your charm [16:36] ( or anyones feedback ) [16:36] dropping a configuration file from 8 months in the past against an updated package is just as reckless [16:36] no, not if there is no abi change [16:36] with a greater chance for breakage as it does not account for changes to the package [16:37] much less chance, its been tested, the latter way has not, thus less [16:42] if i have a config with show-errors off even if thats the default, then i know errors are off, if the maintainer changes that default to on, then errors are shown in my charm and it is then broken imho [16:42] if i have a known state for the software in the charm, not the full system, but what your provinding then you should own it all [16:43] not the package mantainer [16:44] imbrandon: if you know you always need show-errors off then you should make sure it's set via the install hook [16:44] sure, and i do as well as every other value [16:44] by the whole conf [16:44] known state [16:44] won't scale, and does not smell like a best practice to me [16:44] it scales every day [16:44] its called debian packageing [16:45] it works the same way [16:45] damn near every deb drops their config in place [16:46] for much the same reason [16:46] like i said if thats the default now, i cannot garentee its the default alwys [16:46] just as you point out [16:46] so i need to make sure by setting all values [16:48] thats why you get the little popup when debconf see's changes to files in /etc === asavu_ is now known as asavu [17:13] there's a reason that charms have series in their qualified name [17:29] hazmat: sure thats holds up if all the software is installed via the package mgmt sysxtem and not git or gotdeb or src :) === bcsaller1 is now known as bcsaller [17:45] imbrandon: for my oney, you store the whole config in the charm [17:46] and for my money toocurse you high latency [19:29] <_mup_> txzookeeper/managed-watch-and-ephemeral r57 committed by kapil.foss@gmail.com [19:29] <_mup_> session renewal notification, don't track eph sequence nodes, speling comments from review [19:35] <_mup_> txzookeeper/managed-watch-and-ephemeral r58 committed by kapil.foss@gmail.com [19:35] <_mup_> use a separate container node for the no track ephemeral test [19:37] <_mup_> txzookeeper/trunk r47 committed by kapil.foss@gmail.com [19:37] <_mup_> merge managed-watch-and-ephemeral a new auto reconnecting client that recreates presence nodes and triggers watch handlers on session expiration [r=fwereade,jimbaker] [19:49] m_3, ping [19:50] hazmat: pong [19:50] m_3, i just saw r28 on charmrunner.. why did the relation check need to be disabled? [19:50] that's sort of the whole point.. [19:55] hazmat: I'll re-enable it wrt the new schema once environments are working (lp:~mark-mims/charmrunner/with-environment) [19:56] hazmat: it was choking on status [19:58] m_3, on the new status? [20:12] hazmat: yup [20:12] sorry... latency probs atm [20:13] hazmat: there's no relation state there if the relation's good... only on fail [20:13] hazmat: not a hard change, just in the way at the time [20:13] m_3, right but that seems orthognal to the env stuff [20:13] k [20:14] yup... only related by the serial processing queue :) [20:56] m_3, if you use go i'm sure you could do it in parallel ;-) [20:56] :) [20:57] need go for wetware === Furao_ is now known as Furao [23:46] whoohoo!... charm in ec2 is testing charms in ec2... not quite automated yet [23:47] gotta probably write a separate zombie killer script to clean up if there are accidental danglers [23:57] m_3: and maybe use a limited access key that can only spawn a few machines? ;) [23:57] SpamapS: unhuh [23:57] m_3: I'd hate for the graph runner to get crazy with the cheeze whiz and cost you $500 ;) [23:57] s/you/somebody/ [23:57] cripes [23:58] precise is changing faster now than it has all cycle [23:58] every day I sbuild-update and get 15 packages in the base install [23:58] gotta wait until I get a fatter pipe to update