[08:00] hi there. i'm using juju (2.0.2) to deploy an openstack cloud over maas 2.1. each server has 2 eth ports, one for management/internet the other for openstack internal communication. problem is juju picks the "internal" ip instead of the first one. [08:00] looks something like in https://bugs.launchpad.net/juju/+bug/1616098 [08:00] Bug #1616098: Juju 2.0 uses random IP for 'PUBLIC-ADDRESS' with MAAS 2.0 <4010> [08:38] Good morning Juju world! [08:39] Hetfield: you might want to also report this at #juju-dev and #openstack-charms [10:22] kjackal: i created a separated network space in maas may fix the issue. how to pass it in a bundle.yaml? [11:23] Hetfield: this is for deploying openstack on top of maas, right? [11:24] Hetfield: Is the extra network suposed to be a configuration parameter on a charm? [11:24] Hetfield: You might need to grab the bundle and edit it to put in the parameter [11:45] hmm [11:45] i just can't get juju working with sshuttle :( [11:48] hmm, not sure how to solve this [11:49] and juju doesn't seem to understand ssh jumphosts :P [11:53] bbcmicrocomputer: do you have a minute to talk about contrail charms? [12:09] ugh, why can't juju ssh :( [12:18] hmz, i don't understand what juju is doing [13:00] kjackal: i got the yaml [13:01] but where to put the contraint? i could not find docs about supported params [13:21] Hetfield: I am not familiar with how openstack is deployed so you will have to help me abit to understand [13:21] Hetfield: Is there a parameter in any of the charms on the bundle you are deploying that should/could consume the extra interface? [13:22] Which bundle are you deploying [13:22] ? [13:23] it's not important which bundle [13:23] i mean: you can use contraints: tags=storage arch=amd64 [13:24] i dunno if i can put space=internal there too [13:25] now it's just stuck at "Fetching Juju agent version 2.1.1 for amd64" [13:25] --debug should really put all tools it uses into debug [13:26] Hetfield: would that help: https://jujucharms.com/docs/2.1/network-spaces ? [13:34] hmz [13:34] dammit >,< [13:43] ok... i think, maybe. i got it working [13:43] maybe [13:47] how do I remove a deployed charm? [13:49] cnf: juju remove-application [13:50] ok, ty [13:51] hmm [13:51] now i can't deploy juju-gui to the juju controller [13:53] hmm, and I have a machine stuck in "0 pending 172.20.20.14 nx6rta xenial default" [13:53] maas shows it as ready [13:56] juju gui should be integrated to the controller in juju 2.0 [13:56] yeah, it seems so [13:56] i'm new to juju, this is my first setup [13:57] cnf: do a juju gui --show-credentials [13:57] yeah, _just_ figured that out :P [13:57] thanks :P [13:58] ok, only took me 5 days to get maas/juju working :P [14:00] now i just need to figure out how I clear this one "0 pending 172.20.20.14 nx6rta xenial default" [14:02] cnf: if this is a provisioning issue you could try juju retry-provision [14:02] ERROR unrecognized command: juju retry-provision ? [14:02] and the machine is down, i basically want it to release it [14:05] cnf: sorry it is juju retry-provisioning [14:44] hmm [14:44] no, it's stuck in pending [15:14] i have tried for days to do a juju bootstrap on a maas kvm node. every single time it ends the same way - "Fetching GUI 2.4.3" followed by "ERROR failed to bootstrap model: bootstrap instance started but did not change to Deployed state". i'm watching the kvm node running through ridiculous amount of cloud-init and useless package installations but always after 20 minutes, it ends at this error. if it's a timeout issue, how do i increase the 20 minute t [15:16] disposable2: did you run with --debug? [15:16] more debug info at pastebin.com/vxQ4WEs7 [15:16] there is a command to increase the timeout [15:16] but 20 minutes i think should be plenty? [15:17] cnf: i don't understand why the kvm node on ssd is slower than physical nodes. [15:17] are you sure it is? [15:17] it might be timeouting on something else [15:17] can the node reach the internet? [15:18] cnf: i don't know how to find out [15:18] yeah, i just spent 5 days playing to get the right nobs set :P [15:18] disposable2: in maas, you can see the ip of the kvm node [15:18] ssh to it, and checlk? [15:20] cnf: as far as i can tell, every time i switch the node on, it gets pxebooted, runs through cloud init and shuts down. [15:20] well, ssh to it as soon sas maas says it's up [15:21] cnf: since the cloud-inits run through fine and don't give me errors i'd say it's got internet access through the maas server (as a gateway) [15:24] well, maybe [15:24] but why not test? [15:27] disposable2: i had to add --config https-proxy=http://:8000 to my deploy [15:27] and --config http-proxy === joedborg_ is now known as joedborg [15:36] cnf: well, i've finally logged in (the kvm machine is ridiculously slow) and no, i can't ping anything. the default route is through the maas server but it hasn't got masquerading/nat-ing so traffic isn't passed further. which is weird bcause at the same time i can see cloud-init installing shitton of stuff [15:36] pass the --config http-proxy and --config https-proxy [15:37] cnf: pass that how to what [15:37] juju bootstrap --config http-proxy=http://172.20.20.1:8000 --config https-proxy=http://172.20.20.1:8000 dsmaas dsmaas-controller --debug [15:37] is what I ran [15:37] 172.20.20.1 beeing the maas controller ip [15:38] there is a field in x.x.x.x/MAAS/settings -> Network Configuration -> Proxy for APT and HTTP/HTTPS. is that the same thing? [15:39] cnf: i meant http://x.x.x.x/MAAS/settings [15:39] no [15:39] not that i know, anyway [15:40] mind, i am new at this [15:40] cnf: ok, ihave to wait for the commissioning to stop before i can try it. [15:40] uhu [15:55] cnf: ok, i'm bootstrapping it with those proxy parameters now. in the meantime, would you happen to remember how to increase the timeout value? [15:57] --bootstrap-timeout ? [15:58] --config bootstrap-timeout [16:00] rogpeppe: hey can you remind me of the dance to promulgate something in the charm store please [16:01] jamespage: one mo, let me remind myself first [16:01] cnf: where do you get thees config options from? man juju is utterly useless. [16:01] haha [16:01] google [16:01] and lots of time [16:04] cnf: i'm ordering a "marco ceppi voodoo doll". every time there's something missing from the documentation i'll poke it with a fork. that'll teach them... years and years with almost no usable documentation. unless that's the entire point - to have to buy server support from canonical. [16:06] jamespage: two possibilities: it seems there's a "charm promulgate" plugin (but i don't know where it is). alternatively this command should work: [16:06] jamespage: bhttp -j put https://api.jujucharms.com/charmstore/v5/$charmid/promulgate 'Promulgate:=true' [16:07] :P [16:07] rogpeppe: that's the one [16:07] how do I get bhttp? [16:07] disposable2: i just want to install openstack, that's all [16:07] jamespage: go get github.com/rogpeppe/bhttp [16:07] cnf: i need ceph + openstack cinder [16:08] jamespage: you might need to do: cd $GOPATH/src/github.com/rogpeppe/bhttp; godeps -u dependencies.tsv [16:08] jamespage: if you've got some older packages still lying around [16:08] gl [16:10] rogpeppe: ok that sorted me out - thanks! [16:10] * jamespage goes to rewrite promulgate-thing [16:11] cnf: ok, same result, i'll try later with increaset timeout value. thanks for now [16:11] s/easet/eased [16:17] rogpeppe: any idea when that might make it into the charm tool itself? [16:28] jamespage: cool [16:28] jamespage: there is an external (canonical-only) command to do it [16:29] rogpeppe: ftr its "'Promulgated:=true'" [16:29] jamespage: oh drat, thanks [16:29] no worries [16:29] jamespage: ftr it's documented here: https://github.com/juju/charmstore/blob/v5-unstable/docs/API.md#put-idpromulgate [16:30] ta [16:30] jamespage: go get github.com/CanonicalLtd/charmstore-client/cmd/charm-promulgate [16:31] jamespage: actually you'll probably have to manually git clone that [16:31] jamespage: as go get doesn't like interactive authentication [16:31] jamespage: (there's a useful git config setting to make it work) [17:08] sys.path.insert(0, os.path.join(os.environ['CHARM_DIR'], 'lib')) === hml_ is now known as hml [19:04] o/ juju world [19:08] hey lazyPower am I reading this right, running juju deploy canonical-kubernetes will update an existing cluster? === Budgie^Smore is now known as stormmore [19:45] ok I just ran juju upgrade-juju -m controller and now I keep getting permission denied errors, just how screwed am I? [19:47] apparently not much, updated my client system and reran the upgrade and now it behaving [19:59] well that seems to have worked nicely :) [20:09] stormmore: yes, you are correct (re juju deploy) it'll upgrade the charm revisions if that's where you started your k8s deploy [20:14] thanks marcoceppi, I just updated my dev cluster === tbc is now known as Tim === Tim is now known as tbc0 === tbc0 is now known as tbc [21:22] hmmm now I am getting "an error on the server ("unknown") has prevented the request from succeeding " when I try and look at the logs in the k8s dashboard [22:30] stormmore: cdk or kube-core? [22:31] lP|lappy, cdk [22:31] stormmore: this is a manifestation of the api-load-balancer i suspect. The layer7 proxy causes a lot of not-obvious errors like that. [22:31] stormmore: we have a spike coming this week or next to hack on a layer haproxy replacement to bring that down to a layer4 proxy so it can talk SPDY [22:31] :-/ yeah and now after a test reboot of one of the nodes, containerd isn't starting :-/ [22:32] stormmore: make sure you're capturing these as issues so we can address them with minimal pain on your side. I've done some reboot tests and the units survived, but that doesn't mean there aren't hidden dragons in there [22:33] lP|lappy, you know me, first "try" and determine if the issue is my side or yours :P [22:33] this is true :) [22:33] but this is also my mantra [22:33] i'd rather close bugs than never know they exist. [22:33] lol metrics at their finest :P === hml_ is now known as hml [22:35] i honestly wish i could instrument the charms like that [22:35] but that also feels like a quick way to lose users [22:37] lP|lappy, this is the error Docker is giving me: FATA[0001] Error starting daemon: error initializing graphdriver: driver not supported [22:37] which seems odd as it was running just "fine" before the reboot [22:40] stormmore: is there a "NONE" in /etc/default/docker? [22:40] stormmore: i ran into a stray bug i wasn't able ot reproduce last week where a None got rendered in th edefaults file [22:44] Only line worth mention is DOCKER_OPTS=" " [22:59] looks like an issue with the aufs driver [23:01] "modprobe: FATAL: Module aufs not found in directory /lib/modules/4.4.0-65-generic" looks suspiciously like my problem! [23:05] looks like the updates I ran didn't update the linux-image-extras package! [23:10] love when I am multitasking trying to setup the office network while also troubleshooting cdk! [23:47] OK figured out what the problem was, just needed to install the correct linux-image-extra package [23:48] I am surprised that that doesn't get updated by apt update / upgrade though