[00:43] tvansteenburgh, dpb1 could either of you add me back to juju-deployers team [00:45] hazmat, if i can figure out how... [00:47] hazmat, nothing on the lp page that indicates i can do it [00:48] tvansteenburgh, no worries, i'll ping robbie looks like the leave script switched ownership to him [00:49] hazmat, ack === kadams54-away is now known as kadams54 === axw_ is now known as axw [01:05] hazmat: bah, no. [01:05] hazmat: hulk time it is === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [01:59] I can't run `charm add tests` http://paste.ubuntu.com/10025926/ [01:59] it's probably trying to find bzr in the wrong place [02:00] Hi, there is recent update on openstack charms, are there any changelogs? === catbus1 is now known as catbus1-afk [02:22] catbus1, https://wiki.ubuntu.com/ServerTeam/OpenStackCharms/ReleaseNotes1501 [02:37] ping === kadams54 is now known as kadams54-away [04:16] beisner: thank you! === zz_CyberJacob is now known as CyberJacob === CyberJacob is now known as zz_CyberJacob [10:43] Just getting started with juju on trusty. Having an issue as juju-log is missing and doesn't seem to be part of juju-core (currently 1.21) but is required at least by the python hooks. [10:55] TimNich: what do you meanit's missing? [10:58] Well the command 'juju-log' does not exist, but is invoked by 'charmhelpers.core.hookenv.log' in charm-tools [11:01] '/usr/bin' has juju, juju-backup, -bundle, -charm etc but no -log [11:30] TimNich: right, that doesn't get installed in /usr/bin [11:30] they're only available to the hooks at the time of invocation [11:30] TimNich: what are the steps you performed to reach this error? === marcoceppi_ is now known as marcoceppi-sast [11:43] I was trying to test my install hook by running it stand alone, but it fell over, and by simplifying and looking at the back trace it was clear the command …hookenv.log [11:45] TimNich: right, so you can't just execute it. When a hook executes it wraps the hook with a modified environment (new env vars, etc) [11:45] you can test it, it it's deployed, using `juju debug-hooks` [11:46] TimNich: depending on which version of juju you have, you can do `juju debug-hooks unit/# install` [11:46] I hadn't got as far as deplying it, I was trying to test bits as I went along. [11:46] TimNich: you have to deploy to test a hook [11:46] unless you're doing things like unit testing [11:47] when you juju deploy something, juju installs an agent and a set of tools on that machine [11:47] part of those tools are things like juju-log, etc [11:51] OK, thats very helpful. The bash version install can be tested standalone, so it wasn't obvious to me that the pyhon one couldn't. But the ptython one seemed to have some useful libs so I thought I would try it. [12:23] TimNich: none of the hooks can reliably be tested outside of juju [12:23] Hmm. Some unit testing sure would help [12:23] TimNich: right, you can totally unit test without needingto deploy [12:23] you just need to mock the calls made to charmhelpers [12:24] as those are already tested [12:25] Right. I was just being a tad simplistic trying to tset sections without doing proper unti testing! [12:25] Thanks for your help. [12:36] marcoceppi-sast: I see you are the maintainer of charm-tools. I notice that the python hooks structure created uses one .py file per hook function plus a couple of imports, but the structure documented at http://pythonhosted.org/charmhelpers/index.html shows a single hooks.py with sym links to it for each function. Which structure is the one to expect going forward? [12:37] TimNich: we don't really dictate how to structure your charm, we simply help model different patterns. As far as the code in the charm and structure as long as you follow the outline that you implement X hooks that juju expects, everything else is up to you [12:38] TimNich: there's also two different python templates, there's the `python-basic` and then "python" which is our "services framework" teplate [12:38] you can see these options running `charm create -h` === jacekn_ is now known as jacekn [12:47] ahh. hadn't spotted the python<->python-basic difference, and the pythonhosted docs use '…-t python….', but then show the python-basic dir structure! [13:42] I've got bzr installed, but `charm add tests` is returning http://paste.ubuntu.com/10025926/ === kadams54-away is now known as kadams54 === rcj is now known as Guest72419 [14:39] o/ skay [14:39] skay: did you install charm-tools from pypi or source? [14:40] marcoceppi-sast: at this point that is lost to the sands of time. I can't remember [14:40] skay: I used to have a cleanup script [14:40] marcoceppi-sast: which charm and juju tell me /usr/bin/ [14:40] but if you install from apt it will always work. The problem is /usr/local takes precenece over other things [14:41] skay: try this: sudo rm -rf /usr/local/lib/python*/dist-packages/charm* [14:41] then run `charm add tests` [14:44] marcoceppi-sast: I still get the stacktrace. I may have installed bzr via pip (I can't remember at this point) due to wanting git-lp and needing to muck about with bzr [14:45] skay: is it installed with apt? [14:45] are you getting the same trace? [14:45] marcoceppi-sast: I am assuming charm-helpers are installed with apt, because when I do sudo apt-get install charm-helpers it tells me that it is already installed [14:46] well, charm-helpers are not charm-tools [14:46] marcoceppi-sast: derp. that was a thinko [14:46] * marcoceppi-sast nods [14:47] marcoceppi-sast: just checked and apt says it is already the newest version [14:48] marcoceppi-sast: I might take this to the mailing list because I need to switch context to work stuff. thanks for triaging === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [14:51] marcoceppi-sast: I want to be able to compare the generated test scaffolding to the python-django existing tests to see how different things are. ultimate goal is make MRs for the changes in my fork nrpe-external-master is useful, pip_extra_args is useful but I can't get tests to pass yet (http://reports.vapour.ws/charm-tests/charm-bundle-test-10877-results ) and once I fully grok proper testing I want to get those things in [14:55] skay: ack [15:18] python-django question, I recall that an ansible fork is being worked on. Is fabric support getting dropped? https://bugs.launchpad.net/charms/+source/python-django/+bug/1416108/comments/2 [15:18] Bug #1416108: [test] Python-Django test plan

