| mux | hmm | 00:12 |
|---|---|---|
| mux | I'm having a hard time understanding the difference between 'juju storage <whatever>' and the juju 'storage' charm | 00:12 |
| mux | is the 'storage' charm still a thing? | 00:14 |
| thumper | mux: the storage charm was a temporary fix until juju got the right primitives in place | 00:51 |
| thumper | the juju storage commands should supercede the storage charm | 00:51 |
| mux | ahhhh | 01:14 |
| stokachu | wallyworld: to elaborate on my question, when I do a juju list-controllers, is there an exposed api call that I can use to get the same data? | 02:13 |
| Makyo | Trying to bootstrap an lxd env, but I keep getting "ERROR cannot find network interface "lxcbr0": route ip+net: no such network interface" - what would that mean? | 02:14 |
| wallyworld | stokachu: list-controllers is a client side operation working the the locally stored controllers.yaml file | 02:14 |
| wallyworld | there's code to cread that file | 02:15 |
| wallyworld | but it's not a remote api | 02:15 |
| stokachu | wallyworld: ok so my next question is should i rely on the controllers.yaml file? | 02:15 |
| wallyworld | for your locally bootstrapped controllers yes | 02:15 |
| stokachu | there are several files in ~/.local/share/juju some created by hand (clouds.yaml,credentials) | 02:15 |
| mux | man. seriously. the documentation on juju storage is really cryptic and difficult | 02:29 |
| mux | days later I'm still trying to figure out how to use juju to deploy something (anything) on AWS, while creating an EBS volume and attaching it, and using that volume for storage | 02:31 |
| mux | like, say MySQL or Postgresql or something | 02:31 |
| mux | the only one that I can find is the "demo" version of Postgres that supports the storage system, and it hasn't been touched in over a year | 02:31 |
| alexisb | mux, this doc helped me recently with making the required charm updates to use storage: https://jujucharms.com/docs/devel/developer-storage | 02:35 |
| jamespage | gnuoy, https://review.openstack.org/#/c/286451/ | 10:18 |
| === rvba` is now known as rvba | ||
| === Spads_ is now known as Spads | ||
| jamespage | anyone space a cycle for https://code.launchpad.net/~james-page/charm-helpers/fix-ssl-certs/+merge/287639 ? | 14:04 |
| jamespage | tightens up sec for the apache https frontends for openstack | 14:04 |
| === cmars` is now known as cmars | ||
| magicaltrout | kwmonroe: is there a simiple layered leader election snippet somewhere I can leach? | 15:09 |
| magicaltrout | s/layered/reactive | 15:10 |
| marcoceppi | magicaltrout: there's a leadership layer that stub wrote | 15:10 |
| magicaltrout | excellent | 15:11 |
| * magicaltrout goes off in search of the grail | 15:11 | |
| marcoceppi | magicaltrout: I think it's used in cassandra xor postgresql | 15:11 |
| marcoceppi | magicaltrout: https://git.launchpad.net/layer-leadership/tree/README.md | 15:13 |
| marcoceppi | magicaltrout: stub is great at documenting his layers | 15:13 |
| magicaltrout | aye, i've bookmarked interfaces.juju.solutions now :P | 15:13 |
| cory_fu | magicaltrout: I don't know of a specific example, but it should be as easy as @when('leadership.is_leader') | 15:14 |
| magicaltrout | yeah | 15:14 |
| magicaltrout | sadly that time has come where I feel compelled to waste hours of my life figuring it out for the first time in search of a dynamically registering pdi cluster.... | 15:15 |
| marcoceppi | \o/ | 15:16 |
| magicaltrout | indeed, it should really be too hard | 15:16 |
| magicaltrout | shouldn't | 15:16 |
| magicaltrout | brain fade, whats the templating stuff if I need to dump a variable driven XML file into a node? | 15:21 |
| lazyPower | magicaltrout - charmhelpers.core.templating import render | 15:22 |
| lazyPower | and use jinja2 templates i suppose | 15:22 |
| magicaltrout | ah that jinja2 stuff | 15:22 |
| magicaltrout | thanks lazyPower | 15:22 |
| magicaltrout | weird. PDI can have multiple masters | 15:24 |
| * magicaltrout ignores that fact | 15:24 | |
| marcoceppi | magicaltrout: that's actually okay with leadership | 15:25 |
| marcoceppi | magicaltrout: you don't have to have a 1-to-1 match of leader to master | 15:25 |
| lazyPower | hey marco | 15:25 |
| marcoceppi | juju just says "hey, you're a leader, you can help coordinate", so if that means they, the code, says "me and my pal here unit 2 are masters" that's all cool | 15:25 |
| marcoceppi | hey lazyPower | 15:25 |
| lazyPower | if i'm iterating through a scope:unit relation, and i want to poll back all the cached data from teh relations, i return the conversation scope, not the unit, right? | 15:26 |
| lazyPower | i only need the conv.scope if i'm setting data, to read just return the conversation object? | 15:26 |
| marcoceppi | lazyPower: the unit is the conversation scope | 15:26 |
| lazyPower | for conv in self.conversations(): yield conv | 15:26 |
| marcoceppi | conv is the scope, which is the unit name if you're scope: unit | 15:27 |
| magicaltrout | hmm interesting. I'll park that for now and get the basics working. I'm not sure when I'd need multiple masters, there must be a usecase I've not figured out. I'll ask the guys at pentaho when I'm really bored | 15:27 |
| lazyPower | well | 15:27 |
| lazyPower | when ir eturn conv() i can get at the data i'm looking for | 15:27 |
| lazyPower | but i'm doing get_remote() in my reactive method, not in my interface-layer | 15:27 |
| lazyPower | so it seems like i'm still breaking encapsulation | 15:27 |
| marcoceppi | lazyPower: so you're not going to want to do that | 15:28 |
| marcoceppi | get_remote should be done in the interface | 15:28 |
| marcoceppi | you can yield get_remote return data instead of the conversation, if you wanted | 15:28 |
| lazyPower | yeah, i guess that works | 15:28 |
| * lazyPower updates | 15:28 | |
| magicaltrout | this is probably a bad pattern but i'll ask anyway. the @when stuff, if I wanted 2 different launch commands one for when its a leader 1 when its not, i could annotate the trigger method with @when('leadership.is_leader') but is there a way to just check the state in the code rather than having 2 full methods and the additional stuff to go with it to launch the leader and non leader services? | 15:33 |
| === rcj` is now known as rcj | ||
| magicaltrout | like a simple if(leader): start_leader() else: start_non_leader() | 15:34 |
| magicaltrout | ooh | 15:37 |
| lazyPower | if is_state('leader.is_leader') | 15:38 |
| magicaltrout | hehe | 15:38 |
| lazyPower | or whatever the label is :) | 15:38 |
| magicaltrout | https://pythonhosted.org/charmhelpers/api/charmhelpers.core.hookenv.html#charmhelpers.core.hookenv.is_leader | 15:38 |
| magicaltrout | I found that just as you posted that | 15:38 |
| lazyPower | yeah, thats charmhelpers leadership helpers | 15:38 |
| magicaltrout | better than extra methods for the sake of it | 15:38 |
| lazyPower | bit different than the layers, but gets the job done | 15:38 |
| lazyPower | brb | 15:39 |
| magicaltrout | I think I saw this on the mailing list | 15:47 |
| magicaltrout | you can't chain annotations currently can you? | 15:48 |
| magicaltrout | like "when leader.changed.hostname or when leader.changed.port" | 15:48 |
| magicaltrout | oh actually that should just work | 15:48 |
| magicaltrout | me | 15:48 |
| magicaltrout | h | 15:48 |
| magicaltrout | or should it? | 15:50 |
| magicaltrout | cory_fu: englighten me | 15:50 |
| cory_fu | Yes, you can chain decorators. They all just get ANDed together. The only restriction is that you can't use @hook with anything else, but you shouldn't ever use @hook anyway | 15:51 |
| cory_fu | Oh, but you can't OR things together currently | 15:51 |
| magicaltrout | yeah but if I wanted to monitor a bunch of leader params, its or not and isn't it | 15:51 |
| magicaltrout | so I need a method for each param I want to track | 15:51 |
| magicaltrout | no probs | 15:51 |
| cory_fu | There's been some discussion of having a @when_any which would be super useful but has difficulties if you use it with relation states | 15:51 |
| cory_fu | But as often as it comes up for non-relation states, I think I'm just going to make it, and have it never pass params and just document it as not being recommended for relation states | 15:53 |
| larrymi | marcoceppi: hi, is there any plan for juju-deployer to support juju 2.0? | 15:54 |
| marcoceppi | larrymi: we're talking about that right now actually. We do plan to support it, but at a very narrow scope | 15:55 |
| marcoceppi | larrymi: what do you need deployer for that 2.0 juju deploy doesn't have? | 15:55 |
| rick_h__ | larrymi: fginther was looking at updates to make deployer and mojo updated yesterday. | 15:57 |
| fginther | larrymi, yes, the work is in progress now | 15:58 |
| fginther | well, for python-jujuclient and juju-deployer, not for mojo | 15:58 |
| marcoceppi | hold on | 15:58 |
| marcoceppi | how many people are trying to update jujuclient and deployer right now? | 15:58 |
| fginther | uh, hopefully 1 :/ | 15:59 |
| marcoceppi | are there like 4 teams racing to be the first? | 15:59 |
| larrymi | marcoceppi: our bundles are currently using branches .. IIUC that won't be supported in 2.0 | 15:59 |
| marcoceppi | larrymi: cool, just curious the missing feature | 15:59 |
| fginther | marcoceppi, are you also working on this? | 16:00 |
| marcoceppi | fginther: I found out that dpb1 had someone working on this and we're about to work to completely deprectate jujuclient and use another library instead of deployer | 16:01 |
| marcoceppi | sounds like I'll need to send an email | 16:01 |
| fginther | marcoceppi, I'm that dpb1 someone | 16:01 |
| marcoceppi | oh, whew | 16:01 |
| larrymi | fginther: rick_h__: ah cool | 16:01 |
| marcoceppi | I thought someone else from dpb1's team was doing this | 16:01 |
| larrymi | marcoceppi: in our case, we also use private branches | 16:03 |
| marcoceppi | larrymi: ack | 16:03 |
| marcoceppi | larrymi: but why not just upload to the charmstore and set-perms to kepe them private? | 16:03 |
| marcoceppi | so you don't have to use deployer? | 16:03 |
| fginther | marcoceppi, what are the consumers your targeting for this "another library"? | 16:03 |
| marcoceppi | fginther: basically, libjuju | 16:04 |
| marcoceppi | a native python juju library | 16:04 |
| larrymi | marcoceppi: hmm that's something we can look into if we can have the same permissions on the charm store. | 16:05 |
| larrymi | marcoceppi: does juju 2.0 support placement directives in the bundle? | 16:07 |
| magicaltrout | ooh look at that, my leader works | 16:11 |
| magicaltrout | that was painless | 16:11 |
| magicaltrout | what can go wrong now | 16:11 |
| cory_fu | :) | 16:13 |
| magicaltrout | now leadership people | 16:13 |
| magicaltrout | I assume there is a case where PDI tries to start, but leadership hasn't been sorted out? | 16:14 |
| magicaltrout | does that sound like a plausible scenario? | 16:14 |
| magicaltrout | or are leaders sorted early on | 16:14 |
| lazyPower | cory_fu - i call schenanigans | 16:16 |
| lazyPower | cory_fu - @when_file_changed('path/to/file') - its coming up as not a valid decorator :( | 16:16 |
| cory_fu | lazyPower: Are you importing it? | 16:17 |
| lazyPower | nevermind | 16:17 |
| cory_fu | magicaltrout: My understanding is that leadership is sorted out before any hooks are called | 16:17 |
| magicaltrout | okay thats good, so i don't need to trap it | 16:18 |
| * magicaltrout spins up a slave to find out what goes on | 16:18 | |
| cory_fu | That said, I haven't used it extensively, and admcleod- was running into an issue where is_leader seemed to be false on all units and I'm not sure what came of that | 16:18 |
| magicaltrout | bloody love LXD, you lot make me so happy | 16:18 |
| magicaltrout | ah yeah i saw that | 16:18 |
| lazyPower | cory_fu - i've encountered that when i force destroy the leader on pre 2.0 builds | 16:18 |
| lazyPower | cory_fu as in juju destroy-machine --force 5 | 16:19 |
| lazyPower | if 5 were the leader | 16:19 |
| cory_fu | Hrm. It's possible he did that | 16:19 |
| cory_fu | Entirely possible | 16:19 |
| lazyPower | yeah that'll break a leaderized unit | 16:20 |
| magicaltrout | thats what happens when you let loose a new zealander with a british passport who doesn't want to be associated with britain and lives in spain, loose on a development platform | 16:20 |
| magicaltrout | -o | 16:20 |
| cory_fu | lol | 16:20 |
| magicaltrout | this is weird | 16:21 |
| magicaltrout | this happened twice today | 16:21 |
| magicaltrout | I spin up a node | 16:21 |
| magicaltrout | and it claims to be up and running | 16:21 |
| magicaltrout | but there is absolutely nothing on the box | 16:21 |
| cory_fu | o_O | 16:21 |
| magicaltrout | i'm great and finding crazy shit | 16:22 |
| magicaltrout | oops | 16:22 |
| magicaltrout | sorry lazyPower | 16:22 |
| magicaltrout | http://ibin.co/2YlapnApEXm7 look cory_fu | 16:23 |
| magicaltrout | there isn't even a unit log file | 16:23 |
| magicaltrout | yet juju status tells me its ready | 16:23 |
| larrymi | marcoceppi: looking into try the charm store option, can you please point to doc for how to set the permissions? | 16:24 |
| magicaltrout | ooh | 16:24 |
| magicaltrout | that ip address is localhost | 16:24 |
| magicaltrout | so thats weird | 16:24 |
| cory_fu | I assume your charm should be installing stuff under /opt? | 16:25 |
| magicaltrout | well it should be running for a start. This is probably some LXD weirdness. juju ssh pdi/2 drops me into an LXD instance | 16:25 |
| cory_fu | That's very strange considering your charm apparently set a status, so it seems like the hook code all ran | 16:25 |
| magicaltrout | but the juju status returns 127 as an ip address | 16:26 |
| magicaltrout | it reports ready but its not installed in the container or the host | 16:26 |
| cory_fu | Very strange | 16:26 |
| magicaltrout | jam: you wanted some LXD feedback ----^ there it is | 16:27 |
| magicaltrout | there isn't even a charm installed in that container cory_fu | 16:27 |
| lazyPower | magicaltrout - RAAA :) | 16:33 |
| magicaltrout | can you not attach multiple files to a bug report in launchpad? | 16:34 |
| magicaltrout | jam: I filed it: https://bugs.launchpad.net/juju-core/+bug/1551842 | 16:37 |
| mup | Bug #1551842: Juju 2.0 Trunk launches disconnected nodes <juju-core:New> <https://launchpad.net/bugs/1551842> | 16:37 |
| magicaltrout | sorry I can't offer much more repro help | 16:37 |
| magicaltrout | I'll see what I can do | 16:37 |
| magicaltrout | oh add-unit you make me so sad | 16:39 |
| magicaltrout | maybe the repro path is easy :) | 16:39 |
| magicaltrout | https://launchpadlibrarian.net/244640212/Untitled.png | 16:55 |
| magicaltrout | thats a good one as well | 16:55 |
| jamespage | beisner, next -> openstack-charmers-next is working ok as well | 16:58 |
| lazyPower | mbruzek / anybody listening - i could use a quick review on this one - super simple + supporting test run to validate - https://github.com/juju-solutions/charms.docker/pull/12 | 17:11 |
| mbruzek | on it | 17:11 |
| jamespage | beisner, hmm - no stable branch for pxc | 17:15 |
| jamespage | I'll look into that | 17:15 |
| beisner | jamespage, ack thanks | 17:16 |
| cmars | anyone seen python exceptions when trying to `charm build` on xenial, and there's empty lines in yaml files? | 17:18 |
| lazyPower | cmars - have a stacktrace for me? | 17:18 |
| cmars | lazyPower: yep, hang on | 17:19 |
| cmars | lazyPower: https://paste.ubuntu.com/15260600/ | 17:29 |
| lazyPower | cmars - most def bug it | 17:30 |
| lazyPower | seems like the yaml parser hates the space you have in the yaml file | 17:30 |
| lazyPower | cmars - can you also gist up or tag the repos in question so we can repro with what you have that triggered it? | 17:30 |
| cmars | lazyPower: https://github.com/juju/charm-tools ? | 17:31 |
| lazyPower | yessir | 17:31 |
| _Sponge | lazyPower: Are you manx ? | 17:32 |
| ChrisHolcombe | i need some brainstorming help :). I have a way to detect hard drives that are dying with libatasmart. I don't know of a good way for a program to call juju based on an event ( drive dying ). I also don't know of a good way to have juju poll for for an event and take action. Any thoughts? | 17:41 |
| lazyPower | ChrisHolcombe you have update-status which runs every 5 minutes give/take | 17:41 |
| lazyPower | thats one way to poll | 17:41 |
| ChrisHolcombe | lazyPower, ok that's not bad. 5 mins is often enough that i can catch a drive dying :) | 17:42 |
| lazyPower | like i have a lot of awesome ideas about this | 17:43 |
| lazyPower | but its predicated by talking to the juju api | 17:43 |
| lazyPower | aisrael has some experience there | 17:43 |
| ChrisHolcombe | lazyPower, juju api? | 17:43 |
| ChrisHolcombe | lazyPower, this? https://github.com/juju/juju/blob/master/doc/api.txt | 17:44 |
| lazyPower | well the thought was that sounds like you would have an action on the charm to do the work right? | 17:45 |
| lazyPower | so an admin can do it manually | 17:45 |
| lazyPower | having the update-status invoke that action FOR the admin | 17:45 |
| lazyPower | and potentially trigger any nagios/ext monitoring alarms | 17:45 |
| lazyPower | which is kind of what aisrael did for the VPE-Router that was on demo at MWC | 17:45 |
| lazyPower | the charm invoked actions on itself to configure the router | 17:46 |
| lazyPower | it was quite slick | 17:46 |
| ChrisHolcombe | lazyPower, yeah pretty much. i don't want the admin to have to manually do anything | 17:47 |
| lazyPower | _Sponge not sure what you're asking me, and sorry i missed that | 17:48 |
| beisner | jamespage, we have to adjust ACLs for the bot to be able to do anything other than comment. we do that here. and it looks like we could grant whatever powers we wish. http://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/acls/openstack/charm.config | 17:55 |
| beisner | jamespage, for now, i can add the bot user to charms-core. but perhaps we should add an intermediate group, such as what cinder has done @ http://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/acls/openstack/cinder.config | 17:56 |
| === dpm is now known as dpm-afk | ||
| cory_fu | By popular demand: @when_any (and @when_not_all) -- https://github.com/juju-solutions/charms.reactive/pull/56 | 18:12 |
| rick_h__ | cory_fu: not going to be satisfied unti lI can do @tobe_or_not_tobe :P | 18:13 |
| lazyPower | rick_h__ - why do charms need to be concerned with outerwear? http://www.tobeouterwear.com/ | 18:14 |
| * lazyPower ducks | 18:14 | |
| * rick_h__ is afraid to click links supplied by lazyPower | 18:15 | |
| * ChrisHolcombe agree with rick_h__ haha | 18:15 | |
| jrwren | i read it as tobe the brand at first too. ;] | 18:16 |
| cory_fu | rick_h__: https://i.imgur.com/d1grx5m.jpg | 18:17 |
| jamespage | beisner, nah - lets get the acl updated correctly to include charms-ci | 18:18 |
| jamespage | beisner, we can read the comments for now | 18:18 |
| beisner | jamespage, already added to the group, confirming vote success. can remove the bot from that group when done, or leave there until we have the acl nudged. just lmk. | 18:19 |
| beisner | jamespage, shall i take a stab at the acl change? | 18:19 |
| beisner | jamespage, not sure where we request new gerrit groups though. | 18:19 |
| bbaqar | The LXD charm has a block-device config setting that defaults to /dev/sdb. Anyone got any idea how to create this block-device? | 18:23 |
| lazyPower | o/ bbaqar | 18:27 |
| jamespage | beisner, ok leave as is - maybe a group for one user is overkill | 18:34 |
| jamespage | beisner, you get then by adding them to charms.config | 18:34 |
| jamespage | that's all I did | 18:34 |
| beisner | jamespage, ok cool. so even adding to the charms-core group doesn't give verified permission, so we'd still have to add a line to the .config. but i can have the bot do +/- 1 code review as we sit today. | 18:35 |
| jamespage | beisner, how about you have a go at raising the change against project-config | 18:37 |
| beisner | jamespage, ok will do | 18:37 |
| === dpm-afk is now known as dpm | ||
| ney1 | hi? =) | 18:46 |
| ney1 | just testing | 18:46 |
| beisner | jamespage, ok, here's what it looks like atm with the bot in code-review voting mode: https://review.openstack.org/#/c/286653/1 | 18:54 |
| jamespage | beisner, ok for now - lets get it doing verified instead :-) | 19:12 |
| beisner | jamespage, yep, on it | 19:12 |
| jamespage | beisner, awesome-o | 19:12 |
| === JoseeAntonioR is now known as jose | ||
| marcoceppi | magicaltrout: you around? | 19:50 |
| marcoceppi | lazyPower: ping | 19:50 |
| lazyPower | marcoceppi pong | 19:51 |
| marcoceppi | lazyPower: want to look over a blog post I wrote before it goes live? | 19:51 |
| lazyPower | marcoceppi give me 5 and you betcha | 19:51 |
| marcoceppi | magicaltrout lazyPower https://gist.github.com/marcoceppi/e182065c837a3fffc918 feedback welcome | 19:52 |
| marcoceppi | I just read the first paragraph and realize I have a lot of things to fix | 19:53 |
| magicaltrout | checking | 19:54 |
| magicaltrout | didn't know go was in apt :P | 19:54 |
| magicaltrout | marcoceppi: make sure they have git and bzr installed | 19:55 |
| marcoceppi | magicaltrout: good call, I'll add that | 19:56 |
| marcoceppi | here's an updated version https://gist.github.com/marcoceppi/e182065c837a3fffc918 | 19:57 |
| magicaltrout | "got get" isn't a command ;) | 19:58 |
| marcoceppi | UGH, that bites me like 40% of the time, to the point that I aliased got => go | 19:58 |
| magicaltrout | or if it is I've been running the wrong build stuff for this past week | 19:58 |
| magicaltrout | hehe | 19:58 |
| marcoceppi | holy cow, every command | 19:58 |
| magicaltrout | i've not used update alternatives, so I'll just assume you know what you're writing there | 19:58 |
| magicaltrout | the rest looks fine | 19:59 |
| marcoceppi | magicaltrout: I just tested it out, it's pretty sweet | 19:59 |
| marcoceppi | I get tired of misspelling $GOTPATH ;) | 19:59 |
| magicaltrout | hehe | 19:59 |
| magicaltrout | everything I have currently runs on some version of 2.0 so my requirement for 1.2 went away a couple of weeks ago | 20:00 |
| magicaltrout | although i'll cry if anyone updates the api and locks me out again.... ;) | 20:00 |
| marcoceppi | magicaltrout: I don't think that will happen *shifty eyes* | 20:01 |
| magicaltrout | hehe, until v3 at least | 20:01 |
| marcoceppi | though we're pretty much like "2.0 is out chance to 'fix' these things" | 20:01 |
| marcoceppi | yeah, juju 3.0 ;) | 20:01 |
| marcoceppi | but by beta3/beta4 those will be done | 20:01 |
| marcoceppi | we should have a beta2 out in the next few days IIRC | 20:01 |
| magicaltrout | i've not had any real issues on trunk amazingly, apart from this LXD stuff, which is undeerstandable | 20:02 |
| magicaltrout | there are a few niggles, but for the novice like me it all looks pretty good | 20:02 |
| magicaltrout | although i'm sure the dev guys are like "its lies, we're holding bits of it together with string" | 20:03 |
| skay | lazyPower: hi, I see this is marked at fix released. which revno should I use? | 20:03 |
| skay | lazyPower: derp. https://bugs.launchpad.net/charms/+source/block-storage-broker/+bug/1487636 | 20:03 |
| mup | Bug #1487636: b-s-b charm easily confused by multiple volumes partially matching its expected volume name <block-storage-broker (Juju Charms Collection):Fix Released> <https://launchpad.net/bugs/1487636> | 20:03 |
| magicaltrout | marcoceppi: i told jcastro earlier, I got 3 talks accepted into ApacheCon big data and 2 will feature juju in some form or other | 20:04 |
| magicaltrout | you guys should definately come up | 20:04 |
| magicaltrout | it'll be a blast | 20:04 |
| magicaltrout | (not my talks, the event) | 20:04 |
| lazyPower | skay - that may have been a mistake, looking at the latest trusty code tree, i dont see a related revision that I merged. | 20:07 |
| lazyPower | https://launchpad.net/~charmers/charms/trusty/block-storage-broker/trunk - i last touched this on may of 2014, its been quite a while | 20:08 |
| kwmonroe | hey bcsaller, i'm working on a zookeeper layer and notice we have 2 interfaces for it: interface-zookeeper for the provides/requires of a zookeeper convo, and interface-zookeeper-quorum for zookeeper peers. since provides, requires, and peers are already 3 separate classes, is there any reason why i should not merge zk-quorum into zk and just have a single interface-zookeeper handling provides/requires/peers? | 20:08 |
| marcoceppi | magicaltrout: yeah, we're going to chat about that in an hour or so, it sounds awesome | 20:08 |
| skay | lazyPower: it looks like there may be a branch related to it (going on the name of one of thedac 's branches) | 20:09 |
| kwmonroe | bcsaller: the metadata.yaml for layer-zookeeper would then look like this: http://paste.ubuntu.com/15261951/, so provides and peers are the same interface, but with different names. | 20:10 |
| magicaltrout | cool! | 20:14 |
| cory_fu | bcsaller: From my discussion with kwmonroe, it seems like it should work from a technical standpoint, but the question remains as to whether there's a decent argument against doing that. You save a repo and interface layer, but on the other hand you're conflating two different interface protocols into the same repo. But on the gripping hand, the code is distinct in that repo, so how much confusion is there, really? | 20:17 |
| lazyPower | skay i'll change this issue back to something not fix-released unless we have definitive evidence of a MP that fixes it | 20:18 |
| cory_fu | It generally seems a bit wrong to me, but I can't come up with a well-reasoned argument against it. | 20:19 |
| skay | lazyPower: ack | 20:23 |
| magicaltrout | random question of the day, reative buids if i want to do a build for xenial or whatever, do I just checkout a xenial image and do a charm build in it? | 20:25 |
| lazyPower | magicaltrout - even easier | 20:25 |
| lazyPower | charm build -s xenial | 20:25 |
| magicaltrout | banging | 20:26 |
| bcsaller | kwmonroe: I don't know that there is a hard fast rule about doing this one way or the other. The guidelines I would think about are, do the conversations differ significantly, is there an ability to replace client impls of one kind but not the other, does it make the implmentation more complex if only some clients have some permissions/capabilities to the conversation. ZK has some native support for peer models so it can do the right | 20:33 |
| bcsaller | thing with the same connection information as a client but this isn't the common case. | 20:33 |
| bcsaller | kwmonroe: as we look forward though and see a world where interfaces represent richer conversations I expect we'll find things like this come up more frequently and we'll begin looking at what I've called faceted interfaced in the past. In that case they can negiotiate with the remote end which of a set of capabilities they share over a given relation | 20:35 |
| marcoceppi | magicaltrout: you can even make it easier, just add the series key to the metadata.yaml with a YAML list of series supported, then charm build ;) | 20:37 |
| magicaltrout | oooh | 20:39 |
| magicaltrout | that does make life easy | 20:39 |
| lazyPower | that only works on juju 2.0+ | 20:39 |
| lazyPower | it'll break on 1.25 in a weird way with a metadata key error | 20:39 |
| * magicaltrout only works in juju 2.0+ :P | 20:39 | |
| magicaltrout | okay well i'm not making use of 2.0 stuff yet, i'll stick with lazyPower's way and resolve it later | 20:40 |
| cory_fu | bcsaller: Note, with what kwmonroe is asking about, the peer relation protocol is entirely separate from the provides / requires, just hosted in the same repo and sharing the same interface name. Because of how the framework loads the handlers, for the peer relation, only the code in peers.py will matter for the peer relation | 20:41 |
| cory_fu | Because peer relations can never be connected to anything other than another peer, they're really their own class of interface protocol already | 20:42 |
| lazyPower | ^ | 20:43 |
| lazyPower | that x 1000 | 20:43 |
| lazyPower | writing peer relationships with the notion of both provides/requires in the same context gets confusing, so yeah. calling them their own class of interface protocol is decidedly choice verbiage. | 20:43 |
| bcsaller | cory_fu: but they share an interface name in the metadata. In that case I'd say they are not the same name. If we want a way to host that concept in a single repo we can get there with metadata, but if the conversations are different they need different interface names in metadata | 20:44 |
| cory_fu | lazyPower: I think that may be an argument against what kwmonroe is wanting to do. By co-locating the peer relation implementation with the provides/requires and having them share the name, it seems like it would have more potential for confusion | 20:44 |
| kwmonroe | yeah bcsaller cory_fu, i can conceive of a time when a ZK replacement is born, but doesn't do peering the same as ZK. then you'd have this new thing using 2/3 of the interface-zookeeper with a separate interface for its peering. that would be confusing. | 20:45 |
| bcsaller | I'm happy to teach charm build about some more metadata for interface repos, but we can't combine them into the same in the model. They could live in the same repo though | 20:45 |
| cory_fu | kwmonroe: Also, from bcsaller's last comment, when you look at the metadata.yaml and see "zookeeper" in there twice, it makes you think that they speak the same language, so to speak | 20:46 |
| bcsaller | cory_fu: right, having to talk about the peer and non-peer version of an interface by name is wrong | 20:46 |
| kwmonroe | yeah, ok, i'm over it. back to bcsaller's original reply "do the conversations differ significantly", and the answer is yes. | 20:47 |
| kwmonroe | let me warm up my ctrl-z fingers | 20:47 |
| bcsaller | code sharing is a good goal and is different from this though, think about a layout for the repo, or a change to interfaces.yaml that can describe what you want to charm build | 20:47 |
| jose | hey everyone. I'm writing some tests with bdx and I'm setting it to grab the unit number/name from ['servicename'][0]. is that the correct way? Because it's throwing an error, and I'm having to hardcode the unit number for the tests to pass | 20:48 |
| kwmonroe | thx for the input bcsaller cory_fu lazyPower! | 20:50 |
| marcoceppi | lazyPower magicaltrout it'll only break on local deploys of the charm | 20:50 |
| marcoceppi | lazyPower magicaltrout not in the store, the store will just parse and deliver the charm as expected AIUI | 20:50 |
| magicaltrout | k | 20:51 |
| marcoceppi | but I haven't tested that assertion | 20:51 |
| lazyPower | marcoceppi - i'm still having problems getting charm2 uploaded charms down in a 1.25 environment | 20:51 |
| marcoceppi | lazyPower: :\ | 20:51 |
| lazyPower | all of the bundles i published for firl to scope out the k8s work, didnt work on 1.25 | 20:51 |
| lazyPower | so this is a pretty big caveat we need to make ppl aware of if they are participating in the beta | 20:51 |
| magicaltrout | alrighty then, dinner, wine, and ec2 pdi slaves..... | 20:54 |
| magicaltrout | work my pretties..... | 20:54 |
| magicaltrout | booo its done sweet fa | 20:55 |
| marcoceppi | http://marcoceppi.com/2016/03/testing-juju-without-wrecking-juju/ | 21:03 |
| magicaltrout | ooh blimey some slave stuff is actually working | 21:03 |
| lazyPower | marcoceppi - +1 LGTM on your blogpost, sorry i didnt get wrapped up on that sooner | 21:05 |
| marcoceppi | lazyPower: no worries | 21:05 |
| lazyPower | or you know, run juju in a container ;) | 21:05 |
| lazyPower | marcoceppi - there is one thing i did notice however, you didnt explicitly call out that $JUJU_HOME is not compliant between 1.25 and 2.0 | 21:06 |
| marcoceppi | lazyPower: production or notin' ;) | 21:06 |
| lazyPower | that'll cause some grief on users | 21:06 |
| marcoceppi | lazyPower: not really | 21:06 |
| lazyPower | k | 21:06 |
| marcoceppi | $JUJU_HOME is ~/.juju in 1.X and ~/.local/config/juju in 2.X | 21:06 |
| lazyPower | ah thats right,t hey changed it in beta1 | 21:07 |
| lazyPower | or alpha2 | 21:07 |
| lazyPower | whichever | 21:07 |
| magicaltrout | anyway on more serious matters.... I hope you all got out and voted for Trump today! | 21:07 |
| lazyPower | magicaltrout - obvious troll is obvious | 21:08 |
| magicaltrout | lol | 21:08 |
| thumper | marcoceppi: hey... | 21:18 |
| thumper | marcoceppi: at the end of your blog post you talk about updating juju | 21:18 |
| thumper | if you do "make install" instead of "make godeps" you don't need the last "go get -v github.com/juju/juju/..." | 21:19 |
| marcoceppi | thumper: really? | 21:19 |
| marcoceppi | nice | 21:19 |
| thumper | also, you can condense "git fetch origin && git merge --ff-only origin/master" to "git pull upstream master" | 21:20 |
| jamespage | beisner, hey - checking out for the night - ping me with details on the project-config change and I'll try get it nudge in tomorrow | 21:20 |
| thumper | marcoceppi: yeah... | 21:20 |
| thumper | 'make check' runs all the tests too | 21:20 |
| beisner | jamespage, ack, will do. back at it now. | 21:21 |
| beisner | jamespage, o/ thanks! | 21:21 |
| thumper | marcoceppi: good post though | 21:21 |
| magicaltrout | lazyPower: what charm helper do i use to get the private ip address? | 21:24 |
| marcoceppi | magicaltrout: I think there's a private_address() in charmtools.core.hookenv | 21:26 |
| * marcoceppi checks | 21:26 | |
| marcoceppi | magicaltrout: https://pythonhosted.org/charmhelpers/api/charmhelpers.core.hookenv.html#charmhelpers.core.hookenv.unit_private_ip | 21:27 |
| marcoceppi | it's unit_private_address() | 21:27 |
| magicaltrout | bah, the search box sucks :P | 21:27 |
| magicaltrout | thanks | 21:27 |
| lazyPower | or unit_get('private-address') | 21:28 |
| === natefinch is now known as natefinch-voting | ||
| lazyPower | rate my readme - https://github.com/juju-solutions/interface-logstash-client | 22:04 |
| * lazyPower drops mic and walks away | 22:04 | |
| magicaltrout | +1 | 22:08 |
| magicaltrout | if i can understand it | 22:09 |
| magicaltrout | anyone can understand it | 22:09 |
| cory_fu | lazyPower: Is that relation for a subordinate? | 22:27 |
| lazyPower | could be | 22:27 |
| lazyPower | but not in this context no | 22:27 |
| cory_fu | Ok, good | 22:27 |
| cory_fu | Oh the hoops one must jump through to explain how subordinates work with provides / requires: https://github.com/juju-solutions/interface-java#charms-needing-a-java-runtime | 22:29 |
| lazyPower | oooo cory_fu your readme's bringin the heat! | 22:32 |
| cory_fu | lazyPower: It's ridiculous that I have to go through that much effort to explain when you should use provides vs requires. | 22:33 |
| lazyPower | oh i hear ya man | 22:34 |
| lazyPower | i haven't documented dockerhost yet for that reason | 22:34 |
| cory_fu | Though maybe that's just an artifact of the types of subordinate charms I write, but it seems way more common to me than the other way around | 22:34 |
| magicaltrout | that java stuff made me very sad for at least 30 minutes | 22:34 |
| cory_fu | magicaltrout: The provides / requires? | 22:34 |
| magicaltrout | yup | 22:35 |
| magicaltrout | i always get it the wrong way around | 22:35 |
| cory_fu | lazyPower: Feel free to use the java README as a template for the dockerhost one | 22:35 |
| magicaltrout | i should just accept that and when i think its right, flip it | 22:35 |
| cory_fu | magicaltrout: Me too. Even now | 22:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
