[08:24] <tasdomas> hi
[08:24] <tasdomas> what is the best way to run bundletester on my charm in a "pristine environment" ?
[08:26] <anastasiamac> tasdomas: m afraid to ask :) what do u consider "pristine"?
[08:27] <tasdomas> anastasiamac, basically as close to the automated test runner used by the juju charms team
[13:46] <g3naro> can i search juju modules from the cli ?
[13:50] <rick_h_> g3naro: juju charms?
[13:50] <g3naro> yeah
[13:51] <rick_h_> g3naro: hmm, we're working on a store cli plugin but it's not public yet that does have some search abilities.
[13:51] <rick_h_> I don't recall if the eco folks had a plugin for that. marcoceppi lazyPower was there something you all had in charm helpers/tools?
[14:01] <g3naro> ohh k
[14:33] <marcoceppi> rick_h_: g3naro `juju charm search`
[14:33] <g3naro> nice 1 bro
[14:38] <puzzolo> lazyPower: ping
[15:39] <lazyPower> pong puzzolo
[16:16] <magicaltrout> help, bzr newbie here
[16:17] <magicaltrout> https://jujucharms.com/docs/devel/authors-charm-store i completely suck and don't understnad how to get my bzr repo into launchpad
[16:18] <magicaltrout> charm/trusty/saikuanalytics I have a folder structure like that and created a bzr repo in the charm directory
[16:18] <magicaltrout> but can't figure out how to get it into launchpad, I just get No such source package
[16:33] <beisner> magicaltrout - still around?
[17:09] <redelmann> Hi, is there any juju-restart function/method in charmhelper?
[17:09] <redelmann> or just need to call subprocess.check_call
[17:11] <redelmann> marcoceppi, ^?
[17:11] <redelmann> juju-reboot, sorry
[17:11] <marcoceppi> redelmann: not sure, let me check
[17:12] <redelmann> marcoceppi, i search on charmhelpers docs, and didn't find anything
[17:12] <marcoceppi> redelmann: then not yet, you're welcome to submit a patch though
[17:13] <redelmann> marcoceppi, ok, thank you
[17:19] <skylerberg> beisner, wolsen, coreycb: To follow up on our conversation yesterday about connecting to nova-compute. I think it will be best to keep it simple and just use the config-flags options in nova-compute. I can use my README to communicate that users need to do this.
[17:20] <skylerberg> However, I see that config-flags takes a comma separated list. One of the values I need to pass in does itself have a comma in it.
[17:20] <skylerberg> Without having looked at the code, I am not sure if nova-compute will choke on a config flag that has a comma in it.
[17:30] <whit> what's the command that shows all the tools available to a charm?
[17:32] <whit> ah.. juju help-tool
[18:13] <puzzolo> jo lazyPower any news on these lxc networking thingies?
[18:13] <lazyPower> puzzolo: hey there
[18:13] <lazyPower> puzzolo: i dont have any updates unfortunately
[18:39] <beisner> hi skylerberg - as i understand it, the config-flags config option is there for one-off edge case needs.  what are the config options you're needing to pass in?  if they don't collide with others, that may be a sane approach today.  but there's no way to say there wouldn't be future collisions if it's not in the nova-compute code base for reviewers to know about down the line.  i do think the better / more-official (tm) approach may be to add a charm confi
[18:39] <beisner> g option to twiddle the conf bits you need.
[18:41] <jcastro> jose: ping
[19:03] <skylerberg> beisner: I would be adding something like "cpu_mode=none,nfs_mount_options=vers=3,proto=tcp". Looking at it, I don't think it is possible to parse that correctly.
[19:05] <beisner> skylerberg, ok so we already have another need to control cpu_mode in ppc64 scenarios, just need to add that.  keep in mind, in kilo and later the cpu_mode directive got moved to a different conf file that the charm currently has no other reason to touch (so that's not plumbed just yet).
[19:05] <beisner> a lot of conf directives scooted around between icehouse and kilo, so we just handle that via the templates in the charm.
[19:05] <beisner> makes it transparent to the user.  they just set a charm config option, the charm lands it in the right file
[19:06] <beisner> so anyway, that kind of makes the case for using charm config options instead of that little backdoor-ish conf hole we have open.  make sense?
[20:00] <skylerberg> beisner: I need to talk with someone on my team to see if we really need cpu_mode=none. So for the nfs_mount_options we should probably just add that as a nova-compute charm configuration option and then I can just tell users to set it.
[20:22] <skylerberg> beisner: Okay. All I actually need to do is set nfs_mount_options=vers=3. So we just need to add nfs_mount_options as a config option for the nova-compute charm, right?
[21:24] <skylerberg> I was going to try to make a pull request to add the configuration option for nfs-mount-options, but the repo on github is two years out of date. Is there somewhere I can get the source and make a pull request?
[21:38] <lazyPower> skylerberg: https://code.launchpad.net/~openstack-charmers
[21:38] <lazyPower> any of the /next branches are the current dev focus and where you want to make merge proposals against
[22:42] <skylerberg> lazyPower: Thanks for pointing me to the repo. I tried deploying nova-compute based on the latest code and it failed http://paste.ubuntu.com/12138183/.
[22:47] <lazyPower> skylerberg: i would certainly file that as a bug, it seems something changed in /next thats causing a problem. (is this unmodified /next, or was it patched w/ the modifications?)
[22:48] <skylerberg> Perhaps this is because I am running it in a container and it wants to install kvm.
[22:48] <lazyPower> thats indeed possible.
[22:48] <lazyPower> fwiw - you can us ea KVM based local provider and it will be slow (hypervisor in hypervisor) but should complete without issue
[22:49] <lazyPower> https://jujucharms.com/docs/devel/config-KVM
[22:50] <skylerberg> lazyPower: Thanks. I think I can get around it by just marking the issue as resolved. I am really just trying to see the effect on the config file.