[02:06] jcastro: still need to refactor test, they were failing with nonsense errors === mup_ is now known as mup === CyberJacob|Away is now known as CyberJacob === CyberJacob is now known as CyberJacob|Away === underyx is now known as underyx|off [11:02] hi guys, is it valid to have a charm that is subordinate of a charm that already has subordinate relation? Lets say that java charm subordinates to puppet charm while solr charm subordinates to java charm? [11:05] while java charm would be installed as soon as relation to puppet charm is defined, solr charm (subordinated to java charm) would never get installed [11:11] http://pastebin.com/Fyvq8D91 [11:14] metadata: http://pastebin.com/XXHXs1TE [11:32] what is the latest juju version available to mac os? [12:53] marcoceppi, can we sort out ~elasticsearch-charmers? They need to get a fix in for a demo. [12:53] https://code.launchpad.net/~s-matyukevich/charms/trusty/elasticsearch/elasticsearch-dns-bug-fix/+merge/239547 [12:53] need to get this one in [14:09] jcastro: i'll take a look === scuttle|afk is now known as scuttlemonkey [14:20] noodles775: ping [14:23] lazyPower: marcoceppi we need to move the elasticsearch bundle to a new name for the release. We have the flat namespace and no charm/bundle can share the same name in the user space. [14:23] lazyPower: marcoceppi what's the best way to file that/get it updated? [14:24] rick_h_: open a merge request and rename the bundle? [14:24] marcoceppi: rgr ok will do [14:24] marcoceppi: but it needs a new bzr path/etc [14:25] rick_h_: oh, it needs a bzr path? I thought just the name in the bundle needed to be fixed [14:25] but I'll create a mp into that new space and then get it promulgated I guess. [14:25] that will work for creating the new path, but we'll need to follow behind you and clean up the existing path. [14:26] i would imagine this will affect a few other bundles as well... [14:27] lazyPower: yes, right now the one that jumped out to us, as it's highlighted on some marketing pages is the ES one [14:27] lazyPower: we'll be working to get a list of all collisions and working on updating them [14:28] rick_h_: sounds good. if you could share the spreadsheet with us that would be muy bueno. [14:28] lazyPower: will do [14:45] kadams54: hatch ping, where are we at with the added services stuff feature? [14:45] rick_h_: kadams54 is finishing up the database updates from the browser handlers [14:45] the canvas renderer update code is done but breaks the gui without that branch [14:45] well - breaks the added services thing [14:45] so it's holding until his lands [14:46] then i'll likely have to do some merging and it'll be gtg [14:46] hatch and I talked some yesterday about how to handle related services [14:46] kadams54: ok, are we on track to land today then or is this going to go on into this week? [14:47] And I think (hatch, correct me if I'm wrong) we landed on me handling those related services, as far as updating their hide/fade/highlight properties correctly. [14:48] On track to land today, but it'll probably be right at EOD. [14:48] honestly, added services bar is now entering wk4 and we either need to finish it up or we need to figure out what's wrong and rethink it. We need to move on to help with the other release. [14:48] kadams54: ok, if that changes please let me know. [14:48] Will do. [16:04] Who can I add a mysql relation to more then one service without creating new databases? I would like to use the same database to multiple 'services'. Is it possible? [16:05] How* [16:19] X-warrior: i may be incorrect, but as I understand it, the mysql charm reads teh service name and will create a DB for each different service. To support that style of deployment the charm would have to be extended with another relationship type, such as shared-db. [16:19] lazyPower: I guess so, I just started using shared-db to check if it solves this problem :D [16:20] X-warrior: that looks like it will do it [16:20] as the dbname is part of the relationship. just checked the source of shared-db-relation-changed [16:21] marcoceppi: ^ can you confirm this is the proper route for sharing db's among multiple services? [16:21] X-warrior: MySQL already supports this [16:22] should I add something special to use shared-db? Or all relations that are using shared-db for a mysql will have the same credentials? [16:24] X-warrior: you just need to tell MySQl the database name you wish to us [16:24] it'll create unique creds per instance that connects [16:25] how can I set this database name? [16:27] you do a relation-set in the database-relation-joined hook of your charm for the "database" iirc [16:33] shared-database-relation-joined probably [16:40] X-warrior: well you can name the relation whatever you want [16:40] so you can create a database relation with the mysql-shared interface [16:41] marcoceppi: doesn't a shared relation uses password? [16:42] X-warrior: no, I'm pretty sure it creates a unique user/pass per unit just like the regular mysql interface [16:43] only it's sharing a database name between each service [16:44] marcoceppi: So I guess I'm not getting it. Do I need to have a shared-db and a database? Because the relation-changed from shared-db is not receiving any user/password on relation-get [16:44] X-warrior: the relation name is irrelevant [16:44] it's the interface you're implementing [16:46] I'm implementing mysql-shared, but the relation-get doesn't return username/password. [16:48] X-warrior: it should [16:48] I was using mysql interface then I noticed I had this particular case, on mysql interface the relation-get were working. On shared it doesn't seem to. [18:15] Is there someone out there that knows why my machines are pending and can not start? [18:15] http://pastebin.ubuntu.com/8722347/ [18:20] hey marcoceppi I think this has something to do with the setting up juju local to work with different accounts. Do you have a moment to take a look ? [18:21] aisrael, tvansteenburgh, kwmonroe ^ [18:24] mbruzek: can you paste the relevant bits of your environments.yaml? [18:24] * tvansteenburgh really has nfc [18:24] tvansteenburgh: I googled the error I am seeing in that log and found this https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1290920 [18:24] Bug #1290920: non-default lxc-dir breaks local provider

