=== marcoceppi_ is now known as marcoceppi === wolverin_ is now known as wolverineav [01:52] 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] Is it possible to customize the look and feel of juju-gui charm to your needs? [10:41] 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] ? [10:44] apuimedo, sorry - branch hell [10:45] deleted not [10:45] now [10:45] ;-) [10:45] yes, it's just that I have some extra branches for backports I do [10:45] since when somebody wants to try it I usually backport the changes into stable [10:46] 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] rather than using the one provided by the nova-cc service [10:46] jamespage: We did :-) [10:47] now that neutron-agents-midonet is split from neutron-api I may re-evaluate in a future version [10:47] but the deployment recommendation in midonet is usually like that [10:48] jamespage: you suggest adding some nova config in neutron-agents-midonet [10:48] so that it runs neutron-dhcp neutron-metadata and nova-api-metadata, right? [10:49] 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] so like you say [10:49] or [10:50] well, they wouldn't even need a secret setting then [10:50] apuimedo, indeed [10:50] well you do but just for the local neutron-nova comms [10:50] no configuration at charm level. [10:50] apuimedo, that's what neutron-gateway does today... [10:50] jamespage: IIRC, if you leave it blank it also works :P [10:50] really? [10:51] that's what I saw in some of our cloud configs [10:51] apuimedo, that sounds like a security vulnerability to me [10:51] well, I'd say it is an option to disable the "secure" comm [10:52] I opted to keep it in my charms though [10:52] # If authentication token is set, authenticate [10:52] ha! [10:52] ;-) [10:52] precisely [10:52] so only auth is someone actually set the value [10:52] 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] apuimedo, I know exactly [10:53] :-) [10:53] apuimedo, nova needs rabbitmq and the keystone auth data as the neutron agents need - so no new interfaces... [10:54] apuimedo, something like - http://paste.ubuntu.com/14876487/ [10:54] that's pulled from neutron-gateways kilo template for nova [10:54] right [10:55] so I'll give it a shot later [10:55] I'm now fixing the linting and unit tests of midonet-api [10:55] thanks for the template [10:56] 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] apuimedo, I can test locally [11:02] apuimedo, are you worried about upgrades to charms atm? [11:05] well, that would be nice [11:05] :-) [11:37] apuimedo, ok working with kilo ok [11:37] apuimedo, I'll need to re-deploy to test juno [11:38] cool [11:47] apuimedo, actually [11:47] juju create-model midonet-juno [11:47] juju deploy midonet-juno.yaml [11:48] \o/ [11:48] hurrah for 2.0 models [11:49] * apuimedo wants models [11:49] why didn't I start working on Juju now instead of before :'( [11:50] it's starting to get much easier [12:04] apuimedo, apparently my laptop is not up for that much stuff grabbing memory... [12:04] ETOMUCHJAVA [12:04] lol [12:04] jamespage: xD [12:05] ETOMUCHJAVAANDPOSSIBLYSCALA [12:05] lol [12:05] you need like 10G for the whole openstack plus zk+cass+midonet agents [12:05] and maybe a bit of auto config by mysql grabbing anything left.. [12:05] x2 [12:07] apuimedo, OMG that's pretty much the zookeeper charm I wrote many years ago [12:07] apuimedo, well it still works - nice to know :-) [12:07] jamespage: :-) [12:08] apuimedo, there are more recent choices from the big data team: [12:08] https://jujucharms.com/apache-zookeeper/trusty/1 [12:08] jamespage: shouldn't this be promoted to cs:trusty/zookeeper then? [12:09] apuimedo, tricky [12:09] or at least cs:xenial/zookeeper [12:09] for backwards compatibility [12:09] cory_fu, ^^ what do you think [12:09] I suspect that moving from zookeeper -> apache-zookeeper is not a supported charm upgrade path [12:45] jamespage: why did you move the merge proposal from needs review to wip? [12:45] without having it run yet, it looks good [12:45] apuimedo, cause I'm still testing it - I think its ok - just verifying with juno [12:45] s/it run/run it/ [12:46] cool [12:46] your RAM will suffer [12:48] I have some lxd/cloud-init oddisms I have to deal with until a bug it resolved === erlon_ is now known as erlon === bpierre_ is now known as bpierre [13:31] 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 === ddellav_ is now known as ddellav [14:18] * arosales taking a first look at the LTE eNB charms in the review queue [14:31] 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] 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] vaewyn: ^ hth [14:36] 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] arosales: the codebase charm has no relations or anything really... it's just a "get this crud on the disk" charm [14:39] arosales: I'm a very newb to this so I may be totally heading the wrong way but this path looked interesting [14:51] arosales: reading more... now I see what you mean :) Thanks for the direction [15:02] vaewyn: your approach seems very reasonable. It sounds like what we call a "framework" charm, ie rails or java [15:04] but for that "codebase charm" I think you just need to create a layer. [15:05] ref = https://jujucharms.com/docs/devel/developer-layers && https://pythonhosted.org/charms.reactive/ [15:05] vaewyn: ^ [15:11] 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] vaewyn: layers give you 2 basic pieces of functionality to build a final charm. [15:18] 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] 2. "interfaces" give you the ability to easily react to "state" when communicating with other applications (charms) [15:18] vaewyn: ^ [15:22] 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] 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] ya apache-php may blur the lines a little from "run-time" and app [15:27] vaewyn: I hope that helps, let us know how your charming goes [15:27] arosales: does yes... thank you! and will do [15:29] apuimedo, ok so that works on juno as well [15:29] great jamespage [15:29] apuimedo, I love the fact that java is so sensitive for DNS crappy ness [15:29] xD [15:29] apuimedo, https://bugs.launchpad.net/juju-core/+bug/1540061 [15:29] Bug #1540061: juju 2.0 alpha + local LXD provider: dns hostname inconsistency

