[01:20] marcoceppi: around? === menn0 is now known as menno0-afk === urulama is now known as uru-LJ [05:51] lazyPower, designated: I do have a plan to work on that this cycle - we had some work done for a customer to enable this but I was not happy it was up for general use. [05:52] I have a proposed reference network topology and approach - basically you would be able to specify which network is used for each type: [05:52] admin-network: 10.5.5.0/24 [05:52] for example [05:52] and the charm will figure out which configured network interface should be used for internal/admin traffic [05:53] there is already stuff in charm-helpers to discover network interfaces by cidr [05:53] I think its still up to MAAS/juju to actually configure the nics... the charms will not do that === CyberJacob|Away is now known as CyberJacob [06:44] designated lazyPower jamespage :: that's functionality we also like to have in the openstack charms. We are working with the openstack charms and for example we have a VLAN interface where we want the tenant/neutron traffic to go/flow over [06:45] Besides that, in our previous (pre-juju) deployment, we used vlan for the tenant networks. We would love to have that possibility in the charms. [06:47] As i mentioned yesterday on this channel, a colleage started working on the charms (for some other things we need) and when he has working code, he will submit it [06:48] Mosibi, sounds good - I have a design in mind for a reference network architecture based on best practices I've seen [06:49] Mosibi, once I have a little more polished I'll circulate it [06:49] Mosibi, juju + MAAS are due to grow first class support for managing network connectivity which will help alot [06:50] Mosibi, configuring the charms themselves is not actually that hard - the work done before was implemented on a deployment with bonded 10G nics, with traffic separation via VLAN === CyberJacob is now known as CyberJacob|Away === vladk|offline is now known as vladk === gmb`` is now known as gmb [10:52] Freshly bootstrapped local provider with 1.18.4, I get a happy machine 0, status etc. working. But I can't deploy a service. The new machine just hangs 'pending', and there are no logs. [10:53] Any hints on diagnosing this further? [10:53] The jujud process is regularly kicking in chewing a little CPU, but no idea what it is doing. [10:59] Looks like the machine is created, but ssh is failing. All my keys being refused, including ~/.juju/ssh/juju_id_rsa === vladk is now known as vladk|offline === vladk|offline is now known as vladk === vladk is now known as vladk|offline [11:45] machine-0: no kvm containers possible ? === vladk|offline is now known as vladk === psivaa is now known as psivaa-lunch [12:21] So for those reading along at home, ufw had been enabled and my lxc stuff on 10.0.3.* was unable to talk to my main lxc IP, including the log messages. [12:50] jamespage: thats awesome to hear. Thank you for the follow up [12:51] stub: ah, good catch. I haven't heard of any UFW based issues in a bit. Looks like its back to haunting around and stirring up trouble. [13:04] stub: did you see jorge's fix for rsyslog-forwarder? https://code.launchpad.net/~niedbalski/charms/precise/rsyslog-forwarder/lp-1323627/+merge/221903 [13:05] yeah. I was copying from the charm, as it seemed to be the only place the syslog interface was documented [13:07] I'd review it but I have no idea what the double @@ or lack thereof would do [13:08] stub: i'm looking at it myself - it appears to just change the port on the destination [13:08] from 10514 to 514 [13:11] niedbalski_: any light wrt the @@ in the config change proposed for rsyslog-forwarder? === tedg is now known as ted === psivaa-lunch is now known as psivaa === ted is now known as tedg [13:32] lazyPower: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/573461 , fixed in utopic but trouble for me [13:32] <_mup_> Bug #573461: UFW blocks libvirt bridged traffic

