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

magicaltroutcan you build a reactive charm without layer basic?00:21
magicaltrouti need to build a centos charm..00:22
magicaltroutclearly not, you need to bootstrap wheelhouse00:25
magicaltroutbugger00:25
marcoceppimagicaltrout: you can build a centos charm with charm build, but there are a few calls in lib/charms/layers/basic.py that apt-install00:43
marcoceppimagicaltrout: theoretically, you could create a layer:centos which overwrites that file with yum calls ;)00:44
marcoceppimagicaltrout: what we really should do is have layer:ubuntu, layer:centos, layer:windows which all inherit the layer basic but have their own, language specific boostrap mechanisms00:44
lazyPowerThere's some charmhelpers submissions from cloudbase we still need to land that came with a ton of centos abstractions00:44
marcoceppimagicaltrout: I'll poke cory_fu about it tomorrow00:45
PrabakaranHi Matt, As discussed in the previous call i have made some changes in the copyright file and reactive file of ibm-java, i pushed my latest code to launchpad but i am not able to see that particular revision with the changes in the charm store.00:49
PrabakaranCould someone please advise me on this?00:51
PrabakaranHi Matt, As discussed in the previous call i have made some changes in the copyright file and reactive file of ibm-java, i pushed my latest code to launchpad but i am not able to see that particular revision with the changes in the charm store.00:59
Prabakaranthat time i push ibm-java charm push we were not doing it. If we do charm push for ibm-java it may affect the ageing in the review queue. So I have pushed my latest code in the launchpad only00:59
magicaltroutif I create a test charm for centos and do01:54
magicaltrout juju deploy --repository=. local:centos7/joshua-decoder01:54
magicaltrouti end up in a machine error state without anything appearing in juju debug-log01:54
magicaltroutany ideas?01:54
magicaltrout6          error                  pending                                             centos701:55
=== rodlogic is now known as Guest75713
=== rodlogic is now known as Guest21818
cheryljmagicaltrout: if you do a status --format=yaml, you should get some more info about what happened with provisioning02:58
deanmanIs it possible to use manual provider to create a small group of workload VMs but instead of using KVM by default to deploy service to use lxc instead without having to use the --to lxc: command ?05:06
=== blahdeblah_ is now known as blahdeblah
=== frankban|afk is now known as frankban
magicaltroutmarcoceppi: had a good chat today with a few of the guys, we have a Apache Joshua and Apache Nutch as good candidates for Juju integration soon08:49
magicaltroutthere was also good buy in from people about a jujucharms.com/apache type url that I discussed with arosales09:08
magicaltroutof course for that type of thing I carry no official weight but the idea was well recieved09:09
hoenirit is stable enough  to upgrade to 16.04 lts ubuntu server with maas2.0 for juju?10:02
=== rodlogic is now known as Guest45407
marcoceppimagicaltrout: sounds good, I know we can totally do something like jujucharms.com/apache if the community is interested in doing so12:14
marcoceppimagicaltrout: I've never heard of nutch, but looks cool12:14
=== rodlogic is now known as Guest44812
jcastrooffice hours in ~1 hour folks!12:54
arosalesmagicaltrout: I'll be talking to the design folks in person next week and will bring this up13:12
arosalesGood suggestion magicaltrout. Travel safely!13:21
=== rodlogic is now known as Guest56723
jcastrohttps://hangouts.google.com/hangouts/_/hoaevent/AP36tYfaxhNCLABMdXEeSBUmjxyh4UyCe5HbASMOwP-CGMF3ru8MtA?hl=en&authuser=013:53
jcastrohangout url for office hours if you want to hang out!13:54
marcoceppiOffice hours is live, http://ubuntuonair.com/ ask your questions here and we'll do our best to answer them14:04
=== rodlogic is now known as Guest81137
=== fginther` is now known as fginther
tvansteenburghahasenack: i finally discovered the world of bzr-builder and pbuilder and am working through the deployer build issues locally14:28
ahasenacknice14:29
cholcombethis is a silly question but where do you indicate which ubuntu release versions your charm works for?  I'd also like to indicate one of my charms works for centos714:38
lazyPowercholcombe - see: series in metdata in the release notes14:40
cholcombelazyPower, ah thanks :)14:40
* lazyPower points @ topic14:40
lazyPower:)14:40
cholcombelazyPower, i'm having trouble finding it14:42
=== rodlogic is now known as Guest5666
cholcombelazyPower, i think i found it. i need to upload a branch for xenial14:45
lazyPowercholcombe - you just declare in metadata.yaml, and you dont push to a series14:46
lazyPowerso, if my charm defines:14:46
lazyPowerseries: ['trusty', 'xenial']14:46
lazyPowerand i push foobar to cs:~lazypower/foobar - you can deploy either supported series at deploy time14:46
cholcombelazyPower, interesting.  i haven't seen any charms do that.  I'm going to try it :)14:47
lazyPowerjuju deploy cs:~lazypower/foobar --series=trusty14:47
cholcomberight14:47
cholcombeok cool14:47
lazyPowercholcombe - cs:~lazypower/etcd-7 does this14:47
cholcombeah ok. i was thinking of the ceph* and some of the openstack charms i poked at14:47
lazyPowerbut it also has a dependency on resources, so provide those bins if you are testing14:47
cholcombeok14:47
lazyPower(my etcd thing, not ceph)14:47
lazyPower<314:47
neiljerramlazyPower, hi there!14:51
lazyPowero/ neiljerram14:51
neiljerramlazyPower, I'm working on that neutron-calico <-> etcd change, but I think I'm still getting it wrong somehow.14:51
lazyPoweri'm all ears14:52
neiljerramlazyPower, the error is: ERROR cannot deploy bundle: cannot add relation between "neutron-api:etcd-proxy" and "etcd:db": no relations found14:52
neiljerramI changed the neutron-calico metadata to say this:14:53
neiljerramrequires:14:53
neiljerram  [...]14:53
neiljerram  etcd-proxy:14:53
neiljerram    interface: etcd14:53
neiljerramIs that what you would expect?14:53
neiljerramI'm not sure what the difference is between relation name and interface name.14:54
lazyPoweryep. i think i see what i did (and its not necessarily good) - change the relation interface at the bottom of the bundle from "etcd:db" to "etcd:client"14:54
lazyPowerso long as the interfaces match, it should work. I think i declared a different relation name on etcd... which i shouldn't have14:54
neiljerramOh OK.  Is "client", in that context, an interface name or a relation name?14:54
lazyPowerthe relation name14:55
neiljerramOK, so the correct etcd-side relation name is "client".14:55
neiljerramCool, I'll give that a go.14:55
neiljerramActually no, hang on, I was misreading...14:56
lazyPowerneiljerram - and yeah i didnt change the relation name14:57
neiljerramThe error that I'm now seeing is for neutron-api, not neutron-calico.14:57
lazyPowerah ok14:57
neiljerramFor neutron-calico it says: related neutron-calico:etcd-proxy and etcd:db14:57
lazyPowersorry for the red herring, i should have looked first.14:57
cholcombei'm late to the party but this charm publish thing is really cool :)14:58
lazyPowerso long as the etcd-proxy relation is using the etcd interface, that should work as a drop in until we get the TLS certificates added to the interface data-pass14:58
neiljerramSo neutron-calico may be working.  I'd expect an error for neutron-api, because I haven't updated its code yet.  (It needs the same kind of change as neutron-calico.)14:58
neiljerramCool, so I'll make a similar change now in neutron-api...14:58
lazyPowerneiljerram - so, on the bright side if this basic test works for you, i have another version published which will tls terminate your endpoints, and i'm pending the last bits of code in the interface for client certs. we're very close to having POC14:59
neiljerramlazyPower, That's great, thanks!14:59
lazyPowerso you'll get a secure etcd cluster, but nobody can connect to it with what i have done right now14:59
neiljerramBTW, what is the correct Juju 2 incantation for tearing down a deployment, so that I can try again with modified charms?15:02
neiljerramPerhaps juju destroy-model ? - but I really just want to undeploy all the units.15:04
marcoceppineiljerram: that's it15:04
marcoceppionce you destroy model, you can juju create-model and get a fresh canvas15:05
lazyPoweryep, marcoceppi has the science15:07
neiljerrammarcoceppi, thanks15:09
marcoceppiany questions for the office hours?15:10
neiljerramlazyPower, Another random query just arose... does anything in your etcd work rely on Juju 2?  Because I've just heard that the project that I'm involved in is dropping back to 1.25...15:34
lazyPowerneiljerram - its 2.0 only, correct15:36
neiljerramWhat are the 2.0 specific aspects?15:37
lazyPowerresources15:37
lazyPowerresources and series in metadata both cause 1.25 to complain and not function15:37
lazyPowerer wait, series in metadata was fixed i rescind that bit.15:37
lazyPowerresources however are a firm 2.0 freature15:38
neiljerramBut if my target is Xenial - which it is - will we be saved by the fallback kicking in?15:38
lazyPoweronly if you use a local charm deploy15:39
lazyPowerso, in short:15:39
lazyPowercharm pull cs:~lazypower/etcd-615:39
lazyPowerthen put the full path to that local charm in your bundle15:40
lazyPowerthe way resources populate from the store will be a constant problem until https://bugs.launchpad.net/juju-core/+bug/1577415 is resolved15:41
mupBug #1577415: resource-get hangs when trying to deploy a charm with resource from the store <juju-release-support> <resources> <juju-core:Triaged> <https://launchpad.net/bugs/1577415>15:41
=== rodlogic is now known as Guest63438
rick_h_lazyPower: can you make sure juju-min-version is set?15:46
lazyPowerrick_h_ https://github.com/juju-solutions/layer-etcd/blob/master/metadata.yaml#L1415:47
lazyPowerigotchoobb15:47
rick_h_lazyPower:  we should look ay updating the charmstore on those to help that case15:47
rick_h_lazyPower: <315:47
lazyPowerneiljerram - i'm going to dip out for a quick lunch. Ping if you need me in the meanwhile.15:51
neiljerramOK, cool, I think that's OK for now.15:51
neiljerramThanks!15:51
=== rye_ is now known as ryebot
tvansteenburghrick_h_: the new charm Review Queue needs this https://github.com/juju/charmstore-client/issues/5716:07
tvansteenburghrick_h_: thoughts?16:07
magicaltroutcory_fu: i need to create a charm that has access to the hadoop executable16:33
magicaltroutcan I do it? and what do I make it subordinate to?16:34
cory_fumagicaltrout: Have it use the hadoop-client base layer which will enable it to connect to the plugin and then it can connect to either the vanilla Apache Hadoop charms or the Apache Bigtop Hadoop charms16:35
magicaltroutfscking cool!16:35
magicaltrouti shall do that, thanks16:35
cory_fumagicaltrout: https://github.com/juju-solutions/layer-hadoop-client/blob/master/README.md16:35
cory_fuHad good info16:35
=== rodlogic is now known as Guest63003
magicaltroutcory_fu: also, is it possible for an action to set a reactive state? For example I don't want my serivce to start until someone executes an action to configure some stuff16:50
cory_fumagicaltrout: Absolutely.  If your action is in bash, it can use `charms.reactive set_state foo`.  If it's in Python, just `from charms.reactive import set_state; set_state('foo')` like normal16:51
magicaltroutcool thanks16:51
cholcombefor the local juju provider do you have to download a xenial image or something if you're running trusty?16:54
lazyPowercholcombe - the first time you deploy a xenial series charm it will fetch the base image and create the template, yes16:56
lazyPowerand when you say local i assume you mean 1.25 local provider16:56
cholcombelazyPower, correct16:56
lazyPoweryep, thats all valid info then16:56
thedacbeisner: https://review.openstack.org/#/q/topic:bug/1581171 should help with Bug#158117117:02
mupBug #1581171: pause/resume failing <uosci> <cinder (Juju Charms Collection):In Progress by thedac> <glance (Juju Charms Collection):In Progress by thedac> <keystone (Juju Charms Collection):In Progress by thedac> <https://launchpad.net/bugs/1581171>17:02
beisnerthedac, thx.  i think you'll want to rm the __pycache__ bits that got checked in on those reviews though17:03
thedacbeisner: good catch17:04
beisnerthedac, likewise ;-)17:05
beisnerthedac, keystone's python process not running/binding @ https://openstack-ci-reports.ubuntu.com/artifacts/test_charm_pipeline/openstack/charm-keystone/316195/2/2016-05-13_17-07-45/index.html   (see keystone-0-listening.bz2)17:49
beisnerthedac, i've been seeing that intermingled with this pause/resume thing, may be a separate bug though17:50
beisnerso the amulet test tries to initialize a keystone client whilst the charm is in that state17:50
beisnerultimately, the tests will race if/when workload status "Ready" isn't actually the case of course.17:51
thedacbeisner: hmm, I'll run that one locally17:55
cholcombelazyPower, i got too crazy with metadata series :).  charm push doesn't allow centos and ubuntu mixed series18:03
beisnerthedac, looking at the unit log, i actually expect us to race all over the place.  one small snippet of what looks to be a common "I'm Ready ... No, wait.  Watch me fire a hook and render some templates again.." funnybusiness.  http://pastebin.ubuntu.com/16394586/18:07
beisnerthedac, err, this paste i mean:  http://pastebin.ubuntu.com/16394637/18:08
thedaclooking18:09
thedacWell, I expect the update-status hook will re-render config files. So I am not sure that is a problem18:11
lazyPowercholcombe - nope, no cross-distro series sir18:17
lazyPowerit'll require another layer18:17
cholcombesad18:17
lazyPowerthankfully with layers, you can do that pretty cheaply18:17
thedacbeisner: I suspect set_api_version in basic_deployment.py is racing the config change.18:17
lazyPowercholcombe - we've talked about making another layer up -  layer:ubuntu, layer:centos, layer:windows18:18
cholcombelazyPower, that'd be nice :)18:18
lazyPowerwhich all inherit from layer:basic, and give you all the amenities you need for each platform starting with that layer18:18
lazyPowerbut we haven't got anything concrete18:18
lazyPowerso, if you're interested, my thought is poke dbulgia@cloudbase, as he has a lot of work already done to abstract host level bits for centos (see: charm-helpers pr listing), and would be a good stakeholder for a first centos layer.18:19
lazyPowerand i'm fairly certain he would be super jazzed to be working with a charmer  :)18:19
beisnerthedac, that looks to be the case.  but set_api_version comes later than init, where self._auto_wait_for_status happens18:22
beisnerb/c we guard _initialize_tests with the wait for status bits18:23
beisnerin __init__18:23
thedacRight but this is failing at test_112_keystone_tenants. There are multiple calls to set_api_version none of which doing any waiting to make sure it is done if it changed18:24
thedacbiesner: just do a search for set_api_version. It has the possiblilty of changing multiple times https://github.com/openstack/charm-keystone/blob/master/tests/basic_deployment.py#L34618:26
beisnerright-o indeed!18:26
beisnerthere needs to be a wait for status on every one of those18:26
beisnernot just a retry diaper18:26
thedacRight18:26
* beisner <3 chasing 🏁 🐞18:27
thedacbeisner: suggest http://pastebin.ubuntu.com/16395138/18:27
thedacDoes that seem reasonable to you18:28
beisneryah just like we've done in rmq, dashboard and wherever else18:28
thedacOk, pushed up to reviews. Let's watch CI18:29
=== frankban is now known as frankban|afk
beisnerthis is actually the first time i've looked at the ks v3 amulet tests.  def-o need some race avoidance18:29
magicaltroutmarcoceppi / kwmonroe : what needs to happen to get openjdk charm on xenial?18:32
cory_fumagicaltrout: I think we just need to push it.  I don't see any reason why it wouldn't work18:33
cory_fuGive me a second18:33
magicaltroutthanks18:33
magicaltrouti've cloned it locally so i can check that, but it sucks for normal people ;)18:34
cory_fumagicaltrout: A verification would be great.  I'm going to add the series to the metadata and PR that18:35
cory_fulazyPower: What's the syntax for series in metadata?  Just "series: [trusty, xenial]"?18:35
lazyPoweryep18:35
marcoceppicory_fu: preferablly18:35
magicaltrouthold up18:35
marcoceppiseries:18:35
marcoceppi  - trusty18:35
marcoceppi  - xenial18:35
Merlijn_S@cory_fu I'm here :)18:35
magicaltroutit's exploded18:35
cory_fumagicaltrout: Oh noes18:36
magicaltrout Package 'openjdk-7-jre-headless' has no installation candidate18:36
cory_fuMerlijn_S: Ok, give me a sec to set it up18:36
=== rodlogic is now known as Guest72878
cory_fuMerlijn_S: https://plus.google.com/hangouts/_/canonical.com/eco-wx18:37
magicaltroutah yeah xenial is java8+18:37
cory_fumagicaltrout: I thought it should use the default Java for the series by default18:37
cory_fuBut you can set the config option to use 818:37
magicaltroutyeah, kwmonroe set it to do       apt-get install -qqy openjdk-${java_major}-jre-headless openjdk-${java_major}-jdk18:38
magicaltroutso its broken by design ;)18:38
cory_fuAh.  Ok.  Hrm.18:39
cory_fuWe'd want a different default value for each series, then18:39
beisnerthedac, my amulet --> venv full recheck passed for glance (but with the pause/resume test disabled):  https://review.openstack.org/#/c/315777/18:43
beisnerthedac, next - let's land your glance thing then i'll rebase and re-enable that test, yah?18:43
thedacSounds good. Can you do the +2 honors18:43
beisnerthedac, indeed.  meanwhile, can you give https://review.openstack.org/#/c/315777/ a pass-through and call out anything that's not clear?  worth starting in the README_TESTS.md update to see the new usage, etc.18:44
thedacSure, I'll get to that after lunch.18:44
beisnerthedac, thx, thx, and thanks.   maybe one more tyvm, i'm losing track. ;-)18:45
thedac:)18:46
magicaltroutyeah cory_fu works fine when i set the major version18:47
=== rodlogic is now known as Guest18774
lazyPowertvansteenburgh - have we done any amulet tests against any multi-series charms?19:12
tvansteenburghi have19:13
lazyPowergood results?19:13
lazyPower i've defined series='xenial' in my deployment, yet i'm still getting trusty flavored charms deployed in my tests. :(  so pebkac somewhere19:13
tvansteenburghhmm19:13
lazyPowerok weird19:16
lazyPowerif i define xenial as the first series in my charm, i get a xenial series charm19:16
tvansteenburghlazyPower: yeah...can you file a bug on this, pretty sure i know what's going on19:17
lazyPowersure thing, inc.19:17
tvansteenburghlazyPower: was trusty the first one in the list before?19:18
lazyPowerhttps://github.com/juju/amulet/issues/13719:20
lazyPoweryep19:20
beisnerthedac, glance merged, rebased, smoke passed, full now underway19:40
beisnerthedac, as an aside - based on most recent fail on dosaboy's https://review.openstack.org/#/c/314063/ - i suspect rmq is also status racing.  in that one, rmq was listening but status was blocked, waiting for it to start.19:42
magicaltroutcory_fu: what am I doing wrong?19:45
magicaltrouthttps://gist.github.com/buggtb/a6cb65333e63bc3c905f088469c2fdca#file-gistfile1-txt-L2919:45
magicaltrouthttps://gist.github.com/buggtb/b09631cd57531a730798545ca82c8e2f#file-gistfile1-txt-L1119:45
magicaltroutignore me19:45
magicaltroutmy update hadn't fired.....19:45
cory_fumagicaltrout: Yeah, that action sets the state, but the reactive dispatch loop isn't running so it doesn't have a chance to handle the state.  You can manually call hooks/update-status after setting the state in the action19:46
cory_fuThere are proposals to make actions part of the reactive dispatch loop, which would make it work a bit clearer19:47
magicaltroutcool19:47
=== rodlogic is now known as Guest56132
thedacbeisner: ok, rabbitmq will have to go on the pile20:00
beisnerthedac, ack.  also see comment on your keystone review20:01
thedacok20:03
thedacbeisner: mind doing cinder so it does not get lost? https://review.openstack.org/#/c/316194/20:04
beisnerthedac, yep i'm going to do the same there.  land, rebase into my test refactor, retest.20:04
thedacgot it20:05
tvansteenburghahasenack: hey, one thing i wasn't clear on re version updates to debian/changelog in the packaging branch...do you just update that when you notice the upstream version has changed?20:24
tvansteenburghahasenack: and how is that version (e.g. 0.52.0-0ubuntu1~ppa1) constructed? is that a dch thing?20:26
ahasenacktvansteenburgh: the recipe grabs the debversion from the last changelog entry, and appends what the recipe instructs20:26
ahasenack{debupstream}~bzr{revno}~{revno:packaging}20:27
ahasenack"debupstream" is the version20:27
ahasenacktaken from changelog20:27
ahasenackthe rest in the changelog is ignored20:27
ahasenackso I don't have to update the changelog everytime there is a change in the bzr branch the recipe monitors20:27
tvansteenburghah, okay, so do you manually type the new version into the changelog?20:28
tvansteenburghwas wondering about the ~ppa1 or ~ppa2 bits on the end20:29
ahasenackI do that out of convention20:29
ahasenackwhen uploading to ppas20:29
ahasenackthat comes with the help of dch, yes20:29
tvansteenburghokay cool, thanks20:29
ahasenackbut it's ignored by the recipe because it's in the release portion of the package full version number20:29
ahasenackso it's not inside {debupstream} above20:30
ahasenackbut helps if doing a manual build locally20:30
tvansteenburghgotcha20:30
marcoceppitvansteenburgh: yeah, for releasing, you'll need to update the debian packaging branch20:30
marcoceppitvansteenburgh: I can so you my workflow if you're curious20:31
tvansteenburghmarcoceppi: yeah, i think i get it now. update changelog for new version. but yeah, wouldn't hurt to walk through it once20:36
=== natefinch is now known as natefinch-afk
tvansteenburghmarcoceppi: we should do an amulet release soon20:37
* marcoceppi mods20:37
tvansteenburghfor the juju2 stuff in particular20:38
marcoceppiyeah20:38
marcoceppitvansteenburgh: is it ready to go today?20:39
tvansteenburghmarcoceppi: yep20:39
lazyPoweri'm doing the hallway test rn20:39
lazyPowerif that helps confidence any :D20:39
tvansteenburghmarcoceppi: merge #137 first20:39
marcoceppiits friday, the 13th, whats the worse that could happen20:39
tvansteenburghhaha20:39
lazyPoweroh man, this is glorious. clean output from everything with tip of our tooling.20:44
marcoceppi\o/20:44
marcoceppitime to release20:44
lazyPowertvansteenburgh - passes the lazypower test20:44
lazyPower\o/20:44
tvansteenburghsweet20:45
=== rodlogic is now known as Guest76655
marcoceppitvansteenburgh: should we start an amulet daily ppa?20:48
tvansteenburghmarcoceppi: sure20:48
marcoceppieh, later20:48
tvansteenburghactually i was just gonna build all the dailies into one ppa20:48
tvansteenburghis there a reason to have a separate ppa for every package?20:49
marcoceppitvansteenburgh: possibly, but I'm a +1 to a charm-testing daily ppa20:52
tvansteenburghok20:53
marcoceppiokay, 1.15.0 is out21:04
tvansteenburghwoot21:05
tvansteenburghthanks21:05
lazyPowernice21:05
* beisner likes those ideas! ^21:07
=== rodlogic is now known as Guest11340
beisnerthedac, gears are all turning.   fwiw, that rmq thing 2 for 2 on dosaboy's review.  i've not poked further or logged it on the bug, but i think it's same/similar topic.  thanks again for drilling down on those today.22:00
thedacno problem. Seems we have lots of races to track down22:02
=== rodlogic is now known as Guest78418
=== rodlogic is now known as Guest28531

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