[12:17] <D4RKS1D3> Hi lazyPower , you have any notice about my but?
[12:18] <D4RKS1D3> now I reinstalled the compute but I think probably in the future this option should be available
[13:19] <stub> aisrael: No, I haven't tested Cassandra with Juju 2. It shouldn't be much work though, assuming Amulet and/or juju-deployer updates have been released.
[13:19] <stub> aisrael: Some other bits of my test harness could need tweaking too
[13:37] <aisrael> stub: ok, thanks. Here's the logs from running it w/2 and the latest amulet/deployer stuff
[13:37] <aisrael> http://pastebin.ubuntu.com/16258792/
[13:39] <stub> aisrael: I think that is my main test harness - the wrapper is just passing its arguements on through to the real juju-deployer IIRC.
[13:40] <stub> aisrael: The PG charm will likely fail in exactly the same way (they share the harness)
[13:40] <aisrael> stub: Yup. Hopefully that makes fixing it easier, too. :D
[13:41] <stub> I'll find out next week ;)
[13:42] <aisrael> stub: is that long of a run time to be expected?
[13:45] <stub> aisrael: 6 minutes because none of the units ever got deployed? That is rather on the short side.
[13:45] <aisrael> No no. The successful run ran for like, 10 hours
[13:47] <stub> aisrael: That is much slower than I would expect. I don't have a recent full timing, but it runs on my 8GB laptop in an hour or two I think.
[13:48] <aisrael> stub: Ok, I'll give it another run (testing your other mps). Is that hour or two run against the local provider?
[13:48] <stub> aisrael: Yes
[13:48] <aisrael> stub: ack, thanks. I'll pump up the vm ram and give that a go.
[13:49] <stub> aisrael: thanks :)
[13:49]  * stub wanders back into the long weekend
[14:30] <lazyPower> marcoceppi - question for you about best practices with interfaces... I'm looking to add TLS to the etcd interface so communication between client/server is done over that encrypted tunnel , and basically deprecate the non TLS connection(s). This has implications on consumers, but once you've reconfigured the daemon for tls, it drops all notion of accepting connections without it...
[14:30] <lazyPower> so i'm concerned this will cause a problem for users upgrading
[14:31] <marcoceppi> lazyPower: interesting
[14:32] <lazyPower> what i think i can do, which is slightly more complex is make SSL a configuration option, and have the interface adapt accordingly, and leave it off by default
[14:33] <marcoceppi> lazyPower: will etcd relation provide the ssl details?
[14:33] <lazyPower> correct.
[14:33] <lazyPower> its going to need to send a client certificate with the connection string
[14:34] <marcoceppi> lazyPower: so, eek, the best we can is do this xenial only and check what bundles are doing xenial/etcd to see the ramifications for this
[14:34] <mbruzek> lazyPower: marcoceppi: isn't the relation communication done securely from the start? controller -> unit communication is done via ssh, I thought the unit -> unit communication secured too?
[14:35] <marcoceppi> mbruzek: controller -> unit is done via API and unit -> unit is also api and that's encrypted, it's more about upgrading and having something that was doing plaintext suddenly move to tls and not knowing how to handle that drop or change
[14:35] <marcoceppi> lazyPower: if we do this for xenial only we won't break anyone
[14:35] <marcoceppi> becuase we dont' have a xenial charm for etcd
[14:36] <lazyPower> multi-series charm in the layer though
[14:36] <lazyPower> so, that doesn't help
[14:36] <marcoceppi> lazyPower: we should research the ramifications
[14:36] <lazyPower> mbruzek - etcd unit-unit is not secure, nor is client-server comms
[14:36] <lazyPower> its done over plain HTTP
[14:37] <marcoceppi> lazyPower: etcd is used in openstack calico bundle
[14:37] <mbruzek> lazyPower: Oh you mean the non-juju unit to unit communication
[14:37] <marcoceppi> lazyPower: that I can see on the store page
[14:37] <lazyPower> marcoceppi - ok so dev the TLS bits, deploy a k8s cluster with the non tls enabled bit, upgrade it and see how badly it breaks?
[14:37] <marcoceppi> lazyPower: so we should add tls layer, deploy etcd then upgrade-charm from your fork
[14:37] <marcoceppi> lazyPower: yes, lets see what happens with the deployments we know use it, k8s and openstack-calico seem to the be majority of the consumers
[14:38] <lazyPower> yeah thats what i was thinking was get a proper non tls to tls upgrade test.
[14:38]  * marcoceppi acks
[14:38] <lazyPower> but i wanted to ping you so you knew what we were going to run into
[14:38] <lazyPower> i think this can work, but only if its done right, otherwise we're going to brick some deployments and thats no bueno
[15:21] <icey> is it possible to get c-h from head into a layered charm?
[15:24] <lazyPower> icey - i know that you can create your own wheel of it and stuff it in the charm
[15:24] <lazyPower> it doesn't care, it'll use whatever is in the wheelhouse
[15:24] <lazyPower> but thats not a long term solution
[15:25] <lazyPower> i had to do tha tlastnight to check some charms.docker features i had in a pr that had not landed in pypi
[15:25] <icey> lazyPower: basically, the base layer is pulling in 0.7.0 of c-h, I need some stuff that is committed, but isn't yet in pypi -_-
[15:25] <lazyPower> icey - thats the exact same usecase i outlined
[15:25] <icey> yeah, thanks :)
[15:25] <lazyPower> you can make a wheel and use that :) Just stuff it in the wheelhouse and remove teh one the builder put in there
[15:25] <lazyPower> disclaimer, i didnt look in the builder, so i just manually installed the .whl before hook execution
[15:25] <icey> so I have to manually muckl around in the built charm :-/
[15:26] <suchvenu> Hi
[15:26] <suchvenu> Have a query on naming of interfaces
[15:26] <lazyPower> you may need to poke the tactics.py file in charm-tools to see how we're using pip to build the wheelhouse (specifically WheelHouseTactic)
[15:26] <lazyPower> hey suchvenu o/   ready when you are.
[15:29] <suchvenu> http://pastebin.ubuntu.com/16261116/
[15:30] <suchvenu> My interface name is db2(interface.yaml) and the launchpad stream is interface-ibm-db2. In layer.yaml i have given interface-ibm-db2
[15:40] <suchvenu> I got disconnected.. :(
[15:40] <suchvenu> lazyPower , you haresponded to my query ? I think I missed all
[15:40] <lazyPower> suchvenu i have not
[15:40] <suchvenu> *had responded
[15:40] <suchvenu> ok
[15:41] <lazyPower> 1 moment, i'm wrapping up something else and will take a look
[15:41] <suchvenu> you got my query , or did you miss that ?
[15:41] <suchvenu> sure
[15:47] <lazyPower> suchvenu - i'm not sure i know what you mean by launchpad stream.
[15:47] <suchvenu> I meant the branch name in Launchpad
[15:47] <lazyPower> and according to this pastebin, your includes should look like:     ['layer: ibm-base', 'interface:db2']
[15:49] <suchvenu> do we need to follow any naming convention for the interface ?
[15:50] <lazyPower> suchvenu - have you looked at the interfaces site? http://interfaces.juju.solutions  -- no convention other than the name thats listed in the interfaces api should match what you have in interface.yaml
[15:51] <suchvenu> If I keep db2 as te interface name in layer, how it should be in the Launchpad ? As of now its like this : lp:~ibmcharmers/charms/trusty/interface-ibm-db2/trunk
[15:52] <lazyPower> thats fine,  the way the api works is you create an entity for the interface/layer respectively. You can then configure the DVCS url for that entity. so you simply plug that in for the repo
[15:52] <marcoceppi> suchvenu: you don't want to put it under the charms/trusty namespace, that's for charms. This is an interface
[15:52] <lazyPower> oh, but what marcoceppi pointed out, should be corrected :)
[15:52] <lazyPower> he is correct
[15:53] <marcoceppi> suchvenu: you can create a new launchpad project called interface-ibm-db2 but the interface.yaml should just have the name "db2"
[15:53] <wolsen> thedac, if you have a minute - a trivial - https://review.openstack.org/#/c/313226/
[15:53] <marcoceppi> suchvenu: https://launchpad.net/projects/+new once you fill that out you can do `bzr push lp:~ibmcharmers/interface-ibm-db2/trunk`
[15:54] <suchvenu> lp:~ibmcharmers/charms/trusty/interface-ibm-db2/trunk . So can I use this same branch and update the interfaces.yam as db2 ?
[15:54] <suchvenu> ok, different branch for interface
[15:55] <marcoceppi> suchvenu: you do not want to put anything other than charms in the charms/trusty path, that will simply confuse the store. Since this is an interface you'll want to create a new project then push to that branch name in launchpad but you can keep the name as db2 in the interface. It's okay to have a different branch name and a different interface name
[15:55] <suchvenu> So i need to register a new project here ?
[15:55] <suchvenu> ok
[15:56] <suchvenu> let me try create a new project here
[15:58] <suchvenu> so here you say interface name can be db2 only and interface-ibm-db2 is not required ?
[15:58] <suchvenu> in layer.yaml
[15:59] <marcoceppi> suchvenu: right, so in the interface.yaml you can put name: db2 but the project in launchpad can be called whatever you'd like. So Id' recommend either interface-db2 or interface-ibm-db2
[16:01] <suchvenu> In register project, it asks for Name, Url and SUmmary. Is this name you are referring to ? I can add all the interfaces we create into this project right ?
[16:03] <suchvenu> but the project in launchpad can be called whatever you'd like => does this mean the branch name for the db2 interface or the new project i am going to create using Register project link you sent
[16:04] <marcoceppi> suchvenu: no, it's typically one project per interface
[16:04] <suchvenu> oh
[16:04] <marcoceppi> when you create the project name in launchpad it should be named something like interface-db2
[16:04] <marcoceppi> or interface-ibm-db2
[16:04] <suchvenu> so here i will give the proj name as inter-ibm-db2
[16:04] <suchvenu> ok
[16:05] <suchvenu> So for charms we have a single project area, but for interface separte rpoject areas ?
[16:06] <marcoceppi> suchvenu: yes
[16:06] <suchvenu> ok
[16:07] <suchvenu> It asks this : Select the licence(s) under which you release your project.
[16:09] <suchvenu> WHich one to select ?
[16:11] <suchvenu> marcoceppi you there ?
[16:12] <marcoceppi> suchvenu: that's up to you, it's a license for the code, I'd recommend apache2 but that's entirely up to you
[16:12] <marcoceppi> suchvenu: a license for the code of th einterface, not for db2
[16:13] <suchvenu> ya, just wanted to know which is generally selected
[16:16] <suchvenu> so trunk and devel I need to push over here, right ?
[16:16] <suchvenu> and the other ones which i created under trusty needs to be deleted, right ?
[16:17] <aisrael> Anyone see a provisioning machine with an agent-state error of 'cannot record provisioning info for "ubuntu-local-machine-1": cannot set instance data for machine "1": not found or not alive'
[16:19] <aisrael> ^ ever see
[16:22] <lazyPower> negative aisrael
[16:34] <aisrael> lazyPower: ran my vm out of disk space, which might be the cause
[16:34] <lazyPower> seems legit
[16:55] <thedac> wolsen: +2 sorry for the delay
[16:55] <wolsen> thedac, np and thx!
[20:26] <icey> lazyPower: I've gotten it to drop both charmhelpers into the generated charm, but when I remove the base layer version, it seems to resurrect it when I deploy the charm
[21:17] <mattrae> lazyPower: hi, do you know which version of juju-deployer i need to use with juju 2.0? i'm getting an error from juju-deployer complaining that .juju/environments.yaml doesn't exist, which isn't used in juju 2.0 https://pastebin.canonical.com/155977/
[21:17] <mattrae> lazyPower: i'll see if i can try the latest juju-deployer on launchpad
[21:21] <mattrae> looks like trunk also gives the same error
[21:23] <mattrae> fginther: happen to be around? i saw you may be working on a juju-deployer branch that works with juju 2.0. should i use this branch? lp:~fginther/juju-deployer/updated-juju
[21:25] <fginther> mattrae, that branch has already been merged into trunk (lp:juju-deployer), do you have the traceback handy?
[21:26] <fginther> there may be a latent bug or two
[21:27] <mattrae> fginther: sure, here is the traceback i'm seeing complaining about no eivornments.yaml.. do i need enviornments.yaml with 2.0? https://pastebin.canonical.com/155979/
[21:29] <fginther> mattrae, no, you don't need an environments.yaml with 2.0.
[21:30] <fginther> let me take a quick look
[21:31] <fginther> mattrae, are you trying to run this out of a branch?
[21:32] <mattrae> fginther: yeah i've tried the version that comes with xenial, and then i tried trunk
[21:32] <mattrae> both give the same error
[21:33] <fginther> mattrae, ok, if you're trying to use a bzr branch, you'll need to use a virtualenv or something. As it's being used now, it's calling into the deployer modules that were installed with the package
[21:33] <fginther> you can also install from the daily ppa
[21:33] <mattrae> fginther: yeah i followed the virtualenv instructions in the READ
[21:35] <mattrae> i'll see if i can try the daily ppa
[21:36] <fginther> hang on, I have it handy
[21:36] <fginther> mattrae, ppa:ahasenack/juju-deployer-daily
[21:38] <mattrae> fginther: awesome, looking better so far. i'm not getting that error
[21:38] <mattrae> thanks!
[21:38] <fginther> mattrae, you're welcome
[21:52] <mattrae> fginther: if you're back, i'm getting another error saying that the environment isnt bootstrapped.. but i did bootstrap. do you see if i'm doing something wrong here? https://pastebin.canonical.com/155981/