[00:14] NOTICE: jujucharms.com and the charmstore are back up. The storage in IS is workingto rebalance/sync and might time out or be slow for a bit longer. [02:23] lazyPower: hi [02:23] kirkland: o/ i understand you want to compose some charms [02:24] kirkland: whats the core fo what you would like to do? I have it on good authority you were planning on dockering in your charm === rcj` is now known as rcj [02:25] lazyPower: just one new charm, probably a subordinate charm [02:26] lazyPower: I've already created and published a docker image [02:26] lazyPower: it's a simple little cpu scavenging utility (like protein folding or seti), that search for huge prime numbers [02:26] ah so you're looking to squeeze in some CPU time on anything that's idle. gotchya [02:27] thats a perfect candidate, and you can skip all the docker logic if you inheret from our current docker charm. [02:27] all you'll need to do is set your config-changed hook logic to deliver the image and spin it up, as it will be called after the docker (or in this case, the base charm) hooks are executed [02:28] lazyPower: hmm [02:28] lazyPower: I would definitely like to skip any redundant docker logic [02:28] lazyPower: so, should I clone an existing charm, or try this new juju-compose thingy [02:29] there's one caveat to the current docker charm that i'll state now since it looks like you're delivering something supremely light weight. We're using ansible in the current charm. so you'll be getting ansible in that payload [02:29] is this acceptable? [02:31] You'll benefit from getting upgrades of docker, and the newest features we land every time we cut a release if you build on top of the current docker charm [02:31] some of that is landing the new docker plugin support for libnetwork, as well as AUFS is scheduled to land sometime late next week [02:32] once you've written your extension, you'll only need to regenerate the logic that is important to you [02:32] by proxy, your service will be able to connect to everything we've already charmed in the docker ecosystem - such as logspout (log shipping) and registrator (service discovery) to name a few [02:33] If you'd like a better view into what you've got exposed to you, https://github.com/juju-solutions/tupperware [02:41] lazyPower: I don't care much one way or another about ansible [02:41] lazyPower: I like the sound of all of that [02:41] Its a perfect candidate then, we'll make sure the dependencies work, all you have to be concerned with is delivering your container from the hub, and running it properly :) [02:41] lazyPower: it would be nice if I could just point to the docker image, and voila, i'm 99% done :-) [02:42] lazyPower: okay, let's do it... [02:42] kirkland: you're already there actually... [02:42] there's an action to launch images [02:42] 1 moment, it just occured to me that you're delivering a subordinate to eat spare cpu cycles [02:43] docker is a primary charm, let me see if subordinate conversion is supported by composer [02:45] lazyPower: right [02:45] lazyPower: it could run as a primary or subordinate [02:45] lazyPower: I'd think it's more interesting as a subordinate [02:45] * lazyPower nods [02:45] lazyPower: perhaps even if only to the ubuntu charm [02:46] You'd have more flexibility in where you can stuff it, say maybe that one machine on the fringe of your network that only handles log shipping [02:46] sub is interesting the same way a boinc sub would be [02:46] attach it there and let it search for primes [02:46] if the unit is idle, use the CPU to do science [02:46] if not, work for the primary service [02:47] i'd rather not pigeon hole you into a primary. I'm fairly certain we can extend it. if not, we can always publish a "fork" of the docker charm as a subordinate and you simply switch which base your logic inherets from [02:47] run the generator and viola [02:51] lazyPower: sure [02:51] lazyPower: honestly, I'm not really worried about it getting serious use, as it needs ~7 days to do anything useful [02:52] lazyPower: it's more about the exercise of creating a docker container, and then very easily (I hope) creating a Juju charm and a Snappy snap :-) [02:52] lazyPower: if it's not easy, then something is broken that we need to fix [02:52] kirkland: i've got interesting work on that front underway as we speak [02:52] i'm building a RPI2 cluster, mixed with 2 lxd nodes, 2 docker nodes [02:53] lazyPower: fun [02:53] lxd by default supports distributed containers, docker requires swarm - building services that work in concert [02:53] lazyPower: okay -- so no what do I do? [02:53] lazyPower: coolio [02:53] lazyPower: my docker image is here: https://registry.hub.docker.com/u/kirkland/mprime/ [02:54] kirkland: i'm assuming you have juju-compose pulled? our prototype for "inheriting" from an existing charm? [02:54] https://github.com/bcsaller/juju-compose [02:55] You'll also need a copy of the docker charm, obtainable via `charm get trusty/docker` [02:56] lazyPower: juju-compose is not executing for me [02:56] lazyPower: I cloned it, pip-installed it locally, but I'm hung up chasing dependencies [02:56] ok, so you just want to springboard that image - *snap* be done with it [02:56] got it [02:57] start with juju deploy docker, i highly recommend you set latest=true, version=1.7.0 via `juju set docker latest=true version=1.7.0` once its registered via juju deploy [02:58] lazyPower: are you going to be particular about what version of charm-tools you want me to use? [02:58] not at all [02:58] lazyPower: i just apt-got it from the 15.04 archive [02:58] everything we will be doing is perfectly doable from vanilla juju [02:59] last question that i can think of - are you going to be trying this on the local provider? [02:59] kirkland@x250:~/src/mprime/charm⟫ charm get trusty/docker [02:59] Error: trusty/docker not found in charm store. [02:59] lazyPower: I was probably going to use amazon by default, but I can do whatever [03:00] no worries, we can skip fetching the local charm - you're not going to be doing layers with composer. [03:00] lazyPower: why couldn't I get the docker charm like that? [03:00] I'm not sure, but i've taken a note to investigate. [03:01] juju deploy cs:trusty/docker - will achieve the desired result. [03:02] lazyPower: hmm, before I deploy the generic docker charm, I want to add my docker pull image, though, right? [03:03] You wont need to, no. the docker charm delivers the infrastructure required to run your container. [03:03] will your service have any relations to any other services in the topology? [03:03] lazyPower: nope [03:04] lazyPower: so is there a juju set config for my image? [03:04] juju run --unit docker/0 "docker run kirkland/mprime" [03:05] lazyPower: oh, hmm, juju run? that sounds slightly hacky [03:05] Once the latest MP lands, an action will be available to run, recycle, kill - running containers. [03:05] lazyPower: I would have hoped something more like "juju set image=kirkland/mprime" [03:05] i apologize this hasn't been pushed into the store yet, it received some negative feedback on the last review so it took some polishing and is awaiting another set of eyes. [03:05] lazyPower: sure no worries, bud [03:06] kirkland: the problem with juju set image= is you're not altering state of docker, you're altering state of something in docker [03:06] lazyPower: seems like this is better suited for anaction? [03:06] and we want to model that differently. [03:06] marcoceppi: correct! [03:07] lazyPower: hmm, run/action doesn't feel right to me [03:07] doesn't feel like what I'm trying to accomplish [03:08] kirkland: you can deliver your image with a subordinate in a few different methods. 1) via dockerfile (charm written) 2) via docker-compose (seems overkill for one service) 3) via a quick and dirty bash charm [03:08] I mean, it's great as the quickest way to run a specific docker image [03:08] but, if you scale the docker service, it inherently runs across *all* docker hosts you juju add-unit to [03:08] o/ [03:08] if thats side effecty behavior is troublesome for this service, its better suited as an action in todays model. [03:09] lazyPower: so as I scale out the docker charm, that specified action will get run everywhere? [03:09] negative, if you run the action, it stays isolated to the target unit you executed it against [03:10] lazyPower: I suppose I should get around to submitting my celery worker branch for django since I'll be putting it in production soon [03:10] lazyPower: okay, definitely not what I want [03:10] the "scale everywhere" is in relation to subordinate based delivery of docker images, against a cluster that comprises a service. [03:10] in this case, the docker charm. [03:10] lazyPower: okay, right, so how can we get this over to the subordinate charm case? [03:11] whats your preferred method to write a charm? Are you a prototype in bash kinda guy? [03:12] charm create -t bash mprime [03:12] lazyPower: I'm a "cp -a transcode" and the sed from there :-) [03:12] kirkland: ok, a few changes then in the metadata should get you started [03:13] lazyPower: but yes, this is a bash charm, not python or otherwise [03:13] in metadata, you'll need to change [03:13] subordinate: true [03:13] lazyPower: charm-create: error: unrecognized arguments: -t [03:13] marcoceppi: we have something strange going on in 15.04 with charm-tools [03:13] cannot fetch charms, generators aren't recognizing templates [03:14] i'll file a bug in a moment [03:14] ii charm-tools 1.0.0-0ubuntu2 all Tools for maintaining Juju charms [03:14] that explains it. [03:14] 1.5.1 is latest, and available from the PPA [03:15] http://pad.lv/u/charm-tools [03:15] yes [03:15] get from ppa [03:15] dude, you guys haven't uploaded a new charm-tools in Ubuntu in 4 releases, 2+ years [03:16] this is one thing I continue to despise about all things juju -- everything has to be done from a ppa, doesn't play nice with the Ubuntu archive :-/ :-/ :-/ [03:16] kirkland: you're the snappy guy ;) [03:17] we tried to last release [03:17] but it didn't make it in time [03:17] I'll resubmit it for wily [03:17] lazyPower: are you going to be particular about what version of charm-tools you want me to use? [03:17] not at all [03:17] * kirkland reminds lazyPower of that exchange ^ [03:17] marcoceppi: goto https://launchpad.net/ubuntu/+source/charm-tools [03:17] kirkland: my mistake. [03:17] marcoceppi: the last time charm-tools was uploaded to the ubuntu archive was 2013-10-18 [03:18] kirkland: I know [03:18] as the maintainer, I'm aware [03:18] we tried to get a more recent version uploaded last cycle [03:18] it didn't make it [03:18] so now... [03:18] which ppa do I use? [03:18] ppa:juju/stable [03:18] * marcoceppi eod [03:19] thx [03:21] lazyPower: okay, I have a new charm template [03:21] lazyPower: let me fill that out [03:21] kirkland: first thing you'll need to do is edit the metadata [03:21] remember, with subordinates you need to require a host relationship, this is special [03:22] lazyPower: quick docker question...do I need to do something to create the latest tag? [03:22] 2015/07/15 03:20:02 Tag latest not found in repository kirkland/mprime [03:22] the current model we have all across teh subordinates in our ecosystem to date are like this: http://paste.ubuntu.com/11880797/ [03:22] you gave your containers specific version tags [03:22] https://registry.hub.docker.com/u/kirkland/mprime/tags/manage/ [03:23] if you want a latest tag, you either omit, or implicitly give it the latest tag [03:23] ah [03:23] thx [03:26] lazyPower: what's the requirements on icon.svg? [03:26] kirkland: https://jujucharms.com/docs/stable/authors-charm-icon [03:33] lazyPower: hmm, tag suggestion? [03:33] misc - as it dont see it applying to any of the other approved categories. [03:34] lazyPower: ack [03:34] lazyPower: maybe analytics [03:34] lazyPower: or (anti)social [03:34] or performance :-) [03:35] lazyPower: okay, help me with the relations... [03:36] kirkland: the only relation you will need to implement starting, is the host relationship. [03:36] it goes under requires [03:36] and use the pastebin link above as your guide ^ [03:36] lazyPower: so no provides/requires/peers, right? [03:36] unless it needs to exchange data among each unit as it scales, no peering [03:36] does it provide anything? Can it relate to anything other than the host it is attaching to? [03:36] lazyPower: none -- they all phone home to mersenne.org [03:37] lazyPower: nope [03:37] then no other relations required. just the one to the host that makes it a subordinate. [03:37] lazyPower: help me with that pastebin, then [03:37] lazyPower: is it literally copy-n-paste? [03:37] copy and paste it under requires. [03:39] lazyPower: i'm missing something here [03:39] lazyPower: no peers, I agree with that. [03:39] lazyPower: do I have a provides? [03:39] You're not exposing anything to any other charms [03:40] from what has been described to me, it is only a consumer of resources. [03:40] lazyPower: right, okay [03:40] so it has a single relationship, which is the host relationship. [03:40] lazyPower: but, I do put: [03:40] requires: [03:40] docker-host: [03:40] interface: juju-info [03:40] scope: container [03:41] thats it. [03:41] kirkland: you may want to take a moment to review the subordinate docs - https://jujucharms.com/docs/stable/authors-subordinate-services [03:42] this will help you understand the scope of that relationship you just implemented. [03:44] kirkland: its nearing midnight local time. I'm going to be checking out in about 5 minutes. [03:44] do you have any last minute questions i can help with before i check out? [03:44] lazyPower: ack, thanks [03:44] lazyPower: nah, I'll figure out the rest [03:44] lazyPower: you can review tomorrow [03:44] lazyPower: thanks. [03:45] kirkland: just to be clear, charms are reviewed on a first come first serve basis - and you can find the current working queue http://review.juju.solutions, my review time is sloted on fridays unless you have an emergent fix/patch release. [03:45] lazyPower: sure, that's fine [03:46] best of luck on your adventure o/ if you run into any problems feel free to ping tomorrow or hit up the mailing list juju@lists.ubuntu.com === menn0 is now known as menn0-afk === zz_CyberJacob is now known as CyberJacob === CyberJacob is now known as zz_CyberJacob === menn0-afk is now known as menn0 [08:18] Hi, (on Wily) do I need to do anything special to have "$ juju charm create" add the charm-helpers ? [08:43] Hello everyone!! I have an easy question that I can't find in the docs :) [08:44] I'm trying to use juju with a local Openstack cluster without swift or nova-objectstore [08:45] I found this answer https://askubuntu.com/questions/173342/is-swift-object-storage-a-requirement , but since juju 1.21 it seems that those requirements are not needed anymore [08:46] I'm trying with 1.24, but it doesn't seem to work, maybe the openstack provider still needs the object store? === jam1 is now known as jam [09:10] Is config.yaml mandatory in a charm ? [11:47] caribou: what version of charm-helpers do you have [11:48] caribou: also config.yaml is not mandatory. The only mandatory file is the metadata.yaml file [11:48] marcoceppi: lemme check [11:49] marcoceppi: well, the charm-tools I have is 1.5.1 [11:49] marcoceppi: I ended up fixing it in my charm's makefile [11:49] marcoceppi: but "charm create" doesn't add the ./hooks/charmhelpers directory [11:49] caribou: cool, that's the latest version [11:50] marcoceppi: regarding the config.yaml, I may have uncovered a bug [11:50] caribou: did you specify the python-basic template? charm create -t python-basic [11:50] caribou: oh? [11:50] marcoceppi: doing a final verification, but if the config.yaml file is missing, my unit_tests never return unless I do a -C [11:50] marcoceppi: I didn't specify any template [11:52] caribou: so by default you get the services framework template, which should just attempt to install charmhelpers with pip iirc [11:53] instead of embedding charm helpers [11:54] marcoceppi: that's what I get after $juju charm create : http://paste.ubuntu.com/11882195/ [11:54] marcoceppi: trusty with ppa:juju/stable [11:54] caribou: right, so if you look at the install hook, it calls a method in setup.py which will pip install charmhelpers when you deploy the charm [11:55] marcoceppi: ah ok, didn't know that [11:56] caribou: unless you have a restrive network, we've been trying to move charms away from embedding charm helpers. I'm about to kick off a discussion this week which will highlight how we hope to acheive this so that people with restrictive networks and those who don't have that requirement can work still have working charms [11:56] marcoceppi: but that's only good for a deployed charm. [11:57] caribou: well, that's what charms typically do [11:57] marcoceppi: when writing unit_tests, you would expect to have them around [11:57] caribou: when writing the unit tests, you should mock those methods [11:57] marcoceppi: yes, that's what I did [11:57] charm-tools have their own unit tests. It's a python library, you typically don't have those installed in your projects tree either [11:57] marcoceppi: I also have a sync: anchor in my Makefile to do that if needed [11:58] s/charm-tools/charm-helpers [11:58] marcoceppi: well, I made the mistake of starting my charm off an existing one, carring over old helpers [11:58] marcoceppi: that's all fixed now. [11:58] caribou: ah, I see [11:59] marcoceppi: btw, I'll open the bug about the missing config.yaml. I'm able to reproduce it at will [12:03] caribou: yeah, I think that's just an issue with that unit test template [12:06] marcoceppi: https://bugs.launchpad.net/charm-helpers/+bug/1474824 [12:06] Bug #1474824: Charm's unit_test never returns if config.yaml is missing [12:06] marcoceppi: not sure, as I did not use the template [12:07] caribou: interesting, well make test isn't directly tied to charm-tools, it's whatever the unit_testsare for that charm [12:07] i'll take a look though [12:08] marcoceppi: for my charm, test = amulet, unit_test = python unittest [12:09] caribou: I'm guessing I have to install nosetest and coverage? [12:09] marcoceppi: coverage is not needed [12:09] marcoceppi: hence the error in the report [12:15] caribou: this isn't a bug with charm-tools, it's just something that in the test utilities in your unit_tests directory [12:15] check line 13 of unit_tests/test_utils.py [12:17] CharmTestCase instantiates it on line 54 [12:17] if you comment that out, it should work without a config.yaml file [12:19] marcoceppi: that's what happens when one blindly yank code out of other people's project :-/ [12:19] marcoceppi: sorry for the noise [12:20] caribou: no worries! Most all charms have a config.yaml which is why that test_util, not sure who wrote it, but I've seen it from time to time, just assumes it'll be there [12:20] from a charm perspective, everything is optional except for the metadata.yaml file [12:20] marcoceppi: well, my charm will eventually needs it, so having a placeholder for the time being is fine [12:20] marcoceppi: I'll document & close the bug [12:22] marcoceppi: thanks for your help! [12:23] caribou: cheers, no problem at all! [12:24] cory_fu: you around? === scuttle|afk is now known as scuttlemonkey [14:09] gnuoy, hey - could you take a look at https://code.launchpad.net/~james-page/charm-helpers/drop-ensure-packages [14:09] right now the legacy mode flag on nova-compute does not work that well because of that [14:10] sure, I'll take a look [14:21] jamespage, isn't this going to break cases where nova-compute has been deployed without the neutron-ovs subordinate? [14:21] gnuoy, there is an associated change to nova-compute [14:22] jamespage, kk, approved [14:22] gnuoy, https://code.launchpad.net/~james-page/charms/trusty/nova-compute/neutron-plugin-sub-config/+merge/264854 [14:22] thats the mp for that bit [14:40] jamespage, gnuoy: could one of you review this? https://code.launchpad.net/~corey.bryant/charm-helpers/install-warning/+merge/264340 [14:41] coreycb, got it [14:41] coreycb, I'm sorry that hasn't been done, it looks good to me. let me land [14:41] oh, ok [14:41] jamespage, gnuoy: appreciate it thanks! [14:42] hi jamespage, gnuoy - we had talked a while back about moving to pxc instead of mysql in the next/default test bundles, as it's generally what is actually consumed. shall i make that switch in o-c-t and mojo specs? [14:42] beisner, +1 [14:42] I think so, +1 [14:42] (and thanks) [14:43] ok thanks & yw! [14:53] jamespage: when you have time, it would be good to get some more direction on the workload status work: [14:53] https://code.launchpad.net/~thedac/charms/trusty/neutron-api/status/+merge/264315 [14:53] https://code.launchpad.net/~thedac/charm-helpers/openstack-workload-status/+merge/264353 [14:53] I have another branch I am working on now that is a bit more destructive to get the missing context data available to set_context_status() but that may be getting too far into the weeds for our first go round. [14:57] Also do we like 'blocked' or 'waiting' as a status for incomplete contexts? [16:19] thedac: blocked is the user needs to take action, waiting is the charm waiting for something to happen which may be queued but no additional itneraction fromthe user may be required [16:19] marcoceppi: excellent description. in this case waiting then [16:20] * marcoceppi will draft a status page for the docs [16:20] that would be great === lukasa is now known as lukasa_away [16:48] marcoceppi: not already here? https://jujucharms.com/docs/stable/reference-status === lukasa_away is now known as lukasa [17:03] pmatulis: that is handy [17:04] pmatulis thedac: that's just the output of `juju help-tool status-set` [17:04] which doesn't quite describe the states === lukasa is now known as lukasa_away === natefinch is now known as natefinch-afk [19:24] hey stub let me know when you're up and working, I've got a few cassandra charm questions [19:37] marcoceppi: Last chance before bed time === natefinch-afk is now known as natefinch [19:57] stub: it's going to be a long, long, long time [19:58] but tldr, cassandra's java startup is core dumping on GCE [19:58] and we don't knwo why [20:05] marcoceppi: The only thing I'm aware of that we aren't doing that we should be doing is installing this JNA thing. [20:06] marcoceppi: Oracle JRE or OpenJDK? Both? But I'm no expert, and would need to turn to one to debug something like that. [20:08] stub: it's just OpenJDK atm [20:08] should we try Oracle JRE? [20:08] for whatever reason it works for local, amazon, and I'm about to test azure [20:09] marcoceppi: I would try Oracle JRE, yes. And if things still fail, try to manually install that JNA thingy (which is a suspect for a core dump if my understanding of what it is is correct) [20:10] stub: I realize it's late (early?!) you're time, so we'll try those and circle back the next time you're around [20:11] marcoceppi: Yup. Good luck. Writing that charm did not improve my opinion of Java much, so I doubt I could be much real help :) [20:19] stub: Can you explain http://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/revision/158.2.37 to me? Specifically, why are we using old (precise) library versions instead of the newest from pypi that will work? [20:20] charm-helpers needs to run on precise boxes, with precise dependencies installed. We need to ensure charm-helpers works with these old dependencies. [20:22] If we didn't do this, people would write code using the newest APIs and charms on precise would start failing. [20:24] (which actually happened, as there were a heap of features missing in precise's six module that meant charm-helpers could not even be imported) [20:27] Unless, of course, the Python dependencies were install from pypi. But I guess we can't assume that. [20:27] Not that I care, since I'm only dealing with trusty [20:27] Hrm. It just seems backwards to be locked into really old library versions like that. [20:27] cory_fu: Right. egress rules and all that. [20:28] cory_fu: Yes. It is a pain in the bum. [20:29] cory_fu: But if it is a problem, it doesn't have to be all or nothing. It might mean some code paths stop working under precise unless you install more modern dependencies, but people can deal with that. [20:32] well, hopefully with the new method of dpeloying charm-helpers, and dropping a lot of the contrib code [20:32] we can get ride of most of the dependencies [20:32] We probably want to drop precise entirely when Wiley is released. That many years of skew, we could hit the opposite problem. [20:33] Its not like people patching precise charms actually want the latest charm-helpers installed. [20:36] keep in mind that those pesky openstack charms ;-) have a single charm which is expected to support all currently-supported ubuntu releases. ie. the trusty/keystone charm is expected to work for precise through vivid at the moment, with dev focus on wily. [20:37] and in so doing, certain precise-icehouse charm fixes trickle back through charmhelpers [20:38] beisner: yes, but hopefully the openstack charm-helpers are underway of being removed from contrib [20:38] so they can do whatever they want/need, and the new slimmer charm-helpers will have little to no external dependencies [20:38] * marcoceppi looks longingly into the distance [20:38] one day [20:38] doctor, doctor, it hurts whenever I do this... [20:38] marcoceppi, i know it's been discussed, i'm not sure it's underway ;-) [20:38] lol [20:39] * beisner completes interjection. as you were as you were. [20:40] * stub wanders bedwards [20:44] lazyPower: howdy [20:44] lazyPower: so I got my charm deployed and working last night, a little after midnight [20:44] lazyPower: I went a slightly different direction, so I hope that's still kosher [20:46] kirkland: Thats the power of juju, there's more than one way to do something, and as long as it fits your objectives - you've always got your namespace to warehouse any artifacts for sharing. [20:46] glad to hear you found success in your mprime charm however. thats awesome [20:47] lazyPower: curious, I finally got the code to your docker charm [20:47] lazyPower: and I'm trying to figure out when/where/how you install docker itself [20:47] lazyPower: are you pulling it from the archive? a ppa? or, god help us, piping a shell script to sh as root? [20:47] kirkland: playbooks/latest-docker or playbooks/universe-docker [20:47] it d efaults to installing from archive, when you set latest=true and specify the version, it pulls from the docker ppa [20:48] that's covered in the charm docsite [20:48] lazyPower: oh, hmm, wow, this newfangled way of writing charms has my head spinning [20:51] kirkland: its an Ansible based charm. Juju has a hard requirement of hook files, so we take the concept of a hook, and use python glue code to call an ansible playbook - the tags in the playbook are what scope the actions to the context of the hook thats running. [20:53] lazyPower: okay, so point me to the docs on how to submit this charm for review now [20:53] kirkland: https://jujucharms.com/docs/stable/authors-charm-store#submitting [20:54] lazyPower: ta