[00:33] <xarses> so the remaining issue, is that I don't understand how to determine if the charm knew better than to bounce both nodes at the same time or not
[00:51] <xarses> so the remaining issue, is that I don't understand how to determine if the charm knew better than to bounce both nodes at the same time or not
[15:02] <magicaltrout> afternoon
[15:02] <magicaltrout> can someone explain the k8s loadbalancer to me? :)
[15:03] <magicaltrout> cause i look at the microbots example and that uses the xip.io dns service but doesn't seem to use the loadbalancer, but I'm failing to see how services are routed through it
[15:04] <magicaltrout> when i say "explain" i just mean point me to some docs that reflect what is implemented here :)
[15:12] <magicaltrout> oooh thats only apiserver distribution on ingress
[15:12] <magicaltrout> i should read better
[15:14] <tvansteenburgh> magicaltrout: i'm listening but i'm not sure what you're asking :P
[15:14] <magicaltrout> hahah
[15:14] <magicaltrout> i'm trying to rather badly it seems, figure out external routing for k8s services :)
[15:15] <magicaltrout> i thought the load balancer provided it but that seems to be api call balancing
[15:15] <tvansteenburgh> magicaltrout: have you read https://kubernetes.io/docs/concepts/services-networking/service/
[15:15] <Dwellr> I'm using iptables to forward traffic to a worker node ip (because my worker nodes are on an ip range that conjure-up selected, that isn't routable in my network)
[15:16] <tvansteenburgh> magicaltrout: the LoadBalancer can do it if your cloud supports it
[15:16] <magicaltrout> interesting
[15:16] <stokachu> Dwellr: juju config flannel and set the cidr
[15:16] <stokachu> Dwellr: we're adding support to conjure-up to allow you to configure subordinate charms
[15:17] <Dwellr> stokachu: I don't really have a cidr..
[15:17] <magicaltrout> my confusion lies for example, with the microbots setup, you get a dns endpoint that points to the ip of a worker
[15:17] <stokachu> Dwellr: maybe Cynerva has some additional best practices around that
[15:17] <Dwellr> stokachu: Im running conjure up inside virtualbox, the virtualbox vm has a bridged adapter onto my house lan, and I'm using iptables to forward from the bridged adapter to the worker node..
[15:18] <tvansteenburgh> stokachu: that's really only relevant to the cluster network
[15:18] <Dwellr> stokachu: that lets me hit say, microbot, from other pcs on my house lan (provided I pass the fake host header so ingress routes the request etc) .. but I'm very much still learning =) if there's a better/cleaner way.. I'm all ears
[15:18] <stokachu> ah ok
[15:18] <tvansteenburgh> magicaltrout: right, so you it only works if you can route to the node ip
[15:19] <stokachu> Dwellr: i think iptables is the way to go
[15:19] <magicaltrout> yeah tvansteenburgh but also, if you stuck a real DNS entry against the node ip, if you tore it down and the service ended up on a different worker
[15:20] <magicaltrout> you'd have a stale DNS entry for your users, right?
[15:20] <tvansteenburgh> that's why you don't want to point dns directly at a node ip
[15:20] <tvansteenburgh> you point at a Service ip
[15:20] <tvansteenburgh> which *can* be provided by a LoadBalancer, but it can also be configured manually
[15:21] <magicaltrout> haha, minds melting, i've lived in mesos land for too long
[15:21] <tvansteenburgh> Service type can take an externalIP
[15:21] <tvansteenburgh> magicaltrout: read that doc page from beginning to end - i bet you'll understand fine after that
[15:21] <magicaltrout> hehe yeah i'm running through it thanks tvansteenburgh
[15:29] <Dwellr> is there anyway for me to see what juju run-action kubernetes-worker/0 microbot replicas=x does? It's great that it's automated etc, but I want to peek at what it did =)
[15:30] <magicaltrout> https://github.com/kubernetes/kubernetes/blob/master/cluster/juju/layers/kubernetes-worker/templates/microbot-example.yaml
[15:34] <Dwellr> thanks =) more than handy =)
[15:37] <Dwellr> and.. what's the simplest way to get my worker nodes to pull from a custom docker repo? I figure I can run docker back on my vm host, and have the workers pull from that repo, (and mebbe enable docker tls so then I can push to the vm from outside too)
[15:38]  * Dwellr trying to get toward 'kube in a box' ;p where I can spin up the vm, and develop and deploy apps to it from outside the vm
[15:56] <skay> why is the charm snap throwing this exception about one of my local python packages https://paste.ubuntu.com/25486709/
[16:22] <tvansteenburgh> Dwellr: there's a registry action on the worker nodes
[16:23] <Dwellr> whats a registry action, and how does that relate to my current understanding of a docker repository that I push my images to ?
[16:25] <tvansteenburgh> Dwellr: an action is a Juju thing - think of it as a script that you can run on a unit
[16:26] <tvansteenburgh> like, microbot is an action
[16:26] <Dwellr> okie, so what does a registry action do ?
[16:27] <tvansteenburgh> Dwellr: https://jujucharms.com/u/containers/kubernetes-worker/52
[16:27] <tvansteenburgh> search page for registry
[16:29] <magicaltrout> thanks tvansteenburgh that page was indeed very useful ;)
[16:29] <Dwellr> oooh.. thanks =)
[16:30] <cory_fu> skay: That is an issue with the classic snap and the reason we worked on moving to strictly confining the snap.  In fact, we *just* released the strictly confined snap a little while ago, so if you `snap refresh charm` and try again, it should be fixed
[16:30] <tvansteenburgh> Dwellr: if you'd rather use Helm, there's a chart for a private registry here: https://github.com/madeden/charts/tree/master/docker-registry
[16:31] <Dwellr> I'm still learning.. using conjure up as a way to spin up a slightly more complex kube deployment than minikube will, so I can play with what it means to deploy and run apps on kube etc
[16:31] <tvansteenburgh> Dwellr: cool, no prob :)
[16:32] <Dwellr> so I think the juju action for the registry will work
[16:32] <Dwellr> I'm slowly building up a vagrantfile that builds my kube in a box =)
[16:32] <skay> cory_fu: sweet! worked
[16:33] <skay> cory_fu: (actually, I unstalled it and installed it from scratch. at first it didn't find any update)
[16:33] <Dwellr> so far it installs conjure-up, uses it to install kube to localhost (interestingly using 'conjure-up kubernetes-core localhost' produces no output in vagrant until the command completes, which takes like 10mins or so)..
[16:34] <stokachu> Dwellr: is this from vagrant ssh into the machine and running conjure-up?
[16:34] <Dwellr> and then it copies the kube config, rewrites it to update the server address to the external bridged ip for the vbox vm, adds insecure-skip-tls-verify, and copies the config to the vagrant shared dir.
[16:34] <cory_fu> skay: Odd about the refresh.  Maybe it auto-refreshed before you tried it.  Either way, glad it's working!
[16:35] <stokachu> Dwellr: you may be able to get around the no output from conjure-up using `ssh -t` option
[16:35] <Dwellr> stokachu: I mean when I have config.vm.provision : shell, privileged: false, :inline => <<-EOT
[16:35] <Dwellr> conjure-up kubernetes-core localhost
[16:35] <Dwellr> EOT
[16:36] <tvansteenburgh> Dwellr: that sounds like a neat setup - you should write a blog post about it
[16:36] <stokachu> Dwellr: stil could be ssh option
[16:36] <Dwellr> that, when I run `vagrant up` and it runs the provisioning steps.. there's no output from the command until it completes
[16:36] <stokachu> Dwellr: it's inline but i think vagrant has to ssh first
[16:36] <Dwellr> Hmm.. wonder if passing -t is possible in the provision flags
[16:37] <stokachu> Dwellr: try config.ssh.pty= true
[16:37] <stokachu> in config.vm.provider
[16:37] <stokachu> http://blog.medyagh.com/2014/07/fix-vagrant-error-sudo-sorry-you-must.html
[16:37] <Dwellr> the vagrant file then goes on to setup ip forwarding for all nodeports (and 80 & 443) to the first worker ip, and 6443 to the master node ip from the bridged interface
[16:37] <Dwellr> stokachu: I'll try that in a mo =)
[16:38] <stokachu> cool
[16:39] <tvansteenburgh> please publish this awesomesauce
[16:39] <tvansteenburgh> Dwellr ^
[16:39] <Dwellr> hmm the docs for config.ssh.pty say that "When pty is enabled, it is important to note that command output will not be streamed to the UI. Instead, the output will be delievered in full to the UI once the command has completed."
[16:39] <stokachu> Dwellr: ah that's opposite what i was going for
[16:39] <Dwellr> and thats kinda what I'm already seeing with the conjure-up command ;p
[16:39] <stokachu> yea hmm
[16:40] <Dwellr> tvansteenburgh: it will be published =) .. I'm doing this as a side project to create a dev env in a box for gameontext.org
[16:40] <stokachu> Dwellr: though it's odd b/c ive used this option in jenkins ci runs
[16:40] <stokachu> to see the output as it happens
[16:40] <stokachu> i ran into the same issue until adding that
[16:41] <Dwellr> I can always try =)
[16:41] <stokachu> sure :)
[16:43] <Dwellr> was also figuring I could pipe it thru tee or sommat
[16:44] <stokachu> ah yea that may be another way
[16:50] <xarses_> Is this right? The only way to export a model to import as a bundle is via the gui? https://jujucharms.com/docs/2.2/charms-bundles
[16:51] <tvansteenburgh> xarses_: i think that's right yeah
[16:51] <xarses_> =(
[16:51] <xarses_> I don't have gui's attached to most of my controllers
[16:51] <tvansteenburgh> xarses_: just run `juju gui` and you'll have one :)
[16:52] <tvansteenburgh> you can do that to get the initial bundle and then just edit by hand from there
[16:52] <tvansteenburgh> i think that's what most ppl do
[16:52] <xarses_> ya, we don't use the gui around here
[16:52] <tvansteenburgh> neither do i
[16:55] <xarses_> wow, all the icons are missing
[16:55] <tvansteenburgh> from the gui?
[16:55] <xarses_> ya, it's showing the missing image icon
[16:56] <tvansteenburgh> i blame hurricane Irma
[16:57] <tvansteenburgh> xarses_: which charms?
[16:57] <xarses_> openstack*, percona, ceph, nagios
[16:59] <tvansteenburgh> xarses_: can you see this https://api.jujucharms.com/charmstore/v5/ceph/icon.svg
[17:00] <xarses_> yes, but shouldn't it download these things and keep them with the charm?
[17:01] <xarses_> also, we don't use charms directly from the store
[17:01]  * tvansteenburgh looks around for a gui dev
[17:01] <xarses_> uh, export button doesn't work
[17:03]  * hatch waves to tvansteenburgh 
[17:04] <tvansteenburgh> hatch: xarses_ is having some trouble with his gui
[17:04] <tvansteenburgh> missing icons, export button not working
[17:04] <tvansteenburgh> rotfl
[17:04] <tvansteenburgh> nice one hatch
[17:04] <hatch> lol
[17:04] <hatch> sorry wrong key
[17:04] <tvansteenburgh> hatch: xarses_ is having some trouble with his gui
[17:04] <hatch> got that
[17:04] <hatch> export
[17:04] <hatch> and icons
[17:04] <tvansteenburgh> yep
[17:05] <hatch> ok xarses can you click the ? in the top right and head for the keyboard shortcuts to find out what version of the GUI you're using
[17:05] <hatch> also, browser, and version of Juju
[17:07] <hatch> oops xarses_ ^
[17:14] <cory_fu> bdx: What do you think of the soft-launched layer-index repo vs the old micro-site?
[17:15] <bdx> cory_fu: I've been waiting on this for a while now .... super excited
[17:15] <bdx> cory_fu: it will make it easier for me to run a private registry for use in my charm ci/cd
[17:17] <cory_fu> bdx: Excellent.  I know the PR workflow adds a slight barrier to entry to getting new layers registered, but I think it's still reasonable.
[17:19] <bdx> totally, reasonable for sure. It also gives a central place users can subscribe to and more easily track the addition of new layers
[17:19] <bdx> like, I want to know when new interfaces/layers are added to the registry
[17:19] <bdx> this make it easy, you just follow the repo
[17:33] <magicaltrout> just like to say
[17:33] <magicaltrout> the new status button in juju gui
[17:33] <magicaltrout> is epic
[17:38] <xarses_> hatch how does the keyboard shortcuts page show version?
[17:39] <xarses_> juju version is 2.2.2, browser is chrome 60.0.3
[17:42] <xarses_> cli from `juju gui` implies its 2.4.2
[17:42] <xarses_> > GUI 2.4.2 for model
[18:07] <rick_h> xarses_: can you run juju upgrade-gui ? That's quite old.
[18:07] <rick_h> xarses_: it should be 2.9.2
[18:08] <rick_h> hmm, 2.4.2 is Feb release
[18:15] <xarses_> ya, thats about when the controller was originally deployed
[18:15] <xarses_> does it not upgrade with the controller?
[18:16] <xarses_> well, export works now
[18:16] <xarses_> icons are still broken
[18:27] <Dwellr> hmm.. tried doing   conjure-up kubernetes-core localhost > mylogfile.txt   and the log file stays at 0 bytes until conjure up is done too
[18:29] <xarses_> I'm guessing because they are all local charms
[18:29] <rick_h> xarses_: k, icons are pulled based on the charm urls so they might get blocked.
[18:29] <rick_h> xarses_: ok, if they're all local charms they're supposed to be pulled from the controller itself.
[18:29] <rick_h> xarses_: can you open the browser debug tool and see if you can get an error for the icon urls? I imagine they're getting a 404 or something
[18:29] <rick_h> xarses_: and file a bug on github.com/juju/juju-gui with the details ?
[18:30] <rick_h> xarses_: and no, the gui is out of sync with juju itself. There's usually a release every month or so. Since it's not effecting the actual workings of Juju but UX fixes/etc it's on the side.
[18:32] <xarses_> ahh, here is the bug, its trying to resolve the admin user and my model name for icons on api,jujucharms.com/charmstore/...
[18:33] <rick_h> xarses_: :(
[18:33] <xarses_> lemme sanitize
[18:34] <xarses_> yep, raises a similar 404 message
[18:34] <xarses_> https://api.jujucharms.com/charmstore/v5/~my-local-admin-user/my-local-model-name/meta/any?include=bundle-metadata&include=bundle-machine-count&include=charm-config&include=charm-metadata&include=charm-metrics&include=common-info&include=extra-info&include=id-revision&include=manifest&include=owner&include=published&include=resources&include=revision-info&include=stats&include=supported-series&include=tags
[18:36] <rick_h> xarses_: yea, that's a bug-a-boo to fix. Apologies on that.
[18:38] <xarses_> https://gist.github.com/xarses/4b1bea1bcdf8012737dee5f4f57ee7f3 the charms in the model for reference
[18:58] <stokachu> Dwellr: boo :(
[19:09] <xarses_> Dwellr: I found that I had to capture stderr in my pipe to catch most of the information during bootstrap, pass --debug flags and pipe to tee to get a useful looking log (mind you this was just with juju bootstrap)
[19:12] <xarses_> rick_h: file a bug on LP?
[19:13] <Dwellr> I'm having partial success doing    conjure-up &  then tail -f --pid=$! ¬
[19:14] <Dwellr> I'm having partial success doing    conjure-up &  then tail -f --pid=$! ~/.cache/conjure-up/conjure-up.log
[19:14] <stokachu> Dwellr: nice
[19:14] <stokachu> Oh I wonder
[19:14] <Dwellr> gets me a log that updates as far as 'Executing script ... steps/00_deploy-done'
[19:14] <Dwellr> but then it stops while juju status is showing the master/worker etc are still init'ing
[19:15] <stokachu> Yea those logs are in the spell steps dir
[19:15] <stokachu> Like 00-deploy_done.err
[19:16] <stokachu> cory_fu: any idea why the output from headless install only prints out when it's completed?
[19:17] <stokachu> This is from running it via vagrant up and even in our Jenkins runs it would do that
[19:17] <stokachu> Dwellr: did you try that try setting yet?
[19:17] <stokachu> TTY
[19:17] <Dwellr> not yet.. apparently it's pretty strongly recommended against.. so leaving that as last resort
[19:17] <stokachu> Ik
[19:17] <stokachu> Ok
[19:18] <cory_fu> stokachu: No idea.  I don't use vagrant often.
[19:18] <stokachu> Dwellr: the only other thing I can think of is that we use terminal colors for the output
[19:19] <Dwellr> so does apt-get update/install and that outputs ok during vagrant
[19:19] <stokachu> Ah ok
[19:21] <xarses_> rick_h: https://bugs.launchpad.net/juju-gui/+bug/1716037
[19:21] <mup> Bug #1716037: gui fails to render local:charm icons  <juju-gui:New> <https://launchpad.net/bugs/1716037>
[19:22] <stokachu> Dwellr: could vagrant only be printing a certain fd?
[19:26] <Dwellr> well.. it wouldn't explain why conjure-up kubernetes-core localhost > mylog.log doesn't write anything into mylog.log until the process finishes..
[19:26] <Dwellr> that's nothing to do with vagrant
[19:30] <xarses_> Dwellr: does `2>&1` help ?
[19:33] <cory_fu> stokachu: Maybe we could try adding flush=True to print() and cprint() in send_msg: https://github.com/conjure-up/conjure-up/blob/master/conjureup/utils.py#L248-L257
[19:33] <stokachu> cory_fu: good idea
[19:33] <cory_fu> stokachu: (flush=True docs: https://docs.python.org/3/library/functions.html#print)
[19:34] <Dwellr> could I patch that in locally after installing conjure-up ?
[19:34] <cory_fu> AFAICT, cprint() passes through args to print(), so it should work on either
[19:34] <Dwellr> (happy to test if possible)
[19:34] <stokachu> Dwellr: so you would need to checkout the source
[19:34] <cory_fu> Yeah, I don't think you could patch the code in the snap
[19:34] <stokachu> Dwellr: if you clone https://github.com/conjure-up/conjure-up
[19:34] <stokachu> Dwellr: then run `make sysdeps; make dev`
[19:34] <Dwellr> heh.. was hoping being python the source would be on my system somewhere
[19:34] <stokachu> then you can . conjure-dev/bin/activate
[19:34] <stokachu> and try it there
[19:35] <cory_fu> Dwellr: It is, but bundled into the snap filesystem.  The confinement of snaps would make it challenging to modify
[19:36] <Dwellr> yeah.. I know nothing re snaps =)
[19:37] <cory_fu> Dwellr: Well, they essentially are a way to package, confine, and apply security to an application to make it safer and easier to manage.
[19:39] <cory_fu> I think you'd have to be root to unpack and modify the bundled file system image and even then I think the signing of the snap might prevent it
[19:39] <Dwellr> root simple, signing not.
[19:39] <Dwellr> just paste your private key here in the channel, and i'll resign it ;p
[19:39] <stokachu> lol
[19:40] <stokachu> dont forget cc# and security code
[19:40] <cory_fu> You could manage it, but in the end it's just easier to use the source from GitHub and either run the dev venv as stokachu suggested, or build the snap from that and install with --dangerous
[19:40] <Dwellr> I'll need your visa number, 4 digit pin, and 3 digit verification code
[19:40] <stokachu> lol
[19:40] <Dwellr> rofl.. jinx
[19:40] <cory_fu> :)
[19:40] <stokachu> Dwellr: yea the source is quicker, especially if you dont want to build a new snap
[19:40] <Dwellr> lemme clone my vagrant file, and have it stop before it does all the badness =)
[19:41] <cory_fu> stokachu: I wonder if we could test using the output redirection that Dwellr mentioned.
[19:41]  * Dwellr rather glad all this is running on his new dumpster-server ;p 
[19:42] <Dwellr> sold as 'would not power on', I bought it just for the case (3u chenbro with 8x hotswap sata) .. turns out it powers on just fine (after adding some ram) .. it's a twin xeon e5530 server, (now) with 24gb per cpu,
[19:43] <cory_fu> Nice
[19:44] <cory_fu> stokachu: I'm seeing the same thing with redirection to a file
[19:44] <Dwellr> total price (excluding ram/drives).. just under 50$
[19:45] <cory_fu> Dwellr, stokachu: Yep, adding flush=True works
[19:46] <Dwellr> cool =) how long before that can make it into a proper build?
[19:46] <cory_fu> stokachu: I noticed that redirecting the output to a file still generates colored output.  I think "elif syss.__stdin__.isatty():" should actually be testing stdout, no?
[19:52] <cory_fu> Dwellr: I think we could get it in --edge today.  I'm about to put up a PR now
[19:53] <Dwellr> is that a flag for snap install ?
[19:54] <rick_h> Dwellr: yes, it looks at the edge channel of the snap to get pre-release stuff.
[19:54] <Dwellr> okie.. I can add that to the vagrant script quickly enough later then to test.
[19:55] <xarses_> ergh, rick_h two new problems can't logout from the store now that I linked my user, and since I linked my user there isn't a button to switch back to the models, you just have to stay on the user ui or go hack the url
[19:56] <xarses_> actually, 3 the linking the user didn't go to the proper redirect and authorize oauth page, it just selected an account
[19:56] <rick_h> xarses_: k, will check it out. I just got the latest release yesterday and haven't tried the account page thing.
[19:56] <rick_h> huh?
[19:56] <rick_h> linking the user?
[19:57]  * rick_h is lost on what xarses_ is up to
[19:57] <xarses_> yes linking the juju user in the gui to the charmstore
[19:57] <rick_h> k, /me is bootstrapping to see i can see what you see
[19:57] <stokachu> cory_fu: nice
[19:58] <stokachu> Dwellr: so basically when it's ready you would run `sudo snap install conjure-up --classic --edge`
[19:58] <stokachu> or if already installed run `sudo snap refresh conjure-up --egde`
[19:58] <xarses_> it should have raised an oauth authorize page, it just accepted the context I was in, instead of the oauth page making me confirm the app
[19:59] <rick_h> xarses_: it's an openid vs oauth thing. It should open in a new window you can close once you auth (and think it says you can close it now)
[20:00] <xarses_> and its now logged in to the wrong user, and I don't see a unlink button
[20:01] <cory_fu> stokachu: https://github.com/conjure-up/conjure-up/pull/1148
[20:02] <stokachu> cory_fu: thanks, ill merge and push to edge soon as it's done with ci
[20:02] <cory_fu> stokachu: +1
[20:04] <rick_h> xarses_: ok, so I just tried to replicate it and I logged into the charmstore and it shows at the top my two models on my controller (controller and default) and the list of charms and bundles from my charmstore account. I then clicked on the default model, and clicked manage to get back to the GUI
[20:05] <rick_h> xarses_: it shows my username as "admin" on my profile page. I'm not sure what "wrong name" so any screenshots/etc would be helpful in looking at what went off the rails for you.
[20:05] <rick_h> xarses_: bugs are tracked on GH at github.com/juju-juju-gui/issues
[20:05] <xarses_> ya working on those
[20:07] <xarses_> rick_h: for the oauth, I expected a dialog like https://drive.google.com/open?id=0B_Hn-o0wEGNfZHdLZmt4VTdYV1E
[20:08] <xarses_> I got https://drive.google.com/open?id=0B_Hn-o0wEGNfUVR6aVNGOGNVOUE as the first page
[20:09] <rick_h> xarses_: hmm, I think because the GUI doesn't request any of the account details it doesn't have that dialog
[20:09] <rick_h> xarses_: you only have to give approval if the application asks for the details so it can restore it locally for any reason
[20:12] <xarses_> I'd still expect the ask, its now linked to the wrong account because it just used the first cookie it found
[20:12] <xarses_> oauth is supposed to be explicit in this regard, the oauth host isn't supposed to allow the app if the user doesn't allow it
[20:14] <xarses_> with regards to the other issue https://drive.google.com/open?id=0B_Hn-o0wEGNfQ0Y0cmVwRUhEbDg
[20:14] <rick_h> xarses_: as for logging back out you're right there's not a box there. The work-around for the moment would be to wipe the cookies and local storage on the browser for the api.jujucharms.com domain from the browser :(
[20:14] <rick_h> xarses_: understand, it's not oauth atm but good feedback.
[20:15] <xarses_> rick_h: I haven't even authorized that account for jujucharms.com either
[20:15] <rick_h> xarses_: right so from there if you click on the model name you can click on "manage"
[20:15] <rick_h> xarses_: right, you're butting up against how ubuntu sso works
[20:15] <xarses_> and that its super broken for multiple accounts?
[20:16] <rick_h> xarses_: notice nothing through ubuntu sso has that setup. I think you can wipe https://login.ubuntu.com/+applications and remove the web login? I'm not sure
[20:16] <stokachu> Dwellr: it's building now, you can see the status here https://code.launchpad.net/~conjure-up/+snap/conjure-up
[20:17] <rick_h> xarses_: so the user/etc is the local juju account. The charmstore login is kind of on the side and doesn't effect the juju "admin" account you logged into the GUI in any way
[20:17] <stokachu> looks like it'll be at least 40 minutes before it starts
[20:17] <stokachu> usually takes about 5 minutes to build
[20:17] <xarses_> rick_h: ya, I get that but I can't log it out now, as its on the wrong usso account
[20:18] <rick_h> xarses_: right, so that's why I said that it's a valid bug to not have a logout of charmstore button there, so you'd have to remove the localstorage/cookies from your browser atm apologies
[20:22] <xarses_> k
[20:22] <xarses_> oh, those expand? thats totally not obvious
[20:23] <rick_h> xarses_: +1, the team's working on an updated profile page that groups things into more logical buckets and reworks that UX
[20:23] <xarses_> the grouping is fine
[20:23] <rick_h> xarses_: I hate the expandy-two-click stuff and it's not middle click to open in new tab friendly heh
[20:23] <xarses_> just the layout didn't imply that they could expand
[20:23] <xarses_> +2 to the middle click
[20:24] <xarses_> I have to have a 3-5 button mouse
[20:24] <xarses_> Idk how people live with out them
[20:24] <rick_h> lol
[20:24] <rick_h> xarses_: I get your point though after tinkering with this stuff. It just uses your current sso account vs allowing you to pick when you login
[20:26] <xarses_> oh, you don't get to "pick" with the oauth ask from openstack.org either, it just gives you a chance to logout and log back in with the account you want it to use
[20:26] <rick_h> xarses_: right
[20:26] <xarses_> lp and oauth askers seem to be cool with my two accounts
[20:26] <xarses_> these usso ones just pick the first one
[20:27] <xarses_> which was fine for the force portal
[20:27] <rick_h> xarses_: I've got a bug filed on the lack of the logout button but yea, I think there's some limitation on working with the login.ubuntu.com stuff. Will see
[20:27] <xarses_> but is annoying me with the charm store
[20:28] <rick_h> gotcha, sorry I didn't grasp what you meant at first. Because I have 2-fa it always stops up for me to 2fa but if you didn't have that it'll just dump right in.
[21:05] <magicaltrout> ya'll trying the Ceph PV stuff in the CDK readme
[21:06] <magicaltrout> and i get timeout expired waiting for volumes to attach/mount for pod "default"/"web". list of unattached/unmounted volume
[21:06] <magicaltrout> not having used Ceph before, what am i missing or where should I prod?
[21:14] <tvansteenburgh> magicaltrout: what's the output of kubectl get pv
[21:15] <tvansteenburgh> and kubectl get pvc
[21:20] <tvansteenburgh> magicaltrout: i gotta run, feel free to post on the ML or file an issue on the cdk repo
[21:26] <magicaltrout> no worries ex-tim
[22:52] <kwmonroe> magicaltrout: i don't have experience with ceph either, but if i were you, i'd swap that for something lighter, like hdfs.
[22:59] <magicaltrout>  hmmm kwmonroe its like deja-vu
[23:00] <magicaltrout> you're right though, i did
[23:00] <magicaltrout>  /tmp