[00:21] can you build a reactive charm without layer basic? [00:22] i need to build a centos charm.. [00:25] clearly not, you need to bootstrap wheelhouse [00:25] bugger [00:43] magicaltrout: you can build a centos charm with charm build, but there are a few calls in lib/charms/layers/basic.py that apt-install [00:44] magicaltrout: theoretically, you could create a layer:centos which overwrites that file with yum calls ;) [00:44] magicaltrout: 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 mechanisms [00:44] There's some charmhelpers submissions from cloudbase we still need to land that came with a ton of centos abstractions [00:45] magicaltrout: I'll poke cory_fu about it tomorrow [00:49] Hi 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:51] Could someone please advise me on this? [00:59] Hi 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] that 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 only [01:54] if I create a test charm for centos and do [01:54] juju deploy --repository=. local:centos7/joshua-decoder [01:54] i end up in a machine error state without anything appearing in juju debug-log [01:54] any ideas? [01:55] 6 error pending centos7 === rodlogic is now known as Guest75713 === rodlogic is now known as Guest21818 [02:58] magicaltrout: if you do a status --format=yaml, you should get some more info about what happened with provisioning [05:06] Is 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 ? === blahdeblah_ is now known as blahdeblah === frankban|afk is now known as frankban [08:49] marcoceppi: 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 soon [09:08] there was also good buy in from people about a jujucharms.com/apache type url that I discussed with arosales [09:09] of course for that type of thing I carry no official weight but the idea was well recieved [10:02] it is stable enough to upgrade to 16.04 lts ubuntu server with maas2.0 for juju? === rodlogic is now known as Guest45407 [12:14] magicaltrout: sounds good, I know we can totally do something like jujucharms.com/apache if the community is interested in doing so [12:14] magicaltrout: I've never heard of nutch, but looks cool === rodlogic is now known as Guest44812 [12:54] office hours in ~1 hour folks! [13:12] magicaltrout: I'll be talking to the design folks in person next week and will bring this up [13:21] Good suggestion magicaltrout. Travel safely! === rodlogic is now known as Guest56723 [13:53] https://hangouts.google.com/hangouts/_/hoaevent/AP36tYfaxhNCLABMdXEeSBUmjxyh4UyCe5HbASMOwP-CGMF3ru8MtA?hl=en&authuser=0 [13:54] hangout url for office hours if you want to hang out! [14:04] Office hours is live, http://ubuntuonair.com/ ask your questions here and we'll do our best to answer them === rodlogic is now known as Guest81137 === fginther` is now known as fginther [14:28] ahasenack: i finally discovered the world of bzr-builder and pbuilder and am working through the deployer build issues locally [14:29] nice [14:38] this 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 centos7 [14:40] cholcombe - see: series in metdata in the release notes [14:40] lazyPower, ah thanks :) [14:40] * lazyPower points @ topic [14:40] :) [14:42] lazyPower, i'm having trouble finding it === rodlogic is now known as Guest5666 [14:45] lazyPower, i think i found it. i need to upload a branch for xenial [14:46] cholcombe - you just declare in metadata.yaml, and you dont push to a series [14:46] so, if my charm defines: [14:46] series: ['trusty', 'xenial'] [14:46] and i push foobar to cs:~lazypower/foobar - you can deploy either supported series at deploy time [14:47] lazyPower, interesting. i haven't seen any charms do that. I'm going to try it :) [14:47] juju deploy cs:~lazypower/foobar --series=trusty [14:47] right [14:47] ok cool [14:47] cholcombe - cs:~lazypower/etcd-7 does this [14:47] ah ok. i was thinking of the ceph* and some of the openstack charms i poked at [14:47] but it also has a dependency on resources, so provide those bins if you are testing [14:47] ok [14:47] (my etcd thing, not ceph) [14:47] <3 [14:51] lazyPower, hi there! [14:51] o/ neiljerram [14:51] lazyPower, I'm working on that neutron-calico <-> etcd change, but I think I'm still getting it wrong somehow. [14:52] i'm all ears [14:52] lazyPower, the error is: ERROR cannot deploy bundle: cannot add relation between "neutron-api:etcd-proxy" and "etcd:db": no relations found [14:53] I changed the neutron-calico metadata to say this: [14:53] requires: [14:53] [...] [14:53] etcd-proxy: [14:53] interface: etcd [14:53] Is that what you would expect? [14:54] I'm not sure what the difference is between relation name and interface name. [14:54] yep. 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] so long as the interfaces match, it should work. I think i declared a different relation name on etcd... which i shouldn't have [14:54] Oh OK. Is "client", in that context, an interface name or a relation name? [14:55] the relation name [14:55] OK, so the correct etcd-side relation name is "client". [14:55] Cool, I'll give that a go. [14:56] Actually no, hang on, I was misreading... [14:57] neiljerram - and yeah i didnt change the relation name [14:57] The error that I'm now seeing is for neutron-api, not neutron-calico. [14:57] ah ok [14:57] For neutron-calico it says: related neutron-calico:etcd-proxy and etcd:db [14:57] sorry for the red herring, i should have looked first. [14:58] i'm late to the party but this charm publish thing is really cool :) [14:58] so 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-pass [14:58] So 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] Cool, so I'll make a similar change now in neutron-api... [14:59] neiljerram - 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 POC [14:59] lazyPower, That's great, thanks! [14:59] so you'll get a secure etcd cluster, but nobody can connect to it with what i have done right now [15:02] BTW, what is the correct Juju 2 incantation for tearing down a deployment, so that I can try again with modified charms? [15:04] Perhaps juju destroy-model ? - but I really just want to undeploy all the units. [15:04] neiljerram: that's it [15:05] once you destroy model, you can juju create-model and get a fresh canvas [15:07] yep, marcoceppi has the science [15:09] marcoceppi, thanks [15:10] any questions for the office hours? [15:34] lazyPower, 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:36] neiljerram - its 2.0 only, correct [15:37] What are the 2.0 specific aspects? [15:37] resources [15:37] resources and series in metadata both cause 1.25 to complain and not function [15:37] er wait, series in metadata was fixed i rescind that bit. [15:38] resources however are a firm 2.0 freature [15:38] But if my target is Xenial - which it is - will we be saved by the fallback kicking in? [15:39] only if you use a local charm deploy [15:39] so, in short: [15:39] charm pull cs:~lazypower/etcd-6 [15:40] then put the full path to that local charm in your bundle [15:41] the way resources populate from the store will be a constant problem until https://bugs.launchpad.net/juju-core/+bug/1577415 is resolved [15:41] Bug #1577415: resource-get hangs when trying to deploy a charm with resource from the store