[13:33] bizarre. Apparently I'm running the devel release [13:33] i thought i was on 1.18.4, nope. 1.19.3 [13:34] lazyPower, ,@host is udp, @@host is TCP, now by default is forwarding to UDP (ref: http://www.rsyslog.com/doc/rsyslog_conf_examples.html) [13:34] ahhhhh ok. [13:38] I knew that. === alexisb_out is now known as alexisb [14:41] stub: haha :) [14:42] that's amusing. I got bit by that earlier today too. knowing something but not knowing it. [14:44] i am installing havana openstack on Ubuntu 12.04 using juju. How do I find the compatible ceph version [15:14] does a juju charm install the actual package or is it done outside the charm? [15:17] khuss: the charm is responsible for installing any packages required to run the service. [15:18] lazyPower: the cs:precise/ceph is installing the very old version of ceph.. [15:19] lazyPower: the charm is the latest though... i;m wondering how to upgrade the ceph itself [15:19] lazyPower: the readme doesn;t say what version of the ceph is installed by this charm [15:19] khuss: it may be prudent to open a bug against the precise ceph charm to have the ceph version updated. [15:19] I know the openstack charmers are really responsive on the bug tracker. [15:20] lazyPower: is there a way to manually update the ceph version [15:21] khuss: it's recommended that you use the charm to perform any upgrades, to keep support consistent. If a newer version of ceph breaks the charm functionality, teh charm itself would need to be upgraded. I'm not that familiar with ceph, so its hard for me to say what the implications are with just cowboying an update. [15:21] lazyPower: are you aware about any irc channel for juju openstack charms [15:24] khuss: they are in #juju [15:24] lazyPower: if I can find them :) [15:26] niedbalski_: approved LP221903 [15:39] would a charm be the correct unit to release an app? I say "app" in the sense that "services" deployed with juju might be mongo or hadoop where as the "app" would be an application that is used by the organization and is their code. [15:40] * elarson is just starting with juju and trying to understand where it fits [15:44] lazyPower: i've a charm in a weird state. there are no machines associated it with. juju destroy-service doesn't remove it so I'm not able to deploy the new charm. here is the output from juju status: ceph: charm: cs:precise/ceph-26 exposed: false life: dying relations: client: - glance [15:55] khuss: is there a dependent service that's related to ceph in an error state? [15:55] if hook relations fail, the charm will be stuck in a dying state pending you resolving them. [16:00] lazyPower: well there is a broken relationship but it is almost like a deadlock. Both services can't be killed [16:01] khuss: have tried resolving on the service its related to? [16:01] juju resolved service/# [16:01] thats kind of risky if you're in ap roduction setup - as it may leave behind some traces that the charms departed hook performs. YMMV if you go this route. [16:01] it would probably be better to debug-hooks into the service and re-execute the hook to determine why its failing if its a production system. [16:04] lazyPower: i tried resloved but it didn't work.. may be I will do juju destroy-environment and start all over [16:32] jamespage, That sounds awesome. You have already figured it all out or you'll be working on it? I'm interested in whatever information you can provide. [16:34] i am facing a problem with config-changed and relation-chabged, problem in i have a template in this template a variable is ip, this ip is dependent on relation-changed, when relation happen it comes from other service, but that template has other variable which are comes from config.yaml so if i change config after relation-changed ip will change to default 'localhost' and relation will bw broken, how do i fix this? [16:35] lazyPower: hi [16:36] marcoceppi: hi [16:44] themonk: you need to set some kind of a sentinel value, like touch $CHARM_DIR/relation-lock, and check for the presence of that sentinel to determine of the value should be updated. [16:45] thats one method, but this makes me pause to ask "Why are you exposing a configuration value that comes from a third party? Shouldn't this by definition be opinionated in the point its nto exposed to the user and only updated via relationship?. [16:48] lazyPower: my problem is elation related variables and config related variables both are in same config file template :( i cant change it [16:49] lazyPower: about the sentinel value method, in this way after relation happen, i cant change config values ryt [16:51] themonk: you're giving me a catch 22 that your config variable is overriding the incoming value from a remote service. You either need to unexpose teh configuration variable, or change the relationship variable. it's 'OK' to be opinionated in charm development. [16:51] we encourage it, as its spoon feeding the end user best practices with their deployments. [16:52] but without further context, i cant comment - if you have a branch to look at i'll be more than happy to review whats happening and make a proper suggestion. [16:53] themonk: I think you need to store the relation variables in a file in relation-changed [16:53] and then generate the template using that file and the config values [16:54] and you can do that from both relation-changed and config-changed, and they both have all the values that they need [16:54] unless you are talking about the relation value being for the same thing as one of the config values [16:55] in which case it will be more work to get the behaviour you want [16:55] lazyPower: i cant show my code right now :( [16:58] james_w`: i concidered this option too like make a json file :) [16:58] Hello [16:59] i have a question, where is store information what hook is executed after start hook? === salgado_ is now known as salgado [17:04] Egoist: depends on the next action that is triggered. The typical hook flow during deployment: install => config-changed => start -- afterwords, its dependent on the action that is taken. It could be any *-relation-joined, config-changed, or upgrade-charm hooks that are fired. [17:04] or stop, if the service is destroyed. [17:09] is there any imformation stored about what happend when you deploy more than 1 instance? [17:09] i mean something like this: [17:09] juju deploy mysql -n 3 [17:10] Egoist: after the traditional deployment hook sequence is executed, the peer-relationship hook will be triggered on all 3 instances. [17:11] is it possible to make changes in peer-relationship? [17:11] can you refine that a bit more? as 'make changes' is kind of open and broad, and could mean many things. [17:14] i don't want to make relationship beetween this mysql instances that I mentioned earlier [17:14] I just want to have 3 separate instance [17:15] Egoist: to that end, it would be better to deploy them as juju deploy mysql "alias" [17:15] they then become independent service units, without a peering relationship. [17:16] ok, i get it [17:16] and can be independently scaled/managed [17:16] may I ask one more question [17:16] sure [17:17] why juju sometimes don't have relation in list, even if relation-set was executed? Is it possible that relation-set is return false because few instances try to executed this command in the same time? [17:20] Egoist: do you have an example? i'm not sure what you're saying. [17:20] s/saying/asking/ [17:24] when i want to try make a relation beetwen two instance, and each instance execute relation-get and it's return nothing [17:29] I'm just curious and couldn't find backstory on the decision to move from lp to github, anyone know where it took place? [17:29] gQuigs: for juju-core? [17:30] marcoceppi: yup [17:30] Egoist: relation-get returning nothing means it wasn't set on the other side. During which hook is this call being executed? It should be the relationship-changed hook and not the joined, as joined is pre-setup work like archiving an existing database provider or installing pre-req packages. [17:30] gQuigs: it's been decided for a few months. Discussion would have happened on juju-dev mailing list [17:31] marcoceppi: yea, I've been looking over the mailing list... went back to oct 2013 [17:32] ohh, ok, i get it. Thank you very much [17:32] :_ [17:32] :) [17:32] gQuigs: ask in #juju-dev they should be able to enlighten [17:32] marcoceppi: ok, thanks! [17:38] ... and all my stuff is stuck on pending today [17:41] jcastro: stub ran into an issue last night with UFW blocking his deployments. [17:41] have you disabled UFW to validate that's not the over-arching issue? his was specific to 1.18.4 i believe, as i'm on 1.19.x and haven't seen teh same behavior. [17:41] my ufw is off [17:42] lazyPower: I've filed a bug regarding the ceph issue we are seeing - https://bugs.launchpad.net/juju-core/+bug/1326466 [17:42] <_mup_> Bug #1326466: Openstack install failing because of outdated Ceph charm? [17:43] khuss: brilliant. thanks for the bug report! [17:43] jcastro: boo :( [17:55] $ charm get ntp [17:55] (...) [17:55] bzr: ERROR: Transport operation not possible: http does not support mkdir() [17:55] really, no anonymous charm get? [17:59] git clone https://github.com/charms/ntp.git [17:59] :) [17:59] ahasenack, that sucks though, can you file a bug on charm-tools? [18:00] ok [18:02] jcastro: I would need the ntp charm to be available on trusty, what are the steps to get that done? [18:03] ahasenack, currently, ask marcoceppi to push it to trusty [18:04] marcoceppi: hi, are you in a position to do that? ^^^ [18:05] ahasenack: have you tested it on trusty? [18:06] about to [18:06] hitting issues with charm get, and now a overzealous firewall that doesn't allow connections to bazaar.lp.net [18:07] marcoceppi: I can give both (ntp and ntpmaster) a shot and report back, then you can promote them to trusty if no blockers are found? Is that more or less the procedure? [18:07] writing tests for it is the fastest way to get it in to trusty [18:07] oh, that [18:07] * marcoceppi looks at the charm [18:09] I'd say it's a bit lacking in the unit test area [18:28] ahasenack, yeah that's why we haven't mass-moved the charm store to trusty [18:28] still, it says "recommended" in the charm store ;) [18:30] precise is recommended [18:34] Hello, I've a question about the Bundle import using charms that are local, when I try to import the bundle I'm getting errors on invalid configs. For example: An error occurred while deploying the bundle: Invalid config charm precise/true-node-app-1 app_url=https://github.com/zarffg/prototype Invalid config charm precise/true-node-app-1 app_name=prototype Invalid config charm precise/true-node-app-1 app_port=3000 === roadmr is now known as roadmr_afk [19:22] nooky, can you pastebin your bundle somewhere? [19:23] jcastro: yes, wait a minute === roadmr_afk is now known as roadmr [19:30] jcastro: http://pastebin.com/PPAdNe8P [19:32] I have " " around my charm: local/blah stuff [19:33] I don't think that's your problem though [19:33] marcoceppi, ideas? ^ [19:33] jcastro: yes, I've tried with double quotes around the charm definition, but isn't working [19:33] nooky: what is 'bundle import'? How are you importing? [19:34] rick_h_: via juju gui [19:34] nooky: the gui doesn't support deploying bundles with local charms currently [19:34] oh [19:35] rick_h_: juju deployer ? [19:35] or quickstart ? [19:35] nooky: yep [19:35] fine [19:35] let me check [19:35] sorry, juju has an issue we need to correct for that to work properly from the GUI at the moment [19:52] rick_h_: I've tried to deploy via juju-deployer and didn't work, the errors are the same that importing using juju-gui [19:53] nooky: ok, well at least now have an idea that it's something that will work once the issue is worked out. [19:53] rick_h_: i need to use double quotes to charm and options definition? [19:55] nooky: can try it. Not sure. It fussed about all three config options. Stuff like port shouldn't need the quotes, but it complained about that as well. [19:56] does those cross refence to the charm itself exactly? [19:57] rick_h_: look at this: https://bugs.launchpad.net/juju-deployer/+bug/1297940 [19:57] <_mup_> Bug #1297940: deployer does not support a local: prefixed charm url.

