[01:34] is there something in particular that i need to do to pass http proxy settings into LXD containers? [07:31] hey guys, can a peer relation only share private-address? [07:32] I'm trying to share some data across peers, but the relation data that i get is always the private address [07:33] Good morning Juju world! [07:34] junaidali: yes peer relations are just like the rest of the relations, you can share any kind of data [07:34] junaidali: You need to create an interface for that, let me find an example [07:35] junaidali: https://github.com/juju-solutions/interface-spark-quorum [07:35] Good morning kjackal, thanks. === frankban|afk is now known as frankban [09:17] Hello [09:19] when we run juju enable-ha --n 3 we will be avaible to run juju command on the second and third node like the first controller ? [09:19] i mean we will be able to run juju status on the 3 state server in ha mode ? [10:48] how do you run the same charm with different configurations since units have the same? [10:49] for example two mysql databases with different ports? [10:53] you name the services/applications differently [10:54] `juju deploy cs:mysql dba && juju deploy cs:mysql dbb` [10:55] mgz: thanks [10:56] mgz: can you get some kind of unique id from an application? [10:57] the service name is unique [10:57] mgz: not if you remove it and then start a new one with the same name right? [10:59] well, how is that distunguishable from a newly deployed service? config isn't kept if you destroy a service [11:00] mgz: right, ill create the id myself, probably best not to rely on something the user can specify if you want to ensure uniqueness anyway :) [11:01] in juju 2.0 do we need to bootstrap at lease 3 machine to enable ha with juju enable-ha -n 3 ? [11:02] you don't bootstrap three times. juju will take three machines if you want ha though. [11:04] i'm in manual environment did the ha work in manual environment ? [11:05] yes. you'll need to add-machine enough suitable things before calling enable-ha [11:05] i add 2 machine with juju add-machine ... and than juju enable-ha -n 3 --to 0,1 and i got machine 3 already a controller [11:05] i run juju status i see my new machine is add 0, 1 [11:05] and 0, 1 is a new added machine [11:05] did you add-machine in the right model? [11:05] machine 0 already controller sory [11:06] why guidline from doc in manual provisioning juju add-machine ssh:xx.xx and machine showing correctly in juju status [11:06] i follow the doc in 2.0 version [11:07] and also, it's 'ensure-availability' in 2.0 so I hope that's the command you're using [11:08] this command is in 1.25 ? because in 2.0 i don't see this command instead of enable-ha [11:08] my bad, I got it backwards [11:09] in 2.0 it has a seperate between agent list controller list right ? [11:09] yeah, there are two models by default [11:10] one for the controllers, and one empty and ready to use for workloads [11:10] anyway, feel free to file a bug with your steps and what error message you get [11:11] i'm not good at a bug report.. but will try [11:18] mgz: is it possible to have some kind of global configuration for every application deployment of a charm in the same config.yaml and then the specific options under the service namespace? [11:19] SimonKLB: I am somewhat confused about what you're trying to accomplish [11:19] something like [11:19] ssl-enabled: True [11:19] service_1: [11:19] port: 8080 [11:19] service_2: [11:19] port: 9090 [11:19] sure, but you split that [11:19] the config that generally applies goes in the charm [11:20] and the fact there is a port config option [11:20] the ports for specific services goes in the bundle [11:20] hmm, this is two services of the same charm [11:20] sure [11:20] im not using a bundle right now [11:21] you have a bundle that specifies all your services, and can include specific config for them [11:21] so it's not possible to have global configurations without a bundle ? [11:22] you can do everything via command line as well [11:22] so, write a script that says deploy this service, set this config, and so on [11:22] skin the cat however you want [11:23] yea thats what im looking to do right now, so in this example i deploy two services of the same charm, but i was thinking if it was possible to keep everything in the same config.yaml still [11:23] but to not having to repeat stuff in the config.yaml file i was wondering if you could keep the general config options at the top? [11:31] when enable ha other machine is down and sad lost connection [11:32] but running juju ssh still working find [11:32] fine [11:32] vibol: down means the agent isn't talk back, so check /var/log/juju and such [11:34] juju mongo connection fail @@ [11:34] it a strange problem [11:34] let see... [11:35] there 2 nic currently availble first primary one is private and has the static ip.. but why juju mongo try to connect the second nic instead because i set this nic to dhcp and get internet from my rounter [11:36] juju mongo shoud connect through the primary nic... but not sure === Guest21645 is now known as ahasenack === ahasenack is now known as Guest91977 [12:23] it seem like a bug ... because i can reproduce this problem anytime [12:25] vibol: please file one, I'm not sure how multiple nics and the manual provider are meant to play together [12:25] thank you.. i'm sorry to making u confuse [12:25] but there may be additional prerequisites on network setup before you can add-machine [12:25] juju seem to work not very well on manual provider [12:26] i can deploy a service as normal on my network setup for juju [12:26] the only problem os deploying ha only [12:27] yeah, it's likely that the state server requirements are stricter than for a normal service [12:27] as they need to do much more [12:27] i'm sorry before i file a bug [12:27] for instance, need to be on all networks that any other machine is on, and from your experience sounds like the local network setup also matters [12:28] i want to deploy all maas juju both in ha [12:28] and i want to deploy juju and deploy maas using juju [12:29] because the doc say it is possible to deploy maas using juju [12:29] er... you probably don't want to try that [12:29] -_- it really make me confusing [12:29] but why ? any problem ? [12:29] I'm aware of some very experimental maas charms [12:30] ohh [12:30] but the normal way is you just deploy maas, then can use juju for workloads on top [12:30] good [12:30] ... [12:30] juju drives maas quite happily [12:30] i though deploy maas in ha by hand is very hardwork [12:30] but it the same on juju with manual provisioning -_- [12:31] yeah, that is also true [12:31] well, it's easy with homogenous envs [12:31] i guess i should start maas in deploy juju on top of maas and see how it work first [12:33] and also can we install landscape with ha without using juju @mgz [12:39] vibol: I believe so, but you'll need poke landscape for that === frankban is now known as frankban|afk === petevg_afk is now known as petevg === frankban|afk is now known as frankban === frankban is now known as frankban|afk === zz_CyberJacob is now known as CyberJacob === CyberJacob is now known as Guest22220 [19:42] i have a question about charms running in a private maas deployment. i have configured http proxy in the model at bootstrap and things tend to come up fine so long as they are running inside lxd containers; however, whenever I try to deploy something directly to a maas machine, it tries to talk to the api server over ipv6. this normally woudn't be a problem but the requests are hitting my proxy server and are being rejected [19:43] trying to formulate a question.. lol. How about: is there a way to force the charm deployment to only communicate over ipv4? [19:47] vmorris: juju allows using a contraint for deployment that might help there. You'd have to setup different spaces in maas for ipv4/6 subnets perhaps? and then get juju bootstrapped onto the ipv4 space and I would hope we'd use that to communicate vs the v6 [19:47] vmorris: if that doesn't work I'd suggest mailing the list and I'll get some of our networking folks to formulate a more intelligent response vs a guess [19:48] rick_h_ - we used to have a prefer_ipv4 thing in the 1.24 era [19:48] lazyPower: right, that went away [19:48] rick_h_ - do you konw if that got scrubbed? i'm not finding it in teh docs anymore [19:49] ok, thats what i suspected. [19:49] thanks for confirming [19:49] lazyPower: yea, caused some issues as much as it solved and we need a better way to do that right [19:49] * lazyPower nods [19:49] rick_h_: hmm, okay. i've been able to keep ipv6 subnets from showing up in MAAS by disabling the v6 stack on the maas controller [19:49] but I keep ending up with messages like this in the juju debug log: ERROR juju.worker.dependency "uniter" manifold worker returned unexpected error: preparing operation "install cs:neutron-gateway-232": failed to download charm "cs:neutron-gateway-232" from API server: GET https://[fd55:faaf:e1ab:a4f:5054:ff:fea9:25aa]:17070/model/3a3a6a0e-e580-437c-8b25-211b188de393/charms?file=%2A&url=cs%3Aneutron-gateway-232: Get https://[fd55:faaf:e1ab:a4f:5054:ff:fea9: [19:49] 25aa]:17070/model/3a3a6a0e-e580-437c-8b25-211b188de393/charms?file=%2A&url=cs%3Aneutron-gateway-232: Forbidden [19:49] ew sorry [19:50] these requests are hitting my http proxy server and are getting denied there [19:50] vmorris: hmm, but is something in the proxy path getting routed via ipv6? I mean if the ipv6 stack isn't on in maas not sure how juju would be initiating ipv6 traffic [19:52] rick_h_: that's another thing i don't understand, this is the sort of message I see in the squid access log: [19:52] 10.20.95.61 TCP_DENIED/403 3936 CONNECT [fd55:faaf:e1ab:a23:5054:ff:fe14:7dc2]:17070 - HIER_NONE/- text/htm [19:52] wouldn't thins indicate that the request is coming in on ipv4? [19:53] vmorris: hmm, 17070 is the controller port. I'm not sure on the ipv4 part. Would have to try to match those ip addresses with your infrastructure and see what machines are doing what there [19:54] rick_h_: these are all maas machines and lxd containers that came up as a result of a juju deploy [19:55] vmorris: right, but you're saying that the nodes don't have ipv6 enabled [19:55] vmorris: and so the ipv6 addresses must be coming from some dhcp/etc on the network? [19:55] ah no.. the maas controller doesn't have ipv6 enabled [19:55] i don't know if i can control ipv6 on the nodes [19:56] vmorris: so I'm curious how the deployed nodes/containers have ipv6 addresses [19:58] rick_h_: ooh i see what you're saying [19:58] vmorris: right, the nodes and containers get their addresses either as hard coded or via the dhcp server maas runs. [19:59] vmorris: either way, the data comes from maas unless there's another thing in the mix there [19:59] rich_h_: there's definitely not another dhcp server.. and i only enabled dhcp on the 10.20.95.0/24 subnet.. yes where are they getting these addresses? [20:00] here i'll get on the juju controller node and dump out some information [20:01] rick_h_: https://paste.ubuntu.com/23389877/ [20:05] rick_h_: v6 addressing looks like it's coming in through MAAS metadata, looking for confirmation [20:11] rick_h_: lazyPower: perhaps i should've been more clear.. i've disabled ipv6 on the maas-controller itself, but there is a way to disable it in the region/rack settings as well? === matthelmke_ is now known as matthelmke [20:44] rick_h_: let me back up and ask a more pointed question.. if i have 3 interfaces on a maas machine, but only want to use 2 of them in my juju deployments, i can do this with spaces? [20:45] or, even more to the point - if i have internet connectivity out of one interface, but want to run my juju applications on another, how is this configured? [20:48] also, according to the docs, spaces are only supported on EC2 [21:46] question: when running juju deploy with --debug, i'm seeing some messages from httpbakery client.go GET to api.jujucharms.com -- are these requests coming from the juju controller machine? === Guest22220 is now known as CyberJacob === CyberJacob is now known as zz_CyberJacob