[00:48] I got an error on `juju gui`: ERROR Juju GUI is not available: Juju GUI not found [00:48] Can I manually deploy gui to the controller? [01:11] Or, after switching to the controller model and deploying juju-gui, and then exposing it, how do I get that error to go away? [01:13] Or is my controller just sorta fubar'd and need a fresh bootstrapping? (Juju version 2.2.6 - bootstrapping has been a bit of a pain because I had to increase the timeouts due to ProLiants being slower than glaciers at booting) [01:14] oh heck nevermind [01:15] `juju upgrade-gui` did the trick === frankban|afk is now known as frankban === wgrant_ is now known as wgrant [13:23] my subordinate charm is not building like I expect, and charm proof isn't finding the hooks I've defined [13:24] is there a helpful example I can refer too? [13:50] andrew-ii53: glad you got it worked out [13:50] skay: hmmm, is it using the reactive framework? [13:51] rick_h: yes. give me a bit, I'm cleaning it up so that I can push it somewhere [13:51] rick_h: it's pretty simple [14:18] skay: If charm proof is complaining about hooks, are you sure that you're including "layer:basic" as one of your base layers in layers.yaml? That's the layer that contains the hook template. [14:18] cory_fu: oh, I'm not. I didn't know I needed it for a subordinate. that probably explains things [14:19] I haven't written any subordinate charms before [14:20] * skay head smack [14:20] skay: Yeah, a subordinate is basically the same as a regular charm, so it still needs layer:basic. I would also *highly* recommend using the use_venv: true option (see https://github.com/juju-solutions/layer-basic#layer-configuration) [14:21] That will keep your subordinate from conflicting with the principal charm for its python dependencies. We're looking at making that a hard requirement for subordinates in the future [14:22] ack [15:47] <[Kid]> is there a way to list the "register" key for a user after it has been created? [15:56] [Kid]: so that's a bug I know was addressed but I think it's in the upcoming 2.3 [15:57] [Kid] https://bugs.launchpad.net/juju/+bug/1657187 [15:57] Bug #1657187: Get new token for existing user

[17:59] <[Kid]> rick_h, it isn't really a lost key, or is that what you would consider lost if i didn't write it down when i first created the user? [17:59] [Kid]: as good as lost? [17:59] <[Kid]> i guess i just thought there would be a way to view it without resetting it and affecting any other instances that were registered with that username [18:00] <[Kid]> never even thought the key would be something that was shown only once, in other words. [18:08] [Kid]: understand, apologies for the confusion but yea. It's a secret and so treated very secretly to help avoid it leaking as much as possible [18:16] <[Kid]> ahh ok [18:17] <[Kid]> no problem. i will wait on the PR then [18:17] <[Kid]> to get merged [18:17] <[Kid]> i guess i could go to latest beta, right? [18:17] <[Kid]> or alpha [18:20] [Kid]: yea, it looks like it's been landed and should be in the edge channel snap [18:20] [Kid]: and I hear beta2 is on the way any day now === frankban is now known as frankban|afk [19:29] howdy cory_fu tvansteenburgh - hi we have a high prio break re: the USER env var changes. https://github.com/juju/charm-tools/issues/367 [20:05] <[Kid]> is juju supported in a lxc container outside of the bootstrapping localhost? [20:12] beisner: It seems crazy to me that USER wouldn't be set, but it's a relatively easy fix. But are we sure that the build dir when running on Jenkins will work with the confined snap (i.e., will be somewhere under the current user's home dir)? [20:13] cory_fu: by default jenkins doesn't define a USER env var. [20:14] Yeah, I believe you. It just seems odd. :) [20:14] cory_fu: we've added one as a work-around, but we'll still have to go touch a ton of tox.inis like so in order to profit: https://review.openstack.org/#/c/516370/3/tox.ini [20:16] beisner: https://github.com/juju/charm-tools/pull/368 [20:16] kwmonroe: Can I get you to eyeball that, as well? [20:21] Added a test [20:23] tvansteenburgh: Thanks. kwmonroe, nm. [20:23] beisner: Once Travis finishes, I can get that to the candidate channel of the snap. Is that sufficient? We were planning a stable release first thing next week [20:25] cory_fu: we use python virtualenvs for all testing. it'd need to hit pypi for us to consume. [20:26] beisner: You don't use the snap for charm-tools? We really recommend using the snap rather than PyPI. :/ [20:26] rather, we could consume the candidate of course, but it is higher touch for us to do that than to just feed a USER env var all the way through to the venv. [20:27] why publish a python package if that's not a recommended delivery mechanism? [20:27] we can switch charm-tools to snap a consumption model indeed. but not likely today. [20:28] beisner: It's only on PyPI because it's not factored properly and there are portions that are used by bundletester as a dep. So, it's mostly a hold-over. [20:28] cory_fu: you wanna tweak this too? https://github.com/juju/charm-tools/blob/ea5878000a0a33780e1434c83f25c1f97fc847ba/tests/generators/test_generator.py#L52 [20:28] right. we use BT. seems things are in a limbo state atm. [20:30] kwmonroe: I think that test is still fine. It's still using expanduser, so that still patches the right thing [20:33] ah, right cory_fu, get_home still calls eu. i read good. [20:45] I'm trying to bootstrap a controller strict with egress restrictions. I've set up an apt mirror and boostrapped using it with --config apt-mirror=, however I'm still seeing apt operations fail because they're trying to access security.ubuntu.com. Is there a way to make them point at my apt mirror? [20:45] with strict* :\ [21:00] ryebot: is it the bootstrap that fails, or a subsequent deploy to the default model? [21:00] kwmonroe: the bootstrap - I ssh into the not-yet-controller machine and check cloud-init-output.log [21:01] kwmonroe: I'm currently disabling os-update mechanisms (no apt update/upgrade), but I guess I'm not happy with that even if it works. [21:02] kwmonroe: nah doesn't seem to work anyway [21:03] ryebot: you did both configs? --config enable-os-refresh-update=false --config enable-os-upgrade=false [21:03] yessir [21:04] it's making it to trying to install stuff now, but still bailing on security.ubuntu.com hits [21:04] glorious [21:05] ryebot: for giggles, add an entry in your /etc/hosts where you're running the bootstrap: " archive.ubuntu.com security.ubuntu.com" [21:05] kwmonroe: in the controller itself? [21:05] "controller" [21:05] i dunno if that'll work because it's probably failing to find security.u.c from the bootstrap node (not your local machine) [21:06] yeah, that's right, on the controller [21:06] ryebot: sure, if you can get to the controller, add it there too. [21:06] yeah, I can force it, but I need it to work without doing crazy stuff [21:06] * ryebot sighs [21:08] I don't want my offline docs to read, "While the controller is attempting and failing to bootstrap, ssh in and muck about with /etc/hosts!" xD [21:08] lol [21:08] hoping some juju dev will come along and tell me how to do it right... [21:08] * ryebot coughs [21:10] ryebot: you may enjoy this: https://bugs.launchpad.net/juju/+bug/1606487 [21:10] Bug #1606487: apt-mirror does not override security.ubuntu.com for controller [21:10] yeah, I saw that, didn't want to believe it [21:10] shut my eyes and spammed here instead [21:11] * ryebot tries to replace kwmonroe's link with a cat picture. [21:11] meow [21:11] haha [21:11] alright, I gotta do a thing. thanks for the kittens, kwmonroe [21:11] get good candy [21:12] :D [21:23] i'm getting an old version of a charm when i use 'charm pull' on it; it's not giving me the latest stable version [21:23] http://paste.ubuntu.com/25861248/ [21:24] 'charm show' lists the new version ~8, but charm pull gives me ~4, unless i specify --channel stable, in which case i get ~8 [21:25] what am i missing? [21:31] jhobbs: i'm gonna guess it's related to perms: [21:31] perm: [21:31] Read: [21:31] - oil-charms [21:31] jhobbs: i can pull rev4, but not --channel stable. i get access denied if i try to pull a rev > 4 [21:33] jhobbs: if you're ok with everyone reading that charm, do a 'charm grant cs:~oil-charms/ci-configurator --channel stable' [21:33] er, 'charm grant cs:~oil-charms/ci-configurator everyone --channel stable' [21:33] ok [21:33] i did 'charm grant cs:~oil-charms/ci-configurator-8 everyone' [21:33] i will do that too [21:34] kwmonroe: i did the grant you suggested and i'm still getting -4 [21:36] yeah jhobbs, me too.. but at least now i can do a charm show on it, and this is accurate: https://jujucharms.com/u/oil-charms/ci-configurator/ [21:36] so, ya know, small victories :/ [21:37] cory_fu: do a 'charm pull cs:~oil-charms/ci-configurator' and tell me what rev you get [21:38] jhobbs: maybe you and i have some wacky charm cache [21:39] kwmonroe, jhobbs: I get 4 [21:39] seems like a bug maybe [21:39] gah [21:39] i'll file one against jujucharms.com [21:39] thanks for the help! [21:40] cory_fu: you think it's a bug with charm pull or the store? "charm pull cs:~oil-charms/ci-configurator --channel stable" will give you rev8, but omitting the channel gives you r4. [21:41] jhobbs: the issue might be here https://github.com/juju/charm-tools/issues as it seems like the store is up to date. [21:41] kwmonroe: It wouldn't be in charm-tools, it would be in the charm go code [21:42] kwmonroe: You can add --debug to charm pull to see more info about what it's doing [21:46] it's grabbing https://api.jujucharms.com/charmstore/v5/~oil-charms/ci-configurator/archive [21:46] which has the old version [21:47] jhobbs: And if you add --channel=stable, then it adds that as an explicit param to that URL [21:47] So it seems like a charmstore issue, though I would have expected charm pull to include stable as the param explicitly by default [21:49] it's working now [21:49] magic [21:50] i just need to wait longer next time i guess [21:50] thanks again