[00:47] is there a reason that debug-hooks can't wait for a unit's public address to be published? === natefinch-afk is now known as natefinch [02:05] lazypower: pong [10:06] sanity check: if I have $JUJU_REPOSITORY/interfaces/test/{interface.yaml,provides.py,requires.py}, a charm layer in $JUJU_REPOSITORY/layers/test-charm/ that has includes: ['interface:test'], and has the interface in the metadata.yaml, I should expect to see those provides/requires.py in the charm build output somewhere, right? [10:28] gnuoy, thedac, coreycb: what do you think of https://code.launchpad.net/~james-page/openstack-charm-layer-dev/+git/openstack-charm-layer-dev/+merge/279563 ? [10:28] it introduces 'adapters' and a object mechanism for aggregating them across presented interfaces [10:28] argh, we're working on the same thing [10:30] jamespage, I really like it [10:30] gnuoy, some of that needs interfaces/relations [10:30] interfaces is the type, rather than the actual named relation [10:31] gnuoy, I think we can add some base adapter mapping as well, and then override in the subclasses [10:31] jamespage, so I proposed that the adapter code goes into a layer called openstack which places them in lib/openstack/adapters.py [10:31] gnuoy, that sounds good to me [10:31] gnuoy, sorry if I stepped on your toes... [10:32] jamespage, not at all, you'd got much further than me [10:32] gnuoy, I prefer this class based approach to dealing with things rather than functions and global variable in a utils class [10:33] jamespage, I'm happy to grab what you've done and do the layer munging unless you want to do that ? [10:33] gnuoy, please go ahead - we can then collab on getting the layer just right... [10:33] kk [10:33] gnuoy, there are some bits of that I don't like right now [10:33] (I wrote one TODO) [10:34] gnuoy, I did a template mockup as well - http://paste.ubuntu.com/13665616/ [10:35] untested [10:35] kk [10:35] gnuoy, I'm wondering whether we can also take an object based approach to the handlers as well... [10:47] gnuoy, just making the adapaters classes behave like jinja2 wants [10:48] jamespage, lp:~openstack-charmers-layers/charms/+source/reactive-openstack-layer [11:08] gnuoy, OK I'll push my change their [11:11] gnuoy, ok should work with jinja2 now [11:12] gnuoy, I'll refocus onto ceph now and stop stepping on your toes... [11:13] I'm very grateful for the input, thanks [11:13] gnuoy, my thinking on 'interface_type' was to use that for status reporting [11:13] but not thought through just yet [12:19] jamespage, thedac, coreycb: I've taken James' work and created a branch containing the fledgling openstack base layer. I've also updated the setup branch to use it. [12:19] * gnuoy heads out [13:32] jose: hey there. Was looking for you lastnight to get you in touch with mattyw about ubuntu membership [13:48] jamespage, gnuoy: I like that adapter approach. that was a bit to wrap my head around, but if you look at that code without the base classes in the picture it's really pretty simple to write/use an adapter. [13:55] coreycb: what are these adapters you speak of? [13:56] lazypower, https://code.launchpad.net/~james-page/openstack-charm-layer-dev/+git/openstack-charm-layer-dev/+merge/279563 [13:57] interesting.. you can swap in/out interfaces using an adapter? [13:57] lazypower, basically it's a way for the openstack charms to add some logic around interface data, and render it more easily [13:57] i like it [13:57] it looks clean === rogpeppe2 is now known as rogpeppe [13:58] lazypower, yeah and and it keeps any logic out of the interface layer, and lets the interface just return data [13:58] coreycb: thats *exactly* what its supposed to do [13:58] \o/ [13:59] yup [14:02] coreycb, lazypower, thedac, gnuoy: I just pushed a bit of a rename I wnated todo into the openstack base layer [14:02] Interface->Relation [14:09] and I added some support for default adapter mappings into the Adapters base case [14:09] is there a way to exclude directorys in a layer when building? [14:09] I was about to ask the same thing [14:10] I'd like to exclude unit tests for a layer for example [14:10] same here [14:18] there is a way to declare that i do beleive [14:19] Ah, according to the old repo's layer.yaml it only has strategy keys for deleting yaml key names [14:19] from config/metadata [14:23] oh wow - so charms.reactive does not use standard python import mechanisms, it does: [14:24] sys.modules[modname] = load_source(modname, realpath) [14:24] which means imports inside that source don't seem to work right [14:26] e.g. so if my reactive/ dir has 3 files ( foo.py, bar.py, __init__.py), I can not import a from b when running as a hook. I can when running unit tests. [14:26] s/a from b/foo from bar [14:28] oh my [14:28] (Pdb) __name__ [14:28] '_var_lib_juju_agents_unit-x509-cert-0_charm_reactive_x509_cert_py' [14:28] (Pdb) [14:28] that would explain it [14:29] so, reactive/ modules can not depend on other local files. [14:30] an no, that's just name manling, ignore me [14:30] *mangling [14:33] thedac, gnuoy, coreycb: added tox configurations to the layer and the rabbitmq interface - does lint only right now but set to go for unit testing as well [14:33] coreycb, wanna add that to the shared-db interface? [14:33] jamespage, +1 yep I'll do that today [16:19] hello you brainy charmers you [16:20] o/ [16:20] quick q [16:20] deploying openstack with juju [16:20] ext-port in the openstack-config.yaml -- is that the existing connection? [16:20] or a second one [16:21] TheJeff: I think it's existing? jamespage gnuoy beisner coreycb ^? [16:21] like, the interface that connects to MAAS? I guess not, although that seems to be the only active interface on the juju host its up [16:21] TheJeff: I think it's for the external network [16:22] alright... so eth0 will I suppose always default to the MAAS network [16:22] then if i specify eth1 it'll bring that up on its own connection? [16:22] TheJeff: I'd wait to see what the OpenStack charmers have to say [16:22] we have vlans for each physical interface. I'm not sure from this config file and the way its going to spin up which one will be whitch [16:23] which* [16:23] eh, gonna try eth1 (default) and see what happens. if it breaks I'll do it again I suppose [16:23] unless the governor phones before I hit enter [16:26] TheJeff, that's a second one [16:27] TheJeff, so I believe you need 2 ports for neutron-gateway [16:27] ok cool [16:27] one for cloud services, one for external instance traffic [16:27] cool [16:27] got it [16:28] additionally - in the same conf, osd-devices suggests sdb [16:28] is a second phyiscal block device required? [16:28] we only have sda [16:29] TheJeff, one should be ok [16:30] TheJeff, well, in total I think you'd need at least 2 [16:31] TheJeff, but a minimum of one to use as a ceph osd volume [16:32] if that makes sense, one for ceph to consume, one for your root partition [16:35] hm [16:37] TheJeff, its an additional port - eth0 will drop all connections to the server [16:37] TheJeff, you might find https://jujucharms.com/openstack-base/ informative [16:39] coreycb, thedac, gnuoy: idea - use ddt for interface testing [16:39] http://ddt.readthedocs.org/en/latest/example.html [16:41] although that might not do quite what we want [16:47] jamespage, that looks pretty neat [16:47] coreycb, yeah - but I'm not sure it can do anything super complex with regards to data read from file [16:48] coreycb, I was thinking we could spec relations as yaml/json [16:50] jamespage, could be nice for the base openstack layer to work off a yaml of key/value interface data [16:50] ? [16:51] jamespage, I'm thinking more of when an event becomes true, so maybe not for testing the base layer [16:53] jamespage, so for testcharm.py for example you could have a yaml of key/value interface data that you test and verify the adapters work. I think you're talking about testing at the interface level though [16:59] arosales: kwmonroe cory_fu ease and speed of building new hadoop/spark solutions (juju bundles) from existing charms has been impressive and mouth dropping by some . [16:59] w00t asanjar! that's good to hear. [17:00] asanjar: \o/ [17:00] coreycb, nogood brainfried [17:01] 5pm on a friday is not a good time to think about data driven unit testing.... [17:01] jamespage, mine or yours :) yeah time for a wind down I bet [17:01] cory_fu, hey - was looking at your reactive test helper pull request - we're getting to a point where I don't want to write a whole lot more code in interfaces without some unit testing [17:02] cory_fu, for the openstack charms today, we have a way of plugging in a set of 'relation data' which gets plumbed into the relation_get/units/ids calls - what do you think of a similar approach for testing interfaces? [17:03] thinking that we write json/yaml to represent each interface state; that gets read and plumbed in so we can then poke the interface class and ensure it sets the right state etc... [17:03] hey asanjar [17:04] jamespage: how are you my friend.. [17:04] asanjar, well thanks - how about you? [17:05] jamespage: I am well and as usual still causing trouble for arosales [17:05] I'd expect nothing less [17:05] jamespage: sign of good health [17:05] anyway I'm going to EOW for now - have fun everyone [17:05] * jamespage goes for a beer [17:05] * arosales relishes in the touble asanjar creates [17:06] jamespage: have a good weekend, enjoy the beer [17:06] jamespage: have a pint on me === natefinch is now known as natefinch-afk [17:12] jamespage: Sorry, was on a call [17:15] jamespage: I'm not sure what PR you're talking about, but we definitely want to have some framework / helpers around testing reactive charms. One aspect to consider is that the relation data will need to evolve over time to model an evolving conversation, so a static set of data won't work. [17:16] We might also want to consider where we cut the testing of interface layer implementations vs charm layer implementations. As in, maybe in charm layer tests we want to have a system to easily "mock" interface classes based on their API and not the low-level data coming over the relation. But that might be more difficult to manage and might not be worth it [17:16] (Might even be counter productive, if we want full-stack testing) [17:21] hey jose [17:24] cory_fu: when you release a pypi package, you dont track the .egg-info bits or any of that in the repo do you? [17:25] i was looking at charms.reactive as a reference [17:25] No, you shouldn't [17:36] kwmonroe: cory_fu: reactive charms ??!!! i smell another rewrite of big data charms.. third time's the charm [17:36] asanjar: Well, you never liked the services framework, and it turned out that everyone else agreed with you. ;) [17:37] asanjar: Also, it's called "refactor" not "rewrite" ;) [17:38] cory_fu: lol awesome [17:40] asanjar: how could you have missed all the reactive buzz? :P [17:40] we *Started* that in DC [17:40] well, the public buzz anyway [17:41] asanjar: Welcome to the community. I reject your immutable attitude [17:41] lazypower: I don't remember what I had for breakfast this morning . [17:41] asanjar: are you coming to the charmer summit in belgium? [17:41] asanjar: we need to go hit up that little hookah bar street side in brussels again. I'm hankering for some mojitos [17:42] mbruzek: how are you my friend, how is your MUCH better half [17:42] asanjar: she is well. Taking a half day today, to buy YOU a gift. [17:43] asanjar: I don't think the post office will let us mail poo. [17:44] lazypower: I would love to go to the Charm summit, but seriously doubt IBM would pay. [17:45] mbruzek: mark it as white POO, and not BOOM [17:46] asanjar: i smell diversity class coming on [17:46] lazypower: I have that shit reset [17:46] asanjar: seriously happy holidays to you and your kids. [17:46] asanjar: family friendly please sir :) [17:47] mbruzek: same to you buddy, have a wonderful xmas [17:47] asanjar: ... I think their names were Cory and Kevin [17:47] mbruzek: lol lol [17:47] oh man, i forgot about that hookah bar. [17:50] jrwren: good times :) === natefinch-afk is now known as natefinch [18:11] can you create multiple relationships between two services? What are the rules around this interaction? [18:14] hatch: you sure can [18:14] hatch: that the interfaces match on both ends. thats pretty much it. [18:15] lazypower: so can you do two from one service to one endpoint on another? [18:15] or do the two relations have to have unique endpoints? [18:16] its really only governed by the relationship name/interface. Say you have a db relation that uses interface: mdb and you have a db-admin relation that uses mdb interface. Both are completely reasonable uses of the same "endpoint", and can consume any provided relation using the mdb interface [18:17] ahh ok so an endpoint doesn't become 'locked' once it's active [18:17] you can connect to that same endpoint multiple times [18:17] right, as its 2 sep. relation scopes on the requires side keep it as independent relations [18:17] they just share the same communication protocol [18:18] great, now however you cannot create two identical realtionships [18:18] that would be a noop? [18:18] well, thikn of it like this [18:18] juju add-relation foo:bar bar:foo [18:18] when you type that in a second time [18:18] its going to error saying you've already added that relationship [18:18] or rather, that the relationship already exists [18:19] lazypower: thanks for clarifying - I'll file a bug to add this information to the user docsc [18:19] hatch: what you may want to do, is follow up with dimiter, as i know that network spaces were changing some of the rules here about this, as the network spaces bring into it the concept of binding service endpoints to a space, and you may be able to "overload" a relation due to the nature of a scoped network. [18:19] ahh [18:20] where having 2 services in sep. network spaces use the same relation/interface across the different scopes [18:20] due to whatever crazy networking you're modelling [18:20] because dimiter loves crazy networking ;) [18:20] lol [18:20] and meatloaf [18:38] is there a constraints-type option for config.yaml [18:39] admcleod- So when you say constraints-type, what do you mean by that? [18:39] if i config set, it must be one of a defined set [18:39] ah, there is not an ENUM type to speak of that i'm aware of [18:40] We've been working around that with status messaging, and an array of accepted values. [18:40] if its not one of the accepted values, status-set blocked, and message the user that they need to *read* what is acceptable [18:40] ok thanks [18:41] admcleod- seems like a good idea to go poke this issue - https://bugs.launchpad.net/juju-core/+bug/918386 [18:41] Bug #918386: config.yaml should have enum type

