[00:05] lazyPower: o/ [00:05] hey thumper! [00:05] lazyPower: your b'day today for you right? [00:05] in a couple hours ye [00:06] so it is today for me, not you [00:06] happy birthday from the future [00:06] xD [00:07] how old ya gonna be lazyPower ? [00:08] 33 [00:09] awww we become the same age yet again...... [00:11] ;) [00:11] I'm cool with following in your footsteps. I've had worse role models [00:11] zing! [00:19] here you go lazyPower, I have your beats lined up for the flight tomorrow, in the mean time, you can learn a lot from this: https://www.youtube.com/watch?v=5pidokakU4I [00:19] ;) [00:22] THIS IS FANTASTIC! [00:22] hehe [00:22] its pretty clever [00:28] lazyPower: I am so far from unpacked! [00:28] i hear ya i'm on the other end of that, as in not packed. === natefinch-afk is now known as natefinch [02:48] lazyPower: you still around? [02:48] menn0 i am. hacking on etcd - whats up? [02:49] lazyPower: I have a potentially stupid question about charm revisions [02:49] i have an equally potentially stupid answer :) [02:49] go for it [02:49] lazyPower: in the charm store the ubuntu charm has a rev of 0 [02:49] if you install it the charm URL is cs:ubuntu-0 [02:49] yet it has a revision file with 7 in it [02:49] what's up with that? [02:50] When a charm is published it goes into the unpublished channel, and these entities increase n+1 everytime you push [02:51] when you "publish" a charm into a channel, that creates a new revision for that channel, again, n+1 that is a reference to the charm-revision in the unpublished channel. [02:51] so its likely there is a cs:ubuntu-0 through cs:ubuntu-7 in the unpublished channel, while the stable release is pointed at cs:ubuntu-7, thus resulting in cs:ubuntu-0 having a revision file with the contents of "7" [02:52] lazyPower: ok right [02:52] lazyPower: this is causing me some headaches with model migrations... but I think I can work around it [02:52] https://jujucharms.com/docs/devel/authors-charm-store [02:52] i think this is a temorary headache while we start to roll things over in teh new store [02:53] s/temorary/temporary/ s/teh/the/ [02:55] lazyPower: ttvm... this explains a lot [02:55] I will have to accomodate this in model migrations [02:55] happy to help menn0 [08:30] tinwood, I'd be really grateful if you could take a look at these http://paste.ubuntu.com/16942097/ when you have sometime. The charms.openstack pull request is probably the more important/contentious [08:30] gnuoy, sure no problem. [08:31] gnuoy, sneaky :) Four reviews in one paste! [08:31] yeah, sorry === mup_ is now known as mup === stokachu_ is now known as stokachu === FourDollars_ is now known as FourDollars [09:08] Hi, is it safe to use logroate on juju's logs? [09:26] does juju has some built-in mechanism for log rotation or can I go ahead and add a logrotate script? [09:27] do i need to reload rsyslogd post rotation? === \b is now known as benonsoftware === Anita is now known as Guest22054 [11:45] gnuoy, review on charms.openstack done. Now moving on the others. [11:57] gnuoy, reviews done. I'm busy from 1pm till about 2pm, but otherwise free, if you want to push back on those comments! :) === CyberJacob is now known as zz_CyberJacob [12:17] gahan: it is safe to logrotate, but juju should do that for you. What version of juju are you using? [12:23] marcoceppi: i'd like to revamp the mongo charm to make it suck less, but its in ~charmers and owned by lazyPower etc [12:23] do i need to do anything other than fork it to make it happen? [12:24] magicaltrout: you could use the layer I started but never got around to finishing as a base [12:24] cool [12:24] magicaltrout: the old charm is gross, best to just start fresh for Xenial [12:24] yeah [12:24] https://github.com/marcoceppi/layer-mongodb [12:24] excellent [12:25] magicaltrout: I got installing and switching between versions pretty much done, next was to figure out how to replica set [12:26] magicaltrout: it's a few months old, so the reactive file needs some love to drop the abuse of @hook, happy to help where I can (just as soon as I finish up my gitlab changes ;) [12:27] yeah im not in a huge hurry for it but 2.4 is ancient and it just needs some love [12:28] 2.4 is pre agg framework wihch will make a lot of apps like drill quite sad [12:29] also marcoceppi whats the status on decoupling layer basic from ubunut? [12:29] ubuntu [12:31] magicaltrout: just some talk, we're not sure how to really decouple, there's a bunch of ways to do it. I was thinking we could possibly have a layer:ubuntu, layer:centos, layer:windows approach [12:31] which would all inherit the "basic" layer which would simply be the bits required to install reactive [12:31] yup [12:32] cory_fu: ^ thoughts? [12:33] i'd like ot make a concerted effor to build cross platform charms for people who are crazy and run centos etc [12:33] magicaltrout: well that becomes a little more difficult [12:33] but of course apart from saiku every charm i write inherits layer basic [12:33] really it boils down to linux and windows, and it starts getting messy with package management [12:34] so, excluding windows for a hot min [12:34] windows I can get over [12:34] httpd vs apache2 [12:34] there's not standard package names for ubuntu vs centos [12:34] which means, without an abstraction layer like puppet, chef, anisble, etc, making a cross-linux charm is going to be tough [12:36] yeah but in part thats your competition so why not at least come up with a plan as to how to leverage centos based charms alongside ubuntu ones [12:36] in puppet its easy enough to alias that type of stuff [12:37] magicaltrout: you can, you just use puppet, chef, ansible, whomever inside your charm ;) [12:37] thats a crap answer :P [12:37] why re-invent configuration management whene there's N+1 tools already doing it? [12:37] its' the reason charms are langauge agnostic [12:37] ^ this [12:38] we really don't care how you set up the machine, you just need to set the machine up so it can participate in the model [12:38] yeah but you're telling me as a charm author if I want to support non ubuntu i need to use puppet to configure it or write a centos specific charm [12:39] in which case as a service provider i might as well just write a puppet module and stick it in puppet forge [12:39] of course i'm just playing devils advocate here, but i think its valid reasoning [12:39] magicaltrout: puppet doesn't get you what juju does. In the same way that docker doesn't get you waht puppet does [12:40] why is wrapping a charm around a docker container valid but wrapping a charm around a puppet module not? [12:40] furthermore, there's nothing stopping you from writing a bit of python that does this feature from all the other CM tools [12:40] i dislike wrapping docker containers as well :P [12:41] yeah? [12:41] you don't have to use any of these CM, just that it's a solved problem - right tool for the job kind of thing [12:41] magicaltrout - one of these days i want to talk to you about that :) get your insights there [12:41] why wrap a charm around a java application? [12:41] why wrap a charm around anything at that point? [12:41] you wrap a charm around an app to provide actions and relations [12:41] but i could install saiku on any java running platform with no change in code [12:41] you wrap a charm around a puppet script to provide it actions and relations ;) [12:42] my thinking is why do i need to wrap puppet in a charm to do the same, I don't want to learn juju & puppet to do the job [12:42] I just want to learn juju [12:42] hell [12:42] I think you have a valid point [12:42] i hate ruby :P [12:43] ultimately, this functionality, installing packages across distributions of linux, isn't unique to juju/charms. I would have hoped that by now someone had found a tasteful way to do it in python, either by extracting it from a CM tool, or just spear heading it [12:44] i'm not saying i wont figure out a way to do it, but I do think there should be at least some basics in charmhelpers or somewhere [12:44] (there's also a pull request on charm-helpers to add transparent switching between apt and yum based on the linux you're on) [12:44] but that means you'll have to maintain logic in your layers to say this list of packages are APT, this list is YUM [12:44] i'm not trying to absolve myself of responsibility, and also you lot work for canonical so I wouldn't see it being top of your lists either [12:44] well i think with the proper abstractions, and amenities to the charm - you could do some build matrices of a layer.yaml that would give you pretty good results in 'just juju and python'. [12:45] but having talks to people at strata hadoop and stuff yesterday, its a pertinent question [12:45] we will however need to do that 3 tier breakout of basic => series [12:46] yeah [12:46] magicaltrout: https://code.launchpad.net/~dbuliga/charm-helpers/charm-helpers/+merge/296320 [12:46] i think it would be pretty easy to prototype though [12:46] even if it doesn't cover all use cases [12:46] magicaltrout: if you want to help shepard some of the underpinnings for this in [12:47] and sorry for using the word abstraction there, when i mean - using the same patterns with the same state mechanics. Just replacing the bits you cant make generic. [12:47] yeah [12:47] okay marcoceppi i'll try and pick some of that up and see what I can do [12:49] lazyPower: sounds like you have layer basic -> layer:ubuntu, layer:centos which inherit it and just override any functions you can't genericise [12:49] yeah [12:49] and i htink if you do something like layer_options for the package list, and override that as required... [12:50] magicaltrout: I imagine it'd be something like (layer:ubuntu,layer:centos) -> layer:linux -> layer:basic [12:50] it seems like it could work [12:50] also i remember talk of Windows getting and APT like package manager [12:50] could work over there as well [12:50] yeah valid point marcoceppi [12:50] where if you want to jump into a non-distro specific charm, layer:linux is what you'd use [12:50] disregard i said that... it sounds worse now that i've read it out loud [12:50] hehe [12:50] and with custom tactics, we could do some clever things [12:50] lazyPower: did you ever get custom layer tactics working? [12:51] uhhhhhh [12:51] yes [12:51] but its not shipped [12:51] its in layer-docker branches somewhere [12:51] what's custom tactics? [12:51] dare i ask? [12:51] cool, just curious [12:51] magicaltrout: another knife for which you can poke your eye with ;) [12:51] things the builder does when building charms [12:51] so like, i want to wheelhouse *all the thingggssss* [12:52] i need to customize the venv in which its buliding the wheelhouse :P [12:52] a-la even more sticks in even more eyes [12:52] right, so a tactic is what the builder uses to process files during the build process [12:53] got ya [12:53] cool [13:00] http://pastebin.com/3TsBLLG8 from where I'm sitting (heathrow terminal 5 quiet zone.....) it seems like thats not too far removed as an implmentation technique that could be done in juju [13:00] and would make sense without getting too far down the line into reinventing puppet [13:01] in the dependencies yaml you could easily do something like [13:01] https://gist.github.com/buggtb/1805107403835aa897657cfa0ac08f8c [13:01] which would be pretty clean [13:02] it'd be great if there was like an online registry of every "software" name and it's corrosponding package name in an OS so that you could have it populate this mapping during charm build [13:02] packages.juju.solutions ;) [13:05] marcoceppi: regarding logrotate -> using juju 1.25 [13:06] magicaltrout: <3 [13:07] gahan: this was fixed in 1.25.5, what does `juju version` say explicitly? [13:12] is there a preferred way for handling relation departures with interface layers? [13:12] i.e. what's a good practice for this? [13:14] marcoceppi: 1.25.5-trusty-amd64 [13:14] marcoceppi: how often are they rotated? monthly? depending on size? [13:16] gahan: i think it's size dependant [13:19] tasdomas - i'm actually working through that right now [13:20] tasdomas - i can step you through what i'm implementing shortly, its not pushed anywhere. I can ping you then? [13:20] lazyPower, sure! [13:21] tasdomas - but before i skip the basics. Have you read the interface-layers doc page? [13:24] lazyPower, yeah [13:25] tasdomas - https://github.com/juju-solutions/interface-namenode-cluster/blob/master/peers.py#L36 - may answer your question before i do as well [13:26] lazyPower, perhaps I should have asked a better question [13:27] lazyPower, I'm thinking about the charm layer - basically - when a relation is broken/departed, the *_available state gets removed from the conversation [13:27] lazyPower, but if I need e.g. to remove some entry from a file [13:27] is there a way to get data on which conversation got broken? [13:30] there is, this is what i was just testing [13:30] magicaltrout: can drill ingest data sources from elastic search? [13:31] not yet marcoceppi there is an open ticket for that. Also I have a proposal in with a client to build that connector [13:31] i don't know if they'll say yes or not, but it will arrive sooner or later [13:31] magicaltrout: sweet, that'd be awesome [13:31] yeah, its not hard to build either because elastic searches query lanugage isn't that expressive [13:32] so you'd push some filtering down to ES and do the aggregations and grouping in memory i suspect [13:32] a bit like mongo pre-aggregate framework [13:32] the underlying calcite engine will allow you to run SQL over the resultset that isn't technically supported by the source data [13:32] which is pretty cool [13:35] it was something me and SaMnCo touched on briefly yesterday, the ability to do full analytics and reporting over beats and other ES data sources [13:37] lazyPower, so maybe the way to handle departures is to set a _departed state on the conversation? [13:38] lazyPower, that way at least the conv object would get passed to the state handler [13:38] tasdomas - That works, The one thing i did find is that i had to leverage the -departed hook as my source of who was actually leaving the conversation [13:39] the -broken triggers on every unit. In my specific case i'm deregistering and terminating a unit, before it goes it has to self unregister. It was neat to see every unit but the leader drop offline [13:40] lazyPower, is there a snippet of a source file you could point me at? [13:41] https://gist.github.com/e8fe095b99a17038d399ee6776cfb2b7 [13:41] line 37 [13:42] and https://gist.github.com/anonymous/f157083d14a930493a4cafcd2b1da7ae#file-etcd-py-L316 - is where i handle it in the reactive code. [13:44] lazyPower, I see that you don't call depart() on the conversation - is that something that needs to be done? [13:45] Thats news to me. I'll look in a sec. I'm seeing the proper behavior but i may be leaving things open. [13:45] s/open/incomplete [13:45] okay so 10 hours on a flight *if* i have at seat power, I need to a) add some more config to Drill b) write some PDI charm tests c) listen to lazyPower's beats d) write some Saiku relations for other data sources e) finish off Saiku schema stuff so it hooks in juju properly for 3.9 [13:45] should keep me busy [13:45] saved the beats for the plane huh? bold move [13:46] hehe [13:46] i also want to write a Pentaho BI server charm as well [13:46] so i have their stuff downloaded for the flight [13:47] I've been told the jams were rocket fuel for charming. this is per kwmonroe_ [13:47] hehe [13:48] it is lazyPower music beats, or is it lazyPower talking about elasti.co products? [13:48] its music jrwren :) [13:49] cool. oontz oontz oontz. [13:49] trip hop actually [13:51] but oontz indeed :) [13:53] marcoceppi: thanks [13:53] i was thinking: tshuk tshuk -- thump [13:55] alrighty time to find some caffiene and a flight [13:55] see ya'll in 12 hours [14:08] jrwren niiice, even better [14:23] I am trying to install JUJU 2.0 as non-root [14:23] But "juju bootstrap lxd-test lxd" giving error [14:24] tried logging off and loggin in again as nonroot user [14:24] but problem is still not solved [14:26] Anita_: can you create an lxc/lxd instance using `lxc launch ubuntu:` ? [14:27] ok let me try [14:27] root@c277-pkvm-vm62:~# su - charm charm@c277-pkvm-vm62:~$ lxc launch ubuntu: error: Get http://unix.socket/1.0: dial unix /var/lib/lxd/unix.socket: connect: permission denied charm@c277-pkvm-vm62:~$ [14:27] charm@c277-pkvm-vm62:~$ groups charm lxd charm@c277-pkvm-vm62:~$ [14:28] root@c277-pkvm-vm62:~# su - charm charm@c277-pkvm-vm62:~$ lxc launch ubuntu: error: Get http://unix.socket/1.0: dial unix /var/lib/lxd/unix.socket: connect: permission denied charm@c277-pkvm-vm62:~$ [14:29] Anita_: does `id |grep lxd` output anything or is it blank? [14:30] charm@c277-pkvm-vm62:~$ id |grep lxd uid=1001(charm) gid=1001(charm) groups=1001(charm),116(lxd) charm@c277-pkvm-vm62:~$ [14:30] are you able to get my message jrwren? [14:31] Yes I am able to get your message [14:31] charm@c277-pkvm-vm62:~$ id |grep lxd uid=1001(charm) gid=1001(charm) groups=1001(charm),116(lxd) charm@c277-pkvm-vm62:~$ [14:31] Anita_: yes. I read you. is lxd running? `ps auxw | grep [/]usr/bin/lxd` [14:32] charm@c277-pkvm-vm62:~$ `ps auxw | grep [/]usr/bin/lxd` The program 'root' is currently not installed. To run 'root' please ask your administrator to install the package 'root-system-bin' charm@c277-pkvm-vm62:~$ [14:32] Shall I install root-system-bin? [14:33] don't paste my backticks. I included those only to be clear about what command I wanted you to run. [14:33] run only: ps auxw | grep [/]usr/bin/lxd [14:33] k [14:33] sorry ok [14:34] charm@c277-pkvm-vm62:~$ ps auxw | grep [/]usr/bin/lxd root 12249 0.0 0.6 492736 25152 ? Ssl 04:48 0:05 /usr/bin/lxd --group lxd --logfile=/var/log/lxd/lxd.log charm@c277-pkvm-vm62:~$ [14:34] no worries. I write too much markdown ;] [14:34] :) [14:35] hrm, well, those are all of the simple things to check. I do not know what to check next. [14:35] Anita_: ls -al /var/lib/lxd/unix.socket [14:35] charm@c277-pkvm-vm62:~$ ls -al /var/lib/lxd/unix.socket srw-rw---- 1 root root 0 Jun 3 02:52 /var/lib/lxd/unix.socket charm@c277-pkvm-vm62:~$ [14:36] charm@c277-pkvm-vm62:~$ juju bootstrap lxd-test lxd ERROR invalid config: can't connect to the local LXD server: Permisson denied, are you in the lxd group? Please configure LXD by running: $ newgrp lxd $ lxd init [14:36] charm@c277-pkvm-vm62:~$ newgrp lxd charm@c277-pkvm-vm62:~$ [14:36] newgrp lxd is successful [14:36] looks like that socket is owned incorrectly. [14:37] Anita_: sudo chgrp lxd /var/lib/lxd/unix.socket [14:37] Anita_: and try lxc launch command again. [14:37] ok [14:37] lxc launch command is means initializing lxc? [14:38] sudo dpkg-reconfigure -p medium lxd? [14:38] Anita_: it starts an lxc instance using lxd just like juju would. [14:39] Anita_: that probalby wouldn't hurt, but no, by "try lxc launch command again" i mean run `lxc launch ubuntu:` like I said in my first reply. [14:41] Ok I will try [14:42] gnuoy: ping [14:42] hi bryan_att [14:42] gnuoy: hi, I had a question about the Congress charm you showed working [14:42] sure [14:42] charm@c277-pkvm-vm62:~$ lxc launch ubuntu: Creating legal-enid Starting legal-enid charm@c277-pkvm-vm62:~$ [14:42] This time its giving some output [14:43] Anita_: that worked. you can `lxc stop legal-enid ; lxc delete legal-enid` and juju bootstrap now. [14:44] ok [14:44] gnuoy: per http://paste.ubuntu.com/16729946/ I was not able to duplicate this and want to know more about the test [14:44] bryan_att, sure, what would you like to know? [14:45] which bit is not working for you? [14:45] gnuoy: there are no trusty packages for Congress. Where did you get the packages from? [14:45] bryan_att, I built from git branch [14:46] bryan_att, line 23 of the pastebin [14:46] juju bootstrap is running... taking sometime [14:46] charm@c277-pkvm-vm62:~$ juju bootstrap lxd-test lxd [14:47] gnuoy: OK, when I tried that I had an error - I will paste the bin link again [14:49] charm@c277-pkvm-vm62:~$ juju bootstrap lxd-test lxd Creating Juju controller "local.lxd-test" on lxd/localhost Bootstrapping model "admin" Starting new instance for initial controller Launching instance WARNING error copying image: Failed to create ZFS snapshot: cannot create snapshot 'lxd/images/5a2cd3b9793fb066f28399deb294da31c56a7f18c577c73b6bfae1a1918fb007@readonly': dataset already exists no snapshots were created unable to get L [14:49] charm@c277-pkvm-vm62:~$ juju bootstrap lxd-test lxd Creating Juju controller "local.lxd-test" on lxd/localhost Bootstrapping model "admin" Starting new instance for initial controller Launching instance WARNING error copying image: Failed to create ZFS snapshot: cannot create snapshot 'lxd/images/5a2cd3b9793fb066f28399deb294da31c56a7f18c577c73b6bfae1a1918fb007@readonly': dataset already exists no snapshots were created unable to get L [14:50] gnuoy: OK, that was an earlier error. But where I am is I don't see how you were able to get the service running with the charm as-is. I had to modify the chsrm for the build process as it did not include all the necessary steps. [14:50] gnuoy: I will paste the current procedure - hang on [14:50] sounds good [14:53] gnuoy: let's talk about this procedure from congress.py https://www.irccloud.com/pastebin/hMMamRRJ/ [14:54] gnuoy: there are several things there that were not in your original, but are necessary for the service to be activated (as you showed by the datasource creation step) [14:54] jrwren_: lxd/images/5a2cd3b9793fb066f28399deb294da31c56a7f18c577c73b6bfae1a1918fb007 is looks like some previous image which couldnot delete due to read-only [14:55] is that causing issue? [14:55] Anita_: that would be a different issue. [14:55] gnuoy: not that this all works yet - I just don't see how you were able to activate the service without the full sequence of steps, e.g. congress-db-manage [14:56] bryan_att, those two commented out lines look like mistakes [14:56] jrwren_: after this bootstrap should pass? [14:56] bryan_att, having said that there is a congress-db-manage step [14:56] gnuoy: they are earlier attempts - ignore them [14:57] gnuoy: OK, let's compare to your original [14:57] ok [14:57] jrwren_: what is the steps to clean a lxd when we uninstall juju 2.0? [14:59] jrwren_: what is the step to uninstall juju 2.0 ? [14:59] gnuoy: hang on, relocating the original [14:59] bryan_att, sure, no problem [15:00] Anita_: i do not know. I only know a little about getting to running. [15:00] gnuoy: here is your original https://www.irccloud.com/pastebin/2OJIMozC/ [15:01] jrwren_: wants to retry after proper clean up [15:01] gnuoy: there is no congress-db-manage step in that - how did you init the schema? [15:01] tinwood, gnuoy - so with tempest charm now in gerrit, i'm trying to add a very basic unit test. i immediately hit the namespace conflict between lib/charm/openstack/foo (charm.openstack.tempest vs charm.openstack layer, which i presume is why charm_openstack is the new module name) [15:02] bryan_att, if you look in reactive/handlers.py you'll see that when the database is ready the schema is initialised [15:02] bryan_att, http://paste.ubuntu.com/16948479/ [15:03] gnuoy: when I tried your example that did not work [15:03] Anita_: if `lxc list` shows an empty list, I've `rm -rf /var/lib/lxd/` and then run `sudo lxd init` [15:03] Thanks a lot jrwren... will retry after uninstall of juju 2.0 [15:03] so after switching to the charms.openstack (charms_openstack) module in the tempest charm, import issues are solved. now it complains that i've not declared a release. i want the charm to declare that it works with all releases, but stumbling on how to express that. https://github.com/openstack-charmers/charms.openstack/blob/master/charms_openstack/charm.py#L110 seems to accept only one. [15:03] gnuoy: I assumed that these were missing steps that had to be manually included in the src_install script [15:03] may be after proper clean up, it will work with the steps that you provided [15:03] Ok [15:04] bryan_att, no, the charm is setup to do the migration [15:04] charm@c277-pkvm-vm62:~$ lxc list +---------------+---------+------+------+------------+-----------+ | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | +---------------+---------+------+------+------------+-----------+ | claylike-doug | STOPPED | | | PERSISTENT | 0 | +---------------+---------+------+------+------------+-----------+ charm@c277-pkvm-vm62:~$ [15:04] gnuoy: understood that by intent it is - but it did not work for me [15:04] bryan_att, ok, we need to work through where you hit a problem [15:05] gnuoy: I was trying this last week and not able to replicate your results - so I tried to do those steps scripted to get further. When I ran your example as-is the database schema did not get setup [15:05] beisner, yes, that's basically what we were up against. [15:05] bryan_att, did you add the relation between congress and mysql? [15:06] gnuoy: I got the error "no policy table" when trying to start congress-server - it never successfully started [15:06] gnuoy: yes, I added all the relations [15:07] gnuoy: if I try your example again, what debug logs do your need? I can provide the syslog from the congress-server at least where you can see the failure. [15:08] bryan_att, /var/log/juju/* from the congress server would be good [15:09] gnuoy: OK, I'll collect those this weekend and post them. Maybe we can talk again next week? I'm trying to get this done before the 19th (OPNFV Summit) and really no later than next week. [15:09] bryan_att, sure, I will redeploy using the steps I posted [15:09] as well [15:10] gnuoy: OK, thanks for your help [15:11] bryan_att, np [15:14] tinwood, where did OpenStackCharmFactory wind up? tempest charm previously extended openstack.charm.OpenStackCharmFactory but no bueno with charms_openstack [15:14] beisner, it disappeared. A new funky singleton has replaced it, along with get_charm(). [15:15] well f_ [15:15] tinwood, i think i'll just add a no-op unit test that passes instead of having to refactor this whole charm. i just need the charm as a vehicle. [15:21] cory_fu: so, im writing this bigtop pig charm, and i need to define 2 bigtop roles: hadoop-client (to install the hadoop components) and pig-client. however, that results in having the hadoop head node overwritten with what appears to be a default fqdn. i suppose i need to get the namenode and resourcemanager from the plugin relation and then render_site_yaml with those hosts? [15:23] beisner, sure. -- I kind of pulled the rug out of OS layered charms with this change, but wanted to do it now rather than later. [15:23] bryan_att, found an issue with keystone not knowing about congress. I fixed that locally before and the pastebin I sent you does not include how to deploy the fixed icehose. Sorry about that. [15:23] s/icehose/keystone. [15:23] tinwood, ack agree breaking before we really ramp up using it :-) [15:23] gnuoy: thanks! that's one of the issues I did see persistently from JuJu. [15:24] admcleod: That is correct. When I finish the non-install version of the hadoop-plugin relation, you'll want to use that instead as well, so that you don't end up with hadoop-plugin fighting with pig over the site.yaml [15:25] admcleod: So you'll need a @when('hadoop.ready') decorator and the handler should have `def foo(hadoop): bigtop.render_site_yaml(hosts={'namenode': hadoop.namenodes()[0]})` [15:26] Something like that [15:26] bryan_att, ooi what version of juju are you using? [15:26] gnuoy: not 2.0 1.x something [15:27] bryan_att, are you on 1.25.? [15:27] admcleod: The code would be similar to this: https://github.com/juju-solutions/bigtop/pull/3/files?diff=unified#diff-5006dc573a0911f6248e72dc6974038dR7 With the main difference being that the @when would be 'hadoop.ready' (or 'hadoop-plugin.ready' or whatever you call your relation to plugin) [15:27] bryan_att, ok, cool, thanks [15:27] Otherwise, the code of the handler should be nearly identical [15:27] gnuoy: let me look back thru the logs - i pasted it. I'm not near my test machine at the moment. [15:28] cory_fu: ok cool, got it [15:28] bryan_att, don't orry, 1.x is good enough [15:33] tinwood, fyi @ https://github.com/openstack/charm-tempest but lmk if that looks like more than a quick redux and i'll just do the noop thing for now. [15:33] beisner, okay, will do. [15:34] tinwood, thx much [15:35] hey lazyPower, happy birthday! [15:36] beisner, just out of interest, on review.openstack, how do I get into the charms-core group? Everybody else is :( [15:36] Thanks Jose :) o/ [15:36] tinwood, ah you wanna land code? ;-) [15:37] I thought that was just charm-release group. Or can core land code too? [15:38] lazyPower: hey, I managed to get bundletester to work with existing juju 2.0 model to run my layer tests! [15:38] \oo/, Nice dimitern! [15:39] lazyPower: but I found out the charm builder assumes I'm using py34 and py35 only, unless I override that with a tox.ini in the layer [15:41] lazyPower: it's ok though - just initially frustrating until I found that workaround [15:42] tinwood, yep charms-core can land. release has some other perms that i'm not completely sure of just yet. i think you should be in charms-core -- gnuoy ok with you? [15:42] beisner, ah, I see. Sure, I'd like to be apart of the core group if that's okay with everyone. [15:44] lazyPower: oh man! just noticed! happy birthday indeed! \o. [15:50] jose thanks :D \o [15:50] dimitern thanks buddy :) [16:11] openstackers, I have some hotness for you: http://askubuntu.com/questions/tagged/juju?sort=featured&pageSize=50 [16:11] I have many internet points to give away [16:40] tinwood, added you to openstack charms-core [16:41] tinwood, shall we put those new powers to work right away? ;-) https://review.openstack.org/#/c/325398/ ;-) need to land that so i can proceed to add a very basic func test. then we'll be clear to automate layer build/test flows using this as subject matter. [16:46] bryan_att, I just redeployed again and was able to create a datasource. http://paste.ubuntu.com/16952298/ shows the script I used. It'd be better as a bundle but I wanted to include the build step [16:51] bryan_att, I'm at my EOD but I'll check in later if you have any questions === redelmann is now known as rudi|comiendo [17:00] hi thedac, can you give this tactical thing of beauty a look and a kick for me? :) https://review.openstack.org/#/c/325398/ [17:12] beisner: just got off of calls. I'll take a look shortly [17:12] thedac, thx much === rudi|comiendo is now known as redelmann [17:35] jhobbs, fyi, we're moving charm-tempest into gerrit, so the openstack-charmers git repo will be removed soon. that repo has already been pulled into openstack git/gerrit. we're just ironing out CI around it. but wanted to alert you to the new location in case you have mods in-flight. [17:35] beisner: ok - can you give me a url to the new location? [17:36] jhobbs, fyi https://github.com/openstack/charm-FOO is the general format. so for this one: https://github.com/openstack/charm-tempest [17:36] ah [17:36] that's easy [17:36] :) [17:36] thanks! [17:37] beisner: +2 [17:37] jhobbs, yw. the downside is that now we can't land anything until we add tests and make 'em pass. working on that now. welcome to the bloody bleeding new tempest charm yah? [17:37] thedac, thx sir [17:38] beisner, sorry, just came back online after dinner (or 'tea' as we call it hered). Thanks for adding me; sorry thedac beat me to it. [17:38] s/hered/here/ [17:39] tinwood, np and yw! i'm sure i'll have another tactical solution to merge soon ;-) [17:39] beisner: add tests - so each new MP needs a test? or you have to go back and add some tests for existing stuff? [17:39] jhobbs, the landing gate won't land without passing tests so we're working on getting some really basic tests in the charm. then it's a dive into the unknown: git/gerrit/layer/ci ;-) [17:40] k [17:40] jhobbs, fwiw, we're using this tempest charm as 'the first' layered charm through ci so it'll be paving the way through, making some noise for a bit. [17:41] as an unreleased thing which not many people (you and i) depend on, it seems like the best first candidate through. [17:43] thedac, wow upstream job queue is high, still catching up from the outage last night it seems. [17:55] gnuoy, asking in infra if they can re-init that repo from https://github.com/openstack-charmers/charm-hacluster, or whether we need to revert that infra change and resubmit. hopefully they can just re-init for us but i'll let you know. [18:23] gnuoy, fixed-up :-D https://github.com/openstack/charm-hacluster [18:31] Friends... I'm having trouble finding documentation on the contribution process. I've added an amulet test to a charm and would like to submit it for review. Anyone have a link to point me in the right direction pls? [18:40] j_king: what charm? [18:41] rick_h_: mongodb. [18:41] j_king: so the code for the charm is here: https://code.launchpad.net/~charmers/charms/trusty/mongodb/trunk I'd submit a MP on that [18:42] j_king: and when you ahve that up let me know and I'll make sure to poke folks to look at and see about landing. [18:42] rick_h_: forgive me but it's been a dogs age since I've used bzr. :) what's an MP? [18:42] j_king: sorry, pr = github, mp = merge proposal in launchpad terms :) [18:43] pull request by other names === kwmonroe_ is now known as kwmonroe [18:47] cargonza: jamespage, gnuoy ^ note we need to improve https://github.com/openstack-charmers/openstack-community page [18:49] Question: if I want a list of the attributes that I can fetch with unit-get, where should I look? ('man unit-get' isn't helpful) [18:51]