[00:06] vino: the bzr command is "bzr revision-info" [00:08] wallyworld, do u think we should define the device constrains at `juju/juju/device` or somewhere else? [00:10] hmmm. i think "devices" is ok for now [00:11] in the root dir `/devices`? [00:16] ok. [00:19] wallyworld : and for mercurial hg equivalent is hd id --id [00:19] great [00:19] kelvin: yeah, i think so for now [00:20] wallyworld, great, thx [01:35] wallyworld, kelvin: how about core/devices? [01:35] i had wanted to move the /network into core/network [01:35] as long has it has no state or api dependencies [01:36] core/devices looks a good one, [01:37] yes, then we can shorter the root dir ls [02:13] thumper: we should move storage as well then [02:13] wallyworld: yes [03:05] anastasiamac: if you have a moment? https://github.com/juju/names/pull/89 [03:11] veebers: want to talk about resources? thumper has stodd me up for our 1:1 :-) [03:11] wallyworld: hah, sure thing [03:11] wallyworld: we did have a long catch up this morning :) [03:12] we did. but you could have told me :-) === mup_ is now known as mup [03:14] wallyworld: sorry, was planning to but got stuck talking to xavpaice [03:25] wallyworld, could I have ur a few minutes? [03:36] thinking if it's reasonable to consolidate the struct (params struct) at api and apiserver in single place. [03:39] to have the api schema shared for client, server side, or other dependencies. [03:44] kelvin: sure, just finished talking to chris, free now [03:45] c u in hangout [03:45] now? [04:08] thumper: will the hub drop messages if the handler takes too long? [04:09] (I mean, if a subscribed handler takes too long) [04:46] wallyworld: reviewed.. [04:46] ty [04:52] anastasiamac: i pushed a change to use a common method [05:06] wallyworld, could u take a look the PR again when u have time? thx [06:35] wallyworld: have a min ? [06:35] sure [06:35] HO [06:36] am in standup === frankban|afk is now known as frankban [07:54] babbageclunk: no [07:54] good [07:54] did you want to chat about it? [07:55] * thumper is back in the office for a bit [07:55] no, it's fine [07:55] thanks! [07:55] jam: are you back around? [09:04] thumper: hey, just got back, quite the adventure.. are you still here? [09:10] um... was just about to leave, but can chat [09:11] jam: did you want to catch up? [09:15] thumper: sure. Just chatting with manadart, will be available in 2min. [09:16] kk [09:29] Need a review for: https://github.com/juju/juju/pull/8838 [09:33] manadart: i'll take a look [09:34] manadart: just out of curiosity, but jam will probably want to vet the whole thing (?) [09:38] stickupkid: Assume so. [10:06] manadart: done - just a few questions [10:06] stickupkid: Shoot. [10:23] manadart: questions in the PR [10:28] stickupkid: Ta. [11:05] hi. I am trying to deploy a juju maas controller and it starts to deploy but i notice later on it looks for an IP (that was MAAS's old IP address) and then fails to deploy. Is there a way to get the details of what it is looking for. I have changed all ips and restarted all services on MAAS. I am not sure why it is still looking for the old address. [11:07] naturalblue: Did you re-deploy juju? [11:07] the controller? [11:08] If not, i think you need to reconfigure your cloud providers in juju [11:14] ah that maybe it. i think although i removed the cloud provider after the controller, i possible changed its ip after i added it back in. [11:14] I will give it atry and let you know. [11:14] BlackDex: Thansk [11:15] no, i just checked with juju show-cloud openstack-maas and the endpoing shows the correct ip (i.e. the new IP) [11:17] but cloud-init is definitely looking for the old address and then aborting [11:17] during boot? [11:17] pxe boot? [11:19] Please check the if the IP's are correct during the following command: `sudo dpkg-reconfigure maas-region-controller maas-rack-controller` [11:21] during pxe boot, after i ask to bootstrap a new controller, maas rolls the OS, then juju starts the deploy of the controller. Watching the console its installing but suddenly i see a cloud-init script that references the old ip address of maas and the system shutsdown [11:22] the ip in `sudo dpkg-reconfigure maas-region-controller maas-rack-controller` was incorrect, it was the old one [11:23] i didnt realise i had to run that after chaning the ip from the maas web ui and rebooting [11:25] its asking for the api address now on the dpkg-reconfigure. Do i put in thr port of 5240 or is that just for the web gui [11:56] 5240 [11:56] that is the API port [11:56] port 80 wil be deprecated in 2.4 or 2.5 if i'm correct [11:57] yea, you can change those in a file somewhere, but this is better, and it restart the services needed after :) [12:02] naturalblue: it might be in the cache for the cloud in .local/share/juju/clouds.yaml [12:14] BlackDex: rick_h_ : Thanks [12:15] stickupkid: Are you in any position to push your changes that further strangle out rawProvider? [12:16] stickupkid: I am having rewrite provider tests and it makes no sense to be stubbing/mocking out changes to something we are ditching. [12:17] anyone know why if i try and deploy to a machine into an lxd container [12:17] it sets my resolv.conf seemingly incorrectly and the charm fails to apt update? [12:17] magicaltrout: bionic? [12:17] magicaltrout: there was a bug around that for bionic I know that was worked on and a fix landed [12:18] the controller is on bionic the machines are xenial [12:18] magicaltrout: https://bugs.launchpad.net/juju/+bug/1764317 [12:18] Bug #1764317: bionic LXD containers on bionic hosts get incorrect /etc/resolve.conf files [12:29] Hello, I am trying to deploy a service with juju. I want to deploy it inside an lxd container. Till now ok. But I want to add 2 NIC, how can I do? [12:43] manadart: i can do, but it's broken a few things... let me just fix what i've got so you can at least see what i've done [12:56] manadart: this is a very much work in progress - https://github.com/juju/juju/compare/develop...SimonRichardson:lxd-schema?expand=1 [12:56] manadart: i'm in the middle of refactoring the tests, before I get to the construction of the provider - although I may change my mind whilst I'm writing the tests [13:06] stickupkid: Ta. === zeus is now known as Guest21990 === Guest21990 is now known as zeus [14:24] when i try to install juju gui with juju upgrade-gui i get this "ERROR cannot upgrade to most recent release: cannot retrieve Juju GUI archive info: error fetching simplestreams metadata: invalid URL "https://streams.canonical.com/juju/gui/streams/v1/index.sjson" not found" [14:25] ^^but i have tried a wget and can retrieve the file from both the client and the controller [14:30] ^^ please ignore this. turns out i had a proxy variable in /etc/environment which get reapplied on a reboot. removed now and variables unset. [15:34] Hi I just booted three ceph osd that were shutdown. One came up fine but the other two say they are stuck in upgrading. The log message I am getting is DEBUG config-changed Error ENOENT: error obtaining osd_hostname_luminous_start. [15:34] Any idea where this luminous start file is located? === Guest53 is now known as acss [16:07] Anyone know why I would see the following in a juju ceph-osd unit log? 2018-06-21 16:03:06 INFO juju-log Monitor config-key get failed with message: b'' [16:07] acss: hmm, some sort of unexpected config value the charm couldn't parse? [16:08] This would be based on my ceph.conf file? [16:30] I am confused because I have another OSD functioning fine with the same charm configuration. === frankban is now known as frankban|afk [16:43] acss: sorry, ran for lunch stuff. So this is the juju config [16:43] acss: so you can see what you've got with juju config ceph-osd [16:43] okay [16:44] where is this located? [16:47] acss: so it's the config juju is told to send to the charms and changes to that config triggers the charm's config-changed event which then causes it to evaluate things and update any local files/apis/settings that need updating for the software in question [16:47] okay thank you === Guest16456 is now known as jose [21:23] hello all... we have bootstrapped a controller out on AWS cloud and deployed rabbitmq, juju status displays the internal cloud IP address. However, i want to query rabbitmq via the assigned floating ip address, will juju correctly translate/route floatingip -> internal cloud ip? [21:32] sfeole: so you need to expose the rabbit unit for the floating IP to be the one to work since by default the firewall won't allow any traffic to it [21:32] patriciadomin, ^^ [21:33] rick_h_, so just, juju expose ? [21:33] sfeole: juju expose rabbitmq or whatever the application name is [21:33] sfeole: that'll set the firewall rules as long as the charm is setup to expose the rabbit port [21:33] rick_h_, ok thanks, [21:33] patriciadomin, ^^ [21:36] rick_h_ sfeole thx