[00:27] lazyPower: is https://jujucharms.com/observable-kubernetes fixed for the etcd issues [00:27] negative [00:27] ok [00:28] I won't recommend that as a demo atm, but as soon as it is ready look out :-) === menn0 is now known as menno-afk === menno-afk is now known as menn0 [06:23] I want to manually expose a port, how do I do that? [06:24] My initial guess was to run a `juju run --machine 0 "open-port 3000"` [06:24] but that failed "unknown command open-port" === sarnold is now known as sarnold_ [07:21] Guys, I am deploying rabbitmq-server charm on trusty but instead i am seeing that charm for xenial is getting deployed? [07:22] Here's a mind bender. Why would the HOME var not be found inside an install hook? [07:22] `expand_path': couldn't find HOME environment [07:22] jamespage: ^^ [07:22] Andrew_jedi: you can check if charm has explicitly set a series in config [07:22] kakakka: Nope, no series [07:23] you can also manually set when deploying [07:23] you can also check your model config to see if a 'default' is set [07:23] are you deploying from xenial? [07:23] kakaka: Nope trusty [07:23] kakakka: Where is the model config? [07:24] what juju version are you running? [07:24] juju get-model-config [07:24] for 2.0-beta8-xenial-amd64 [07:26] kakakka: 1.25.5-trusty-amd64 [07:26] search docs then, i dunno 1.25 [07:26] you could try juju get-model-config [07:27] the version jump between 1.x and 2.x is staggering [07:27] lots of rough edges and changes going on here in jujuland [07:30] Trying to gem install rails in my charm and getting a "couldn't find HOME environment" === frankban|afk is now known as frankban [07:34] The rails gem seems to want to `File.expand_path('~/.railsrc')` and that's causing problems [07:40] Andrew_jedi, you can force the version by deploying cs:trusty/rabbitmq-server [07:41] Andrew_jedi, when you say 'on trusty' do you mean from a trusty client? [07:41] jamespage: I just did that after reading some docs and it worked. [07:42] Andrew_jedi, the charm store will be making a decision if you just do juju deploy rabbitmq-server as to which series is provided and used - I think that has switched to xenial as default now [07:44] jamespage: ohhh, thanks for this info. Is there a way i can override the default? [07:44] Andrew_jedi, yes you can set the default-series value for the environment [07:44] default-series: trusty [07:44] for example [07:46] jamespage: Perfect, that's what i was looking for [07:46] :) [07:53] Andrew_jedi, yw [08:04] jamespage: for Bug 1590257, should I have just checked on the mailing list or here before posting it? [08:04] Bug #1590257: ceilometer version has bug, can you increment verison [09:21] gnuoy, changed my mind on approach for https://review.openstack.org/#/c/326597/ [09:22] having two files named keystone.conf that the charm manages is not helpful or functional [09:35] hi guys [09:35] according to the official documentation, 'juju charm get' should work - however, it tells me 'unrecognized command'. 'charm-get' also doesn't work after installing charm-tools. [09:36] this is with the latest stable ppa. [09:36] is the documentation wrong or am I doing something wrong? :) [09:36] there is also a pull-source which is not mentioned in the 'deploying charms offline' document [09:45] anyone can help me with bug 1590172 [09:45] Bug #1590172: ERROR cmd supercommand.go:448 autorest:WithErrorUnlessStatusCode POST https://login.microsoftonline.com/fb30bf07-xxxx-xxxx-xxxx-02ef08680fb9/oauth2/token?api-version=1.0 fa iled with 400 Bad Request [10:14] jamespage, I'm looking into a bug in nova-cc that landscape have found and I seem to be seeing the charm attempt to start a nova service, and it reports a 'start/pre-start' but logs in /var/log/{upstart,nova/* have earlier timestamp and the service is not running. Have you seen anything like that ? It looks like the upstart pre-start is running but not the main script block. I can't see anything wrong with the pre-start bit fwiw [10:28] What's the password for the the default 'ubuntu' account, created by Juju [10:29] piao, it does not have one - the only way to access is via "juju ssh" [10:29] using the ssh keys generated as part of deployment (or the local ssh keys) [10:29] So I'm using juju ssh to login, but I cant use systemctl to modify systemd? [10:30] Ah, I get that it's using ssh certs now. [10:30] if you can login as ubuntu, it has passwordless sudo [10:31] ok ty [10:31] perfect, that worked [10:42] hi [10:46] hi im having some issues with trying to run `juju quickstart mediawiki-single` [10:47] it says The program 'juju' can be found in the following packages: [10:48] it recommends the juju-2.0 package [10:53] jamespage, nm, figured it out [10:55] yaz_10_36_: quickstart is a 1.X thing only, so you'd want juju-1.25 (or you can just not use quickstart) [10:59] yeah i was following the guide at https://jujucharms.com/get-started and 1.25 is installed [11:01] if possible I was hoping to try it out, before having to read a lot of docs [11:01] yaz_10_36_: so, you can install juju-1-default which will alias juju-1 back to juju, or you can type juju-1 quickstart .... [11:01] thanks, ill try that out [11:02] btw should i use juju-2.0 for production? [11:02] yaz_10_36_: not quite yet, in the final betas, but shortly [11:03] ok I guess i'll keep an eye on it then [11:40] For my local charm the icon.svg doesn't want to render in the juju gui. [11:47] ubuntu@juju-1-18:~$ juju deploy ubuntu [11:47] ERROR cannot download charm "cs:trusty/ubuntu-0": bad SHA256 of "/var/lib/juju/charmcache/cs_3a_trusty_2f_ubuntu-0.charm" [11:47] Hi, lads [11:47] do you know why I'm getting this when trying to deploy ubuntu charm from any juju version less than 1.24? [12:25] charms.reactive: what could cause a hook handler for a -departed hook in an interface layer to be executed in the context of a -broken hook? [13:18] kwmonroe: got a minute? I need to ask you about bunldes. Is it possible to call an action while after the bundle is setup? [13:20] I am asking this because the apache-spark charm starts in standalone mode and it is not sending jobs to yarn in the spark-zeppelin and spark-notebook bundles we have [13:20] kwmonroe: Also! Good morning :) [13:23] http://askubuntu.com/questions/774928/openstack-autopilot-deployed-new-machine-with-juju-not-showing-in-horizon-dashbo [13:24] http://askubuntu.com/questions/778234/unable-to-resize-openstack-instance [13:24] any help for these from openstackers? [13:24] cargonza: ^ [13:25] http://askubuntu.com/questions/779636/juju-bootstrap-wrong-maas-api [13:25] also not sure if this one is fixed in beta8? [13:25] I am unsure of maas/juju connectivity lately [13:25] yo kjackal - are you asking about calling actions from a bundle test? [13:26] kwmonroe: not from a bundle test but from a bundle.yaml itself [13:26] jcastro: it's out from the feature flag and tells the API version automatically I thuoght [13:26] kjackal: for the spark problem, if the charm is in standalone mode, it won't send jobs o yarn. the yaml needs to deploy spark in yarn mode in those bundles. [13:27] rick_h_: yeah I am unsure enough to not answer, heh [13:27] jcastro: will prod for more details and we'll look into it [13:27] no kjackal, you can't call an action from a bundle yaml. [13:28] actually, cargonza if the fellas have time to go over some of the openstack tagged questions they're starting to pile up [13:28] stokachu: got a few conjure questions in there as well [13:29] jcastro: wehre? [13:29] http://askubuntu.com/questions/780831/conjure-up-io-openstack-lxd [13:29] kwmonroe: hm.... so we have acouple of options then. a) update the readme to say that spark is in standalone and you need to call an action to go to yarn mode b) fork & fromulgate a spark version that just has the patch to deploy to network restricted environments [13:29] jcastro: thanks taking a look [13:30] http://askubuntu.com/questions/781009/ubuntu16-04-conjure-up-opentsack-how-long-it-takes-to-conjuring-up-openstack [13:30] jcastro: please feel free to shoot off emails on things you find to the lead of the team involved. cc me please [13:30] kwmonroe: basicaly b) is not an option, just a mental excersize :) [13:30] stokachu: hover over the juju tag and subscribe, it will send you an occasional summary email [13:30] rick_h_: if we could have people subscribe to the tag that would be lovely [13:30] though I know lots of core devs do already so it's likely just a time thing [13:30] jcastro: thanks Im also subscribed to ones tagged 'conjure-up' as well [13:30] excellent [13:31] jcastro: understand, but appreciate you helping to poke people [13:31] stokachu: Lemme fix up the formatting on these [13:31] kjackal: i don't understand the problem. spark changes exe mode on config, right? [13:32] kwmonroe: config? I thought it was an action, let me check this (obviously dont remember the code I worte....) [13:34] kwmonroe: you are right! (as always!) [13:34] we said that yesterday! [13:34] :) [13:35] stokachu: the conjure-up tag wasn't existing, it exists now, you might need to resubscribe [13:35] kjackal: i bet you got it mixed with upgrade.. upgrade is the action, but changing spark config mode is config... so you do have control over spark's execution mode in a bundle.yaml. [13:35] jcastro: thanks! [13:36] kwmonroe: now I need to see how we specify config variables in a bandle.yaml [13:37] de we do this anywhere else? [13:37] stokachu: you can fill in stuff here and submit it: http://askubuntu.com/tags/conjure-up/info [13:37] links to the site, etc. [13:37] jcastro: sweet, ill get this updated [13:38] I just found a truckload more questions for you, I'll start retagging them, prepare thyself [13:38] sure do kjackal, check mariadb's config in the sql bundle: https://github.com/juju-solutions/bundle-apache-analytics-sql/blob/master/bundle.yaml#L38 [13:39] kwmonroe: awesome, thank you [13:39] np [13:40] stokachu: http://askubuntu.com/questions/772551/how-do-i-join-a-new-node-to-conjure-open-stack-mitaka [13:40] Mark explained the "what you should do" but I think adding an answer with the actual commands, etc would help that out [13:41] jcastro, I'll check it out. [13:44] http://askubuntu.com/questions/780072/how-do-i-make-juju-request-machines-and-provision-them-in-parallel [13:44] I could have sworn we did this by default [13:47] jcastro: yeah, we make the api calls sequentially, but certainly shouldn't block on commissioning before we make the next call [13:47] jcastro: is it allowed to change some tags that are not openstack related? just a quick glance and there are MAAS items which doesn't relate directly to openstack. [13:48] jcastro: I haven't done add-unit -n 36 on maas, but we do lots of bundle deploys where the machines are visibly deployed in parallel [13:49] cargonza: yeah if it's maas you can change the tag from openstack to maas [13:49] or add a maas tag if it applies to both [13:49] ok thx u [13:52] cargonza: for many of them they will have juju, openstack, and maas because usually the asker isn't sure exactly where in the stack their issue is [13:53] yup I saw one that is directly MAAS deployment related. I'll make sure I don't have a fast trigger on the edits. [13:54] all your edits will go into a queue anyway until you have enough reputation to make direct edits [14:17] jamespage, have got a sec to look over https://github.com/gnuoy/interface-openstack-ha ? [14:19] gnuoy, looks generally OK but I think we've been using the .connected state to signal a joined event, rather than having a .joined state [14:19] jamespage, ack, will fix [14:20] gnuoy, icey: hey for reference I think we need to start prefixing anything being targetted to openstack namespace with charm [14:20] so charm-interface-xxx [14:20] charm-layer-xxx [14:21] stokachu: hey, haproxy is failing on autopilot deploy, is this a known issue? [14:21] hmm we should also think about bug tracking as well... [14:22] gnuoy, beisner, cargonza, coreycb, thedac, tinwood, dosaboy, wolsen: btw its fine for us to start using the openstack-dev ML for charm development discussion now [14:22] I emailed the openstack-charmers ML to that effect [14:22] jamespage, kk [14:23] ok. cool [14:23] jamespage, i like it. replied to one earlier. [14:23] beisner, i saw [14:23] beisner, any idea how we go about getting an #openstack-charms irc channel? [14:23] jamespage, ha i was just typing a suggestion here to that effect ... [14:24] i'd like to have that channel, and can look into what it'd take to add it. we added one for the now defunct tailgate group last yr. just some infra coord iirc. [14:25] aha, https://git.openstack.org/cgit/openstack-infra/project-config/tree/gerritbot/channels.yaml [14:27] marcoceppi: running openstack-install or conjure-up? [14:31] stokachu: openstack-install [14:31] jamespage, I've made the change you suggested. Am I right in thinking: "looks generally OK" <=> "I LOVE it! Get it forked into github.com/openstack-charmers right now!" [14:31] +1 [14:32] ta === scuttle is now known as scuttlemonkey [14:32] gnuoy: forked into? [14:32] marcoceppi: this isn't a known issue to me, maybe dpb1_ knows more? [14:33] mgz, Create a for of the repo in the openstack-charmers namespace [14:33] s/for/fork/ [14:34] Anyone mind if I update topic, I think jujucharms.c is fine now [14:34] I guess that makes sense, strange turn of phrase as it's generally forked-from [14:34] forgiveness rather permission blah === gnuoy changed the topic of #juju to: Welcome to Juju! || Docs: http://jujucharms.com/docs || FAQ: http://goo.gl/MsNu4I || Review Queue: http://review.juju.solutions || Unanswered Questions: http://goo.gl/dNj8CP || Youtube: https://www.youtube.com/c/jujucharms || Juju 2.0 beta8 release notes: https://jujucharms.com/docs/devel/temp-release-notes [14:34] mgz, not in my head [14:42] marcoceppi: will need more details. :) [14:42] got a pastebin or something? [15:04] zul, o-c-t change merged. thx! [15:10] dpb1_: http://paste.ubuntu.com/17119672 [15:12] marcoceppi: a bit more please? unit: haproxy/0: machine: 0/lxc/0 agent-state: error details: hook failed: "install" also, a paste of juju status would be good. [15:12] dpb1_: this is using openstack-install, I don't know how to even get that [15:14] export JUJU_HOME=~/.cloud-install/juju [15:14] juju status [15:14] my go-to answer: http://askubuntu.com/questions/606422 [15:17] dpb1_: it's an error with dns/apt resolutions [15:23] stokachu: this is a problem with openstack-install, it's setting apt-http-proxy to http://:5240:8000 [15:24] marcoceppi: thanks we'll take a look and get it fixed [15:25] marcoceppi: yea we fixed that lemme push a new build out to the stable ppa [15:25] stokachu: cool, ppa so I can install it onthe orangebox? [15:25] marcoceppi: yea ill kick off a build in just a sec [15:26] stokachu: link to ppa? [15:26] marcoceppi: ill push it here: ppa:cloud-installer/stable [15:28] stokachu: thanks [15:29] marcoceppi: waiting for the buidl to complete now, https://code.launchpad.net/~cloud-installer/+archive/ubuntu/stable/+recipebuild/1155753 [15:34] stokachu: ack, ta [15:58] Hello Team, I have a small doubt in the layered relation part. Usually we will be using interface for holding the exposed value from one charm to other charm with respect to layered charm development (Here both the charms are layered charms). [15:58] For example i have a non-layered charm which is actually exposing some port number. And in this scenario i have a layered consuming charm which is actually making use of the port number of the non-layer charm. Could you please advise how to use port number of the non-layered charm in layered consuming charm. [16:10] os-charmers: new charm pushes will now result in a repo-info file in the published charm artifact. https://jujucharms.com/tempest/ --> https://api.jujucharms.com/charmstore/v5/tempest/archive/repo-info [16:11] dpb1_, fyi^ will be helpful in tying cs revno to the repo and commit level of that published charm. [16:12] also, fyi, that applies only to os-charms in the git/gerrit flow. [16:17] cory_fu: bcsaller: will you scan this and tell me if my expectations are wrong or if this is a bug in charm build? tl;dr, i expect "middle" layers to override config values from "bottom" layers: http://paste.ubuntu.com/17121725/ [16:20] kwmonroe: You shouldn't repeat layer:basic in every layer [16:21] kwmonroe: Your includes should be more like this: http://pastebin.ubuntu.com/17121896/ [16:21] Otherwise, layer:basic will get re-applied on top of layer:bottom and layer:middle [16:21] er, on top of layer:bottom, but not layer:middle [16:22] ok, duly noted. that doesn't seem to change the fact that the bottom config value is stuck in my top layer. [16:22] Still looking. That just jumped out at me [16:22] there might be a legit bug in there :) [16:22] beisner++ [16:23] good lookin out cory_fu. i was just saying that didn't affect this particular outcome. [16:23] Hrm. Actually, it looks like it already de-dupes the basic layer, so my comment is moot [16:23] kwmonroe: Can you run it again with -lDEBUG? [16:26] cory_fu: http://paste.ubuntu.com/17122059/ [16:26] Hrm. I don't know why I thought that would be helpful. [16:27] :) [16:31] does anyone know what determines the "trusty" part when charm building? ie. i get ./build/trusty/my-built-charm but there is nothing declared as trusty in the charm that i see. [16:32] beisner: bitrot :) [16:33] defaults that are no longer needed or apply [16:33] bcsaller, aha. would ./build/my-built-thing be safe in some future release? [16:34] with multi series charms and no JUJU_REPOSITORY needed, yeah, we can change how that works [16:35] bcsaller, i mean i'm fine with just always hitting that trusty dir for now. i'm about to inject a build step in our commit -> push -> publish flow and didn't want to unexpectedly hit a variable in that dirname. [16:36] oh! -o i can be explicit, yah? [16:36] I think that currently would still create a series dir under it [16:37] bcsaller, ack it does [16:39] kwmonroe, bcsaller: I have a fix, but I don't understand how this didn't break long before now [16:40] Oh, I think this was a regression from 87c26dc4 === Guest47242 is now known as med_ [16:45] stokachu: http://paste.ubuntu.com/17122635 [16:45] getting closer [16:50] kwmonroe: https://github.com/juju/charm-tools/issues/218 I'm creating a patch now [16:50] marcoceppi: yea we broke it trying to fix another exception bubbling up, https://github.com/Ubuntu-Solutions-Engineering/openstack-installer/commit/1419917de3801340712fe52ca817c24c38685e63 [16:50] marcoceppi: will get it fixed [16:54] aww - thanks cory_fu! === frankban is now known as frankban|afk [17:04] kwmonroe, bcsaller (and marcoceppi): https://github.com/juju/charm-tools/pull/219 [17:11] stokachu: any eta on that fix? [17:11] stokachu: or another way to get autopilot running? [17:11] like, if I just deploy the bundle directly? [17:12] cory_fu: thanks [18:25] marcoceppi: you can deploy the bundle directly if you want [18:25] marcoceppi: i was going to take a look at the issue in the next hour === alexisb is now known as alexisb-afk === redir is now known as redir_lunch [19:26] cory_fu - is it possible to list and iterate over converations for another relation than the one thats in context of the interface module? [19:26] eg: in provides.py - iterate over the list of peers [19:26] or do i want to pre-fetch this and pass it into the method? [19:30] You definitely don't want to be interacting with a different relation than the one for your interface class, because it breaks the encapsulation of the interface protocol [19:30] The peer interface layer should provide a method to get the data that you're interested in, and you should then pass that in to the other interface class [19:39] cory_fu - or i can iterate each member of the provides, and build the connection string on the client. I think was looking at the problem from the inside out. [19:42] or do it the way you recommended because i cant break my interface data model [19:42] ok i think that sorts it then === redir_lunch is now known as redir [20:40] when building from a top layer, do we expect its README.md to survive the build process and exist in the resultant built artifact? === natefinch is now known as natefinch-afk === alexisb-afk is now known as alexisb [21:27] beisner, yes i believe so [21:27] beisner, i've forgotten to add a README.md before and i get something from the lower layers === Spads_ is now known as Spads === lifeless_ is now known as lifeless [21:31] marcoceppi, https://github.com/juju/charm-tools/issues/220 [21:33] beisner: oh wow, it's just straight up getting deleted [21:33] that's really freaking odd [21:33] yah no can proof ;-) === zz_CyberJacob is now known as CyberJacob [21:54] marcoceppi, it's my day :-) also losing dotfiles in charm push. that's less critical for us. but here's that: https://github.com/juju/charmstore-client/issues/72 [21:55] marcoceppi, the build issue is pretty hi prio for us. lmk if there are any suggestions or questions. thx! === Spads_ is now known as Spads === Spads_ is now known as Spads === Spads_ is now known as Spads === CyberJacob is now known as zz_CyberJacob === skay[cloud] is now known as skay_