| arosales | /away afk | 01:31 |
|---|---|---|
| * arosales misssed that space | 01:32 | |
| === Guest93739 is now known as Kyle | ||
| xnox | I have pushed a charm to lp:~xnox/charms/trusty/jemjem/trunk I'm trying to open a bug against jemjem charm but apperantly "jemjem" is not published in the charm collection. | 09:58 |
| xnox | How can I track bugs against my charm? | 09:59 |
| xnox | Can I declare constraints in the charm itself? As in my charm can only work with minimum 2CPUs & 2GB RAM | 11:02 |
| xnox | (i want to prevent people deploying it on worse configuration) | 11:02 |
| xnox | I guess that's what bundles are for =) | 11:03 |
| jam | xnox: it has come up a couple times, as you've found, bundles are the current answer for that | 11:17 |
| === gary_poster|away is now known as gary_poster | ||
| mattyw | Hi Folks, If I do a local deploy is it possible for me to have different directories of the same charm for different version? like my-charm-1 and my-charm-2 and deploy them using local:my-charm-2? At the moment it looks like it doesn't work becuase the name in the metadata is differnt | 13:31 |
| marcoceppi_ | mattyw: I think what you can do is possible, but can you expand a little more how your files are setup and the end goal? | 13:33 |
| mattyw | marcoceppi_, sure I'd have the same charm in a local directory - different versions would be under different directories ~/mycharms/my-charm-1 ~/mycharms/my-charm-2 | 13:35 |
| mattyw | ^^ but underneath they're the same charm - so the metadata is unchanged (but the revision number is different) | 13:35 |
| marcoceppi_ | ah, so that won't work. Charm versions are tracked via the revision file in the charm, not by the directory name | 13:35 |
| marcoceppi_ | mattyw: try ~/mycharms/my-charm and ~/mycharms2/my-charm instead | 13:36 |
| mattyw | marcoceppi_, that's a pretty neat idea | 13:36 |
| mattyw | marcoceppi_, I'll give that a go, thanks | 13:36 |
| marcoceppi_ | mattyw: np, cheers | 13:36 |
| bashok | Hi, I am currently testing out juju with my private cloud setup, my cloud has multiple compute regions all my global services has endpoints with a region name, and nova endpoints has a different region name, while configuring environments.yaml, I can specify only one region name, which is creating issues, is there a way to overcome this, is this a hard requirement to have all services with same region in endpoints? | 14:14 |
| === elopio_ is now known as elopio | ||
| arges | Hi. Is there a way to deploy a specific revision of a charm using juju deploy? Without having to locally clone, checkout etc... | 14:25 |
| marcoceppi_ | arges: juju deploy mysql-# where # is the version number | 14:38 |
| arges | marcoceppi_: : ) thanks | 14:46 |
| jcastro | marcoceppi_, can I get a +1 or -1 on my two new bullet proposals? | 14:50 |
| jcastro | the GUI guys would like to do an update | 14:50 |
| ghartmann | Hi, just a quick question. Anyone working on a IPython Notebook charm ? | 14:50 |
| marcoceppi_ | jcastro: neither really "require" anything by the charm author, per se | 14:51 |
| marcoceppi_ | jcastro: actually, I'll reply to the thread | 14:51 |
| jcastro | yeah but it's a nice feature to show in the gui | 14:51 |
| marcoceppi_ | jcastro: truth | 14:52 |
| marcoceppi_ | ghartmann: not that I'm aware of! | 14:52 |
| jcastro | since those are now more "this charm has this features" more than "this charm passes this" | 14:52 |
| marcoceppi_ | jcastro: true | 14:52 |
| jcastro | either way reply to the list | 14:52 |
| ghartmann | thanks | 14:52 |
| caribou | In an existing charm, if I want to add a new option, is config.yaml the only place I need to go to define it ? | 15:52 |
| medberry | I think so. marcoceppi_ ^ | 15:52 |
| marcoceppi_ | caribou: yes, then you need to make sure to utilze the new option in the config-changed hook :) | 15:53 |
| caribou | marcoceppi_: thanks | 15:54 |
| caribou | marcoceppi_: so you mean that *every* option has to appear at least once in config-changed ? | 16:01 |
| caribou | marcoceppi_: my change is to add an option in a conf file | 16:02 |
| marcoceppi_ | caribou: no, it doesn't have to be used at all, but then why even bother addint it to config.yaml? | 16:02 |
| marcoceppi_ | I was more referring to the fact that it's best to have it in config-changed, it can be used in any hook of the charm though | 16:03 |
| caribou | marcoceppi_: of course; my change is to define a value in a template file (cinder.conf for instance) | 16:03 |
| jcastro | hey evilnickveitch | 16:08 |
| evilnickveitch | jcastro, hey | 16:08 |
| jcastro | hey on the list | 16:08 |
| jcastro | the guy trying jenkins says the debug-hooks doc page is "opaque" | 16:08 |
| jcastro | he thinks some examples there would be good | 16:09 |
| caribou | marcoceppi_: nOOb's mistake, I forgot to increment the revision :-/ | 16:11 |
| evilnickveitch | jcastro, ok | 16:11 |
| jcastro | hey marcoceppi_ | 16:18 |
| jcastro | bac landed the new QA bullets | 16:18 |
| jcastro | https://manage.jujucharms.com/charms/precise/apache2/qa/edit | 16:18 |
| jcastro | we can now check those off as part of the audit | 16:18 |
| === negronjl_ is now known as negronjl | ||
| dpb1 | Would it be possible for someone to look at this? https://bugs.launchpad.net/charms/+bug/1259630 | 17:50 |
| _mup_ | Bug #1259630: add storage subordinate charm <landscape> <Juju Charms Collection:New for davidpbritton> <https://launchpad.net/bugs/1259630> | 17:50 |
| === CyberJacob|Away is now known as CyberJacob | ||
| marcoceppi_ | dpb1: if it's not in https://manage.jujucharms.com/tools/review-queue we don't really know about it | 18:03 |
| === medberry is now known as med_ | ||
| === CyberJacob is now known as CyberJacob|Away | ||
| marcoceppi_ | dpb1: wait, is this a charm or an idea you want feedback on? | 18:03 |
| dpb1 | marcoceppi_: what do I do to get it there? | 18:03 |
| dpb1 | marcoceppi_: I have the bug marked with charmers, I have it assigned to me | 18:04 |
| marcoceppi_ | dpb1: but is it a charm or just a concept you want to discuss? | 18:04 |
| dpb1 | charm | 18:04 |
| marcoceppi_ | dpb1: you need to link a branch to for it to show up | 18:04 |
| dpb1 | blah | 18:04 |
| marcoceppi_ | I don't see a branch linked anywhere other than your jenkins mention | 18:05 |
| dpb1 | lp should just know! :) | 18:05 |
| marcoceppi_ | ;) | 18:05 |
| marcoceppi_ | dpb1: cool, it'll show up in the queue in the next 10 mins and I'll try to get eyes on by end of the week | 18:06 |
| dpb1 | marcoceppi_: thanks much! we already have some follow-on work and are looking to integrate it into the postgres charm, so feedback would be appreciated | 18:06 |
| marcoceppi_ | dpb1: cool, I also see the swap charm is up for review soon too | 18:07 |
| dpb1 | marcoceppi_: yes, that one is much more limited in scope. just something to clear out some todo items. el-mo even told me already it sucked. :) | 18:08 |
| jcastro | marcoceppi_, I think I found the problem with the mongodb replicaset you mentioned in passing the other day | 19:15 |
| marcoceppi_ | jcastro: excellent! | 19:15 |
| === CyberJacob|Away is now known as CyberJacob | ||
| lazypower | jcastro, do tell | 19:19 |
| jcastro | I think you need to set the replica set name before you add unit | 19:19 |
| jcastro | I am testing it out now | 19:19 |
| jcastro | lazypower, "Not using --replSet" do you get that in the UI? | 19:22 |
| lazypower | jcastro, 1 sec on the phone with blythe | 19:22 |
| jcastro | no worries | 19:22 |
| jcastro | here it is | 19:23 |
| jcastro | 19:22:40.165 [initandlisten] ERROR: can't use --slave or --master replication options with --replSet | 19:23 |
| jcastro | negronjl, around? | 19:23 |
| lazypower | jcastro, as i understand it, which may be incorrect, you have to define the heartbeat set and let election occur | 19:27 |
| lazypower | *define the replica set, allow it to heart beat, and election occur before you define master slave relationships | 19:27 |
| jcastro | yeah it's just none of that is in the instructions | 19:27 |
| jcastro | it's like "yo, juju deploy, add-unit, done!" | 19:28 |
| marcoceppi_ | jcastro: maybe the config just doesn't have sane defaults? | 19:28 |
| lazypower | good point, i ran into that helping maxcan get his mongodb cluster deployed. | 19:28 |
| jcastro | marcoceppi_, maybe | 19:28 |
| lazypower | and what actually solved it, was just running it again with -r after the config servers came online | 19:28 |
| jcastro | I mean, the hardcore one with sharding needs a config.yaml and all that | 19:28 |
| lazypower | oh this is strictly replset creation? | 19:29 |
| maxcan | yup | 19:29 |
| jcastro | this is just the simple multi node deployment | 19:29 |
| jcastro | lazypower, yeah | 19:29 |
| maxcan | resolved -r; rinse; repeat is your friend | 19:29 |
| jcastro | ugh | 19:29 |
| maxcan | also, needed to make sure that teh configsvr RS was all set up and good before relating to mongos | 19:29 |
| jcastro | anyone have their history handy with all the commands? I am working on fixing the readme today | 19:30 |
| jcastro | so you can just do it in the first try | 19:30 |
| lazypower | Maxcan has a sharded RS history | 19:31 |
| lazypower | Let me reach out to some peeps and see if i can fetch the history of my last deployment. | 19:31 |
| jcastro | ta | 19:31 |
| * lazypower doffs hat | 19:31 | |
| jcastro | I don't need the sharded one yet, but I'll take it! | 19:31 |
| lazypower | jcastro, its going to be a sharded repl set from me as well... | 19:32 |
| jcastro | aha! | 19:33 |
| jcastro | the resolved --retry seem to do the trick | 19:33 |
| lazypower | jcastro, thats the race condition we ran into. Something's not getting set right away during the relationship-joined/changed hooks | 19:33 |
| jcastro | ok | 19:33 |
| jcastro | I am going to file a bug | 19:34 |
| jcastro | and then add a note in the readme | 19:34 |
| jcastro | https://bugs.launchpad.net/charms/+source/mongodb/+bug/1267222 | 19:37 |
| _mup_ | Bug #1267222: Race condition when deploying a simple replica set <mongodb (Juju Charms Collection):New> <https://launchpad.net/bugs/1267222> | 19:37 |
| jcastro | if anyone has anything to add | 19:37 |
| marcoceppi_ | So, you have the ability to create a testing configuration file, it will live in the tests directory. I have it called testplan.yaml but think it's too long. suggestions? | 19:37 |
| negronjl | jcastro: I'll get back to you in a few minutes ... let me finish lunch | 19:38 |
| jcastro | no worries! | 19:38 |
| marcoceppi_ | I was going to call it config.yaml, but didn't want ot confuse the actual config.yaml file | 19:39 |
| jcastro | config_test.yaml? | 19:39 |
| lazypower | marcoceppi_, is this related to setup/teardown of your testing suite? or specifics? | 19:40 |
| marcoceppi_ | lazypower: it's the ability to see the test driver with configuration options for your charm | 19:40 |
| marcoceppi_ | more like test plugin preferences | 19:40 |
| marcoceppi_ | jcastro: test_config.yaml sounds better, so I'll go with that unless someone thinks of the equivlant "promulgate" word for this before eod | 19:41 |
| jcastro | no more weird words! | 19:41 |
| lazypower | ^ | 19:41 |
| marcoceppi_ | <3 | 19:51 |
| maxcan | lazypower: just got back, was on a cll | 20:00 |
| lazypower | All good my man. I was too. | 20:00 |
| lazypower | How's things post deployment? I assume it went without a hitch after we got the cluster setup? | 20:00 |
| maxcan | no, took me several hours to get it right | 20:12 |
| maxcan | but your help was invaluable | 20:12 |
| lazypower | Well thanks for the plug :) Did you happen to do a writeup on your hurdles you faced? | 20:22 |
| lazypower | maxcan, and if not, I can help by doing a phaux interview with you. I'm really interested in your experience. | 20:29 |
| === hatch_ is now known as hatch | ||
| jcastro | mbruzek, arosales: TLDR is that the juju in stable ppa uses lxc-ls, which in trusty now requires root | 21:02 |
| jcastro | 1.17 skips that and should work, so we'll be fine. | 21:03 |
| jcastro | note, that it does not work for me right now | 21:03 |
| marcoceppi_ | jcastro: 1.17.1 should be landing in the dev ppa sooner or later | 21:04 |
| mbruzek | should I enable trusty-proposed ? | 21:05 |
| mbruzek | Or where do I get the dev one? | 21:05 |
| marcoceppi_ | mbruzek: ppa:juju/devel | 21:05 |
| mbruzek | oh. | 21:05 |
| mbruzek | juju dev | 21:06 |
| marcoceppi_ | actually, 1.17.0 is already out | 21:06 |
| marcoceppi_ | jcastro: did you try 1.17.0? | 21:06 |
| mbruzek | mbruzek@skull:~/workspace/charms/tomcat$ juju --version | 21:06 |
| mbruzek | 1.16.5-trusty-amd64 | 21:06 |
| jcastro | yeah | 21:06 |
| jcastro | I get some connection refused error. | 21:06 |
| marcoceppi_ | mbruzek: yeah, 1.EVEN are "stable" releases, 1.ODD are devel releases | 21:07 |
| marcoceppi_ | so if you sudo add-apt-repository ppa:juju/devel; sudo apt-get update, sudo apt-get upgrade you'll get 1.17.0 | 21:07 |
| jcastro | jorge@jilldactyl:~$ sudo juju bootstrap | 21:07 |
| jcastro | ERROR Get http://10.0.3.1:8040/provider-state: dial tcp 10.0.3.1:8040: connection refused | 21:07 |
| jcastro | is what I get currently | 21:07 |
| marcoceppi_ | jcastro: run it with --debug --show-log | 21:08 |
| jcastro | oh dude, environment exists | 21:08 |
| jcastro | I think I had it bootstrapped | 21:08 |
| jcastro | and _then_ upgraded | 21:08 |
| marcoceppi_ | doh! | 21:08 |
| jcastro | ugh, can't destroy it now | 21:09 |
| marcoceppi_ | jcastro: stop all the juju-* upstart tasks | 21:09 |
| marcoceppi_ | then rm -f /etc/init/juju-* | 21:10 |
| jcastro | got it | 21:10 |
| jcastro | blowing away .jenv did it | 21:10 |
| jcastro | that's my new debug tool | 21:10 |
| marcoceppi_ | ah | 21:10 |
| jcastro | "something broke? blow away the .jenv file" | 21:10 |
| jcastro | ok, so it works fine now with 1.17 | 21:11 |
| marcoceppi_ | jcastro: sweet | 21:19 |
| maxcan | lazypower: i will definitely do a write up | 22:22 |
| arosales | jcastro, sorry I was tied up in a meeting. thanks for the fyi in trusty needing 1.17 | 22:57 |
| === CyberJacob is now known as CyberJacob|Away | ||
| maxcan | so, anytime I add-unit juju opens up my juju-amazon security group ports 22, 17070, and 37017 to 0.0.0.0/0 | 23:31 |
| davecheney | maxcan: yes, that is necessary | 23:32 |
| maxcan | also dangerous | 23:32 |
| davecheney | those are the control ports juju needs to talk to the bootstrap node, the state server and the api server | 23:33 |
| maxcan | coulnd't it just only open those ports to the IP of the management server | 23:33 |
| maxcan | why 0.0.0.0? | 23:33 |
| davecheney | the management server is the bootstrap node | 23:33 |
| davecheney | those ports are open so your client can connect to juju | 23:34 |
| maxcan | i get that opening to the AWS security-group is to AWS specific | 23:34 |
| davecheney | i understand your point | 23:34 |
| davecheney | it's not something that juju does at the moment | 23:34 |
| davecheney | please consider raising a freature request | 23:34 |
| maxcan | i'll add it to my list of feature requests | 23:35 |
| maxcan | that i'm writing up | 23:35 |
| maxcan | FYI, my setup is that I have a client running on an EC2 host which requires yubikey 2FA for SSH access | 23:35 |
| maxcan | my juju scripts generate a random admin secret and run all the juju commands from that machine | 23:36 |
| maxcan | so that way, it should be impossible for any outside access to the juju boxes | 23:36 |
| davecheney | sounds like a sound practice | 23:36 |
| davecheney | the firewaller currently doesnt' handle source ip acls, it just knows how to configure by port | 23:37 |
| davecheney | this would have to be something additional to juju | 23:37 |
| maxcan | yeah | 23:37 |
| maxcan | currently, on AWS at least, the default juju behavior is to open all ports on all juju machines to all juju machines | 23:38 |
| davecheney | yes, charms expect that | 23:38 |
| maxcan | but, each machine does get its own security group (juju-amazon-N) which is basically unused | 23:38 |
| davecheney | yes, this is a known bug | 23:38 |
| davecheney | it sort of extends from openstack providers which limit security groups | 23:38 |
| davecheney | so we 1/2 finished the workaround | 23:39 |
| maxcan | would it be consistent with charms' expected behaviors to only open up ports (besides conmand ports) when there is a relation | 23:39 |
| maxcan | and to only use the relaitons ports | 23:39 |
| davecheney | charms expect an open network | 23:39 |
| davecheney | the open-port close-port comments relate to the external network | 23:39 |
| davecheney | so, when i say open network | 23:40 |
| davecheney | i mean open internal network | 23:40 |
| maxcan | because not all relations have explicit ports? | 23:40 |
| davecheney | open-port / close-port only talk about services exposed by the charms | 23:41 |
| davecheney | when charms are related together the expectation is they have full network access to one another | 23:41 |
| davecheney | eg, mysql <> wordpress | 23:41 |
| davecheney | expects 100% access on a private network | 23:41 |
| davecheney | wordpress may call expose-port, but that is realy just to setup the port forwarding | 23:41 |
| maxcan | i see | 23:41 |
| davecheney | eg, when wordpress and mysql relate the mysql charm will call | 23:42 |
| davecheney | unit-get private-address | 23:42 |
| davecheney | to obtain it's private ip address and pass that via the relation to wordpress | 23:42 |
| maxcan | i see | 23:43 |
| maxcan | kind of violates the principle of least access but if all the charms expect that, not much to do | 23:43 |
| maxcan | for the charms i'm using and writing (mongo and internal) it could be accomplished | 23:44 |
| maxcan | next question, is it possible to add-units to a service using a newer revision of the charm without upgading the running instances? | 23:45 |
| davecheney | maxcan: no | 23:45 |
| davecheney | add-unit always uses the version of the charm that is cached in the state | 23:45 |
| maxcan | hm | 23:45 |
| davecheney | ie, add-unit always depliys the same version of the charm | 23:45 |
| davecheney | i know what you are trying to do | 23:45 |
| davecheney | juju doesn't support smoke test upgrades at the moment | 23:46 |
| davecheney | s/smoke test/rolling/ | 23:46 |
| maxcan | so if i have 20 app servers and hit upgrade charm, will they be done serially or in parallel? | 23:48 |
| davecheney | parallel-ish | 23:48 |
| davecheney | we wave our hands and say juju is asynchronus | 23:48 |
| maxcan | that seems not good-ish | 23:48 |
| davecheney | so the only guarnetee is all the units will process the upgrade charm request | 23:49 |
| maxcan | zero downtime deploys would be nice | 23:49 |
| davecheney | a. eventually | 23:49 |
| davecheney | b. before doing any other relation events | 23:49 |
| davecheney | maxcan: for zero time upgrades we recommend having two environments | 23:49 |
| davecheney | eg. omgubuntu has two environments, A and B, upgrade A, making it the primary B bcomes staging | 23:50 |
| davecheney | upgrade B it becomes the primary and A becomes staging | 23:50 |
| davecheney | ie is difficult for juju to handle zero downtime upgrades because juju is not a process manager | 23:50 |
| davecheney | ie, it doesn't know the state of processes, only the agents which run comments | 23:50 |
| davecheney | commands | 23:50 |
| maxcan | that wouldn't work for us, we'd have to move our mongo cluster | 23:51 |
| marcoceppi_ | there's definitely room to for a subordinate charm to do zero downtime upgrades, but you'd have to not use upgarde-charm and instead opt for a configuration option on your service (ie a version configuration option) | 23:51 |
| davecheney | another option is to create two services | 23:51 |
| maxcan | so, for us, we dont need process managers because we're happy to have immutable app servers | 23:51 |
| davecheney | marcoceppi_: yeah, that is what I think the openstack chamrs do | 23:51 |
| maxcan | i.e. spin up 10 servers with version 2, when their started, kill the 10 servers with version 1 | 23:52 |
| davecheney | maxcan: you'd have to do that as two services | 23:52 |
| marcoceppi_ | right, they tack version as a configuration option and only use upgrade-charm when the charm's code changes. So you can juju set version="whatever"; then have your charm perform leader election and perform rolling upgrade execution | 23:52 |
| maxcan | aaaahhh | 23:52 |
| maxcan | now it all makes sense | 23:53 |
| davecheney | maxcan: i don't know if the mongo db charm would give out the smae credentials on two different relations | 23:53 |
| davecheney | i suspect it would not | 23:53 |
| maxcan | essentially version my services | 23:53 |
| marcoceppi_ | davecheney: probably not | 23:53 |
| marcoceppi_ | maxcan: yes, the openstack charms do this and several others (discourse comes to mind) | 23:53 |
| davecheney | maxcan: so possibly in that scenario you have two services, one with zero units, the other with 10 | 23:53 |
| davecheney | upgrade-charm on one service | 23:53 |
| davecheney | then add units to it, and remove units from the other one | 23:53 |
| davecheney | or have 10 in each | 23:54 |
| davecheney | and just have a big red button on your load balancer that switches the load from one service backend to another | 23:54 |
| marcoceppi_ | maxcan: here's an example of the configuration options for discourse | 23:54 |
| marcoceppi_ | http://manage.jujucharms.com/~marcoceppi/precise/discourse and http://manage.jujucharms.com/~marcoceppi/precise/discourse/config | 23:55 |
| maxcan | thanks! | 23:55 |
| maxcan | davecheney: perfect | 23:55 |
| marcoceppi_ | If you decouple the application upgrade process from the charm upgrade process you no longer have to rely (as much) on juju to perform the upgrade and can implement your own upgrade logic via the peer relation and config-changed | 23:56 |
| maxcan | marcoceppi_: we kind of have. our install hook pulls a docker image from s3, so if that is updated, even wtihout the charm being updated, we'll get a new version | 23:57 |
| marcoceppi_ | cool | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!