| Prabacha | Hi Team, After deploying mariadb charm, i am not able to access the database running the below command. | 06:12 |
|---|---|---|
| Prabacha | i ran "juju deploy mariadb" and sshd to the container | 06:12 |
| Prabacha | and ran mysql -u root -p$(sudo cat /var/lib/mysql/mysql.passwd) | 06:13 |
| Prabacha | i was getting error statin "ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)" | 06:13 |
| Prabacha | could someone help me on this? | 06:13 |
| Prabacha | Hi Team, After deploying mariadb charm, i am not able to access the database running the below command. | 06:49 |
| Prabacha | and ran mysql -u root -p$(sudo cat /var/lib/mysql/mysql.passwd), i was getting error statin "ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)". could someone help me on this? | 06:49 |
| === danilos` is now known as danilos | ||
| === verterok is now known as verterok-away | ||
| === verterok-away is now known as verterok | ||
| === verterok is now known as verterok-away | ||
| jrwren | charmers: may I please have a rerun once the docker test env is fixed? "Error response from daemon: Unknown filesystem type on /dev/mapper/docker-253:16-9412611-76217dce5f7b552422b80917c9234a0da3415990afc0afb82c07b3c46c13865a-init http://review.juju.solutions/review/2357 | 15:17 |
| tvansteenburgh | jwren: queued | 15:40 |
| jrwren | tvansteenburgh: thanks! | 15:40 |
| apuimedo | lazypower: is there a way to retrigger a hook afer doing "resolved" ? | 15:56 |
| lazypower | apuimedo: juju resolved --retry | 16:01 |
| apuimedo | :-) | 16:01 |
| lazypower | apuimedo that will re-execute the last failed hook, but if you've simply juju resolved, it will progress on | 16:01 |
| lazypower | you'll have to trigger the hook via conventional means, such as changing config or changing relations | 16:02 |
| apuimedo | cool | 16:03 |
| apuimedo | that's what I usually do, use the conventional means | 16:04 |
| apuimedo | lazypower: can I just do a suggestion for the cli team? | 16:23 |
| apuimedo | I don't know who's the right person | 16:23 |
| apuimedo | but basically | 16:23 |
| apuimedo | juju ssh name-of-the-charm should resolve when there is only one unit | 16:23 |
| apuimedo | instead of complaining that the unit name does not exist | 16:23 |
| apuimedo | I can't typo anymore | 16:23 |
| lazypower | apuimedo: protip: dhx solves that for you | 16:43 |
| lazypower | but a bug against that would be totally appreciated | 16:43 |
| lazypower | thats a bite-sized bug | 16:43 |
| === apuimedo is now known as away | ||
| === away is now known as Guest32752 | ||
| === verterok-away is now known as verterok | ||
| stokachu | hi all, i wrote an email discussing ways to cater more to the application developer, https://lists.ubuntu.com/archives/juju/2015-December/006186.html | 17:40 |
| stokachu | please have a look and provide your feedback | 17:40 |
| beisner | hi marcoceppi, tvansteenburgh - can you re-trigger tests for this? i get 404 for results. or lmk if i can retrigger somehow via review.juju.solutions. tia! http://review.juju.solutions/review/2348 | 19:06 |
| tvansteenburgh | beisner: done | 19:07 |
| beisner | tvansteenburgh, thx! | 19:07 |
| cory_fu | mbruzek, lazypower: So, bcsaller pointed out to me that there is a much simpler way to model your leader vs follower roles for the TLS layer | 19:19 |
| lazypower | cory_fu: we tried it that way | 19:20 |
| lazypower | theres still no good way to hand back a CSR via just leadership | 19:20 |
| lazypower | ben and i had drinks over this in seattle | 19:20 |
| cory_fu | lazypower: You don't need to pass CSRs around at all | 19:20 |
| lazypower | how else is the leader going to sign the services cert? | 19:21 |
| * lazypower is not understanding | 19:21 | |
| cory_fu | lazypower: Just make the leader solely responsible for creating and signing CSRs and it only needs to send the signed cert over the relation | 19:21 |
| lazypower | you still need the server.key from that remote unit to generate a proper csr | 19:21 |
| lazypower | if that were the case, you wouldn't ever need to submit a CSR to a commercial CA | 19:22 |
| lazypower | you would just buy, receive, and drop in apache | 19:22 |
| cory_fu | lazypower: Except that in our case, we control both ends. So the leader can create the server.key and send it along with the signed cert | 19:22 |
| lazypower | hmmm | 19:22 |
| lazypower | maybe | 19:22 |
| lazypower | i haven't tested that, but i' gonna say spidey sense says there be dragons there | 19:22 |
| cory_fu | Obviously, it wouldn't work with if the leader were instead a public CA, but since it's just a unit of our service, then it can be in charge of both the server.keys and the signing. | 19:24 |
| cory_fu | Let's say the leader were sending out CSRs to a public CA instead of self-signing. It can still create a server.key and CSR for each follower, send the CSR to the public CA, and then give the server.key and signed cert to the follower | 19:25 |
| cory_fu | I think the only case where that would break down is if you wanted to re-sign with the same server.key after a leader change | 19:26 |
| cory_fu | But that's only an issue because "data sent from leader to follower" doesn't persist after a leader change. You could work around that by storing the server.keys in the leader data, but you'd have to create your own mapping of followers to server.keys | 19:27 |
| lazypower | tbh, i dont think thats any simpler/easier | 19:28 |
| lazypower | its not very redundant | 19:28 |
| lazypower | the fact we're generating csrs on the unit, and then shipping @ a leader, seems to me like its the 'right way' to do it | 19:28 |
| lazypower | and as long as that CA cert doesnt expire/change, we're in the clear with what was prototyped | 19:28 |
| cory_fu | Why does it need to be redundant? | 19:29 |
| lazypower | i dont know, it sounded like a great supporting adjective? | 19:29 |
| cory_fu | lazypower: I'm not saying that the way you have it now won't work, but I do think it would be simpler (at least in the interface layer) if it were just the leader telling the followers what they need to know (removes the back-and-forth aspect) | 19:29 |
| cmars | speaking of certs... is anyone working on a layer for let's encrypt yet? that would be *awesome* | 20:18 |
| marcoceppi | cmars: not yet, but mbruzek and lazypower are working on a general TLS layer | 20:21 |
| lazypower | cmars: i'm willing to sponsor you with a pizza if you want to write that layer | 20:21 |
| lazypower | cmars: the catch is you have to consume the tls layer matt and I are writing.... | 20:22 |
| === Guest32752 is now known as apuimedo | ||
| marcoceppi | lazypower: no idea if there's a hostname charm-helper or not | 22:14 |
| lazypower | marcoceppi: you read my mind | 22:15 |
| lazypower | ta | 22:15 |
| jhobbs | when i deploy a charm on wily in an lxc, charms.reactive gets installed for python3.5, but my install hook from 'charm build' is using 'python3' in the shebang, which by default points to python3.4 on wily, causing it to not be able to find charms.reactive | 23:15 |
| jhobbs | is there a good way to fix this (better than hand editing my generated install hook)? | 23:16 |
| jhobbs | bug filed: https://github.com/juju/charm-tools/issues/78 | 23:28 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!