[00:58] <mhall119> marcoceppi: is there any way I could get a juju gui showing off the developer.ubuntu.com staging deployment?
[05:23] <stub> marcoceppi, cory_fu : I think fixing imports is a separate issue, and should be done in any case. It makes things cleaner and less magic, and avoids hacks in situations that need it (eg. an @hook('upgrade-charm') wanting to invoke @when handlers directly). Python3 spent a lot of effort getting it working in the odd situations it didn't work in Py2, because occasionally you do need it and not having it is a pain in the bum.
[05:27] <stub> marcoceppi, cory_fu : If the convention is to put APIs and callable or shared non-handlers in lib/charms, thats fine. I had things in reactive because I wasn't aware of the convention, and it felt quite nice having it in the same package.  It was handlers and methods and helpers called by handlers, and some of those methods also designed to be called by handlers in other layers.
[05:29] <stub> (you call things directly rather than set state when you want a particular invocation order, have things invoked inside a context manager, interleave calling handlers with other code...)
[09:59] <jamespage> apuimedo, hey - I will get to your MP's today - just need to sortout an issue in our QA cloud with liberty
[09:59] <apuimedo> very well jamespage ;-)
[11:01] <stub> Has anyone wired up a Juju charm integration test suite to travis-ci ?
[11:06] <marcoceppi> stub: we did for a few layers irrc
[11:06] <marcoceppi> but not the integration stuff
[11:06] <marcoceppi> (like amulet)
[11:19] <stub> lxc test runner needs a kick - failing to bootstrap due to port in use
[12:00] <smartbit> Where can I find the recording of the first day at cfgmgmtcamp 2016, that includes Mark Shuttleworth's talk? I found it a couple of days ago, but lost it :-/
[12:12] <marcoceppi> smartbit: I'm not sure we've published it yet? I'll see if I can find them
[12:13] <marcoceppi> smartbit: we typically publish them here: https://www.youtube.com/jujucharms/videos but none have been uploaded yet
[12:14] <marcoceppi> smartbit: I'll ping James who was doing the recordings
[12:20] <smartbit> marcoceppi: Found it through http://eventifier.com/event/cfgmgmtcamp/videos : https://www.youtube.com/watch?v=sp_Re8Mx9xk&t=4095
[12:21] <smartbit> Recordings of day 2 & 3 juju charner summit 2016: https://www.youtube.com/playlist?list=PLzSGDpUWtiotngRgVqpa8jeCBQ2CCjzfo
[12:24] <marcoceppi> \o/
[12:53] <icey> can I `juju add-machine` with an existing machine, in essence bring the manual provider stuff to a regular deployment?
[12:55] <rick_h__> icey: I've not tried it, but I *think* so?
[12:55] <icey> well then rick_h__ I'll let you know how it works :)
[12:56] <icey> I need a very much not standard machine for a demo tomorrow so wanted to build the /machine/ by hand and then let juju have at it
[12:56] <marcoceppi> icey: yes you can
[12:56] <icey> glad to have it confirmed marcoceppi
[12:57] <marcoceppi> juju machine add ssh:user@address
[12:57] <marcoceppi> icey: ^^
[14:09] <jamespage> apuimedo, neutron-api and charm-helpers fixes landed thankyou!
[14:10] <apuimedo> I just got the email
[14:10] <apuimedo> thank you ;-)
[14:10] <apuimedo> I made some improvements to midonet-api today
[14:10] <apuimedo> to prevent races when running in HA
[14:10] <apuimedo> if you want an ha liberty bundle yaml let me know
[14:11] <stub> marcoceppi: Just looking at the apt layer, I have an install_queued method that may be called directly that is also a handler called automatically. So if I split it, there is going to be some silly duplication.
[14:21] <jamespage> apuimedo, bundles good
[14:21] <jamespage> yes please
[14:21] <apuimedo> very well
[14:21] <jamespage> apuimedo, hows the polish on lint, unit and amulet tests going?
[14:22] <apuimedo> lint should be fixed. unit tests are almost there
[14:22] <apuimedo> amulet tests I basically have to remove the old ones
[14:22] <apuimedo> the new one I added that can also install the enterprise edition, should be good
[14:33] <stub> Yeah, lib/charms/apt.py ends up ok but reactive/apt.py is a bag of dead chickens and the bootstrap/setup method.
 Hi,I will be developing IBM-IM as layer and I explored to make use of basic layer which is present in the "interfaces.juju.solution". and I am not sure about which interface that i can use it for IM from "interfaces.juju.solution",...? or do we need to develop IM interface seperately?? Can you please guide me on this?