[18:57] hey cory_fu, so, i jsut got my layer setup for wheelhousing deps. [18:57] http://paste.ubuntu.com/13674509/ -- as confirmation [18:57] on charm deploy does it do the due dilligence to setup the proper linking for $PATH and all that schenanigans? [18:58] Ok, first of all, there is a new release of charm-tools coming that will fix the fact that those are platform specific wheels and will probably fail when you deploy them [18:59] ok, i have something i need ot forward you then - as it appears we may have some overlap [18:59] if you check your mail, there's a stack there about being unable to find charms.reactive that i'm en-route to try and reproduce [18:59] Second of all, the wheelhouse is now installed into the system and not the charm dir, so the path and imports should Just Work. The base layer still supports lib/charms/* in the charm so that you can include small, charm-specific helpers libs in the charms.X namespace without packaging and pushing to pypi [18:59] is that the error you're referencing? [19:01] lazypower: Hrm, no. The error I would expect is that the pip install on the wheelhouse would fail because the platforms don't match [19:01] So it would have failed earlier than that [19:01] And the error would have specifically mentioned the platform [19:03] hmm [19:03] Ok, back to reproducing then [19:03] thanks for TAL [19:05] np [19:06] ah yep [19:06] found it [19:06] wheel broke when installing PYYAML [19:19] well cory_fu - on the bright side, osx brew released charm tools is now properly embedding dependencies (it didnt seem to in the 1.8.x releases), however its got the wheel bug as you pointed out :) so its progress in the right direction [19:20] Again, I believe marcoceppi is currently working on the next release (including OS X brew) that should fix the wheel bug [19:21] Right on [19:21] marcoceppi: confirmation on the above? [19:21] Well, work around it, since we can't actually use wheels any more. (Which makes the "wheelhouse" a bit of a misnomer.) [19:21] lazypower cory_fu otp, but afterwards 1.9.4 is being released [19:21] whee \o/ [19:21] lazypower cory_fu https://github.com/juju/charm-tools/milestones [19:22] Thanks for the hard work, marcoceppi! [19:22] cory_fu: Does the reactive base work with the leadership hooks at this time? [19:23] cory_fu: In other words can I use @hook('leadership-settings-changed') to decorate my python function? [19:23] mbruzek: No, but I believe that can be handled outside of the charm-tools release cycle (unlike actions) [19:23] i believe its missing the storage hooks, and the leadership hooks. https://github.com/juju-solutions/reactive-base-layer/issues/4 [19:24] lazypower: storage hooks will need a charm-tools update as well [19:24] Since the hook names are not fixed [19:24] ah, true [19:24] it needs to generate them much like the interface layers are handled right? [19:24] Yep [19:25] Same w/ actions, and I'm still a little unsure as to how / whether we should handle actions [19:25] cory_fu: so your advice for leader-settings-changed is to make an old sytle hook named "leader-settings-changed" in this case? [19:25] mbruzek: Or create a PR against the base layer. I think that fix at least should be easy [19:25] I'm happy to review and merge [19:25] ack [19:38] hey what up everyone? [19:38] has anyone here ever preformed an instance resize? [19:38] :-) :-) :-) [19:38] whattup bdx [19:38] Hi bdx [19:39] hey guys, we need to add the "allow_resize_to_same_host=true” and “allow_migrate_to_same_host=true” to ALL nova confs [19:39] otherwise resize functionallity is broken [19:40] bdx: would be good ot get that as a bug against the requisit charms [19:41] lazypower, will do. [19:42] lazypower, mbruzek: I have a few questions concerning charming with layers.... [19:43] fire when ready [19:43] I want to create a puppetserver and puppetagent charm [19:43] so [19:43] cory_fu: https://github.com/juju-solutions/reactive-base-layer/pull/12 [19:44] from what I can tell, I would need to create a puppet-agent interface and a puppet-server interface [19:44] on top of that, I would need to create 2 layers, puppet-server-layer, and puppet-agent-layer [19:45] bdx: i'm not sure why you would need two interfaces. afaics the puppet agent / server comms would use the same interface. perhaps just interface: puppet - as an interface layer so the agents can self-register. [19:45] then, 2 charms, a puppet-server and a puppet-agent, each of which would provide the interface for itself, and require the interface for the other [19:46] the other interface would be consuming the typical HTTP layer as puppet master is a REST API, so expose that if required. [19:46] bdx: i think you've got relation and interface confused :) [19:46] bdx: interfaces are just the communciation happening between the two units. same interface, 2 relations - one for each charm. [19:47] entirely [19:48] bdx: are you familiar with statically typed languages implementation of interfaces? [19:48] somewhat [19:48] its just a data contract, that say you can be / do whatever you want. But you will implement "these things". [19:48] totally [19:48] ok [19:49] in charms, its very similar. We're saying this interface will *always* expect these data points, and communicate in ['global'|'service'|'unit'] . [19:49] totally, tracking [19:50] which is why the interface programmer typically writes the provides/requires side of the interface, that way consumers just point at it, and the metadata susses out the details. All you need to ensur eyou do is grab the proper side of hte interface, and then handle it in your reactive bits [19:50] bdx: did you watch the UOS session over charming with layers? [19:50] yes [19:50] cory did a great job of explaining this in that session. highly suggest you grab a re-watch of that session [19:51] I've been reading and watching, and following the interface and layer repos you all have created [19:51] so [19:51] mbruzek: Should we go ahead and add update-status while we're at it? [19:51] cory_fu: you had a pretty legitimate concern there [19:52] There was some discussion on https://github.com/juju-solutions/reactive-base-layer/issues/4 and I was trying to play the devil's advocate, but I'm generally pro-update-status [19:52] cory_fu: lots of curn on the unit during update-status if the hook is treated as a reactive handler. [19:52] *churn [19:52] Yeah, maybe. Though there are several reasons why it would be very useful [19:52] And, it's entirely possible to code around that churn and is really something we should be encouraging anyway [19:52] oh indeed :) I see my name on that issue comment stream for being pro update-status, i just wanted to play the devils advocate once :D [19:53] ha [19:53] because "reasons" [19:54] mbruzek: Merged [19:54] I'm really tempted to Friday afternoon cowboy in the update-status hook. :p [19:56] cory_fu: do it [19:56] cory_fu: do you ened a charm-tools change for that? [19:56] * marcoceppi hasn't cut the release yet, it won't go out until late tonightr [19:58] marcoceppi: Nope [19:58] storage support would, though if we want to get that in real quick [19:58] cory_fu: I'm down [19:58] I can hold release off until weekend too [19:59] ligaf [20:06] hey all; i'm managing 2 servers using manual provider, and on the second machine the agent is always lost when i deploy a service and agent-state ends up failing. functionally i can't deploy anything to it. === JoshStrobl is now known as JoshStrobl|AFK [20:12] marcoceppi: i urge you to not hold it as the current revision is utterly broken [20:12] lazypower: that's fine. it's going out probably around 5pm EST [20:12] marcoceppi: nothing i build coming from c-t 1.9.3 in brew will work [20:13] i'm testing now w/ the vagrant box to see if thats a valid work around [20:16] mbruzek, lazypower, marcoceppi: https://github.com/juju-solutions/reactive-base-layer/pull/13 === JoshStrobl|AFK is now known as JoshStrobl [21:20] cory_fu: How does one release a new version of a reactive layer? Do we need to do something on interfaces web site? [21:20] Nope. Anything merged to master is immediately released [21:21] cory_fu: OK. I did not touch the update-status hook in my contribution because I saw the issue where you were worried about that one hook. [21:23] mbruzek: Thanks for the README catch [21:23] cory_fu: no problem, while in the README I wondered why you used so many backticks [21:23] mbruzek: Also, it's less that I'm worried about the hook, and more that I'm worried about people writing naive charms that end up churning on the machine [21:24] mbruzek: Too much reST writing in the pydocs [21:26] cory_fu: whats the version in the interfaces site in reference to then? I thought that had ot be incremented when you update a layer... [21:27] I think it's intended to auto-update, like the charm revision, but it's not implemented yet [21:28] ah ok [21:28] Also, I wonder if using semver there might be better [21:34] i <3 semver so i'm an automatic +1 to that [21:34] could use a quick pair of eyes on this to get landed, it works in non x-platform cases, which is good enough for me for now - https://github.com/juju-solutions/layer-docker/pull/20 [21:37] lazypower: Should the "## States" header actually be "### States"? [21:37] Yeah, good call [21:38] Otherwise +1 [21:39] ninjaed [21:40] daww i merged it too fast? [21:41] sorry mbruzek, i'm so used to our workflow :P [21:41] all good [22:18] marcoceppi, mbruzek: https://github.com/juju/charm-tools/pull/67 [22:37] cory_fu: I'm not sure this works [22:38] Why do you say that? [22:39] cory_fu: commented on mp [22:40] I also don't see any tests for this? [22:40] Gah, yeah, so much for me paying attention to my copypasta [22:41] mmm pasta [22:49] marcoceppi: Updated [22:59] cory_fu: I'll land this, but it'll be a 1.10.0 bump [22:59] That's fine [23:01] cory_fu: https://github.com/juju/charm-tools/pull/55 is now conflicting [23:02] marcoceppi: I'm confused, are you now looking at doing a 1.10.0 release? I'm fine with the storage changes not landing now, but I do need the other, smaller changes (dist.yaml and resources.yaml) [23:03] cory_fu: well I just landed the storage stuff, so I figured I'd do a 1.10.0 bump [23:03] but maybe that was a bit...zealous [23:03] Oh, well, if you're ok with doing that at EOD on a Friday [23:03] I always am [23:03] cory_fu: I was saying, if you wanted to update the py3 changes, I'll land that now as well [23:04] Ok. You ok with a pull --rebase for that branch, or should I just do a merge? [23:04] I was just holding off to group it with a bigger minor feature release [23:04] (To update it to master) [23:04] cory_fu: ti's a feature branch do whatever you'd like :) [23:04] I'm just not sure how github handles PRs being rebased out from under it [23:04] though I am a fan of rebase [23:04] cory_fu: it does the right thing [23:04] you just have to force push your feature branch [23:07] marcoceppi: Updated. CI is running, but tests passed for me [23:08] I'm also a fan of rebasing feature branches [23:08] cory_fu: cool, ta! [23:20] have a good weekend guys [23:20] * mbruzek waves the eow flag [23:21] You, too, mbruzek [23:21] Damn