/srv/irclogs.ubuntu.com/2016/05/06/#juju.txt

=== blahdeblah_ is now known as blahdeblah
=== Makyo is now known as Makyo|Vacay
=== fginther` is now known as fginther
=== rogpeppe2 is now known as rogpeppe
=== rockstar_ is now known as rockstar
=== rohit___ is now known as rohit__
=== julen_ is now known as julen
D4RKS1D3Hi lazyPower , you have any notice about my but?12:17
D4RKS1D3now I reinstalled the compute but I think probably in the future this option should be available12:18
stubaisrael: 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
stubaisrael: Some other bits of my test harness could need tweaking too13:19
aisraelstub: ok, thanks. Here's the logs from running it w/2 and the latest amulet/deployer stuff13:37
aisraelhttp://pastebin.ubuntu.com/16258792/13:37
stubaisrael: I think that is my main test harness - the wrapper is just passing its arguements on through to the real juju-deployer IIRC.13:39
stubaisrael: The PG charm will likely fail in exactly the same way (they share the harness)13:40
aisraelstub: Yup. Hopefully that makes fixing it easier, too. :D13:40
stubI'll find out next week ;)13:41
aisraelstub: is that long of a run time to be expected?13:42
stubaisrael: 6 minutes because none of the units ever got deployed? That is rather on the short side.13:45
aisraelNo no. The successful run ran for like, 10 hours13:45
stubaisrael: 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:47
aisraelstub: Ok, I'll give it another run (testing your other mps). Is that hour or two run against the local provider?13:48
stubaisrael: Yes13:48
aisraelstub: ack, thanks. I'll pump up the vm ram and give that a go.13:48
stubaisrael: thanks :)13:49
* stub wanders back into the long weekend13:49
=== chuck__ is now known as zul
lazyPowermarcoceppi - 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
lazyPowerso i'm concerned this will cause a problem for users upgrading14:30
marcoceppilazyPower: interesting14:31
lazyPowerwhat 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 default14:32
marcoceppilazyPower: will etcd relation provide the ssl details?14:33
lazyPowercorrect.14:33
lazyPowerits going to need to send a client certificate with the connection string14:33
marcoceppilazyPower: so, eek, the best we can is do this xenial only and check what bundles are doing xenial/etcd to see the ramifications for this14:34
mbruzeklazyPower: 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:34
marcoceppimbruzek: 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 change14:35
marcoceppilazyPower: if we do this for xenial only we won't break anyone14:35
marcoceppibecuase we dont' have a xenial charm for etcd14:35
lazyPowermulti-series charm in the layer though14:36
lazyPowerso, that doesn't help14:36
marcoceppilazyPower: we should research the ramifications14:36
lazyPowermbruzek - etcd unit-unit is not secure, nor is client-server comms14:36
lazyPowerits done over plain HTTP14:36
marcoceppilazyPower: etcd is used in openstack calico bundle14:37
mbruzeklazyPower: Oh you mean the non-juju unit to unit communication14:37
marcoceppilazyPower: that I can see on the store page14:37
lazyPowermarcoceppi - 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
marcoceppilazyPower: so we should add tls layer, deploy etcd then upgrade-charm from your fork14:37
marcoceppilazyPower: yes, lets see what happens with the deployments we know use it, k8s and openstack-calico seem to the be majority of the consumers14:37
lazyPoweryeah thats what i was thinking was get a proper non tls to tls upgrade test.14:38
* marcoceppi acks14:38
lazyPowerbut i wanted to ping you so you knew what we were going to run into14:38
lazyPoweri think this can work, but only if its done right, otherwise we're going to brick some deployments and thats no bueno14:38
=== frankban_ is now known as frankban
iceyis it possible to get c-h from head into a layered charm?15:21
lazyPowericey - i know that you can create your own wheel of it and stuff it in the charm15:24
lazyPowerit doesn't care, it'll use whatever is in the wheelhouse15:24
lazyPowerbut thats not a long term solution15:24
lazyPoweri had to do tha tlastnight to check some charms.docker features i had in a pr that had not landed in pypi15:25
iceylazyPower: 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
lazyPowericey - thats the exact same usecase i outlined15:25
iceyyeah, thanks :)15:25
lazyPoweryou can make a wheel and use that :) Just stuff it in the wheelhouse and remove teh one the builder put in there15:25
lazyPowerdisclaimer, i didnt look in the builder, so i just manually installed the .whl before hook execution15:25
iceyso I have to manually muckl around in the built charm :-/15:25
suchvenuHi15:26
suchvenuHave a query on naming of interfaces15:26
lazyPoweryou 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
lazyPowerhey suchvenu o/   ready when you are.15:26
suchvenuhttp://pastebin.ubuntu.com/16261116/15:29
suchvenuMy interface name is db2(interface.yaml) and the launchpad stream is interface-ibm-db2. In layer.yaml i have given interface-ibm-db215:30
suchvenuI got disconnected.. :(15:40
suchvenulazyPower , you haresponded to my query ? I think I missed all15:40
lazyPowersuchvenu i have not15:40
suchvenu*had responded15:40
suchvenuok15:40
lazyPower1 moment, i'm wrapping up something else and will take a look15:41
suchvenuyou got my query , or did you miss that ?15:41
suchvenusure15:41
lazyPowersuchvenu - i'm not sure i know what you mean by launchpad stream.15:47
suchvenuI meant the branch name in Launchpad15:47
lazyPowerand according to this pastebin, your includes should look like:     ['layer: ibm-base', 'interface:db2']15:47
suchvenudo we need to follow any naming convention for the interface ?15:49
lazyPowersuchvenu - 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.yaml15:50
suchvenuIf 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/trunk15:51
lazyPowerthats 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 repo15:52
marcoceppisuchvenu: you don't want to put it under the charms/trusty namespace, that's for charms. This is an interface15:52
lazyPoweroh, but what marcoceppi pointed out, should be corrected :)15:52
lazyPowerhe is correct15:52
marcoceppisuchvenu: you can create a new launchpad project called interface-ibm-db2 but the interface.yaml should just have the name "db2"15:53
wolsenthedac, if you have a minute - a trivial - https://review.openstack.org/#/c/313226/15:53
marcoceppisuchvenu: https://launchpad.net/projects/+new once you fill that out you can do `bzr push lp:~ibmcharmers/interface-ibm-db2/trunk`15:53
suchvenulp:~ibmcharmers/charms/trusty/interface-ibm-db2/trunk . So can I use this same branch and update the interfaces.yam as db2 ?15:54
suchvenuok, different branch for interface15:54
marcoceppisuchvenu: 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 name15:55
suchvenuSo i need to register a new project here ?15:55
suchvenuok15:55
suchvenulet me try create a new project here15:56
suchvenuso here you say interface name can be db2 only and interface-ibm-db2 is not required ?15:58
suchvenuin layer.yaml15:58
marcoceppisuchvenu: 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-db215:59
suchvenuIn 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:01
suchvenubut 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 sent16:03
marcoceppisuchvenu: no, it's typically one project per interface16:04
suchvenuoh16:04
marcoceppiwhen you create the project name in launchpad it should be named something like interface-db216:04
marcoceppior interface-ibm-db216:04
suchvenuso here i will give the proj name as inter-ibm-db216:04
suchvenuok16:04
suchvenuSo for charms we have a single project area, but for interface separte rpoject areas ?16:05
marcoceppisuchvenu: yes16:06
suchvenuok16:06
suchvenuIt asks this : Select the licence(s) under which you release your project.16:07
suchvenuWHich one to select ?16:09
suchvenumarcoceppi you there ?16:11
marcoceppisuchvenu: that's up to you, it's a license for the code, I'd recommend apache2 but that's entirely up to you16:12
marcoceppisuchvenu: a license for the code of th einterface, not for db216:12
suchvenuya, just wanted to know which is generally selected16:13
suchvenuso trunk and devel I need to push over here, right ?16:16
suchvenuand the other ones which i created under trusty needs to be deleted, right ?16:16
aisraelAnyone 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:17
aisrael^ ever see16:19
lazyPowernegative aisrael16:22
aisraellazyPower: ran my vm out of disk space, which might be the cause16:34
lazyPowerseems legit16:34
thedacwolsen: +2 sorry for the delay16:55
wolsenthedac, np and thx!16:55
=== CyberJacob is now known as zz_CyberJacob
=== frankban is now known as frankban|afk
=== scuttle|afk is now known as scuttlemonkey
=== zz_CyberJacob is now known as CyberJacob
iceylazyPower: 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 charm20:26
=== alexisb is now known as alexisb-afk
=== scuttlemonkey is now known as scuttle|afk
mattraelazyPower: 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
mattraelazyPower: i'll see if i can try the latest juju-deployer on launchpad21:17
mattraelooks like trunk also gives the same error21:21
mattraefginther: 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-juju21:23
fginthermattrae, that branch has already been merged into trunk (lp:juju-deployer), do you have the traceback handy?21:25
fgintherthere may be a latent bug or two21:26
mattraefginther: 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:27
fginthermattrae, no, you don't need an environments.yaml with 2.0.21:29
fgintherlet me take a quick look21:30
fginthermattrae, are you trying to run this out of a branch?21:31
mattraefginther: yeah i've tried the version that comes with xenial, and then i tried trunk21:32
mattraeboth give the same error21:32
fginthermattrae, 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 package21:33
fgintheryou can also install from the daily ppa21:33
mattraefginther: yeah i followed the virtualenv instructions in the READ21:33
mattraei'll see if i can try the daily ppa21:35
fgintherhang on, I have it handy21:36
fginthermattrae, ppa:ahasenack/juju-deployer-daily21:36
mattraefginther: awesome, looking better so far. i'm not getting that error21:38
mattraethanks!21:38
fginthermattrae, you're welcome21:38
mattraefginther: 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/21:52
=== frankban is now known as frankban|afk

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!