[15:25] skay: mup: that means that it has no point for me to implement test on the current python-django charm till the ansible fork is merged? [15:26] nicopace: I don't know, so let's see what the project maintainers thing [15:26] lazyPower: I remember talking to you about python-django, I think? [15:26] nicopace: I'm only a user [15:27] skay: (y) [15:28] nicopace: I'm making a reply for you in the issue [15:29] jog ping [15:38] hi mbruzek, I'm stepping out to bring the kids to school, I can ping you back in a bit [15:38] jog ok [15:51] hi [15:59] Hello mwak_ [16:49] tvansteenburgh, are you the new maintainer of deployer? [16:50] whit: i'll never admit to that [16:50] tvansteenburgh, :D [16:51] tvansteenburgh, if hypothetically, you were the new maintainer of deployer, where would I submit bugs? [16:51] whit: https://bugs.launchpad.net/juju-deployer [16:56] tvansteenburgh, thnks [16:58] mbruzek, ping [17:00] Hi jog, I was not seeing the results from the jobs I kicked off yesterday 02/02/2015. [17:00] http://reports.vapour.ws/charm-summary/kubernetes [17:00] I see them now, was there something that changed? Or does the ingestion only run so often [17:00] mbruzek, ok I fixed that... should be there now? [17:01] mbruzek, it should be happening every 15 minutes [17:02] jog can the result page show the bundle that was used? we are passing a -b bundlepath/bundlename to the command now. [17:02] tvansteenburgh: added the bundle feature for us, right now I can not tell which bundle was used to start which test. [17:02] I'll take a look [17:03] jog as an example I am running the command like this: -envs 'aws,hp,azure,joyent' -b specs/head-latest-release-v0.8.2.yaml gh:whitmo/bundles-kubernetes [17:03] I would hope to see specs/head-latest-release-v0.8.2.yaml in the charm column [17:04] Because the bundle URL will always be the same. [17:07] jog, i added a bundle key to the json [17:07] yup, I see it there [17:08] I can add that information to the report [17:08] thank you jog and tvansteenburgh [17:09] mbruzek, although I don't think I'll replace the URL... since this report is used for other charms that may not have the bundle information [17:09] jog Yes I understand, I just want to know what version that is === kadams54_ is now known as kadams54-away === kadams54-away is now known as kadams54_ === beisner- is now known as beisner [18:12] I have different physical servers i want to use for specific packages. Is there a way to link the MAAS name and setup to a specific machine in Juju? Seems they deprecated the Maas-name tag. I was able to use the add-machine ssh:maas_server_name_here command, but then Juju Doesnt apply a name to the machine that correlates to anything. [18:35] icetoad: maybe you can use constraint tags? see `juju help constraints` [18:43] yea, i tried the constraints, but the tags dont exist any more [18:43] they eliminated the maas-name constraint tag [18:45] seems like juju is meant to just grab a machine from a pool and go, but if the machine died, i would have no idea which physical server it was without trying to hunt through ips and configurations [18:46] icetoad: this should still work: https://maas.ubuntu.com/docs/tags.html [18:55] i was assuming it did, but even if i tag the machine(talking about tagging 1000 plus machines here), will the tag show up in the JuJu gui? [18:56] sorry, i forgot the juju status command shows the maas name.... perhaps its not as a big a deal... it would just be easier if that were exposed on the juju gui [18:57] i can target the machine with the add-machine ssh command, but i guess i could play with tags to see if i can add a step in the preseed to add the tag automatically [18:58] i understand why they got rid of the maas name tag, but i wish they had just fixed the issue === kadams54_ is now known as kadams54-away === kadams54-away is now known as kadams54_ [19:41] skay: o/ [19:41] allo, you had some questions? [19:42] lazyPower: I can't remember if you are a python-django maintainer. are you? I had a question aobut whether fabric is getting deprecated in favor of ansible [19:44] lazyPower: nicopace has a test plan, and if fabric will be around a long time, it makes sense to be included in the test plan. but if that isn't true, then we should let nicopace know [19:49] skay: fabric 2 with python 3 support is still under development afaik, I don't think it has been abandoned. [20:00] fabricccc! I don't want to have to use crapistrano for deployment!! aaah [20:06] roadmr: I've used fabric, not the other [20:07] skay: it's mostly a joke; most python tools have ruby equivalents, capistrano is roughly equivalent to fabric [20:07] roadmr: I'm working my way from fabric to ansible [20:07] roadmr: heh, it went over my head. I thought capistrano was more complicated than fabric [20:08] roadmr: ansible is a gazillion deeply nested directories of yaml files [20:08] oh the horror.yaml :( [20:08] roadmr: I haven't decided how bad it would be if I don't follow the custom. people probably do it that way for a reason [20:09] roadmr: you haven't had enough java in your life, I bet. [20:09] roadmr: more like horror.xml [20:09] NOOOO [20:10] I have had to translate xml files by hand - spit out by some horrid microsoft web development framework, I recall [20:10] like finding 4 sided dice on the floor with your bare feet, is xml [20:10] ouch... === kadams54_ is now known as kadams54-away [20:21] skay: ah good catch. I'm not a maintainer, but i will definately take a look at the merge chain and see how things are going. Patrick Hetu has been the primary developer on the charm, and it probably warrants a touch base with him [20:21] skay: thanks for taking a vestd look and reaching out - i'll make sure to follow up on that now so i dont forget [20:22] lazyPower: thanks, maybe he can leave comment here https://bugs.launchpad.net/charms/+source/python-django/+bug/1416108 [20:22] Bug #1416108: [test] Python-Django test plan