[20:00] nooky, its a different syntax [20:01] nooky, that deployer file you pasted is wrong in a few ways [20:01] nooky, s/charm: local:precise/true-varnish-0/charm: true-varnish [20:01] you can also point to github repos as the charm branch [20:03] hazmat: ok, thanks, I'll try to replace the charm definition in the bundle file [20:03] nooky, charm: should do the trick [20:03] great [20:08] hazmat: using the way charm: , I'm getting this error, 2014-06-04 20:06:58 Invalid charm specification true-varnish [20:16] hazmat: Is possible that the errors are because I'm using a new environment and not the environment where I've exported the Bundle? [20:17] nooky, well with local charms you have to access to them... locally there not in the bundle [20:17] gui exports of local charms are not functional [20:18] nooky, i'd also toss a series: precise right under envExport [20:19] you can specify branch: https://github.com/name/repo.git for the charms to pull them straight from vcs [20:19] hazmat: ok ok [20:20] so, can i define in this way? charm: https://github.com/name/repo.git [20:21] nooky: not quite [20:21] you would have to change charm to branch [20:21] marcoceppi: ok, thanks [20:41] * hazmat signs off === vladk is now known as vladk|offline === menno0-afk is now known as menn0 [21:03] a mysql charm that sets up blank databases with no tables === wallyworld is now known as Guest56344 === wallyworld is now known as Guest68975 === sebas538_ is now known as sebas5384