[01:52] <yuanyou> jamespage: Hi , as we known, neutron-gateway charm have a config "ext-port", and i want get the "ext-port" value in my own charm onos-controller, how should i do ? thanks
[09:31] <deanman> Is it possible to customize the look and feel of juju-gui charm to your needs?
[10:41] <apuimedo> jamespage: you created a new merge proposal for nova-cloud-controller besides https://code.launchpad.net/~celebdor/charms/trusty/nova-cloud-controller/liberty/+merge/283709?
[10:41] <apuimedo> ?
[10:44] <jamespage> apuimedo, sorry - branch hell
[10:45] <jamespage> deleted not
[10:45] <jamespage> now
[10:45] <apuimedo> ;-)
[10:45] <apuimedo> yes, it's just that I have some extra branches for backports I do
[10:45] <apuimedo> since when somebody wants to try it I usually backport the changes into stable
[10:46] <jamespage> apuimedo, I know we discussed this but I can't remember the rationale for not having the nova-metadata service co-located with the neutron-dhcp and neutron-metadata agents in neutron-agents-midonet like we have in the neutron-gateway charm?
[10:46] <jamespage> rather than using the one provided by the nova-cc service
[10:46] <apuimedo> jamespage: We did :-)
[10:47] <apuimedo> now that neutron-agents-midonet is split from neutron-api I may re-evaluate in a future version
[10:47] <apuimedo> but the deployment recommendation in midonet is usually like that
[10:48] <apuimedo> jamespage: you suggest adding some nova config in neutron-agents-midonet
[10:48] <apuimedo> so that it runs neutron-dhcp neutron-metadata and nova-api-metadata, right?
[10:49] <jamespage> apuimedo, well i have two ideas - one to run the nova-metadata service on neutron-agents-midonet and drop the shared-secret stuff across both charms - each neutron-metadata agents just talks to localhost with a unit local secret
[10:49] <jamespage> so like you say
[10:49] <jamespage> or
[10:50] <apuimedo> well, they wouldn't even need a secret setting then
[10:50] <jamespage> apuimedo, indeed
[10:50] <jamespage> well you do but just for the local neutron-nova comms
[10:50] <jamespage> no configuration at charm level.
[10:50] <jamespage> apuimedo, that's what neutron-gateway does today...
[10:50] <apuimedo> jamespage: IIRC, if you leave it blank it also works :P
[10:50] <jamespage> really?
[10:51] <apuimedo> that's what I saw in some of our cloud configs
[10:51] <jamespage> apuimedo, that sounds like a security vulnerability to me
[10:51] <apuimedo> well, I'd say it is an option to disable the "secure" comm
[10:52] <apuimedo> I opted to keep it in my charms though
[10:52] <jamespage> # If authentication token is set, authenticate
[10:52] <jamespage> ha!
[10:52] <apuimedo> ;-)
[10:52] <apuimedo> precisely
[10:52] <jamespage> so only auth is someone actually set the value
[10:52] <apuimedo> jamespage: do you know how much of a nova.conf chunk I'd have to add if I want to give it a shot?
[10:52] <jamespage> apuimedo, I know exactly
[10:53] <apuimedo> :-)
[10:53] <jamespage> apuimedo, nova needs rabbitmq and the keystone auth data as the neutron agents need - so no new interfaces...
[10:54] <jamespage> apuimedo, something like - http://paste.ubuntu.com/14876487/
[10:54] <jamespage> that's pulled from neutron-gateways kilo template for nova
[10:54] <apuimedo> right
[10:55] <apuimedo> so I'll give it a shot later
[10:55] <apuimedo> I'm now fixing the linting and unit tests of midonet-api
[10:55] <apuimedo> thanks for the template
[10:56] <jamespage> apuimedo, how about I do that for you now? I'd rather work that than have the manual configuration of shared secret in nova-cc
[10:56] <jamespage> apuimedo, I can test locally
[11:02] <jamespage> apuimedo, are you worried about upgrades to charms atm?
[11:05] <apuimedo> well, that would be nice
[11:05] <apuimedo> :-)
[11:37] <jamespage> apuimedo, ok working with kilo ok
[11:37] <jamespage> apuimedo, I'll need to re-deploy to test juno
[11:38] <apuimedo> cool
[11:47] <jamespage> apuimedo, actually
[11:47] <jamespage> juju create-model midonet-juno
[11:47] <jamespage> juju deploy midonet-juno.yaml
[11:48] <jamespage> \o/
[11:48] <jamespage> hurrah for 2.0 models
[11:49]  * apuimedo wants models
[11:49] <apuimedo> why didn't I start working on Juju now instead of before :'(
[11:50] <apuimedo> it's starting to get much easier
[12:04] <jamespage> apuimedo, apparently my laptop is not up for that much stuff grabbing memory...
[12:04] <jamespage> ETOMUCHJAVA
[12:04] <jamespage> lol
[12:04] <apuimedo> jamespage: xD
[12:05] <apuimedo> ETOMUCHJAVAANDPOSSIBLYSCALA
[12:05] <jamespage> lol
[12:05] <apuimedo> you need like 10G for the whole openstack plus zk+cass+midonet agents
[12:05] <jamespage> and maybe a bit of auto config by mysql grabbing anything left..
[12:05] <jamespage> x2
[12:07] <jamespage> apuimedo, OMG that's pretty much the zookeeper charm I wrote many years ago
[12:07] <jamespage> apuimedo, well it still works - nice to know :-)
[12:07] <apuimedo> jamespage: :-)
[12:08] <jamespage> apuimedo, there are more recent choices from the big data team:
[12:08] <jamespage> https://jujucharms.com/apache-zookeeper/trusty/1
[12:08] <apuimedo> jamespage: shouldn't this be promoted to cs:trusty/zookeeper then?
[12:09] <jamespage> apuimedo, tricky
[12:09] <apuimedo> or at least cs:xenial/zookeeper
[12:09] <apuimedo> for backwards compatibility
[12:09] <jamespage> cory_fu, ^^ what do you think
[12:09] <jamespage> I suspect that moving from zookeeper -> apache-zookeeper is not a supported charm upgrade path
[12:45] <apuimedo> jamespage: why did you move the merge proposal from needs review to wip?
[12:45] <apuimedo> without having it run yet, it looks good
[12:45] <jamespage> apuimedo, cause I'm still testing it - I think its ok - just verifying with juno
[12:45] <apuimedo> s/it run/run it/
[12:46] <apuimedo> cool
[12:46] <apuimedo> your RAM will suffer
[12:48] <jamespage> I have some lxd/cloud-init oddisms I have  to deal  with until a bug it resolved
[13:31] <vaewyn> Hey all...  found a bunch of environment variables but have yet to find one with the charms name in it... is there such a beast I can use in the hooks? Wanting one of the hooks to act differently depending on if the charm is directly deployed... or is used as a layer for another charm
[14:18]  * arosales taking a first look at the LTE eNB charms in the review queue
[14:31] <arosales> vaewyn: hello. I may not understand your question, but you can't use a charm as a layer for another charm.  You have to create an explicit layer that is used to build a charm.
[14:33] <arosales> So I can't use https://jujucharms.com/mysql/ as a layer for another charm. If you wanted to build a charm using layers you would need to include a layer from http://interfaces.juju.solutions/
[14:34] <arosales> vaewyn: ^ hth
[14:36] <vaewyn> arosales: I guess maybe I should say more what I am trying to accomplish then...  I have a charm currently that sets up environment and downloads a central codebase... then I have subordinate charms to deploy various apps off it it... was trying to reform all that into layers so I can still reuse the codebase charm in each application but end up with a single charm to deploy made of layers instead
[14:39] <vaewyn> arosales: the codebase charm has no relations or anything really... it's just a "get this crud on the disk" charm
[14:39] <vaewyn> arosales: I'm a very newb to this so I may be totally heading the wrong way but this path looked interesting
[14:51] <vaewyn> arosales: reading more... now I see what you mean :)  Thanks for the direction
[15:02] <arosales> vaewyn: your approach seems very reasonable. It sounds like what we call a "framework" charm, ie rails or java
[15:04] <arosales> but for that "codebase charm" I think you just need to create a layer.
[15:05] <arosales> ref = https://jujucharms.com/docs/devel/developer-layers && https://pythonhosted.org/charms.reactive/
[15:05] <arosales> vaewyn: ^
[15:11] <vaewyn> arosales: It seems kindof inferred...  but are layers always processed/completed in the order of inclusion? ie... are the reactive portions just for interaction with other charms or for internal change events also as each layer gets slapped together?
[15:17] <arosales> vaewyn:  layers give you 2 basic pieces of functionality to build a final charm.
[15:18] <arosales> 1. "layers" give you the ability to react to "states" to model how the service, ie code how the internal events are handled
[15:18] <arosales> 2. "interfaces" give you the ability to easily react to "state" when communicating with other applications (charms)
[15:18] <arosales> vaewyn: ^
[15:22] <arosales> btw, for reference here is the ruby layer http://interfaces.juju.solutions/layer/openjdk/ and the java layer = http://interfaces.juju.solutions/layer/openjdk/
[15:24] <vaewyn> arosales: ahh... those are much cleaner.. the apache-php layer seems to blur those lines you stated a bit... so I was a bit confused
[15:27] <arosales> ya apache-php may blur the lines a little from "run-time" and app
[15:27] <arosales> vaewyn: I hope that helps, let us know how your charming goes
[15:27] <vaewyn> arosales: does yes... thank you! and will do
[15:29] <jamespage> apuimedo, ok so that works on juno as well
[15:29] <apuimedo> great jamespage
[15:29] <jamespage> apuimedo, I love the fact that java is so sensitive for DNS crappy ness
[15:29] <apuimedo> xD
[15:29] <jamespage> apuimedo, https://bugs.launchpad.net/juju-core/+bug/1540061
[15:29] <mup> Bug #1540061: juju 2.0 alpha + local LXD provider: dns hostname inconsistency <juju-release-support> <lxd> <juju-core:Triaged> <https://launchpad.net/bugs/1540061>
[15:30] <jamespage> apuimedo, until the first dhcp lease renewal everything is called 'ubuntu' in the dnsmasq instance...
[15:30] <apuimedo> jamespage: also, alai reported some lxc containers in maas env not getting "search domainname" in /etc/resolv.conf
[15:30] <apuimedo> which is problematic
[15:31] <apuimedo> jamespage: so I'll merge your proposal
[15:31] <jamespage> apuimedo, that sounds like old MAAS behaviour to me - I'' check
[15:31] <apuimedo> jamespage: I didn't experience it
[15:31] <apuimedo> it was on oil
[15:31] <jamespage> apuimedo, anyway - if you're ok with my changes to neutron-agents-midonet, lets drop https://code.launchpad.net/~celebdor/charms/trusty/nova-cloud-controller/liberty/+merge/283709
[15:31] <jamespage> its really not needed any longer \o/
[15:32] <alai> jamespage, apuimedo : it's maas 1.9 we are using
[15:34] <apuimedo> jamespage: there's the part of selecting the libvirt vif driver
[15:34] <jamespage> apuimedo, I think that may only be required in the nova-compute units
[15:34] <apuimedo> yeah, I thought so too
[15:34] <jamespage> I've been running with stable n-cc charm and its working fine...
[15:35] <apuimedo> alright, I'll abandon the merge
[15:38] <jamespage> apuimedo, awesome
[15:41] <apuimedo> jamespage: I'll never get used to a brit saying awesome instead of brilliant :-)
[15:44] <apuimedo> jamespage: you had to manually add the compute hosts to the tunnel zone, right?
[15:45] <jamespage> apuimedo, nope - they all got added automatically
[15:45] <jamespage> \o/
[15:46] <jamespage> apuimedo, I had to work around that bug I detailed with a quick dhclient -r && dhclient before stuff got installed but apart from that 0 hacks...
[15:46] <jamespage> apuimedo, instances are getting dhcp IP addresses and can access the metadata service fine
[15:46] <jamespage> apuimedo, still can't get the external network bit going...
[15:46] <apuimedo> ok
[15:47] <jamespage> but that may be my test right
[15:47] <jamespage> rig being a bit bleeding edge...
[15:47] <apuimedo> well, I'm fixing the midonet-api unit tests and changing how the midonet-api registers the hosts into the tunnel zone
[15:47] <apuimedo> to use contrib.network.ip to get the ip of the compute node
[15:48] <apuimedo> and get the uuid from the relation
[15:48] <apuimedo> because otherwise it doesn't work with maas with dns domains :(
[15:52] <jamespage> apuimedo, ack
[15:52] <jamespage> apuimedo, I'll post a summary of TODO to the bug
[15:52] <apuimedo> very well ;-)
[15:52] <apuimedo> I am now removing the split branch
[15:52] <apuimedo> and leaving only /trunk
[16:47] <magicaltrout> alright chaps, charm publish, does that stuff work for us minions if I'm running the PPA?
[16:47] <magicaltrout> or do I have to wait?
[16:48] <jrwren> magicaltrout: it works
[16:48] <magicaltrout> boom!
[16:48] <magicaltrout> cool
[17:13] <jhobbs> is thre some way to tell juju which interfaces to associate with containers it creates?
[17:13] <jhobbs> we're using MAAS 1.9's vlan interface configuration and want containers to be connected to one or more interface
[17:13] <jhobbs> via a bridge
[17:13] <jhobbs> MAAS can't create the bridge - can juju do it?
[17:13] <jhobbs> this is the MAAS bug for creating the bridge https://bugs.launchpad.net/maas/+bug/1512187
[17:14] <mup> Bug #1512187: ability to create bridges on MAAS nodes for use without Juju <MAAS:Triaged> <https://launchpad.net/bugs/1512187>
[18:46] <magicaltrout> in actions, can you set default parameter values?
[18:46] <magicaltrout> of course in the action I can test to see whether its set or not, but if a sensible default was set if it wasn't passed in by the user,it would save me writing check logic
[19:30] <handicraftsman> Hello
[19:31] <handicraftsman> How i can install juju on my debian sid?
[19:32] <handicraftsman> It does not supports ppas
[19:33] <jrwren> handicraftsman: you can use the long form of ppa added to sources.list
[19:37] <handicraftsman> I'll choose xenial version, because it's not finished and ubuntu is always build on debian sid
[19:37] <jrwren> handicraftsman: go here: https://launchpad.net/~juju/+archive/ubuntu/devel/  expand the green "Technical details about this ppa" link and for sid, i'd recommend picking wily, but YMMV.  You'll need to run `sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys C8068B11 `
[19:38] <handicraftsman> I'll just install it on my linux lite laptop xD
[21:11] <marcoceppi> magicaltrout: yes, you can define a default
[21:15] <magicaltrout> marcoceppi: thanks
[21:15] <magicaltrout> somehow this hotel's wifi is worse than the other one, so testing this stuff is taking time! :P
[21:24] <marcoceppi> magicaltrout: boo
[21:25] <marcoceppi> magicaltrout: now that everyone is gone it's rather peppy here ;)
[21:25] <magicaltrout> hehe
[21:25] <magicaltrout> lack of porn being viewed......
[21:38] <jrwren> i'm roughly following the vanilla layers walkthrough and build says it can't find the layer i'm using.
[21:38] <jrwren> Does the walk through skip a part where I download layers to INTERFACE_PATH and LAYER_PATH?
[21:40] <marcoceppi> jrwren: no, you don't need to download layers
[21:40] <marcoceppi> jrwren: can you pastebin the output
[21:40] <marcoceppi> jrwren: (layers are fetched from the index)
[21:41] <jrwren> http://pastebin.ubuntu.com/14882887/
[21:42] <jrwren> let me check my charmtools version. maybe i didn't re-add ppa after upgrading to wily or something stupid.
[21:42] <marcoceppi> jrwren: yeah, was about to ask
[21:42] <marcoceppi> jrwren: charm version should do it
[21:42] <jrwren> 1.11.1
[21:43] <marcoceppi> that's latest
[21:44] <marcoceppi> jrwren: is your layer somewhere?
[21:44] <jrwren> marcoceppi: no, its brand new.
[21:44] <marcoceppi> jrwren: could you put it somewhere :)
[21:44] <marcoceppi> jrwren: also charm build -l DEBUG will be helpful
[21:45] <jrwren> http://pastebin.ubuntu.com/14882909/
[21:46] <marcoceppi> jrwren: layer.yaml file?
[21:47] <jrwren> includes: ['layer:nodejs', 'interface:mongodb']
[21:47] <jrwren> marcoceppi: https://github.com/jrwren/parse-server-example/tree/no-go-layers
[21:48] <marcoceppi> jrwren: you have a few problems, not related
[21:48] <marcoceppi> I don't think - in reactive file paths will work because of how they're imported
[21:48] <jrwren> marcoceppi: tons, i'm sure :)
[21:50] <marcoceppi> jrwren: works for me. Unset your LAYER_PATH and INTERFACE_PATH
[21:50] <marcoceppi> if there's nothing in there you don't need to set
[21:50] <jrwren> same results.
[21:52] <marcoceppi> http://paste.ubuntu.com/14882948/
[21:52] <jrwren> amazing
[21:55] <marcoceppi> this is what it should do jrwren http://paste.ubuntu.com/14882969/
[21:56] <marcoceppi> jrwren: does http://interfaces.juju.solutions load for you?
[21:56] <jrwren> marcoceppi: yes, i even just used curl to make sure it loads from the remote system on which I'm writing this
[22:01] <jrwren> marcoceppi: i added some debugging, i get 'build: fetch FetchError:No fetcher for url: layer:nodejs'
[22:03] <jrwren> indeed there is no layer fetcher
[22:04] <marcoceppi> jrwren: did you ever pip install charmtools?
[22:05] <jrwren> marcoceppi: not system wide. Maybe in a venv someplace, but that venv isn't active.
[22:05] <marcoceppi> ack
[22:05] <marcoceppi> otp, brb
[23:10] <jrwren> marcoceppi: tried on a different system, can confirm its something wrong with that system.
[23:10] <jrwren> marcoceppi: thanks for walking me through.