[20:23] skay: ta [20:23] o/ [20:24] skay: lazyPower: thanks for that, i'll be working on the python-django charm in a couple of days === roadmr is now known as roadmr_afk [20:27] nicopace, skay: correspondance has been sent. nicopace - i cc'd you as well. [20:27] (y) [20:27] :thumbsup: [20:27] irc needs more emojii [20:28] :D [20:28] thanks lazyPower, i lack the connections you guys have ;) [20:28] lazyPower: :thumbsup: is bd [20:29] lazyPower: bd can also be batman [20:29] NaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaN WATMAN! [20:30] https://www.destroyallsoftware.com/talks/wat <- i cite my reference [20:31] oh I LOVE that talk. === zz_CyberJacob is now known as CyberJacob [20:32] Hi guys... you know, the monitors relation (belonging to nagios) is really badly documented... it would be great if we add at least some of this content to this relation's documentation: https://maas.ubuntu.com/2012/09/05/nagios-is-from-mars-and-mysql-is-from-venus-monitoring-part-2/ [20:32] nicopace: can you file a bug? [20:32] sure :D [20:33] a good majority of our charm interfaces are widely undocumented [20:33] that's not good at all :S [20:33] also the death of yavascript one. which has inspired some other great talks. one at an open bio conference by Titus Brown, https://www.youtube.com/watch?v=uwsjwMO-TEA [20:33] and thats not a great story to have - but if we can identify the low hanging fruit like that - we can knock out a good chunk of them. [20:33] skay: another great reference :) [20:34] sure! i'll pay attention to that while i implement the tests [20:34] nicopace: thanks a million mate. tag them with 'doc' and 'interface' and i'll keep a running sort on them so i can try to assist as i get time [20:35] lazyPower: I should do that too, I was wondering bout how to auto-discover the servername of the apache2:reverseproxy so that I could think of adding the ability to the python-django charm to inject it in to ALLOWED_HOSTS but the interface def in metadata.yml does not indicate anything [20:35] lazyPower: and maybe I should file a bug? [20:35] likewise for python-django for its http interface. [20:36] but I got to wondering whether it was an expected practice or if those were widely documented somewhere that I hadn't discovered yet [20:36] skay: yeah - if none of the interfaces are documented, i think its fine at this point to just mention that the interfaces are undocumented, which makes the integration path = diving through code. [20:36] its not documented :( [20:36] marco has been dangling a carrot in front of me while we keep piling work on him [20:36] https://bugs.launchpad.net/charms/+source/mysql/+bug/1417753 [20:36] Bug #1417753: Document monitors interface [20:36] so i think bugs + tags for now will start that ball rolling in docs, and if we ever get a moment to build an interface listing, we'll aggregate it in one spot for quick reference [20:37] skay: i was thinking about building a chart on something like interfaces.juju.solutions - where you can plug in a charm name and get back the listed interfaces, and the data pass [20:37] my way of understanding what a relation does, is looking over the README, and diving throught the code [20:37] along with examples [20:37] nicopace: yeah :( that sucks :( [20:38] i dont like that :( its totally user friendly [20:38] lazyPower: that would be excellent. right now if you click on an interface you get a view all the things that use the interface, at least [20:38] yeah, I have had to do that a lot too [20:38] lazyPower: it seems that there was an interface in the past, but it is not there anymore:http://jujucharms.com/interfaces/monitors [20:39] skay: yeah - which is a good first step - but trying to integrate without knowing what the datapass is, is the pitts [20:39] and i was vehemently opposed when i supported gets/sets in metadata.yaml [20:39] so now it kind of needs a central registry to view that information [20:39] jsut for simplicity sake (bare minimum, stuff it in the readme) [20:39] that link was retrieved from "Interface docs" from here: https://manage.jujucharms.com/interfaces/monitors [20:40] the problem seems to be that the interfaces don't belong to anyone [20:40] so, who would be responsable of documenting it? [20:41] lazyPower: skay ^ [20:43] nicopace: the provides is the owner actually [20:43] requires is just a consumer of the provides relationship [20:43] its a loosely coupled contract [20:43] but for example, mariadb and mysql both provide the same interfaces [20:43] and the http interface is provided by a lot of services [20:44] nicopace: https://speakerdeck.com/chuckbutler/service-orchestration-with-juju?slide=25 [20:44] take a look at this slide deck i've been using to teach juju since FOSDEM [20:45] relations are the declarative language juju provides to expose how one service will interact with another - in either a provider or a consumer fashion. This is bi-directional, so the actual "ownership" of the interface, would be the responsibility of the provider - since there is no actual registry or uniform standard that you have to conform to [20:45] lazyPower: did fosdem manage to get a video of the talk? [20:45] skay: i have no clue :( [20:45] i can reach out to kris and find out - but later. I've been bugging him like mad lately with cfgmgmtcamp [20:46] lazyPower: it's okay, I have friends of friends who are involved inf osdem video [20:46] ok... so for the majority of the relations, as they are almost one-to-one with provider charms, there is no problem === rcj is now known as Guest17528 [20:47] skay: nice! if you find out - let me know :D [20:47] nicopace: correct. [20:47] ok... so it would be great to have that docs arround... [20:48] lazyPower: where does they go? metadata.yml? [20:49] it would be super-easy to do an automated script that checks if a charm's providing relations have documentation or not [20:49] nicopace: the relationship definitions are in metadata.yaml - the interfaces are loosely defined contracts between two services - so presently there is no easy way to discern what data is being handed over the wire except grepping the code for relation-set [20:50] from this docs, there is no way to specify documentation of a relation: https://jujucharms.com/docs/authors-charm-metadata [20:50] (not structured at least) [20:51] nicopace: correct, that was actually recently removed [20:51] why removed? [20:51] and by recently i think it was october 2014 - give or take, when the gets/sets key was removed from metadata.yaml [20:52] is this a bug that needs to get addressed (by juju)? [20:52] because we like making things hard I suppose :( i dont have a good reason for you, as i was on the party that voted against this. [20:53] but, what i can do is ask when marco returns. I know he's got a well formed answer for this [20:54] allright, i'm outy 5000 for now. its late here in belgium. [20:54] ty for all the feedback, ideas, and enthusiasm nicopace [20:54] if you need anything dont hesitate to ping [20:54] o/ skay - thanks again for being awesome :D [20:54] sure lazyPower See you tomorrow then :P [20:54] :D === roadmr_afk is now known as roadmr [21:32] I have some nodes that are cpu-cores=8 and cpu-cores=4. Is there a way to force juju to add one of the lower-core machines? When I use --constraints "cpu-cores=4", it is still picking a machine with 8 cores. [21:35] ctlaugh: set cpu-cores=3 [21:51] there's an open bug on this [21:51] https://bugs.launchpad.net/juju-core/+bug/1380989 [21:51] Bug #1380989: juju picking randomly from available machines instead of best fit

[21:52] only applies to machines already in the environment without workloads [22:07] marcoceppi-sast: I tried... still gives me an 8-core :( [22:10] hazmat: Mine are in MAAS and haven't been added to juju environment yet. I guess I can use tags, but I was trying to avoid that. [22:18] ctlaugh, hmmm, that could be an issue on the maas side then, juju basically passes those through afaicr [22:20] ctlaugh, what version of maas? [22:21] hazmat: 1.7.1~rc5+bzr3341-0ubuntu1~trusty1 [22:21] ctlaugh, interesting [22:22] ctlaugh, looks like maas picks the first one it finds by natural db order that matches the constraints [22:22] hazmat: oops [22:24] ctlaugh, would you mind filing a bug? [22:24] hazmat: Yes - just about to. Here? https://bugs.launchpad.net/maas [22:24] ctlaugh, yup [22:38] hazmat: https://bugs.launchpad.net/maas/+bug/1417793 [22:38] Bug #1417793: MAAS selection of node for juju constraints does not choose "least-capable" match === kadams54 is now known as kadams54-away === CyberJacob is now known as zz_CyberJacob [22:56] ctlaugh, cool, thanks