[13:37] <beisner> hi jamespage, can you review c-h mp? @ https://code.launchpad.net/~1chb1n/charm-helpers/charm-helpers.liberty-fetch-init/+merge/267515 - fixes invalid install source re: liberty, also adds a couple of amulet helpers for updated test WIPs.
[13:42] <jcastro> jose: ah nuts I missed sebas
[13:42] <jcastro> jose: the talk looks awesome, though, I suck at Spanish!
[14:26] <jose> jcastro: hey, it's good that we have it recorded! you can always try using the automatic spanish CC on youtube and then the English translation
[15:00] <mbruzek> jose:  How did your conference go?
[15:01] <jose> mbruzek: it was super awesome! I didn't get to catch much of the sessions as I was running around, but it was great
[15:01] <jose> people left the auditorium with a big smile :)
[15:01] <mbruzek> jose:  awesome
[15:01] <mbruzek> jose: Yeah you really can't enjoy the events you are organizing, I know that too
[15:01] <mbruzek> Jose link to vids?
[15:02] <jose> mbruzek: youtube.com/ubuntuonair, scroll down a bit and there's an ubuconla+ playlist
[15:02] <mbruzek> ok
[15:03] <jose> oh, and seb's talk is there too!
[15:03] <mbruzek> I see that, how did you say to translate?
[15:04] <beisner> wolsen, can you confirm an observation?:   enabling ssl in the rmq charm is a one-way deal.  ie. hooks aren't present for disabling ssl once enabled.
[15:23] <lazyPower> ouch
[15:24] <lazyPower> that seems like we broke a cardinal rule there beisner
[15:25] <beisner> lazyPower, yeah, ran into this while test writing.  tests want to flip ssl on and off and run some of the same checks with it enabled and disabled.  i can turn it on ok ;-)
[15:26] <lazyPower> you do good work my man
[15:27] <beisner> same @ ya, lazyPower
[15:28] <beisner> wolsen, lazyPower - actually, turn-it-off logic is there, but it leaves the key files behind.  probably should clean those up when disabling.
[15:29] <beisner> so, error in my test logic .. it sees key files and says "fail, ssl isn't disabled dood"
[15:29] <lazyPower> well, thats tricky. are they self signed certs?
[15:29] <lazyPower> or are they provided base64 encoded certs?
[15:31] <lazyPower> i guess either way you would want to not keep them on disk
[15:40] <beisner> lazyPower, functionally, the charm seems fine.  just that lil bit about leaving old news behind that may or may not be of concern.
[15:50] <jose> Odd_Bloke: ping, still around?
[15:50] <Odd_Bloke> jose: Yo.
[15:50] <jose> Odd_Bloke: you have a min to talk about the ubuntu-repository-cache charm? got some thingies after using it for production the past weekend :)
[15:51] <Odd_Bloke> rcj: Around?
[15:52] <jose> mr. Jennings has been idle for over 140 hours
[15:55] <Odd_Bloke> He's been active more recently in internal IRC. :p
[15:55] <jose> oh cool
[15:56] <Odd_Bloke> jose: Do you want to brain-dump?  rcj can catch up when he's around.
[15:56] <jose> sure
[15:59] <jose> mbruzek: enable automatic CCs on the video, then choose 'translate' to english, and it should do good
[16:00] <jose> Odd_Bloke: so, I installed the charm and started working alright. however, when I did the DNS redirect to archive.ubuntu.com, I needed to make sure the redirect didn't point to the same machine, otherwise I would end up in a loop
[16:01] <jose> also, jjox helped me find a bug, bug #1483093
[16:01] <mup> Bug #1483093: .archive.ubuntu.com is non inclusive <squid-deb-proxy (Ubuntu):Incomplete> <https://launchpad.net/bugs/1483093>
[16:01] <jose> so, that means I had a problem right away. when users connected from archive.ubuntu.com it would give a 403. solution was to remove the . in front
[16:02] <jose> however, what happens if I want to mirror something else? or have the mirror use another domain name? it also needs to be specified on the file, otherwise users will end up with a 403 and won't know what to do
[16:02] <jose> that's... basically it :)
[16:02] <jose> apart from that, it did a great job
[16:03] <Odd_Bloke> So we haven't hit the redirect loop problem before because all of the cloud images are built to use <cloud_name>.clouds.archive.ubuntu.com (or something along those lines).
[16:03] <Odd_Bloke> So we don't have to do any DNS magic.
[16:04] <Odd_Bloke> jose: "specified on the file" <-- What needs to be specified, and which file?
[16:05] <jose> yeah, but happened to me when I was using the manual provider :)
[16:05] <Odd_Bloke> Thanks for the feedback, glad to hear it was useful!
[16:05] <jose> check the bug, the mirror-dstdomain.acl file needs to have the domain name that's gonna be used, so I'd suggest a config option to have any domain names you want in there
[16:05] <Odd_Bloke> Ah, OK, I see what you mean.
[16:06] <jose> if it's not there squid-deb-proxy will throw a 403 error, and it's a bit hard to spot
[16:06] <jose> need to navigate between several files
[16:06] <Odd_Bloke> Yeah, I run squid-deb-proxy at home, so I've hit that problem before.
[16:08] <Odd_Bloke> jose: So I suspect that we won't find time to fix the 'extra domains' thing any time soon; we're using this as a mirror of archive.u.c, and that's unlikely to change.
[16:08] <Odd_Bloke> jose: But I would certainly be happy to review a patch.
[16:09] <jose> I'd love to give a hand, I'd have to find my way around python charms as I'm not experienced, but definitely willing to take a look
[16:09] <Odd_Bloke> jose: As for the DNS loop, I'm not sure what to suggest, unless perhaps the charm didn't try to hit archive.u.c but tried to hit a subdomain of it?
[16:09] <jose> for the DNS loop, a quick note on the readme could do :)
[16:10] <jose> something like 'make sure you don't end in a DNS loop when you are using the manual provider, otherwise your repository will not update!'
[16:10] <Odd_Bloke> jose: So what exactly did you do to fix it?
[16:11] <jose> put a custom entry on /etc/hosts, since the firewall was somehow blocking 8.8.8.8, reason why I didn't edit resolv.conf
[16:13] <Odd_Bloke> So hard-coded an IP address that you knew was archive.u.c?
[16:15] <jose> yep, directly from canonical
[16:16] <Odd_Bloke> Hmm, that's probably fine for a temporary deployment but you could end up with it breaking if that IP address ever stopped being an archive mirror.
[16:16] <Odd_Bloke> (Or, worse, continued to be an archive mirror but was taken out of the DNS rotation because it wasn't updating properly)
[16:17] <jose> right. maybe a resolv.conf entry edit or making sure it doesn't use the custom dns but google's, for example, should be good
[16:17] <jose> just that in my case it wasn't enough
[16:18] <Odd_Bloke> Well, I'm wondering if we should mirror from 'urc.archive.ubuntu.com' or somesuch.
[16:18] <Odd_Bloke> Provided people don't advertise their mirror as a wildcard, that should work.
[16:22] <jose> yeah, mine was a wildcard too :D
[16:22] <jose> so I could've hit it from different dns records
[16:22] <Odd_Bloke> I feel like my lack of experience with configuring DNS servers is letting me down here. :p
[16:47] <jamespage> beisner, how do you normally do the switch helpers/tests to stable thing?
[16:48] <beisner> jamespage, i believe in the past, coreycb has done both and pushed into stable as the first commit after the release.
[16:49] <beisner> jamespage, i have a batch, which would result in 1 MP per charm, as i (thankfully) can't push straight into the charms  ;-)
[16:49] <coreycb> beisner, thanks, lemme know if you need a review
[16:49] <wesleymason> I have charm related conundrum..I'm revisiting an earlier attempt to get one of our internally used subordinates into the store, proper, and trying to add some basic amulet tests per review feedback..however there aren't any public charms which currently have a rel for this subordinate (although part of getting it promulgated is to encourage more charms to
[16:49] <wesleymason> support it)...so do I either a) try and spend some time adding support to a charm like the wordpress one (which would be nice eventually anyway, but a fair bit of work to undertake properly), or b) can I add a "dummy" charm with minimal amount of mcok data fed back over the relationship to the subordinate to make it testable in the amulet test?
[16:52] <marcoceppi> wesleymason: what does the charm do exactly? A lot of people have used an Ubuntu charm as the base of a subordinate and will modify it (with the amulet test) so it will mimic a potential client charm
[16:52] <beisner> jamespage, coreycb - so shall i do the charm-helpers yaml + stable test bit flipping MPs?
[16:53] <jamespage> beisner, pls
[16:53] <jamespage> beisner, lemme push the big button and publish the stable charms
[16:53] <beisner> jamespage, coreycb - curious, does stable charm-helpers branch also get a push from dev in tandem with our release?
[16:53] <jamespage> beisner, it does
[16:54] <wesleymason> marcoceppi: it installs a utitliy (conn-check), and takes either a filepath to a config file or the config itself as a string and creates the file from the relation (but this is deprecated in the charm), and if related to nrpe sets up a regular nagios check
[16:54] <beisner> jamespage, ok good.  lmk when the charms are pushed, i'll update my batch o matic thing and do those flips.
[16:56] <marcoceppi> wesleymason: doing route (a) sounds best either by using an existing charm in your personal namespace as an example or by forking the ubuntu charm as a "vanilla" implementation. Having that will go a long way to helping people grok how to implement the bits required to make their charms compat with yours
[16:57] <wesleymason> marcoceppi: :+1+, ta will do that
[17:04] <ddellav> coreycb, can you take a look at this amulet output? I'm not sure why it failed http://paste.ubuntu.com/12049127/
[17:06] <jamespage> beisner, apparently I'm done
[17:10] <beisner> jamespage, ok, c-h.yaml + amulet flip batch underway.  will ping when ready for review.
[17:19] <coreycb> ddellav, I've not seen that error.  for many charm errors you can look in the jenkins artifacts and find logs from the run, typically you'd want to look in /var/log/juju/unit*.log.  but I dont' think that'll help here
[17:20] <coreycb> ddellav, could be related to this?  https://bugs.launchpad.net/juju-core/+bug/1468586
[17:20] <mup> Bug #1468586: juju 1.24.0 bootstrap failure - Waiting for API to become available - Error connection is shutdown <oil> <juju-core:New> <https://launchpad.net/bugs/1468586>
[17:20] <stub> marcoceppi: Is there any particular reason that the storage subordinate has not been promulgated to trusty?
[17:21] <jamespage> coreycb, beisner: you guys ok to handle landing those branches for the stable switch?
[17:21] <beisner> jamespage, yep we've got it
[17:21] <coreycb> jamespage, sure
[17:23] <marcoceppi> stub: no one's asked?
[17:25] <stub> marcoceppi: ok, asking now :)
[17:25] <stub> marcoceppi: ok, asking now :)
[17:25] <marcoceppi> stub: just open a bug like you would a new charm asking to promulgate storage charm to trusty and it'll go iunto the review queeu
[17:26] <stub> but laaazy
[17:26] <marcoceppi> stub: me tooo
[17:30] <lazyPower> stub: you rang?
[17:58] <beisner> coreycb, pile o' openstack charm merge proposals for c-h/amulet stable flips @ http://paste.ubuntu.com/12049694/
[17:59] <coreycb> beisner, k, queued!
[18:01] <beisner> coreycb, woot, thank you
[18:07] <beisner> meanwhile...   bots gone wild!
[19:08] <jose> mbruzek: ping
[19:13] <beisner> coreycb, oh fyi, only expect lint + unit results on that batch, as amulet was green on all of them.  though, as soon as those land, i plan to release a full run of stable charm tests for new baslines.
[19:13] <beisner> baselines even
[19:17] <coreycb> beisner, ok
[19:27] <wolsen> beisner, coreycb ... release day - I can feel it... literally - the cell phone buzzes with each email sent for merge lol
[19:28] <coreycb> lol
[19:28] <beisner> bzzzt bzt!
[19:28] <wolsen> lol
[19:56] <lazyPower> marcoceppi: do we have charm helper wrappers that gracefully degrade to determine is_leader? My current strategy for approaching this is to panic and halt execution - https://github.com/whitmo/etcd-charm/pull/16
[19:57] <marcoceppi> lazyPower: not that I'm aware of, the openstack charmers implemented the code. I'd have to look to see
[19:58] <lazyPower> ok, i think where i'm at today satisfies the bug, but I'll circle back and look into making the charm gracefully degrade
[20:02] <marcoceppi> hatch: it also runs the config-changed hook
[20:02] <hatch> marcoceppi sorry?
[20:02] <marcoceppi> and potentially the install hook (if upgrade-charm isn't present)
[20:03] <hatch> I must have missed a previous message
[20:03] <lazyPower> marcoceppi: thats what you get for trying to ninja
[20:03] <marcoceppi> hatch: I'm just really good at predicting the question you're about to ask
[20:03] <hatch> lol
[20:03]  * lazyPower plays sadtrombone.wav
[20:03] <hatch> marcoceppi so when upgrading a charm, it overwrites everything? or just matching files in the charm path?
[20:04] <marcoceppi> hatch: it just unpacks the zip file ontop of the charm_dir
[20:04] <lazyPower> only the files contained in the charm itself. if the charm creates for example .foo - .foo will persist so long as it does not exist in the charm package.
[20:04] <marcoceppi> it won't delete anything
[20:04] <hatch> mm ok - the root of this question is that I need somewhere to write keys supplied via config
[20:04] <hatch> so I wasn't sure if the charm directory was stable enough to do so
[20:05] <lazyPower> hatch: are you using charm helpers? if so, there's a storage module to do this, and it has a handy side effect of letting you know if the value has changed which helps with idempotency
[20:05] <hatch> no I'm writing it in bash
[20:05] <lazyPower> welp, nothing to do here then *whistles*
[20:05] <marcoceppi> hatch: you acn use charm_dir, or you can always just use /etc :)
[20:05] <hatch> lol - I was surprised that there was no 'common charm actions' section in the docs with code examples
[20:05] <marcoceppi> lazyPower hatch the kv stuff is available through the chlp bash interface :)
[20:07] <hatch> thanks for the information marcoceppi lazyPower
[20:08]  * lazyPower hattips
[20:50] <hatch> Is the $CHARM_DIR environment variable always defined? Or only during hook execution? I'm wondering if I can use it in an upstart script
[20:51] <marcoceppi> hatch: only during hook execution
[20:53] <hatch> marcoceppi is there any way to know where the charm path is from the upstart script?
[20:53] <marcoceppi> hatch: have the charm write it to the init script?
[20:53] <hatch> Or should I copy everything to usr/local/bin or something
[20:54] <marcoceppi> hatch: it's best to use the linux filesystem, either usr/local/bin or /opt or something like that
[20:54] <marcoceppi> I typically go with /opt/<thing>
[20:54] <marcoceppi> but that's just a convention I grew up with
[20:54] <hatch> alright I'll do that  , I need a place to put the bin and keys and whatnot
[20:54] <hatch> so I'll just have to make sure the upgrade script properly replaces those
[20:54]  * marcoceppi nods
[20:55] <hatch> thanks again :)
[21:00] <coreycb> beisner, those are all merged except rmq which I don't have upload rights for
[21:01] <coreycb> beisner, however, precise and trusty charms are now different, so can you propose all of them against precise too?
[21:25] <lazyPower> thumper: ping
[21:25] <thumper> lazyPower: with you shortly
[21:26] <lazyPower> thumper: its a quickie. you were hacking on django and used features that only exist in newer juju, i used the proposed semver approach we riffed in about a month ago - and it got nacked in peer review, you may want to take a look here at this cleaner block update that you can recycle - (reason why is inline) https://github.com/whitmo/etcd-charm/pull/16
[21:35] <thumper> lazyPower: ok, will look
[21:35] <thumper> lazyPower: btw, I support the min-version idea
[21:36] <thumper> will raise again
[21:36] <thumper> lazyPower: however, it does raise the interesting point of "how to fall back"
[21:36] <thumper> lazyPower: if I have, say, the django charm that now uses leadership, and has min-version of 1.24
[21:37] <thumper> lazyPower: what would the expected behaviour be of someone using 1.22 going 'juju deploy python-django'
[21:37] <lazyPower> thumper: i think thats on a case by case basis
[21:37] <thumper> I believe this is the main sticking point w.r.t implementation
[21:37] <lazyPower> if you can probe if you have it available, you're already leaps and bounds ahead
[21:38] <lazyPower> you can either chose to work around it, or raise an error with a meaningul output with regard to "Yo, your version of juju is crusty, please update if you want to use this charm"
[21:45] <marcoceppi> lazyPower thumper it seems that leader election is the only hard sticking point atm. status and storage have feasable workaround to degrade nicely
[21:47]  * thumper nods
[22:30] <wesleymason> PSA: !juju now works on duckduckgo.com to redirect searches to the charm store 😉