[00:19] <jose> hey guys, any known way to run 1.18 on saucy?
[02:02] <tvansteenburgh> is it legit to call `juju set` from within a charm hook?
[02:03] <tvansteenburgh> for example, if i wanted to change on a config value on the "other" service when a relation is joined
[02:04] <tvansteenburgh> change a config value
[02:14] <marcoceppi> tvansteenburgh: you can't actually do that. Charms can't set configruation for itself or other services
[02:14] <marcoceppi> tvansteenburgh: if you need to commuicate from one charm to another in a deployed environment you should use relation-set and relation-get
[02:14] <marcoceppi> jose: 1.18 isn't released yet
[02:14] <jose> oh
[02:15] <jose> marcoceppi: mind a quick PM?
[02:15] <tvansteenburgh> marcoceppi: thanks
[02:15] <marcoceppi> 1.17.5 is latest devel, 1.16.6 is latest stable
[02:15] <marcoceppi> jose: sure
[03:24] <jose> marcoceppi: hey, do you know approximately how much time does the mysql charm take to set the variables (database, user, password...)?
[03:34] <marcoceppi> jose: not very long, shouldn't take more than a few seconds. If you're thinking about putting a sleep in your script to wait for variables then you're doing something wrong
[03:35] <jose> marcoceppi: that's just what I did
[03:35] <marcoceppi> don't
[03:35] <jose> I did `while [ -z "$DB ]; do sleep 10; done`
[03:35] <marcoceppi> you won't get them, because relation-get variables are locked at the start of the run of the hook
[03:35] <jose> hmm, how should I set it, then?
[03:35] <marcoceppi> they're only updated when a hook is done executing
[03:36] <marcoceppi> use relation-changed hook
[03:36] <jose> instead of a relation-joined?
[03:36] <marcoceppi> right, relation-joined is basically anything you need to do pre-relation
[03:36] <marcoceppi> it's like an initial handshake
[03:36] <jose> cool!
[03:36] <marcoceppi> if you're just waiting for data
[03:36] <jose> (yeah, you read my mind)
[03:36] <marcoceppi> put your code in relation-changed, and add an idempotency guard
[03:37] <jose> a... what?
[03:37] <marcoceppi> like, db=`relationg-get database`; if [ -z "$db" ]; then exit 0; fi
[03:37] <jose> oh, gotcha
[03:37] <marcoceppi> that way, if the relation settings haven't been set the hook will just exit
[03:37] <marcoceppi> and when relation data does change, the hook will fire again
[03:38] <jose> btw, let me say this as I *just* did my first juju (unsuccessful) deploy on EC2: it's AMAZING.
[03:39] <marcoceppi> :D
[03:40] <bodie_> :}
[03:41] <jose> if this does good, then you should be have another charm on the queue
[03:57] <jose> marcoceppi: still around? I'm kinda stuck with a hook
[11:02] <jamespage> marcoceppi, is amulet still pip installing cherrypy?
[11:03] <marcoceppi> jamespage: bleh, yes
[11:04] <marcoceppi> jamespage: next patch will address that
[11:04] <jamespage> marcoceppi, because its not avaliable on 12.04 right?
[11:04] <marcoceppi> right
[11:04] <marcoceppi> well, py3 cherrypy isn't at least
[11:04] <jamespage> marcoceppi, please - I really like the work mbrusek has done on rabbitmq-server for amulet tests
[11:05] <jamespage> but I can't run that on our QA cloud with pip installs....
[11:05] <marcoceppi> right, jamespage i have a 1.4.1 patch release planned for friday, I'll make the change then
[11:05] <jamespage> marcoceppi, thanks - are you dropping the requirement for it?
[11:06] <marcoceppi> jacekn: going to use a web framework that's in archive
[11:06] <marcoceppi> jamespage: ^^
[11:06] <jamespage> marcoceppi, +1
[11:09] <jamespage> marcoceppi, how does amulet choose which series to test on btw?
[11:10] <marcoceppi> jamespage: the test set it (considering the fact that charms are currently tied to series) that might change where series is set by the test runner though
[11:10] <marcoceppi> no one has had a use case for it yet
[11:11] <marcoceppi> jamespage: when you create a new amulet.Deployment you can set series as an option, defaulting to precise
[11:11] <jamespage> marcoceppi, I do - cause althought the branch for the charm is 'precise'
[11:11] <jamespage> it actually works on 12.04->14.04
[11:11] <jamespage> marcoceppi, OK - cool
[11:12] <jamespage> marcoceppi, I can see how I can make that work - thanks!
[11:12] <marcoceppi> jamespage: can you file a bug for amulet about muti-series testing. I'll target it to 1.5
[11:13] <marcoceppi> we'll probably need a way to override via env variable, mobile atm so cant file it myself
[11:25] <jam> vila: just checking in with you that things seem happier on HP for you today
[11:32] <hazmat> jose, ping.. resolved?
[11:32] <vila> jam: thanks for checking ! Things stabilized enough yesterday for me to be able to deploy and use the deployment.
[11:32] <jam> great
[11:33] <vila> jam: being able to use 1.17.5 without uploading it was key. I'm still talking with hp about the upload issue I face
[11:33] <hazmat> marcoceppi, why does amulet need a web app? re cherrypy
[11:33] <hazmat> marcoceppi, oh.. ic.. xmlrpc server is builtin and roughly the same
[12:05] <jose> hazmat: hey, not exactly... if you have a min I have the links around
[12:19] <hazmat> jono, sure
[12:19] <hazmat> er. jose sure
[12:20] <jose> hazmat: so, I deploy https://code.launchpad.net/~jose/charms/precise/phpbb/trunk and install, config-changed and start run good, but when a DB starts a relation with it I get an error when running db-relation-changed, says something about unbound variable on line 18
[12:23] <lazyPower> if anyone has time can i get a +1 on https://code.launchpad.net/~lazypower/charms/precise/nrpe/fix-lp-1287393/+merge/209137 ? I need to land this as a dependency on some other stuff in the queue
[12:24] <jose> oh, morning, lazyPower!
[12:24] <lazyPower> jose: if a variable is reported as unbound, you're referencing it before it's set
[12:25] <hazmat> jose. line 18 you've got an extra > at the end afaics
[12:25] <lazyPower> and good morning :) o/
[12:25] <jose> hmm, let's change that
[12:25] <hazmat> jose,  re http://bazaar.launchpad.net/~jose/charms/precise/phpbb/trunk/view/head:/hooks/db-relation-changed#L18
[12:26] <jose> hazmat: looking at it now! I'm just wondering, does relation-get host with the mysql interface provides the host address? or what's the parameter set?
[12:28] <hazmat> jose host does work for mysql interface
[12:28] <hazmat> the mysql server side  sets database, username, password, host atomically
[12:29] <jose> then I wonder what's the variable not set?
[12:30]  * jose deploys and does debug-hook
[12:37] <jamespage> marcoceppi, hey - when I wrote the percona-cluster charm I decided to default all databases to UTF8
[12:37] <jamespage> marcoceppi, any reason why we should not do the same in mysql?
[12:38] <jamespage> marcoceppi, I was so busy testing pxc with openstack for icehouse b3 I missed https://bugs.launchpad.net/glance/+bug/1279000
[12:38] <_mup_> Bug #1279000: db migrate script to set charset=utf8 for all tables <glance> <Glance:In Progress by lzy-dev> <oslo:In Progress by lzy-dev> <glance (Ubuntu):Triaged> <glance (Ubuntu Trusty):Triaged> <https://launchpad.net/bugs/1279000>
[12:47] <marcoceppi> jamespage: I don't see why not
[13:05] <jose> guys, I'm having a problem when SSH'ing into a machine... looks like juju is getting the private IP instead of the public IP so it never goes through
[13:05] <jose> (using EC2)
[13:09] <lazyPower> thats strange, i've not seen that behavior
[13:09] <lazyPower> jose: how are you attempting to access the unit?
[13:09] <jose> lazyPower: juju ssh phpbb/0
[13:09] <jose> and juju status is the one giving me that info (I'm checking my console atm)
[13:10] <lazyPower> which release of juju are you running?
[13:10] <jose> .16
[13:10] <lazyPower> hmm i dont have a .16 release to check on
[13:10] <jose> I'm going to try adding an entry to my hosts file
[13:10] <jose> that may solve it in the meanwhile
[13:11] <lazyPower> jose: if you can reproduce it, make sure you file a bug on that.
[13:11] <jose> will do - it's not the first time I've seen this
[13:22] <rbasak> mgz: around? I think bug 1248283 is critical for MAAS+juju in Trusty, but it isn't milestoned to make Trusty currently.
[13:22] <_mup_> Bug #1248283: juju userdata should not restart networking <dbus> <deploy> <landscape> <maas-provider> <midway> <ubuntu-openstack> <juju-core:Triaged> <MAAS:Invalid> <dbus (Ubuntu):Invalid> <juju-core (Ubuntu):Triaged> <juju-core (Ubuntu Saucy):Triaged> <juju-core (Ubuntu Trusty):Triaged> <https://launchpad.net/bugs/1248283>
[13:23] <jamespage> fwereade, ^^
[13:29] <mgz> rbasak: looking
[13:31] <mgz> rbasak: I'll set back to 1.18
[13:31] <mbruzek> jamespage, Thanks for the review on the amulet tests, working on addressing the issues now.
[13:31] <rbasak> mgz: thanks!
[13:32] <jamespage> mbruzek, did you see what I was poking at? we should be able to confirm the correct data is set on the relations
[13:32] <jamespage> mbruzek, excitingly I have a full redux in flight for rabbitmq - want to land your tests first tho!
[13:32] <mbruzek> Honestly did not, but running them now to see what ceph is passing on the relation
[13:33] <mgz> I think our issue with that bug is we're actually not sure what to change on the juju-core side... or we have already poked it and our change didn't work, we tried moving when the bridge-utils package gets installed for... basically that reason?
[13:33] <mgz> but the last comment looks hopeful
[13:34] <mbruzek> jamespage, What key should I be looking for in the ceph relation?  Is it actually called "key"?
[13:34] <jamespage> mbruzek, look for 'key' and 'auth'
[13:35] <mbruzek> jamespage, Running the tests now to get that.
[13:35] <jamespage> mbruzek, where does stdout go? I could not see the print statement anywhere
[13:37] <mbruzek> It depends upon how you run them.  If you are running juju test 20_relations_test.py  you need the -v flag
[13:37] <jamespage> ah - right I see
[13:37] <mbruzek> I run them differently so the systems are still up after the test is done.
[13:38] <mbruzek> juju test  <test name> both bootstraps and destroys environment
[13:42] <mbruzek> jamespage, http://pastebin.ubuntu.com/7119833/
[13:43] <jamespage> mbruzek, amqp stuff looks good - however the ceph cluster isnot bootstrapped so it won't send the keys
[13:44] <mbruzek> Ahh I see now, thank you for pointing that out.
[13:44] <lazyPower> dosaboy: are you around?
[13:51] <dosaboy> lazyPower: otp but yes go ahead
[13:52] <lazyPower> dosaboy: i noticed the MP we have reviewed is getting quite a bit of back and forth. touching base with you so we can find a middle fo the road resolution without the delay.
[13:55] <bloodearnest> howdy. Is there a way for a charm to respond when a floating ip is added?
[13:55] <bloodearnest> like, does it automatically fire any realtion-changed hooks with a public-address?
[13:55] <lazyPower> bloodearnest: floating ip on which provider? elasticip from AWS?
[13:55] <mbruzek> bloodearnest, How would the charm know when that changes?
[13:55] <lazyPower> mbruzek: good point!
[13:56] <bloodearnest> mbruzek: indeed, I didn't think so (though that would be ideal from the charms pov, no?)
[13:56] <bloodearnest> lazyPower: openstack
[13:56] <mbruzek> If something changes on the relation, a *-relation-changed gets fired yes, but what would trigger that
[13:56] <bloodearnest> lazyPower: but, interested in the general
[13:56] <lazyPower> bloodearnest: since juju doesn't spend cycles monitoring the ip table of the machine, i dont think thats in the cards
[13:57] <mbruzek> bloodearnest, I supposed one could write a daemon that checks the ip, and if somthing changes trigger a relation-changed event or something of that nature
[13:57] <bloodearnest> mbruzek: right, and that would now include a public-address automatically? Or would you need to provide it explicitly?
[13:57] <bloodearnest> mbruzek: ack, was thinking along those lines
[13:57] <bloodearnest> or set the ip manually as a config (ugh)
[13:57] <mbruzek> bloodearnest, I would have to check, but I believe that the  private address is often part of the relation-changed information.
[13:58] <lazyPower> ^
[13:58] <mbruzek> So if you could somehow detect that the ip changed you could fire the relation changed juju event and it would get sent to the related charms.
[13:59] <marcoceppi> bloodearnest: you could write an out of band check
[13:59] <marcoceppi> but there is no mechanism in juju that i know of
[14:00] <bloodearnest> marcoceppi: yeah, I thought so. Just wanted to check if I was missing something.
[14:00] <bloodearnest> maybe when juju grows a network abstraction, perhaps
[14:01] <marcoceppi> bloodearnest: its a compellimg case for a unit-changed hook
[14:01] <bloodearnest> marcoceppi: WANT
[14:01] <bloodearnest> that could do volume changes too. nice.
[14:02] <marcoceppi> bloodearnest: you shoild file a bug about ot on core. afaik juju has no way of tracking unit changes, inclidimg address, but given your use case it would make sense
[14:02]  * marcoceppi is typing from a phone :\\
[14:03] <dosaboy> lazyPower: sorry lots of calls :(
[14:03] <dosaboy> lazyPower: so can you remind me which MP this is?
[14:03] <lazyPower> dosaboy: perfectly ok. ping me when you're off the phone?
[14:03] <dosaboy> mysql per chance?
[14:03] <lazyPower> indeed
[14:03] <bloodearnest> marcoceppi-mobil: ack, will do
[14:04] <bloodearnest> is there a hack to trigger a hook context from a cron job in 1.16 (i.e. what juju-run does in 1.17)?
[14:05] <marcoceppi-mobil> bloodearnest: not without a lot of work
[14:08] <bloodearnest> marcoceppi-mobil: right. 1.18 is due like RealSoonNow™, so maybe I can convince IS to use that in prod :)
[14:08] <marcoceppi-mobil> bloodearnest: that's whati would do
[14:14] <zchander> HI, is anyone familiar with preseed settings for MaaS? I want to partition a disk while commissioning
[14:19] <bloodearnest> marcoceppi-mobil: https://bugs.launchpad.net/juju-core/+bug/1294673
[14:19] <_mup_> Bug #1294673: Support hook for handling unit changes (like public IP address) <juju-core:New> <https://launchpad.net/bugs/1294673>
[15:19] <Fishy_> juju ssh only goes to service, not machine?  So if I kill a service (but the machine is still up), no juju way to ssh in?
[15:23] <lazyPower> Fishy_: just give it the machine #
[15:24] <lazyPower> eg: to ssh to machine 1 - juju ssh 1
[15:25] <bbcmicrocomputer> any idea when the OpenStack charms are going to appear for Trusty?
[15:26] <marco-traveling> bbcmicrocomputer: ask jamespage
[15:27] <marco-traveling> afaik they already work on trusty, just need to promulgate the as such
[15:27] <bbcmicrocomputer> marco-traveling: k, cool
[15:27] <Fishy_> juju ssh 1 Permission denied (publickey,password). ERROR exit status 255
[15:28] <Fishy_> (whereas juju ssh wordpress is fine)
[15:28] <mgz> Fishy_: which provider?
[15:28] <Fishy_> local
[15:29] <mgz> local you can only use the units
[15:29] <marco-traveling> Fishy_: is this local provider?
[15:29] <mgz> Fishy_: bug 1233497
[15:29] <Fishy_> blah ;)
[15:31] <Fishy_> that bug is about a password protected ssh key, mine is wide open
[15:31] <Fishy_> maybe same root cause though
[15:32] <mgz> yeah, should be another bug too somewhere
[15:42] <bloodearnest> marco-traveling: so, my bug is duplicate of https://bugs.launchpad.net/juju-core/+bug/1215579
[15:42] <_mup_> Bug #1215579: Address changes should be propagated to relations <addressability> <juju-core:Triaged> <https://launchpad.net/bugs/1215579>
[15:48] <jamespage> bbcmicrocomputer, probably at or around the time trusty releases
[15:48] <jamespage> bbcmicrocomputer, if you want to test the branchs are all under ~openstack-charmers
[15:49] <jamespage> bbcmicrocomputer, /icehouse suffix
[15:50] <bbcmicrocomputer> jamespage: k, thanks
[15:51] <jamespage> bbcmicrocomputer, oh and just to be clear - the precise charms will be the trusty charms
[15:51] <jamespage> so don't look for 'trusty' in the branch path
[15:51] <bbcmicrocomputer> jamespage: k :)
[16:23] <Fishy_> whats it mean if I see 3 charms with the same name in the charm store, but none under reccomended.. and none work from a juju deploy command line?
[16:23] <Fishy_> some kind of beta charm that hasn't been approved yet?
[16:24] <Fishy_> i.e.   Location: cs:~canonical-ci/precise/gerrit-59
[16:24] <Fishy_> deploy did finally work, ignore me
[16:24] <Fishy_> need full path i guess
[16:27] <rick_h_> Fishy_: so charms can be customized for various users
[16:27] <rick_h_> Fishy_: so you'll often see copies of a charm that a user is working on or with
[16:28] <rick_h_> Fishy_: in this case, you found the charm used by ~canonical-ci
[16:28] <Fishy_> the source link didn't work for these though.. is there a normal procoedure to take one of these and grab the source?
[16:28] <Fishy_> so I can tweak for my own needs
[16:29] <Fishy_> https://bazaar.launchpad.net/~canonical-ci/charms/precise/gerrit/trunk/files
[16:29] <Fishy_> no worko
[16:29] <rick_h_> Fishy_: there's a thing in charm tools called 'charm get'
[16:29] <rick_h_> where you get give it a cs: url and get the downloaded charm
[16:29] <Fishy_> nice
[16:30] <rick_h_> Fishy_: oh hmm, that's not public. I wonder why that got pulled in
[16:34] <Fishy_> the entire charm isnt supposed to be or just the source url
[16:34] <rick_h_> Fishy_: I'm looking into it.
[16:34] <rick_h_> Fishy_: you've hit some edge case and I'll need to look into how it got this way
[16:34] <rick_h_> it's not typical
[16:34] <Fishy_> apparently I am good at edge cases with juju
[16:35] <rick_h_> stick around, we like finding those. :)
[16:35] <Fishy_> if I move my entie infastructure over to juju land, I will be here a few months...
[16:36] <lazyPower> we like the sounds of that Fishy_
[16:36] <Fishy_> next up is try to write my own charm for an internal app
[16:36] <Fishy_> if it's not too bad, then I just need to do it 50 more times
[16:37] <lazyPower> Fishy_: we also have a testing tool for validating your charms are doing what you expect them to
[16:37] <lazyPower> Amulet to the rescue!
[16:37] <Fishy_> What testing tool?
[16:37] <lazyPower> Fishy_: https://juju.ubuntu.com/docs/tools-amulet.html
[16:38] <lazyPower> if you need test examples, mbruzek wrote an excellent amulet test in the memcached charm
[16:38] <lazyPower> he's also got some solid work in rabbit-mq
[16:38] <Fishy_> nice
[16:39] <Fishy_> is it insane to try and use "Subordinate services" as kind of mix in behavior?
[16:39] <Fishy_> like say I have a home-rolled backup service I write...  then have 10 charms, all using my backup service
[16:40] <lazyPower> not at all. I wrote a subordinate for papertrail-app (a PAAS log aggregator service)
[16:40] <lazyPower> because I didn't want to pay/manage my own logging infrastructure
[16:41] <lazyPower> I've used it in 3 production deployments thus far, managing a total of 52 hosts.
[16:41] <bloodearnest> Fishy_: that's the idea, there is a backup subordinate already around somewhere, but not in the store yet I think
[16:41] <lazyPower> i throw those metrics in there because it makes me feel special.
[16:41] <Fishy_> haha
[16:43] <Fishy_> just need to see how it works mixing in to stuff people already wrote.. I see how it would be easy for my own charms to all put data in a common place so a backup subordinate could grab it..   harder to see how my charm would work on say a wordpress charm vs a mysql charm vs a postgresql charm
[16:43] <Fishy_> without devolving into a   if postgress:  <>  else if mysql <>
[16:45] <bloodearnest> Fishy_: the backup subordinate has a relation that the primary charm can implement to tell it what to back up
[16:45] <Fishy_> ok so then i would need to write my own version of postgresql that supports fishy-backup
[16:45] <Fishy_> which seems reasonable
[16:46] <Fishy_> except how to deal with upstream postgresql charm changes
[16:46] <Fishy_> part of what is nice about using a precanned charm is to get the upstream fixes
[16:51] <bloodearnest> Fishy_: heh, I would like to use a charm called fishy-backup :)
[16:52] <bloodearnest> Fishy_: fork and pull changes periodically works pretty well, especially in your case where you would probably not alter the upstream functionality, but add new stuff
[16:54] <Fishy_> ya that's true
[16:54] <Fishy_> would at least be an easy merge
[16:58] <lazyPower> yeah we catch most of the schenanigans during peer review
[16:58] <bloodearnest> Fishy_: we do that for all charms, and deploy from a local repo. We don't deploy from the charmstore at all
[17:01] <Fishy_> and juju download is the start of it?  or do you go and find the actual svn/git repo
[17:01] <Fishy_> assume juju download is just a snapshot and not a repo?
[17:02] <lazyPower> Fishy_: in what context do you mean? charm get? that fetches teh current snapshot from wherever the parent branch of the charm is located.
[17:04] <Fishy_> i dont think charm get exists
[17:04] <Fishy_> in stable juju
[17:07] <rick_h_> Fishy_: it's in charm-tools package. You have to install that on its own
[17:10] <Fishy_> genius
[17:11] <marco-traveling> bbcmicrocomputer: i still think unit-changed would be a sweet hook
[17:19] <Fishy_> wow people still use bzr
[17:24] <bbcmicrocomputer> marco-traveling: what happened to charm-helper-sh?
[17:55] <marco-traveling> bbcmicrocomputer: it was depricated
[17:56] <marco-traveling> bbcmicrocomputer: only available on precise and in a PPA, but probably won't be going to trusty
[17:57] <bbcmicrocomputer> marco-traveling: ah ok, thanks
[17:57] <marco-traveling> bbcmicrocomputer: if you need the ppa, I think ~charmers owns it
[17:57]  * marco-traveling goes and looks
[17:57] <bbcmicrocomputer> marco-traveling: ah no worries, it was just my curiosity asking
[17:58] <marco-traveling> bbcmicrocomputer: really, we're pushing charm-helpers (v2) instead, which will have something soon for charms in shell
[17:58] <bbcmicrocomputer> marco-traveling: ah nice!
[18:20]  * alexisb has just deployed her first service in the cloud using juju
[18:20] <sarnold> woo :)
[18:20] <alexisb> very good documentation did not take long to figure out, cool stuff
[18:21] <sarnold> isn't that fun? :)
[18:21] <sarnold> "ooh I just made a VM spin up a few hundred miles away and now it is doing my bidding!"
[18:21] <alexisb> it *was* fun :)
[18:41] <marco-traveling> alexisb: glad you had a good experience! Feel free to ask here if you have any questions :D
[18:43] <sarnold> wallyworld: your connection is bouncing
[18:53] <alexisb> marco-traveling, thank you and will do
[19:15] <jose> guys, if I want my hook to run a python script which does not go to background, how should I do it?
[20:00] <marco-traveling> jose: do you want the hook to block or not on the script? If the former, then just run it, if the latter write an upstart script
[20:00] <jose> uh oh, I think not, I'll check how to write an upstart script then
[20:02] <jose> marco-traveling: that phpbb charm I was writing, I'll need to stop as the feature we're looking for to get the DB info in place is not there yet
[20:02] <jose> but the base is there, maybe in the future I can re-do it
[20:03] <marco-traveling> jose: upstart is pretty simple if you need any help #upstart or ping me
[20:03] <jose> cool, thanks!
[20:07] <jose> marco-traveling: would a charm be approved if the user has to go and manually get the database values and set them by itself?
[20:07] <ev> does the charm hook context not pull in /etc/environment?
[20:09] <marco-traveling> jose: yeah, that won't fly
[20:09] <marco-traveling> ev: probably/maybe not?
[20:10] <ev> boooo
[20:25] <webbrandon> any juju contest going on?
[20:34] <marco-traveling> webbrandon: not at the moment
[20:36] <webbrandon> :( `
[20:55] <marco-traveling> webbrandon: there's an Ubuntu Touch app development competition going on
[20:58] <ev> marco-traveling, others: what's the preferred way of setting some environment data for all charms in a deployment? Say I'm at a very security conscious company and they have a http proxy for all traffic. I cannot just set the juju http-proxy config option because juju doesn't also have a no_proxy setting for putting the IPs of swift, glance, etc in.
[20:58] <marco-traveling> ev: uh, that's a good question
[20:59] <marco-traveling> ev: so, there's set-environment, but that's really only for the juju deployed environment
[20:59] <marco-traveling> not like, environment variables
[20:59] <marco-traveling> or, maybe that command does do that
[20:59] <marco-traveling> ev: let me check
[21:01] <marco-traveling> ev: yeah, not, it's just to modify the juju environment, not environment variables
[21:02] <marco-traveling> ev: so, my first though it like a proxy subordinate, that can talk you can set filter based rules on
[21:02] <marco-traveling> err, not subordinate, service
[21:03] <marco-traveling> so set http proxy to this deployed service, then update it's configuration with filtering rules on which ips to send to the actual proxy and which shouldn't be
[21:03] <marco-traveling> but that sounds messy
[21:04] <ev> marco-traveling: I have the ability to bake the image
[21:04] <ev> but I need to know where to stick http_proxy https_proxy, socks_proxy, no_proxy, etc so juju respects them
[21:05] <ev> as when I put them in /etc/environment in the baked image, it didn't find it's way into the environment for $charm/hooks/hooks.py
[21:05] <ev> oh
[21:05] <marco-traveling> ev: I'd ask around in #juju-dev
[21:05] <ev> okay, thank you
[21:05] <marco-traveling> There might be a place that you can place these environment variables within juju that the hooks will pick it up
[21:36] <Fishy_> install is ran by user root, but start is run by user ubuntu?
[21:36] <Fishy_> is that the convention
[21:36] <Fishy_> or anything except install is run by ubuntu
[21:36] <peterklipfel> hi all, I made an oops, and now I have a mess. I accidentally spun up too many lxcs, my computer exploded, so I killed all the juju processes and deleted the lxcs. When I run juju status, I see a bunch of non-existent containers. The processes are still around, but they won't die (I assume there's a daemon respawning them). How do I reset everything?
[21:36] <Fishy_> sudo juju destroy-environment
[21:37] <peterklipfel> Fishy_: that doesn't work. I get "ERROR failed to rename container directory"
[21:38] <Fishy_> next time dont delete stuff by hand ;) messed somethin up
[21:41] <Fishy_> have not seen that error though
[21:41] <Fishy_> (yet)
[21:42] <Fishy_> for juju could just blow away ~/.juju directory
[21:42] <lazyPower> peterklipfel: use --force
[21:42] <Fishy_> but lxc has stuff elsewhere
[21:42] <lazyPower> peterklipfel: juju destroy-environment local --force
[21:42] <peterklipfel> ok. Actually, I was almost there. I just had to go in and manually recreate the directories (empty) and then run destroy-environment until it succeeded
[21:43] <peterklipfel> the --force flag made juju complain. It doesn't recognize it
[21:43] <lazyPower> peterklipfel: are you on the 1.16 series of juju?
[21:43] <peterklipfel> lazyPower: yes
[21:43] <lazyPower> ah ok, thats a recent convention
[21:43] <lazyPower> hang on there are instructions for cleaning up a broken local install
[21:43] <lazyPower> 1 moment while i fetch them
[21:44] <lazyPower> peterklipfel: http://askubuntu.com/questions/403618/how-do-i-clean-up-a-machine-after-using-the-local-provider
[21:45] <peterklipfel> lazyPower: thanks!
[21:45] <lazyPower> peterklipfel: np, let me know if you run into any issues. I've gotten my hands dirty quite a few times with LXC  misbehaving
[22:10] <Fishy_> how do I tell the juju that I have something running on port 80
[22:10] <Fishy_> so it shows up on status
[22:10] <Fishy_> and gets exposed
[22:11] <Fishy_> provides:   website: http
[22:11] <lazyPower> Fishy_: open-port exposed
[22:11] <lazyPower> er
[22:11] <lazyPower> wow
[22:11] <Fishy_> ?
[22:11] <lazyPower> Fishy_: open-port 80 in your hooks.
[22:11] <Fishy_> start hook?
[22:11] <Fishy_> or install
[22:11] <lazyPower> that works.
[22:11] <Fishy_> i guess install
[22:11] <lazyPower> I typically put them in config-changed if i have an ssl option so i can switch the ports on the fly
[22:12] <lazyPower> or if there is a port setting, i can react on it. but if its always going to be port 80, put it wherever it makes sense.
[22:12] <marco-traveling> Fishy_: you typically want to open-port when the service is ready to be used
[22:12] <Fishy_> open-port : command not found
[22:12] <Fishy_> I am in bash land
[22:12] <lazyPower> Fishy_: it has to be executed within hook-running context
[22:12] <marco-traveling> Fishy_: so if after installation its ready, install hook. If you have to start the service, then start hook, if it requires a database, then the db-relation-changed hook
[22:13] <Fishy_> o okay
[22:13] <Fishy_> not ready till start happens
[22:13] <marco-traveling> Fishy_: then open-port 80 in the start hook should suffice
[22:13] <Fishy_> config changed is good idea when I tie it to the config
[22:14] <Fishy_> but thats step 11
[22:14] <marco-traveling> Fishy_: yeah, like lazyPower said, if you can configure the port then it should /definitely/ be in the config-changed hook instead
[22:14] <marco-traveling> but as you mentioned, you can iterate on that later
[22:14] <Fishy_> is the juju master node a single point of failure in this whole operation?
[22:14] <marco-traveling> Fishy_: it is at the moment, we have HA landing for the bootstrap node in the next week or two
[22:15] <marco-traveling> Fishy_: and it's a point of failure in terms of controlling the environment, if the bootstrap node goes down the other services will continue to run
[22:15] <marco-traveling> you just wont' be able to orchestrate anymore (deploy, relate, expose, destroy, etc)
[22:16] <Fishy_> and if i brought it back up, it wouldnt re-discover what was done
[22:17] <Fishy_> so potentially lost track of what my machines are doing
[22:19] <Fishy_> cool open-port works
[22:19] <marco-traveling> Fishy_: well, if you rebooted the node
[22:19] <marco-traveling> Fishy_: it would pick up where it left off
[22:19] <marco-traveling> like, if there was a networking outage or something similar
[22:20] <marco-traveling> but if it was deleted, then there's really no way to recover from that at the moment
[22:20] <marco-traveling> with HA you'll be able to deploy and scale your bootstrap node, so if you wanted HA you could have three bootstrap nodes, if one goes down the other two will continue serving
[22:21] <Fishy_> ya that would be good long term
[22:21] <Fishy_> for sure
[22:21] <Fishy_> master - slave ?
[22:21] <Fishy_> or can i run commands from any of them
[22:24] <marco-traveling> Fishy_: well, you don't run commands from the bootstrap nodes
[22:24] <marco-traveling> Fishy_: the bootstrap nodes expose an API server that the CLI and GUI, etc talk to
[22:29] <Fishy_> ya but can you talk to all 3 of the HA
[22:29] <Fishy_> or just 1
[22:45] <marco-traveling> Fishy_: all three, but juju will just select one
[23:23] <bodie_> do I really need to use the gophers/go PPA to get lbox or can I just go get launchpad.net/lbox?
[23:40] <marco-traveling> bodie_: the latter is better