[15:30] apuimedo, until the first dhcp lease renewal everything is called 'ubuntu' in the dnsmasq instance... [15:30] jamespage: also, alai reported some lxc containers in maas env not getting "search domainname" in /etc/resolv.conf [15:30] which is problematic [15:31] jamespage: so I'll merge your proposal [15:31] apuimedo, that sounds like old MAAS behaviour to me - I'' check [15:31] jamespage: I didn't experience it [15:31] it was on oil [15:31] 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] its really not needed any longer \o/ [15:32] jamespage, apuimedo : it's maas 1.9 we are using [15:34] jamespage: there's the part of selecting the libvirt vif driver [15:34] apuimedo, I think that may only be required in the nova-compute units [15:34] yeah, I thought so too [15:34] I've been running with stable n-cc charm and its working fine... [15:35] alright, I'll abandon the merge [15:38] apuimedo, awesome [15:41] jamespage: I'll never get used to a brit saying awesome instead of brilliant :-) [15:44] jamespage: you had to manually add the compute hosts to the tunnel zone, right? [15:45] apuimedo, nope - they all got added automatically [15:45] \o/ [15:46] 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] apuimedo, instances are getting dhcp IP addresses and can access the metadata service fine [15:46] apuimedo, still can't get the external network bit going... [15:46] ok [15:47] but that may be my test right [15:47] rig being a bit bleeding edge... [15:47] well, I'm fixing the midonet-api unit tests and changing how the midonet-api registers the hosts into the tunnel zone [15:47] to use contrib.network.ip to get the ip of the compute node [15:48] and get the uuid from the relation [15:48] because otherwise it doesn't work with maas with dns domains :( [15:52] apuimedo, ack [15:52] apuimedo, I'll post a summary of TODO to the bug [15:52] very well ;-) [15:52] I am now removing the split branch [15:52] and leaving only /trunk === magicalt1out is now known as magicaltrout [16:47] alright chaps, charm publish, does that stuff work for us minions if I'm running the PPA? [16:47] or do I have to wait? [16:48] magicaltrout: it works [16:48] boom! [16:48] cool [17:13] is thre some way to tell juju which interfaces to associate with containers it creates? [17:13] we're using MAAS 1.9's vlan interface configuration and want containers to be connected to one or more interface [17:13] via a bridge [17:13] MAAS can't create the bridge - can juju do it? [17:13] this is the MAAS bug for creating the bridge https://bugs.launchpad.net/maas/+bug/1512187 [17:14] Bug #1512187: ability to create bridges on MAAS nodes for use without Juju [18:46] in actions, can you set default parameter values? [18:46] 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] Hello [19:31] How i can install juju on my debian sid? [19:32] It does not supports ppas [19:33] handicraftsman: you can use the long form of ppa added to sources.list [19:37] I'll choose xenial version, because it's not finished and ubuntu is always build on debian sid [19:37] 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] I'll just install it on my linux lite laptop xD === alexisb is now known as alexisb-afk === ryotagami_ is now known as ryotagami === alexisb-afk is now known as alexisb [21:11] magicaltrout: yes, you can define a default [21:15] marcoceppi: thanks [21:15] somehow this hotel's wifi is worse than the other one, so testing this stuff is taking time! :P [21:24] magicaltrout: boo [21:25] magicaltrout: now that everyone is gone it's rather peppy here ;) [21:25] hehe [21:25] lack of porn being viewed...... [21:38] i'm roughly following the vanilla layers walkthrough and build says it can't find the layer i'm using. [21:38] Does the walk through skip a part where I download layers to INTERFACE_PATH and LAYER_PATH? [21:40] jrwren: no, you don't need to download layers [21:40] jrwren: can you pastebin the output [21:40] jrwren: (layers are fetched from the index) [21:41] http://pastebin.ubuntu.com/14882887/ [21:42] let me check my charmtools version. maybe i didn't re-add ppa after upgrading to wily or something stupid. [21:42] jrwren: yeah, was about to ask [21:42] jrwren: charm version should do it [21:42] 1.11.1 [21:43] that's latest [21:44] jrwren: is your layer somewhere? [21:44] marcoceppi: no, its brand new. [21:44] jrwren: could you put it somewhere :) [21:44] jrwren: also charm build -l DEBUG will be helpful [21:45] http://pastebin.ubuntu.com/14882909/ [21:46] jrwren: layer.yaml file? [21:47] includes: ['layer:nodejs', 'interface:mongodb'] [21:47] marcoceppi: https://github.com/jrwren/parse-server-example/tree/no-go-layers [21:48] jrwren: you have a few problems, not related [21:48] I don't think - in reactive file paths will work because of how they're imported [21:48] marcoceppi: tons, i'm sure :) [21:50] jrwren: works for me. Unset your LAYER_PATH and INTERFACE_PATH [21:50] if there's nothing in there you don't need to set [21:50] same results. [21:52] http://paste.ubuntu.com/14882948/ [21:52] amazing [21:55] this is what it should do jrwren http://paste.ubuntu.com/14882969/ [21:56] jrwren: does http://interfaces.juju.solutions load for you? [21:56] marcoceppi: yes, i even just used curl to make sure it loads from the remote system on which I'm writing this [22:01] marcoceppi: i added some debugging, i get 'build: fetch FetchError:No fetcher for url: layer:nodejs' [22:03] indeed there is no layer fetcher [22:04] jrwren: did you ever pip install charmtools? [22:05] marcoceppi: not system wide. Maybe in a venv someplace, but that venv isn't active. [22:05] ack [22:05] otp, brb [23:10] marcoceppi: tried on a different system, can confirm its something wrong with that system. [23:10] marcoceppi: thanks for walking me through.