[11:54] <tiagogomes> Hi, if I loose the juju state server, and I haven't ran the ensure-availability command, is all lost?
[13:21] <jose> tiagogomes: was your server turned off or completely shut down?
[13:22] <jose> by 'completely shut down' I mean destroyed forever
[13:23] <tiagogomes> jose I was talking about a hypothetical scenario. I'd like to know if was possible to recover from "completely shut down"
[13:24] <jose> not 100% sure on this
[13:25] <tiagogomes> ok. what if I ran ensure-availability. And laster I acquired new hardware. Would it be possible to rerun ensure-availability so that a new state server starts on the new hardware?
[13:59] <stub> I think the review queue needs a kick. 30 mins and my MP isn't up.
[14:03] <jose> stub: let me check if the merges I did cleared from the queue
[14:06] <lazyPower> stub it may be behind a bit, when tvansteenburgh surfaces i'll poke at him to poke @ the logs and see if it needs cycled
[14:06] <lazyPower> also o/ stub
[14:07] <stub> ta both of you
[14:07] <stub> o/
[14:07] <lazyPower> mornin jose
[14:07] <lazyPower> tiagogomes thats tricky
[14:07] <stub> I'm never sure if it has hung or if my ISP is being evil.
[14:07] <lazyPower> stub :(  always a gamble
[14:08] <tiagogomes> lazyPower oh, can't just I add a state server?
[14:08] <lazyPower> tiagogomes nope. if you ran a single state server (no ha) and then destroy it, the chances of re-creating your model controller node are pretty minimal
[14:08] <lazyPower> there are some backup/restore tecnniques but i dont recall off hand what they were
[14:09] <lazyPower> natefinch: didn't' you do a writeup to the list on how to recover from a tanked state server? or was it just how ot recover from missing .jenv files?
[14:11] <tiagogomes> lazyPower oh I think that you were replying to my first question. I asked after "<tiagogomes> ok. what if I ran ensure-availability. And laster I acquired new hardware. Would it be possible to rerun ensure-availability so that a new state server starts on the new hardware?"
[14:11] <lazyPower> tiagogomes - i think if you had one node still participating, you could reasonably re-create a HA state server, but restoring from a single node you're in for some heartache
[14:11] <lazyPower> but to 100% be certain of that i would need to confirm from core that its been tested
[14:11] <lazyPower> this is all theory at the moment
[14:12] <lazyPower> beisner still need that mysql mitaka sync landed?
[14:15] <tiagogomes> My use case is that I purchase some blade server to use for JuJu. Later on I purchase another server and I would like to run the state server in the new server for high-availability, as they are in two different availability zones
[14:16] <beisner> hi lazyPower - indeed if you've got cycles, please do.  TA!
[14:16] <lazyPower> beisner just pushed. LGTM
[14:16] <lazyPower> i like what you did in tests/tests.yaml
[14:43] <jose> ohai lazyPower
[14:44] <lazyPower> o/
[14:45] <lazyPower> updates
[14:45] <natefinch> lazyPower: howdy... not me, I don't think.  Maybe perrito666?  He's the restore master.
[14:46]  * perrito666 feels summoned
[14:46]  * natefinch waves at perrito666.
[14:46]  * natefinch points at lazyPower.
[14:47]  * lazyPower points at scrollback
[14:47]  * natefinch sorta misses MUDs and all the emotes they had sometimes.
[14:47] <beisner> thx lazyPower
[14:47] <lazyPower> haha
[14:47] <lazyPower> natefinch did you MMUD bro?
[14:47] <natefinch> lazyPower: hugely in college... even ended up running a MUD for a while.
[14:48] <lazyPower> same here, i pulled it out in 2014 and played a couple months worth of "let the bot autoroam in foreveralone mode"
[14:48] <perrito666> I see, it is theoretically possible
[14:48] <perrito666> although I never tried to do exactly that
[14:48] <lazyPower> tiagogomes ^
[14:48] <lazyPower> seems like its theory, but not practice yet
[14:50] <lazyPower> beisner np np
[14:58] <lazyPower> If anyone is looking for some background noise, I just cut the final edit of the systemzoo podcast - episode 3 featuring former juju developers Wayne Witzel, and Whit Morriss - http://systemzoo.org/3
[14:58] <tiagogomes> lazyPower ?
[14:59] <lazyPower> tiagogomes - confirmation that rebuilding from a fractured HA setup hasn't been verified
[14:59] <lazyPower> perrito666 says its "theoretically possible" but it doesn't appear that we have data to back it up
[15:00] <tiagogomes> lazyPower, ha, what you mean by fractured.  I was hoping to rerun ensure-availability with a working system to make it even more HA
[15:00] <perrito666> backing up, changing a server and restoring should work but we never tested said feature as a migration, only as a rescue
[15:33] <tvansteenburgh> stub: lazyPower: revq looks ok on the backend, should get to your mp eventually
[15:37] <pmatulis> can juju use a network image store remote with the lxd local provider?
[16:07] <matt_dupre> I've pushed a bundle to Launchpad, but it hasn't appeared in the charm store (been a few hours).  I used lp:~project-calico/charms/bundles/<bundle-name>/bundle; but is there anything else I need to do?
[16:08] <lazyPower> matt_dupre nope, that looks about right
[16:08] <lazyPower> we were having issues with ingestion in the last couple of weeks though
[16:09] <lazyPower> matt_dupre - take a look here and if its a problem item add the url to the bug please - https://github.com/CanonicalLtd/jujucharms.com/issues/189
[16:12] <matt_dupre> What kind of time should I expect for a bundle?
[16:13] <lazyPower> matt_dupre the longest you should have to waiti for a bundle ingestion is ~ an hour. publications using the launchpad ingestion system cycle every half hour
[16:13] <matt_dupre> OK, thanks lazyPower: I'll add a note to the issue
[16:13] <lazyPower> this problem will "go away" with juju 2.0 - as store upload is a direct process.
[16:13] <lazyPower> while that doesn't help today, we're getting there quickly!
[16:58] <Prabakaran> Hello Kevin, Hope you are doing great !!. This is regarding IBM Java layer charm. Since it is a subordinate charm i am using ubuntu charm to test ibm-java subordinate charm.
[16:58] <Prabakaran> In this case i am connecting ibm-java charm and Ubuntu charm via java interface. So before running charm build command layer.yaml file looks like this http://pastebin.ubuntu.com/14497095/ .
[16:58] <Prabakaran> If I am connecting via java interface to test my charm, i have downloaded ubuntu charm and edited metadata.yaml file and mentioned provides as "java".
[16:58] <Prabakaran> Now if I want to connect ibm-java layer charm with Ubuntu charm with juju-info interface. I think I may have to change layer.yaml file before running charm build command.
[16:58] <Prabakaran> If so, is there anything that i need to edit in the layer.yaml file, please advise how to connect Ubuntu charm and ibm-java layer charm with juju-info interface.
[17:17] <tiagogomes> Hi, I am trying to boostrap JuJu on OpenStack but I am getting an not very helpful authentication failed. Is there a way to see more information about what's going on? I am using verbose mode. Also, does JuJu supports keystone v3?
[17:21] <kwmonroe> hi Prabakaran - the java relation is needed to test your charm.  without it, the java states won't be set, which means you will not enter the code that does install or config-changed.  so i don't think you should change your ibm java charm to use juju-info.
[17:22] <kwmonroe> Prabakaran: i'm working on the following, which is a generic ubuntu charm that already has the java interface for you.  if you deploy this, you shouldn't have to modify a local ubuntu charm.  instead, relate your ibm-java charm to ubuntu-devenv:  https://jujucharms.com/u/kwmonroe/ubuntu-devenv
[17:23] <kwmonroe> Prabakaran: the nice thing about a generic ubuntu-devenv is that we can use the same thing for stuff like ibm-xlc and ibm-fortran, in addition to jdk providers like ibm and zulu.
[17:25] <Prabakaran> Thanks kevin, i will test my charm with ubuntu-devenv charm
[17:27] <kwmonroe> cool - good luck Prabakaran!  once i get tests added to that charm, i'll put it up for review.  until then, you can deploy it in a test like this (note the cs:~kwmonroe namespace for ubuntu-devenv): http://paste.ubuntu.com/14497345/
[17:40] <tiagogomes> does JuJu boostrapped on OpenStack requires Swift?
[17:45] <bdx> mbruzek, lazyPower: Nice work on layer-k8s and layer-tls!  After giving it some thought, and reviewing what I'll be trying to do alot of using the tls-layer, I feel like I need to use the  ca(), client_cert(), and server_cert() functions in k8s.py, everywhere I will be using layer-tls. Should/could those functions just be part of layer-tls?
[17:46] <lazyPower> bdx we're considering shipping a lib w/ the tls layer
[17:46] <lazyPower> that would be a good abstraction point
[17:50] <bdx> lazyPower: each of the three functions, and the other two functions they depend on could just be defined in lib/tlslib.py and accept an input parameter of dest_dir?
[17:59] <lazyPower> something like that
[17:59] <lazyPower> we like the idea of key retrieval from unit data
[18:00] <lazyPower> its all nicely encapsulated there in the charm state store, so why not?
[18:00] <lazyPower> you can put it wherever you want
[18:00] <lazyPower> keep it in memory if thats something you're into
[18:00] <lazyPower> skys the limits
[18:00] <lazyPower> bdx: file a bug and lets sketch what it looks like there
[18:01] <lazyPower> i'lll ping the list about it, see how many "does this work with lets encrypt" responses and then land a lib
[18:17] <bdx> lazyPower: sweet!
[18:17] <bdx> will do
[18:24] <icey> what's the policy with regards to layers on python versions, I'm trying to use a layer that does not work on python3 but works fine on python2
[18:25] <lazyPower> i think we're targeting python3
[18:26] <lazyPower> i know stub has strong feelings on this. I feel like as a whole we are moving away from python2 as its long since deprecated.
[18:26] <icey> that's what I was hoping to hear :)
[18:27] <icey> I notice that the hooks generated with charm build use /usr/bin/env python3
[18:34] <bdx> lazyPower, mbruzek: like this https://github.com/jamesbeedy/layer-tls/blob/port_k8s_to_tls_lib/lib/tlslib.py ?
[18:35] <lazyPower> bdx add some unit tests and you're talkin buddy!
[18:35] <lazyPower> bdx btw we like py.test <3
[18:49] <bdx> lazyPower: Is there a way to run my tests w/o deploying the layer/charm?
[18:49] <lazyPower> just unit tests, if you want to functionally test it, you'll either need to provide the env its expecting or mock it out like crazy.
[18:51] <lazyPower> bdx i have a few concerns of mixing state in a library, as that seems like a layer should be doing that
[18:52] <bdx> entirely, I was wondering about that too
[18:52] <lazyPower> i suppose if its properly namespaced, theres no harm in it, but in the event that webapp.certificate.available ever is set in another layer... its going to cause unintended side effects
[18:52] <lazyPower> i think if it just performs the system level operation, and is used like a helper
[18:52] <bdx> totally
[18:53] <lazyPower> and all state is set outside of that utility library, its good as is, just needs some uniform docstrings and unit tests
[19:12] <bdx> lazyPower: https://github.com/jamesbeedy/layer-tls/blob/port_k8s_to_tls_lib/lib/tlslib.py
[19:13] <lazyPower> bdx i like where this is headed
[19:13] <lazyPower> +1 to your docstrings
[19:13] <bdx> thx
[19:14] <bdx> lazyPower: so looking into unit_tests, I want to start with the unit_test template for a charm modified for this layer
[19:14] <bdx> lazyPower: https://github.com/jamesbeedy/layer-tls/blob/port_k8s_to_tls_lib/unit_tests/test_actions.py
[19:14] <bdx> is this ok/recommended in a layer?
[19:15] <lazyPower> bdx thats fine, i've also adopted a py.test pattern here - https://github.com/juju-solutions/charms.docker/blob/master/tests/test_docker.py
[19:16] <lazyPower> but i also made this a proper python package that is nested in charms.d
[19:16] <lazyPower> charm.*
[19:16] <lazyPower> s/m./ms./  # epic typing fail of the week achieved
[19:17] <bdx> wow, really cool
[19:17] <lazyPower> bdx just basic python unit tests
[19:17] <lazyPower> i try to keep my code as concise as possible so i'm only done one, and at most two mocks at a time while testing the code
[19:17] <lazyPower> stacks of mocks get messy, and i dont always trust that i'm testing what i think i'm testing
[19:23] <bdx> lazyPower: I feel like I need the keys to exist to be able to test the functions in lib .... should I create optional input params to those functions for source_directory?
[19:23] <lazyPower> you can make it a test fixture
[19:23] <lazyPower> be aware that unitdata.kv() will create a db in the directory that is running the tests
[19:23] <lazyPower> and need to clean itself up
[19:25] <bdx> lazyPower: so I could essentially create a fixture for layer-tls, or just for each of the functions?
[19:27] <lazyPower> just for that test file
[19:27] <lazyPower> test fixtures aid in ssetting up things like controlled files on disk so you can create/remove a database in between tests, or only at start/end of test run
[19:27] <lazyPower> bdx https://pytest.org/latest/fixture.html
[19:39] <bdx> wow, really cool
[19:50] <lazyPower> bdx: sorry split brain. i re-read the scroll back and yeah - i would make some optional input parameters, and also template a couple of throw away certs to load in as fixture data
[19:51] <lazyPower> that way you're not married to having the amenities provided by the layer, you're only dealing with the end certificates w/ examples to test with in that lib. that will keep the sep. of concerns to a minimal.
[19:58] <bdx> lazyPower: ok, what about things like JUJU_UNIT_NAME ?
[19:58] <bdx> http://paste.ubuntu.com/14498348/
[19:59] <bdx> lazyPower: should I just set the env vars that it needs in the tests?
[19:59] <lazyPower> those are environment variables when they are read in, so now we're heading into mocking out os.environ
[19:59] <lazyPower> or setting those in the fixture
[19:59] <bdx> gotcha
[20:09] <aisrael> lazyPower: "Authors can use this hook to take action if their protocols for
[20:09] <aisrael> leadership, consensus, raft, or quorum require one unit to assert leadership." <-- should raft be draft?
[20:10] <lazyPower> negative. Raft is a consensus algorithm
[20:10] <lazyPower> aisrael ^
[20:10] <aisrael> lazyPower: ack, thanks!
[20:10] <aisrael> lazyPower: This a good link? https://en.wikipedia.org/wiki/Raft_(computer_science)
[20:11] <lazyPower> aisrael indeed
[20:13] <aisrael> Wow
[20:13] <aisrael> Wrong window ^_^
[20:15] <lazyPower> aisrael mind = blown? :)
[20:15] <aisrael> pwoooosh
[20:39] <icey> https://gist.github.com/ChrisMacNaughton/f8a6e9b32b8d9bccfbe5 is replacing newlines in the output file with nothing and I can't figure out why; if I print privkey to stdout, it has newlines correctly but the written file has none, I've tried splitting on \n and iterating on lines, I've tried leaving the base64decode result as bytes and opening the file as binary
[20:40] <hatch> has there been any discussion around adding 'required' fields to a charm configuration?
[20:49] <aisrael> jrwren: Hey, is this ready for re-review? https://code.launchpad.net/~evarlast/charms/trusty/apache2/trunk/+merge/278220
[20:50] <jrwren> aisrael: yes, iirc
[20:50] <jrwren> aisrael: or no.
[20:51] <jrwren> aisrael: if the tests pass, then yes. otherwise, no.  Sorry, I lost track of that one.
[20:52] <bdx> lazyPower: https://github.com/jamesbeedy/layer-tls/blob/port_k8s_to_tls_lib/unit_tests/test_actions.py
[20:52] <bdx> lazyPower: any pointers from here?
[20:53] <bdx> lazyPower: https://github.com/jamesbeedy/layer-tls/blob/port_k8s_to_tls_lib/lib/tlslib.py
[20:54] <aisrael> jrwren: ack. I'll re-test and bump the bug if it needs attention
[20:54] <jrwren> aisrael: thanks.
[20:54] <lazyPower> bdx close, i dont see any assertions
[20:55] <bdx> ahh entirely..... what should I assert though? just '0' ?
[20:55] <bdx> oooh
[20:55] <bdx> I should assert that the certs are in the correct places after the functions are ran/tested
[20:56] <lazyPower> that or just verify the write operation was called
[20:56] <lazyPower> we dont have to test python, we should test that we're using python correctly though
[20:59] <icey> lazyPower: ever use base64 to pass blobs of data into charm configs that you end up writing out to a file?
[20:59] <lazyPower> i have
[20:59] <icey> a layer I'm trying to use does that but it doesn't work correctly, (stripping newlines?!)
[20:59] <lazyPower> uhh
[20:59] <lazyPower> what?
[21:00] <icey> want to see the code?
[21:00] <lazyPower> what layer?
[21:00] <lazyPower> yeah
[21:00] <icey> https://plus.google.com/hangouts/_/canonical.com/juju-client
[21:00] <icey> and the layer is the juju-client one
[21:00] <icey> :-P
[21:00] <lazyPower> icey i'm in standup room atm
[21:00] <icey> doing standup or hanging out?
[21:00] <lazyPower> it might still happen ;)
[21:01] <lazyPower> not sure yet, we have 5 minutes for it to go either way
[21:01] <icey> hahaha
[21:01] <icey> this shouldn't take 5 :)
[21:01] <icey> but I can wait too :-P
[21:01] <icey> let me know
[21:14] <bdx> lazyPower: now? https://github.com/jamesbeedy/layer-tls/blob/port_k8s_to_tls_lib/unit_tests/test_actions.py
[21:47] <icey> lazyPower: maybe we can look at it in the AM if I can't figure it out by then :)
[21:47] <lazyPower> icey Sounds like a plan
[21:47] <lazyPower> i need ot EOD soon
[21:48] <lazyPower> bdx Hit me with a PR in the morning and i'll review
[21:48] <icey> me too :) started tearing down my aws env and realized we had an outstanding maybe today :)
[21:48] <lazyPower> haha, right on icey  thanks for circling back
[21:48] <icey> course lazyPower, will ping you tomorrow if I haven't cracked it by then :)
[22:04] <beisner> coreycb, first of many mitaka amulet test enablement MPs, ready for review/landing if ya will:  https://code.launchpad.net/~1chb1n/charms/trusty/cinder/next-amulet-mitaka-1601/+merge/282519
[22:04] <coreycb> beisner, ok
[22:16] <lazyPower> beisner: how did that ppc64 patch go?
[22:17] <lazyPower> from sfeole
[22:31] <beisner> lazyPower, thx for directing us to that.  gave feedback on the MP re: targeting at a different charm branch.  /me --> EODs
[22:34] <ennoble> could someone explain to me how the runcmd file that is handed to cloud-init is created by juju?
[23:24] <bdx> Is there a way to direct `charm generate` to grab layers from charms/layers if they exist instead of from there repos?
[23:25] <bdx> whoops ... my bad, looks like it already does :-)
[23:30] <bdx> I can spell