[15:00] <mbruzek> shruthima: Hello again!  From the information you gave me yesterday the IBM IM layer would be a charm layer not an interface layer (which is like a relation).  So your layers.yaml would import from the layer:basic.
[15:02] <mbruzek> That will give you a starting point and you can create a charm layer in a repository such as Github or Launchapd.
[15:03] <mbruzek> at this point you shouldn't need to worry about interfaces.juju.solutions, you can make a layer off-line on your own machine. Then when you run "charm build" it will go to interfaces.juju.solutions to pull the basic layer just once
[15:06] <cory_fu> stub: While I enjoy your colorful metaphor, I'm not sure I understand why you're unhappy with the resulting reactive/apt.py?  Do you have it committed, perchance, that I might take a look?
 oh ok thank you.
[15:07] <cory_fu> A branch, perchance?  :)
[15:08] <mbruzek> shruthima: Other people on the team know about layers and reactive, you can ask technical questions about layers and reactive here and others should be able to respond.
[15:09] <mbruzek> here == #juju
[15:09] <shruthima> okie :)
[15:12] <jacekn> hello. I'm having problems understanding juju storage documentation: https://jujucharms.com/docs/1.25/storage I am looking for list of possible values for "type" parameter. I can see "type: block" in an exmaple but it's not documented anywyere
[15:12] <jacekn> also "type: filesystem" seems undocumented
[15:13] <jacekn> will something like this work at all? https://pastebin.canonical.com/149486/
[15:58] <stub> cory_fu: https://git.launchpad.net/layer-apt/tree/?h=apipackage
[15:59] <stub> cory_fu: Its not terrible, but it seems worse than what I started with.
[16:08] <stokachu> marcoceppi: \p/
[16:08] <stokachu> :(
[16:21] <jacekn> hello. I have not heard anything regarding this bug I filed 2 weeks ago: https://bugs.launchpad.net/charms/+bug/1538573 can somebody tell me if it's on charmers's radar?
[16:21] <mup> Bug #1538573: New collectd subordinate charm <Juju Charms Collection:New> <https://launchpad.net/bugs/1538573>
[18:41] <cory_fu> stub: Do you really think that users will need to manually call install_queued or ensure_package_status instead of just relying on the state system to invoke them?
[18:42] <cory_fu> marcoceppi: https://github.com/juju-solutions/layer-basic/pull/33  Thoughts?
[18:43] <marcoceppi> cory_fu: weeeee LGTM
[18:43] <cory_fu> It's untested, though.  ;)
[18:43] <cory_fu> (Testing it now)
[19:38] <jcastro> https://www.youtube.com/user/TheSmartbit
[19:38] <jcastro> does anyone know who this is so I can credit them in the summary?
[20:01] <marcoceppi> jcastro: it's probably smartbit
[20:20] <jcastro> yeah I was looking for a real name
[20:50] <stub> cory_fu: Sometimes. A simple linear @hook('install') might be preferable to half a dozen state handlers. I was also calling install_queued from inside a context manager at one point.
[20:51] <cory_fu> stub: If that's the case, might it not be cleaner to just use the existing tools in charmhelpers?
[20:52] <stub> cory_fu: I think the API is tidier in what I have, and if people like it, this would be where this bit of charmhelpers migrates too
[20:52] <stub> So I would like to support both calling styles. There doesn't seem to be any reason to not support it.
[20:53] <cory_fu> Fair enough
[20:53] <cory_fu> btw, you could avoid doing explicit aliasing if you just import those functions directly
[20:53] <stub> Which is certainly an argument in favour of sticking things in lib/charms
[20:53] <stub> Oh, duh.
[20:56] <cory_fu> I see what you mean, though, about the reactive file just ending up a place to add decorators to existing functions.  I'm not sure that I consider that a bad thing, though.
[20:56] <stub> I can argue it both ways
[20:57] <stub> I don't think these 'library' layers are typical.
[20:58] <stub> I'll go with the split unless people have other use cases for putting an API in reactive.
[20:58] <stub> But I still think it is worth doing the imports better ;)
[21:00] <stub> Given the PEPs Python3 has implemented to get absolute and relative imports working in all other cases, it will be surprising and seem broken whenever people discover it doesn't work in built charms.
[21:03] <cory_fu> Yeah, I don't disagree
[21:04] <stub> When you say 'just a place to add decorators to existing functions' I have flash backs to Zope3 and ZCML ;) At least we don't need to use XML to decorate them :)
[22:21] <wesleymason> Are there any good examples of a reactive charm using the nrpe interface? I can't seem to get the bloody thing to work.
[22:34] <marcoceppi> wesleymason: not that I'm aware of - what are you having problems with?
[22:35] <bolthole> question about juju and lxc. https://jujucharms.com/docs/1.24/troubleshooting-local-lxc doesnt mentoin how to view the actual lxc containers juju uses. doing "lxc list" doesnt show anything?
[22:38] <marcoceppi> bolthole: is this lxc local provider or lxc in a deployed environment?
[22:39] <marcoceppi> bolthole: also, if you're not using 1.24 of juju, I recommend going to the /stable/ version of the docs
[22:40] <bolthole> juju with local environment
[22:40] <bolthole> setup with juju bootstrap, etc.
[22:41] <bolthole> as far as version of docs.. I go to what google pulls up. So you guys may have some tweaking to do for google search optimization ;->
[22:42] <marcoceppi> bolthole: we've been trying to kill juju from crawling our versioned docs, so far that has been fruitless :\
[22:42] <marcoceppi> bolthole: does `lxc-ls` work instead?
[22:42] <bolthole> anyways, content is identical.
[22:42] <marcoceppi> bolthole: sure, but just a point in general
[22:43] <bolthole> lxc-ls shows nothing. (and isnt it just an alias for lxc list?)
[22:44] <marcoceppi> bolthole: `lxc list` and lxc-* are two different versions of lxc. one, lxc list, is the new LXD frontend, and the other is traditional lxc
[22:44] <marcoceppi> bolthole: do you have services deployed?
[22:44] <marcoceppi> does `lxc-ls -a` show anything?
[22:45] <marcoceppi> err `lxc-ls --fancy`
[22:45] <bolthole> nope
[22:49] <wesleymason> marcoceppi: effectively, deploy my charm, deploy nrpe, add-relation, I have a handler with a @when('local-monitors.available'), and it never fires.
[22:49] <wesleymason> Same for nrpe-external-master if I used that instead
[22:52] <marcoceppi> bolthole: what does you juju status output look like?
[22:52] <marcoceppi> wesleymason: weird, that's not the intended design
[22:52]  * marcoceppi checks interface
[22:53] <marcoceppi> wesleymason: do you mean nrpe-external-master?
[22:54] <wesleymason> marcoceppi: well using either, local-monitors for nrpe
[22:55] <marcoceppi> wesleymason: we don't have a local-monitors interface in the interface listing
[22:55] <marcoceppi> haha
[22:55] <marcoceppi> I can't read
[22:55] <marcoceppi> wesleymason: what does your metadata.yaml look like?
[22:56] <bolthole> rebuilding it right now, so cant answer :-/  but if someone with workig juju local wants to post THEIR ouptput, that would be great :)  meanwhile, I am going to be afk for a while
[22:57] <marcoceppi> bolthole: I've been running the alpha1 for a while and am using the new lxd provider - so much more awesome :)
[22:58] <wesleymason> marcoceppi: https://github.com/1stvamp/juju-errbot/blob/master/metadata.yaml
[22:58] <marcoceppi> wesleymason: that's the problem
[22:59] <marcoceppi> wesleymason: you don't require local-monitors, you provide it. The interface library is a bit incomplete - it only has one side of the protocol implemented, the more common side, which is providing local-monitors
[22:59] <marcoceppi> https://github.com/cmars/local-monitors-interface
[22:59] <wesleymason> marcoceppi: aaaaaah nuts, yes, I see it now
[22:59] <wesleymason> marcoceppi: been staring at that metadata for ages, blind
[23:00] <marcoceppi> wesleymason: it's all good. we should consider adding a check at build time that "you provide X interface but interface library does not have provides.py"
[23:01] <wesleymason> marcoceppi: good idea, I should also check my glasses prescription 😉
[23:07] <marcoceppi> wesleymason: https://github.com/juju/charm-tools/issues/105
[23:08] <wesleymason> marcoceppi: 👍
[23:08] <wesleymason> marcoceppi: also interface working fine now 😀
[23:08] <marcoceppi> \o/
[23:09] <wesleymason> Quite close to a fully working errbot charm now
[23:10] <smartbit> jcastro: Bart Smith >smartbit :-)
[23:10] <wesleymason> marcoceppi: out of interest, what's the generally accepted way to package/ship a charm built from a layer? Are people just checking into separate repos/branches, or shipping built tarballs somewhere etc?
[23:22] <marcoceppi> wesleymason: people are starting to use the charm command to upload/publish them into the store
[23:22] <marcoceppi> wesleymason: but that's still a private beta, otherwise, they're putting their layers into VCS they like then the charm artifcat that's built is just uploaded to bzr like charms have been in the past