[00:33] <adam_g> using PPA, is 'instance-state' meant to reach the 'started' state, or stop at 'provisioned' ?
[00:40] <hazmat> adam_g, started
[00:41] <hazmat> robbiew, cool, good to know thanks
[00:43] <adam_g> 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] <hazmat> adam_g, hmm.
[00:45] <hazmat> adam_g, looking at the orchestra provider, it looks like its either 'provisioned' or 'pending'
[00:45] <hazmat> so no 'started' staet..
[00:45] <hazmat> probably worth a trivial for consistency
[00:46] <hazmat> except its not really checking that the machine is started
[00:46] <adam_g> 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] <hazmat> adam_g, apparently not.. does orchestra provide that info?
[00:48] <hazmat> the code reads.. state = "pending" if d["netboot_enabled"] else "provisioned"
[00:48] <hazmat> not sure what other info is available from cobbler wrt to the actual state
[00:50] <hazmat> interesting yet another cobbler fork.. http://code.google.com/p/madhatter/
[00:53] <hazmat> 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] <SpamapS> cobbler only knows that it has been setup for pxe boot
[00:54] <SpamapS> and can be asked what the power state is *if* it has power control setup
[00:54] <jcastro> SpamapS: hey, my mini proliant came in
[00:54] <jcastro> you want one
[00:54] <jcastro> it is SO cute.
[00:55] <jcastro> I think everyone should have one
[00:57] <marcoceppi> I know what the charm contest winners can put their gift card towards
[01:01] <adam_g> those mini proliants are great
[01:01] <adam_g> and cheap
[01:13] <bkerensa> adam_g: but are they energy efficient?
[01:15] <bkerensa> oo 150W
[01:15] <bkerensa> two PCI slots so you could turn it into a little RADIUS box
[08:38] <yolanda> 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
[09:25] <yolanda> 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]
[12:03] <yolanda> hi, what's correct way of restarting a service in a juju charm?
[12:03] <yolanda> i have something like that:
[12:03] <yolanda> # restart service
[12:03] <yolanda> service openerp-core start || service openerp-core restart
[12:04] <yolanda> 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] <yolanda> hi, need help with a juju charm, i'm having problems restarting a service
[12:26] <sc-rm> 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] <yolanda> sc-rm, there is an openerp-core service, that is started on the install hook
[12:26] <yolanda> and in the db-relation-changed, i try to restart it
[12:27] <yolanda> because i need some changes to be applied on a config file
[12:28] <marcoceppi> yolanda: How is it started in the start hook?
[12:28] <marcoceppi> err, in the install hoook*
[12:28] <sc-rm> 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] <yolanda> sc-rm, yes
[12:30] <yolanda> the service is started automatically when installed the package
[12:30] <yolanda> 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] <sc-rm> 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] <yolanda> 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] <yolanda> then if i do the service openerp-core start it works, and after that i can restart correctly
[12:36] <yolanda> seems that there is some problem between install and db-config-changed hooks
[12:36] <sc-rm> 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] <sc-rm> the openrp-core script in init.d is that something you created and is it public accessible?
[12:42] <yolanda> sc-rm, the openerp-core is a package that we are writing for openerp 6.1 version
[12:42] <yolanda> i can send you the url for you to check it
[12:53] <yolanda> sc-rm, code for the package is here: https://code.launchpad.net/~openerp-community/openerp-tools/yolanda.robla-openerp-core
[13:10] <yolanda> sc-rm, any idea?
[13:46] <yolanda> 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] <sc-rm> 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] <yolanda> let me test
[14:17] <yolanda> sc-rm, pid is the same in /var/run/openerp-server.pid as the ps
[14:22] <al-maisan> Can I use environment variables in environments.yaml? E.g. for secret keys?
[14:22] <yolanda> 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] <yolanda> so i'm not able to kill old process and start new
[14:27] <yolanda> 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] <yolanda> when i run it, pid in ps remains the same, but pid in /var/run/openerp-server.pid changes
[14:27] <yolanda> and process isn't restarte
[14:27] <yolanda> restarted
[14:36] <avoine> yolanda: it should not be: service openerp-core start && service openerp-core restart
[14:36] <avoine> because you want to restart only if the start doesn't worked
[14:36] <yolanda> yes
[14:37] <yolanda> well, the start should not work because process should be already started by the last step
[14:37] <avoine> oh no, your right
[14:38] <avoine> my logic fail in the morning
[14:39] <yolanda> 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] <al-maisan> hmm .. did anubody see a "ERROR Invalid SSH key" upon sudo juju status -e oneiric-aws? The bootstrap command finished successfully
[14:40] <al-maisan> anybody even
[14:40] <yolanda> 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] <marcoceppi> al-maisan: do you have either an id_rsa.pub or id_dsa.pub in your .ssh folder?
[14:41] <avoine> yolanda: maybe a permission problem
[14:41] <al-maisan> marcoceppi: I have a symbolic link as follows: " id_rsa.pub -> juju_rsa.pub"
[14:41] <al-maisan> in ~/.ssh
[14:42] <yolanda> avoine, the process is running as openerp user, perhaps is that?
[14:42] <yolanda> but it's the same also if i run as root
[14:42] <marcoceppi> al-maisan: that error is usually indicative of your public key not be copyied to the bootstrap
[14:42] <avoine> yolanda: if it's an upstart script it should not be a problem
[14:43] <al-maisan> marcoceppi: removed the symbolic links and renamed the files, trying again
[14:43] <yolanda> yes it is
[14:43] <marcoceppi> 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] <avoine> yolanda: have you try  start openerp-core || restart openerp-core just in case
[14:44] <al-maisan> marcoceppi: will try
[14:45] <yolanda> avoine, unknown job
[14:45] <avoine> hum
[14:46] <al-maisan> hmm .. marcoceppi .. made no difference .. still getting "ERROR Invalid SSH key"
[14:46] <marcoceppi> al-maisan: are you using the juju PPA?
[14:46] <al-maisan> I am on 12.04 and using the juju package
[14:47] <al-maisan> marcoceppi: I also get this: http://pastebin.ubuntu.com/924951/
[14:47] <al-maisan> is that normal?
[14:48] <marcoceppi> al-maisan: yes
[14:52] <al-maisan> hmm .. no luck .. I get the "ERROR Invalid SSH key" no matter what I try
[14:53] <al-maisan> .. and I am supposed to demo this in 2 hours :-P
[14:55] <al-maisan> marcoceppi: I see that jdstrand had a similar problem http://irclogs.ubuntu.com/2012/03/22/%23juju.txt
[14:55] <marcoceppi> al-maisan: can you log in to ec2 get the address for the bootstrap and try to ssh -vv ubuntu@ec2url ?
[14:55] <al-maisan> will try
[14:56] <al-maisan> debug1: connect to address 50.19.3.207 port 22: Connection refused
[14:57] <marcoceppi> al-maisan: that looks like a bug, but it might already be fixed in the PPA
[14:58] <al-maisan> I am running Version: 0.5+bzr504-0ubuntu1
[14:58] <al-maisan> should I install from the PPA?
[14:58] <marcoceppi> Try the ppa, and add "origin: ppa" to the environments stanza you're using
[14:58] <hazmat> al-maisan, can you pastebin the console output from the instance?
[14:58] <marcoceppi> *in the interest of getting it ready for your demo*
[14:59] <al-maisan> I try "ec2-get-console-output i-84af18e3"
[14:59] <al-maisan> Only getting:
[14:59] <al-maisan> i-84af18e3
[14:59] <al-maisan> 2012-04-11T14:59:12+0000
[14:59] <al-maisan> quietsch ~ $
[15:00] <al-maisan> ignore the last line please
[15:01] <al-maisan> OK .. upgraded to 0.5+bzr519-1juju5~precise1
[15:01] <marcoceppi> al-maisan: make sure to update your environments.yaml file to use ppa as well
[15:01] <al-maisan> yup
[15:13] <yagey> monring.  is there a way to juju ssh into the bootstrap host?   I apparently need to run some lxc apt updates
[15:13] <marcoceppi> yagey: juju ssh 0
[15:14] <al-maisan> 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] <yagey> 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] <al-maisan> marcoceppi: "juju ssh 0" gets me into  the aws instance..
[15:15] <marcoceppi> al-maisan: does juju status work?
[15:16] <al-maisan> yes!
[15:16] <al-maisan> now it works
[15:16] <marcoceppi> al-maisan: success! you should be good to go for your demo
[15:16] <al-maisan> yeah !!
[15:16] <marcoceppi> yagey: have you restarted since the last time you tried to connect?
[15:16] <al-maisan> marcoceppi: thanks for your help!
[15:17] <yagey> rebooted? I'm using lxc, won't that kill the bootstrap instance?
[15:19] <marcoceppi> yagey: it will, I was just making sure you haven't
[15:19] <al-maisan> marcoceppi: I think I know what went wrong all the time: I was using *sudo* with juju all the time :-P
[15:20] <marcoceppi> al-maisan: ah! that would probably be the reason, good to know it wasn't a bug *bug* :)
[15:20] <al-maisan> yeah .. sorry for the noise :-/
[15:22] <yagey> 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] <yagey> 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] <marcoceppi> yagey: one of your charms isn't updated properly.
[15:44] <marcoceppi> Or the tomcat7 isn't updated. Let me check it
[15:46] <marcoceppi> Interesting, which version of juju are you using yagey?
[15:49] <yagey> whichever apt-get installed
[15:50] <yagey> how can I tell?
[15:52] <marcoceppi> dpkg -l | grep juju
[15:52] <yagey> 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] <marcoceppi> that's a pretty old version of juju, I don't think it has the updated types since boolean was added later
[15:55] <marcoceppi> which is why it's saying expected string when it got boolean for the multicast configuration option in tomcat7
[15:56] <yagey> ok.  upgrade from the ppa?
[15:56] <marcoceppi> upgrading juju from that version to latest will likely break your current deployment though
[15:56] <marcoceppi> so if you're okay with re-boostrapping then yes
[16:33] <imbrandon> 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] <imbrandon> 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] <imbrandon> ( or anyones feedback )
[16:36] <marcoceppi> dropping a configuration file from 8 months in the past against an updated package is just as reckless
[16:36] <imbrandon> no, not if there is no abi change
[16:36] <marcoceppi> with a greater chance for breakage as it does not account for changes to the package
[16:37] <imbrandon> much less chance, its been tested, the latter way has not, thus less
[16:42] <imbrandon> 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] <imbrandon> 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] <imbrandon> not the package mantainer
[16:44] <marcoceppi> imbrandon: if you know you always need show-errors off then you should make sure it's set via the install hook
[16:44] <imbrandon> sure, and i do as well as every other value
[16:44] <imbrandon> by the whole conf
[16:44] <imbrandon> known state
[16:44] <marcoceppi> won't scale, and does not smell like a best practice to me
[16:44] <imbrandon> it scales every day
[16:44] <imbrandon> its called debian packageing
[16:45] <imbrandon> it works the same way
[16:45] <imbrandon> damn near every deb drops their config in place
[16:46] <imbrandon> for much the same reason
[16:46] <imbrandon> like i said if thats the default now, i cannot garentee its the default alwys
[16:46] <imbrandon> just as you point out
[16:46] <imbrandon> so i need to make sure by setting all values
[16:48] <imbrandon> thats why you get the little popup when debconf see's changes to files in /etc
[17:13] <hazmat> there's a reason that charms have series in their qualified name
[17:29] <imbrandon> hazmat: sure thats holds up if all the software is installed via the package mgmt sysxtem and not git or gotdeb or src :)
[17:45] <SpamapS> imbrandon: for my oney, you store the whole config in the charm
[17:46] <SpamapS> 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] <hazmat> m_3, ping
[19:50] <m_3> hazmat: pong
[19:50] <hazmat> m_3, i just saw r28 on charmrunner.. why did the relation check need to be disabled?
[19:50] <hazmat> that's sort of the whole point..
[19:55] <m_3> hazmat: I'll re-enable it wrt the new schema once environments are working (lp:~mark-mims/charmrunner/with-environment)
[19:56] <m_3> hazmat: it was choking on status
[19:58] <hazmat> m_3,  on the new status?
[20:12] <m_3> hazmat: yup
[20:12] <m_3> sorry... latency probs atm
[20:13] <m_3> hazmat: there's no relation state there if the relation's good... only on fail
[20:13] <m_3> hazmat: not a hard change, just in the way at the time
[20:13] <hazmat> m_3,  right but that seems orthognal to the env stuff
[20:13] <hazmat> k
[20:14] <m_3> yup... only related by the serial processing queue :)
[20:56] <hazmat> m_3, if you use go i'm sure you could do it in parallel ;-)
[20:56] <m_3> :)
[20:57] <m_3> need go for wetware
[23:46] <m_3> whoohoo!... charm in ec2 is testing charms in ec2... not quite automated yet
[23:47] <m_3> gotta probably write a separate zombie killer script to clean up if there are accidental danglers
[23:57] <SpamapS> m_3: and maybe use a limited access key that can only spawn a few machines? ;)
[23:57] <m_3> SpamapS: unhuh
[23:57] <SpamapS> m_3: I'd hate for the graph runner to get crazy with the cheeze whiz and cost you $500 ;)
[23:57] <SpamapS> s/you/somebody/
[23:57] <SpamapS> cripes
[23:58] <SpamapS> precise is changing faster now than it has all cycle
[23:58] <SpamapS> every day I sbuild-update and get 15 packages in the base install
[23:58] <m_3> gotta wait until I get a fatter pipe to update