[11:06] <myeagleflies> hello
[11:06] <myeagleflies> I'm having problems bootstrapping juju 2.0 on ubuntu 16.04.1
[11:07] <rogpeppe> myeagleflies: what's the problem?
[11:07] <myeagleflies> following https://jujucharms.com/docs/devel/getting-started
[11:07] <myeagleflies> when executing: "juju bootstrap lxd-test localhost"
[11:07] <myeagleflies> getting error:
[11:07] <myeagleflies> ERROR failed to bootstrap model: cannot start bootstrap instance: Missing parent 'lxdbr0' for nic 'eth0'
[11:08] <myeagleflies> ifconfig shows there are following interfaces: "ens160 lo openstack0"
[11:08] <myeagleflies> so possibly juju expects eth0 to be still around?
[11:09] <stub> myeagleflies: Do you know if you have lxd working on your machine. There is some lxd setup needed that might not be mentioned in the Juju docs ('lxd init' I think)
[11:10] <myeagleflies> lxd init succeeded
[11:11] <stub> myeagleflies: Do you have the older lxc installed? lxd brought in the lxdbr0 bridge, and it might be conflicting with the old lxcbr0 bridge
[11:12] <myeagleflies> let me check
[11:13] <myeagleflies> stub: dpkg -l lxd* shows only current version
[11:14] <myeagleflies> ii  lxd                                  2.0.4-0ubuntu1~ubuntu16 amd64                   Container hypervisor based on LXC - daemon
[11:14] <stub> Thats my guesses out the window then
[11:14] <myeagleflies> ;)
[11:15] <stub> IIRC lxcbr0 should be brought up automatically as required by lxd.
[11:16] <stub> "lxc launch ubuntu:" might help narrow down if this is a juju or lxd problem
[11:18] <myeagleflies> I'm experiencing some DNS resolving issues on this host. This host also runs MAAS. Can juju be bootstrapped on some other host?
[11:19] <myeagleflies> I presume this should be possible?
[11:19] <stub> yes. You can point it to an lxd configured to allow remote access IIRC, but I don't know the details.
[11:20] <stub> (or any other cloud provider, including your MaaS if you have enough spare hardware)
[11:22] <myeagleflies> what I'm saying is I'm trying to bootstrap juju on same host that is running MAAS. I will try to bootstrap it on some other 'fresh' host and just asking if juju is fine with being run on different host withoug MAAS on it?
[11:35] <stub> Yes, Juju doesn't need MAAS. I don't have it anywhere.
[12:47] <cholcombe> how do you juju deploy from the edge channel?
[12:47] <cholcombe> also, the docs are out of date.  the development channel no longer exists apparently
[13:21] <marcoceppi> cholcombe: juju deploy <charm> --channel=edge
[13:23] <cholcombe> marcoceppi, thanks. I found the docs mention it in one place but in another place it says development
[13:23] <marcoceppi> cholcombe: please make sure to file bugs against the docs
[13:23] <marcoceppi> esp as we're so close to 2.0 now
[13:23] <cholcombe> will do
[13:59] <cholcombe> cmars, do you know how to breakpoint juju?  I'm trying to track down a bug where juju refuses to deploy my charm
[13:59] <cholcombe> cmars, i've got gdb and dlv installed
[13:59] <cmars> cholcombe, ping #juju-dev, or i can help in now + 2-3 hr
[13:59] <cholcombe> cmars, ok
[14:33] <jamespage> stub, was the removal of the juju-wait bzr branch intentional? I see its moved to git on lp - I must of missed the headsup on that
[14:40] <stub> jamespage: An unfortunate side effect of switching to git, per https://bugs.launchpad.net/launchpad/+bug/1623924
[14:40] <mup> Bug #1623924: git-based source build recipes are sometimes interpreted as bzr recipes instead <Launchpad itself:New> <https://launchpad.net/bugs/1623924>
[14:41] <stub> jamespage: I can put things back as they were if you can't deal with the change now, although obviously I'd rather not.
[14:42] <jamespage> stub, dunno trying to find beisner to check on move
[14:42] <jamespage> stub, our gate is bust right now
[14:49] <papertigers> where is `juju actions` in juju2?
[14:49] <papertigers> juju help doesnt show it and running it doesnt work
[14:49] <magicaltrout> same place
[14:49] <magicaltrout> juju list-actions
[14:49] <magicaltrout> juju run-action i think
[14:49] <magicaltrout> juju show-actions
[14:51] <papertigers> thanks
[14:51] <papertigers> also new to juju, so how do I restart services or nodes
[14:54] <magicaltrout> er
[14:54] <magicaltrout> i've not done that in 2 years of using it
[14:54] <magicaltrout> juju ssh unit/0 restart
[14:54] <magicaltrout> or something
[14:54] <magicaltrout> ssh commands run as root and you can address services or units
[14:55] <magicaltrout> so that would work
[14:55] <magicaltrout> i don't know if there is a "proper" way
[14:56] <papertigers> I only ask because a few of the services are not running properly after a deploy
[14:56] <papertigers> they are in the error state
[15:30] <lazyPower> magicaltrout: actions would be a proper way to do that. you should honestly get int he habit of using juju-restart in a hook context
[15:30] <lazyPower> magicaltrout: it'll ensure all the lxd containers on the host are prepared to handle the reboot as well
[15:31] <lazyPower> in a hyperconverged world, that will be a big deal
[15:32] <lazyPower> magicaltrout: so, in summation, stuff reboot in an action, and when invoking that action instead of `reboot now` it becomes `juju-reboot` or `juju-reboot --now`
[15:32] <lazyPower> which also paves the way for signaling other units/applications participating of the reboot sequence and they can then react/handle temporary routing changes if the underlying app doesn't do this natively.
[15:33] <lazyPower> but thats pie in the sky talk there...
[15:33] <magicaltrout> there you go then
[15:44] <cory_fu_> kwmonroe, petevg, kjackal: Can I get a review on https://github.com/juju-solutions/interface-spark/pull/9
[15:46] <petevg> +1
[15:47] <cory_fu_> petevg, kwmonroe: Hrm.  I just realized that that PR accidentally included an unrelated change as a drive-by, which makes it more significant of a PR.  Maybe I should split it out
[15:48] <cory_fu_> (The two commits)
[15:49] <petevg> The code all made sense, and seemed to do what you intended. I guess that it could use more tests, for the classpath stuff.
[15:54] <kwmonroe> cory_fu_: in SERVICE scope, don't you still need to wait to remove .joined until the last unit is departing?  https://github.com/juju-solutions/interface-spark/pull/9/files#diff-6e152090b45a29ed86305121942fb300L30
[15:55] <kwmonroe> i love conversation scopes, btw.  just love them.
[15:56] <cory_fu_> kwmonroe: heh.  And no, I don't think so.  For non-GLOBAL scope, the conversation when inside a hook handler should only contain that one unit.  I think
[15:59] <cory_fu_> kwmonroe: Hrm.  You might be right, and that might be a bug that affects almost all interface layers.  :/
[16:00] <kwmonroe> easy enough to test cory_fu_.. do you have a deployment with multiple sparks using this interface that we can break into and check conv.units in a hook?
[16:00] <cory_fu_> Not up right now
[16:02] <kwmonroe> aight, i can build up a spark to try that in a few minutes.. gotta sort out some docker/mac issue first though.
[16:16] <cory_fu_> kwmonroe, petevg: Actually, I just remembered that the use-case I had for this (insightedge as a subordinate to spark) went away, so we could probably even just ditch that part.
[16:16] <petevg> Sounds good. Less code is good code.
[16:24] <bildz> is there a dedicated channel for conjure assistance?
[16:24] <stokachu> bildz: o/
[16:24] <marcoceppi> you found it!
[16:25] <bildz> hey stokachu
[16:25] <bildz> im dealing with some conjure scripts that arent working well for me atm
[16:26] <stokachu> bildz: custom scripts or ones in the available spells?
[16:26] <bildz> the ones in the available spells
[16:27] <stokachu> bildz: ok whats up
[16:27] <bildz> i'm able to get a juju controller up and all my nodes, but there is a failure during the neutron setup
[16:27] <bildz> https://bugs.launchpad.net/conjure-up/+bug/1626941
[16:27] <mup> Bug #1626941: neutron-gateway/0: hook failed: "config-changed" for Openstack local <conjure-up:In Progress by adam-stokes> <https://launchpad.net/bugs/1626941>
[16:28] <stokachu> bildz: subprocess.CalledProcessError: Command '['ip', 'link', 'set', u'eth1', 'up']' returned non-zero exit status 1
[16:28] <stokachu> thats failing
[16:28] <stokachu> meaning that no eth1 exists on the system where that command was run
[16:28] <bildz> well it's using a xenial image
[16:28] <bildz> and as we know, the interface names have changed
[16:28] <bildz> is that why it's failing?
[16:29] <stokachu> could be
[16:29] <stokachu> bildz: you have maas setup?
[16:29] <bildz> i do
[16:29] <stokachu> sorry maas 2.0?
[16:29] <bildz> let me get the version i have
[16:29] <bildz> ii  maas                               2.0.0+bzr5189-0ubuntu1~16.04.1
[16:29] <stokachu> bildz: cool one sec, lemme get a screenshot of what i do
[16:29] <bildz> thanks man
[16:31] <bildz> so when I conjure-up openstack, I connect to the MAAS deployment and it spins up a server to install the juju controller
[16:31] <bildz> then the rest all come up in sequence to deploy
[16:32] <stokachu> bildz: yea exactly
[16:32] <stokachu> here is the page: http://imgur.com/a/m4JdJ
[16:32] <stokachu> you want to set that under global kernel parameters in settings
[16:32] <bildz> ooo thanks
[16:32] <stokachu> that'll change the default behavior of your maas nodes to not do that auto naming
[16:33] <bildz> aw man thanks
[16:33] <bildz> ill give this a shot now
[16:34] <stokachu> bildz: cool
[16:37] <stokachu> bildz: one thing im not entirely sure if it requires you to re-commission your nodes
[16:37] <stokachu> bildz: keep that in mind if the network interfaces are still being renamed
[16:41] <cory_fu_> kwmonroe, petevg: https://github.com/juju-solutions/interface-spark/pull/9 updated
[16:42] <bildz> stokachu: i've recommissioned them all and they all reflect the new settings
[16:42] <bildz> thanks for the heads up though
[16:42] <bildz> i've been through this process about 20 times :)
[16:42] <bildz> with that said, going to add this channel to my autojoin for irssi heh
[16:47] <stokachu> bildz: cool, yea i got conjure/conjure-up on highlight so just mention that and ill see it
[17:32] <cory_fu_> petevg: https://github.com/juju-solutions/interface-spark/pull/9 updated
[17:33] <petevg> cory_fu: +1
[18:05] <gQuigs> new to Go.. how can I build juju 1.25?  the instructions seem geared towards trunk...
[18:10] <myeagleflies> is juju 2.0 ok with interface names like 'ens160'?
[18:10] <myeagleflies> "ERROR failed to bootstrap model: cannot start bootstrap instance: Missing parent 'lxdbr0' for nic 'eth0'"
[19:53] <marcoceppi> myeagleflies: that interface name should be okay
[21:10] <bryan_att> hi anyone that can help with a charm-tools issue I am having - narindergupta pointed me here for help. charm-tools is failing with this error "pkg_resources.DistributionNotFound: The 'paramiko<2.0.0' distribution was not found and is required by charm-tools" but paramiko 1.16.0-1~cloud0 is installed
[21:21] <holocron> I'm fooling with juju lxd here, and following a reboot, none of my lxc containers will start properly. With no lxc processes running, I can run lxc list without issue, but "lxc start <container>" hangs. If I CTRL-C and check ps, there's something called "forkstart" still running, and two more processes of [lxc monitor] on the container.
[21:21] <holocron> commands like "lxc list" or "juju status" hang with no output until I kill the lxc processes with SIGKILL
[21:21] <holocron> anyone seen this behaviour before?
[21:33] <bdx_> is there a way to specify what subnet to bootstrap to by using constraints?
[22:26] <lazyPower> bryan_att: looks like you might be missing some deps that i think are in teh ppa
[22:26] <lazyPower> bryan_att: do you have ppa:juju/devel and ppa:juju/stable installed? additionally are you using the snap or the deb package to get charm-tools?
[22:26] <lazyPower> holocron: thats new, but totally bug worthy
[22:28] <holocron> lazyPower: sigh alright i hate opening up bugs
[22:28] <holocron> lazyPower: i'll see if i can duplicate it again, I'm in the process of reinstalling the base OS now ^^
[22:31] <bryan_att> lazyPower: not sure about those deps, let me check with narindergupta - the JOID installer for OPNFV setup the environment
[22:35] <bryan_att> lazyPower: narinder may be gone by now - how do I answer "do you have ppa:juju/devel and ppa:juju/stable installed? additionally are you using the snap or the deb package to get charm-tools?"
[22:35] <cholcombe> is there a bug report needed to refresh promulgated charm code?
[22:40] <petevg> bryan_att: to check for the ppas being installed, you can open a terminal and run 'ls /etc/apt/sources.list.d/ | grep juju', or open "Software and Updates" and look on the "Other Software" tab.
[22:41] <petevg> bryan_att: if you installed charm tools via the ppa, then
[22:41] <petevg> running 'dpkg --list | grep charm-tools' on the command line will return a result.
[22:41] <bryan_att> https://www.irccloud.com/pastebin/1zesvxmG/
[22:41] <petevg> bryan_att: Similarly, you can do 'snap list | grep -i charm' to check to see if you have installed the snap.
[22:42] <bryan_att> https://www.irccloud.com/pastebin/tDeyOCSn/
[22:43] <petevg> bryan_att: it looks like you have the stable ppa, but not he devel ppa. And it looks like you've installed charm tools from that ppa.
[22:43] <bryan_att> narinder said "we use ppa:juju/stable and deb package no snaps"
[22:44] <petevg> bryan_att: what command are you running when you get the error that you pasted?
[22:46] <bryan_att> petevg: the JOID installer for OPNFV, the step was "charm build -s xenial -obuild src" for the Congress charm (git clone https://github.com/gnuoy/charm-congress.git xenial/charm-congress)
[22:48] <petevg> Hmm ... So the error is happening when Juju is attempting to put the Python packages in the wheelhouse. Have you updated your apt packages, either via the software updater, or via "apt update && apt upgrade" recently?
[22:50] <bryan_att> yes, I ran apt-get update and " sudo apt-get dist-upgrade -y" as directed by narinder but it didn't help
[22:54] <petevg> bryan_att: Have you ever installed charm tools via pip? One possibility is that you have some crossed dependencies in your Python environment.
[22:55] <bryan_att> petevg: not sure - is there a way for me to clean it up and reinstall in case?
[22:56] <bryan_att> petevg: the tools are automatically installed by the JOID installer I think
[22:58] <petevg> bryan_att: you could uninstall the apt packages, then do 'pip freeze | egrep -i "charm|juju"', and uninstall any packages that remained using pip. But I'm not sure that's the best course of action here.
[22:59] <petevg> bryan_att: if you can, it might be best to stand up a VM and try running through the setup inside of that. If you run into the same issue, then the installer or instructions you're following are possibly broken, and you should file a ticket with the people who wrote them.
[23:03] <bryan_att> petevg: they claim the issue does not occur in their environment - I'm not sure what value it would be to debug why this is happening - I just need to get beyond it; maybe just reinstall my jumphost I guess. A pain but it appears there is no clear way to clean this up. One of the reasons I abhor python...
[23:10] <petevg> bryan_att: good luck! Sorry that I couldn't find a quicker fix for you.
[23:11] <bryan_att> petevg: thanks for your help though - it's been a while since I ran into an issue I couldn't work around, and reinstall is a chance to upgrade to xenial I guess...