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

junaidali 06:16
=== CyberJacob is now known as zz_CyberJacob
=== zz_CyberJacob is now known as CyberJacob
=== frankban|afk is now known as frankban
=== ionutbalutoiu_ is now known as ionutbalutoiu
=== rohit___ is now known as rohit__
=== mmcc_ is now known as mmcc
jacekncould somebody check any my MP is not showing on review.juju.solutions? https://code.launchpad.net/~canonical-sysadmins/charms/trusty/apache2/apache2-storage/+merge/29861709:08
magicaltroutjacekn: its probably just broken, although I think there is movement on the new review queue09:09
magicaltroutmarcoceppi is in europe at the mo I believe so might be able to shed some light09:09
jaceknyes some info would be good, I know there were problems with the review queue months ago but they must have been fixed by now09:10
aisraeljamespag`: We need to connect a charm to keystone. Is there a layer for that relation?09:41
jamespag`aisrael, there is an interface for the keystone interface which is probably what you want to use09:41
jamespag`its in the index09:41
jamespag`aisrael, context?09:42
aisraeljamespag`: openmano charming session w/marks09:42
jamespag`aisrael, right - so does it need todo endpoint registration into the keystone server catalog?09:42
jamespag`aisrael, if it does not you might want to use the keystone-credentials interface to just get some credentials - really depends09:43
jamespag`there is also an interface for that09:44
aisraeljamespag`: ack, that's a good starting point, thanks. I'm not up to speed on how deep the keystone integration goes.09:44
jamespag`aisrael, ok well around most of the day - will be out for lunch at about 11:30 UTC09:46
marcoceppijacekn: we're moments away from deploying a new review-queue, but it's stalled because it's not on IS infrastrture and I'm having problems fetching remote resources in our qa environment10:09
jaceknmarcoceppi: thanks, good news10:12
=== jamespag` is now known as jamespge
=== jamespge is now known as jamespage
eeemilLink to https://jujucharms.com/docs/devel/config-local from https://jujucharms.com/docs/devel/developer-getting-started is broken13:13
shilpaHi, I deployed a charm making using of juju resources, I have pushed empty packages to the charm store, when i deploy the charm , i see that the charm is stuck at Unknown package_status None13:26
shilpaCan anyone help why we get this status message ?13:26
kwmonroeahoy jamespage -- do you know much about this bundle?14:30
kwmonroehttps://jujucharms.com/openstack-midonet-liberty/bundle/0/14:30
kwmonroewe have an incompatible zookeeper change, and it looks like this bundle is the only one using zk.14:30
kwmonroealso jamespage, you're the current maintainer of zookeeper, so if you have a sense of how much your charm is used, that will help us in deciding how much effort to put in to make it upgradable / back compat / etc..14:32
cory_fujamespage: When kwmonroe says "incompatible" he means it's layered, so you can't directly upgrade, and that it adds a required java relation.  Otherwise, the interfaces are the same.14:37
magicaltroutsee kwmonroe told you we defer to cory_fu for explanations ;)14:40
kwmonroelol14:40
jamespagekwmonroe, cory_fu: hmm - I know midonet uses it - and I think contrail does as well - bbcmicrocomputer would be able to confirm14:41
* jamespage feels sheepish about 'current maintainer' status14:41
bbcmicrocomputerkwmonroe: yes, contrail uses zookeeper14:42
cory_fujamespage: I think we're comfortable taking over maintainership since it will be a Bigtop charm now, but we're concerned about the transition14:44
kwmonroethx for the info -- we'll run through https://jujucharms.com/requires/zookeeper and see how deep the rabbits live.14:44
tinwoodcory_fu, jamespage tells me that you've been discussing actions in the context of reactive.  I was wondering if you had an exemplar of how much of reactive to bring up when running an action? Thanks14:46
drbidwellWhere do I find how to set the default directory to put lxd containers?  I am using an existing xfs file system instead of a zfs or btfs file system.14:58
neil__Hi lazyPower, are you around?14:59
lazyPowerneil__ i am14:59
neil__(Just poking the new etcd charm...)14:59
lazyPowerAwesome! Hows it goin?15:00
neil__lazyPower, I've deployed the new charm into my OpenStack cluster, and so far things are not fully hooking up...15:00
neil__lazyPower, ...which is I think as expected because I need to do some work in the charms that use etcd client proxies.15:00
lazyPowerhow so?15:01
neil__Well I have this charm 'neutron-api', which includes installing etcd to act as a proxy.15:01
neil__And right now it's not getting the initial cluster string properly.15:02
lazyPowerneil__ https://github.com/juju-solutions/layer-etcd/blob/master/reactive/etcd.py#L15615:02
lazyPoweri found the issue. We must have missed a merge in the final bits before moving for release. the interface was updated, but looks like the invocation block never made it15:03
neil__Ah, I was wondering about those lines being commented out :-)15:03
lazyPowergive me a couple minutes and i'll get you a fixed revision15:04
neil__But then I also wondered if the code under hooks/relations/etcd-proxy was intended to be a better alternative to those lines...15:04
=== caribou_ is now known as caribou
neil__How is the code under hooks/relations/etcd-proxy hooked into the rest of the charm?  I couldn't find any explicit references to the EtcdProvider class.15:07
lazyPowerthat code is the interface code :)15:07
neil__Oh I see, I think EtcdHelper in the commented out code should in fact be EtcdProvider (with an appropriate import at the top of that file), because there's nothing else in the charm that has a provide_cluster_string method.15:10
neil__One other thing - could the key be 'cluster' instead of 'cluster_string'?  'cluster' is what my two proxy client charms are expecting.15:13
neil__(And I believe previous iterations of the etcd charm used 'cluster' - e.g. my latest version before your recent work, at https://github.com/projectcalico/charm-etcd/blob/master/hooks/hooks.py#L80)15:15
lazyPowerneil__ - negative, the cluster strings are now computed from the active members coming back from etcdctl15:31
lazyPowerthe etcdhelper is deprecated fully, it was harder to understand than modeling the client utility.15:31
lazyPowerwhat i'll wind up doing is pulling the member list of who's actively participating in the cluster and send that over with client credentials. i'm not finding that branch, so i think we legitimately missed porting this15:33
lazyPowerneil__ https://github.com/juju-solutions/interface-etcd-proxy/pull/315:42
neil__Understood I think.  There's also what looks like reasonable code in the hooks/relations/etcd-proxy/README.md (in case you'd forgotten that).15:44
neil__That PR LGTM - thanks.15:45
lazyPowerneil__ - https://github.com/juju-solutions/layer-etcd/pull/3215:53
kwmonroepetevg: that suggestion to use bigtop::jdk_preinstalled: false may not work.. zk builds off of the bigtop base layer, which will report blocked when_not java.ready :/16:03
petevgDarn :-/16:03
kwmonroeso we'd have to tweak our java check in the base layer16:03
petevgThat sounds entertaining.16:03
petevgActually, since we're passing in overrides to the Bigtop class, it might be able to check for that value.16:03
kwmonroelet's see what cory_fu comes up with after his current meeting.. it may be a non issue if we vote to rename zk to zk-bigdata or something16:04
petevgCool.16:04
cory_fuI missed the context for this.  Are we suggesting not making ZK depend on the external java relation?16:05
cory_fuCan we make the charm use the Bigtop java install by default but let the java relation override / switch the java when related?16:10
neil__lazyPower, Just in a meeting at the mo - will look properly at your layer-etcd PR soon after that finishes.16:12
cory_fukwmonroe, petevg, kjackal: So it sounds like we'll make the bigtop zookeeper charm xenial only and leave the existing charm for trusty16:28
cory_fuWith that, we could keep the required java relation.16:28
neil__lazyPower, Is it a concern that the new integration code in the PR is different from what is suggested in https://github.com/juju-solutions/interface-etcd-proxy/blob/master/README.md ?  Should the latter be updated?16:29
cory_fuThe relation name changes wouldn't be an issue either16:29
cory_fuWe'd have to have separate tests for trusty vs xenial16:29
kwmonroethere's a pickle in there cory_fu16:30
kwmonroelet's say i deploy hadoop-processing, which is currently gonna use all trusty charms.. including openjdk.  then i add xenial zk and it says "blocked waiting for java".16:31
kwmonroeso i'm all like "cool, juju add-relation zk openjdk"16:31
kwmonroeand then juju's all like "ERROR cannot add relation "openjdk:java hive:java": principal and subordinate applications' series must match "16:31
cory_futinwood: The majority of the discussion around actions & reactive is at: https://github.com/juju-solutions/charms.reactive/pull/6616:31
tinwoodcory_fu, yes, jamespage pointed me to that - interesting read.  I'm trying to work out if it's possible to get the relation data whilst I'm doing an action. Hmm.16:32
cory_fukwmonroe: That's a problem with subordinates in general.  It would be an issue in mixed series deployments even if both ZK series were the same charm underneath16:33
tinwoodcory_fu, i.e. I have  some data set from the other end, and I want to check/use it in an action.16:33
neil__lazyPower, sorry, will be AFK again for a while now - back later16:34
cory_futinwood: The goal of that PR would be to be able to use @when and @action together, so your action would be predicated on the relation state and would get the relation instance16:34
tinwoodcory_fu, that would work nicely.  In the meantime, can you think of anyway to do with a 'plain' action?16:35
plarsanyone familiar with a problem where the bootstrap node constantly has *very* high load? I'm not sure if it's the cause or a symptom, but mongodb is hammering the logs16:36
plarsby very high, I mean up aroun 400-50016:36
plarsrestarting juju-db brings it down temporarily, but it creeps back up pretty quickly16:36
tinwoodcory_fu, could I set a state, run reactive.main() and then pick up that state and a relation state?16:37
kwmonroeplars: i haven't seen that, but i think #juju-dev might know better16:37
plarskwmonroe: thanks16:37
=== frankban is now known as frankban|afk
cory_futinwood: You could, and there are some examples of charms that do that.  You could also just use RelationBase.from_state('state.name') to get the relation instance directly (or None)16:39
tinwoodcory_fu, that latter thing is JUST the ticket.  Thx!  (I thought I'd stared at the code, but I must have missed that).  I'll try to code it so I can revert to an @action() if it lands.  Thanks for your help.16:40
cory_futinwood: We don't tend to promote using from_state directly because it's generally better to make your preconditions clear with the decorators.16:42
cory_fuAnd no problem, glad to help16:42
tinwoodcory_fu, yes, i understand that - I'm going to try to get it as early as possible so that it can be converted to a 'proper' @action() @when('state') def... form.16:43
lazyPowerneil__ - sounds good. https://github.com/juju-solutions/interface-etcd-proxy/pull/416:49
=== X-Istence is now known as x58
=== sarnold_ is now known as sarnold
neil__lazyPower, your PRs all look good to me now.  Is there a way I can easily pull them together into a complete new charm to try out?18:02
lazyPowerneil__ in standup, give me 15 and i'll push an assembled version to my namespace18:03
neil__lazyPower, thank you - sorry to keep bothering!18:03
lazyPowerneil__ url: cs:~lazypower/etcd-18  if this revision works for you, ping me back and i'll propose it against the proper charm18:37
neil__lazyPower, thanks, will try that out now18:37
neil__lazyPower, cycle will take about 45 mins though, so please don't hold your breath!18:38
lazyPower:) I'm in no rush, I'm moving this week. I have to admit, Pods + movers = the way to do it.18:39
geethaHi , I have uploaded resource to the controller using `juju attach` command but when I try to fetch resource using `resource-get`, it's keep on trying to fetch the resource..(log : http://pastebin.ubuntu.com/18187857)/18:48
lazyPowergeetha - the pastebin looks truncated. can you paste the full log, or use a utility like `pastebinit` (which is apt-get installable) to send that paste over to paste.ubuntu.com?18:49
mskalkahey guys, I'm having an issue deploying a charm that I've written. It keeps spitting out the following error: ERROR POST https://10.18.150.54:17070/model/3362bfce-179e-44b0-8c02-b6b7bb238d85/charms?series=trusty: URL has invalid charm or bundle name: "local:trusty/charm-DataCenterTopology-0" Does anyone know what I should be investigating to fix this?18:50
lazyPowermskalka - try removing charm- from the name in metadata18:50
mskalkalazyPower, save error as before18:51
lazyPowermskalka - can you link me to your layer/charm?18:52
mskalkalazyPower - like to the repo?18:53
lazyPoweryep18:53
lazyPoweri'll clone it and see if i can reproduce here, and try to help you find a fix18:53
geethalazyPower: you can see full log here: http://paste.ubuntu.com/18188302/, its keep on going..18:54
neil__lazyPower (etcd), hmm: hook failed: "proxy-relation-joined" for neutron-api:etcd-proxy  Just going to investigate further.19:00
lazyPowergeetha - it looks like it ran on line 175219:01
lazyPoweri see voting bits below, which tells me the charm went idle19:01
lazyPowerhow large is the resource you are trying to fetch geetha?19:01
neil__lazyPower (etcd) - http://pastebin.com/r4UiF3LL19:02
lazyPowerdoh19:02
lazyPowerneil__ - sorry i know what i did there... duh19:02
lazyPowermy python is weak today19:02
kwmonroecory_fu: petevg, hive is in the same boat as zookeeper.. the current promulgated hive is non-layered, so it would have a broken upgrade path.  fortuantely, that one is only precise, so we should be able to drop in a xenial/trusty version without much hurt.19:06
kwmonroeso here's what i propose.. we find all the services that might conflict with an existing promulgated non-upgradable charm, then fire off a note to the list.  if people need precise hive, they'll need to be explicity in their deployment instructions and bundles.  same for zk.19:07
mskalkalazyPower - that did it! Thanks again!19:07
lazyPowermskalka happy to help :)19:07
petevgkwmonroe: I think that makes sense.19:08
geethalazyPower: The resource size is 163M...I have tested it already, it was not taking much time.19:11
geethaI am deploying charm from charm store and attaching resource using 'juju attach' command19:13
lazyPowergeetha - yeah without more information i'm not much help :( sorry. This looks like you've followed the correct process. You may have uncovered a bug, can you investigate the logs on your controller to see if there are any errors scrolling in there while its attempting to fetch the resource?19:19
kwmonroegeetha: is it still running?19:23
kwmonroegeetha: you might want to 'juju ssh' to the unit and have a look in /var/lib/juju/agents/unit-ibm-im/charm/resources to see if the file is still being fetched19:24
kwmonroefor anyone else seeing slow resource fetches, logs and observations would be great in bug 159492419:27
mupBug #1594924: resource-get is painfully slow <resources> <juju-core:Triaged by dooferlad> <https://launchpad.net/bugs/1594924>19:27
arosalescory_fu: promulgation issue https://github.com/juju/charm/issues/21419:27
arosalescory_fu: feel free to add any examples to that issue specifically if you find it occurs with zookeeper19:27
lazyPowerneil__ sorry about the delay i got a bit distracted. cs:~lazypower/etcd-19 - i deployed a hollow charm and verified the data on the wire looked good this time around, no more python errors :)19:30
neil__lazyPower, thanks, will give that a go now...19:42
neil__lazyPower, while that's coming up, could I ask you about my step?20:07
lazyPowersure20:07
neil__lazyPower, thanks. So, on the machines where I have etcd-using units, I need an etcd proxy that connects over the network on its db side (using 'cluster') and allows localhost access only on its client side.  I'm not yet sure if I need TLS-security for the localhost connections.20:10
lazyPoweryou wont, you'll need to provide the client keys on your proxy configuration however20:10
lazyPoweryou wont be able to communicate with the primary etcd cluster without that key.20:11
neil__lazyPower, Yes indeed, I definitely need the proxy to have keys on its connection to the non-proxies.  I believe I can get that using the requires part of interface-etcd-proxy - right?20:11
lazyPowerneil__ - yep. that interface is reactive based, so i dont know that you can consume it out of the box in your charm.. you're supporting a non layered approach right?20:13
neil__lazyPower, Is there a cast-iron argument for saying that TLS security isn't needed for the localhost connections?  (I'll be very happy if there is, but I'm not greatly experienced yet in security questions.)20:13
lazyPowerneil__ - with that being said, the keys are all there for you. cluster, and the 3 ssl keys.20:13
lazyPowerah, i dont think its required, thats kind of the point of the proxy right?20:13
lazyPowerthats solely up to you in the implementation details of that proxy20:14
lazyPoweri just gave you the pipeline to do so :)20:14
neil__Thanks.20:14
neil__At the moment, the etcd proxy function is integrated into the charms that need it (neutron-api and neutron-calico).  But I was thinking it might be nicer to have a separate etcd-local-proxy charm, and then just to deploy that alongside the other units that need it, and remove the etcd code from neutron-api and neutron-calico.20:16
neil__If I did that I guess it might be quite easy to do the new charm using reactive...?20:17
lazyPoweryep!20:18
lazyPowerand you can grab that interface code too, the conversation is done for you, just follow the placement guide. YOu'll need to update  the systemd defaults template for etcd so you can declare the tls options. thats all thats different that i can think of20:19
neil__Yes, that's what I was thinking.  But what do you mean by the placement guide?20:19
mskalkahey everyone, is there any way to specify machines to deploy to outside of the 'deploy --to' command? Like pre-configured in a config file or something similar20:21
neil__mskalka, In the bundle, yes.20:22
mskalkaneil__, thanks, I'll check that out20:23
neil__mskalka, Complication is, I think, that the supported declarations depend on what version of Juju you're using; and it's not well documented.20:25
valeechthis may be a bit off topic, but does ubuntu openstack autopilot leverage juju to deploy the services on maas devices?20:25
mskalkaneil__, haha 'not well documented' seems to be the phrase of the month. It gives me a place to work from though.20:26
neil__mskalka, But for Juju 2 the bundle can say, for example: "to: [ bird ]", which means "put the first unit of this service in the same place as bird"20:26
mskalkaneil__, bird in this example being another service?20:26
neil__mskalka, yes20:27
mskalkaneil__, that's exactly what I'm looking for actually20:27
neil__mskalka, some doc claims that you can specify machine numbers, but I've not got that to work reliably20:27
mskalkaneil__, I'm trying to get a charm deployed to every machine another charm operates on20:28
neil__mskalka, hmm, I think that's possible.  But you might also want to look up 'subordinate' charms20:30
neil__lazyPower, looks like your latest etcd charm is good: on the etcd proxy client machine I now have /etc/default/etcd with correct ETCD_INITIAL_CLUSTER.20:32
mskalkaneil__, I don't need to access any of the other charms on the machine, just gather information about the machine and its relation to other machines. It's basically a charm to create crushmaps for Ceph without actually touching the Ceph charm20:32
neil__lazyPower, the etcd proxy is still failing to connect to the cluster, but that's expected because I haven't implemented code to get the keys from the relation and add those into /etc/default/etcd.20:33
neil__mskalka, Sounds like you just need 'juju status' then.20:34
mskalkaneil__, if only.. it's got to be able to do some code execution20:35
lazyPowerneil__ - excellent20:55
lazyPowerneil__ - add the TLS keys to the defaults file and you should be in like flynn20:56
lazyPowerdo you need those? i'm pretty sure i have them in my design notes20:56
neil__do I need which?20:56
lazyPowerthe tls flags to provide the defaults file20:56
neil__sorry, I'm afraid I'm lost...20:56
lazyPowerneil__ https://gist.github.com/chuckbutler/3649337495ca3fa95bb6a3bdb11fc70f20:59
neil__sorry, still not quite understanding - what is it that supports those flags?21:01
lazyPowerneil__ : thats what you'll want to set in the defaults file for flags to etcd21:02
magicaltroutran a  40 m cat 5 cable the length of  my garden..... then find its broken21:03
magicaltroutwoop21:03
lazyPowerso, receive and write out those client certificates (the interface code does this for you if you're using that), and use the path you saved those client certs to populate those flags in the defaults file, and you should be g2g w/ the new etcd implementation21:03
lazyPowermagicaltrout - blarg, hardware problems21:03
magicaltroutindeed21:03
neil__lazyPower, Right, got it, thanks.21:04
neil__lazyPower, But I see two sets of possible settings: ETCD_CERT_FILE, ETCD_KEY_FILE, ETCD_TRUSTED_CA_FILE; and ETCD_PEER_CERT_FILE, ETCD_PEER_KEY_FILE, ETCD_PEER_TRUSTED_CA_FILE.  For a proxy connecting to a non-proxy, do you know which ones I need?  (I would guess the ones without _PEER_, but not at all sure about that.)21:06
lazyPowerthe ones without PEER assume server installation21:06
lazyPowerthose keys are client keys not server keys :)21:06
lazyPowerso i'm 90% certain you want the PEER flags21:07
=== urulama is now known as urulama|___
neil__lazyPower, Thanks, I think you're right - I found a note elsewhere that says "etcd proxies communicate with the cluster as peers so they need to have peer certificates." (http://docs.projectcalico.org/en/1.3.0/securing-calico.html)21:09
lazyPowersolid :) sounds like you're all set. Let me know how you make out with it. I'm going to be taking off in a bit21:10
cholcombethedac, mojo question for ya21:14
thedaccholcombe: sure21:14
cholcombethedac, i'm working on a mojo spec for gluster.  I'm wondering what i should put in the deploy config=gluster-default.yaml delay=0 wait=True target=${MOJO_SERIES} MOJO_SERIES field21:15
cholcombeit says it can't find 'trusty'21:15
cholcombethedac, i can show you the whole spec if you'd like.  i can push it up to a branch21:15
thedactarget is the name in the config file (gluster-default.yaml) that juju deployer uses to deploy. In openstack specs these like trusty-liberty and xenial-mitaka21:16
thedacBut it can be anything you named it in the bundle file21:16
cholcombei see21:16
cholcombethedac, cool i think that helps :)21:17
thedaccool, let me know if it down not21:17
cholcombethedac, ah yes this was the thing i was hitting.  i ran mojo again.  it says 'gluster' not found.  Available base.  When i try putting base that also fails21:18
cholcombethedac, i should prob push this up to lp so i can show ya21:19
thedaccholcombe: just as an example of multiple targets in a single bundle file http://bazaar.launchpad.net/~ost-maintainers/openstack-mojo-specs/mojo-openstack-specs/view/head:/helper/bundles/full.yaml21:19
thedacsure, it is probably the bundle file21:19
=== rye is now known as ryebot
cholcombethedac, http://bazaar.launchpad.net/~xfactor973/mojo/gluster/revision/26321:27
thedacok, I'll take a look21:27
cholcombethedac, i'm a n00b i don't know what the heck i'm doing lol21:28
thedaccholcombe: based on gluster-default.yaml you want target=base. Are you using juju 2.0? I don't think mojo is 2.0 ready21:31
cholcombethedac, i believe i'm using juju 1.x21:31
thedacok21:31
cholcombethedac, does it need a clean juju environment?21:31
thedacWell, at least one without gluster deployed21:32
cholcombeok cool21:32
cholcombei think it got further21:32
cholcombeit's complaining now about no charm metadata for precise/gluster/metadata.yaml21:32
cholcombei need to restrict it to trusty/xenial somehow21:32
thedacah, we need some more info in the bundle file.21:32
thedacYou can set series:21:33
thedaccholcombe: let me fix the bundle a bit. :)21:33
cholcombethedac, much appreciated :)21:33
thedaccholcombe: try this http://pastebin.ubuntu.com/18196928/21:37
cholcombethedac, interesting21:37
cholcombethedac, it's doing something \o/21:38
thedac:)21:38
=== setuid_ is now known as setuid
cholcombethedac, that got me to the testing part where it says it can't find my test script22:09
thedaccholcombe: let me look again22:10
cholcombei assume it copies the mojo dir onto the unit somewhere?22:10
thedacyes. /srv/mojo/$MOJO_PROJECT/$MOJO_SERIES/$MOJO_WORKSPACE22:11
cholcombehmm nothing is on there22:11
thedaccholcombe: on your local not the instance22:11
cholcombeok22:11
cholcombethedac, i think i have a typo22:12
thedacah yes, test_gluster_store.py vs test_gluster.py22:12
cholcomberight22:13
cholcombelooks like once the service is up it's quick to change stuff and retest22:13
thedacYes, the deploy is the slowest bit22:13
cholcombethedac, success!22:14
thedac\o/22:14
cholcombe:)22:14
cholcombethedac, alright cool i'm going to put this up for review22:17
thedacsounds good. I am heads down the rest of my afternoon. but I can take a look tomorrow22:17
cholcombesure thing22:17
cholcombethedac, thanks a bunch for the help :)22:17

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