[03:20] cory_fu: new ghost is working on xenial so far :D [03:20] i want to test the 0.8.0 release and get that out the door soon too === frankban|afk is now known as frankban === stub` is now known as stub [11:46] hello!! [11:46] some services are stuck in update-status hook is this normal? [11:46] it's been some hours that they are updating === dpm_ is now known as dpm === gnuoy` is now known as gnuoy [12:20] we have the best stuff ever for OLAP over all your big data stuff coming in our 3.9 release [12:20] just putting together an RC2 with juju datasource injection, automatic schema generation and stuff [12:20] it'll make analytics over the big data & SQL charms really easy [13:09] stokachu: I should have mentioned, I updated the ghost charm to support changing the "release" option, so we should definitely try upgrading. I just realized, though, it should probably retry on "checksum" change as well [13:13] stokachu: https://github.com/battlemidget/charm-layer-ghost/pull/3 [13:14] :) [13:15] cory_fu: merged, ill try the upgrade now [13:18] cory_fu: ping re: https://github.com/juju-solutions/charms.reactive/issues/76 [13:19] marcoceppi - is that a verbiage change to reactive as a whole? [13:19] cory_fu: people we really confused by `status_set` and `set_state` [13:20] givenhow close in nature they are, it aslo made it really confusing since it blurs what state, people assuemd this was a state engine in juju instead of on the unit level [13:20] you know what [13:20] I was going to say that exact thing the other day [13:20] and I thought I was being pedantic ;) [13:20] so the idea of flags as a way to distil the state without really changing meaning was proposed by mark [13:21] here's an example of what the code could look like: https://github.com/marcoceppi/layer-vyos-proxy/blob/master/reactive/vyos_proxy.py [13:22] +1 for something like that [13:22] also helps in amulet and stuff where you're tying to figure out what status/state/message you're trying to extract [13:22] If we're going to change that, should we make it "flag_set" (even though I hate that order) to be consistent? [13:23] +1 to normalizing on the method signatures [13:24] (I'm not even going to bother trying to argue that we change "status_set" :p) [13:24] cory_fu: welllllllllllllll [13:24] I'd be okay with set_status [13:24] ^^ +1 [13:24] in charms.model [13:24] ;) [13:25] True [13:25] with like an from charms.model import classic_names [13:25] cory_fu: though, set_action seems odd compared to action_set [13:25] maybe not [13:26] Hello Team, I am facing the below issue in Juju 2.0 while uploading packages to the controller using juju attach command and also juju inline deployment command using resources. Error code : http://pastebin.ubuntu.com/18097919/ [13:26] set_action_data might be better name in general [13:26] And also it is taking lot of time to upload into the container when the product package is of more than 1 GB. Is there any trick to increase file upload speed? And also I am wondering why it is taking long time to upload/download on the controller within the same subnet. Could somebody make me clear on this? [13:26] marcoceppi: What about charms.model.status.set() and charms.reactive.flag.set() [13:26] Prabakaran - how large is your attachment? [13:26] +1 to set_action_data [13:26] 1.8GB [13:26] cory_fu: possibly [13:26] I'm still very much up in the air about charms.model [13:27] Prabakaran - ah i missed your follow up. There is a bug currently that prevents large attachments from working in the current betas [13:27] lazyPower: thats push to controller is it the same? [13:27] cory_fu: right now it's more like charms.model.unit.status.set() [13:27] cory_fu: should we be using mariadb instead of mysql? [13:27] magicaltrout - it appears so, it ran into an IO error trying ot attach to the controller [13:28] cory_fu: so I like charms.model.unit.set_status instead [13:28] Prabakaran - can i get you to file a bug for that? i'd like to xref with core on this issue [13:28] ah yeah [13:28] i didn't scroll across far enough [13:28] ya sure [13:28] stokachu: I did my testing with mariadb, but marcoceppi has put a fair amount of work in recently to improve the mysql charm [13:28] marcoceppi <-> work? [13:28] cory_fu: ok cool [13:29] stokachu: cory_fu: that's an overstatement, I removed and touched up the tests that were failing consistently because of bad setups [13:29] magicaltrout: great question! [13:29] pfft [13:29] ;) [13:29] and also is it possible for me to upload the file by getting into the controller...? [13:29] i'm looking forward to a whole room of americans with similar enthusiam later this year marcoceppi [13:29] although I might need ear plugs, or a sick bowl ;) [13:30] magicaltrout: I'll make sure to beef up on my "English" [13:30] hehe [13:30] just ask kwmonroe for some tips [13:30] he's got the english patter down to a fine art.... if you live in the early 1900's [13:30] pip pip! [13:33] cory_fu: if you get time today you could run through my conjure-up enabled ghost bundle [13:33] https://gist.github.com/battlemidget/a35809531b34db683d54d8b046353d80 [13:33] Prabakaran - negative. the resources feature works with gridfs in mongo, and then some internal juju bits rely on that process to complete successfully (eg: BSON ID's of the resource) [13:33] Prabakaran - so without having intimate knowledge of that, i dont think you can fake it out [13:33] stokachu - oh btw i ran the cojure scripts for kubernetes, nice work :) [13:33] *conjure [13:34] lazyPower: thanks :D ive got some updates to make to the bundle as well [13:34] nice [13:34] cory_fu: I updated the issue, I was projecting on screen when I filed it [13:36] k thanks what is the bug number for the timeout issue? [13:36] Prabakaran - I'll need you to file the bug for that :) [13:36] can u help me on how to raise a bug? [13:36] Prabakaran - its only hit the list as far as I'm aware of. There was a thread started by merlijin, but it was specifically in reference to jujucharms.com resources, not local resources on the controller [13:37] Prabakaran - sure, start here https://bugs.launchpad.net/juju-core/+filebug [13:37] Prabakaran - we'll need the juju version, arch, what you did, what you expected to happen, what happened, associated logs, and reproduction steps [13:58] i am getting timeout error while submitting bug.. " Timeout error Sorry, something just went wrong in Launchpad. We’ve recorded what happened, and we’ll fix it as soon as possible. Apologies for the inconvenience. Trying again in a couple of minutes might work. (Error ID: OOPS-4ad94ec13b63a1d16b8f1c05cd6b031b)" [13:59] Prabakaran - if you hit the back button in your browser and re-submit does it complete successfully or does it give you the same 500 error? [14:06] cory_fu: do you want a help in reviewing zeppelin? [14:07] it's a big balloon filled with gas and exploded in flames.... [14:07] much like some juju deployments! ;) [14:07] * magicaltrout gets his coat [14:07] alternatively, its a wicked rockstar group whos music is as timeless as... well.. a zeppelin [14:07] kjackal: Yeah, if you want to take a look at it, go ahead. [14:07] potentially made from lead even [14:08] * lazyPower rimshots and wanders off stage [14:10] i tried twice still i am getting the same... i asked my teammate to raise for the same.. bug number is https://bugs.launchpad.net/juju-core/+bug/1597354 [14:10] Bug #1597354: Juju 2.0 Resource Error - cannot add resource failed to write data: read tcp : i/o timeout [14:10] Prabakaran - that makes me want to say it might also be on your end if your tcp connections are timing out [14:10] cory_fu: cool, I am on it [14:11] Prabakaran - perhaps do some network debugging and see if you're experiencing packet loss? [14:11] kjackal: thanks [14:11] but thanks for the bug, I'll shop this with the core dev release manager to see if they've seen anything like this in testing [14:13] i just pinged from my machine .. there is no packet loss [14:26] lazyPower: who can i bug for https://bugs.launchpad.net/charms/+source/elasticsearch/+bug/1589947 [14:26] Bug #1589947: Use status-set when elasticsearch is active and ready [14:27] stokachu - thats going to be fun... you'll have to set that in the middle of the ansible routine [14:27] ew [14:27] yeah [14:27] :) [14:27] I considered going for a reactive rewrite but time prevented me from doing that [14:28] that and our ES charm is pretty solid right now [14:28] yea [14:28] * lazyPower had a bag of bugs to sprinkle around :P [14:28] i can try to hammer that out today [14:28] should be pretty simple [14:28] hmm i wonder, juju should just pull from agent status if workload status is undefined [14:28] i dont think thats right to just clone the agent status [14:29] i'd rather the workload status remain unknown if the author has not put any status messaging in the charm [14:29] then its pretty blatant whats happening [14:29] well you dont really know whats happening as there is no messages :) [14:32] lazyPower: also seeing this on aws https://paste.ubuntu.com/18101489/ [14:36] stokachu which revision of ETCD is this? [14:36] lazyPower: rev3 [14:36] kubernetes is rev5 [14:36] hmm, flannel biffed it on registering the network [14:37] is the instance still up? [14:37] lazyPower: yea [14:37] if so can you ssh-import-id lazypower on that node and hit me with some ip <3? [14:37] i'd like to see why that tanked, its been good in CI [14:37] you want on kubernetes or etcd? [14:38] or both [14:38] both would be good [14:49] resource-get [14:49] Use 'resource-get' while a hook is running to get the local path to the file for the identified resource. This file is an fs-local copy, unique to the unit for which the hook is running. It is downloaded from the controller, if necessary. [14:49] whoops [15:08] stokachu: I am testing the good work you and cory_fu did on ghost [15:08] arosales: cool! [15:08] arosales: you should also test the upgrade [15:09] since it defaults to version 0.7.2 and latest is 0.8.0 [15:09] stokachu: recommended wise I see https://jujucharms.com/ghost/precise, but I was wondering if we should reach out to hatch and confirm to promote yours for trusty and xenail [15:10] yea i'd like to see the reactive charm go recommended [15:11] ok, I don't see hatch here atm but I'll send a mail on it. [15:11] stokachu: thanks [16:14] jcastro marcoceppi: is there a best guess eta for a final 2.0 release? (are we talking weeks or months?) [16:14] also - great job on beta10. It's been really smooth for me so far === rogpeppe1 is now known as rogpeppe [16:47] Hi, I am running juju 1.25.5-trusty-amd64. If I run a command using juju run which gets timed out, then the next command seems to be getting timed out too even with the greater threshold. I checked it on the machine side it seems both processes seem to be running and stuck http://paste.ubuntu.com/18109177/ === frankban is now known as frankban|afk [16:51] openstack-charmers: how do you guys feel about setting openstack-dashboard session timeout to that of the keystone token expiration? [16:52] openstack-charmers: or possibly a new config "session-timeout" for openstack-dashboard === cargonza-holiday is now known as cargonza [17:06] bdx, you should attend the openstack irc meeting in the #ubuntu-meeting === dpm is now known as dpm-afk [17:32] cargonza: thx, on it [17:33] cargonza: did I miss it? [17:34] bdx, yup... next week again - https://wiki.ubuntu.com/ServerTeam/OpenStackCharmsMeeting [17:34] awwwwweee [17:34] thanks [17:34] I'll mark my schedule [17:34] cool! [17:35] stokachu: around? [17:36] rick_h_: hey whats up? how are cross-model-relations coming along? [17:36] bdx: :P [17:37] bdx: stop asking about juju post-2.0 we're still working on 2.0 [17:41] rick_h_: shucks ... I was under the impression that was in the 2.0 milestone. Last we spoke you guys were sprinting on it ... just wondering how its coming along is all [17:42] bdx: sorry, it's on the "release after 2.0" one [17:44] no worries [17:44] thanks [17:49] rick_h_: how is the 2.0 release coming? [17:49] bahaa [17:49] yes [17:50] rick_h_: go easy on him [17:50] Don't want to be a bother - just curious if there is any idea of a timeline - i.e. weeks vs months [17:50] LiftedKilt: weeks, just more than a couple of them :) [17:51] rick_h_: totally understand - there's a ton going into this release, and I'd way rather it get delayed and the bugfixes added than just rushing to get it out there before it's ready [17:51] any idea when gui will be beta10 compatible? [17:54] LiftedKilt: more soon than soonish. [17:55] jrwren: haha fair enough [17:58] rick_h_: heyyy [18:21] conjure-up is beta10 compatible just fyi [18:21] so is macumba :) [18:24] stokachu: <3 [18:26] rick_h_: see my email? [18:28] stokachu: yes, sorry, getting pulled into a customer issue atm so kina afk looking at that [18:33] rick_h_: all good [18:53] Hi everyone, I'm having an issue in one of my deployments, juju gets the ip of node as public-address. Anyone knows about this issue? [19:31] cory_fu: i'm doing an "if is_state(db.available); do_something(db)", but i can't remember how to get the db object. halp. [19:32] I'd recommend using @when() if at all possible. [19:32] If not possible, you have to use RelationBase.from_state('db.available') [19:33] But that will make your handler / code harder to unit test [19:33] And petevg will get mad at you [19:33] :) [19:34] fair enough.. i was on a kick about condensing reactive handlers so i didn't have stuff like "configure_with_db()" and "configure_without_db()", but whatevs. [19:35] Mocking out RelationBase.from_state isn't the worst thing, for the purposes of unit tests. [19:35] I'm still working out what level of mocking we want to tolerate, though. [19:36] petevg: i don't care what cory_fu says.. you're alright in my book. [19:36] Aw, shucks. [19:42] kwmonroe: https://medium.com/@ecesena/a-quick-demo-of-apache-beam-with-docker-da98b99a502a#.k8dnol49r [19:42] good one for you guys, I mentioned it before I think, but the blog is a good demo [19:43] yeah - neat magicaltrout.. but there goes my afternoon :/ [19:43] you're very welcome ;) [19:48] kwmonroe: to confirm, what were your plans for cs:~bigdata-dev/xenial/apache-spark-79 [19:48] kwmonroe: specifically for promulgating the s390x pieces. [19:52] arosales: i wanted to make sure the rebuilt spark charm didn't break realtime syslog bundle, but i haven't gotten around to bundletesting it with the -dev charms. i'll kick that off right now. [19:52] if it looks good, i'll promulgate the xenial pieces for spark [19:53] kwmonroe: sounds good, thanks [19:53] kwmonroe: your code never has bugs right [19:53] yeah arosales, but this has some stuff from cory in it too. [19:54] ah, ok [20:02] kwmonroe - so they are rocket powered bugs, with heisenbug tendencies [20:06] Sorry, I wandered off in the middle of the conversation. Keep in mind that you can avoid duped code across handlers by calling one directly from the other. Or by refactoring shared code up into a lib/charms/layer/foo.py library for your charm. [20:07] kwmonroe: That said, I just did the optional state plus RelationBase.from_state() approach in https://github.com/battlemidget/charm-layer-ghost/blob/master/lib/charms/ghost.py [20:08] See lines 44 and 81 [20:10] very cool cory_fu [20:14] hi all start from today i am seeing weired issue with juju where public-ip was blank with the service and deployment failed at last. But status says installation in progress. ceilometer/0 maintenance executing 1.25.5 2/lxc/0 (install) Installing packages [20:23] hey guys .. is there any way to connect a bridge to a VLAN interface i have created using maas? i.e. bond0.120 -> br-mgmt [20:33] arosales: syslog bundle looks good: http://54.67.62.114:9090/#/notebook/flume-tutorial rev 10 is ready: https://jujucharms.com/apache-spark/ [20:35] kwmonroe: and assuming the current promulgated version is built from https://github.com/juju-solutions/layer-apache-spark it has your latest bits in it, correct? [20:36] to confirm the correct charm publish workflow is: [20:36] charm push . [20:36] charm publish cs:/- [20:36] and then a grant to all for read [20:37] charm grant cs:~/ everyone [20:37] My main question is the charm grant is needed or publish to the stable channel does that by default. My testing shows the grant was needed by wanted to confirm that is indeed correct [20:37] arosales: correct in that the current promulgated version is built from that gh link. [20:38] https://jujucharms.com/docs/devel/authors-charm-store is my reference [20:38] kwmonroe: cool thanks [20:38] arosales: ymmv if you're not explicit when you 'charm push .'. i think by default it will stick the charm in your namespace (ie, ~kwmonroe) based on the distro you pushed from (ie, xenial). so for spark, i was more explicit: charm push . cs:~bigdata-charmers/apache-spark [20:39] and then it spit back a charmstore url, which is what you feed charm publish [20:39] grant is only needed the first time [20:39] arosales: so i just "charm publish cs:~bigdata-charmers/apache-spark-10", but didn't need to re-grant for that specific revision. [20:40] kwmonroe: ok I was pushing a new charm to my name space and I had to charm grant to deploy it [20:40] kwmonroe: I got an odd Ubuntu One login when I didn't grant, in the terminal no less [20:40] very odd [20:41] arosales: i would bet if you built a new version of that charm, you could push/publish without a re-grant [20:41] kwmonroe: but if I wanted apache-spark in my name space [20:41] I would need to push/publish/grant [20:41] right [20:41] ok [20:41] I didn't think I needed the grant [20:41] (the first time, subsequent times would just be push/publish) [20:41] but it turns out I do [20:41] ok [20:42] I'll let you return to watching the beam demo now [20:42] thanks for the help kwmonroe [20:42] :) np [21:09] kwmonroe: got a sec to look at some reactive bits? [21:09] or any other reactive gurus in here [21:09] http://paste.ubuntu.com/18126079/ [21:16] arosales: The configure method requires a "config" param: https://github.com/marcoceppi/layer-mongodb/blob/master/lib/charms/layer/mongodb.py#L66 [21:17] arosales: I'm guessing that just needs to be changed to: m.configure(config()) [21:24] cory_fu: thanks, I'll give that a try [21:29] how do you specify the repository in juju2 like juju1? --repository=blah/blah [21:29] just give it a path to your local charm [21:30] mskalka, ^^ [21:30] juju deploy /home/charmbuilder/charms/trusty/mynewcharm [21:30] magicaltrout, thanks [21:31] no problem.... appears the charmers don't believe in depreciation of stuff! ;) [21:31] lol [21:35] cory_fu: following up on our conversation about unit testing layered charms this morning ... I may push back and say that we really do need to build a layered charm before unit testing it; the code isn't really complete until you do so. [21:35] That said ... [21:35] Behold the horrors that I have wrought: http://paste.ubuntu.com/18127615/ [21:35] Why? [21:36] Ask again after you read the module I linked above :-) [21:36] That code actually works, and it handles the issue where I want to import the "real" charms.layer.apache_bigtop_base in my test while mocking out charms.layer.options [21:36] *case (not issue) [21:37] Here's the top of my test class, to give an example of actually using it: http://paste.ubuntu.com/18127718/ [21:40] cory_fu: I'd like to spend a little more time writing tests with the thing that I linked above, just to see how weird or messy it gets in practice. It may be cleaner to just tell people to build the charm and then run "make unit_test", though ... [21:45] Any good references or methods for negotiating a relation that sets up a database charm with a web application? [21:45] I am happy about having written something that involves a closure, hacking the sys module, and monkey patching import. I'm not sure that it's the right kind of happy, though ... [21:45] What's the best way to pass around the credentials? [21:46] I'm familiar with lifecycle hooks, but I'm new to relation hooks. [21:51] igonl: if you're writing a charm, you can use relation-get to fetch things like the password, which the database charm will generally generate for you. Take a look at the "database-relation-changed" from the walk-through for reference: https://jujucharms.com/docs/1.25/authors-charm-writing [21:52] If you're writing a layered charm, things are a little bit different. It doesn't sound like that's what you're doing, though. [21:53] igonl: i might have something [21:53] Yah, that looks good. I've found relation-get and relation-set helper methods. [21:53] * magicaltrout greps around launchpad [21:54] petevg: https://github.com/juju-solutions/layer-apache-bigtop-base/commit/a4c1b8355c9032d0e7f577af9ecc92e25e93f9e7 [21:54] Docs do stress that they run out of order though and to not rely on anything from those methods being there. Then something about the -relation-changed being the best place to get variables. [21:55] I did test the out of order bit to be true using `sleep` to change the writes to a file. [21:55] petevg: That works for me. The pre-import of charms.layer and the create=True are both critical, though [21:55] I can't use Layers as it's built in python and I'm sticking with Bash-only. [21:56] cory_fu: Yep. I was going for something where we could generate a list of all the things that we need to mock, and pass it in all at once, rather than ending up with a cascading layer cake of "with" statements. [21:56] igonl: http://bazaar.launchpad.net/~spicule/charms/trusty/saikuanalytics-enterprise/trunk/view/head:/hooks/mysqldb-relation-changed [21:56] i use that to get mysql details and store them in a file inside my charm install [21:56] igonl: no pressure to use layers -- I just wanted to make sure that was wasn't pointing you at bash when you were looking at Python :-) [21:57] magicaltrout: I like the juju log message in that script, thanks. [21:57] petevg: My point was that I think we can avoid having to mock builtins.__import__ [21:58] I was interested in if any usage of the environment variables provided were being used in such charm conversations. $JUJU_REMOTE_UNIT [22:01] cory_fu: We could actually hide multiple calls to .patch in a context, so it would look something like 'with mock_modules([ Hrm. It seems like removing the pre-import of charms.layer works ok after all [22:04] It should. I was only pre-importing it in my code because I wanted it in sys.modules. [22:04] Sometimes package namespaces work strangely [22:04] ... before I did my module hacking, that is. [22:04] Anyway, I have to EOD [22:04] Cool. I am going to do the same soon. Catch you later. [22:04] petevg: I got about 1/4 of the way through reviewing your hiera layer change. :p [22:05] I'll finish it first thing tomorrow [22:08] igonl: just fyi, you can write bash layers.. openjdk is an example bash charm: https://github.com/juju-solutions/layer-openjdk/blob/master/reactive/openjdk.sh [22:10] igonl: i should note that interfaces need to be in python, but the charm layers can be in bash. [22:10] kwmonroe: had no idea. Must of developed the bad assumption off of what the docs showed and from the charms I browsed. Thanks. [22:11] anyone seen a situation where the bootstrap node gets *very* high load average? We had a power outage recently, and the maas cluster I'm using came back ok but it was slow to do anything with juju [22:11] after many failed attempts, I was finally able to ssh to the bootstrap node and it had a load avg near 500! [22:11] Ya'll Ill take another look at layers. They did seem like one more layer of abstraction I didn't want to deal with when learning charms. [22:12] syslog is getting flooded with a lot of messages like this: [22:12] Jun 29 22:12:08 limited-club mongod.37017[20063]: Wed Jun 29 22:12:08.533 [conn918] update presence.presence.pings query: { _id: "e548e092-a274-46ef-8ed7-089b1cb954d7:1467238320" } update: { $set: { slot: 1467238320 }, $inc: { alive.36: 4294967296 } } nscanned:0 idhack:1 nupdated:1 fastmodinsert:1 keyUpdates:0 locks(micros) w:116225 116ms [22:12] (and many more, all from mongod) [22:12] restarting juju-db brings it down for a little while, but it always creeps back up [22:12] kwmonroe: btw that's some clean code you wrote there. [22:13] THANKS igonl! see magicaltrout? i do good things.. ^ [22:14] i never said you didn't kwmonroe [22:14] too right magicaltrout, too right. [22:14] chip chip cheerio [22:14] i just defer to cory_fu when it comes to you explaining the stuff you've done :P [22:14] lolz [22:19] ah its still online! [22:19] kwmonroe: http://www.whoohoo.co.uk/cockney-translator.asp [22:19] that is more important than apache beam [22:20] oh hairy biscuits [22:30] hey kjackal admcleod, on the off chance you're online.. how long should a hbase perf-test take on aws? [22:31] ha! nm, just returned in 1300 seconds.. i guess that's how long. [22:32] i believe what you really mean is kjackal admcleod, on the Frank Bough chance you're online.. 'a long should a 'base perf-test take on aws? [22:34] :) that's exactly what i meant [22:35] of course [22:35] you have to bear in mind admcleod 's scottish background [22:36] Guid day kjackal admcleod, oan th' aff chance yoo're online.. hoo lang shoods a hbase perf-test tak' oan aws? [22:36] would be better