[18:25] tvansteenburgh: http://pastebin.ubuntu.com/8722467/ [18:26] sinzui: I've uploaded 1.20.11 to Trusty (waiting SRU team approval) and Vivid (built and available in vivid-proposed). [18:26] tvansteenburgh: From reading that bug, I am thinking it could be related to multiple people trying to use juju local on the same system. [18:26] sinzui: I'm off for a week now though. Once the SRU team accept the package into trusty-proposed, please could you verify it? [18:27] sinzui: the tracking bug is bug 1386144 [18:27] Bug #1386144: juju-core 1.20.11 is not packaged in Ubuntu

[18:27] (I mean verify the pieces you normally would - nothing extra) [18:27] Then you can use the results of that in your release decision. [18:27] rbasak, already on my list to do :) [18:27] Great - thanks :) [18:29] aisrael, kwmonroe, can we try destroying your envrionments and see if the regular local works? I am thinking each environment is trying to log to the same place [18:29] i'm fine with that mbruzek [18:29] ^^ destroy away [18:30] aisrael, kwmonroe, negative on my theory... $ ls -d juju-* [18:30] juju-ubuntu-local juju-ubuntu-local-aisrael juju-ubuntu-local-kwmonroe [18:30] They are all in different directories, but I am going to destroy the environments to see if the regular one starts working [18:31] if/when we figure this out let's remember to update https://juju.ubuntu.com/docs/config-LXC.html#configuration [18:31] ack [18:35] aisrael, kwmonroe, no good, I still get an error in status: agent-state-info: container "ubuntu-local-machine-1" is already created [18:40] marcoceppi, aisrael, kwmonroe I am still stuck with this local system, no machines start [18:42] mbruzek: what about creating a local-mbruzek environment and seeing if that works? [18:43] aisrael: Yes I *just* started off a deployment in local-mbruzek [18:47] mbruzek: I was lunching [18:47] still broken? [18:49] marcoceppi: I can deploy with local-mbruzek environment but not the "local" environment. [18:49] kwmonroe, aisrael ^ [18:50] mbruzek: that sucks, lets talk after 3 EST [18:58] marcoceppi: http://pastebin.ubuntu.com/8722885/ [18:59] marcoceppi: I was able to deploy ubuntu, but when I tried to run a test I get all containers fail to start, different error than the "local" environment. [18:59] this when i just hit it with the juju-clean hammer and start over [19:00] yes let me try that [19:08] tvansteenburgh: the hammer did not work, now I am getting the same error as the "local" environment [19:09] :( [19:16] jose, around? [19:38] lazyPower: hey there. I'll work on a fix for the ec2 es bug today. The branch that's currently proposed will work, but (a) we can't merge it as is, and (b) I'm hoping we don't have to use sockets but am not sure yet. You mentioned sockets failing in other scenarious, was it being used for the same reason (trying to find an ip for a private dns)? [19:39] noodles775: the issue was with socket failing, socket wraps hostname, which issues a call on our openstack deployments that fails [19:39] noodles775: i'm not convinced it will fail until i get a result back from our SETeam that someone has tried it and life is good... but initially i have a gut feeling this is going to cause more headaches than we're anticipating === CyberJacob|Away is now known as CyberJacob [19:50] lazyPower: question about this commit: https://bazaar.launchpad.net/~charmers/charms/trusty/haproxy/trunk/revision/85 [19:50] It's introducing a new lint error: [19:50] /home/ubuntu/aisrael/trusty/haproxy/hooks/hooks.py:972:80: E501 line too long (80 > 79 characters) [19:50] but removing the spaces you introduced don't seem to throw a lint error? [19:52] aisrael: http://paste.ubuntu.com/8723402/ [19:52] who can I bug to get a charm to show up in the store that's been pushed? [19:52] aisrael: i think its a discrepancy between linter configs between my laptop and my desktop [19:52] Beret: how long ago did you push it? [19:52] 10 mins [19:53] Beret: takes up to 30 minutes [19:53] can we manually kick it [19:53] ? [19:53] store ingest happens on a 15 minute cycle, so depending on when it was pushed [19:53] hatch: do you guys do requests? [19:54] like for the next juju song? ;) [19:54] ah, ok [19:54] hatch: more like for kicking off a store ingest, mr store dj [19:54] lol, *wiki wiki reeeiiinnngggessstttt* [19:55] lazyPower: best to ping rick_h_ for that [19:55] hatch: with him being out, request denied by default right? [19:55] lazyPower: Yeah, that's what I'm seeing. If I revert your patch, lint passes clean [19:55] rick_h_, hi :) [19:55] aisrael: punt [19:56] lazyPower: heh tbh I don't have access to do it so I can't, [19:56] I probably should get on that though, sorry [20:26] hatch: you're good. just looking to get an answer ;) === menn0_ is now known as menn0 [21:04] noodles775 bloodearnest you guys now own the elasticsearch and gunicorn charms [21:09] jcastro: ^ [21:12] marcoceppi: did they move namespaces? [21:13] yeah [21:13] onlineservices-charmers [21:13] ack. typically i get emails about that [21:13] lp email must be backed up [21:13] elasticsearch trusty/precise and gunicorn precise [21:27] marcoceppi: Thanks. I don't have anything to do with the precise elasticsearch - if it's no issue, it'd be better to leave that under ~charmers. I've only worked on the trusty one (which was a rewrite). [22:29] marcoceppi: hmm, we are using a (currently unmodified) branch of gunicorn fine on trusty. What do I do to add a trusty version? === urulama is now known as urulama__ === CyberJacob is now known as CyberJacob|Away [23:26] bloodearnest: push it to the trusty name space and let one of us know