[09:47] <bloodearnest> it there a bug open for better formatting of the stdouts of a multi-unit juju run? Because it's unreadable at the minute
[09:53] <lazyPower> bloodearnest: not that i found on a quick search
[09:58] <bloodearnest> lazyPower, yeah me neither, just wanted to check here before I filed one
[10:22] <lazyPower> bloodearnest: you made mention you wanted to use the slides i dropped on speakerdeck. do you want the impress template?
[10:25] <bloodearnest> lazyPower, yeah, that'd be sweet, thanks
[10:25] <lazyPower> https://www.dropbox.com/s/pxapq90ma326nw3/service-orchestration.odp?dl=0
[10:25] <bloodearnest> lazyPower, sounds like you had fun :)
[10:25] <lazyPower> bloodearnest: it was intense. one man show, 8 speaking events, 3 weeks notice. I was dancing, non stop :)
[10:26] <lazyPower> well i had prior notice, but nothing was confirmed prior to 3 weeks before the conf.
[12:20] <hazmat> lazyPower, intense
[13:08] <lazyPower> hazmat: \o/
[13:09] <lazyPower> hazmat: signs of life! i thought you were going to be MIA for a while
[13:09] <hazmat> lazyPower, i am for most of the day, restricted networks
[13:09] <lazyPower> oi
[13:11] <lazyPower> hazmat: did you have a chance to follow any of the slide work i published?
[13:11] <lazyPower> i'm curious to get your take on what i put out there
[13:12] <hazmat> lazyPower, checking
[13:15] <hazmat> lazyPower, pretty solid
[13:16] <lazyPower> hazmat: thanks for the review. Means quite a bit that you stamp it with approval :D
[13:16]  * lazyPower hat tips
[14:44] <jcastro> hatch, ping
[14:45] <hatch> jcastro: hey
[14:45] <jcastro> hey so check this out
[14:45] <jcastro> https://jujucharms.com/ceph/
[14:45] <jcastro> one revision behind, but james and crew pushed a new version on thursday
[14:45] <hatch> did their version pass proof?
[14:45] <marcoceppi-sast> https://store.juju.ubuntu.com/charm-info?charms=cs:trusty/ceph
[14:47] <jcastro> aha!
[14:47] <hatch> :)
[14:47] <jcastro> E: Unknown relation field in relation nrpe-external-master - (gets)
[14:47] <jcastro> yeah, got it, thanks!
[14:47] <hatch> jcastro: np - we should probably have some indicator somewhere of something somehow for this :)
[14:48]  * hatch intentionally leaves that very open ended :D
[14:50] <hatch> jcastro: typically if your charm doesn't show up in under an hour something went wrong :) it's on a 30min loop so depending on when you catch that loop...
[14:50] <jcastro> ack
[14:51] <jcastro> hatch, would it make sense to autofile a bug on the charm if it fails?
[14:52] <hatch> jcastro: tbh I'd like to see some kind of a status page somewhere where you could check
[14:52] <jcastro> well, not for me
[14:52] <jcastro> for people who push and have no idea why it didn't show up
[14:52] <hatch> right - it would be in the docs "go here for charm ingestion status"
[14:53] <hatch> that could even possibly be linked by the page on jujucharms.com
[14:53] <hatch> I'm totally just throwing out an idea here
[14:54] <jcastro> iirc the original plan was to have the "status lights" on the charm's actual page
[14:55] <hatch> yeah I think that filing a bug would be hard - I'm not sure that the proper people would see it for promulgated charms
[14:55] <hatch> I don't think I see bugs filed for Ghost if it's on the promulgated charm?
[14:56] <jcastro> hatch, found the problem, charm tools is returning 0
[14:56] <jcastro> so the ceph guys lint check, it's just returning(!) zero
[14:56] <lazyPower> hatch: couple things about that
[14:56] <lazyPower> 1) we already have the review queue - why not attach diagnostic messages like that to the review item?
[14:56] <hazinhell> jcastro: the new store should have some events support .. ie if you use juju publish it should give you feedback
[14:56] <lazyPower> 2) Why am i checking a page when you have the maintainer field in metadata and can contact the maintainer?
[14:57] <jcastro> hazinhell, oh awesome, that sounds great.
[14:57] <hatch> lazyPower: people can push to their own namespace (it'll still fail if proof fails) and it doesn't touch the review queue
[14:57] <hatch> and the maintainer field isn't always accurate
[14:58] <hazinhell> jcastro: its been supported for a few years fwiw (re events and juju publish for store feedback).. haven't tried it with the new store impl that's extant but it should work
[14:58] <jcastro> right so instead we just say `juju publish fail, please run charm proof and fix your stuff
[17:49] <hatch> is it normal for the debug-hooks command to not dump you into the hooks context on the 'start' hook?
[17:50] <hazinhell> hatch: yes it dumps you into a empty window, and the others pop up in response to hooks executing, but if there is no active hook you won't be in a hook context
[17:50] <hatch> ahh that's probably what's happening
[17:50] <hatch> I wish I didn't have to spam debug-hooks after deploy
[17:51] <hazinhell> hatch: there's some arcana involved but if you want to poke around at the unit context, you can use juju-run on the unit to examine its state.
[17:51] <hazinhell> hatch: cory_fu made some nice debugging tools to avoid having to do the double poke (debug and resolved --retry)
[17:51] <hatch> is there a reason why we don't say 'ok you asked for debug-hook, but the unit isn't up yet, so we'll wait till it is'
[17:53] <hazinhell> hatch: no, there is no reason.. feel free to file it as a cli ux bug, there's a few like that
[17:54] <hatch> Will do! thanks
[17:57] <hatch> looks like there is already a bug :) https://bugs.launchpad.net/juju-core/+bug/1278831
[17:57] <mup> Bug #1278831: debugging first run of install hook is not straight forward <debug-hooks> <juju-core:Triaged> <https://launchpad.net/bugs/1278831>
[17:58] <hatch> now to figure out how to use tmux in a tmux :)
[18:09] <hazinhell> hatch: its easy.. rebind control key on the outer one ;-)
[18:10] <hazinhell> hatch: that requires forethought.. the other way if they match on controls is to double hit the control char
[18:16] <hatch> yeah there was definitely no forethought here :P
[22:12] <dbart> mbruzek: ping
[22:12] <mbruzek> hello dbart
[22:12] <mbruzek> What can I do for you?
[22:13] <dbart> mbruzek: hey there! I was working with lazyPower on the MariaDB charm
[22:13] <mbruzek> dbart: Yes I heard that
[22:13] <dbart> we had an issue with the charm on P8, but I think I've just solved it
[22:14] <mbruzek> dbart: OK great news!
[22:14] <dbart> MariaDB on P8 is built with IBM's Advanced Toolchain, and without the runtime package, MariaDB won't install
[22:14] <dbart> so the issue was how to get the runtime
[22:15] <mbruzek> dbart:  "was" so you solved it?
[22:15] <dbart> so what I've done is added the package to our MariaDB repository, so now when the charm goes to install mariadb-server it sees and pulls in the runtime package
[22:15] <mbruzek> dbart:  what is the package name?
[22:16] <dbart> advance-toolchain-at8.0-runtime
[22:17] <dbart> our packages (correctly) depend on it, but on the test box lazyPower was testing on the package wasn't in any of the configured repos, so apt-get failed
[22:17] <mbruzek> $ apt-cache search advance-toolchain-at8.0-runtime
[22:17] <mbruzek> I see no results for that dbart when I search on a power 8 system.
[22:18] <dbart> exactly, it's generally found in a separate IBM repository
[22:18] <dbart> so by adding it to our P8 repo when you try to install mariadb-server apt can find it
[22:19] <mbruzek> dbart: This conversation seems familiar.  Have we talked about this before?  Does MariaDB need to be built with that package?
[22:19] <dbart> IBM really wants us to build with it, it's not absoultely required, but performance is better when it's used
[22:20] <mbruzek> dbart: It is my understanding that the advanced toolchain was needed for people who build with older kernels, and this was a way to get the new compiler to older level of kernels.  My understanding is if you use modern kernels and compilers they are often newer than advanced toolchain.
[22:20] <mbruzek> dbart: If the performance is better then I am not arguing
[22:21] <mbruzek> dbart: From the conversations I have had it was obsolete and no advantage.
[22:21] <mbruzek> to have the toolchain.
[22:21] <dbart> ok, I don't know about all that, I just know that our devs are still building with it...
[22:21] <dbart> I could ask them about it
[22:25] <kwmonroe> negative mbruzek - AT brings cpu flags to the table that gcc hasn't brought yet
[22:25] <mbruzek> dbart: I don't want to conflate the issue, if you have a fix that is great!  I just was telling you what my understanding was of the advanced toolchain.  Because we (Canoncial) asked about using advanced toolchain for other instances and I seem to remember that it was not needed.
[22:25] <mbruzek> kwmonroe: ahh very good, thank you for correcting me.
[22:25] <dbart> ok, understood :)
[22:25] <kwmonroe> event based branching comes to mind.. as a power8 cpu feature that's not in gcc, but is available for AT
[22:26] <kwmonroe> hardware transactional memory is another.. why buy a p8 if you're not gonna STEP UP TO THE POWAHHHHH?!?!
[22:27] <dbart> mbruzek: so just a few minutes ago, with the runtime package in the repo, I was able to install MariaDB on the test instance lazyPower gave me access to
[22:27] <mbruzek> dbart: it seems my memory is not as good as it used to be.  Disregard my earlier statements about AT.
[22:27] <dbart> :)
[22:28] <mbruzek> dbart: how can I help?
[22:28] <dbart> I'm going to be going afk now, and I don't know what else there is that needs to be done... lazyPower was working on testing the charm, but hit the repo issue
[22:29] <dbart> so now that the repo issue is solved (and MariaDB can actually be installed) I assume testing can be resumed, but I don't know what lazyPower was going to do next on that
[22:30] <mbruzek> dbart: what is your branch?
[22:32] <dbart> https://code.launchpad.net/~dbart/charms/trusty/mariadb/trunk
[22:33] <mbruzek> dbart so let me see if I understand, your install hook now installs the toolchain that was needed for mariadb to pass on ppc64le?
[22:33] <dbart> there's an issue with the amulet tests (they don't account for the enterprise instructions in the README)
[22:34] <mbruzek> dbart can you give me a hint?
[22:35] <dbart> you basically need to create a ent.yaml file that has the correct information in order for the enterprise repo to work (which is where the P8 packages are)
[22:35] <dbart> I don't know how lazyPower was doing the tests (since the amulet tests, out of the box, don't work)
[22:36] <mbruzek> dbart: passing the amulet tests are something that are required for a charm to go into the recommended section of the charm store.
[22:36] <mbruzek> dbart: Do you know what is needed to make them work?
[22:36] <dbart> yes, so those need to be fixed, that's probably the next step
[22:37] <kwmonroe> i know mbruzek.. the ./tests/10-deploy test is trying to install the "normal" maria packages first.  that adds a repo and does an apt-get install mariadb.  that's great, except the repo doesn't have a ppc64le arch.. so 10-deploy fails right off the bat when testing locally.
[22:38] <dbart> kwmonroe: yup, that's it in a nutshell
[22:38] <kwmonroe> on an arch that *does* exist in the mariadb repo, the next setp in 10-deploy is to "upgrade" the repo to use the secret enterprise url.  but running the test natively on power, we can't get past step 1 to get to step 2.
[22:38] <dbart> by using an ent.yaml file and passing that to deploy, you can set it up right of the bat
[22:39] <kwmonroe> yup - just like the readme tells ya to do ;)
[22:39] <kwmonroe> so mbruzek, the problem is making the amulet test do what the readme says.
[22:40] <dbart> we really need a better solution for those that want to use the Enterprise repo, but what's outlined in the readme is all I've got at the moment
[22:40] <dbart> lazyPower was working on updating the tests I think, but I don't know how far he got
[22:40] <mbruzek> dbart: Can you refactor the amulet test to do that?  I haven't seen or used mariadb in quite some time, a bit out of the loop
[22:40] <kwmonroe> i think it gets even stickier dbart.. if you want to test the enterprise repo (which is the only option for p8), you need to expose a user:password in the amulet test.
[22:40] <dbart> yup, that's the other issue
[22:42] <dbart> I've been complaining to our team about removing the login requirement (nothing but trouble IMO), but as of today it's still needed
[22:42] <dbart> tomorrow I can look into refactoring the test
[22:42] <kwmonroe> dbart: is there perhaps an x-day trial user/pass?
[22:42] <dbart> perhaps, I'd need to look into it
[22:44] <dbart> anyway, I've got to go now, but I'll work on the tests (and see if lazyPower got anywhere with them) tomorrow
[22:44] <dbart> thanks all
[22:44] <kwmonroe> sure dbart - i'll help you manana in case you're sick of mbruzek
[22:44] <kwmonroe> ;)
[22:44] <dbart> thanks!
[22:44] <dbart> :)
[22:44] <mbruzek> dbart lazyPower is traveling across the ocean so I doubt he will be working on them
[22:45] <dbart> oh yeah, he mentioned that... :-)
[22:45] <mbruzek> dbart see you tomorrow let kwmonroe know if you need help refactoring the tests
[22:46]  * mbruzek ducks