=== rodlogic is now known as Guest63438 [15:46] lazyPower: can you make sure juju-min-version is set? [15:47] rick_h_ https://github.com/juju-solutions/layer-etcd/blob/master/metadata.yaml#L14 [15:47] igotchoobb [15:47] lazyPower: we should look ay updating the charmstore on those to help that case [15:47] lazyPower: <3 [15:51] neiljerram - i'm going to dip out for a quick lunch. Ping if you need me in the meanwhile. [15:51] OK, cool, I think that's OK for now. [15:51] Thanks! === rye_ is now known as ryebot [16:07] rick_h_: the new charm Review Queue needs this https://github.com/juju/charmstore-client/issues/57 [16:07] rick_h_: thoughts? [16:33] cory_fu: i need to create a charm that has access to the hadoop executable [16:34] can I do it? and what do I make it subordinate to? [16:35] magicaltrout: 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 charms [16:35] fscking cool! [16:35] i shall do that, thanks [16:35] magicaltrout: https://github.com/juju-solutions/layer-hadoop-client/blob/master/README.md [16:35] Had good info === rodlogic is now known as Guest63003 [16:50] cory_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 stuff [16:51] magicaltrout: 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 normal [16:51] cool thanks [16:54] for the local juju provider do you have to download a xenial image or something if you're running trusty? [16:56] cholcombe - the first time you deploy a xenial series charm it will fetch the base image and create the template, yes [16:56] and when you say local i assume you mean 1.25 local provider [16:56] lazyPower, correct [16:56] yep, thats all valid info then [17:02] beisner: https://review.openstack.org/#/q/topic:bug/1581171 should help with Bug#1581171 [17:02] Bug #1581171: pause/resume failing [17:03] thedac, thx. i think you'll want to rm the __pycache__ bits that got checked in on those reviews though [17:04] beisner: good catch [17:05] thedac, likewise ;-) [17:49] thedac, 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:50] thedac, i've been seeing that intermingled with this pause/resume thing, may be a separate bug though [17:50] so the amulet test tries to initialize a keystone client whilst the charm is in that state [17:51] ultimately, the tests will race if/when workload status "Ready" isn't actually the case of course. [17:55] beisner: hmm, I'll run that one locally [18:03] lazyPower, i got too crazy with metadata series :). charm push doesn't allow centos and ubuntu mixed series [18:07] thedac, 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:08] thedac, err, this paste i mean: http://pastebin.ubuntu.com/16394637/ [18:09] looking [18:11] Well, I expect the update-status hook will re-render config files. So I am not sure that is a problem [18:17] cholcombe - nope, no cross-distro series sir [18:17] it'll require another layer [18:17] sad [18:17] thankfully with layers, you can do that pretty cheaply [18:17] beisner: I suspect set_api_version in basic_deployment.py is racing the config change. [18:18] cholcombe - we've talked about making another layer up - layer:ubuntu, layer:centos, layer:windows [18:18] lazyPower, that'd be nice :) [18:18] which all inherit from layer:basic, and give you all the amenities you need for each platform starting with that layer [18:18] but we haven't got anything concrete [18:19] so, 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] and i'm fairly certain he would be super jazzed to be working with a charmer :) [18:22] thedac, that looks to be the case. but set_api_version comes later than init, where self._auto_wait_for_status happens [18:23] b/c we guard _initialize_tests with the wait for status bits [18:23] in __init__ [18:24] Right 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 changed [18:26] biesner: 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#L346 [18:26] right-o indeed! [18:26] there needs to be a wait for status on every one of those [18:26] not just a retry diaper [18:26] Right [18:27] * beisner <3 chasing 🏁 🐞 [18:27] beisner: suggest http://pastebin.ubuntu.com/16395138/ [18:28] Does that seem reasonable to you [18:28] yah just like we've done in rmq, dashboard and wherever else [18:29] Ok, pushed up to reviews. Let's watch CI === frankban is now known as frankban|afk [18:29] this is actually the first time i've looked at the ks v3 amulet tests. def-o need some race avoidance [18:32] marcoceppi / kwmonroe : what needs to happen to get openjdk charm on xenial? [18:33] magicaltrout: I think we just need to push it. I don't see any reason why it wouldn't work [18:33] Give me a second [18:33] thanks [18:34] i've cloned it locally so i can check that, but it sucks for normal people ;) [18:35] magicaltrout: A verification would be great. I'm going to add the series to the metadata and PR that [18:35] lazyPower: What's the syntax for series in metadata? Just "series: [trusty, xenial]"? [18:35] yep [18:35] cory_fu: preferablly [18:35] hold up [18:35] series: [18:35] - trusty [18:35] - xenial [18:35] @cory_fu I'm here :) [18:35] it's exploded [18:36] magicaltrout: Oh noes [18:36] Package 'openjdk-7-jre-headless' has no installation candidate [18:36] Merlijn_S: Ok, give me a sec to set it up === rodlogic is now known as Guest72878 [18:37] Merlijn_S: https://plus.google.com/hangouts/_/canonical.com/eco-wx [18:37] ah yeah xenial is java8+ [18:37] magicaltrout: I thought it should use the default Java for the series by default [18:37] But you can set the config option to use 8 [18:38] yeah, kwmonroe set it to do apt-get install -qqy openjdk-${java_major}-jre-headless openjdk-${java_major}-jdk [18:38] so its broken by design ;) [18:39] Ah. Ok. Hrm. [18:39] We'd want a different default value for each series, then [18:43] thedac, my amulet --> venv full recheck passed for glance (but with the pause/resume test disabled): https://review.openstack.org/#/c/315777/ [18:43] thedac, next - let's land your glance thing then i'll rebase and re-enable that test, yah? [18:43] Sounds good. Can you do the +2 honors [18:44] thedac, 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] Sure, I'll get to that after lunch. [18:45] thedac, thx, thx, and thanks. maybe one more tyvm, i'm losing track. ;-) [18:46] :) [18:47] yeah cory_fu works fine when i set the major version === rodlogic is now known as Guest18774 [19:12] tvansteenburgh - have we done any amulet tests against any multi-series charms? [19:13] i have [19:13] good results? [19:13] i've defined series='xenial' in my deployment, yet i'm still getting trusty flavored charms deployed in my tests. :( so pebkac somewhere [19:13] hmm [19:16] ok weird [19:16] if i define xenial as the first series in my charm, i get a xenial series charm [19:17] lazyPower: yeah...can you file a bug on this, pretty sure i know what's going on [19:17] sure thing, inc. [19:18] lazyPower: was trusty the first one in the list before? [19:20] https://github.com/juju/amulet/issues/137 [19:20] yep [19:40] thedac, glance merged, rebased, smoke passed, full now underway [19:42] thedac, 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:45] cory_fu: what am I doing wrong? [19:45] https://gist.github.com/buggtb/a6cb65333e63bc3c905f088469c2fdca#file-gistfile1-txt-L29 [19:45] https://gist.github.com/buggtb/b09631cd57531a730798545ca82c8e2f#file-gistfile1-txt-L11 [19:45] ignore me [19:45] my update hadn't fired..... [19:46] magicaltrout: 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 action [19:47] There are proposals to make actions part of the reactive dispatch loop, which would make it work a bit clearer [19:47] cool === rodlogic is now known as Guest56132 [20:00] beisner: ok, rabbitmq will have to go on the pile [20:01] thedac, ack. also see comment on your keystone review [20:03] ok [20:04] beisner: mind doing cinder so it does not get lost? https://review.openstack.org/#/c/316194/ [20:04] thedac, yep i'm going to do the same there. land, rebase into my test refactor, retest. [20:05] got it [20:24] ahasenack: 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:26] ahasenack: and how is that version (e.g. 0.52.0-0ubuntu1~ppa1) constructed? is that a dch thing? [20:26] tvansteenburgh: the recipe grabs the debversion from the last changelog entry, and appends what the recipe instructs [20:27] {debupstream}~bzr{revno}~{revno:packaging} [20:27] "debupstream" is the version [20:27] taken from changelog [20:27] the rest in the changelog is ignored [20:27] so I don't have to update the changelog everytime there is a change in the bzr branch the recipe monitors [20:28] ah, okay, so do you manually type the new version into the changelog? [20:29] was wondering about the ~ppa1 or ~ppa2 bits on the end [20:29] I do that out of convention [20:29] when uploading to ppas [20:29] that comes with the help of dch, yes [20:29] okay cool, thanks [20:29] but it's ignored by the recipe because it's in the release portion of the package full version number [20:30] so it's not inside {debupstream} above [20:30] but helps if doing a manual build locally [20:30] gotcha [20:30] tvansteenburgh: yeah, for releasing, you'll need to update the debian packaging branch [20:31] tvansteenburgh: I can so you my workflow if you're curious [20:36] marcoceppi: yeah, i think i get it now. update changelog for new version. but yeah, wouldn't hurt to walk through it once === natefinch is now known as natefinch-afk [20:37] marcoceppi: we should do an amulet release soon [20:37] * marcoceppi mods [20:38] for the juju2 stuff in particular [20:38] yeah [20:39] tvansteenburgh: is it ready to go today? [20:39] marcoceppi: yep [20:39] i'm doing the hallway test rn [20:39] if that helps confidence any :D [20:39] marcoceppi: merge #137 first [20:39] its friday, the 13th, whats the worse that could happen [20:39] haha [20:44] oh man, this is glorious. clean output from everything with tip of our tooling. [20:44] \o/ [20:44] time to release [20:44] tvansteenburgh - passes the lazypower test [20:44] \o/ [20:45] sweet === rodlogic is now known as Guest76655 [20:48] tvansteenburgh: should we start an amulet daily ppa? [20:48] marcoceppi: sure [20:48] eh, later [20:48] actually i was just gonna build all the dailies into one ppa [20:49] is there a reason to have a separate ppa for every package? [20:52] tvansteenburgh: possibly, but I'm a +1 to a charm-testing daily ppa [20:53] ok [21:04] okay, 1.15.0 is out [21:05] woot [21:05] thanks [21:05] nice [21:07] * beisner likes those ideas! ^ === rodlogic is now known as Guest11340 [22:00] thedac, 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:02] no problem. Seems we have lots of races to track down === rodlogic is now known as Guest78418 === rodlogic is now known as Guest28531